Imagine Half-Life soaked in 2025's big gaming trends

Abiotic Factor looks like Half-Life, but plays like Subnautica. This summer, the game's creators released the official 1.0 edition of the game. Now, Russ Frushtick deciphers what makes this survival game tower above so many others. Plus, Plante dives into three new games from up-and-coming indie publisher Critical Reflex.

Games discussed:

Abiotic Factor

Troleu

Eclipsium

No, I'm Not a Human

Silksong

UFO 50

Movies and TV discussed:

• Brain Damage

• Basket Case

• Hacks

Comment discussed:

From listener Chad:

Wanted to touch a little on the chat about Hotshot's performance and its relation to the graphical fidelity. From a computer engineering perspetive, there are three really fascinating trends that I believe have caused this pattern of seemingly non-intensive games having some terribly poor performance. First, there's this unbacked expectation right now that a poor running program just needs stronger hardware to support it, which in this age is just not accurate. More accurately, software engineers are using stronger hardware as a way to limit the amount of optimization put into their programs - rather than have some meaningful looks at reducing the size of our program and rigorously ensuring memory is managed judiciously and intentionally, we can just write it the easy way and tell people to get more RAM. Secondly, while there's many great aspects of open source game engines and the reduced barrier of entry for new developers, they all unilaterally come with bloat and assumptions that will by default decrease performance vs an identically functioning program that only has what it needs. When building a game in UE5, you are using all the parts you need to run your game, but you're also running and storing everything else UE5 needs to do its thing. In its design are implicit and explicit assumptions that make programs run faster or slower, if they lean into UE5's assumptions or fight against them.

And thirdly, the classic, is a faster turnaround time with a shorter development window and significantly less time dedicated to addressing code debt or other technical improvements, preferring updates that are flashy to the end user: which typically ends up being visual or UX changes, things that are very obvious to the end user.

There's a lot of underlying technical detail that might be too boring for this post, but overall, a vast majority of poorly performing programs that I've personally seen (or made) have had some really simple breaches in logic that have hogged or poorly utilized resources; and indeed, one of the easiest things to optimize and improve performance nowadays is graphics. Stutters are probably not happening from the GPU side, but on the actual central processing side, as the GPU does hundreds of thousands of operations every clock cycle versus the maximum one operation on the CPU every clock cycle. I'm reminded of that one memory bug in GTA V Online, where the developers wrote some strange code that would open up a text file, pull its contents into a block of memory, copy a single line of the text file into another block of memory, and then copy that single line into yet another block of memory, and then close the text file, and then reopen it, and then read the next line of the text file, over and over, which caused a ~5 minute load time increase for playing GTA V Online for years. Just some really basic logical flow problems that went unnoticed, in no short part because the devlopers computers are significantly stronger and faster, their monolothic engine is humongous and probably not very rigorously tested in a piecemeal fashion, and because it doesn't necessarily impact Take Two's bottom dollar if people need to wait a lil longer to play a certain game mode