Open Tag

Started making a case for the laser tag device. I want something that will hold the arduino, battery, and align the infrared LED with a sight and optic so that it is easy to tag someone from far away. I've landed on using iron sights, similar to a pistol, to make it easy to aim the device at other players. 

This version is a re-make of an older version, with an attachable lens on the front. Below is a photo of one of the prototypes, with a device installed.

It seems to work well, and if you aim through the two posts, you can see the screen pretty easily. When I tried using them, I didn't look down at the screen very much, but the devices did send tags a considerable distance. I didn't measure it, but it went at least 50 yards. That is an acceptable range to play in a park, so I think that this design is at least good enough for the first version of the device. I'm not interested in making a case that looks more like a gun with a traditional trigger, so I'm not going to. This meets the criteria I have for a functional device, and is incredibly simple to make. So there you have it. 

I'll need to make another prototype to fix some small issues with hole sizes and how to more easily detach the lens, but overall it's a good prototype. Maybe one or two more versions and I'll say it's good enough to be promoted to version 1.0.  

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. 

After another big round of code changes, the first 10 classes are now added into laser tag. One of them is the "base" which other players can capture and revives players, so there are only 9 playable classes. But this completes the first version of the laser tag device. The different classes, and their abilities, are shown below. Every class can send a tag to deal 1 damage and has a different ability they can send that has different effects.

Special Abilities

1. Soldier - send 3 tags, but take 1 damage

2. Medic - heal 1 damage

3. Base (capturable, non-player class for stationary bases that can revive you to bring you back into the game

4. Pyro - has a short range flamethrower. Anyone hit by it takes double damage. And, when they are out, the get 5 extra health for 45 seconds (to encourage them to have an aggressive, charge your enemy playstyle)

5. Ice - slows down enemy tags

6. Poison - deals damage over time

7. Rock - gives armor that blocks abilities

8. Water - jams other people's devices, keeping them from sending abilities for a short time

9. Lightning - deals damage and removes character's mana, which keeps them from sending abilities

10. Necromancer - brings characters back from the dead.

I'm excited to test out the devices and the classes. The classes might need tweaking, along with the variables that control them, but I think this completes all the major coding work for version 1.0. I'm excited to release it and start making the final boards and case for the first version once this is tested.

A diagram of the classes and how they relate is shown below, along with some of the synergies that are built into the system to encourage team play.

So, spent some time in the code and added three different classes. Now there are the following built:

1. Soldier class - ability to do triple damage, but take 1 damage

2. Healer class - ability to heal 1 damage

3. Base - ability to revive players. Can be "captured" and will change from the red team to blue team after taking 25 damage

4. Pyro class - ability to "ignite" other players in flame. Applies the "fire" status effect, which doubles all damage on that player. Also deals 1 damage. This special ability allows you to hold down the button instead of having to press it.

5. Ice class - ability to "freeze" other players with ice. Applies an "ice" status, that stacks up to 3 times. For each stack, players' main tag cooldown goes up, making it take longer for them to send their main tag.

I'm happy with how everything is displayed on the OLED, and it's now time to build a few more of them and do a play test. Right now, everything is prototypes with alligator clips and jumper wires, so I'll need to wire everything together and make is a bit more sturdy so you can run around with the devices. All in all, I think this next test will start testing whether the idea of class based laser tag adds another layer of depth to the game. And hopefully, makes it more fun. 

There are five more main classes to add after this, with 10 total. Although, technically, only 9 of them are playable classes. You don't really play as a base. That's just a base. 

So, Arduino released a product a while back that is basically an online IDE. They are calling it Arduino create, They have some cool things. Tools for IoT tech, SIM cards for using cell towers to connect stuff, and lots of other cool tools. They even have third party libraries installed.

But.

For the Adafruit library that I"m using to run a 0.96" OLED screen, I get an error whenever I try to compile the code, "no matching function for call to 'Adafruit_SSD1306::Adafruit_SSD1306(int, int, TwoWire*, int)' ". 

So, I basically can't use that library on Arduino's web IDE. I'm really not sure why. To me, this seems like a problem between Arduino's Web Editor and Adafruit's library, and I do not have the tools or resources to troubleshoot that. Nor do I need to, since I can still use the arduino IDE on my computer just fine. I tried using other versions of the library and checked that the library that I'm using with the Arduino software on my PC is the same as the version on the web editor. Still no dice. I even tried modifying the function that it said had an error. Made the code completely fail. 

But, they have a lot of cool tools. Like making it super easy to share code, either through links or iframes that you can embed in a website. Like this one. (note: I tried to put the iframe in this log, and hackaday didn't like it, so it didn't get displayed. Oh well)

So, I've included the example sketch, from the library itself, below so you can see for yourself if you get the same error. I am totally going to use this to embed code in the website in the future because it is great, but it means that it won't work for the final product. You'll have to compile that on your own PC. 

Alright, so, one of the pieces of feedback I got was to add haptic feedback to the device. I threw a vibration motor onto the device and saw what it did.

The results were a little underwhelming. Yes, it was very simple to add, and yes, i can get a bigger one, but it was hard to feel the vibration while I was holding the device. Mounting also seemed to be very important to transfer the vibration through the case, which makes sense. You want the whole device to rattle, not just the motor. 

It was a pretty simple thing to add, and it should make it easier to determine when you are tagged. The only other thing I thought of adding was to invert the colors on the OLED display to indicate that you have been tagged. I think that combined with the vibration and sound should make it clear. Initial tests showed people didn't notice when they were getting tagged. Or, at least, wanted more feedback when they were. 

Also, the wires on this motor are tiny. It's fine, I can work with them, but stripping small wires is annoying. I cut through the whole wire twice. I guess I need to practice more with small wire.

So, I switched from a LCD to an OLED. And man, is it smaller. The 0.96" screen is much smaller, but you have much more control over what each pixel displays. Thanks to Adafruit's Graphics Library and SSD1306 library, these displays are easy to control with an arduino. I found a handy tutorial, plugged it in, and...

Nothing.

No display.

So, I checked the address settings, found the display, and got it displaying. Hooray!

And then, I got a great recommendation from someone on hackaday to use icons instead of text to display status. So, after I played around with the words and numbers for a bit to get a feel for the device,  I needed to add icons. But I didn't want to make the images myself. Not when there's the internet. So a few searches later, and I found this tutorial and this tutorial on how to make images you can display on an OLED using an arduino. The tutorial had a link to an application that you have to use on a computer. I thought it was going to download something (it doesn't, it's browser based, but I didn't want to click it) so I found the original here. I then found a bunch of images that I wanted to put on the OLED, like fire, a snowflake, skull and crossbones, etc. 

I got images for all 6 status' that you can have. Converted them all to byte arrays, using the tool and put them all on the arduino. It turned out great, and I can fit all of the status effects on the OLED screen.

I updated the laser tag code with the OLED code and it

crashed. 

Huh.

Well, went digging into the code and found that whenever I had a bunch of debug information to the serial monitor, I couldn't connect to the OLED. My code just wouldn't run. I tried hunting down where in the code it was breaking, spending quite a bit of time commenting and uncommenting lines of code. Eventually, I took to the internet, and low and behold someone already had this problem, posted about it, and it was answered. Turns out, the OLED I'm using is a 128x64, and requires about 1 kB of RAM. Since the ATmega328p (arduino) only has 2kB of RAM, I can't have more than 50% of the RAM used after compiling my code, or there won't be enough space to run the display. In fact, you need to get it down to 30% ish so that there is still enough RAM to do other things. Like, you know, run your code or store other variables. Also, I learned that, storing strings in lines with Serial.print stores it in RAM. That used up a lot of my memory, well over 50%, so the OLED would fail. It just didn't have enough RAM. Well, the guys at arduino built a way to keep those strings from taking up all your memory, as described here. Using the F( ) command stores strings in flash memory rather than RAM, so now I have enough RAM and everything compiles. 

Yay. I wish I had known that earlier, but, you sometimes find out about the hardware and software limitations of the libraries and hardware you use after getting and installing them. If I wanted to run more displays, I'd really need to get a microprocessor with more RAM. Or use smaller displays. Or different displays. Ok, there are lots of ways to fix this problem, but for now, it's fixed.

Except that whenever I send a tag, I get something on the IR sensor output. It may be my power's doing some weird jig or something. Or some interference. Or a wire's got loose again. Either way, that's a debugging problem for another time. For now, it's working. 

Mostly.

First of all, I'm very happy with how easy it is to connect an LCD to an arduino. I purchases an LCD, found a library on how to control it (I started with this tutorial, which was very informative about the chip they use for I2C communication to LCD's, and ended up using a different library, LiquidCrystal_I2C.h. It was very easy to install, and the example sketch got me up and running quickly.

And now, onto the gripes. 

First off, I want to be able to display health and any status effects so they are easily readable. If you have more than one status effect, I want you to be able to look down and read them all. With 16 characters per line, and two lines, I can't fit very many characters on the screen. I thought that it would be ok to shorten the words, like using e- for electricity or H2O for water, but it's not immediately apparent what you are looking at and what everything means. I'd like to make the text on the screen more self explanatory. That way, it will be easy for someone to look at the screen and know their status. 

Secondly, the screen is too wide. It's wider than the current board, and when you hold it it sticks out. I didn't like it, so I started looking at alternatives.

OLED's are another option for displays, and there are ones that also use I2C (which is great, because I don't have a lot of pins available to throw at this, especially if I'm adding radios/wifi later). I purchased a 0.96" OLED board and will try that one next. There are also good libraries on how to use that, from Adafruit (a company I love). 

Hopefully, with the OLED display, I will have more characters I can use (the text size is variable) and the screen will be smaller. Hopefully not too small. We'll see. the LCD that I had is a 16x2 (16 characters on two rows). Each character is 5 pixels wide and 8 pixels high. Or, the screen is about 80x16 pixels. The screen that I'm buying is 128x64 pixels (however, I think the pixels themselves are smaller), so, assuming the same number of pixels per character, I should be able to fit more characters per line, and have a lot more lines. The pixels and screen will be smaller, so I'll have to balance size with amount of information I need to show. Should be manageable. 

One last thing that I realized is that now that I have a display, I can start adding more features that require that you see how much health or mana you have. Instead of having unlimited use of your ability, I could have it on a recharge timer, or have a mana pool that is drained when you use the ability, and refills if you don't use it for 1 second. I think that would help the issue of holding down the flamethrower button forever or sending infinite healing. I think that would be fun, and I'll look into adding that into the next version of the code.

Build prototypes of the laser tag system, version 0.89, including a case and a lens to columate the light and send the tags further. 

Tested it in a park with five other people, and the devices worked! You could send the tags about 100 feet and tag people while they were running. That is a big improvement over the old model, which made it nearly impossible to tag someone while they were moving, and they didn't go as far. 

I also got some feedback on the device itself. Overall, the device worked, but it could use a few improvements on telegraphing to the other players when you are out, and adding an LCD to display information to the player. Right now, it was using the RGB LED to convey information to the player, and using an LCD would make that much easier. Especially as the game gets more complicated. 

Overall, I'm happy with how the devices performed. Sending and receiving tags worked well, and with a little instruction, it was easy to do. That is the core mechanic of the game, and if that is working well, then I have a solid base to build the rest of the mechanics of the game on. So now, the rest of the year can be adding to that base mechanic of sending and receiving tags.

In addition to building an arduino shield, I am also building a full on arduino compatible version. 

Boards were made by Seed studio. They aren't as good as OSH Park, but they are cheaper. I could probably pay for them to be made with a higher quality, but I don't need to have gold plated contacts or super flat components. I'm not using surface mount components right now.

Plugged it in, and it works! Hooray! I learned a couple of things from making it and testing it. Next version, 0.9 (which is completed on upverter here) will have a few tweaks to the board, along with the headband board, so that it is easier to make and add the cables to. 

Now I just need to build enough of them to play test. I'll then have to make some cases, which will be the next part of the build. Along with updating the code. Right now, there are three classes that are functional: soldier, healer, and a base.