What game are you trying to write? If your plans are vague all that can be recommended are portable libraries for low-level functionality that's almost always needed, e.g. C++ with SDL2 and BGFX, but if your supported platforms are more limited and your needs are more defined many specialized and "opinionated" game engines might be a better fit; modding a sufficiently close existing game might be enough.

What is your problem with Unity? How can it be considered not object oriented?

Have a look at Ogre3D which is all developed through code (C++). Sometimes the amount of OOP makes it a little fiddly (similar if using Unity entirely through code).

If you want an OOP engine like Ogre3D but perhaps with more functionality included by default (but a tad less powerful), have a look at Irrlicht.

Finally, check out the Unreal Engine which as long as you avoid blueprints and keep with the standard C++ interface, can mostly be done through code.

My dislike of Unity is the abuse of the interface for everything :).
I.e. instead of having to drag and drop the classes and creating prefabs I'd like to code it, to me it's simply much more intuitive and it allows me to prototype and try stuff faster. When I need to keep figuring out on the internet where I gotta drag and drop stuff it's frustrating, specially when I could just write, say, a ScenarioManager to manager the objects and events of a map.

You are not alone in this. It makes the architecture of code very scattered which is why a lot of Unity projects are simply messy.

- It also works completely against documentation systems like Doxygen which cannot hope to follow a call graph or reverse call graph through the Unity black box
- It also makes going between versions of Unity difficult. Prefabs get orphaned and their data gets munged whereas code stays consistent with a clear deprecation scheme if one arises.
- It also makes continuous integration awkward because a headless UNIX build server obviously cannot reliably run an OpenGL accelerated GUI.
- It also makes unit testing a bit of a joke because there isn't an idea of a "unit", it is just a bunch of weirdly linked prefabs and serialized binary data.

But remember, Unity is not a professional tool (and neither is Blueprints from UE4). It is targeted towards "prosumers" and as such is designed to get things done as quickly and as "dirty" as possible. That said you can do pretty much anything through code if needed. I.e:

GameObject go = new GameObject();
MeshFilter mf = go.AddComponent<MeshFilter>();
mf.mesh = ...

But if you do ever work with Unity developers, the chances are they will not share the same views and so will just trash everything you do ;)

Whenever I am dumped with a Unity project because of bad choices made by management earlier on, I try to think of the editor as a simple "programmer friendly" level maker and then have proper initialization code attached to some ratty game object kicking around the scene. At least then I only need to fight with .NET (UnityScript or C#) being an inflexible scripting language whilst at the same time being a retarded systems language.

(Though 99% of the time I simply will not take on a contract if I smell something like Flash or Unity is going to potentially be involved further down the line haha)

I'm interested in knowing if there's an engine more focused on OOP programming than anything else. Rather than, say, something like Unity, which has a huge focus on interacting through the interface.

When you're writing a game in Unity as a programmer, you spend far more time in your programming IDE than you do in the Unity level editor. Depending on your role you might not even touch the editor at all. The code that you're working on might not even interact with any Unity specific APIs - it might be completely unaware of which engine it's running on.

Also, anything you can do through the editor, you can do via code. Unity is basically a framework for building your own game engine, so one of the big tasks at any professional studio is writing extensions to the editor to implement the tools that your specific game needs... and libraries of code that implement the gameplay frameworks that your game developers need. It's just a massive head start on making an engine compared to starting completely from scratch.

i.e. instead of having to drag and drop the classes and creating prefabs I'd like to code it, to me it's simply much more intuitive and it allows me to prototype and try stuff faster. When I need to keep figuring out on the internet where I gotta drag and drop stuff it's frustrating. Regardless of the game I just want to be able to do and try out stuff fast (fast prototyping).

That's more of a complaint about it being harder to use things that you haven't yet learned how to use. The whole point of tools like Unity is that they should give you a productivity gain - they have no value otherwise. It will take time to learn all the APIs of their engine, and all the editor features though... so it always takes some time until those eventual time savings become greater than the initial learning time...

FWIW, in my experience with game jams (where people are trying to make a game in 48 hours for example) Unity is by far the most popular choice for development environment precisely because it lets people prototype game ideas incredibly quickly, assuming they've already learned how to work with it... The same goes for any engine though -- until you learn how to use it, you're going to be going extremely slowly.

But remember, Unity is not a professional tool (and neither is Blueprints from UE4). It is targeted towards "prosumers" and as such is designed to get things done as quickly and as "dirty" as possible.

- It also works completely against documentation systems like Doxygen which cannot hope to follow a call graph or reverse call graph through the Unity black box
- It also makes going between versions of Unity difficult. Prefabs get orphaned and their data gets munged whereas code stays consistent with a clear deprecation scheme if one arises.
- It also makes continuous integration awkward because a headless UNIX build server obviously cannot reliably run an OpenGL accelerated GUI. - It also makes unit testing a bit of a joke because there isn't an idea of a "unit", it is just a bunch of weirdly linked prefabs and serialized binary data.

That's not really true... Maybe you've not been lucky enough to work with professionals on a Unity project, but that doesn't mean it's not used professionally. It mostly certainly is a professional tool, which happens to be used by millions of newbies as well. That just means that statistically, if you pick a unity project at random, it will almost certainly be newbware :P

Almost all the successful developers that I know in my local indie scene are Unity studios... One in particular makes over a million dollars a month, and they have documented code with the ability to traverse call graphs, they regularly migrate across versions of unity, and they have amazing CI and automated QA practices, including a massive unit test suite, integration tests and million-monkey-testing (automatically deploying CI-generated builds to all sorts of devices and having an AI press a lot of buttons). As mentioned above, in a professional / clean code-base, most of your gameplay code won't even care about what engine it's running on top of, so of course you can separate bits of that logic out and write unit tests. Not being able to write unit tests is just a sign of bad code :P

Not a Unity anecdote, but on a previous contract job, I've been hired to help port a game from one generation of console to the next, and in the process we threw out the old engine and developed a brand new one. The gameplay team didn't care and weren't even aware of the fact that they were running on a different engine now, because it had been written cleanly enough that all the engine-specific details were abstracted from the game logic and netcode :)