Highway to the Moon Postmortem – What Went Right: Tool Centric Design

Highway to the Moon is actually made up of data generated by tools that is then run by an engine. This means that without this data, the engine does nothing. This set up allowed non-programmers to work on many parts of the game that they would not have been able to work on otherwise.

The tool suite itself is composed of three primary tools, with a few secondary tools to perform simple but otherwise tedious supporting tasks. The three primary tools are the Enemy Editor, the Road Scriptor, and the UI Editor.

The Enemy Editor is used to create the majority of the various types of data files used in the game. It allows us to edit graphical files, physics files, AI files, and enemy files. Things are broken down into fairly small pieces, which allows for reuse. It is particularly notable for its powerful AI editing functionality, something I’ll go into greater detail on in another post. Suffice it to say, however, that enabling non-programmers to be able to create complex AI was very beneficial in the creation of the game. Furthermore, various other pieces of data were much easier to create thanks to the editor’s visual representation capabilities.

The Road Scriptor’s primary use is creating the road. It handles various aspects, such as graphics, physics, enemy placement, and parallax information. Finally, and very oddly, the player sprite is made in this tool. Perhaps the most useful feature of this tool, though easy to overlook due to its apparent simplicity, is the “Physics Button.” This is a button that, when pressed, calculates the physics boxes used for the road. This saves the level creator a great deal of time, as it relieves them of the effort required to manually place all of the physics boxes for the level. The tool also streamlines the process of making levels by having all of the necessary functionality in one place; this proximity makes it much easier to transcribe ideas from one’s brain into game-ready implementations.

The final of these editors is the UI Editor. It is primarily used to define user interface elements in the form of UI screens and the HUD. It is also where certain Super Special Options – used to define behavior for the Reality Alternator – and achievements are created. Finally, it is where the all-important Masterfile is defined. This file informs the engine about many static details for the game, and is the launching off point for behavior. In short, it is the entry point for the game. This tool helps a great deal when creating UI screens in particular, due to the ability to see the layout without having to run the game. It also makes balancing playable characters an easier and more streamlined task.

The focus on tools, and making a solid tool suite, has helped make many tasks not only easier to do, but also more accessible. On the first point, it made small tweaks and rapid iteration easy to do – these helped greatly with feeling things out for the game – and also reduced the tedium of repetitive tasks. Increased accessibility is also very notable, expanding the number of tasks that individuals could work on. Allowing designers to work on behaviors without having to rely on programmers to implement them, including designers with minimal to no coding skills or knowledge, greatly increased efficiency and turnaround times. Overall, the effort required to make the comprehensive tool suite was worth it for increasing accessibility and efficiency for the entire team.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s