Journals

CPripyatUit20 hours ago2024-03-18 14:22:54 UTC 1 comment
Every time I try to make a map, I force myself to try planning it beforehand instead of building away willy-nilly. And every time, sooner or later, I sit in front of a stack of badly hand-drawn maps and am out of ideas. Stuff I draw doesn't fit, doesn't work, I had a better idea afterwards, the proportions are off, the page is too full… you name it.

I tried different approaches. Floor plan design software, for one, though it's tough to find any that is free, works offline or without an account, and lets you save in some useful format.

So last night, I thought: what about writing?

I know I can do that, so what if I wrote descriptions of the maps I wanted to do? It can only get better, compared to drawing and sketching...

VERY GOOD JOURNAL ENTRY

I decided to try to write a Journal post. You can now read this masterpiece of a post. If you happen to have stumbled upon this journal post and have read it to this point, please write "wasd" in the comments. Anyway, this function is quite a cool way of telling people what you have made progress on. Obviously, I didn't make any progress on anything and still wrote one. If you happen to have stumbled upon this journal post and have read it to this point, please write "blackmesascientist" in the comments. Anyway, I like this function and I might even use it properly some time in the future. If you happen to have stumbled upon this journal post and have read it to this point, thank you!

THE END
Every few years, after playing around with other games and engines, I touch Source / Half-Life² / Hammer again, and every time I go in with grand ideas about what kind of things I'd like to do. And every time, invariably, I quickly run into the limitations presented by the I/O system.

This time, I've come back to HL2 after doing some stuff with Arma III and BI's Real Virtuality Engine, namely the 3DEN Editor and the SQF scripting language, and the difference is night and day. The two engines almost perfectly complement each other; what Arma is lacking, Half-Life provides, and what Half-Life fails to do, Arma makes a breeze to achieve.

Whenever I was working with 3DEN, I would usually want to make some missions themed around urban warfare (or story-heavy missions), and the bottleneck would usually be level creation. The 3DEN Editor doesn't facilitate much in the way of creating new environments; beyond dropping new buildings or props into the landscape, the maps are immutable. New maps can be made, of course, with different tools, but anything like creating new houses instead of choosing existing models is a fairly big endeavour, and any sort of indoor scenes are usually close to impossible to stage due to the AI's limited-to-nonexistent navigational capabilities. Cinematics of any sort are hard to create, due to a limited set of NPC animations and very imprecise navigation that's largely oriented to squad-level movements on an expansive battlefield. What 3DEN and Real Virtuality excels at, though, is scripting highly-adaptable missions with any number of varied outcomes, custom dialogue, custom AI behaviour, custom gameplay features, the whole nine yards, due to its fairly trivially-learned scripting language and near-unlimited possibilities it offers in customising UI, NPC behaviour, interactions with world objects, and accounting for as many divergent player behaviours as the scripter is willing to anticipate. This makes it possible to make highly nonlinear missions.

Back to Hammer, it's the complete opposite. Building new things is trivial. The geometry tools are right there; short of vertex limitations, nothing stands in the way of creating any building the mapper can imagine. An entire city can be built from scratch, if so desired. Cinematics can be much easier, in certain ways; NPCs can be directed to walk anywhere with a nearly pixel-perfect precision, an extensive system for scripted sequences exists, and animations flow together much more smoothly due to the story-oriented singleplayer origins of the engine, as opposed to the MMO combat-oriented gesture system of Arma III. The navigation mesh is hand-built by the mapper, so indoor navigation can be as good as the author is willing to invest time and effort into; NPCs running into walls, failing to see doors, or being unable to navigate around trivial obstacles is usually a non-occurence. Compared to Arma, whose physics engine is virtually nonexistent, the Source engine allows liberal use of movable props, physics puzzles, destructible levels and objects that are easy to manipulate, and packing custom content with the maps is trivial as well.

Polar opposites. Taken together, the two would form a near-limitless engine.

And here comes the bottleneck, where my HL2 dreams are concerned: no scripting.

Half-Life² is an incredibly linear game. At no point is the player asked to make any sort of choice, at least none that matter beyond throwing cans at cops. There are no alternative routes. There are no side quests, optional objectives, no ways to fail partially without failing entirely. Reduced to its core, Half-Life² is a tube; what goes in at one end must come out the other end, following the only path available.

And that works fine for the game's campaign. It's much more of a ride-along movie with puzzle and combat interludes than an interactive narrative, it doesn't try to be anything else, and it does what it is very well.

But by these engine limitations, attempting to create any sort of nonlinearity in custom maps is very, very difficult.

I've been thinking a lot about projects like that lately, about what I'd like to make once I've reacquainted myself with the engine and tools sufficiently. Drawing on Warren Specter's famous quote about wanting to make games that are "an inch wide and a mile deep, rather than a mile wide and an inch deep", the idea of making small levels, perhaps the size of no more than a city block, that offer a multitude of ways for the player to engage with them, I've thought about ways that could be achieved in Source.

But doing that with the I/O system? A map that needs to keep track of, and adapt to, countless variables and changes in their values? It seems impossible, secondarily due to the entity limit, but primarily due to the sheer workload and the ever-increasing possibilities for increasingly hard to track errors to occur the more complex the I/O network becomes.

The one beacon of hope here is Mapbase, which to my knowledge implements VScript, something I have yet to learn. I've always been a little intimidated by Mapbase and largely dropped out of RTSL mapping tournaments when they switched to routinely mandating Mapbase, simply because at the time I couldn't figure out how to install it and was just glad Hammer worked for me at all after an extended stint with perpetually broken game configurations for mods (maps not updating, maps failing to compile, etc. etc.). I ought to take another look at that some time.

Idk. I just needed to get all that out. I'd still love to make less linear, more freely approachable HL2 maps and try to bring more of that New Vegas, Deus Ex, Mankind Divided feel over to the Source Engine. Of course the obvious solution would be to simply switch to a game and engine that offer more support for the kind of maps I want to make, but it's a labour of love: I love Source / Half-Life², and I want to make and play the kinds of maps I dream of in the game I love playing so much I'm still doing it in 2024.

P.S: Two additions I forgot earlier:

One, perhaps the best way to compare working with NPCs in Arma III vs. Half-Life² is this: in Arma, it's easily possible to create NPC behaviour that will dynamically, react to certain map/story events, in variable order (within the boundaries of what you prepared), but very difficult to exercise precise control over an NPC. In Half-Life, it's easily possible to manipulate an NPC with minute detail, but very hard or often impossible to set up any sort of behaviour that will continue working once you take your hands off the reins.

Two: one more limitation of HL2 is that custom dialogue or custom scripted sequences are very hard to implement purely on a map basis, because they require things like recompiling scenes.image, editing game-wide files like language files for subtitles, etc. In Arma III, custom dialogue relies on its own, separate subtitle and script files, much like HL2 custom materials and models can be packaged into the map.
Overfloater6 days ago2024-03-12 18:29:38 UTC 0 comments
So with the open-sourcing of Pathos being more successful than I expected it to be, and after fixing bugs and other issues and having a bit more of a stable build available on GitHub, I've decided to take a bit of a break. Truth is I've spent the last few months working tirelessly on Pathos(and by extension, my game), and I've hit a bit of a burnout. Spending hours upon hours on one bug I couldn't fix yet made me realized, I've become a bit obsessed with it.

What does this mean? Basically, I will be online less, and I will be taking a break from working on Pathos for a little bit. I'll still check any issues that are reported, from time to time, but I will be unresponsive for a bit. So if you find any issues, please raise it on GitHub so I can track it easier.
Names are for unlosers1 week ago2024-03-09 11:01:37 UTC 4 comments
Ever wondered how to get to those batteries and health packs in that one blast pit room?
Well turns out you have too... walk on the slope its actually really easy why
User posted image
Overfloater1 week ago2024-03-06 21:20:08 UTC 5 comments
So... I didn't think I would crunch this hard, but I did it. I spent the last few days working tirelessly on the public release of Pathos, to remove spoiler code and content, to remove as much Half-Life content as I could, and to write documentation. After all that blood and sweat, I present to you, the public release of Pathos on Github:

https://github.com/TheOverfloater/pathos-public/tree/main

This includes the files required to run the game, along with some example levels, example NPCs and models. I have decided that for now, I will not include the custom Hammer editor I use due to obvious reasons. I recommend using JACK, but more is explained in the readme.

I hope you find it useful, and enjoy.
Overfloater1 week ago2024-03-05 16:00:33 UTC 3 comments
I've been contemplating this for a while, and I've recently come to the decision that I will be open-sourcing the Pathos Engine. After the experience of needing to maintain and provide fixes for Trinity back in the day, I was put off by the idea of having to do the same all over again, while at the same time being busy with the process of creating a video game as a one-man team.

For those who do not know exactly what Pathos Engine is: Pathos is a Quake-like game engine heavily inspired by GoldSrc. It offers extended limits, better graphics and better performance, support for HD textures, vertex weights, normal mapping, specular highlights, dynamic lighting with shadows, and a lot more. This all without any copyrighted code attached to it. Unlike Xash, it does not rely on Half-Life code at all. Everything was reproduced with a clean-room approach while referencing the Half-Life SDK and ReHLDS, as well as the Source SDK.

This means that while the game is very similar to Half-Life and Quake, it is not the same engine. And as far as content is concerned, you are still not allowed legally to use Half-Life code and content in Pathos. Pathos is not compatible with GoldSrc mods, and attempting to run such content on Pathos will cause issues.

I have several videos on my YouTube channel which show Pathos's development progress, and new features:
https://www.youtube.com/playlist?list=PLQnXkjA1l7uamgh8_ZnrFPSQxm1Kr91oA

I have already begun work on an open-source version of Pathos, one which is missing most if not all game specific code and content that would qualify as spoilers, or placeholder content I do not on, which I cannot just release. This version of the engine will offer the same expand-ability and functionality as the one my game uses.

However, I also believe that Pathos can offer the community a lot, in the form of a perfectly legal engine replacement for GoldSrc. People have become more and more frustrated with recent updates to GoldSrc, in which Valve still refuses to provide useful updates, such as upping the model limit and the AllocBlock limit, for example.

For now the current hurdles I am facing are the following:
  1. The need to ensure that no content remains which would act as spoilers for the game I am building on Pathos.
  2. Removing content that is not needed for the example game to run.
  3. Removing Half-Life 1 textures, sprites, sounds and models.
  4. Writing documentation for each entity in the game.
  5. Writing a comprehensive credits list.
Currently I have already accomplished tasks 1 and 2 mostly, but there's still work to be done. The remaining HL1 textures and models will be wiped clean from the code with proper replacements provided. This part is not that big of an issue, but it will take time to do so.

As far as entity documentation is concerned, this will take a bit of time to accomplish, same for the credits list.

So when will the release happen? I can't provide a deadline, as the amount of work left to be done is not small, and I need to make sure that legally, Pathos is covered and won't end up like Xash when it comes to Valve.

Speaking of which...
  • The level editor
Pathos's model format requires a custom level editor, and currently there are no alternatives, other than the custom Hammer I use, which was based on the 2003 leak code. There have been previous examples of people releasing custom Hammer binaries(Hammer++) and Valve not really caring, but one thing which would be great, is to add support to TrenchBroom, however this again depends on how much time I am willing to sacrifice for this purpose. In all likelyhood, I will be providing the custom Hammer binary without any sources as part of the release.
  • The model compiler
Pathos uses a custom model format for model geometry data, in order to support vertex weights and facial animations. However, I am still using the original HLSDK studiomdl code, albeit heavily edited. I would prefer not sharing the source code for this until I have my own clean-room version for Pathos available. So until then, I will only supply the binary with the release.

So, I hope this has gotten people excited. I will try to get things out the door as soon as I can, but I can't promise anything in terms of timelines. I hope to keep you updated as this project goes on.

Edit: Decided to edit my opinion regarding JACK out. Regardless of me thinking it's the most likely scenario, that's still just like, only my opinion, so I'd rather everyone treated it as such.
FranticDreamer3 weeks ago2024-02-22 22:38:16 UTC 4 comments
Some Time Passed until 23/02/2024
Meerjel013 weeks ago2024-02-22 20:49:54 UTC 1 comment
User posted image
Names are for unlosers3 weeks ago2024-02-22 16:18:55 UTC 1 comment
while playing half life i quicksaved while a barney was saying "Got another one!"
there was a brief freeze while i was saving, after the "Go" and it resumed at "ne!"
this resulted in barney cheerfully stating "Gu n! :D"
funny
the end
Goonty3 weeks ago2024-02-22 14:58:05 UTC 4 comments
My single player Op4 campaign (tentatively titled "Op4: Wrench/Barnacle/Snipe") emphasizes use of just the wrench for most of it, then the grapple, and finally the sniper rifle.

Do people generally hate that? The problem I face is that, for people who love the wrench (like me), it's extremely easy to clear rooms of monsters. For people who hate melee, it will be super difficult.
Erty3 weeks ago2024-02-21 23:56:05 UTC 4 comments
Hi, hope you all are well!

For me I've just been very busy at work and stuff, and most days been too tired to work on any personal projects. Most of these days have just been working, cooking, and trying to sleep. 😅

But had a few days where I managed to force myself to argue with geometric planes and fix up silly mistakes and eventually got the MAP parser and converter finished up and released a new beta version of Map2Prop (and with that also opening the repo to the public).
With that I feel like it's getting near to a state where I can confidently elevate it out of the beta and up to a proper full release. With that comes of course the question of what remains for that.
In the development branch I've already added a config option and CLI argument for auto exiting on finish (instead of waiting for input). I decided to keep the wait-for-input on finish as the default behaviour to give non-CLI-savvy users the opportunity to see the success message or alternatively any possible error/warning messages before the window closes. This option should make it easier to use the application in batch scripts and such, which will later on open up for including it in map compile processes.

Next up is making use of tool textures to accomplish certain tasks. So far I've got this list:
  • ORIGIN: Set a custom origin point for the model instead of using world origin (removed from mesh)
  • BOUNDINGBOX: Set the parameters for the $bbox QC command (removed from mesh)
  • CLIP: Set the parameters for the $cbox QC command (removed from mesh)
  • CONTENTWATER: Mirror all faces of the model
  • BEVEL: Smooth all vertices within this volume (removed from mesh)
  • CLIPBEVEL: Do not smooth the vertices within this volume (removed from mesh)
Lastly I want to create a FGD with a custom brush entity class that will be read by Map2Prop. The idea is to include Map2Prop in the compile process and when fed a MAP file it will read these custom entities, convert their brushes to models, and change these entities to item_generic/cycler_sprite/etc (classname will be specified using a keyvalue) already filled out to use the newly converted model.
The entity class will include keyvalues to configure many of the options already exposed in config/CLI but on a per-entity basis (this will of course also be available outside of the compile process context).

I haven't decided yet whether any of these features will have their own release, or if I'll save all of them for v1.
I want to thank you all for the love you've shown my silly little project already. I'm looking forward to seeing all the maps you guys are making using it and I hope it continues to be helpful 😁
Dr. Orange1 month ago2024-02-18 16:37:11 UTC 4 comments
2️⃣3️⃣
Overfloater1 month ago2024-02-04 20:02:24 UTC 2 comments
So Valve's 25th anniversary update pretty much broke all custom renderers that would replace Half-Life's world renderer code, and that meant I had to jump into Trinity and apply some fixes. I initially thought I only had to change one engine structure, but oh boy, Valve had some surprises for me. Turns out they now use a variable which I previously used for storing indexes, as it was never used previously. I had to totally rewrite everything that dealt with that particular bit.

You can find it here:
https://github.com/TheOverfloater/trinity-engine
  • Abyss Engine
I also wanted to provide some updates on some stuff I spoke of in the Discord. As most of you know, Trinity eventually evolved into the Abyss Engine, used in Abyss-048 and Half-Life Episode Two, and now also a mod called Nohra's Concealment. This engine revision has improved code, such as studio models rendered in retained mode, and support for vertex weights. It's also an all-shader based renderer, which means it's far faster than Trinity was. It uses OpenGL assembly shaders, which means it has very wide support across different GPUs.
So why do I bring this up? I'm planning on revising the Abyss Engine and bringing it into a form that can be open-sourced. I will post that also on my Github page once it's done. My plan is to give it as part of a clean SDK much like Trinity, but that'll also require some work.
  • Reckoning Engine
The third and final revision of the engine is known as the "Reckoning Engine", which is what it became before I moved over to my custom engine, Pathos. Now the Reckoning Engine is a very different beast and it also breaks compatibility with some HL features, like switchable/animated lights, but instead it supports those features for dynamic lights. This revision of the engine is completely shader-based also, and uses GLSL. The list of features is way too long to discuss here, but things like a rudimentary facial animation system, variance shadow mapping, support for Paranoia's bump map data in the BSP, specular light reflections, etc are there. I plan on eventually open-sourcing this engine version as well. Opensourcing this version would be a rather difficult piece of work, but it's doable.
  • Raven City
I have been thinking of releasing the corpse- er, I mean, the most playable version of Raven City for those who might want to see this mod. Time here is a major factor, of which I don't have much when it comes to fixing some broken things to make it work. It also doesn't help that the mod is in some ways an absolute cringe-fest and I want to just remove some... really embarrassingly cringey crap from it. Another issue is that it requires a very specific version of Cg to work properly, which I need to dig up from somewhere.
  • Half-Life : Retail
I think it goes without saying that with the HL25 update, this is effectively cancelled, but I will probably upload the source code at least on Github, but I won't create a final release.
savvaisnotagirl1 month ago2024-01-24 20:11:04 UTC 1 comment
It's been a while!

I wanna write down what I've been up to for the past 6 years, since I was always active, just in different communities, but a separate journal would be necessary as it's a long story. Right now, I want to share what I learned during my development of my first Half Life 2 Deathmatch map, including creating custom VBSPs, color correction, and general discoveries I encountered.

When I first got the idea to make an HL2dm map, I was probably watching old nostalgic 3kliksphillip video and stumbled upon his tutorial on moving water through func_water_analog. I immediately brainstormed ideas and wandered if the functionality even worked in Half life 2 Deathmatch. So far, I played around 100 hours of HL2dm, which isn't a lot compared to my TF2 playtime which is like a 1660% increase, but enough that I realised there's not many maps in HL2dm that utilize func_water_analog, at least one's that aren't killboxes or Undertow from HLDM. So I quickly created a map in hammer just to test this proof of concept, and it works like a charm!
User posted image
The entity isn't the most stable as it is with other source games, but it serves its purpose and the lag compensation helped make it bearable enough for even 100 ping tests. I only hope that the next Mapbase update for Source SDK 2013 MP will fix and give additional parameters for func_water_analog and other entities for HL2dm. Now, it was time for me to conceptualise the gimmick and how to make it fun.
User posted image
After trying to test out and create water textures that would work with func_water_analog, I quickly realised that swimming in HL2dm wasn't fun at all and it was too difficult to create good looking water for the entity due to its limitations. Instead, I went for the toxic slime approach as it gave me a few desirable gameplay approaches:
  • It becomes a hazard that players will have to go around or use physics props to get across, creating an interesting dynamic that allows players to do quick manoeuvring to gain an advantage against their foes.
  • It creates a risk reward style of gameplay with boats located in the canal, where some items and weapons are laid for players to try and snatch.
  • It creates a more balanced secret path that requires the toxic slime to be drained in order to access and retrieve the RPG, making players more intrigued and vigilant in their task for the most powerful weapon.
It was through this thought process that I knew I wanted to continue working on this map. I always wanted to make a form of HL2 or HL2dm map but never had any concrete ideas, at least to continue and finish the work. But now, I wanted to make a map based on this idea, and I went and looked for references on canals. The Panama Canal was an obvious choice that I chose its namesake.
User posted image
Now that I got a reference in mind, I went ahead and quickly developed a layout. I went through my HL2 buildings prefabs and picked out some that I believed would be appropriate for the theme. It had to make sense taking place in a jungle like area with developed enough infrastructure to support one of the largest trading networks in the world. That said, the 7 Hour War also destroyed much of the world, so a little dereliction with HL2 assets would be good. Throughout plopping down these buildings, I eventually got the idea to also add Team Deathmatch support to this map and have it work as a Rebel Vs Combine map. And so, the early layout started looking like this:
The CanalzoneThe Canalzone
Combine BaseCombine Base
Rebel BaseRebel Base
Derelict HouseDerelict House
SewerSewer
Whether this was my subconscious guiding or a stroke of luck, you'll notice that the Rebel side has more warm orange shades, while the Combine side has much more cold blue shades. I noticed this early on in development and decided to play to its advantage, helping players realize what side of the map they're on. I also wanted to take full advantage of Counter Strike Source and TopHaTTWaffle's texture pack for the source engine, as both had warm colorful textures and useful models that helped sell the theming of a Central American vibe. With these assets, I had a clear path on recreating the buildings from the reference image as well as from my own ideas.

Early on during my texture work, I chose a bright blue skybox texture from TopHaTTWaffle's pack, which looked great on its own, however in-game it looked weirdly dull and flat. I tried saturating and editing the texture manually to get the colors to pop, but I realised that the dullness was likely due to how other textures around affected the look of the skybox. I found a better solution, I experimented with color_correction and found that it not only made the skybox better, but it helped with the Panama vibe by making all the colors vibrant and fitting the tropical environment.
User posted image
For anyone who want to experiment with color correction in their map, keep in mind that there is a bug in the source engine that sometimes doubles the intensity of color correction in the map. The best way to fix this is to get a neutral .raw file and apply that to your existing file at half opacity in photoshop. Full tutorial on the fix and other color correction tips in Source Engine can be found here.

Continued in Part 2...