{"author_name":"CJ K","cat":"LD #30","comments":[],"epoch":1410797760,"likes":2,"metadata":{"p_key":"26198","p_author":"CJ K","p_authorkey":"35714","p_urlkey":"61623","p_title":"100 Days Postmortem","p_cat":"LD #30","p_event":"LD30","p_time":"1410797760","p_likes":"2","p_comments":"0","p_status":"UPD5","us_key":"35714","us_name":"CJ K","us_username":"cjddmut","event_start":"1408665600","event_key":"24","event_name":"LD30"},"text":"

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\u2019t 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\u2019t have much to show for it. Raw prototypes don\u2019t show off very well. However, Ludum Dare gives me the opportunity to release a game, even if it\u2019s a short web game. It\u2019s nice to be able to show people something with a little bit more polish to it.<\/p>\n

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.<\/p>\n

100 Days Entry<\/a><\/p>\n

What went right?<\/strong><\/p>\n

Scope<\/em><\/p>\n

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\u00a0be in my prototypes, I didn\u2019t 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.<\/p>\n

 <\/p>\n

\"paperdesign\"<\/p>\n

 <\/p>\n

Though knowing when features needed to be done didn\u2019t mean they would be done in time. I also executed the features in scope efficiently. As a programmer, it\u2019s really easy to get caught up in doing things the \u201cright\u201d 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 \u201ccorrect\u201d is not often worth the time spent.<\/p>\n

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\u2019t 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.<\/p>\n

 <\/p>\n

\"generatedworld\"<\/a><\/p>\n

 <\/p>\n

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<\/i>. 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\u2019t even attempt to use a heuristic which would not have been hard since I know where the player is. I didn\u2019t need to. The game ran at 60 fps with the simple searching.<\/p>\n

Though more than just programming features contribute to scope. Content is expensive.<\/i> It takes time to build a diverse world, write an interesting script, or to have a wide variety of challenges. That\u2019s 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\u2019s 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\u2019d have kept creating 100 Days in 48 hours possible.<\/p>\n

Time Management<\/em><\/p>\n

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\u2019s easy to think that you need to spend more and more hours to complete your entry. I\u2019d argue that doing this hurts your output and you can get more quality work completed by spending less<\/i> time working on it. I make sure to get a full night\u2019s rest every night, I regularly take breaks, and I\u2019ll try to make sure I have a wind down period where I\u2019ll do something else before going to bed. The thing is if I\u2019m tired I\u2019ll make mistakes. If I make mistakes I\u2019ll get frustrated. If I\u2019m frustrated then I\u2019ll make more mistakes. The worst of it is if I\u2019m frustrated then I\u2019m not having fun. If I\u2019m not having fun then I don\u2019t want to participate. Sleeping and taking breaks both improved my output and made the whole competition more enjoyable.<\/p>\n

Polish<\/em><\/p>\n

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\u2019t really surprising. When most players only spend a few minutes on an entry it\u2019s critical to leave an immediate impression and that\u2019s where polish shines.<\/p>\n

However, polish isn\u2019t free and takes time to do. So it\u2019s 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.<\/p>\n

 <\/p>\n

\"largeenemy\"<\/p>\n

 <\/p>\n

 <\/p>\n

What went wrong?<\/strong><\/p>\n

Understandability
\n <\/em><\/p>\n

This is problem that just continues to haunt me and it reared its ugly head for 100 Days. It\u2019s 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\u2019t. Those who didn\u2019t struggled to grasp the resource aspect of the game leading to a degraded experience.<\/p>\n

 <\/p>\n

\"understanding\"<\/a><\/p>\n

 <\/p>\n

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\u2019t want the player to learn that they die if their fuel hits zero. I wanted the player to learn how<\/i> 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.<\/p>\n

Grammar \/ Typos<\/em><\/p>\n

This one is pretty embarrassing. The typos I really have no excuse for. The grammar I can at least claim ignorance, for what that\u2019s 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.<\/p>\n

Analytics<\/em><\/p>\n

This probably seems like an odd entry for a Ludum Dare postmortem but it\u2019s 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\u2019s successes and failures. Anything that helps me learn is worth my time.<\/p>\n

However, analytics only helps you learn if you gather actionable data, with actionable being the key word. I didn\u2019t 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\u2019t 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.<\/p>\n

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.<\/p>","time":"September 15th, 2014 11:16 am","title":"100 Days Postmortem"}