Robots in the Cloud

The WARoS engine is deliberately designed as a module that you can use from any kind of code. If this were published as a public crate on crates.io, you could declare a dependency on it in any application you’re writing and immediately gain the ability to run multi-player WebAssembly combat matches on demand.

If you wanted to expose this as a cloud offering, you’re only a few steps away. You could build a website that allows developers to upload their own robot modules, and then the website could hold randomly chosen matches between stored robots. If you wanted to get really fancy, you could create a logger (just a Receiver half of a channel) that, instead of displaying events to the console, emits them to a message broker like NATS, RabbitMQ, or Kafka. You could then have a web page listening on web sockets for events, rendering matches in real time for live spectators.

The possibilities are endless—leader boards, competitions, prizes, achievements, even different kinds of battlefields with obstacles and barriers other than simple walls at the edge. I would love to spend months coding all of that, but this book is about WebAssembly, so I (and my editor) had to draw the line somewhere.

If you’re as into distributed systems as I am, one could even imagine a cluster in which a match execution service had been deployed, awaiting signals from a message broker to begin a match. As a match begins, it emits events back to the broker, which could be listened to by a scribe service (recording matches for posterity), a projector service (updating live state of each robot and match), and to a real-time spectator service responsible for delivering updates on matches straight to browser clients.