My last post on this blog was nearly a year ago; I instead put my time toward recap videos. Now that Bot Land has been in development for a little over a year, I want to consolidate some the history behind its design!

The original design

Bot Land has always been an online strategy game with a focus on automation. However, our initial plan was for it to be a realtime player-vs-player game. This video sums up the gameplay. You make bots, write scripts, then throw them into the Arena to battle—sounds great! There was a big problem though: the strategy aspect was lacking.

When talking about strategy games, it’s important to be able to describe a player’s decision tree. A decision tree is formed around the rules of the game (“what can I do?”) combined with how you think about the state of the game (“what should I do?”).

In the original design of Bot Land, your main action consisted of choosing which bot you want to deploy. This was really two “sub-actions”:

• Choosing which hardware your bot has (e.g. Missiles and Cloaking)
• Choosing which script your bot has (e.g. only move while cloaked)

Bot hardware roughly follows a rock-paper-scissors model: Reflect will beat Missiles, but it will lose to Melee. The problem we faced with choosing a bot was that this wasn’t a meaningful decision. You couldn’t control where your bots were deployed, and the bots themselves didn’t have any knowledge of an enemy’s hardware. This meant that you may want to deploy a Reflect bot to counter the enemy’s Missiles bot, but you couldn’t guarantee that the two would meet up in the Arena.

For a minute, let’s consider a world where you could guarantee that your Rock bots encountered the enemy’s Scissors bots. The problem is that it’s not a difficult decision to make. Games like StarCraft that feature rock-paper-scissors mechanics aren’t as straightforward because it involves a lot of speed and dexterity to be able to pull off a particular strategy. In Bot Land, after you deploy your bot, your script takes over for you.

Without meaningful decisions to make in a game, there won’t be a high skill ceiling. That means that “pro” players won’t be much better than new players. This undermines a strategy game in my opinion. More importantly, playtesting of Bot Land was confirming our suspicions that the game wouldn’t be fun if we stuck with this design. This meant we had to revamp the decisions that a player could make.

Flux

I published this video at the end of July. It covers the section you just read above, but it also talks about how we planned on pivoting our game design. In short, we wanted to expand the player’s decision tree. Over the course of August, we tested concepts like:

• Being able to choose a bot’s spawn location
• Being able to control bots that were already deployed (via waypoints)
• Building factories which would lock you in to a particular hardware loadout
• Creating hero bots which could be teleported at will
• Spawning scrap piles on the map to give players points of interest to contest
• Having territory for players to generate money
• Upgrading bots

In the end, we determined that the game still wasn’t very strategic. What’s more is that it was hard to tell if we were even closer to a solution. Maybe another week of prototyping would get us there, or maybe we were pursuing something that was impossible. I was the most stressed-out that I think I’ve ever been in my life. I was beginning to think that Bot Land was unraveling and that I wouldn’t even finish the project.

Right around this time is when Ian, the game designer, stepped down due to time constraints. He left the company on amicable terms.

I started to question all of our original assumptions about the game. I created a document while streaming and started brainstorming (it’s now 70 pages and largely unreadable, but feel free to check it out). Here are the most important conclusions:

• If you’re expected to change scripts in a game, then the game shouldn’t be in realtime. There are two reasons for this:
  • It’s neither easy nor fun for most people to code quickly. It’s especially unfun on a mobile device.
  • A big problem with being expected to make major changes to automation while it’s running is that it means that the automation needs to run slowly enough for you to be able to identify where you need to make a change, but it needs to run quickly enough for you to know whether your change had any impact.
• If you can’t immediately tell exactly how something is going to play out in an automation game, then the game should give you multiple attempts at winning. The reason software has bugs is because people make mistakes. I think it’s okay to punish certain mistakes in games, but I think it would be frustrating to lose in Bot Land just because you couldn’t accurately predict how several medium-sized programs would play out.

New design

I started the last two sections with videos, so here’s another one that covers the last section and some new stuff (hey, I mentioned at the beginning of this post that I’m just consolidating information here!).

The biggest change in the new design is that Bot Land will no longer be a realtime game. It’s still a strategy game involving automation, and you’re still playing against other people, it’s just that those people don’t happen to be present when you’re challenging them. This is very similar to games like Clash of Clans or King of Thieves.

As a player of Bot Land, you have two roles. As a defender, you set up your own Arena ahead of time. Your goal is to protect your CPU. As an attacker, you are matched against another player’s defense (and remember, the defender isn’t actually present during the game). You get three attempts (AKA phases) to take out their CPU.

In this new design, attackers take their time positioning their bots, choosing hardware, and rewriting scripts. When they’re ready, they can start the phase and watch their automation play out. Any damage that the defender sustains will persist throughout later phases. After the phase is over, the attacker can make adjustments to their strategy and pick up where they left off.

Because attackers get to react to what they’re seeing in the Arena, defenders need some kind of advantage too. Defenders are able to place more bots than attackers can, and they also get to install chips into their Arena. Chips can boost the damage of their bots, make them move faster, or perhaps even alter the rules of engagement (maybe one such chip will make your CPU immune to damage until the chip is destroyed).

After an attacker is finished, the defender will be given a replay of what happened. Maybe the attacker teleported over all of your bots and gunned down the CPU quickly, or maybe they whittled you down with fiery weapons. The defender can use this knowledge to patch up any holes in their defense.

Bringing this back to the decision tree of Bot Land, attackers now have these decisions:

• High-level strategy
  • Do I want to put down many bots in one phase, or do I want to spread them out evenly over all phases?
  • Do I go after their chips, their bots, or their CPU?
• Low-level strategy
  • Where should I put my bots?
  • What should their hardware be?
  • What should their behavior be?

It’s my goal as a game designer to give defenders all sorts of different tools so that attackers aren’t falling into the same patterns. It would be a shame if attackers could win most matches with the same strategy, so it’s your job as a defender to come up with something unique! There will be plenty of hardware and chips at your disposal, and of course you can always write custom scripts that will surprise attackers.

Conclusions

This new design of defenders and attackers is analogous to puzzle-makers and puzzle-solvers. Sure, there are going to be some dead-simple defenses that you come across and “solve” instantaneously, but my hope is that defenders will keep evolving them to the point where even seasoned players are challenged. It’s in this way that I think the new design comes together; a player’s ingenuity is what should decide how well they do in Bot Land.

I prototyped and playtested enough of the new design to the point where I can say that it’s worth pursuing. I’m sure there will still be tweaks down the road, but as long as they’re not major overhauls, I think we’re on track for a fun game!