On Wednesday, 13 December 2006 at 0:38, [EMAIL PROTECTED] wrote: > On Tue, 12 Dec 2006 19:50:00 -0500 Christian Ohm <[EMAIL PROTECTED]> > wrote: > > >- The network code > > > >I have seen the discussion on the forum about this, I just want to > >address two points: 1. There are libraries that do the stuff you have > >talked about, so there's no need to rewrite that (but has all > >disadvantages as listed with the graphics engines). One of those is > >RakNet. Unfortunately the author has changed the license from GPL to > >a CC license, which might or might not be compatible to the GPL (hard > >to say, since the CC licenses were written for artwork, not code; > >additionally, there are references to both the GPL and CC in some > >source files). But there are older GPL versions available (if you > >search for them). At least in Debian there seem to be no usable > >networking libs, so we'd need to do something about that (like > >including the RakNet code). > > I was looking at this: The Torque Network Library is a robust, secure, > easy to use, cross- platform C++ networking API designed for high > performance simulations and games. The network architecture in TNL has > powered some of the best internet multiplayer action games to date. > Whether you're writing a multiplayer game, developing a complex > simulation, or just need a solid foundation for network apps, TNL will > meet your needs. > > TNL is available under the GNU General Public License (GPL), an indie > license, and a commercial license. > > It is C++ though. Can all compilers handle mixed code OK? I know > MSVC can, I think gcc can (or is it gpp? g++?) dunno about mac? > > There is also hawkNL: http://www.hawksoft.com/hawknl/
Right, forgot those. Well, OpenTNL was last updated in February 2005 and doesn't compile with gcc 4.0, so we'd have to fix it. HawkNL seems unmaintained as well. We'd have to include both into our source and maintain them, same as with RakNet (unless we can use newer versions). I think OpenTNL and RakNet are comparable featurewise, HawkNL is more low-level. Another thing I forgot was the network architecture: - One server: One machine is the server, and all other just connect and get their data sent. The server is authoritative, so whoever serves the game can modify it to cheat. Also, once the server quits, the game is over. Can be fixed by having a dedicated server everyone trusts. But that needs a machine to run it on and bandwidth. Or by having another machine take over the server role, which then needs to get all game state before it can continue. Bandwidth is mainly from server to clients. Easy to implement, every networking library should support this. - Peer to peer: Every machine gets all data, thus needs more bandwidth. Differing game states can be detected, so cheating is more difficult. Any machine can drop at any time. - "Distributed server": Like a RAID 5 for servers. Combines the advantages of client/server and peer to peer, without the problems. No machine has all data, but all data is on several machines. Needs less bandwidth than peer to peer, more than a pure server (but the requirements are distributed more evenly). Probably by far the most difficult to implement, I don't think any library supports this. Note: If some game logic is exported to scripts, once several machines are involved in server duties, all have to run the same scripts (ideally all have the same data (though some data can be different without negative consequences), but checking just the scripts is easier than checking the whole data). > >And 2. The float issue. This doesn't only apply to networking, but > >could be very important there. As floats are not accurate and can > >lead to different numbers on different machines, _no_ part of the > >game state should use floats (else the game state drifts apart > >between the machines and the game desyncs - perhaps that's the > >problem right now, I don't know the network code). Well, that the > >ideal case if you want to stay deterministic, I don't know if that's > >easily doable with any graphics engine... > > What is the float issue? I must have missed this? All compilers > follow the IEEE standard. http://www.gamasutra.com/features/20010713/dickinson_pfv.htm (very interesting article, by the way) "It may seem surprising, but different FPUs can produce marginally different results for some calculations, even though all units are IEEE compliant." > >- All game data should be externalized so it can be changed easier > > You can edit all the game data now, most are just text files, and that > is pretty easy to change. Changing isn't the hardest part, it is > adding stuff. Look what has to be done to add menu options and > things. Ick. You mean you can edit everything in the data directory. But not every data is in there, some is hidden in the code itself (that's what I meant with "magic numbers", things hardcoded in the engine). > >- General structure > > > >The general structure of the code leaves a lot to be desired... I am > >wondering if it's easier to start a new engine from scratch with a > >good design, and make a Warzone mod for that than to change the > >existing code... > > That is the conclusion that Rodzilla/Grim/Coma/Qanly/Per(?) came to > also. It would be easier to just start a new game. From the last > logs I read, Rodzilla & Grim, Coma,maybe Qanly also, started a new > project using the torque engine. Those logs on wztoys haven't been > updated since july. I don't know what is going on with that. :( They > might have a pretty decent game going on now. Anybody know anything > about it? If they have achieved anything, they haven't told us so. Also they wanted to make a closed source engine, IIRC. -- BOFH excuse #383: Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet. _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
