Post news RSS DungeonQuest: Paper Prototyping

As I promised last week, it’s time to make DungeonQuest combat fun. Before turning my head to programming, I want to make sure the game is fun to play. How? Paper prototyping and playtesting.

Posted by on

I have read it many times in all game design books. However, I can't emphasize enough how truly fundamental it is for video game development. I'll try to make it big and bold so it stands out in its own:

Prototyping and playtesting are the heart of game design

Do you want to make a cool game? Don't wait until your code and art are ready. Start prototyping. Now. And here comes the best part. There's no need to use any exclusive tool or language than only special game designers know how to use. You only need paper, a pencil, and a pair of scissors. Oh! I almost forgot. If you're prototyping an RPG (or for that matter any type of game where chance and random numbers are important) you may need another extra tool: a pair of dice. With this simple toolset you can lay
out the basic gameplay elements of your game in a paper prototype and start playing. And that's what really matters: play your game as much as you can. Play it when it's a paper prototype so you can feel what's right and what's wrong as soon as possible. Add rules, remove rules, change rules, and start from scratch if it's necessary. When the game is fun as a prototype, how can't it be fun with a better presentation?

Enough theory. Let's get started with DungeonQuest paper prototype, step by step.

DungeonQuest paper prototype

Step 1. Define what you're prototyping

DungeonQuest is a multiplayer platformer-RPG set in an epic fantasy world. The core gameplay mechanics of DungeonQuest are movement and combat. This will be our focus for the paper prototype. Things like projectiles, magic, bosses, etc. are out of the scope of this combat prototype, and will be covered in future prototypes.

Step 2. Setting up the paper prototype

Players can't play DungeonQuest without some basic elements: heroes, enemies, and a dungeon level. Time to get our hands a little dirty. Cut some paper rectangles and draw a human icon on them. Use a simple arrow to indicate where the character is facing. Paint the enemies red to differentiate them from the heroes. Draw a simple grid in a sheet of paper and we have our dungeon level. Thick borders represent platforms. They are strategically positioned to be accessible by characters with jump = 1 (tables), jump = 2 (library), and jump = 3 (lamps).

Step 3. Defining (and re-defining) rules

Also, players need a set of rules to play the game. Take a paper and begin writing the most basic game rules. In DungeonQuest these basic rules determine initiative of heroes and enemies, movement, and melee attack/defend. When you have a "complete" set of rules that allows you to play the game, stop, play the game, and take notes about what's fun and what's not working. This process will be repeated many times, so get used to tweak rules and playtest the changes to see if the game improves. In these last days I've been playing DungeonQuest many times, tweaking many rules. I can't tell you about all the intermediate rule sets that DungeonQuest have passed through, but I can tell you how's the actual state of
the game. Keep in mind that it's a wok-in-progress rule set. All of these rules can change in the following prototypes (so don't become too attached to them):

  1. Random initiative: all players and enemies throw a 1D10 die to determine the order of action (the highest values act first).
  2. Action and reactions: each player or enemy can perform two actions per turn (like attack, or defend when you've been attacked). The basic actions are represented in the prototype with cards: Movement/Jump, Attack, or Defense.
  3. Random Movement: a player or enemy who wants to move in his turn, throws a dice to determine the number of cells that the character moves. Characters move a random number of cells between 1 and their movement speed stat, making running away and chasing enemies more fun to play since it's not entirely determined by stats. Human characters have movement speed 3 so they can walk between 1-3 cells per turn. Of course, you can spend your two actions walking, making 2-6 cells (perfect for escaping when you're low of health points).
  4. Random Attack: a player or enemy who wants to attack in his turn, throws a 1D10 dice to determine the degree of success of the attack. Higher values indicate more power in the attack, with 10 being the critical hit. Critical hits can't be defended, and make the opponent fall to the ground (taking 1 action for getting up).
  5. Attack-Attack: if two characters attack to each other in the same turn, the attack with the higher value gains the position of the opponent. Gaining the position means "moving the opponent 1 cell back, while you advance 1 cell to take his position".
  6. Attack-Defend: if one character attacks and the opponent defends, the defender holds the position (adding 1 point to the defender "defense stance"). When the "defense stance" reaches the maximum value, the defense is broken exposing the defender during a short period of time (1 action). Heroes defending with a weapon have defense stance = 1, i.e. they only can defend 1 hit before being overwhelmed by the attacker. Heroes defending with a shield have a defense stance = 3, making them harder against attacks.

As I said before, this rule set is not written in stone. They are a great improvement in combat, especially thanks to the addition of randomness in movement and attack and the simplification of attack-defend (no ducking, defenses can be broken). But still combat has some problems:

  1. Getting stuck by the enemies. Since the world is 2D and heroes can't pass though enemies (and viceversa), you can find yourself stuck in a situation where two or more enemies become a "wall" that prevents you from moving. This is a serious problem, since players surely want to move freely all the time.
  2. Can't reach the enemies. For the same reason, if you arrive too late at combat, your fellow companions will be engaged in combat, becoming a "wall" that prevents you from reaching the enemies. This is a more serious problem, since players always want to attack baddies. Taking turns to attack the enemies is not an option.
  3. Winning strategy: surrounding enemies. If you manage to pass through an enemy (for instance using a platform), chances are you turn back and attack the enemy from the back while other allies attack the same enemy from the face. This Hero-Enemy-Hero situation is a winning strategy for heroes (and viceversa for enemies). No matter what the poor victim tries, he is condemned to die. The victim can't move, and either if he attacks/defends at one opponent, the other has a clear shot in his back.

For the first time, I have a clear idea of which elements are adding or subtracting to DungeonQuest experience. And that's why paper prototyping is so cool. I've experienced in a couple of hours more gameplay versions than I could ever have coded. On top of that, I can change the game just tweaking the rules, cutting more paper characters, or drawing more cells in the dungeon level. This is the cheapest development time you'll ever face.

But of course, paper prototyping is not the ultimate end of game development. As soon as I have a super-fun version of DungeonQuest combat, I'll playtest the paper prototype with real players: DungeonQuest is a multiplayer game so I can't just playtest it myself. Then if everything is still super-fun to play, I'll code the rules in DungeonQuest software prototype. This will be a perfect time to upload the game and hear your suggestions about it. Meanwhile, you can let me know your thoughts on the new combat rules ;)



So this game is going to be turn-based?

Reply Good karma Bad karma+1 vote
EmanuelMontero Author

Not really. The game is in real-time, but the prototype is turn-based. The random initiative system works pretty well for simulating real-time gameplay since players can get the same value in the die roll (therefore acting at the exact same time).

Reply Good karma+2 votes

Writing in C++?

Awesome work man!

Reply Good karma Bad karma+1 vote
EmanuelMontero Author

C# and XNA :)

Thanks for the comment!

Reply Good karma+1 vote

Really enjoyed reading this.. rarely do people ever explain the process of paper prototyping especially in the sense of combat. Sorry I was missing in action for a week been really sick check your email for updated sfx.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.