Close

Code Update: Adding teams and changing game variables

A project log for Open Tag

The best game of laser tag you've never played. Choose your class - from a sniper to a pyro, and customize your own game of laser tag!

opentagopentag 10/26/2020 at 14:290 Comments

We played the laser tag game and I saw how people played it. Naturally, there were some things people did that weren't very fun. For example, there were bases that would bring you back into the game after you were out. And, when five people were out, they would stand around the base, revive themselves, and tag everyone around them until they were out again, and then revive themselves again. They were on different teams, and weren't supposed to do that, but it was hard to tell what color the base was at any given moment, and it was the last base that they could use. So they all stood around for a minute, frantically trying to win. That's not a very fun way to play the game. So now, I have a choice as a game designer. I could do nothing and let people do that, or I could re-design the game so that behavior is no longer an option. 

For example, I added two things to change how people play the game. First, I added teams. When someone sends a tag, they now send what team they are on in addition to what type of tag they are sending. Using teams, I got rid of friendly fire, and which means that you can only be healed or revived by a base that is on your team. You can't stand next to an enemy base and keep reviving yourself. 

Another thing I is change when a base can revive someone. When a base is tagged by an enemy, the base can't revive people for a few seconds. That way, if the base is contested (and getting tagged by an enemy team), you can't keep using it to come back into the game right next to an enemy player. You will have to run back to another base to rejoin the game. Even if I just had this second change, you couldn't stand around a base as everyone tagged each other, since the base wouldn't allow anyone to use it to come back into the game as long as it's getting tagged.

One other issue that came up is balance. I don't want any of the classes to be over or under powered compared to each other. The reason for this is that I want to encourage people to play as any class and for each class to be fun and a viable option. If there is one class that is better in all situations, people will eventually figure that out and only choose that class. Which kind of happened. The pyro had an ability where, after they were out, they got more temporary health for a short time. This was to encourage them to play aggressively and constantly run at the enemy team. But, they got way to much health, to the point where you would have to tag them 45 times before they were out. That's more than double everyone else. Which, made it easy for the pyro to run around the battlefield, ignoring any signs of danger and burn all their enemies to the ground (metaphorically, they were sending "fire" tags). Their damage also got their enemies out in about 3 seconds, since they did double damage with each tag. That was a bit fast, so to balance that, I changed how health and damage works. I was using a system where you had 10 health, and each tag did either 1 or 2 damage. Now you have 100 health, and tags do between 7 and 20 damage. That allows me to have a broader range of damage and fine tune how much damage a tag does so no one character can do way more damage than another. 

This is all done in hope of making the metagame, or the game around the game of which class is best for a particular scenario, something that includes all classes. Because one other thing I learned during playtesting was that the lightning class's special ability didn't work. At all. There was a problem with how the tag was received, and I had to change the entire sending and receiving tag protocol to fix it. Which ended up being fine, but I still don't know how balanced that class is, since it didn't work. But that's what testing is for. Figuring how whether or not what you've built actually works. 

And, this round of testing allowed me to make some improvements to the game, which I think is helping it be better. Which, in my eyes, means designing a balanced game where each strategy has a way to counter it, and no one strategy is dominant over all others. That way, people can continue to think around the problems they are given and play the game in different ways depending on who they are playing against. And that, I think, is the key to making a long lasting, competitive multiplayer game. Which, is what I am trying to build. 

Discussions