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.

Background

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:

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,

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:

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.

Initial Decision

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)

Breaking point

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

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.

Moving forward

Ill probably pick something that starts with U unless lumberyard really makes impressive strides

January 28, 2018 · dexGame · engine


Previous:Happy holidays
Next:easier updates