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 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:
Normally 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 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.
VISPORTALEXIT
seems similar in purpose to HL'sSKY
texture, with anything outside aVISAREA
basically ending up as part of a 3D skybox. As for portals, can't you derive those automatically from where twoVISPORTAL
brushes are touching or intersecting? That would simplify the level-design process somewhat.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.
So what this means is, the engine and client only know about something called
sharedEntity_t
, which is kinda like GoldSRC'sedict_t
andentvars_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.