Friday, December 12, 2014

Designing Tensai, Part 1: Take Up Your Chisel

A while back, I was pretty gung-ho about making a Battler (basically, a Pokémon clone). A friend had expressed interest in cloning an existing online Pokémon battler in order to practice his programming skills, so I took the opportunity to pitch an idea for a new game, in the vein of Pokémon, designed to improve on what I viewed as some flaws in the formula. Although the game got abandoned as the programmer got busy on other projects, I still dwell on the design and thing, “If I ever made this game, it would be fantastic.”

Don't get me wrong; I have no grandiose ideas of knocking Pokémon off the throne Nintendo's used Charizard's flames to forge together among the many cartridges of the other mobile franchises that have fallen before it, but I definitely see flaws in the franchise's design that irk me as a designer.

I've been pondering writing a blog series for a while about my mindset in designing and addressing Pokémon's issues / designing Tensai, but it wasn't until reading Hardy LeBel's recent blog about what he views as the Universal Truth of Game Design #1 that I really felt my approach was truly correct.

So Design Part 1: The Elements

Now, if you took the time to pause and read LeBel's blog, you saw that he said the second most important tool in a designer's kit is subtraction.

If you didn't take the time to pause and read LeBel's blog first, go back and do so. He says some seriously cool stuff. In fact, I encourage you to go read his other posts as well. Especially if you play Halo.

Back on topic: Subtraction.

One of the biggest flaws to the Pokémon formula in my opinion is the convoluted type strength/weaknesses the different elements all have. Sure, it's cool to have x be strong against y, and d/f dual type being 4 times weak to y while d/x dual type is neutral. But it's convoluted and needlessly complex. The player can't be expected to learn the type interactions through a normal play-through of the game, and there's too much information for it to be displayed in the game's UI in a clearly readable manner.

So when I started working on Tensai, I borrowed from a fantasy world I've been world-building for some time (which borrowed heavily from both Eastern and Western influences)...where there were simply seven elements: Fire, Metal, Ice, Wood, Air, Water, and Earth. (The keen of you will notice those are literally the 4 Classical Elements with the inclusion of Chinese elements Wood and Metal...and then Ice.) The interactions followed a simply RPS7 system; each element was strong against the 3 that followed it and was weak to the 3 that preceeded it.

By trimming the number of available elements from 18/17/15 (depending on generation) to 7, you immediately make it much easier for players new to your system to tell what is strong against what. Fire, for example, is strong against Metal (melts it), Ice (melts it), and Wood (burns it)...while being weak to Air (Blows it Out), Water (quenches it), and Earth (Smothers it / Doesn't Burn). The type interaction chart is so simple it could be displayed with a single chart featuring each of the seven elements with 3 lines of the same color going from each element's symbol to the three it is strong against. Your player base is now given a clear idea of how the elements work, which can be communicated even within a battle.

In addition to limiting the number of elements, I also made one mandate to go along with it that made the design very, very simplified compared to Pokémon: A Creature's base moveset can only include moves of the same element as that Creature. A Fire creature can only use Fire moves, An Air creature can only use Air moves, and so on.

But wait, Audley! I see a problem with that!

Oh, do you now?

Yes! Won't that mean the elemental type advantages are too steep to overcome if you switch into a bad match-up?!

Clever girl, you have found a weakness...and the second major design decision I made on Tensai...which came about as a domino effect of removing a large chunk of Pokémon's clutter.

Design Part 2: Action Types

In Pokémon, moves have their own “attack” element which interacts with the creature's element or elements. Say, for example, you had the Fighting-type Pokémon Hitmonchan. He wasn't limited to Fighting-type moves, thanks to Fire Punch, Ice Punch, or Thunder Punch giving him attacks of those elements to allow him to better cover his weaknesses (for example, Ice Punch or Thunder Punch would enable him to beat up any Flying types that came his way if he was fast enough.)

Since I'd removed this possibility in Tensai, I had to compensate for the aforementioned problem where there was no ability to cover your type weaknesses. And that is where Action Types came in.

I created five “Action Types” that an attack move could be quanlified as. Melee, Ranged, Magical, Aerial, or Defensive. These five also interacted in a sort of Rock-Paper-Scissors-Lizard-Spock format, but not in as straight forward a manner as the RPS7 chain of elements.

Melee attacks were strong against Ranged, but super effective against Magical.
Ranged attacks were strong against Magical, but super effective against Aerial.
Magical attacks were strong against Aerial, but super effective against Defensive.
Aerial attacks were strong against Defensive, but super effective against Melee.
Defensive attacks were strong against Melee, but super effective against Ranged.

Instead of just improving the damage your creature dealt, however, the Action Types did something better: they reduced the damage you took from the opposing creature. Strong = Half damage. Super Effective = No damage.

So if my Fire Creature were out against your Water creature...I would be at a disadvantage. However, if I predicted you were about to use a Ranged move, and my creature had a Defensive move in his moveset, I could use the Defensive move to take no damage, while dealing a slightly improved chunk of damage to your creature.

Since creatures only have 3 moves (technically 4, but I'll address that later) in Tensai, you can use process of elimination to get a reasonable guess of your opponent's moves and attempt to rock-paper-scissors your way to victory. It also leaves room for some Sirlin-loved Yomi Layer 3 in terms of “Well he should do this move for the most damage, so I should use this type of move to negate its damage...but if he predicts I'm going to do that, he may use this move to counter my counter...” et cetera, et cetera. In the few instances of practice battle runs I ran utilizing nothing but a Skype chat room and a PHP-coded calculator, the four of us who tested it all enjoyed the new layer of depth created out of necessity to coincide with the design-by-subtraction sledgehammer taken to Pokémon's element system.

In my next blog on Designing Tensai, I'm going to cover more in-depth how I approached the largest problem in competitive Pokémon, “hax” (RNG) in detail (I touched on it in the past in my blog Fighting Chance.) – but thanks to the Action Type system, I was able to have even greater control than would really be able to be tuneable otherwise.

So stay tuned for Part 2. Don't worry, this one will be updated much, much sooner than my Calling the Shots blog! And thanks again to Hardy LeBel for the inspiration. Seriously, go read his stuff:

Part 2
Part 3
Part 4

No comments:

Post a Comment