-1
\$\begingroup\$

How to construct my multilayer mode for my Delphi game? For LAN I use UDP server/client. But for internet I think UDP is useless.

I have in mind something like:

  1. The host create SQL database and store the game data.
  2. The clients connect via TCP/IP and sent requests in that database to get current state of the game.

Or is there a better option for internet multiplayer?

\$\endgroup\$
3
  • 3
    \$\begingroup\$ There's no such thing as a "general" approach to multiplayer. It depends heavily on the type of game you're creating. You should therefore make your question more specific. \$\endgroup\$
    – bummzack
    Commented Mar 28, 2012 at 7:52
  • \$\begingroup\$ Well the game is real time fps like... \$\endgroup\$
    – TreantBG
    Commented Mar 28, 2012 at 8:29
  • 5
    \$\begingroup\$ "But for internet UDP is useless i think." WAT \$\endgroup\$
    – o0'.
    Commented Mar 28, 2012 at 9:17

2 Answers 2

9
\$\begingroup\$

When it comes to making a multiplayer FPS, this is a pretty amazing resource: https://github.com/id-Software

That is the full source code to every one of id's games up through Doom 3.

There is no reason to go with a different implementation of how it works over a LAN vs over the internet. UDP is definitely the way to go, I don't know of any FPS that didn't use that protocol for it's network play. You can probably make TCP work, but ultimately UDP will allow you to better handle interruptions. Transacting through a database is going to introduce far more latency then will be acceptable in an action game, you need to have the server delivering updates directly to the clients.

For a lot more information in general, check out this collection of articles: http://gafferongames.com/networking-for-game-programmers/

\$\endgroup\$
1
  • \$\begingroup\$ 10x that helped \$\endgroup\$
    – TreantBG
    Commented Mar 28, 2012 at 9:46
2
\$\begingroup\$

UDP is okay, you have exactly the same problems as you would have on a LAN but with the bonus that you can do NAT Hole punching

TCP/IP is easier to use (no packet losses and everything comes in the expected order) so go with that if you think it is easier for you.

For the "how does it work", it is a correct start but you seems to have forgotten the "server" or some of its work namely to act as a buffer between the database and the client:

Client negotiates a login (server checks database for login, pass, playerID etc) Server loads up the new player from database to memory and sends That off to the client.

Every change will primarily affect the memory (I use a class Player that holds all the data of a character for example) and only rarely the server will save off the memory to the database (for example, the minimum required is when a player quits the game).

I use the same technique for items, they get checked out too by the server and 'saved' in the player class. Every time the item changes owner (I give you an apple) I reflect that instantly and then I save off the new state to the database, this way it is fast and secure and fast(I can send back information before even touching the database).

Another thing is of course the need to add another 'layer' for lag compensating. This doesn't need to be something extremely complicated but some data (like positions) should not be updated directly when the client gets information from the server but saved off in another variable and the client position can then use some sort of lag compensation like interpolation or dead reckoning

Good luck and as a side note, what's the game about?

\$\endgroup\$
1
  • \$\begingroup\$ Action fps - 2d cartoon style - very pretty \$\endgroup\$
    – TreantBG
    Commented Mar 28, 2012 at 8:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .