Spring RTS Engine

Basically, the more I mess with LUA, the more concerned I'm getting about this issue. To set up any really fancy game stuff involving the world, I need to do some very heavy math, which may take up to several seconds, on slower computers.

I think that we need to have at least 30 frames of "sim" which run before Spring accepts any UI input from players, or starts sending network traffic.

Why frames? Well, Spring's already structured around this, and it's a very loose definition- a "frame" lasts as long as it does, period.

Moreover, a frame has a start and an end, allowing for operations to be performed without interfering with one another- say, a mod's code wants to do certain operations on the gameworld's state, then the map's code needs to also do stuff- they cannot "know" about each other, so therefore the logical solution is to give them different frames to operate.

Allowing for 30 "frames" to occur, say, while the countdown was being performed (and not allowing the countdown to complete until a network packet was received from the host, stating it was complete and that data from the outcome was being sent), and having the results of then displayed on the "official" frame 1 (from there on out, network traffic begins) would allow game designers and mappers to run very complex code on the gameworld, and would greatly facilitate game designs that require extensive modifications of the gameworld.

Yes, this mainly means P.U.R.E. + World Builder, at the moment. However, I suspect once World Builder's available, a lot of people will want to use it (or variant ideas) to mess with the gameworld before the game really "begins", and I'm rather concerned that this will lead to constant desyncs until some leeway is introduced, at the game engine level.

Does anybody else have any thoughts on this?

Allowing 30 seconds to pass by previous to the game starting and the untis spawning would make AIs brake utterly. AIs expect the starting units to be present when they first run, and what happens may be different depending on the AI.

If the AI is dependant on the frame, such as NTai then either itll reach frame ten look for commanders and find nothing and either crash or not do anything, that or it gets spawned when the game starts and never initializes itself because its too late and the check never executes and thus starts receiving unit events, uses uninitialized data, and crashes.


What you need is a callback function that executes when loading finishes but before the loading screen dissapears.

doesnt the call in initialize works for this?

hmm not sure if that applies to my comment on AIs or arghs lua widgets.

What you need is a callback function that executes when loading finishes but before the loading screen dissapears.

Firstly, I hear you, about the AIs. Sorry for not thinking about that wrinkle in advance.

The only problem with what you're proposing is that it needs to allow for more than one iteration- there has to be some sort of timing condition. IOW, we need to be able to do stuff like this:

Game Code: DoSomeStuff.

Map Code / Other Code: DoSomeOtherStuff.

Game Code: DoYetMoreStuff.

That way, game code and map code can exist without conflicts. That's my main concern with this- there needs to be a mechanism that allows for them to work separately in time, execution-wise, so that they don't "fight" with one another, whilst modifying the gameworld.

If it's signed then you could always start at frame -29 or so.

I'll check, but I'm going to be extremely surprised if it's signed.

GlobalStuff.h wrote: int frameNum;

What's so surprising? It makes sense to use a plain int to simplify things and avoid conversions unless you really need that extra bit of space.

That's not what I meant, sorry, I was being very unclear. The issue is whether Gadget:GameFrame can operate before frame 0...

It works pretty well, actually. Changing the init frame from 0 to -9000 made the game start at -5:00. The coms didn't spawn until frame 0/1, only air units could actually move (ground units could just turn), and there were a lot of no response and delayed response messages, but pretty workable. I'll try to get those bugs fixed up.

Wonderful! That'd solve the vast majority of problems associated with this stuff...

Okay, got the gameserver sorted out. Now for the movement code.

Edit: Woo! Everything works now. Probably still has a couple minor bugs related to unit actions, but that's only an issue if you plan to play the entire game in negative time. Which you can. That and the corner clock having a separate negative sign for the seconds...

*ahem* Forgotten something? Hmmm?

imo setting up negative frames like this is a kludge, it would be much much better to have a proper method such as a lua callout after loading has finished, especially since only one frame is needed, what would do we do with the other 29 negative frames?

What's more it isn't apparent how it should be done in the end user API. I shouldn't have to be told this sort of thing, I should be able to see something like a preload() callback.

Argh, have you considered for the time being queuing up requests to spawn things and then doing the work over several frames rather than all at once?

well, it's not uncommon to delay some stuff on game start in other games; quakes e.g. spawn initial entities over several frames.

kludge or not, I'm playing an entire game in negative time later

Argh, have you considered for the time being queuing up requests to spawn things and then doing the work over several frames rather than all at once?

Yes, I considered that. It's not practical, however. I'd have to break up the actions so much that it would be severely deleterious to gameplay, imo.

Any chance this will show up at some point? I'd really like to make use of this to do a few major speed-ups for players...

Probably not, why? Once the rng seeding is fixed you could do it pregame at the end of loading, the way THIS operates.

I'll have to take a look at THAT's source, and see if it'll work. Dunno, World Builder requires placement of Units, and has very heavy math requirements.