Stacktors Moot

From IcehouseOrg
Jump to: navigation, search

This page contains all moot discussions for Stacktors!, as an archive of development thoughts. Only Talk that is still current will remain on the Talk:Stacktors! page.

Regarding Game Name

OT for sure- but Stackabilities sounds like a good name for the rpg, if not for the RPG, then a completely different Icehouse game.--Tuxhedoh 18:37, 5 Mar 2007 (GMT)

  • I concur--though I am also partial to some GURP-like anagram, given its generic nature. Maybe GRIPS: Generic Roleplaying Icehouse Piece System (role-playing can be unhyphenated, being a ubiquitous term and no longer an "innovative concatenation" or whatever they call coined hyphenated phrases). --David Artman 18:45, 5 Mar 2007 (GMT)
    • I always enjoy recursive acronyms: Pyramid: Your Roleplaying And Monster Immolation Diversion Krisjohn 03:18, 7 Mar 2007 (GMT)

OK, it looks like GUTS is going to win out, for the name, if we can figure out a good acronym. "Generic Universal Treehouse System" is the obvious choice, but it's misleading: RPG is not "universal," in any current usage of the term, and there's no mention of roleplaying or adventure or anything else to designate RPG from the host of other pyramid miniatures games. I would also consider "Brains, Guts, & Feet" which folks would very soon just call "BGF." Doesn't evoke a sense of a roleplaying or adventure game, though. --David Artman 16:30, 23 Mar 2007 (GMT)


AND... the name is finalized: Stacktors! - Roleplaying with Pyramids. It came to me during a smoke break at work, like a pun from the blue! --David Artman 18:16, 28 Mar 2007 (GMT)

Regarding Ability Table

If the "size matters" element gets in, here is an initial table template which has sub-rows for size:

Character Stack Abilities By Position And Size
Color Grounder Guts Topper
Clear S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Red S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Orange S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Yellow S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Green S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Cyan S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Blue S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Purple S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
White S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]
Black S: [TBD] S: [TBD] S: [TBD]
M: [TBD] M: [TBD] M: [TBD]
L: [TBD] L: [TBD] L: [TBD]

Fred Poutre writes....

Regarding Dice

Well, as for pips to dice, I would suggest pip = number of dice, or number of sides per die.

  • 0 pip (no skills) 1D4
  • 1 pip 2D4, or 1D6
  • 2 pip 3D4, or 1D8
  • 3 pip 4D4, or 1D10

Stacks Redefined

Stacks of 8:

  • Two Bottom = Movement (Grounder)
  • Next Two up from Two Bottom = Combat (Lower Guts)
  • Next Two down from Two Topmost = Social (Upper Guts)
  • Two Topmost = Mental (Topper)

Skills

Here is a brief list of skills ideas.

I did not consider powers (magic psychic, psionics, supper powers, cybernetic implants et all). so, it might require one more category (unless you just split the powers into the other skill categories).

Movement (Grounder)

Pilot Ground Vehicle, Pilot Water Vehicle, Pilot Air Vehicle, Pilot Animal

  • Clear :
  • Red : Walk/Run
  • Orange : Climb
  • Yellow : Jump/Leap
  • Green : Wood Walk (clogged Move- normal speed (1/2 speed)
  • Cyan : Fly (air Move- normal speed (0 speed)
  • Blue : Swim (water Move- normal speed (1/4 speed)
  • Purple : Teleport (any Move- normal speed)
  • White : Ice Walk (water Move- normal speed (1/3 speed)
  • Gray : Tunneling (solid Move- 1/2 speed (0 speed)
  • Black : Space Travel (water Move- normal speed (0 speed, & Dead)

Combat (Lower Guts)

  • Clear : Camouflage Defense
  • Red : Distance Attack
  • Orange : Melee Weapon Attack
  • Yellow : Hand-to-Hand Attack
  • Green : Poison/Toxin Disease Defense
  • Cyan : Armor Defense
  • Blue : Dodge Defense
  • Purple : Magic/Psychic Power Defense
  • White : Block/Parry Defense
  • Gray : Mental Attack
  • Black : Mental Defense

Social (Upper Guts)

Bard Skills, Diplomat Skills, Psychology, Culture/Law, Camouflage/Disguise, Hide/Sneak, Animal Ken, Assess/Appraising, Strategy, Games ...

Mental (Topper)

Awareness, Thief Skills, Survival, Geography, Language, Hard Sciences, Biology/Ecology, Engineering, Medical, Construction, Weird Science ...

David Artman replies...

More Dice

Adding more dice into the mix is, I feel, going away from the core design. We are thinking something closer to Amber, for resolution systems. In fact, I am close to removing dice from the game entirely. The current conflict rules, for instance, allow for several pyramids to apply in an action (with only one "active," to indicate whatever special nature the attack has). Thus, one might get a large pip value for the attack and, thus, possibly equally large defensive value. That would make a d4 insignificant; and make it rather hard to figure what die is interesting without being overwhelming.

Skills Breakdown

While I kind of like the 8-piece stack, I don't feel that's flexible enough. Why would every character have social skills, for instance? I prefer more flexibility in character creation.

Why indeed would every character have social skills. :-) - misuba 22:10, 7 Mar 2007 (GMT)

That said, I have been wondering how to get more social and mental skills into the mix. Mind you, the direction I am leaning now does not use quite as "firm" definitions for them as Fred's--I prefer to keep a slight layer of abstraction. So, for example, rather than a laundry list of mental skills, I would favor "Knowledge" or "Technology" or more general abilities. Or, really, actual effects and not "mere" skills. In other words, if it doesn't target something (including oneself) then it's not appropriate to the current concepts.

Check out the current color chart and Actions rules, and you should be able to see what I mean.

misuba asks:

What are the design goals here? I don't mean what you want the headings on the rule sheet to be, I mean what you want the game to feel like when you play it, why you are designing it, what you feel it'll get the average player over existing generic RP systems.

David replies...

Good questions, all--they even sound familiar. ;)

So I'll admit this is not a universal role playing game--I don't think that could be done with mere stacking (though with all sorts of pointing and over-under relationships, it might have enough "slots"--Universalis meets Zendo, basically).

So I suppose what I am really trying to make, here, is your classic crawl system: dungeon, haunted house, space dock, whatever. That's the "generic" part. As for what it would offer that other systems don't? Well, no other systems use pyramids for stats and resolution, right? OK, OK, cheap answer.

Frankly, I am becoming stumped, the more I think about it and about how limited it is in its current state. I got nothing for traps or locks or strange gnomish engineering, I got one form of ranged attack (the fact one can do ranged; big deal), I got a handful of "interesting" effects beyond just damage... and I got a TON of ways to maneuver. Just looking at what's on the Main Page, I am making--at best--a gladiator-style game or fighting game. There's little more going on under the hood than in HeroClix/MageKnight. Not a bad little one-off tactical combat game, perhaps... but not what I wanted at all. No room for role playing at all. Or, rather, no more room than any miniature game allows--which is a lot, but none of it is ever "mechanically backed," so to speak, just folks acting out as they maneuver their minis.

Something significant has to change, to open up more challenge types and to provide more character "classes" or modes of play. I want front-line, ranged, and sneaky combatants. I want martial and social challenges (logic puzzles and the like should be left to the players' skill, not a mechanic, in my opinion). I want niche-protection for individual characters. I want "magic" or "psionics" or some special class of ability that fills in the gaps not covered by typical combined arms abilities.

  • Still need sneaky!!! --David Artman 21:52, 19 Mar 2007 (GMT)
    • And, the chart is full... sneaky will have to be abstracted, as a "special effect" of some combination of abilities. --David Artman 20:07, 21 Mar 2007 (GMT)

But the current basic design element (stacking, three significant positions) only affords 33 slots for ALL that. And, really, it should only be 30--gray shouldn't be requisite, as only Rabbits can buy them. 30 slots to allow for five general modes--aggressive and defensive melee, ranged abilities, knowledge and mechanical skills, social abilities, and support functions (i.e. heal, controlling magic, etc). That's six color/position slots per major mode of play: not very dynamic.

But maybe there's a way to inflate that range of options, like Fred suggested. He created a fourth significant position in the stack (separated guts into upper and lower) and thereby opened up 10 more slots for effects. And I too-quickly objected to the seemingly static nature of EVERY character ONLY having two pieces per position. But maybe that's a start.

Hmmm... but then again, we DO have a means to put an entire axis of effects at angles to the three current positions: piece size. Until now, I have only considered piece size as the means for comparison for who wins. But suppose we toss that out in favor of some other resolution system (see below), and make SIZE MATTER. Now, instead of 30 slots, I get 90--three positions * three sizes * ten colors! And those six color/position slots per major mode of play, instead, now have eighteen available slot effects. And they needn't just be scaling: a small orange gut needn't be a "weaker" version of a medium or large orange gut; it could be a totally different ability (but somehow related to the other sizes of orange, for ease of recollection).

Any thoughts about other ways to expand the play mode options (increase the number of available slots for abilities and skills)?

As for a new resolution system, I think, with a bit of experimenting, we cold figure out a way to use smalls as pseudo-dice. For instance, what are the odds of a small landing upright, if rolled across a table or dropped from a foot or so? Or could we use a "spin the bottle" (drop the bottle) method to see who succeeds in a given attempt: drop the small and whichever character it points at wins. Perhaps committing extra pieces gets a player extra drops? The beauty of such a resolution mechanic is that it keep it all in pyramids... and we could suggest using Volcano Caps for these "dice," as they would be easy to find for anyone and their color would not be used for abilities (otherwise, players will be trying to use spare colored smalls, which might not always be available!). Nice little marketing angle, there.... :)

Thoughts on resolution mechanics, if committed pip value comparison is rejected to allow for triple the ability slots?

misuba bloviates some more

Well, that gets you a lot of headroom for representing a lot of complexity with the pieces. However, that right there is my biggest problem with this design. You're using the pieces in such a way that everyone's going to need a big reference sheet to know what everything means anyway; once you're doing that, isn't it easier to just have a character sheet to begin with?

If you did that, it'd free up a lot of pieces for other uses. Now, the second thing that sprung to mind about this design is that, besides the meanings of each individual piece, the stacks are hard to read. I mean, if you need a quick glance at what your movement abilities all are, you're gonna have more trouble than you should, especially if some of your movement abilities are of small size. That's another reason to move to character sheets, but that's not my point: what this is pointing out is the inherent puzzliness of Icehouse pieces. That quality presents itself in IceTowers, Zendo of course, lots of places. That quality is something that's working against you right now, but what if you started working with it? Imagine all (or most) those pieces in the hands of the GM... making fiendish stacks that the players have to work out how to take apart without dying. A puzzle is definitely one valid way of representing a dungeon crawl.

Lastly, and again on the point of working with the material rather than against it: Icehouse pieces want to be simple. This is a bit deceptive, because you can get a lot of combinatorial complexity, as you're seeing. But as I learned when I was working on my Icehouse skirmish-minis combat game (don't ask), just because you can get it doesn't mean it's the most profitable design vein to mine. (I think that's doubly true in your case: all the new dungeon-crawly games that have come out lately have traded on simplification, taking the aspects of an adventurer that matter for a dungeon crawl and making those aspects more awesome, not just providing more and more options. Have a look at the Dungeoneer card game if you haven't; there's an RPG version coming out later this year that I think will underscore this. The way to people's hearts as a dungeon-crawl game is simplicity and fast pickup play.)

Rambling Fred

Well, I think part of the nice aspect of this game is the lack of a character sheet. Once you introduce the character sheet, it losses part of the unique aspects of it. Adding pyramids in as some mechanic on top of a character sheet just makes it a variation of other systems (like Deadlands) which use something else on top of dice as another random system (most often seen with playing cards and poker chips).

In no way does s system limit the ability to actually Role Play. The GM and the players handling the system limit it. I created a system that was based on Arcade games such as Castleviani, Super Mario Brothers, and Kid Icursus. In the initial playtesting, becuase of the mechanics of the system working similar to a video game, there was more rolepleying then in other games that are supposedly built for roleplaying.

While most systems are built from resolution conflict to abilities, I would suggest in this case try it the other way around. We should come up with the list of abilities first, then deal with the how do they stack, then worry about resolution.

As I often tell my students, one step at a time. The entire project may be daunting, but each little step is not so difficult.

As for idea on the stacking; Two stacks (combat, defense, movement)(social, mental, powers) would be a good deal. This does limit the number of skills possible to easily note. Multiple stacks per each category would work well, but requires an easy glance at system of knowing which stack is which. This can be covered by a table mat. Which is leaning slightly to the character sheet, but not all the way there.

Part of deciding skill points with multiple stacks could be the position in the stack. Bottom is the base number, second in stack gains a +1 et all.

With ten colors (excluding grey), this still allows for 10 skills per area. I am sure that with ten skills we can narrow down a list enough for decent play.

I suggest you start with a set of more easily delt with skills, such as movement, and define that list. Then work onward from there.

As for using sizes and color and position (or stack) to indicate skill, I think that is too much to notice. Color + Position (or Stack) = Effect Color + Size + = Effect Color + Size + Position (or Stack) = Effect

C + P = E

C + S = E

C + S + P = E

In deciding which variation to use, keep in mind what is easiest to notice. Color is a very good one, because it is easy. Size is ok; because it is fairly easy to notice (smaller pieces hidden under something might be an issue). Position is hardest. Separate stacks could be difficult (though less then position), unless marked (hence table mat suggestion).

On Complexity, Abstraction, and Getting Past Square One

Thanks, Fred and misuba, for participating. You're putting me into a tough push-pull position, but that's OK: it should make for the best game possible.

I am not sure if any RPG design that couples Icehouse pieces to abilities, effects, or what-not can be played without a reference sheet. I can't play HeroClix without the sheet... and it has fewer net effects than 30 (most of which are well themed, by color). Obviously, 90 effects will necessitate a reference sheet. Is that a "retreat" from "the stack shows all?" Well, maybe--but if not that way, what way?

It is possible that the whole system could be utterly abstracted out. For instance, one could write it such that a player may attempt to claim that a given size, color, position, etc grants Ability X and leave it to the other players to agree by vote. Then, there's no chart... just guidelines for players as to what "good" abstractions are like. This brings it VERY close to a sort of kid's game described on the Icehouse list: younger children find it completely "obvious" that a stack of greens is a Christmas tree, or that a red on a white on a red is Santa Claus. But wherein lies the "system" in such a freeform, majorly abstracted game?

What's worse for getting past square one, here, is that I am still waffling on whether this will be a system of granular actions, resolved as you go (Task Resolution) or one of whole conflicts framed by each opponent's stakes and resolved in one fell swoop (Conflict Resolution). That's a Major Decision that will shape the entire subsequent game design... and, again, the abstract nature of pyramids seems to favor that over a lot of particular effects and the reference chart they would require.

BUT, my co-designer--and both of you guys, it seems--favors traditional Task Resolution and likes the notion of "my stack shows what I can do and how well and that's all I need to see." He doesn't even want dice in the mix, which has a certain elegance... but which can lead to vicious spirals, if all effects are not carefully balanced against each other. The "uber" ability will tend to knock down all others, and without randomness to occasionally thwart it, will continue to do so until it reigns supreme.

So... that's a bunch of waffle to say, in short, "I'm starting over!" So... where to begin, then?

Characters - I want people to play single characters (roles, not teams or "story tokens" or whatever). Those characters will have various abilities that make them shine over other characters, at times (niches). Characters can cooperate in some manner to more easily or more quickly surmount challenges.

Challenge Variety - I want the game to involve more than just martial challenges or "killing things and taking their stuff." There should be the option to have challenges that involve sneaking past, negotiating with, or outwitting things... so you can take their stuff. I want the usual trappings of riddles and logic puzzles, but not mechanically resolved (i.e. left to the players to work out themselves, not "roll Deduction"). But I also want traps, locked chests, and nefarious obstacles that DO require mechanical efficacy to surpass--that is a very common trope for one niche in RPGs.

Character Progression - Challenges should not be surpassed merely for their own sake: somehow, the system should mechanically reward successful play and mechanically punish failure, even to the point of eliminating the character from play (death). Bigger, better, stronger, with commensurate ramping up of challenges until a breaking point... or until Omega point, where a character is retired as an agéd success.

So... we have these pyramids. They stack and point. They have values and colors. How do they make a character--WHAT IS a character, anyway? I am not married to the generic system idea, at this point. They could be weird, abstract energy beings that can morph their physical forms. They could be sentient molecules, if that suits the system and the above design ideas. Or they could be typical humanoid adventurers, out for fun and profit.

The appearance of pyramids do not lend themselves to being representative of typical adventuring humanoids, do they? A stack of five or ten or more pyramids looks like nothing so much as an abstract sculpture... or something I see on my World Community Grid screen saver (SETI@Home; FightAIDS@Home). Or DNA....

So maybe the way to go with this is some form of Homeworlds or Martian Mud Wrestling meets RGB or Ice Fu. Perhaps a character can "defeat" an opponent by giving up "DNA sequences" to that opponent until it "melts down" under the weight of them... then feed off of the remaining DNA to recover itself... while avoiding causing its own meltdown. Perhaps a character has to adjust its stack to the best possible configuration that, when compared to the opposition, determines success--"unmatch" pieces do "damage" by their color.

Hell, I dunno... See what I mean by Square One? I can have a number of general design goals that get me nowhere NEAR a working game or system. I suppose this is where creative vision comes in... and where collaboration may break down. With so many directions to go from Square One, almost any step forward closes tons of other options down. If we, as a group, aren't all pulling in the same direction as soon as possible, we could go around and around forever and never get to a testable game.

OK, enough babbling... Thoughts on the above, so far? Should we brainstorm ideas for types of characters and types of challenges, to begin to get a feel for where Square Two is?

Thanks again, folks! --David Artman 16:51, 9 Mar 2007 (GMT)

Questions to find step one and two

The thing is that a generic system, or any system if built correctly could be about energy beings, or molecules, or anything.

A character is a collection of skills, backed by a personality provided by the player or the gamemaster (as per PCs and NPCs).

You need to answer the following questions:

Do you want the colors to matter in the mechanics of the game?

Do you want the stackability to matter in the mechanics of the game?

Do you want a random factor, as compared to static factor?

From those three points we can build whatever you want. It is just a matter of finding the correct pattern to suit your wants, based on the resources you have (in this case Icehouse).

I still think you are trying to see a final product in your mind, instead of focusing on one step at a time.

I still think, from your description, you think of this as a video game in the mechanics.

Using the small pyramids for reward points would be worth while. No skill attached to them, but use them as experience points and counters for health. As the character advances they can cash in the small pieces to get larger ones (more skilled in what already is, or new skills). Or collect them for power or health points.

Responses

First, the above discussion already answers most of the questions you pose to me, so I'll let it stand and invite you to review.

We are still in the waffling stage on Task versus Conflict Resolution; and there might be a shift to allow for some things to be "off the map" for characters (e.g. items, objects, whatever) while others are "on the map" (in a stack) to represent the characters themselves. That is another possible axis for variety, as is pointing (which would likely only work "off the map"--folks won't want to be moving around what amounts to a Zendo koan just to move their character around).

Second, I am not thinking of a video game at all. I haven't seen a single video game in my life that does Conflict Resolution, so that should be obvious. Perhaps, with a Task Resolution style game, it could resemble a video game... but that's trivial: Neverwinter Nights is a video game, and we all know it's really based on D&D. And any RPG I might design with Icehouse could, yes, be ported to a video game.

So what's your point? What "video gameness" do you see that makes the current (fledgling) design less "role playing gamey"?

Finally, I dig your idea of smalls as a resource counter. However, I feel there's already too few points of contact with the current size + color structure, to lose one whole size as a tool for representing a game effect. Also, it's trivial to come up with "tokens," which is what you reduce the smalls to... unless perhaps there's some meaning to the color of the tokens. In THAT case, one could still use colored beads (or the all-powerful pen and paper) to track such resources. I am disinclined, therefore, to go with that choice. I need the smalls "on the map," so that I can get enough effects to have a full role playing game and not just a miniature combat system.