I have to implement collision detection and response for my 3D game engine, while keeping it as lightweight as possible (it runs on Dreamcast, have to conserve cpu cycles) and I'm really dreading it

the maths is fairly hard (definitely the most mathematically complex part of the project), especially to do efficiently. But the bigger issue is the choices I make here have far reaching design decisions. For instance, if I limit the game to a (conceptually) flat plane, even though it's visually 3D I could treat it as 2D for purposes of collision detection and eliminate an entire dimension of problems

Follow

also I need a way to author collision geometry intelligently - I don't want to use the complex 'visual' geo for collision detection because it will be too slow, so every map area needs an additional invisible 'collision' geometry layer, a hidden world or dimension that can not be seen by the player but can be 'felt' as it determines where the characters can move

· · Web · 1 · 1 · 0

@voxel does this help?

developer.mozilla.org/en-US/do

how simple you can make it depends on what level of sophistication you want out of your collision detection, simple aabb may be good enough. if you want more detailed collision geometry, or faster than aabb, there are options

@voxel there’s a gamasutra article i could dig up that does a deep dive on dreamcast ish era collision detection strategies too

@zens that would be great actually! im trying to get hold of the 'DOCUMENT OF METAL GEAR SOLID 2' a kind of 'behind the scenes' info disc which I hear goes into some detail on how they did their collision detection.

@voxel @zens I have a serious MGS fan friend - I will see if he knows where that is

@dualhammers @zens without incriminating myself, it's possible I'm already working on that, it's just slow going.

@voxel @zens My friend apparently has a physical copy but he's not selling :P

@dualhammers @zens spent 15 minutes exploring this and there's lots of interesting material but the collision focused content is minimal (not too surprising). I had read some ancient forum post that led me to hope you could visualise the collision geo in the map browser but all I could do is fly around and tweak the fog colour

@zens its not so much the 'how' (though im not looking forward to that), as the 'what'. I know where to go to get good examples of each type of collision detection, but before that I have to decide what kind I need. Can I (through game design decisions) limit myself to only needing sphere to sphere collisions, or find a way to ensure collision volumes are always axis aligned etc

@voxel ah yes. or even do different strategies depending on whether it’s player ~> environment, player ~> mobile object, non player object ~> non player object

@zens @voxel This last part is super important for dreamcast-tech-level games; not everything is created equal and your level format will matter the most.

You probably want either BSP quake-like stuff, or (sphere |capsule|aabb) vs tri for level geo.

In most games, everything else can almost certainly be spheres/capsules/aabbs vs each other, which is "just" 2 primitive collision routines to implement.

If you can constrain to 2d (plus or minus terrain height) that's even better of course.

Sign in to participate in the conversation
Merveilles

Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.