[Alephmodular-devel] Re: 0.4 Planning and future

[Chris B. <zzk...@uq...>]

Below are some of my thoughts on techniques that could be used for AM 
and problems we might encounter. Go ahead and rip it to shreds, you 
know you want to ;-)

chris



GUI

I would tend to split more of the GUI out as platform-independent code 
if possible. Despite the fact that the underlying GUI model may differ 
between platforms, I don't see that the entire GUI would need to be 
rewritten. It would be more maintainable to pick a subset of GUI 
functions which are present (or can be faked) on each of the target 
platforms - ie. buttons, dialogs, etc. and make these the 
platform-specific layer.

This would allow us to keep the code for the preferences / main-menu 
etc. generic. Admittedly it'd be a little bit more work to set up 
initially (keeping the GUI framework consistent between platforms) but 
once it's done changes can be made to the GUI without having to make 
the same set of changes for each target platform (which would likely 
lead to some platforms lagging behind the main code base and becoming 
difficult to maintain.)

In cases where insufficient built-in GUI support exists (on a console 
or whatever) the GUI framework could be entirely based on OpenGL or 
some other graphic layer. This code in itself would be portable to any 
platform assuming the graphic layer is slightly abstracted (not a 
difficult task) and would ease the porting of the game to new platforms 
until such time as the "normal" GUI code is completed.

Also, on the flip-side to all of that, you could move the entire 
main-menu / preferences GUI into a separate "application" which acts 
like a launcher for the game "application" (be this through separate 
executables or whatever.) This separates the GUI development completely 
from the game development, which is possibly a good thing since it 
would make the division of labour a lot easier. It may or may not be as 
friendly for the users, depending on how well it's implemented.


Networking

It's fairly evident that the current networking code is not useful for 
WAN games  (and not great for larger LANs, probably.) It's easy enough 
to replace it with a better model, however marathon is based around the 
concept that everyone is perfectly in synch, always. Stripping that out 
may be fairly simple also - it means changing the ownership of 
individual entities in the gameplay from "each machine does its own 
thing because we know they'll get the same result" to "each machine 
does its share of the work and then lets all the other machines know 
about any state changes. This especially affects things like the AI and 
map constructs such as Platforms, etc.


Animation / Rendering

This is one that's a little tricky. In the spirit of modularity, we'd 
want to be able to take out the Good Olde 2.5D graphics and 
pre-rendered animation code and swap in a sweet 3D system. 
Unfortunately if things are replaced on a frame-by-frame basis, we 
aren't going to get any great results. New (3D) animations will require 
different timings and may react differently to the game environment 
(ie. imagine someone wanted to do a death animation/physics system 
similar to that in HALO. Not only is the time taken for the animation 
going to change, it's going to change based on the cause of death, the 
nearby obstacles, other explosions/bodies, etc. The character is moved 
around rather than staying stationary, etc. A simple example but you 
get the point.)

What we need is for some useful ways for the animations to communicate 
with the physics/game code (bidirectional - to determine what animation 
to play based on what is happening, and to affect timing, motion etc 
based on the animation (speed, length of stride, etc.) and also with 
the networking code (to tell other machines about what animations are 
happening on this machine.)

It's a fairly simple concept, but i think it may run into trouble when 
we try to match up this kind of system with the original game/physics. 
How to stay true to the original while allowing flexibility is probably 
one of the biggest issues that needs to be tackled.


Game Loop

Probably the simplest thing to do here is to simply use a timer, eg:

prevTime = GetTime();
physicsTime = prevTime;

while (playing)
{
	RenderFrame();
	
	newTime = GetTime();
	deltaTime = newTime - prevTime;
	prevTime = newTime;
	
	numPhysicsFrames = (int)(deltaTime / timeslicePerPhysicsFrame);
	
	if (numPhysicsFrames > 0)
	{
		physicsTime += numPhysicsFrames * timeslicePerPhysicsFrame;
	
		// if we for some reason pause for a long time, it's better to "lose" 
that much time rather than
		// spend ages trying to catch up or run ultra-fast for a number of 
frames to catch up.
		// this generally wont happen in normal gameplay, it's just a 
failsafe clause.
		numPhysicsFrames = MIN(numPhysicsFrames, maxPhysicsFramesPerCycle);
	
		UpdatePhysics(numPhysicsFrames);
	}
	
	UpdateAnimations(deltaTime);
	...
}

Keyboard input may need to be queued with some timing information taken 
into account but that's really a separate issue to the physics timing.