Secondary RPS on a forever expanding game

I am sorry to say that, I am quite lost.

It might help if you gave us a frame of reference for this information. let me start with some questions.

What is "a mechanical RPS"?
What type of game is this (Theme/Genre)?

Sounds to me, like a combat system for a card and dice game... but I am not sure. Are the players placing the cards in a pattern to form the numbers you are talking about or are those numbers tables that will be referenced from the rulebook? Also, it is unclear to me what part of the game is ever expanding, outside of the way numbers do this on their own when incrementing them to infinity.

Overall I think you should take a quick step back from the mechanic you are trying to explain and just give us the big picture for how the game works. Then once we can see the structure of how the game might play/flow and what the game might have in the way of components. Then we might be able to see where this information fits into things.

-Eamon

Thanks, that does make things clearer. While I might be a "lurker" who has not been very active, I am not new to the world of board game design...

The use of terms and acronyms without a common understanding is something very near and dear to my heart right now.

Rock-Paper-Scissors (RPS)

I do think I understand what you mean now, but I am not sure everyone will.

-----------

I do feel that you must "tell" new players this type of information. You might not need to tell players already familiar with real-time strategy games this type information, only because, they are already conditioned to this type of mechanic.

You are making an assumption of understanding where that understanding may not actually exist.

When you say "the RPS is seen when the game is played" I feel like you are taking about the feedback a player gets from a computer game. I as the player, take an action and the outcome (shown me by the game) tells me that my action succeeded or failed.

This is sadly not the case with board games. If you approach your design with the need for player feedback (as a learning method) you will need to provide that feedback in the form of informative rules or gameplay examples in the rulebook. Also, understand that "new" players will need to see the game played by others before the concepts in the game become clear to them.

You through the rulebook must tell the players how to determine the outcome of events in the RPS engine. The fact that one unit type is better at overcoming the strengths or exploiting the weaknesses of other unit types does not make it an RPS engine. The dice rolling aspect of combat makes the two ideas mutually exclusive.

As designers, we need to craft the game and the rules as if the people playing/reading them are new to the type of game we are making. I don't mean that you have to talk down to them like children (unless it is for children). I just mean we need to be careful not to make assumptions about what players already know or don't know about the mechanics we are using.

-----------

On the subject of "RPS"

The RPS that you are calling "natural" is not an RPS (in my opinion). It is more a system of interdependent power curves based on the natural way the physics and tactics of warfare happen in real life. This is more of an attempted simulation and not a zero-sum RPS.

• Example 1: Tank beats soldier, soldier beats airplane, airplane beats tank

This is an RPS. This represents a zero-sum game mechanic.

• Example 2: Tank is "stronger" than a soldier, but if I have more soldiers or a good roll of the dice the soldiers can beat the tank.

This is not an RPS because is not a zero-sum game mechanic.

These comments are meant only as my way of trying to clarify the concepts being talked about and not in a "you are wrong" sense. I just feel it is important as designers to understand the structure of the mechanics we are trying to implement so we can better compensate for the strengths and weaknesses of the mechanics. I am only ever trying to be helpful (for you and me). I am still working out the distinctions between these ideas for myself.

-----------

Back on the subject of you post...

I think you are onto something with having the comparison stats on the units. If I understand them right now, you can look at any two opposing units and based on how the stats "line up" with each other... the players will know what table from the rules they are rolling against?

For "specific targets" you might use "point targets" and "area targets". This is they way we talked about weapons when I was in the military. A big machine-gun was an area of effect weapon just like a grenade. Another distinction that we made about weapons was direct and indirect fire. The first being that you needed to see you target and the second that you did not have to. This would be a rocket launcher vs. a mortar. I guess this type of thing would be used more in rules about "cover" and "line-of-sight", but just throwing it out as ideas.

I do see how adding columns adds a new level to the power curve over time. Do unit cards also have "abilities" or are they more of a "stat & roll" vs. "stat & roll" combat? I guess I am thinking about how to keep lower armored units useful once there are units with 5 or 6 columns on the field.

I hope you can see that I only want to help and I am not trying to be difficult.

-Eamon

-------------
Zero-Sum: "A zero-sum game is a mathematical representation of a situation in which each participant's gain or loss of utility is exactly balanced by the losses or gains of the utility of the other participants."
-------------

You are not wrong about what a zero-sum is, but there is a flaw in the thought that a "soft" version is what real-time strategy games have.

This is can be a fascinating topic to listen to when doctors of mathematics get into game theory. The main problem is that for every one layer of complexity that we added to a game system we bring in thousands of mathematical variables that need to be balanced in order to maintain the "claim" that it is a zero-sum game. Adding randomness is the leading cause of death for zero-sum games. The second cause is variable powers... this is a bad combo for the type of game we are talking about.

I don't point this out to say you are wrong (because I think you understand the concept of a zero-sum game quite well)... but more to try and explain the need you and I (and all other board game designers) have for the qualifying language that surrounds the topic.

"Mechanical or Natural RPS" and "Soft RPS" and an "RPS effect"

These are all "abstract versions" of the core concept that modify the meaning. Because none of these "extra" terms are clearly defined it adds misunderstanding and flawed thinking into the mix.

I am not saying that we don't need these variations of the core RPS concept, but we do need to understand how they are different from the core.

But I am sure this is something that should have its own thread someday... and I am sorry this side-bar has distracted from your core point.

--------------------------------------

ON/OFF topic, I think you have been doing balancing using the zero-sum idea as a guide and that is a great guide.

One way to do group or area of effect "tests" is to start with just one unit that can attack two targets at the same time. this in playtesting will reveal how strong that power is... and that might serve as a guide for powers that attack a group of hex (spaces). It will be hard to measure the power vs. the cost of these special units or unit powers.

Even with only stat vs. stat comparison, you will have a challenge in the way the power curve is built. but I do recommend looking into the math of power curves rather than trying to maintain a zero-sum RPS mechanic.

One of the strong and weak points of Magic the Gathering is that the design team did not use an RPS style of thinking... but they did have times when the power cures were not managed as well as they could have been.

I guess that was the point I was trying to make at the start... you might have an easier time thinking about things if you take off the shroud of the zero-sum and just work to make good power curves for each unit type. Just don't fall into the power curve traps and I think you will be fine. But this might open up the field and give you the freedom to add features I can tell you want.

As always... just food for thought not intended to be negative. I think you have put a lot of thought into the design and from your comments I can tell you have done your homework.

-Eamon

--Edit--
RTS games I have played.
Warcraft 1,2, & 3
Starcraft 1
Command & Conquer
Age of Empires 1
Dawn of War 1 & expansions
Sins of a Solar Empire
--------