Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Breaking the Mold: Designing a kung-fu game that's not about fighting - Part 2

This is part two of a series in which I'll blog about the Making of Shuyan the Kung Fu Princes - Designing a kung-fu game that's not about fighting.

Drew Parker, Blogger

September 30, 2013

5 Min Read

By Drew Parker, Mark Animation (Ontario, Canada)

Creative Director, Shuyan the Kung Fu Princess, coming this Fall exclusively to iPad

This is part two of a series in which I'll blog about the Making of Shuyan the Kung Fu Princes - Designing a kung-fu game that's not about fighting. Missed Part 1? Read it here.

Part 2:  To Not Get Hit  -  Deciding on our Primary "Attack"

In his book, Jesse Schell proposes one reason many games feel so derivative is because they all ask you to perform the exact same actions.  Thinking over my own gaming experiences, this made a lot of sense to me. 

How were we going to make a unique game about Kung Fu, if everything you do in our game is the exact same as other melee games?

The most often repeated action in melee combat games besides navigation is the primary attack. Of course in a combat situation this makes sense. If you want to win, you must "attack" until the opponent is beaten. If you want to do other more powerful moves, they are still variations of "attack," (like the secondary attack) and typically are opened up by doing the primary attack first.

I looked to our essential experience, "Finding self-restraint through kung fu training, by learning to have no intention to fight."  My kung fu teacher would say things like, "Hitting is easy, anyone can hit. Not getting hit, that's kung fu."

Then an exciting (yet scary!) idea emerged. What if the primary operative action, the action performed most by the player, was not an attack?  Our game should be about how to not get hit.  Perhaps the move could be defensive, similar to what a melee combat designer calls a "Block."

Our game is played from a somewhat top-down perspective, and conflicts take place in small arenas.  We already had entity path-finding, enemy attacks, and player controls setup from a previous prototype.  Enemies could chase the player around, and if they got close enough, damage the player with a punch.

We added a new defensive movement, and made the move directional and only successful if the player matched an incoming attack line. Now the player could stop any incoming attack if they timed it right.  In addition, we removed our previous attack action! 

We called this new defensive move the GREET, because in kung fu thought, every time you intercept an opponent's attack you are not trying to forcefully stop him, but are actually greeting his energy like a handshake.

As many designers have mentioned, the only way to make a game is to build the game, you can't play a paper design. So we built it, and found the experience did not work yet - so we iterated.

The enemies swarmed the player and hampered the player's movement, as our old attack which used to push enemies back was gone - so we set up enemy-formation logic to help enemies maintain a minimum distance from the player.  The player could just run away from fights, so we sped up the enemy movement speed, added running acceleration to the player (it's slower to change directions) and slowed them down if they bumped into an enemy.  The combat pace dragged, so to speed things up we increased the enemy attack rate, allowed the enemy attack windows to overlap, and added movement prediction to the AI so the enemies would start to attack if they thought the player would be in range soon.

It felt better, but still too repetitive.  When switching my viewpoint and looking at the game as a board with pieces, I realized the problem was the game "board" (arena) was too static, as all the "pieces" (entities) were in the same place!  All the blocking of attacks stifled the navigational and group formation logic.  So I added physics responses on all the entities, and gave each landed or blocked attack a velocity impulse with a slight random variation.

Now the design felt like it had promise, because it was stirring up my emotions some, and finally started to feel like Kung Fu!  Attacks were flying in from any direction (excitement), being surrounded by enemies you had to wait for just the right moment to defend yourself (tension & skill) and as everyone was being shoved all over the place and smashing wooden walls (pleasure of surprise), when you finally survived a flurry of punches (pleasure of success) you realized you were on the other side of the game grid!  (new situation, new choices).

Because that small experience proved by itself it was fun and had potential, our team gained confidence we could make this "fight without fighting" idea pan out.  But there was still a lot of hard work and uncertainty in front of us.

What are the other moves?  We need attack moves somewhere, but how do we create them without falling into old ideas and losing what we just gained?

At this point we followed more closely the conventions and standards of combat design. This gamasutra post gives an excellent outline of how to design a combat system. Sébastian Lambottin’s design process gave us a lot of guidance in setting up our combat system, such as in how to pick different abilities and make them all unique and interesting.

During that process, one of the most obvious yet important questions raised itself: in a game where you are supposed to "fight without fighting," how do you end the fight?

Watch out for Part 3 of the series where I'll get into how our team discovered our victory condition.

 

Read more about:

Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like