Hi linux_monkey,
Hello. I registered just because of this thread.
As it's proven to be difficult to re-create source code from the original DOS game,
what about (instead) mapping out the game logic functions and how they flow? Do such "functional blueprints" exist?
Well, not exactly, I have game working just fine in C# VM I created. The problem (code) is more complex than I first imagined.
The Decompiler I created for the game contains some high level translations I never finished because of:
* Code is constantly augmented by direct assembly that was inserted at places the original programmers felt appropriate to speed up the game. Even whole functions were written in direct assembly!
* You have Segment:Offset problem in translating 'virtual' addresses to absolute ones (that's why there are virtually no decompilers for 16-bit code).
* The compiler did optimizations which are difficult to directly translate to code.
The part of the code logic has been mapped, especially regarding save game data .sve and .map files. That's where JCivEd shines. But going throughout the code I found some mistakes that will be documented when I finish replacing save game data memory references to direct object references. Also, I mapped the format and logic behind the .cvl overlay (driver) files and documented them.
Rephrased: A visual blueprint of game functions, arguments and types.. which functions call what, and which data, would be a great resource for anyone looking to learn how the game worked under the hood... OR for anyone looking to re-impliment it all in a fresh codebase.
Yes, that is what I'm doing (you can play with the code History on the GitHub page and see what I'm doing). I'm slowly mapping the code, variables, arrays, structures etc. So I end up with clean codebase. If you look at the GitHub page, I set that as First milestone.
It's apparent to me, as I slowly replace save data variables, there is a lot of places to improve upon the code, to lift up city number restrictions, map size, current bugs, etc. and that is the Second milestone.
Backstory: I remember figuring out that saving your game was not always a great way to cheat, or steer the game. Unit battles were not simply decided like ((player1 vs player2) * chance)), there was like this overlay of "good luck or bad luck" that seemed to ebb and flow over turns. That felt like a leap when compared to older implementations of Risk, or DOS Empire.
Regarding this, there is number of ways that you can make progress or regress in a game. The random number generator seed at offset 6 (ushort) in .sve file (see
https://forums.civfanatics.com/threads/sve-file-format.493581/), the AI players defense/attack policy regarding certain continent, also technology discovery, city development etc. all come together in a game to dictate your progress.
That's why Civilization is one of the most popular games of all times, at first glance everything seems simple, yet there is much more under the hood that meets the eye
