Jump to content

  • Log In with Google      Sign In   
  • Create Account

Like
10Likes
Dislike

Post Mortem: Da Boom!

By Sean "rioki" Farrell | Published Mar 22 2014 06:10 AM in Production and Management
Peer Reviewed by (jbadams, Servant of the Lord, Aldacron)

postmortem indi deisgn development

Da Boom! was developed over the course of the last half year in my spare time. It is a classical bomb laying game with a retro art style, but with the ability that you can play the game over the network. Not only can you play the game over the internet, but you can mix local multiplay and network play, you can for example have stwo player on one end and two on the other.

The focus of this project was mostly centered around developing technologies and development strategies. This is the first hobby project that I ever completed. I went out and said, either I complete this project or I give up on game development.

What Went Right


Limited Scope


From the start I knew that I had to pick a small project and severely limit the scope. I can only invest around 20 hours on a good week and this means that I had to remove as much gold plating as possible.

The actual choice of the game type was triggered by a good friend complaining about that lack of bomb laying games that worked properly over the internet. This game type with its limited scope fit the bill quite nicely.

But even here the scope was reduced to only have 3 power ups and a restricted art style.

Art Direction


Although the art is technically speaking “programmer” art, it is not at the level I can produce. I specifically aimed at a severely reduced and retro looking art style. This art style meant that I could quickly get something on screen and play around with the game mechanics.


Attached Image: DaBoom-0.1.0-sc1.jpg


Pivotal Tracker


I almost by chance started to try out Pivotal Tracker. Originally I wanted to use no planing software at all. I have come to the conclusion, at least for my hobby projects, that the more you plan the less you actually do. The problem comes from the fact that when I see the mountain of work to do and miss a deadline that this can deal a final blow on my motivation.

But I found two things that were awesome about Pivotal Tracker. It allows you to easily reorder work. This is important since I tend to plan things that are not needed now or even ever. This gold plating can then simply be pulled out of the plan, when you notice that everything will take forever.

The second thing is that deadlines or rather milestones are estimated by the work already done and how much there is to do. Although you can assign a date to a milestone, there is no kidding you about the chance that you will make the milestone on time, when that is not the case.

Technology


I have a bone to pick with most graphics libraries that are available to me. They either make really simple things hard to achieve or lack focus and maturity.

Over the years I have amassed a large body of code that does most of what I needed. The only problem was that it was not packaged in an easy to use fashion.

I invested some time into building and packaging pkzo, spdr and glm. Not only do I now have usable libraries for rendering, sound and networking, I gained a significant productivity boost. I'm not trying to integrate unwieldy libraries that waste my time, because they do not build from the get go, they have weird intrusive interfaces or the setup overhead is huge.

On the other hand I did not rewrite everything from scratch. Being able to build upon awesome libraries like SDL and the companion libraries SDL_image, SDL_ttf and SDL_mixer really cut the development time in half.

Excessive Refactoring


One thing that I can simply not stand is ugly and bad code. This might be a character flaw, but I have given up working on projects because the code felt wrong. This time around I was determined to keep the code in the best shape possible.

It sounds easy at first, but some things just sneak up on you. For example, the class handling the menu logic went from being small and well defined to a huge jumble of special cases. But even here it was possible to break up the code and remove most duplication.

It takes severe discipline to refactor code. The problem is that it feels like you are making no progress at all while doing it. But it was worth the effort.


Attached Image: DaBoom-0.1.0-sc2.jpg


What Went Wrong


Lack of Discipline


We are all humans and it is often hard to muster the strength to do all the little tedious things. The project was on a great start, what what do you expect, this is my passion. But after the first two months went by I started to not put in the desired time. This was especially true that I also started to pick the interesting thing to do instead of the really necessary ones. It is interesting how much time you can spend choosing music when the game does not even have the means to play it.

Rewrites and Gold Plating


I am proud to say that I only rewrote the entire rendering and networking systems about one and a half times each. Although this is a record low for me it remains one of my biggest stumbling stones.

The first most obvious gold plating was that I migrated my rendering code from immediate mode OpenGL 2.0 to OpenGL 3.2. Although the old code was inefficient, it did fully and totally not matter. The scene is so simple that any decent PC is able to render it without breaking a sweat.

The second gold plating and unnecessary effort was in making the network system asynchronously multi-threaded. Although the networking code worked fine, the game logic broke in very subtle ways and I ended up falling back in synchronous single threaded code.


Attached Image: DaBoom-0.1.0-sc3.jpg


Technological Blunders


The biggest lack of foresight was the game logic and especially the interaction with the presentation layer. Although the two were weakly bound, through the help of an event based system, it turned out to be fatal when integrating the networking layer. The multi-threaded nature of the networking system indirectly forced the presentation layer to be multi-threaded. But as it goes with OpenGL, manipulating resources from multiple threads is not a good idea.

The real problem was that implementing mitigation strategies, such as call marshalling or locking strategies, were a significant unplanned effort. In the end I ended up calling the networking system in the main even loop.

In future designs I must think about multi-threading from the start, especially if I want to get the most out of multicore systems. Then again, on such a small game, this is a wasted effort.

Missing Features


Unfortunately I was not able to implement all features I wanted. These being notably character animation, scoring and AI. My focus was on the core experience and unfortunately I did not find the time and energy to implement them. I will maybe add them in on another go around.

External Conditions


On of the biggest dampers was my professional situation. Normally I am working 4 day weeks. This gives me at least one entire day to work on such hobby projects. But as the project at my day job approached its release date and things got a bit hectic, I worked 3 months for 5 days a week. This reduction in time meant that I could simply not get so much done.



About the Author(s)


Sean "rioki" Farrell is a professional software developer with a hobby of developing games.

License


GDOL (Gamedev.net Open License)




Comments
I noticed a few typos but all together a good article. I would love to seem more post mortems from small projects. Maybe you could elaborate on what pkzo, spdr and glm are?

 

I forgot to link to the libraries in the article, will amend it.

Congratulations on completing your first game! You have already achieved more than 90% of other hobby developers. ;)

First: you provide some good information on things to do right and things to not do wrong in the development of the game. The brevity of the article actually enhanced that.

 

However:

 

The title starts with "Post Mortem" which gives the reader an idea of the intent of your article. However, the introduction says nothing about what you're going to discuss. The introduction is where you should tell the reader what you're going to tell them.

 

Pivotal Tracking: it appears something was important to the development of your game. What IS it? The reader shouldn't have to interrupt the reading of the article to go googling for something that you could describe in a sentence or two.

 

Technology: Two sentences of rant before you finally say: "Good libraries for rendering.. gave me a productivity boost." I would suggest that, when you're talking about things that went right, start out with what went right. Also, I suggest you describe the libraries that helped you. Links are fine, but maybe more in the style of "... for rendering [ link ], audio [link].."  If not individually described, the links should, at a minimum, be in the same order that you discuss them.

 

Excessive Refactoring: Do you mean you avoided excessive refactoring? Honestly, I wasn't sure whether that section described what went right or wrong. E.g.,

 

For example, the class handling the menu logic went from being small and well defined to a huge jumble of special cases.

 

Not sure what you intend to say there.

 

As first mentioned, your experience provides some good tips for game development. Help the reader understand what those tips really are.


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS