Sequencing events in Games

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.

Building a game framework. The Old Style Game Framework

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.

Building in Dungeon Conquest

Building in Dungeon Conquest is meant to be easy. On the Overview screen you can layout the general design of your dungeon.

Overview Screen

Right now you have three selections on the left side: the background, the base dungeon tiles and a delete option. Selecting the background you can set the background pattern that will display behind the dungeon.

The base dungeon tile button, allows you to place “tiles” for you dungeon. You can layout the dungeon in any pattern you want. The current maximum dungeon size is fifty by fifty. This may seem small, but each of these tiles is a two by two area for characters, monsters and other decorations, making the map a one hundred by one hundred square size.

On the detail screen you can add specific tiles to give you dungeon its appearance.

Detail screen

As you can see here, this room is six tiles across on the overview screen, but is twelve squares across in the actually dungeon the players will play in.

On the detail screen, the left side menu you can select a tile pattern. Then clicking on the tiles you can set that pattern. You can also select the “mass tile placement” button at the top left to set all tiles on a selected tile pattern.

The Feature menu across the top has the different types of details you can set in your dungeon. These are: Tiles, Creatures, Decorations and Usables. Tiles are the dungeon pattern for the floors, walls and top edges. Creatures include setting the player’s start position and the monsters within the dungeon. Decorations are added features for the dungeon such as columns, torches, etc. Usables, as of now, is a catch all for items that players can interact with. This will be doors and traps. Details are still being worked out on this part.

We will keep you updated on our progress.