Jumpgate started as an idea twenty-eight years ago. Soon, it will have been twenty five years that it is playable. And jumpgate-tri.org is turning 10 this year. For a lot of people, there’s just the satisfaction that the game can still be played after this long. But it’s easy to miss how with time, it is becoming less and less playable. If it is working for you, or has been, but you don’t play regularly or at all, you will easily miss all the instances where it is, in fact, not. I have seen many cases of players complaining about the game crashing frequently, and some accounts of it not running at all. The most common culprit, anecdotally, seems to be the station UI requirement that Jumpgate runs in 800x600 resolution, but also the way the game switches resolution between 3D and 2D rendering. There have been compatibility issues with newer Windows versions, with modern screens that don’t support 4:3 aspect ratio or lower resolutions very well. Jumpgate runs in compatibility mode and this brings its own set of problems. With every new Windows version, with every new graphic card, NVidia firmware and driver updates, there is a chance that something breaks, and the game will no longer run.
Jumpgate.exe, the game client, was last built on February 19th, 2011. Although the current maintainers, the admins of jg-tri, have shown efforts to patch the client, with two updates in 2014, those were only compatibility hotfixes. And then, there’s been nothing since 2014. I am not issuing any judgement here. The admins do not have the client source code, and without this, what one can do is extremely limited, and even then a tremendously painful process. But the lack of updates will slowly kill the game if nothing is done about it.
This article is about what I think can or should be done, what I have found and done myself, and where it can lead us.
What Jumpgate Is
Jumpgate is a Microsoft Visual C++ project. It was built as v 1.0125 with MSVC 2003 v7.1 and DirectX 8.1 SDK for the last time at 00:35:26, on Saturday, the 19th of February 2011, as can be seen in the compiled executable info. I cannot prove this but I suspect this is the last time Steve ‘Istvan’ Hartmeyer ran the build pipeline on the latest version of the client’s source code, in NetDevil’s now-shuttered headquarters.
After this, Istvan, LupinOne and others tried to get Jumpgate’s source code handed over to the community, but Gazillion eventually relented, citing concerns with third-party commercial code embedded in the source, which may or may not be the truth.
Since then, it is possible, or even probable, that the source code was lost. Without the source, one has to use a disassembler to peer into the workings of the compiled binary. Thankfully, disassembly has come a long way, and there is free software available that we can use to do this, such as IDA.
This is the ‘start’ function of jumpgate.exe, where it invokes the main application Window with a WinMain() call, as seen in IDA. IDA also tells us there are 2583 functions and 254 library dependencies in the client.
What we are looking at with IDA is assembly code (the result of compilation). Assembly is very close to machine code. It uses a small set of instructions referring to locations in memory, which is not a very practical way for a human to work on a complex program like a 3D video game. It is quite informative however to look around. 2,500+ functions may seem like a lot but it is a number we can comprehend and use to gauge effort, and progress. The code of Jumpgate was rumored to be “spaghetti,” “awful” or other derogatory terms, but so is most videogame code (generously) and it is, in some parts, quite legible, even in its assembly form.
For example, as I was working on my article on RRR buildings, I had a look at IDA to check my assumption that Refuelling depots are in fact in the game. It is pretty easy to locate code with some knowledge of the game by following symbols such as text strings that we know exist in the UI.
This first led me, by accident, into code that belongs to the POS implementation.
Although it is not what I was looking for, it was interesting to see this because it contains references to the unfinished Factory POS module.
After another attempt, I was able to locate the refuelling depot interactions code.
This part of the code deals with all the pinhole-tube buildings in fact, including ore depots. The graph for it pretty small and quite easy to follow. Of course not every bit I’ve looked at is nice and tidy like this, but it illustrates that Jumpgate’s code is not some totally unworkable mess of code. In fact, it is perhaps even surprising that the code has nothing much in the way of obfuscation. A lot of the code used to package and read messages about the game state is just there for anyone with a disassembler to see. Even if some parts do have spaghetti.
OK So What Now? Can We Have Patches?
From the disassembled binary there are two routes:
patching changes in the executable straight,
going back to source.
My initial project followed the first route. The idea was to add support for currently-unavailable resolutions that the 3D view could be coerced into rendering, namely 4K and native Steam Deck resolution. While this project stalled for reasons other than technical, I have come around to think it is not the best approach for Jumpgate at this stage, because it does little to nothing to ensure the long-term viability of the game client. I now think route 2 is what we need.
Route 2 involves recreating the development environment for the game client, using original compiler, SDK and library versions such as those I mentioned above. Following this, we will take the assembly code one piece at a time, and rewrite source in C++.
The first step, and what I have started on, is to rewrite the “start” function to the point where it invokes WinMain, and get it to display a blank window.
Following this, we will be looking at every single function in the client, understand it, and add it to our “blank window” executable. At some point, we’ll hopefully get the game to display the station menu, then one day, we’ll be able to switch to simulator mode, and perhaps even launch into space… and so on.
What Do We Get Out Of This?
If this effort completes, then we have new source, and we can rebuild the game client from source. It will not be the same source than NetDevil had, but if we do it right, it will be somewhat similar, and function pretty much identically, including bugs and all.
However, BECAUSE we have source code now, we can start getting serious about making improvements, fixes and changes. It becomes relatively easy to do simple client-side changes like adding an additional resolution option, or create an installer for the game client. We also can start making ambitious plans to enhance the game’s compability, perhaps by stripping DirectX rendering and replacing it with OpenGL (the way rvgl did) or whatever 3D rendering framework is trending in the 2030’s. We can ensure the game is able to run natively in Windowed mode, side-stepping the resolution issues, or even come up with a new method of rendering the station UI.
Note that we aren’t able to make big gameplay changes yet, because for these we’d need to update the game server binary too. We don’t have the source code for this either, but I am optimistic that IF we had a complete client rewrite, we could work with the admins of jg-tri and get a server binary rewrite project off the ground.
So We Just Leave It With You Then?
I’d prefer you don’t do that, no. I am not the person you need for this project, I am the person you have. This is my first reverse-engineering project and I need all the help I can get.
I estimate I am about 0.01% through this. It’s taken me about a month to get to this point. I’ll let you calculate a completion estimate yourselves from this, but we can look at it other (more optimistic) ways. As I move along and if I don’t get stuck or demotivated, or distracted, I’ll probably get better at this. Comparing with similar projects, if everything goes really well, it’s a reasonable best case that the project may complete in about 5 years time. Those of you who have done anything related to project management will have a chuckle at this point. It’s probably a good idea to take the engineer’s estimate and double it. Still, at this early stage, there is a very significant chance that the project fails and never comes close to completion. If it gets anywhere useful though, I promise I’ll share all I have. You can’t hold me to time completion estimates but you can hold me to that.
Here’s what can help make it happen faster:
If you are in possession of source code for the game client, even if it’s partial, even if it’s a demo or very old version, please get in touch!
Sample code from the work of NetDevil will help identifying original variable and function names and their purpose. There may be insightful comments and other information in there that can be related with the client binary and will make the rewrite work easier, faster, and more true to the original form.
If you would like to contribute to the rewrite
The following skills are useful at present.
Experience with reverse-engineering, e.g. IDA.
Experience with Assembly and C++.
Windows Game development experience, in particular DirectX and Direct3D.
Experience with Git, GitHub and build workflows for Windows games.
If you have any of these, again, please get in touch. This is a purely volunteer, non-profit project. I will work with you if you are willing to keep all the work open and published under an open license. I have no desire to technically lead the project, so if someone more experienced would like to drive, I will happily slide down into a simple contributor/padawan role. I am rather qualified in fields such as software project coordination and communication, so I will also happily focus on these, where and when it helps.
Why Would This Succeed Now If It Hasn’t Already (and other questions)?
I believe there were some concerns about the legal aspect of publishing and maintaining the code of Jumpgate. I’ve already posted about similar projects, and seeing how old this game is, and how many transfers of IP ownership occured, I do not think there is any reason for concern today. There are plenty of game preservation projects existing out there, some for games with much more valued intellectual properties than Jumpgate. Code for games from currently active and powerful game companies has been hosted and kept hosted. Because this project is a volunteer project, will never be for-profit, and I am willing to front it in a country with reasonable individual protections, I don’t think anybody will waste time or money contesting its legality. After all, NetDevil, 3DO, MightyGames, CodeMasters and Gazillion all tried and failed to make money off Jumpgate. None succeeded.
Another concern I’ve heard is about cheating. With published code for a client, there is nothing stopping someone from authoring a version of the client that incorporates an aimbot, for example. This is true, but also, anybody can use a disassembler today, or a debugger and a hex editor, and inject cheated data anyway. So I would not say this project changes the state of cheating in any meaningful way. On the contrary, if the project completes, we can start thinking about making updates to harden the game code against cheaters, which would be very hard now. On balance, I do not think these concerns hold much weight against the necessity of preserving the game so it remains playable by its community.
If you disagree with my take, if you have other questions or concerns, please share. It is my intent to keep this effort as open and transparent as possible. You should not expect regular updates about it, because it will take me a very long time to get anywhere useful with it (if ever), but in the absence of other information, you can assume it is an active project. And no, sorry, you are not getting Corvette-class ships this decade.
Amazing article dude.