One Game a Month

This is my post-mortem of my one game a month (1GAM) challenge during 2014. Twelve games in a year, one every month.

I don’t remember exactly how I decided to do the challenge. If I recall correctly I read Christer Kaitila’s (@McFunkypants) post about his 1GAM and I commented with my wife how crazy was that. Like is not hard enough to make a game, so try that once a month.

Because my free time may be diminished considerably in the near future, my always supporting wife encouraged me to do it, and I agreed (reluctantly!). Making one game every month is serious business, but I thought that could be a good way to improve my game-making skills, or just hate it for ever!

The no-rules rules of the challenge are simple: make one game a month (it has to be finished or at least released in that month), with a 96 hours grace period to do it (giving you 4 extra days each month, or 4 days less for next month game), and non-trivial ports to a different platform are allowed. Chapters and continuations are also welcomed, although now that I think of it I didn’t do it.

Besides I added a personal extra rule about what I consider “a game”: I would try to release games that are playable, excluding demos and technical previews.

I mostly succeeded with that last point, although some 48 hour compo games are really borderline.

Finally I programmed the games, did the graphics, sound effects and (when available) the music. I didn’t use any existing engines because for me writing the engine is part of the fun. My development platform is Linux and I used different libraries and tried to learn new things, so I used different programming languages (Javascript, Python, C++, C and some Z80 assembler) and targeted different platforms (web, Android, Linux, Windows, Mac and the ZX Spectrum).

So let’s go through the 12 games!

January: Flax

Game page: Flax

There’s been a constant in all this year: not knowing what game to make! In some months I wasted half of my time looking for “the idea” or some inspiration to get me started.

I finally decided to go with a genre I already had experience with: a shoot’em up (I made Dodgin’ Diamond 2 over 10 years ago). Not exciting, but I didn’t want to fail the challenge the first month!

I used Javascript and plain canvas 2D for this game. I already had some experience with OOP Javascript and canvas so it wasn’t too hard to get started, just to get really frustrated by the sorry state of hardware acceleration in Linux browsers.

Although it has improved a lot during the year, it makes everything harder when you’re trying something new and you don’t know if you’re doing it wrong or if it is just that you can’t get more from the platform. Besides a new browser release doesn’t necessarily mean things will get better because sometimes there are regressions too.

My struggle in this game were the graphics. I managed to scale the canvas to get a nice retro feel, but drawing is hard and I’m not good at it (I’ve improved during the year though).

At the end I managed to put together 3 stages with some enemy variety, including three end bosses, and I learnt a lot about Javascript and canvas. It has some issues with some supported platforms (like the aforementioned hardware acceleration), but it’s OK to make some types of games.

I also implemented gamepad support for Chrome (that now is deprecated and will stop working soon, that’s cutting edge technologies for you). The music was added after the game was released, using Schism Tracker (clone of the old Scream Tracker for DOS; although I was more Fast Tracker II user back then).

This first game is quite good for 1GAM, but it starts to show how I have a problem scoping projects. “Flax” was quite ambitious for half a month (I wasted the other half, remember?), and it was a lot of work for roughly 6 minutes of game play.

February: Alien Gamma

Game page: Alien Gamma

With this game I repeated the same mistakes in a way that is quite funny: I wasted too much time looking for a “good idea” to implement and ended with too many things to do in not enough time. For second time in a row I needed the 96 hours grace period (spoilers: it won’t be the last time).

This is a “shoot and run” game inspired by classics like Contra, Midnight Resistance, Green Beret, and even some Castlevania. I spent time watching YouTube videos and I tried to implement few mechanics that make this type of game “fun”.

I used Javascript and canvas again, specially because JSON is easy to use and Tiled (a very nice map editor) allows JSON export. I was hoping to do as much as I could in Tiled to make my code simpler, and it turned out to be one of the best ideas I had in the whole year.

The map renderer wasn’t to difficult to write, but getting a platformer right is really difficult and I spent a lot of time trying to make the character behave. To make things worse I wanted the maps to have multiple levels and that required a mechanism to allow the player to change levels. I chose vertical platforms, and they’re really hard to implement.

At the end the platforming wasn’t too choppy, but it wasn’t great either. The maps are nice and add exploration to the game play, not just running and shooting around collecting items.

I couldn’t add too many enemy types, but with 5 levels it was a decent game. I struggled with the graphics, but to be completely honest, I was stuck until I wasn’t. Basically the last weekend before the deadline I draw what was left to have a minimal game, and it turns out it wasn’t that bad.

I got positive comments, but some people didn’t like that the character didn’t crouch, making some of the enemies a little bit annoying to kill. Others didn’t like that the character jumps back when gets hit (in pure Castlevania style). If one wants to play the game, is not that bad; so I think the challenge is OK. Anyway, it was nice to get feedback!

Again, I think this game was pretty good for a 1GAM. At this point I was quite exhausted already, so I had to start doing simpler things if I wanted to finish twelve games!

March: Flax for Android

Game page: Flax for Android

This game was a port of Flax to Android and it was more manageable than the previous projects, but not as easy as I expected.

The game port was pretty straightforward. I had to change the screen resize code to support as much screen factors a possible, making the scaling code adaptable. Besides I had to implement a way to control the game using the touchscreen with a “on-screen” joystick, and adjust the difficulty so it was playable being the controls less accurate than a regular keyboard or a proper gamepad.

That didn’t take me too long, until I tried to wrap everything with Apache Cordova and discovered that the webview component was kind of broken in Kit Kat: the hardware acceleration for canvas was disabled.

So the game played smoother than in my Linux laptop, but just in Chrome; in the webview the performance was roughly 1 frame per second in my Motorola Moto G.

I couldn’t release the game like that, so I did some research and I found the project Crosswalk. It basically ships its own Chromium-based runtime with your web application and you can get most of the Chrome browser functionality with the small inconvenient of the app size and having to ship a native component with your Android app.

It wasn’t easy to compile and package, but I managed to get it working. It’s not a perfect port though, e.g. the on screen joystick doesn’t look perfect in all the devices, but it was close enough.

April: Submarine (treasure hunting)

Game page: Submarine (treasure hunting)

This is my first Ludum Dare game (a 48 hour game programming competition), meaning it is the first time I managed to submit anything (although it was for the jam and not for the compo, so I had more than 48 hours to finish the game).

It is interesting how I reproduced yet again the same pattern: too much time in the “what do I do?” stage to finally “do whatever!” just to find out I run out of time.

I used Javascript and canvas again. I was getting used to the language and its “gotchas” and it is good for prototyping. I wasn’t happy with the performance issues without hardware acceleration, but for a competition like LD it was OK.

The game is quite simple, but I found quite amusing how some people praised the graphics, specially the title screen and the animations, and it got #98 position in “fun” category in the Jam. Just for that, I think the game was a total success.

I could have used more time to improve the game after the competition, but because LD voting lasts several days I though it was OK to leave it like it was.

May: Grid Runners

Game page: Grid Runners

This game was made in a week for PyWeek, a game programming competition to make a game from scratch in a week using Python. It is special for me because it was PyWeek what got me back into making games about two years ago.

The game was written in Python (obviously) using the Pyglet library (I was contributor). It’s not the first time I use Tiled with Python, but this time I had a better idea on how to get the most of the editor whilst keeping my code reasonably simple. Besides it actually helped me a lot that my prior experience was with Javascript, because the “from scratch” rule is quite hard when you have already code that works and you can’t use.

The main point of that rule is to encourage people to release code as open source (something I did with my map rendering code), but it is still tiresome to bootstrap your game again and again.

The game implements an idea that I put together for a previous PyWeek but the final theme wasn’t the one I was expecting so I couldn’t use it. This time the theme was “8-bit”, so I found it possible to adapt the idea to match the theme.

The game uses shaders and OpenGL so the performance is good, but it is really hard to get things “fast enough”. Pyglet is great, but there are so many things you need to know about its internals and OpenGL to get the most of it that it is quite frustrating if you’re a newbie.

I managed to package the game for Linux, Windows and Mac (and I don’t own a Mac), but I got a couple of unexpected problems because things I didn’t know about Pyglet’s internals. At the end I must confess I was a little bit burnt all together.

The end result is really polished for a week of work (part time, I have a job!), and I’m really happy with the atmosphere and how it plays. It may not appeal to everybody and I got third in the overall rank (again!), but it is my best game so far using Python.

June: Zooooop!

Game page: Zooooop!

Not the best name ever (five Os), but it was my excuse to get back in touch with C++ and learn SFML by making a simple match-3 puzzle game (slide to match style).

I used C++ a lot back in university, but that was long ago and the language has changed a lot since then. I ordered “Accelerated C++: Practical Programming by Example” and started to read SFML docs.

Turns out my experience with Pyglet was really useful to understand how SFML works and why things are implemented in a certain way. With some help from “Accelerated C++” I discovered C++ is quite enjoyable, specially because with std::Vector it feels quite natural to use more or less the same tricks I was using with Javascript, but very fast.

Well that sums up pretty much how I felt: I knew I wasn’t doing things in the most optimal way, but it was still blazing fast! Compared with the default “optimized” way of thinking I was forced to use when writing Python (and Javascript), it was refreshing.

The game itself is not amazing, but if you’re into match-3 games it is not too bad. It was the perfect project to try SFML, specially cross-compiling for Windows in Linux and all the details to package and distribute the Linux version.

I found a couple of things in SFML that could be improved and I’m pleased to see that latest release (2.2) has fixed most of them (and I’ve been told that my feedback was taken into account, so I’m extremely happy with it).

July: The Legend of Traxtor

Game page: The Legend of Traxtor

After last game I swiftly started to work in the next game using C++ and SFML, and back to my problem limiting the project size and not keeping things simple enough.

In fact this is the closest I’ve been to fail the challenge, because that game I started is not “The Legend of Traxtor”. That game was never finished.

I realized it was impossible to get something good enough to be my next 1GAM and I had one week left of the month. Then I learnt about GBJam, a game competition to make a Game Boy looking game, and it was starting the weekend of the 96 hours grace time. So I made “The Legend of Traxtor” in a weekend so it could be my July game for 1GAM and also submit it to the jam (although the jam allowed one week!).

It was the first game to be submitted and still got 21st position in the overall rank.

I found that I was OK with the GB limitations (4 colors, 160x144 resolution), perhaps because my limited art skills, and C++ with SFML was a total pleasure to use.

The game is yet another match-3 game, with mechanics reminiscent of Klax with a three level stack to manipulate the blocks. I was surprised that the idea turned out better than I expected, being quite fun to play despite the basic mechanics.

August: DUAL Adventure

Game page: DUAL Adventure

This was another Ludum Dare game, and I managed to submit it to the competition (not the jam). This is probably the weakest game of the year, and I think I wouldn’t have accepted it as a game in January, but 7 months into the challenge I was ready to make some concessions.

I used Javascript and canvas, with a Tiled based engine again trying to get a minimal platformer.

The graphics are nice, and people liked them (specially the title screen and the palette), but the physics and the controls were terribly flawed.

I like the map renderer a lot. It is simple, minimal, and still readable and full of functionality. I guess that’s the bright side of starting from scratch knowing how to do it. I’m surprised how bloated feels “Alien Gamma” map renderer in comparison.

I failed to explain the story I had in mind, and basically I run out of time. I didn’t have all the 48 hours anyway, so I’m happy despite the results. I’m definitely not good doing LD, basically because I need my time to get inspired.

September: The Accolade

Game page: The Accolade

This game is quite special for two reasons: my first computer ever was a ZX Spectrum 128K +2A, and made once an RPG game in gwbasic in my Olivetti PC1. So when I learnt about the SpeccyJam (a game jam about making a “ZX Spectrum looking game”) I was too tempted. My random theme was: dungeon. Seriously.

Obviously I didn’t try to make a full featured RPG in a week (my old game included a 4 members party, inventory, lots of stats, etc), but I thought I could pull out perhaps a rogue-like in isometric perspective using Spectrum graphics. It was quite ambitious anyway (ridiculous in fact), but the jam was extended to 10 days, and thanks to that I could make a couple of playable dungeon levels.

I could have done more, but my engine design wasn’t flexible enough. Couldn’t find a easy way to use Tiled splitting the map in screens in the same style classic isometric Spectrum games did, so I had to encode the levels by hand using a JSON file.

I used C++ and SFML this time, and I spent too much time working on the graphics. Totally worth it, although I couldn’t use all the graphics just because I didn’t have the time to write the code.

The end result is not as good as in “…Traxtor”, that had quite right the Game Boy look and feel, but still looked and played like an Spectrum game. At least until I started making real ZX Spectrum games.

October: The Legend of Traxtor (ZX)

Game page: The Legend of Traxtor (ZX)

I had so much fun programming “The Accolade” that I couldn’t stop asking to myself: but how hard would it be to make and actual ZX Spectrum game?

I did some research and found some tools: Z88DK is a C cross-compiler that can target the Spectrum, and it comes with some interesting libraries for game programming.

Then at some point I decided to port “The Legend of Traxtor”, although “conversion” would be more accurate, as I couldn’t reuse much. My wife looked at me like I was crazy. Well, it is quite different programming for the ZX Spectrum in 2014 than it was in the 80s. I can use C and an emulator, and that’s a great advantage.

My approach was really naive and I did many things wrong, but there are a few tools and documentation to help you making games, so I finished the game in a week. And it was playable, and as fun as the original version.

This was really unexpected. Because I finished it quite early in the month, I had lots of time to learn why my code wasn’t quite right. Of course: my next game would be for the ZX Spectrum.

November: Escape from Colony 8

Game page: Escape from Colony 8

This was a good reality check. “…Traxtor” was very simple, and the playability suffered in some parts. Doing things right is very difficult, and I had to write some Z80 assembler (which is OK, but I rather not).

I like this game, but it was again too much for a month and, what is worse, too much for the ZX Spectrum 48K. Basically because I failed to plan some parts, the sprite library I used requires too much memory and, well… I think I understood the memory map and what was going on a little bit too late.

I had to spend a lot of time reviewing my code, looking for optimizations to get some bytes back to have enough space to finish the game. I used compression, wrote parts in assembler, but it didn’t help to fix a broken design.

So I assumed it was going to be a short game, and finished it anyway. The maps and the sprite animations are nice, I like the music and the sound effects, but it has just one enemy type and it is limited to 16 screens.

Days after the release I got and idea on how I could encode the maps using way less memory, but even the sprite library author recommends targeting the Spectrum 128K for a mid-size game, so I’m happy after all.

December: Micro INC

Game page: Micro INC

I was quite tired after finishing “…Colony 8”, and I don’t usually have time for programming on Christmas, so I decided to do something simple in a couple of weeks and complete the challenge.

This is yet another match-3 puzzle game, playing against the clock, with a nice and colorful screen design. Nothing fancy but effective. Compared with the amount of work I put in “…Colony 8”, this last game got way better feedback, which is… confusing.

I didn’t feel like making a sequel to “…Traxtor”, but I used all the things I learnt with “…Colony 8”: interrupts, memory map, properly counting frames, integrating sound with the action, and the result is quite polished (with less assembler!).

I like the game. I played several times after it was released, and I found amusing trying to beat the high score (that I set initially in 1500 points, not easy!).

Final words

The 1GAM challenge was intense and hard, really hard. I learnt a lot of new things and finished 12 games. That’s part of the challenge: finishing projects. I may have made the same mistakes over and over, but perseverance is the key.