#Inventory System questions (yay)

1 messages · Page 1 of 1 (latest)

prime ginkgo
#

I think I understand steps 1 through 3, but where do I store the concrete implementations for each behavior? Children of IInventoryItemBehavior?

strong barn
#

Those will be classes you create straight up

#

you wanna make 1 class per behavior

#

they should just be POCOs really

prime ginkgo
#

Which are children of IInventoryItemBehavior? or no

strong barn
#

nah IInventoryItemBehavior is an interface

#

You can think of interfaces as like job titles, whereas inheritance is like your parents

#

So in C# you can only have 1 parent, but you can have multiple job titles

#

And jobs involve contractual agreements you agree to fulfill

prime ginkgo
#

Yeah I get that, but I'm just using children to define the "contract holders" of the interface

strong barn
#

So if you say do

public class MyClass : IDisposable { ... }

The compiler will yell at you until you implement public void Dispose() on your class, because you agreed you would do that when you declared MyClass implements IDisposable

strong barn
#

or just Concrete vs Abstract is sorta right, though abstract class is also included in Abstract

#

but you basically would say "My class is an implementation of my interface" or "that interfaces' implementations"

prime ginkgo
#

So the actual like projectile spawning, or stat editing, or whatever is stored in implementations(?) of IInventoryItemBehavior

strong barn
#

but yeah, youd basically make like

FooInventoryItemBehavior : IInventoryItemBehavior { ... }
BarInventoryItemBehavior : IInventoryItemBehavior { ... }

And you would also have Foo and Bar in your Behavior enum

strong barn
#

Like youd have a ProjectileItemBehavior

prime ginkgo
#

literally amazing

strong barn
#

Id make this a bit more generic

#

Id even go as far as to say that InventoryItem is specifically one type of behavior

#

And I would call these things like Entity or Model or whatever

#

Cause then InventoryItemEntityBehavior would have stuff like how does it behave in the inventory. Can it be dropped or is it a quest item, how many slots it uses up, can it be stacked, etc etc

prime ginkgo
#

and if I finished this, and wanted to make a new item (big sword that spawns cats) i would create a new "ItemBehaviorSelector" as a SO? and flag the projectile spawning and stat editing, etc.

strong barn
#

nah youd just have 1 single ItemBehaviorSelector

#

think of that bad boi as the like big service hanging up in the clouds above everything and it handles orchestrating and wiring up what behavior gets invoked for each entity

prime ginkgo
#

Why make it a scriptable object then? also how would i make a new item lol

strong barn
#

Basically your ItemBehaviorSelector should have a list of every single behavior registered on it

strong barn
#

You'd just make a copy of the prefab and then modify its fields

#

Select the matching behaviors in the flag enum (which will expand the matching fields for each selected behavior), then configure each of those "sections"

#

you'll also then prolly make a few templates with stuff preselected that you keep re-using

#

like prolly a MeleeWeapon template premade that already has, say, the MeleeWeaponBehavior and InventoryItemBehavior selected on it, and its fields partially filled out and ready to be tweaked

#

Then you just clone that MeleeWeaponTemplate prefab, and rename that clone to CatSword and fix it up to be specific

prime ginkgo
#

Alright cool I've done something similar before, but Why make ItemBehaviorSelector a scriptable object?

strong barn
#

TBH Im not 100% sure if that is what is needed

#

I dont use SOs, I know often they get used as a sort of global background service

#

personally I use Dependency Injection to construct my entire "game engine" background stack of services that run and do stuff, so I basically never touch SOs

prime ginkgo
#

Lol it's cool, but in this situation I don't think they're needed.