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“.

Darwin Gator post-mortem (overdue)

I think making a game is always a great learning experience, yet not writing a post-mortem after a game makes that learning experience less effective.

I’ve made Darwin Gator a few months ago, but I’ll try to remember its development process. So without further ado let us talk about:

Darwin Gator

Originally, the game was made for a GameJam which asked to combine a lot of random themes, along with a gamejam about monsters, a gamejam about destruction… well yeah. This game was a mess in terms of ideas, because it was entered in many many gamejams. But after leaving it for a while, I decided to work more on it. For some reason, I was motivated to take this game to the next level in terms of quality, so this game actually ended up very different from the original gamejam entries.

  • The graphics

It’s mostly my friend Sophie who encouraged me to improve the graphics of this game by an order of magnitude. I think everything grew from there, because at that time there was only one stage, with bricks. As I drew the extra layer of plants on top of the bricks, the game looked not just more beautiful, but it also started to have some artistic style. To further the graphics, I made a total of three stages. One is the first stage in the forest, second stage is the ice world, and the third stage is the underwater world. Each having its own art style and music.

  • The penguin missions

One of the biggest addition of Darwin Gator is the mini-games. I decided that every 5 or 6 levels there will be an unlocked game, in which the gameplay has nothing to do with the main levels’ gameplay. The first mini-games is a bit like Flappy Bird, the second one is a guessing game, the third one a snowboarding game (which was also released as a standalone game called King of the Slope), and the last one is the secret insanely difficult boss. To unlock the mini-games, you had to visit a penguin at each level. The penguin itself was just a way to unlock the mini-game, but he also has a different dialog every time you meet him. Eventually, I found that the dialog of the penguin made for a more compelling story than the story of the game itself! The story of the game is completely forgettable: Collect all the worms to save the world yadiyada… But the story with the penguin actually became very interesting: First the penguin loses his job, then his girlfriend has a baby, and the first mini-game is to rescue that baby, then he tries to sell icecream… It’s too bad that the penguin missions are not easily accessible, because I think some people will miss that part, which I find to be the most interesting. But hey, that’s how I decided to design the game.

  • The problems

One of the biggest challenge of the game is the control. I insisted that the game has to be playable by pressing just one button, but it turns out to be more problematic than I expected. A character controllable with one button, is really not that pleasant to control. One problem is that I kept testing the game over and over, and thus learned controlling Darwin Gator with great precision by doing lots of practice. When I released the game, I really thought the character’s control was easy, but it seems quite a few people had issues with the controls. When I asked my friend to test it, it turns out the controls were so hard to use, that even the second or third level was too difficult to pass.

  • Overall

The game wasn’t as popular as I hoped it could be but it was satisfying as a game. While it’s hard to control, I found it fun to play it myself. I guess I wished it could do better because of how much time I’ve spent working on it. Yet it game me somehow a new perspective on my game development journey. I now feel that there is some level of quality that I should try to reach when making games. I was always used to pump out quick games for participating into gamejams, but now I’m trying to always have a main game on which I spend a lot of time and effort, one that I can really polish and make it look good.

You can play Darwin Gartor here.