|
David Clark -> RE: Is there persistence in the campaigns for enemy forces? (11/29/2014 12:43:23 AM)
|
(Sorry for the crosspost - two threads popped up at the same time on the same topic)
I'm planning to do this programmatically.
My plan is to create an operational combat framework that uses FC:RS as its tactical combat resolution engine. Players would command V Corps/8th Guards forces on a hex map of the combat area, and when forces moved into contact, a FC:RS save-game file will be generated. Once the combat is concluded or time limit reached, the game is saved, and the operational framework is updated, taking into account losses, terrain modifications, unit positions, logistic expenditures, morale effects, etc, etc, etc. Some out-of-FC:RS combat resolution will be required for tactical combat that both players regard as too tedious to play out in FC, or as inappropriate for that game. Combat map data in its roughest form will be generated by scanning in topo maps, binning the resulting terrain at 500 metre resolution - that data can then have diffs applied to it by any interested community member. Hex grid size will be 15km, time will be tracked in minutes, unit scale will be battalions/regiments with specialized companies, and the implementation language will be C#.
This will accomplish several goals: it will allow for persistent force state and location between battles, will serve as a scenario generator, will allow combat victory to be decoupled from the Victory Point system, will allow players to circumvent the sudden-death nature of scenarios, will create unpredictable combat between heterogeneous combat arms, and provide for persistent terrain effects such as fortification, minefields, blown bridges, nbc contamination, etc etc etc.
The main challenge at the current time is decoding the savegame/scenario file format. Savegame files are binary blobs with a magic number at the beginning and no discernible structure. They may have been deliberately obfuscated; in any case there is no documentation. I will either reverse-engineer them from first principles by creating scenarios with known configurations, or I will have to write a daemon that hooks into the game process and intercepts serialization. Worst-case scenario is I have to write a screenscraper, but that would be a nightmare with localization and Windows font settings issues, so I hope it doesn't come to that.
Anyway, I have a couple of paying projects to work through, and then I'll get cracking on it. If anyone has the actual sav/scn file documentation, or the serialization code itself, that'll dramatically speed this along :)
|
|
|
|
