Hedgerow Hall

by Hedgemistress
Hedgerow Hall
Serious role-playing-oriented game world, with animals.
ID:2076987
 
Well, it's been about a year since I'm posted anything about this game. I find that since the heyday of my BYOND participation, my game design/tinkering follows a curve that goes something like this:

1. I start making a game.
2. I run into a problem involving either the limits of the system, or the limits of my understanding of the system, or both.
3. I start a side project to explore the topic.
4. The side project spirals into a real project.
5. Repeat step 2.

Yesterday, while I was distracted by outside worries and distracting myself from them, the cycle circled all the way back around to Hedgerow Hall when I realized how a bunch of things I'd developed for RetroQuest and I Made A Dungeon and other, unnamed side projects could be put together to solve a lot of the essential design problems of Hedgerow Hall.

In preparation for resuming work, I re-read all the forum posts I made last year, and I found where I'd talked with Tom about the shift of BYOND from a simple hobby package that let someone like me (a reasonably clever dilettante, basically) bash out a game in a matter of days into a much more powerful development platform, and with Ter13 about the place of simple, retro design elements.

And in the process, I realized there's nothing stopping me from doing things the way I used to do them. BYOND's changing structure is mostly additive; it can do things like pixel movement, but it didn't lose the ability to do tile movement.

One of the things that bogged me down last year and shifted me into Step 2 of the above cycle was the difficulty of translating HrH's GMUD/GMUSH structure into something that could be navigated entirely with a relatively simple and intuitive system of keys and mouse clicks, since BYOND's native verb-accessibility architecture depends on whole tile distances.

As soon as I accepted that pixel movement is not objectively an improvement over tile movement but rather that the two things are both options that might be the right thing for a given project, I realized that tile movement is and always has been the right choice for Hedgerow Hall. The specific advantages for which I sought pixel movement (notably, the ability to have characters moving at different speeds with a high degree of gradation and without visual stutteriness) is now part of tile movement, easily implemented by using a higher FPS and dynamic glide_sizes.

So I'm back at work on Hedgerow Hall. My goal is not to make it "modern" in any purely arbitrary sense, but to improve the original game based on things that have improved in the engine, in my coding abilities, and in my grasp of game design theories.

Current Status



Since yesterday, I have made the following:

Map Generator

When the game loads, it creates an overworld map around a pre-designed hall. This generator has "hooks" where I can put other pre-designed map segments, either at set locations (for when I add other factions) or as randomly placed "set pieces" to be shuffled into the world.

The overworld "map" is actually a square array of regions that either contains an area, or a datum that contains information about the region, including base landform type and which of its edges are cleared or blocked (and blocked by what; some blockages, like trees, are more passable than others).

The game uses a simple maze-generating algorithm (the modified Prim's I developed for I Made A Dungeon) to ensure that every region in the overworld has an unblocked path to every other square on the overworld. Because it does not ensure more than one such path, there are currently a lot of dead ends, but I have plans that will fix that.

Right now all regions are "forest". When I add more types (open plains, deserts), some of them will knock down the walls in every direction around them, or between them and all coterminous regions of the same type (lakes). I'll also generate a few roads and rivers that move through the world, which will also knock down walls. Wall removal will be the only wall-state alteration that happens after the maze iteration phase.

In order to take advantage of BYOND's native pathing and distancing procedures over the relatively small scales being used, the maze is generated by using a set of placeholder turfs on a single small map. Because the maze generator is not actually creating anything except for these few turfs and simple datum structures, it runs very quickly.

The quick-and-dirty proc I wrote for populating the contents of each region when it is invoked for the first time is not very aesthetically pleasing, but I whipped it up to make sure that all required elements (rocks, trees, water, etc.) are placed in the world. As I add more landform differentiation, it will become more intelligent.

Command Parser/Control Processor

One thing I never mastered back in the day was an elegant, centralized way for parsing input from the player. Pretty much everything just went through the verb that triggered it, which meant a lot of redundancy (and bugs, and omissions) in things like event trapping and exception checking (like, "You can't do this because you're unconscious.")

The current iteration of RetroQuest I'm working on has client.mob set to an unseen "player" mob whose input is parsed to one of several "character" mobs, which required me to get with the program on making a central command processor thingy. Hedgerow Hall does not include such a feature, but I've used what I've learned to my advantage.

Movement System

One of the disadvantages of the "bash a game's base code out five seconds after you dream it up" style of development is that you don't know what the game's requirements will be, so it winds up being a tumorous agglomeration of shoehorned in additions. With the previous version of the game as a mental design doc, I know what sorts of things I'm going to need and have been able to design accordingly.

The game uses tile movement (as noted above). It supports both arrow keys and WASD movement. The normal walking pace is fairly slow, covering about two tiles a second. You can increase your speed through three successive levels (the four levels are called "stroll", "hustle", "run", and "all out run") by pressing Z (for zoom, maybe? Also, it's handy to the WASD keys) or +, with shift-z and - lowering it. Either direction can "cycle around", too.

Walking and hustling paces are steady. Things can increase (or lower) them, but as you move across the world you glide at a steady pace. The two running speeds include the possibility of bursts of speed, similar to (but smoother than!) how running worked in the old HrH.

Where old HrH required you to verb-climb something, climbing is a togglable move mode (macro'd to C). When you're in a climbing stance, trying to move into a turf that has a height characteristic triggers a climbing check; on success, you move into that square. Pixel_y is set when you're on a high turf; it's reset after you finish exiting it, which creates a nice and simple "hop down" effect. If you don't have climbing on, then you don't make the attempt. This is to make it so that skilled climbers don't have to constantly be clicking on things, but unskilled climbers aren't constantly accidentally failing to climb.

Currently, climbing is suppressed if you're moving at a run or faster; maximum climbing speed is actually a preference, but there's no front-facing interface for changing preferences. Again, this is so Zippy the Wonder-Squirrel can run up a tree, but Bobo the Blunder-Badger doesn't accidentally exhaust himself trying to climb every tree he crashes into while running through the forest.

Skill/Stat Checks

This was not a big deal to implement, but again, I have the advantage of knowing the sorts of things the game will involve.

Physical and Mental Condition

As described last year, Mind Points have been replaced by stress, which accumulates over successive failure, deprivation, or exacting activity. Stress is a percentage measurement that is easy to get rid of when you don't have much of it, but sticks around a lot longer when it's a measurable amount. When stress is over 50%, it becomes a failure chance for all skill checks.

Stamina/Endurance (I'm not sure what name I'll use for it; the fact that Stamina and Stress both start with the same sound seems like a powerful argument for and against it) is your overall physical energy, used up by physical activity. I've made the general rate of stamina burn fairly low for most tasks. The accumulation of stress and waste of breath (see below) will be used to space out activity more so than the spending of physical energy.

Breath is a short-term version of stamina. Breath is an answer to a problem that old HrH had with its "energy economy", where characters who were forced to exhaust themselves far from home were kind of out of luck, and characters who were engaged in labor would just have a cycle of burning down their Endurance Points and then sleeping. Breath, like Stamina/Endurance, is used up for physical activity, but as soon as you stop using it up, after a short delay (longer depending on how low you let your Breath get, but never very long), it starts to refill very quickly. However, if you do something that would spend Breath and you don't have any? Your character gets winded. While winded, you can't move or perform most actions, and your breath doesn't refill.

An untrained character with normal physical fitness can get winded running full-out for the length of a single map region. One with higher fitness and running skill can run for multiple map segments while their breath slowly drains, then stop briefly to catch their breath and continue on without penalty.

Happiness is a single stat that replaces the ad-hoc agglomeration of various indicators of comfort and taste that old Hedgerow Hall used to modify your recovery rates. Eating good food, sleeping in comfortable places, etc., will all increase your happiness, while doing unpleasant things will lower it. Right now happiness is coded in but nothing interacts with it.

SCROUNGING!

I'm particularly pleased with how I've worked this one, as I think it captures the spirit of the original version while not relying quite so much on a lot of verb-expansion.

Scrounging for supplies, like climbing or running, is a toggle mode. When you are scrounging, your speed is slowed and each step you take generates a scrounge attempt. (Added bonus: scrounging is now represented by someone slowly moving back and forth or all around the region, rather than standing stock still!) There's no text spam for the attempt. I would eventually like to add visual representation for scrounging, but Glitz is Not Gameplay.

You can also specify what you're looking for, which can be a category (available top-level categories so far are food, materials, and minerals; sub-categories work, too, as you can search for fruits or vegetables) or specific item. If you are not skilled in scrounging, all this does is filter your results; if a successful scrounge would have given you leaves when you're looking for berries, you just don't get anything. If you have scrounging skill, then the weighting of everything you're not looking for goes down.

As I'm talking about this, it occurs to me that I might add an alias like "valuables" that filters everything but rare items.

When I add other harvesting skills like herbalism, they will work with the scrounging system.

Scrounging uses a little endurance, but mostly it generates stress on failures, and even skilled scroungers fail more often than they succeed, requiring you to pace yourself.

Because each map region has its own area, "resource depletion" will function at a per-map-region level, though it is not yet present.

Mmmmm parsers tho :D
Yessss (to all of that)
\o/
Wow. I come back to BYOND after a long break to see this? I am thoroughly satisfied.