Originally posted: 29 Sep 2014

http://web.archive.org/web/20150416141713/http://mgarcia.org/2014/09/29/gameplay3d-vs-urho3d/comments/#comments

Choose your game engine wisely Part2!


Firstly, both are great, open source, multi-platform game engines!
Each having their dedicated and inspiring leaders and respective communities.
But after some thought and a year with GP3D, I’m considering moving on to the Urho3D engine.

My main issues are #1 official 32Bit support will be dropped which is the building of third party dependencies
that currently isn’t open nor documented.
And #2 there is no standard cross-platform build scripts, instead relying on proprietary IDE’s (VS, xcode)
which in turn lock you into a specific OS version (ie Visual studio 2012 requires Vista or better).
The lead developers of Gameplay3D like to keep the engine up to date with current hardware and software, not a bad thing.
But at the expense of dropping support for older architectures, I don’t think that’s wise… especially because it’s a mainly a mobile phone engine after all.

I’m sure these issues can be solved by a cmake/gcc guru, but with no information, I couldn’t.

So why Urho3D over Gameplay3D, from importance to me:
#1 All source code is included ie: third party dependencies, engine, samples, tools & editor
#2 cmake is standardised across all platforms, with optional IDE support (Code::Block & VS20XX projects).
#3 Not limited to only FBX 3D assets via Assimp converter (Open Asset Import Library).
#4 Better controller support (libsdl), networking (kNet) and other little nice to have’s (Scene editor, busier forums).


The Gameplay3D engine

Gameplay3D has a simple and elegant design, it’s philosophy is a bare bone framework and is not specific to games!
The engine does the common requirements of a cross-platform openGL application like physics, animation, GUI etc.
But there are no game specific features (ie path finding, fog, etc) because not all games require it.
It’s not seen as a limitation, instead it frees’ up the developer to create their best solution instead of fighting
with the engine’s implementation.

I like this philosophy, because that’s how games become innovative and new ideas are created.
The other benefit is a flatter hierarchy and a very simple C++ design (avoiding templates),
which is a lot easier to learn and debug if you’re new to C++.

The other GP3D philosophy (which I also like) was not requiring a scene editor, instead relying on your 3D creation tool.
This keeps your game asset creation workflow very short and fast, plus more time to master one tool (important for indies).

The Urho3D engine

From my initial understanding, Urho3D has features of a tradition game engine while being lightweight.
Including a Octree scene system, libsdl integration, networking, mesh navigation and DirectX or openGL for in windows.
Impressive considering you can target new machines and a Raspberry Pi (embedded linux) ‘out of the box’.

But with more features comes more complexity.
If you can program in any other language but you are new to C++, it’s a steep learning curve!
It uses many complex C++ design patterns which means template functions, and pointers to pointers are common.

My final thoughts

GP3D has been a great learning experience, debugging/stepping through the engine code and being 2 or 3 “step into’s” the openGL layer is without doubt GP3D’s best feature for beginners!
And something I couldn’t have got from my previous, closed source engine or even any other OSS engines, but being forced to upgrade my dev OS/IDE to keep up isn’t open source to me!
Choose your game engine wisely!