Multi-Screen Multiplayer: The Unusual Architecture Of The JEOZ Engine

Or: “Why on Earth are you building a new game engine?!”

One of the main reasons is that it seems no game engine is built quite like this from the ground up. Upon bootup, the JEOZ Engine can optionally start a second copy of itself in the background in “server mode”, which I call the “Hub”.

You can’t have two Windows running OpenGL on two screens without running two apps: One Windows app can only have one OpenGL process. So the idea of having separate players on each monitor is only possible through a local “network” on one machine.

Many multi-player networking systems, such as classic Doom, operate by running the GameWorld on the server. Each player is actually a “dumb terminal” client. Your inputs are sent to the server, which handles the game logic, and then tells your system where you and everyone else is in the GameWorld. That way you’re not running around freely, while the server copy of “you” is stuck somewhere, and that “you” gets shot in the head, and suddenly you drop dead for no good reason.

So in the JEOZ Engine, the inputs will all be sent from each client app to the Hub app, which handles updating the GameWorld. This is how I will handle multi-threading between the Update and Render stages of the GameLoop.

The Client receives network data on another thread, which has access to update the game objects while other objects are being drawn in the main thread. But all of the logic will be handled in the Hub, which won’t be drawing much, and therefore run at a more consistent speed.

By running two separate processes, this forces Windows to handle processing over multiple cores on a higher level than multiple threads within a single process. I don’t know how much of a performance gain this means, but that’s not really the point. And as I said earlier, this is optional, the engine can still run as one process.

One benefit of this system is that all forms of networking, even instant localhost networking, have some amount of inherent latency in them. By designing the single-player game to involve a networking Hub, some of that latency will be included in designing the game logic. The difference between single and multi player won’t be so drastic.

The overall goal is simple. It is technically possible for one Windows PC to have one game running on a ridiculous number of monitors, with an absurd amount of GamePads.

So this is mostly just a big crazy experiment, but I feel it’s worth pursuing. And I’m deciding that based on developing this on an old 3.0 ghz quad-core PC I built in 2010, with a budget video board made in 2014. If I feel that I can actually get this working with this kind of hardware, of course it’s possible.

But we’re gonna need GamePads. Lots of GamePads.

No one’s ever done anything like this before.

That’s why it’s going to work.

Leave a Reply