Re: [Alephmodular-devel] Re: 0.4 Planning and future

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

On Tuesday, December 24, 2002, at 02:56  AM, Chris Bergmann wrote:

> 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.

I found myself thinking of there being one preferences file used by the 
application with conceptually the preferences GUI being handled as 
almost a separate application within it.

I'm also not very familiar with cross-platform GUI support. My 
ignorance here could be a factor. So my choices are between something I 
don't know how to plan for very well, and trying to leave room for 
someone to polish their GUI as long as I can really polish mine. I 
don't think it's a bad concept as it might allow a specific project to 
build more quickly on another platform with modified features.


> 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.

I was thinking a little more along the lines of one machine serving as 
dedicated server and handling each game tick. Woody himself has had 
some very good ideas with regards to networking. I'm not sure how I 
feel about trying to figure what each machine itself should be doing.

> 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.)

Well, even for Marathon 2, the shapes/animation define some of what 
occurs. Keyframes, for instance, which denote when in an animation to 
actually fire a projectile. My thinking was that the physics model will 
need access to the shapes to note the timing of when to fire. (5 ticks 
after beginning 'attack' fire the projectile) So all movement is done 
in the game engine. If you had the ability to make a dying body dance 
with gun fire until it slumped back against a wall, then that would be 
all handled within the physics model as well.

I'm viewing animation as details that the Physics engine doesn't need 
to worry about. With an eye towards performing animation faster than 
the 30 frames per second of the game ticks. With information going one 
way from the physics model and driving the animation. A game server 
could conceptually run as an entirely separate process, accepting user 
input and returning information to update game state. (Whether this 
means broad casting the actions of all entities on the map or merely 
confirming player inputs for the local game state to reinterpret is an 
exercise for later) Locally the GUI would be accepting input, animation 
would be receiving updated game state animation. Then performing 
animation up until the next game update. Animation itself would be 
driving the rendering.

 From the game engine point of view, it's only worrying about the 
object's current behavior. Be it 'running', 'attacking', 'exploding', 
or 'dying in flames while falling' If we want to get a really detailed 
animation system with bodies that turn into rag dolls before tumbling 
off a ledge, then we should probably skip the animation system and 
instead focus on changing the way Marathon's tick counter and input 
handling queue works.

Revamping the Marathon engine to be kick-ass 3D is low on my 
priorities. I can understand updating the engine to do its rendering 
using OpenGL. But I don't see the draw in replacing everything with 
highly detailed models. Or why, if you really want kick ass 3D and 
highly detailed models, you're looking at Marathon to provide it.

I'd rather say "Yes we have a dated 2.5D engine, gosh darn it, but 
we're going to try and make it the best it can be" and provide 
opportunities for people to make all sorts of games that use it. Not 
necessarily FPS.

-Jeremy Parsons