18
\$\begingroup\$

I want a way to make a lot of different units without having to program stuff like moveTo and Attack actions more than once

The way I see it, there are 2 ways I can do this.

  1. A single generic Unit class with flags that specifies what it can/can't do (then create instances in a static array and grab them when needed)
  2. Abstract unit class with abstract methods for Unit-specific actions like (Attack, Harvest, Patrol), which then all need to be implemented in the subclasses, even if the unit can't actually harvest anything.

the first way of doing this seems the simplest, but i would end up having a lot of code being unused for the majority of the units.

the second way could also work. But if i decide to have two different units that can harvest resources, i'm gonna have the exact same code in two different classes, which doesn't seem like the right way to do it.

Is this even the right approach to this problem?
In a game like AoE, every unit has, what i presume is, some kind of List of Actions/Orders, I would really like to know how to achieve something similar to that, where i can just code each Action/Order once, and then give it to all the units that need said Action.

If i'm unclear (highly plausible) or you need more information on what exactly i'm looking for, just ask me in a comment.

| improve this question | |
\$\endgroup\$
25
\$\begingroup\$

A common approach is to have a component-based approach where the base-class "Unit" just implements the most basic aspects all units have in common, while each unit then has a list of multiple component-objects which say what it can do and how it does it.

For example, a tank might have the components Mobile, Destructible, Attacker, an immobile turret only Destructible, Attacker and a harvester Mobile, Destructible, Harvester. These classes would then include all the code which is needed to implement these behaviors. Interactions between components (an Attacker can only damage what is Destructible) can be implemented by having the component check if the other unit has the required component and then interact with that component directly.

The advantage over a classical class-inheritance is that you can easily combine abilities. For example, when you want to have a harvester which can also attack, transport infantry and fly, you just need to add the necessary components. You can also easily add and remove new features in form of new components without having to bloat the basic Unit class.

Unity supports you in such an architecture, because the whole engine already is component-based. So game-logical components like these can be added in form of scripts.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ So in unity, would i then disable and enable the components as needed?. \$\endgroup\$ – Daniel Holst Jan 17 '16 at 20:01
  • \$\begingroup\$ @DanielHolst No, you would add and remove them as needed. You can do that in the Unity editor or with scrips using gameObject.AddComponent and gameObject.RemoveComponent. \$\endgroup\$ – Philipp Jan 17 '16 at 20:16
  • \$\begingroup\$ ah okay, but say for a "moveTo" action/order. how would the unit know when the order is done?, and how would i queue up the orders? \$\endgroup\$ – Daniel Holst Jan 17 '16 at 20:17
  • 2
    \$\begingroup\$ @DanielHolst I think you misunderstood something. The Movingcomponent means "this unit is generally capable of movement". The component is permanently attached to it, regardless of if the unit is moving or not. It doesn't mean that it is moving right now. Although you could also do it this way by adding a MoveOrder component to it and having that component remove itself from the unit when the order is fulfilled or canceled. \$\endgroup\$ – Philipp Jan 17 '16 at 20:25
  • 1
    \$\begingroup\$ @DanielHolst Now you are drifting into the direction of unit AI, which is a whole other can of worms. A possible approach would be to have a library of AIScript components which either assume that certain components are present or change their behavior depending on what components the unit is having. But that's really a far too complex topic to handle in a comment. \$\endgroup\$ – Philipp Jan 17 '16 at 20:33
4
\$\begingroup\$

A lot of games use a component-based system for entities which is where a bunch of behaviours and abilities can be added to a more generic unit type rather than being coded as part of the entity's class (or equivalent).

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ would this be extremely difficult to implement? \$\endgroup\$ – Daniel Holst Jan 17 '16 at 19:03
  • \$\begingroup\$ Patterns like this are used to make implementation easier overall. If you can't decide what approach to take, it's a good idea to just start as simple as you can and grow your choice as you being in more functionality. Once you've got more of a feel for the problem, you can either refactor or rewrite to an approach that fits your situation better. \$\endgroup\$ – Ross Taylor-Turner Jan 17 '16 at 19:06
  • 1
    \$\begingroup\$ @DanielHolst I notice your question has the Unity flag. Unity already has a built-in component system, and strongly favours composition over inheritance. One straightforward method would be to create a MonoBehaviour for each of your action types, then attach to each unit type prefab the actions it's able to perform (customizing the action instances with per-type details like damage values & costs). This keeps your unit creation data-driven, so you can easily make many custom unit types. \$\endgroup\$ – DMGregory♦ Jan 17 '16 at 19:10
  • \$\begingroup\$ @DanielHolst That depends on your definition of "extremely difficult". My answer goes into more detail about how this could be implemented. \$\endgroup\$ – Philipp Jan 17 '16 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.