Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

To start, I have a good amount of background in networking (hardware, routers, ex.) but very little knowledge past the basics of network programming. This may seem like a stupid question, but I want to know what I am getting myself into while fathoming the implementation of multiplayer in my game.

I am creating a tile-based world, which is generated through a simple 2D Array. Let's say something like World[100][100], for simplicity's sake.

Currently, the render method only renders the tiles based on the resolution of the window, plus one tile (for smooth rendering during movement.) No matter how large the world is, (10x10, 1million x 1million) the rendering is flawless in performance.

The gameplay needs nothing more than to know what is in the currently visible (rendered on screen +1) and at the most possibly SOME information of tiles in an area around the player.

So anything more sent by the Server wouldn't be the full tile information. Ex. Items laying on the ground, ground type, trees, etc. would not be important in the area outside the player's view, but would only be what the Client/Player needs to know about in those tiles. (Ex. Ultima Online's 'incoming names' where players could know a Character [player or monster] was just beyond the tiles in their rendered view.)

I do not know very much about networking, so perhaps as I learn this might answer my question. However, I am curious if this is a feasible solution or if the idea is simply laughable.

The information being sent would be about a 10x15 area of tiles, and each tile holds information about what is on the tile. More efficiently, everything would be an Object, where the tile holds all the Objects on the tile. Ex. Tile[4][4] holds Sword#23452, Rock2, Tree5, Player3, Monster4.

Empty tiles would send nothing more than terrain type [Grass, Sand, Water] if not already loaded during Initialization/Load. Some tiles would have a handful of objects [Tree2, Sword#924, Gold, Corpse, Rock3].

So I cannot imagine that a tile would have very much information to send to the Client from the Server, since the Client mainly only needs to know the Texture that needs to be loaded and Position to place it on screen. Position being only two integers and Texture being one integer for a list of files to tell the client to render.

At the craziest, the Server would have to send 150 tiles with information of only a handful of Objects OnLOAD, and from then on update only changes to tiles (if any) and any new tiles (10 to 15 everytime a player moves in a direction) and the direction of movement for characters on screen (so the client can simulate smooth movement between tiles).

I assume I am correct in thinking this is an incredibly low amount of information being sent over the internet or between peers, so it should have little problems with performance even over laggy connections? Or am I so ignorant of networking that my mind will be blown when I finally get around to opening up my book on multiplayer networking?

If it is a very low amount of information being sent between Client/Server, would it make more sense to simply load the entire World on Initialization? Or 'Map' if the World is excessively large. And then after LOAD, send only tiles which are updated?

I am still pondering how I should specifically deal with data. The book I am using as reference wants me to have a Linked List, where I add and remove objects, so everything is a bool. "Is there a Character? Is there a Tree?"

I was thinking of a different approach, such as a container which holds objects, and Server logic that sends only what is required to tell the Client what to render. Possibly with objects that hold networking information within itself, which is sent out when called for by the Server.

share|improve this question
    
I suggest you take a look at freemmorpgmaker.com, this engine helped me a lot when I just started out. The script is relatively simple and a lót of fun to work with. The code taught me everything I needed to know to create my own 2D engine/game. What you should not learn from them is how to secure your server/client. –  Nick Jun 3 '13 at 9:35

3 Answers 3

You are on the right track.

Consider Minecraft. Minecraft only loads the areas (also called chunks) immediately surrounding players. This is how the server is able to run without running out of memory, and why clients don't get bogged down from network traffic.

If it is a very low amount of information being sent between Client/Server, would it make more sense to simply load the entire World on Initialization? Or 'Map' if the World is excessively large. And then after LOAD, send only tiles which are updated?

This is exactly what you should do. Only send the data that you need to send.

  1. When a client joins, send it a chunk of the tile map (or all if it, if you're dealing with small areas)
  2. When the player tries to modify a tile, send that data to the server.
  3. When a tile changes state, send a packet with that information to all relevant clients.

If you're just sending a 2D array of tile IDS, the size of the data can be very low, especially if you have less than 256 different tile types. In that case, you could use a single byte (or unsigned char). So if you're sending 100x100 tiles to the player, and each tile only consists of a single byte... You get the idea. It is not a lot of data.

The Minecraft community has done a wonderful job documenting its protocol: http://mc.kev009.com/Protocol

http://www.minecraftwiki.net/wiki/Classic_server_protocol

share|improve this answer
1  
wow, thank you very much! This is a big confidence boost that I was told I am on the right track, when I know so little. It tells me that I am understanding things correctly and engineering to the best that I can. I am confident that if I keep learning, I will do adequately enough. It is so satisfactory to hear positive advice, and no "You are doing it wrong!" lol :) –  user31435 Jun 3 '13 at 4:35
    
It took me a long time before I gathered the nerve to take multiplayer and 3D games. :) –  Nick Caplinger Jun 3 '13 at 7:15
    
Also, positive advice is what this community thrives on. I encourage everybody to contribute in any way they can! –  Nick Caplinger Jun 3 '13 at 7:16

It is generally a good idea to only send the information to the client which is supposed to be shown to the player. Following this principle reduces network traffic and prevents cheating.

But keep in mind that when the player moves their character, you certainly want to start the move on the client-side before receiving the confirmation from the server to make the game appear less laggy and more responsive. That will likely mean that you also want to start scrolling the screen to an area which isn't loaded yet. This forces you to leave this part of the map blank and replace it with the actual world when it has loaded. That would be quite an immersion-breaker. For that reason you should preload the area in a certain radius around the players screen.

The size of the preloaded area depends on how fast your players can move and how long their average latency will be.

share|improve this answer

The amount of data you are sending from the Server to the Client can be INCREDIBLY insignificant. If this is all you need to send, I would vehemently suggest loading as much as you can on Load, so it is even less data required. The amount sent on load will be small enough to justify the load time, the memory usage will be nearly non-existent unless your world is ridiculously oversized, and you will need to update almost no data at all.

I imagine you could also do some neat tricks to optimize lag prediction which compensates for the average delay a user experiences, allowing for predictable movement with characters.

Also prioritizing the insignificant data with Character movement and Character actions/reactions being highest in priority can help to make sure even laggy players feel very little lag.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.