GoldSRC + Godot = ???

Posted 3 years ago2020-10-24 12:12:40 UTC
Admer456 Admer456If it ain't broken, don't fox it!
My last post in "Post your WiP screenshots" was about my modification of the idTech 3 engine. Now I decided to take it to the journals, since it's ultimately unrelated to Half-Life. But not entirely.

Simply put, the ideas are:
1. Have a GoldSRC-like folder structure: maps, models, sound etc.
2. In mapping, work with it almost as if it were GoldSRC or Quake (this means you make the map in J.A.C.K. or TrenchBroom or whatever)
3. Don't use any Half-Life asset formats or anything from the HL SDK
4. Keep the aesthetic of GoldSRC

It's mainly for folks like me, who are too used to GoldSRC but still wanna make standalone games using archaic methods.
I moved the project to Godot, primarily due to licencing. Not being able to use certain libraries, due to GPL, sucks.

Now the challenge is even more interesting, because I'll need to build a "game engine" on top of Godot - something vaguely similar to what S&box is doing; also somewhat similar to what SharpLife is doing - because I wish to keep the GoldSRC-like workflow: make a map in an external map editor like TrenchBroom, export, compile, and put it somewhere in the maps folder. Then run the engine, open the console and use the map command. No Godot Editor involved.

One neat thing I'm planning to do is manual VIS, since there's no VIS in Godot, or rather, no occlusion culling system. Manual VIS, done in the map editor, would look like this:
CryEngine Sandbox Editor manualCryEngine Sandbox Editor manual
How you'd do this in J.A.C.K., I imagine, would be to place two big brushes textured with VISAREA, each encompassing a room they're associated with, and between them, you place a smaller brush textured with VISPORTAL. I believe that humans are more efficient at optimising a map than the compiler. Anything outside of VIS areas (isn't encompassed by any such brush) would be treated as the outdoors, which is never rendered from the indoors, unless the player sees a special VISPORTALEXIT portal.

Here's an illustration:
User posted image
Normally world brushes; I only used func_wall to get the transparencyNormally world brushes; I only used func_wall to get the transparency
The compiler would have to strip off the NULL faces etc., mark which face is in which area etc. and that's about it as far as the basics go. In that early state, maps will have to be made in a specific way, for example, you'll have to cut brushes wherever two VIS areas meet:
Kinda tedious, I knowKinda tedious, I know
If I develop the compiler any better, it'll automatically cut stuff where two areas meet, which is basically what Doom 3's map compiler does.

We'll see where this goes. Worst-case scenario, I'll just go back to idTech 4 and dumb it down lol.


Commented 3 years ago2020-10-24 19:15:32 UTC Comment #102991
Commented 3 years ago2020-10-31 23:44:51 UTC Comment #102997
So basically, instead of the CSG/BSP/VIS/RAD pipeline, you're only using a VIS process, at the expense of having to manually set up visibility areas? That's an interesting idea. I wouldn't be surprised if applying this to HL would result in similar performance to what you'd get from the 'traditional' approach.

VISPORTALEXIT seems similar in purpose to HL's SKY texture, with anything outside a VISAREA basically ending up as part of a 3D skybox. As for portals, can't you derive those automatically from where two VISPORTAL brushes are touching or intersecting? That would simplify the level-design process somewhat.
Commented 3 years ago2020-11-01 18:47:14 UTC Comment #103001
The truth is, I don't even have to use VISAREA brushes. I can quite simply mark everything "between" VISPORTAL brushes as a visarea, basically what idTech 4 does. The only issue with that is the consequential existence of leaks, whereas with the system described in the journal, leaks don't have to exist.
If I gain any greater understanding of VHLT, I might as well implement this idea in HL. xD

Anyway, I moved the project from Godot back to idTech 3. A month's worth of work has been undone, for the greater good.
User posted image
In a nutshell, I underestimated the required amount of work to do the new entity system properly. The plan was to integrate a common entity interface between the game DLL, client DLL and the server part of the engine. But, since I need to start making a game in January or February, and finish a demo by May (for a local gamedev competition), I decided to drastically decrease the needed work (and time) by keeping the entity interface only in the game DLL.

So what this means is, the engine and client only know about something called sharedEntity_t, which is kinda like GoldSRC's edict_t and entvars_t, while the game DLL will have a bunch of different entity classes.

It's not a big deal. I can still implement entity components the way I imagined, and I can get rid of the old game entity (gentity_t) system.
Commented 3 years ago2020-11-03 09:19:37 UTC Comment #103015
Worldspawn is now a thing. Of course, the engine crashes because players are still entities from the old entity system. This will be a simple fix.

You must log in to post a comment. You can login or register a new account.