• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
SubZeroGaming

RuneScape's Inventory and Item System.

6 posts in this topic

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!

0

Share this post


Link to post
Share on other sites

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

Edited by dsm1891
0

Share this post


Link to post
Share on other sites

"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.

1

Share this post


Link to post
Share on other sites

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.

Edited by warnexus
2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

Edited by Juliean
0

Share this post


Link to post
Share on other sites

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

Appreciate it.

0

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  
Followers 0