3
\$\begingroup\$

I'm designing a game where there is a relatively small set of items. A single player holds an inventory of item slots. Each item slot contains a single item. The inventory allows you to use the item directly, move item around the slots (to organize), equip the item (weapon), and lastly, to combine compatible items together.

I've come up with the diagram below: UML diagram

Where I'm having trouble is combining. To simplify the game, the game will only do Health+Health, Ammo+Ammo, Weapon+Ammo, Prop+Prop.

Where should I check if the above is permitted? Should Inventory check, or should I delegate the checking to the items themselves?

If I have a green health item and a red health item, it would double the strength of the green potion (increases HP) due to the red health item. But what if the player tries to do: G+G+G+G+G or G+R+R?

I can see that with this design, I run into the problem of having a health item as an (subtype).

For Props, they're simply items used in the game, like keys, cranks, etc. Sometimes two props can be combined as one.

All combinations are designed. As in, the player wouldn't come up with a unique item combination.

Edit 1: The example, with health items, G+G+G+G+G implies that there's a limit as to how many green health items can be combined together. For example, the green health item has a HealthItem.health_sum=.40 (40% of your HP). After the third combination, it becomes meaningless.

\$\endgroup\$
  • \$\begingroup\$ May I ask which tool you are using to create UML diagrams? Looks much better than what I am using. \$\endgroup\$ – LukeG Sep 29 '16 at 21:37
  • \$\begingroup\$ @LukeG I used gliffy. \$\endgroup\$ – mrkotfw Sep 30 '16 at 1:32
3
\$\begingroup\$

When you handle all item combinations in the Inventory class, that class will potentially grow to an enormous size because it needs to implement the combination logic to handle every single item combination.

You could have items handle combinations themselves, but then you have the issue that you need to ensure that itemA.combineWith(itemB) has the same effect as itemB.combineWith(itemA).

A third possibility is to introduce another class ItemRecipe with the attributes ingredientA, ingredientB and result. When the player wants to combine two items, you look at your list of recipes and return the one which matches. When more than one matches you could prompt the player to choose which combination to perform. When your game concept consider ambiguous combinations impossible, you should throw an error when an ambiguity is detected. To avoid the ordering problem, ItemRecipe could have functions bool matches(item, item) and Item combine(item, item) which accept the ingredient in any order.

Those methods should be the only ones which are part of the public interface. That would allow you to create a subclass of ItemRecipe which solves your health item combination problem by not having the above attributes. It instead implements match to return true for any two health items which still allow combining and then implements a combine method which implements your health item combination mechanics.

\$\endgroup\$
1
\$\begingroup\$

Where should I check if the above is permitted? Should Inventory check, or should I delegate the checking to the items themselves?

Assuming that all items within an ItemType can always be combined with any other item of the same type, it would seem reasonable for this check to occur in ItemInventory, as it's really straightforward.

However, if that's not the case, for example if there's a limit on how many items of a particular subtype can be combined into the same item (e.g. you can't combine more than 2 red potions together), then you would probably want to query each of the items about to be combined whether they can be combined with the other. I.e. ItemInventory::CombineItems could call both items' CanCombineWith method.

(...) But what if the player tries to do: G+G+G+G+G or G+R+R?

Based on your description it's not quite clear what the problem here is, perhaps you could clarify.

The way I see it is, you would have a number of predefined 'templates' used to initialise 'base' items (e.g. a red potion), each of them would come with a list of item subtypes it can be combined with. As you combine the items, that list could be modified (e.g. red potion could be removed from the list once one item of that subtype had already been combined).

\$\endgroup\$
  • \$\begingroup\$ I guess that makes sense. If I can outline what item combinations create what, then it's a matter of checking compatibility. \$\endgroup\$ – mrkotfw Sep 29 '16 at 20:22

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.