Hi Rynhardt, in theory this sounds good, but I have a couple of questions for 
you.

What data types are you storing in your array? I.E. HOw are you showing that 
there is a wall and not air per se in a particular area? I'm assuming here, 
that we're talking about a full-scale map of the level.

Also, is your player moving in only 1 unit per frame?

I ask these because firstly, it sounds like you're simply treating the world as 
a very large array of described points in essence. (Which begins to sound 
exactly like a 3D coordinate system again) :) The exception being that you have 
labels for each point, which can really unnecessarily inflate the amount of 
data needed to render a map. Even just using a byte of data per coordinate, it 
inflates the map eight times larger than it needs to be rather than using a 
simpler collision-based model.

-And, incidentally, you'll still, in effect, need to use collision detection 
anyway, since the map is full-scale. I.E. if your player is moving at 5 
coordinates per second in a direction but that move rate isn't always the same, 
you'll still need to check to see if the path of the player will come into 
contact with some feature of the map. You'd need some form of collision 
detection for this. -Yes?…

To address your other point, about needing to move through each entity in the 
game each frame, you could simply use the current room as your bound for 
checking entities. There's no sense checking entities on the other side of the 
map.

Even if you simply used the player's radius instead, and did more detailed 
collision detection based on that, the math to check every entity's position in 
a level really wouldn't be anything for a modern machine.

I like your idea though, using perhaps an array of 8 bit integers, which could 
simply represent a full-scale environment with amazing detail, in the sense 
that one could simply test for a point anywhere on the map and instantly know 
what exactly was there. I.E. A point could contain air, water, be solid or not 
with numerous materials.

I question how much faster or less intensive this would really be in gameplay 
though. -But honestly, I'm not sure it really matters on the scale we're 
talking about here. I.E. we're not even actually rendering any of this in 
graphics so these shapes and structures we're testing against are purely 
hypothetical in the sense that a sphere is simply a 3F coordinate and another 
float for a radius. That's so little data to represent and so little math to 
manage, that it's nothing for a computer these days. -Know what I mean?…

I think it's really interesting though, as I've said, as it really sounds like 
your and other's full-scale approach is really beginning to blend with a raw 3D 
coord system anyway. :) I love the idea of symbolic representation of 'reality' 
and vice versa!… woohoo! :)

Have a totally awesome day!…

Smiles,

Cara :)
On Dec 7, 2010, at 2:30 AM, Rynhardt Kruger wrote:

Hi Cara,

The reason I thought the 3d array would be faster is:
Lets say you want to check if the player object moves into a wall when it takes 
a step. In the case where every object 
has attributes for the 3d coordinate, you have to search through all the 
objects currently in the level and check if one 
of them is at the position of the players next position. If all the objects are 
stored in a 3d array, it requires only 
using the players next location as an array index and checking if an object 
occupies that array element. In 
languages like c or c++, getting an array element requires only the calculation 
of the correct offset in memory based on 
the array index and element size and referencing that location in memory. 
In this case I'd thought of storing wall-like elements in 
the array apposed to rooms.
Another way might be to (as you said) give each object bounding coordinates 
e.g. a left upper coordinate and a right 
lower coordinate and have all the objects in an array or other data structure. 
May be having rooms in stead of walls 
represented by objects will decrease the number of objects so the search time 
isn't so big?
A reason I like this method is that rooms can have interesting shapes e.g. a 
round room and that you can move a hole 
room to another location, possibly moving everything inside as well to create a 
vehicle like object.

Take care,

Rynhardt

* Cara Quinn <caraqu...@draconisentertainment.com> [101207 07:53]:
> Rynhardt;
> 
> -It occurred to me that I didn't completely answer your question in my last 
> note, so my apologies. :)
> 
> In my own personal opinion, yes, it's good to have map data in an array, as 
> well as using a flexible coordinate system as in my code example. HOwever, 
> even though game objects can still rely on a coordinate system to move within 
> the game, they can still be stored in an array as well.
> 
> I.E. one could use two arrays in-game; one to store the amount of active 
> entities and the other to represent rooms in a level. Within the rooms array, 
> game entities can freely move in 3D space using the usual 3D coordinate 
> system we're discussing.
> 
> this is one approach I personally like, but it's also not perfect in my 
> opinion.
> 
> For one thing, using one element of an array per room, can make it difficult 
> to accurately or easily map certain complex room layouts, though on the 
> up-side, it can be really easy to juggle and switch rooms around to cause 
> some really neat effects for cool game-play.
> 
> Perhaps my very fav mapping type would simply be to map out the entire space 
> with a coordinate system and simply take the 3D coordinate-based physics 
> approach and rely on collision management and such?
> 
> -Just my thoughts?
> 
> -Hope this comes closer to answering your questions / addressing your 
> comments?
> 
> Smiles,
> 
> Cara :)
> On Dec 6, 2010, at 5:22 PM, Cara Quinn wrote:
> 
> Hi Rynhardt;
> 
> ACtually collision detection really isn't that expensive. Here's some C++ for 
> checking two axis-aligned bounding boxes in 3D.
> 
> // set the lower and upper coordinates of each box
> // and set their position
> 
> Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
> A.setPosition (3.0, 3.0, 3.0);
> 
> Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
> B.setPosition (0.0, 0.0, 0.0);
> 
> // check to see if any part of the above boxes touch or overlap
> 
> if((A.lower.x <= B.upper.x && A.lower.y <= B.upper.y && A.lower.z <= 
> B.upper.z) && (A.upper.x >= B.lower.x && A.upper.y >= B.lower.y && A.upper.z 
> >= B.lower.z)) {
> 
> // Manage collision
> 
> }
> 
> In this case, the two boxes are not touching, as the bottom-most point of A 
> is at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so 
> there's a length of one coordinate between them. Does this make sense??
> 
> The above code is all you need to detect whether two boxes in 3D space touch 
> or overlap each other. This really isn't overly intensive. YOu can also check 
> for collision of spheres easily too, but it is a bit more expensive than the 
> above, but it is equally simple, relying on the Pythagorus theorem. Basically 
> you can just check the length of the line between the centers of two spheres 
> and see if it's less than or greater than the radii of each sphere. So if the 
> two radii add up to (or are greater than) the distance you just found, then 
> the spheres are touching or overlapping.
> 
> On the subject of arrays, (depending on the type of array) it's not 
> necessarily any less expensive to access an array vs doing something like the 
> above every frame of a game, since the system may need to move through the 
> array to find what it needs, regardless of how easy it looks to the user. so 
> just because you can call an element of an array as in array[x] doesn't mean 
> the system doesn't need to do any work to access that element.
> 
> There are faster ways of storing data which are easier on the system in C++ 
> but I'm not as familiar with them as I'd like, so forgive me but I just know 
> they're there, but have no explanation for you. :)
> 
> Anyway, hope this sheds some light?
> 
> Smiles,
> 
> Cara :)
> On Dec 6, 2010, at 3:19 PM, Rynhardt Kruger wrote:
> 
> Hi,
> 
> Another question to the devs on this list:
> 
> What have you find to be the best way of representing the map and other game 
> objects in software?
> Two ways I can think of is to either have everything in an big 3d array, or 
> to give each object attributes specifying 
> the 3d position.
> 
> Advantages of giving each object an x y and z attribute:
> * objects can have floating point positions
> * uses less memory than the array method (not really an issue anymore)
> * More than one object can be in the same position (think of doors or walking 
> through walls in SOD)
> * Possible for objects to be bigger than one unit e.a. having a start 
> position as well as an end position
> 
> Disadvantages:
> * Detecting collisions may be expensive as all the objects need to be 
> searched to find an object at a specific position. 
> Something like binary search may be useful, but then all the objects must be 
> sorted every time an object moves.
> * Increasing the number of objects in the game may decrease performance as 
> the list of objects to be searched gets 
> longer.
> 
> Advantages of the 3d array method:
> * Very fast to reference an object at a specific position.
> This makes path finding and collision detection very fast.
> * One object may be placed in several array locations, e.g. having a lot of 
> references/pointers in the array point to 
> one 
> wall object.
> * If the array size stays constant, adding more objects will not have such a 
> great effect on game performance.
> 
> Disadvantages:
> * Not possible to have more than one object at the same position, unless each 
> array location points to another list.
> * Not possible for an object to be bigger than one unit.
> * Not possible for objects to have floating point positions.
> 
> Something I've missed?
> 
> Another way might be to combine the two approaches, e.g. having all fixed 
> objects like walls and floors be placed in a 
> 3d array, and the movable objects like the player and items use the other 
> method.
> 
> What are your thoughts on this?
> 
> Take care,
> 
> Rynhardt
> 
> 
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gam...@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
> 
> 
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gam...@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
> 
> 
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gam...@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.

---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.


---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to