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
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
@voxel does this help?
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.
@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
@voxel Well, I don't know if any of these are the articles I *distantly* remember, but I've maybe saved you some scut work of searching gamasutra yourself for relevant things..
@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
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.
@syntacticsugarglider current plan is to have the gameworld is composed of discrete 'rooms' that are small/simple enough I should be able to safely test against every collider present in the room for *most* areas, but there's a few special cases where this approach is probably going to be a terrible idea. Occasional larger areas, and areas with overhanging walkways (something like a bridge over a road) are complicating matters
specifically for the how, efficiently part. it covers a lot of topics like polygon soups and similar that old games would use but might not answer what you need based on your game
@voxel It’s one of those books that is hard to live without once you have it, if you make those kinds of things often enough. I revisit it all the time for various answers and it’s always clear and concise
@voxel to your actual question about what, if you elaborate on the game and it’s needs It’d be easier to point in different directions
@ruby0x1 found a copy at an academic library i can access, but I have to wait until Wednesday to get it 😊
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.