Let's have some thoughts about the overall design of the source base

[amtoine]

from @gbrivady in #2

Conception

On a more subjective point, we should take some time to discuss whether or not the project is flexible enough to be build on. This will require a lot of discussion (that we will keep out of this PR, unless you see an obvious flaw that can be fixed), but it would be nice if everyone could think a little bit about this while reviewing the code. To help with this, I have attached an elided UML of the current state of the project at the end of the PR. I try here to brief on all the subsystems.

Graphics/Display

Prettry straighforward. Straight pipe between the engine and the SFML library

Box

System that will handle intersection of shapes. Currently used for collisions, soon to be used for the combat system (hitboxes and hurtboxes f.e.). Only implements rectangles as making several shapes interacts is a big headache, and is not exactly required as of today.

Physics

Contains a simple gravity to make objects fall; and a not so simple subsyste,

Input

Simply translates keys to entity movements. Very very basic, lacks a lot of stuff including a jump subsystem, proper buffering of input, animations, etc...

Universe Master

I think this is the strongest point of the conception. I believe the code illustrates by itself the beauty and simplicity of addind/removing/updating component to the game.

Entity

Keystone of our Entity-Component-System, yet I fear it is already outdated. Please pay attention to this class in particular and think about way to further separate the entities and the components that I find currently too linked.

UML diagram

Not complete, lacks a LOT of methods, attributes, access control...

⚠️ let's discuss that in here, shall we 😌