Halo inspired laser tag (LTTO hack)

I 3D printed a docking station for the guns that also enables 5V charging. I mounted it inside a custom sized box that also houses the base stations inside the lid. 8 guns per box. Also, the base stations now mount directly to the walls at my church. They used to be mounted at the end of telescoping marshmallow sticks that attached to the 5V wall charger. The purpose for this change was to get the bases above your head so you couldn't stand in front of it and block it from other players. 

I drastically improved the way mass messages are shared across the whole system by using (what I'm calling) the round robin method. There is a single path from base to base that goes in a big circle around the whole church. When a base needs to share a message with the whole system, it sends the message tagged as a round robin message, and only sends it to the next base in the circle. It then waits for the message to come back. This process takes less that 50ms and is quite stable. 

I've fixed the way weapons and items are distributed throughout the game. At edit, you can determine how many are available, how quickly the respawn after pickup, what percentage of the game must pass before the item is revealed, whether or not the item is distributed randomly after respawn, or if it should only go to specific bases. 

Radar is now an item that can be picked up. it reveals on the map where items are and where enemies are. 

On April 10th my wife gave birth to our second born, so play testing is slowed but I still find time to make minor code updates every now and then. I would say that the first game mode (Team Slayer) is nearly complete, and I'm wanting to start working on capture the flag next. 

Milestone reached: arsenal doubled from 8 to 16.

I'm currently spending all my laser tag dev time building up 8 more guns, but I had this quick idea to make an add-on graphic display so the bases can show what items they currently have available for pick up. It's hard to get a good picture - it looks really good in person, and the different colors are visible from far away. It's easy to implement and will allow player to rely less on the tiny map icons to know where stuff is to pick up. I can also add one more item - I think it's going to be radar. 

If your project code isn't currently being tracked with version control like git, it's time to start. I was able to go back through my log and find the bug that caused my "terrible playtest". It was actually quite a simple bug that broke everything and caused a very complicated result. The real REAL root cause of the issue was terrible engineering practices by me. In my radio communication scheme, I have 3 different versions of almost the same message for distributing the game rules. I added a feature and forgot to update just one of those 3 messages. What I ought to do is simplify this messaging system down to one somehow to make updates and new features easier to implement. 

A couple more code improvements after perusing the base code, everything is back to being fast and stable. 

I was testing the rocket launchers with some friends and discovered that the antenna strength of the bases are not the same. This is kind of an issue because I'm trying to make the blast radius consistent. What I decided to do instead was use the radar on the map to determine how far away you are from a blast. If this works, then I can also confine explosions to whatever room the are in too. 

While testing weapon pickup and radar, I discovered that with 8 players there is too much radio congestion to have reliable weapon pickup, so I'm going to table that feature for now and think of a better way to share every player's location in a more efficient way.  (edit: this was also due to a bug. while experimenting with how quickly/how often the location finding algorithm worked, I inadvertently also increased the radio traffic. this was easily fixed and I think I might still have multiplayer radar available) 

Sometimes, everything works, everything is great, you feel like you're almost there, and then other times nothing works, everything is broken, and you feel like you need to start over. 
I had a terrible playtest after two awesome playtests that made me feel I needed to rethink my radio messaging scheme from the ground up. Right now, it's basically a shouting match. I got to this point by just barely getting things to work - if a critical message wasn't getting through, just send it 4 times instead of one, there are tons of delays based on arbitrary values (note: they're actually "delayAndRead()" functions that read the radio while waiting). There are a bunch of retries, there's no real sense of priority in the messaging system, and there is no coordination. 
I think what I need to do is attempt to coordinate all radio nodes to time slices. There's a fixed number of radio nodes, 10 bases and up to 32 players. So I think I can get away with 42 time slots spaced at 10ms. Need to do a lot of testing to see if that window is big enough, but I feel like it's more than enough. My hope is that this new method brings about stability into the system and I can reduce the retries and the redundant messaging. 

R&D can have big setbacks like this, but it's important to remember lessons learned. Have no fear of doing something wrong the first time - even if it means having to redo it later. 

using map icons to display all teams at once

I got to root cause for one of my more frustrating stability bugs. The culprit was noise generated by the large vibration motor being in close proximity to my radio antenna. These large voltage spikes on the battery voltage rail were causing the radio to become unresponsive to receive messages and in more extreme cases causing it to lock up and freeze the program. My current work around it to try and keep the battery voltage bus far away from the radio and antenna inside the gun, but I think I will be moving the motors to dedicated motor driver ICs that appear to do a better job of keeping the voltage rail clean.

The function button on the side of the gun was feeling pretty useless, and I really wanted to fit a joystick with a center button in that hole somehow. I was very fortunate to find a cheap 5-way nav switch that fit. However, I didn't want to run extra wires down the length of the gun. I was able to still fully use all 5 switches on one wire buy making a resistor divider network and reading in the voltage at each node.  The switch fits on a small oshpark pcb I designed.

This worked so well, and was so much cheaper and easier to build that I also decided to scrap the analog joystick and extra buttons on the main control panel for a second one of these. 10 switches on only 2 wires! This only works well in this case because the switch physically prevents you from actuating more than one switch at a time.
PCB: https://oshpark.com/shared_projects/1sKpkusr