New answers tagged

2

You should use option 1, which has 3 advantages: It's easier to instantiate a resource - instead of having to pass the type of the resource as a parameter, you would just do, for example, new Gold(50) If you need to give special behaviour to a resource, you can by changing it's class. It's easier to check if a resource is a certain type - resource ...


1

If your resources have no business logic of their own, or special case scenarios with how they interact with the environment, other resources (besides trade which you've covered) or the player then option two makes adding new ones very easy. If you need to consider situations like what would happen if you mix two resources for crafting, if the resources can ...


14

I would like to add there are two extra options: Interface: you can consider it if the resource class would be just a "storage" for 5 integers and each other entity would have different logic regarding resources (e.g. player spend/loot, city produces resource). In that case you might not want a class at all - you merely wanted to expose that some entity has ...


30

A rule of thumb is that you use different classes when objects require different code and instances of the same class when the objects only require different values. When the resources have different game mechanics which are unique to them, it might make sense to represent them with classes. For example, when you have Plutonium which has a half-life time ...


52

Go with the second approach, simply due to the fact that you can introduce new resource types or items at any time without having to rewrite or update code (data driven development). Edit: To elaborate a bit more on why this is in general good practice, even if you're 100% sure some value won't ever change. Let's take the console game example mentioned ...



Top 50 recent answers are included