Subscribe to download
2D_Gamelib_UnityStyle_Public

This a basic 2D "engine" that expands on the idea of the newly released rg_game library example.
It was however wrote from scratch with a design structure based on how Unity seperates and does things.
The code might not be the best because I've done this project for the purpose of learning Lua.
Feel free to use it however you like.

Everything exists as GameObjects with components such as a Transform, SpriteRenderer, Animator, BoxCollider and Rigidbody.

The SpriteRenderer and BoxCollider work independently of each other as they are linked to the GameObject independently through the Transform. This means that an object can have one or the other, both or none at all.

The BoxCollider can be flagged as being a Trigger so that collision is ignored but can be checked to know when an object is inside its bounds.
Each collider needs to be flagged with layers (one or more). There are two lua scripts that hold the layer interaction "matrix": CollisionLayers.lua and TriggerLayers.lua. When resolving collisions it will only check colliders that interact with its layers. For example the "player" layer can collider with the "static" layer as specified in the CollisionLayers.lua file. But if I remove it and leave it empty the player won't collide with anything.
Same thing with TriggerLayers.lua but this will apply when checking for triggers.

The Animator requires a SpriteRenderer to exist in the GameObject it is added to, but works independently from the SpriteRenderer itself. The Animator will be updated before the sprite is rendered and will change the spritesheet and spritecoords of the sprite to be rendered. If you delete the Animator mid animation the SpriteRenderer will simply continue to render the last sprite it was given.
Animations are composed of a name, a spritesheet, time between frames, an array of frames, whether it loops and if it transitions to another animation when it ends (animation name). A Frame is simply the sprite coordinates inside the spritesheet.

You can Destroy all the components independently, except the Animator will also be destroyed when its SpriteRenderer is deleted. You can also Destroy a GameObject which in turn will destroy all its components.
In order for memory to be released by the Garbage Collector no reference to the tables of neither components nor gameobject have to exist. To do that a ReferenceManager exists and no other table should keep references to objects or components. The player is the only object that is seperated for easy access: RefManager:GetPlayer()
There is a method to directly access other objects by its UUID, RefManager:GetObjectByUUID(uuid). The UUID of a GameObject is returned when creating it through the Lib's CreateObject() which you can keep somewhere to access the object later.
This limitation can be ignored if you don't destroy objects during gameplay or don't care about memory :)

The Rigidbody does not need a BoxCollider to work so if you just want to make a sprite use physics you can. It only implements gravity and constant forces that need to be applied every frame (e.g. wind). After moving the object it will handle collision if it has a collider assigned when creating the Rigidbody.

You can access collision/trigger information inside the collider. For example the player's collider will have information about what it collided and triggered with.
"collider.collision" has global collision info that summarizes the previous collision results.
"collider.collisions" is an array of all the collision it received.
Finally "colider.triggers" is an array of all the triggers it was inside of.
These three tables/arrays get wiped at the start of every collision detection cycle. This means that the information is a result of the previous frames movement and collision.

I've also added a PlayerController based on Celeste's movement that uses every component for a quick example. As well as a Coin object that can be collected by the player and displays the coin count on screen.