////////////////////////////////////////////////////////////////////////////// // theory-of-ops.doc // (such as it is) // // for World II // by Eric J Krejci // Copyright Eric J Krejci February 1998 // Revised : 04 Jul 2002 ////////////////////////////////////////////////////////////////////////////// OK, Where to start ? The server runs as account worldii under a linux box that has an alias of worldii. It listens on port 4000 for connection requests, when it hears one it fires off three threads a portmonitor (portmon), a queue loader (qloader) and a server. The portmonitor simply reads data from the port and stores it in a CRawBuf object that is basically a FIFO. The qloader reads the CRawBuf and parses it and stores the message in a CMQueue object. The server reads that object and acts on the messages. The client uses the same code to gets its mesage traffic, the comm code is the same source for win32 and Linux. The server has a CServer Object that tracks servers (triplets of the portmon, qloader and server threads) and holds pointers to the CRawBufs and CMQueues for each server triplet. The queues are separately maintained, so that a hold up on one wont stall another. The client has a handler routine instead of a server routine, but it does that same thing, it handles messages coming in. The socket stuff is in a CSock object. The socket is protected by mutecies so that we prevent concurrent access. The source code for the server is in server-v3, and client is in client-v3-dx8. The include dir has includes that are shared between both client and server. The win32 code should by compilable be just creating a project for it. Be sure to have directx 8.1 loaded, that means win98. Also be sure to have the directx sdk loaded. I dont know if VC6.x came with it or not. The server code should compile with just a normal RH 7.x dist install. I do use pthreads and ncurses. Pthreads is the prefered threading library under *nix these days, and should come installed. The ncurses is simple cursor placement on a terminal screen. The sql directory has the beginings of the worldii database. Right now it is implemented on Postgres version 7 although i dont think i have used any non ANSI stuff yet, nor do i think we need to yet. The life directories has some simulation stuff (very rudimentary) in it. The env is as follows: The server runs on a linux box that has an alias of worldii. It listens on port 4000. The client runs under 9x or Win 2k or XP. The client will start immmediately showing the boids example. The client/s can log in to the server and drive around and send chat to each other. The server & client should be have TCPIP, and the client should be able to find the server via the worldii alias. The server is controlled cia a "console" app. This is so the server can be left to run in the background. When the server starts it just sits there doing nothing until you connect with the console and tell it to listen. Then it starts actually repsonding to requests for connections. Why worldii ? Well so far all the Massively multiplayer games are static worlds. Well the worldii world can and will change. If you want to bash a hole in a wall and you have a big enough hammer you should be able to do it. You should be able to dig a hole in the ground, or cut down a tree for firewood. IE the level of useability of the world should be much greater. The NPCs should have a MUCH better AI behind them. Also (a pet peave) I would like to de-emphasize killing for exp, ie a defeat (chasing the thing off, or causing it to surrender should be enough in many cases to acheive an exp win. Conversly penalty for dying is MUCH greater. The goals are as follows: 1) Simulate a planet that orbits a sun that has seasons and real weather. 2) Simulate growing and changing plant life 3) Simulate animal life that uses and eats the plant life 4) Server engines should be clusterable, targeting about 10,000 concurrent players 5) Players should be able to climb anything, dig anything, go anywhere, (not magically prevented of course) find and use real things as you might expect them to. 6) IE a much more detailed simulation environment. 7) Investigate the use of voxel rendering if or where appropriate. 8) As many physical laws as can be simulated should be. IE Weapons should wear out. Sound (talking to party members) should draw attention of creatures. Smell should too, wind should work. You get the idea. How to do this? Well that will the fun part :) I fully expect that we will need hardware about an order of magnitude better than what we have now to be able to attempt this, ie bandwidth and graphics and compute speeds. But i think it will be doable, remember we are *simulating* :) I know that almost everything i have done here can be improved upon, and that maybe the whole architechture should be changed, but then thats part of the goal: learning how to do this stuff. Should be fun :) The website is www.viagloria.com The email is eric@viagloria.com or ejkrejci@swbell.net This project will be GPL'd. IE it will be copyrighted by its authors and contributors, but will be released under the GPL. See accompanying license.doc for more info. NOTE: The client has been based on several Microsoft Example code pieces from their sample directories. I would like to state for the record that I fully intend to honor any and all copyrights that Microsoft, or any other party, may have on work that I have used here. If the use of certain sample peices of code turns out to be not authorized (as I intend to release all MY work under the GPL) I will work with Microsoft to remedy the situation, even if I must remove the code completely from the client. Again I state my absolute willingness to adhere to all applicable laws.