A very long time ago, I made the decision to write my own game engine from scratch. If you want to get anything done well or in a reasonable amount of time it’s a terrible idea, but it does serve as a great vehicle for exploring best practices in performance-critical code.
One area of interest is how to describe large numbers of in-game object classes. I wanted to be able to add a class and its properties with as little code overhead as possible to avoid huge source files and maintenance difficulties.
Startup performance was bad under this system. Well over half of the reset time was spent in ObjectMakr’s instantiation. Using this screenshot of a captured performance profile, can you guess why?
In its original design, ObjectMakr processed all class functions immediately.
That’s the big green chunk in the center.
We’re talking hundreds of dynamically generated
class objects all being created and assigned properties before the game can do anything.
Important performance protip: minimize unused work. Out of those hundreds of objects, maybe a couple dozen would be used immediately. I changed ObjectMakr to only instantiate classes as needed, and voila! Reset performance was suddenly much better.
Use only what you need.
Laziness is good. When designing startup flows, I like to think of each application component as a node in a directed acyclic graph (DAG). If you map out the components this way and do an exhaustive search starting from the “everything is ready!” state, you’ll notice which parts are or aren’t required to get there.
Probably don’t write your own game engine.
On the one hand, I’ve learned a ton from it and have an intimate knowledge of all its ins and outs. On the other hand, there are plenty of great open source alternatives for every popular platform yet I’ve sunk way too much time into this thing. Were the learnings worth the time investment? Great question.
By the way, I have multiple game engine versions. The title doesn’t have a typo!