Monthly update

Well, it appears that once a month, my sleeping schedule reverses itself. I'm good for like three weeks, and then suddenly I can't help myself and I stay up all night, go to bed at 6 AM, and then I'm stuck for a few days, trying to get back to normal. My apologies if this post is unintelligible.  Life!

Blarg!

So like I mentioned previously, these mini-updates on the status of the horror text adventure don't mean much, and on days when the work peters out because of distractions, I feel like I'm not posting anything useful.

So I think what I'll try this month is posting updates on the horror game once a week, and reserve the other post that week for something else.  That way I'll feel like I accomplished more in any given post, and it'll also break up the posts and give them more variety.

Dev Log: Horror Game part 12

Nothing of interest, coding-wise, to report; simply played with a splash screen. Mostly my time has been spent on my volunteer project last weekend, since it was crunch time.

However, I've been playing a few interesting games and thinking about how they compare to this one. None of them are text adventures, of course; but this is more in regards to how gamey they are, and what feelings they evoke.

I played a tower defense game called Demons vs. Fairyland, which I 'beat', in terms of completing the last level, but I have yet to get '100% completion', meaning I haven't upgraded everything or gotten platinum stars in every level. But really, I don't care much. It's all just badges and achievements after you beat a game.

I also played Daymare Cat just the other day, which I don't think is quite canon with the Daymare series, but more of a side story, or just a bit of art. Mostly it serves as an ad for a music artist, but that's all beside the point. It's basically a platformer and item adventure combo (by 'item adventure' I mean the kind of game where you simply find items and figure out where to use them). When you beat Daymare Cat, it's game over. And yet the Daymare world is so visually interesting you wish it would continue.

Now that's more like it: a game that doesn't overstay its welcome, leaves you wanting more, and doesn't BS you with badges. Not that I'm lamenting DvF, since it's a perfectly good tower defense game (even though I've said in the past I don't like them in the first place, DvF is quite good).  What I mean is that I think a great game leaves you wanting more because it's good, not because it's addictive.

That's always been my philosophy, at least since I thought long enough about games to devise one. And with this horror game, that's also exactly what I need to do: make it fun, but not gimmicky. DvF is a game and clearly a game. After every level you see if you've gotten enough experience to level up, you look at all the little numbers, you try to maximize everything, you meticulously plan before you hit the play button on any level to make sure it goes off without a hitch. Daymare is more of a flow sort of game: you are in the game and experiencing the single play mode, there are no numbers, you simply walk around, explore the scenery, and solve some puzzles. You never leave the 'main mode' of the game, since there really is only one.  It's a game (like the rest of Mateusz Skutnik's adventure games) that tries everything it can to draw you into the unsettling world and keep your attention in it.

With this horror text adventure, I want to accomplish the same thing: create a world that creeps you out but make you want to keep exploring because it's so fascinating. And I'm also someone who finds himself desiring to stick in garbage like achievements and leveling up and numbers in everything, so I'm doing what I can to force the minimization of that stuff. Because the world is randomized, there is not likely to be any chance for such things, or at least I can't figure out a way to put any in (not that I'm trying very hard), and that's the way I want it.

In the early stages of making any game, when nothing is really playable, I have to find motivation where I can. For this game, my motivation has to come in by playing other games, especially games I don't like, or at least don't want to emulate, and say to myself "I can never find a game like xyz! Oh, my game is doing that; I think I'll work on it."

Of course, I've also got to know when to put away the addictive games. I spent way too much time on Demons vs. Fairyland already. Man, am I glad I'm not a smoker.

Dev Log: Horror Game Part 11

I did a fair bit between this post and last post--enough to have to reread the last post to see just how much!

Most of it was spent figuring out rooms. I've got a lot more to go, of course, but I've got a few basics down. Right now a room has pointers for each surrounding room, and when it's randomly generated, it throws each surrounding room type into a list, along with a randomizer keyword, and then picks from that list to determine what the new room type is. I'm sure I'll play with the odds of a new room type when I see it in action, but for now I think it's kind of a neat way to go about it.

I've also decided to give the room and player a vector of items, and the player gets a pointer to which room s/he's in. I found that once a decision was made about how they'd be handled, the coded was very simple. The hard part is mostly deciding the best approach that won't bite me down the line.

I've also started working on a "New Game" interface. I'm trying to decide whether the player character's physical description should actually be a thing in game, so if Player A looks at Player B, they'll get a description, or if players should not be limited in that way, and should describe themselves if asked. I want to try to help the player get into the game as much as possible, and it's always tricky deciding if it's best for the player to be able to customize their avatar (in this case their description) or if they should just pretend to be themselves. I also don't want the player to have a long drawn out customization process before getting in the game, at least not without a randomize button.

For now, though, I think player customization is low on my list of priorities; I want to be able to start dropping the player in a room soon and see how it works out.

Dev Log: Horror Game Part 10

I figured out some interesting things this weekend, mostly about how to make a text parser. I discovered I already knew how to make a text parser, but tutorials I found online were misleading. Combining a little of what they said with a much more basic and flexible way to read text, I got it so it takes the full command when the player hits enter. Text parsers online wanted to do it on a character basis, which is kind of overkill.

After that, I divide the text into words, putting each into an array slot (or vector slot, as the case may be). Currently the parser can take an infinite number of words, which may be necessary for the chat portion. Basically if the player is talking to the game ("Open door") I imagine at most four words ("Tie rope to tree"), but if the player is chatting with (what will be) a chat command, they should be able to type as much as they want (I suppose within reason).

But anyway, now that I've got the text split into words, my next step (in the text parsing area, that is) will be to create a dictionary. I expect that the average player will use the sentence structure verb-subject, or at most verb-subject-preposition-direct object, so hopefully I'll just have to identify the position of the word to note its type. That may be the best way to do it, but I suppose that might not even be necessary, on thinking about it. We'll see.

Of course, such a thing as a text parser requires testing by nature, especially testing by a player who's imaginative. That way I can create a dictionary of things that a player can do, useless and useful. Start useful, of course; turn useless only when I run out of ideas.

But combining a dictionary to what's actually in the world will be the tricky bit. My first thought is to have a series of booleans that determine what objects are in the room, and therefore what the player can effect, but I don't like that very much. I'm positive there's a better way to do it.

I'm thinking if I visualized the world as a map in the way I drew the school earlier, and programmed the dictionary to interact with those objects accordingly, things may work out well. I'm used to thinking in abstractions like booleans, but I think visualizing the world more concretely will be a better way to do it.

So I'll switch gears out of the text parser for a little bit, but keep it in the back of my mind while I work on making room objects and such.

Dev Log: Horror Game Part 9

I've been doing more research into the best language to use. I played around in AS3 some more, but since this game would be a multiplayer game, requiring an Internet connection to meet others, as well as files stored on the PC for the player's personal randomly generated world, it would have to act more like an MMO. Using basic Flash/AS3 has the problem of not allowing files to be created onto a PC (mostly for security reasons, since an Internet app that could do that could easily install malware, etc.), but after trying to look up a way around that I discovered AIR. AIR allows me to code in AS3 but additionally allows me to create files on a player's computer, and hopefully also allows me to hook that up to a server.

So far, all I've been seeing is stuff about SQL databases, which I don't quite know how to use, but this gets me a big step closer to seeing this as being feasible with a language as comfortable for me as AS3.

Using AIR also gives me the bonus of being browser independent, since it creates a standalone application. I hear mumblings that Flash will be replaced for web with HTML5 and other things, so even if browsers start to drop support for Flash, it won't matter to me. The chance of that happening anyway is for another article.

But I'm getting optimistic about this project and can see it now forming as more than just an idea and half-functioning prototype. The biggest barrier for me has always been the fear of backend development like connecting to servers and whatnot. I know I have a ton to learn about it, but it seems a little less scary now.

Development Log: Horror Game Part 8

Well, not too much this week. Travelling last weekend (hence no post) plus extra hours on my volunteer project (gearing up for crunch time) means little time for this project.

So the small update today is that I coded up the 6-panel UI, just visually, that is, and started learning about how to handle a text parser. This is just in Flash, mostly because I like AS3 and I have the most recent practice with it, though I may change languages before things get too deep. Maybe.

Also, my design notes for the past week were nothing to write home about, just considering making it so a "chunk" of a level/year or a whole year at a time, generated at the beginning of the year, rather than one room at a time, mostly so that ghosts could be free-roaming.

I think that I'm also going to try out small posts like this for the month, and just see how it works out. I may end up feeling guilty and spend next month writing giant articles or something.

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.