I've been working on a PHP web-based (MO)RPG for about a week now, and I've finally gotten to the point where I have to implement inventories. This is one aspect that I haven't come to a decision yet about how I'm going to implement it, because I haven't figured out what, exactly, I want from the system. So I'm asking here for some opinions on some of the options that I've currently got in mind, being mindful of the database structure that each will require. Basics: In every situation, there are (at least) 2 tables: the item 'dictionary', and the player inventory tables. The dictionary contains a row for each item in the game, with its stats, effects, description, etc. The inventory table describes the items currently in the possession of the player. Decision One: Limited or Unlimited Inventory for Non-Equippable Items? Basically, if we take the subset of all the items that might be 'collectable', ie, potions, boar hides, arrows, essentially items in which one would expect no stat variation, we have two choices: limit the number of different items one can carry, or not. My explanation is poor, as usual, but this decision determines the structure of the inventory table. In the former, where there are limited inventory slots, the table becomes a set number of item#/quantity matchings - playerid | item1id | item1count | ... itemNid | itemNcount Where N is the maximum inventory size. The other option is slightly more space demanding, since we can potentially have every item in the game at once - playerid | countofitem#1 | countofitem#2 | ... countofitem#N Where N is the number of items in the database. I personally have no opinion on this one, but am leaning towards a combination of the two - have the player's "out in the field" inventory be limited to a set number of items, and have an unlimited storage space back in the city. This adds an equipment strategy dynamic, since it takes time to walk back and forth between the city and other areas. Regardless - this only works for items in which every 'copy' of an item is identical to every other item. (a 'rock' is always a 'rock' and shares the same qualities as every other 'rock'). Decision Two: Items with 'Unique' Qualities..? This is where things get a little complicated. For things like equipment, I'd like to have a bit of diversity. Maybe this piece of leather armor is beaten up, and thus doesn't provide as much protection as that piece of leather armor. Or maybe this steel sword has an enchantment which causes it to turn orcs into chickens when the moon is full. Or maybe it just has slightly different stats than the others. Basically, things that add flavor and diversity. Option 1: Pre-calculated Permutations The cheapest solution to this (using an existing solution described above) is to make each possible item its own item with its own unique item ID, ie, "beaten-up leather armor" and "leather armor" are completely unrelated items, except they have the same name and picture. I think this is an unacceptable method, simply because... ugh, it requires excess stupid work to generate all possible permutations. Option 2: 'Identical' Items and 'Deviant' Items If we instead break out of our "each item is identical" (as defined in the item dictionary), we need to add more stuff to our inventory layout, since we need to have more data to define what's unique about this particular instance of the weapon. We need a method to define this uniqueness, though... Option 2a: Enumerated Differences This is the approach used by Space Cowboy Online - each weapon could have a prefix and a suffix. The prefix and suffix were, essentially, fixed stat modifiers which acted on the weapon's base stats. Since each weapon could only have, at max, one prefix and one suffix, the system wasn't too unmanagable, but a little limited. For example, there would be no easy way to enumerate the remaining durability of a weapon. Option 2b: Explicit Differences Conversely, we could explicitly say that each weapon is BASE+13 DAMAGE, FREEZE ATTRIB, 58% DAMAGED. This would provide the maximum amount of flexibility, but essentially kills the entire point of having an item dictionary. Which is bleeehhhh because it would take up quite a bit of space. Conclusion: Basically, I haven't been able to think of a solution I like to this problem. The constraints are -

• It must provide a flexible system allowing a diverse range of weaponry
• It must be... sane to implement (with respect to table layout)

Opinions/Comments on my current ideas? I'm really lost right now :(

Decision One:
Well, when you're trying to mediate between convenience and realism, which is a category where I'd put this dilemna, I'd usually go with realism to be safe. It seems to me that infinite inventories (limited or no) and the like melt the structure of a game. Items begin to build up in mass quantities, reducing their perceived value, and when the perceived value of items goes down so does the drive to collect items at all. Conversely, if crafting/economy is set up to accomodate an amount of items roughly equal to the amount that will be collected, then having an infinite inventory is completely unnecessary.

I would suggest a modest field inventory and a healthier city inventory.

Decision Two:
I have to be honest--I got confused with your description of Enumerated Differences, but I'm pretty sure this is what I feel would be the best decision. Though I'm not sure I like the prefix/suffix idea. I think they should share names but have slightly varied stats. The prefix/suffix would only be for the player's sake, right? If you needed to, an invisible prefix/suffix variable pair would be fine, but I don't like how visible word modifiers turns out.

Definitely your gonna want a limited inventory. Simply put a lot of people hate getting rid of stuff in a game and will hoard everything. Even things that are worthless. Also it takes up more memory on your server.

Personally I'd use a Level * Modifier + startingWeight, or just copy WoW's bag system to show a number of items picked up. I'm against the Diablo 2 mini-puzzle-game that was put into the inventory. So basically you can go by a weight system, or a slot system. A slot system as you deduced was Item ID and then how many of that item can be stacked for a slot. The weight system relies on each object to have a weight and a listed inventory. You can still use bags instead of a strength or level modifier by just having spots for bags and setting a weight each bag adds to the maximum weight.

Having limited items also stops someone from grinding the same area for as long as they want for expensive items or supplies. Since they will want to go and sell stuff when their inventory fills up.

As for Identical and Unique items that's fairly simple. (easier if PHP allows polymorphism). For instance if you put a variable called "unique" into the system right when someone imbues or enchants or damages or modifies an item, it is no longer an ID and is put into a specific item dictionary unique to that player. Basically it's a copy of the item with it's modified stats and still has an item ID so it can tell it's differences from it's original. Explicit Differences can be handled the same way, just when the item again equals it's item ID item change it back into an item ID. So you might damage a weapon and then repair it. It will be unique as long as it's damaged. Unique items that are sold are destroyed from the game, and traded items between players is just added to the other player's unique items.

With respect to the table layout this is very possible. Get coding, it could get advanced, but only as advanced as you make it. (I'm making an MMO real time and that's how I handle everything kinda).

Quote:

Original post by Mushu Option 2a: Enumerated Differences This is the approach used by Space Cowboy Online - each weapon could have a prefix and a suffix. The prefix and suffix were, essentially, fixed stat modifiers which acted on the weapon's base stats. Since each weapon could only have, at max, one prefix and one suffix, the system wasn't too unmanagable, but a little limited. For example, there would be no easy way to enumerate the remaining durability of a weapon.

I had no idea that <big> was a tag. I guess I can only blame myself, because I haven't reviewed HTML since 4.0 or so.

Since you don't want to have an ItemEntryAttribute table, you should probably fix a maximum of special attributes for each item. The two (prefix/suffix) from SCO sounds a little small, and I wouldn't want a fixed relationship between item name and attributes. I haven't played SCO, so I don't know if that's how it works or not (Please tell me it's about Cowboy Bebop!).

I don't know if that defeats the purpose of an item dictionary for you, because I don't know what information you need to be common to all items of a particular type and which information can vary.

I'll just organize it how I would enjoy an RPG to flow, and see if I hit far from your target. I'm not so hot on PHP, so I'll use the Common Tongue


In the above code, I set up some classes to describe generic ideas of weapons. So, Excalibur is designated with WeaponType LongSword, given the appropriate power, piercing and so on.

Then, in populating your game world with items, you'd use the following classes:


Finally, to create an Excalibur item, you'd do ItemFactory::Create(EntryID); where EntryID == WEAPON_EXCALIBUR. In the item instance's constructor, the ItemFactory fills in the default stats from the dictionary.

The reason I like the enhancements (turning Orcs to Pigs for instance) array is that it keeps the number of them fixed for easier databasing, as well as being modular for better reuse of effects over different items.

The next problem comes in whether you locate the enhancements in the dictionary or in the instance. In the dictionary, you can create as many copies as you want of excalibur, but you can't create weapons with random enhancements like the rares in Diablo2. Placed in the instance, you'd have to populate the enhancements of each item by hand, which automatically disqualifies it.

I say have an array of a fixed number of enhancements in the dictionary, and a dynamic array in the instance. That way, enemies can cast rust on your excalibur, independent of its dictionary enhancements. Since I don't know PHP, I don't know how you'd save the dynamic enhancements outside of an Item -> Enhancement database where each line is an ownerID, uniqueItemID and an enhnacementID, which sounds an awful lot like your original problem.

back to decision one:
I agree with the earlier assessment of limiting carry-on player inventory. I would limit it by weight and give them an unlimited number of slots, because wrestling with inventories is not a good time. As for a bank-like inventory in town, you could limit that by something different like volume, just to be a jerk about it! [lol]

Awesome, thanks for the input guys - I think I've got something scratched together that'll work fine (mostly Option 2b). Huggles and rate++ all around.

Also, <3 Washu.