creating a game engine that supports multiplayer...
I would really like to create a small multiplayer rpg. I actually am part of a small team (a few friends that want to create games) which consist of artists, designers and musician. I am the only programmer however, so I have a metric ton of work. The project that we want to create is relatively small in scale, sorta like this game
The only problem is, I don't know how to go about desiging a game engine that supports networking. I deffentially will use a 3rd part lib such as raknet. Im just at a loss on how to go about binding the npc's and such with the lib.
I was going to post this in the multiplayer programming section, but I think it's more of a game design problem since the networking component should be designed in the beggining of the project. Should all of the people on the server be constantly updated by the server? and on the client side, when do you not update other players, when there not visible?
I know that this is a pretty complex problem and is probably hard to answer, im just looking for soem advice or maybe some linx to some good articles.
Thanks a lot.
~Jason
It's quite a major undertaking, and a major design decision, as you say. The best way I can think of is getting a good book, because a post isn't gonna be enough by a long shot.
The usual way is doing a server-client architecture. It's gonna be quite painful if you never done things like that before :)
The usual way is doing a server-client architecture. It's gonna be quite painful if you never done things like that before :)
I recommend grabbing a library like HawkNL, sitting down, and making lots of client-server examples. Like, lots. Client-server tic tac toe, client-server chat, etc, etc, because otherwise you will make so many mistakes in implementation it will become suicide-inducing.
I've done this before in a game project at school. We made a connect-4 game.
We abstracted the player object into an input-player, networked-player and AI-player.
The player told the core when it made a move. So, the input player would calculate the mouse position and translate it into a column and tell the core about the column. The core would then check if it was the players turn and do the move.
The networked player worked the same. It would receive data from the network, translate it to a column, and pass it to the core.
And the AI player calculated a column and told the core of the result.
After a move was made by a player, it was relayed to all other players.
For instance, if the game had a networked player, and an input player, and the input player made a move, the networked player would be notified of that move. The move would be sent to the other computer on the network and the game state would be updated on the other computer.
As I see it, you need to abstract your players to receive their information from several sources.
For example, on the game server, 100 players are active. One of which is controlled by you at home. The client you have has 99 networked players (those that receive their orders from the remote server) and one input player (that receives orders from your keyboard and mouse). Your client does not need to know where the orders come from. The players, whether they are networked or local, tell your core of their status.
And when you move your own character locally, you tell all other networked players about this update. These will send the change to the server for you (or, only one of them, but I'll elave that up to you).
Next problem, how do you arrange multiple networked players to receive from the same server?
Creating a socket for every player is BAD.
You have one socket connected to the server. When the server notices a player has moved, it sends a message that contains an identifier to tell which player has moved. You receive that message, you extract the identifier, and you give it to the corresponding networked player.
Your layered design would look as follows:
- Players
- identifier to player translation
- protocol interpreter
- networking module
The networking module would contain the socket. If this guy receives information, it passes it on to the interpreter. It looks at what kind of information is received. For example, it can be a message that contains chat information, or, the update of a player position. If it is a player update, the message is given to the identifier-to-player-translator. This sees to which player the identifier is connected to. After that, it is passed on to the actual player, who will notify the core of any updates.
It works the other way around too. If your local layer has been updated, it notifies the translator, which translates to a identifier, which then passes it to the protocol interpreter which will create a network message of it, which will the send it to the networking module which will send it to the actual server.
This is a lot of information, but keep in mind, your internal game logic should NOT change if a player is networked or local. A player is a player, regardless of where it gets its information from.
Here is the connect4 project. It is accompanied with a slightly simplified class diagram. You will be most interested in the left-bottom of it where the players reside.
We abstracted the player object into an input-player, networked-player and AI-player.
The player told the core when it made a move. So, the input player would calculate the mouse position and translate it into a column and tell the core about the column. The core would then check if it was the players turn and do the move.
The networked player worked the same. It would receive data from the network, translate it to a column, and pass it to the core.
And the AI player calculated a column and told the core of the result.
After a move was made by a player, it was relayed to all other players.
For instance, if the game had a networked player, and an input player, and the input player made a move, the networked player would be notified of that move. The move would be sent to the other computer on the network and the game state would be updated on the other computer.
As I see it, you need to abstract your players to receive their information from several sources.
For example, on the game server, 100 players are active. One of which is controlled by you at home. The client you have has 99 networked players (those that receive their orders from the remote server) and one input player (that receives orders from your keyboard and mouse). Your client does not need to know where the orders come from. The players, whether they are networked or local, tell your core of their status.
And when you move your own character locally, you tell all other networked players about this update. These will send the change to the server for you (or, only one of them, but I'll elave that up to you).
Next problem, how do you arrange multiple networked players to receive from the same server?
Creating a socket for every player is BAD.
You have one socket connected to the server. When the server notices a player has moved, it sends a message that contains an identifier to tell which player has moved. You receive that message, you extract the identifier, and you give it to the corresponding networked player.
Your layered design would look as follows:
- Players
- identifier to player translation
- protocol interpreter
- networking module
The networking module would contain the socket. If this guy receives information, it passes it on to the interpreter. It looks at what kind of information is received. For example, it can be a message that contains chat information, or, the update of a player position. If it is a player update, the message is given to the identifier-to-player-translator. This sees to which player the identifier is connected to. After that, it is passed on to the actual player, who will notify the core of any updates.
It works the other way around too. If your local layer has been updated, it notifies the translator, which translates to a identifier, which then passes it to the protocol interpreter which will create a network message of it, which will the send it to the networking module which will send it to the actual server.
This is a lot of information, but keep in mind, your internal game logic should NOT change if a player is networked or local. A player is a player, regardless of where it gets its information from.
Here is the connect4 project. It is accompanied with a slightly simplified class diagram. You will be most interested in the left-bottom of it where the players reside.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement