Introduction:
This post will detail what I have learned from working on my first game engine Polygame V1. While I wouldnt consider the engine fully complete, I felt I had learned enough that I wanted to start over with a new version of the engine. Below is a video demonstrating the features the engine supported: rendering sprites, basic gravity and collision, and input.
Build Systems:
Polygame is the first exposure Ive had to setting up build systems. Prior to this project, I had worked exclusively with Visual Studios built in system which was fine when only working on one machine, but troublesome when moving work to my laptop where all of the include directories and library linkings were not setup. To create Polygame, I started with a Premake template provided by the Cherno. While I didnt write the code myself, I was able to learn how basic build systems work, and I am using that knowledge now with CMake on most of my current projects.
Documentation:
While creating Polygame, I used Githubs wiki feature to document the classes I had created and what each of them did. I found this to be a huge mistake as my classes were changing so frequently that I would constantly be going back to the wiki pages to update them. Its clear to me now that I should have looked into an automatic documentation tool such as Doxygen. One of the reasons I created the documentation was to plan out how different systems would be architected, but I dont think it was the best way to approach that either. I have found that writing text is not the best way to architect a system, and a drawing tool or pencil and paper is better for visualizing how the different components of a system will come together.
Rendering Architecture:
The way I set up rendering is the biggest flaw in Polygame V1 that made me want to transition to V2. The way the system works is it takes in a pointer to a GameObject class I created. Each game object was a part of a linked list that would contain all of the objects in a scene. The renderer would traverse the linked list and get a RenderInfo struct from each GameObject that had one. The way I determined whether or not a GameObject had RenderInfo was to create a child class of GameObject called WorldObject that had a GetRenderInfo() method. This meant that every time the renderer went through the linked list of GameObjects, it would have to perform a dynamic cast to WorldObject to get the render info. Looking back, I can see that one major issue is how tied the renderer was to the scene as a whole. The renderer really shouldnt have been responsible for getting the RenderInfo structs, it shouldve been given them and known nothing about the GameObject class as a whole.
Conclusion:
While Polygame V1 didnt turn out to be all that great, I would consider the experience I gained from it invaluable. Having only worked in prebuilt game engines up to the point of creating Polygame V1, I was able to learn a lot about working in a raw C++ environment without any garbage collection or other safeguards to help me. While I only mention 3 major lessons I learned from this project, there are plenty of smaller bugs and quirks that I gained experience working through. It may be overstated, but the true value of Polygame V1 wasnt the engine, it was the lessons I learned along the way.
Author Of article : Roman Stanuch Read full article
