Invasion of the Energy Monsters is a project that I’ve been working on for two years now, first as work with a professor, and now as a free-time project.

The Game

Energy Monsters started as an educational game where two teams (Human Heros and Energy Monsters) faced off in a “haunted” house composed of individual room tiles. Energy Monsters played cards to attack, or turn on appliances in rooms and grow stronger on the “wasted electricity”. Humans could then turn the same appliances off to save electricity and turn the tides in their favor before their own attacks. The lab saw some commercial potential in the game and I was told: “Well right now it’s pretty fun, but it’s not really fun”.
I set out to make it really fun.

The Rules

I played Energy Monsters constantly, with every friend that I could recruit, and tweaked the rules. I gradually discovered that the game could be stalled out by either team, and there wasn’t enough speed to the game by having teams only play cards (often in far-away rooms) to shift the playing field. So, I implemented my first major rule change: when a monster entered the room, it automatically turned on the “lights” in that room and added 50 watts of wasted electricity. When a human entered a room, they automatically turned any “on” lights off, and reduced wattage by 50. Read my first updated version of the rules here.
This added chase element made the game much more exciting to play. Players always had a move they could make, even if it was just turning off or on some lights while they bided their time for a bigger play.

The Problem

As with most things, with the new solution came a new problem. players were having to flip over multiples tiles every turn to signify that lights were on or off in specific rooms. This drastically slowed the game down and was annoying. Using tokens or the like to signify “lights on” was no better because it cluttered up the board. The new lights rule also meant that players had to be adding and subtracting small amounts of wattage to the spinner every turn, which was tedious. I set out to solve all of these problems.

The Board

My idea was to build a board that the tiles would sit on. I wanted to use magnets in the pieces to trigger LEDs in the board to turn on or off depending on whether the piece was a monster or a human. I set off learning about circuits, an area I knew nothing about, and finally came to a solution. Using magnetic-field-sensing hall effect sensors connected to an arduino, and magnets in the playing pieces oriented towards different polarities, I was able to make pieces turn on and off lights in each room, and automatically track the change in wattage with the arduino. The feedback was instant and very satisfying.
This process was a journey though. There aren’t enough pins in the Arduino to manage all of the sensors and lights on the 5x3 board. Once I managed my goal with just a couple rooms I had to learn about and implement multiplexors for the sensors. The LEDs needed different multiplexors because they need to hold their state even after the player’s magnetized piece moved to a different tile. Magnetizing the pieces themselves was also a challenge. I solved it by 3d-printing a hollow space into the token, droping the magnet in, and 3d-printing the space closed. Now the board tracks players paths as they move about, and dynamically updates the house wattage from the lights. I was published for my work with the board, and demoed it at the Games+Learning+Society Conference in Madison this past August, where our team won 1st prize.

The Future

Another prototype is already underway that will add wifi connectivity to the board. After that, I plan on approaching a way to track the use and play of the cards themselves. Using an RFID reader and an antennae array, I hope to identify individual pieces (by adding RFID chips to them) and where they are on the board when at rest. Because RFID takes a few seconds, the hall-effect systems will still be needed to track movement. I will also add RFID chips to the cards themselves, and create a discard section of the board where cards are played. This way, when a person plays a card, the board itself will be able to determine where the respective piece is, and if the play is legal. If it is, the board will be able to alter the wattage accordingly on the house. In this way, all of the wattage tracking will be taken care of automatically and digitally, and the players can focus on the fun of the game, and still get the satisfaction of spinning a real spinner, rolling real die, and moving real pieces. This connection of digital convenience with physical feedback and motion is where I think all boardgame design is destined to end up.

In winter of 2015 I co-founded a startup called BabyNinja. We learned that pediatricians require parents to track information about a baby's feeding, sleeping, and bowel movements. Seeing the need, we created an iPhone and Apple Watch app (right before the Apple Watch was released) that allowed parents to track all of these with only two taps on their Apple Watch.

As a commited member of the nerd community, I love Settlers of Catan. After playing with my friends one night I was struck with the idea that a computer could do it better. I recruited my buddy Mark Langer, and together we began the Catan-AI project.

Gameplay

Long before beginning any actual artificial intelligence, we needed to code in actual gameplay. We really wanted to make an AI that we could use to play actual Catan against human players at a table (not making people play Catan on a screen). So we've been building out the system as a state machine. As things happen on the board, we inform A.A.R.O.N. of them via terminal inputs. Then, when it's the AI's turn it will output a move (or purchase, trade proposal, etc.) A major challenge of this was coding in the board (which changes every game). We settled on a grid system with nodes at each location so that we could quickly type in a set of tiles (read from left to right and top down) which would inform properties of each node connected to the tile.

We recetly iterated on this node design and are putting another grid overtop of it, a broader ABC123 similar to Chess, to make entering updates easier on us.

Current Work

The structure of the board and the objects that will be used have all been built. We're now nearing the end of programming in all actions that people can take. This is easier said than done. We need to be able to tell the AI when trades have been made, when exchanges happen, when longest road or largest army change hands, etc. The more we code the more we are learning the number of human nuances and actions in this game that we take for granted and aren't in the rules. All the more challenging and exciting.

The Pain Point

To me, programming has always been about making machines do things for us so that we don't need to do them for ourselves. When I was studying for, and taking, coding interviews, I fould myself constantly referencing and re-building the same basic data structures, such as graphs or trees. I got tired of building the same directed graph class over and over again to solve a variety of different interview questions, so decided to make a package for it.

The Reasoning

This immediately begs the question: "why didn't you just download one of the many existing data structures packages for python?" The answer is that they are all much too complicated for coding interviews. I wanted just the bare-bones objects that I could modify for each different question, and easily explain every part of to an interviewer. This is what I got with campyStructs.

The Results

I thought some interviewers wouldn't allow it, but it turns out most good interviewers tend to be more focused on the fact that you know the structure to use and how to use it than that you can build a Graph class as quickly as possible before actually solving the problem.