Spring RTS Engine

Like Console++, this is an invitation. I've had a breakthrough, and I came up with a basic plan for writing / reading a saved game state and allowing players to access it (from outside Spring).

If anybody is interested in helping, please let me know. The source will be made available when it's ready.

Breakthrough? That you can have an approximate state saved an loaded by lua is common sense and not very hard, if that's what you mean. If you have a way to fix the save generator or make a new one with exact saves, then YOU ARE AWESOME.

I'm not sure if I can get the exact saves... yet. We'll see. The sticking points are Lua states and projectile states.

Is it intentional that you sound like you have a way to get exact unit states? Even that would get me quite interested.

[BIG FAT EDIT]

Ok, so I'm right. The save editor tries to talk to AIs. Does it work without any AIs (i.e., just a null AI or one player only)?

<testing>

So, it crashes writing the save, and it crashes attempting to read the save. Doesn't matter if you have one player or multiples.

Great... uh, back to Lua... yeah.

Gotta quick question, though. Why is the savegame function not a Demo recording, and in what significant ways is it different? Demos aren't just records of Commands, right? They contain projectile states and stuff? If so, then a save-game / load-game could just be a Demo that runs without graphics at some pretty ridiculous simulation speed up to the end... then allow the engine to draw. Pretty ridiculous solution to it, but meh, it's really surprising that if Demos work solidly, that savegames are so hard to do. I'll stare at the crash log a bit more, see if I see anything obvious...

Argh wrote:Demos aren't just records of Commands, right?

Yes they are.


So you don't actually have anything crazy-awesome? That's fine. A simple system where lua dumps out units and things is useful to have, and is waiting for anyone to come along and code it.

No, sorry, no crazy-awesome. Just adequate enough that people aren't like "wtf! no save games?!" If it just saves commands and positions and health and etc., it'll be like starting at the end of a Demo, I figure that's a win.

Oh, and the crash I get when saving has to do with losHandler btw. Dunno where yet, but it stops on the line:

s.SerializeObjectInstance(loshandler, loshandler->GetClass());

IDK about you, but I don't see the point of storing that, or some of the other stuff being saved. It'll all be calculated on the next slowUpdate at worst.

I wrote a multiplayer save mod for Supreme Commander. It took nearly 8 months to complete. Of course SC is closed-source but I hope you're not thinking this will be easy.

One of the biggest issues you will face is restoring orders. It isn't really enough just to re-issue the order because some orders can contain state that runs in the engine only. For example, on a multi-point patrol it isn't enough to just restore the patrol, you also have to restore the current target waypoint for each unit. If you don't then a unit will head for the first patrol point which may be directly across enemy territory or in the wrong direction.

The underlying issue is that certain events are time-critical or contain temporary state and you therefore have to allow for the state changes during the elapsed time between the event starting and the current game time. Often these will be critical loops in C so the state may not even be accessible without changing the engine or impacting on performance.

Also as noted the AI and many mods will have their own time-critical data and events. Some you will be able to fudge, others will be essential to restoring the game.

The best option is to go with the idea of fast-forwarding replay data. This resolves all the above issues and the data and replay system is already written. The hard part will probably be disengaging the rendering, UI and audio system for maximum possible fast-forward speed. To be practical you want playback "framerate" of at least 10x realtime (or 300+ FPS) or savegames will take ages to load. At 10x a 2 hour game will still take 12 minutes to load. 100x is still over a minute load time.

Argh wrote:I'm not sure if I can get the exact saves... yet. We'll see. The sticking points are Lua states and projectile states.

Are COB states easily accessible?

No. The COB engine is all about threads. It'd be a nightmare I think.

btw. The replay fast-forward is also a solution to another issue - joining or re-joining a running game. If such a system were implemented then a joining player could fast-forward the elapsed game until they catch up within a few seconds of real-time. Then the game could pause for a second or two to let them sync up to everyone else.

Yeah, I'd like to see the fast-forward demo. Although, if all it stores are order states and Unit positions, it's not a whole lot different than what can be done with Lua.

As for your example with Patrols, I had to handle that with World Builder to some extent already.

It's imperfect, but it's how I make the animated Gaia units and things on the maps that have to move around. What's bad, and may even be impossible, is stuff like custom Lua order states, unless I hard-code all of that in a P.U.R.E.-specific way. I want to build something a lot more general, though, if possible- I don't like the idea of writing something that's difficult and annoying to port, if I can possibly help it, this is a fairly important fundamental engine feature (imo) that we need to get working for every game on this engine, if possible.

Replays don't store 'order states' or 'unit positions'. They store orders and frame numbers (or more precisely, commands and command sequence). If every command is played back on the same frame (and in the same order) as issued in the original game then the engine (being completely deterministic) will generate exactly the same sequence of future events (this is why Spring has no true random).

There are no shortcuts. You can't just start playback at any frame because the game state is always the sum total of everything that happened up to that point. There are no 'unit positions' because these are the total of every decision or force applied to that unit since it was created. Even its creation is dependent on the outcome of every impact and event up to that point (did its factory get nuked or was the nuke intercepted?).

What about doing a ram dump?

I did a quick test and Spring appears to run ok at a speed of 19.5x (the max setting) on my PC (3.0ghz Core2) even with rendering and sound enabled. I didn't get as far as checking actual framerate but it certainly seemed to be running 20x faster, even when I increased my army to about 500 units. With rendering and sound disabled I think a 100x speed or higher is not that far-fetched after all.

SpliFF wrote:I did a quick test and Spring appears to run ok at a speed of 19.5x (the max setting) on my PC (3.0ghz Core2) even with rendering and sound enabled. I didn't get as far as checking actual framerate but it certainly seemed to be running 20x faster, even when I increased my army to about 500 units. With rendering and sound disabled I think a 100x speed or higher is not that far-fetched after all.

Many late games traverse the 1000 unit limit. At that point, it would take me around 3- 5 minutes to advance 15 minutes of gameplay on a 2.6GHz C2D.

Of course, the story might be different for PURE, so this could be entirely acceptable.

Nonetheless it remains the only viable solution. Anything short of a perfect save state is likely to cause unexpected crashes and desyncs and probably won't work with most AI and mods.

This brief test shows me that the sim is capable of much higher framerates than I expected. The only true test will be benchmarking with rendering/animation and sound disabled completely as I expect these to be the primary bottlenecks.

I assume you were kidding about the RAM dumps. Unless you were selective it would result in save files in the hundreds of megabytes. Any missing data would likely result in broken pointers and lots of illegal memory access. Also loading a save on different hardware or Spring versions would crash.

Oh yeah. It's also worth mentioning that some state would be stored in your video card so you'd probably have to dump/restore that as well.

SpliFF wrote:I assume you were kidding about the RAM dumps.

No of course I wasnt kidding thats why I had two rows full of lols and rolls.

Spliff, try /skip [seconds] in a replay. Only works after game start.

Beherith wrote:Spliff, try /skip [seconds] in a replay. Only works after game start.

Also, that was what I referred to with regards to performance. I suggest either spectating a large/long BA match or getting a large demo file from someone, and attempt to skip to mid/lategame.