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.
2 comments:
Could you have the speech bubbles visually fade out--become more and more transparent--in the case of staying visible for a fixed realtime.
Possibly, although one of my (self-chosen) aesthetic constraints is to not do anything that couldn't have been done on the original IBM Color Graphics Adapter. In fact, I had to check the rules recently to see whether I had remembered correctly that you could disable the blink hardware and use the high attribute bit to get bright background colors instead. (You can, and I'm doing that now, since bright background colors are more useful to me than hardware blink.)
I don't know if the fading would address the issue of too many messages coming in; were you thinking they would be rendered over each other?
Post a Comment