# Using Unity as a front-end GUI for a non-unity application?

I'm working on a game right now that is 2D, and grid based, and for a variety of reasons have decided making it in Unity wouldn't be worth the hassle I'd have fighting the engine.

That said, I want to possibly add in VR support at some point, and Unity seems the easiest way to make that happen. Right now, the game is structured so that part of the code takes in a grid from the game-core, and that grid tells it what sprite(s) to stick in each spot on said grid.

My thought was that it might be possible to replace the "take grid array, render sprite-grid" portion of my game with a Unity front-end. For example, perhaps this would be like a board game sitting on a table, and rather than a 2D grid, the "sprites" would be simple models on the grid-board, with the user looking down at it in VR.

Is this a thing that is possible? Essentially, all I would need is for my Unity program to take inputs, and send trigger signals to the game-core, then receive an updated grid-array and respond accordingly. I've not been able to find any information on this kind of thing, interfacing Unity with an external program in this way. The game is turn based, so 2-3 updates per second would be the absolute max I'd need, performance-wise, and the game core could run on a potato.

In specific: can Unity send triggers to and receive a data array from an external binary (written in c#), and how would I do this?

I really hope this is possible.

• Doing it this way is likely to be much more work (and harder to debug) than simply writing your game natively in Unity. Once you have your core game logic, porting/reworking it to use Unity GameObjects/MonoBehaviours where appropriate should not be especially difficult, compared to developing and maintaining a signalling layer complex enough that you can swap-out the game's whole front-end. If you really want to go this route though, there's no Unity/gamedev-specific considerations here - it's just standard interprocess communication – DMGregory Nov 1 '16 at 22:00
• Thanks - I'd considered that, and I guess it might still be the best option, porting directly into Unity... I'll have to look into interprocess communication though, I don't think I'd have known how to look that up otherwise. – user1002617 Nov 2 '16 at 1:00

Some real games actually take this game logic and render separation approach that you are mentioning. I know that the ARMA games do it. You can always communicate via TCP with your 'game logic server' if its on the same PC it might be fast enough for board games.

Of course this is quite a convoluted approach. You might wish to make a small prototype to see if its worth it.

(Also the term GUI might not really apply here)

• (Also the term GUI might not really apply here) yeah I'm realizing from comments OP really meant building the client in a client-server architecture using Unity, not just building the GUI. In that case sure; that's how most multiplayer games work after all. – jhocking Mar 6 '17 at 16:46

I don't know whether or not this is possible, but regardless this wouldn't really address your use case anyway. VR is a hell of a lot more than just the GUI, so using Unity just for the GUI wouldn't help you any as far as converting the game to VR. If that is at all likely to happen in the future, you are best building your game in Unity from the start, since there isn't really a distinction between 2D and 3D graphics in Unity.

• I'm a pretty heavy VR enthusiast, so I know that making a VR experience is about more than just HMD compatibility. In this case, though, my goal is to be able to put on my headset, and play the same 2D game I might play on my monitor within a VR environment. I am literally trying to make a VR GUI/wrapper for a 2D turn-based game that simply enhances the experience - not a VR re-imagining. – user1002617 Nov 1 '16 at 20:33
• The idea is, this game is played on a monitor - but could be represented as a board game. In VR, the game would have the user sitting at a table, and viewing it as a board game on that table. Things in the room/the atmosphere might shift depending on game factors, but largely it would all be window dressing on the existing 2D grid game, to make it playable from within a VR HMD. It doesn't use the motion controllers much or at aall, it doesn't have room scale interaction, so it's not ~true VR~ in some people's eyes, but I don't care about that. – user1002617 Nov 1 '16 at 20:36
• If I built the sitting room, board game etc. in Unity, and used Unity's SteamVR integrations to add Vive support to allow the user to sit in that VR room and look at that VR board game, all that remains to be done is to send XInput to the game-core, and to receive back updates to the board positions. Via simple interpolation, I'd then have a board game, in VR, with moving pieces, etc. – user1002617 Nov 1 '16 at 20:39