Bonus ROM: How an emulator can add multiplayer to a singleplayer game

Rich Whitehouse is doing things with an emulator I’ve never seen before — for a system that’s never been properly emulated before. Over the course of this year, his emulator BigPEmu for the Atari Jaguar has grown into one of the most impressive projects in the scene, as Rich has built upon a foundation he created for Digital Eclipse’s Atari 50 anniversary collection.

When Rich added support for the Atari Jaguar’s VR headset to BigPEmu — a prototype ‘90s VR headset that never saw the light of day — I wrote in a previous ROM that he “apparently has a niche, and that niche is creating things that literally should not be possible.” I still didn’t see this coming, though: a recent update to BigPEmu added 32-player multiplayer support to the Jaguar’s Alien vs Predator — a singleplayer game.

It’s impressive enough when emulators are able to take local multiplayer online (BigPEmu also does that, by the way); but creating multiplayer in a game that never supported it? I had to figure out what the heck was going on, so I talked to Rich for this bonus newsletter.

The heart of this new feature — and many other impressive things BigPEmu is capable of — is a scripting system that anyone can use to “easily set breakpoints, read/write memory, and more or less do anything you could want to do to the emulated machine through easy-to-use script code.” The website details that scripting “enables TAS, achievements, stereoscopic rendering, native-resolution rendering, and many other features.”

If you’re interested in supporting Rich’s pioneering emulation work and helping him deal with some hefty medical bills, consider backing him on Patreon. That support is the reason BigPEmu exists, and continues to get amazing features that could one day influence what other emulators are capable of, too.

Now here’s Rich talking about how he built AvP’s multiplayer — his answers were engaging enough and easy enough to follow that I’ve laid them out as a Q&A, lightly condensed and edited for clarity.

You've been adding a lot of features and functionality to BigPEmu, but what gave you the idea to just, make multiplayer for AvP, a game that didn't have it?

“I liked the idea, fundamentally, of adding some radically new functionality to a game entirely through the scripting system. So I gave it a bit of thought, and had a whole bunch of different ideas for a lot of different games. Writing AvP multiplayer is the one that stuck for me. It's a much-beloved title in the Jaguar library, and I'm generally a fan of cooperative experiences. Part of me wanted to be lazy and bite off something a little smaller, but after arguing with myself, the more adventurous part won. I'm always hoping someone else will come along and start applying this stuff to other games as well, and I thought this would be a nice way to implement some robust networking functionality for the script interface and really put it to the test.

I know that at least one Jaguar developer is planning to leverage it in their own work, and that makes me happy. I won't say who it is, in case they want to surprise everyone themselves at some point.”

A lot of emulator developers follow wherever their interest leads, since there's always so much work they could be doing. Why this multiplayer?

“I really enjoy the creative aspects of software emulation, and that's more of a divisive idea in emulation than it should be. Some people are purists, and the very idea of enhancing old games rouses them to anger. I understand their feelings, but it's silly to take an absolute stance like that. It gets into the whole FPGA versus software debate as well. Each approach has a lot of value, because the strengths and weaknesses in each approach are so different. I've seen some silly ego competitions in recent years, with people asserting supremacy in one domain or another, and that whole narrative is really just harmful. It kills ideas instead of inspiring them.

So in writing a software emulator, it was natural for me to think about how to really leverage the native hardware across a wide variety of target platforms, and do things that would otherwise be problematic or cost-prohibitive to do. Just like there are things that you can do trivially with an FPGA-based approach (like emulating complex bus priorities) that are computationally cost-prohibitive in software, it really goes both ways. I also wanted to make the sort of system that I've often wished I had while reverse engineering and/or modifying old games, so that's been a driving force behind developing the emulator's scripting system. A small but powerful core API like that can make seemingly-impossible tasks seem a lot more possible.”

Forgive me for the non-programmer question, but would you call this a mod for AvP? Maybe it's just semantics, but you're not actually modifying the AvP rom at all, right?

“Yeah, it's operating with the unmodified retail binary. It's a really convenient approach, if you don't mind tying the functionality to a particular emulator like this. So it does come down to semantics, and you have to ask the question of whether something should be called a mod if it's adding more functionality than it's modifying. I'd say it's something like an add-on, which happens to leverage functionality that doesn't exist in the hardware universe.”

You mentioned in your video overview that you found some source code online for AvP. Was that critical to making this work? How repeatable is it for other Jaguar games — and which would you like to see multiplayer in next?

“The networking script code is pretty reusable, and a lot of it can apply to any game! The per-game work is in figuring out where to hook into the existing binary, the data you need to synchronize over the network, how to read that data on one end, and how to apply it on the other end. Then you have to figure out how to do that without the game exploding on you. That's especially hard to do when you're working in nothing but a sea of disassembly. Having that source code to AvP as a reference did make the job much easier than it would've otherwise been, but the source I was able to find doesn't match the retail binary and is missing quite a few bits. So the process still involved a great deal of sifting through disassembly and charting out code/data with the emulator's debugger.

Iron Soldier springs to mind right away. I think that could be a lot of fun, in the form of both deathmatch and coop, and my mind immediately starts running wild on new game modes. I haven't really looked into the internal structures of that one at all, so I have no idea how much work I'd be in for if I jumped into it.”

You worked on the multiplayer code for Star Wars Jedi Knight 2: Jedi Outcast, right? Did you bust out some old skills while scripting this AvP multiplayer?

“Haha, man, I had no idea what I was doing in those days. But I did actually employ a system here which automatically compresses chunks of data using unique IDs, to make it really easy to just throw huge amounts of data at the network API from script code. The stuff behind the scenes copes with it, using delta compression to reduce the amount of data going over the network. So it is actually kind of like a much more flexible version of Quake 3's old entity state delta compression.

JK2 used a modified (rather heavily in some areas) Quake 3 engine, for all the younglings out there. My thinking is definitely still influenced by some of those old concepts. To go off on a little bit of a tangent, there's a trend in software development of greater power (in terms of things like memory, processing power, and network bandwidth) leading to greater inefficiency. We like to justify that by saying there are trade-offs in usability and such. But you can get so much more out of hardware if you follow some of the Old Ways, and doing that doesn't necessarily have to come with usability or maintainability trade-offs. I think Unity and Unreal have both established some negative trends there, and you end up with penalties in various categories (like load time) because of the fundamentally inefficient design choices in those engines for things like data serialization.”

Do you have plans to do more with the scripting you used to create AvP's multiplayer to enhance other Jaguar games in other ways? What are the limits of what you're able to modify this way?

“I really think it's limitless, and eventually BigPEmu's scripting system will open a wormhole into the Mirror Universe. Silliness aside, though, the system that's in place at this point can facilitate just about anything you could hope to do with a Jaguar game.

It seems like no one had ever really considered things like the native 3D rendering employed with BigPEmu's Cybermorph script … That turned out to be another system that suddenly makes seemingly-impossible things almost trivial. The ability to open those doors is what makes software emulation really shine for me. So I do want to have some more fun working with this system and thinking of ways to pump new life into more Jaguar games. There's also a certain satisfaction in taking an experience that seems terrible or barely playable, and flipping some switches to make it really enjoyable.”