# Unity Special Rules in a Turn Based Entity Component System

This topic is 2075 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello,

I'm currently planning on implementing a tabletop game in the spirit of Warhammer 40k.

This is a turn based strategy game with lots of special rules.

Why a entity component system?

• Units have special ability, which could be realized each as a component
• Area effects such as fear, could also be realized as a component indicating that a unit is affected by fear
• Each race or army type have there own special rules
• Special rules generally only effect some part of the system, e.g., movement or shooting
• Ease of integration in Unity (make games not engines  )

So what is the problem?

How to realize the special rules?

Example:

To perform an action two six side dice are rolled and the sum is compared to a threshold.

Lets assume a special ability or effect that modifies this test as follows: instead of two dice three dice are rolled and the highest result is discarded.

Another effect might case that an additional dice is rolled and added to the result.

So the combination would be: roll four dice remove the highest and add the rest up.

So in a perfect world the rules do not have to know about each other.

But should be able to override each other such that an ability can cancel out an effect.

Would you ...

• implement the abilities as flag components? And put there effect into each system, e.g. shooting or movement system?
• put the logic of the ability into the components?
• have the logic of the ability as another component, where one could have many components of the same type, if the effects can stack?
• any other ideas?

Of course if you are missing an information please feel free to ask. Also I'm looking forward to suggestions of different approaches.

##### Share on other sites
This is just my personal take, but it sounds to me like you really want to write a component system but don't actually know why they are useful or when to use them. Your reasons are square peg/round hole to the extreme.

I think you've picked the wrong tool for the job, or maybe the wrong job for the tool.

##### Share on other sites

Very well then.

But what would be the 'right' tool?

Which would be the 'right' method or pattern to use in the above sketched example?

##### Share on other sites

Well, if I'm reading you correctly, it seems the issue you have is with event communication.

The "Event" that is occurring is a dice roll.

Ignoring everything else,  the event taking place is a dice roll.

Now, from what you describe, there are a number of dice-roll types that can occur.  2-dice, 3-dice-subtract-lowest, 4-dice, etc.

Those events must be communicated to all interested components.  The most generic way to do that is to broadcast the type of dice-roll, and then the dice.

Broadcast(4-DICE-ROLL_ENUM, 6,3,2,6)  //where the enum tells what kind of roll, and the 4 numbers tell what the rolls were.

You can package the message up in a million different ways, the important part is entities and/or their components need to hear about it, and react by changing their internal state, and/or sending out their own messages.  One of the entities/components may score that roll as a hit, and set it's internal state to dead, while sending out a "Died" broadcast message to all the other entities/components.

So, to directly answer your question, I guess you would say you "put the logic of the ability into the components".  Because they have to deal with these events as they see fit.

##### Share on other sites

[quote name='ApochPiQ' timestamp='1358372763' post='5022315']
Composable rule systems
[/quote]

Thank you very much!

I'll look into your suggestion and will report back on my progress.

##### Share on other sites

I think your problem is just reducing the complexity by separating those dice throws from interpreting them. Why not make make some simple classes to do them and then have each component which needs a different algorithm use its own different instance of that? For example like this:

class Dice {
Rng& rng;
int sides;
public:
Dice(Rng& rng_,int sides_);
int DoThrow() { return rng.GetNumber()%sides+1; }
};

class DiceThrower {
// some variables to remember how to calc all the throws
public:
DiceThrower(Dice&);
SetDiceNumber(int);
SetRuleRemoveHighestDice();
// ...
int DoThrow();
};

class Component {
virtual ~Component() {}
// ...
};
class MoveComponent:public Component {
MoveComponent(DiceThrower&);
// ...
};
class ShootingComponent:public Component {
ShootingComponent(DiceThrower&);
// ...
};


##### Share on other sites
If you can give me any good reason whatsoever to write that code in a "component" style instead of just providing a DiceThrower class and using it simply and sanely, I will buy you a six pack of the beverage of your choice.

##### Share on other sites
If you can give me any good reason whatsoever to write that code in a "component" style instead of just providing a DiceThrower class and using it simply and sanely, I will buy you a six pack of the beverage of your choice.

LOL

Ok, I can't do that.    But was thinking about a similar problem for my hex-based war game.   Where like the question above each unit-class can have special rules that exempt them from the "normal" base rules.    Now this can be more complicated that just the number of dice.    To give two different examples...

ALL units move at 6 hexes per turn.    Well except a select number of fast units.   They move 7 per turn.

ALL units calculate attack damage with "formula Y".   Welll except for "maulers" which use "formula Z".

and so on...

Initially I thought about just making those flags in my unit data table and the code would just check the flags and deciede what to do.    With all my recent reading though it seemed like a componet system might be a nice way to handle this.

I think (please correct me dragongame) this is similar to what the orginal question was about s/he just gave the dice throws as an example.

So based on that is going the componet route just overkill?

##### Share on other sites
Component systems are a very specific tool for solving a very specific problem.

To wit: components solve the case where you have a lot of common functionality that needs to be recombined in an unpredictable number of combinations, but with consistent rules as to how the combinations should work. A classic example would be building cars. Every car is a collection of a drive train, wheels, body, accessories. A component system lets you assemble a car from any combination of the requisite kinds of parts. I can come along in 6 years and assemble a totally new type of car just by combining the latest and greatest version of each part. The whole totality remains a car; if I want to change gears and start building houses, I need different code. But so long as what I'm building is still a car, my component model serves me well.

What it sound like you want is just a data-driven architecture. A unit has some properties: how many hexes can I move in a turn? Most set this to 6, some set it to 7, or 5, or any other number that you pick. A unit has an assigned damage formula. Again, most use Y, some use Z. Or if you want to introduce Q and J, you can add the formulas as new options and just pick from those (think enumerations here). Hell, if you do it right, all of them use formula K and just provide different coefficients and constants.

A rule of thumb I would suggest regarding component systems: if the vast majority of your component implementations involve less than 10 lines of unique code that is specialized for that component type, you're doing it wrong.

There's nothing bad about simple components, mind you; but most of them are going to be fairly rich, not trivial.

For your case, movement speed is trivial. Damage formula is trivial. In the OP's case, basically everything that would have been a component is really just a function.

Put another way: start your organization by grouping lines of code into routines. Group routines into modules (classes, namespaces, packages, whatever your language of choice considers a cohesive unit). Group the use of modules into components. Group components into entities. Group entities into worlds.

If at any point you don't have enough stuff to make a group (i.e. fewer than 3 of something), stop building additional layers of organizational abstraction.

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 9
• 23
• 9
• 32
• ### Forum Statistics

• Total Topics
632624
• Total Posts
3007505
• ### Who's Online (See full list)

There are no registered users currently online

×