Is it appropriate to design heroes as items in game development?

Can characters be objects?

Yes.

First of all, a player (the person playing) is not a character. But the player has characters, and items, and so on. And yes, you can think of them existing in inventories.

A player might have a currently "equipped" character. There are games where the user controls a party of characters. There are also games that you switch characters. These are not new concepts.

And, of course characters might have their own inventories. Or they might share a single inventory. And yes, items could have inventories too (i.e. containers such as bags or chests).

None of this prevents characters from being items.

---

I would like to challenge that items exist in the game world. Instead I would say that there are wrappers for items (and also for characters) in the game world. But the question is not about that, so let us not dwell on it.

---

Classes

For your classes, it is probably better to think about the things that the player has. For example: vehicles, buildings, decorations, characters, pets, weapons, tools, consumables, keys, crafting materials, etc... And cosmetics for those things that apply.

Using the type system of your programming language each of these could be a different class, and they might or might not share interfaces.

Now, thinking about inventory and equipment, what I see is they are mostly different data structures (ordered/unordered, with/without stacking, with/without named slots, fixed size or not). And you could have these data structures containing any kind of objects (regardless if they are "items" or not).

Thus, even if characters are in an "inventory"-ish structure, it does not imply they must be items.

If there is any benefit for characters being items, it is probably something specific of your game.

---

Constraints

When using an item it makes sense to specify by who and on what or whom, in particular if there are multiple characters (be them from a party controlled by the player, bots, or multiplayer).

And you might want to constraint on what or whom an item (or a spell or attack for that matter) could be used on.

Similarly you want to be able to constraint what you can put inside of those or any other inventories (e.g. again, containers such as bags or chests).

Furthermore, you want to constraint what bots can target, etc.

The first filter is the type system of your programing language, but you can have more checks (e.g. inventories might have weight and size limits).

Plus, I explicitly say "the type system of your programming language", because there is something else might look like a type system that you can use: flags and tags.

That is you would define some checks in terms of flags and tags that an object must match to be placed inside a container, or to be the target of an effect (e.g. the target must not be an enemy).

Two reasons to not hard-code these come to mind:

• To make it easier for designer to specify them.
• To allow changing them in runtime.

Thus, if we say that a healing spell can be used on characters or pets, but not vehicles or buildings, although it sounds like we are talking about the type system of your programming language, it does not have to be.

Thus, issues of the type "can you put a character in a backpack?" could be resolved at this level instead.

Of course the actual constraints will vary from game to game.

---

Can items be characters?

You seem to be doing something different from what you ask. You ask if it is it appropriate to design heroes as items, but the in code looks like you are making items as heroes (Item implements IItem, IHero).

That does not seem right, but there might be a game idea hiding in there.

Still from the movie Everything Everywhere All at Once.

I don't foresee any benefits to implementing characters as items.

If you had a proliferation of dozens of specialized "user inventory ownable" entity types like items and characters, lumping them all under a single type might be a significant savings. But if characters are the only special case, you're probably not gaining much by combining them when most code will need specialized paths for each of them anyway.

The menus where you select characters and the menus where you select items are different menus — you're unlikely to ever have a situation where you need to store/iterate/manipulate a mixed collection of both characters and items, where being able to treat both as items would be a convenience. The same goes for the operations you'd perform on the two — you'll never "consume" or "wear" a character like you would a potion or an armour piece, and you'd never "embody" an item like you would a character. It might make sense to have a stack of multiple copies of an identical item in your inventory, where that may not make sense for characters (depending on the particulars of your gacha system).

Similarly, these types likely need different data stored. Every character might have a set of core stats like strength/defense that don't apply to all items, while an item might have a purchase price that doesn't apply to characters. If your data type for one of them either is or descends from the other, it gets saddled with these extra unused fields, redundantly wasting memory and reducing cache locality for batch operations.

Any low level system that you might want to use for both — like a menu widget for displaying a list or grid of icons to select — can and probably should be written generically so that it can work for collections of any entity, rather than only those that descend from Item or implement IItem.

Keeping these separate can even save you from bugs. If all characters are items distinguished only by an integer type marker, your compiler won't stop you from using an invalid integer there (and accidentally interpreting a character as a potion that can be consumed or currency to be spent, etc). Instead, if Item has an ItemType enum with values like CONSUMABLE, CURRENCY, WEAPON... AND Character has a CharacterType enum with values like SUPPORT, TANK etc, then you get compile-time support protecting against this kind of error.

More generally, I recommend minimizing "is-a" relationships in game code wherever "has-a" can do the same job. This is the principle of composition over inheritance, and it helps guide toward more flexible, modular code that's simpler to read and modify. A potion can be an entity that "has-a" consumption effect component and an carrying weight component etc, while a character can be an entity that "has-a" base stats component and a melee attack component, for example. (This leaves open the possibility of creating a character you can drink/spend down the line, if that's a combination you decide you want to create deliberately, rather than stumbling into as a data bug)