2 years ago, I proposed this silly little idea. TL;DR imagine if you could have a GoldSRC-like workflow but in a modern engine. After all, wouldn't it be a dream for some, to be able to make full-on games in a modern engine, without any of GoldSRC's limitations?
Note: This is aimed at gamedevs who 1) want to make games the way they make HL mods 2) want their games to be moddable out of the boxSo, about 2 and a half years later, here I am, coming back to this idea.
I've sailed the seven seas, climbed all hills and mountains, grown, learned, made friends, contacts, partners, all kinds of things in the meantime. I've worked with various idTech engines and their respected forks, Unigine, CryEngine, Unreal Engine, Unity (almost got a job in this, well, almost), NeoAxis, Flax Engine, Source 2 even... none of it was really a good fit for my idea.
Unigine came the closest, honestly. Nonetheless, I, one day, decided to start writing an engine from scratch. Virtual filesystem, input system, windowing, console system with CVars and commands, plugin system, all kinds of systems. Worked on it for 13 months, and it got somewhere for sure.
But then, something odd happened.
History repeats itself
Godot 4 alpha something came out with the claim that they merged .NET 6 to replace Mono. I like .NET more than Mono (it's what they use for C# scripting). I just had to check it out. After a couple nights recompiling stuff and messing with NuGet packages, I was able to get a working build with all tools. And it was LOVELY. I compiled it to try out modern C#, stayed for the UI system and all the flashy new toys they added, and most of all: volumetric fog.
I got absolutely
mesmerised by it. I love fog. I love smoke. I love volumetrics in games. I fell in love with the thing. That + a few other things motivated me to consider rebuilding my engine on top of Godot, if that makes any sense. I then remembered the article I wrote over 2 years ago, and it is true what they say - history repeats itself.
And you know what? This time I actually have the skill, time and patience to actually do it! But FIRST, I needed to make sure it can actually even work.
Payback time
Do you know what's the purpose of a proof of concept?
The PoC, internally 'BodotPoc' It proves a concept. It proves that the core idea can certainly work, and is worth prototyping. And that's exactly what you're looking at. This was a pile of code in a single Godot project, that could read Valve220
.map
files, and let you move around. In the 2 weeks I programmed this thing, I learned a lot more about Godot than I did in the last 2 years.
After that, it was time to start working on the real thing.
This diagram here below, this architecture, is what gives me a great deal of convenience. I can work on the launcher, engine and games/plugins separately, without the need to re-export a Godot project if I just want to modify the "engine".
Plugin architecture overview Now, before someone says "Ayo, what the HELL are you doing?", let me tell you this first: Godot is not just a game engine. It's a game engine, engine. Alright?
An engine engine. With Godot, you build your own workflow, you combine some things that you like and you use that unique combination of those things to make your game. My case is just a very special one.
In fact, here's a quote from one of their recent articles:
Godot, at its core, is and will always be (by design) a very general purpose game engine. This mean that the tools provided, while certainly capable, are still game neutral. The goal for Godot is to provide a great set of building blocks that can be used and combined to create more specialized game functions and tools.
(taken from
Godot for AA/AAA game development - What's missing?)
I don't know about you, but I definitely see Godot this way. Maybe I'm more radical about it. Either way, I cannot think about making games, until I have a workflow that I truly love and am comfortable with. Godot gives me a foundation for that.
The dream
In the end, I just hope to have my dream come true: making games the way I make Half-Life mods.
And by that, I mean: making commercial games with modern technology, the way I make Half-Life mods, with modern tools and mostly without any of the bad parts of the workflow that make it incongruous.
- I don't like the SMD+QC workflow, I just want to import a GLTF and be done with it. It is a reality we can have in HL modding even, and I'd like to write such a tool one day. It'd help beginners tremendously, I am certain in that.
- I love the mapping workflow, but I'm not a fan of the BSP limitations. We're all very ambitious, and limitation breeds creativity... but not when that limitation is a few centimetres above your head. Can't even jump, let alone fly. Just look at AllocBlock or clipnodes. You don't want that in a modern engine, do you? An octree-based solution - as opposed to BSP - would fit this engine of mine, and even play with Godot 4's occlusion culling system pretty well.
There's several other things I could talk about, but these are the main two. Every modern engine I've worked with (except Source 2) basically had those 2 arguments up there flipped. The modelling workflow was great, mapping was not. Can I have the best of both worlds? Somehow, I convinced myself I indeed can.
At the moment
So, right now, we have:
- a plugin system
- a virtual filesystem with Source-style game mounting and folder structure
- a console system
- a placeholder game template that loads TB maps
Where we're at now
Folder structure What's missing is frankly a lot of stuff. Animated models, audio, networking, a main menu system, AI, mostly the need to build a proper game SDK, and flesh out parts of the engine. I have lots of ideas I want to experiment with,
including entity components.
Here's a monthly breakdown:
March:
- map compiler
- interactive console from BTX
- asset loading
April:
- networking
- more accurate Half-Life-style player movement
- standard map entities
May:
- material system
- basic main menu
- a bit of documentation
- the first developer preview
And yeah, my engine project now has a name: Elegy.
Either way, I hope to get a little game demo out by June or July. I'll be reimagining my very first game project, so that will be fun.
Right now I gotta test Elegy on Linux, deal with college and all that other stuff. See ya until then. I may eventually create a website for this project so I don't have to post about it here all the time, though it is kinda nice.
I feel like the past 2 years (turning idTech 3 into GoldSRC, enhancing idTech 4, writing an engine from scratch) were more or less a preparation for this thing. Designing systems, understanding how my motivation works, keeping track of things via Trello and getting them done etc.
Also I forgot to mention this in the journal, but once summer's here, I will likely be looking for volunteers, mainly mappers and programmers. We'll have to see though! From experience I know stuff gets delayed, so that might as well be in autumn.
Now, I'm most likely not touching this thing until March, because February will be full of exams.
Anyway oof, I appear to have a nasty cold right now.
Grate work
I might even ask someday how to make a sectors generator for an engine. I guess making the sides (2 vertices down and up connected to another 2 down/up vertices) and maybe the sectors (Floor and ceiling) is easier for me to work with, but not generated UVs with offset and rotation values.