Game server design

[supergillis]

Hello!

I am developing a game server for an existing game. It's a project that I started for fun and also for learning how to work with servers in Qt.

It's a game server for an RPG game. I'm not really sure on how to implement some things like:

• A player gains hitpoints (and other stuff) each X seconds,
• A player can click on the map and then the server should generate a path,
• A player attacks someone and hits him each X seconds,
• ...

I have never made a server with Qt so that's why I am asking for help. These are the designs I could think of.

Design 1
There is one instance of a game class (handles player movement, keeps track of items, ...). There is a QTcpServer that listens for connections. When someone connects, a QTcpSocket is made. That socket checks for incoming data and checks what to do with it (move player, say something, ...). These actions get executed by QtConcurrent (for example QtConcurrent::run(&Game::instance(), &Game::playerSpeak, player, message)).

Design 2
Again, there is a game class and a QTcpServer. When someone connects, a new SThread is made containing the QTcpSocket. The socket checks for incoming data (asynchronously) and checks what to do with it. The action gets executed (for example Game::instance().playerSpeak(player, message)). The game then contains mutexes in functions that change global or class variables.
But will this work? The game is created in the main thread and the function call is made in the socket thread. Will the function be executed asynchronously? And what about signals and slots?

Also, I need to check the player each X seconds (for example when attacking). Should I need to make a thread for each player, or should I just run a QTimer in the main thread that executes Game::playerAttack each X seconds?

I hope my explanation is clear and that someone can give me some advice :).
Thanks in advance!

Gillis

[Archimedes]

Here you'll find a really nice faq that will give you a start, as a lot of your questions are answered there(not Qt oriented but it's the same idea). Also, in that site you'll find useful material about gaming programming in general.
Btw what's the existing game name?

[supergillis]

Thanks, some of those FAQ's were helpful! Like this one:

Q10) Should I spawn a thread per connection in my game code?
A10) The short answer is "likely no." The longer answer is that, if you're using UDP, you should only need a single socket, from which you can read a packet, process a packet, repeat. If you're using TCP, you will need a socket per player, but the players are likely sharing and affecting a single world state inside the program, which needs to be protected by locking; thus, the extra threads would just end up blocking on locks anyway, so using select() and reading out what's there, then processing it, is recommended. Some users find "co-operative threads" or fibers to be a nice middle ground, because it gives some of the advantages of real threads (a stack per context) without the locking overhead (because yield is explicit).

I guess this means, in Qt, that it's best to use QtConcurrent instead of making a QThread per player.

This is what I got so far:

• Gaining hitpoints: I could make one QTimer in the game class that loops through all players and gives them hitpoints.
• Attacking: When a player, or creature, starts attacking, a timer is made for that specific player. So it attacks the target each X seconds. When he stops attacking, the timer stops too.
• Generating the path (not sure about this): Make a separate thread to calculate the path? When finished, send a signal to the game and move the player (or something like that). Or I could make one hell of a fast algorithm and do everything synchronously :p

The game is called Tibia (http://www.tibia.com). There are lots of projects made for it, like OTServ (http://www.otfans.net/) and some Tibia specific programming forums like http://www.tpforums.org/.

[Archimedes]

What if you had a world timer? I mean a timer responsible for "moving" the world, eg. sending info about monster/NPC position.
In general, you could follow an event driven logic. Keep a constant number of threads, get some network events (eg. the player is attacking etc), divide the work to be done to the threads and then send back the result (eg. creep killed and gained xp). Also you could make use of the proactor design pattern, take a look at the implementation of Boost.Asio.
About the path generation, this is a problem known as shortest path problem with many solutions, but 1st you must know how the map is represented. Using the event driven logic, let's say you got the event of a player that enters the agro range of a creep. Assign a thread to run the algorithm for the shortest path between player and creep position. Then start updating the position of the creep according to the solution of the algorithm every X msec (the world timer I mentioned at the start). And the above will be rerun till the creep contacts the player.