Development Log: Horror Game Part 7

A big change that I've been thinking about is how to make the game scarier when it's turn-based. I mean, how can something make you want to run away FAST when a monster will just wait patiently for you until you type something?

So first I'm thinking of making "monsters" be a little different. I know that often a grotesquery can overdo it, and it loses its scariness if it doesn't resemble reality, so I'm considering going to a mostly-ghostly route. Perhaps scarier monsters would be year-end bosses or something, as long as they're rare.

But onto triggering flight response: have some realtime descriptions, that appear when you don't expect them. Consider: you're in a room, looking at a puzzle, trying to decipher it, when suddenly a new sentence pops up and catches your eye: "You feel breath on your neck." Hopefully, the player will freak out.

So to compensate for this new feature, I've rethought the UI just a little.  I think it makes more sense this way:

Top row slightly changed.

Basically, the top left used to be "static description" which was essentially flavor text, plus the directional description. Top center used to be "Dynamic description" which was puzzles and other stuff that could change. But separating these into two separate sections had a problem: the player would glance through the static description just to find the directional description ("There is a door to the south") and not care about the flavor text, which would be important to maintain mood.

However, if the flavor text were interwoven with the dynamic text, the player would not necessarily know which is which, and the game would feel less gamey. After all, if "There is a fire extinguisher in a case on the wall" were in the dynamic box, you knew you could take it, and if it were in the static box, you knew you couldn't. But by shoving all the description together, it makes things a little more mysterious. You don't know if the fire extinguisher is useful, and you might have to try a few things to see if you can take it.

I kept the directional descriptions in the top left box because that is info that is absolutely needed to be kept separate, and would annoy the player if they had to dig through that.

Then, the top right used to be specifically for monsters, but if I expand it to be all realtime text, it will get more use. The chance the player will catch it is good, but they'll likely catch it out of the corner of their eye, which makes it a (hopefully chilling) surprise.

Probably, also, now that I think about it, the bottom left could be player inventory or something, since I definitely want to go with a text parser, rather than a menu-driven game.  I'll have to think about that.

Anyway, that's all this week.  Uninteresting notes on implementation below, just there because I did write them, and I'm trying to be as transparent as possible with everything I work on. The notes are me just trying to figure out all the bazillion variables that go into making a room class, then a blip at the end about world creation.

 

Notes

Room:

Room Brief -- Quick description that can be used for pointers ("Forest", "Cemetery", "Classroom") as in, "A cemetery lies north", etc.

Static Description -- Never updates

Dynamic Description -- Updates every turn

Timed Description -- Updates in real time

Doubly Linked Lists for Adjacent Rooms?

• North
• Northwest
• West
• Southwest
• South
• Southeast
• East
• Northeast
• Above
• Below
• Set any of these to NULL if they do not apply.
• Set any of these to ? if the adjacent room has not been discovered?
• Set any of these to LOCKED if the player can't go that way until they solve a puzzle?
• What happens if you can SEE or HEAR an adjacent room?  Or even SMELL? Would I not want all adjacent rooms to be created when the player is adjacent? Or even before?
• What kind of info must pass between rooms?  What if a monster is chasing you? Surely the player must hear the noise in an adjacent room?
• Should each passage be more than a direction, but also be linked in other ways? Like VISIBLE if the player can see into the next room?

Room ID? Some kind of internal number so it can be referred to easily?

So when you enter a room, there are potentially up to 10 rooms that could be adjacent, heck, maybe even more.

What if we go the DF way and world gen at least year by year? I don't want to, but...? Makes most logical sense, I suppose. But the point is there's more to explore than you do explore! So how to get a player to explore 365 rooms and go through a door that cuts off stuff? I don't want to make 1000 rooms and erase them.

What if adjacent rooms are half generated, in the sense that only some aspects are created and the when you step into the room, the rest is generated? That may work.

Must have a flag for "fully generated", and when generated, don't overwrite anything that's already there.