A journey of 33 steps detailing thoughts, methods and tools used to recreate this classic game
Overview
Traffic Department 2192 is a top-down action shooter notable for colorful characters led by anti-heroine Marta Velasquez. The story unfolds over 59 missions as Vel and the Traffic Department team stop the Vultures from dominating the planet.
TD2192 is a game that I’ve played through quite a few times since it’s its initial release back in 1993. It remains a rare example of how excellent writing can carry a game. While the gameplay is dated, the characters and their story are timeless.
Project
This project started as a personal question of just how fast the programming portion of commercial title from the early 90s could be done using 21st century tools. The answer: fast! Combining reverse engineering with commercial game engines reduces the effort to a matter of days for one man. Naturally, we side-step the time-consuming and costly part: asset development.
Although the game itself and programming effort is unremarkable by today's standards, I decided to make this education for beginning developers. There's a lack of tutorials for projects of several thousand code lines that involve using many tools to bring together the final result. My goal is to document the effort and make the journey as instructional as possible. Happy learning!
Playable prototype in HTML5 -- (Play)
- Represents our work as up part 33 of the video series
- Framework complete, but content limited.
- Mission 1 is fully scripted — Remaining missions default to “destroy all ships”
- Briefing sequences complete through mission 5. No dialogue sequences afterwards.
GitHub repository -- (View)
- Includes the prototype source code in GameMaker
- Has the C and Python utilities we build to analyze and extract assets
- Also hosts the HTML5 build, but use the above link to play
Video series
Each video has a 15-30 second introduction. Here is a 13 minute preview video of all the introductions put together.
For all the project parts linked below, click on the title to go to the project page or click on the thumbnail to go to directly to the YouTube video.
| A short overview of the project highlighting the main development arcs, suggested prerequisite knowledge for the target audience, and my personal approach to the project.
- No tools are used in this segment
|
| Video runtime: 1:58 |
|
|
Playing through a single mission of traffic department to identify features, systems, and game flow that supports game design. We’ll write down observations to better understand what needs to happen over the course of a game
|
| Video runtime: 14:15 |
|
|
Digging through through the game files distributed with the creative commons release of TD2192. We’ll try to figure out what kind of files we’re looking at and how to approach taking them apart
|
| Video runtime: 12:39 |
|
|
Exploring the SCR files distributed with TD2192 in order to discover their format and convert them to bitmaps. We’ll build a C utility to extract the bitmap and use it as a springboard to the next few file types.
- Hex Editor
- Powershell
- GIMP
- C Programming
|
| Video runtime: 21:04 |
|
|
Exploring the Faces files distributed with TD2192 in order to discover their format and convert them to bitmaps. These files complicate the SCR file by adding multiple images per file.
- Hex Editor
- Powershell
- C Programming
|
| Video runtime: 12:40 |
|
|
Exploring the BLK files distributed in order to discover their format and convert them to bitmaps. BLK files are similar to Faces files except they have no embedded palette.
- Hex Editor
- Powershell
- C Programming
|
| Video runtime: 8:36 |
|
|
PIC files take more work since they’re all different. Disassembler to the rescue!
- Hex Editor
- Powershell
- IDA Pro
- C Programming
|
| Video runtime: 24:09 |
|
|
We’ve learned all we need to know to pull out these assets. Let’s put together all we’ve figured out and knock these out quick!
|
| Video runtime: 1:09 |
|
|
The menu graphics are packed in to a texture sheet-like archive. We see signs that it uses color cycling to simulate animation.
- Hex Editor
- Powershell
- C Programming
|
| Video runtime: 7:54 |
|
|
Font assets are simple sprite fonts, not vector curves. We can use the same strategy for extraction that we used on the regular graphics assets
- Hex Editor
- Powershell
- C Programming
|
| Video runtime: 7:05 |
|
|
The Map files don’t conform to any standard except that of common sense. We’ll make use of that to understand how the MAP files work for our prototype.
|
| Video runtime: 5:13 |
|
|
Dialogue files also have a custom encoding and have a more complex interaction with the game that we’ve seen so far
- Hex Editor
- Powershell
- Python
|
| Video runtime: 8:24 |
|
|
The Mission files are the most complicated archive in the original Traffic Department. Understanding how these files work will allow us to accurately recreate the mission setups.
- Hex Editor
- Powershell
- Python
|
| Video runtime: 16:49 |
|
|
We’re going to defer capturing the sounds and music from the archive to 3rd party tools. Doing this manually might be a separate project for another time.
- Hex Editor
- DosBox
- Audacity
|
| Video runtime: 7:43 |
|
|
Our first look at the GameMaker engine and the features we’ll use to prototype Traffic Department. I'll only use a small subset of engine features, but I'll rely heavily on the resource manager and GML script.
|
| Video runtime: 9:48 |
|
|
The first prototype steps are to set up the five rooms we’ll use in the game. We’ll also identify three objects that provide services across all the rooms and the entire game.
|
| Video runtime: 11:38 |
|
|
The first room in the game contains the easiest of several challenges in event management. We’ll build a simple finite state machine for handling user input to drive the introduction sequence with custom markup controls.
- PowerPoint
- Powershell
- IDA Pro
|
| Video runtime: 12:37 |
|
|
Implementing our model of the introduction in GameMaker. We import fonts, add scripts, custom markup, and two objects. Nothing works the first time so we spend a few minutes debugging.
|
| Video runtime: 26:26 |
|
|
We take a different approach for the main menu design than was originally used in TD2192. We ditch color cycling for backlighting. We divide up the main menu tasks between three objects.
|
| Video runtime: 7:43 |
|
|
Implementing our main menu design in GameMaker. We hit several bugs along the way that we clean up before moving on. The results are very close to the original.
|
| Video runtime: 22:55 |
|
|
The (de)briefings are arguably the most interesting part of the game for the player. For the developer, it will be the most complicated task so far. We’ll build a design that incorporates the dialogue we previously extracted alongside modules to display the SCR and PIC files.
|
| Video runtime: 11:32 |
|
|
The longest segment of programming featuring all the tedious parts: Data extraction from binaries, interpreters for dialogue files and storyboards, and a parser. Our implementation of the dialogue leaves a few things to be desired, but remains faithful to the original game. It’s all downhill after this!
|
| Video runtime: 32:28 |
|
| Missions are by far the most complicated part of our design. Fortunately, the overall simplicity of the action brings this within reach in one (long) design video. Prepare for death by PowerPoint in the name of design.
|
| Video runtime: 18:16 |
|
| Getting the game world loaded is our first chore. We’ll make some changes to the source map file and discuss the finer points of the memory usage / processing power trade-off
- C Programming
- Hex Editor
- Powershell
- GameMaker
|
| Video runtime: 14:43 |
|
| It’s difficult to play a game without a player ship. Collisions are usually a touchy subject, but the constraints of the game design allow for a simple solution. We’ll also experiment with bit fields to capture multiple ship actions in a single variable.
|
| Video runtime: 22:37 |
|
| A world without friends and foes is a boring world. Let’s fix by by loading them from the mission file and give them a default behavior.
- C Programming
- Hex Editor
- Powershell
- GameMaker
|
| Video runtime: 16:25 |
|
| The HUD concentrates game data. We have to efficiently pull and display multiple sources in every frame. The minimap and direction finder are especially interesting. This will take some debugging.
- C Programming
- Powershell
- GameMaker
|
| Video runtime: 22:25 |
|
| Enemies are more fun when they actually respond to you. The trick is to find an AI that provides some challenge without completely dominating the player. Warning: A* algorithm incoming.
|
| Video runtime: 20:12 |
|
| A playable prototype requires some kind of default goal in lieu of actual mission scripting. The easiest solution is to force the player to destroy all hostile ships. Let’s make that happen
|
| Video runtime: 11:29 |
|
| The default mission is ok, but now we need the ability to script actual missions and goals in to the game that support the storyline. We’ll hack in the first game mission for now
|
| Video runtime: 6:30 |
|
| The joke is on us – we already designed the mission debriefing back in part 22. Now we just need to add a little more code to close the loop.
|
| Video runtime: 12:30 |
|
| We have something that looks very close to the original game. Possibly a bit too close. Let’s take advantage of 21st century technology and open up the window. While we’re at it, we’ll make a way to skip the action and watch all the dialogue sequences.
|
| Video runtime: 8:58 |
|
| The prototype works! …and we’ve nail down the scope of our final product including new enhancements. If we wanted to continue on with the prototype, we’ll discuss what needs to happen to make it a complete remake. Or, the design is ready to be dropped in to your own custom engine using your framework of choice. C and SDL anyone?
|
| Video runtime: 12:19 |
|
Other Links
- gekk.info project - Another project to extract TD2192 mission scripts using Python. Uses some of my work and adds thoughtful notes about tackling reverse engineering projects.
FAQ
Why did you pick Traffic Department when you could have picked [some other game]?
A perfect storm of coincidence. Traffic Department is one of the games from younger days that I tend to pick up every few years. After a good round from early July 2016, I found this blog by a guy named Earok who aborted an otherwise impressive attempt to remake it. I wondered about how much effort it would take to make a working prototype. A few weeks later, I had an answer. So the real answer is that I didn’t choose the project, the Internet made me do it.
How long did it really take?
The playable prototype took between 30 and 40 hours across two weeks in late July/early August of 2016. Probably two of the days were off. The work flow of the video series follows my actual effort almost perfectly. My best detailed guess is:
- Day 1: Asset Sprites
- Day 2: Asset Maps
- Day 3: General time-wasting on disassembly
- Day 4: Sound & Music including several false starts
- Day 5: OFF
- Day 6: Introduction
- Day 7: Main Menu
- Day 8: Briefing (and 95% of debriefing)
- Day 9: OFF
- Day 10: Mission gameplay
- Day 11: Mission AI
- Day 12: Mission scripting
- Day 13 & 14: HUD and general tweaking
I then did some general work with a custom engine implementing the prototype. I don't intend on finishing that unless there's a larger community interest. Putting together this website and videos took me far longer than actually making the game. I started recording the creation of a second prototype three weeks after finishing the first. Almost no logical refactoring happened between the prototypes (mostly variable name changes and code consistency for clarity's sake). I posted about 2 videos per week between September and November, 2016. The code is very much in a 'first-pass' state.
Is this really a beginner programming project?
Absolutely. Throwing a modern game engine at a 25 year-old game is like pushing in a thumb tack with a sledgehammer. Casual knowledge of data structures is about the only thing you should need to know. Knocking out a project like this in a reasonable amount of time depends on tool-specific experience and your ability to pull an appropriate solution out of a hat. The largest hurdle blocking new programmers is sitting down and focusing on the work itself. Many of the more specialized points I demonstrate, like disassembly and asset exploration with Python, are optional.
Why didn’t you use [insert game development paradigm] in this project?
I probably didn’t think about it. If I did think about it, then I concluded that I didn’t need it. I didn’t prioritize code reuse at all since I don’t foresee extending or even revisiting the project once it’s complete. Maintainability is an afterthought.
Hey! The prototype isn’t finished! Why don’t you add the other missions?
That’s right, the framework is complete, but the content isn’t all there. I estimate the effort to make the prototype a full beatable game from part 33 of the videos would take another 10 to 15 hours of concentrated effort in scripting the individual missions just like I demonstrated with mission one. Getting the remaining dialogue sequences in there would probably only take about 2 hours. I’m debating if I want to simply brute force it or dedicate another part to extracting the goals directly from the original binaries. In any case, getting the full content in is the final step. Since there isn't much learning to be had by repeating the last video, I leave it to the folks that find this project. I don't actually expect this version to replace the original in any way.