The Cabal: Valve’s Design Process for Creating Half-Life (1999) | Hacker News Reader

The Cabal: Valve’s Design Process for Creating Half-Life (1999)

gamasutra.com

188 pointsthisismyswamp84 comments

That's a refreshingly good example of "design by ...cabal..." actually working out pretty well. I think the key element is how the members actually had to implement their designs. If you just come up with a lazy compromise, it'll start haunting you immediately, and not just after the worker bees did their thing.

I think the "cabal" responsible for USB 3.1.1.1.gen2-420gig-whatever should have done the same, with each meeting ending in every member having to explain to their grandma why she can't connect her monitor to her laptop even though the cable fits perfectly, and that it's somehow _both_ the wrong cable and the wrong laptop port.

I've noticed that happening a lot in my time in the games industry as well. The person making top-down design role isn't exposed to the friction that their decisions are making down the hierarchy. I think the worst part is that they're not even necessarily as invested in the product as someone else, so they're kind of structurally going along with the inefficient situation they're in.

Cabal. Design Bible. All grounded in the Single Source of Truth philosophy. With feedback from 200+ playtest sessions directly incorporated into the stream. And the result is the cohesive narrative vision in Half-Life.

Contrast this with "What Went Wrong with Cyberpunk 2077" exegesis from Bloomberg this morning and I'm still not sure anyone can point to a single reason beyond "we were too ambitious". I wish this breakdown were more technical in nature. Like a good GamaSutra postmortem. I suspect tooling plays an enormous role. UE4 Blueprints are phenomenal for visual development. But does it scale to teams of hundreds of designers?

Inside Cyberpunk 2077's Disastrous Rollout

https://www.bloomberg.com/news/articles/2021-01-16/cyberpunk...

It's interesting to me how the physics bugs such as characters and object getting stuck inside walls, flying cars, failed inverse kinematics and so on have been the usual bugs for so many years now, but there isn't yet a methodology to prevent gamedevs from falling in those old known pitholes. These are very difficult to detect by QA and the way to fix them is tweaking some parameters and geometry here and there. There should be a way to supervise the physics engine, find whether future calculations will cause an invalid state on some object and choose a transformation that won't produce such conflict.

As with everything in gamedev it comes down to one thing: performance. Anything that can be faked, approximated our outright hacked in the name of perf or memory will be.

The canonical example for me(which was ironically is in Half-Life) is that the AI for the grunts is surprisingly simple. If you throw a grenade they were scripted to shout "grenade" and navigate to the nearest nav node.

Tons of people thought there was really complex AI behind that behavior but it was just a couple of really well telegraphed "if()" checks.

This anecdote reminds me of the AI in the original F.E.A.R game as well, which did something similar. The actual AI good on its own, but their barks did an -amazing- job telegraphing their behaviors. Like if they shout "flank him!" and then flank, you know because they announced it that the AI made the conscious decision to flank and it wasn't just some NPC incidentally wandering into a flanking position.

There's a talk somewhere about the F.E.A.R. 1 AI and there were two key changes made in the development: 1) it was restricted so that only a handful of actors can actually attack the player at the same time 2) introducing loud radio chatter because playtesters grew frustrated dying over and over to the AI just flanking them quietly. Before these changes playtesters were frustrated because they thought the AI is cheating (which it isn't).

Some devs do focus on it - this blog post goes into detail about how someone worked through making sure you could walk everywhere in The Witness: https://caseymuratori.com/blog_0005

> There should be a way to supervise the physics engine, find whether future calculations will cause an invalid state on some object and choose a transformation that won't produce such conflict.

This is probably just me not really understanding the domain, but this sounds like a version of the halting problem?

Even if it’s not, isn’t that just an extra layer doing what the collision engine is meant to do in the first place? And if you can monitor a system to ensure correctness, couldn’t you use a similar mechanism to make the original system correct to begin with? And if you can’t do that, how can you expect to make the supervisory layer correct?

Let's say when a cylinder of the car, a wheel, bumps into the infinitesimally sharp edge of the road, it could somehow result in a "singularity" that launches the wheel, the vehicle and its occupants to the sky, and that could be a perfectly valid result of that algorithm. The algo's task is not to determine whether that produces some "weird" animation from the player's perspective.

For that reason there should be a "user level" interpretation of the physics engine results, looking ahead in time and correcting.

What I’m failing to articulate is that it seems like if you can reliably look ahead to detect a “weird” but technically valid result of the physics engine, you’ve also detected the flaw in the physics engine that led to that result. At that point you should just... fix the bug.

“Let’s monitor in real time for whether any possible combination of inputs could produce a technically valid but undesirable state” doesn’t sound any less complicated or more effective than finding bugs and fixing them.

And yet you still see that approach in the wild. In the game destiny 2, there are a slew of bugs which seem to result in failed assertions, at which point your character suddenly dies. The message which describes what killed you will read "Killed by the architects" as a catch-all. The game has been under development for years and years but somehow the players (and bungie) have come to accept random dying due to physics and netcode bugs. I'll say it's better than an outright crash, but not by a lot.

Huh. It still seems there’s a meaningful difference between “if we’re in a bad state, kill the character instead of trying to recover” and “see a bad state coming in advance and avoid it”, which is what parent proposed.

The Destiny version doesn’t require understanding the bug, only recognizing after the fact that the player has, say, clipped out of bounds. Doesn’t matter how you got there. That sounds like a decent compromise for a pvp game where preventing exploits is very important.

But being able to extrapolate that the current state will lead to a bad state implies that you already understand the bug and could, you know, fix it.

Yes, you're right. My example was not quite the same. Detection of errant state is sort of the starting point, knowing preconditions is a step further in debugging.

For that to happen, you’d first have to detect that the wheel bumps into the edge. Checking for collisions takes CPU time.

Well stated argument! I always wondered why your car sometimes launched to the sky in Stunts, from 1990.

Yes, you could have for example energy limiters and total momentum checks in your algorithms. Energy can not be added in a collision. In a collision between two finite mass objects, total momentum is preserved (you can't use this with collisions with the ground). Maybe games already do this?

You could also just fudge the equations to avoid singularities, like always add +1 to the divider. This could probably cause other problems though.

Testing things like that is a little weird - they're inherently fuzzy, so even if you compare to a ground truth like a serious MBS package you're spending needless FLOPS on accuracy no-one will notice.

I guess if you are able to formulate the problem as a state machine, you could use something like bounded model checking to ensure it doesn't blow up, but the problems there are twofold: Firstly, that's way too complicated and brittle for a game codebase, and secondly your average game developer probably doesn't even know what it is to begin with.

>UE4 Blueprints are phenomenal for visual development. But does it scale to teams of hundreds of designers?

This comment seems to come out of nowhere. Cyberpunk isn't written in UE4 to the best of my knowledge. But rant time! I love ue4 blueprints. I think they're the bees knees because documentation of things is so hard, but blueprints make that so easy! The ability to grab a bunch of nodes and collapse them into one node means you can comfortably make your top level view of things just a series of collapsed nodes with long form descriptions in full sentences. So your high level stuff is basically pseudocode.

Most people don't do this of course. But then most people don't write good code, and lots of people writing blueprints one sees in the wild don't even know how to code to begin with.

Blueprints are, imo, what people really want when they think they want jupyter notebooks for data science.

> Cyberpunk isn't written in UE4 to the best of my knowledge.

It’s in (their in-house) REDengine 4 according to Wikipedia (citing https://archive.today/20180405084214/https://www.gamezone.co...). But perhaps that has Blueprint-inspired visual development tools?

node based game dev has been around decades before Blueprints.

Monkey Hero (1999) used node based game dev and I'm sure they weren't the first.

>>> comment seems to come out of nowhere

Most definitely represents my scatterbrain state of mind as of late ;)

As boogies states, this is the crux of what I was trying to get at re: tooling. Considering Cyberpunk 2077 as a massive non-linear narrative. What does the graph tying it all together look like? With hundreds of designers adding their contribution. How do you reason about the whole? Even basic algorithms such as "can I reach this node from every other node"?

Talking about Unreal Blueprints, did you know creating a new blueprint node is as simple as writing a C++ function and adding a reflection macro on top of it, that's it. It's freaking awesome.

I haven't tried that but it did seem straightforward. Personally I think it would be much more useful if you could go the other way around. Define a node sort of like an anonymous function/first class citizen kind of thing, and pop open a little code editor that lets you write the implementation with all of the boiler plate pre-generated.

The only time blueprints fail me are

1) Really nitty gritty networking stuff 2) More classic CS algorithmic stuff, with strings, arrays, sorting, etc.

The latter feels very solveable. Maybe in ue5...

Speaking of blueprints for data science: https://www.luna-lang.org/

Hmm... Not to sound pessimistic but there's something I hate about this. It looks like a futuristic sci fi ui you'd see in movies. It looks... complicated even though it expresses something simple.

This feels wild, in a good way, but I wish there were python or julia: >Luna will let you paste any Haskell, C and JavaScript code into a component, handling the Interoperability for you.

> UE4 Blueprints are phenomenal for visual development.

My guess is that it probably doesn't scale all that well. I think the issue it's so much the technology but the people who use it - when you see UE4 projects labelled "Blueprint only!" what that usually means in my experience is unmaintainable, unsearchable, no version control etc.

They're great for animations, but for anything vaguely structured they're just slow and RSI inducing.

HL to Cyberpunk 2077 is very much apples to oranges, on many levels.

* The team size required for a modern day AAA title is significantly higher than that of HL days.

* The games design choices are vastly different. HL was very on the rails, though hides it it really well by giving you the illusion of a large world, this a really great design trick and HL is rightly lauded for it. In contrast CP2077 aims to be closer to a true open world that tries to provide a linear storyline inside a large world with more open level design with many auxilary story lines and interactive world building.

* HL had a single platform focus (PC) for the initial development whereas CP2077 try to straddle two very different hardware generations and a multitude of platforms. If CP2077 had, in a hypothetical world, only focused on PC and maybe current gen consoles (PS5 and XBox S) it would not have nearly the same level of negative press.

The team size required for a modern day AAA title is significantly higher than that of HL days.

I'm often left unconvinced by statements like this. Is it that the team size for a modern AAA title is required to be so large, or is it just that they are so large? The diminishing returning from making teams ever bigger makes me wonder if having such large teams are just a sign of low-level, dragging general incompetence somewhere in the chain of people running the whole thing.

I don't have any hard evidence either way, but every so often when I see a small, well-run team of competent people turn out something really good, I wonder.

For CP2077 vs HL it's pretty obvious why it would need to be a lot larger, with the sheer volume of art assets, story writing, level design, voice acting, game balancing and engine sophistication required. But I'll be the first to echo your sentiment that there are massive diminishing returns on team size.

Of course in many ways AAAs have dug their own pit of despair with this, they throw so much investment into it that they need to make sure they appeal to as large an audience as possible and cram as much content as possible in, while also having an eye to DLC later down the line, the economics demand it. Hence why CP2077 had to desperately try to get it to work on last gen console, otherwise they'd be immediately removing a massive portion of the market.

As consumers we can get as much enjoyment out of some indie level gamer. I for one have play way more hours of The Binding of Isaac than any AAA title I've played and it would have been a fraction of the development costs.

I think the team size grows with open-world multiple storyline type games like Oblivion/Skyrim. I haven't played CP2077 but from the sound of it, it's in that realm. They have a core group that programs the actual mechanics, physics, play - but then separate teams create content missions and bosses (and boss fights). That's where the spend is. And a lot of people can play these games for a really long time because there are a lot of different side missions. ... and eventually DLC.

A lot of what defines AAA games these days is that, as much as possible, every moment has some kind of hand crafted element to it, often not constructed from the core mechanics. In the days of half life and what not, distinct content was mostly in the form of level design and enemy placement and what not. In AAA games of today its from scripted sequences that are more movie esque. I think its a bad direction tbh. It's too expensive and, especially in an open world game, you end up with an uncanny valley of super deep and super uninteresting gaps of content. I think breath of the wild was the one game to make a more traditional approach work with open world content. There's NOT a lot scripted sequences. Most of the fun is emergent from a small but comprehensive physics system. You don't see a whole lot of new elements around each corner, but it works.

But if your goal is hip cliche AAA game, yeah, you need the huge team. I don't know if its much of a diminishing marginal utility of devs/artists either, so much as a sprawling tree of parallel but unrelated pieces.

The newer tomb raiders are the epitome of this to me. Every five minutes you're on a death defying leap with crumbling architecture or whatever. As close to the video game ideal of "every frame a painting".

To me, more successful "open-world" games these days are not that open, but are rather smaller, denser, and sometimes vertical. Sleeping Dogs nearly a decade ago and Yakuza now fit that paradigm, and do pretty well for it.

A handcrafted open world doesn't scale all that well, and Cyberpunk, from my impressions, seems to be both large and vertical, which makes the challenge even harder. Pretty much the only open-world I've enjoyed in recent years is BOTW, and that world is pretty empty, if only because the setting is literally an apocalypse where most people died. (In fact, for people arguing for interaction density, there is a collectible in the game that is revealed when it is 100% to be a pile of feces, specifically to make fun of 100%-ters.)

Yes, it scales well. Also, Cyberpunk 2077 doesn't use UE4.

I truly don't understand the Cyberpunk2077 complainers. Has any of you/them actually played the game? I've played it on Google Stadia and loved it, the main story and major side stories were exciting (Konpeki Plaza really had me on edge), combat is complex, characters are well written, graphics are amazing. As far as bugs are concerned I had to reload an earlier save maybe 3-5 times over the span of 40 hours of gameplay, which is not good but honestly I didn't care. It does look like the console versions were worse off, though, but I didn't play these myself.

No, many complainers haven’t played the game, because it crashes or runs terribly on their on-spec device.

If your answer to that is “buy a new device”, you need to get outside more.

What have you tried to play it on? Genuinely curious, the whole thing feels like being gaslighted (I get that it doesn't work well on consoles).

> crashes or runs terribly on their on-spec device

like which device exactly ? Most complaints were about base PS4. This is how it runs on base PS4, those are the "mayor" game breaking bugs people are crying about: https://www.twitch.tv/videos/854702029?t=00h45m00s [1] https://www.twitch.tv/videos/857020318?t=01h09m53s [2]

TLDR:

- 30fps with drops to 20. For reference Remedy shipped Control running all the way down to 10fps [Both PlayStation 4 and Xbox One can see prolonged frame-rate drops in sustained combat, dropping all the way down to 10 frames per second at its absolute worst.] https://www.eurogamer.net/articles/digitalfoundry-2019-contr...

- crashes once every 5-7 hours of continuous gameplay. Not a game breaking problem since it auto saves often. Saving game is one of the fastest of any games I played, its instant, no slowdowns when autosaving.

- has problems with streaming game assets on time (geometry[1], animations[2]). Claire's races are perhaps the only problematic part of the game due to this bug. GPS markers on the ground load too slowly.

... and thats it. The rest of the game works exactly as on other platforms, including random animation glitches.

I don't understand this response, I have seen it repeated many times over many threads about cyberpunk. You've no doubt seen the thousands of reports of game breaking bugs across all platforms, PC included. Do you believe all these people are lying just because you had a different experience on Stadia? I don't get the logic. Feels like St Thomas.

Personally I had to get a refund after a few hours because of dozens of crashes, and an unreasonable amount of bugs, and I really wanted to play that game. I even installed Windows to be sure it wasn't Proton related. My PC is high-end.

Worked perfectly well on my Xbox Series X, my brother played it on his PC. Crashed few times, yes, but nothing that bad.

Game itself is remarkable by quality of the story, acting, etc. World is huge and beautiful. Insane amount of quests. In GTA V, for example, you can really only play golf outside of the main quest line.

100% agree.

As to the grandparent comment - one day maybe I will understand what really causes this split in reception/bug prevalence, but today is not that day. Very much recommended (and save when you play, not only because gonks can jump you up, and not only because you may fail to date the super hot Panam [or River for the ladies], but also because it does crash/break every 5-10 hours of gameplay).

> this split in reception/bug prevalence

a split between the older gen and next gen consoles/PC? Or perhaps a gradient of bug tolerance, compounded by how much issues each user experiences (depending on the hardware used). Though I've heard that it's not just the bugs that cause issues

I’ve played it on PC. I enjoyed the gameplay, main and bigger side missions a lot. But I had so many minor, mostly visual, glitches, it really threw me off. Floating everything’s (cigarettes for Johnny, traffic lights, guns), my character T-posing while driving, other characters T-posing, my car randomly exploding when I call it, my motorbike getting stuck in another vehicle when calling it, and so on. In addition a few gamebreaking bugs requiring me to load an earlier save, one even required me to load a save before a specific event. So my attempts to just grab the latest save and try that was not working

The Stadia version is one of the best performing ports of the game in benchmarks, and far outperforms the PS4/xbone console version most will buy.

Stadia gives an experience similar to good PC, it’s the base console version where the vast majority will play where dynamic resolution scaling and inability to stream game assets in time destroy the game, not to mention the launch bug where save files corrupted if they went over 8mb...

It’s the only game ever Sony and Microsoft have had to remove from sale from digital store fronts due to quality issues, unheard of and shocking for a game with this budget etc. People will be dissecting what went wrong with this for years.

I played on a high end PC and still saw a lot of bugs, none game breaking thankfully though.

> And the result is the cohesive narrative vision in Half-Life.

Half Life has no cohesive narrative. It is just a bunch of interesting random scenes thrown together and people make up their own narrative about it. It works but it's not a "cohesive narrative"

I think the Cabal concept is especially interesting in the wider context of Valve's "self organising" culture. It doesn't seem that this structure was designed, but was emergent.

This structure is definitely not emergent, if left alone, human groups form little fiefdoms around local "lords", the hierarchy and bureaucracy of a feudal system emerges. To have working anarcho-syndicalism is a constant fight against this mechanism.

Who decides how much anyone gets paid, and how many virtual crystal gold smileys someone gets for doing what he currently does?

How many golden-smileys do you have to have on your shoulder to influence that decision?

I remember reading that Valve's internal structure nowadays is lords of fiefdoms even if they communicate externally that it's not. The only difference from other companies is that there's no org chart saying who the lords are, you have to discover that yourself.

“ Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time.”

This always sounds good in theory but ends up with unnecessary individuals falling asleep during meetings. I prefer either a staggered approach to meetings where the likely unnecessary people are only invited to the end of the meeting OR are simply “on-hand” for the meeting in case they need to be pulled in.

I don’t care how critical the input is, if you pull someone into a three hour meeting and they only contribute five sentences, they’re not going to be happy with you.

It depends on the program domain, but I think it must have been quite fun designing a game as opposed to the client still doesn’t know what it wants and this API should instead do this.

They where the ones that where going to be responsible for it so how can they be unnecessary? He even said they started to say no more and more as the deadline started to loom over them.

In most significant decisions in gamedev you want art, design and engineering (at least - QA, audio, animation and a number of others as well) to be involved. Some people from one discipline may be versed enough in another to cover the role, but the role must still be present, or there will be pain and work thrown away later on.

(incidentally, the ability to understand an issue from these multiple but interrelated angles is what makes experienced people so valuable in gamedev, and their constant loss to other less crazy industries so painful)

> If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

This! I remember being scared to move around when playing Half-Life the first time. Flickering lights still make an instant association with crowbars to me. Great to read a bit more in detail how they managed to make something so great!

The Cabal sounds great and I'm looking forward to try it.

I'll pick the projects carefully though, as it's impossible to ship more than two products with this methodology.

"The meetings were only six hours a day" ... ahhh ... (for five months straight)

Fascinating article.

One question remains unanswered though - how did Valve afford all of this? Given Half Life was their first game, where was the money coming from to not only produce an entire game, but to then scrap it and redesign/rewrite from scratch?

Valve was started by two Microsoft Millionaires. Money wasn't an issue.

Even still, the initial Cabal was three engineers, a writer, an animator and a designer, so you can assume that the broader team was at least that much again. That's 12 people full-time working for 2-3 years (and the actual credits go up to 30, so it's probably even more). At $75k per FTE (in 1996 salaries), that's at least $3 million, which is quite a lot, even for two people wealthy from MSFT stock options.

Gabe Newell was in a senior role at MS for 13 years before he left to start Valve. That’s a lot of money.

Half-Life was published by Sierra, presumably Valve received some money from them.

>"The first theory we came up with was the theory of "experiential density" — the amount of "things" that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control.

If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

The second theory we came up with is the theory of player acknowledgment.

This means that the game world must acknowledge players every time they perform an action.

For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound — there should be some visual evidence that they’ve just fired their gun. We would have liked to put a hole through the wall, but for technical and game flow reasons we really couldn’t do it. Instead we decided on "decals" — bullet nicks and explosion marks on all the surfaces, which serve as permanent records of the action. This also means that if the player pushes on something that should be pushable, the object shouldn’t ignore them, it should move. If they whack on something with their crowbar that looks like it should break, it had better break. If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name. Our basic theory was that if the world ignores the player, the player won’t care about the world.

A final theory was that the players should always blame themselves for failure.

If the game kills them off with no warning, then players blame the game and start to dislike it. But if the game hints that danger is imminent, show players a way out and they die anyway, then they’ll consider it a failure on their part; they’ve let the game down and they need to try a little harder. When they succeed, and the game rewards them with a little treat — scripted sequence, special effect, and so on — they’ll feel good about themselves and about the game."

On game scripts (literature, not programming), a lot of ideas were shaped before in text adventures/interactive fiction. ZMachine-Inform/Tads have several games based on sci-fi and weird tech environments, such as Babel, or Spider and Web. And the reverse happens, too. H.P. Lovecraft->Alone In the Dark->Anchorhead.

from the mod makers pov, circa after they launched in 1999:

https://medium.com/super-jump/building-a-popular-half-life-m...

Mod making was a digital cabal concept, with local leads forming fiefdoms. They were opinionated to a design/delivery. Sometimes straying to other mods, but mostly focusing on one concept at a time.

Valve also hired really heavily from the mod community. I spent a good portion of my youth in that scene and the people that they hired they really went far for(relocation, visas, etc).

I think most of the leads for the more popular mods(outside of CS obviously) ended up there in one form or another if they were interested in it.

Nice writeup. I was part of a mod team that got by Valve long time ago, and indeed it was a giddy fun time. We had no idea what we were doing, but we just created a game that we wanted to play - and it seemed to have worked.

TLDR: Small, cross-functional teams build better products.

> If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name.

If only Gordon returned this courtesy.

Silent protagonists are such an awful thing.

You are Gordon. Did you acknowledge the NPCs by looking at them?

I realize why they do it, but it can never work because the n.p.c.'s do not react to me in return. I can talk to them, say things to them, but they will never respond to anything I say.

Thus, the end result is that Gordon Freeman is a man whom many speak to, yet who never speaks back, and no one considers this to odd to say the least. — the conversations thus appear ridiculous.

It worked better with Chell, because others do not that Chell does not speak back, and Chell actually canonically refuses to speak out of stubbornness, so it's amusing to see Wheatley being obviously uncomfortable from the fact that Chell does not speak back and is simply blabbering to fill the awkward silence.

NPCs in Half-Life 2 mentioned a number of times that Gordon doesn’t say much and is a “man of few words.” I’m sure this is a nod to his silence in the first game as much as it’s a storytelling device.

I’ve always liked that his character never said anything—feels like Gordon can be anyone. Same goes for the lack of cutscenes that take control of the player’s camera. You always feel like you’re looking from your own POV vs. being pulled out of the immersion.

> NPCs in Half-Life 2 mentioned a number of times that Gordon doesn’t say much and is a “man of few words.” I’m sure this is a nod to his silence in the first game as much as it’s a storytelling device.

That is an in-joke at best and does very little to rectify that n.p.c.'s have entire “conversations” with him and at no point ask as to why he's remaining quiet throughout it. — the conversations are simply completely implausible.

> I’ve always liked that his character never said anything—feels like Gordon can be anyone. Same goes for the lack of cutscenes that take control of the player’s camera. You always feel like you’re looking from your own POV vs. being pulled out of the immersion.

Perhaps if one go about his daily life talking to walls and being completely disinterested in what a man might have to reflect back.

Whether you reply back to them or not, it always leads to an unnatural conversation where one party is talking to a wall that doesn't respond.

I'd much rather the protagonist be silent in an FPS. It ruins the immersion for me, unless there are dialogue choices so I still have some agency. I quit playing Dishonored 2 after a couple of hours because the protagonist keeps talking as a way to narrate things for the player, but it's just silly being a stealth assassin constantly talking to yourself.

Obviously in a stealth game it makes no sense for the protagonist to talk.

But it does not make sense either that a protagonist not answer when he be spoken to.

It was quite ridiculous in StarCraft where there was a player character who had a rank and was an actual character, his allies discuss strategic plans with him and talk to him, but he never speaks back, and is only addressed by title, for he lacks a name.

In StarCraft II, the game withdrew from the notion of a “player character” and the player simply took control of various different actual characters with dialog and a face.

I think silent protagonists are excellent, and when done well make me feel more immersed in a game.

Three excellent games with them, off the top of my head: Metal Gear Solid 5, Half-Life, and Far Cry 2.

I stopped playing Cyberpunk 2077 mainly because the protagonist’s dialogue and voices didn’t make me like the character.

> But it does not make sense either that a protagonist not answer when he be spoken to.

It may not make sense to you, but when I played through the half life games I found them more immersive than any games I had played.

I think games will have their protagonist be some cocktail of “this character is me” and “this character is not me but controlled by me”. I think a competent game will usually to try pick a mix that’s in best-service of the experience. Gordon Freeman, Mario, or Cloud Strife all do this in different amounts.

I beg to differ, and in any case HL was explicitly designed this way.

It can be really discordant when the protagonists speaks for you but isn't really in-line with the character you're roleplaying. Making them silent is a neat way of not breaking that immersion

More discordant than the fact that he has completely implausible conversations with everyone but either everyone talks to him and he never talks back or provides input or as much as acknowledgement that he hears them, or conversely, if the player simply talk back to them in his head, the fact that no one says anything back to what he is saying?

Role playing a video game character does not work until artificial intelligence matures to the point that a computer might have a meaningful conversation with a man.

The idea is that the player fills in their response in their imagination. Though, I think it's a little fourth-wall-breaking when NPCs comment on the player's silence. No future-AI needed.

I know, but as I said, the n.p.c.s don't respond to the player's imagined responses so it doesn't solve the problem that he conversations are implausible and silly.

Either the player doesn't imagine a response, and the n.p.c.s are talking to a wall and act as if that be normal. Or the player does formulate a response, and Gordon Freeman is talking to walls, and acts as if that be normal.

Interesting it's canon that Freeman is not simply mute, although I wish they hadn't closed the door on that interpretation.

https://half-life.fandom.com/wiki/Gordon_Freeman

Even if he be, most other characters do not treat him as such, and do not remark upon the fact even after having just met him and have no way of knowing, that he never speaks back. It provides for a very surreal experience.

(1999)

(if the title gets edited, please delete my comment for me)

(1999)

In the context of Cabal and video games, I was expecting something about Destiny 1/2

Reply on news.ycombinator.com