Category: Post-mortem

Lessons Learned from MiniLD #20

Post author By Gianfranco Berardi
Post date 7/26/2010
3 Comments on Lessons Learned from MiniLD #20

Two weekends ago, I hosted and participated in the MiniLD #20 competition.

Mini LDs are usually looser than regular Ludum Dare competitions in terms of rules enforcement, voting, time start and end times, and themes. The host can also enforce a different set of rules. For instance, one MiniLD involved using a specific palette of colors from a 64×64 image to load levels from, and it was interesting to see all of the completely different games share the same level data.

For MiniLD #20, I picked the theme “Greed”, with an optional fun theme of “Fishing”. The special rule I made: “Only one of each.”

In programming, it’s easy to make lots of copies of objects. Well, I’m putting a stop to that! For this MiniLD, you’ll need to ensure that every object in your game is unique. If you build a wall, there better be a single wall (it doesn’t matter how complex it is) and not many tiles composited together to make a wall (unless all of those tiles are completely different from each other, which might make an interesting game…) Granted, maybe everything derives from a common object, but you can’t have two objects that are exact copies of each other. If that means you can only make a few objects, then work within those constraints. B-)

While there was some griping about this rule from the participants, many of them pulled through and submitted a game. In all, 24 entries were submitted.

Unfortunately, The Old Man and the Monkey Thief, the game I was working on, wasn’t one of them.

Also, there were some complaints about how the MiniLD was handled overall, and while I wasn’t taking any of the complaints personally, I did think I let some people down. What follows is a post-mortem of both the game and the competition as a whole.

What Went Right

Participation was high.
I was very pleased to see that 24 entries were submitted. I know that there were more games being developed that weekend that weren’t finished, so overall, there were many participants, especially for a MiniLD. I was happy to see that the special rule didn’t scare off too many people. There were even a few people who have never participated in a MiniLD before. A trial by fire for them!
Simple art was quick art.
When it comes to creating art, I’m much better with a pencil than a computer program. I needed to create quite a bit of unique art, though, and I didn’t really have time to draw with a pencil much anyway. So what did I do? I took pictures with my camera and then traced those images in a separate Layer in the Gimp. That means this flask I got as a present for standing up in my sister’s wedding became a unique golden treasure in my game:

became and this spatula became this Unique Spatula .

Oh, my kingdom for an artist!

But it worked well enough, and it was relatively quick. I even did a decent job creating the main character with a pencil drawing, did the layer tracing thing in the Gimp, and came up with a digital old man who didn’t look half bad!

Overall, tracing with layers in the Gimp made quick programmer art even quicker than it usually is! I didn’t have to worry about being bogged down in getting the lines or curves right.
Being Prepared Helps Before the competition started, I did a quick MiniMiniLD for myself. I hadn’t done any code outside of a day job in many months, and my computer had been upgraded since then, so I wanted to ensure my development environment worked as expected. It would have been annoying to start the competition only to learn that my compiler or build scripts were unusable.
Also, I’ll go into more detail below, but I’m glad I had my backup plans! When a storm knocked the power out for me and apparently 30,000 other people, I’m glad I had my Uninterruptible Power Supply to keep my desktop computer from getting more damaged that it could have been. Also, my laptop let me continue work for over an hour after the power went out, and so it was lucky that I replaced the battery the week prior. When the power didn’t come back in the morning, I took my laptop to a new, powered location, and I was able to keep working even though my apartment went over a day without power. It was a horrible situation during a timed competition, but I think I responded to adversity well.

And it helps to have an encouraging girlfriend remind you that you can’t give up. B-)

What Went Wrong

The power went out.
I took a nap Saturday evening, woke up in the middle of the night, and started working on my project. I had a number of ideas I wanted to implement, and I was wide awake. Around 3AM, with a storm raging outside, I found that my laptop was providing the only illumination in my apartment. The lamps were off, the UPS was beeping, and my desktop’s monitor was dark. That’s OK. I can SSH into my desktop to shut it off…oh. Wait. The router was not plugged into the UPS either. I made a note to change that situation for next time.

I lit a few candles, one in my office, and one in the dining room so I could see when I go out to get some water out of the fridge. Maybe 50 minutes later, the smoke alarm went off. It turns out that the dining room candle was on fire.

Now, I don’t play with fire much, but it wasn’t the fire itself that scared me. It was the fact that the candle, the thing that is meant to be used to hold a flame, was on fire! Another note for next time: don’t put out candle fires with water. The flames exploded upwards before dying out, and suddenly it was dark. I could hear the heated glass and metal parts of the candle holder tinkling, and I had no idea what was going on. And of course the office candle was also out since the melted wax drowned the flame. I had enough with fire for the night, so I didn’t bother relighting them.

So I sat down at my laptop and continued to work. I lowered the brightness and shut down many unneeded applications and was able to eek out 10 more minutes of battery life. Then I had nothing else to do but go to bed. Of course, I was wide awake. I could have searched for the flashlights in the dark or tried the candles again, but I decided this was a forced break and went to bed. My DS was still charged, and I played Advance Wars: Dual Strike for a bit before sleep took me.

The next morning, there was still no power. I learned it wasn’t just my apartment. It turns out that a huge part of Des Moines was without power due to the storms. The library is closed on Sundays due to budget cuts, and I wasn’t sure where the nearest wifi-enabled cafe with power was. Luckily my cell phone still worked, so I had people I could call and a basic way to do searches. My girlfriend was out of town, but I had the key to her apartment, so if she had power, I could work there, too.

I had options, but I’ll admit that I felt a bit defeated that Sunday morning. I wasn’t as enthusiastic about getting up and running again as I’d like to be able to report. Maybe it was because I was exhausted. Maybe it’s because my home office chair is hard to sit in for days at a time. Maybe I just missed seeing people. I was a new full-time indie, and I was secluding myself in my office for way too long as it is. Maybe I just needed exercise. Maybe I assumed the power would come back within hours and I wasn’t sure if I should venture out or stay home. Whatever it was, my motivation had dipped to the point that I was dragging my feet to decide which of these options I’d use.

When I talked to my girlfriend, she was very encouraging, especially as she heard the reluctance in my voice. This weekend was MiniLD weekend, so there’s really no excuse for me to not do what I can to continue. I packed my laptop, the laptop riser, some game dev books, and some papers and notes, and I headed over to her place. I didn’t have the key to the front door, but the doorbell is linked to her cell phone, so she buzzed me in remotely. And she had power at her apartment! Glorious power! I was able to continue work.

Of course, I lost a lot of my waking hours. While I don’t like shifting blame, especially since I had options, there aren’t many options at 3AM during a storm. Now, if my life depended on it, I’d have no qualms about waking people up at 3AM, but for a MiniLD? Still, while the power outage disrupted my work, it didn’t stop me completely.
The Urgent took priority over the Important.
Some things I did other than work on my MiniLD project: called phone company tech support to find out why picture emails weren’t going through to recipients, played a video game, fight a literal fire and not just a metaphor for urgent business matters, read interesting blog posts or watched interesting YouTube videos, chatted on IRC with other MiniLD participants… Now, chatting on IRC is part of the fun of working in a Ludum Dare competition, but links get posted. I found myself distracted by links from Twitter, too. Being new to Des Moines, I spent part of my time looking up local game developers to connect with.

All of these things are fine on their own, but since I was supposed to be focusing on my game project, they were distractions, and I failed at putting them off until after the competition.
I burned myself with my own special rule.
Only one of each was meant to challenge developers to try to do as much as they could with less. Unfortunately, there was some confusion as to what was on or off limits. Could you have the same sprite displayed two times if one had a red color overlay while the other had blue? What if you just add noise so they look different?

Now, I think the idea of using noise to get around the limitation was clever, but outside of that, there were two options: do lots of unique content, or do a game involving only a few unique items. The latter would definitely be doable and be more along the lines of what I was hoping for.

So of course I ended up making a game that required lots of unique content. B-(

Now, being the host, I knew about the special rule long before anyone else did, but I didn’t think about the kind of game I would make until I started the competition. In hindsight, I should have cheated and thought my game idea through before the theme/rule announcement.

The Old Man and the Monkey Thief was supposed to be about an old man who goes to sleep one night only to wake up and find that all of the unique treasures he collected over the course of his long life were stolen by this energetic, ninja-like thief. The old man then had to go into the world, collect these unique items, and use them to save his wife. I figured he could use the fishing pole as a way to retrieve otherwise inaccessible items, and so the secondary theme was satisfied.

What I didn’t realize was how much work it is to program unique items! I spent a huge chunk of a day getting the fishing hook and the key to work. By the time they were implemented, I was afraid to add a third item because of how much work would be involved, and time was running out. Now, this is 48 hours. Imagine being a game developer on a 3 year project and learning that you need to implement another item without letting the deadline slip. I got some insight into that kind of despair.

Essentially, having only one of each item meant that they were either reusable, like the fishing hook, or one-offs, like the key. Either way, this rule encouraged feature-creep if you intended to make a game with a lot of unique content. If I could do it all over again, I’d have tried to do more with the fishing pole alone rather than try to have more than one usable item. Less is more, and I probably should have made a note that it was my original intent with the rule.
The little things.
When I decided on the themes and special rule, I wrote up a blog post and scheduled it to publish when the competition started. There’s a problem with doing so on the main LudumDare.com site. Editors can see the post before it’s published! So I wrote the theme and rules in a post on my own blog, then used the LD post to link to it. Great!

Except something went wrong. For some reason, the LD post didn’t publish, and it took some time to get it corrected. I was away at an event, but I checked in, found out about the problem, and got it working somehow. IRC participants learned about it, but people who were depending on the website being updated at the correct time were out of luck.

I didn’t request a submission form for the competition until near the end when I realized that there were so many participants. Some people had finished before the form went up, so they had to retroactively submit their games. Not a big deal, but it could have been smoother.

And the end? I could have handled the ending better.

Since it was only a MiniLD, the 48 hours is a bit flexible. While it officially started at a specific time, the usual expectation is that you could do any 48 hour period in that weekend. Since I had power issues, and other people were also hoping for a little more time, I thought I’d allow the competition to continue into Monday.

Then the fact that I’m running my own business took over, and other priorities came up. When I finally had time to dedicate to LD again, I learned that some people felt like the MiniLD had no closure. It was understood to be over, but there was no fanfare or official word. The submission form allowed for the entries to have ratings, but since voting was not enabled, participants couldn’t vote. MiniLD #20 felt like it just stopped, especially for people who weren’t in IRC and were relying on the main website for their up-to-date competition information. New LDers can’t be faulted for not understanding what was happening. I had every intention of providing a proper ending, but as the host, I dropped the ball.

What I Learned

There’s more to being a MiniLD host than announcing a theme.
Being a MiniLD host, I found I had some unexpected responsibilities. Namely, I needed to keep things going for everyone to ensure they had a good time! Now, I’m not being paid, and no one else is either, but I still feel terrible that people felt the weekend was somewhat spoiled due to my inability to prepare for those responsibilities. I plan on writing up a checklist for future MiniLD hosts. It may sound a bit formal for such a loose event, but I think it would help everyone have a better time going forward.
Feature creep is insidious.
Let’s extrapolate The Old Man and the Monkey Thief from a 48-hour project to a six month project. Thinking that I’ll add just one more item might mean I spend a few weeks to a month doing so. And if I have an item that can be used, that means creating objects and a section of the map that allows you to make use of it. For instance, I wanted the old man to find a unique tie, which he could use to tie up pieces of wood together to make a boat. Making a tie, suddenly the work is to create boat components and a boat, and why would the boat exist if not to allow you to get across water, and if you can cross water…. The point is that the scope of the project blows up quickly. I realized I was making a poor Zelda clone.

On the other hand, if a game makes use of a single mechanic, suddenly it’s much more manageable. What if the entire game involved the use of that fishing hook? I probably could have finished a game using just that one mechanic.
I need to work on my discipline.
I found myself getting distracted too easily this MiniLD. When adversity hit, I didn’t respond immediately and affirmatively, at least not right away. One of my favorite quotes is “Discipline is remembering what you want”, and I need to remember what I want and why I’m doing what I do if I want to see myself through to the end of any future projects.

All that said, I think MiniLD #20 was a success for me. The Old Man and the Monkey Thief is the first game I’ve ever created that made use of a scrolling background. Previous games used a single screen. To determine where the old man can and cannot walk, I normally would check the tiles, but since I didn’t have tiles, I did something I’ve never done before. I created a black & white version of the entire world map, which the player never sees, and one color represented where the player could walk. Once again, a 48-hour game development competition allowed me to learn some new techniques. I also learned what areas I need to work on. Discipline and project planning in 48-hours is one thing, but discipline and project planning in months or a year? I won’t last very long as a full-time indie if I don’t figure those out.

Game Design Game Development Games Geek / Technical Linux Game Development Personal Development 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]