
March 4th, 2004, 01:57 AM
|
First Lieutenant
|
|
Join Date: Dec 2003
Location: Calgary, Canada
Posts: 762
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: Speeding up battles
Quote:
Originally posted by PhilD:
Well, how much more space would the turn files take (they're already rather large) if, instead of just the battle's initial placement, they included the situation at the start of each turn of each battle? that should let the battle replay "jump" to any single turn of the battle with no additional calculations, which would help a lot with the battle replays (right now, if you want to watch something in a battle and miss it, you have to restart the replay from the beginning!)...
Battles, especially large battles, tend to Last what, 10-20 turns? If the result is to make the turn files 10 times larger, I guess that's not feasible (but I don't know how much of the file is battle placement... I just had a look at my "UlmWorld" game files - World map, about turn 90), and the .trn files are about 360KB, while the .2h files are about 160KB.
Still, there might be another solution, like doing the "battle effect" computations at the start of the replay, and storing the exact state of the battle at the start of each round. Obviously, the complete movement of arrows is just graphical display, and does not need to be stored - it can be recomputed on the fly. It might add a few seconds of precomputation for each battle, but then the battle could be replayed at leisure.
And, adding an option to turn off missile/spell volley would be nice. I like the Spirit Helmet, but since each and every one of them fires in its own time slot, it just makes battles unbearably sllooooooow...
I'm not a (real) programmer, but I really believe an at least partial fix to the battle replay thing should be doable with reasonable effort. I mean, the battle results have already been computed, with no display, and they're being re-computed, with display. There shouldn't be that much of a difference...
|
Current turn files may not contain actual unit placement (I don't know if they do, but it is not necessary to store them). The user can only control placement of commanders and squads which implies that the initial placement of all units can be reconstructed from these data. During the battle each unit moves on its own, thus the state after each round of the battle has to be saved completely, which will make it large (and what's worse Illwinter may not have code that can do it, meaning that it will require additional development).
I don't think that there's a need to pass this information, because it can be recomputed locally. It is drawing that slows down the battle replay, not computations. For example, on Orania map one turn hosting (about turn 80) takes 1-2 minutes (on my computer). This includes 6-10 battles with my participation with 1 or 2 including large number of units. With about 10 nations left, this means that an approximate total of 8*10/2 = 40 battles is processed including 7-8 large ones. It's easy to see that the large battle resolution isn't taking more than 5-10 seconds. So the state of the battle after every round can be calculated locally.
More difficult question is how to manage these data, depending on the internal program organization it may vary from very easy to very hard. But developers mentioned that the feature was in game, but was pulled out because of bugs.
And considering that recently Johan K. made few comments implying that he was using unpatched MSVC (ouch!) with unpatched STL, I believe our prospects of getting advanced battle replay capabilities are good 
|