Friday, June 6, 2014

Dev Log: Horror Text Adventure #50

I cut out the way descriptions were generated in favor of an adjective-based set, and also made it so common area items could have specific adjectives applied, while items in random areas would have randomly generated descriptions.  This also will apply to general room descriptions and barrier descriptions.  I first made it work on items.  Each item has a particular set of words to describe each aspect of it, so far with height and width (just as a generic test), but it can be applied to any item for specifics.

To get adjectives working with randomized (non-common) rooms, I removed the older, placeholder stuff about temperature.  So now adjectives work with rooms, so you can "look at room" or "look at [room type]" and you'll get a description with the adjectives.

A screenshot showing some of the stuff in action.
The adjective being "large" at the moment, but hey, I've got a thesaurus.
As I was testing that, however, I discovered a very intermittent bug.  On one test, the room I started in appeared to have no way out (the directional description box was empty), but after testing each direction, I was able to go up, and the directional box correctly displayed the directions for that room (except the way back).

Later on it happened that my starting room had one apparent way out, west, and the western room had one way out, east.  I thought there must be something wrong with the way connections are made at first, or walls being put up when rooms were adjacent.

Eventually I realized it was just that I had forgotten to make directional descriptions for counters, so nothing was being displayed when there were some.  But it took until a room full of counters appeared to start in before I even noticed the problem.

Of course, it makes pretty much no logical sense to have counters be above or below, unless the world is topsy-turvy.  So next I made two sets of barrier types: those that can go north/south/east/west, and those that can go up/down.  Perhaps I'll add ladders, too.  Although, it might be even more interesting to have ladders be objects, and you have to set them up to be able to go up/down to rooms.  Unfortunately, the more I think of this game as just rooms, the more I imagine the movie Cube, which is not what I'm going for.  Must add outdoor areas to the to-do list and logical connections.

After splitting up the barriers into those kinds, I thought I encountered a bug where doors just didn't show up.  I made doors identical to windows in definition, and windows showed up, so the problem wasn't there.  Next I checked what I had just made: the directional barrier list, to see if I had forgotten to add doors, but the doors were in there, and listed second, between counters and passages, which both worked, so I knew it wasn't that I was leaving out an index at the beginning or end (that sometimes happens when I use length-1 to check through a vector when I should use just length, or vice versa).  But, alas, after much testing, I discovered it was just an unlucky few random startups where doors were simply rare.  That's the nature of randomness, I suppose.

To combat that, I'll have to put in parameters and statistics for how likely a barrier (or room type, or item) is to come up, instead of the equal opportunity I have now.  Added to the to-do list.

Next I made it so the player can open closed barriers, like doors and windows.  If the barrier can't be opened, like a wall, it properly tells you.  If it can be opened, but is already open, it tells you that.  For the moment, you specify which barrier you want to open by listing a direction, so you'd say "open west door", even if the only door in the room is west.  Right now it doesn't actually matter what you're trying to open, you just need to say "open west".  Next for this is to improve the functionality so the player can just name the barrier type (if there's only one), as well as using adjectives to describe which barrier to open.  Also, opening items that are containers or otherwise can be opened.

While I was taking care of that task, I finally decided to stop fooling around with directional numbers.  Basically, barriers are contained in a vector in each room, so the north barrier has an index of 0, etc.  I always mix them up, so I created a few extra constants so I never need to remember which barrier is which index again.  This also makes the code far more readable, so you know that the string DIR_NORTH ("north") clearly goes with DIRNUM_NORTH (0), and I can forget that the number behind the direction even exists.

Next, I added some detail to the school common area, by finally adding chalkboards, chalk, and erasers to each classroom.  As I create each kind of item, I'll not just add them as possibilities for random rooms, but also put them in the school.  Of course, my to-do list of items to add is very, very large.  But before I go throwing items around, I want to make sure I have a use for each one, so in general that will require new verbs with each item.

Next I doubled back and made it so the player could examine barriers, by setting up adjectives and editing up the examine command.  It's junky placeholder at the moment, only giving a height description (and half the time it's grammatically incorrect)... but it works.  I also added a function for properly converting the directional number to the corresponding string, which I'm surprised this is only the first time I've needed that--though I think I've probably just done it multiple times in other places and forgot... spaghetti!  For now, it examines the barrier type you specify, and gives you descriptions of all barriers of that type.  So I have to do the opposite of the open command, and incorporate directions into the commands.

Code made of angel hair pasta.
I'm pretty sure there's a way to condense this slop.
Also, plenty of code cleanup, as usual.  I had a function referenced multiple times to set a room's common value as true or false, but it could all get deleted because I already made it so a room gets a common value assigned on instantiation, and that's a value that doesn't change, so it was not necessary to have all the extra functionality.

No comments:

Post a Comment