More progress today.

Changes:

• Switched to Open Sans for better font weight options
• Updated tag styles to include semibold, cursor style and hover
• Updated player output style to be more traditional
• Added a nifty background (experimental) with sunbeams and falling leaves
• Added a new Rule system. It’s expansive, so I’ll go over it in its own post.
• Cleaned up nametag helper to more closely match tag helper
• Added cursor styles for LOOK and TAKE tags

Bugs & Problems:

• Looking at an invalid thing while using a look alias results in odd output: “I understood everything up until ‘examine bird’” vs “I understood everything up until ‘bird’”. Worked around it with an onBadInput catch, but I’m not completely happy with it.

• Experimental background stuff is performance intensive. Should have an option during setup, or disable by default. Need to look into better solutions (canvas?) later rather than CSS/jQuery.

• Nothing new

More progress today.

Changes:

• Added descriptions for lair and wyrmling
• Added missing exit tags for all locations
• Made locationIs() check more flexible
• Fixed exit descriptions in dim clearing
• Fixed exit descriptions in east trail
• Fixed bird chirps not working
• Fixed wyrmling anger

Bugs & Problems:

• Nothing new

Made a bit of progress today, but I’m also running into a few bugs that are proving tricky to track down. As a followup to yesterday’s post, I’m going to relax the schedule on what I write about each day, with the exception of the Weekly Update. Still 7 days a week, 5 days coding, but the writing can be about whatever rather than alternating SRPG/Other.

Spoilers below (really, it’s just going to be spoilers all the time from now on).

Changes:

• Added Lair
• Added Wyrmling
• Added a couple dialogue options for Ranger Bob
• Added Ranger Bob’s twig

Bugs & Problems:

• Nested dialogue trees don’t seem to work quite right
• onEnter handlers for locations are super clunky
• Need a way to add visible/interactive items in other character’s inventories (for example, looking at a pipe being smoked by an NPC)
• Bird is roaming outside its area

Today I did the thing I said yesterday I’d do today. My new goal is to do that today almost every day.

I’m coming up on 60 posts to this dev journal; so far I haven’t missed a day, and I’m pretty pleased about that. What I’m not pleased with is my progress on the game itself, planning and dreaming aside. So I’m setting an additional goal: writing code for StupidRPG 5 days out of every 7. It doesn’t have to be a lot, but something needs to be happening on a continual basis.

My schedule is now:

• Dev Journal: Every Day
• Coding: 5 days a Week

Today I added the Temperature module and the Thermal component. It’s work in progress. I started by adding temperatures to the Player (warmish), the hot springs (hot), and the glowing orb (lukewarm). Temperatures can be optionally displayed in room descriptions. I also need to add a System to handle Thermal objects, since they can fluctuate in temperature and change the temperature of other objects.

I’ve decided to add a Temperature component to the game. It will initially be used for a challenge related to the hot springs, but may have other interesting uses later on. With this component I’ll be able to create puzzles with thermal elements, make things like ovens, or add dynamic NPC behaviors based on the current temperature (seeking out warmth, for example).

First up: adding a thermometer to the game.

Too busy. Things heating up at work.

Changelog:

• Planning

Known Issues:

• Nothing new

Next Up:

• Fill out Ranger Bob’s dialogue tree.
• Add The Twins.
• Wrap up litterbug quest
• Fill in new character

Don’t have a regular update today. Went to a friend’s wedding, partied hard. Excellent evening.

I’ve been thinking a bit about versioning. StupidRPG as a project is version controlled, just like any software project should be. Now I’m considering versioning save files, at a yet-to-be-determined level of granularity.

The problem this is intended to solve is program changes breaking a player’s save file. For example, if I remove an area entirely from the game, and the player’s save puts them in that area, now they have an invalid savestate.

Versioning the save file (as a whole) allows for ‘migrations’ (a script that transitions the structure of the data) for save-breaking changes like this. A change that removes an area would also include a version migration to check for objects in the area and move them to another location deemed appropriate.

I don’t think there’s any case where the versioning needs to be more granular (i.e. per-entity versioning). I sure hope not.

This one’s pretty simple. SRPG breaks if you kill everything, so that won’t be allowed. In a perfect, psychopathic world, you’d have the freedom to murder everyone, but that doesn’t seem particularly feasible in this case. This is similar to games like Skyrim or Fallout 3, where you can kill most people, but certain key NPCs (without whom the game is impossible to complete) are protected.

This might seem like an odd thing to mention, but it’s a design decision that doesn’t simply happen on its own. The default behavior is mirrored from the EAT (can’t eat anything by default) behavior: you can fight anyone by default, with restrictions on fighting certain characters. It will have consequences, however, based on the factions of the targets you choose.

A filter is a piece of code that runs before an action, to determine whether it should be allowed or modified. The first use of this feature is a filter for taking objects from containers. If the container is closed (something the TAKE verb has no knowledge of), the container filter makes sure execution doesn’t continue (and an appropriate response is generated).

It’s a valuable feature, but a bit rough around the edges.

Filters Now

• Easy to set up, works fine for simple cases
• Behavior for multiple filters is undefined (that’s bad)

Filters Later

I need to expand the feature set to handle more complex situations. Primarily:

• More advanced feature constraints (e.g. “filter for TAKE from a container in the Cave”). Right now a filter runs for all actions matching the given verb.
• Handling of multiple filters in a predictable way. I don’t have a firm solution for this yet. The simplest way to handle it is a prioritized list, but the relative priority of two filters isn’t necessarily the same in all situations.

There are also a couple use cases I’ve been considering, for which filters might be applicable. For example, setting a rule for an action like “when entering the Cave while holding food” would be a challenge in the current system.