HACKER Q&A
📣 tjchear

As the tech lead, how do you ensure success in Cyberpunk 2077?


While still retaining the ambitious scope, and with the same capital backing and time frame (8 years), sans the crunch time? What processes can be deployed to massively reduce chances of glitches and bugs?

Is this feasible given their scope and time constraint?


  👤 hkarthik Accepted Answer ✓
The best thing the Cyberpunk team could have done to ensure success where they could avoid a myriad of technical issues is to have limited how many platforms they supported when they launched the game. Trying to simultaneously support high end PCs, and lower end last-gen consoles (PS4 and Xbox One) with a 2020 release was just foolish.

I think it would have been a fantastic game if it was a console exclusive, or a launch title for PS5 and Xbox One along with PC (since many CDPR fans are PC players). Yes this would have limited how many copies sold, but it would have set them up for building a long term franchise too.

Half measures to support their last gen console support was ultimately what killed their PR for the game.


👤 Aeronwen
License someone else's game engine and spend the next 8 years refining AI/UI/basic gameplay.

👤 wildermuthn
What a great question. Part of the answer comes from the question itself, which defines the problem as a well-funded long-term project with almost no hard specifications beyond “open-world sci-if that will be hailed as one of the greatest games ever made.”

So on one hand, you have enough time and resources to hang yourself in a thousand different ways. And on the other hand, you have a genie-wish specification that thinks money and time can solve any problem.

Already, we can see that we have two problems - software engineering and product management - and among these two, product management is the hardest due to the formulation of the problem itself.

The first thing that should have been done is reduce the budget, timeline, and scope — focusing on innovative gameplay rather than innovative technology. The most obvious first result of this smaller scope is not making your own game engine. That should have been the first huge red-flag for the project. If you give talented engineers unlimited time and resources, and tell them to build any sort of “best ever” product, they will happily go down premature-generalization rabbit holes and never come out, creating spectacular architectures that shine in technical art museums (if such things existed) but fail in production. Premature generalization kills projects more often than premature optimization, as it is the leakiest of all abstractions due to solving problems that only exist in our imagination of the future.

So the answer is 1) reduced budget, scope, and technical innovation, and 2) gameplay innovation of existing open-world RPG technology set in a new genre (sci-if).

The hard part here is that gameplay innovation may require technological innovation: so the most important software choice is finding an existing open-world technology that is 1) available for license/purchase at a decent cost, and 2) is extensible and performant enough to handle gameplay innovation.

The problem as I see it isn’t that these technical considerations of buy vs. make weren’t asked. It is that they were asked in the context of having seemingly unlimited time, budget, and ambition.

Reduce your timeline. Focus your ambition. Choose proven technology. At least then you’ve got a shot at making what people want!


👤 alexaholic
The Cyberpunk 2077 FUBAR is not a tech problem as much as it’s a management problem. Tech can only compensate a bad employer this much.

👤 agilob
Well, the first one is to treat software as a process not a product, so don't overpromise, don't built hype and do not lie to your customers. It's fine if you release software that's not feature complete and keep adding modules to expand it.

👤 fulafel
It would be interesting to now how e2e testing and CI is done in these kinds of games.

👤 boogies
> massively reduce chances of glitches and bugs

Write it in Rust. (/s? idk.)