Thoughts about Item-typing
In most games, item typing is very simple: x is x, x is not y. Even in games with crafting like WoW, the probability that item-typing needs to have any kind of subtlety to it is low.
When item typing is done, there are usually a couple of ways to achieve it. If you are doing OO programming, you can simply use the Class of the Object as a shorthand for type. This is fine as long as each item is a distinct class; it may be that resource items (such as the items used for Revelations in Rogue Galaxy) do naught else but be used in some formula and it would be a waste to individually class them.
The second method is to fix a set itemID to the item as originally instanced. In this system, all items with their own unique class may be ID'd statically or (in the case of java) finally. In other languages this would simply be a const or be hard-coded into the constructor. The generics above then would also need to know their itemID, which is fine if you are creating them in a hard-coded fashion. The only issue that arises is that now you have a bunch of hard-coded itemID's in potentially multiple places.
One solution to that debacle is to take one of the central objects in the game, say the World, and attach a list of static constants (or final's) to it which are the ID's of all defined items. Thus whenever you are creating an item, you will always reference this list. If it changes, it will require a re-compile (no problem here) and the constants referenced will also change.
A third way is to take the second method and instead of having a static list of item ID's (or, rather, instead of only having a static list of item ID's) you have a static list of items. To create a new item you clone an item from that list. This allows you to also simply statically reference implicitly static resource objects (such as the card-deck OO model) while allowing you to clone items that will need to individually have properties.
In this case the item ID's are assigned on-list-create, likely a static event itself. This is great! The only problem is now managing this list, which overall is not too huge a deal.
There are still two unresolved issues with this method, however. They are twofold. The first I will address, the second I will leave as an exercise to the reader.
The first is a common problem, and it is versioning. Any game which plans only to be played as a complete game and not modified can ignore this issue (which is a valid way to do it.) But for those of us whose engine will be used by modders and who will have a fairly large beta crowd with save files they may wish to re-use, how do we get around item ID incompatibility?
The common solution here is to only add item ID's going forward, leaving old items as legacies that may be unused. Old saves are then a subset of the new version's saves. This works fine until modders create item ID's with conflicts.
Well, you might say, create a space of item ID's for modders! This leaves the modders to manage their itemID's, and presumably prevents conflicts. This is a decently libertarian solution, though ultimately it creates spaces like IPv4 which may or may not be sufficient later on. Furthermore, it simply pushes off the itemID versioning issue for both your own team (remember, you may not be working alone) and the teams of modders, whose problem is likely to be much nastier.
This punt is fine as far as it goes, but there is a better way.
In this 'better' way we have to do two things.
1. We must bind the itemID to the session (instance of the game world being played)
2. Item ID's are assigned automatically as the item list for that session is populated.
3. Sessions must store their list (save files get bigger) and validate that list on load.
4. Reflection should be used here to determine if the needed classes exist.
5. Finally, modders are given a method to add items, and a method to discover the itemID's assigned.
We may even use this method ourselves, but it depends on how we plan to use items. Where do we ACTUALLY use items, reader? By this I mean, where in the code do we create items from scratch?
In my view, this will be two places: One in random 'generation' functions that produce treasure-troves and place items within the world. The second is in widgets that transform items from one kind into another.
In these places, we need a quick way to discover an item verbally. The second case the bindings belong to Recipe objects of some kind, whether they be recipes for a Transmogrifier, a Furnace, or a crafting table. Either way, we will be verbally referencing an item to retrieve it... even if the references are static.
This works out fine, actually, version-wise. You may wish to provide a key that is static to each item kind, which if the item's class is not found can be searched for to try to migrate the item from the previous verison. These keys should be hashes and such that only the program itself tries to read, which are fixed to an item kind when you create it the first time (not in the game, but in your editor!)
As long as you create your items and recipes in the same place, if the string you use to retrieve the item changes you can discover the issue and resolve it quickly. Since the save file uses itemID's and those ID's are a reference to the list that it provides, saves will never mangle their items, though they may lose them if the items are removed from the next version. However, you will be able to discover this issue and resolve it, and if you set up your keys correctly, also you may be able to migrate the save successfully.
Keys may be multiple, allowing an individual item to be what two previous versions' items migrate to.
The item name (a simple string) can be used by the programmer when coming up with troves, recipes and other lists of items to be distributed in the world.
Saves and inventories deal in itemID's, allowing sane stacking and permitting recipes to refer to an item directly if necessary. Since these ID's are bound to the session, the save file can easily do verification checking on load.
You may provide variant methods as well, for retrieving items which are 'a form of a material' - a stick of oak, a brick of granite, etc. Because we use the population method, we can generate a list of possible rock chunks, etc, based on our loaded materials list, which the modder may add to.
The second problem here is the problem of how to properly create disorganized inventories; stacks that obey only some rules of kind-based-stacking,
If it seems easy, consider that most of your list types will ignore objects of the same instance, meaning that if you try to variously stack static cards, you will fail to get them in the list. If you try to force it, you may find the get() methods don't work right, either!
It's probably not as tricky as I've made it out to be, though.
kianamaiart
stormborns
turnnoffyourmind
annaxmalina
romaincrisis
izzy806
andulkaphoto
jacobvanloon