Health system using timers, flags and ifs

OurJud
I'd like to incorporate a slightly different kind of health system, based on whether or not you've eaten.

I want it to run through the whole game (not just specific locations), and work something like this:

20 minutes into the game you get a message hinting that you could use a bite to eat (I would strategically place cafes, food vans, etc to back this up). If you chose to bypass these food stops, you get another message 15 minutes later warning you about your health. Ignore the message again and 10 minutes later the warnings are cranked up... repeat until player collapses and can't continue.

However, if at any point during these reminders you buy a burger (or whatever), your health (the timer loop) is reset (even though there's no indicators for this). You are then free to roam for another 20 minutes before the loop is triggered again.

Those times are just examples, of course.

Thanks in advance.

HegemonKhan
Conceptually, quasi-code structure:

game.last_count = 0

Timer (20)
-> msg ("warning1")
-> if (don't eat) {
->-> Enable Timer (15)
->-> Disable Timer (20)
-> }

Timer (15)
-> msg ("warning2")
-> if (don't eat) {
->-> Enable Timer (10)
->-> Disable Timer (15)
-> } else if (eat) {
->-> Disable Timer (15)
->-> Enable Timer (20)
-> }

Timer (10)
-> if (game.last_count = 3) {
->-> msg ("GAME OVER")
->-> finish
-> } else if (don't eat) {
->-> msg ("warning3")
->-> game.last_count = game.last_count + 1
-> } else if (eat) {
->-> Disable Timer (10)
->-> Enable Timer (20)
-> }

The Pixie
I would take a slightly different approach to HegemonKhan. I would set up a timer that fires every 60 seconds.
player.hunger = player.hunger + 1
if (player.hunger = 20) msg ("You feel a little peckish")
if (player.hunger = 35) msg ("You feel hungry")
if (player.hunger = 45) msg ("The hunger pangs!")
if (player.hunger = 50) {
msg ("You have died of starvation")
finish
}

When the player eats, set player.hunger = 0

Have you considered doing it by turn rather than by minute? It might be a better experience for the player.

HegemonKhan
I was just coding directly for his~her design, I think I could've come up with a little better way to design it (I hope, lol), but I'd probably not come up with your way Pixie (despite it now being 2-3 years at learning code... I'm still so far away in coming up with good coding designs that you good coders can come up with so easily and quickly, sighs). OurJud not even being even a noob coder, and possibly new to 'if' logic too, isn't going to be coming up with the best designs for coding for quite awhile, though he seems to be picking it up quite well. I'm jealous, laughs. I'm slowly learning, but it's a struggle.

jaynabonne
Just to play devil's advocate here, I'd like to inject a tangent (or is it a wrench?).

I've been perusing the IntFiction forums for a while now, and I've come across posts from time to time where people wish to have hunger/air/energy/resource management aspects of their game. And the response has generally been negative. There are certain features of IF that have fallen into disrepute. One of them is mazes. Another is limited inventory (e.g. "you can't carry any more") sort of situations, where you have to constantly keep shuffling what you're carrying. Another is the "hunger" puzzle, where you need to keep finding food from time to time to stay alive.

I understand very well that the desire is some form of realism. Believe it or not, this seems to be discouraged from seasoned IF authors and players. The question always is: why does or should the player care about this? What does it contribute to the game?

Now, some games absolutely demand a hunger/thirst sort of dynamic. If your main character has crashed landed in the desert and needs to get back to civilization before dying, then resource management is a key part of what the game is all about. However, tacking a non-essential resource management aspect onto a game that doesn't require it is perceived more as busy work and a grind than a *meaningful* addition to a game.

Speaking personally, there are certain features of an IF game that will drive me away from even bothering to play as soon as I get a whiff. One is resource management sorts of mechanics, and the other is real time play. If I want the irritation of the former, I have real life to turn to for that. Why would I play a game with the same frustrations? And the latter makes it necessary to be at the game constantly to fight the time demon.

Since you seem to be combining the two, it means that basically if I'm playing and I get called away (dinner, minor family crisis, nature calls, etc), I may very well come back and find that I have died. (I tried a game on this site recently where, while playing, I was distracted for less than 30 seconds only to find when I turned my attention back that I had been killed. Needless to say, I didn't try the game again.) It is a different style, but the vast majority of IF can be taken at the player's pace. If you do plan to have real time elements, you might want to consider some sort of "pause" capability (as odd as that seems).

I just want to emphasize again: just as with the best fiction, IF does not need to incorporate a complete simulation of real life. (I would not, for instance, want to have to find a toilet from time to time either). I feel the calling myself, to try to make it immersive the way other more graphical simulations can be. But I would say don't let real life simulation aspects hamper the player experience. Don't let it detract from the story you're trying to tell or the goal you're trying to achieve. If such features are key to what the game is all about from an overall design point of view (in a critical way), then fair enough. But I would be very careful about putting in non-essential annoyances in the pursuit of the reality god. Really, while people may wonder, nobody ever complained that the characters on Star Trek never go to the bathroom. They're much more interested in the stories and being engaged on a dramatic level and staying focused on what's important.

Just my take. :) As always, do what you wish. It is your game.

HegemonKhan
just to add on to Jay's post:

if you're going to have a 'hunger' feature, you need to make it WORTH it (enough rewards to merit the effort~annoyance of it) for the person playing the game.

this is a good thread (along with other threads in the same board area, that you might want to read):

viewtopic.php?f=20&t=3877

(I know you're probably more jsut trying to test how to do things with quest, but as for making a game, there's quite a bit more to think about: the experience for the people who will hopefully play your game: your 'customers:paycheck', if it were to be a commercial game venture)

----------

if you're going to put "HP" Attribute into your game, then there's a really neat feature done by Tales of Phantasia (SNES):

you have 3 levels of 'sack' Objects that hold: (0)+200 food, +2000 food, +4000? food

and instead of using it as a direct consumable item for +currenthp, what they do is:

each step you take outside of battle, you use up XX food and getting +XX HP back.

http://shrines.rpgclassics.com/snes/top/food.shtml

err... not quite had it's mechanics right, meh.

Silver
Very good post. I'll add to it that one of my annoyances in IF (not directly applicable here but sort of relevant as that's where this timed play leads) is dying. Even if the death is deserved but more so if it's an undeserved punishment or I have to jump through major hoops to try and stop it happening.

Death in games made sense in the 80s when RAM was an issue. It could act as a block to the game ending too quickly. But that philosophy sort of died out as RAM increased and was replaced by being able to explore worlds unhindered by punishment. So if I play a game nowadays that kills me quickly I just take it as laziness on the part of the author. I'm also less likely to bother trying to play it through to the end and feel resentful that they have rewarded the effort I have put into playing their game by making me start over from the beginning again. I savaged a game recently in its review and comments section (The Piskie) for doing this.

OurJud
Thank you, all.

Jay's post (and the others echoing it) made for very insightful reading. I'm not easily swayed on things, but that post alone means I now won't be using a health system (at least not one triggered by hunger). The last thing I want to do in frustrate my prospective players.

I can sympathise, as one of the biggest turn-offs for me is a constant stream of "I do not understand that." or "You can't do that." responses. I don't mind puzzles, but when logic doesn't solve them, I get frustrated and move on to another.

However, it's funny how you become blind to these things when on the other side of the camera, so to speak, and I'm now wondering if I have other annoyances.

For instance, as my game is set in the future, locked doors (not all, of course) need to be opened with hand or retina scanners. I will describe the entrance, noting that a scanner is placed by the side of the door. 'open door' or 'enter' will get "The door is locked", but "use scanner" then "open door" will give you access.

Is this acceptable or a chore too??

Food for thought and I think proof that mechanics is just another element that needs to be given careful consideration.

Believe it or not, I did think about starting a thread on this very subject a day or so ago.

jaynabonne
I think it depends on how much you have to do it. If it's clear (and if you give some feedback when they use the scanner like "you hear the door click"), then it can be ok.

On the other side, I know some games have the idea of simplifying repetitive actions. For example, some games allow you to immediately jump to a room once you've been there (so you don't have to slog all the way back from wherever you are). The recent "Hadean Lands" (which I haven't played, as I'm i-deprived) has complex combination rules - but once you've done it once, you don't have to go through all the steps again. It's as if the player character learns.

I don't know if the door opening needs would be such that you'd make them use the scanner the first time, but thereafter the PC would just do it, having "learned" how. That's another thought, not necessarily better or worse (and definitely more complicated from an authoring point of view).

OurJud
jaynabonne wrote:I don't know if the door opening needs would be such that you'd make them use the scanner the first time, but thereafter the PC would just do it, having "learned" how. That's another thought, not necessarily better or worse (and definitely more complicated from an authoring point of view).


Brilliant!! And feasibly not that complicated. Wouldn't a simple 'if player has visited room' script do this?

I like the 'jump to room' thing too, but only because my game is sci-fi and it could be implemented as a transporter type thingy! I couldn't bring myself to use it in a game setting that would make it seem implausible, though.

Silver
Check for a flag again. Perform the first action then set a flag to player called 'scanned' then all future doors being opened will open automatically with a print msg saying you've been scanned and the door opens. If you lose the ability to be scanned for whatever reason just unset the flag so each door becomes a puzzle again.

OurJud
Silver wrote:Check for a flag again. Perform the first action then set a flag to player called 'scanned' then all future doors being opened will open automatically with a print msg saying you've been scanned and the door opens. If you lose the ability to be scanned for whatever reason just unset the flag so each door becomes a puzzle again.

Nice!

Silver
If you're doing something repeatedly (like lots of doors scanning your hand) apparently it's easier if you make a function. I'm not too knowledgable on this though as I've yet to find a situation repeated enough to require it.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums