[Alephmodular-devel] Re: networking, everything over christmas ;-)

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

> As I stated to the AlephModular development list: "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"

Agree and disagree :-)

Yes, Marathon is a 2.5D engine. It is fairly limited in extensibility 
because of this ('fact', not insult ;-) and because of this it's my 
opinion that the project could achieve more if it allows for growth 
into a full 3D engine. I guess I could ask - list your reasons for and 
against allowing support for 3D rendering? List your reasons for the 
project as a whole? If your focus is purely to bring marathon (with 
modern SW/HW support) to those of the mac gaming community who grew up 
on the game, fair enough. If you're trying to pull new users, you'll 
need to do a little more than just an updated version of the 
same-old-game. That's not to say the gameplay needs to change much. 
(sorry if you've explained this elsewhere, quite possibly i've missed 
it.)

Woody - no insult taken, my original message was posted with exactly 
the idea of bringing argument (and hopefully constructive discussion 
from that.)

Perhaps my outline of the basic networking was poorly explained. I'm 
not opposing (or supporting) the idea of a central server, but rather 
trying to point out the links between physics, animation, and 
networking. They aren't three separate beasts, as much as that would 
simplify life. They need some fairly close ties and if we are to make a 
generic set of systems which can cover different game technologies (as 
suggested by the Modular name) then they will have to communicate to a 
significant degree.

One thing that is required is that local animation and physics 
simulations must be present. They may not be an authority on the game 
state, however they are needed to smooth out the gameplay between 
updates, hide latency, etc.

As was mentioned, animation currently provides the events on which the 
physics system is driven. I'm not at all opposed to this mechanism as 
it simplifies the creation of new (different) models. This doesn't even 
require the animation system to be tied to the physics frame rate, as 
long as it's being simulated (eg.) at some reasonable minimum (maybe 
10-15 fps) frame rate in those situations where the real frame rate 
drops below this.

> What's the problem with larger LANs?

Packet loss, and significantly higher latencies with a ring network. a 
60 player game is going to have > 10x the latency of a 6 player game. I 
can't remember offhand whether marathon uses a ring or not, but even if 
it doesn't, any packet loss / moderately increase latencies is going to 
hurt badly. Even over appletalk it was never the most reliable of 
beasts.


> I am not too big on this idea because of the possibility that the user 
> experience could easily become unpleasant.

Yes, but there is a significant advantage to the developer. It would 
work well on most OSes, the exception probably being macos 9 although 
really that could be done as well with a little IPC. The advantage i 
see is that it splits the project in two definite parts, which is a 
considerable bonus considering the distributed development nature of 
the project. If coded sensibly it could be re-integrated at a later 
date when everything is stable and fairly clean. Again, I think either 
way would work fine, this one just has the advantage of not tying the 
game executable to the (current) limitations of the game interface - 
eg. we could start by simply having it parse a text config (~ 30 lines 
of code) and load the appropriate files and level and settings.

Certainly not ideal for end users, but then, are we expecting end users 
to be able to sit down with the AM code any time soon and start playing 
with it? As soon as people get serious about the development, it's 
probably going to be 6 months before it's any good to anyone..

Again this is just my thoughts, and jeremy gets to make the decisions 
on this, but i think it makes more sense (for now) to have it working 
well for the developers than it does to try and make it polished for 
the end users. I guess it depends if the project #1 priority is (1) 
making marathon work as-is, quickly, or (2) developing the code-base 
and making it modular.


thoughts?

chris

ps. Merry Christmas, everyone.