July 15 2012 — things which can be carried around
I thought these days of game engine implementation would be tedious, but it turns out there are lots of interesting design questions lurking in here. That's extra true for today's material, which is a bit late, but hopefully only fashionably so.
We'll be occupying ourselves with the actions take
and drop
today. For this
purpose, we'll be introducing a new category of things: carryable things.
Only these can be picked up. (Oh, and "pick up" will end up being a synonym for
"take" in the game.)
Internally, taking something will amount to moving it to a special room called "player inventory". Someone could theoretically add such a room to their adventure game, and objects would magically appear there as they were taken by the player. This is considered a feature, not a bug.
Let's see what the commits look like today.
We start out as usual. A player can take things.
But only if the things are carryable. Right?
I then back-port this carryability restriction to putting things, as I realize that putting something is tantamount to taking it and dropping it in or on some container or platform.
What's the easiest way in a BDD setting to check that something was successfully picked up? Well, you can't take something twice, so that's an excellent test.
Realized that I hadn't required the player to be located somewhere before starting to take stuff, so I added that.
Implemented dropping things. Notice that, as usual, the game engine doesn't care about actually carrying out the event until that's necessary for validation. This keeps us more honest with tests.
Oh, and of course you can't drop something that you're not holding. That's just common sense.
Here's the check that dropping actually works. We know that taking works, because we have a test against taking stuff twice. So we can make sure that dropping works properly by taking, dropping, and taking something. This is quite possibly the most fun test I've ever written.
Taking and dropping form some kind of "complementary actions". They cancel each other out in some way. This leads to fun interactions between their behaviors. Maybe that's why there were a few more commits today than usual. Anyway, a nice surprise that their behavior was so rich. I don't recall thinking as deeply about this last year. Events seem to really bring out thinking about the semantics of actions.
There are many ways to factor the internals, but in this case creating a "player inventory" room and just shoving things there seemed like the simplest thing that could possibly work. And, since they're internals, in some sense it really doesn't matter if we cheat ourselves blue in there. We can always change the internals, as long as the tests still work.
Tomorrow — really today because I'm late — is the last day of game engine hacking. After that we'll start putting together the actual crypt game in earnest.