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
  • Unity
  • Amazon Lumberyard (crytek)
  • Tombstone
  • 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.

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

  • 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.

Moving forward

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

dexGame engine

Happy holidays

Hope everyone had a good christmas and a relaxing break. There will be a bit of a lapse of updates while I find something lower friction for posting updates


dexGame damage update

This will be a quick update, but a few things have been added where the game is at an actual playable point!

Here's what has been added since last post:

  • player damage
  • basic hud showing health, for above damage system
  • player damage opened a wormhole of other stuff needed
    • player respawning
    • player gibs
    • etc..

So now, you can spawn into a game, run around , shoot and kill someone and they will respawn. This is also the first time I've been easily been able to see the player model and boy is it bad (or to theme...), but the weapon mount system is working well.

dead1dead1 don't worry, dexGame is so advanced, it has no crouching so you cannot be teabagged.

The gib system is still WIP, so right now i just draw a red beam where you died. Eventually, chunks of your player model (im thinking wireframe shaded chunks of player model) will go flying. Not because I'm anti violence, but because real gibs require you to know what you're doing


impending rip gibstick2

It's also quite jarring when you die, you pop to a 3rd person free floating cam where you died. But the spectator camera doesn't inherit movement and stops cold, and loses all inputs. This is the stock spectator camera built into the engine, so I'll have to make a custom one that is a little more friendly.

I spent hours trying to get the above features working in a true network game and was led astray quite a few times, but at the end of the day it came down to a missing one liner for a network message constructor :(

debugging Sorry to anyone who has me on snapchat


dexGame rocket progress

Building a solid, real-deal game foundation this past week, I have only done some minor tweaks and cleaup to the following:

  • Player model, physics/movement
  • Rockets now have pushback / rocket jump (very ghetto atm)
  • Slightly less stupid visuals

I made the rocket look somewhat like something that would kill you and tweaked the player model to be more in the corner because this is clearly a critical issue. There is also support for left/right handed player models but its not yet exposed to UI. A settings UI is badly needed.


Yes, that is a bad version of amphi. Next I will move on to the following:

  • Damage system (which will then require player state/health)
  • Next weapon
  • Gamemode manager

I should also mention I'm using teamcity to automate all my builds + update this site which will make further updates easier.


big dexGame push

This thanksgiving break, I got my nerd on and made some good progress on fundamentals for ol' 'dexgame'. The following boring-plumbing-things are in place (first passes..) so its shaping up to look like a real game:

  • Input and basic menu systems
  • Player joining & spawning into network games
  • Networked player movement
  • Base weapon system
  • A few lame maps


On the player spawning stuff, I thought I was done a long time ago initially before I dug out a real second machine and tried it. I was slapped with reality and all sorts of bizzarre stuff was wrong. At first, players would spawn but have no control (this was caused by not tying a model to a controller). Then the first player in the server controlled ALL clients, which was moderately funny.

Finally, I got it working and I was greeted by my placeholder player model collapsed completely into its head. So I have replaced it with cylinderdudette (tm). It turns out getting not-shitty feeling movement in a rigid body physics based engine is easier said than done, but I got something OK going.

Call me old, but coming from the source engine which has two weapon models - an explicit one for first person model, and world model (view_model / world_model), it was very convienent just gluing a single model to the player on a mount and then transforming it a bit in the player view. Marvel at my first person model for a rocket launcher. Accepting offers for s1ck 3D gfx artist


The rocket was par for the course with a backwards quad effect for the flame:

first rocketfirst rocket

However it is all spawning in game, working, moving around etc, so its getting fun


Starting dexgame

For quite a few years, all of my spare time on hobbies that werent games have been spent on ruthlessly utilitarian projects (or I felt 'pointless' if they didnt serve an immediate purpose/learning). With that in mind, and to get on the fact I've been saying I want to do this for a while, I'm going to actually make my own game.

Unfortunately I suffer a severe case of jaded bitter gamer vet syndrome (tm) and I only like niche fast paced arena shooters of yesteryear like quakeworld and quake3 mods like CPMA, so it will probably be a simplified, modern version of a fast paced arena shooter with not much more to it. And no, many games coming out calling themselves 'fast paced' or 'old school' are anything but.

Astute readers may be wondering, "Why?" - this is a fair question, especially with games like warsow (which i contributed to for years), nQuake, Reflex (RIP), etc still readily hitting this niche quite nicely - all of which have virtually no players - why bother?

A few reasons: Firstly - I want to make it for me and no one else. Besides, I way too much of a realist about indie game development, its a diluted sea of garbage, just take a look at new steam releases. Endless asset flips and unreal engine hello worlds make it impossible for people to find your game by chance. That coupled with this ruthless, unwelcoming gameplay is a recipe for disaster.

Second, I want to learn an engine from the ground up so I have an effective way to play around with ideas. For this reason I will not be using UE4 or Unity, but will NOT be trying to create an engine because that is guaranteed failure. I'd like to really learn things like modern C++ (which I truly hate), 3D math, and maybe give some bot ai a stab. Third and last, I want to get the hang of 3d asset creation, I have done very minimal tweaking of assets in past but thats about it.

With that said, I'm about as creative as a honeydew in a spelling bee so I've calling the project just 'dexGame' internally, but I'll probably call it "Bad art arena" in homage to the impending chunks of double digit tris polygons pretending to be 'art'.

Development is underway, still mostly toolchain/setup phases. I'll try to update somewhat regularly as motivation ebbs and flows.