Game Engine
In this semester we will be building a Game Engine. I would like the Game Engine to be a 2D game engine for retro style games. The reason for this is, I have a few games that I would like to make in that style and it would be way overkill to build them in the big engines like Unity, Unreal, or even Gamemaker.
I would like it if I could support tying in different Store APIs like Steam or Epic.
I will try to keep it cross platform by keeping any platform specific code to a minimum and any platform specific code I do use will be kept within wrappers.
I plan on using Microsoft Visual Studio 2019 because Visual Studio is the only IDE I have used and I have a limited amount of time to work on the engine and don't want to take time away from development to learn a new IDE. Plus I've gotten fairly fast with it and have memorized a lot of the macros that might not translate to other IDEs.
Engine Components
Graphics Manager
The engine will include the a graphics manager for managing the drawing of sprites, using the flyweight design pattern to keep track of their actual texture memory locations and an array of all the sprites. It will also manage drawing them and in what order. The Graphics manager will hold a rect which will represent the Camera for the game. The rects will be used to manipulate the sprite's rects right before drawing them.
UI
Next would be the UI. UI would be a companion to the graphics manager except it would be drawing it's sprites in the screen space instead of world space. They would support dynamically drawing text have resizeable (without stretching) borders, along with support for mouse click / screen touch. They would also support blocking each other. So if one UI button is being drawn over another one, it can be set so that a mouse click will only register on the top one.
Physics
The next component will be the Physics system. The physics will be outsourced to Box2D.
Input
The Input Manager will be taking in generic non platform specific questions assigned on the game side instead of the engine along with what the key pertains to. Kind of like Unity. An example would be on the game side, you'd program the key "Horizontal" axis to be 'a'/'d' or left/right arrows or horizontal on the left analog stick. It would support multiple inputs for the same key.
Audio
For some reason, this my least favorite part of game dev. Either way, a game engine can't be complete without it. The audio will keep track of all the audio tracks for the game in an array. Any object that has its own sounds (like a gun's shooting sound) will keep a pointer to it's sound in the manager's array. The manager will have a function for playing sounds. Something like this:
bool PlaySound(Sound* sound, vec2 position);
GameLoop
I will have in the main Game class, and While loop that will continue until told otherwise. It will be in charge of updating the renderers, physics engine, and UpdateManager. The UpdateManager will house a list of "Updateable"s which will be a class that things I need to update can extend. Maybe not the best way of doing it but in my head, it seems like it could work. Things like GameObject will extend Updateable and then in their Init function they will register themselves with the UpdateManager which will then add them to the list. (It is done in their Init function because they are in an object pool so they won't be using their constructor when re-enabled) They will deregister themselves when "destroyed" or disabled in the object pool.
Components
I would like there to be a ComponentHolder class which other classes (like GameObject) can extend. Maybe this should just be a part of the GameObject class and that's probably what I'll end up doing. But separating them would allow for me to let other things hold components without necessarily making them GameObjects.
GameObject
There will be an object manager that houses a list of all the objects and utilizes an object pool so as to not fragment memory.
It will handle creating and destroying objects by enabling and disabling them in the pool. They will extend from both Updateable and ComponentHolder. Other than that, they will just be an empty shell.
Event Manager
It also makes sense to have an Event Manager. I'm not too sure how these work though. I would maybe give the EventManager an Event List that other classes can register events with. Then maybe classes can subscribe to the events? Just writing that here I can tell that's probably not how I should do it.