Learning component

One of the projects assigned in Moses Wolfenstein’s class on Games and learning was to create an educational game. Because bots! already had a, limited, coding component I decided to use the assignment as an opportunity to work on my game. At the beginning there seemed to be several ways I could expand my game so that it could teach players coding. I had already done taken a similar approach on the project Tangibe Turtle but I wanted to try something different this time around. Influenced by the Code Hero project I tried to think of ways to make the coding aspect more explicit in Bots!. For a while, I thought of actually putting a command line into Bots! until i realized how lame it could potentially be, especially if mavis beacon didn’t teach you tying. I then thought about allowing the player to create custom action blocks by stringing simple commands together (for example, making a dash attack by combining moving and attacking). I didn’t entertain this idea for very long because I realized that balancing such a game would be a nightmare. Since I actually wanted to finish this project, I decided not to pursue this.

At this point I was a bit upset about trying to make the coding aspects of Bots! transferable to a formal setting. I then realized that it was because the core experience that I wanted to convey didn’t fit with teaching people to code. What it did fit with was making agents do cool things as they battled to the death. I was in luck, the core experience I wanted actually fit with another part of the game I wanted to develop.

What’s in a game?

I cannot stress how important I consider playtesting. I remember creating games growing up and immediately having my brother try them out. Thanks to his suggestions, I was able to make many otherwise mediocre games into something we had fun playing. Isn’t a memorable experience what we want when we create a game anyway? Playtesting makes that happen, and this is why I playtest to this day.

Playtesting bots! has made it a much better game than what it was just a few months ago. Two major changes that come to mind are the removal of the defend option, and the splitting of attacking into two directional attacks instead of an area of effect.

During a playtest I was asked to explain each action and why a person might want to use it instead of an alternative. When I was asked about the defend option I simply said that a player would use that when they think the opponent might attack them on the next turn (The defend option was meant to deflect an attack and nothing more). i was then asked to explain the reflect option. Before I finished, I realized that no one would ever choose the defend option if they could choose reflect. Both options protected the player from being hit, however, a reflect had the additional advantage of sending the attack back, killing the other player. Knowing this, I decided to remove the defend option from the game.

The problem of attacking having a one block area of effect had already raised it’s ugly head at the beginning of development, but it wasn’t until I had a few playtests that I found out how broken it was. During this particular playtest Player 1 stood next to the block with the coin and proceeded to only use the attack action. as a result, Player 2 couldn’t get close to Player 1 or the coin. As a result I split the attack into two actions. One that hit anyone unfortunate enough to be above or to the side of the attacker and one that dealt damage diagonally.

Although these changes have made Bots! a stronger game, I’m not done with yet, and I expect to have a lot of revisions before I am.

Killing your babies

After a few rounds of successful prototyping I started to think about other things I might be able to incorporate into the game. One such idea was the ability to execute special moves. In order to enhance the strategy component of the game I had always pictured being able to string a list of commands in order to execute something much more powerful.

Fully committed to implementing this feature, I started to think about how exactly these moves would be used. How many moves would be required to execute such a move? What would be the effect of such a move? Would moves combo between rounds or matches? In order to answer a few of these questions I decided to look at the critical path for my game. I figured that special moves wouldn’t be used if another player could win before it was executed. With this in mind, I tried to find out what was the smallest number of moves that I needed to make before winning (given that I wasn’t worried about my opponent killing me). The answer turned out to be 4 (though it rarely happened).

I decided to see if I could add special moves, Given only 4 actions. I came up with double attacks, speed boosts, scramblers but I couldn’t really justify the addition. The game also changed drastically as a result of adding special moves, which in this case didn’t really help the game out. With this is mind, I removed special abilities.

Recently, a change to the way attacks work has made me reconsider the decision to remove special attacks. Instead of hitting everything in a one block radius, which lead to stalemates, players now have to choose between diagonal and horizontal/vertical attacks. With this change the turtling problem that I described earlier disappeared. This also gave rise to a game type where players can attack each other without going after coins. Finally, this change meant that the critical path is no longer 4, players could now use special moves that were more than 4 actions long without forfeiting a point. However, I know the allure of feature creep so, for now, I will stick to my initial decision… at least until the core game is completed.

In the spirit of other indie game devs, I will be writing a couple of posts chronicling the development of Bots. Bots is a synchronous strategy game where two players compete to be the last one standing, or collect the most coins.

The Beginning.

The idea for bots came to me during GDC where, once again, I was told to make a game about something I know well. While I’m not a virtuoso hacker, I can write some mean code and decided to make a game around some sort of programming. The first challenge I experienced was abstracting the process of coding while keeping the feeling of making things do cool stuff (the reason I enjoy programming).

One of my initial ideas was to have both player sit at a terminal where they would type in commands to control their robots in real time. After some reflection I realized that this would be both complex and boring to people who don’t type very fast. In order to address both of these issues I decided to scale my game back and tried to simplify it. Instead of players typing their commands in realtime, I allowed players to select from a set of 7 actions (4 for movement, one for attack, one to defend, and one to reflect). I also narrowed down the playing field to a 5×5 grid and made the objective “destroy the other player”.

The paper prototype.

After nailing down the initial mechanics I decided to start testing the game right away. I really like paper prototyping. Making something is really rewarding, and paper prototyping lets you make a game really quickly. The initial prototype involved two white boards (for the players to write down the actions they would use for that round) two markers to represent the bots themselves, and a coin for the center tile. This was very versatile and allowed me to make several changes on the fly. After playing a few rounds of the game I tired to break the game by greifing it myself. I found that if a player stayed in the corner and waited for player 2 to come to them there was no way that they could lose. In order to prevent this turtling strategy, I added a second objective: Collect the coin. I placed a coin in the middle of the board so that if a player decided they wanted to hide in the corner, player 2 could simply walk to the middle and collect the coin winning the round. This proved to be a great addition resulting in a heavily contested area while making the game more exciting.

After the core mechanics settled I created a more polished version of the game (no use making it look too polished when heavy changes were imminent).