New1 Question Answer

If I understand correctly, your application isn't a game, but is a communications system for use with games. If that's the case I wouldn't suggest any game engine, including Unity. My points, related below, are based on the assumption that you're not making a game, but a utility for games. If my assumption is incorrect, then I'd need that corrected.

I also ignore the technical complications associated with an application that can recognize a keystroke when it doesn't have focus, or those associated with whatever graphics modes a game may invoke which can wreak havoc with your intent to overlay your application. There is nothing about using a game engine that would help with making an overlay. Quite the contrary, I have reason to think it would be more difficult if not impossible. The overlay is more a function of the operating system's compositor than of any game engine.

My primary reason for saying that no game engine is appropriate is because of the animation cycle indemic to all game engines, and their reliance on the GPU for display. The animation cycle is actually ill suited for what I expect is the GUI for your application, and the GPU usage (from shader programs to the GPU pipeline in general) would tend to conflict with the game you're application is supporting. By conflict I don't anticipate errors, but of performance interference of both your application and the users game. You need GUI efficiency for what I assume you're making, and a second game engine running simultaneously with the user's game does not fit that requirement.

I'm primarily a C++ developer (over 3 decades), so naturally I'd use C++ for such a project. The more I use C# the less I like it, and the more I find objectionable. While I could easily ignore the aspect of not preferring the language, my objections to C# have to do with what I can't do in C# that I can in C++, with performance issues and even portability concerns. I recognize that C# offers certain conveniences that attract programmers, but those conveniences are not generally realized by users. Quite the contrary, whatever conveniences developers may exploit from C# are all too frequently recognizable to users through performance complications, particularly memory usage and raw speed.

You state you have some experience with C++, but I also know that C++ is a nasty language full of complications that require more than familiarity, expertise is required. For an individual, the right tool for any job is the one you know best. C# is much easier to master, and where that mastery is more important than those issues that cause me to object to C#, mastery is a higher priority. I may have to agree that C# may be your best choice. For me, having written in C++ since 1987, there is no question that C++ would be my best choice.

If I used C++ I may use the boost libraries for some features (I've used ASIO with good results several times), and either Qt or wxWidgets. Qt may be more mainstream, but wxWidgets can be remarkably effective while somewhat simpler to use on various compilers, including XCode in MAC, anything on Linux and Visual Studio on Windows. One of wxWidget's flaws has been it's network objects, for which I'd use boost::asio, if required, and possibly other frameworks as required for database access over the Internet. I detail that not as a prescription for you to consider in C++, but as a measure of the complexity of using C++. I'm comfortable with that, but I've had a lot of time to get comfortable with that. C# includes just about all of that from the .NET framework and generally requires very little external library or framework support. That's why I have no choice but to acknowledge the convenience of the language.

The nature of what I expect to be your application requirements wouldn't suffer much from C# compared to a C++ product of the same design, and both would be lighter on the GPU than any game engine. I assume you're thinking of a translucent background to a largely text oriented application (as in controls, text, buttons, etc...not 2D or 3D animations). Even if you wanted some minimal 2D or 3D animation in your application, it would be much simpler to incorporate a graphics control with support for a minimal rendering or game engine (something like Irrlicht or even GamePlay 3 in C++) in a way that supports the overall application requirements. Just positioning and correctly overlaying your application will be much more straight forward in C# or C++ than in any game engine. All display of information, text and controls will be much simpler in C# or C++ than in a game engine, because such UI controls are generally more difficult to implement in a game engine due to the animation cycle. To see what I mean, look at this documentation on Unity's order of execution. Scroll down to the diagram to notice FixedUpdate and Update. These two functions are the primary methods you use to write your code, and they are synchronized with the engine's cyclic operation, usually tied to the display's frame rate (FixedUpdate is tied to the physics engine's cycle time). Mouse operations are much more difficult to manage than in a traditional GUI. Unity must queue incoming messages from mouse and keyboard operations, then feed those to the Update method at the time it is called. Traditional GUI, on the other hand, responds in a more "live" manner to mouse and keyboard control.

With all of that said, I'll tell you that if the time comes that you are making a game, Unity is hard to avoid. There are only a few other game engines that compare, but Unity strikes a unique balance between ease of use and short learning curve (relative to the subject of making a game) than most other engines. More importantly, though, Unity performs much better on modest mobile hardware than on all engines I know of that are based upon a game editor. There are rendering engines and game frameworks that are often called game engines, but they are presented as a C++ library only, and some do perform well on mobile devices, but Unity enjoys much better coverage and compatibility with the huge variety of Android devices than most any other engine, given the complexity of targeting such variety. Given the costs (free until you're selling over $100,000 a year), it isn't difficult to recognize why Unity has the reputation your friend described.