Warum nutzt du Managed C++? Nimm dir C#, SharpDX und entwickel drauf los.
Das Problem dabei: du musst dir deine Engine selbst schreiben. Mag sich für einen Anfänger schwer anhören - was es auch ist, solange die Grundlagen der Vektor- und Matrizenrechnung nicht bekannt sind - erlaubt aber unglaubliche Flexibilität in der späteren Entwicklung.
Du hast zwei Herangehensweisen: eine "echte" Isometrie (was 2.5D ist) Engine nehmen/schreiben, oder das ganze in 3D machen und die Kamera entsprechend drehen - was imho das einfachste wäre.

Wenn dir die Spielidee im Kopf herumschwirrt: nimm dir einen RPG Maker und zeichne dir das grundsätzliche Konzept erstmal in einer Grundidee auf - habe ich bei meinem Spiel vergessen, und bereue es. Du könntest auch Unity3D zur Umsetzung nutzen, sodass du dich komplett auf die Entwicklung des Spieles konzentrieren kannst, ohne eine Engine zu schreiben. Eine "einfache" Engine zu finden, die nicht dreitausend Zusatzfunktionen bietet, wird schwierig, da sie zu speziell ist - Engines haben den Anspruch universell nutzbar zu sein.

tl;dr: kein Managed-C++ sondern .NET, eigene Engine oder Unity3D (bzw. RPG Maker/GameMaker)

Okay .. habe ich mich falsch ausgedrückt: ich meinte natürlich Native-C++.

Ja, Unity ist genau wie der RPG Maker ein Klick und Bastel, allerdings mit dem Vorteil, dass im Hintergrund noch eine ordentliche Engine arbeitet, die mit JavaScript/C# verändert werden kann. Für jedes normale Spiel reicht das vollkommen aus - selbst sehr spezielle Dinge wie Kerbal Space Program können damit gemacht werden.

.NET ist einfach zu dekompilieren, ja, aber wem bringt das etwas? Die Techniken, die in Spielen genutzt werden, sind seit Jahren bekannt und bringen nichts neues. Bei Spielen gilt imho das Gesetz: Je offener (Veränderbarer) das Spiel, desto erfolgreicher ist es. (Minecraft, The Elder Scrolls: Skyrim, Warcraft III, GTA IV) Wenn das Spiel nun in Native-C++ geschrieben wurde und damit unglaublich abgeschlossen ist, kann ohne großen Aufwand zu betreiben, eine Modifizierbarkeit nicht gegeben sein - zudem sind bei einer eigenen Engine die Wrapper deutlich besser, als das "Original".
Wenn es dir nur um die "Dekompilierbarkeit" geht, ein kleiner Trick: wenn du es schaffst, nativen Code in Managed Methoden einzuarbeiten, ist kein Dekompilierer der Welt in der Lage, dein Programm auseinanderzunehmen.
Nimm dir also ein C++/CLI Projekt, erzeugt damit eine DLL, mit der du auf die WinApi zugreifst (natürlich muss es eine ref class sein) und versuche sie zu dekompilieren: es wird nicht gehen. So kannst du theoretisch die sensiblen Teile deiner Anwendung schützen - allerdings sehe ich diesen Teil bei Spielen nicht wirklich, bei Programmen ist es imho anders.
Wenn du trotzdem bei C++ bleiben willst, nimm C++/CLI und den SharpDX-Wrapper. So kannst du native Klassen weiterhin behalten, hast aber den unglaublichen Vorteil, dass du mit SharpDX einen extrem starken Wrapper in der Hinterhand hast.

Die Idee dahinter wäre dann:


Zudem: Was würde es einem potentiellen Angreifer bringen, dein Spiel zu dekompilieren?

Bei meinem Spiel bspw. habe ich alle Ressourcen in Quellform rumliegen: Shader, Grafiken, Fonts, alles. Der Spieler kann also theoretisch alle Dateien so manipulieren, wie er es gerade für richtig hält.
à la: "Der Shader ist scheiße? Ich schreibe einen neuen!", "Die Font kann ich nicht lesen, ich ersetze sie." Ob dabei nun die Anwendung in .NET geschrieben wurde oder nicht ist damit vollkommen egal, die Offenheit eines Spieles ist auch gleichzeitig sein Erfolg.

@AliveDevil
VC++ != C++/CLI. In nativem C++ benutz direkt DX oder OpenGL, SharDX ist für .Net. Ist zwar blöd mit den ganzen COM-Interfaces aber kann immer noch am meisten