AllTinker

Yeah so life decided to do its thing and blow up in my face not that long after my last post. Losing my job and my house were the main highlights... But I'm still not dead so there is at least that. Happily things are approaching pleasantly mundane again though, so I'm hoping to resume hobby project stuff ASAP! As far as progress goes: I've implemented a first pass at collisions/physics, I basically just need to implement the elevators now on that front. The driver cabin is mostly functional (e.g. radar, steering wheel), and I dropped in an optional full-screen (no cabin) mode too. The basic vehicle AI/path-finding is essentially done, but I haven't implemented any combat/mission-specific behaviours yet (e.g. bosses). I'm using the same engine for other projects (hobby+commercial) and it's undergoing a bit of a refactor at the moment, but I'm hoping that won't take much longer. As for the bigger picture I'm wondering if I'll have two modes - original and custom - where the former will recreate the game more faithfully, and the latter will be balanced to be fun for the long haul through the whole story (i.e. avoid the frustrations Ross discussed in his episode). Either way I'd like to implement numerous options to tweak the experience. Regarding dumping the levels to .OBJ format - that's definitely doable. My engine builds a texture atlas for each environment on the fly so I could also dump those out. The main issue is how much of the level detail comes from billboard sprites, which can't really be represented in .OBJ in a useful way. Perhaps I could dump out the object data in a different (e.g. CSV) format...

Eventually I'd like to do just that, be able to render out a nicely anti-aliased (8K?) shot with all five maps loaded at once with proper roofing etc. But for now here's some quick'n'dirty previews with no culling/distance fogging... Kemo City: The Park: Old Town: Note that this map actually has quite a few blocks with proper roofing since it has bridges where you can see (and fall) down onto them. The Projects: The Wharf:

Hmmn good question; if each pixel in an isometric screenshot corresponds to one pixel of wall texture, some quick math suggests the levels would be something in the order of: Kemo City - 101888 x 32256 The Park - 51200 x 51200 Old Town - 37376 x 32256 Projects - 51200 x 39424 The Wharf - 100864 x 29696 This is based on each wall (i.e. one edge of a block) being a maximum of 512 texels long. Objects can be smaller than this, but map-wise you wouldn't be missing anything major. So fitting that to the overview map you see in full in Ross's episode, it might be something in the order of 120k x 80k, at a guess. There is a problem though - most blocks do not have roofs, since you only ever see them from near ground level. I'm fairly sure I can robustly generate a roof wherever one is needed though, but I haven't attempted it yet. Baby steps, but who knows! Some ambient occlusion might work well, and some dynamic lighting wouldn't hurt... API-wise right now I've gone for broadest support, so it'll run on anything that supports OpenGL 2.1 or ES 2, but it'll use GL3/4 features if they're available. My main focus right now is getting the systems up and running - physics/collisions, NPC logic/path-finding, GUI components etc. Then it's into recreating (and subsequently tweaking) gameplay.

I'd love to see the original editors they used to make them and so on, but sadly those seem likely to be - along with the game source code - long gone. (I can see the StarCraft vibe too; quite a similar grungy tech look.) I'm very close to the point now where I could make a new block/map editor for the original game... Although that's not the direction I'm going, since I'd rather work towards a new version which runs on modern OSes and lets me fix bugs/issues and generally tweak things. I probably shouldn't spam the thread with crap about my random hobby project, but I'll just drop a quick video I recorded today showing a "drive" through parts of each of the five levels: Still very early days, just having fun with it. Rendering at twice the resolution of the original game in that demo; I actually think a little chunkiness suits it. Also the FOV is significantly wider than the original... Anywho.

Inspired by Ross's episode on it (which rekindled my own memories of the game), I've spent the last couple of weeks reverse engineering the data formats for Quarantine into a little custom (C++/cross-platform) engine I've been working on. I'm not sure what this will amount to, if anything, but I certainly have ideas... I'm essentially done with decoding the audio-visual assets and gameplay data at this point - at least everything useful (by my estimation anyway). Here are some quick shots of the first level: One of the boss vehicles (colour palette isn't set up as it would be in-game): I've also figured out the animation formats - the format used for those quick "plug in/out" animations upon entering/leaving a shop/exit was a real head-scratcher. Especially because it's only used for four animations in the whole game (two of which are just reversed versions of the other two). Here's a sample of decoded passenger text - note the names, which are never seen in-game. An overview visualisation of (part of) the first level: One of the many "blocks" which are used (sans objects) - each map cell seen in the previous image specifies which one of these to use. Figuring out how to decode these took by far the longest...

Just on reverse engineering - a minor point to throw into the melting pot which I haven't seen/heard mentioned (at least directly) in the discussion so far is the concept of "clean room" reverse engineering. Wikipedia covers this under the term "clean room design", for whatever that's worth. This is essentially where you observe the behaviour of a piece of software, then write new code from scratch to imitate that behaviour as closely as possible without duplicating any copyrighted aspects. This approach has been legal under US law since at least the 80's, as far as I'm aware. Sony Computer Entertainment, Inc. v. Connectix Corporation (about 20 years ago now) even extended it to include disassembly of actual code in cases where behavioural observation is impossible any other way. Having said that the risks in doing actual disassembly are still much higher regardless. I've done software reverse engineering professionally for 20 years or thereabouts, but I'm no lawyer... Obviously none of this precludes legal action being taken, but precedent definitely seems to indicate that (done correctly) reverse engineering itself is absolutely legal. I'd argue that writing a server emulator should be almost inherently "clean" since it's vanishingly unlikely that you'd have access to the game server software in the first place. BUT then you run into the data problem as others have already mentioned. If the server provides non-trivial amounts of (copyright-protected) data to the client then providing a legal set of alternate data might be by far the larger undertaking - if it's even possible in any practical sense.