Dad Strength is a comedic beat ‘em up video game modeled after old-school titles such as Double Dragon and Final Fight. In this postmortem, the game’s development process will be examined in depth. Dad Strength was developed over the course of two years, and luckily a developer’s diary was maintained throughout this time.
When building an executable under Microsoft Visual Studio (either the 2005 or 2008 edition), an accompanying manifest file is generated. The purpose of this file is to describe various dependencies of the executable such as DLLs. The manifest file is typically baked directly into the executable itself, but alternatively it can exist as an external XML file. In externalizing an application’s dependency information, developers can explicitly control which versions of the dependent files are to be used. One major benefit of this design is that various versions of a dependency can exist simultaneously (Side-by-side assemblies as Microsoft calls them) and thus different programs need not use the same version of the dependency files. This is a great idea in theory as it would eliminate the problem of keeping system DLLs in sync, a process affectionately known as DLL Hell. However, there are still a few quirks of manifest files that can drive developers and users alike mad. (more…)
While developing a humble beat ‘em up game (an homage to such classics as Final Fight and Turtles in Time), I found myself in need of a way to organize various scenes. The game would start with a loading screen, transition into a short narrative, and finally cut to the title screen. Once the actual gameplay began, another scene would be needed to keep track of the entities, images, sounds, and other game-related objects for stage one. In keeping with the ethics of object-oriented programming, I decided to make the scenes themselves objects by creating a scene entity with methods for loading, activation, deactivation, and unloading.
Lately, I’ve been wondering if I haven’t developed a bit of ADHD. I have a handful of game ideas that I want to explore and the list keeps growing. The problem I’m facing is how to choose the best ideas and spend time turning them into projects. When I completed the scene entity (which took very little time), I made the decision to design a small game to test its usefulness (which took much more time). It turns out that the scene entity has very little to do with the final game, yet I am left with something much more satisfying. (more…)
SFII90 - C++ and Ruby Video Game Engine
My name is Phillip Weisberg and I’m a software developer in the Washington, D.C. area. Welcome to fiber-optic megawatts! This blog will focus mainly upon video games - from reviews through development and anything else along the way. Today’s topic is SFII90 - a free video game engine that I developed in C++ and Ruby and licensed under the GNU LGPL 2.1. Before I jump too far ahead, let me first give you a little background about myself and the how the engine came to be.
I’ve always been interested in designing and producing video games. I made a few demos in 2005, but I wasn’t satisfied with how horribly inefficient they were; There was almost no reusable code nor consistent design from game to game. I looked at the top ten or twenty engines available for hobbyists and for some reason or another was not satisfied with any of them. I thought it might be a good idea to create my own video game engine (despite some foreboding comments on www.gamedev.net), so I started by designing a small system that could draw sprites from bitmap files and load OGG Vorbis files. It was… better, but still not very good. (more…)