Ludum Dare is awesome. A welcomed challenge every four months. In order to improve my skill at design, I spend most of my time creating simple prototypes to learn what does and doesn’t work. This has benefitted me immensely and I remained convinced that it is the right route to becoming a better designer. The downside to this practice is that I don’t have much to show for it. Raw prototypes don’t show off very well. However, Ludum Dare gives me the opportunity to release a game, even if it’s a short web game. It’s nice to be able to show people something with a little bit more polish to it.
For Ludum Dare 30 I created 100 Days. You are the EAS Indomitable, the first human vessel to explore deep space. Disaster strikes and you must survive for 100 Days before home base can warp the Indomitable back to safety.
100 Days Entry
What went right?
Scope
When the theme was released at 6pm I did not go anywhere near a computer. Since I have been making it a habit to design on paper every detail that will be in my prototypes, I didn’t see why I should do it any different for a LD game. Especially given the short time limit, I wanted every aspect of the game thought out upfront. If I missed some detail then I would consider that a failure. Before touching a computer I had the actions listed, the resources that would be used, the costs of moves, combat details, and even had drawn what I wanted the UI to look like. Because of this upfront effort, there were less surprises and I had a pretty good idea of what needed to be done by when.

Though knowing when features needed to be done didn’t mean they would be done in time. I also executed the features in scope efficiently. As a programmer, it’s really easy to get caught up in doing things the “right” way. Spending the extra time to make sure architect is clean or making sure the code runs as optimally as possible. KISS: Keep it simple stupid, especially for a game jam. The gains you get by doing it “correct” is not often worth the time spent.
The world generation for 100 Days is hardly optimal or even elegant. In a 200×200 space, random worlds are created based off of a probability curve which decreases the further away from the origin. Then another pass marks worlds that are connected to the origin world. Yet another pass will then walk from each world that isn’t connected to the origin and walk towards the origin until it hits a world that is connected. To make sure that the player can traverse at any depth a circle of worlds is created every 10 nodes. Finally, to keep options open for the player, random worlds are selected and additional worlds are generated walking away from the selected world.

Now I have very little experience with procedural generation. I do not know any common practices, algorithms, or techniques. My approach to the world generation was simply the most obvious option that came to me. I am absolutely sure that there are far more calculations than necessary, probably even redundant calculations, but I do not care. I had the entire world generation code completed before I went to the bed on the first night. A huge part of what I needed in the game, completed in a few hours. The negative impact of my straight forward obvious approach? 2.5 seconds. According to my analytics, the average load time for users was 2.5 seconds before they can play the game. I can live with that. To further drive this point, the AI uses limited DFS to find the player. I didn’t even attempt to use a heuristic which would not have been hard since I know where the player is. I didn’t need to. The game ran at 60 fps with the simple searching.
Though more than just programming features contribute to scope. Content is expensive. It takes time to build a diverse world, write an interesting script, or to have a wide variety of challenges. That’s not to say focusing on any of these for a Ludum Dare is a bad idea. We all want these things for our games, but it’s easy to forget or underestimate just how costly content can be. 100 Days was kept purposefully simple. The story was brief, only a few enemies and they all behaved the same way, and no sprite animations were created. Keeping an eye on how much content I’d have kept creating 100 Days in 48 hours possible.
Time Management
I see a lot of people who sleep little or none at all and work themselves past the point of exhaustion. This is not the way to handle a Ludum Dare. I understand why this happens, you only have two or three days to complete a game. Time is precious and you have very little of it. It’s easy to think that you need to spend more and more hours to complete your entry. I’d argue that doing this hurts your output and you can get more quality work completed by spending less time working on it. I make sure to get a full night’s rest every night, I regularly take breaks, and I’ll try to make sure I have a wind down period where I’ll do something else before going to bed. The thing is if I’m tired I’ll make mistakes. If I make mistakes I’ll get frustrated. If I’m frustrated then I’ll make more mistakes. The worst of it is if I’m frustrated then I’m not having fun. If I’m not having fun then I don’t want to participate. Sleeping and taking breaks both improved my output and made the whole competition more enjoyable.
Polish
In my opinion polish is the single most important aspect of a Ludum Dare game, in terms of being judged. I have seen otherwise uninteresting games receive high praise because of how polished the entry was. This isn’t really surprising. When most players only spend a few minutes on an entry it’s critical to leave an immediate impression and that’s where polish shines.
However, polish isn’t free and takes time to do. So it’s important to pick your polish battles carefully and even more important to pick your tools carefully. Leveraging cheap polish techniques can make your game feel much more complete without a huge time cost. For 100 Days I heavily leveraged tweening. For everything from moving, combat, to zooming the camera. Carefully picking an easing function for your tween can give your animations more flavor and improve the general feel of the game. Particle emitters are another great tool for creating quick and effective polish. In 100 Days the engines and explosions were created using very simple particle emitters.

What went wrong?
Understandability
This is problem that just continues to haunt me and it reared its ugly head for 100 Days. It’s a goal of mine to make the interaction with the game intuitive enough to not require a separate tutorial screen. As a player I am annoyed when its necessary for me to look at instructions outside the actual game itself. To combat against needing a screen outside of the game, I implemented a help section in the UI that prompted text when the player hovered over an object. However, that only works if players realizes it is there and understood how to make use of it. Some noticed and figured it out, others didn’t. Those who didn’t struggled to grasp the resource aspect of the game leading to a degraded experience.

To improve on the understandability of my games, I think using more assets to be as clear as possible about how the interactions with the game works. I didn’t want the player to learn that they die if their fuel hits zero. I wanted the player to learn how to prevent their fuel from reaching zero. Using simple art assets to clearly show the next valid movements or larger icons for resources on planets can go far for understandability. It may not be elegant, but having a prompt that the player must click through that explicitly stated that additional help text is supplied on hovering could have made 100 Days much more approachable.
Grammar / Typos
This one is pretty embarrassing. The typos I really have no excuse for. The grammar I can at least claim ignorance, for what that’s worth. Luckily the typos are an easy fix that really comes at no cost. I need to write all my content in a proper word processor that can detect misspelled words. Easy. Grammar is trickier but a problem I want to solve. Writing more and having people proofread will help me with grammar. This postmortem has an excellent exercise on its own, and yes, I have a friend who has been proofreading it for me. Though he didn’t have time to check out this final version, so we’ll see how it goes.
Analytics
This probably seems like an odd entry for a Ludum Dare postmortem but it’s certainly an area I came up short. Earlier in this postmortem I wrote, in great length, about implementation efficiency and time management. So why would I even be concerned about adding analytics to my game when it takes time? Because information is power. A big reason I participate in Ludum Dare is that it gives me a chance to try new ideas and when I try out an idea I want to learn from it. Analytics is another tool to help with learning about your game’s successes and failures. Anything that helps me learn is worth my time.
However, analytics only helps you learn if you gather actionable data, with actionable being the key word. I didn’t really have a plan when I started placing analytics into 100 Days. I basically decided to record as much as I could and hope that it was useful later. Some of the analytics worked out alright, as I mentioned earlier it took an average of 2.5 seconds for players to load my game. That was useful to know because it justified my decision to not optimize the world generator. But most of the data didn’t help me out in the end. Knowing that over 2000 extractions have occurred in my game is cool but not useful. What would have been useful? Analytics around the user experience. How long did it take before the player hovered over an item to read the help text? How often did the player do it? I knew fuel was the most important resource to manage, how many attempts did it take for players to learn this? Hindsight makes it easy, but these were the important questions.
My whole approach on how to add analytics to a game needs to change. Much like designing, this is going to require me to step away from the computer and truly think about. I need to sit down and ask myself what is it that I really want to know? And if I can learn the answer, what can I do about it? Once I have the questions that lead to actionable answers, I can start figuring out what data would help me answer the questions. As good analytics can help me improve everywhere, doing this correctly is perhaps the most important thing I can take away from this Ludum Dare.