RPG Postmortem

Ran Numenera today. It went reasonably well, got through about half the material I had prepared. Relevant bits in context for SRPG:

1. Players Enjoy Grounded Weirdness

AKA the PEGW principle. No, that acronym is not going to become a thing. Numenera is all about The Weird. The random, the unexplained, the mysterious. If overused, this becomes pure randomness, insignificant and inconsequent. It’s not very interesting and it’s not very fun. Weird needs to connect back to the mechanical constraints of the game universe. Giving the player a device that flips gravity at will is fine so long as the idea of variable gravity constraints is accepted in the universe. You can only push boundaries if the boundaries exist in the first place.

2. Don’t Save the Good Stuff

Roleplayers have a propensity for avoiding prepared content in favor of random, unpredictable actions. Players will ignore good content, focus on insignificant details, and generally follow the worst possible paths through any scenario you have in mind. It’s easy to blame others for this. In reality, it’s your fault. Your scenario needs to be compelling enough to drive the players forward. Don’t give irrelevant details or focus on inconsequential details. Lead with your best materials, and if that’s not enough to capture the attention of your audience, take note.

3. Honestly didn’t think this post would reach a third item.

Challenge Types

I feel the need to classify the challenges in SRPG a bit. I don’t want to wear out the player with too much mechanical repetition (e.g. 5 fetch quests in a row). I use the term ‘challenge’ as a broad container for all manner of Quests and Puzzles. They can have some overlap, of course.

Types of Challenges:

  • Task: the most straightforward type of challenge. The player is presented with some kind of objective, like collecting all the litter in the forest. There’s no puzzle to solve, and the mechanical complexity is minimal. There’s nothing to ‘figure out’. Task-type quests are used to track progress rather than measure skill.

  • Guess the Verb: this one comes from a common text adventure trope, where the challenge is figuring out not what to do, or even how to do it, but exactly what command the game will accept ti achieve the desired goal. I don’t want SRPG to have any of these, with the possible exception of some kind of optional meta-quest.

  • What to Do: I need a better name for this. It’s not quite a puzzle. A What to Do is a challenge where the objective is clear, but the player may not immediately know how to get there. The answer usually becomes obvious once the player has all the necessary information, requiring few logical leaps. For example, spotting a key hanging from a high branch out of reach, then discovering a chainsaw in a nearby toolshed. This is a slightly more involved version of the Task type.

  • Mechanical: the first type I consider a puzzle. Like a What to Do challenge, the end goal may be obvious (getting through a door which can only be opened by pressing two buttons in different rooms simultaneously), and the relevant mechanics may be understood (using a time machine to summon clones of yourself who perform a limited number of actions before disappearing), but there’s a bit of thought required to determine the appropriate sequence of steps (summon clone A two turns ago, walk west, press button, summon clone B three turns ago, walk east, walk east, press button, walk north). Mechanical puzzles should have a short iteration time (to avoid lengthy, frustrating trial and error) and allow the player to experiment with the relevant mechanics.

  • Mindbender: to be used sparingly in mandatory quests, these puzzles require some degree of lateral/creative thinking. While most of the puzzles in the game will be mechanical in nature, many of them will have alternative solutions for players who think outside the box.

  • Timed: again, to be used sparingly. Timed challenges in text adventures (in my experience) are rarely fun, especially when the player fails and has to repeat them.

Fetch Quest

One of the many tangential ideas I have for SRPG is the Infinite Side Quest. It’s not really infinite, but the idea is an absurdly overcomplicated fetch quest. That is, you need the key bo the bathroom, but before you can get the key you need to do a favor for the custodian, but before you can do that you need to acquire the macguffin, and so on and so forth.

SRPG will have at least one game-spanning quest, the reward for which is likely to be insignificant relative to the effort involved. That said, I’d like it to be a badge of honor for anyone stubborn enough to stick it out to the end.

Time permitting, I’d like to make the ISQ truly infinite, and rank players based on how far they get.

Component Removal

One of the tricky issues I’m sorting out right now is how to handle removing a Component from an Entity. When a component is added to an entity, its values are merged into the entity’s grab-bag type collection of attributes, and the component can perform initialization tasks. Certain components overlap in terms of which attributes they modify, so the process of removing a component isn’t straightforward.

The specific case I have in mind is a Part entity (that is, an object that is part of something else), which is pretty simple to clean up manually if need be (it adds some TAKE checks and not much else), but there are almost certainly more complex use cases.

Given that not all components need to be removable, the most straightforward approach may be to define an (optional) onRemove function at the Component level, and let each component decide how to handle its own removal. No refactoring required for components that don’t need to support the new behavior.

Weekly Update #12

Chipping away this week when I have time away from work (which I don’t).

Changelog:

  • Stubbed in the Twins
  • Added a description for when the player is inside the hot springs
  • Added a dialogue option for the Rainbow Sword
  • Stubbed out areas and items for Act I.
  • Stubbed out some areas and items for Act II.
  • Stubbed out more Act II content.
  • Stubbed out some Act III content.
  • Refactored verb handling to allow for preprocessing of important data (prior to the ‘before’ rules executing). In particular, this means I can canonicalize movement directions before movement rules are executed.
  • Moved ‘isOpen’, ‘onOpen’, and ‘onClose’ to Openable component.
  • Fleshed out Door component.
  • Added door to Hot Spring location.
  • Added rule for movement through doors.
  • Identified cause of out-of-order printing. Will take some work to fix, as it’s a fundamental issue with how text was previously output. Need to reorganized output mechanisms into current Rule structure, or allow Rules to force prepending (immediate output).
  • Refactored output to include a Deferred Output queue. It’s a bit clunky right now, but it lets me catch/trap queued output from verb handlers during NLP processing.
  • Fixed implicit action response timing (displays before action response now).

Known Issues:

  • Nothing new

Next Up:

  • Add more doors.
  • Add hot springs puzzle.

Daily Update 276.2015

Changes:

  • Refactored output to include a Deferred Output queue. It’s a bit clunky right now, but it lets me catch/trap queued output from verb handlers during NLP processing.
  • Fixed implicit action response timing (displays before action response now).

Bugs & Problems:

  • Would like to find a more elegant solution for output ordering. Possibly incorporate the output queue into the ECS to give it more structure.
  • Need to test refactoring thoroughly. Everything seems to be functioning right now but there may be weird edge cases.

Daily Update 275.2015

Changes:

  • Identified cause of out-of-order printing. Will take some work to fix, as it’s a fundamental issue with how text was previously output. Need to reorganized output mechanisms into current Rule structure, or allow Rules to force prepending (immediate output).

Bugs & Problems:

  • Nothing new