I've tried Unity, which I think works on all of those platforms now, but I could never really get into the vibe of working with a mostly visual game engine after a decade of writing my game engines from the ground up. Guess I'll always prefer graphics engines over ready-made game engines. It usually seems like I'd spend more time jerking those types of engines around, trying to fit them to whatever needs might be outside the typical use case, than anything else, so I err on the side of flexibility.
It's an interesting quandary. It took me a while to get into Unity as well. And I can definitely understand why a veteran developer familiar with lower-level systems and traditional OOP structures would find Unity difficult to get into. I had only been working with an OOP extension-based engine for a year or two (Flixel), and switching over to a component-based system like Unity still took me quite a while. It requires some mental gymnastics to move over from full-on OOP to component architecture.
The nice thing is that once you've really gotten it, it becomes possible to integrate both approaches in Unity. After years of practice, I've finally reached that point and my development is really taking off now. While Unity is mainly focused on the visual editor and component-architecture, it fully allows for more traditional OOP techniques. Getting the two to work together is surprisingly easy once you get the hang of it.
Quick example, I recently put together a basic "tile" system. The base of the tiles is a standard Unity component, written in the standard style. I integrated a few "tool" functions for adding links to other tiles in that base component. But then I used classic OOP extension to make another script that was a "square" tile. I used the tool functions I had written in the base class to pre-populate the square tile class with the standard eight tile links you would expect from a diagonal-capable board-game setup. Then I created a separate editor script for a Unity-editor window, and put the tools in it for creating a 2-dimensional board made up of standard square tiles. It takes the desired width and height as arguments, as well as a GameObject reference in case you want to use a PreFab, and creates a standard 2D board at the press of a button. It even creates all of the links between the tiles automatically.
Thanks to the OOP structure I used, the base Tile class becomes much more flexible. I used it to make square tiles, but I could also use it to make hex tiles, or tiles with any number of links to other tiles. (for more path-based board games) And since I didn't bother trying to integrate the graphics with the tiles, it can be re-used for a huge number of different game types. Applied correctly, the Unity way of doing things can actually be hugely flexible.
I don't blame you for sticking to Phyre Engine. A lot of coders insist on have source-code access, and that's one thing that Unity still obscures from it's basic users. I'm more of a high-level script monkey, so I don't mind.