The story of arcticum
A good week-end that was. I am pretty satisfied with what I came up with.
Here comes a (rather long) reflexion about the process of creation.
The theme
Advancing wall of whaa? It is a classic, it was tough finding something original. I tried to mindmap my brainstorming around the theme, but it only confused me more with thhe possibilities. One continuous wall/many separate elements. Rectilign/soft-shaped. You’re the wall/the wall is the enemy. Possible actions again the wall (ie gameplays): run away, slow it down, destroy or damage it, protect yourself, go through it, push it back… After a walk to see the sunrise (woah it’d been ages since I woke up so early that I could see the sunrise…) I had narrowed down to three main ideas. A classic sidescroller where a bunny is chased by a wally cloud of darkness. A space-sim where you control a band of space pirates and have to use linked ships (as a “wall”) to take over other ships and planets. Or (as the sea outside is still frozen) a thing with ice that threatens an island.
I discarded the first one because it implied a lot of content to create, and possibly level design (or randomly generated levels, which might be difficult to make interesting). I discarded the second one (although it would have allowed me to use my cool glowy vector graphics script) because it would have needed too much AI, and I was really not sure of what control scheme to use. And a classic STR “click to select and order” seemed daunting to code. So seals and bears and moving ice. The fact that the wall is not a frontier, but the side of solid matter seemed original enough.
The game mechanics
The base principal was simple: advancing ice, make it melt as it gets closer. Surely I was counting on the “cool, fireballs!” effect, but I’m not sure how fun that is. With the boni it makes it a bit challenging, because the only way to get them is to use the fireballs. If you concentrate too much on getting a bonus, you let the ice get dangerously close, and vice versa: if you just keep melting ice, you never get any bonus.
Here is the important thing: you don’t need the boni, since melting ice is enough to keep you safe. The goal of the game would then be to survive as long as possible.
It took me a while to realise that this was not enough (well my mind was busy with broken geometrics algorithms…) So I needed a winning condition, to do something else than just clicking on some ice forever. Having no time to implement anything radically new (and having no other idea anyway) I just made special boni, that you collect. They are more rare, and you need one of each to complete the game. I made up the pretext later.
The “play until you die” type of game is not my favorite. It seems too “easy” from the designer. Like they didn’t even bother. I think the winning condition turns a toy (even if it’s a complex simulation) into a game: there is another goal than just playing the game per se.
The technology
Deformable wall meant I was in for a treat. Good thing I like geometry. The wall is simply modeled by a sequence of points. It’s not even a closed line, the ends are just outside the screen. This is OK conceptualy, but it made things more complex later on. Especially for the drawing. The two big difficulties were:
- the vertical faces. They needed to be drawn in the correct order, of course (far first, close last). But it requires to deal with a lot of special cases. The algorithm makes a lot of assumptions (notably, the line shouldn’t self intersect).
- the ice top. I thought “easy, just close the line somewhere outside the screen, and call love.polygon()” Myeah right. OpenGL can draw correctly only convex polygons. There was a big moment of panic when I realised the whole game could be ruined by such an stupid thing. I though of doing it otherwise, like abandoning the neat regular side and “paint” the area with sprites. But someone on IRC told me tesselation was not too hard to implement and should take an hour or so. It took a bit more, but I got it running, with the help of mighty google. Then when you think it’s over, you have to revise the algorithm several times for stupid reasons like counter-clockwise polygons and stuff. Also, the tesselation take time (O(N^3) algorithm. Had no time to optimise), so I had to make sure it was computed only when necessary.
By the way, known bug: when the line intersects itself, the polygon is not simple anymore (it’s crossed), and the algo fails. But I tried to optimize the blast radii so that it doesn’t happen too often. I’m proud I managed to avoid losing more time on that.
Add isometric projection on top of that, and you find yourself converting coordinates between screen space and game space all the time. But I like how it worked out. I think it was worth it.
Löve’s particules are full of awesome. Instant fireball gratification. Well, almost instant.
Also, Lua, I’m loving it more and more. Everything is so easy. People criticize its lack of features. I think it’s what makes it so good. Instead of using a specific method of a specific container class for each different purpose, here you can just call the same thing all the time. table.insert, table.remove. Doing things “myself” with just two functions makes me work faster than having to check a class’ interface documentation.
The graphics
All the ice is vector graphics, which is quite easy (once you managed to compute some coordinates). Compute a color depending on an angle, call drawing functions.
The sprites, well. Harder to make. Half was made solely in Inkscape (the boni, the seal island). The rest was handdrawn, photographied, and used a model in Gimp. Working at high resolution slightly masks the horrible mouse drawing. It still took a lot of time.
Also, so much time that I couldn’t draw the bears, while I had them coded. They random walk and stay away from the border of the ice. It’s useless, but it gives life to the game. The seals do the same and random walk while staying close to the center. I didn’t bother to draw them in the z-order by the way, so they might be buggy.
The sound
Sound effects in sfxr. Three clicks, hop, done. It was too late to be more creative.
The music was tracked in Milkytracker, in the XM format. On my computer the render done by Löve (so SDL_mixer) isn’t really nice, but I hope it’s only a problem of performance. Making the music was fun. Heavy use of repetition. Modules for the win.
The wonders of time managment
Here in Europe it started saturday morning at 6. I think it’s close to the optimal solution.
If you sleep before theme announcement, then you have the full saturday with full energy to code. Then a small night sleep, and another full day of awesome, barely tired. And of course you make the final rush last until the deadline.
It’s only 5-7 hours of sleep over compo time, but you’re still at best performance (except in the last hour, where panic makes you slightly unconfortable…).
Compare with starting friday evening: theme announcement, excitement, starting coding, w00ps, it’s 7 in the morning already. Well too late to sleep. Then you continue during saturday, but you lack of sleep makes you do crap. Maybe you consider a nap, and wake up 10 hours later. w00ps.
I mean, if you try the normal sleep schedule, it has two nights on compo time. If you want to skip one, better if it’s at the end.
In total I worked 36h on the game. It has about twice as many lines of code than my previous entry. You can see on this bzawesome graph the repartition of time among categories of tasks. The major time eater was making 3D in vector graphics. I mean, it was so cool to code, but that’s what 3D engines are for.
The conclusion
Ludumdare is hard. Because you have to complete a chalenging technical task (programming) while making sure that the game will be interesting. Programming is easy. It just takes time. Finding a good concept is hard. It doesn’t take time, it takes imagination, cleverness, genius for some. I have absolutely no idea how fun is my game. None whatsoever. What I’m sure of is the performance of my tesselation algorithm, the quality of my vector library, or the extent of their suckiness.
I may know some programming, and some math, it doesn’t make me a good game designer. Actually I realise I don’t play that much. I find most games boring. I’m looking forward to the day when I’ll have an idea and think “Wow, *i* would love to play that game”. That day, I’ll feel like a game designer. In the meantime I’ll train for the developing part, to be competent when I’ll need it.
I’m happy that I managed to make a complete game. From the three ideas I had, this was probably the simplest, gameplaywise. And this is how it should be. Simple means better chances to implement it correctly and have an enjoyable game. I hope.

It was pleasure being around the IRC playing with old memes and following people’s progress. Grade wisely.
See you all next time!
Tags: postmortem
Very interesting post-mortem. Thanks!
Very insightful