Final Touches

As is quite often the case with my games, the last part of the game that is created is the title screen. The first part of the title screen is the game's logo. My One of the Weeks logo is not really appropriate, even though this game is part of that series, so to make this a stand-alone game I created a new logo. For the start button, I opted for a door as that is emblematic of the game play. As always, the code to control the button is very straight forward.

spelchan.Nightmare.prototype.startTitle = function() {
this.playButtonHandler = this.playButtonClicked.bind(this);
this.stage.playBtn.addEventListener("click", this.playButtonHandler);
this.stage.stop();
}

spelchan.Nightmare.prototype.playButtonClicked = function(e) {
console.log("Play Button Clicked!");
this.stage.playBtn.removeEventListener("click", this.playButtonHandler);
this.stage.gotoAndPlay("Intro");
}

One problem that I had with the game at this point was the fact that someone who started playing the game without reading the instructions would be totally confused by what was going on. While confusion may actually add to the story, it can also turn a lot of people off the game. As this is the first episode of a series, one thing I don't want is to turn people off the game.

While I would like to think that people read the instruction pages that I put a some effort into creating, the reality is that a lot people just start playing the game.

One solution would be to have a link to the instructions on the game's title screen. The problem with doing this is that the people who skip over the instructions page are likely to not bother clicking on the instructions button either. This means that I would end up putting more time into creating the instruction pages - which is more time consuming then writing an instruction page - which few people are going to read. This is obviously not a good solution.

The solution I did for this episode is to incorporate the background portion of the instructions into the game by starting the player at an explanation screen. This is simply a looped animation of the text bubble growing then shrinking. The code for handling the button is also very simple.

spelchan.Nightmare.prototype.setIntroButton = function(e) {
this.introButtonHandler = this.introButtonClicked.bind(this);
this.stage.con_btn.addEventListener("click", this.introButtonHandler);
}

spelchan.Nightmare.prototype.introButtonClicked = function(e) {
console.log("Intro Button Clicked!");
this.stage.con_btn.removeEventListener("click", this.introButtonHandler);
this.stage.gotoAndPlay("enterRed");
}

And that is all there is to the game. Next fortnight we will look at changes to my Blazing Games porting plans and next month we will start chapter 7 which sets the foundation for the creation of video poker.

Losing and Winning

In the previous section we introduced the BSoD. This leads to the problem of what to do when the player loses the game. My first thought was to have the BSoD claw the player to death. This would reflect the feeling you get when you have an hours worth of unsaved work and the real blue screen of death shows up. Not that I’ve ever had that happen to me as I always save my work frequently. Mind you, the reason I always save my work frequently is because of learning what losing hours of work because of a computer crashing feels like.

Having someone being clawed to death is not really appropriate for a family friendly game so instead, I decided to have a bit of fun and generate a nice error message.

There is a button on the screen which returns the user to the title screen that we will be creating in the next section. To have the button do something we have a method in our Nightmare class for dealing with returning to the title screen. This method is called using nightmare.registerTitleButton(this.losecon_btn);

spelchan.Nightmare.prototype.registerTitleButton = function(btn) {
console.log("registering toTitle called! " + btn);
this.toTitleButton = btn;
this.toTitleHandler = this.toTitle.bind(this);
this.toTitleButton.addEventListener("click", this.toTitleHandler);
}

spelchan.Nightmare.prototype.toTitle = function(e) {
console.log("toTitle called!");
this.toTitleButton.removeEventListener("click", this.toTitleHandler);
this.stage.gotoAndPlay("Title");
}

This code simply sets up a button that is passed to it to call an event handler that simply returns the game to the title sequence.  To remove an event listener, however, you need a link to the event that is to be removed. Binding objects end up creating something new so to properly remove the event handler we need to keep a reference to the binded version of the handler. The actual handler code simply uses this binded reference to properly remove the event handling reference and then goes to the title sreen frame.

Now that it is possible to lose the game, perhaps it would be nice to allow the player to win the game. The winning scene was designed with two purposes in mind. First, as a distinct way of showing the player that they have completed the game. Second, to preview the next episode of the game. The number 666 has certain significance with my upbringing and to this day I still consider that number to be a bad omen. As you can't have that number on a clock, at least not legitimately, I opted for 6:36 for the time. The code for handling the “To be Continued...” button, as with the lose screen, is simply a call to nightmare.registerTitleButton(this.wincon\_btn);

Now we just need the title and intro screens and we are finished.These will be completed next fortnight which will conclude this chapter.

Enter the Nasty

To add a bit more pressure on the player, I have a villain that pops up after the player has stayed in the room too long. Being a programmer, the first villain that came to mind is the dreaded Blue Screen of Death that occurs on Windows machines. Linux and Macintosh OS X don't have this problem (and are extremely stable operating systems) but most people have windows, and a lot of my programming happens to be for Windows machines. To be fair to Microsoft, the blue-screen problem has largely gone away.

In addition to the BSoD image, we also need a movie that controls the BSoD. This movie consists of nothing for the first few frames (labeled hide) with a stop on the second frame. There is also be a block labeled show which is a two second sequence of the BSoD appearing. For control purposes we have the button code in the previous section call the hide method which shows nothing. There is a flag that is set indicating that there is no BSoD yet. A timer is set up to 0 and when this timer reaches 3 the BSoD will appear. What are we timing? We already have a loop for growing and shrinking the room so we will use the end of that loop as the timer. So instead of having a gotoAndPlay on the last frame to loop the animation, we instead have nightmare.updateBSOD("blueLoop"); with the string being the name of the label to go to for looping the room animation. The BSOD update code is as follows:

spelchan.Nightmare.prototype.updateBSOD = function(loop) {
// BSOD calculations
if (this.bsodAppearing) {
this.stage.gotoAndPlay("loseGame");
return;
}
++this.bsodTimer;
if (this.bsodTimer >= 3) {
this.bsodAppearing = true;
this.stage.bsod_movie.gotoAndPlay("show");
}
this.stage.gotoAndPlay(loop);
}

The function simply keeps track of how many times it has been called. As the function is called every 2 seconds, we simply figure out how long we give the players before the BSoD appears and then start the appearing animation. If another tick happens after the appearing animation has occurred then we know that the player has bit the bullet. This simply goes to the loseGame frame which we use for losing the game. Which leaves us with the task of handing the winning and losing of the game.

Linking the Rooms

Now comes the task of assembling and linking the rooms. I create a block of frames for each of the six rooms with each room being broken into three animated sequences. First is the Enter sequence (labeled enterColor, with Color being the color of the room). This sequence shows the room zooming into view. Next is the main room loop (labeled colorLoop, with color being the color of the room). I want to have an additional disorienting effect added to the room. Therefore, I set this block of frames to loop. The room will slowly grow and then shrink back to it's starting size. Finally there is an exit sequence (labeled colorExit, with color being the color of the room). This shows the room shrinking into nothing.

As animate likes to tie code to the frame it is written in, we are creating a globally accessible class that we will be using for tracking the state of the game. This class will be added to throughout this chapter but to start with we have the following initialization code.

if (typeof(spelchan) == "undefined") spelchan = {};

spelchan.Nightmare = function() {
this.registerStage = function(stage) { this.stage = stage;}
this.dirButtons = [null,null,null,null];
this.dirClickHandler = this.directionClicked.bind(this);
this.exitTarget = "exitRed";
}

This sets up a spelchan.Nightmare class that holds the list of buttons that are used to control the navigation between rooms. We need buttons for the four directions that the player can go. Quite simply, I will label the directions North, South, East and West. The four buttons will be invisible buttons. These are buttons that have a hit box but no image. Actually, when the player is over the buttons, we will have a "Go Direction" message appear. This is done simply by having the over and down frames of the button have the desired text in them. In the editor the invisible buttons have a cyan color and are placed over the doors in the image. Due to the animation of the room this placement isn't exact.

Every room will have it's own set of four buttons. I use the convention of naming the button instances colorDirection_btn. As the logic for the buttons is similar for all the rooms we can create a general method for setting up the buttons for a room as follows:

spelchan.Nightmare.prototype.setDirectionTargets = function(
btnNorth, targetNorth, btnEast, targetEast,
btnSouth, targetSouth, btnWest, targetWest, exitTarget) {
this.dirButtons[0] = btnNorth;
btnNorth.directionTarget = targetNorth;
this.dirButtons[1] = btnEast;
btnEast.directionTarget = targetEast;
this.dirButtons[2] = btnSouth;
btnSouth.directionTarget = targetSouth;
this.dirButtons[3] = btnWest;
btnWest.directionTarget = targetWest;
this.exitTarget = exitTarget;

for (var cntr = 0; cntr < 4; ++cntr) {
this.dirButtons[cntr].addEventListener(
"click", this.dirClickHandler);
}

this.bsodTimer = 0;
this.bsodAppearing = false;
this.stage.bsod_movie.gotoAndPlay("hide");
}

This code simply sets up the buttons and gives each button a target frame to go to when it is clicked. It also provides the frame to goto to start the exit room animation. The buttons are then assigned an event listener to handle being clicked. We will be covering this handler later in this section. Finally the code sets up the timer for the villain. We will cover the appearance of the villain in the next section. Each of the six rooms needs to call the above method when it is appearing with the code being on the frame where the room starts appearing. This code is something like the following:

nightmare.setDirectionTargets(
this.redNorth_btn, "enterCyan",
this.redEast_btn, "enterGreen",
this.redSouth_btn, "enterCyan",
this.redWest_btn, "enterYellow", "exitRed");

As you can see this is simply a function call to the method we created above. The parameters would be the appropriate buttons for that room and the labels of the frame the program should go to when the button is clicked. The button variables are self-evident while the target frames require looking at the map to determine the appropriate room to go to.

Handling the click is the next thing we need to do. This is done by the event handler we hinted at above.

spelchan.Nightmare.prototype.directionClicked = function(e) {
// make sure button has valid target
if (typeof(e.target.directionTarget) == "undefined") {
console.log("ERROR - Missing target in button");
this.directionTarget = "enterRed";
} else {
console.log("Button target is " + e.target.directionTarget); 
this.directionTarget = e.target.directionTarget;
}

// clean up buttons
for (var cntr = 0; cntr < 4; ++cntr) {
this.dirButtons[cntr].removeEventListener("click", this.dirClickHandler);
}
this.stage.gotoAndPlay(this.exitTarget);
}

This function first sets up a class variable called directionTarget to be the name of the frame to go to once the room has been exited. We can't go to this frame right away because we have to play an exit animation first. To be good citizens, we need to clean up our event handlers so we remove the event listeners. Finally we start the animation for exiting the room.

To finish our navigation system we need to go to the appropriate room when the player is exiting the room. Each of the exit animations will have a call to nightmare.nextRoom() on the last frame. This is a simple method that simply goes to the frame indicated by the button that was clicked on above.

spelchan.Nightmare.prototype.nextRoom = function() {
this.stage.gotoAndPlay(this.directionTarget);
}

This code simply goes to the appropriate frame for the next room. And that is all that is required for a navigation system. Now we need to implement the villain of this game which we will do next fortnight..

Planning the Adventure

The basic theme behind nightmare maze is that you are lost in a maze and must move quickly from room to room before the evil Blue Screen of Death reaches you.  The maze in this game is consistent in the fact that the same door will take you to the same room, however it is not commutative meaning that the door from A to B does not necessarily go back to A. This means while there is a structure to the maze it works different then the real world, which is typical of dreams.

Mazes are fairly easy to implement. This maze, however, is not a linear maze. With a linear maze, you can use graph paper to plan out the maze. This is obviously not the case with a non-linear maze. Instead, a different type of graph is used for creating a non-linear maze. This graph consists of the rooms drawn as boxes with arrowed lines showing how the rooms connect. I used a variation on this having colored lines corresponding to the room the line is from.

As you can see by the above map, the links between rooms are fairly complex. However implementing the links is actually very easy. You can also see that there are a lot of ways of reaching the exit, but do to the fact that there is nothing highlighting the exit, a player could end up being stuck in the maze for quite a while.

The room approach is very common in adventure games as travelling between locations is a very common activity. Generally, when designing an adventure game, each location will be considered to be a room even if it is an outside location. This allows for rooms to be worked on independently of each other and for earlier computers that had a very limited amount of memory would allow for the computer to only have to load the drawing data for the room that the player was currently in then having some type of transition animation between "rooms" when the player left a room and the game had to load in the image for the next room.

From a programming perspective, having rooms that are connected together with lines allows us to represent the map as a mathematical graph in which each room is a vertex of the graph and the connections between rooms are the edges of the graph.  Graph theory, however, is not necessary to build an adventure game. All that really matters is that you are able to create a basic map of the locations within the adventure so that you can move between them. The map can also be used to plan out where objects are located in the world and what obstacles or puzzles there are in the game. This allows for a walk through of the game before you have even started any real work on building the game so that you know that the game is solvable.

Once the map is planned out you then have the ability to itemize all the assets that will be needed for the game and can start work on building the art needed for each of the rooms. Building the rooms is what we will be doing next fortnight, but thanks to the nature of our maze this is a lot easier for this game than it would be for most other adventure games.

CRA Agent Postmortem

David S. Gallant was fired for the dreadful sin of creating a game about his job. Ludum Dare decided to host a game jam related to this. I created my CRA Agent game as part of this CRAJam. Now I am writing my postmortem about the development of this game.

What went right.

I had a very clear vision of the game I wanted to make. Having clear and realistic goals made getting the game done fairly quickly. The fact that the game was fairly simple from a coding perspective was a bonus. While I had hoped to have the adventure game kit portion of my GameJam library ready, it simply was too far from completion to contemplate using it which may have been a blessing as I probably would have spent far more time working on my generic adventure game library than on the game.

One big change from my original plan did occur, which is why it is always good to have some flexibility with your designs. Instead of the single inevitable ending I was planning for, I decided that the underlying score systems could be tweaked to allow for three different endings based on how the player plays. It actually didn't take very long to tweak the numbers and I think the game benefited from this change. It is still a short game that can be finished in a couple of minutes but now it has enough replay-ability that it allows more exploration of the theme.

What went wrong

Politics. I hate politics so having a politically themed game was certainly an issue for me. While I think my political opinions can be discerned from this game, some of the decisions that the player could take clearly went against my beliefs. I think I handled both cases with enough humour that the game should be enjoyable even by people with differing opinions than mine, but the fact that politics happens to be one of those subjects that invoke strong irrational emotions from people I am sure I have pissed some people off.

Too much art.  Instead of creating unique art for the agent, the 8 people being audited, and the boss, I may have been better off creating a face-making program that would generate a huge number of faces based on a small number of art pieces. I could have then spent more time creating text for people being audited which would have added a lot more content to the game.

Conclusion

I think even though this game is likely to piss some people off, it turned out pretty good.

Merry Christmas

Merry Christmas and have a Happy New Year! I am quickly writing this after quickly posting the final episode of One of those Weeks. I am doing this Christmas Morning due to the fact that I have plans this afternoon and evening. I suppose I could wait until tomorrow morning to post this game but figured it would be safer to get it posted early. Enjoy. If you enjoyed One of those Weeks and want to see me create another adventure game (or even a sequel to OotW) then be sure to email me and let me know.

Classic Text Adventure Release Candidate in repository

Well, I managed to finish my horror themed text adventure today and have posted the files to the repository so those of you who can't wait five days and know how to compile java can download and play episode 57 of the Ultimate Retro Project early (in the unlikely event that any exist). The development of this game was quite quick due to the fact that the two main parts of the engine, the room management and the parser, had already been written (at least partially) for other games in the ultimate retro series. Still, when adventures are concerned, the parser is very important. I opted for a simple two word parser which was used by a lot of adventure games.

A two word parser is actually one of the easier things to implement. This is because the format is very straight forward. You have a verb followed by a noun. Both the verbs and the nouns can be grouped into a list and you can then simply look up the command on the list and turn the command into a number representing the action and a number representing the object that the action is being applied to. My parser is slightly more sophisticated then this.

At the heart of my parser is the command class which holds a number that represents the verb and a number that represents the noun. The word, however, is not a single word for each command but a list of words that represent that command. The list of words are stored in a Word class that also holds other info about the word that I do not take full advantage of. A sentence class, which consists of a word class for the verb and a list of words that can be used for the noun (after all, some commands may have different nouns that can be used such as in the case of the move command) forms the basis of the command architecture. Finally, the parser class consists of a list of sentences that the game can understand.

After the parser command has processed the input string, you are left with a command. The ID of the verb is used to determine what to do and the ID of the noun is used to additionally quantify the action being performed.

While I was hoping to have a generic adventure creation engine by the end of this episode, puzzles tend to require a lot of condition processing. I was not about to spend far too much time writing a simple scripting language that could handle the condition processing so the final code is a bit too integrated with the data files than I would like. I think the time for text adventures is over and I have far better projects to work on so a general purpose text adventure game engine will not be coming from me any time soon, though there are already a number of them that already exist.