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

[Woody Z. I. <woo...@sb...>]

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

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

Actually, I did a lot of this sort of thing already in Aleph One.  
You'll notice it moreso in the netgame dialogs than in the others, since 
I worked with the netgame dialogs a lot more.

The end result felt pretty messy, but at the same time I managed to 
split out quite a bit of shared code.  The SDL dialog support stuff has 
notions of dialog item ID's (which are set to be the same as the Mac OS 
ID's of course) and there are shared routines that enable/disable an 
item based on ID, get/set the state of items by ID, etc. etc.

So anyway, I agree that there should be a low-level/high-level 
(platform-specific/platform-independent) UI separation.  ;)

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

Note that the SDL dialog system works on any platform with SDL.  So what 
you've suggested here is already available also.

> 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 am not too big on this idea because of the possibility that the user 
experience could easily become unpleasant.

> It's fairly evident that the current networking code is not useful for 
> WAN games  (and not great for larger LANs, probably.)

What's the problem with larger LANs?

I agree that WANs typically exhibit much less favorable latency 
characteristics, so you're right that the current code is not terribly 
WAN-friendly.

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

No offense, but this strikes me as a Bad Idea.  There are three basic 
models I guess along these lines:

1.  Server is authority for everything (most current networked games)
2.  Each machine is authority for some elements (your proposal)
3.  No machine is an authority (the current Marathon scheme)

(1) is the most secure against hacked clients etc.  (3) is next in line 
because the extent to which a hacked client can do damage is to show the 
player more information than he deserves or to help automate the 
player's actions (aiming etc.) through the existing input mechanism.  
(If it tries to change other stuff, it will fall out of sync.)  (2) is 
least secure because a hacked client could change anything it wanted to 
about the parts of the game it's assigned, and the other clients would 
just have to live with it.

(2) also strikes me as the most complex to manage and as the one 
requiring the most communication between machines, with (1) following 
far behind and (3) the easiest.

So I could see planning ahead for letting someone add 
server-is-authority code at a later date, but I'm not sure I'd invest 
much in supporting the 'everyone's an authority on something' scheme.

BTW while I'm thinking of it, Br'fin wrote:
> 	network
> 		ethernet

I think 'ethernet' is a fairly poor name to use.  'AppleTalk' would be 
appropriate.  If using IP-ring stuff, well then probably 'IPring' would 
be a good name.  You could call it 'IPring-SDL' or have an SDL 
subdirectory or something if you want to emphasize its dependencies.

> Game Loop
>
> Probably the simplest thing to do here is to simply use a timer, eg:
>
> ...
>
> 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.

It's my impression that what you're describing here is almost exactly 
what Marathon already does.  Hmm, well, almost.  Instead of having a 
real-time timer that determines how many physics-updates to do, it 
counts the number of action_flags it has available from the input 
routine (which is a separately-scheduled, high-priority, periodic task) 
or network subsystem.  Since each action_flag conceptually captures one 
game-tick's actions, the number of action_flags indicate the amount of 
time that's elapsed.

Please point out the differences so we can talk about them if I'm not 
right.  (And, if you look in the engine development documents area on 
source.bungie.org, you can read my analysis of the current input scheme.)

Hmm, I should scare up and post the stuff I wrote to Br'fin about 
networking and prediction and smooth-rendering interpolation etc.  
Soon.  :)  But it's busy here with the holiday.

Woody