We’re really excited to show you the progress we’ve made in the last few months, which mostly involved implementing the multiplayer arcade itself. This will be the meat of the game for most people, visiting one of many player-managed virtual arcades to play user created arcade games, spectate other players, compete for highscores or win tokens and collectibles.

Players that enjoy management simulation games might decide to host their own arcade. This will involve (among other things) designing the layout, purchasing games and decorations with virtual currency, and attempting to maximize revenue by providing a compelling experience for other players.

The last mode of play is content creation. Our main focus here is to allow you to write your own arcade games, but we also hope to let players design decorations and collectible items too. We imagine that being able to easily share the games you create with friends will be a great motivator for those who wish to dabble in programming and game development, and we’re excited to see what you can come up with!

Arcade Interiors (Layla)

We finally have the game loading room geometry made using the room editor! The materials and lighting aren’t final but it’s nice to have some geometry to run around in.

I added neon light strips around the room for basic lighting but you’ll be able to place neon lights wherever you want.

Here’s an overview of the interior inside the editor.

Cabinet Security & Networking (James)

Something that had been bugging me for a while was the potential security concerns caused by running user-written arcade games on players’ machines. At the moment games are written in C#, and up until recently it would have been possible for developers to write malicious code that could do nasty things to your file system or install unwanted software. The standard solution is to run user code in a safe environment where it can’t do any damage, which is known as sandboxing.

A big hurdle with sandboxing arcade game code was that all communication between the host environment and the sandbox has to be marshalled, which can be costly to performance. To minimize this problem I’ve refactored the cabinet framework to organize all communication into two bursts; one that is sent to the sandboxed code at the start of an update containing information like player inputs, and then another sent from the sandboxed code when it is done processing a frame, which contains a minimal representation of the graphics to draw and sounds to play.

This refactoring has two other major benefits besides improving the performance of individual sandboxed game instances. This architecture makes it very easy to run each game instance in a separate thread, so maintaining a large number of cabinets simultaneously is more feasible. Secondly, the graphics and audio data stream sent from the sandboxed game can also be routed to other players on a network, making streaming games to spectators very easy to set up after sandboxing was implemented.

Cabinet Game: Zombie RTS (Ryleigh)

I’ve been working for awhile now (too long) on a single-player RTS / zombie survival game. I started out with the code for my SWAT game (whatever it’s called), took out all stuff about directly controlling a single unit, and went from there.

The thing I find interesting about it is the surprising amount of personality your units can occasionally display. In an RTS like Starcraft your units either attack and hit the enemy, or they don’t attack the enemy. There’s no chance that they do something unexpectedly helpful, or royally fuck up. In this zombie RTS your units sometimes unload a whole uzi clip without hitting the enemy right in front of them, or shoot their teammate in the face by accident when they’re just trying to help out.

I want to wrap it up soon, hopefully without rushing it at the end like I did with the SWAT game. I vowed I’d keep my scope on new games under control but I definitely went off the deep end on this one, adding a bunch of (fun) little details before even getting the core gameplay finished up. But the gameplay is almost where I want it to be: feeling satisfied that you’re barely microing your units well enough to keep them from killing eachother.

Physical Game: Basketball (Layla)

Our networking code makes it easy for us to make networked entities so I decided to make a physical ball machine game for the Arcade. The networking is simple because it’s only one player playing at one time. This game is similar to things like bowling and skeeball so you can expect to see them soon.

James wrote a useful glowy LCD shader that allowed me to display the scores on the ball machine screens. We can use this for any game that needs to display scores.

Here it is in action during our latest play test.

Physical game: Pool (James)

Layla looked like he was having a great time writing his physical game, so I had a go at writing a virtual pool table. After messing around with Blender for long enough, a simple replica of the office pool table appeared (I think I’ll stick to programming). Following that, I wrote a billiard ball shader that procedurally textures a sphere:

Next was the code. Since the game would ideally be networked between several players, I needed to find a nice way of making sure each player is sync. The solution I went for was to keep all the physics involved deterministic, and to send the state of the balls only when a player takes a shot. After a spectating player receives the table state they will start simulating the physics on their machine, and as everything is deterministic the system will evolve in the same way for everyone.

For extra fun I implemented the physics for ball collision responses myself, so that I could guarantee determinism and implement continuous collisions for extra accuracy. It seems to work well:

Just before our playtest I added a few features like a shot guide and a collector for potted balls:

At the moment I haven’t decided whether I’ll have the game enforce a certain ruleset (perhaps chosen by players before they break, or by the arcade owner on a per-table basis), or if I’ll leave it up to the players to stick to whatever rules they agree on. There could be issues with players griefing by interfering with ongoing matches, but that might be balanced by letting players play games with their own invented or obscure rules.