Saturday, January 4, 2014

Gameplay Prototyping #2: From Tabletop Playtesting To Software Prototype

Here's the second instalment in my brief summary about how I prototype games. It's not a definitive methodology or something but it has worked pretty well in my previous projects. Also, it's aligned with the common good practices of iterative game design.
Let's get into it. First, let's remember that last week I had a game design proposal for Bloodhunt tactical combat. There were some ambiguities and imprecisions that needed to be playtested. So I took a notebook to write down all alternatives, character sheets, a generic square tile board, and also I borrowed some Tannhauser miniatures to help me visualize the game scenario. Here's the result:


I played some random encounters progressively expanding the set of rules, from the most basic tactical combat (a blank scenario, one player against two enemies, all using only punch and block) to the depicted combat scenario (with cover positions, four enemies against the player, melee and ranged weapons, armors). Also, I playtested some scenarios with a friend controlling the player character and myself controlling the enemies. As a result, most of my original game design ambiguities were gone, but also some new and more interesting questions arise. Let's start by the original hypothesis:
  • The amount of tiles that a character can run in a single action is determined by 3 + Dexterity instead of Dexterity x 2 (with a minimum of 4). Both formulas were very similar, but the simpler formula which is also the most restrictive, ended up making the combat maneuvers a lot more interesting.
  • The 4 levels of health work better than the original VtM health system, which is great in terms of story, but too complicated and static for a tactical combat encounter. In VtM all characters have 7 health levels ranging from bruised to incapacitated. In Bloodhunt, each character has a different number of health points proportional to Stamina (the Brujah vampires for instance have 5 + Stamina health points). Instead of 7 health levels, characters have 4 levels of health ranging from unhurt to crippled. Each level down, means a dice pool penalty and a movement restriction. While being unhurt, your character can run and act without dice penalty, but when losing 1/4 of health you can only run half tiles and all your rolls suffer -1 to the dice pool. Another 1/4 of health and you can't run, while all your rolls suffer a -2 to the dice pool. And your final 1/4 of health is totally agonic, moving 1 tile instead of 2, with a -3 to the dice pool.
  • The diagonal movements and attacks were better off the game. The square tiles allows tactical movement since attacks from the side add +1 to the dice pool and attacks from the back add +2. However, diagonal attacks were imprecise and felt unnatural. Also, moving only in 4 directions made each movement matter in terms of coverage and orientation.
  • When shooting, VtM rules talk about range which is a bit of a vage term when playing in a square tile grid. There are three alternatives: you can shoot any enemy in a circular range (which allows you to shoot enemies behind your back), you can shoot any enemy in a cone of vision (which allows you to shoot enemies in diagonals) or you can shoot any enemy in a straight line (just like a tower in chess). This last option ended up being the most tactical. However, the cone of vision will be added as a Firearms combat action (Strafing).
During the random combats, there were some bugs that require further attention:
  • When a character is surounded by enemies, he is almost certainly dead. This is mostly because of the rule dictating that characters never share a tile with another enemy (unless one of the characters is using Hold). However, when your character is surrounded by enemies you need to create a break though so you can escape the beating. One option is to add a Brawl-based action for that (or modify Throw to allow this "push" behaviour), but this leaves all characters without Throw vulnerable. Another option is to add a generic throwback rule for all attacks. Something like "All attacks resulting in Stamina or more health points of damage throw the character back one tile (if possible)". Of course, more playtesting is needed to validate which option is better or if both options should be used in combination.
  • Even though running adds fatigue, there's not much penalty for constantly running to your best combat position. This "chicken run" behaviour should not be allowed. Maybe all dice rolls after running should have a cumulative -1 to the dice pool. 
After these first playtest sessions, I have gained a lot of insight knowledge about Bloodhunt tactical combat. There're still a lot of mechanics to test, but the experience clearly points where should I start prototyping. Also, this gives me a clear next step for prototyping: the software prototype. I need to perform all mechanic work automatically (initiative rolls, turn management, health system, etc). Having a software prototype speeds up a lot the playtesting process since I can test a thousand times what has been tested just once in the paper prototype. Of course, they are just different steps of the same principle: playtesting is at the heart of game design. Sometimes it's easier to start off in paper prototypes, but you can also shift to software prototypes at any time.


Here's a first screenshot of the tactical combat software prototype in Unity. It's ugly and it's still in a very early stage but it is serving its purpose: making each playtest faster and more efficient. In the left side of the screenshot you can see that we have buttons to restart the combat, perform an action and end the turn without doing anything. Also, we have all dice rolls printed in the console window (bottom left corner of the screenshot). The size of the grid is customizable and the number of enemies too. I'll give more details about the software prototype in the next post, I just wanted to show how it's all evolving. More to come soon.

No comments:

Post a Comment