Abber Keep

In my third video, Rendering animated images in LibGdx, I show how LibGdx has a TextureRegion for splitting the cells of an animation sequence. I demonstrate the Animation class and how setting the PlayMode, you can achieve different looping techniques. There are LOOP, LOOP_PINGPONG, LOOP_RANDOM, LOOP_REVERSED, NORMAL and REVERSED. It is nice to have that in a single class. One feature that I didn’t see, was having it loop a set number of times. I show how to implement that manually, by using the getKeyFrame() and passing in a boolean for continuous looping. You have to manually keep track of the number of loops.

I then move on to the additional parameters to the getKeyFrame() method for resizing, by passing in additional values for the size in pixels you want the image to appear at. Then, I show the rotation, including setting the origin, and show you how the rotation degree affects the resulting image. I then show how the rotation with the counter-clockwise boolean, and how the size (height and width) are flipped in this implementation. I find it odd that with the counter-clockwise rotation, they change the height and width direction from the source image. Not what I would expect from just setting the direction to counter-clockwise.

I finish off this video with a character walking around the screen and what is involved in coding that.

In the fourth video, Creating an Animation Framework for LibGdx, I build a framework around the Animation of images, to simplify the entire process. This is based on the Animation framework I used in my Old Style Game Framework. I start with rending a single image in the StaticAnimation class. I move the values from the method parameters into class attributes, thus removing complexity in just drawing an image on the screen. This also give flexibility to easily change the size and orientation of a single image.

Finally, in my fifth video, Updating the Animation Framework for LibGdx, I build out a BaseAnimation class for storing common attributes and extend it with three classes: LoopAnimation, BounceAnimation, and RandomAnimation. The LoopAnimation handles going through the sequence any number of times, one to many times. Also, handling the “ping-pong” animation, bouncing forward and backward. Again, the changing of the size and rotation are the same methods as in the StaticAnimation. This gives us a familiar framework between different types of animating. Having common ways of changing an animation’s size and rotation makes working with the classes easier. It also removes the multi-parameter method out of sight. As an additional feature, I have the animation loop, or bounce, a set number of times as well.

I will enhance the framework in the sixth video, which will simplify the animation of a character walking.

Imaging effects in my original Old Style Game Framework was more “involved” to get it to work. I had to make it as an added feature of the Animation class, by creating the ImageFx class. Effects that dealt with color changes; brightening, darkening, changing color, etc, involved more complicated procedures and using a BufferedImageOp object to do the operation. Rotating the image involved using the AffinsTransform class. One thing about this class is that you had to be careful where the “center” of the rotation is; if you move the object and then try to rotate it, you get a different effect than rotating it and then moving.

LibGDX, with the underlying LWJGL framework underneath it, makes much of this trivial. The SpriteBatch’s draw method has arguments for rotating, shrinking and enlarging, cropping and even flipping the image horizontally and/or vertically.

public void draw(TextureRegion region, float x, float y, float originX, float originY, float width, float height, float scaleX, float scaleY, float rotation)

public void draw(Texture texture, float x, float y, float originX, float originY, float width, float height, float scaleX, float scaleY, float rotation, int srcX, int srcY, int srcWidth, int srcHeight, boolean flipX, boolean flipY)

The use of the booleans to flip the image can also be achieved by using the method that takes U and V values and reversing them. I demonstrated this in my second video on still image rendering. Coloring and translucency effects are done by setting the color on the SpriteBatch.

SpriteBatch.setColor(new Color(red, green, blue, translucency or alpha));

In my framework, I integrated this within the BaseAnimation class. Using a framework, takes away all the hard work in making a game.

Animation is key to any 2D Game, but one aspect I didn’t want to overlook was how to make switching between different animations by the direction in which a sprite is moving. To me, this logic is repeated again and again in a 2D Game. You move your character across the screen, then back again. If your character walks (or runs) from left to right across the screen, then he moves back (from right to left), you either have him run backward or change his direction. The variance is in how many directions the character can go. Does the character only move in one direction? Is he able to only move left and right? Can he jump? Does he move in four directions or eight? No matter which kind of game you make, your sprites will move in some direction, likely multiple directions.

I feel that this is another item to be added to the framework. The hard part was to figure out the names of the classes. My first thought was Movement, which is confusing with the sprite actually moving, so I came up with the class name of Motion. What the Motion class does is encapsulate the transitioning of Animations based on the direction in which the Sprite moves. If you remember in my third video, making the Animations switch between directions can get excessive. When the sprite moves from left to right, it uses the Animation for that direction, and when it moves from right to left it uses the Animation for that direction. Since the Motion classes internally use Animation objects, the developer is free to put in any type of Animation class they want, including using the same Animation.

Now, you can have a sprite that has a looping Animation when moving from down to up and a static (non-changing) Animation when moving from up to down. If you decide to change how the sprite will be animated, you just have to change the Animation used in the Motion class. This makes changes easier and gives the flexibility to experiment with different animation sequences.

A Note about the Animation and Motion classes is that they don’t deal with placing the image on the screen. The location where these images are placed must be passed into the draw method. The Motion forwards that location to the Animation class. The Motion class has an additional method for setting the direction, which it will use to determine which Animation class to use for rendering.

In June 2023, I started recording videos on how I built a 2D Gaming Framework on top of LibGDX. During that summer, I was able to publish a video every week. Then every two weeks, as work started to pick up. Then as I had time, when my Masters classes started up again.

In the videos, I built up the framework in what I perceived as a logical order, starting with a basic element of a video game, an image. I went through the documentation about rendering an image on a 2D orthographic view. I built out the BaseGame and BaseScreen class to remove all the setup required for making a 2D game. This allowed one to start making a game faster and not re-code the boilerplate code. I demonstrated how to render a static image and animated images to the screen.

It was here that I developed the Animation class (see this video on Animation), a flexible API to simplify the rendering in a reusable way by using the Strategy pattern. A pattern I will use again and again in the framework. I extended this with animated images, showing that now an Animation object can be reused wherever it’s needed. The Animation class can easily be swapped for another Animation class, reducing the rework of one’s code. As noted this is based on my previous Gaming Framework that I had created some time ago. While the previous framework is Java-only code, the new one is built on top of LibGDX, using the capabilities of that framework.

I’ve been working on a progress game, called Quest: Plain and Simple. If you don’t know, progress games, play themselves. It’s meant as a “mock”, a criticism of games that end up requiring little interaction to play. You may click something and a whole bunch of things happen and then you win. There are a few of these progress games already available, so what I’m doing different is to have a graphical element to it.

In my game, there is a character that will run across the screen, talk to an NPC and “accept” the quest. In this part, I will have text about the quest for the players to read. An interaction between the player and an NPC. Then the character will walk off the screen and there will be a new scene. Here the character will run on the screen, either he will will be searching for something or fighting a monster. After this scene the character will walk off, and a new scene appear with the original NPC. They will have a short conversation and the player will get his reward.

My first run at this was to off load all the individual steps into a “manager” class. This in itself is not a bad idea, as it separates the switching function from the rest of the game. I had “phases” for each step of the entire flow, like the image just above. But as I worked with it, what I found was this was becoming burdensome. The manager had to keep track of each individual step of the process.

The first time you play the game, or load a game, the scene will display a “curtain” with the name of the zone your character is in. It would go to the next phase and move the player to the action point and get the first quest. Then to the “talking” phase, it would go through the dialog and display talking bubbles when each character is speaking. I did move the conversation control into a separate manager, that will display the speech in the dialog section and make the bubble appear above the correct character and output the text for the players to read.

It was when I was working on the finding the item sequence that I realized the manager was becoming complicated. All these little phases were directed by the manager on each action and what action to do next, move to the action point, talk, move off the screen. The logic method for this was getting complex. For example: walking to the action point, I then had to determine what is the player doing at the action point, or they searching for something or fighting. For searching, the player would walk up to the “action point,” and an icon indicating the player was search will appear. Then I had to make the found items appear. Each part of that became another phase the manager had to keep track of.

The code to determine which phase it was going to was turning into a complex if else chain of code. I realized I needed to take a step back and re-think this process.

I started by breaking down the elements of a quest.

1. The player will talk to the NPC to get the quest.
2. The player will search for the item or fight a monster
3. The player will return to the NPC to get his reward.

    Then I broke down each of these even further.

1. The player talks to the NPC to get the quest
   1. The player moves to the “action point”
   2. The player talks with the NPC
   3. The player moves off the screen
2. The player searches for the item or fights a monster
   1. The player moves to the “action point”
   2. The player performs the action (searching or fighting)
   3. The player moves off the screen
3. The player returns to the NPC for his reward
   1. The player moves to the “action point” 
   2. The player talks with the NPC
   3. The player moves off the screen

There is a pattern of moving to the action point, performing an action and moving off the screen, that is repeated again an again. Additionally, at the beginning of each sequence the scene is rebuilt, the background changes, the stage is set, characters or props added. I create a “phase” class to manage this sequence, breaking the code into smaller pieces for easier managing. Each phase class would manage its own sequence. The constructors would have a List of all its steps it would go through, as I listed out above.

The base class has the code for rebuilding the scene, starting the player to move to the action point, perform the action and moving off the screen. Three steps. In the update method it checks to see if a step of the sequence is done. Once a phase is done it moves to the next phase in the list. For Example: the first phase would be talk to the NPC, the second phase is fight a monster, and a third phase is return to the NPC and get your reward. Once the whole sequence of phases is done, then it will return the results back to the original manager that it is done. The manager will then build the next quest.

As I worked with this I realized that I could then have the quest be more dynamic, by chaining different phases together. First, I could have the NPC tell the player to talk to another NPC, find an item, talk to another NPC, fight a monster and then return to the original NPC for the reward. To do that originally would have been more cumbersome, since the code was expecting the entire sequence to be a specific order and only three phases.

When you have a game that will go through sequences, think through how you really want it to work. Don’t write over complicated if logic to make it work, when you can chain phases together.

For years I have been working on my own gaming framework, beginning back in 2007. It has been a long road to build it up. The focus of the framework is to abstract out the common classes and prevent duplicating the same code over and over again for use in 2D games. I built out an Animation classes to handle all types of animation sequences. Added a Motion classes for dealing with the motion of the character, changing the animation based on which direction the character was moving. Then a Movement class for coordinating between the input and the direction the character would move.

On June 3rd 2015, I have finished what I considered version 1.0 and started working on version 1.1. In this version I worked on making a dungeon crawler, Dungeon Conquest. I fine tuned the framework, built out a debugging framework to step through animations, and beefed up the components framework.

On February 9th 2020, I started a new project, Quest: Plain and Simple. This is a progress-like game with a graphical output. This is when I started on version 1.2. I ended up only make a few minor changes for this entire version. A easing in/out script action for Movements. Correct the circle movement.