Initial Client Server Architecture

Yesterday I gave you an architectural challenge. I'm going to walk through my early thinking about the system architecture for this project to show how it's possible to define and isolate your unknowns so they don't become blocking problems.

The first consideration is that we need some central arbiter of game logic, in addition to all of the elements I've described in the requirements. This shapes up to be a pretty typical client-server relationship, with the server maintaining game state, while anything that the players interact with can be considered a client. For the moment, we'll just focus on these elements and not worry about lighting/sound/video control yet.

The puzzles in the arcade cabinets were played on the command line. We had to accept input from the keyboard, but also from some custom arcade controls that we wired into the Raspberry Pis. Raspberry Pis are meant to be hacked in this way by exposing what are known as GPIO pins, which stands for General Purpose Input/Output. These pins are for taking input from the user or sending output to other devices such as LEDs or relays.

There are many libraries available for interacting with these pins, and the interactions become events you can listen for in your code, just like keystrokes or mouse clicks. This allows us to abstract away a lot of the implementation into a few different classes of problems. Button presses and LEDs become their own classes with known interfaces, configured to operate on specific GPIO pins.

There's one major limitation though. In order to access GPIO, you have to run your process from the operating system, not from a browser. For that reason, the command-line nature of the terminal puzzles was a benefit. My client application running on the terminal could interact directly with the arcade controls, and communicate with the server over a websocket connection, and paint the UI to the screen, all as one process.

But what if I wanted to run the client in a browser? How could I have a browser application, and take inputs from GPIO pins, and communicate with the game server? I'll give you a hint: the terms "client" and "server" are fairly fluid roles. An individual machine can host either or both, and an individual process can act as either one depending on the moment.

Think about it. More tomorrow.

Next Up:
Client and Server are Just Roles

Previously:
Could you build this?