Yes Thomas, this seems to be a different approach than the popular one people 
are taking here, in that it seems to kind of free up the programmer to use real 
physics and constant relatively low-cost collision detection without needing to 
worry so much on the exact position an entity will be in at any given time. 
I.E. let the detection routine do the work and deal with the touches on an 
entity by entity basis.

Touches and collisions can be dealt with uniquely, depending on the two or more 
entities touching. Each entity has it's own touch routines that get called and 
the correct results easily work for all the entities without so much 
forethought on the part of the developer. I.E. Let the entity itself check what 
touched it or create a short-lived object to represent the touch between two 
entities and act accordingly. -It can be a very cool paradigm…

In essence, the map now has only the barest coordinates representing the actual 
objects and the rest is just nothing! lol! So it's a whole lot less data to 
manage. the down-side in my opinion, is that each type of map element really 
needs to be defined in terms of active objects. I.E. a body of water really 
needs to be it's own entity with a bounding box or some shape. Admittedly, it 
could be represented with a really minimal amount of data, (three floats) but 
still, it's still another object like a wall or door.

Sizewise though, maps really are a lot smaller than the array-based paradigms 
we've been talking about now, and could be stored in files that are very small 
text files.

I kind of like a combo approach, myself, as I've said, where the map uses a 
straight 3D coordinate system, but still is divided into regions like rooms and 
such. Anyway, -Just some thoughts…

Smiles,

Cara :)
On Dec 7, 2010, at 3:23 PM, Thomas Ward wrote:

Hi Cara,

Hmmm...I'm going to have to try that. When you put it like that it
looks pretty easy. Essentially, all I should have to do is create a
class to hold something like a wall and define its maximum x, y, and z
boundries and detect if the player comes into contact with any point
of the wall, door, whatever.  I've got to try this as it sounds
interesting.

Cheers!


On 12/6/10, Cara Quinn <caraqu...@draconisentertainment.com> 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 :)

---
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