Forum rules - please read before posting.

RPG Inventory - Items with random properties

edited August 28 in Technical Q&A

Hi

I would like to
1. Create inventory items at runtime
2. Have random properties applied to them.

For example:

  • A base "Sword" item exists in the game. It has properties (Damage, Cost, etc).
  • When a sword is "dropped" at runtime, there is a %'age chance to apply a prefix and suffix.
  • The prefix and suffix modify/add properties to the item, for example: Damagex2, BaseCost 100, AttributeX + 2.
  • Pretty typical Diablo/RPG stuff.
  • Players can different "Sword" variations in their inventory.
  • There are many different combinations; creating every combination as a unique item at compile time isn't feasible.
  • This same concept applies to all armor pieces and accessories. IE its very random.

While I can certainly code this all on my own, I would like to buy into as much of AC's systems (especially inventory) as possible (ie be able to use containers, add/check inventory actions, etc)

Before I go off and write this, I was hoping you might provide some insight to follow as many AC best practices as possible.
I realize this is a specialized system and will require custom code :)

Main challenges I see:

  1. InvItem's (specifically their id/UID) must be created at compile time.
  2. LinkedPrefab is the same for all instances of an InvItem
  3. InvInstance class is associated with a single InvItem.

Notes:

  • I realize AC is geared towards adventure games and this is a very RPG feature. I know it might not be elegant.
  • While Id prefer not to, I'm fine with modifying AC code if I have to as this is an important feature.
  • Unity 6.1, AC 1.84.2

Comments

  • edited August 28

    Followup.

    I'm not seeing any obvious way to do this after looking through the code.

    So heres a bit of a brute force idea (ignore this if you have a better one)

    1. Make a category/bin for these special items - say "RandomItemInventory". (ie the random weapons, armor and accessories portion of the players inventory).
    2. Add Inventory Properties like DamageModifier, CostModifer that are limited to the RandomItemInventory category. Add one special "IsUsed" boolean defaulting to false.
    3. Create N inventory items belonging to that category where N is the maximum "inventory" for the player. Categories are set to default values. IsUsed is false. Carry on start is true. Carry multiple is false. Graphic is the empty inv slot graphic.

    This is the players default "empty" inventory -ie the player has 50 inventory "slots" (InvItem0..49).

    At runtime when a item is "dropped", a custom action "DropItem" action will

    1. Iterate over the player RandomItemInventory and find the first InvItem with the IsUsed property of false (next open slot)
    2. Roll the unique suffixes and prefixes for the item
    3. Assign those random rolls to the corresponding InvItems slot's categories. Ie we roll DamageModifier + 10, BaseCost x2, Strength +1.
    4. Set IsUsed to True.
    5. Initialize the other AC fields as well (main graphic, use interaction, etc) likely pulled from a template for the item type (armor, weapon, etc).

    Finally, if a quest needs to give out a specific item every time (Sword of Fire Damage + 2) those items will be crafted "by hand" as their own items and mostly use existing AC actions. However the properties will still need to be manually copied with a custom action into the next available "slot" when its added, much like above.

    Dropping an item resets the slots items properties and sets IsUsed to false.

    Equipping an item from _Inventory _to the Paper Doll (which will have its own containers for chest, helmet, left hand, right hand...) will be similar to above.

    The above is a quick writeup and likely not complete.

    Does it sound at least reasonable? Im sure there will be issues, only worried about showstoppers.

    Note: I dont have to worry about combine/recipes - not needed in my game.

    Important: The above assumes changes to an items category properties at runtime will be serialized (ie applied back to the inventory managers version), or I can reasonably write code to do that.

    TL;DR: Im not creating items at runtime. I have N premade items and I manipulate their properties to make it appear like items are made at runtime.

  • edited August 28

    Well, InvInstance.invVars is not serialized (that makes sense now that I think about it). And I cant change the InvItem properties as that's going to permanently change the actual asset.

    So I quickly wrote my own remember script to serialize/deserialize the IsUsed/Other Properties for all the items with IsUsed == true in RandomItemInventory category of the players inventory - and saves/loads in my simple test.

    But I think I want to hold off to see what you suggest :)

    Sorry for the rambling posts.

  • Inventory properties are saved/loaded at runtime - just not directly with InvInstance.invVars. The full data set is extracted as part of its GetSaveData function.

    Your breakdown is a bit complicated for me to process, but I'd suggest starting small and building up from there. Items do need a unique ID that has been defined in the Inventory Manager in Edit mode, but beyond that different instances of an item can be considered unique. You could have all of your "Sword" variants reference an original Sword item, just with different properties. It's also possible to override an Item's texture with InvInstance.Tex.

    For interactions: rather than using ActionList you're probably better off hooking into the OnInventorySelect_Alt / OnInventoryInteract_Alt events, which pass the unique InvInstance class as a parameter.

  • Thanks for the response.

    Not sure how I missed that InvInstance properties are serialized. That's nice.

    You could have all of your "Sword" variants reference an original Sword item, just with different properties

    Could you elaborate on this?

    AFAICT only one InvInstance for any given InvItem can exist in the players runtimeInventory.PlayerInvCollection.

    • If InvItem.CanCarryMultiple is true, one InvInstance exists and subsequent adds decrease the capacity.
    • If InvItem.CanCarryMultiple is false, one InvInstance exists and subsequent adds fail (InvCollection::Add() returns false.

    Is there a way to have multiple InvVariations of the same InvItem (id)?

    (I can code all this, but if AC supports a native way I'd much prefer that).

  • edited August 29

    Yes, should be. You'd need Can carry multiple? to be true, but if the Slot capacity property (maxCount) is 1, then you should be able to have multiple, unique, instances of the same item within the InvCollection, each with their own set of properties.

  • Well, thats almost exactly what I need - perfect.

    I never would have started this thread if I had realized that (and in hindsight it makes complete sense). Thanks again.

  • Based on the above - The player inventory holds various InvInstance's of a InvItem - I'm having some challenges.

    1. I dont know how to pass the specific InvInstance to action lists as a parameter. The instance only holds a reference to the InvItem. The ActionList InventoryItem Parameters expects and ItemID. So any properties I then access in action list access the InvItem, not the InvInstance.
    2. If I then pass that InventoryItem parameter to Inventory -> Remove, all instances that match that InvItem.itemID are deleted.
    3. InvInstance has no explicit base class, so its an Object. Therefore I cant pass it as a GameObject or UnityObject paraemter.
    4. There is some support for runtimeInventory.SelectedInstance in Inventory -> Remove - but in my specific case I'm not selecting the item as that would "use" it (which equips or attacks).

    I dont see any obvious way to work with InvInstances in action lists.

    Ive gotten around this with my own custom actions so this isnt a big deal, but checking if there is something obvious im missing here: Is there a way to pass a specific InvInstance to an action list as a parameter?

    Thanks!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.