We recently built a retro arcade as an Alloverse Place — complete with Street Fighter II, shuffleboard noises, and the smell of popcorn.
The key to this experience is of course the arcade machine itself — it’s an AlloApp, a piece of software emulating games from the 80s and 90s.
In part 1 of this blog post series, we focused on the process and team experience of building a fun hack project together.
This, part 2, post focuses on an overview of the juicy technical bits. how were we able to run a SNES emulator in a collaborative environment? Is this something you could do yourself with something like Unity/Unreal? Can we teach you how to do it?
The answers are: through magic; only with extreme effort; and yes we can and we will!
In part 3 and on, you’ll actually get a code tutorial to build your very own arcade.
Technical overview: What are we building?
As a recap, an AlloApp is a 3D thing running inside an Alloverse Place. Unlike other VR apps, an AlloApp doesn’t take over your entire experience (think: Beat Saber, taking over the entire environment, soundscape, hand behavior, etc to give you a holistic and immersive experience), but rather runs alongside your experience (think: a widget, tool, decoration or other thing in your environment). If you’d like to dive deeper into what and how an AlloApp is, try out our Getting Started guide, or perhaps our Architecture documentation.
Here’s an architecture block diagram of the project:
LibRetro/RetroArch
The first piece of tech involved is LibRetro from RetroArch. This is a project to consolidate all retro game console emulators under a single umbrella.
RetroArch is a end-user app you can run to emulate pretty much anything. They do this by wrapping all the regular emulators as libraries, and calling them “cores”. For example, the popular Super Nintendo emulator Snes9X has been made into a core that can be loaded into RetroArch to play Super Nintendo games.
LibRetro, then is the library implementing all the core abstractions. It can be reused to build your own emulator front-end. Which is what we’re doing!
LibRetro is unusual in that it has two separate API surfaces:
- It has an interface “downwards” into emulator cores. Each core, such as the Snes9X core, has to reply to API calls to “perform a step of emulation”, “give me the pixels on screen right now”, “Call this callback every time there is new audio to be played”, “these buttons are pressed on player 1’s controller”, “save your save games here”, and so on.
- It has an interface “upwards” towards some sort of user interface. The standard user interface is of course RetroArch, which might be running on your computer, on a set-top box, or some portable Android-based game console. This interface doesn’t have to know anything about any specific emulator. It’ll just tell libretro, “please play this game the user selected, using the standard core for taht kind of game, and here are the controllers. Give me the audio and video when the core has them”. This is the same whether it’s emulating NES, Amiga or Playstation 2.
Allonet/AlloUI
The next layer is the Alloverse specific libraries.
Allonet is our C library abstracting out network communication, audio and video transfer, and world syncing. We’ll be sending the audio, video and controller data through this pipe, as a bridge between libretro and the user.
AlloUI is an abstraction on top of allonet, providing something that looks like a high-level front-end UI framework; but it’s actually just a layer to talk to Placeserv and visor apps, which are the the pieces of software actually providing the user interaction. We’ll be using this to build a user interface for the user.
Flynncade
Finally, the project “Flynncade” wraps LibRetro and builds an AlloUI interface on top of it.
The emulated screen’s pixels are sent as a video stream to placeserv and then forwarded to all the users looking at the arcade
The same for the emulated sound.
The user’s controllers are interpreted by this code and converted to a SNES controller’s input, and sent to LibRetro. In VR, we’ll steal all the face buttons on the user’s left and right Quest controllers, and map those to a standard “snes/playstation” style controller. In 2D, we’ll steal the keyboard and use that for input.
Then there’s also code to make the arcade machine usable and pretty:
- The 3D model of the arcade cabinet has a swappable texture to match the game being played
- There are buttons to get help, choose game, change sound volume, read more about games, etc.
That’s it for part 2! Next time, we’ll get to building! But you’re of course more than welcome to try on your own and let us know how it went by joining our discord!
