A better approach could be memory mapping the whole map. The kernel will handle loading/unloading/caching automatically. The only important factor is to use a chunked format so you get a better page locality. This means cut the W*H map into N*N pieces, like it's done for large images in image editor programs.
Example: map[A][C][D] where A=W/N, B=W/N, C=W%N, D=H%N
Viktor
How many tiles was ultima online? How big was it?
In my opinion, memory mapping sucks for real-time applications.
The problem is that the thread that makes the reference has to stall, waiting for disk, before it can make progress. Typically, in games, you want to know that reading a tile out of your map is not going to take 10 milliseconds.
Instead, I would recommend using asynchronous I/O of some form to pre-load map areas that are close to the currently active area, so that the map is always loaded when you need it.
In some OS-es, you can get around the memory mapping problem by "wiring" certain pages into RAM, although it's sometimes hard to tell when the wiring has taken effect -- your management of that becomes as hard as the management of just reading a file into memory, so you might as well stick with the asynchronous or threaded file approach (which is more portable in concept).
The problem is that the thread that makes the reference has to stall, waiting for disk, before it can make progress. Typically, in games, you want to know that reading a tile out of your map is not going to take 10 milliseconds.
Instead, I would recommend using asynchronous I/O of some form to pre-load map areas that are close to the currently active area, so that the map is always loaded when you need it.
In some OS-es, you can get around the memory mapping problem by "wiring" certain pages into RAM, although it's sometimes hard to tell when the wiring has taken effect -- your management of that becomes as hard as the management of just reading a file into memory, so you might as well stick with the asynchronous or threaded file approach (which is more portable in concept).
According to Raph Koster, UO's map was built primarily of 8x8 "chunks" of tiles seeded by a central "egg" which provided natural-looking distributions of resources, splats and other tile properties.
One would therefore assume that the chunks were paged in and out of memory as necessary, and designed to be very lightweight network-wise.
Storing your entire game map in one single giant array is almost definitely a bad idea.
One would therefore assume that the chunks were paged in and out of memory as necessary, and designed to be very lightweight network-wise.
Storing your entire game map in one single giant array is almost definitely a bad idea.
Quote:Storing your entire game map in one single giant array is almost definitely a bad idea.
Depends on how big it is, and how you do zoning or clustering.
Suppose a single zone will never be bigger than, oh, 4000x4000 tiles, and there aren't more than 4,000 tile kinds in a single zone (which gives us room for tile plus status bits in a 2-byte value), then that'll only be 16 MB. Certainly quite feasible for modern computers. In fact, I dare you to create a playable, interesting zone that comes anywhere near 4000x4000 tiles in size :-)
is it true the server application only cares about tiles that are boundaries of some sort.. a rock, wall, end of the map, a player, npc..
i'm coming to think i should never create a tile in memory server side if nothing occupies it...
is this thinking correct?
i'm coming to think i should never create a tile in memory server side if nothing occupies it...
is this thinking correct?
Quote:Original post by luzarius
is it true the server application only cares about tiles that are boundaries of some sort.. a rock, wall, end of the map, a player, npc..
i'm coming to think i should never create a tile in memory server side if nothing occupies it...
is this thinking correct?
There will always be scenery in it. And you want the same scenery when you go back to it later.
Look into 'infinite universe' methods if you want to understand more about generating worlds 'on the fly'. Unfortunately a completely random world (like based on randoms seeds from coordinates) wind up being random. To build a cohesive world (like with realistic patterns of continents/rivers/cities/communities) it takes fairly complicated generating functions and manually placed seeds or tuned coefficients (like for fractals -- most patterns are rubbish and the good looking ones are hand picked).
You can have it be generate from standard overlapping templates with variations
for much of the world (ie- most of the ocean surface looks the same...) and a coarse level seed map to control the terrain placement. Specific high detail or specially (hand) detailed areas can be premade and stored in full detail.
Similar to the terrain locations of Mobs (mobiles) spawn points can be based on
terrain features and added as needed (and then evaporate after the player moves far enough away). With complex generator functions, entire towns could be built up when needed -- but if you allow changes caused by players actions, you will either have to save the result data fully or figure out a patching mechanism to recreate the changes made.
Of course with a MMORPG, players are crawling all over the fairly small world so it doesnt pay to do this 'on the fly' building. In future the world may become large enough to require a generating system (at least to fill in fine details that would be prohibitive to store if a large world).
[all the information presented here about ultima online is from quite a long time ago, several years, which was when i last played it]
Since this thread is rotating around a specific game, ultima online, it just happens to be the case that 'constant' things, like rivers, oceans, general map forms, dungeons, ect, where all saved in their complete form on the client side. This even goes as far as to say that things like trees, houses, tables, candles sitting on the tables, anything that was considered by the game to be constant and server [or shards in ultima's case] independant, was fixed within the client's version of a given map [these constant things could not be move by the player, many of them could not even be used by the player, only identified by a single click, which showed the objects name, like 'a chair']. Things that were dependant, even if unmovable, were not saved on the client side, but a truely huge amount of the data was saved.
Ultima online had no random dungeons, and as far as i know, entire maps were never transmitted.
Since this thread is rotating around a specific game, ultima online, it just happens to be the case that 'constant' things, like rivers, oceans, general map forms, dungeons, ect, where all saved in their complete form on the client side. This even goes as far as to say that things like trees, houses, tables, candles sitting on the tables, anything that was considered by the game to be constant and server [or shards in ultima's case] independant, was fixed within the client's version of a given map [these constant things could not be move by the player, many of them could not even be used by the player, only identified by a single click, which showed the objects name, like 'a chair']. Things that were dependant, even if unmovable, were not saved on the client side, but a truely huge amount of the data was saved.
Ultima online had no random dungeons, and as far as i know, entire maps were never transmitted.
Quote:Original post by hplus0603Quote:Storing your entire game map in one single giant array is almost definitely a bad idea.
Depends on how big it is, and how you do zoning or clustering.
Suppose a single zone will never be bigger than, oh, 4000x4000 tiles, and there aren't more than 4,000 tile kinds in a single zone (which gives us room for tile plus status bits in a 2-byte value), then that'll only be 16 MB. Certainly quite feasible for modern computers. In fact, I dare you to create a playable, interesting zone that comes anywhere near 4000x4000 tiles in size :-)
You mean 4000 x 4000 x 2 bytes == 32 meg......
(just a bit bigger and still within most low end computers these days...)
I actually am doing something like this on a 'create zones on the fly' type system that has a large array of seed values in_mem for the 'infinite universe' style generating functions (precanned static seed data so the land forms have some cohesion....)
32meg these days is only a tiny part of memory (even after Billy Gates Bloatitus has done its worst...)
Quote:Original post by Peachy keen
[all the information presented here about ultima online is from quite a long time ago, several years, which was when i last played it]
Since this thread is rotating around a specific game, ultima online, it just happens to be the case that 'constant' things, like rivers, oceans, general map forms, dungeons, ect, where all saved in their complete form on the client side. This even goes as far as to say that things like trees, houses, tables, candles sitting on the tables, anything that was considered by the game to be constant and server [or shards in ultima's case] independant, was fixed within the client's version of a given map [these constant things could not be move by the player, many of them could not even be used by the player, only identified by a single click, which showed the objects name, like 'a chair']. Things that were dependant, even if unmovable, were not saved on the client side, but a truely huge amount of the data was saved.
Ultima online had no random dungeons, and as far as i know, entire maps were never transmitted.
They later had a patching mechanism (or maybe even early on as a 'house' changed the clients view and navigation map). Items could be added to the map and the objects were downloaded 'on the fly' as you walked within view (actually it was probably an extension of the code that made dropped items viewable).
I remember watching the delay when large numbers of patch objects -- like on building roofs or inside (they even changed the server code that made items in a house only be transmitted to the player when the player stepped inside a house -- it was slowed people just walking by down so much ).
Later they really overworked that patching mechanism when the added the building block houses (was that 5 years ago??)
The UO mechanism was so stiff that when you entered a dungeon you actually were teleported to a different section of the large 2D array (you can see this on some of the world maps people made).
I am still amazed at what they were able to do with the 2D isometric interface and how little most of the glitzy 3D games actually added. Even though UO botched many things (poor management decisions and wasted efforts like UO2 and UOX) its still was an amazing game.
Not entirely on topic, but it was a great resource to me...
The RunUO project has recreated the server side of Ultima Online. You can download the server and run your own Ultima Online game...kinda fun for nostalgic reasons. The biggest thing is that the code is available for you to use, look at and modify. Going thru their code and how they recreated the server is very educational. It was done in C# and requires .NET, however it still reads well and is clearly commented...and if you dont have C#, MS has a free version C# Express to DL and use.
All in all its a great resource and it should help with mapping issues as well as many others that may arise.
So just ask yourself wwUOd...
oh ya http://www.runuo.com is the link
The RunUO project has recreated the server side of Ultima Online. You can download the server and run your own Ultima Online game...kinda fun for nostalgic reasons. The biggest thing is that the code is available for you to use, look at and modify. Going thru their code and how they recreated the server is very educational. It was done in C# and requires .NET, however it still reads well and is clearly commented...and if you dont have C#, MS has a free version C# Express to DL and use.
All in all its a great resource and it should help with mapping issues as well as many others that may arise.
So just ask yourself wwUOd...
oh ya http://www.runuo.com is the link
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement