dexGame engine boogaloo
Well it finally happened, I threw in the towel on the current engine tech I was using for dexGame / BAA. I will detail why, but first some background as to how I ended up here.
I was looking to start a simple, ruthlessly barbaric shooter game. I didn’t need triple A features or crazy artist workflows. However, I did want responsive, good feeling input for a fast shooter. Here are the candidates I seriously considered:
- Unreal Engine 4
- Amazon Lumberyard (crytek)
- Old quake engines, etc
Unity: Amazingly, I didn’t pick unity, because I had an unfair, dated stigma about it’s input handling and overall ‘feel’ for fast shooters. My main concern was hitting a point where I wish I had the sources to fix an issue, or customize input or movements. It’s definitely back up on the chopping block. If nothing else, I know C# very well, it was my bread and butter professional development language for over 5 years.
Unreal: While I like unreal and have made throw away project and demos with it, I had a hankering to use something more ‘lightweight’ in terms of code/cognitive load for a fresh game. If I was going to go for something with full code, I’d prefer something where I could understand the majority of the engine front to back. I’m not afraid to admit Unreal is beyond my mental capacity to even pretend to understand each subsystem. Aside from that, I could implement the game in blueprints if I really wanted, but I kept looking.
Lumberyard: I ended up at lumberyard trying to figure out what the heck happened to the old crytek sdk licensing. I like what Amazon is doing with it (tho the AWS integration is lukewarm for really fast shooter servers). I strongly considered this due the amount of work and money Amazon is dumping into it but I was put off by a few things,
- Old crysis systems were in place next to new amazon (nicer) systems
- Docs were being caught up/written up, complex interaction
- Lack of industry acceptance, who knows how long it will last
With that in mind I kept looking.
Tombstone: This engine, previously known as C4, is a one man show. Written by Eric Lengyel (along with many other tools written from scratch for the entire pipeline), It boasts some interesting features and a completely integrated editor. Importantly, he heavily sells his code quality and architecture on the website. All of the model & map, sound, video, texture formats are completely homegrown here. However, he also developed an open exchange format that no one else uses. Some island syndrome here.
Old quake engines etc: I have a lot of experience hacking on quake2, quake3 and source engines, so it was tempting to use something like that but a few issues I had with going this route include:
- outdated tools (mapping, model importers, source’s stupid qc system)
- not learning anything new
- remaking quake in quake would be stupid :D
It’s also worth noting valve doesn’t care about providing SDKs for modders at all anymore (can you blame them?), after a 5 year hiatus the source2013 sdk was dumped and left for dead and all the tooling is held together with duck tape.
Ultimately, I drank the kool-aid and went with Tombstone. If I had full sources, I wanted to have a hope of understanding most of the interesting systems and I have to say, Eric is not exaggerating. The code quality is absolutely excellent. It’s written in modern C++ and it was the most readable code of any non-trivial system in any language I’ve ever seen (while still being C++) which says a lot! For my goal of understand the code (well most of the important system) I succeeded thanks to the excellent engineering.
The systems make sense and work well together. It’s not free, but for what you get, with no royalties or runtime fees it is a serious bargain.
The content system is a little different, but you can actually create models and maps within the integrated editor, as well as 2D gui systems which was extremely handy. Furthermore, my game compiled and shipped was under 6MB total. It’s a very sweet package and compiles nicely (well mostly, linux require minor opengl header fuss)
If I am praising Tombstone so much, why am I moving away from it? While it was great, overall several small things slowly grated at my already small chances of completing a one man game. None of these are critical, but over time it made me start to consider more and more
- Everything is really homegrown. For format imports, you have very limited options
- The tools and editors do not scale to 4K/hidpi, this was very annoying after upgrading monitors
- The world editor works well, but the binds are unlike anything else i’ve used in my life
- The editor is only usable from in game. Which is kinda a plus and minus at same time
- Networking is very basic. there is no proper full netcode (eg, client prediction systems)
- Movement is done via rigid body dynamics. Having some entities ignore the system with custom movement caused issues
- There is intense math notation in the code. Eric is a mathematician and you are reminded of this
- Minor, but development seems to have slowed a bit.
- No built in code-level scripting system (just basic map entity stuff)
- Virtually no industry use :(
Not to sound like I’m picking on this engine, I really do like it and still highly recommend it if you can work within those constraints. If I was making a small single player game or visualization/simulation software I’d very likely pick it up again.
Ill probably pick something that starts with U unless lumberyard really makes impressive strides