Ludum Dare 28 Post Mortem…

Okay so I guess I’m a few days late in putting up a Post Mortem for LD 28, but life gets in the way sometimes, so better late than never.

Before I start talking about my game and what I learned, you can click the image below to play the version I ended up submitting.

My LD 28 Game - Zombie Mall

While you’re at it, you should also check out my game’s page on the LD website, where you can see the feedback I’ve received.

I’m going to start off by saying that I’m mostly happy with my game. By no means did the game turn out perfectly, but to say that I failed would be inaccurate as well. I think for a first attempt at a solo game jam, I did a pretty good job. Most of the feedback I’ve gotten up to this point has been pretty positive about the gameplay, and has otherwise been directed towards the lack of polish/animations, and towards little things that could be changed or improved. Despite what I considered to be a lack-luster idea, many people seemed to like my game and thought I did it in a unique way. So before I get into the nitty-gritty, let’s talk about what my game was, and what it was trying to be.

The Concept

If you read through my previous 5 posts you should have a pretty good idea of the game’s concept, but just in case, here is an overview. The theme of Ludum Dare 28 was You Only Get One. I used this theme in a couple of ways.

The game itself was a pretty standard survival-horror/zombie game done from a top-down perspective. To integrate the theme I first used the obvious idea that if you are hit once by a zombie, you lose. On top of that though, I wanted to add an extra stress/horror element to the gameplay to make it challenging. To do this I made it so that the player could only perform one action at a time. For example, the player cannot run while they are shooting or reloading. If I had gotten the chance to implement it, the player also wouldn’t have been able to have their gun out while moving objects and constructing barriers.

The idea here was to make the game challenging and stressful by forcing the player to always be considering their next move, and to be very wary of the environment they are in when doing things. I also wanted to make the game somewhat realistic with this. If you concede to the fact that my character is not a trained marksman or combat specialist, it’s unlikely he would be an accurate shot when standing still, let alone when moving around with enemies coming from all sides. To that end, I also played with the way reloading works. In most games you reload your guns based on the clip. So if your gun’s clip size is 50, you reload up to 50 all at once. I wanted it to feel more stressful so I decided that instead you would reload bullets one at a time, or they would reload over time. This has been done in some other games, and I thought it would add a nice effect to do it here.

Beyond these ideas, there wasn’t much more to the game. My personal opinion is that wile the game did fit the theme, and was fun to work on, competitions like this are the most fun or the most interesting when they explore a concept you would be unlikely to sell to a larger publisher, or which would not at first glance seem like it could be a financially successful game. In that respect I do think I failed, simply because the concept itself is not incredibly unique or revolutionary. With that said though, not every idea can spark a revolution, so you gotta go with what you have.


Overall, the gameplay felt the way I envisioned it when I first started. Even I felt the stress of having to worry about how much ammo I had, where I needed to go next, and whether I was ‘aggro’ing the zombies in the area. I also know based on feedback I received that other players felt similarly, and did get the experience I was trying to create. Despite this I received a few comments about the movement, specifically that the way the player locks to the direction they are moving felt unnatural and was annoying. The idea here was to make it feel like your character was stressed and was flat out running away without looking back, but it ended up just making the game feel strange when the direction would change in an instant.

While many of the gameplay elements I did include were successful, I wish I had the time to include a few more. I really wanted to give the player the ability to lay down traps for the zombies, and I wanted the player to be able to move large items that would affect the zombie pathing, and allow the player to construct barriers. These features didn’t come to fruition for a few reasons. First, I didn’t have the time due to poor planning. The trap system would have been easy, since I’ve built similar things before, but I didn’t plan my schedule well enough and kept putting it off because bigger things came up. Second, I didn’t plan the barrier movement idea well enough. I tried a couple different methods, and it simply didn’t work the way I wanted it to. If I had put a little more time into how it would work before starting on some earlier systems, I might have been able to get it in, but I didn’t want to risk breaking what I had to implement something that I wasn’t sure I could even use effectively. The game itself ended up being fairly short, modifying or expanding the level to make the system useful probably would have taken more time than I had, and I didn’t want to take that risk.

The lack of these features also caused another issue. Initially I had envisioned the player being able to move items, but didn’t want them to be able to unless they were unarmed. Because of this, I gave the player an unarmed state. When I failed to integrate this feature, I never thought to remove the unarmed state for the player. This player state ended up being mentioned in about half the comments I received on the game, between all the places I posted it, so I definitely think it detracted from the game that I left it in.

The other feature that received a lot of attention was the reloading. Many people seemed to like the way the reloading worked, but I did realize that my instructions themselves were actually unclear. In the game you use the ‘R’ key to reload. Each gun reloads at a different speed, and if you hold down the key the gun will continue reloading until the clip is full. In the instructions I failed to mention that you could hold the key down, and a lot of people thought you had to manually press the button for each bullet. While this is fine for guns like the pistol and shotgun which each take less than 10 rounds in a clip, the machine gun and flamethrower would end up being a pain to use since they take 60 and 150 rounds respectively.

Level Design


In the end I think the level itself turned out very well. I didn’t have the time to make sprites for most of the in-game objects/props, but the level layout seemed mostly successful, and received very few comments.

One comment I received about the level was positive, and mentioned that the player liked how the extra ammo was mostly in corners, and it forced them to take risks to receive the bonus. I also received a comment from a player who didn’t think the goal was clear enough. That was the biggest fault with the level design. While the level does a great job of giving the player an environment to explore and mess around in, it doesn’t do a good job of guiding the player to their destination. On top of that, unless you read the instructions, you probably won’t know where to go. So in the end, the level layout works, but the scenario design could definitely be improved.


The graphics for the game turned out better than I expected. The sprites I made may not have been masterpieces, but they came out better than I expected.


The biggest comments I received about the art were that I needed animation, and it didn’t fit the style of the game, and I honestly can’t argue with either of those points. I went with a sprite look because I love classic games and thought it would be fun to try my hand at it, even if it didn’t turn out well. While the sprites themselves aren’t bad, many people commented on the fact they thought the art could be darker, or that the art was too bright. Considering I was attempting to make a zombie game, they thought I should have put more effort into creating a mood with the art. As for animation, I simply didn’t budget my time well enough. I actually had animated a walk cycle for the main character, but I had a lot of trouble getting to work . Eventually, since I couldn’t solve the problem, I decided to move-on and use non-animated sprites. I didn’t realize what I was doing wrong until a few hours after the competition ended, and promptly kicked myself because I was making a mistake that seemed simple in retrospect.

Thinking back I wish I had spent more time practicing striping beforehand since I had a strong feeling I’d be using it in the game. On top of that, I wish I had looked into how to simulate lighting with Construct 2, since that would make a huge difference in the game’s feel.

What I Took Away From LD 28

With all this in mind, I learned a few lessons from this competition:

  • Just because an idea doesn’t interest you, doesn’t mean it can’t be good – While I didn’t love my idea to begin with, I ended up enjoying making it, and a lot of people reacted positively to it. When the competition first started I spent 3 hours trying to think of a better idea, and lost some precious time because of it. Next time I participate in an event like this I definitely won’t dismiss ideas as quickly simply because I don’t feel as positive about them initially.
  • Budgeting time in advance is very important – Early on I made some assumptions about how long things would take, and assumed I would have certain amount completed by certain points. Despite this, I never sat down and actually wrote out how much time I was giving myself for each thing I wanted to do. This often caused me to go “over-budget” and spend more time on some tasks than I should have, especially ones which ended up failing. If I had set time limits on each task early, I may have been able to attempt more features or given up on failed ones quicker.
  • Focus on one thing at a time – Especially towards the end of the competition, I found I would often start one task, and then without realizing it jump to another that was tangentially related. This would leave me with a number of incomplete items that I would forget about and then need to return to later. In the last 12 hours of the competition I finally started keeping better track of the tasks I had, and worked much harder to focus on a single task at a time, no matter what else I thought of Those hours ended up being some of my most productive.
  • Quicker is not always better, even when the clock is ticking – One important element of the game was the zombie behaviors. Early on I used a very simple system to get the zombies following the player and it seemed to work. Eventually I wanted to make the zombies more complex, and found that because of the simplicity of my initial system, it would be very challenging to implement these new features. This forced me to switch to a more complex, but more versatile system later on and I ended up scrapping most of the old one. If I had taken more time to consider the pros and cons of each option early, I may have been able to use that time for better purposes and make the zombies more “intelligent”.
  • Keep track of how much time is left – Towards the end of the competition I was under the assumption that it was ending at 9:00 pm my time, when in fact it ended at 10:00 pm my time. Because of this I rushed to complete a few features, and spent time exporting and “finishing” my project so it could be submitted. I then saw on the site that I had an extra hour and rushed to complete/polish a few more things. While this mistake was good in the end, I still ended up exporting my project multiple times, and wasted time thinking I didn’t have the time to do anything else. If I had kept better track of the time I had, I might have been able to accomplish one more small task.
  • Do more outside playtesting – Due to time constraints and other factors, I didn’t do too much outside testing, and most of the testing was done by me. If I had brought over some friends to test for me, it would have shown me a few small bugs sooner, and it would have made it clear that some information wasn’t being conveyed correctly. Next time I will definitely plan to have people test for me at certain points to prevent this issue from happening again.

What’s Next?

While the competition is over, I did really enjoy working on this game, and it sparked a few interesting game concepts in my mind. My goal right now is to keep working on my project from Ludum Dare and to see if I can improve it based on the feedback I’ve received.  I’ve already started to do this, and if you want you can try the most recent version of my game by clicking the image below.


So far I’ve made a couple of different improvements:

  • I removed the unarmed state as a separate state the player can be in, and made it so that instead they can either have their gun out, or have it holstered. Now the player always has a gun equipped, it’s just a matter of whether it has been holstered or not. By holding the right-mouse button down you can take out the gun to fire, and reload. This preserves my intent to add movable objects which can only be manipulated while the gun is away, and makes it more realistic in some ways.
  • I added a message that tells the player he needs to reload or switch weapons because he has no ammo.
  • I changed the movement speed.
  • I added an aiming reticle for the player when they are firing.

On top of that, I am currently working on getting a lighting system in. I would like to use ray-casting, but it seems like that may not be possible in the engine I’m using. I’m currently looking into other alternatives, but depending on how hard or convoluted they end up being, I may just move to a new engine and restart development at some point. I am enjoying working with Construct 2, but I do constantly feel the limitations of the engine. My decision to switch will depend entirely on how the lighting ends up working out, and how serious I become about this project.

In the end, despite my failings, I still feel good about this project as a whole, and I took away some good lessons that will likely do me well in the Global Game Jam next month.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>