a few intermediate questions...

Well, just one, really I think.
So, in my game I want to add a tiredness factor.
After about 100 turns the player will have to return to there home and sleep, or find the nearest bed.
I was able to find code that had the slightest relevance to this.
At 9:10 AM: say “You realize that you are becoming exhausted.” At 9:20 AM: say “Your exhaustion is threatening to send you crashing to the floor, unable to move.” At 9:25 AM: say “You are about to drop dead of exhaustion. You really should get in bed.”
This comes from a website I discovered. Now, the question is, what should my code look like in order for this to work?
Also, if the player doesn’t get in bed after 100 turns, the game ends. I’m not sure I want to go with 100 turns, just thought I’d mention.
also, I want to add an object that will give the player the ability to fly. At first I thought of making the player able to fly right at the start but decided against it for reasons I will leave out of this post. Thank you so much in advance. I’ve gotten pretty far in my first day of coding this thing.

At 9:10 AM: say "You realize that you are becoming exhausted." and the likes work as is. (By default play begins at 9:00 and each turn takes one minute, so a hundred turns would take till 10:40.)

One way of flying would be to give the player an either/or property to set whenever the player is flying:

A person can be flying or not flying.

To create the illusion of flying you’ll then have to write rules and room descriptions etc. that check whether the player is currently flying or not and behaves accordingly. (A place may look different when viewed from the air, you may not take things on the ground when flying, and so on.) That would be the tricky part.

Instead of taking when the player is flying: say "You'll have to take ground before you can take [the noun]." The description of the Lakeside is "[if the player is flying]From this vantage point you see all kinds of stuff at the bottom of the lake.[otherwise]You look out over the lake, the water glimmering in the sunshine."

Ok then. What I mean by flying is the player will discover a suit, and this will give them the ability to fly. I don’t want them to be able to fly right away, I know how to code it if I wanted them to fly right off the back. Also, towards the end. I know this is going to be tricky but. Near the end there will be a scene the player will have to watch as it happens. Now I think I know what to do but not sure. It will be a fight between 2 individuals. The main character, a female, will have to watch as it unfolds. I think I know how to do it but not sure. It will be every turn describing the fight as it goes on. Eventually, when the fight is finished, the player will encounter danger that she will have to flee from, flying or otherwise she will die. The bad guy, in this case the winner of the fight will begin to try shooting at her. I might as well email you, seriously about the details of this game. It’s not my first IF project, it’s just my first serious one. I’ve lost the source code to most, if not all of my previous projects. But thanks to playfic.com I was able to get right back on track. Thanks, let me know if you need more info.

Ahhhhhhhhhh. This is shitty game design, don’t do this. But wait! Wait, sir! Let me say why. :slight_smile:

There’s been a ton of games that have hunger code, sleep code, recharge-some-frobitz-code and the idea just isn’t fresh or all that great. Now, if you want a bunch of things to happen and then have your player character be told he’d better sleep that’s not so bad, because you’re basically telling the player, “Hey, it’s time for a new scene, and I need you in a predictable place.” But after 100 turns, well, let me put it this way: I am a high functioning illiterate person, and my 100 turns could have me bravely reading descriptions and consulting a thesaurus/dictionary, whereas a better person (I was going to say “better player,” but no) could be flying around, solving puzzles, and getting to more of the good stuff.

Right. Then write a rule to check that the player is wearing the suit:

Instead of flying when the player is not wearing the flying suit, say "Yeah. Pigs can fly, too."

There is no such thing as a bad puzzle-type. There are only bad uses for neutral puzzle types. It is true that there have been many old school puzzles centred around eating or sleeping, and it is also true that they were all (that I have seen) universally annoying, useless puzzles. However, that is not because there is anything wrong a puzzle centred around eating or sleeping. What is wrong is puzzles with no rewards. What is the reward for eating or sleeping? Not ending the game? That’s a pretty lame reward for such an annoyingly inconvenient puzzle: that is the problem, here, not the eating or the sleeping.

It is quite possible (perhaps difficult but possible) to create an eating or sleeping puzzle with a non-lame reward. For example, finding a place to sleep where your gear won’t get stolen – that’s not bad. Another way to improve it would be to change the consequence of failure to something more amusing, like instead of ending the game, failure to sleep turns you into a raving lunatic. Failure to eat could make you aggressive, which could change a few outcomes in interesting ways. There is good stuff to be had here. There is a lot of throwing-the-baby-out-with-the-bathwater when it comes to rejecting puzzle types. The quality of a puzzle is deeply bound up with its consequences and rewards: they cannot really be evaluated separately.

P.S. This goes for mazes too. 8)

Wow the first time I looked at that it flew over my head… Thanks so much there! I’ll give it a go now. BTW, I’m not going for 100 turns, probably more like 300 to 500 turns. I want to stay away from 500 though for some reason.

I agree that it’s possible to make any kind of puzzle great, just as it’s possible to transform any story concept, however unprepossessing, into something awesome given enough craft. But this doesn’t mean that all puzzle styles are created equal; some are a lot more problematic than others. Some of this is about expectations rather than formal qualities; I will generally be less willing to give a game with a timed sleep requirement a fair shake, because I’ve seen it done poorly so often and well so rarely. But there are also solid principles (avoid petty realism, don’t be obstructive for the sake of it) that weigh against it. It’s bad by default: you have to do something unusually good to make it not suck.

I agree that rewards and consequences are pretty essential to the quality of any given puzzle, but they’re not the only thing that matters. (Unless you extend ‘consequences’ to ‘every effect the puzzle has on the play experience’, which would make it a tautology.)

You are right. But I think we are saying the same thing in different ways. I acknowledged that every implementation I have seen of this puzzle-type has been bad, but that badness isn’t a necessary component of that puzzle type. You wish to call the puzzle-type ‘bad by default’ because of the poor way it is usually implemented. I agree that it is usually implemented poorly but I don’t want to call it ‘bad by default’ because I feel that the ‘default’ should only include necessary pieces, not unnecessarily faulty implementations that merely happen to have been common in the past. I prefer to define things in this way so that I can be free of convention and see clearly what is truly possible and what is not — you might consider joining me on that basis — but I do not disagree with you at all about the potential pitfalls in designing this type of puzzle.

No that is what I meant by “bound up” — when two things are bound up they both matter. In this case, the lousiness of the typical eating/sleeping puzzle comes from the poorly implemented (read: annoying) consequences and dull (read: merely avoiding death) rewards. It does not come from the puzzle type, although the puzzle type does, of course, matter. I still feel that essentially there are no bad puzzle-types. They do matter because they are different and are useful for different purposes. But just don’t choose an annoying consequence of failing to solve, or a boring reward for solving, any puzzle, and you really cannot go wrong, so that is the sense in which there are no bad puzzle-types.

Paul.