The Corgi Engine was created as an alternative to physics based platformers, aiming to provide a tighter gameplay, faster, and more predictable than physics. To do so, the engine implements its own “physics” : collision detection, movement, etc. Note that this is absolutely not a physics engine, this is not compatible with regular Unity physics, and if you’re planning on recreating Angry Birds, this will not do the trick.
The Corgi Controller is at the heart of this system. It’s the basis for each character. Its main function is to handle collisions, and basic movement. You’ll be able to add or set forces to it, usually via Character Abilities, which will make it move.
To handle collisions, the Corgi Controller uses Collider2Ds (any type, BoxCollider2D, CircleCollider2D, PolygonCollider2D…) and raycasts, which you can see in the scene view when playing your game. Basically how it works is that the controller is casting small rays all around itself, like tiny lasers. If a horizontal laser hits a Collider2D, then we’ve probably hit a slope, or a wall (in the context of the engine, any slope more than 45° strong). If a vertical ray hits a Collider2D, we’ve hit the ground or the ceiling. Depending on the forces being applied every single frame, and based on whether or not the raycasts hit something or not, the controller will move the object around the scene, or make it stop to prevent it from entering a wall for example.
Being at the center of your character, the Corgi Controller’s inspector settings are quite important. There you’ll be able to define the gravity, various speed factors, what slopes the character can climb (and at what speed).
You’ll also need to define Collision Masks. The Corgi Controller can interact with different types of platforms :
- regular platforms (Platforms)
- moving platforms
- one way platforms (platforms you can jump on from underneath)
- one way moving platforms
By default, the engine comes configured with a number of layers, and there’s one for each of these platforms : Plaforms, MovingPlatforms, OneWayPlatforms, MovingOneWayPlatforms respectively. If you add more layers, or change these, make sure to replicate these changes on your characters.
From the inspector you can also customize the raycasts. Their number really depends on the size of your character. What you’ll want to achieve is as few raycasts as possible (for performance reasons, even though raycasts are not really an issue these days), but with raycasts close enough to each other that no platform/enemy/whatever could fit between two raycasts (and in this case wouldn’t be detected by the engine).
The engine relies on layers to identify certain objects, notably platforms. Layers are metadatas you can associate your gameobjects with, and you can then use these to casts rays on certain layers only, via Layer masks (a selection of layers). Note that layers and sorting layers are completely different things. There are no restrictions or naming conventions regarding sorting layers in the Corgi Engine.
Here’s a list of all the layers used by the engine. Note that the only mandatory ones are the platform related ones :
- Platforms : all your “regular” platforms should be in that layer
- OneWayPlatforms : for all your platforms that can be accessed from underneath
- MidHeightOneWayPlatforms : for one way platforms that you want to position at mid height compared to your character’s height. While walking, the character will ignore this platform and go through it.
- MovingPlatforms : for all your moving platforms
- MovingOneWayPlatforms : for all your moving platforms that can be accessed from underneath
And these ones are pretty self-explanatory (and not mandatory at all, just used to tidy things up) :
Tags are metadata you can add to your gameobjects to find them easier from other scripts. The engine used to rely on tags to find certain objects (player characters mostly). Since 3.0 it doesn’t rely on tags at all anymore. Feel free to keep using them in your scripts though, but that’s one less thing to keep an eye on.
The Corgi Engine is not based on Unity’s physics. That’s one of its strengths, but it also means that if your game relies heavily on physics interactions, especially for your character (pushing stuff, weight puzzles, torque…), this may not be the best solution. It comes with fallback compatibility, which will allow you to still work out common interactions (flat push, pull, etc) if you want. Look at the demos for some examples of push. That said, this only really affects the characters, and you can still use physics in the rest of your scenes for things like projectiles (the grenades in the Minimal demos are physics based), traps, etc.