Right now I'm working on a RPG in Java and need to implement an item/inventory system. The only way I can think of is to create a class for each item I would have in the game and create an instance of each when the game initializes, then I could make a linkedList or something that you would use for the inventory.
The problem is, if I have say 100+ items this would be very inefficient. Does anyone else have any ideas that would help with either the way I could set up my items or the way I would do the inventory?
Thanks
4
Java RPG Item system
Started by stein102, May 23 2012 12:21 AM
15 replies to this topic
Ad:
#2 Members - Reputation: 151
Posted 23 May 2012 - 12:32 AM
For doing what ?, then I could make a linkedList or something that you would use for the inventory.
The problem is, if I have say 100+ items this would be very inefficient.
Choosing the right collection class is important, but that all depends on what you want to.
#8 Members - Reputation: 477
Posted 23 May 2012 - 09:31 AM
It also depends on how frequently your accessing your data, if you have a hundred items that are only iterated thru once in a while like when the character is looking thru inventory then you have nothing to worry about. Now if that array is being accessed constantly lets say every render call for whatever reason then you might want to look at an alternate approach but even then depending on the actions preformed on the array it might not be an issue.
Like people previously said in this thread it all depends on what you need and what your doing so we would need more details.
Like people previously said in this thread it all depends on what you need and what your doing so we would need more details.
#9 Members - Reputation: 191
Posted 23 May 2012 - 10:13 AM
The more details you give, the better.
-> How big is the inventory? If every Item takes maximum of 1 'spot' in your inventory, you could go for an 2 dimentional array.
You can then loop them and everywhere Item[x][y] != null, you display that item.
For the Item structure, I'd work with a system like this:
Have one base Item class with the basics that every Item has; If every item has the same, leave it this way.
If some Items are different (for instance, Health items, Weapon Items ...) inherit from the Item base class and use the factory design pattern. This allows you to 'load' your items from a database or XML. Don't create a class for every Item, as it makes your code to 'implementation-wise' and adding Items will be more difficult.
The following UML can make things clear: make the following. Then create some class that will spawn the items (factory pattern) and add them to the inventory.
Of course, the array idea only works with everything of size 1. Otherwise you could use some system that has a 'size' field in the Item class and prevent from inserting new items to zones which are taken
-> How big is the inventory? If every Item takes maximum of 1 'spot' in your inventory, you could go for an 2 dimentional array.
Item Inventory[HorizontalSizeOfInventory][VerticalSizeOfInventory];
You can then loop them and everywhere Item[x][y] != null, you display that item.
For the Item structure, I'd work with a system like this:
Have one base Item class with the basics that every Item has; If every item has the same, leave it this way.
If some Items are different (for instance, Health items, Weapon Items ...) inherit from the Item base class and use the factory design pattern. This allows you to 'load' your items from a database or XML. Don't create a class for every Item, as it makes your code to 'implementation-wise' and adding Items will be more difficult.
The following UML can make things clear: make the following. Then create some class that will spawn the items (factory pattern) and add them to the inventory.
Of course, the array idea only works with everything of size 1. Otherwise you could use some system that has a 'size' field in the Item class and prevent from inserting new items to zones which are taken
#10 Members - Reputation: 281
Posted 23 May 2012 - 03:42 PM
It also depends on how frequently your accessing your data, if you have a hundred items that are only iterated thru once in a while like when the character is looking thru inventory then you have nothing to worry about. Now if that array is being accessed constantly lets say every render call for whatever reason then you might want to look at an alternate approach but even then depending on the actions preformed on the array it might not be an issue.
Like people previously said in this thread it all depends on what you need and what your doing so we would need more details.
I am going to want to access them during each render call. The inventory is always on screen.
Also, as Miklas said I could use XML or a database for storing my items. I suppose I will need to do some reading in regards to that if I'm to go with that approach, I'm not familiar with either of them, but willing to learn. What would be the advantage of one over the other?
Thanks
#11 Members - Reputation: 477
Posted 23 May 2012 - 07:37 PM
It also depends on how frequently your accessing your data, if you have a hundred items that are only iterated thru once in a while like when the character is looking thru inventory then you have nothing to worry about. Now if that array is being accessed constantly lets say every render call for whatever reason then you might want to look at an alternate approach but even then depending on the actions preformed on the array it might not be an issue.
Like people previously said in this thread it all depends on what you need and what your doing so we would need more details.
I am going to want to access them during each render call. The inventory is always on screen.
Also, as Miklas said I could use XML or a database for storing my items. I suppose I will need to do some reading in regards to that if I'm to go with that approach, I'm not familiar with either of them, but willing to learn. What would be the advantage of one over the other?
Thanks
Well those are just methods of storage, like where the data will live and in what form which seems to be a completely different issue then the one u first stated. If the items are going to be always be displayed and constantly accessible and there will be 100 possible items, then there are no shortcut around, you might at times have to iterate through all 100, at which point a LinkedList is perfectly fine.
Dont worry to much either about it being efficient or not, optimizing your code should come after you already got something working. You might THINK your saving time or playing it smarter by trying to come up with efficient solutions before they become a problem, but thats exactly the issue you are trying to come up with solutions to problems that don't exist yet.
Once your game is completed you might not have any significant issues with speed, and if you do! I highly doubt a 100 item inventory is going to be the cause of it all. Long story short try not to worry to much about smaller things and try just focusing on the bigger picture, its the best thing you can do in the long run. I say just go with the LinkedList and have fun coding!
Edited by The_Neverending_Loop, 23 May 2012 - 07:38 PM.
#13 Members - Reputation: 477
Posted 23 May 2012 - 11:05 PM
Well if you refer to the diagram provided by Miklas....
This is the best way to do it. You should look into polymorphism that way you can make your code easier to use and follow. By creating a super class Called say Items, and creating other classes that implement or extend from Items to represent their special functions like "HealthItem" or "WeaponItem", then you can call a common method they both share say "use()" and it will use the appropriate function for that particular health item or weapon item.
As for the storage medium, its honestly up to you to decide whats best for you. But all it basically is meant to do is pass the arguments to one of your Item Constructor in order to recreate that object in your game, so whether you get your data from a SQL Database, or some XML file located on your hard drive, its all up to you.
One thing I would say tho is that if this is a game you install on your computer that you dont play with anyone else you can go with XML if you'd like, if not and there is some kind of networking involved use a Database.
This is the best way to do it. You should look into polymorphism that way you can make your code easier to use and follow. By creating a super class Called say Items, and creating other classes that implement or extend from Items to represent their special functions like "HealthItem" or "WeaponItem", then you can call a common method they both share say "use()" and it will use the appropriate function for that particular health item or weapon item.
As for the storage medium, its honestly up to you to decide whats best for you. But all it basically is meant to do is pass the arguments to one of your Item Constructor in order to recreate that object in your game, so whether you get your data from a SQL Database, or some XML file located on your hard drive, its all up to you.
One thing I would say tho is that if this is a game you install on your computer that you dont play with anyone else you can go with XML if you'd like, if not and there is some kind of networking involved use a Database.
#14 Members - Reputation: 191
Posted 24 May 2012 - 12:50 AM
You should find a way to store your data in a way that you can read it, without having to recompile. This means that you should have some files (XML, INI, TXT...) or database that contains the items.
Why?
Default CSS Gui
HolmGUI
So your Java RPG engine should be capable of parsing files like this. Of course, a 'basic'(hardcoded) system (like the_neverending_loop suggested) is fine, and then you can expand it to be able to 'parse' the GUI. The more you keep your engine separated from your game, the more you can reuse it in future projects.
Why?
- Because updating and adding Items is nothing to worry about then: you can then send updates by sending a new XML/INI/TXT.. file instead of having to send a whole new build to your clients. You could also serialize your classes. This means that you create your classes once, and them saves them to disk to be loaded later. (tutorial) The advantage of this is that your code is harder to manipulate (as people can 'cheat' by editing your XML/INI's) but you have to do more work when creating your serialized objects.
- You should always program to an interface and not to an implementation. What's the difference? With an interface (look at my UML schema) you can reuse your code. You can then just give new models & new 'item'-files to your clients and you have a whole new game - without touching your source code. You could even do this for your GUI! (For example the source engine does this (known from counter-strike:source, gmod, half-life2, team fortress, portal...). They have created a way to parse '.res' files (see attachement, ChatScheme.txt - this file is from a new GUI for Counter-Strike:Source). By editing nothing else then these files, they have created a whole new GUI)
Default CSS Gui
HolmGUI
So your Java RPG engine should be capable of parsing files like this. Of course, a 'basic'(hardcoded) system (like the_neverending_loop suggested) is fine, and then you can expand it to be able to 'parse' the GUI. The more you keep your engine separated from your game, the more you can reuse it in future projects.
Attached Files
-
ChatScheme.txt 15.29K
46 downloads
#15 Members - Reputation: 197
Posted 28 May 2012 - 03:10 PM
Regarding persistence, I'd start with simply storing them serialized to a file. That is a minimum amount of coding work and you won't have to change any code as your game evolves, you add new item types, change existing ones etc. Once your game starts maturing and if you have certain requirements on the file format (e.g. editable in a text editor) you can rewrite this part.
And just to throw another perspective into the discussion: If the items don't carry individual state, or very simple state, you may want to invert the object model to instead being compartment-centric: Your inventory holds 100 item compartments. Each compartment has a "held item type" and possibly some parameters (such as item count). If you can stack items, e.g. 100 bullets in a single compartment and the bullets don't have individual state, this is perhaps the better approach. (Then again, if all you'll ever have are 100 inventory slots in a single player game, processing and memory usage will probably not be headache either way!)
And just to throw another perspective into the discussion: If the items don't carry individual state, or very simple state, you may want to invert the object model to instead being compartment-centric: Your inventory holds 100 item compartments. Each compartment has a "held item type" and possibly some parameters (such as item count). If you can stack items, e.g. 100 bullets in a single compartment and the bullets don't have individual state, this is perhaps the better approach. (Then again, if all you'll ever have are 100 inventory slots in a single player game, processing and memory usage will probably not be headache either way!)
#16 Members - Reputation: 280
Posted 28 May 2012 - 04:09 PM
If I were you, I'd use a 2d array of Item referenes. Item would be a sealed/final class that in other words cannot be inherited. It would have fields like name, graphicsId, isStackable, stackedAmount, equipableOnSlots, listOfEnhancements and listOfActions (or just a single action).
You can also have a reference to a ItemBaseType which is all of that excluding listOfEnhancements and stackedAmount. You may also need some additional state such as durability, action cooldowns etc depending on your game.
listOfEnhancements is a list of stat changes, +20 mana, +4 strength etc. Whenever you change equipment/inventory, you create a per-character combined list of all active enhancements which you can then use for your calculations (instead of looping through each item multiple times each frame).
listOfActions is a list of Actions which is ways to use your item. In Diablo 2 for example, a staff could grant the user spells and if I remember correctly, it could sometimes even grant multiple additional spells. This might not apply to your game. If there's a single action (right-clicking a potion to drink it), you can use a single action-field in the Item class or the ItemBaseType class if you use that.
It's very easy to look at inheritance/polymorphism for stuff like this, but in my experience it often creates problems with serialization/network communication as well as code structure. What if an item has two actions? Or what if two different items have the same (or very similar) actions? For additional info and tips, google the strategy pattern.
You can also have a reference to a ItemBaseType which is all of that excluding listOfEnhancements and stackedAmount. You may also need some additional state such as durability, action cooldowns etc depending on your game.
listOfEnhancements is a list of stat changes, +20 mana, +4 strength etc. Whenever you change equipment/inventory, you create a per-character combined list of all active enhancements which you can then use for your calculations (instead of looping through each item multiple times each frame).
listOfActions is a list of Actions which is ways to use your item. In Diablo 2 for example, a staff could grant the user spells and if I remember correctly, it could sometimes even grant multiple additional spells. This might not apply to your game. If there's a single action (right-clicking a potion to drink it), you can use a single action-field in the Item class or the ItemBaseType class if you use that.
It's very easy to look at inheritance/polymorphism for stuff like this, but in my experience it often creates problems with serialization/network communication as well as code structure. What if an item has two actions? Or what if two different items have the same (or very similar) actions? For additional info and tips, google the strategy pattern.
