Category: Post-mortem

LD#15: Mineral Miner Post-mortem

Post author By Gianfranco Berardi
Post date 9/17/2009
2 Comments on LD#15: Mineral Miner Post-mortem

Ludum Dare #15 is over, and I already wrote that the results are in. Aside from placing well in Community, which shows how much I love participating in LD48, I also saw my overall ranking come in at around the 40 percentile. I was ranked #63, which sounds good, but there were a number of ties for previous rankings. Out of 144 entries, Mineral Miner was 87th. It’s much better than coming in almost dead last in the previous Ludum Dare (and not completely last only by virtue of two other entries not getting rated at all), but I’ve done better.

Let’s look back on this project and see what happened. First, let’s go over a summary of the game. Mineral Miner turned out to be a puzzle game in which you drive around a cavern in a tank, getting out to collect minerals. You can only collect one mineral at a time, so you need to drop off collected minerals in your tank to collect more. If you are near a monster lair and not inside the safety of your tank, a monster will come out and chase you. If a monster catches you, you lose. If you collect all the minerals, you can leave the level and win.

What Went Right:

Rapid Prototyping on Paper I took a free, online game design course at GameDesignConcepts.wordpress.com, and I was able to put use those skills to great effect. During the competition, I posted about my prototypes. With only 48 hours, it can feel painfully slow, but I iterated through the design, adding a new mechanic, trying it out, and deciding whether to keep or remove it, and then repeating until I had something I thought might be fun. Painfully slow? It took me almost no time at all. In previous LD48s, I’ve been known to add mechanics at the last minute in an attempt to make a game out of the code I was writing. This time, I knew exactly what mechanics I needed, and there were no real surprises here. The finished game ended up playing exactly how I hoped it would.
Quick ‘n Dirty Graphics I’m not terribly familiar with art tools, such as The Gimp, and so every LD48 I find myself looking up how to use it to create what ends up being ugly art for my games anyway. I decided that this time, I wouldn’t try to make anything fancy. If I have any images that need text, I will use the basic text tool instead of the script-fu that creates cool looking logos if you tweak parameters just right. The tank? A square with a dot to let you know which way is the front. The driver? A yellow circle. Hey, it worked for Pac-man. I was able to focus more of my time on making the game because I wasn’t frustrating myself with trying to create halfway decent artwork.
I Made Sound Effects This is my fifth Ludum Dare, and only the second time that a game I made had sound effects. Because I had a game that pretty much worked the way I expected it to, I had time for some polish. I made a list of sound effects I thought I would need, used sfxr to create the beeps and boops, and wrote the code to tie it all together. Adding sound really makes a big difference to a game, and I was glad that I could do so for this one.
Faster Build Times and Lighter Distributables Because I had been doing some work on my Vampire Game, work that involves using TDD from the first line of code, I also did some work on my build scripts. Going from a 10 minute build time with a distributable that is already 10+MB due to including source libraries to a build that finishes in seconds and is less than 2MB is amazing for productivity, especially as it comes down to the final hour of the competition. Everything happened so much faster, keeping me focused on game development instead of getting distracted as I waited for a build to finish. Now, it isn’t as if my builds always took 10 minutes, but going from checked out source code to a complete build would. Once the libraries were built with my old system, compiling and linking would still take some time, much longer than the time it took with my new build scripts. Plus, one of the complaints I would get from previous competitions is that my game package was so large, so that’s one complaint I did not see this time around. B-)
Simple AI Goes a Long Way I remember taking a few minutes to think about how I wanted the monsters to interact with the level. Should they obey the walls and other obstacles, like the player has to? If so, that would take a bit of AI programming. I don’t have much experience with AI, and I didn’t want to take the time to learn it for this LD48, so what did I do? I made the monster head towards the player every step, ignoring the environment. I could explain it away. It’s a monster. Maybe it climbs walls like crazy? The big surprise was how well it looked. Besides making it move towards the player, I also made the monster randomly move horizontally or vertically to do so. Combined with the sound effect when it comes out of its lair, the twitchy looking monster moving really fast at the player actually feels scary.

What Went Wrong:

Distractions I have two cats, and both of them have been featured in previous LD48s, so I won’t focus on their antics too much. My home office wasn’t in a usable state, so I was out in the kitchen or living room. The cats love distracting me from productivity, and LD#15 was no exception. The one thing I did my hardest to control was external obligations. Anytime someone wanted to make plans with me for the weekend of LD48, I would politely tell them that I was busy. And it worked! I was able to focus almost entirely on eating, sleeping, and LD48ing…except for the Chicago Fire game.

I won tickets to the Fire vs D.C. United game, which happened to be the same weekend. They were really good tickets, too, and so I made an exception. In practical terms, I lost a good chunk of Saturday. I was able to get the game finished, but having an extra hour or two would have been good for tightening up the graphics and audio. On top of knowing that, the Fire lost, so it wasn’t even as fun a game to watch from the 2nd row as it could have been.
The Sound Effects Were Very Rough By far the biggest complaint from people playing my game is that the audio hurts. I was able to get audio in within the last hour of the competition, but I didn’t have time to adjust it. I knew that some of the sound effects were loud and obnoxious, especially the one that plays when you bump into walls, but I couldn’t dedicate the time to tweaking it. The deadline was looming, and I still had a few more programming tasks to complete.
There’s Only One Level Right before the end, I realized that I did not have a victory condition. I had programmed a way to lose if a monster caught you and also if you tried to leave the level without collecting all of the minerals, but someone will eventually collect all of them. What then? Ideally, I would have added code to load the next level, created that level, and kept going. In fact, Level 2 is in the distributed game, although it is a copy of Level 1 and there is no code that knows about it. I was thinking about taking Level 1 and breaking it up into at least three levels, with each level introducing new puzzles and getting progressively more difficult. Three doesn’t sound much better than one, but it would have made a big difference. The player would have felt that progress was being made, and the later levels could introduce the trickier ways to deal with monster lairs.
Level Loading Bug I could not figure it out in time for the deadline, and I still haven’t looked at it since, but every so often, the level loading code would choke on the data, bringing the game to a halt. Sometimes shutting down the game and rerunning it would work. The data came from a text file, and my code is supposed to load a single character at a time, mapping the value to a tile. Sometimes, however, it would choke because a single character variable would have a value that is two characters long. For a time, I was dedicated to fixing it, but with only 48 hours, a good chunk of which I couldn’t make use of, I decided that since it wasn’t a show-stopper, I would keep going. I really wish I could have figured out why that bug was there. Besides ruining the perceived integrity of the game, I know at least one person didn’t review it due to this crash.
Making a Puzzle Game I didn’t set out to make a puzzle game. I didn’t want to worry about creating a lot of content. One level might not be such a problem if the level was varied and fresh each time you played. I could have created a procedural level generator, but I never built one before. I didn’t want to spend time learning how to do so, nor did I want to spend the time tweaking the algorithm to make nicer levels even if I did end up accomplishing it. Out of all of the ideas I came up with, the game I liked the most ended up being a puzzle game, which unfortunately meant I was either going to spend a lot of time making clever levels or finish a game with hardly any levels. It ended up being the latter.

What I Learned:

Rapid Paper Prototypes Work My game design skills are sorely lacking, but I’ve been able to practice what I learned in the game design concepts course, and it really paid off with Mineral Miner. I’m not claiming that it’s a fantastic game, but it did rank #45 in the Fun category, putting it in the top 50%, and #27 in the Innovation category, which puts it in the top quarter! It feels good to know that the game design I prototyped early on before writing a single line of code came together, and the comments for my entry showed that people saw a lot of potential in my game. Everything I wanted to put into the game, I learned from minutes of drawing on paper and messing around with tokens. I didn’t need to have a game engine coded up to explore, discard, and introduce mechanics, which means I saved a lot of time that would otherwise have been wasted on code that would get thrown away and changed needlessly.
Quick ‘n Dirty Graphics and Audio Can’t Be Permanent My art and audio work was minimal and saved me a lot of time, allowing me to work quickly at getting the game play up and running. Unfortunately, my overall rating got hurt here. I was near the bottom in the Graphics category at #104 and surprisingly a little better in the Audio category at #77. I was hoping for time near the end to replace crude art and sounds with better ones, but it didn’t happen. On that note, even if it did happen, it wouldn’t be more than marginally better since I don’t have the practice and skill with my art tools. One suggestion was to use images of my prototype work, and I agree, the drawings look much nicer.
My Pacing Still Needs Work I felt much more confident about my entry this time around, but I still found myself finishing the game at the last minute. There’s very little time for polish when the complete game forms only an hour before the deadline! It’s especially a concern since I decided to go with quick and low-quality art in order to get the game running as quickly as possible. I probably could have set mini-deadlines for myself. 48 hours sounds like an incredibly compressed period of time to make a game, and it is, but it’s still enough time to flounder. Early on, I have two whole days to worry about everything. In the last 5 hours, I’m in crunch mode. I could stand to manage my time and prioritize my tasks much better.

If I could do LD#15 over again, I would try to manage my time better. I could have had the prototype work done much earlier on, leaving me with more time to do the actual programming and arting. I might have been able to get more levels and variety in if I didn’t waste 5 or 10 or 20 minutes at a time wondering what to do. Still, even though Mineral Miner wasn’t a winner of Ludum Dare, I felt it was a success. I designed early on paper instead of designing with hard-to-change code, and I was able to focus on making the game I felt had a chance of being fun. People said they enjoyed the game and wished there were more levels. It was a complete game, meaning that aside from the level loading bug I mentioned above, everything that happens in the game happens because I designed it that way. In 48 hours, a complete game that provided some entertainment for others is a good accomplishment.

Game Design Game Development Personal Development Post-mortem

Sea Friends Post-mortem

I released my first Facebook app Sea Friends in February, and at first it looked like my friends were the only ones adding the game. Pretty soon, strangers started adding the game as well. It is a good feeling when you find that people are enjoying your game. It validates what you’ve accomplished and shows that people find value in it.

If you are familiar with my game development, you’ll know that Sea Friends is based off of my recently released game Walls, which in turn is based off of Minimalist. Minimalist was created for the 11th Ludum Dare 48-hour game programming competition. I wrote a separate post-mortem for it. Sea Friends took the same simple game play, applied a theme, and added a ranking system to a social networking site.

What Went Right:

Setting an aggressive schedule. My business colleague in this endeavor convinced me that it should be possible to get this project done in two weeks. Considering how long I spend working on a single project outside of 48-hour game dev competitions, I liked what I was hearing, even if I wasn’t sure how to get it done. We scheduled one week to make the Facebook app, and another week to tweak it. I figured the worst-case is that I learn a lot in a short period of time, so I went ahead with the project. I’m glad I did, because I was right. I got so much out of this experience, and I was able to put together a game much faster than I would have done before.
Leveraging the work of others. So how do you work a full-time Day Job AND get a complete Facebook project completed in a short period of time? You pay other people to do it for you. I didn’t have the time to learn new languages and write all the code, and while I am a decent programmer artist, I still create programmer art. I needed other people to do the work for me. Essentially, this project taught me how to be a project manager. I only did a few hours of programming, and it was mainly to update Walls with a few new features so I could have the Flash developer see what I wanted in the Flash version of the game. While I was at the Day Job or sleeping, someone else was still getting work done. By leveraging the work of other people, I fit 48 or 72 hours into each 24 hour day. That isn’t to say that I didn’t do anything myself, though. My work was less direct product development and more coordination, planning, and design. I was still exhausted by the end of this sprint.
Before starting this project, I had been reading The 4-Hour work Week: Escape 9-5, Live Anywhere, and Join the New Rich which focuses a lot on the benefits of outsourcing to free up your time to do more of what you find important. One of my favorite moments during this project? Finding out that my car was buried by the previous day’s snowfall and knowing that I would need it to get to a meeting with my colleague on time. I needed to spend my evening looking for a Flash developer. I didn’t have time to dig out my car! So I went to Craigslist and found someone to do it for me. It cost me $20, and the job was done in less time and in a higher quality than I would have done myself. Most importantly, I was able to use that time to do higher priority things, like work on my aggressively scheduled project!

You probably outsource some things without even realizing it. Dry cleaning and automobile repair are two good examples, but why stop there? I haven’t done my own laundry in over a year since I started dropping it off at the laundromat. You pay by the pound, and pick it up at the end of the day. They even fold it for you! There are grocery shopping services, cleaning services, lawn care services, research services, and many other services that you can take advantage of, all so you can focus on what you “don’t have time to do” now.
Theming an existing game. Walls is a fairly abstract game. It is based on Minimalist, after all. While I think the game play should be enough to compel people to play it, I can also accept that having something cute and fun-looking helps. People argue about the importance of high quality graphics to a game, and I’m one of those inclined to believe that they aren’t nearly as important as some people think they are, but I suppose a blunt way to put it is that players will generally like attractive games more than games that don’t appeal aesthetically.
The good news is that the game itself was already finished, so I could literally swap out the art and have a different feel for the game. Check out these screenshots to see what I mean:
Finding a good “team” I found one fantastic Flash developer named Brennan through FlashKit.com’s freelance forums, and he was able to port Walls to Flash in less than a day and did great work putting together Sea Friends. I found a great artist, Jessica Garibaldi, through a coworker at the day job. She did incredible work and was able to give me great looking art daily. Together, these two people helped me have a good experience with outsourcing and put a together high-quality game. If you would like to get in touch with either of them for your own work, feel free to ask me through my contact form.

What Went Wrong:

Finding a good “team”. In order to find the good, I had to go through a bit of bad. On the first day, I found one company to do the Flash port, and I thought everything was going to go smoothly. Hours later, they found that the project was more complex than they initially thought and told me that they couldn’t get it to me on time. I found another developer who was doing decent work, but he wasn’t able to get me the work at the times we agreed. It was almost two weeks into the project, and I still didn’t have the initial Flash port completed! And then, to top it all off, when I tried to bring the project to a close, the relationship fell through, so now I was two weeks in and with nothing to show for it! It was a frustrating experience, but rather than give up, I tried to take whatever benefits I could get out of it and move on.
And the main lesson is that I need to communicate my intentions better.

What’s embarrassing is that I already knew how important clear communications are when dealing with other workers, and yet I still sent out emails and messages that had the potential for misinterpretations. For one thing, Walls looks deceptively simple, and I could have done a better job of conveying how involved it actually is. I had a number of people tell me that they could do the Flash port for $20, and I believe the first company thought they could do the work in a matter of hours. When I finally found the developer who worked on the full project, I learned that I needed to be very very clear and specific. Just because you give the original C++ source code to people, it doesn’t necessarily mean they will read it and know what the game is meant to be. I took every feature, design decision, and mechanic, and explained in detail what was expected. Once I was able to do so, things seemed to go much more smoothly.
Slipping the schedule. Unfortunately, my first two weeks were more about learning lessons than about making a game. I had to take another two weeks to get all of the work done, meaning it took about a month from start to finish. I was still a bit new to the aggressive schedule myself, and I was learning how to set expectations with the people I pay to do work for me. When you’ve never been in a management or leadership position before, it can be a bit foreign to set expectations and act on those expectations. If someone promises you completed work in a day, and 24 hours later he/she make excuses about why he/she couldn’t fulfill that promise, it is perfectly fine to cancel the arrangement. I actually found myself trying to be accommodating to one of the first Flash developers’ schedule, only to have it bite me in the end later. It’s my project, so I should be the one setting the pace. It sounds obvious, but again, if you’ve never done it before, it’s a new skill you need to learn. I never had plans to hire anyone full-time, so I never paid attention to the business books about management, and I wish I had.
Feeling like I’m standing still. The problem with not personally knowing the technology involved is that you can’t easily dig in yourself. I did not know Actionscript or general Flash development, and I’m not familiar with PHP or MySQL. There were days I spent waiting on contractors, and I felt like I was idling in the meantime. I spent some of that time working with my colleague on potential design decisions for this and future projects, but there were a few times when I wanted to dig into the code and get my hands dirty, especially when I knew what little changes would be needed to improve the various releases I received. I had to remind myself that I’m paying these people to do these things for me.
I still want to learn these technologies since I can’t always rely on someone else to do the work for me. I have a finite amount of cash, after all. Sometimes it is fine to let others do the work you asked them, but I still would prefer it if I can take what they have and tweak it. Waiting for them to send me back small changes I could have done myself should save time.
Using proprietary formats. Of course, if I can’t actually make the change even if I had the source, what good is it? With this project, I’m referring to the Flash part. The source was provided as an FLA file. I don’t use Windows or a Mac, and Adobe hasn’t released a way for me to open FLA files on my Linux-based system. It’s funny because there are Flex tools available for writing something new, but I have no way to take work someone else did and modify it. Or if there is, I couldn’t find it.
And no, I really don’t like the idea of using a completely different OS just to use one tool that I don’t actually need to use. Again, there are tools available to create Flash files, but even separate from that, I could have used Java to create applets, or AJAX technologies, or any number of open technologies, and any of them would have been less of a hassle for me.
Marketing the game. Aside from ads in my colleague’s own games, the only way my game would spread was by the players challenging their friends. And it seemed that they were doing so, although the growth seemed to drop off after a bit. I wanted it to be a quiet initial release to ensure that there were no show-stopping bugs, but I’ve only recently been adding links to the game on the GBGames main website. As much as I know that marketing is important, I feel that I dropped the ball here. Press releases, submissions to major game websites, and paid advertising could probably do wonders.

What I Learned:

I learned that you can create complete games in a very short period of time. Now, it isn’t really all that new as far as revelations go. I participate in Ludum Dare, after all, but I usually do so for fun anyway. If I don’t have a working game at the end, it can be disappointing, but it isn’t the end of the world. When you’re making a game that you intend to base part of your income upon, it can be more daunting. It seems like it should take longer to make a “real” game. I found that the greatest breakthroughs came when I thought, “If I HAD to get this done, what would I need to do?”

I learned that when you are going full-steam ahead on a project, the rest of your life can start to deteriorate. Dishes don’t get washed. Paperwork doesn’t get filed. Bills don’t get paid right away. And this is fine! You’ll catch up with everything later. It sounds like a common enough occurrence. You just have to accept that being busy with important stuff means the less important stuff piles up and waits. You’ll get to it when you’re done with the project, or if something else becomes more important AND urgent.

I learned that no matter how much you may want to peacefully and mutually come to an understanding with someone, you can’t always see eye to eye. You can’t get everyone to like you, and you shouldn’t spend too much time trying. You have important work that needs to get done, and if someone isn’t helping you, it’s your job to find someone else. You can’t whine, and you can’t give up. It’s just another obstacle to get past.

I learned that outsourcing work is accessible and affordable to an indie. All told, I spent about $1,175 for Flash work and art creation, which is actually a little higher than it had to be, I’m sure. Even if Sea Friends never makes that money back for me, I think the cost was well worth the experience. I don’t expect to spend so much money on each future project, but if I need work that someone else to do faster and better than I could, I know I have the option to trade my money for their time.

Sea Friends was an exercise in outsourcing more than anything else, and I thought it worked out well overall. On that topic, I would highly suggest reading Outsourcing Art: Ten Steps to Success by Jon Jones for great advice for working with contractors.

I had a lot of fun working on this project, and it was great to see it all come together. And seeing real people in the rankings? It’s very satisfying.

Please check out the game at http://apps.facebook.com/seafriends, and let me know what you think!

Game Design Game Development Geek / Technical Linux Game Development Personal Development Post-mortem

LD#12: Tower Defender Post-mortem

Post author By Gianfranco Berardi
Post date 8/21/2008
1 Comment on LD#12: Tower Defender Post-mortem

My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.

What Went Right:

Simple game mechanics still work.
Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.
I had an office door I could close.
My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.
Using Test-Driven Development
Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.

What Went Wrong:

Learning Test-Driven Development while using it.
I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.
I still didn’t have a good handle on SDL
Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.
Working long hours really does screw with your productivity
It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.

I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.
I didn’t get game play until the very last minute.
I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.

What I Learned:

I still have a lot to learn.
It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.
Test-Driven game development is awesome.
Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.
I need to work on my pacing for LD.
It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.

Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.

[tags] postmortem [/tags]

Game Design Game Development Games Geek / Technical Linux Game Development Personal Development Post-mortem

LD#11: Minimalist Post-mortem

Post author By Gianfranco Berardi
Post date 4/29/2008
7 Comments on LD#11: Minimalist Post-mortem

In one 48 hour period, I made a simple game based on the theme “minimalist”. I didn’t try to stay awake throughout the entire Ludum Dare competition, so the game was made in less than 48 hours.

What Went Right:

Used my build script to create a distributable game from the beginning.
I have a build script from a previous project that allows me to use a single command to take my project source, build it, and create a .tar.gz file to distribute for GNU/Linux users. Towards the end of the competition, I wasn’t spending too much time trying to figure out how to get my project into a judge’s hands since.
Mouse control was easy to do and easy to use.
Since I was learning SDL, I tried to make my game as simple to use as possible. I knew that using a mouse was a lot easier than expecting someone to use the keyboard, but I had never implemented mouse control in a game before. Luckily, it turned out to be very easy. As a result, the interface was very simple since you’re just moving the mouse around, and the game that this interface produced was better for it.
I got really involved in it.
I had food photos and a time lapse video, and I even received two trophies, one for my eclectic food choices. Hanging out with all of the other Ludum Dare participants, even if just virtually through IRC, was a lot of fun.
I finished!
Of course, finishing was also a lot of fun. While I could have used some more playtesting and would have loved some feedback before it was submitted, I think I put together a decent game in a short amount of time. It feels good to finish things.

What Went Wrong:

My work environment was horrible.
A couch is comfortable…but not for marathon game development sessions! My back still hurts. I need to clean my office. Right now, I am using it as a giant inbox:

I prefer development with my laptop because the CRT of my desktop is harsh on my eyes. Still, it would be nice to sit in a real chair while working. Alternatively, I can finally buy an LCD for my desktop.
My cats love to hang out with me.
Even if I was sitting in my office, I know from experience that my cats would still jump up into my lap and try to rest their heads on my arm. When you’re using a laptop, there isn’t room for it AND a cat or two. Having an office door to close would help, of course, but the cats were quite a distraction for LD#11.
I didn’t practice using SDL before the competition.
It was a problem especially since I had decided not to depend on the Kyra Sprite Engine for future projects, but I really only used libSDL for input and creating a window prior to this project. When the first 24 hours are finished and all you have is a window rendered and the knowledge that the mouse handling is working (even if it isn’t visible), you might be afraid that you won’t have anything to show at the end of 48 hours. I did manage to pull it off, but by the next competition, I want to be able to work with less of a focus on technical details and more of a focus on game development.
I spent too long in the beginning trying to mock something up in the GIMP.
Similar to the previous point, I was spending more time on technical issues than on creation. I thought I was more familiar with the GIMP than I was, and I spent a lot of my early hours fighting with it instead of just using pencil and paper. The worst part about it was that the initial idea was one I ended up discarding, and if I wasn’t wasting time with figuring out how to do some simple things in it, I might have been able to figure it out sooner.

What I Learned:

My kitchen goes to entropy during LD.
When you’re focused on game development for most of your waking hours for two days, other things have to take a lower priority. One of those things was cleaning. I had a bit of a mess to deal with after the competition was over.
Even something incredibly simple can be a good game mechanic.
I knew I wasn’t going to be drinking multiple cans of Mountain Dew or Red Bull, and I don’t drink coffee, so staying up for 48 hours wasn’t going to happen. I needed to work on a game I could finish, so I picked the simplest thing I could. Surprisingly, it was fun, and some of the judges have said so as well. At the end of the competition I already had a list of ideas that could improve it, and I hope to release an updated version with those improvements.
It’s possible to do a lot in a single day.
Even though I spent some time learning how to use SDL, I still managed to make a game. The best part is that I can incorporate what I have learned into my personal library of code for my future projects. Also, there were over 70 games submitted, and it is amazing what some people were able to do in 48 hours. Some of them were learning how to program!

I set aside most of a 48 hour period, and I have a game, some new code, and more experience. If I could work on a project with a similar scope each month, I think it would go a long way towards improving my ability to create video games. Also, it’s a lot of fun, and I will definitely be participating in future Ludum Dare competitions.

To see my entry, check out the final version. There is a GNU/Linux and a Windows version.

[tags] postmortem, video games, game development, cats [/tags]