The Orion Nebula

Hello everybody.
About year ago, I posted some sources on xspace.ru forum regarding possibility of getting debug information from DOS version of MOO2 into something readable. At that time, I came up with cludgy tool, which can lookup symbol name for specific address. Also, I had idea to create remake of MOO2. However, because of real life problems I had to abandon it.
Now I had few spare hours to play with Watcom debugging format and I came up with small tool that dumped symbol names + their types (if possible) to text file. Unluckily, none of dynamic structures (player, planet, colony, etc) was dumped, as their structure is not present in debug information. Also, Watcom debugging format is little bit ugly (even OpenWatcom guys said that no one should use it anymore), so it's impossible to get name for a specific data type.
Regarding possibility of remake: after playing with assembly + symbol names, I think it is NOT worth to do remake of MOO2. It will be much more convinient to recreate MOO2 from scratch and, maybe, simulate AI behaviour.
Why? Quite simple. MOO2 was done... err... badly. For example, static arrays for planets (250 max), limited amount of planets per star (number is hardcoded inside of star structure), hardcoded UI's, hardcoded screen handling, etc. If we talking about multiplayer/singleplayer, for each screen in update (render) routine, there's call to Mox_Net_Update_, which plainly sucks.
Funny thing, though. Seems like some of the source file names was named after programmer that was responsible for it. For example: ERICNET, JIM, KEN, HAROLD, ERIC, ERICHELP, RUSS, BILL, BILLHELP, etc.

Why? Quite simple. MOO2 was done... err... badly. For example, static arrays for planets (250 max), limited amount of planets per star (number is hardcoded inside of star structure), hardcoded UI's, hardcoded screen handling, etc. If we talking about multiplayer/singleplayer, for each screen in update (render) routine, there's call to Mox_Net_Update_, which plainly sucks.

Eh, that's not that bad. Static allocations can be _easily_ replaced with dynamic ones. Instead of keeping a global array, replace it with a global pointer. At game init time, malloc it to the appropriate amount (and free it again when you're done, or at the next time you're starting/loading a game before the new malloc).

Truth is, most game source code isn't the prettiest, and for this reason I don't think any remake will achieve that goal. It might look a bit more elegant, but to achieve the moo2's feature set would take ages, imho (when done on a volunteer basis, unlike moo2 where full time programmers were paid to do it).

If the source can be decompiled and transformed into C (even if some things aren't named right, or the code is particularly ugly in some cases), then it can be cleaned up/de-obfuscated, which is an easier process then re-coding anew. I still say that the effort is worth perusing.

I would disagree here. Effort spent on recreation of original source code will be comparable with complete rewriting of original game. Well, that's only my humble opinion.

Effort spent on recreation of original source code will be comparable with complete rewriting of original game. Well, that's only my humble opinion.

After sometime trying to decode the disassembly, I have would have to agree with Joe. Perhaps the best option is to write a patch for the game to improve the areas that are most in need of improvement. Lord Brazen has done a great job with the DOS version with his patches. It would be nice to see a new patch for the Win32 version. It shouldn't be that hard to create a Win32 patch that fixes most of the bugs and improves the game play.