koobas.hobune.stream
Replicating genesis Sonic's collision physics
Firstly, its kind of long, but also very interesting and I need you to read it to know what Im talking about - http://info.sonicretro.org/SPG:Solid_Tiles
Basically I would like to replicate Sonic's slope physics and his collision detection as detailed here. Specifically, Id like to know how Id go about implementing the terrain-made-of-solid-tiles -rather-than-objects approach in Unity, or is that just a bad idea for Unity? Furthermore, how would I give each of the tiles its own height mask like it explains and communicate that across to the player? Interested to hear your thoughts on this :)
For any future open-ended questions like this, use the forums. They aren't generally welcome at UA. I let it through because it's darn interesting.
The specifics of this approach are pretty fascinating. They're also not necessarily the best approach for re-creating these behaviors in Unity - or in the twenty-first century for that matter.
note: in any tile-based game larger than checkers, it would be most unwise to use individual gameobjects per tile. A typical Map structure should store a collection of Tile objects in a two- or three-dimensional array. Purely static visual and physical elements should be merged into as few objects as practical. Such merged groups are typically called "chunks". Non-static objects can be individual objects, usually called "entities". Plenty of info to research on these topics.
Don't get me wrong, there's nothing stopping you from bypassing Unity's physics system for everything (or everything but collision and / or raycasting). You can do this with sufficient forethought and the use of some other geometry library that gives you line segment collisions and other very basic 1980's collision mechanics. Or you can get in the ballpark using Unity's native 2D physics simulation, aka "Box2D", for which there is plenty of content to research.
Whether it is wise to do this is pretty subjective. I'd say no; these 2D physics engines exist to save you from this tedium. They grew out of the desires of designers who were fed up with doing the kind of work you're looking into. Why re-invent the wheel? It would make for a good lesson in low-level data management and be interesting to code, but apart from this, the approach has little merit in the modern era.
Of course certain aspects of the techniques described have a place in 2015, and in Unity. The use of "feeler" rays is definitely a valid practice, for instance. Measuring slopes by casting rays in clever ways would replace the old-school "lets examine nearby tiles" access methodology you're looking at in that article. Get your surface data from the actual collider surface; not by computing surfaces from a jagged 2D data set. That was innovative; in 1993. ;)
Ultimately it depends on what you want to achieve and why. Unity can be used to code a complete game with direct GL calls without the use of GameObjects, too, but that would totally miss the point of using Unity in the first place. Definitely an interesting read and a resource worth studying, but faithfully reconstructing it in Unity would be a bit like putting a lawnmower engine in a Charger.
Best,
The reason I was thinking of replicating this is because Im pretty new to unity and Ive found about 0 on how to implement curved slopes. Also, Im not using rigidbody2D, its a custom controller, so everything is pretty much made from scratch anyway, and I have no idea how to make curved slopes work using the conventional objects method.
Don't forget to post non-answers as comments.
I suspect you've found nothing on the subject because there's nothing special about them.
First, a quick point: Curves don't technically exist in game geometry. A true curve (the result of a mathematical expression) has infinite fidelity. Any video game's approximation of a curve is made of many flat pieces which describe an impression of a curve whose fidelity is deter$$anonymous$$ed by how many segments are used. This includes Unity's 2D and 3D colliders, as well as the curve extrapolation method described in the sonic article.
There is no real reason to think of these faux curves as anything special. Obviously a character controller that respects curves in this unique way requires additional thought, but it's still nothing magical.
Choose a method for building your level geometry which you are confident you can use throughout your game. This may be based on a 2D tileset of modular shapes with pre-made colliders, generated collider geometry built based on the tile's metadata (somewhat analogous to the sonic technique), or something less traditional for tile-based games like full pre-constructed geometry typical of game environments in other genres. Give any curved surfaces sufficient fidelity to achieve your desired "smoothness" - e.g. a circle made up of 16 line segments may be too rough, but 32 should be plenty; an arc that sweeps 90 degrees (a "quarter pipe") would have 8 segments.
Structure your character controller logic around whatever geometry you've chosen. It can use rays to feel around itself. If it feels that the surface ahead of it is higher than the surface beneath it, you can extrapolate an angle (and all kinds of useful data) from this information. You can use the surface normal of the hit to get related data. You can also write logic which "hugs" the nearest surface if the character is experiencing sufficient momentum. Note that none of these things requires using rigidbody physics, so that requirement is still satisfied.
It's not necessary to go with an oldschool technique to achieve this behavior. In fact it's probably detrimental in numerous ways.
*IIRC, sonic games involve geometry that exists in two layers. Which layer to measure depends on the state. If rolling, exa$$anonymous$$e the layer which includes any corkscrew shapes. If walking, exa$$anonymous$$e the other layer which allows him to walk past them. (This implies having two colliders on these special "corkscrew entrance/exit" tiles on separate Unity layers.) If, while rolling, you want him to enter and execute the corkscrew loop once - then proceed through the "walking" layer to move on from the corkscrew - this can be done by asking, e.g., has a trigger at the top of the full pipe been hit in the last N seconds? If I'm making no sense with this part, it's because I don't have a clear memory of these games.
The reason why we generally don't like questions like this on Unity Answers, btw, is how do we know whether we can now consider this question "answered"...? :)
@tanoshimi : when AlwaysSunny spends a half hour writing, it's answered! :D
I think most UA newcomers are unaware of protocol, or would rather leave it hanging. I'm normally strict in the mod queue but I couldn't resist the interesting topic. ;)
