Back in 2008, I met someone that was going to impact the way I view engineering. It was my car mechanic.
Every time I would take my car to his shop, he would say "don't simply fix the problem. Look for what caused the problem". That was his mantra. "Don't just fix the problem. Find the root of the problem".
Years later, as I started developing my game engine, I finally understood what he meant. What he meant to say was to always view at a problem "holistically." No problem exists in a vacuum. That in a complex system, Everything is connected, either directly or indirectly.
Having this mindset has genuinely helped. It has helped me step outside the box and look at my engine from a different perspective.
So, In this post, I'm going to share some tips to help you think outside the box and approach game engine development from a different perspective.
Let's begin
Be mindful of your engine's API
How people interact with your engine's API may break your engine.
Your job is to foresee the various ways users will use your API. And make it hard for them to misuse it.
For example, the following function, although correct, is asking for disaster:
The function asks for dates parameters: month, day, and year. However, it is easy to see how the user may accidentally swap the order of the parameter. There is no safety guard from such an innocent mistake.
A way to prevent such a problem is to create a new data type and use it as the function parameter. It doesn't change anything. But it forces the user to write out the correct data explicitly.
A good API design is akin to a good GUI design. It should be simple enough for anyone to start using it and hard enough for anyone to misuse it.
Here are some tips to achieve this:
- Keep your APIs simple so that anyone can use it.
- Keep your APIs short so that anyone can remember it.
- Keep your APIs clean so that anyone can understand it (without reading the full documentation)
Be mindful of WHAT you implement
When you are developing your game engine, think of LEGOs.
You want to provide the minimum number of building blocks in such a way that enables the maximum creative freedom.
Is about providing building blocks that enable creativity. And too many building blocks usually have a negative effect.
So, how can you determine what to implement and what not to?
This is quite simple. If a feature is too dependent on the kind of gameplay, then do not make it part of your engine.
If the feature is not dependent on the type of gameplay, then consider implementing it.
For example, Collision Detection is not dependent on the gameplay. No matter what types of game, you will need to detect collisions. So you should implement a collision detection system.
However, an AI Sense Management System may depend too much on particular gameplay, so it is best not to implement it. The game developer can work on that if his/her game requires it.
However, it makes sense to provide the AI building blocks to make the AI Sense Management System easier to implement.
For example, once a character senses another object nearby, then it will need to navigate towards the character. In this instance, providing an A* pathfinder algorithm in your engine will make sense.
So keep this in mind:
"Provide the building blocks. Not the building."
Be mindful of HOW MUCH you implement
A while back, I saw an illustration that got me thinking.
The illustration went as follow:
Imagine a system with four individual components. Each of them with an efficiency of 90%.
Do you know what the efficiency of the whole system is? Is not 90%. It is less than that. It turns out to be 65%.
The whole message of the illustration was that as we introduce more components into a system, its efficiency will suffer.
I think we can all agree with that argument.
Of course, the job of an engineer is to make sure the efficiency of a system stays within an acceptable level. But to do that, the engineer may have to "steal" resources from other components.
When it comes to game engines, those resources will be either computation time or memory space.
Why am I saying all this?
Implementing a new feature always comes with a cost. A component in your engine will end up paying the bill.
Either you end up with not enough bandwidth to perform all required computations. Or it will end up using too much space.
Providing every possible feature does not make your game engine better.
So here is a tip for you:
"Implement enough so that it is Usable. But not too much that it becomes Useless."
