28 Mar, 2010, David Haley wrote in the 21st comment:
Votes: 0
Oops. Was thinking bits. My bad.
Point still stands that it doesn't accomplish the stated goal, is wasteful, etc.
28 Mar, 2010, Scandum wrote in the 22nd comment:
Votes: 0
David Haley said:
Point still stands that it doesn't accomplish the stated goal, is wasteful, etc.


Scandum said:
The concept can be used with a tile-based approach as well.
28 Mar, 2010, Runter wrote in the 23rd comment:
Votes: 0
Scandum said:
David Haley said:
Point still stands that it doesn't accomplish the stated goal, is wasteful, etc.


Scandum said:
The concept can be used with a tile-based approach as well.


Quote
My wilderness used a shared room approach. There were 20 default rooms for each sector, with a 2000x2000 grid of pointers, each pointing to 1 of those 20 rooms. When a room becomes interesting you create a copy of the room it was pointing to (typically when a player enters the room), and once that copy becomes identical to the default room (player leaves) you destroy it and link it back. The concept can be used with a tile-based approach as well.


We're coming full circle. Any-who, here's the problem with your clarity. Putting aside what a 2000x2000 "grid of points" is pointing to, putting that memory aside and what savings you're getting out of it, the pointers themselves cost something. That's what DavidHaley is saying. So if you want to be clear, then be clear. Do you have a 2000x2000 "grid of pointers" pointing to ANYTHING? We don't care if they're pointing to shared memory or not. You very well may find this acceptable. DH doesn't. Or maybe you can just explain what you really are suggesting is better.
28 Mar, 2010, David Haley wrote in the 24th comment:
Votes: 0
Yes: as long as you have 2000x2000 pointers pointing to anything, you're consuming a whole bunch of memory for those pointers, even if what is pointed to is shared (as Runter said). KaVir addresses this by having a smaller grid of pointers, pointing to larger tiles (among other things). If you want to describe a tile-based system, then you wouldn't have a grid of 2000x2000 pointers anymore. Since decisions here affect memory usage very directly, it's important to be extremely precise when we discuss this issue. Indeed, in the thread that KaVir linked to, much confusion was eventually avoided exactly when we hammered down what we were all talking about. A seemingly small change can have considerable consequences.
28 Mar, 2010, Deimos wrote in the 25th comment:
Votes: 0
I don't really think that a grid of pointers is infeasible for me. My project is on a dedicated box with plenty of memory and I'm not looking to win any flyweight awards. It may not be as efficient as a tile-based system, but a tile-less design offers a lot more uniqueness to the world. Granted, there are probably vast expanses where this won't come into play (deserts, oceans, etc.), but even with hundreds of different tiles, it would probably be apparent to anyone looking at a map that the world is tile-based. This is especially true when looking at things like rivers, roads, etc. where they can run through different terrains in different directions. I'm basing this opinion on experience with tile-based graphical games (the Civilization series, for example), since I've never implemented anything like this for a MUD. The principles seem pretty much the same, though. It also seems like creating tiles with which to construct the game world to begin with would probably double the amount of work needed, as well. Instead of picking up my brush and painting a nice river across one of my continents, I would have to keep swapping back and forth, copy/pasting different pre-created river tiles and such. Which, depending on the surrounding terrain, could get ridiculously tedious. And, of course, creating all the tiles to being with would take an exorbitant amount of time.

My $0.02, anyway.
28 Mar, 2010, Runter wrote in the 26th comment:
Votes: 0
Deimos said:
I don't really think that a grid of pointers is infeasible for me. My project is on a dedicated box with plenty of memory and I'm not looking to win any flyweight awards. It may not be as efficient as a tile-based system, but a tile-less design offers a lot more uniqueness to the world. Granted, there are probably vast expanses where this won't come into play (deserts, oceans, etc.), but even with hundreds of different tiles, it would probably be apparent to anyone looking at a map that the world is tile-based. This is especially true when looking at things like rivers, roads, etc. where they can run through different terrains in different directions. I'm basing this opinion on experience with tile-based graphical games (the Civilization series, for example), since I've never implemented anything like this for a MUD. The principles seem pretty much the same, though. It also seems like creating tiles with which to construct the game world to begin with would probably double the amount of work needed, as well. Instead of picking up my brush and painting a nice river across one of my continents, I would have to keep swapping back and forth, copy/pasting different pre-created river tiles and such. Which, depending on the surrounding terrain, could get ridiculously tedious. And, of course, creating all the tiles to being with would take an exorbitant amount of time.

My $0.02, anyway.


Read the code I posted. I think the broad concept could solve your problem.
28 Mar, 2010, Deimos wrote in the 27th comment:
Votes: 0
I did read it, and it's very intriguing. I'm not exactly sure how having hundreds or thousands of facades is going to affect the performance (if at all), though. Am I correct in assuming that :sector_default would simply be whatever terrain type is the most prevalent in my game world (most likely the ocean type)?
28 Mar, 2010, Runter wrote in the 28th comment:
Votes: 0
Deimos said:
I did read it, and it's very intriguing. I'm not exactly sure how having hundreds or thousands of facades is going to affect the performance (if at all), though. Am I correct in assuming that :sector_default would simply be whatever terrain type is the most prevalent in my game world (most likely the ocean type)?


Yes, but you could rip that part out if you don't have anything prevalent and always have a facade setting the template explicitly when it's created. It may increase loading speed for a memory trade.

Either way, the facade instance is absolutely an empty instance and it relies on class methods to do lookups. Interestingly, you could assign things to the singleton-class to overload values from the templates effectively making the individual facade unique from a template without dramatically decreasing performance.

In any event, 3 seconds to load 5 million of these facades is a lot more reasonable than the numbers you were reporting for less. If you broke that up into more dynamic loading it could be seemless, too.

Also, it's going to be difficult to relate C solutions to a pure ruby solution.
28 Mar, 2010, Runter wrote in the 29th comment:
Votes: 0
Configured differently and with a sample the size you suggested originally.

http://www.mudbytes.net/pastebin-32818

Rehearsal —————————————————————-
Loading 2,500,000 locations. 1.500000 0.110000 1.610000 ( 1.754308)
——————————————————- total: 1.610000sec

user system total real
Loading 2,500,000 locations. 1.450000 0.050000 1.500000 ( 1.501584)


I think it's reasonable.
28 Mar, 2010, KaVir wrote in the 30th comment:
Votes: 0
Deimos said:
Granted, there are probably vast expanses where this won't come into play (deserts, oceans, etc.), but even with hundreds of different tiles, it would probably be apparent to anyone looking at a map that the world is tile-based.

That depends how many tiles you've got. But with a small number, yes, it's fairly obvious.

Deimos said:
It also seems like creating tiles with which to construct the game world to begin with would probably double the amount of work needed, as well.

Actually I found it reduced the amount of work considerably (my first wilderness system didn't use tiles). It's a bit like building a map from pieces of a jigsaw puzzle - it won't let you fit together pieces that don't match. I generated the initial map from a bmp file (one tile per pixel) but after that it was pretty easy to add detail with in-game tools. The tiles automatically include coastlines and riverbanks and such, and they verify that rivers are flowing in the correct direction. While you can still technically fool the system (eg a river that flows in a ring with no start or finish) it's generally pretty good. In fact I found the tile-based approach so effective that I used it again in my roomless mud.

But there's no right or wrong approach - if you don't mind the extra work, there's no reason why you couldn't do it room by room.
29 Mar, 2010, David Haley wrote in the 31st comment:
Votes: 0
Deimos said:
It also seems like creating tiles with which to construct the game world to begin with would probably double the amount of work needed, as well. Instead of picking up my brush and painting a nice river across one of my continents, I would have to keep swapping back and forth, copy/pasting different pre-created river tiles and such.

You can always render it however you like, and have the MUD generate tiles for you. You'd be surprised at how much natural repetition there tends to be. You could experiment with fixing tiles at 5x5, 10x10, etc., and see how compressed your world becomes.

It's also worth noting that a tile-based approach can easily varying levels of detail. Nothing prevents you from painting oceans and plains with very large strokes (i.e., tiles representing many squares) and then drilling in for finer-grained detail with smaller strokes (i.e., tiles representing fewer squares).
Random Picks
20.0/31