Game server

Is this a real time game? Or is it slower, turn based or RTS? You should take a look at the Multiplayer and Networking Forum FAQ, it contains links to descriptions of how commercial games have handled this (see Question #12).

One critical flaw in your system is that it is trivial for clients to cheat unless your server is authoritative over position, velocity and most other data (e.g. most games don't bother making the server authoritative over client orientation because the client can move their mouse too quickly for any realistic validation).

Generally SQL is used for long term data storage, so if your game features user accounts with items, achievements or character stats which you want to retain between games then yes this might be a suitable mechanism for managing such data.

Since your game is written in UDP can it handle packet loss, packet duplication or packet re-ordering?

it is a real time game. My concern is mostly on what platform the server should run. Maybe WindowsXP will run the server as smoothly as a Windows Server OS will, thats what I want to know. And instead of dwelling in to SQL, why not take the shortcut and make my own text files which stores "account info" each in their own account folder on the harddrive.

I doubt there will be much of a difference between running on Windows XP or running on Windows Server. What is your definition of "a large number" of players?

Managing account information in a text file is indeed a shortcut, but it could hurt you in the long run. It depends on the size and scope of your game. If your server can edit the file (e.g. you have a UI for adding accounts) be aware of corruption issues. Using the "write everything to temporary file, atomic OS rename" technique for managing the data might suffice for small number of users.

If you plan on dealing with lots of users, the concurrency and correctness will force you to write something ACID compliant anyway, so you'll have re-written part of a database but you won't get a lot of cool features such as a flexible query language and the ability to create secondary applications to manage the users. For example, with a SQL solution, you could make a website for account management, and your game server need only check it during logins. Complex interfaces for banning users could be offloaded from the game server, possibly even to a separate physical machine.

The other questions I posed earlier are important, you should really research them.

Hi again

Will a timestamp suffice for sorting UDP packets? Simply put, if a packet arrives with pos/vel info for an object is older then another packet with the same info, just ignore it.

Also I don't find a good awnser for how often the server should update clients with data(i.e send a packet). It is a Diablo style game, PvP is important.

Thanks again

it is a real time game. My concern is mostly on what platform the server should run. Maybe WindowsXP will run the server as smoothly as a Windows Server OS will, thats what I want to know. And instead of dwelling in to SQL, why not take the shortcut and make my own text files which stores "account info" each in their own account folder on the harddrive.

Windows XP is fine for small scale servers, the main limitation is that you can't use more than 1 cpu (home edition) or 2 (professional) (IIRC both support a maximum of 32 cores so even with todays multicore cpus XP will be just fine), RAM is also quite limited in the 32 bit version (~3GB), There is a limit on half open outgoing tcp connections but normally that shouldn't be a problem for a server (AFAIK This restriction does not exist in the consumer editions of Windows 7)

Windows Server can handle 1-64 cpus (depending on what edition you choose) and Linux up to 4096 , unless you are making an MMO you will be fine with any consumer OS. (If you are making an MMO you should worry about getting your software to scale before you start worrying about finding an OS that can scale with it).

as far as SQL vs textfiles goes, textfiles is not a shortcut, its far harder to write a robust system using textfiles than using a database.

As for how often you should send updates to the players.. it depends on the game, it could be anything between 15 and 100 times per second for a realtime game, around 30/second should be a good value to start with, reduce if possible (Lower updaterate = less bandwidth needed) increase if necessary, for a more complex game with a large number of players you might want to keep the update rate dynamic and send updates for entities that are close to the player in question more frequently.