Roody_Yogurt wrote:Congratulations! I'm not much of a tinkerer, so I haven't tried that hard to break anything, but I think it's especially neat that you bundled it with a game. It was fun to play through.
Thanks! I understand about not wanting to break something. The extra week making the game allowed me to field test the contribution in a way that has made it much better than it would have been otherwise.
Roody_Yogurt wrote:I know it's not the point, but as far as the game itself goes, I'd maybe help the player out with motivation at a couple places. Like, looking at the radio (and its battery panel) prompts the thought, didn't I see a battery around her somewhere? And trying the dead battery prompts the thought, wasn't there another battery in the shed?
Also, it'd be kind to the player if he couldn't even play with the breaker settings until the radio had power, so they don't end up playing with it prematurely like I did.
There are some in-game hints, but they were a last minute addition. I'll tweak those and also provide the player with a little more motivation to visit the shed.
I put the breaker in to mix things up a little. Hopefully it's not too frustrating. I tested it out last night on my wife and she said that if she had been the one at the station they would have found her, months later, frozen to death with a shattered circuit breaker nearby.
Roody_Yogurt wrote:The one question I had about npcmove.h is, in "array path_exits[20]", what exactly does 20 represent? If it's a value that should be increased in a larger-sized game, I'm thinking you should use a constant there like I did with mine so the player can easily change it without modifying the file itself.
This is something that I should have made clear from the beginning. In the array's path[20] and path_exits[20], twenty is the maximum number of steps that can exist between an npc and his goal. If the npc is further than that the FindGoal routine will return false. Twenty was an arbitrary number picked at random. I'm sure it could be much higher.
Using a constant in this situation is brilliant. I've now added the constant PATHSTEPS, in which the default setting is 20, but can be set to whatever is needed.
I should also mention that, as of now, the maximum number of exits that can be tested by npcmove.h is 8. I've been meaning to change it to at least 10, but haven't gotten around to it yet.
Roody_Yogurt wrote:Also, personally, I'd probably change the "#ifset BETA" to "#ifset DEBUG" since that's almost more of a HugoFix monitoring kind of deal, but that's really not important, of course.
You know, I was wondering about this and chose #ifset BETA simply because I understand the concept better that Hugo's debugging abilities. I think you're right though, so now all instances of #ifset BETA are changed to #ifset DEBUG
Roody_Yogurt wrote:
In the game code itself, the only thing that really called out to me (in a distressing way) was:
Code: Select all
e_to
{
"You prepare yourself to face the cold and step outside.\n"
return outer_door
}
That works fine with your game designed as it is, but in general, I think it's safer to have circumstance-checks on strings printed in direction code. These alternatives should work better with exit-checking code:
If anyone should appreciate smooth running exit checking code, it's me. Thank you for the tip. I think I prefer the first instance:
Code: Select all
room desertroom1 "In The Desert"
{
s_to {
if verbroutine = &DoGo ! the next line will only run if the player
! actually typed >GO SOUTH
"Blinking your eyes against the whirling sandstorm, you trudge southward until you reach the..."
return desertoasis
}
}
It feels more natural to put it in the s_to property as opposed to the before property.
[quote="Roody_Yogurt"]Congratulations! I'm not much of a tinkerer, so I haven't tried that hard to break anything, but I think it's especially neat that you bundled it with a game. It was fun to play through.[/quote]
Thanks! I understand about not wanting to break something. The extra week making the game allowed me to field test the contribution in a way that has made it much better than it would have been otherwise.
[quote="Roody_Yogurt"]I know it's not the point, but as far as the game itself goes, I'd maybe help the player out with motivation at a couple places. Like, looking at the radio (and its battery panel) prompts the thought, didn't I see a battery around her somewhere? And trying the dead battery prompts the thought, wasn't there another battery in the shed?
Also, it'd be kind to the player if he couldn't even play with the breaker settings until the radio had power, so they don't end up playing with it prematurely like I did.
[/quote]
There are some in-game hints, but they were a last minute addition. I'll tweak those and also provide the player with a little more motivation to visit the shed.
I put the breaker in to mix things up a little. Hopefully it's not too frustrating. I tested it out last night on my wife and she said that if she had been the one at the station they would have found her, months later, frozen to death with a shattered circuit breaker nearby.
[quote="Roody_Yogurt"]The one question I had about npcmove.h is, in "array path_exits[20]", what exactly does 20 represent? If it's a value that should be increased in a larger-sized game, I'm thinking you should use a constant there like I did with mine so the player can easily change it without modifying the file itself.[/quote]
This is something that I should have made clear from the beginning. In the array's path[20] and path_exits[20], twenty is the maximum number of steps that can exist between an npc and his goal. If the npc is further than that the FindGoal routine will return false. Twenty was an arbitrary number picked at random. I'm sure it could be much higher.
Using a constant in this situation is brilliant. I've now added the constant PATHSTEPS, in which the default setting is 20, but can be set to whatever is needed.
I should also mention that, as of now, the maximum number of exits that can be tested by npcmove.h is 8. I've been meaning to change it to at least 10, but haven't gotten around to it yet.
[quote="Roody_Yogurt"]Also, personally, I'd probably change the "#ifset BETA" to "#ifset DEBUG" since that's almost more of a HugoFix monitoring kind of deal, but that's really not important, of course.[/quote]
You know, I was wondering about this and chose #ifset BETA simply because I understand the concept better that Hugo's debugging abilities. I think you're right though, so now all instances of #ifset BETA are changed to #ifset DEBUG
[quote="Roody_Yogurt"]
In the game code itself, the only thing that really called out to me (in a distressing way) was:
[code]
e_to
{
"You prepare yourself to face the cold and step outside.\n"
return outer_door
}
[/code]
That works fine with your game designed as it is, but in general, I think it's safer to have circumstance-checks on strings printed in direction code. These alternatives should work better with exit-checking code:[/quote]
If anyone should appreciate smooth running exit checking code, it's me. Thank you for the tip. I think I prefer the first instance:
[code]
room desertroom1 "In The Desert"
{
s_to {
if verbroutine = &DoGo ! the next line will only run if the player
! actually typed >GO SOUTH
"Blinking your eyes against the whirling sandstorm, you trudge southward until you reach the..."
return desertoasis
}
}
[/code]
It feels more natural to put it in the s_to property as opposed to the before property.