In the code as it currently stands, disparate components are tied too closely to GameObjects. We should be able to add different components (e.g. Script, Transform, Model) as required rather than having one big interface. This will make further development much simpler going ahead.

GameObjects should hold a vector of multiple components, and have methods to add or remove them.

All components should have the following methods (not required to implement):

• init
• start
• update
• draw

Components should also hold a reference to their owning gameobject - this would allow them to add and obtain components themselves.

Description
The way shaders are used typically is that they are usually compiled straight after creating them. We should alter shaders to do the following:

• Provide constructor argument for allowing compilation on construction (yes by default).
• Compile the shader in constructor if so.
• Change how preprocessors work so they can be supplied in the constructor rather than being externally set.

Description
It would be nice if we could implement a system to automatically generate documentation for the code. Was thinking of using Doxygen, but spend some time researching any other frameworks for this and weigh up the pros and cons.

Description
Currently there is no production pipeline in place for merging new pieces of work into the codebase. The main task here is to research what needs to be done to create this, set up a production server and implement the pipeline.

For now, the main steps involved for the pipeline involve:

1. Development build
2. Release build
3. Run tests

Blocking issues

• TDE-3: Create unit testing framework

Currently, there are many entities (models, lights etc.) that have an update function intended to be called in the main game loop. What we want is the ability for any updateable entity to automatically have this function be called every update cycle rather than having to do it ourselves. This will likely require implementation of the following:

• Some kind of overarching Updateable interface (can tie in with a transform interface, similar to Unity's Monobehaviour).
• Some way for the Main class to store and call updateables.
• Some way for updateables to be added and removed on demand.

Consider using something like the Observer pattern to achieve this.

Description
This issue I discovered to be a prerequisite to implementing a general gameobject class. Currently we are using the old matrix functions for interacting with gameobjects in scripts rather than the new general transform class. We should be able to access transform instead and call its functions instead. This would bring the following benefits:

• Scripts are brought in line with how things work on the C++ side.
• Scripts can be significantly simplified (don't have to keep track of angles themselves anymore).
• Allows for scripts to be used with any valid gameobject, a class that will be implemented in the future.

Description
There's currently a lot of junk that we don't really need in the third party libraries (documentation, examples, binaries etc.). Identify the most obvious stuff and remove it.

Implement shadow mapping for directional lights. This should be relatively similar to the process for spot light but with some key issues:

• Implementation of orthographic projection for the projection class.
• Dealing with low quality shadow issues when projecting over a whole map.

Do some research and find out how we can solve these.

Description
Currently we can only display a single level for demoing. We would like to be able to showcase different 'levels' to demonstrate different graphical effects and techniques. Don't have too much idea about what this will involve beyond having each level load their own resouces, but we can work this out later.

Currently we don't have any kind of editor for physically placing entities, so level file format must be human-readable for now. I'm thinking of using JSON for this. We also don't have to worry about saving to a file, only loading from one.

This should also really be kept in its own sub-project as its got little to do with the rest of the engine.

This is currently blocked by TDE-15: Implement automatic calling of updateable entities

Description
Many entities in the game engine make use of similar properties in terms of position, rotation and scaling. It would be vastly more beneficial for us to have a dedicated class for storing this information and using it.

The transform class should hold the following information:

• Position
• Rotation
• Scale

The transform class should also have methods to set, or move any of these three properties by a delta. Such methods should also return a transform to allow for chaining.

Finally, it would be good to try splitting out the view and projection matrix generation, but can be done in another issue if its too much work. The main beneficiary for this is the Camera class, but drawables can also make use of this.

Implementing shadow mapping for point lights is quite different from that of spot or directional lights. We will likely have to make use of cubemaps and new shader code in order to get this to work. Do some research and find out how we can implement this.

Description
The UI menu overlay is currently created and updated in the main game loop. This is not the game loop's responsibility and this should be moved into its own separate class. In addition, the menu toggling behaviour needs to be reimplemented.

A likely improvement that also needs to be made first is changing how drawlists collect the necessary drawable items first. It would be preferable to be able to dynamically add new items to the drawlist rather than collect all of them at once and move them into the list. This could also do away with the mess of shared pointers being used that aren't really required.

Description
Currently our game loop and initialisation are all done from the Main class. We need a separate game class to separate game-related responsibilities from the main game loop. These include:

• Window creation and management
• Cameras
• User input

This isn't an exhaustive list and we do not need to separate everything at this stage. The main priority is to avoid usage of singletons for windows, cameras and user input devices, making them all accessible from the game class itself.

Changes

Testing

Additional details

Description
There is currently no testing implemented in the project. This cannot go on forever and the need for them increases as this project grows in complexity.

Main choice is the Google Test framework, but consider shopping around for others. Would also be interesting if you could find a suitable mechanism for testing the graphical side of things as well. As for tests themselves, there is no need for immediate complete coverage. Select a few key areas to add tests for as a proof of concept, full coverage can wait for later.

Changes

Testing

Additional details

Description
There's a load of stuff we simply don't need in the third party repo. Find the most obvious or largest items and remove them. Also consider researching ways to reduce the repo size, consider something like Git LFS.