3

I've been programming for many years and this is sort of a strange need and I've never seen anything like this but I have a game where there are abilities that you can do. There is an ability class that stores data like Name, DamageType, DamageValue, Cooldown, CurrentCooldown. It's a very generic class where the instances I make really define the ability.

The thing is stuff like Name, DamageType, DamageValue, & Cooldown are values that can be defined once for the ability itself and never changes after that instance is created. However, CurrentCooldown would be owner specific. If 2 actors use this ability then each would need their own instance of CurrentCooldown but not their own instance of the other fields. Yes, I COULD just make 2 instances of this Ability but there is no real need for that as those other fields won't change.

Ideally I would make a list of abilities and just make each ability 1 time, and then tell each actor which ability they have. All the details for that ability is there and will be the same and shared, but the CurrentCooldown needs to be instanced per actor.

It would be nice to be able to make some fields "owner" specific. I guess a solution would be to make a dictionary where the name of the ability the actor has is the key and the value is the cooldown for that. I'm wondering if there are other ideas around this that people have and I'm not able to think about?

Improve this question
0

2 Answers 2

Reset to default
4

This sounds very similar to a flyweight pattern.

What you do is create ability objects that hold the data defining what that ability is and store them in an object pool for easy reuse.

The owner does not directly contain an ability, it creates an object that encapsulates the ability but with owner-specific state such as the current cooldown or any other overrides (maybe the owner has a damage boost?).

Advantages:

  • You can define an ability once per application run, not once per owner object. Less complexity in the initialization logic.

  • Ability state is guaranteed to be consistent between owners because they are using the same Ability objects.

  • Slight memory savings because data is not duplicated. Probably nothing to write home about, compared to 20 years ago when the flyweight pattern was documented and memory was limited and expensive.

Improve this answer
1
  • This sounds exactly like what I'm talking about. I've never heard of this pattern before. Thanks for the link. Will check it out. Commented May 14, 2015 at 19:41
0

Don't get trapped by premature optimization. You have to weigh any gains against the increased cost of development and maintenance. The later of the two is the killer.

Modern computers have an incredible amount of memory. How large is the instantiated object you are looking to deduplicate. 1KB? less? Over-engineering a system to save bytes of memory often means overly complex systems which are harder to maintain. It usually isn't a linear tradeoff. Even if you are God's gift to optimization as the project grows and the dev team with it there will be less experienced developers. What is the overhead of that optimization on their productivity and accuracy.

http://blog.codinghorror.com/hardware-is-cheap-programmers-are-expensive/

The reason why this often leads to an anti-pattern is because likely your design requirements will change over time. Elements which are static now may become not so static in the future. The size of the duplicated data and the number of instances will factor into your decision process but lets say it is 1KB and 1,000 instances. At most that saves you 1MB. It sounds great until you consider that is worth about $0.02. Ok lets say 10x that for both the size and number of instances .. still only $2.00 How much time both in development and in future maintenance did you spend over the lifetime of the project to save $2.00? My guess is >$2.00.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.