I get you, but then Car Parts have categories of their own, like ‘Engines’, ‘Wheels’. If you know every engine you ever want to make has an output ‘Rotation’, why not just inherit from that whenever you want to make a new type of Engine. At least that’s how I look at it. In this case, interfaces between classes would just seem really unclean to me, the analogy for me is it’s like bodging a cruise-liner engine into an aeroplane. We want ‘Rotation’ to be ‘Thrust’ now for example. Doesn’t make sense to me.
In my case, I know that all the Vehicles in my game need to share a lot of the same functionality. The various sub-classes of vehicles might hover or fly or drive… but each sub-class of vehicle can still set that independently, while still allowing for variables like “Occupant” or “Array_Occupants” etc.
IDK, the inheritance/sub-class system just makes the most sense to me, at least in cases where I’ve needed to program in code, rather than programming loads of discreet classes that might do the same functionality in a lot of cases, but involve you having to go through an interface to actually use them.
I tend to make a baseclass for most things, in my game I have an Item class, where in blueprints I can make different versions of that Item but it generally has the same functionality (eg: pick up / destroy). I did the same for the base pawn class, which has all of the main functionality then I just create a blueprint of a different character. I don’t know if this is an inheritance method or composite, since I came straight from UnrealScript. However, it makes the most sense to me.
In nutshell. The easiest way to approach component based design is:
Create aggregate class, which will aggregate various more or less related componenets.
Create base component class, which might implement core functionality needed by all componenets.
Create specialized componenet classes.
In case of Car, you would have class Car. You don’t care what exactly car it is, or how many wheels it have or how many engines.
Engine is component.
Wheel is componenet.
Subclasses of these componenet may or may not implement additonal functionality. In most cases they will just differ by default properties values.
Implementing each car as separate self containing entity doesn’t make any sense, since there are many discreete componenet, which are used to assembly single car.
There is place for everything.
But IMO it’s best to implement not really related functionality in small componenets, and the use inheritance if you need to add new functionality to these componenets, which might be specific to them or when you need different default properties.
In unreal this system would be even more awesome if we could create blueprint componenets, and swap default subobjects (componenets) in actor at runtime.
Data Oriented Design is not only about performance, it’s about focusing on the problem (data) and not about the tool you are going to use (code), it’s a different and reverse approach to Object Oriented Design.
DOD does not preclude object oriented programming or meta programming or structured programming or whatever and it doesn’t preclude abstraction. You can apply it even on managed and interpreted programming languages, not only to native like C/C++/Objective-C. It’s a different methodology of think the problem and solving it. In my experience a data oriented designed code is simpler to read, simpler to write, simpler to maintain and simpler to debug (and of course it is simpler to improve its performance).
Yes, if you learned high-level programming as a synonym of object oriented design only it could be difficult at first to change your design (idea) of programming, but you should give it a try, and not only on critical performance code.
Unfortunately a lot of people do not learn how hardware works, what semantic is, how compilers works and they see OOD as the only way to code with abstraction; or they code in a OOD way since they think they have not to deal with pointers, but in reality they are adding pointers everywhere and they only throw away pointers’ arithmetic (which doesn’t cover nullpointerexception XD).
How I deal with pointers in DOD code? I usually use them only in the lowest level of abstraction and a lot less I did when I coded in a OOD way.
Bad HS teachers and very bad Uni professors everywhere.
I mostly am using deep inheritance structures for my classes. Mostly cause one of the first professional codes which I studied was the UT3 present in UDK. Sometimes I have wanted to use ActorComponents but have not used it until now.
It will be really helpful if some one could make a guide on the best way to use ue4 actor components. Also I wanted to know how does a component based system and replication work with each other.