So it turns out my idea for the sticklike property was indeed quite awesome, and turned out well. I ignored the issue with "dips" entirely, it's an edge case and I'll wait until I get some legitimate in-game situations that look disturbingly bad before I address it.

@p This one shows sticklike containment:

What you see here:

@p - Player is carrying a mop (sticklike)

@p - Another mop is contained in a giant yellow vase (you see the handle)

@p - Smaller vases on the ground

@p - Each smaller vase contains a smaller flower (sticklike)

@p - Another smaller flower is on the ground between the vases, automatically laid on it's side (sticklike)

@p - Player has his underpants on the outside.

There is a real difference, to my mind, between a "system" and "model" in game design; though it's something of a continuum between the two.

@p A system is like a set of rules that you envision for the player to exist within. So for instance you have HP for life, MP for magic; if you run out of HP you die, and MP you can't cast spells. Within these basic sets of rules you introduce new rules: if you have the Cure spell, then you can cast Cure and recover 25 HP for a 5 MP cost. And so on.

@p A model is just a system whose set of rules that fit together naturally. Since our definition of "naturally" is going to vary a lot, so does the definition of model. But let's examine it.

In the above example, you might introduce rules for bodily and mental sleepiness. When you sleep, you recover MP (your mind rests) as well as HP (your body rests). You might also sit down and rest for awhile, e.g., if you were reading a book to study a skill in an RPG, but this won't recover MP, only HP. Now we're leaning towards model; the rules are starting to fit together naturally.

@p As we add rules to a model, we should think about ways that they would naturally fit together or interact. If we add a rule for poisoning, we should think about what that poisoning will do to not just HP, but MP. Maybe while you are poisoned, your maximum MP is cut in half to simultae adverse confusion effects due to feeling sick. Or, perhaps, your magic skill reduces temporarily for the same reason.

The trick is, some sets of rules might fit together better than others. In the above example, we aren't sure how to represent the mental effects of being sick in our given set of rules. Perhaps MP isn't the best model for mental energy, then? A better model might be mental strain. As you stay awake, this increases bit by bit, and when we cast a spell, study something, etc. our mental strain increases greatly; up to a point. If our mental strain is too high, casting a spell is less likely to work, or work well. Resting might reduce our mental strain somewhat, but only to a point; we eventually need to sleep. Lastly, as our mental strain increases a lot (e.g., if we were forced awake for 48 hours) we could start to hallucinate. Being sick with poison would increase our mental strain by a set number of points as long as we are poisoned, since we're constantly thinking about and feeling sick.

@p This illustrates the difference between a "system" and a "model". Mental strain is a model; things fit together more naturally. You could say it's a set of very simple rules that do a better job of capturing real life than the simple MP system does. As long as we're at all trying to mimic reality, we'll find it easier to work with the mental strain model than the MP system.

This brings us to the aforementioned sticklike properties. The reason I implemented it, and the reason it works so well, is not because it's a good "system" for storing things. It works well because it's a good model for reality. It's based on euclidean geometry in a way that is mathematically sound.

@p It's not a full physics simulation. A full physics simulation can be very fun; the trick is to make sure that a) it can can capture the variety of effects we want to capture and b) it's not too difficult to structure gameplay around it. But by this theory, physics is a better model for reality, and so works more naturally in a game design sense, too.

What I realized this morning, was that I could fairly easily handle water containment, now that I have this model. The basic idea is that, we add a tiny bit of extra information to our model. First, for pointlike objects, are they a liquid (maybe in the future, how much). Also, for liquids, a liquid color would be useful (future? opacity).

@p For planelike objects (really, should be boxlike) we just need to flag if they will hold water or not.

@p With this information, we can make very slight modifications to the existing model in only a few places to allow jugs, etc. to contain liquids. Moreover, and more amazing, we can actually quite consistently show the liquid being contained.

I really shouldn't go into this much detail, but I do need to make notes for myself to read over tomorrow (the primary purpose of this dev blog, after all =)

@p We have already something called an areafiller. When we are creating the renderable object, we pass in an areafiller. This filler just takes two parameters, W and H, and returns a renderable object. The generator that uses the areafiller doesn't need to know anything about it, which is what is nice.

@p What we do is create a special areafiller generator which returns an areafiller that shows the contents of an object (items inside) and also calculates liquids. This already exists, and works marvellously; we just have to extend it to show liquids.

@p Net result is that for instance, if we open up a box we can see what is inside, no matter what we put in. So simple but it's very satisfying as a player. This will just be extended to show liquids, if we're containing any.

@p Net result, if you put flowers and water into a jug, it will figure out based on the volume of water and the dimensions of the jug, how high the water should come, and render it. It will also show the flowers in the jug.

@p Behaviourally, we also have nice effects. For instance, how do we fill a jug with water from another source? We just put it in that source, and then take it out again. A bigger jug will contain a smaller one.

@p We could also envision an object-to-object move mechanic, but that isn't implemented and might be overkill (though it might be more intuitive, and hence worthwhile).

@p The other thing we could do, is when you drag a jug to another jug, if the first jug has a liquid in it, it will pour the liquid in.

@p We also need some way to account for volumes. I think the most consistent, model-like way of doing it would be to specify the volume of the water in liters. That would work but I have to think whether I really want to. First step would be to have a liquid object have a fixed number of liters.

@p We need also to handle mixing. This itself shouldn't be too hard, as long as you can end up with swampwater at the end (if you e.g., mix things that we don't know what it should produce). I'll have to think about it, but this would be a worthwhile model/system to have in place.

@p Enough! Lots to think of, and we shouldn't implement this right away. These things should be mulled over for a day or two before we start to implement. But containing liquids is going to go in, one way or another.

2009-06-08

◀ Back