Rewriting Onlink
by Steven NoonanMiah and I decided a few weeks back that the code that Onlink is based on is unmaintainable. The code is riddled with some pretty major problems:
- Poor design decisions
Every Person is also a Company? Why?! - “magic” numbers littered everywhere
One example: I tried changing the default values for the Date class to be one second past the UNIX epoch (1/1/1970) to allow for use of standard date functions (difftime, mainly). Unfortunately, this didn’t work too well when missions were generated, because other places determined whether the Date had been set or not by comparing the year to the old default (1000). So all the missions actually expired before they could be displayed, since they appeared to be over 50 years old. - OpenGL immediate mode
According to Alastair, immediate mode is deprecated. He’s been harping on me about using immediate mode for graphics code. Generally speaking, he’s right to harp on this. In most cases, immediate mode is much slower than using the logical alternatives: display lists and vertex buffer objects. It’s also a lot harder to code without immediate mode. But we’ll work through this over time. - Bizarre problems that can’t be easily or immediately identified
The current save issues with Windows XP, for instance. - Licensing issues
It’s difficult to get contributions to the project when every developer has to have obtained the Uplink Developer CD [legally]. It just makes sense for this to be an open source project instead.
Long story short, we’re sick of maintaining code that is unwieldy. It’s time for a proper rewrite.
So on July 22, I started working on Codename “Cerberus”. We have decided that keeping the name “Onlink” anymore is inappropriate, since this is no longer just a mod of Uplink. We don’t know what we’ll call it yet, but for the time being, it’s just “Cerberus”.
I basically took the ARC++ code base, ripped out anything ARC-specific, and started coding on it. My first job is to come up with a decent interface. Miah and I asked the community for suggestions, and we saw some pretty interesting ideas that we may integrate.
Miah and I decided that we needed to start off with a few bullet point goals for the project:
- Fast
We want to keep slow code out of our project. We don’t want to cut corners and use poor code, even if it saves on development time. We want to focus on the long-run. Maintainable, high-performance code. - Customizable
We’re going to try to make pretty much everything configurable. - Intuitive
Everything should be easy to figure out and learn, especially for people who haven’t even looked at Onlink before. Following in the footsteps of the developers at Valve, we want to make the game teach the player how to play as they play. Hopefully, you shouldn’t need tutorials or manuals to figure out what you’re doing, if we do this properly.
We have more than that, but we don’t want to give away our content concepts that we’re working on.
Also, Miah and I will be discussing open source licenses for Cerberus sometime between August 29th and September 3rd, and we’ll hopefully be able to publish some code at that point.
So within the next couple weeks, we’ll be posting several different screenshots and user interface demos, and hopefully get some comments and suggestions. Subscribe to this blog’s RSS feed to keep tabs on this!
Stumble it!
August 16th, 2009 at 1:40 pm
Please do an effort in trying to fix the WinXP problem first )-:
October 28th, 2009 at 1:38 pm
i’ve some experiences on “unmaintable code rewriting” or starting completely over (… some of this code has been written by me a long time ago, though
).
what’s the current status? will there be something open source-like? possibility for others to help on writing the code / fix bugs to speed on coding?
January 26th, 2010 at 8:33 pm
I had a couple of ideas about onlink/uplink that I wanted to throw your way, you mind shooting me an email at xje…@gmail.com