Re! > But i think it will not solve all of our problems (for replay for example). > We need also to write something like a game client event driven. Events are > coming from a gaming server (local, ai, network) and each event update > character position, weapon projectile explosion. In gaming server, object > are refreshed and then send event like explosion, moving object etc. In > game client, we read an event, then updating etc. For objects like > particles (not fire particles !), classical game engine should be fine.
Well, the code to store each characters position is almost there when we sync the game at the end of each turn, but nothing is there for objects. But, the aim of the modifications i'm proposing is to avoid to send the position of each character/object, and send only the user actions (mainly keyboard/mouse interaction) As for replays, i'm not focusing on them yet! The first goal is to put the network code out ofthe main game code. > Here is the advantages i can see : > - separate graphic processing from physical engine. Totally agree, it's not a big task most of objects have this code already separated into ::Refresh() and ::Draw() > - write a real layer between keyboard, mouse and game engine. Totally agree, see https://gna.org/task/?3638 :) > - run independant game server without game interface. Not sure it's really useful, my aim is not to make all physics rendered by a server that sends object position to all client (that would need to rewrite almost everything).. So an independant game server wouldn't increase the framerate on clients. The only use of such a mode would be to have better speed to test the physic engine code (useful under valgrind), or to train a neural network based AI (maybe in the future! :)) > - same code for local and network client. That's the goal! :) > - replay ! Save the game context at the begining of the turn (map, characters > position etc), save the events as they come in a round buffer and when you > have a big explosion with big damage, replay each event on the previously > saved game context and add someone laughting :) (damn ! another sound !) > Well, to be honest, it will need a huge amount of work ... Sure that's why i'm talking for after the 0.8 release ;) Lodesi > > Drayan > > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > part de Laurent Defert > Envoyé : lundi 30 octobre 2006 16:45 > À : Discution sur le développement de Wormux. > Objet : Re: [Wormux-dev] Network code > > > Hi! > > > > - Run the game loop at a constant rate by refreshing the main clock (the > > > Time class) at a constant rate, instead of having the physic engine do > > > it. > > > > I'm not sure to understand what you speak about. How can you be sure that > > you > > ran the game loop at a constant rate ? On my computer, Wormux runs with > > about > > 20fps and is playable BUT sometimes, big explosion make it fall to about 6 > > fps. > > In my case, the only way to be sure that game loop is running at a constant > > rate > > is too ran it about 5 times by second making the game totally impossible to > > play. > What I mean is, the game loop would run at a fixed rate, but independently of > the > displaying rate. > Practicaly, the class Time would store the current time in a member variable, > so > each call to Time::GetTime() would give the same value for a same frame, > independently > of the time elapsed since the last frame. > In the game loop, we would put a Time::Refresh() that increase the value of > the time by > 20ms or something like that (it limits the max frame rate to 50 fps, the same > limit > we have currently in the physic engine). Then we compare the time variable to > the time > reported by SDL, and there we decide wether we have enough time to display > the frame, or > just skip it. > The difference with the current main loop, is that we will run more often the > Refresh methods and check for keyboard and mouse interaction. Most of the > current Refresh > methods is to call the physic engine loop, so the impact there is null, the > loop is just at > an other place. So the main difference is that we'll check more often for > user interaction, > which is negligeable I think. > > Also I forgot to tell, it's a future work, I don't intend to do any of this > before 0.8!! :) > > Lodesi > -- > > _______________________________________________ > Wormux-dev mailing list > Wormux-dev@gna.org > https://mail.gna.org/listinfo/wormux-dev > > > ======================================================= > > Ce message et toutes les pieces jointes (ci-apres le "message") > sont confidentiels et etablis a l'intention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. > La SOCIETE GENERALE et ses filiales declinent toute responsabilite > au titre de ce message s'il a ete altere, deforme ou falsifie. > > ======================================================= > > This message and any attachments (the "message") are confidential > and intended solely for the addressees. > Any unauthorized use or dissemination is prohibited. > E-mails are susceptible to alteration. > Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates > shall be liable for the message if altered, changed or falsified. > > ======================================================= > > _______________________________________________ > Wormux-dev mailing list > Wormux-dev@gna.org > https://mail.gna.org/listinfo/wormux-dev -- _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
