3 Days to Game. After coming from varying distances (one coming all the way from Warsaw), we all gathered at my place on Friday evening and waited for the theme to be announced at midnight. We were going to enter the Jam competition: we would have exactly 72 hours to make a game from scratch, or close. The team was composed of Caroline (2D artist), Manon (3D artist), Staś and myself (developers).

Staś and I agreed beforehand that we would use the Godot game engine, even though none of us had ever done anything with it. It was a risky move, but we would benefit from better integration tools for our artists (which we would have had to create had we gone with JavaScript and Phaser3), and it allowed us to do a 3D game (Phaser3 only supports 2D).

After breaking the ice around a home-made diner, and setting up our working environment in my office, midnight rang and the theme was announced: start with nothing. Our first reaction was, "what a crappy theme" (as was the reaction of many folks on twitter, which was quite fun to read). In almost every RPG you start with nothing. In Minecraft or Don't starve, you start with nothing. In 4X games like Civilization, you start with, well, pretty much nothing. But after ranting for a bit, ideas started flowing in. Here are a few that we had but did not pursue:

• a platformer where you control the movements on the player but composing, in advance, a sort of poem. Sentences would correspond to actions of the avatar, and you'd have to line them up in the correct order to move through the level;
• a dating sim where your goal is to have a character named Start to go out with another character named Nothing;
• a game where you'd have to get rid of everything you have in order to be able to start the real game (for example, you'd need to free the RAM of a computer before another program can run);
• a top-down puzzle game where your avatar has a big bubble of "nothingness" around them, and you need to move carefully around the level to reach the end (we didn't go too far in exploring this idea but it might have potential);
• and a bunch of other nonsensical ideas…

We all slept on those ideas, and came back in the morning to decide which one we would tackle. After a bit of talking and thinking about some of the ideas we had expressed, we made our choice. Here's a summary of the pitch as it was at that time:

An infinite runner where the avatar runs into elements that kill them, like fire or lava, and you the player must disable some physical characteristics of the world in order to let the avatar pass through. You can only disable a few things at a time, so you'll have to juggle between them to reach the end of each level.

I really liked this idea as I thought it was small enough for a Game Jam, it fit the theme quite well (every action you take starts with nothing, like "nothing burns" or "nothing flies") and it was original (as far as us four knew). We quickly drafted a list of elements that the avatar would encounter (fire, water, spikes, plants) and their associated physical effects (respectively, "burns", "drowns", "pierces", "holds"). Then Caroline and Manon worked on the ambiance of the game, and decided to give it a Halloween vibe, as we're getting close to the event. And we all went to produce a game…

Good Game, Bad Game. After about a day and a half of working, we had a prototype that was good enough to test our gameplay. And that is when I started to feel a bit down. We had decided, upon my insisting, to go for a drag & drop user interface: the user has to drag a "word" into a space below it, to disable the associated physical effect. The reason I wanted to do that was that the game needed to put a restriction on the number of effects you could disable at the same time. Otherwise, you'd just disable everything and run through the level without having to do anything, which wouldn't have been fun.

It turns out using the drag & drop interface wasn't much fun either, and neither was the game overall. There wasn't much challenge, and I think no amount of level design would have solved that. Staś had told me a few times that he didn't like the drag & drop, and had tried to work on different UIs without success. He wanted the player to use the keyboard to control the elements, and to disable an element as long as the corresponding key was being pressed. It fell into the previously mentioned problem of a player just pressing all the keys and rolling through the level. We were stuck.

That is when we took a good break, and Staś asked the right question: what can we do to make the player want to release the controls? We had a few possible answers, like getting more points the less you pressed keys, but one really took to me: we could add enemies, who would walk towards the avatar, would kill her if they hit her, and would die if they walked into an enabled element. That was it! That single proposal solved all the problems we had: now we could have a much simpler UI (using keys to disable elements) and we would add a great source of stress for the player, as they would have to pay attention to the upcoming elements but also to the upcoming enemies, and juggle with a lot more information. I was convinced the game would be a lot more fun with this.

I went back to working on the game feeling a lot more optimistic! We reworked the UI into something that works with a keyboard, and we implemented two enemies. Sadly our 2D artist had left us at that point, for she was to be back home and to work, so we had to take sprites from the Web. Luckily, opengameart.org is a fantastic resource for this. I quickly found a vampire and a skeleton spritesheet, both not too far from the cartoonesque Halloween theme we had. The first few gameplay tests we did sold it for me: now our game was fun, and all we had to do was finish it in time!

There's Something About this Game. And that we did. On Monday, only Staś and I remained, as both our artists had to get back to their jobs, and we worked on fixing a bunch of bugs, implementing audio (all of the sounds and musics coming from the Web, thanks again opengameart.org), adding a few missing features, and creating levels.

We wanted our level design to be as smooth as possible to the player, and we wanted to have to give only very few explanations. The game had to be as intuitive as we could make it. We thus made the controls on the screen look like keyboard keys, to hint that the game was played with a keyboard. We had a very first level that was entirely empty (heh, that even kinda works with the theme, right?) just to demonstrate that you don't have to do anything to control the avatar, that levels have an end, and that the end sometimes gives you a reward (a new "Word", to disable a physical property). Each new element we introduced had a dedicated, single-element level, so the player could understand what it did and how to go through that element. And then we had fun, making levels that increased in complexity. We ended up making 15 levels (not counting the first empty one), which is about twice as much as what we had anticipated, but the game only takes around 5 minutes to complete.

We also came up with a story, though sadly it isn't very well integrated into the game. I don't want to kill the surprise, so I'll just give you a high-level description: you are an Entity that has an interest in the avatar getting to the end of her journey. Progressing in the game gives you, the Entity, new Words of power, giving you more control over the world. But what you are actually looking for is… The Last Word.

I hope I did a good job of teasing you, and that you want to try the game for yourself now. If that is the case, here is the game:

Play The Last Word - Read our Ludum Dare entry

The game is available for Windows, Linux or Mac, and we also have a Web version playable directly in your browser (though I recommend downloading it if you can, as the Web version has a few issues with sound).

Word Runner. I am very happy about the game we made. I think it looks great, and it is actually fun to play. I thought it would be a sort of puzzle game, but it's not. It's not a runner either, even though it looked like one. My friend Osmose, I think, summarized what it is best:

I had the pleasure to watch some people discover the game and it was quite gratifying. We didn't hear about any bugs, and even though we could of course improve a bunch of things — we did release a version 1.1 with a better layout for the controls — the quality is very good for a Jam game.

I do want to improve a few things though. I wished we could have only art made by ourselves, but that depends on our artists and sadly they have jobs and not much free time. I'll need to learn a bit more about sound in Godot, and rework the volumes of each sound, as people did report that it was not well balanced. There's a "power" we implemented but did not have time to add to our level design: flying enemies, and the "Nothing flies" Word, that you would have to enable precisely when the enemy is flying over an element. And I do want to add more levels, for I deem the challenge too easy for now. I don't think the game should be more than 10 to 15 minutes long, but I'm sure there's room for a few more levels, and some tricky ones at that. I did make a level that was impossible for me to beat, but I'm sure is technically feasible, and I'd like to put that in the game for the hard-core gamers out there. Maybe as a secret level for folks who finish the game?

Waiting for Godot to improve. Regarding Godot, I have mixed feelings. The engine allowed us to make a game in 72 hours, and a 3D game at that. It seems Manon, our 3D artist, really liked it and the tools it gave her. She was able to import her models in the engine directly, and push to our git repo, so that we developers then just had to import her scenes into our levels. That sure felt a lot better than all those Jams where I had to do the integration myself for each and every graphical component of the game. Godot provides a lot of utilities that are great, and its interface is quite easy to use once you've got the hang of it.

However, I am not convinced about some of their architectural decisions and patterns. Signals, for example, look like an anti-pattern to me: you have to couple components very tightly for them to communicate. Maybe I did not understand how to properly use them, but that triggers warning in me that a Godot project might be hard to maintain.

GDScript, Godot's dedicated language, supports typing variables, but it seems that it isn't very strict about enforcing types. We were led to believe at some point that we couldn't do something with a variable we had, because of the type we had defined, only to figure out after trying that Godot didn't care and let us do whatever we wanted, even if that would definitely not have been possible with the type we assigned.

After talking with Staś near the end of the weekend, we came to the conclusion that Godot was just a tool and there were ways we could have used it that would have made the code base saner and more maintainable. Our lack of experience with the engine clearly showed there, and only by using it more will we be able to say for sure if it's a good fit for long-term, maintainable projects. One thing is for sure though: we did make a game with it!

On the other hand, we came across a few issues unrelated to Godot's API that were more problematic. The integration with a VCS like git isn't great. After pulling changes from someone else's, I often had to close the project, clear my repo, then reload the project. Otherwise, changes in scene files or in the project config file would not be taken into account by Godot, and it would actually just erase them on my next save.

The documentation is clearly lacking on some aspects, notably sound. It took me way too long to figure out how to simply play a music. I had to run a bunch of searches, and go to old Godot forum posts from outdated versions of the engine to wrap my head around it. I thought it was crazy that there was not a simple entry about playing sound in the Godot tutorial (which is, otherwise, pretty good).

There are also some tools that are OK when you use them in the graphical interface, but become impossible to use with code. I experienced this with the AnimationPlayer: creating and playing an animation using the graphical interface is not too hard (though not easy either), but doing the same from code turned out to be so hard for me that I had to abandon a feature because it was taking too much time to wrap my head around the scarce documentation.

One final thing that I regret is that the integrated editor is not great compared to ones like Atom (which I ended using for coding) or SublimeText. The autocompletion is nice, but I found a plugin for Atom that provided almost the same features, so I just switched at some point.

The Last (Few) Word(s). I would like to give a big thank you to Caroline, Manon and Staś for doing this Jam with me: it was real pleasure to work with you three, and I'm really happy about the game we made together.

Game Jams are still a great way to spend a weekend, even though it's freaking tiring. The excitement of showing a game you just made to your friends far overweights the exhaustion. It's always an opportunity to learn something new, and it was great for me to see how much I progressed in the game design field, after reading some books and spending quite some time designing games (but almost never building them) in the last few years.

I hope you enjoyed playing The Last Word, and I'm looking forward to my next Jam — likely, the 15th Jam by the Game Dev Party association (which I'm part of), happening in Lyon on the weekend of November 8.