09 Jun, 2009, quixadhal wrote in the 101st comment:
Votes: 0
What's difficult about using a linked list of persistent objects for wilderness areas? When instantiating a room at a coordinate set, search the list for any matching entries and clone those objects into the room. You simply need a way to distinguish between someone absently dropping junk and intentionally placing something for future recovery (which might be by object data, or by the way they place it, such as "bury" instead of "drop").
09 Jun, 2009, Skol wrote in the 102nd comment:
Votes: 0
Hm, nice idea actually Quix, could keep track of timers and everything in there.
I think yeah, place/bury/hide or some command to differentiate.
09 Jun, 2009, flumpy wrote in the 103rd comment:
Votes: 0
David Haley said:
Well, I didn't say the AI had to be sophisticated..


Sorry David, I seem to have been putting words in your mouth :redface: Dunno what happened there.. was sure you said "sophisticated".. :sad:
09 Jun, 2009, Runter wrote in the 104th comment:
Votes: 0
Scandum said:
Runter said:
Cause every mud uses multiple locations in one room, amiright?

Using a classic character grid for a 32,000 x 32,000 wilderness (so 1 location per room) you'd still need 1 gig of memory, so it's pretty much a given that a mud with that many locations uses tiles.

What exactly is your argument?


I'm just not feeling the grid of pointers. Or the grid at all, really. It probably works fine for a smaller wilderness, but even then I think I would try to use a more elegant solution. To be honest, at this point, my issue is how to give readily available access to data on nearby locations. (Like terrain type) Dynamic instantiation from a database could help solve this, albeit slowly.
09 Jun, 2009, KaVir wrote in the 105th comment:
Votes: 0
Scandum said:
Kavir has 32,000 x 32,000 locations, not 32,000 x 32,000 rooms. Assuming he has 40x40 tiles that's only 800 x 800 x 4 which is roughly 2.5 MB.

My implementation was 512x512 tiles, which represented 5120x5120x40=1048576000 rooms.

quixadhal said:
What's difficult about using a linked list of persistent objects for wilderness areas?

I had too many objects to store in memory.
09 Jun, 2009, flumpy wrote in the 106th comment:
Votes: 0
Runter said:
I'm just not feeling the grid of pointers. Or the grid at all, really. It probably works fine for a smaller wilderness, but even then I think I would try to use a more elegant solution. To be honest, at this point, my issue is how to give readily available access to data on nearby locations. (Like terrain type) Dynamic instantiation from a database could help solve this, albeit slowly.


I too cannot see an array of a billion pointers (that was the example given?) in memory, it would be daft. The wilderness "controller" would have to give you access to lazy loaded nearby locations that have content cached in memory. Rooms should only be cached in memory and/or persisted when you actually drop or bury something in that location as has already been mentioned.

eg..
> look east

[controller works out the array location using the east exit]
[controller checks the in memory cache (the list) for a loaded room]

[if it exists in the cache]
[use the room in memory]
[if it exists in a db or exists as a hashed file]
[load the room from the file/db]

[dynamically generate the room's description]

[cache the room in the list]

[display]
To the east you see:

A rocky path at the base of a mountain.
You see:
There is a small mound here, a head on a rusty pike and a longsword.
There are 3 exits: north, south and west.

[remove the room from memory, possibly with a time delay in case the player moves that way]


This only a very simplified psuedo description of what might happen of course.
09 Jun, 2009, Runter wrote in the 107th comment:
Votes: 0
flumpy said:
Runter said:
I'm just not feeling the grid of pointers. Or the grid at all, really. It probably works fine for a smaller wilderness, but even then I think I would try to use a more elegant solution. To be honest, at this point, my issue is how to give readily available access to data on nearby locations. (Like terrain type) Dynamic instantiation from a database could help solve this, albeit slowly.


I too cannot see an array of a billion pointers (that was the example given?) in memory, it would be daft. The wilderness "controller" would have to give you access to lazy loaded nearby locations that have content cached in memory. Rooms should only be cached in memory and/or persisted when you actually drop or bury something in that location as has already been mentioned.

eg..
> look east

[controller works out the array location using the east exit]
[controller checks the in memory cache (the list) for a loaded room]

[if it exists in the cache]
[use the room in memory]
[if it exists in a db or exists as a hashed file]
[load the room from the file/db]

[dynamically generate the room's description]

[cache the room in the list]

[display]
To the east you see:

A rocky path at the base of a mountain.
You see:
There is a small mound here, a head on a rusty pike and a longsword.
There are 3 exits: north, south and west.

[remove the room from memory, possibly with a time delay in case the player moves that way]


This only a very simplified psuedo description of what might happen of course.


My only question would be, is this appropriate for someone wanting to view some type of ascii overmap? This seems like it could be a lot of additional overhead if your mud actually ended up with players, even with caching.
09 Jun, 2009, flumpy wrote in the 108th comment:
Votes: 0
Runter said:
My only question would be, is this appropriate for someone wanting to view some type of ascii overmap? This seems like it could be a lot of additional overhead if your mud actually ended up with players, even with caching.


I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

Keeping a small list or hash of lazy loaded tile types that are mapped to coords in the immediate vacinity (for a while) would not be much of a problem. If you indexed your data correctly the search space would be paltry and any db or even file index (but why do it yourself?) could return the data with minimal delay. If you kept it in an indexed way in memory too then re-searching that space at a later time is easy and fast as well. You can expire least used tile hash entries if you want to to free up space if the area becomes cluttered. However, all you are loading is a hash of co-ordinate and tile type, and tile object only need loading once (flyweight?) to become aware of what their type is, so I can't really see it being that slow or memory intensive to be honest.

I expect if you generate your map as you move you are going to make more of an impact on memory than if you force the player to use a map command of some sort. If you are worried about the implications of large memory footprints when generating a map, make the user do it when they want to see where they are (or even have to find a map object to find where they are).

After all, they're in a big wilderness, why should they know where they are at all times?? Its fun being lost, and you could make that part of the game too.
09 Jun, 2009, Runter wrote in the 109th comment:
Votes: 0
flumpy said:
Runter said:
My only question would be, is this appropriate for someone wanting to view some type of ascii overmap? This seems like it could be a lot of additional overhead if your mud actually ended up with players, even with caching.


I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

Keeping a small list or hash of lazy loaded tile types that are mapped to coords in the immediate vacinity (for a while) would not be much of a problem. If you indexed your data correctly the search space would be paltry and any db or even file index (but why do it yourself?) could return the data with minimal delay. If you kept it in an indexed way in memory too then re-searching that space at a later time is easy and fast as well. You can expire least used tiles if you want to to free up space if the area becomes cluttered. However, all you are loading is a hash of co-ordinate and tile type, and tile object only need loading once (flyweight?) to become aware of what their type is, so I can't really see it being that slow or memory intensive to be honest.

I expect if you generate your map as you move you are going to make more of an impact on memory than if you force the player to use a map command of some sort. If you are worried about the implications of large memory footprints when generating a map, make the user do it when they want to see where they are.

After all, they're in a big wilderness, why should they know where they are at all times?? Its fun being lost, and you could make that part of the game too.


I think that's making an assumption about the game-play the wilderness is being designed for, and for the code to be generic enough to work in all situations it should allow for all likely game-play implementations. It might be fun to be lost, but maybe someone doesn't want to make being lost part of their game. I'm also wondering with a map being traversed by many players how it would stand up to such a system if they were indeed typing areamap upon entering any room.
09 Jun, 2009, flumpy wrote in the 110th comment:
Votes: 0
Runter said:
I think that's making an assumption about the game-play the wilderness is being designed for, and for the code to be generic enough to work in all situations it should allow for all likely game-play implementations.


yes i see your point

Runter said:
It might be fun to be lost, but maybe someone doesn't want to make being lost part of their game. I'm also wondering with a map being traversed by many players how it would stand up to such a system if they were indeed typing areamap upon entering any room.


The trick is to have the controller as a single instance object. As long all your players used a shared controller object and you don't cache the data for the map in each player's thread stack space then I don't see a problem. It may be initially slow, but the caching should actually improve performance (although be memory intensive) the more players you have.
09 Jun, 2009, KaVir wrote in the 111th comment:
Votes: 0
flumpy said:
I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

If that's in reference to my former implementation, note that each tile contained the data (including the terrain type) for 10x10 rooms. As my map only showed 11x11 rooms (centred on the viewed), I never needed to reference more than 4 tiles per player when drawing a map. There was no need to generate any physical rooms for the map, as the tiles contained all the data I needed.
09 Jun, 2009, Runter wrote in the 112th comment:
Votes: 0
KaVir said:
flumpy said:
I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

If that's in reference to my former implementation, note that each tile contained the data (including the terrain type) for 10x10 rooms. As my map only showed 11x11 rooms (centred on the viewed), I never needed to reference more than 4 tiles per player when drawing a map. There was no need to generate any physical rooms for the map, as the tiles contained all the data I needed.


But I think the question is, how is the data in the tiles stored/accessed?
09 Jun, 2009, KaVir wrote in the 113th comment:
Votes: 0
Runter said:
But I think the question is, how is the data in the tiles stored/accessed?

There are two 'world' arrays. The first is an array of 512x512 8bit tile IDs, initialised from a data file and representing the default terrain (there is a separate array of 256 default tiles which can then be referenced based on the tile ID). The second is an array of 512x512 pointers to customised tiles*, representing modified terrain (these tiles are stored in a move-to-front heuristic list, and saved to disk). The elements of the second array are initially all NULL, indicating that the terrain hasn't yet been modified.

When you want to check the terrain type for a specified location, you use that location's x/y position to determine which array element it's in (i.e., by dividing both 10 and y by 10), then check that element of the second array - if the pointer is NULL, you instead retrieve the corresponding tile ID from the first array and use it to grab a tile from the default list. This gives you the tile (of 10x10 rooms) you're standing on, and you can retrieve the data for the specified room by checking the x%10/y%10 element of the tile array. Of course you wouldn't do that manually, there'd be functions to do it for you, but that's the underlying concept.

* Technically the second array contains pointers to lists of custom tiles, as players can dig underground tunnels and build multi-floor buildings, but I'm trying to keep the explanation simple.
09 Jun, 2009, flumpy wrote in the 114th comment:
Votes: 0
Runter said:
KaVir said:
flumpy said:
I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

If that's in reference to my former implementation, note that each tile contained the data (including the terrain type) for 10x10 rooms. As my map only showed 11x11 rooms (centred on the viewed), I never needed to reference more than 4 tiles per player when drawing a map. There was no need to generate any physical rooms for the map, as the tiles contained all the data I needed.


But I think the question is, how is the data in the tiles stored/accessed?


I dont think it matters how you store it, its accessing things and how big a search space you have that matters (finding things and finding them quickly). Any kind of index would help, no matter how you stored it.

Heck I could write my map on a peice of paper, and as long as the mud could give me my co-ordinates on the map I could find where I was.
09 Jun, 2009, Scandum wrote in the 115th comment:
Votes: 0
Runter said:
I'm just not feeling the grid of pointers. Or the grid at all, really. It probably works fine for a smaller wilderness, but even then I think I would try to use a more elegant solution. To be honest, at this point, my issue is how to give readily available access to data on nearby locations. (Like terrain type) Dynamic instantiation from a database could help solve this, albeit slowly.

I don't think it'll get any more elegant than a hashed pointer grid. A large wilderness is doable using tiles, in which case a hashed pointer grid of tiles would still be the most elegant solution since it makes it easy to copy and modify tiles on the go.

You could have a pointer to a hashed forest tile, a player moves in, so you copy the shared forest tile to a unique tile. Next the player starts cutting trees, so you update the unique tile to have some holes where trees used to be. When the player leaves the tile the forest starts recovering, and when the tile once again matches the default tile you set the pointer back to the shared forest tile and free the unique tile.

If the player was to build a fortress on a hill you could search through the list of default hill tiles and change the default pointer from a hill to a hill + fortress. The alternative is a static wilderness where you're bound to a couple of hundred default tiles.
09 Jun, 2009, Runter wrote in the 116th comment:
Votes: 0
Scandum said:
Runter said:
I'm just not feeling the grid of pointers. Or the grid at all, really. It probably works fine for a smaller wilderness, but even then I think I would try to use a more elegant solution. To be honest, at this point, my issue is how to give readily available access to data on nearby locations. (Like terrain type) Dynamic instantiation from a database could help solve this, albeit slowly.

I don't think it'll get any more elegant than a hashed pointer grid. A large wilderness is doable using tiles, in which case a hashed pointer grid of tiles would still be the most elegant solution since it makes it easy to copy and modify tiles on the go.

You could have a pointer to a hashed forest tile, a player moves in, so you copy the shared forest tile to a unique tile. Next the player starts cutting trees, so you update the unique tile to have some holes where trees used to be. When the player leaves the tile the forest starts recovering, and when the tile once again matches the default tile you set the pointer back to the shared forest tile and free the unique tile.

If the player was to build a fortress on a hill you could search through the list of default hill tiles and change the default pointer from a hill to a hill + fortress. The alternative is a static wilderness where you're bound to a couple of hundred default tiles.


I think anytime someone uses the word pointers and elegant in the same sentence is cringe.
09 Jun, 2009, Runter wrote in the 117th comment:
Votes: 0
flumpy said:
Runter said:
KaVir said:
flumpy said:
I guess for a map you only need to know the rooms tile type and I think its been mentioned that a small immediate area around the player would only need to be searched.

If that's in reference to my former implementation, note that each tile contained the data (including the terrain type) for 10x10 rooms. As my map only showed 11x11 rooms (centred on the viewed), I never needed to reference more than 4 tiles per player when drawing a map. There was no need to generate any physical rooms for the map, as the tiles contained all the data I needed.


But I think the question is, how is the data in the tiles stored/accessed?


I dont think it matters how you store it, its accessing things and how big a search space you have that matters (finding things and finding them quickly). Any kind of index would help, no matter how you stored it.

Heck I could write my map on a peice of paper, and as long as the mud could give me my co-ordinates on the map I could find where I was.


I'm sorry, but I do think it matters. I'm assuming at this point he doesn't have a big 2d array of pointers. ;)
That's 4gigs of memory for his 1billion locations in pointers alone.
09 Jun, 2009, Scandum wrote in the 118th comment:
Votes: 0
Runter said:
I'm sorry, but I do think it matters. I'm assuming at this point he doesn't have a big 2d array of pointers. ;)
That's 4gigs of memory for his 1billion locations in pointers alone.

KaVir would have actually saved memory if he had used a hashed pointer grid for dark city. I'm not sure why you keep going on about 4 gigs of ram, I'd suggest you carefully read over previous explanations until you grasp the concept.
09 Jun, 2009, Runter wrote in the 119th comment:
Votes: 0
You already said earlier you want pointers which point to NULL a default room if not occupied. Without data a pointer is 4 bytes. If you want a pointer for every possible element, even ones not "loaded" or whatever, it's still 4 bytes. Believe me. I grasp the concept. I've been programming for a very long time. Maybe you're changing your idea without telling anyone?

Quote
Not needed if you design your wilderness map as an array of pointers. Unused rooms can point to a default (hashed) room, used rooms point to an actual room loaded into memory.
09 Jun, 2009, KaVir wrote in the 120th comment:
Votes: 0
Scandum said:
KaVir would have actually saved memory if he had used a hashed pointer grid for dark city.

True, and as the majority of modified tiles were clustered together it wouldn't have had much of a speed impact either. But the two arrays only used 256K and 1MB respectively, and the rest of the mud had a very low RAM overhead, so it wasn't a major problem even back then.
Random Picks
100.0/181