(map 'map-leader-test.tga') (player (pos 17 12)) (torch (pos 19 11) on) (torch (pos 19 13) on) (torch (pos 46 34) on) (torch (pos 54 34) on) (torch (pos 68 68) on) (torch (pos 68 76) on) (lamp (pos 58 51) on) (lamp (pos 63 51) on) (leader (patrol (pos 13 12) (pos 49 36) (pos 72 72)))
I've been plodding along on work with ThiefRL. Mostly stuff that didn't add any new gameplay. Pathfinding is a bit faster, for instance. (I cut out a ton of heap allocation during path computation.) A level loads from a combination of a bitmap and a text file now, instead of being compiled into the executable. The bitmap (an enlarged sample shown above) specifies the base ground tiles, and the text file (also shown above) specifies the rest of the objects. It's much easier to lay out a level in a bitmap editor, although I will probably eventually have to break down and write my own level editor to gain additional productivity.
Via Harry Connolly's blog I encountered an essay by author Rachel Aaron: How I Went From Writing 2,000 Words a Day to 10,000 Words a Day. I follow a bunch of writers' blogs because they deal with similar productivity issues to mine. This article has inspired me. The thrust of it is:
- Plan what you will do before you do it
- Keep productivity records (and examine them for trends)
- Find something to be enthused about in each session's work
I've decided the most crucial thing to do right now is to prototype the gameplay elements I'm considering for ThiefRL but haven't yet nailed down. Think of them as the “verbs” of the game. This will enable me to figure out which things will work together which will then enable me to organize a game.
To that end I have put together a leader behavior (aka Call of Duty mode). I'm thinking that, in the early parts of the game, you might have a friendly character lead you around as part of training in how to hide, evade guards, etc. They might also point out the locations of compounds you'll be infiltrating later and give a bit of story about what they are.
The basic behavior is that the AI wants to get to a particular spot but they also want to be close to the player. Being close to the player takes priority, but once they're close enough they will head toward their goal. Once they arrive at their goal the player has to speak to them (by bumping) to trigger the next thing.
Next I'm going to adapt this into a frog-march behavior. The idea is that a guard has hold of the player and is forcing them to walk in a particular direction. It might be tremendously un-fun but I'm going to try it as it represents a possibility for softer failure conditions. It might also work as a movement tutorial in the very beginning of the game.