Yesterday a handful of Mini Micro users hung out online and chatted for a bit, while chasing each other around the screen and otherwise goofing off. What makes this unusual is: we did this in Mini Micro.
The Mini Micro API (application programming interface) has only a single approach to networking: an http class, which lets you get or post (or put or delete) to a web URL. I've always said that would be enough to make many kinds of multiplayer games, if you can also make a simple server to handle the http requests. But not a lot of Mini Micro devs have made use of it.
So, I decided to make a quick demonstration. I wanted something that would be a good starter for an Among Us-style imposter game, or a small MMO, where players can chat and move around on a map.
You can download the code and play with it from the GitHub repo. It consists of two parts:
1. The server (Go)
I chose Go because it's a relatively simple, modern language (like MiniScript in that respect), but (unlike MiniScript) it's strongly typed and fully compiles to machine code. It can even cross-compile, meaning that I can test the code on my Mac, then (right on my Mac) build it for Linux, and just upload a single-file executable to my Linux server. The Linux box doesn't even need to have Go installed! So Go is both efficient and convenient for the server code.
2. The client (MiniScript)
The client code is written in MiniScript and runs in Mini Micro. To do my test, I just dragged the MiniScript file (under 300 lines) into Discord and said "hey everybody, help me out and run this in Mini Micro!" (People felt safe doing that because (1) it's hard-to-impossible for a program in Mini Micro to do anything to your system outside of whatever folder you mount, and (2) they could read the code before running it.)
With the server running, anybody can then run the client code in Mini Micro, type in their name, and presto — they appear in the game world, able to move around and chat with anyone else online.
How it works
The system is based on polling, normally about once per second (possibly faster when you click). These polls can send a command to the server, or they can just ask for the latest events. There are only two commands: "move" (sent when you click a location to move there), and "chat" (sent when you press Return after entering a chat message). Those commands become new events on the event queue, and get sent out to other players when they next poll.
And that's basically it. The client does some smoothing, to hide the fact that updates are coming in with up to a second delay. It works surprisingly well. We were able to move around and chat with no problem.
The key to this success is designing the game so that the frequency of commands (input changes) is low. I chose a click-to-move design because you can move clear across the screen with a single click. If we used gamepad directional movement, it would be much worse; we'd have to send an update every time the controls changed state, which could be many times per second.
As it is, with six players, the server is getting hit with about 6 requests per second. A lightweight, in-memory Go server like this should be able to handle thousands of requests per second. So, this approach would scale decently to the number of players a small indie game is likely to ever see.
The one hitch in our get-along
There is one little thing I don't love about this. Our http calls are synchronous, meaning that your script stops on the http.put call and waits for the result before proceeding with the next statement. Our demo measures the round-trip time (RTT), and most of us were seeing 80-130 ms or so. That's 5-8 frames, during which the game can't update any animation, every second.
The app hides this stutter by moving things at a constant real speed, independent of the frame rate. But when you pay attention you can still see it as a little jump. And of course on occasion, the freeze is longer.
This would be cleanly solved if we had an "asynchronous" option for our http calls. That's now a feature request for Mini Micro 2.
However, it's a relatively minor problem, and I would encourage you not to let it stop you. You can minimize it now, like this demo does, and then eliminate it completely when Mini Micro 2 comes out (probably around the end of the year).
Go forth and create!
If you have an idea for a multiplayer game, and it does not require many updates per second — like most turn-based games, anything that's mostly chat, or even simple movement like in this demo — then you now have no excuse. The demo code is in the public domain; you are free to use it, adapt it, and build on it however you wish.
So get out there and create some cool multiplayer experiences for Mini Micro! And be sure to send me an invitation. I'll see you online!
Top comments (0)