About tzachs


Ludum Dare 20

tzachs's Trophies

tzachs's Archive

Auto Army- Postmortem

Posted by
Thursday, May 12th, 2011 6:39 am

Well, it was my first LD and it was some ride!



I already decided before the competition that I would use FlashPunk & FlashDevelop for development, Box2D for physics, MinimalComps for UI and Paint .Net for drawing.

Other than MinimalComps I had already worked with all of the tools to some degree, and felt confident with them, and while I didn’t know MinimalComps I figured it would save me the trouble of drawing my own buttons and such, so it would be worth it…



I woke up at Saturday morning, and went straight away to see the theme.

I then realized how dangerous it is to work alone, so I took this!, and then spent the next ~2 hours coming up with ideas. I tried to think of something simple, that I would be able to make something playable fast with, but which can also be extended after the competition will be over.

Eventually I came up with a bit weird and vague idea, that seemed simple enough to accomplish, and looked fun in my head. What I first imagined (I think) was basically you building your army to stand against your enemies, and then slipping to the next room while everybody is fighting and shooting at each other… Something like a mash-up between Plants vs Zombies and Heroes of Might & Magic (the battlefield part), only with puzzles that combine both tactical thinking and real time co-ordination.

Did I say weird and vague already?

Well, at this part, I obviously concluded that I won’t be needing physics so I ditched Box2D, and decided to go on a tilemap based game. Also, since this idea can still go in plenty of directions, I decided to first try to do some level design before even starting to code, to see if this idea is even feasible.

So I spent the next ~2 hours designing 10 simple levels. I did that with an awesome tool called notepad, it lets you write different characters on screen! I simply wrote all my maps with ASCII characters where each symbol meant a different unit, enemy or obstacle. During the level design I also designed the player’s units, the enemies, the obstacles and the player behavior. I also had to design how each of these interact with each other, which I did, but did not think it through (as will be seen later). For each level I wrote down the layout of the room, and my proposed solution to see that all levels are passable.

When the level designs were done, I actually had to go and visit my father, and then meetup with some friends (earlier engagements). That wasted several important hours, and as soon as I came back I sat down, pulled an all nighter and drew all of the tiles.

These look less than pretty, but that was what I was able to come up with at such short time and with limited skills. In the official version, I hope to partner with an artist and make some super awesome graphics! In fact, if there’s an artist who wishes to join me, feel free to contact me.

I also started scripting the UI, it was then when I realized, that MinimalComps is simple only if you don’t touch it! I just wanted to make the font larger, and discovered that it was not really supported, so I had to hack the code, another waste of time…



Next morning,  unfortunately, I had to go to work. Yes, there are countries in which Sunday is a work day, mine is one of them! Another waste of time…

As soon as I got back, I started frantically coding. The first thing I did was coding a level map reader, so that I could simply put my earlier notepad designs in, and it would layout the level for me. That worked pretty well and saved me some time, and so I started to crank up the first levels. I coded the behaviors of the units and enemies, play-tested it, fixed some issues and continued.

As I reached the more advanced levels, the time was starting to run out, and then I realized that the advanced levels assumed some abilities that I had not coded, and were now pretty complicated to make. For instance, the enemy archers should shoot my player as he runs out if they are not occupied, even if they are not on the same row with it. However, I coded the archers to only shoot at stuff coming on their row, which made them pretty pointless as enemies if they are not in the player’s row, which they weren’t, because I had already put some other stuff in that row…

Since it was already too late, I decided to scratch the last 4 levels, and I quickly designed a single new advanced level which would fit with what I already coded. After that was done, I play-tested the game from start to finish and saw that it’s playable. However, I only play-tested the right solutions, I didn’t try to play-test wrong player behavior due to lack of time.

I had maybe 2 hours left at that point, and I wanted some spare time in case of uploading trouble. The one feature which was obviously missing was a “Restart Level” button for when you die. I really hadn’t planned it in advance, it was an afterthought, and as a result, it only works half the time…

Well, that’s it.


So, to sum up:

What worked-

  • I selected in advance tools that I’m familiar with, which made my job easier.
  • I chose an idea which I honestly like, and I think has a lot of potential.
  • I made the level design first. This gave me insight into the coding.
  • I coded the level map reader, which allowed me to easily switch level layouts, and this could expand later on reading output from a full fledged level editor.

What didn’t work-

  • The biggest problem was that I didn’t make enough time to work on it properly. I will try to amend this in future LDs.
  • I gambled on MinimalComps for UI, which I didn’t really know, and it only partly paid off.
  • I didn’t think through the interactions between the components of my game, when I designed the levels.
  • The “Restart Level” feature was an afterthought, I should have thought about it in advance. More generally speaking, I should have sat down and decide on what features are a must before starting to code.
  • I only play-tested the solutions to the puzzles, and didn’t give much thought to other actions that the players might do.


In the end, despite all the faults, I am pretty satisfied with the fact I have an idea which has potential to become an interesting game, and from the feedback I’ve been given, I’m not the only one to see this (which is a first).




[cache: storing page]