Here’s to the crazy ones, the misfits, the trouble makers, the engine-eers! - dazza
After reading this excellent blog from ZeroEqualsFalse I thought I’d counter with a defence for writing and deploying your own engine.
I’ve been writing “engines” for 20 years both professionally and for fun. I am in no way a Carmack and I am under no illusion that I can compete with all of Unreal or Unity on all fronts but…
Pushing it
If your game is in any way pushing the limits you can’t stick with Unity and often even Unreal is not ideal. For Smith and Winston we need to regenerate detailed visible and collision meshes VERY quickly as the player can destroy nearly anything in the game.
We prototyped the game in Unity but it had slow mesh creation times and quite frankly shockingly bad collision mesh insertion times. By writing our own engine we managed to get orders of magnitude speed increases over Unity and about 10% faster than Unreal. Write a plugin you say! There you go assuming most of the speed boost didn’t come from not working through multiple layers of abstraction that general engines necessarily have.
This may have changed now, I see there are some excellent voxel plugins both Unity and Unreal but my point still stands in general.
It’s part of the fun
Part of what attracted me to making games was the tech side. There are loads of people who have been enabled to make games because the bar has been lowered and this is a great thing but there are many people like me that love the tech, love the challenge, love the low level, love the bus speed usage, love the lack of memory fragmentation, love the aligned cache access, love the parallel thread usage as well as love making games. If you’re one of them go for it!
We need skills
ZeroEqualsFalse make an excellent point that writing an engine is a great learning experience. You’ll only really understand engines by writing one. They all have their own quirks, good points and bad points. But why would you waste your time writing an engine when Unity and Unreal are quite frankly great engines? As an industry we need these skillz to be honed and we need people that understand how to finish an engine as well as a game.
Taking an engine to market, getting it through QA, TRC, localisation and deploying it on a myriad of platforms is a valuable skill and a skill that is rapidly disappearing. During the “democratisation of game making” that has been going on for the last 10 years people have been actively discouraged from learning these valuable skills. Someone has to write the bloody engines of the future!
Plurality
It’s quite frankly not healthy for our industry that there are two dominant engines (Unity and Unreal). There are other great engines (Godot being a great example) that are largely pushed to the margins. The industry already suffers from Autodesk dominating the creation pipeline with Maya and 3DSMax. At some point one of those engines will collapse under it’s own weight, competition or market forces. This will leave a huge hole in the scene.
Its actually ‘not that hard’…
but can be time consuming. 20 years ago when I wrote my first engine (as opposed to just a game) every single line of code was mine. It had custom string, vector, matrix, model, collision, physics, sound, rasteriser, input… you get the point. I wrote it all in C and “C with classes”!
Nowadays you really don’t want to be doing that and you don’t need to! Here are the libraries that I use in the Smith and Winston codebase
- PolyVox - excellent voxel library, I didn’t even write the voxel code!
- Bullet - world class physics (soft and rigid) and collision library
- BGFX - world class low overhead rendering API with DX9/11/12, OpenGL, Vulkan and Metal backends.
- C++11/STL - night and day compared to old C++. Basically cross platform code is way easier to write now with MSVC/GCC and Clang.
- CMake - meta makefiles system that’s arcane but makes cross platform project management so much easier.
- OpenSteer - navigation library (bit dated but very usable)
- GLM - video game maths and maths utility library. Apes the GLSL syntax.
- LibZlib/lz4 - open, free and very squashy.
- SDL - input, windows, sound, back massages
- FMOD - For all your sound needs OK, it’s not ‘free’. But it is basically free for all indie games and it’s amazingly good. It took two days to integrate in to my codebase!
- Lua/LuaJIT - you are not going to get a language as fast and expressive as Lua that fits in < 1MB of memory. Scripting for grownups!
- stb_* great collection of utility functions/classes by Sean Barret
- plus countless other small bits and bobs
Essentially my engine is really just the glue between all of these off the shelf, highly polished and stable libraries.
For an editor just use Qt/WxWidgets or Mono. Integrate your engine with it and you’re most of the way to having a very usable editor.
You’re not really writing my own engine because you’re using all these great components.
Well if that’s true you’re not making sprites unless you’re typing in HEX.
To conclude
So it’s not for everyone and it’s great that more people can create all the varied games that we see and love but don’t discourage the future Carmacks of the world. GO FOR IT!
Whatever and how ever you decide to progress, be excellent to each other and PARTY ON, DUDES!.
have fun, dazza
updates
- 170723 - added facebook link
- 170723 - added links to the libs I mentioned as that’s how the internet is supposed to work.
- 170720 - This post generated an interesting discussion on Reddit.
- 220930 - removed links to smith and winston that are dead.
Comments