Abber Keep

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, a flexible API to simplify the rendering in a reusable way. I extended 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 is Java only code, the new one is built on top of LibGDX.

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.