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.
- The player will talk to the NPC to get the quest.
- The player will search for the item or fight a monster
- The player will return to the NPC to get his reward.
Then I broke down each of these even further.
- The player talks to the NPC to get the quest
- The player moves to the “action point”
- The player talks with the NPC
- The player moves off the screen
- The player searches for the item or fights a monster
- The player moves to the “action point”
- The player performs the action (searching or fighting)
- The player moves off the screen
- The player returns to the NPC for his reward
- The player moves to the “action point”
- The player talks with the NPC
- 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.
