How to organize logic for table-like feature set? Looking for architecture pattern advice

Perhaps a shift of perspective can help you.

You seem to describe all feature implementations as "the so-and-so feature of battle type such-and-such". Is there some inherent concept about those features, that you have not abstracted yet?

For example, let's say your battles types have a ground feature that can modify movement speed. For instance in forests, troops move 50% slower.

class BattleType: def __init__(self): self.ground = GroundFeature() def modify_troop_speed(self, speed): return self.ground.modify_troop_speed() class GroundFeature: def modify_troop_speed(self, speed): return speed class ForestBattleType(BattleType): def __init__(self): self.ground = ForestGroundFeature() class ForestGroundFeature(GroundFeature): def modify_troop_speed(self, speed): return speed * 0.5 

Now imagine we rename ForestGroundFeature by SlowingGroundFeature and add a bunch of others. Now you can compose your ForestBattleType from features that have meaning of their own:

class ForestBattleType(BattleType): def __init__(self): self.ground = SlowingGroundFeature(0.5) self.visibility = DenseVegetationVisibilityFeature(density=2.5) self.random_events = DinosaurAttackRandomEventsFeature() 

Pros:

• Linear instead of quadratic amount of functions needed
• Probably less code duplication, and more code reuse since features probably do similar things

Cons:

• Good abstractions are hard to find. The system may be more complex to code now, but should be easier to understand later.
• Using a feature palette is less flexible in the short term than free coding for every type/feature combination. You may need a way to combine features or just move to a more complex BattleType model than your 10-feature-slot model. It may end up looking like a domain-specific language, as @rwong commented.
• I don't have a suggestion on how to compile-check this, but it may not be necessary since the BattleType implementations are easier to understand now.

(Answer to comment)

I took a look at your diagrams, Pavel, and I can't shake the feeling, that the table metaphor isn't the most helpful. Just having the grid fields makes people want to fill them in, even if nothing fits very well.

When I thought about the "feature palette" metaphor, I had more of a layer system in mind:

I think, this promotes a more manageable code base. I'd start out with a simple scenario and add one implementation for each layer. Sometimes a single, well-generalized implementation may be good enough, others will need branching out. (Side-note: what the layers should optimally be is probably a very difficult decision. You seem to have thought about which parts of the logic need to be adjustable, which is good.) Saying from the get go, "ok, we'll need 10 implementations for 10 scenarios each" seems like an invitation for trouble. Whenever your architecture slightly changes, you will have to modify at least 10 places. As more Battle types or Features get added, this gets harder and harder.

Take my opinion with a grain of salt, though, I'm only three years in the industry ;)

You seem to have skipped a step in analyzing your requirements, because you're not leveraging the reusable parts of your code. Almost every column in your table hints at an interface/abstraction that can be made. I'll use a few examples from your columns in this answer.

Entry fee implies the need for an entry fee calculator. So what you do is you make a specific interface (IEntryFeeCalculator), and write your battle classes so that they can handle any IEntryFeeCalculator. For example:

public interface IEntryFeeCalculator { int GetEntryFeeForPlayer(Player p); } public class PlayerLevelEntryFeeCalculator : IEntryFeeCalculator { private readonly int _goldPerLevel; public PlayerLevelEntryFeeCalculator(int goldPerLevel) { _goldPerLevel = goldPerLevel; } public int GetEntryFeeForPlayer(Player p) { return p.Level * _goldPerLevel; } } 

I could come up with hundreds of different calculators. One that spews out a random number. One that calculates the price based on whether the player has bought the premium game license. One that calculates the price based on the day of the week. And so on...

But in all cases, the battle class can just expect to handle any entry fee calculator:

public class Battle { private readonly IEntryFeeCalculator _entryFeeCalculator; public Battle(IEntryFeeCalculator entryFeeCalculator) { _entryFeeCalculator = entryFeeCalculator; } public bool CanPlayerRegister(Player p) { var entryFee = _entryFeeCalculator.GetEntryFeeForPlayer(p); // Player can join if he has the coin return p.Money >= entryFee; } } 

I hope the general outset is clear here. We defined a reusable behavior, i.e. calculating the entry fee, we created an interface that all our varied calculators will implement so that they can be used interchangeably, and then we make sure that our battle class only uses that reusable interface.

For the other examples, I'm just going to show you an example of what such an interface would look like. The implementations are up to you.

Availability

public interface IBattleAvailabilityEvaluator { bool IsAvailable(Battle b); } 

Environment

public interface IBattleEnvironment { void RenderGraphics(); } 

Rewards

public interface IBattleRewardGenerator { IEnumerable<Reward> GetRewardsForWin(Battle b, Player winner); IEnumerable<Reward> GetRewardsForLoss(Battle b, Player loser); } 

The others are similarly possible, though much depends on the precise details of how these things are implemented. I made a reasonable guess at the needed input parameters, but this of course hinges on your specific requirements as well.

So now we've got a bunch of calculators/generators/... and their interfaces, and we have the Battle class which works with these interfaces. So how do we put it all together?

Well, we could use a factory pattern to generate our battles with the correct dependencies:

public class BattleFactory { public Battle GenerateStoryBattle(Player player) { return new Battle( new StoryNotCompleteAvailabilityEvaluator(), // IBattleAvailabilityEvaluator new StoryRewardGenerator(), // IBattleRewardGenerator, new StoryLevelEnvironment(player), // IBattleEnvironment new PlayerLevelEntryFeeCalculator(5), // IEntryFeeCalculator "Try gain better equipment" // Hint on loss ); } public Battle GenerateArenaBattle(Player player, Player opponent) { return new Battle( new PlayerAvailabilityEvaluator(opponent), // IBattleAvailabilityEvaluator new ArenaRewardGenerator(), // IBattleRewardGenerator, new ArenaLevelEnvironment(), // IBattleEnvironment new PlayerProgressEntryFeeCalculator(player), // IEntryFeeCalculator "Try go to encounter" // Hint on loss ); } } 

I skipped the other dependencies, but the principle remains the same. First, you develop all your needed components, and then the factory assembles your battles using the components.

This factory is, in essence, using your table to put it all together. But before it can do so, you need to develop all of the features in that table (using the columns as a guideline for abstractable behavior).

Also, notice that the hint is just being passed as a string. This is to show that not every dependency has to be a class of its own. Sometimes it might just be a value that you pass into the battle class, without it needing to be dynamically generated.