[quote name='The_Neverending_Loop' timestamp='1337787072' post='4942591']
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
[/quote]

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!

Well I want to figure out how to store the data too. Should I just make a class for each item then? Idk...

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.

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?

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

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.