it should be possible to exchange e.g. the graphical functionality.
for this matter add at least a:

• GraphicsInterface
• SettingsInterface
• AudioInterface
• EventInterface

The graphics interface has major priority!
Also think of a way to pass all interfaces as a whole (InterfaceContainer?)

How are these interfaces to be initialized? Builder pattern??

separate structural methods from game loop and other ones

Add HierarchicalObject and ActivatorObject classes.

By now the communication between the ImageInterface, FontInterface and GraphicsInterface is not as good as it could be.

A general texture need further properties in order to be rendered properly (or just to add flexibility).
A texture needs at least:

• a size
• a position
• a rotation angle
• a boolean flag for flipping horizontally and vertically
  (add more if reasonable. nothing library specific!)

Also think about what the ImageInterface/FontInterface should return. Are own Texture derivates needed or suffices Texture?

Node: Sizes and positions are relative to the parent (the element's renderBox in this case). The angle should be in radians.

This is meant for members like name, renderBox, collisionBox, etc. and NOT for vectors or current/activated instances or indices.

AnimationUtils should be responsible for:

• adding textures
• removing textures
• retrieving textures
• providing the texture count
• setting the frames each texture get displayed
  (add more if reasonable)

The name of a texture should be used as identifier where needed (a name field may not exist yet...).

Derive from GraphicsInterface and implement all functions using the SDL2 library.

If the interface need changes, implement them too.

The SDL EventInterface has already been implemented (legacy_snippets/) but it may not fit into the new structure.

Merge it back into our main workspace!

SceneUtils should be responsible for:

• adding elements
• removing elements
• retrieving elements
• providing the element count
• moving elements to different collision layers
  (add more if reasonable)

The name of an element should be used as identifier where needed.

To avoid loading the same image again and again we need an image cache to store the resulting texture.

Should this be implemented directly in the ImageInterface?

if should be possible to save the current state of a Game and restore it later on.
as serialization format should the JSON be used (possibly with https://github.com/nlohmann/json)

user defined derived classes should also be able to be saved.
minimize the code for the type registry (hardcode the default classes?)!

The builder classes should not automatically try to add an instance when there is no parent.

To avoid doing the same calculations again and again we need a caching algorithm for loaded Fonts AND rendered Textures.

Should this be implemented directly in the FontInterface?

By now objects can only be queried one layer at a time. This can result in frustrating and messy code.
To prevent that each object should be accessible from everywhere in the hierarchy. The new unique names should be of the following format:

<sceneName>[<typeID>].<elementName>[<typeID>].<animationName>[<typeID>]

To make this work naming should follow the same rules as variable naming does!
The optional typeIDs can be used to resolved ambiguity. Most of the time it won't be necessary but with elements containing child elements and animations in the future it will be helpful.

If possible try to implement the query methods to parse the string on compile time even if the format needs to be adapted!!

ElementUtils should be responsible for:

• adding animations
• removing animations
• retrieving animations
• providing the animation count
• "activating" an animation
  (add more if reasonable)

The name of a animation should be used as identifier where needed (a name field may not exist yet...).

The Entity class has already worked for older versions.

Merge it back into the main workspace and write tests for it!

Derive from ImageInterface and implement all methods using SDL2_image.

If the interface does not suffice, change it and implement the changes in the structure too!

GameUtils should be responsible for:

• adding scenes
• removing scenes
• retrieving scenes
• providing the scene count
• "activating" a scene
  (add more if reasonable)

The name of a scene should be used as identifier where needed.

As all these classes get more and more complex it has to be something done against is
The simplest approach would possibly be to implement a factory pattern. This would also allow to differentiate the overloads with reasonable names.

Other methods of object creation should not be allowed at all (friend class?) !

percent instead of pixels

Methods for adding, removing and querying children are identical for (most) core classes.
Create a base class with basic implementations for adding removing and querying (the querying methods should be stubs. that will be a separate ticket).

It should also be possible for inheriting classes to somehow modify the adding/removing process. Scenes for example need to add their elements to the right collision layer too!

Derive from FontInterface and implement all methods using SDL2_ttf.

If the interface does not suffice, change it and implement the changes in the structure too!