Many many many times it seems as if I'm not progressing in the game engine. I tend to obsess about the architecture of the engine. I move things around, put them back, completely modify the engine until I have something that I think is optimal.
I tend to look for things that allows the engine to be flexible and modular. I also strive my best to avoid any code duplication. I love minimalism and I tend to code the same way.
However, in the last couple stages of development, I forgot to keep the above rules in mind.
Let me explain. Currently I'm working on implementing collision detection in the engine. I'm working with two algorithms. One is called GJK algorithm and its purpose is to detect a collision between two objects. This algorithm simply returns a True or False.
The second algorithm is called EPA algorithm and it generates the contact manifold, i.e. Penetration depth and contact normal vector.
What I did was the following: I created a class called GJKAlgorithm and in this class I implemented two methods:
- A method which determines if a collision occurred
- A second method that determines the contact manifold, i.e. EPA algorithm
You may say, so what is the problem?
The problem is that by making one class responsible of a) detecting if collision occurred and b) getting the contact manifold, I'm making the engine static.
Imagine if a year from now, I read about a nice algorithm which is twice as fast as EPA and provides better collision information? How would I implement this new algorithm? I will have to modify/remove code that I currently have in order to give room to the new algorithm.
See, this is bad design. The engine needs to be modular. It needs to be flexible. I always try to follow these rules of Object-Oriented Programming
- Encapsulate what varies
- Code to the interface, not to the implementation.
- Favor composition over inheritance.
- Strive for loosely coupled designs between objects that interact.
- Classes should be open for extension but closed for modifications.
- Depend on abstractions. Do not depend on concrete classes.
- A class should have only one reason to change
In this instance I was breaking rule 4,5 and 7.
I was not making my engine loosely coupled between objects. I was not making them closed for modifications and I was making a class responsible for two operations.
So, I decided to make each algorithm a class and make them both sub-classes of a super-class. If in the future, I find better algorithms, I will be able to simply plug them into the engine without modifying my current algorithms. This keeps the engine modular, flexible and clean.
PS. Sign up to my newsletter and get OpenGL development tips.
