Blog Archives

“Dave’s Dream” post-mortem

Dave’s Dream was produced for the #MeatlyJam, in which we could use some assets provided by TheMeatly, a website on comics about game developers. The theme of the game was:

All things TheMeatly:
Life as a Game Developer

I have to admit, I had some idea in my head before the theme came out. I really wanted to incorporate this idea of time travel, where a character could travel back in time and interact with itself. It’s an idea I had for a while, and every time there was a gamejam with a theme about time travel, I would get motivated, then lack time to work on a game, then miss it.

This time, the theme made the concept turn into an interesting idea: Dave, a game developer, has been caught working on a game at work. He is now in a dream in which he keeps repeating the same day by killing himself.

I knew the concept would be very difficult to implement, and it is quite novel. Yet, I had no problem to ruin this MeatlyJam entry if I was not successful, or make it the way I imagined. Quite frankly, gamejams are for taking risks and experimenting with game development, because you really don’t have much to lose.

Now let’s talk about all the nightmares I had to go through producing this damn game!

  • The game mechanics

So one of the key feature of the game is the fact that you will play for a while, then kill yourself, then replay from the beginning alongside a previous version of yourself.

Basically, I had to make each character repeat the movement of a previous playthrough. This was done by storing a series of actions for each character, each with a timestamp. Actions were basically clicking on an object, or using an item on an object. There isn’t much more you can do in the game, as it is a point-and-click adventure. But here starts the nightmare…

What happens when two characters interact with the same thing?

One of the problem of the game’s design, is that it was designed to allow only one character to interact with one thing at a time. When a character pulled a lever, which takes 1 second, the sprite of the character was basically hidden, and the “pull lever” animation was played on the lever, the the character sprite was shown again once the animation is done. Of course, that means you can’t have two characters pull the lever at the same time because you don’t have many instances of the lever to play the “pull lever” animation twice. At some point, I thought perhaps I could make copies of the lever when this happens, but then reality hits: Even logically, you can’t have two people pull the lever at the same time, because… well what happens to the door? Does it open? Does it close?…

So because of the simple fact that everything had to go through some animation, I was forced to have every item being touched by one character at a time. I could have fixed it by removing the animation for pulling the lever, but I already did too much work animating the character, and animation looked too important for the game to be removed at that point. Almost every single object in the game had an animation, even jumping on a platform was an animation!

This became the source of a nasty bug: When one person interacts with an object and another person interrupts, I have no choice but to either:

  • Cancel the current animation and let the next person interact with the object
  • Let the current animation finish and the interrupting person’s action is cancelled. (I guess I could make the next person wait, but not only it’s a pain to implement but it also mess up with the synchronization of the game).

To keep the game playable, I had to ensure that the previous versions of yourself could never miss the actions that they did before. So if the current self was doing an action and was interrupted by a previous self, I would cancel the action. If the current self was interrupting an action of the previous self, I had to prevent the current self to interrupt.

What a mess! It’s even difficult to explain about this! I’m sure what I’m writing is completely unreadable! Let’s just move on.

  • The animation

What really shine in this game in my opinion was the animation. The system I found of hiding the player’s sprite and just dumping the animation on the interacted object itself allowed me to make very precise animation. I was using the character from TheMeatly, which is actually not so hard to redraw roughly, so I was able to make several animations from it.

I did get lazy towards the end so there was less and less animation, but the beginning had a lot of work!

  • The scripting

There was one important aspect of the coding that I found particularly interesting for “Dave’s Dream” and its sequel, which is the scripting system. Actually, the scripting of Dave’s Dream was a result of laziness. In previous games, I would write scripts related to the game (such as pull this lever => open door / use item => do action) inside each class. I’m not sure what my fellow engineer would think about this successful application of Object Oriented programming, but I really got sick of jumping from files to files to search for my code. I just wanted everything in one place, so most of my scripting got moved into one single file. The way it was done, is to have one giant object in the main file contain all the functions, indexed with the names of all the objects in the game world.

So instead of:

class Door {
// code to open the door
}

class Lever {
// code to open the door
}

We had something like this in the main file:

var giantScript = {
“door”: {
“action”: // code to open the door
},
“lever”: {
“action”: // code for pulling the lever
}
}

Of course, this looked like a very bad coding style, and quite frankly I wasn’t used to work like this before, but for this game, it put all my spaghetti code into one single place and saved me a lot of time from not having to jump from files to file. I was able to just scroll up and down to work on my script related code (note that the engine code was still separated into different classes).

Especially for games and gamejams, once in a while… actually, quite often… no let me rephrase it… ALL THE TIME, you will have to put your elegant object oriented coding style aside and come up with some good hack, especially if elegant coding style gets in a way of productivity. Keep in mind that your gamejams code is quite possibly throwaway, nobody is going to be looking at that code.

Now in this case, while exploring very bad coding practice for the purpose of efficiency, I actually discovered a way for coding adventure game that’s actually quite good. One of the advantage of that coding method is that I truly separated script and engine, and I had the script code all in one place, without having to jump from files to files (unlike I did in previous work like Dobuki’s Epic Journey). Perhaps this is really the way adventure games were meant to be coded.

This coding method really shines for Dave’s Dream’s sequel: (Oozie plays with himself), because I had one script per scene. In terms of organization of the code, I have to say I’ve never reached this kind of elegance when coding an adventure game. I think there’s probably even a better way to organize the code, by splitting the script into quests rather than scenes. This is something I will try to investigate in future projects.

  • The Verdict

The concept itself turned quite successful. It was one of Jupiter Hadley’s favorite of the MeatlyJam.

The learning experience is invaluable. I am just really happy about the new way of scripting adventure games that I discovered. Until then, scripting actions, stories, cut-scenes, dialogs… all of that seemed like a nightmare. Now I feel that I can script all my adventure games in a similar way.

However, one of the things that was a big turn off for people was the fact that the main character kept killing himself. It was a risk I took, because I really couldn’t imagine a better way to do this. At the end, I think the imagery was very effective, but I did decide to remove the suicide part from the sequel.

I was also glad that I finally got to try out that time travel concept I had in mind, especially since so many concepts end up in the forgotten realms sooner or later. This gave me the confidence that some of my crazy ideas can sometimes make it into reality if I try hard. I didn’t expect to encounter so many bugs in the beginning, and having to tweak the game so much even as the game was already released. I did get a lot of complains about bugs, yet the game was playable enough for the majority of people. I think one of the things I enjoyed the most is watching how people react in the gameplay videos.

Gameplay Videos:

Let's Play MeatlyJam! Part 1 Outsidemapen plays Dave's Dream Jupi Plays MeatlyJam

For me, this game was a personal success that I decided to make a sequel: “Oozie plays with himself“.

Advertisements