That depends to some degree on your language choice. Some languages allow you to modify the class inheritance tree on the fly (Perl, Ruby, Python?, Lua?), where others have it nailed down so you would have to create new subclasses.



Sure, but you're confusing the IS-A vs. HAS-A model there. A tree branch would generally not BE a light source, but it may HAVE things added to it that would themselves be light sources. In your example, the fire itself would BE the light source, and thus would inherit LIGHT. I could also see glowing lichen, or even dead fireflies as something which would act as a light source and be attached to the tree branch.

The key there is how you handle allowing objects to be grouped. You could make "on fire" be a property. You could also make the fire itself be a first-class object and have it be physically attached to the branch, so the two things both act on whatever they're around. If your language allows it, you could on-the-fly add LIGHT and HEAT to a tree branch and create a (temporary) burning-tree-branch object which would inherit both of those without having to plan ahead beyond having a property (or class) to indicate that it is flammable.

Now, you don't really want to have to wander around to every object and add "flammable", "soakable", etc… so of course you want to have those things be in the materials the objects are made of. A tree branch is wood, so it could inherit WOOD as its material, which in turn would inherit FLAMMABLE, opening the door for it to have fire attached to it (or added as a property). Of course you can do all that via properties and lots of if/then checks too…

I can see where a rigid language like C++ might well make using properties much more attractive, since as you say, you can't really generate subclasses on the fly, and also can't account for all desired permutations ahead of time.

@quix: What you're proposing sounds over-engineered to me. I'd be interested in seeing what you're referring to by "grouping", though. If you're telling me that each thing would have a collection of other things attached to it, that's an interesting proposition on its own. Can't say the idea of fire being a first class object sits well with me, though.

Edit: Also, the language I'm personally using doesn't allow runtime inheritance restructuring, so inheritable properties aren't an option for me, AFAIK. It would certainly be nice to have inheritable materials and the like, but due to the language restrictions, that would mean that changing materials on the fly would be really complicated, I think.

Grouping simply means you can in some way attach several objects together so they act (collectively) as a single thing with properties of each part. For example, a sword might be a collection of a hilt, a crosspiece, and a blade. The hilt could give you a bonus to accuracy/skill, the crosspiece might give you a boost to parry/armor/riposte, and the blade would give you your damage numbers.

In the case of our tree branch, the tree branch by itself isn't a light source, but if you have a mechanism for combining objects, it could be combined with something that gives off light, be it some fungus, fire, or something else. The exact details depend entirely on your infrastructure. The simplest might be to just have base objects (like your branch) have a "modifier" inventory of affects or other objects which would augment their function. The player sees "you light your stick on fire", and what actually happens is the fire affect is added to the modifier inventory, and so whatever methods/properties/etc are available for "fire" can be iterated over when using the "branch".

IE: When you call "do_damage(branch_object)", it might in turn call do_damage() on anything in its modifier inventory, giving each thing a chance to do damage (or return some damage data to be added to the branch's attack). If an affect/thing doesn't do damage, it would just have the empty stub do_damage that returns NULL/0/whatever so nothing gets changed. So your basic "object" inheritable would need stub functions for some things you anticipate using, but they don't need to be fleshed out unless the thing in question can actually do it.

I dunno, it's a thought anyways.

That is where you start having to put mre and more logic in your game in order to make it coherent then.
The hilt is made of wood, so you can put it on fire, but then, by where would you hold the sword. The blade ?
Ok, so now you have to make so an item reacts differently dependings on wich part you hold it.
And so on and on and on. You HAVE to put a limit somewhere for the sake of your game. It is not a code problem, it is a human problem. You will not be able to code everything timewise anyway. We get back to what you want to achieve. Objects will be limited one way or another, so no need to go too far anyway. Since you will not be able to use all the possibilities you forced yourself to code. Useless complexicity.

That's precisely the approach I take in my game. I use a size range from -1 to 999. Every object and character has a size associated with it. Objects and characters can change sizes. The ability of characters to interact with objects is often based on the relative difference between their sizes. For instance, utilizing something as a weapon follows the rule of Character.size +/-5. Admittedly, I've noticed a problem with that restriction when a shapeshifter becomes a size 140 giant and can only use objects in the 135-145 range, likewise with a size 3 pixie being able to use a size 8 object as a weapon. Perhaps I should make the variance a percentage instead of static numbers.

I'd respond to some other points in this thread, but I'm short on time…

Yeah, that's how I do it as well, but I'm still struggling with how to classify really odd shaped objects like spears, lances, trees, etc. They're really long, but not "big" like other, less oblong objects with similar dimensions.

So, a boulder that's 10 ft. in diameter is size 100 (or whatever). Does that mean a 10 ft long spear should also be size 100? I don't think so, but nor do I think it should be size 30 like a chair, either.

That's the problem with trying to map 3 dimensional objects into 1 dimension, though. For now, I'm just leaving it be, even if it does cause a few suspension-of-disbelief scenarios.

Use cubic measurements like freight shippers do, then. You'll pay dearly if you ever want to ship a box that LxWxH is >= X or Weight >= Y. Or transpose your current relative "size" figure into multiple dimensions given some basic properties of each "thing". Anything derived from spear must be at least 2x longer than wide; players can not wield anything derived from spear if it is X heavier than they are or X% taller, because then it would be too long to be practical for use.

I used the largest dimension of an object in inches.

So a 10 ft spear is 120.
A short sword is 24.
A small sack (3 ft diameter) is 36.

I'd use inheritance as composition, however your language doesn't support it very well.
In C++ and C, you might want to look into dynamic delegation.

I think that bulk+weight is a decent approximation of this. Your 10ft boulder will have big bulk and big weight, whereas your 10ft spear will have lesser bulk and lesser weight.

You can consider bulk to be cubic inches, or whatever.

It's realistic that you can use a very "big" weapon that weighs relatively little (a whip, even a spear), but it's not realistic that you use a weapon that weighs too much no matter how big it is (e.g. a human couldn't wield a 200lb dagger).

This, more or less. I still keep up with weight as a separate attribute from size. The lance and the boulder may both be size 100, but the lance weighs ~10kg, while the boulder weighs ~100kg.

For those of you who implement bulk + weight, how do you handle inventory capacity? I'm curious whether anyone's going for realism there in any way.

Inventory capacity is also defined as bulk+weight. The idea being that you can't really carry around a very bulky even if light object unless you're, well, carrying it in your hands in which case it's different from inventory, which is presumably your pouch, pack, or whatever.

It's not perfect, and not realistic (you could still strap large but light objects to yourself, in principle) but it keeps things simple while allowing for more believable situations where it counts (combat, the be-all end-all of many games).

This idea isn't new, by the way. Castle of the Winds (graphical single-play MUD) featured it quite prominently 23 years ago.

I read this post several times and can't say I understand it. Does your game implement bulk+weight-based restrictions on inventory capacity? If so, can players carry more than their own bulk or their own weight? If not, do they get annoyed that they can't carry more than 3-4 swords or more than 1 jam-packed backpack? If players' bulk and weight varies based on race, etc, does their inventory capacity vary also and if so, how does that affect 'fair play'? These are the kinds of questions I find interesting and I think some specific examples will help me understand better.

I've been toying around with a few different inventory management systems. One requires each item carried to be in a specific location. Hands, a bag, a backpack, etc.. with the ability to "ready" items in certain bags. While I consider it slightly more realistic it can be unruly and would probably just lead to people scripting item handling. The other is a console rpg style system with few set equipment slots and an inventory system that features no weight, bulk, or item limits. In the second system item use is menu based and cannot be exploited in combat as using an item will use your combat turn (as will any other action – aside from a few special abilities).

EDIT: I misread the question about inventory management and completely missed with my answer. In the first system I haven't added weight or bulk yet but I was considering just giving containers an internal numerical size and weight capacity. Each item will have a "size" and "weight". You cannot exceed the maximum size of the container by placing items inside of it and exceeding the maximum weight can damage the container. I hadn't considered how to handle bulk in carried items.

I find these types of mechanics discussions relatively tedious. For me it was always acceptable to limit inventory by item count alone. It plays fine for my tastes and the mechanic is simple enough that anyone can immediately understand it. "Okay, so I can carry 20 items total." I even removed the ability to place items in containers in my game and made container items when equipped add to the maximum inventory statistic. Not because it was too much work to engineer nested items, it was done for chests and what not anyways, but because I err on the side of concepts rather than arbitrary realism in a game. It may be that your game needs to use complex spacial algorithms to determine if someone can carry another magic mushroom. I just personally think it's too much for a text based game, since visually is how normally humans judge this sort of thing. Raw information like bulk and dimensions being determining factors is just lost on most players, myself included.

As much as I like tedius realism, having a number of inventory slots is not only simpler, but lines up with what graphical games do these days. In particular, graphical MMO's often implement a set number of "bag slots", which can have containers equipped to expand storage. So, a new character has a single backpack which might hold 20 items, and occupies 1 bag slot. If you obtain a small bag, it might add 6 more inventory spaces and use another bag slot. A large bag might hold 12 items, and a magical floating chest that follows you around could have 32 spaces.

Scale such numbers as appropriate for you game, of course. Graphical MMO's tend to be loot factories, and it takes some time to get back to town to sell stuff.

The spatial inventory management that I've been toying with isn't something I'd use in production. I agree that simple is better in this regard and I'm not interested in limits really.

I do approve of this approach and may consider it myself, the only caveat being that I enjoy nested containers on a player simply for what you can "do" with them. Any game that allows stealing/spying at another person's inventory benefits from containers to obfuscate the contents of your pack. Containers also facilitate simpler trade/item management for players: put all the items to trade, or all items from a "RPing" equipment set vs the "combat" equipment set into separate containers. It's a lot easier to trade one container instead of multiple items.

All of the above can certainly be emulated in code, without containers, but I believe that's less direct for the player to know what's going on. In my game containers can also catch fire/explode – poof, there all your stuff went on the floor; but there are also enchants to prevent this. For simplicity, I entirely agree with this method (of just raw item count) – but for further mechanics, I still like having nestable containers.

Was that a typo?