[Philosophy] Are items just mobs that don't move?

[applebappu]

Here's a philosophical question for you.

Let there be a roguelike game. Let this game have mobs, which are mobile objects; Examples include the player, goblins, slimes, etc. Let this game also have items, e.g. swords, food, armor, potions.

From the player's point of view, obviously these things are different. They can't necessarily pick up and eat or equip other mobs (though maybe that's a fun game too).

But from the point of view of the code, are these things different? Or rather, do they necessarily have to be?

Are items just mobs that don't call their Move method ever? Is picking up an item the same as despawning a mob? Or should these things be separated out into different classes?

We're working in Lua here, so our answers are going to vary pretty widely, I think. What's your reasoning for your particular answer? How would YOU do this, if the above roguelike were yours to make? I've left this pretty wide open because I'm not trying to solve any particular problem, just interested in how we all think. Feel free to take this idea and run with it outside the original scope of the question, too.

[zorg]

You could also think of it the other way around; are mobs just items that can move?

Then again, if the game was funny, would a piece of mold be both? since it could be an item, but it might be one that moves... why wouldn't it be a mob then? How about an immobile mob, like an evil tree or posessed statue or something?

If anything, i'd consider both of those to be entities, as opposed to the unmoving, unchanging, unpocketable world... whether tile-based or not.

[darkfrei]

How about an immobile mob, like an evil tree or posessed statue or something?

Spikes are mobs, that cannot move, but hit you.

[ReFreezed]

You can think of it like this... Every thing, or "entity", in your game is just a container with other things in it. On a high level, an enemy might be an entity with a position, an AI, and a model. An item might be an entity with some graphics, and something that says it can be picked up. On a low level, an enemy might be a table, where one field is the x position, and another field is an array of other tables, each representing an animated sprite. An item might be a table with an type field that says what kind of item it is (which e.g. the rendering system would use to determine what graphics to render for it), and a boolean field that says whether or not the entity can collide with the player and thus be picked up.

It is very common for games to a single system that contains most things in the game (including objects in the game world, but also more abstract things like logic that connects other entities). Usually there are some properties that are common; that all entities have (like a position in space, and a unique ID), but then there are properties which are only used by some types of entities. There are several ways to deal with this. Some complex game engines, like Unity, allows you to attach "components" to entities. Each component would contain logic or data for specific things, like a sprite, or AI. In a different system you could simply stores all properties in existence on all entities and then just have a field that specifies what type of thing the entity is supposed to be (and what fields are relevant) and code everywhere has to check that field to determine how the entity should be treated.

In my games I aim to have systems that are as "flat" as possible (i.e. no components or nested entities, and very little "inheritance" of logic) because it makes things simple. If I were to make a rogue-like I would make mobs and pickups part of the same entity system. They would both have common properties like a position, but also have properties that are unique to their type of entity. The inventory of the player would be stored on the player entity, and when the player collides with a pickup I would simply remove the pickup entity, probably spawn an effect entity, and increase some item counter on the player.

So to answer the question in the title... Sure, items can be mobs that don't move!

[darkfrei]

As idea: Items are move from player's character, but not faster than half of max player's speed.

[Gunroar:Cannon()]

Items can be mobs, or be items, depending on your game. A more dynamic game would have items inherit from mobs so that in a nutshell they can do everything mobs can do, like becoming animated, etc. But most just make items seperate from mobs, since they have different behaviours like corrode instead of illness, break instead of die and repair instead of heal .
Mostly, yeah, that entity thing. All just inherited from entity with basic position and drawable sprite. Then split up and do their own thing

[zorg]

How about an immobile mob, like an evil tree or posessed statue or something?

Spikes are mobs, that cannot move, but hit you.

Depending on the game, they'd not be mobs, but rather tiles that can inflict damage... i.e. not really entities.

Items can be mobs, or be items, depending on your game. A more dynamic game would have items inherit from mobs so that in a nutshell they can do everything mobs can do, like becoming animated, etc. But most just make items seperate from mobs, since they have different behaviours like corrode instead of illness, break instead of die and repair instead of heal .
Mostly, yeah, that entity thing. All just inherited from entity with basic position and drawable sprite. Then split up and do their own thing

To me, this seems a bit more like animate vs. inanimate or organic vs. inorganic to be honest. robots would be mobs that could corrode, and star trek, as an example, had bio-neural gel packs that were items embedded into a starship... but could be infected and "be ill". same with healing vs. repairing.

[applebappu]

To me, this seems a bit more like animate vs. inanimate or organic vs. inorganic to be honest. robots would be mobs that could corrode, and star trek, as an example, had bio-neural gel packs that were items embedded into a starship... but could be infected and "be ill". same with healing vs. repairing.

Agreed! We can always set those distinctions at the UI / user level, whereas in the code, it can be more "flat".

[Gunroar:Cannon()]

To me, this seems a bit more like animate vs. inanimate or organic vs. inorganic to be honest. robots would be mobs that could corrode, and star trek, as an example, had bio-neural gel packs that were items embedded into a starship... but could be infected and "be ill". same with healing vs. repairing.

Nice view on it! Maybe robots could be items ... yeah, I know...I know.

[Jasoco]

This is how it works in old games like Wolfenstein and DOOM. "Sprites" in those games are just all the same "thing" class with different flags applied. A thing can be flagged as being able to move and attack, or it might have those flags turned off and just ends up being stationary.

Basically mobs are objects with AI attached to it.