I'm thinking through a re-design of how players can select their team and class. While I do have a base that players can use to change their class and team, I'd like players to be able to utilize as much of the game as possible without needing a base. And so that's the main requirement.

In addition to that requirement, there is a constraint. Players should not be able to change their class while they have health, or in the first few seconds of starting up their device. This is primarily going to be controlled by the software, so that shouldn't be too difficult for any of the solutions below.

From there, I have a couple of objectives that I'd like the design to optimize:

• Ease of use - it should be easy to change classes
• Ease of expansion - There should be the ability to expand classes (and teams) in the future without a hardware change
• Cost - shouldn't add too much extra hardware (relative to the other options, none of this hardware is actually very expensive)

Here are the options (at least, the ones I could think of for now) for how to let a user select their team and class, and how I rate them on how well they meet these objectives:

And now for a little explanation of each:

Potentiometer

I'm currently using a potentiometer with labels around it on the circuit board. Just point the potentiometer to the class you want to play, and when you reset your device, you start the game as that class and team. Because the labels are on the board, it's not easy for someone to add classes or teams to the game and have those classes or teams be selectable with the potentiometer.

Menu with Button Select

This would be similar to how a digital wrist watch works. On startup, you can push a button to change your class, or another to change your team. You have a few seconds to do so. This means that every time you reset your device, you will have to select your team and class again, as it doesn't save. Not having the selection carry over is a little more annoying than the potentiometer, but that may be fine. 

This could also let players select the number of lives that they start with, which could be a fun addition to the game.

Rotary Encoder

Similar to the potentiometer, I can use a rotary encoder to allow users to select their team and class. This would also require a menu on the screen, since the rotary encoder can continuously rotate, so you'd have to have the encoder scroll through items on a screen, similarly to how the menu with button select would work. It's more expensive and takes more pins than buttons, and provides the same functionality as buttons. But it is cool. 

Voltage Divider 

Let people plug different resistors into the board and have the arduino read the voltage. This requires that players swap out resistors on their board whenever they want to change teams or classes. This can cause quite a headache to look up the resistor values you want, find the resistors, plug them in, realize you lost the ones you need, etc. 

It's very expandable, but it isn't very easy for the user.

Shift Register

I can add more inputs and have someone select their class and/or team using a shift register, which is detailed here. Then I could add a button for each class and a button for each team. But, then again, you'd need space for new classes and teams that are introduced later, or this would just let you have a keypad or lots of buttons to control a menu screen where you can change your class and/or team at the same time. It would be cool, but it doesn't seem worth it when there are simpler options that do the same thing. 

Conclusion

Voltage divider isn't easy to use, so that's out. Shift register, rotary encoder and buttons all need a menu, and the buttons are the simplest of that group. So that leaves controlling your class and team with buttons and a menu on the OLED screen or with a potentiometer. The trade off is ease of use vs the ability to add more classes and teams in the future. It's easier to tell someone to turn a knob to point at the team you want to play, but you can't add new teams easily (since the teams are printed on the circuit board, and you'd need to put new labels on the board to get new teams). With a button, you can easily push it to change teams or your class, but you have to do it every time you restart. If you are playing with teams, you don't want to have to reset your team and your class every time. So, why not both?

The number of teams is most likely not going to change in the future. People can add more teams, but you would need to modify the tag protocol to do so, which would require a lot of knowledge of the system and how it works. Plus, I don't like the idea of having to change your team every time you reset your device. 

The number of classes is probably going to change in the future. For that reason, using a method that allows you to expand what you can select is a good thing. Hence, using a button that changes your class and displays it on the OLED at startup. 

The downside of having your class be determined with a button while your team is determined by a potentiometer is that the player now has to learn more information to play the game. Instead of learning one system, they have to learn two. The trade-off here is, once again, how easy it is to pick up and play the game versus how easy it is to expand upon. I think in this case, I'm going to go with how easy it is to expand upon. At the start of each game, players can select their class with a button and their team with a potentiometer. I think that strikes a good balance between my objectives.