Re: [Alephmodular-devel] Network vs Game Core vs Interpolator (was Copy-on-write in practice)

[Br'fin <br...@ma...>]

On Thursday, January 16, 2003, at 09:18  AM, Woody Zenfell, III wrote:

> I see, yes since I didn't really have any obvious problems with the 
> current code in this regard, I didn't spend much time thinking about 
> these issues, and so my suggestions were generally made with something 
> rather like the current scheme in mind.
>
> For my overview of the way things currently work (in M2/A1), see
>
> http://source.bungie.org/_enginedevelopment/reference/networking-
> input.html
>
> (Note that contrary to what the end of that says, I now believe that 
> heartbeat_count is probably important for proper timing of film 
> playback (but not single-player games), though I still haven't 
> bothered to analyze it in detail.)

I should indeed make time to read that then.

>> (I don't currently know the feasibility of having the world itself be 
>> actively managed over 30 fps, would we have to make sure that M2 
>> style monster aren't allowed to readjust their AI except every 1/30th 
>> of a second?)
>
> If we didn't care about 100% compatibility with M2, i.e. a film 
> recorded in M2 and played back in AM would produce *exactly* the same 
> results (or the same results but rendered more prettily etc.), (which 
> I should hasten to say, I think we *do*) then it would probably be 
> reasonably straightforward to do what I'd call "real updates" more 
> frequently than 30 ticks/sec.  But since we do care, I think we need 
> to preserve the "real update" code as-is (reorganization 
> notwithstanding), including the 30 ticks/sec restriction.  So I agree 
> that some kind of lightweight "move some things a little bit between 
> actual ticks" interpolative scheme is the way to go.

I am currently and will continue to use the 3 M2 demo films as test 
cases for M2 Compatibility. (Oh interesting, I notice that close object 
visibility in one of those films too run from M2 proper too :) )

It is an area I'd not mind seeing some experimentation in. But that 
won't help us get our first and primary goals done either :)

> "Which side of the code" is responsible?  Well neither I guess, again 
> I think this is an oversimplification.  There would be some kind of 
> game manager that would know what needs to happen (apply real updates 
> to real game state, copy that state (whether an actual copy or marking 
> as COW) to make a predictive state, apply predictive updates to that 
> state, copy the resulting state (maybe COW) to make an interpolative 
> state, apply an  interpolative update to that (pretty sure we should 
> always only do one of these, representing the activity of some 
> fraction of a game-tick), and call the renderer).

I don't see a great deal of difference between the predictive state and 
the interpolative state. If we find that simply 'continue doing as you 
are' is inappropriate, we could put in a toggle to the interpretive 
controllers. Interpolate for X-real time then either give up the ghost 
to try to predict.

I see something like the following.

Both Game Core and Interpolation have their own world state. Game Core 
drives Interpolation but doesn't actually know everything. (Game Core 
doesn't need to care about specific frames of animation or management 
of effects. It can generate new effects, but when they stop interacting 
with other things in the world, Game Core forgets about them)

Game Core is lord over Interpolation. When an object moves in Game 
Core, the Game Core tells interpolation that the object is moving from 
initial position with a specific velocity and facing. (As well as if 
it's doing anything) It also tells Interpolation of any new objects or 
objects which should be removed.

I don't know if this is copy on write, I suppose it could be... But 
Interpolation is picking up not just the object's states, but it's 
attitudes in a different way then Game Core does.

> It sort of sounds like you're picturing a decoupling in the actual 
> execution of the game-update stuff and rendering stuff (e.g. into 
> separate threads or something).  I suppose there could be advantages 
> to that on a multiprocessor system (and yes, there are some of those 
> out there) but on a uniprocessor it seems like it could only make 
> performance worse (and complicate the code)... and might gratuitously 
> break Mac OS 9 compatibility (in case that's a problem).

Yes, I'm picturing a decoupling. I do not know where good lines are 
with respect to something client/server. (How much information over a 
TCP/IP line is too much? And would we actually be saturating the line?)

It might be nice to be able to spin these off into multiple threads if 
the current machine can handle them (ala multiple processors) But 
single thread for this loop is probably reasonable on most machines.

	1 Game Core update world
		No faster than 30FPS
		play catch up if we've been idle too long and have the input to do so
		reset Interpolator's synced data to new states (critical section)
	2 Interpolator
		run as often as possible
			allow locking to 60 fps
		each run should process as many times steps as last render step took
			but no more than 30fps.
		pause and allow renderer to display current Interpolator step
	3 Renderer
		run as often as allowed

In a networked setting supposing Client/Server with the server doing 
all of the Game_Core, then you'd want something like a Network Receiver 
replacing Game Core up above. (Interpolation shouldn't stop just 
because our network is busy after all :) )

Hsm. Interesting stray thought... Interpolation should have at least 
one network sensitive predictor even in the simplest case. I don't 
think a user would want their high speed machine and lagging network 
careening them through walls while waiting for the next Game Core 
update to apply their movement controls.

While not ok, it is acceptable to jump enemies around the screen when 
their real update comes in. It is not acceptable to jump or jerk the 
current player's view port around. Not sure how in this case platforms 
and even wall collisions would be handled. (Player state is true copy 
on write as opposed to other details of the system? This would let all 
of the functions in this space operate on the Interpolator's version of 
the player as if it was the real one Game Core knew about...)

Another amusing thought involved 'only objects reasonably in a person's 
view are updated for the Interpolator' which might make a nice filter 
if a client/server's bandwidth needs to updates needed to be lessoned.

> (I just got this picture of Conker asking the gargoyle "Isn't it a bit 
> early in the morning to be talking about gothic architecture...?")
>
Oh definitely.

-Jeremy Parsons