Also CI in gamedev is not nearly as common as in webdev, mainly because the state space for a videogame is far larger than for a web app. These issues are caught at playtesting and QA time, and every stakeholder involved in that process should be well aware that they are shipping a broken game

Yes, I’m aware of that, but it’s not an excuse. Poor development methodology is rife in the game industry, leading to missed deadlines, crunch time, and shipping broken games. For some reason game development managers are absolutely allergic to good housekeeping practices.

I think the state space issue is valid if you’re developing one-off games mostly from scratch. That is not the case at Creative Assembly. They have been working on a single game series since 2000 when Shogun: Total War shipped. Fans of the series have been complaining about major issues with the AI and gameplay for literal decades. There is absolutely no technical reason they couldn’t have kept the game in a CI-driven nightly build, mostly or completely playable state for that entire time.

The reasons are entirely cultural. Compare with an open source game like Dungeon Crawl: Stone Soup [1]. This game has been hosted on GitHub [2] for years with continuous integration and nightly builds automatically published to test servers to play on. The game is always in a playable state and the community is constantly providing feedback to the developers as features are added, tested, tweaked, tested again, and finalized. Many of the systems in the game are tested automatically by scripts and battle simulation arenas. The developers are able to see almost instantly, for example, how a small tweak to a weapon’s stats will affect the overall balance of the game. This level of tight iteration has led to a much-beloved, highly polished game experience.

Sure, not all of this can apply to a commercial closed-source game studio but a heck of a lot of it can. For a series as long-running as Total War, there’s no reason they couldn’t have gradually built and maintained suites of automated tests for battles between AI opponents on different maps and with different unit compositions. All of this could allow the testing of different AI strategies, different unit statistics for balance purposes, and different map layouts for pathing tests and tactical situations.

The problem, I believe, is that the management at the studio views all of this polish and software quality as unnecessary and wasteful. Any development time spent on any tool or feature used only internally would’ve been viewed as a waste. They’d much rather proceed in a toxic and short-sighted fashion, looking forward only to the next game release for an influx of cash. On some level the game studio is really operating like a drug addict. It’s totally dysfunctional. It’s also not how every commercial game developer has behaved.

Blizzard in the past (1990s through 2010 or so) was very committed to software polish and high quality development tools. We know their map creation and scripting tools were polished because they decided to release them to the community for modding purposes!

[1] https://crawl.develz.org/

[2] https://github.com/crawl/crawl