This week I got a little bit done on the plane flights to and from the Game Developer Conference. I added an alternate control scheme for notebook computers since I happened to be working on a notebook computer and they don't have numeric keypads. I opted for a numpad-style configuration of keys that are marked on my notebook as an alternate numpad: 7, 8, 9, U, I, O, J, K, L. I looked up the notebook control scheme in Unangband and it uses a VI-style scheme, where the NSEW movement is on J, K, L, H, and the diagonals are on keys hanging off of H: Y, U, B, N. I don't like this scheme as well because, while it's more comfortable for vertical and horizontal movement, it's definitely less comfortable for diagonal movement, and diagonal movement is critical in my game.
I've made the alternate scheme available simultaneously with the primary scheme (as opposed to having a configuration option) since I don't use a lot of keys yet. The game keeps track of which one you're using and adjusts the status-line help prompts to refer to those keys.
I also made wall sliding a bit more conservative, so it would stop when you hit a usable object such as a door.
The big thing I've been experimenting with, though, is guard senses. I've been trying adding motion to the mix, so that if you move you are more visible than when you're still. After experimentation I think it may be a bad idea. For one, it exacerbates the general problem with stealth-based games, in that your movement is restricted and you have to sit still and wait (something that turns a lot of people off to the genre). However, the bigger problem is that, if you are moving and a guard is about to spot you, often times sitting still will only plant you in the path of the guard, to be discovered in a few turns when he draws near. If you are about to be spotted you need the freedom of movement to get out of the way.
Monday, February 25, 2008
Young programmer
My father recently discovered a photo of me taken in 1985. I was programming in BASICA (the BASIC that came with DOS) then.
The computer appears to be an IBM XT, which was the first PC with a hard drive (5 MB if I remember correctly). There's an HP plotter perched on top, with the myriad pens next to the monitor. A couple of model rockets are visible up on the window sill.
The computer appears to be an IBM XT, which was the first PC with a hard drive (5 MB if I remember correctly). There's an HP plotter perched on top, with the myriad pens next to the monitor. A couple of model rockets are visible up on the window sill.
Monday, February 18, 2008
First playtest
Diapers
If you find yourself among strange men the surest way to get a conversation going is to talk about shaving. Men love to talk about shaving. Likewise if you find yourself among parents of infants you can't go wrong with poop.
Before I became a parent I knew in a vague way that I'd be dealing with a lot of dirty diapers. What I didn't realize is the scrutiny with which I would examine them, like an augur poring over entrails. Babies have very few communication channels so you take what you can get.
For the first few days you get diapers that look like Vegemite. After that, if the baby is breastfed and there aren't any problems, you get diapers that look like either Dijon or French's mustard. We recently diagnosed a problem with the way we were feeding our baby from the green, frothy appearance of her output.
Enough about that, though; I can tell you're bored already.
Playtesting
I sent off a copy of my little Thief/Rogue hybrid to an old friend this weekend. He's been playing my half-creations since we were teenagers. I got back some keystroke logs and watched to see how things went.
He commented that he found the Ctrl-direction system of using things somewhat cumbersome. When you attempt to move into a closed door, you get a message on the status line that says something like “Press Ctrl+left to open the door.” Pressing the key combination opens the door; you can press it again to close the door. I also require “use” style movement when entering terrain types that hide the player (water, tables, bushes) because I thought people might be confused if their player icon disappeared. The bump messages serve the purpose of identifying things in the world, too. You can bump into anything usable and see what it is: a torch, a switch, a window, a portcullis, etc.
I already have a problem with teaching the player about the different ground types, since there's no way to bump them. Any solution I come up with for that could probably be applied equally well to water and bushes, and probably for crawling under tables as well.
Doors (and windows) are a bit more of a problem. The close-door action is already hidden; you have to use the empty door space so you don't get a bump message for it. If I make doors automatically open when you bump them it will make the close-door action even more hidden since it won't be symmetric with opening. Also, I'd need to preserve the bump message and use for locked doors since I don't think players would want to automatically enter the lockpicking minigame. Also, I am not sure how key use would fit. I was thinking of having the game automatically use the correct key on a locked door, but indicate in the bump message which key would be used.
Other random thoughts:
Doors could close themselves when you move away from them. I think this would take out some fun, though. At the moment I have locked doors lock again when you shut them, so you're committing to another lockpicking session when you shut a door. (Most doors only lock from one side, so you can freely open them from inside.) On the other hand, I've planned to make guards suspicious of opened doors, so closing a door would help keep you from being caught.
Door opening is a risky action. There might be someone on the other side, or light might spill out and illuminate you. This is part of the reason I've got it as an action distinct from basic movement.
Alternatives to the Ctrl-direction key chord method of using:
1. Bump-then-use. In this scenario you would be required to bump something to put it into ready-to-use state; then you'd press a single key (numpad Enter, say) to use the thing you'd targeted. This is nicer in that you press a key sequence rather than a key combination. However, it does require you to get bump messages for things. The biggest loser for that is door-closing. Perhaps door closing could be handled by generating a bump message when you enter the square containing the open door? It would say “Press Enter to close the door.” If you pressed Enter, the door would close as soon as you moved off of that square. If you did anything else I guess it would cancel the door closing. It's not ideal since you don't get immediate visual feedback that the door has closed; it's more like you're putting your hand on the door and pulling it shut as you move.
2. Omnidirectional use. This would work similarly to bump-then-use except you wouldn't have to get a bump message first. When you press the use key, if there is a single usable object adjacent it uses that. If there are two or more you'd be prompted for a direction. I really don't like this because behavior is different in different contexts, which means it won't be something that can be committed to muscle memory.
3. Special keys for using things. This is the grand Roguelike tradition, with several pages' worth of commands for doing various kinds of actions. You could have a “close door” command, an “open door” command, a “light lamp” command, etc. etc. I dislike this because I don't feel that making all of these actions into distinct keys really adds anything to the gameplay. If it was done in order to reduce the number of keystrokes required that would be defensible; but in most cases they could be collapsed to fewer distinct keys without adding any ambiguity.
If you find yourself among strange men the surest way to get a conversation going is to talk about shaving. Men love to talk about shaving. Likewise if you find yourself among parents of infants you can't go wrong with poop.
Before I became a parent I knew in a vague way that I'd be dealing with a lot of dirty diapers. What I didn't realize is the scrutiny with which I would examine them, like an augur poring over entrails. Babies have very few communication channels so you take what you can get.
For the first few days you get diapers that look like Vegemite. After that, if the baby is breastfed and there aren't any problems, you get diapers that look like either Dijon or French's mustard. We recently diagnosed a problem with the way we were feeding our baby from the green, frothy appearance of her output.
Enough about that, though; I can tell you're bored already.
Playtesting
I sent off a copy of my little Thief/Rogue hybrid to an old friend this weekend. He's been playing my half-creations since we were teenagers. I got back some keystroke logs and watched to see how things went.
He commented that he found the Ctrl-direction system of using things somewhat cumbersome. When you attempt to move into a closed door, you get a message on the status line that says something like “Press Ctrl+left to open the door.” Pressing the key combination opens the door; you can press it again to close the door. I also require “use” style movement when entering terrain types that hide the player (water, tables, bushes) because I thought people might be confused if their player icon disappeared. The bump messages serve the purpose of identifying things in the world, too. You can bump into anything usable and see what it is: a torch, a switch, a window, a portcullis, etc.
I already have a problem with teaching the player about the different ground types, since there's no way to bump them. Any solution I come up with for that could probably be applied equally well to water and bushes, and probably for crawling under tables as well.
Doors (and windows) are a bit more of a problem. The close-door action is already hidden; you have to use the empty door space so you don't get a bump message for it. If I make doors automatically open when you bump them it will make the close-door action even more hidden since it won't be symmetric with opening. Also, I'd need to preserve the bump message and use for locked doors since I don't think players would want to automatically enter the lockpicking minigame. Also, I am not sure how key use would fit. I was thinking of having the game automatically use the correct key on a locked door, but indicate in the bump message which key would be used.
Other random thoughts:
Doors could close themselves when you move away from them. I think this would take out some fun, though. At the moment I have locked doors lock again when you shut them, so you're committing to another lockpicking session when you shut a door. (Most doors only lock from one side, so you can freely open them from inside.) On the other hand, I've planned to make guards suspicious of opened doors, so closing a door would help keep you from being caught.
Door opening is a risky action. There might be someone on the other side, or light might spill out and illuminate you. This is part of the reason I've got it as an action distinct from basic movement.
Alternatives to the Ctrl-direction key chord method of using:
1. Bump-then-use. In this scenario you would be required to bump something to put it into ready-to-use state; then you'd press a single key (numpad Enter, say) to use the thing you'd targeted. This is nicer in that you press a key sequence rather than a key combination. However, it does require you to get bump messages for things. The biggest loser for that is door-closing. Perhaps door closing could be handled by generating a bump message when you enter the square containing the open door? It would say “Press Enter to close the door.” If you pressed Enter, the door would close as soon as you moved off of that square. If you did anything else I guess it would cancel the door closing. It's not ideal since you don't get immediate visual feedback that the door has closed; it's more like you're putting your hand on the door and pulling it shut as you move.
2. Omnidirectional use. This would work similarly to bump-then-use except you wouldn't have to get a bump message first. When you press the use key, if there is a single usable object adjacent it uses that. If there are two or more you'd be prompted for a direction. I really don't like this because behavior is different in different contexts, which means it won't be something that can be committed to muscle memory.
3. Special keys for using things. This is the grand Roguelike tradition, with several pages' worth of commands for doing various kinds of actions. You could have a “close door” command, an “open door” command, a “light lamp” command, etc. etc. I dislike this because I don't feel that making all of these actions into distinct keys really adds anything to the gameplay. If it was done in order to reduce the number of keystrokes required that would be defensible; but in most cases they could be collapsed to fewer distinct keys without adding any ambiguity.
Monday, February 11, 2008
Gravel
I tried out stacking speech messages on the top of the screen and keeping them there until sufficient real time elapsed. The problem with this is that the average time between messages, over a handful of messages (however many lines you're willing to have messages on), needs to work out to be less than the average real-time duration required to read each one. When turns can be dispatched at a rate of a couple dozen per second it's too easy to overflow the screen with messages.
My next idea to try is a variant of the “pull” method I suggested last time, where you would press a key to elicit speech. Instead, I'm thinking to try a “tooltip” approach, where speech is displayed after a short (real-time) period of inactivity. Of course, the player could have been deliberating and end up pressing a key immediately after the speech pops up, so this may just be shifting the problem. I could have speech require dismissal by the space bar; in combination with the tooltip approach it might not be onerous.
This weekend I managed to get in keystroke logging and playback, which should make it possible to view other people's games and see what works and what doesn't. The game ordinarily seeds its random number generator from the system clock, but I record the seed chosen in the log file so that playback will be identical. Other than that the only other thing in the file is a version number.
My game relies heavily on the Ctrl-plus-direction key combinations for using items in the world. I think eventually I will need a non-chord alternative for people who have cerebral palsy or want to play one-handed. I experimented with having the numpad Enter key function as a toggle-able alternative to the Ctrl key, with mixed results. I need some sort of on-screen feedback to make it work completely, and I might move it up to the numpad Plus key.
I intend for the player and NPCs to generate sounds as they move, with the noise level depending on the type of surface they're walking on. Previously I had had only creaky floorboards. A wood floor can have these sprinkled around. They're basically like invisible noise traps: every time you step on one it generates a noise.
Gravel, on the other hand, is a visible terrain type that makes noise. I got it partly implemented this week. In the Thief game I'm drawing my inspiration from, the player's noise level is a product of the surface they're walking on and their speed. In a turn-based game it's harder to have different movement speeds, but I think I've got something that basically works for the gravel. If your last turn was a move, and your current turn is a move, and the current turn ends on gravel, then a “crunch” sound effect is generated. Thus, you can walk silently on gravel by alternating movement turns with waiting turns, as demonstrated below.
The guards don't hear noises yet; I still need to implement that. One thing I noticed with the gravel, though, is that the little sound-effect text messages are possibly annoying. As a result I've been experimenting with color-coding the main character to indicate lighting, noise, and motion. Dim blue is unlit, silent, and still. Bright blue is unlit, silent, but moving. Bright cyan is noisy. Gray is lit but silent and still, and bright white is lit, silent, but moving. As you can see, the noisy state overrides all the others for purposes of display. Whether that will hold up or not remains to be seen.
I may also make gravel be something that is sprinkled around more sparsely, so that you can possibly avoid most of it by maneuvering carefully.
Finally, I put in secret doors. They look like walls, but if you bump them you get the door-opening message. These were easy but they increased my desired to clean up my door and window code so there's less duplication.
My next idea to try is a variant of the “pull” method I suggested last time, where you would press a key to elicit speech. Instead, I'm thinking to try a “tooltip” approach, where speech is displayed after a short (real-time) period of inactivity. Of course, the player could have been deliberating and end up pressing a key immediately after the speech pops up, so this may just be shifting the problem. I could have speech require dismissal by the space bar; in combination with the tooltip approach it might not be onerous.
This weekend I managed to get in keystroke logging and playback, which should make it possible to view other people's games and see what works and what doesn't. The game ordinarily seeds its random number generator from the system clock, but I record the seed chosen in the log file so that playback will be identical. Other than that the only other thing in the file is a version number.
My game relies heavily on the Ctrl-plus-direction key combinations for using items in the world. I think eventually I will need a non-chord alternative for people who have cerebral palsy or want to play one-handed. I experimented with having the numpad Enter key function as a toggle-able alternative to the Ctrl key, with mixed results. I need some sort of on-screen feedback to make it work completely, and I might move it up to the numpad Plus key.
I intend for the player and NPCs to generate sounds as they move, with the noise level depending on the type of surface they're walking on. Previously I had had only creaky floorboards. A wood floor can have these sprinkled around. They're basically like invisible noise traps: every time you step on one it generates a noise.
Gravel, on the other hand, is a visible terrain type that makes noise. I got it partly implemented this week. In the Thief game I'm drawing my inspiration from, the player's noise level is a product of the surface they're walking on and their speed. In a turn-based game it's harder to have different movement speeds, but I think I've got something that basically works for the gravel. If your last turn was a move, and your current turn is a move, and the current turn ends on gravel, then a “crunch” sound effect is generated. Thus, you can walk silently on gravel by alternating movement turns with waiting turns, as demonstrated below.
The guards don't hear noises yet; I still need to implement that. One thing I noticed with the gravel, though, is that the little sound-effect text messages are possibly annoying. As a result I've been experimenting with color-coding the main character to indicate lighting, noise, and motion. Dim blue is unlit, silent, and still. Bright blue is unlit, silent, but moving. Bright cyan is noisy. Gray is lit but silent and still, and bright white is lit, silent, but moving. As you can see, the noisy state overrides all the others for purposes of display. Whether that will hold up or not remains to be seen.
I may also make gravel be something that is sprinkled around more sparsely, so that you can possibly avoid most of it by maneuvering carefully.
Finally, I put in secret doors. They look like walls, but if you bump them you get the door-opening message. These were easy but they increased my desired to clean up my door and window code so there's less duplication.
Monday, February 4, 2008
Speech bubbles 2
Slow down! You're talking too fast
The big problem with speech bubbles is that they flash by too quickly to read if the player is holding a key down or pressing keys rapidly.
I tried forcing the player to let up on the keyboard when a speech bubble appears before accepting further input. This solves the held key case very nicely but doesn't address the rapid-typing case at all.
I also tried the traditional method of putting the game into a message-dismissal mode. Whenever pop-up speech bubbles appear, the player has to press Space to dismiss them before continuing. This turns out to be pretty disruptive, especially during chases when the guards are currently fairly chatty (to make their states apparent). It really breaks the flow and the feel that you are running away to have to continually dismiss messages.
While I was standing at the bus stop the other day I thought about whether a “pull” model would be better than the current “push” form. In this world, people would not normally say anything. You could elicit speech at any time by pressing a special listen key. Essentially, you could “ping” them for their current state of mind. This is attractive for certain types of speech, such as the guard state indicators (“Hey! I see you!”; “Where'd he go?”). There is still the question of whether time would pass when listening. I am inclined to think it wouldn't. Otherwise, you could hold down the listen key and be back to square one with dialog flashing by too quickly to read.
I'd like to have overheard conversations be a part of the game (it's a big part of the Thief DNA and a great way to add color and depth to the world). Somehow these just don't feel quite right as elicited behavior. It might be made to work, though. I could have conversation partners wait in a place until you have listened to (or interrupted) them.
The other downside of having a listen key is that it's another key to train the player to use.
The next experiment I may try is keeping speech bubbles on-screen for a minimum real-time duration. I'm dubious about whether this will work. The challenge is to present speech bubbles from multiple turns in a way that makes sense. To remain readable the speech bubble should probably stay in the same place on-screen. To preserve time ordering the older speech bubbles should be above the newer ones. I think I'd need to put speech on lines at the top of the screen rather than putting it adjacent to the speakers. I'd probably figure out a way to key speakers to connect them with their speech; perhaps with a background color.
Planned guard behavior work
This is just a dump from my design notes:
Currently the game's just not that hard. How can the difficulty be increased
in interesting ways?
Other needed changes that don't necessarily increase difficulty:
The big problem with speech bubbles is that they flash by too quickly to read if the player is holding a key down or pressing keys rapidly.
I tried forcing the player to let up on the keyboard when a speech bubble appears before accepting further input. This solves the held key case very nicely but doesn't address the rapid-typing case at all.
I also tried the traditional method of putting the game into a message-dismissal mode. Whenever pop-up speech bubbles appear, the player has to press Space to dismiss them before continuing. This turns out to be pretty disruptive, especially during chases when the guards are currently fairly chatty (to make their states apparent). It really breaks the flow and the feel that you are running away to have to continually dismiss messages.
While I was standing at the bus stop the other day I thought about whether a “pull” model would be better than the current “push” form. In this world, people would not normally say anything. You could elicit speech at any time by pressing a special listen key. Essentially, you could “ping” them for their current state of mind. This is attractive for certain types of speech, such as the guard state indicators (“Hey! I see you!”; “Where'd he go?”). There is still the question of whether time would pass when listening. I am inclined to think it wouldn't. Otherwise, you could hold down the listen key and be back to square one with dialog flashing by too quickly to read.
I'd like to have overheard conversations be a part of the game (it's a big part of the Thief DNA and a great way to add color and depth to the world). Somehow these just don't feel quite right as elicited behavior. It might be made to work, though. I could have conversation partners wait in a place until you have listened to (or interrupted) them.
The other downside of having a listen key is that it's another key to train the player to use.
The next experiment I may try is keeping speech bubbles on-screen for a minimum real-time duration. I'm dubious about whether this will work. The challenge is to present speech bubbles from multiple turns in a way that makes sense. To remain readable the speech bubble should probably stay in the same place on-screen. To preserve time ordering the older speech bubbles should be above the newer ones. I think I'd need to put speech on lines at the top of the screen rather than putting it adjacent to the speakers. I'd probably figure out a way to key speakers to connect them with their speech; perhaps with a background color.
Planned guard behavior work
This is just a dump from my design notes:
Currently the game's just not that hard. How can the difficulty be increased
in interesting ways?
- Guards should notice open doors or extinguished lamps. They should restore them to their closed/lit states.
- Guards should definitely notice missing treasure. They should go into more-or-less permanent alert when their treasure is stolen.
- Guards should hear creaky floors and crunchy gravel. (Gravel could be the every-other-move surface, although it's hard to imagine gravel in spots where the treasure will be.)
- Guards should alert other guards.
- Guards could see movement from a farther distance than a person sitting still.
- Guards should have levels of information. Do they hear something? See someone but don't know who it is? Identify you as a thief?
- There should be un-pickable locks, for which you will have to acquire a key.
- Guards should carry keys.
- Archers who can shoot you from a distance.
- Dogs who function as alarms.
Other needed changes that don't necessarily increase difficulty:
- Guards need turfs. Guards may be separated into private and public guards. Private guards have a turf; anyone spotted on their turf is assumed to be an intruder. Public guards will not accost you unless you are wanted, or if a private guard calls for help.
- A rock-throwing move to distract guards. This would allow you to take a more active role in your relationship with them.
Subscribe to:
Posts (Atom)