Data Adventure by Post Test 2 - I Can Do It in 2! - Signup Thread

[nightblitz42]

RP Facility Draft 2
You can use this thread as a signup thread.

Scenario - "I Can Do It in 2!"
You are a Pokemon. Your Trainer left you home alone for the day to go to work, or school, or wherever it is humans go for the day. Since they've been feeling down lately, you want to surprise your Trainer by doing one of their chores for them while they’re gone. You've never done it before (nor have you been taught how to) but it shouldn't be that hard, right?

You're a Pokemon. You know 2 moves. Their relevance is dubious, and some might be destructive or dangerous. Success is unlikely. We can only pray that in your earnestness, you keep collateral damage to a minimum.

Design Goals

Response I collected to the previous playtest design was mostly negative. I think I tried to introduce too many new things at once, too many mechanics intertwined and co-dependent, and as a result it's very difficult for me to identify which exact parts of that design were problematic. For this playtest, I'm taking things way, way simpler and giving a more traditional RPG-like experience.

Think of this as, me marking a sketch and guidelines at the start of a drawing. At this stage, the feedback will be most important. Please give this a shot -- it's intended to be as approachable as possible. Particularly: with the Judge side, I think there are transferable skills you can hone from playing which you will be hard-pressed to find a lower-stakes opportunity to practice.

Rules:
This is a 2-player storytelling game.

The players take different roles in the game: a Quester and a Judge.
The Quester’s job is to play the role of the Pokemon, as laid out by the Scenario.
The Judge’s job is to decide the results of the Quester’s actions. They also create and control non-player game elements and characters.

There is no winner in this game, unless the Judge decides there is one.

Game Flow: Signup
The Judge posts a challenge. They may choose to specify the Goal and/or Setting, or they may let the Quester decide.

The Quester accepts the challenge by posting their Pokemon, background info, and 2 moves (plus the Goal/Setting, if left unspecified by the Judge).

Game Flow: Match
The Judge creates the thread.

*** Gameplay loop ***
The Judge establishes the scene.
The Quester attempts 1 of their 2 moves.
The Judge decides the result of the attempted move, then advances the Chaos Clock if necessary.
Repeat from the top until the Chaos Clock reaches 4.
*** End loop ***

*** End Game ***
Once the Chaos Clock reaches 4, the Trainer arrives at the scene. The Quester then chooses 1 of 2 ways to end the game:
. As the Trainer, in 3 words or fewer, describe how you attempt to fix all the problems your Pokemon caused thus far. The Judge decides the result of your attempt, and then the game ends.
. Skip ahead to the future. Describe how the setting has changed so that your Pokemon is able to achieve their goal without any of the problems you encountered this game.


Quester's Guide
Quester’s Mechanical Guide
Each turn, pick exactly 1 move to use.
You may additionally Aim towards something – meaning, you intend to shift your focus to it next turn after you use your move.
Always phrase your actions as attempts to do something: “I try to X,” etc.

If you end up in a situation where neither of your moves help you, don’t freeze up or overthink – just pick the one that sounds more interesting or reasonable at the moment, and move on.
You’re not expected to succeed, nor do you stand to gain anything from winning, so just take it loose and easy.

Quester’s Writing Guide
During signup, give your Pokemon 2 moves that contrast one another in as many ways as possible.

If one is an attack, maybe the other is a non-combat action? One is subtle, the other is extreme? One is pretty, the other is ugly? etc.​

Specific moves are more fun than vague ones.

(Instead of “Talk,” which is very general, try something more specific and evocative, like: Beg, Threaten, Flirt, Whisper, Lie, Joke, Flatter, etc…)​

Your character isn’t a robot or a game piece! They should have limits to what they are willing to do in pursuit of their goal. Keep this in mind when coming up with your Pokemon, and also when playing them.
Each turn, act out how your character might react to the situation. Make sure to consider how they would feel about things.
Whatever their personality, the game works best if your character has a big heart.

Judge's Guide
Judge’s Mechanical Guide
Your main job is to figure out the outcomes of the Quester’s moves.

If the outcome of the Quester’s attempted action is obvious, you may apply that outcome. Otherwise, you will use the Judgment Chart (provided at the bottom of this post).
Either way, if the result of the Quester's action caused an increase in chaos, advance the Chaos Clock by 1. (starts at 0, max. 4.) Once it reaches 4, the game ends.

Judgment: Whenever you need the answer to something non-obvious (for example: the Quester attempts an action that could either succeed or fail, or you’re not sure how an NPC reacts to something, or you just don’t know what happens next in the story), you can perform Judgment using the Judgment Chart.

Here is how to do Judgment:
. Ask yourself a question.
. Answer your question twice with the 2 most likely outcomes.
. Decide which outcome would be more chaotic.
. Decide how likely that outcome is.
. Check the corresponding row on the Judgment Chart, but shift up 1 row for each tick on the Chaos Clock.
. Roll a d100. Each cell in your row tells you the roll values less than or equal to which trigger that column’s result.

Here is an example:
The Quester’s Charizard tries to use Fire Punch on an enemy Blaziken. The Judge notes that Charizard and Blaziken are both competent, equally-skilled fighters, and neither has a clear situational advantage. So, the Judge concludes that the outcome of the move being attempted is unclear.

The Judge decides that the most likely outcome is for the Blaziken to get hit by Charizard's punch for a minor amount of damage, but probably not enough to end the fight. The Judge then decides that if that doesn’t happen, it probably means the punch got blocked and Blaziken is going to retaliate with a counterattack.

Of these two options, the more chaotic outcome would be for Charizard to get blocked and counterattacked. As for how likely that outcome is, it’s slightly unlikely. The Judge finds the "Slightly Unlikely" row on the Chaos Chart. But, the Chaos Clock is currently at 1, so the Judge shifts up 1 row to the “Even Odds” row.

Finally, the Judge rolls a d100 (1-100). Surprisingly, they roll a 4 out of 100! According to the Judgment Chart, anything under 30 is an “Exceptionally Yes” outcome – “Yes” as in, “Yes, the more chaotic outcome happens.” As for the “Exceptionally” part: what does it mean for the Blaziken to “exceptionally” block and counterattack? In this case, the Judge decides that the counterattack is exceptionally technical. Instead of striking back with an ordinary punch or kick, the Blaziken uses their opening to duck in on the Charizard and grapple him to the ground, ensnaring his arm in a twisting lock.

The Quester's Charizard is now in a much worse (more chaotic) position than they were before, and if they don't do something soon the Blaziken might seriously injure their arm. The Judge advances the Chaos Clock by 1.

Question: “As a Judge, how am I supposed to know to come up with those specific answers? That took a lot of logical jumps.”
Answer: As Judge, there is no “correct” way to apply this process. Every single step is up to your discretion. The Judge in our example decided that Blaziken blocking the punch was “slightly unlikely,” but a different Judge in the same situation might decide Charizard’s small arms make it “very likely” that the Blaziken blocks the punch. The Judge in our example decided that “Exceptionally Yes” means the Blaziken uses an exceptionally skilled technique, but a different Judge might interpret the outcome as Blaziken using an exceptionally strong block that bruises or injures the Charizard’s striking arm. When you are the Judge, you can come up with whatever answers to your questions you like, so long as the answers you come up with are the ones that make the most sense to you.

Judge’s Writing Guide
You should root for the Quester’s Pokemon even when they make bad decisions or fail.
The Quester’s actions should always have consequences. Their actions should always end up changing something in this world.
Don’t post your Judgment process, only the outcomes.
You should never have to do Judgment more than twice in a round. If it comes to that, you should try to trust yourself more instead.

The ideal would be 1 Judgment per round at most.​

Whenever you introduce something to the story (an object or character, for instance), give it meaning.

Suppose at a point in the story, the Quester’s character needs to use their home computer. As you introduce the existence of the computer, give it meaning. If it belongs to the Trainer, what does it mean to them? Is it expensive? Old? Does the data it contains have personal or emotional value?​

​

Bad or chaotic things should come in pairs. If the Quester’s action causes one bad/chaotic thing to happen, pile on a second.

Extrapolate: Not only X, but also Y.​

Intensify an ongoing problem: X, and also Y problem from earlier progresses into Z.​

​

For prodding the Quester, you have 2 moves: Present an obstacle, and Present a distraction.

Present an obstacle: You want to X, but Y is there to prevent your motion.​

Present a distraction: You want to X, and you encounter Y because of your motion.​

Because the Quester is obligated to use a move each turn, any distraction you put in front of them quickly becomes a problem by virtue of existing.

You don’t need to try to trap the Quester with a trick, or force the Quester to fail. Simply putting things in front of the Quester, then watching them fail as a natural matter of course, should suffice.

At the end of the game, if the Quester tries to defuse the situation as their Trainer: Everything the Trainer attempts in those 3 words succeeds (within reason), but every problem that they neglected to address blows up on them.
If the Quester skipped to the future, usually the Judge does not need to post anything afterwards.

Judgment Chart:
Ask the chart: Between the 2 most likely outcomes, does the more chaotic one happen?
Roll a d100 (1-100). Shift up 1 row for each tick of the Chaos Clock.
Read each cell as, "Rolled less than or equal to."

How likely is the more chaotic outcome? ↓ ↓ Does the more chaotic outcome happen? →→	Exceptionally Yes	Yes	No	Exceptionally No
+2	75	100
+1	50	100
Almost Certain	45	90	95	100
Very Likely	40	80	90	100
Slightly Likely	37	75	82	100
Even Odds	30	60	80	100
Slightly Unlikely	25	50	75	100
Very Unlikely	12	25	62	100
Almost Impossible	7	15	57	100

 

[Maxim]

Going to sign up as a Questor with Volcarona.

Incinerate
Gust

EDIT: This signup will self destruct if not taken by July 3.

 

[HydrogenHydreigon]

I'll also take a stab at Questing with Ripple the Raichu-A!

Picking moves Nuzzle and Extreme Speed

 

[Maxim]

Unfortunately I'm going to be dropping my challenge. I want to participate but this test caught me at a bad time for me to participate.

Queue:
HyHy

 

[Snarguffle]

I'm interested in giving this a try. Lance the Beedrill, reporting for duty.

Moves: Twineedle, Tailwind

Queue:
HyHy
Snarguffle

 

[nightblitz42]

A bit of design theory. This might be helpful to keep in mind for anyone playing the Judge role this playtest. But that's secondary. Mostly it's just me sharing the thoughts rattling in my head.
Feel free to respond.

I'd like to define the word, "Scope," as follows:

Suppose a player performs an action. We know that that player has a specific intention behind performing that action (otherwise, they wouldn't have done it). The scope of a player's action is everything that is touched by their intention.

"Scope": Everything a player intends for their action to affect.

To give an example: Player A's character, a young knight in well-polished armor, traverses a perilous dungeon. He carries in his right hand his steel shortsword, and in his left a lantern to light the way. As he turns a corner, he comes face-to-face with a fearsome Goblin Bandit!

For his action, Player A has his character swing his sword at the Goblin's neck.

In this example, we can assume the player's intention is to decapitate the Goblin, or at least mortally wound him. So, we could say the scope of the action encapsulates the Goblin, and the knight's sword.

Any result coming from this action that affects the Goblin or the knight's sword would be "In scope." Any result that affects anything other than the Goblin or the sword would be "Out of scope."

Some examples of In-Scope effects:

• Your sword slices the Goblin's head clean off, ending him instantly.
• The Goblin parries your attack with his rusty, bloodstained axe.
• Your sword bounces off the Goblin's plate armor. The impact severely chips your blade; you'd best take it to a blacksmith for repairs.
• The sword lodges into the Goblin's flesh, but your edge alignment is off -- not only is the hit non-lethal, but your weapon is stuck and you are unable to retract it. As the Goblin raises his spiked flail to counter-attack, you briefly weigh your options. What will you do next?
• Your sword passes right through the Goblin's body without touching, as if he were some sort of specter or illusion.
• The sword is much too heavy for someone of your size. As you move to attack, your weapon flies out of your hands and clatters against the far wall of the chamber.

Got it? In-Scope can still mean "unexpected," but the result necessarily operates within the limited context of the goblin and the sword.

Some examples of Out-of-Scope effects:

• As your sword bites into the Goblin, you feel overcome by nausea. The sight of his viscuous green blood draining down his robes rattles your head and churns your stomach.
• In a hurry to attack, you accidentally swing with the wrong hand. Instead of your sword, you thrust your lantern at the Goblin's head. He yowls with pain as his scraggly hair catches on fire.
• The two Goblin Lackeys standing behind him are cowed by your display of martial prowess. They drop their weapons and flee.
• Your adventuring companion, a sorcerer, berates your fighting style as barbaric and filthy. He explains with bombastic flair how he would have used magic to dispatch the foe.
• The next morning, a mob of Goblin-Fan-Club members with pitchforks and torches line up at your doorstep.
• You black out, and when you come to, the goblin is in twenty-six pieces scattered all over the room.
• Before your attack connects, the Goblin drops to his knees and begs for mercy. Your sword whizzes over his downturned head as he clasps his hands together in suppliance. He has a family, he explains, and a dozen children to feed. People would miss him if he's gone. He also tells you he knows the passcode for a secret treasure room, which he will share with you if you spare his life.

As you can see, Out-of-Scope effects involve elements the player might not have accounted for -- things besides the Goblin that will be acted upon by attacking him, and which will often, in turn, act back upon the player's character. They can be good, bad, or completely inconsequential.

Obviously, In-Scope effects are necessary for a game to function. Nobody would want to play a game that ignores their intentions at every turn! When the player attacks the Goblin, the first thing they will be concerned with is the in-scope result: "does the attack work?" If you don't answer that question right away, the player probably won't be concerned with whatever else you have to say. Therefore, as a general rule, every action must receive an immediate In-Scope result (this could include "it fails/accomplishes nothing") before considering Out-of-Scope results.

At the same time, if you only have In-Scope effects, what you're playing isn't really a Tabletop game. It's a strategy game, or a tactics game. Come to think of it, BBP is played entirely In-Scope (if you know what you're doing) (that is to say, spamming Earthquake won't cause the stadium's roof to unexpectedly collapse). Then, what we're looking for in a TTRPG design necessarily lies in the Out-of-Scope. The Out-of-Scope is what makes a game a TTRPG.

So ideally you want a healthy mix of In-Scope and Out-of-Scope effects. The problem is, Out-of-Scope effects, by definition, cannot be completely codified by a ruleset. If you have rules that perfectly codify, for example, how your NPC adventuring partner will react to any situation, then the player can predict that and weigh it into their decision-making process. And once that decision-making sequence becomes deliberate, it is no longer Out-of-Scope -- it becomes In-Scope, and therefore loses a good chunk of its power within the design space. To combat that shift is where the human element comes into play.

There must be a human in the loop interpreting the results of actions in order for true Out-of-Scope results to happen. If the player interpreting the results is the same player performing the action, then either the method of choosing actions or the method of deciding results needs to be substantially outside of that player's control, because with complete 1-player control actions cannot have Out-of-Scope outcomes.

Why is this a problem?

We've established that:

1. A human must interpret the results of actions, and:
2. interpreting the results of one's own actions requires the game system to take some measure of control away from that player.

The conclusion is if the interpreting player does not assume a very, very deliberately proactive mindset towards interpreting; then the process of deciding outcomes (which is vital to any TTRPG game design) will feel very passive. This will either be because: one player is evaluating the other player's actions, which appears to frame their relationship as active/reactive (despite the reality); or, the self-evaluating player must sacrifice mechanical control in some way (which can lead to interesting games, but makes it difficult for a player to pursue any specific fantasy they might have in mind).

 

[nightblitz42]

Perhaps aiming to make a "self-sustaining terrarium" of a Facility is a dead end. I'll have to step up and participate in whatever roles are needed, continuously.

Which, I'm all for that, so long as I'm not hogging the spot (which I have no reason to believe is the case).

Taking HydrogenHydreigon and Snarguffle.

Queue:
(empty)

 

[nightblitz42]

< Previous: Defining Scope

What is a TTRPG?

Having defined "Scope," I will now take a step backwards and define what I consider a TTRPG to be, from a design standpoint.

(Exact naming is nebulous. "TTRPG" vs "Storytelling Game" vs "Narrative Game" is a distinction that means 100 different things to 100 different people. When I use these or similar terms, I do so interchangeably; the main takeaway is that they are games whose primary goal is to create a story as a byproduct of gameplay. I usually prefer to write "TTRPG" because it's easy to type.)​

As I define it, a TTRPG's design must do 3 things cyclically:

1. Intake: Receive player input.
2. Processing: Generate In-Scope effects.
3. Interpretation: Generate Out-of-Scope effects (sometimes).

The cycle stops and the game ends if/when the game's narrative premise is irreversibly undermined.

(Suppose there exists a superhero-themed game. The game's sales pitch might be, "A player controls a superhero character, who tries to take down a supervillian while keeping their hero-life a secret from their civilian-life love interest." In that case, the narrative premise has 3 parts:​

> The character is a superhero.​

> The character opposes a supervillain.​

> The character keeps their superhero identity a secret from their love interest.​

If we accept that as the premise, then over the course of the game, if any of these statements becomes irreversibly false, we should expect the game to end then or shortly after.)​

A TTRPG's appeal comes from the emotion of surprise. Surprise is attained through lack of control: meaning, no individual player should have complete control of all 3 design steps at any given time. Of course, each step is a essential and non-negotiable part of the game design. Therefore, if the designer wishes to take away a player's control over a certain step, they must reassign that stolen agency to a different player, or to the game system, because it must get done.

Designing a TTRPG is deciding how much control over each of the 3 steps to assign to each player, and to the game system.

 

[nightblitz42]

< Previous: What is a TTRPG?

Design Concepts in Practice - A Practical Example: "I Can Do It in 2!"

My writing thus far has been highly abstract. In order to provide grounding for the ideas discussed, let's give a concrete example of a design process from start to finish.

Our illustrative example in this case will be this thread's prompt: "I Can Do It in 2!".

(We're getting into the kind of design territory that I typically do not discuss with others. There are two reasons: firstly, I feel that if I share my early ideas but later scrap them without actuating them, then the abandoned ideas linger in the air like ghosts, forever haunting my final product with the tantalizing fantasy of "what could have been." Oversharing undermines the final design's capacity to stand on its own, to be judged by its own merits.

I also see oversharing as unduly self-congratulatory.

Yet, when I was talking with someone about the unexpected difficulty I've been having with this project, they suggested trying to collaborate with others; which, of course, means sharing more (skills and information) with others.)

The process began, as any should, with a brainstorming session. Following the dreadful reception to Playtest 1, I gathered feedback. One of the (many) takeaways I gathered from feedback was that the playtest "did not feel enough like an adventure."

Adventure. That was the word I fixated on. Unable to squarely define it, I brainstormed as many answers as possible to the question of, "What is an adventure?".

Brainstorming

A brainstorm is a period of time during which you assume that every answer that pops into your head is correct, write it down, and quickly think of another answer.
An adventure is:

• A journey.
• A process of discovering that one of your assumptions about the world's rules is wrong.
• Anything dangerous.
• A setup to get the main character to do their Cool Thing(tm).
• Crossing a point of no return.
• Overcoming impossible (literal) adversity.
• Doing something that improves the world for others.

Curation

Once the brainstorming session ends, you realize that some answers are, in fact, more useful than others.

I investigated a few answers somewhat in-depth, but the one that compelled me the most was, "A setup to get the main character to do their Cool Thing (tm)."

What I mean by that answer is: in media like Sentai shows or combat-action anime, the main character often has a flashy Signature Move that the audience looks forward to seeing every episode. In fact, the point where that happens is usually the climax of the story. If we work backwards from that, we can interpret a story as a "setup" to arrange a situation where the character can do their big flashy move for maximum effect.

To some extent, I think that aligns with how players engage with TTRPGs. For instance, suppose a player designs their character to be a sneaky Thief with lockpicking and pickpocketing skills. They do so because they expect to be able to use their thievery skills, right? In other words, they designed the character with certain specific actions in mind, and they want an opportunity to perform those specific actions during the game.

With that as a basis, I decided that the design goal of the next playtest would be:
Let the player character Do Their Character's Thing(tm) quickly and efficiently.

(As you've been reading this you might think, "Wow! This guy sounds really darn cynicalI!" But I assure you, that's not my attitude at all. I'm being earnest. The hypothesis I started with was, "An adventure is defined as an opportunity to do a flashy thing." If that's true, then the inverse is also true: a design that lets the player do flashy things is necessarily going to feel like an adventure. The stated design goal is a means to an end: the end being, giving the player a satisfying adventure.)

Designing For the Design Goal

Step 1: Intake. How should player actions be issued?
Well, the point is for the player's character to Do the Thing(tm), so a command to Do the Thing(tm) should be an allowed input. In theory, that's enough to fulfil the design goal, but a player who chooses from only 1 option isn't participating in a meaningful sense... So, we'll give the player 2 allowed actions to choose from instead of just 1. That way, they have a decision to make each turn.

Step 2: Processing. Once the player chooses an action, how do we determine its In-Scope Effects?
Whatever happens, it needs to be exciting! We want the player to feel that they really Did Something by Doing the Thing(tm)! To accomplish that, we'll heavily skew the game's mechanisms for determining In-Scope Effects towards chaotic outcomes.

(In the rules post at the top of this thread, there's a probability table for determining the outcomes of uncertain events. If you study the table even briefly, you'll notice the odds are way off. In situations where two oucomes should be equally likely, the more chaotic outcome actually has a 60% chance of happening! The odds go up even further as the game progresses.)

Step 3: Interpretation. How do we determine Out-of-Scope Effects?
We need to continuously give the player reasons to Do the Thing(tm) over the course of the game. So, we'll stipulate that every chaotic In-Scope event is acompanied by a chaotic Out-of-Scope event. This will cause the number of crazy things happening to quickly exceed the player's capacity to deal with all of them, ensuring that the player never runs out of reasons to Do the Thing(tm).

(As we've already discussed, one player cannot be completely in control of all 3 steps. Also, it's very difficult to arrange for the acting player to also come up with out-of-scope effects. The most obvious solution is to stipulate that a different player from the one issuing actions must be in charge of Interpretation. While they're at it, the Interpreting player might as well also handle the Processing.)

As for the setting... an overarching mood of "Chaos" has emerged in our design, and as a result there's going to be a high degree of collateral damage over the course of the game, so we need a setting that performs a couple functions:

1. Starts off in a stable/orderly state, so that the ensuing Chaos stands out.
2. Is low-stakes enough that causing mayhem inside it won't be that big a deal, but still carries enough significance that we should care if it gets trashed.

One's own home fulfils both requirements. Houses are often seen as a symbol of stability and sovereignity, and the house naturally contains whatever happens inside it, inside it.

Once we've decided that, it follows that we must answer the question of, "why is a Pokemon acting up inside the house," which is answered by, "The Trainer isn't there to control them, and they're trying to do something that's beyond their capacity."

That naturally gives us our narrative premise:

1. The Pokemon is home without their Trainer to oversee them.
2. The Pokemon wants to do something that's beyond their capacity.
3. The Pokemon Does the Thing(tm) continuously in an attempt to reach their goal.

On demand, we can end the game by undermining any part of the premise: most obviously, by making the Trainer return.

That concludes the illustrative example. This was a design for a simple playtest, so the process was kind of basic. Most design projects will have multiple design goals instead of just 1, so the process becomes a bit more complex, but the thinking remains the same. As long as you know what basic steps your system needs to perform, and what goal those steps serve, you can craft the specifics of each step in service of that goal.

 

[nightblitz42]

Tree's Battle Design Philosophy

This is not a part of my ongoing series on TTRPG design. If you're only here to read TTRPG-related stuff, you can skip this.
The scope of this post is entirely about the battling aspect of the discontinued version of Battle Tree.

Someone in the Discord sent me a question/suggestion about old Tree design. Essentially, they said, "since getting Tree refs was so difficult, why not reduce the length of the challenge to 1 battle instead of 3?" I tabled the topic so that I could discuss other things at that moment. That means I still owe them an answer. So, as much of a downer as it is to discuss old Tree, let's get to it.

Tree featured battles against randomly generated opponents. This meant there was a high degree of variance. On a battle-by-battle basis, it was entirely possible for the challenger to get counter-teamed and beaten into the ground through no fault of their own. (Case in point: Epicdrill rolled Mega Scizor (which hard-countered his team) as an opponent in the Final Boss Team 4 times in a row.)

(The odds of any individual Boss Team having Mega Scizor were 5%, so the odds of that happening 4 times in a row were .000625%. Multiple different refs were involved across the 4 battles (including myself who reffed the fourth), so that rules out the possibility of cheating. As a designer, seeing something like that happen in your game mode, there's really nothing you can do but throw up your hands in resignation?? There are possible design adjustments you can make, such as not allowing the same Pokemon to show up in a Boss Team for two consecutive challenges, but the odds of the scenario you'd be trying to prevent are so miniscule that the added labor and rules complication objectively aren't worth implementing.)

Guaranteeing 3 battles per run was a policy put in place to counteract the variance of randomly generated enemies. It used to be that if you lost 1 battle the challenge ended there, but that frustrated battlers. So it was changed to 3, but that made challenges take really long. If I were to take away the random generation while also reducing the number of battles, the Facility would become indistinct from Realgam. The more I worked on the Facility, the more this problem -- and other problems with Tree -- became apparently impossible to resolve. I think the emergence of these no-win design problems was a result of having too many conflicting design goals.

Tree needed to be:

• Skill-based and challenging, so that it could justify giving completion rewards
• Consistently fair/beatable, so that challengers could justify spending their time/effort/JC here and not feel "cheated" when they lose
• Randomized, so that it has replay value and can't be [counter-teamed/scripted out] by challengers

• About equally as fun to challenge and ref, so that the queue doesn't pile up with too many of one or the other
• Made so that the ref's skill doesn't have a huge effect upon each match's outcome, otherwise challengers will avoid strong refs
• Made with the expectation that the ref fights hard, so that the challenger has an obstacle to overcome
• Made with the expectation that the ref isn't under a lot of pressure
• Made so that the ref doesn't have to work super hard/track a lot of things compared to other Facilities which pay their refs roughly as much

• Simple and understandable, so that beginners can use the Facility to progress
• Complex, so that players can learn its mechanics and grow in skill across multiple attempts
• Unique, so that it stands apart from other Facilities like Realgam or Pike
• Like BBP, so that players with a lot of experience don't feel like they have to re-learn a new system as a hurdle to advancing their Pokemon

You might think I can "just compromise," and find a middle ground between these design goals, but there's enough BBP here (on the forum) that players don't need to compromise by playing/reffing Tree. They can just choose to go to a different Facility with a more focused and less compromising design. Anyone could see that decision in action by looking at Tree's play rate (or more precisely, its reffing rate).

I did the best I could, but eventually I reached a point where there wasn't any adjustment I could make that wouldn't mess up a different design goal in some other way. So, it's natural that I'd want to start from scratch.

As I've expressed elsewhere, I am adverse to re-introducing standard BBP battles into ABP. My concern is that that doing so would unavoidably "smuggle" a lot of these old design goals back into the system, which would cause the same contradictions that led to my decision to scrap Tree in the first place.

 

[Snarguffle]

I have a number of things to say in response.

Firstly, I think that most of these design goals are going to be along for the ride no matter what kind of facility you're designing. The only exception I can think of would be if the intent is for the facility not to reward anything, in which case: I regret to inform you that no one will play it. BBP's slow progression leaves essentially no room for any content that doesn't provide adequate rewards.

That said, I think a couple should be discarded from the outset:

• Made so that the ref's skill doesn't have a huge effect upon each match's outcome, otherwise challengers will avoid strong refs

No facility in BBP makes any effort to design around this. Players aren't (as far as I know) able to reject refs, so it is a non-issue.

• Complex, so that players can learn its mechanics and grow in skill across multiple attempts

I don't think it's necessary to strive for complexity. At the present moment, BBP facilites are, as a whole, far too complex for their own good. I think there's an adequate niche for something simpler.

With those out of the way, the only remaining criterion that doesn't necessarily need consideration is the randomization aspect. All the others are characteristics that any facility will need to possess at baseline. Including BBP battles would automatically fulfill 2 of them: The need for a skill-based challenge, and the need for similarity to BBP. The latter criterion shouldn't be discounted; It provides an anchor point for players to understand the rest of the facility, and appeal for players that enjoy battling (which should be most of them, given it's the focus of BBP as a whole).

From there, the next most logical place to go is uniqueness: how can one make the facility stand out from the others? The obvious characteristic that stands out is the RP; while other facilities allow RP, it is a core part of this facility's design, which will automatically lend it a level of uniqueness regardless of how it is designed. If more uniqueness is needed, it should be obtained by further focusing on this aspect, rather than anywhere else.

The next set of criteria concern effort: The need for it to be accessible to beginners, and the need for it not to be too difficult or time-consuming for refs. This is best accomplished by making the mechanics as lightweight as possible, and by keeping the length of the challenge from becoming too bloated. BBP battles help somewhat in terms of simplicity, providing a system players are already familiar with rather than having them learn an entirely new system for battle resolution. Of course, it would be necessary to avoid complicating them with unnecessary mechanics (such as the fiddly customization system from Tree). It does also add a certain amount of length to the challenge, but not necessarily more than it would take to RP a battle using some other system.

Now, if battles are included, it may still be correct to randomize opponents. This naturally conflicts with the need for the challenge to be consistently fair and beatable. However, there are a couple ways to balance the two concerns:

• Create a set of criteria that filter out unfair opponents. For example: rerolling opponents that have a strict type advantage over the player's pokemon.
• Allow the player some degree of control over the randomness. For example: choosing from a number of randomly selected opponents.

Depending on how these mechanics are designed, they can also be used to tie together the RP and battle segments more tightly, addressing another concern with Tree that the RP didn't matter enough. As for the remaining criteria, they are not worth calling out individually; they should naturally be fulfilled as a consequence of the fulfilling the others.

Overall, while I understand the desire to start fresh after the death of Tree, I do think the new facility could suffer if it goes in too radically different of a direction. Players are, broadly speaking, here to play BBP. While non-BBP distractions have some place, they ultimately will most likely end up playing second fiddle to BBP content, similar to the current state of Contests.