Stronghold - Getting Started

I've been working on a game engine "from scratch" for the last 6~8 weeks.

It's programmed in Jai, Jonathan Blow's language that has been in development for ~11 years.

I wanted to do as much as possible myself, both for professional development but also because I believe it's important when you have a distinct vision you want to bring to life in a very specific way.

It utilizes the (kind-of brand new) SDL3 GPU for cross platform graphics, Jolt for the physics system, and wren for scripting (which primarily exists for UGC / user-generated content).

I'm also using sqlite to help support UGC and rapid iteration in the editor.

Offline tools are Focus (a text editor written in jai which I encourage anyone who likes a more minimalist development environment to check out) and slangc for shader compilation across platforms and languages. I also tried out SDL Shadercross for this, but after using it for a bit it hasn't seemed necessary and it was a little more complicated to get set up than slangc (read: cmake + a bunch of unincluded dependencies).

I'm not currently using fmod for sound but I do have a high opinion of it having used it before in Unreal projects, so I may choose to include it further down the line.

Beyond that and the Jai standard modules included with the compiler (more on why those are significant later) I don't plan on using any other 3rd party libraries, frameworks, etc.

There are some questions I had to ask myself before embarking on this first, which I will regurgitate here

1.) For someone experienced already in Unreal, why make your own engine?

I don't really have a low opinion of Unreal. Infact, I rather like it and have often recommended it. I first used it sometime around the 4.12 release in 2016, and dabbled in random projects on and off for a while until I started making more serious ones in 2018. I really like a couple things particularly, which is the source available nature (writing an entire game in an abstracted language on top of the engine just sounds horrible, and actually understanding what the engine is doing at every stage is incredibly important) and the integrated development stuff, like animation tools and modeling.

However, I think it has little bit too much baggage. Things like Python scripts and dependencies are deeply embedded in the engine and are very difficult to rip out. Huge numbers of features that are completely irrelevant to my project can't be (easily) toggled out of compilation. A full Unreal Engine 5 source install folder easily hits over 300GB and the C++ can take a very long time to compile, making it troublesome working with people on different architectures on an indie project or jam.

And on a purely personal level it goes against my philosophy of making things as small as is reasonable and as fast as is economical. Options like the Forward shader (which is a generally more performant option) continually exist in a semi-abandoned state with checkboxes that literally don't do anything and major bugs that go years unaddressed. "General" engines, despite ostensibly being good for any game type, will still be beholden to whatever smaller target class of game development it is focused on. And since I'm not interested in making a PBR third person multiplayer shooter or racing game where physics doesn't need to be thought about too much it probably isn't right for me.

Finally, and maybe most importantly, the learning quality, rate, and overall experience of writing your own engine bottom up is pretty much unmatched. There is nothing you won't touch on!

2.) What kind of engine do you want to build?

The question between "what kind of engine do you want to make?" and "what kind of game do you want to make?" are highly synchronous. You shouldn't make one without the other. That being said, separating them can be useful to make distinct technical thoughts and more game design oriented thoughts.

The title I'm working on right now (code name "Stronghold") has some requirements I've given myself.

So far, these requirements have been surprisingly not difficult to meet. I attribute a lot of this success to Jai, probably the first programming language I've used where I've actually distinctly felt the "joy of programming."

3.) What kind of game do you want to make?

I've felt more and more lately that the kind of game you want to make and the engine you should use really go hand in hand at a very intrinsic level. Obviously, many people have made really amazing games on general purpose engines but the more specific the type of game you want to make and its requirements the harder it is to go the extra mile on an engine you are fighting with.

My favorite game of all time growing up was Warcraft III. In my view, nothing has ever come close since then to the type of game it was. A very solid RTS with RPG mechanics as well as a fantastic map editor that led to the creation of multiple dominant genres years later. I think there are still more incredible games trapped in WC3 custom maps that have yet to break free, so I thought I'd try my hand at one (co-operative hero siege games) albeit not coming at it quite head on.

Additionally, I wanted to go for a low poly art style that is a little more "early phong" or Gouraud looking. Ultimately the point is to make the player feel something, and I think the graphical arms race forgets that sometimes. There have been many, many varied movements in traditional art across history and realism is one of many. Evoking a feeling is more about mastery of style and delivery. Given my formative years being spent in the early 2000s consoles and games like the Gamecube, OG Xbox, and computer games of the time it's natural to gravitate towards. Also I suck at art so it's a little easier in some ways.

In the forthcoming posts I will detail some development issues I've run into thus far, how I solved them, and most importantly go over the learning and iteration process.

Back to Home