Keybattle Royale Development

development process: 

When we started brainstorming for this project we knew that we would want to include player vs. player interaction, the presence of items/stats and a time based mechanic. The first brainstorming ideas we had included a card based dueling system and we also wanted to use the keyboard in-front of the player to act as a physical board. In the first iteration the player moves across the board from a start key to end key. This seemed too limiting and linear so we decided to expand the board by focusing towards the center and forcing the players to move to a new area that uses the same keys. Taking inspiration from Battle Royale games we wanted to use shrinking barriers to force players into combat and making it more strategic and skill based. After playtesting we adjusted and fine tuned these elements like the shrinking boundaries, adding speed boosts and fairies (wild cards). 

Successes and what went right: 

From the earliest playtests Keybattle Royale received positive player feedback in terms of engagement. Our systems offered meaningful player choice that created an environment where everyone felt they had a chance to win. Our team worked seamlessly together to brainstorm ideas and workshop them until they entered the game space with enough functionality to be enjoyable. Ava’s idea of using the keyboard as the gamespace was original and interesting, with such an immediate distinguisher we were able to implement simpler internal systems without losing player interest.

Setbacks, what went wrong: 

While the surface of our core combat system feels good, a deeper look at it quickly reveals it’s shortcomings. Without penalties for ties, a good player with even one item type lead can ensure victory. We also struggled with the need for someone other than the players to organize and run the game. While this could easily be solved if we were implementing a fully digital version, in its current form a shoutcaster/referee was helpful for keeping game pasing flowing.

What you learned and How you overcame your setbacks: 

While we’d hoped to operate without one, our presentations utilized multiple group members to annotate the reference board and hype up the environment. This was particularly helpful when demoing to a large group as it created an almost spectator feel. While we didn’t implement a fundamentally different combat system, we were able to adjust the rules for loot acquisition to limit the frustrations of players who ended up with duplicates before completing a set of the basic items. Having multiple points of adjustment in your systems allows for greater control and balance.

future development:

As for next steps, the first concern we would like to address is the penalty for ties (or repeated ties). It was brought up during one of our playtests that players could force an infinite amount of ties if penalties were not set. Beyond this a complete redesign of the core combat system wasn’t off the table as additional complexity was requested by some of our repeat players. We are also interested in experimenting with how different rates of boundary shrinkage in different realms affect the overall game. In our first playtest it seemed that having boundaries shrink every single round was too forced and rushed. However, in our second playtest where we implemented an every other round boundary shrinkage, the gameplay felt very drawn out and lengthy. Finding the correct balance when controlling boundary shrinking rates, and adjusting player speed, will improve the pacing and feel of our game, making it much more enjoyable. Lastly, we are very interested in allowing players to place terrain blocks around the map to either force enemies into combat or force enemies to be caught outside of the boundaries. Besides terrain blocks, we have thought about allowing players to place invisible sticky traps as well that could (in a similar manner to terrain blocks) be used to force players outside of boundary lines. Implementing more actions such as these would allow for a more diverse range of gameplay and thus a more exciting one as well.

group roles and responsibilities: 

The Keybattle Royale team consists of Ava, Chloe, and Connor. During this project each of us was able to give feedback and work collaboratively on many of the different elements when constructing and playtesting our game. In the early stages of brainstorming, our group focused on ways to combine Ava's idea of using the keyboard as the game map and Chloe's idea of making the game centered around strategic pvp dueling.  We addressed any issues with game play as a group through discord, Connor gave valuable insight on the balancing of the game throughout the process and guided us in how to create meaningful strategy.  After our first few iterations, we agreed that in order to inject our game with a sense of urgency and action incentive, we should create a boundary shrinkage every other round. It was from these conversations that Chloe made the first iterations of our color coded game board. From there, Connor and Ava discussed doubling the colors purposes so that they also served as identifiers for the types of loot within them. Ava made the final cleaned up version of the colored and labeled game board. By looking at the system and seeing where issues would arise, we were able to address many issues before they would have become obvious with playtesting. Through our online set-up we were able to work collaboratively using google docs and messaging over discord and made sure every group member's thoughts and ideas were heard and discussed. 

GAME BOARD DESIGN:

PROCESS:

Early card game idea which was dropped but the strategic dueling idea stuck:

Idea to use keyboard as game board:

Racing from z to p with dueling in between idea:

Laying out ground rules for final game idea:

Idea to bind loot to colors:

Adding speed buff rewards: