12 Oct, 2007, Mabus wrote in the 41st comment:
Votes: 0
So storing only the coordinates where "special circumstances"(SC) exist, and saving a set of coordinates on the ship-object and player-objects, and then just checking to see if other ship-objects, player-objects or SC exist at the set of coordinates is best?

Trying to wrap my head around this. Felt more sure before, but good input (hell, any input) before design and coding is always a blessing.
12 Oct, 2007, David Haley wrote in the 42nd comment:
Votes: 0
Mabus said:
So storing only the coordinates where "special circumstances"(SC) exist, and saving a set of coordinates on the ship-object and player-objects, and then just checking to see if other ship-objects, player-objects or SC exist at the set of coordinates is best?

It's hard to say "best" without knowing exactly what you plan to do. However a general principle that I think it always important is to only represent what you need to represent. For example, if you have a 100x100 square of plain old ocean, it would be better to compress that information somehow. My spatial partitioning aims to take advantage of the fact that, typically for an ocean, there is a lot of information that can be represented implicitly.

Mabus said:
Trying to wrap my head around this. Felt more sure before, but good input (hell, any input) before design and coding is always a blessing.

If it makes you feel better, I think that representing very large terrain spaces is one of the hardest things to do right in MUD design. :smile:
12 Oct, 2007, KaVir wrote in the 43rd comment:
Votes: 0
DavidHaley said:
KaVir said:
DavidHaley said:
As soon as you allocate an array the bulk of which is taken up by generic tiles (i.e. all of which are the same) you have allocated what is essentially empty space.


But I don't do that, nor have I suggested that Mabus do that. Right from the start I've been stressing the value of arrays for storing varied terrain.


I realize that, but unless your terrain is pathologically varied (e.g. checkerboard) you will have considerable homogeneity in your terrain even if there is some variation.


It doesn't have to be a checkboard to work out more efficient as an array. Just having a lot of variation can be sufficient.

DavidHaley said:
KaVir said:
The array solution deals very well with highly varied terrain (as in scattered rather than clumped together), IMO much better than quadtrees and the like.


For your first claim, I'd like to hear something to back that up. We're talking huge swaths of very similar terrain here


Please re-read what I just said (particularly the highlighted part). I very explicitly said it deals well with "highly varied terrain", not "very similar terrain".

DavidHaley said:
KaVir said:
That depends on the implementation. Just because the world is 10000x10000 tiles, it doesn't mean he has to literally have an array of 10000x10000 elements. He could for example have a 1000x1000 array, each element of which is a "sector", with a sector storing 10x10 tiles. Much of the world could then be assembled from a few hundred sectors (a bit like creating a picture from pieces of a jigsaw puzzle).


You're going to have to explain yourself a bit. If your sector has any variation in it (which is an assumption you seem to have been running with) you will have to provide detail for that sector.


I already explained it in my first post in this thread, when I suggested it as a solution for a larger world.

DavidHaley said:
So instead of having 10k by 10k of cells of size 1, you have 1k by 1k of cells of size 100 sub-cells. You still have the same number of points in the end of the day. You haven't gained anything by doing this.


If you have 10k by 10k tiles, and each tile is 1 byte, then that's over 95MB. If you have 1k by 1k sectors, and there are 256 predefined sector types each containing 10 by 10 tiles, then that's less than 1MB. That's the same sized world, but using about 1% of the memory.



I disagree with your views about the space grid, but I've already said why and can't be bothered to repeat it.
12 Oct, 2007, David Haley wrote in the 44th comment:
Votes: 0
KaVir said:
DavidHaley said:
I realize that, but unless your terrain is pathologically varied (e.g. checkerboard) you will have considerable homogeneity in your terrain even if there is some variation.


It doesn't have to be a checkboard to work out more efficient as an array. Just having a lot of variation can be sufficient.

Sigh. We're going in circles. I'm not going to repeat what I've already said about this… it is no longer interesting. We're hardly even talking about the same thing anymore.

KaVir said:
If you have 10k by 10k tiles, and each tile is 1 byte, then that's over 95MB. If you have 1k by 1k sectors, and there are 256 predefined sector types each containing 10 by 10 tiles, then that's less than 1MB. That's the same sized world, but using about 1% of the memory.

You're assuming that all 10x10 macro-tiles will be one of the 256 predefined patterns. If that assumption is true, then fine. But it wouldn't apply to any of the maps I have been working with. :shrug:
13 Oct, 2007, Scandum wrote in the 45th comment:
Votes: 0
DavidHaley said:
- Binary trees of fixed size (e.g. a terrain map) can be implemented with a fixed-size array, eliminating all pointer overhead. (A clever optimization in this case given the fact that it won't grow.)

Smart thinking, that would work quite well. There'd be between 0 and 50% memory overhead due to the incremental nature of binary trees but that'd be a minor inconvenience. There'd still be the issue of slower access speed and being unable to make changes to the grid, but if less than 10% of the world needs storage it'd be worth the trouble.

I'm not a big fan of static world grids though since it turns the entire world in useless/filler space from a game perspective.
13 Oct, 2007, KaVir wrote in the 46th comment:
Votes: 0
DavidHaley said:
KaVir said:
If you have 10k by 10k tiles, and each tile is 1 byte, then that's over 95MB. If you have 1k by 1k sectors, and there are 256 predefined sector types each containing 10 by 10 tiles, then that's less than 1MB. That's the same sized world, but using about 1% of the memory.


You're assuming that all 10x10 macro-tiles will be one of the 256 predefined patterns.


No, those are just the default tiles - once again, I explained this my first post.
13 Oct, 2007, David Haley wrote in the 47th comment:
Votes: 0
Scandum said:
I'm not a big fan of static world grids though since it turns the entire world in useless/filler space from a game perspective.

That's a good point. However the grid wouldn't be completely static: you could still grow it. It would just cost you a fair bit to recreate the binary tree. If you wanted to add stuff, you'd have to allocate a new (bigger) fixed-size array and resort the elements into it. But, this shouldn't be *too* much of a problem, since presumably the world wouldn't grow all that often and it would be tolerable to wait on those rare occasions.

Having empty space isn't entirely useless from a game perspective, though; it can be used to give the world a sense of scale. But you need ways to work around it, like fast and mostly automated transportation. For instance, you should be able to hop in your ship and say "keep going east until (…)". But, I agree that in general empty space should be used extremely carefully because otherwise it is pretty useless.
13 Oct, 2007, Mabus wrote in the 48th comment:
Votes: 0
DavidHaley said:
Having empty space isn't entirely useless from a game perspective, though; it can be used to give the world a sense of scale. But you need ways to work around it, like fast and mostly automated transportation. For instance, you should be able to hop in your ship and say "keep going east until (…)". But, I agree that in general empty space should be used extremely carefully because otherwise it is pretty useless.

There could be many ways to represent a sailing/ship-combat system. I am going the route that I have chosen (large open ocean grid) because that is how I picture the sub-systems surrounding the system. These systems will require large "navigable" areas.
13 Oct, 2007, David Haley wrote in the 49th comment:
Votes: 0
Yes, that's a good reason to have empty space. Frankly empty sea space doesn't really bother me that much; empty land tends to be a little more problematic but even then I don't mind. I kind of like the feeling of vastness it affords.
40.0/49