Yes you read the title right and im going to show you the general architecture of my engine and the hacks i used during the jam to make a game that used such an UNSTABLE engine!

https://ldjam.com/events/ludum-dare/49/unstaballz my game btw :)

my engine was lacking numerous features: -particles -font rendering -physics -editor -scene loading -easy resource management and lots more some of which i created during the jam!

on top of that it had no web build support!

my engine operated similar to unity. a scene was composed of a vector of gameobjects. GameObjects had a vector of components in which all inherited from a base component class which had methods Built in such as Update draw and start. First the gameobjects were looped through and then their components were looped through and called methods appropriately.

Scene:

gameobject | gameobject | gameobject

comp1 comp2 | comp1 comp3 | comp3 comp2

GENERAL GAME ARCHITECTURE during the jam i kept it simple choosing to make a simple endless game. It was still a pain though as my engine was so underdeveloped with scarcely a month of preparation. My idea was to make a basketball that unstably sprouted boosters that you had to modify to stay afloat. It was pretty simple to implement.

PLAYER CODE I had a player class from which extended all the game logic. It had a vector of boosters which were themselves gameobjects because I lacked a parenting system i made the parenting system inside of the player class overwriting the positions of the boosters to extend outwards from the center of the player. the boosters themselves were really just aesthetic because their behaviour was controlled inside the player class. physics were just a cheap imitation of real world physics as i used some incredibly hacky physics code to constrain the player inside the boundaries.

PARTICLES! I wrote a quick and hacky particle system during the jam. although hacky and quite limited it remained pretty solid and usable. A particlesystem component in which resided a vector of particle structs.

GLOBALS i needed a way to access stuff from everywhere although considered bad programming practice due to my laziness and the general easiness of globals i stored a global value in which a function would give a pointer to the main camera and many other things this was the general design of the globals. pretty hacky and stupid but oh well.

some drawbacks of such an engine though is the unsolid parts. At one point i figured out that my windowing and mouse input were all broken! i spent half a day fixing it and was so exhausted i barely did anything else.despite all this and much more hacks i used the game remains performant and running and since i had so much control over these things i could modify easily anything i wasn't happy with. With my custom engine i had both the convenience of a simple gameobject and component system and the control of being able to modify ANYTHING!