Act I

Here’s my first post. I’ve been working on a first simple quest: animate a kitten.

I recommend you to download the code from github before continue reading.
I’ve inserted some links across the post. Some of these links will guide you to external resources. Other links lead to my code.
I will differentiate my links with this color.
It is important that you keep this in mind because it may be difficult to figure out what am I trying to do without reading the related code.

Please, forgive me for using other’s charset on this first steps. I know I will have to start drawing some day, but for the moment I rather focus on software design in order to avoid overwhelming myself.

Let’s go:

Summary

In this post, I will explain how I built:

  1. Main class.
  2. GameScreen.
  3. Data access.
  4. Nekomata.


1. Main

1.1. General purpose

This is where I call Screens. For now, I will use only one screen, so I won’t mess the code with multi-screen support. I’ll be back when I finish my first screen.

1.2. Analyzing the code

This class extends Game.

The first element you will find is an IF statement. This if encapsulates actions that are just needed when developing (when DEV_MODE is true), for example, getting all the images from a folder and generate an atlas, so I don’t have to use TexturePacker each time I want to add a picture.

Then I set the app’s configuration. I take almost all the values from MySettings class, which contains static values (that allows me to access them from anywhere).

Finally, on the create() method, I create and launch my screen.


2. GameScreen

2.1. General purpose
This is the game screen. It will show kitten’s combats to the player and make him puke rainbows.

2.2. Analyzing the problem
Well for now I will just try to show a kitten walking on the screen (but not moving).
For that purpose I will have to create an Actor, add it to a Stage and watch that stage through a Camera.

Where am I going to do this?

I can see that Interface Screen defines two interesting methods: show() and render().
show() is called only once, “when the screen becomes the current screen for a Game.”

render() is called each time the screen is rendered.

Obviously, I don’t want every single component of my screen to be created each time the screen is rendered, so maybe I should create them on the show() method. But… wait a minute. What happens if the player opens a potential “OptionsMenu” screen? The screen “GameScreen” will stop being the current screen for Game. Then when the player closes the OptionMenu screen, he will come back to GameScreen and recall show(), creating again all the components. I want them to be created just ONCE. And, what is the only method that will be called only once? The constructor! That’s the appropriate place to create my objects. Let’s implement it.

2.3. Analyzing the code

This class implements Screen.

At the constructor, I create an OrthographicCamera and a Stage.

Next, I set the camera for my stage.

Finally I will get some textures from my atlas and combine them to create an animated actor and make it act on my stage. I’ll explain this in detail in the following sections.


3. Data access

3.1. General purpose
Grant flexible access to external data.

3.2. Analyzing the problem
An atlas is a file that contains several textures which may be identified using their names. On my GameScreen, I need to retrieve a TextureRegion named “gatitos” from an atlas. I could do it like this:

Let’s analyze this piece of code. I am creating a new TextureAtlas using an internal file which is located at the path defined in the local string “pathToMyAtlas” variable. This would be OK as long as the file stays there and is always accessed this way, but…

Maybe this is not the best example to explain my worries, because an atlas will always be a file. But, if we reflect on the potential data we are going to use, for example, our cute fighting kitten’s stats, Health, Power, Attack, Defense… those statistics could be stored on an XML file, a database, a Java class… and what will happen if I later decide to change the storage device? (Who knows? We the women are so unpredictable!)

If I get used to access data like the code above shows, and I later decide to get health from the Health tag on an XML file, I will need to refactor every single line where I was using the static attribute. And I’m too lazy for that.

I need a flexible way to access data. Time to use one of the few things I learned during my frustratingly boring office work days: The DAO pattern.

3.3. Analyzing the code

Let me show you this little diagram I made with creately:

DAO Arch
DAO Arch

AtlasFile is the “data storage device”. It just stores a TextureAtlas. It uses the Singleton pattern, I borrowed Big Pugh’s implementation after reading this post. I used it because it provides a thread-safe, lazy-initialization implementation.

IAtlasDAO is an interface that will be implemented by every class specifying the access to the atlas file.

AtlasFileDAO is a concrete implementation of IAtlasDAO which gets the TextureAtlas from AtlasFile class.

AtlasDAOFactory is a enum that will return a concrete AtlasDao implementation. You can learn more about using enums to implement factory pattern here.
Back to the GameScreen constructor, I can retrieve atlas this way:

Great! I like it!
We could nail it saving the factory on MySettings file, like this:

So I can now do :

or:

Where is it retrieving the data from? I don’t know. Who cares about that?


4. Nekomata

4.1. General purpose

There’s only one more thing we must do: create an actor and add it to the stage. To do this I will base on an interesting approach that was built by my battle buddy, vocational psychologist and boyfriend, Hanto. He is an indie game developer and has been working on a self-sufficient class named Pixie, which builds and shows a Sprite.
My Pixie-based class is Nekomata. Both nomenclatures are based on the Sprite name itself. As you can see on the wiki,

The term was derived from the fact that sprites, rather than being part of the bitmap data in the framebuffer, instead “floated” around on top without affecting the data in the framebuffer below, much like a ghost or “sprite”

One day, while I was researching on Japanese folklore, I found a mythological creature named Nekomata, which is a cat shaped ghost. Bingo.

nekomata

Let’s take a look at the code.

4.2. Analyzing the code

This class extends Actor.

The class is heavily commented, please read it and feel free to post any doubt about its behavior.

Conclusion

Gratz! You reached the end of this post. I hope it wasn’t much pedantic. This first step (and the related post) took me four days, and it was really exciting to see the walking kitten animation running. On the next step I will try to move the kitten across the screen.

Please let me know your opinion!

#FightingKittenBlog

Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail

2 thoughts on “Act I

Add yours

  1. public void HurtTheKitten(float damage)
    {
    Stats.Health = Stats.Health – damage;
    }

    public void HealTheKitten(float heal)
    {
    Stats.Health = Stats.Health + heal;
    }

    Use camel case for your method names i.e. hurtTheKitten

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑