glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] further direction for mars and months to come


From: Leo Wandersleb
Subject: [glob2-devel] further direction for mars and months to come
Date: Sun, 02 Mar 2008 22:39:56 +0100
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109)

hi *

bradley kept asking me what should be done and i didn't say much as i felt he's doing much and doing fine. now i feel a bit at a point i wish to base direction on a broader basis as the broken nicowar at fosdem and some ideas on switching back to udp made me nervous on weather things are still fine now and for future development.

- for at least steph and me stability has top-most priority. there are no new features after feature freeze period. testing is a must. all known bugs must be dealt with. those tons of valgrind output should be dealt with, too.

- networking: i thought routing should be done like now (tcp routing via yog) just with the addition that every client launches a restricted server, too. so once the game starts (after pre game screen), the main yog server can move routing
* to one of those connected clients' servers if possible,
* to another server that registered as "open server" if not and
* do the routing itself as a final resolution.

this should do for lan game as a subset of central yog. just connect to a yog server on the lan.
* join yog (join yog.globulation2.org)
* start lan (join localhost. make localhost an open server. localhost can change settings like max. games and allowed IPs)
* join lan (join ip)
* etc/init.d/glob2-server start (headless (no X needed). start a yog-server that registers at yog.globulation2.org as open for game routing of n commands/s)

what should be very robust would be the handing over to another server. if gameN routes via serverM those connected to it should not notice once playerM leaves (lost) and switches off the pc. the server object should go back to the next higher yog server (clients would ask there, too.) and this should be able to delegate again for the running game. to be robust this server would get a request for new routing by all the clients that lost their server all providing their respective serverID and last valid command queue. that should be all it needs to re-delegate the game smoothly.

- other features excluding AI improvements as the AI is far beyond strong enough already.

Greetings,

Leo Wandersleb






reply via email to

[Prev in Thread] Current Thread [Next in Thread]