Game Design, Programming and running a one-man games business…

Making actual tools

cliffski

I know that editors and level tools are part-and-parcel of most game development processes. Most games companies have at least one full-time tools programmer, who will work 8 hours a day for a year designing, coding and supporting the tools made to build the game. However, when you are a one-man-band, dedicating that amount of time to tools just isn’t viable.

There are several solutions. You can try and hit the happy medium where you spend enough time to get usable tools, but don’t let it eat too much into your schedule. You can produce really good quality tools that make game production a breeze, then realise you have not got close to finishing a game and you have to go get a day job again… Or you can just hack everything in manually using notepad and excel and worry about it later.

I’ve traditionally chosen the last option. I hate MFC, which is the ‘language’ that tools used to be built in, and I’ve never learned java or C#, which is what people often use now. That means that when I coded the few tools I use (like my particle-engine tool), I hand code them in C++ just like the games GUI. This takes ages.

Until now, I’ve been manually editing text files for the spaceship data. I have a master spreadsheet with lots of the data in, to make balancing easier, but there is a lot of manual staring at paintshop pro and memorizing pixel positions to type into notepad. Clearly this is mental.

So this weekend I made my very first steps towards a proper ‘spaceship-hull-editor’ for the game. This is still a makeshift hacked tool which won’t ship in the game, it’s just a quick tool to make it easier for me to tweak some of the graphics data, such as placing particle emitters for burning ship hulks. It’s a small step in the right direction I guess.

In non-tools news, I’ve been fixing a lot of very minor graphics glitches, the odd disappearing piece of debris or mis-aligned laser blast, or slightly crappy looking tractor beam graphic. The game is looking quite nice. Next week will be geared towards some online-integration, and some general gameplay code.

3 thoughts on Making actual tools

  1. Yeah, MFC sucks. So is that what you’re using after all? You could give C# a try. The Express edition is a free download and I don’t think it would take much time to get into it.

    It’s a blend of nice C-like syntax with garbage collection, tons of documentation, flawless drag & drop GUI designer and great library support. Intellisense tells you much more than in C++ so you essentially learn any API on the go by pressing ctrl-space. Integrating with native code is also quite straightforward.

    I used it a while ago to make some tools and although I started with a similar view as you (quick’n’dirty, makeshift tweaking utilities) they quickly evolved into pretty solid editors. And I actually enjoyed it.

    Example: http://www.catnapgames.com/blog/204

  2. I second Tom’s suggestion to try C#, it’s very easy to learn for a c++ programmer and creating GUIs is a snap.

    If you’d rather stay with pure c++, take a look at QT. It’s a real pleasure to work with and it also has a handy OpenGL widget.

  3. C# garbage collection only works if you don’t use classes that need resources. Otherwise you have to do the MyInstance.Dispose() all by yourself like in C++. And if you derive from those classes you inherit the fraking .Dispose() – greatness! If your code depends on destructors – forget that – C# theoretically has destructors but they don’t work as in C++.

    But all in all it’s way easier than C++ with all the includes, libs and such… ;)

Comments are currently closed.