Cross-Engine - Let's discuss it!

Hello everyone!

Lately, I though about something that, from what I have barely been able to read about, seems like the ultimate taboo of video game development.

Ok. I'm exaggerating here. It's just that finding information on this kind of thing seems to be overly hard because any search engine will returns thousands of results on Cross-Platform instead of Cross-Engine. (It's over-saturated)

Normal, how many people think about using 2 different game engine for 1 project? Not many, but it does exist in some form or another. For example, you might never think about it that way, but that's the principle behind any game systems that uses a website that display in-game content such as the system used by EA with battlelog.battlefield.com or Bungie's Destiny 1 & 2 and the online access to the player's data via bungie.net

So using Flash to fetch something like a player's profile on a webpage while the game use a game engine is a basic example of Cross-Engine because both looks uses the same access information to fetch and upload their respective data.

So, how about other possible Cross-Engine? How about Unity <=> Unreal and Unity <=> CryEngine?

The first thing that comes to my mind as to why we rarely or ever see such a thing is because it's usually Flash and another Engine (since Flash is usually universal on every port) or because the Engine does the job for all the ports (or the game is simply not released on the port which doesn't work at an acceptable level.)

But, let's put this into another perspective... How about having a game made in something like CryEngine, Unreal or whatever engine, but with a complimented mobile app that add a whole new level of interaction. EA & DICE did that when they implemented the Commander management system via an app for phone and tablet while their game run on the FrostBite engine.

I'm posting this in the Network side of the forum because that's the main point that link Cross-Engine. One engine usually communicate with another engine via data fetching from a 3rd party that is usually a server. So I think this is more relevant to Network than anything else, but I'm also opening the discussion toward something more hardware-oriented.

Let's say you make a game in another Engine than Unity. The reasons can be many as each Engine has its pros and cons. (We're not here to discuss those. Leave that out of the discussion please.) Have any of you who are reading this ever though that you could implement Unity in a way that could enhance your project in a different way?

If so, what have you though about? What did you achieve or learned from it?
Let's discuss this!

---------------------------------------------------------------------------------------------------------

Now, about me and this discussion...

Now, here's why this crossed my mind and the idea stick in my brain like a damn tumor. (It's a bad joke. Sorry for anyone feeling or who have experienced something related to a brain tumor.) I even have lost some sleep because of it at some point. It pop up now and then and, now that I'm working on some personal-learning project that involve some hardware and Unity (even a Raspberry Pi 3), I'm thinking of experiencing something around the concept of Cross-Engine even if it's just for the fun of learning from it.

I got 3 ideas on which I'm currently thinking and planning. I only gives out those 2 ideas as possible subject of discussion if nobody reading this could think of something, but are interested to the subject.

1) Using Unity for an App to manage something like an inventory, trades and communication for a project I'm planning in Unreal. (I selected Unreal because the core of what I'm looking for is covered by it natively while I got to build it in Unity from the ground. It will also be my first official project in Unreal after tinkering with it for 2-3 years.) I'm still in the planning phase for this one. Nothing advanced yet.

2) Using Unity for the game Engine for a Brawler (Fighting + Platform) game on PC, and using Unity for an app that will allow direct access the player's inventory, communication and other online-only features of the game via mobile.
(You see, it's not just about something else than Unity, but also about using 2 completely different builts of Unity. You could consider Unity itself as multiple engines in a way.)

3) Using Unity for the game Engine and using a RaspBerry Pi3 with one of its possible game engines to create a special kind of high-tech controllers. This is not much Online-Network-related, due to how ambiguous the subject can be, I hope you forgive me for adding this in.
Anyone around remember Steel Battalion on the original XBox from 2002? Remember this "controller"?

It's kinda like an old dream of mine to create my own mech-like game and, while I'm currently planning such a thing, it's also part of the dream to make a special kind of controller for that game.
(All hardware would be optional, but possible.)

Basically, creating something close to a simulation platform that can display on up to 3 screens, one big "controller", a touchscreen on said Controller to manage some part of the simulation.

Of course, the game can't run on a Raspberry Pi and for 3 screen, we're talking high-end PCs if we want something of quality. Running the game on Unity, having the controller communicate via something like Bluetooth or through the WIFI/Router (like a LAN config). Especially since I want to implement a touch screen a bit like 2) above that allow the player to manage things in the game and maybe even being update with things from the game like a radar system. That's why I'm considering Bluetooth as maybe not optimal, but instead might uses something like the LAN/WIFI network approach (similar to what is used in the WiiU controller.)

The controller part is not a Commercial project. Too much risks of seeing some legal issue with the damn impossible-to-guess-or-even-check Patents issues that we see as raising in the recent years. I don't have the funds to cover my rear against patents trolls and hardware is one hell of a mine field for such thing. (Did you know that there are currently 4 patents for Time Traveling? Yep. That's goes as far as that.)

I shared this dream-like project as it's reflect another possibility from Cross-Engine.

Have you any experience in Cross-Engine features or have you ever though of ways of handling those?
Feel free to share anything related to it. (As long as it's constructive, everything is welcomed.)

 

Trying to build the same game for multiple platforms, some with Unity and some with Unreal (or any other engine combination) would be a complete nightmare. You're not only basically building the same game twice, but having to reconcile differences between the engines - where one engine does something simple, but with the other engine normally you would just not do things that way but end up needing to so as to keep the two versions of the game as similar as possible. It would probably be faster to simply create two completely unrelated games using the two different engines than to try to build the same game twice, outside of certain assets you would share between the projects.

I'm confidant big studios can pull it off, but it seems like a waste of resources for the average indie or small studio.

I think the mobile companion app idea has the most merit. So in this case you're not actually porting a game from one engine to another, but instead building a completely new set of companion features for the game. The most difficult part is probably going to be having the two games talk to each other, but you could handle that with a central database that both engines can deal with.

Unity's license doesn't allow for use in embedded systems, which your game controller idea would qualify as. Using a build from a game engine to embed into a controller is probably not optimal anyways. There's a lot of unnecessary overhead that just operating a controller wouldn't need.

 

I agree that porting between Engine is mostly a waste of resources which is why the 3 examples I gave are mostly use of Cross-Engine for sidelined inputs or management system. As making the two games communicate to each other is the more complex part, this was why I posted this as a network topic.

Unity's license doesn't allow it to be used in a embedded systems, but most of the low-end game engines such as what you find as compatible with the Raspberry Pi3 doesn't have such limitation in their license. Most of the engine available that works natively with Raspberry Pi2-3 are shareware build by a community of some sort with, as limitation, only that you can't take their work and claim it as your own (which I don't plan to). With that said, Unity license doesn't have any limits as to was kind of inputs source we can use with it which is why I said my game project uses Unity for the game engine and another engine for the input manager in the "controller". This means that you could create a controller the size of a car for a car simulator with a VR head set and Unity's License wouldn't revoke you the right of using their engine to run the simulation in the 3D environment. (I'm pretty sure they would be quite interested in actually trying it out. Hahaha.)

You're right as to mention that using a build from a game for a controller involve a lot of unnecessary overheads which, normally, a controller wouldn't need, but at the same time, we go an existing example of the principle behind it which is the Wii U gamepad. The Wii U Gamepad is pretty much a tablet by itself, but instead of having an autonomous OS that can "play" games, it's mostly a streaming touchpad with inputs and with low-mid memory capacity similar to the Shield streaming technology by Nvidia, but instead of using the Internet to access the data, it uses a low-frequency short range custom WIFI signal.

The way I plan on managing this (as I'm currently thinking and looking it up) is to make the build/client made in Unity as a local server and, after opening the access between the PC and the "Controller" (which is basically like a tablet, but with a lot more buttons), having data being exchanged between both. The PC (Unity) would send data relevant to the touchscreen's content and the Controller would send data relevant to the inputs.
(The controller isn't an absolute necessity to that project of mine in a way that you couldn't play the game without it, but more as an accessory possible for it. The project does involve the possibility of using a Keyboard + Mouse to play it.)

Now, the thing I'm still uncertain about is how to connect the 2 together. (I'm not asking for the solution. I'm just sharing what's currently on my plate.) As you wrote, a central database would be ideal which is why I though of using the PC which runs Unity's client as the central database. I'm still thinking about how I should communicate the data between the 2 devices.

What do you think would be the most efficient way?

• The Client (Unity) create a file that has all the data required by the Controller. The Controller fetch that data through the LAN/WIFI with the right authorizations (which have to be set up when the controller is linked up through the WIFI/LAN with the PC).
Having the Controller create another file on the PC through the LAN/WIFI which includes the inputs. The Client (Unity) look up for that file and converts it content into inputs/actions in the game.
This involves some kind of constant read & write of 1 or multiples files in both side. As the data is stored on the HDD/SDD(so that the Controller can access it itself), it's slower than if it's stored on the RAM. It also involves some sort of "checker" to see if the file is being written or not by the other client when 1 client tries to access it.

• Having some kind of third party local server managing executable software on the PC which is started by the Client (Unity). Then having both Unity (local client) and the Controller (over LAN/WIFI) access the data stored by that local server, updating and loading its data at specific interval. This is similar to the possibility above, but instead of storing the data in some kind of file, it's mostly stored in the RAM memory (faster access in theory), but requires that both the PC and Controllers to request their data and wait for the data to be returned. (First point have both clients access the data within their respective software. This method have both software request the data through another software like a server. This is the only way I can think of where I use the RAM to store the temporary data.)

I'm thinking highly of the 2nd possibility, but I might have missed something else also. Got any idea?

 

Why not just have the controller connect to the PC via USB and write a game controller driver to handle it like any other game controller? Or design your controller to emulate another common controller? Otherwise this piece of hardware is only going to be useful in games you write for it, which means no one will want to buy it, assuming you're not just planning to build it for yourself just to satisfy your curiosity.

Also, latency with a game controller needs to be reduced to almost zero or it will have the feel of a PC joystick from the 1980's. A game controller that connects via wifi, and handles communication either by writing to a file on your PC's disk or bouncing controller commands off of another server is undoubtedly going to involve relatively high latency in comparison to just sending signals over USB.

 

I'll be a bit side-tracked (outside the core of the discussion about Network and Cross-Engine) and will answer your questions as everything you mentioned, I already though about those.

If anyone reading this doesn't want to read about USB/Controllers/Input subject unrelated to its Network part, I suggest you skip this post.

Spoiler: Skip this if you don't want to read about Controllers stuff

Because it's not just a game controller. It's a game controller + touchscreen. Why do you think the WiiU Gamepad doesn't use USB for data transfer? (If you plug the USB into the WiiU, it's only charging the gamepad battery.) That's because the concept of how the data is transferred through USB is actually quite limited without one hell of a complex driver to handle the process. A USB controller really basics techniques to manage how its communicate its inputs to the PC. It doesn't have any "real" ways of handling data being sent toward the controller from the PC. There's an exception with the gamepads that has light signals. Those might have some kind of hardware and micro-processor that handle what light is turned on or off with really simple tasks flashed into it.

I could use USB to plug a RaspBerry Pi3 based controller in the PC. It could be an option.

There's not a "common controller" complex enough to emulate what I have in mind. Using a controller as a base to make my controller would limit myself at using what the said controller has to offers and I can forget the touch screen with that.

I did wrote that the controller is a not-commercial project as I can't even think about how I could protect myself against Patent Trolls. I don't have the backing or funds to defend myself. Hence, while the game will work with a Keyboard and mouse, I do plan to implement an optional "control" setup and giving away the software and instruction for the hardware that will allow anyone to build their own controller. You would be surprised on how DIY (Do-It-Yourself) can be quite popular today. As I'm preparing the things to works with something like a Raspberry Pi3 (a 35$ computer the size of a credit card and about 1 inch tall). It's crazy what you can build with as little as $100 of hardware and a 3D printer and a plan with instruction on how to set it up.
Who knows? Maybe even making a contest out of it.

So, the game itself (the software on the PC using Unity) is a serious project being planned. The controller is more of a side-line project for the fun of it from which I plan to release data from it for free to the public so that others can innovate and/or learn from it.

WiiU uses WIFI for its gamepad with a screen and it's a low frequency version of it. It's a custom version of it, but it's still uses the exact same technology. There's link from 2012 that explain it a bit : LINK
Of course, I'm not using the exact same techniques or technology. I got to adapt to something less "specific" here.

The RaspBerry Pi3 has an integrated WIFI adapter (yep... in that credit-card-size package!) and an Ethernet slot drive. What's the difference between USB and Ethernet?

USB 2.0 (since some player still has USB2.0) has a speed capacity capped at 280Mbits/s
Yeah, I'm making the controller for myself, but as I plan to allow others to build their own, I got to think of everything as if I'm still one of them. If one of them has 2.0, I got to think 2.0.

Ethernet cable has a speed based on 2 factors: the cable and the motherboard's jacks.
Then you got Cat5 cables with 100 Mbits/s. That's the hardset limit on the RaspBerry Pi3.
(Only 1 Ethernet cable would "drop" the speed at 10Mbits/s and that's a Cat3 E Cable. The first Ethernet cable on the public market in the 90's and early 00's. Cat5 is pretty much the minimal standard you got for around $1 per foot or even less.)

Since the Ethernet cable is part of the DIY side of the project, if I simply mention the note about not using Cat3 and it should avoid most misunderstanding on that part.

What about WIFI?
With a "wrong fully setup" WIFI router, I have seen reports that the RaspBerry Pi3 has a WiFi bandwitdh of 150Mbits. Still, I also see reports that it depends on the router's configuration and it can reach 300+Mbits. But as I previously stated, I'm looking at the "worse" scenarios which is 150Mbits capacity with the WiFi. (This doesn't includes the WiFi's traffic like if the user also run a phone, a tablet and 2 other PCs on the router.)

The frequencies are:
USB: 200 MHz
RPi3 Ethernet: 100 MHz
RPi3 WiFi: 20 MHz

This means that, indeed, frequency of USB is 2x faster than Ethernet and 10x faster than Wifi on paper.
But, there's something many might not knows... some controllers doesn't use the full frequency capacity of their USB cable. for example, the XBox 360 wired controller uses a frequency of 100MHz at 2.4GHz... which is exactly the capacity of the RPi3 Ethernet cable. (funny, right?) The Xbox One uses a dual band at 2.4GHz (same as 360) and 5GHz (same as USB 2.0 capacity).

Still, it remains that the WiFi could be a problem for really touchy people who want their controls to be responding faster that 1/50 secs. I admit that someone who's playing at 60 or 120 fps might feel the issue and especially if their WIFI is rightfully used by lots of devices. Still, it's not like I'm limited to only put Ethernet or WiFi or USB... I could implement all of them at once with a kind of setup system which is set by the user on the controller... like when you try to connect your console to the Internet, it ask if you want to use the cable (if plugged) or connect wireless.)

I hope this answers your questions as to why I went toward this direction.