21 April, 2016
One of the most important and ironically most overlooked area of game development is tools. Tools are incredibly important because they enable game developers to create content for a game. In MMOs, this is especially vital because an MMO often lives or dies by its ability to create content ongoing; an MMO without new content gets stale. In single-player games, tools can be refined and shipped with the game to give the game longevity from players who will continue to create content for the game, keeping it fresh for a group of enthusiastic fans.
Let’s take a look at the importance of tools in games.
The junior programmer for the job
I’m hard-pressed to think of a senior game programmer who has made a career of developing tools for games. Tools programming is often seen as unsexy and usually given to junior programmers, where more senior programmers tackle the more sexy parts of game development; graphics, gameplay, networking, etc. Because of this attitude, you often get tools that may not be quite what the project needs; but the end up being what the project gets.
The problem here is that some games, particularly MMOs, really need good tools. As I said above, MMOs often live or die on their ability to create new content for people to consume. If the tools don’t allow you to create the content, then you have a problem.
Of course, the tools programmer is only part of the equation. The people using the tools are also important to the process.
The right person for the right tools
Understanding who is going to use the tools is another important step in building good tools. If tools are going to be used by other programmers, for example, you might be able to get away with a more programmer-centric interface. For example, a command line tool might fight perfectly into a programmer’s workflow, where they already use other command line tools and may want to write scripts to automate use of the tool. But, for an artist or non-technical programmer, a command line tool will often require a lot of extra support if that tool doesn’t fit neatly into the existing tools that person already uses.
When creating tools for non-technical people, it is important for the programmer creating the tool to understand how to balance the needs of the tool user with the needs of the rest of the game. For example, if the tool is going to take input from a designer and populate a database with data, then the tool needs to understand the needs of the designer and balance that with the requirements for the data in the database. In an MMO, there may be requirements for efficiency in reading from the database in order to get the data from the database to the game server and/or packaged as resources to be shipped with the client. It can seem unfair to saddle a junior programmer with this task if they don’t have a lot of experience in design and the technical requirements of the project.
The other thing to keep in mind is that although you should think of the tool user as your “customer”, the customer may not always know exactly what is needed. For example, it’s there’s a tradeoff between ease-of-use and power in software; as something becomes more powerful, those additional options and customizations come at the expense of making the system harder to use. So, a tool user might say they want a lot of power, but when faced with all the options and customizations they may find themselves unable to easily use the tool to do what they need to get done. On the other hand, a tool that is easy to use but restricted may simply require more programmer time to let the tool user do what needs to be done. But, as features are added over time, the tool may start to get hard to use.
The right tools for Meridian 59
M59 is open source these days, so you can go look at the tools we had available.
The main “tool” we had was the scripting language called “Blakod”. I wrote about Blakod before, so you can see a bit of how it worked from my point of view. The main server itself was essentially a socket manager, a timer tracker, and language interpreter; almost all the gameplay was implemented in the scripting language, which worked well for me. I have a background in programming, so I was able to use the scripting language (with its command line compiler tool) easily enough. I was able to adjust most of the existing code to fix bugs and add plenty of new features over the years I ran the game. The system was fairly flexible and I only found myself wanting to add more deeper changes to the server a few times.
There was also a tool for level layout. This was based on an a freeware DOOM editor; the graphics engine was an implementation of the same rendering engine that DOOM used. This worked fairly well, but it did create a tool that was hard to use. Particularly after M59 added slopes to the game, the tool became even harder to use since the original editor had no concept of slopes. In the end, my old business partner at NDS was one of the few people able to use the tool effectively.
There were also some tools for art, but I know almost nothing about those. M59 used sprites with views from different angles and different frames of animation, so there was a tool to coordinate all that. There was also a tool to handle placement of images together; this was used for the player characters in the game, where you could assemble different facial features to create a unique face. We didn’t add much art to the game during the NDS era, and my former business partner mostly handled that side of things.
The right script for the right behavior
I’m a big fan of scripting languages. One of the most useful classes I had in university was one the professor claimed might be useless: a class on compilers. In the class we implemented a simple compiler for a subset of the then-new language Java. I learned a lot about how computer languages worked. I grew to appreciate scripting languages, particularly when I started using Blakod while working on M59.
There has been controversy about the role of scripting for designers, as I wrote previously. The main complaint is that designers don’t often have the understanding of programming issues that a programmer would have, and scripts they write may cause performance issues. I will say that for M59, I rarely had to pay much attention to efficiency issues. Of course, when I worked on the game we were using gigahertz processors with gigabytes of RAM, whereas Blakod was designed using RISC philosophy according to the documentation and the original server was designed for processors measured in megahertz with RAM measured in megabytes. Applying more programming discipline to the design and and implementation of the scripting language could alleviate this.
But, of course, that type of focus can be expensive. When we talk about implementing a scripting language, this is usually in the context of embedding an existing language like LUA or Python. This means less upfront work, better tools, and better support/training, but it means that any issues with the specific languages need to be addressed in development.
The right tools for your team
Hopefully you’ve come to appreciate tools are an under-appreciate art form in game development. Good tools take a lot of work and collaboration. And, I didn’t even touch upon how much more work goes into making great tools for non-game developers to be able to add content to a game.
So, let’s hear it for the good tools programmers out there! They keep your favorite games going.