This is a social arcade bar game made with Arduino. The idea behind the game was that players would be able to use a drink as their credit to play. Once their drink is gone they can’t play anymore and someone else can take their place. Games on Bierbaas were designed with the possibility of a drinking game in mind, which resulted in all the games only having a single loser, instead of a winner.
The game was created as part of a school project. It is a tabletop 4 player arcade machine with a 64×64 3 color display. The entire machine is powered by a single Arduino Mega. It plays 14 different games in a randomized rotation, these games are based on old arcade games.
The system was meant to increase social cohesion in a bar scenario, by creating a place for people to meet while doing an activity, but also having a reason for them to leave that situation to create a rotation of people. We didn’t want to have the traditional coin slot, because we wanted to reduce the barrier of entry to the minimum, which is why we chose to have the drink, that you are likely to have in a bar, as the game credit.
We chose a 64×64 display because we wanted to go more retro than retro and to try to capture that feeling people had when they saw the original Pong for the first time back in the day. The size of the pixels and the amount of light generated creates a flickering red glow that gets people’s attention very easily.
The biggest challenge was the Arduino Mega’s tiny amount of processing power. I didn’t want to have a separate controller for the screen, since that would increase the cost, but with the screen having to update at a rate of at least 100hz to make it look like the pixels were not flickering this seemed close to impossible. After doing some research I figured out that using the official Arduino way of shifting the data to the screen was highly inefficient. Every update of the screen was taking about 30ms at this point, which is about a third of the minimum speed we needed, while it was only displaying random data at the time. Once I found out I could talk to the pins on the chip directly without any unnecessary safety checks, the amount of time needed for a single update dropped to about 5ms. Which meant we were now in the viable range, but it didn’t leave too much space for actual game logic. After some more poking and prodding at the code I created an improved system that would only change the values it was going to write to the screen when it actually needed to, instead of writing the pixel value for each pixel seperately. With this in place the average time it took for a single update dropped again, but this time to less than 0.5ms. This made sure even the most complex game we had thought up at the time could run at 300hz.
