RuneScape's Inventory and Item System.

Hello,

I am creating a game framework similar to RuneScape.

Can someone help me out with the logic behind an inventory and item system like RuneScape? I'm a little lost as to where to start :/

From my understanding here is how I want it to work.


I can right click an item in my inventory, and it will have the option to drop, use, or equip. depending on the item. It also may say eat or consume.

ex:

sword = equip.

lobster = consume
bronze bar = use

For the item manager...crap...I litterally have lost my train of thought...

basically, I want my item system and inventory system to work 100% like runescape. Anyone able to point me in the right direction?

Thank you so much!

Hello,

I've thought about this before, and have done something simular in the past.

For the inventory system (items shown as items) each one is essentially an image button, with each image representing an item (stored in an array) and then displayed 4 by 7(is it) on x,y part of the screen. on left click (& !mousemoved) the first option is automatically selected (more on that later). but if the mouse moved the item will be re-ordered in the inventory Array, list, vector, what have you.

The 'image button' differs from standard buttons because you can right click and a menu pops down, thinking back on how I did it (it was a while ago so might be a tad off). I had an array of all 'commands' and then depending on the item type (I dont know c#) but you could use something like java's/c++ instanceof opperator to check the type/subtype, and only display the ones needed. And from there the selected option goes into some type of command parser.

I didnt know how indepth you wanted his, but let me know if you want more / i tottally missed the point of this thread

"basically, I want my item system and inventory system to work 100% like runescape."

Why not aspire to be better? If people want to play Runescape, they know where it is...

"you could use something like java's/c++ instanceof opperator"

This is exactly why virtual dispatching was invented. So you don't have to look at the types of the objects. You create an interface for doing this and your object types implement it and then you simply call through the interface.

Rule of OO design; if you're using instanceof or dynamic casts or similar monkey business, you've gone wrong in your OO design somewhere. You must find the error and either describe it accurately in the documentation or fix the problem.

Your abstract object needs to specify a way to populate a list of possible command names and actions; probably takes a pointer/ref to the object instance instance (the language object which represents the game object which is of this game type). The names are displayed. When the user picks one, the action is executed. It's probably going to be some simple interface like Java's Runnable or a C++ function object taking no parameters. (The object to apply the work to is encoded i the function object by the menu item factory)

The actual game-object-type classes implement this interface, providing suitably configured command objects as the second part of their pair.

This way, later, when you tire of implementing objects in a hard programming language you can start doing them in softer ones.. like say Lua, and writing the list populator so it fills in command names and Lua function objects and the just dynamically load lumps of Lua instead of having a build/debug cycle.

This also allows objects to change their command structures depending on the world around them. If you're in a suitably magical place, 'wield' becomes an option for the wand. If you're near a river 'deploy' becomes an option for the canoe. That sort of thing.

And since just copying another game is dull, we can think of improvements...

Provide importance ordering on the commands, and now you can float different commands to the top of the display lists (so now the appearance of 'wield' is more obvious to a player).

If you allow things to return non-executable commands, the menu for 'hat' can contain a non-selectable option saying 'already wearing a hat'. And if you remove that hat, this object will change that to a 'wear' command which does work. Now the player knows why an option might become available.

The idea and logic behind managing the items in the Inventory System is basically a bunch of game items that can be added to a list. You can have a list that grows dynamically(in Java they are called ArrayList) as you add more items to it.

If you think about how Runescape inventory it has a 6 rows and 4 columns which in programming is a 2 dimensional array: inventory [6][4].

The idea of representing the Inventory System in-game is a basic GUI(in Java it would be a menu JPanel that holds an inventory JPanel which holds a bunch of JLabels that displays an Image object(partyhat image, potion image etc) that has mouselisteners(to listen for events from the user when the user clicks the JLabel that represents a particular item it pops up a menu(which itself is a JPanel that holds buttons(use, drop) that has mouselisteners.) The contentpane will be the object holding the JPanel.

So you can think of the Inventory System as an Inventory class that is made up of many JPanels on top of each other.

In terms of simulating a right click, a google search should have some results.

You want to make your inventory better though. Why not be able to sort the items by rarity levels like in Monster Hunter instead of making the user sort it themselves? Or sort by alphabet because most people who see the item recognize the first name of the item so when it is sorted by alphabet they know where to look.

You also want to think about the menu JPanel(which is the menu being able to redraw itself or repaint to display different things or JPanels) depending at the moment when you are clicking the inventory icon or the stats icon or the prayer icon. The state of the menu panel should change accordingly to the buttons that is pressed.

Hopefully this serves as a good base for you to start with or think about how to go about it.

I would draw the design of the inventory on paper and break down which JPanels should go where.

You should also look into setting different layouts for the JPanel that changes the orientation of how components get display on the JPanel. BorderLayout, GridLayout, FlowLayout to name a few.

Use an interface that all your objects inherit from. Then in the new version define specific behaviors. State or Strategy pattern if you want to use patterns.

Use an interface that all your objects inherit from. Then in the new version define specific behaviors. State or Strategy pattern if you want to use patterns.

Don't. At least for the "inherit all objects from interface" - part. That will lead to many bad things - dread diamond, duplicate code, ungodly awfully deep inheritance trees, pick your favorite. Instead, use an entity/component based approach - a generic item-entity, where you attach different components to. For example, a pickaxe might have an melee-weapon and a woodcutting component. Use systems to work on these generic components - if an item has a woodcutting-component, it can cut a tree, no matter if it is a fire-breathing magic teleport wand with a axe-head on top of it. Good luck implementing this with inheritance.

This will also allow you to "soft-code" your objects - the code knows what components there are, but it doesn't matter where the items come from - store them in a database, in an xml-file, a json-file, etc... and just store the type of component plus its parameters for the item, then use this to put together your item.

Thank you all so much for the replies. This certainly has helped me with the base!

Appreciate it.