Since the completion of the latest quest - the quest for the holy game engine - I noticed that if I were to use the traditional entity inheritance structure, I would have to rewrite most of the code in order for it to be suitable for future game projects. Other than that there is some major issues with an inheritance structure and that is the fact that you will be implementing tons of new classes that will eventually change the structure of the inheritance layout which means you will have to refactor, or put the features in the base class.
Now this frightens me, not only takes it longer to implement new classes due to refactoring, and you will not be able to reuse the code due to the coupling through major inheritance. There is a lot of code that needs to be modified if you simply try to copy & paste it into a new game project... ouch. There is at least one good thing about this structure and it's the low time complexity compared to other structures.
But still this annoys me greatly to have to rewrite code all the time. For a company, that would be quite a lot of unnecessary money that could have been spent in other areas, such as stocks or a bigger salary for the CEO. So the general question that barked at me was how would I make my code reusable, so I would not have to rewrite health, damage, control mechanics etc. all the time?
When in doubt Google... Several hits revealed that there is a structure called "Component-based software architecture", this was the first time I've ever heard of component-based software engineering, except for the subcategory about pipelines.
What is this? What are components?
If you have a function that spans over several big classes, you separate these functions, put them in their own classes, and keep the "big class" as the container for these smaller classes (components). Now we will not have to rewrite a lot of code, but simply create an instance of each component in a class. The key is to isolate these components from coupling to keep the components as reusable as possible for future projects. Now the major disadvantage of this is that we lack communication among components. It will happen that some components need information from other components, coupling is one answer but it's a step back, makes the code less reusable since it's dependent on the code of a specific component.
The typical approach for communication is to create an event-based structure to send messages or events when something interesting is happening - a form of a finite state machine. Now this will increase the time complexity somewhat and might increase the response time. Therefore you may have to combine with some level of coupling if speed is desired between specific components.
There is not a lot of information how to implement this in practice on Google or in the books that I've checked, but there is loads of theory behind component based software engineering to keep your code reuseable. This is far from new, and has been a topic since the 60's it seems, although the theory was probably quite different back then when object oriented programming languages did not exist. It was probably discussed in the forms of modular programming at that time, I am only speculating though.
I am already implementing this kind of structure for my current game project, and see exactly how slow the responses will be, and try to optimize enough to make the game enjoyable. It will be worth to invest time into this, and in learning these approaches that are probably used all the time in the hardcore world of software engineering.
Once I have succeeded in this task, I will definitely share the source, but until then I will keep it closed since it will probably mislead people or include bad practices for starters.
