DEV Community

Cover image for Postmortem of my First Game Engine Project
Roman Stanuch
Roman Stanuch

Posted on β€’ Originally published at polygonal.hashnode.dev on

Postmortem of my First Game Engine Project

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.

Image of AssemblyAI tool

Transforming Interviews into Publishable Stories with AssemblyAI

Insightview is a modern web application that streamlines the interview workflow for journalists. By leveraging AssemblyAI's LeMUR and Universal-2 technology, it transforms raw interview recordings into structured, actionable content, dramatically reducing the time from recording to publication.

Key Features:
πŸŽ₯ Audio/video file upload with real-time preview
πŸ—£οΈ Advanced transcription with speaker identification
⭐ Automatic highlight extraction of key moments
✍️ AI-powered article draft generation
πŸ“€ Export interview's subtitles in VTT format

Read full post

Top comments (1)

Collapse
 
lppogrr profile image
Leroy β€’

that's not a game engine, maybe a game framework, unless you can just change some assets, change some scripts and have the basics of an entirely new game. new devs love to use 'game engine' because it makes them feel like they are among the big boys, but it's only a baby step (which is great!).

just make games, and over time you will have bits you keep recycling. that is a game framework, and it might grow into an engine if you keep making games in the game genre. if not, it'll likely never be an engine. and that's fine too!

Sentry image

See why 4M developers consider Sentry, β€œnot bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

πŸ‘‹ Kindness is contagious

Engage with a sea of insights in this enlightening article, highly esteemed within the encouraging DEV Community. Programmers of every skill level are invited to participate and enrich our shared knowledge.

A simple "thank you" can uplift someone's spirits. Express your appreciation in the comments section!

On DEV, sharing knowledge smooths our journey and strengthens our community bonds. Found this useful? A brief thank you to the author can mean a lot.

Okay