Sign in to follow this  
Sean_Seanston

Items in Game World vs Items in Inventory

Recommended Posts

I've a short question regarding how to implement Items such as you might find in an RPG.

Given that an Item might be present in the game world, such as for the player to collect, but also at another point present in a character's inventory, how should such a discrepancy be dealt with?

While in the game world, an Item would have a position within the game world and be drawn at the appropriate position, as well as in some way containing the information necessary for the Item to cause its effects when later used from an inventory. However, in an inventory, it no longer has position within the game world. Though its graphic might still be used to display it inside the UI. Normally, however, the Item would likely be unseen and therefore would have no use for coordinates and would not be drawn anywhere, as well as not colliding with other objects etc.

Maybe the answer is obvious, but I can't figure out how to deal with that elegantly. Would the best solution be a simple flag (or equivalent check) such as "bool inInventory = true;" which would be checked before drawing an object and if false, skip drawing? Also skip collisions etc. and everything that involves it being in the game world.

Share this post


Link to post
Share on other sites
You could put your item in a container while it is in the world. The container would hold its its location and (maybe) its drawing instructions. When an item is picked up, put the item in the player's inventory and delete the container.

Share this post


Link to post
Share on other sites
Yeah, I was thinking of something kinda similar myself.

Do you mean something like, having 2 objects, say Item and ItemDrop.
Then a player might have a list of Items which describe functionality and an ItemDrop would contain an Item but also have position etc.?

That was one of my first ideas... but then I thought it seemed a bit cumbersome and that maybe there was a simpler way. Isn't bad I suppose, just seems odd to have to create 2 different objects for what is essential, 1 conceptual object. But maybe that's one of the easiest ways in practice.

Anyone else have experience with something like this?

Share this post


Link to post
Share on other sites
Yes, that is one way you could do it. It is two objects, but to some extent it is also two ideas. One is an item with stats and requirements that can influence the player. The second is an object in the game world that has a physical size and can be interacted with. This is why component based game objects are popular. The relationship between various behaviors is more complex than an object hierarchy can represent, so the behaviors are made into components and game entities grab whichever components they need.

Share this post


Link to post
Share on other sites
[font="arial, verdana, tahoma, sans-serif"][size="2"]I would have completely separate logic for these. For example, a WorldItem and an InventoryItem then some other class InventoryManager that gets notified when the player picks up the WorldItem and adds the corresponding InventoryItem to some internal representation of the inventory. You would also need an XML file or something to map each WorldItem to its corresponding InventoryItem.

As far as drawing goes, I would have an InventoryItemRenderer that knows how to draw InventoryItem objects to the inventory screen and a WorldItemRenderer that knows how to draw WorldItems in the world. Since the drawing logic is going to be very different between the two, it makes sense to have different renderer classes as well.[/size][/font]

Share this post


Link to post
Share on other sites
I disagree with the previous posts here. An item is an item whether it is in the game world or in your pocket. Consider real world example : there is a sword on the ground and you pick it up. What has changed? The sword is now in your hand and you say that you possess it. The sword is still in the same world and you are merely manipulating it's position.

So possessing an item in game terms is that "the item is travelling with you and it belongs to you in your opinion".

However, to keep things simple, I'd say that you just remove the object being picked up from drawn/physics scene and add it to the list of things carried by the character. I assume that you are using some sort of entity system to present every object in the game world. So practically, with this kind of system you are able to pick up any object in the world.

For drawing the inventory, you'll just need to add a method for the item for drawing a 2d icon presentation.

Good luck!

Share this post


Link to post
Share on other sites
The details always depend on the overall architecture. Using a component based entity system, I'm dealing the following way with such a problem:

Such an item needs at least 2 components to participate on a visual rendering of the scene: A kind of drawable (e.g. a mesh) and a WorldPlacement. The latter component defines the position and orientation of the item in the world, while the former one defines its look. If the WorldPlacement isn't there or it is inactive, then the item's entity is in fact not in the world, cannot and hence will not be rendered. E.g. scripting can be used to make the WorldPlacement inactive if the engine doesn't support component removal.

If the avatar picks up the item and holds it in the hand, sticks it to the belt, or carries it in another way visible with her/him, then a active WorldPlacement will still be needed. However, the placement now gets controlled by a sub-type of Controller named "Grabbing". Without going into the details here, this means a special kind of parenting the placement.

If the avatar picks up the item and stuffs it into an inventory container, then the item's entity "leaves the world", so its WorldPlacement gets at least deactivated. If, for example, the inventory screen is opened and the contained items are shown spread out on the view, then a OnviewPlacement (kind of placement that bypasses the VIEW transformation) will be used by activation.

If the inventory container is itself a world entity and can be opened and looked into, then still the WorldPlacement is in use. The opening / closing of the container can be used to drive some optimization, e.g. enabling / disabling the placements of contained items just in time.

I further allow to deal with more than a single scene. This allows to remove the item's entity totally from the main scene and inserting it into a scene used to just render a inventory containers content, for example. This can be used as a 2D overlay or texture to the main scene when needed.

Of course, the fact that an item counts to the inventory need to be handled besides graphical rendering.

Share this post


Link to post
Share on other sites
[quote name='kauna' timestamp='1297946795' post='4775378']
I disagree with the previous posts here. An item is an item whether it is in the game world or in your pocket. Consider real world example : there is a sword on the ground and you pick it up. What has changed? The sword is now in your hand and you say that you possess it. The sword is still in the same world and you are merely manipulating it's position.

So possessing an item in game terms is that "the item is travelling with you and it belongs to you in your opinion".

However, to keep things simple, I'd say that you just remove the object being picked up from drawn/physics scene and add it to the list of things carried by the character. I assume that you are using some sort of entity system to present every object in the game world. So practically, with this kind of system you are able to pick up any object in the world. [/quote]

Well, I suppose the difference between the real world and a game is that in a game the sword would generally cease to exist after being collected until called upon later. It would just disappear into a magically large backpack or some such.

I think I see what you mean about the lists though... it could go from one list that's drawn to another that isn't. Yeah, that sounds good. I should've thought about that before... that might work better. I'll see what happens. Thanks.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this