[LarsDu88]

Now having read most of the article, and having done quite a bit of game development myself... it sounds like a large amount of the problems with Rome II and the engine they were building was the navmesh.

The navmesh is a sort of 3d mesh where the center of every triangle defines a node on a graph which can be used for pathfinding using algorithms like Astar.

It sounds like they needed people to manually create and optimize these for various maps rather than using an algorithm to generate it automatically.

Additionally there's this big issue with sea battles where each little boat has a little moving navmesh which little soldiers can move around on, including when the ships actually land and have to make the boat navmesh connect with the land navmesh at runtime.

Altering navmeshes at runtime (which are generally static stack allocated) is sure to lead to a bunch of stale references if the code wasn't architected to be flexible to begin with

This sort of detail is probably lost on non-technical folks and needs to be clearly communicated early on.

At the end of the day, I have much fonder memories of capturing the Black Ship in Shogun 2 (which used the old two navmesh system separating boats and land), and virtually no memories of landing troops in sea land battles in Rome 2. The feature was not important to gameplay, but requires refactoring the whole damn navmesh system!

[chongli]

That may be the proximate cause of the issues but the ultimate cause was the development methodology. There was absolutely zero reason for the game to not be in a playable state throughout the development lifecycle given that they had Shogun 2 — an incredibly polished and well-built game — to work from. This was a management own-goal as far as I’m concerned.

Go back in time to the beginning of the Rome 2 lifecycle and simply proceed by iteration. Maintain playability throughout. This would’ve given them a much longer lead time on major issues with the gameplay.

It’s absolutely crazy to me that they would tear Shogun 2 down to its individual components and work on them all separately without maintaining a playable version of the game. A ton of it could be done with continuous integration, where they just have a couple of CI servers sitting in the office running the nightly build in an all-AI automated fashion. Heck you could even plug in a monitor to the server so that people can just walk over and watch the AI vs AI battles as a sanity check.

The other baffling part of the whole thing is how little communication was going on. I mean it’s baffling in terms of good design and development practices but it’s understandable from a dysfunctional management perspective.

[LarsDu88]

The other thing to keep in mind is that CA built their own game engine for this series of games.

Tearing up any part of the game engine (which dates to the late 90s) is sure to have big breaking consequences for other teams and any half decent project manager or mid level manager should be aware that this cannot be done in parallel with other activities without first really carefully communicating and engineering interfaces.

Any sort of navmesh rewrite or fix in the engine would ideally be done BEFORE non artistic assets are laid out. Ideally, they should have set out to automate the mesh generation and built artist tools for mesh editing as a major goal.

[LarsDu88]

Quite honestly, I could see why they would want to rework big chunks of Shogun 2.

Rome II with all its faults had working cities with plazas and walls. Shogun 2 had maybe 6-8 actually distinct fortresses, where folks just line up on some walls most the time and do tower defense. The AI was always jank.

The "tower defense" gameplay in Shogun 2 was way more enjoyable than in Rome 2 though. Having a small fortress you can tightly defend against overwhelming odds is more fun than having a sprawling city where you're running foot soldiers around plugging gaps along a 20 km long wall.

The other part is the crazy requirement that soldiers be able to fight each other on boats which are very often moving around. Quite honestly naval hand to hand combat is pretty boring, but tacking that requirement on by featuring it in a trailer is an insane decision. Sounds like the marketing team wanted to do Saving Private Ryan in 200 BC. The number of times I actually used this mechanic in a 30 hour campaign was like 3-4 times, and it sucked every time. Typically the soldiers would slowly disembark (quite often literally teleporting to land) and then immediately get run down by enemy cavalry since the AI would get stuck in the "disembark" state and soldiers would stand still barely defending themselves.

Shogun 2 had many of its core problems plastered over with solid game design.

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.

[chongli]

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

[fakedang]

So how did you capture the Black Ship? I would basically use a bunch of fire arrows from bow kobayas to set it on fire. Others would use a pair of Nanban trade ships on either side to do a double barrage at the same time. And then others go ham with a heavy bune fleet.

Which route did you go for?

[LarsDu88]

Just spam my entire fleet at the damn thing and save scum if I accidentally sink the damn thing. Lol.

Endgame campaign.

Really shows that in gamedev, game design trumps everything.

Shogun 2 under the hood was janky as fuck, but boy did they plaster over that shit with some solid game design and playtesting.

[novaleaf]

any navmesh alternatives for dynamic worlds? I am toying with gamedev and this one still has me stumped.

[LarsDu88]

Well if you use the Unity game engine, you can always script a setup that does a runtime bake on level load. Not really sure about navmeshes that actively change at runtime though...

[novaleaf]

yeah I don't think dynamic navmeshes at runtime would work well.I'm using Godot, I'll have to keep looking