Another LD ended (my third one) and this time I’m proud of this game. A mix of puzzle and quick-action I hope that it will deliver some good moments to the player.
From the beginning I started with a cumulative design in mind, that is, I started with “the player runs in a grid” and started coding that. Then the next idea was making the player explore a maze, so the maze concept was implemented, but then enemies were needed to give more pace to the game. The maze and enemies combined聽 well into this puzzle-like + memory + timing mechanics. So all maps were created to take advantage of this moto: “the real challenge of the game is to understand the level and then go to the next” (note that replayability was never a goal of the game). The last design element was growing difficulty, I wanted a serve-all solution so the multiple exits were implemented (an exit that it’s easy to reach means that the next room is easy (when compared to the other choice)).
But this way of designing the game brings its share of problems. First, there’s no defined “finished” game, so you can always add or at least think of other features you can add. Second, and building in the first problem, you may lose some notion of how much time left there is for polishing the game (the menu teaching on how to play the game was only made two hours before the deadline and so the code for that is one BIG hack).
The big thumbs-up for this method is flexibility, if an idea doesn’t work you can throw it way without worries. In contrast, when you design everything and only after you start coding, if some feature doesn’t work as expected you must certainly will have to change (or, in the worst case, also throw way) some features that depended (or interacted) with the lost one.
Another positive point is that you never over-design a game that needs completion in 48h, although you need to reserve a greater chunk of time to polish the game than you would need with the design-everything-first method to avoid the problems mentioned above.
Technologically, everything went smooth for the most part of the game code. SFML is a really good media library that gives you everything you need but doesn’t get in the way you want to design your code. Many people use SDL when using C/C++ but I really recommend using SFML. I picked it up one day before LD15 and still could make a game without almost no worries (great tutorials for each feature and great organization of the library also makes the API reference easy to read).
The problem arose when porting to Windows. SFML uses OpenGL but support for it (in Windows 7) is still in the early stages , so testing the game when its rendering performance dropped considerably was a pain. I just hope that other Windows users don’t have those problems and can experience the game in its fully performance.
About the graphics, although I’m no artist, I always try to make something good looking. But this time I focused much more on game design, making the maps balanced and polished. So the 30 minute art that I did in the first day stucked until the end, but still I think it isn’t that bad though I could have made simple animations if I just had put another hour to it.
In the retrospective, I think that, of the 3 LDs I’ve taken part, this is my best entry so far. The biggest problem was really porting to Windows, so lesson learned, next time code in Windows and Linux comes as a bonus port 馃槈
