🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to Networking and Multiplayer

Client/Server Tile-Map Considerations

MatrixCubed · 2000-12-21T19:54:20

This really didn''t get a response in the Game Development section, maybe it will spark interest here... I came across a particular problem when designing the server portion of my game. On the client side, the player sees only one part of the map at one time; loading the map dynamically is not really a big thing. However, the server might need to keep track of a lot of different characters all over the place. With a map file of 4096*4096 at 6 bytes per tile, we''re looking at a 96mb file. I thought of a couple of resolutions: 1 - load the entire map into memory 2 - load portions ("regions") based on character occupancy 3 - split the map up into sections (groups of regions) and distribute server load across many machines Of course #1 requires an awful lot of resources for areas that mightn''t be accessed all at once. So we waste memory and CPU cycles maintaining the entire map. I figure #2 would be a good starting design choice, since it''s unlikely that a character will be at EVERY location that requires memory at once; this allows the server to allocate/deallocate dynamically, and avoid wasted resources. But in the event that characters DO overload the server (that means only 1024 characters online at once, ALL spread out over the map evenly to maximize server load) we''re looking at server crash, lost items and character advancement, and general playerbase upheaval. So what about a combo of #2 and #3... the final option lets many servers handle the game (in the event of a large player base), or one server handle the entire game (for a small player base). You''d have a multi-server configuration as below: Server 1 { NorthBoundary=0 WestBoundary=0 EastBoundary=4095 SouthBoundary=2047 IP=24.67.231.19 } Server 2 { NorthBoundary=2048 WestBoundary=0 EastBoundary=4096 SouthBoundary=4096 IP=24.67.231.36 } You could add different IPs, ports even, plus maybe a custom password authentication, per server (for total servers > 1) or just host the whole thing on one machine... and with #2 map handling in effect, you don''t have to worry about overloading the server (for total servers = 1). Comments? MatrixCubedhttp://MatrixCubed.org

Networking and Multiplayer Programming

Started by MatrixCubed December 07, 2000 07:09 PM

23 comments, last by MatrixCubed 23 years, 6 months ago

MatrixCubed

199

Author

December 18, 2000 08:42 AM

Definitely, but with so many gamers moving to highspeed connections, I doubt it would be significant to these. The main concern I guess is modem users.

This update might be best done upon logon, as well as "vicinity" updates if you happen to be standing right where a map update is performed. I guess it''s not really much different from adding updates to the server''s local item list that are sent to clients only when they enter regions.

On that note, perhaps just (as you stated) a list of regions that have been changed... regions may be edited as much as necessary, and if a ''save'' operation occurs that changes even one tile in a region, that region is marked as ''dirty'' on the server... anyone entering that region gets the entire region''s contents sent to them (around 20k) and life goes on. Not too much latency, but then there is nothing to download as soon as you log on.

MatrixCubed
http://MatrixCubed.org

[ Odyssey Project ]

Shannon Barber

1,684

December 18, 2000 06:35 PM

Its going to get bandwidth heavy on the server...

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Succinct

169

December 20, 2000 04:34 PM

I''m not an authority on this topic, so i don''t have much to say, but what i did want to remind you guys of is that on uo, when you hit a server boundry, you knew you did.

no npc''s would follow you across it.
no npc''s would attack you if you didn''t melee w/ it.

but they''d stay right there, as if they were still in follow mode.

the trick? drag a will-o-wisp to a corner boundry and tear it up w/ magic. or, take some hits from it and run back. both would raise skills dramatically.

just a smidgen of cheating that is possible w/ the uo implementation of multiple servers, so be careful, k?

-frank

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have no name that you may call me. I am merely Succinct.
~Succinct Demos Online~
"Hey, where''d that display list rotate off to now?"
-(Drop me a line here)-

-- Succinct(Don't listen to me)

fokiali

122

December 21, 2000 03:55 AM

Maybe you could keep the map compressed in memory and just uncompress the portion you need. Possible having an uncompressed cache of frequently used portions.

--------------------------------------

"Follow your heart, do what your passionate about, and in the long run you''''ll succeed in ever way that matters."

--------------------------------------

MatrixCubed

199

Author

December 21, 2000 07:54 PM

I''ll certainly keep that in mind when planning what functions servers can call between eachother, like ...

Server->MovePlayer(server, player);Server->MoveMobile(server, mobile);Server->SendItem(server, item);

... I guess these sorts of checks would be done during normal move routines, on the server side, so that the server automatically moves players seamlessly (and so that high-end machines or ones with faster connections won''t notice the transition much) etc.

I don''t like the idea of compression, because there are so many checks to perform per connected player... I''d rather stick to something simple (!) like the aforementioned region management. Plus I haven''t a clue how to design a compression system like that.