Hacker News Reader

Comment by ArtWomb | Hacker News Reader

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...

View on HN

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.)

>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.

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.

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"

> 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.

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

Reply on news.ycombinator.com