Toolin' around



In the year 26,000,0XX BC...

A man stands victorious over a kill.
It was a tough fight, but the prize of food was well worth the effort.
In his hand...

A blood-stained tool.

A lot has changed since then. For example, many of the modern programmer's tools aren't blood-stained!
Tools are essential to all of us. Whether it's the IDE you use, the text editors and command shells that facilitate your work, your calculator, Wikipedia, online forums... They're all exceptionally useful (and sometimes, indispensable) tools. Whether you're making side-scrolling games, RPGs, or FPS games, game development tools exist for you! There's stuff like Game Maker, Allegro Sprite Editor, Mappy, Blender, and much, much more.
As your games get more and more advanced, however, generic tools become less and less useful. Eventually, you reach a point where your existing tools either become increasingly inefficient at what you need them to do, or cease being useful altogether.



What do you do when you need a tool so specialized,


that it doesn't exist?

For the programmer, there's a solution. We simply make our own!
I've made many tools over the years to help me make games. Here's an overview of some.




This is an old one, simply titled "AnimationMaker." It loads images or image sequences and allows you to play and save them as animations. You can also adjust the length of each frame, to time it to your liking in-game. It's a very bare-bones program, and was made about three years ago when I was learning Allegro and C++. It has extremely limited use today- the functionality that an animation needs is more than the AnimationMaker can offer. For example, an animation needs to know whether or not it's looping and whether it's playing or stopped when the game creates an instance of it.
There's your first lesson.


If you're going to make a tool,

Make sure it does everything you need it to do.

The AnimationMaker is like a screwdriver that only turns one direction, and doesn't have an interchangeable blade. It's completely outdated- not only has my animation format changed, but it has also evolved to require more data. Data that the AnimationMaker simply can't provide in its current state. Really, I should have recognized that animation states would be necessary things to have. Oh well.




Guess what this one's called. Here's a hint: it makes maps. That's right, this one is MapMaker.
Also made with C++ and Allegro, this one is my first attempt at putting something together that can help design levels. It can load and swap tilesets, change map size, and... that's about it. You can scroll the map with WASD and pick and place tiles from the tile selection window.
Primitive? Yes.
Useless today? Also yes.



If you're going to make a tool,

make sure it's as future-proof as you can make it.

MapMaker is great, but there's one teensy little problem. You can't place anything but tiles.
That's right. No objects, no player, nothing. Instead, you load the map and hard-code the objects in your game. Obviously, this is a terrible idea. Not only do you have to recompile the program every time you want to test enemy placement, but it also makes it a lot harder to edit.
(Let's see... was that enemy I wanted to delete the one made with spawnEnemy(650, 120), or was it the one made with spawnEnemy(660, 110)?)
Not only does this tool fall prey to the first mistake I mentioned, but there's no possibility to re-use this in later games! Not only does it lack core functionality for a "MapMaker," but it also presumes that the game we're making is tile-based. What if I was making another kind of game?




This one, dubbed "LevelEditor," was a major improvement over MapEditor. The most obvious change? Objects!



With editable properties! Now we're talking with fire. This one is actually useful! It can load tilesets, place objects, and give objects custom properties. You might have noticed, however... that we're missing a few features. Where did map size and map name go? You guessed it- we can no longer scroll the map, either. The LevelEditor was actually made for a SpeedHack entry in 2009 titled ClothesQuest. Given the nature of the competition, I didn't have time to give the LevelEditor the polish it deserved. But it's good at what it does! It can make Zelda-esque maps, no problem.
So where does it fall flat?

First of all, it lacks features found in the previous MapEditor. That's a big no-no. We should never be taking one step with our right foot and two steps back with our left. Unless we want to turn awkwardly, or if we're playing DDR.



If you're going to make another iteration of a previous tool,

don't eliminate necessary features.

This is a pretty obvious issue. If we keep adding features in future iterations while losing features from previous ones, eventually we'll have a tool that deviates so far from the initial vision that it does virtually nothing we want it to. Is LevelEditor usable today? Yes and no. Without the ability to scroll the map, it's fairly useless outside of Zelda-esque games. We're still lacking the ability to freely place objects, so we're limited to tile-based games. Not to mention, the tiles are a fixed size. No room for growth here.

Before I get to my latest tool, here's something that I worked with a couple years ago.





This might look familiar if you're into 3D design. Yep, that's Blender! It's what made most of that stuff in my art gallery.
This is one of the alternatives I looked at, instead of making my own tools. I had no idea how to parse Blender's native *.blend file type, but fortunately, I remembered I had an AC3D model loader that I had already written. Since Blender can export AC3D format files, it's no problem! Right?
Well, let's look at the positives. Blender is perfect for a vector-style retro game. It's a modeler and level editor rolled into one. Plus, since it's a vector-style game, the output from Blender doubles as collision data, which was awesome. Since I'm quite familiar with Blender, there was no learning curve. But it was far from perfect for what I needed. Again, there was no easy way to add custom data to the map. See those vertical black lines in the Blender window? Those are enemies. (I killed them in the game's screenshot.) There wasn't any way to tell my game what type of enemies they are, so their type is packed into their Blender object name. (There may be a way to do this with Blender's format, but remember I was working with AC3D.)

Using Blender reaffirmed my idea that I need a tool that's built for me. Versatile, powerful, and designed for making games.




(More screenshots)

This is ObjectMaker. Because it makes objects, I guess. This is a tool I'm currently developing to rectify all the problems I've had with all my previous tools.
You might notice that it looks a little like Blender. Because I'm quite comfortable with Blender's environment and tools, I made ObjectMaker function in similar ways. You can use the mouse wheel to zoom, the middle mouse button to pan the view, right click objects to select, and press space to bring up a context menu. Like Blender, G grabs objects, R rotates them, and S scales them. You can also scale on the X and Y axes, if you want!
Already, we've got some major improvements here. Not only are we free of tiles, but we can freely manipulate objects in any way we want. This is just a start- soon I'll add functionality to add buttons (for GUIs), change object properties like alpha and velocity, and add custom properties like collision type. I also plan for a way to be able to import objects that have already been created with ObjectMaker. So I could create an enemy, give it custom collision data and properties like HP, damage, cooldown, etc., and add it into a level I'm making with ObjectMaker.
As for the level itself, you'll be able to add custom collision data and overlay it on top of the level graphics. I'm also working on particle systems and physics. Needless to say, this is going to be one awesome tool.
Later, I'll add even more functionality, like editing animations, managing events, and more. Not only is ObjectMaker future-proof in that it'll be able to handle virtually anything a 2D game needs, but it will also be complete and extensible to handle future technology my games might require. (Fluid dynamics? Polygon vs polygon collision? More?)

ObjectMaker is my 2D game-making pocket-knife. It has everything I need, in just the right amounts.



If you're going to make a tool,

make your very own pocket-knife.