koobas.hobune.stream
How should I structure my unit class relationships?
I want to structure my classes in a way that makes sense and is easily adaptable when implementing new types of units etc.
I was thinking that I'd have a base Class: Unit. This class would define the abstract interface for all the Units including players and AI.
I would then have three classes that Implement/Inherit from Unit. They would be the different elemental types of the Unit.
So i'd have the following:
FireUnit : Unit
WaterUnit: Unit
EarthUnit: Unit
My problem is that I want players and AI units to act differently but still use the same Unit classes.
I can't seem to get my head around how this would work. Would Unit inherit from player? Or would player inherit from Unit?
Hopefully this makes sense, I'm quite new to OOP so I'm not even sure if i'm asking the right questions!
Thanks
Really I'm just thinking how the Player Class and Enemy classes would be defined.
For example, if the player class was defined:
Player: Unit
Would I be able to set the Player = new FireUnit()?
The best approach is probably having your Unit class delegate most of its logic to sub-modules which you can swap as needed. So, your unit's $$anonymous$$otor modules could be identical, but the Control modules would be different - AI units would get a version driven by AI logic, while the Player gets a version that accepts input. A great use-case for Interfaces.
You wouldn't be able to set Player p = new FireUnit(). This is against the rules :)
Could you tell me more about what FireUnit means in your game? Then I could give you an answer how I would do it.
In game development and especially in unity it often makes sense to use Composition/Aggregation based development rather than using a lot of inheritance.
e.g. Player and AI are very different but they might share some properties like life. Ins$$anonymous$$d of having the class Life and Player and AI inherit from it you could just give Player and AI a member variable of type life. You can still gain the same advantages of polymorphism by using an interface.
@devluz The Unit Class would hold the basic attributes like Health, $$anonymous$$ovespeed, Name etc.
FireUnit would have different functions for its abilities e.g. Ignite; Whereas a WaterUnit would have a function "IceBeam"
Thinking about it I could just call them "Ability1", "Ability2" etc in the Unit class and then have them do different things within FireUnit and WaterUnit.
Also the takeDamage for example would be different in each childClass so a FireUnit would take increased damage from a WaterUnit.
Just to elaborate if I wasn't clear.
I'd want the player class to be able to inherit from FireUnit, WaterUnit or EarthUnit. I'd also like the AI to be able to inherit from these classes.
$$anonymous$$aybe inheritance isn't what I should be using here?
Inheritance would look something like this... but player and ai can only inherit from one of the element unit classes. (Sorry for the crappy paint job :P)
Thanks for your input btw guys.
Ditch deep inheritance (for the most part) and use components to go wide instead.
Each GameObject has the following components
Movement component
Weapon component
Armour component
Input component
Then each component type can have an inheritance structure
Movement component is the base for
Tracked
Walker
Flying
Weapon
Gun
Flamethrower
Water pistol
Input
Player controlled
AI (You can further derive for different AI behaviours)
Get the idea?
Your AI component simply requires a TypeOf(Movement) to be present. The AI interacts with the movement component, and never needs to know exactly what type of component it is dealing with.
The weapon component behaves the same if it is fired by a PlayerInput or an AgressiveAI2. Again, it doesn't care.
Alright, I think I see where I went wrong.
Since the Units themselves defined their "weapon" type, I was looking at it in a different way.
If I think of their element as a component of the Unit class then that makes it a lot easier to wrap my head around!
Thanks everyone for your help! This is a great community :)
