This statement is written for players of the Total War games but it might also be of interest to a wider gaming or games industry audience.
Ten years ago I was allowed to become a hate figure in the community following the disastrous launch of Total War: ROME II, at great personal cost. I was widely blamed for the problems with the game and was assumed by many to have been fired for incompetence. The truth is that I led the effort to fix the game and fought behind the scenes for changes to production and design so that it would never happen again — and quit the company when it became clear that leadership was going to keep repeating the same mistakes.
More recent events involving Creative Assembly have shown that my experiences are still relevant years later. I’ve stayed quiet until now, but the time has come to set the record straight.
This statement is not endorsed or authorized by Creative Assembly or Sega. This is my testimony, and consists of my own views.
Background
I’ve been a software and game developer for over 20 years, and I’ve worked on 16 games in my career including smaller independent games and larger “AAA” games. Between 2009 and 2014 I worked as a programmer on the Total War series at Creative Assembly, starting with Napoleon: Total War and then working on Shogun 2, Fall of the Samurai, Rome II, and Attila before departing from the company. In October this year it’ll be a decade since I left, and for most of that time I haven’t paid very close attention to Total War, but over the last year I’ve been troubled by events involving the company. I won’t go through all of it here, and you can easily find a summary elsewhere, but there’s been mistakes involving Total War products and treatment of the community which have resulted in intense criticism from players and commentators.
We also learned that Sega, Creative Assembly’s parent company, cancelled Hyenas — a major first-person shooter project in development at the studio for a number of years — shortly before it was due to launch. This has been followed by multiple rounds of layoffs in which an apparently substantial number of developers, including former colleagues of mine, have lost their jobs.
Long time Total War players may recognize my name, because I became publicly associated with the launch of Total War: ROME II, a game we shipped in September of 2013 in a largely unplayable state resulting in a major player backlash. I had appeared a couple of months earlier in an episode of their Rally Point web series to discuss the work we were doing with the AI for the battle side of the game, and that exposed me to a lot of criticism over the state of the AI and the game in general.
Yes, I’m that guy.
Due to the way the state of the game contrasted with the tone of my interview it looked as though I had deliberately misrepresented the game and the work I’d done; and while the Rally Point video itself had a relatively small viewership of 100,000 or so, some reviewers and commentators used clips from it to ridicule me to an audience of millions. All of this led to quite a vicious backlash against me personally, with countless angry comments about and directed at me across YouTube and social media, which included many death threats and threats of violence (although I should be clear that while these threats were numerous and graphic, I doubt any of them were “credible” from a law enforcement standpoint, i. e. I did not have actual reason to fear for my safety). Some of it was extreme — one viral video contained long sequences of my face being stabbed and set on fire while the words “BURN, IMMORAL AI GENIUS!” flashed onscreen.
Criticism and discussion of my involvement persisted online long after I’d left the company. Recently, while catching up on Creative Assembly’s latest controversies, I discovered that an online review of one of their most recent games repeated footage ridiculing me over Rome II, and this video also has a large number of views. So this situation isn’t even in the past, it’s still an ongoing problem for me many years later.
I was by no means the only employee to be targeted after Rome II launched, but I became a focus for a lot of the anger being expressed towards the company. There was even a narrative that emerged that Creative Assembly itself shouldn’t be blamed for Rome II; that it was all because of me, a single rogue developer who had been fired and the game would improve now that I was gone. I think this narrative was actually quite convenient for Creative Assembly, and I don’t think it’s an exaggeration to say that I became a scapegoat for the project’s failures. I’m not necessarily alleging that a conversation took place where management conspired to throw me under the bus — it may have just been that they didn’t have any incentive to intervene and do the right thing by me, so they just let the situation play out the way it did.
Either way it wouldn’t have been entirely without precedent, because after Empire: Total War released in 2009, also in a very bad state, a central leadership figure posted a statement on the forums citing the departure of the battle AI programmer as one of the main reasons for the project’s woes. This was shortly before I joined the company, so I can’t tell you exactly what happened there, but I know enough to know that it was unfair, and I can attest that I am not the only battle AI programmer to have experienced significant difficulties in the role. While it’s not my place to speak for other developers, I will say that at least some of them left for similar reasons to me, reasons that I’ll discuss at length in this statement.
Some disclaimers
The decision to speak out has been given careful consideration even though I have a very clear justification to do so. Under normal circumstances I wouldn’t want to create trouble for a former employer, but this situation was and is quite extreme. I’m taking this action because of the severity of the problems I experienced at Creative Assembly, the way that the company handled my situation, and the resulting damage to my reputation. I also hope that by speaking out about these issues I will shed light on chronic management problems at the studio, and I believe doing so is clearly in the public interest.
I’ll extend as much courtesy to my former employer as I can under the circumstances, meaning that I’ll limit my statement to topics I need to discuss in order to set the record straight. I won’t name names and I’ll be vague about job titles, and I’ll stay away from anything like unannounced projects or trade secrets. I’ll refer to groups like “leadership” and “management”, without specifying the exact individuals involved. Leadership and management staff change over time, and there are no doubt leadership figures at the company now who weren’t there during my time and had nothing to do with the problems discussed in this statement.
I also want to say that I think Creative Assembly employs many talented people who are among the best in their fields anywhere in the world. I don’t intend for the problems highlighted by this statement to detract from that in any way, as I consider them to be entirely the responsibility of management and not of the wider development team. I also have friends who still work at Creative Assembly and don’t wish to cause them any headaches, although I believe they will understand my motivations.
AI is discussed extensively in this statement, and there’s been a lot of discussion in recent years about “AI” meaning generative AI systems like ChatGPT. They’re a different subject. When I say “AI” here I mean it in a conventional game development sense, the game code that controls non-player characters and factions.
Finally, while I’m going to say a lot about Rome II and problems with the game and how it didn’t turn out as well as it should have, I don’t want to alienate players. If you like Rome II, if you still play it, that’s fine by me — I’m not here to tell you you’re wrong. But judged on its own objectives it failed in a lot of ways, and unquestionably had a terrible launch, and that’s mainly what I’m going to discuss here.
Rally Point Episode 14
Let’s talk about the Rally Point interview. I think the way that most people looked at it was, here’s a developer who’s working on the game and therefore has all of the inside information, so then when it comes out and it’s completely broken, he must have known that everything he was saying wasn’t true. I suppose that’s how the situation looked from the outside, but the truth is that at the point I gave the interview, I didn’t know what we were going to ship. I think people who don’t work in games will be really surprised to learn that it’s quite possible to work on a project like this and even a couple of months from launch not really have a clear idea at all of what the final game is going to look like.
When I worked at the company, Total War games usually only came together in the final weeks and months prior to launch. They were usually unplayable for most of their development time, and Rome II was unplayable for almost all of it. At the time I gave my interview, the pieces were all still coming together. I was mostly testing the battle AI in specific test maps rather than organically in the game itself, and was starting to see good results at that point which gave me the confidence to speak publicly about those improvements. At that stage I simply did not understand how far behind schedule the project was, or what new problems would arise while the team was trying to get it finished. I had previously worked on Napoleon, Shogun 2, and Fall of the Samurai, all of which had turned out reasonably well. Rome II had some obvious production and design issues, and we had a lot of bugs to fix, but those previous projects I’d worked on had their own issues and also took a lot of work to get to the finish line.
What happened is that the community team were getting a lot of questions about AI and asked if I wanted to help give some answers. I agreed. I’ve seen people speculate that I was forced or coerced into giving the interview and I want to be clear that that wasn’t the case at all. I was asked to, but I could have said no. I went ahead with the interview because based on my awareness, and the internal communication on the progress of the project, I believed we were going to ship another game like Shogun 2.
I also think my appearance on Rally Point and my involvement with an important area of development seems to have given the impression that I had some seniority within the team, but this was not the case at all. I was one of many programmers on the team and was not part of Total War’s leadership in any capacity (my one and only minor leadership appointment came after Rome II’s launch). I was rarely included in high-level decision making and was typically not even invited to meetings where important production or creative decisions were made. Many of the management decisions that impacted the project were well outside of my remit, and I relied heavily on communication from leadership to understand the state and direction of the project.
Poor communication was later identified as a major source of production issues, and it also allowed me to be largely in the dark on the state of the project during development. By my reckoning there were two main ways that information about progress flowed from the top down to developers in the trenches like me. The first was production milestones, which as far as I can remember were all reported as having been hit on time, and I later learned that these had not been signed off on by the QA department — that’s Quality Assurance, responsible for game testing — who did not agree that the state of the game reflected those milestones. In other words, it seems that production leads were failing to report on those milestones being missed, despite QA reports that made it clear.
The second main way information was disseminated was marketing updates, where brand and marketing leads delivered polished presentations on game vision, trailers, positive reception at events, and so on. So the same apparatus of the company that communicated the state and progress of the game to the outside world also directed that energy inwards at developers like me. These updates were always optimistic in tone and added to a false impression that the project was on track.
I think that production, marketing and leadership in general failed consistently to understand and communicate the extent to which the project was behind schedule. Believe me that if I had known we were going to ship a totally broken game I would never have done the interview. I saw debates online about what my motivations were for doing so, and there were jokes about me driving off in a Ferrari and things like that. I promise you, that is very far from the truth. I made a modest salary working at Creative Assembly, a fairly average salary for a software developer in the UK at the time.
All that being said, in doing the interview I chose to put my trust in leadership and made assumptions that I shouldn’t have made. While I never meant to mislead anyone, that’s clearly what I did — the decision to speak for Rome II is on me, and I can only apologize for it. If you were disappointed by the game and felt that I misled you,
I really am sorry. I got it wrong, and I paid a heavy price, and learned some hard lessons as a result. I hope this statement can go some way towards making it right.
What Really Happened?
Rome II was grossly mismanaged. The truth is that the Total War team was dysfunctional even at the best of times, and when I sat down to give my Rally Point interview, I knew there were serious problems with the way the team operated, and that it would take a lot of hard work — and a lot of overtime — to get the game done. What I didn’t yet understand was that this project also suffered from a number of unique production and design problems which had introduced a lot of additional risk and would make finishing the game in the remaining time extremely difficult. Having later developed a fuller understanding of these problems, I think it’s possible that the game — or at least the launch — was doomed from the early planning stages, but it’s also possible that with good leadership we might have salvaged the project at the 11th hour. Instead, serious mistakes were made in these late stages in response to emerging problems that made the situation worse and put us on a crash course.
Note: It’s quite possible that the problems I describe as “unique” to Rome II had reared their heads on previous projects like Empire, or continued to do so after I left, but I can only speak to my own direct experiences.
I’ve described how, at the point when I gave the interview, the pieces of the game were still coming together and it was still largely unplayable. This is an important piece of the puzzle because it’s this production approach that allowed many of the problems and their consequences to remain invisible for a long time only to emerge together in the crucial final months. Total War games were usually developed this way but the point at which Rome II started to become playable was substantially later than other games which meant we had less time than usual in the final stages. This on its own should have warranted delaying the game, but Creative Assembly’s management made the choice to stick to the planned launch date knowing full well that the game would have a rough launch.
This is an approach that is sometimes taken when planning game projects, that you design your production plan so that as many parts of the game as possible are made in parallel, and then it all gets put together near the end of the development timeline, hopefully with enough time to fix bugs, balance gameplay, and add polish. Because the launch date is difficult to move, I’ve heard this described as like “jumping out of an aeroplane and having to assemble your parachute on the way down”. In theory this approach is more efficient, but I think in reality it’s risky and error prone, as mistakes made during development may not become apparent until late in the day, when there isn’t sufficient time left to properly deal with them. Most developers don’t work like this anymore in my experience, but it’s definitely still done and I think it’s one of the main reasons that many games come out in a clearly broken and unfinished state.
The alternative is to make sure the game is playable early on and then iterate regularly by adding features and making changes over the course of development. This allows the entire development team to maintain visibility on the state of the game and test features and give valuable feedback while they’re being developed. The best projects I’ve worked on have been like this, where frequent iteration has been championed by design and production, but it’s not what happened at Creative Assembly. Iteration was even viewed by some in leadership as wasteful and undesirable; instead, the goal was to “get it right the first time” and production planning tended to allow little room to correct for mistakes that were inevitably and predictably made — so they were usually dealt with in patches after the game had launched instead, if at all.
Total War’s leadership assumed they would get Rome II right the first time, but they got many things badly wrong. The project had more time and resources than previous games and we were starting from the solid foundation of Shogun 2, meaning that we had a real opportunity to produce a polished game worthy of succeeding the beloved Rome: Total War. Instead, these resources were spent on a long list of dubious new features and changes to the formula that I believe made the game worse, complicated its development, and forced us to throw away hard-won progress from previous titles. Worse still, management gave priority to marketing efforts during development that diverted resources towards producing trailers that should have been focused on the development of the game itself. These problems could have been easily avoided had leadership heeded warnings and advice from the wider development team, but instead it made crucial decisions in a vacuum and also later failed to take accountability for them.
I’ll share details of the most significant of these problems, including those common to Total War projects as well as those that were unique to Rome II. I’ll then share my experiences in the aftermath and how these failures were addressed by management. Finally, I’ll give an account of my experiences during the development of Total War: Attila, which led me to quit the studio.
Expanding Cities
A good place to start is one of the worst production mistakes made late in the project, because it had a significant impact on the AI in siege and unwalled settlement battles, and also demonstrates how production, design, and communication issues had major effects that were beyond my control. Rome II had much more complex siege and settlement battle environments than we’d had in previous games, where we’d required a lot of large open space for the gameplay and the AI to work correctly. There generally weren’t a lot of complicated pathfinding routes and choke points in Shogun 2 and previous games. More complex environments meant it would be harder for the AI to reason about how to move and position its troops, and would need more computation time to do so.
In order to make it viable, we agreed on a set of strict level design requirements for the authoring of AI metadata that would be baked into maps and used to generate an AI navigation graph that would help the AI understand these environments, as well as help us shape and control the way it engaged with them. This was essentially invisible geometry that was created for each map for use by the AI, and I should say that this kind of thing is very standard in game AI development. It’s not cheating — it’s the only way realistically we could have delivered the complex Rome II maps under the time and performance constraints that we had.
The AI Navigation Graph can clearly be seen in several of the B-roll shots in my interview.
A decision had been made at some point early in the project that there was only going to be one battle map per campaign city, whereas in Shogun 2 there had been several size variants for each city. That was a cool feature because as you upgraded your city on the campaign map, it would increase in size on the battlefield and become easier to defend with higher walls and more places to put archers and so on. For most of the development of Rome II there was just going to be one map, so regardless of any campaign-side upgrades you’d see the same map every time you fought at that city. I don’t know what the reason was for that decision, my guess is that it was decided that it would be better to have fewer maps but spend more time on them rather than having to create a larger number with less detail.
Meanwhile, one of the main new features being added to the campaign map was city expansion. In previous games cities could be upgraded in the campaign map, but they always took up a single tile. Now in the Rome II campaign, the city would grow as it was upgraded and its population increased, taking up more and more tiles so you’d feel like your city was growing on the campaign map and not just on the battle map. Unfortunately, it seems like the battle and campaign design teams weren’t communicating these changes to each other, and neither was aware of what the other team was doing. It seemingly wasn’t discovered until a conversation I had with a lead campaign artist within the last couple of months of the project. He immediately brought it to the attention of leadership, and I think there was a bit of a panic.
We were now facing an embarrassing situation where expanding cities would be marketed as a major new campaign feature, and players would discover that the feature wasn’t reflected in battles, even though that was the only way it’d worked in past games. In order to extend it to battles, they would need to make three new maps for each of the existing ones, allowing for Small, Medium, Large, and Extra Large battle map options. I think they had a few sensible options, assuming they weren’t going to scrap the feature from the campaign side. They could ship the game as is and accept criticism over the missing battle maps, then add them in a free update once they were made, or they could remove the feature from campaign for launch and restore it in an update along with the maps once they were ready. If neither of those options were acceptable, they could delay the launch of the game. What they chose instead was to instruct the level designer to rush the creation of the missing maps and get them ready for the launch date as planned.
Replacing one variant with four meant effectively quadrupling the level design workload, and this was happening in the final stages of the project while we were already working overtime to fix bugs and get the game finished. I should point out that while writing this statement, I checked the current state of Rome II and found that the Large and Extra Large battle maps were identical in the cases that I looked at, so I’m not sure whether the fourth variants were ever made, it’s possible that the Extra Large maps are just a duplicate of Large. In any case the level designer worked really hard and actually managed to complete all of the maps that were included at launch, but because they had been rushed they contained many issues with pathfinding and more importantly, they were riddled with bugs in the AI metadata that was so crucial to the AI’s performance. These maps came online so late in the day that they received little test coverage and we had no chance of finding even a fraction of the AI bugs they caused by the time the game launched. The unfortunate result was that in many cases, players could interact with the maps mostly fine, but the AI was unable to do basic operations like pathfinding and couldn’t issue move orders even when its higher-level logic correctly identified what it needed to do.
Consequently AI in settlement and siege battles often sat in one place and did nothing, barely responding to the player’s actions. I’m not saying this was the only cause of inactive AI — there was still work to be done on the AI and many bugs to be fixed — but if you played Rome II close to launch and experienced inactive AI, there’s a good chance this was the reason why. These bugs were extremely common because the new map variants were the smaller variants, usually encountered early on in a campaign. Settlement and siege battles were also one of the most common battle types, meaning it was likely that inactive AI would be a player’s very first battle experience in Rome II. It took us months to find and fix all of these bugs, more time than was spent rushing the maps themselves. Following the Rally Point interview, this situation appeared to reflect very poorly on me, but the truth is that it was the result of a major late design change requiring lots of new content close to the launch date when 100% of our effort should have been concentrated on fixing bugs.
Curse of the Battle AI Programmer
The decision to greatly increase the level design workload during the project’s final months was an especially bad example of a late design change, but late design changes were common on Total War projects and created a lot of problems and extra work in the lead up to launch. As the pieces came together and the game slowly became playable, design leads would often react to feedback and surprises by making significant changes to a game’s design, which would invalidate work and require further changes to AI code in order to satisfy the new requirements. This process in and of itself isn’t a problem, it’s essentially iteration — the problem is that it happened far too late in the project with major changes to design sometimes continuing all the way up to and even after launch, continuing in patches and updates.
Late design changes created a lot of new problems at a time when we should have been concentrating on fixing bugs and polishing the game. It affected people across the team, but its impact was felt especially by AI developers, because significant changes to gameplay typically needed to be directly supported in AI code. This is not surprising when you consider that the AI is playing the game, so if the game changes, the AI usually needs to change as a consequence. We did try to design systems to be flexible and work with a range of possibilities where it was practical to do so, something which I spoke about in my Rally Point interview, and that did allow for changes to maps, unit data and balancing, for example, to be done without extra AI programming work.
Yet, there was only so far that AI systems could be stretched before they would need to be changed in order to properly support changes in the design. Any kind of fundamental change to the logic of the game, or changes to parameters that were substantial enough that they invalidated design assumptions, would almost always need code support. Unfortunately, there was a persistent misunderstanding among some in leadership that the AI was (or should be) able to figure out on its own how to respond to design changes and this was often used to dismiss concerns about how gameplay changes would impact the AI. In reality, AI code is no different to other game code, in that it supports features known about at the time of its implementation and any flexibility beyond that requires further development and investment. AI programmers having to react to frequent changes in gameplay and other knock-on effects usually meant that we had no time available to develop the kind of AI technology that might have been able to robustly handle significant changes to gameplay rules or balancing, if such a thing would even have been possible.
Late design changes also meant that Total War games often launched with rough AI that improved later in patches. It improved after launch mainly because the rest of the team would be moved on to new projects and the design would stabilize, allowing us to stop doing reactive work and actually focus on improving the AI. It wasn’t because AI developers were fired and replaced with better people, we were just able to do our jobs properly from that point onwards. This affected every Total War game that I worked on, but the problem was greatly exacerbated when a project was behind schedule, as the more unfinished the game was closer to launch, the larger and more frequent the design changes would be, whereas projects that went more smoothly would stabilize earlier and give us a bit more of a chance of having a decent launch.
Developing competent AI for a complex strategy game like Total War would be challenging enough under optimal conditions, but the way Total War games were developed was often incompatible with delivering a good result when it came to AI, especially at launch. I mentioned earlier that other battle AI programmers also had difficulties. By the time I moved into the role, developers on the team already talked about a pattern in which programmers in the role had quit the company after only one or two titles. It was called the “curse of the battle AI programmer”. The curse was really just a repeating pattern of bad management and dysfunctional team dynamics that resulted in conflict and burnout — and my experience was certainly no exception. Late design changes was one of the problems, but there were others. We were typically not included in the decision making process and AI development challenges were generally not taken into account when designing the game. To make matters worse, important design and production decisions that impacted us frequently were not even communicated to us, meaning that we tended to find out about changes only after they had been implemented and started causing problems for us that we then had to react to.
Leadership treated AI as “someone else’s problem” and it was left to us to just do the best we could under difficult and sometimes impossible circumstances, with design and production decisions often undermining the AI development effort. These problems were reported and known about for years, but during the time I worked there leadership did not take responsibility for them, and in fact as I’ll explain in detail later, these problems only got worse during my time at the studio.
Leadership Culture
The Total War team was very hierarchical for its size, and key design and management decisions were made by a small handful of individuals at the top without any real oversight from the wider development team. Whereas the best teams I’ve worked with had leaders who went out of their way to communicate important decisions team-wide and opened themselves up to scrutiny, Total War’s leaders seemed to resent critical feedback and treated it as unwelcome. It was common for important decisions to be already treated as final by the time they were communicated to those of us in the trenches, if they were communicated to us at all. As there was no formal process for sharing feedback on creative or management decisions during development, most staff simply relayed their concerns to their peers and maybe their line managers, rather than risk confrontation with those in charge. This culture of design by authority rather than collaboration allowed the team to make serious mistakes that could have easily been caught early if the wider team had been able to express themselves.
Although I intend to protect the specific identities of the responsible leadership figures, I feel that I need to share information about the power dynamics that existed between development disciplines on the team. Many of the problems discussed in this statement were well understood by the programming team, for example, and I think the programming leads tended to promote caution and good engineering discipline, and tended to voice concerns about questionable design and management decisions. Programming leads would usually think carefully about whether or not a change warranted the risk of unintended consequences close to release. But they weren’t in charge of the wider team; it was designers who called the shots on Total War.
Designers are the developers who are responsible for making the decisions about how the game should play, what features it should have, and for things like the balancing, difficulty and the overall creative vision of the game. But the nature of the game design challenge is that it has to work within technical and production constraints, and so usually good management will empower both the design and engineering efforts along with other disciplines, so that they can complement each other and collaborate effectively. This is especially important on a technically ambitious game series like Total War, which involves a number of substantial engineering challenges, including AI development.
But it’s not what happened at Creative Assembly. Even though designers were not technically our bosses, programmers understood that they were in charge, and the programming team really had no power to overrule them even if we knew the changes we were implementing were going to cause problems. To make matters worse, designers often left a lot of the detail of the design work to programmers during implementation, so programmers often had the responsibility for a lot of the design details in practice, but weren’t really given the credit or autonomy that should have come with it. As a programmer, I’m obviously biased, but I think a lot of the most skilled and talented game developers on the Total War team were found in the programming department, and I think it’s unfortunate that those people didn’t have more influence, especially considering that the scale of the real-time battles — arguably Total War’s main unique selling point — is primarily to the credit of its programmers.
When I say that designers called the shots, I don’t just mean with respect to the programming team, because it seemed like production were also unable to hold them to account. The production team is responsible for the management of the project and keeping the team on track to meet milestones and deadlines. It absolutely should have been their responsibility to stop major design changes from happening late in the day, for example, but in my experience they always backed design in disputes with the programming team or others. The way it looked from my point of view was that production leadership let designers do whatever they wanted, and it’s one of the main reasons that Rome II went so badly wrong.
Game design is hard. I’ve never envied people whose job it is to make the high-level creative decisions as they’re critical to a project’s success and can easily make or break a game on their own. When criticizing people in that position I don’t want to give the impression that I think design is easy, because I know from experience that it’s not. The problem with Total War’s design leadership was that they didn’t seem to take the responsibility very seriously. Designers routinely made decisions on intuition instead of empirical observation, rarely opting to test or prototype ideas before pushing them into production. Decisions that should have been given careful thought sometimes appeared to be chosen spontaneously in mid-conversation, and when those of us on the wider team asked basic questions about the motivation or rationale behind a design choice, we rarely got convincing or reassuring answers, when we were given answers at all.
I should be clear that there were certainly good designers on the team who recognized and, at least privately, acknowledged these problems. I was in a somewhat fortunate position as a programmer in that I didn’t officially report to design leads, which limited their ability to censure feedback from me. But designers who were lower in the chain of command sometimes shared with me the treatment they received for raising concerns about their bosses’ decisions and that definitely helped me understand why criticism usually came from the programming and art departments rather than from the wider design team. This didn’t surprise me because I’d experienced some of that myself, with design leads sometimes losing their temper with me or others and raising their voices or speaking harshly. I think it’s fair to say that the behaviour of some in leadership could create a toxic work environment that caused valuable feedback from the team to be suppressed.
Let me give you a concrete example that demonstrates the relationship between the programmers and design leadership, and led to problems that contributed to the bad launch state of the game. One of the main new features included in Rome II was combined land and naval battles. Since Empire we’d had naval battles, but they were completely separate from land battles, and the codebase had been developed without any expectation that they might one day be unified. What that meant was that you had one part of the codebase that handled land units and land-based combat, and another part of the codebase that handled ships and naval combat, and neither half had been designed with the other in mind. The battle programming team was asked to deliver combined land and naval battles as a core feature in Rome II, and our lead warned that combining those parts of the codebase would require a lot of the code to be changed, and that it would create a lot of bugs that we would spend most of the project dealing with, and we couldn’t guarantee that it would be stable by the end of the project.
Leadership said to do it anyway. They then went ahead with the Carthage trailer which demonstrated an amphibious assault and locked us in to delivering the feature. When the game shipped, combined battles were riddled with bugs. We had ships pathfinding through the land, getting stuck or otherwise breaking gameplay; it was a mess and took us numerous patches to sort out. So a lot of people will look at that, see Roman triremes careening through the desert and think, well this is obviously just terrible programming. But in my view that was clearly on design leadership. We warned them it would be hard to deliver and would lead to bugs, and they made us do it anyway. We would have approached it with caution, maybe worked towards it over a couple of projects until it was stable and proven in terms of game design.
Design leadership’s control over most aspects of development created a lot of problems that went far beyond game design. One significant problem was that the programming team wasn’t in charge of its own priorities, meaning they weren’t able to prioritize improvements to the engine, or to tools and infrastructure, or to address growing technical debt. Programmers were very aware of long standing technical issues with engine, gameplay and AI, but the design department tended not to recognize these issues as important, and it was difficult to properly address them when design leads were reluctant to assign any time towards doing so on the schedule. Designers weren’t totally unaware of these issues and did sometimes complain about the engine and tools even though it was their department setting the team’s priorities, which could cause frustration among programmers. When programmers did do work to address technical debt it was often done off the schedule or snuck in as part of implementing designers’ features.
Too Many New Features
Creative leadership appeared to place a lot of importance on the number of new features added to Total War games, and the available time on each project tended to be filled up with new features and design changes, which almost always took priority over other work. This contributed a lot to the problems with programmer’s scheduling as there was rarely any time to work on maintaining and improving old code and features if they weren’t directly relevant to a new design change. This in turn meant that the series suffered from problems in gameplay and AI that never improved because they weren’t a priority to designers, and it increased the risk of buggy launches because more changes meant more unknowns and problems that could arise in the late stages of a project.
Even at the best of times, Total War projects were hectic and required us to deliver a lot of features on a tight schedule, but as far as Total War games went, the three previous projects had been relatively straightforward. Napoleon, Shogun 2 and Fall of the Samurai each had slightly less than a year of development, and in each case the goal was a focused experience where a new setting would be delivered without much in the way of a major overhaul to the fundamentals or the formula. These projects were still ambitious, especially given the tight deadlines, but for the most part the changes and new features were just those necessary in order to deliver the new setting in a compelling way. Shogun 2 was probably the most challenging of the three as it was our first foray into a feudal setting with the engine designed for the gunpowder weapons of Empire, but the design concentrated effort where it was needed. With plenty of hard work and a few patches, we had made a solid game.
Shogun 2 is one of the games I’m most proud to have worked on in my career. It wasn’t a perfect game, and suffered from some of the issues described in this statement, but I think it’s an interesting contrast with Rome II as many of the things that went right with Shogun’s sequel went wrong with Rome’s. We had a significant challenge just in moving from Napoleonic rifle tactics to feudal era combat, and all of the changes that that would entail in the new engine. We also had to overhaul sieges and naval battles for a feudal Japanese context, so there was already a lot of work just in moving to the new historical setting, and with only 11 months or so to get the game out the door, we had to focus on core functionality and minimize the level of risk we took on. I think also the studio was still recovering from the hit to its reputation caused by Empire, and so there wasn’t a lot of appetite for risk in general.
Rome II had substantially more time, with pre-production starting around two years prior to launch, with most of the team including myself moving over to Rome II after Fall of the Samurai launched in March 2012, giving us around 18 months of full development time. This was more time, but it was still a tight deadline for such an ambitious project. Even if we had taken the exact same approach as Shogun 2, just delivering the features needed for the Roman setting, it would have been a challenge in that timeframe. While Shogun 2’s Sengoku period allowed us to reuse content across the campaign map and give all factions mostly the same unit roster, Rome II would involve different cultures, asymmetric factions, and many hundreds of different unit types, all of which multiplied out the design and implementation challenge. But leadership clearly thought that because we had more time and resources, we had a lot of room to add new features, and that is what they did.
They pushed a lot of new features, many of which were challenging and risky and involved significant changes to the Total War formula. I already touched on combined land/naval battles, which was one major design change. Here are some others: capture points in land battles, true line of sight visibility system, ambush battles, encampment battles, deployable defenses, cinematic battle camera, total redesign of siege battles, new port siege battles, unwalled settlement battles, tactical view, facial animations on the battlefield, total redesign of battle combat rules; and of course all of the features needed to actually support the change in setting like siege towers, battering rams, triremes, slingers, testudo formation, and chariots, to name just a few. That’s just on the battle side, I’m not even talking about the campaign map. And it’s not even the full list of features that design started with, because a number of things were actually cut from the game during development.
Rome II did have more time and resources than previous games, that was no lie. But with so many new features squeezed into the schedule, the amount of time available to finish and polish each feature was so low that we likely could never have released a polished game even without all of the other problems described here. Despite the increased budget, the game looked and felt rushed because on a feature to feature basis, it was.
The long list of new features and changes to the fundamentals in the design of Rome II was, in my opinion, mostly unnecessary. Shogun 2 was a good game and while its core gameplay had room for improvement, my view was that most of its imperfections were down to a lack of detail and polish; there was no obvious need to reinvent its core design for the Roman setting, and doing so created much of the unnecessary risk and development complications that put us behind schedule and caused the problems at launch.
Flawed Design
Trying to change so many things at once was irresponsible and went against the advice of the wider team. This would have created many problems even if the changes had been worthwhile in theory, but in many cases they added little to the game and in some cases made the game worse and proved to be unpopular with players. There were many design decisions made during Rome II’s development that I disagreed with, more than I could possibly cover in this statement. I’ll focus on a handful of examples which illustrate the role that poor design direction played in the fate of the project.
Probably the most unpopular new feature was capture points in open land battles, which caused immediate controversy when they were first shown to the public at an event prior to launch. There were two kinds of capturable victory points found in battles in Rome II; there were victory points in siege battles and unwalled settlement battles, which had to be captured and held in order to win the battle, and this was the same as in previous games except that unwalled settlements were a new feature (they had previously only appeared in Shogun 2’s Rise of the Samurai DLC). Siege battles could now also have three victory points instead of just one. But in Rome II capture points were also added to normal land battles, which was a fundamental change to battle gameplay. These were called “baggage trains” and were intended to represent the defending army’s supplies — there was a plan for wagons and tent models to be placed nearby, but I don’t think this work ever got done.
After the strong negative feedback we received from a public demo, these were scaled back to just a subset of battles around launch; but for most of development the plan was for these to be in
all normal land battles. Now for the first time in Total War’s history, the objective of a battle would be to capture and hold the enemy’s supplies, rather than to engage and rout or destroy the army itself. This may seem hard to believe, but it’s the truth. My understanding of the motivation behind the change was that it would prevent the “corner camping” tactic, in which the player uses the corner of the map to protect their army from flanking manoeuvres when defending. I suppose it would have been nice to find a way to discourage that, but sticking a victory point in the middle of every map is a cure far worse than the disease. During development I made my feelings about this known, and everyone on the team I spoke to outside of leadership knew it was a terrible idea. When the backlash came, there was little surprise. Some leaders who had hyped the feature as having a “transformative effect” on battles, later pretended they had always been opposed to them.
Even at a high level the design direction failed to align the team on a clear creative vision. One of the main pillars of Rome II’s design established at the beginning of the project was called the “human face of Total War” and was the basis for a lot of the new features being added to the game. This was a nebulous concept intended to mean something like human drama, but the exact meaning in the context of designing a strategy game remained unclear for most of the project. Sometimes it meant literal human facial details, such as facial animation improvements in battles, and other times it meant bringing the camera down into the action to see and hear the behaviour of the soldiers — although that was a core feature of Total War games anyway.
Bizarrely, the same leadership team that was pushing for improvements around human drama also decided to remove existing features that already served that goal. Pre-battle speeches, where the general issues a stirring speech to the army at the start of a battle, were removed in Rome II after only being reintroduced in Shogun 2. They had been a popular feature in Rome: Total War, Rome II’s predecessor, but hadn’t been included in Empire and Napoleon. I was the developer who designed and implemented the pre-battle speeches in Shogun 2, working with writers and cinematics staff, and had ideas for developing the feature further in Rome II. The reason given to me for their removal was the cost of voice acting, which seemed really unfortunate given the budget and expected profitability of the game, especially considering that “human face” was now a central design pillar.
After two years of hearing about “human face” we shipped a game that couldn’t render human faces.
As far as I know, the only significant example of a “human face” gameplay feature that made it into battles was the cinematic mode that allowed players to control an individual unit from a close third person perspective. This was similar to the unit camera that existed in previous Total War games, but arguably worse because it forced the camera very close to the unit, reducing players’ tactical awareness. During testing it became clear that no-one was using this feature, and design leads were unhappy that a feature they had spent a lot of time on was being ignored by players. They then announced that a combat bonus would be given to units while in this camera mode in order to encourage its use, which prompted controversy with programmers arguing that the camera mode should not influence the outcome of the battle. Eventually design leadership settled on the following compromise: The user interface would
tell players that it gave a combat bonus, but the combat bonus wouldn’t
actually be applied. They wanted to explicitly lie to players in order to trick them into using an unpopular feature so that they could save face. I honestly don’t know whether a combat bonus was applied in the end, it’s possible that the button is still lying to this day.
AI Limited By Design
But there’s one aspect of the design direction that’s especially relevant to this discussion. I think the way most people look at the AI in Total War games is to say well, the AI has always had problems and it’s never really gotten much better, I guess Creative Assembly’s programmers just aren’t very good and don’t know how to do AI. I don’t think many people have considered that the AI is to some extent the way it is, on purpose. I can attest that at least some of the AI’s deficiencies at the time I worked there were by design, which is to say that designers instructed us not to improve it in certain ways, because they believed that players enjoyed being able to dominate the AI and that we shouldn’t deprive them of that.
There were also many cases where features were added to the game that would give players advantages over the AI, but we were instructed not to add AI awareness for them, or were told that there was enough time on the schedule for the feature itself but not for the AI work associated with it, meaning that these features just became more tools for the player to use to defeat the inadequate AI. My view is that Total War is an AI-driven single player strategy game, and any feature that a player can use against the AI that the AI can’t use in return or doesn’t even know how to evade or counter, is arguably not really a feature at all, in that it only defeats the core value proposition of a strategy game. Certainly if I’d been in charge of the design, no gameplay features would have been added without AI support.
Here’s an example from Rome II. They decided to add true line of sight visibility, meaning that you wouldn’t be able to see enemy units on the battlefield unless your own units had line of sight to them, regardless of where your camera was positioned. In theory this feature would allow for interesting gameplay where players could use the terrain to obscure their forces or their movements, but right from the design stage it was decided that no time would be allocated to AI development for the feature. This meant that the AI would not know how to use the feature to its advantage, but more importantly would not be able to reason about players’ units appearing and disappearing as they moved to and from cover, which likely meant a new category of AI bugs. This probably contributed to the poor state of the AI on launch and was entirely by design. We made our feelings about this clear but were told that “the players won’t be able to tell the difference”.
This certainly wasn’t the only case of that on Rome II. The baggage trains I mentioned earlier were also not to have any dedicated AI crafted for them. Unwalled settlements and siege battles were a special case and had dedicated AI that — at least when it worked — was designed to reason about the capture points in the settlement. But we were instructed not to develop AI for the capture points in field battles, because the AI already sort of handled it by accident and this was seen as good enough by design leadership. When I say by accident, what I mean is that AI units would go for capture points if they were nearby and didn’t have a higher priority target, but it wasn’t guaranteed and certainly there was no tactical-level awareness of the importance of these capture points, at least in field battles, which meant it wouldn’t have been hard for the player to pin the AI down and win the battle by capturing the baggage train.
If it hadn’t been for the negative reception of these capture points prior to launch we would have had an even worse time than we did. Total War is marketed as a strategy game and there have been statements and promises over the years about AI being a priority, but the reality when I worked there was that new features were always prioritized over AI improvements even if they directly made the AI worse.
Marketing Demos
Prior to Rome II, marketing had little presence at Creative Assembly. We had a small number of people working in PR and communications roles, and brand and marketing seemed to be mostly Sega’s purview. Starting with Rome II, we had an in-house brand department who were much more directly involved with the project, and seemed to have been given significant influence over its production and management. For the first time, the production schedule was organized around a series of marketing demos which would be released at certain times during the development of the game. By marketing demo, I mean a demonstration of gameplay shown publicly for marketing purposes either as a video trailer, or as a playable build offered to players at public events. The most prominent of these were the Siege of Carthage trailer, the Teutoburg Forest trailer, and the Hannibal campaign trailer. There was also an E3 demo in 2013 and a special review build made for members of the press to play when reviewing the game.
The dates of these demos became our production milestones, and the game’s schedule was organized so that the game’s features were developed in the order that they were needed for the demos. As far as I know the marketing demos were all delivered on time, and had exactly the desired effect of generating hype for the game, but I think they contributed a lot to the project’s production issues. To start to understand why, I need to explain that these demos were not remotely representative of the state of the actual game at the times they were released. When the Carthage trailer and the Teutoburg Forest trailers were released, there really wasn’t a game to play. The demos themselves were custom built in the engine, using a lot of scripting and purpose-built components. You could interact with them provided you understood how the scripting worked and followed the expected timing and sequence of events. While these did end up shipping as “historical battles” — semi-scripted battle scenarios as a separate feature to the main campaign mode — it was their importance as marketing assets that caused their development to be prioritized.
Each of these demos was really a “vertical slice”, so named because, if you imagine the whole game laid out from the start of the player experience to the end of it, with all of its components layered — user interface, AI, pathfinding, levels, animation etc. — a vertical slice is a small portion of the game that demonstrates all of those components. Essentially, it’s when you make five or ten minutes of your game without making the rest of the game, in order to demonstrate what the final game will look and play like. They’re almost always made early on in a project, usually to prove game concepts to the team, or to convince stakeholders to fund the rest of the game. And they’re a perfectly reasonable development tool when they’re used internally to help align the team on the vision, or secure funding. The problem is when the marketing department takes it and decides to show it to the public as though it was representative of the actual game at that point in development.
While it might sound straightforward to just build a few minutes worth of a game instead of the full game which might take tens or hundreds of hours to play, the reality is that games involve a lot of systems and components that don’t actually change much between the beginning and end of the game. A few minutes worth of polished gameplay might require most if not all of your game systems to have been completed. The pathfinding either works or it doesn’t work, it’s generally not much easier to make five minutes worth of pathfinding, especially if it has to perform to the same level of quality as it will in the final game. Components like story, cutscenes, level design, and environment art are the sorts of things that might change over time, whereas all of your game systems like your game mechanics, AI, user interface, all of your art that’s reused throughout the game, not to mention all of your technology like engine, rendering, tools, etc. all of that is generally “horizontal” in that it doesn’t change over the duration of the game.
So if you’re making a vertical slice early on in your project, how can you show five minutes of gameplay if you haven’t built your systems yet? The answer is you cut corners however you can, and fake things if you have to. You script behaviours, you use canned animations to represent events that should be happening organically, you write code that handles just the specific cases you need it to, and not the general problem you’re going to have in the actual game. Smoke and mirrors, basically. This is what happened during the development of Rome II. Despite the fact that the game at that point was still under heavy development and it was still many months before basic features would become playable, we were managing to produce something that looked like polished gameplay, something that could only be done by faking a lot of it. It shouldn’t have been shown to the public as though it was legitimate gameplay footage, and this unfortunately was the entire purpose of prioritizing these demos.
I need to try to be as clear as I can about what was fake about demos like the Siege of Carthage. We weren’t building a whole new game, and we had a lot of game systems brought over from Shogun 2. So we did have pathfinding, unit formations, artillery, etc. and certainly a lot of work was done while working towards the demo milestone that was included in the actually game. So I’m not saying it was
completely fake, much of it was real. But a lot of what made it impressive and differentiated it from Shogun 2 was fake. First of all, there was no AI, all of the enemy units were scripted. Lots of parts of the game were only partly working at that point, things like siege towers and disembarkation from ships were demonstrated as working but would still need a lot of work over the course of the project. A lot of the cool moments were scripted, artillery hitting and collapsing buildings, elephants charging through the dust clouds, things like that tended not to be real gameplay. Cool moments where the commander issues a speech to his men, or shouts commands to the troops before engaging the enemy, all scripted. Even if everything in that demo had been fully representative of the Carthage battle that we would end up shipping, it still was not representative of the state of Rome II at that time.
The idea in theory was that the Siege of Carthage was our target for the final game and that was what we would eventually make, but even that wasn’t true in practice, because there were features that went into the demo that weren’t even on the project plan. Sometimes I’d ask a question about something I saw in the demo and whether we were actually going to have that in the game, and you’d get an answer like “oh well we wanted it to look really epic and cinematic” and so on, but it was clear they hadn’t really considered whether that feature would be feasible in the game or if there was time for it on the schedule. In some cases we even had to go back and try to add features to the game simply because someone had put them in a trailer and now we were told we had to deliver them because they’d been shown to the public.
So how is all of this related to the production issues? Well, doing all of that scripting work, adding all of that polish to make the demos look as cool as possible, that all cost development time. These demos were important deadlines and in the lead up to them they would take priority over everything else, and staff would sometimes be working overtime to get their contributions done in time. So a lot of developers would end up spending a lot of time getting features half working or helping to add polish on what was ultimately a small facet of the overall project. Considering the number of these demos and how much work was involved in making them, it’s not an exaggeration to say that for a significant portion of the project’s development, the team was making marketing trailers when it should have been focused on making the actual game.
Marketing is a business reality and I suppose it’s fair that some effort be diverted to support it. I’d seen some of this on previous projects such as Shogun 2’s battle demonstration for E3 2010, which was also essentially a vertical slice and did take several weeks of the development team’s time. With Rome II though the time and priority given to these demos was far greater, and totally disproportionate even taking into account the need for marketing. I can attest that in addition to putting the whole project behind schedule, these marketing demos also directly impacted AI development. In one case, one of the battle AI programmers was diverted for several weeks to help develop the AI for a playable E3 demo which was made a high priority, and that time would clearly have been better spent fixing AI bugs, especially as it was only a few months from launch. In theory that work might have counted towards development except the process for that demo was very experimental and the developer spent most of the time reacting to the ever changing design, and none of that work ended up being very useful from the perspective of getting the actual game done.
Even when we were done with marketing trailers and were trying to finish the game, there was a review build we had to focus on for a press event about a month prior to launch. This event was held in Rome itself on the set of HBO’s Rome TV series and press from all over the world were invited there to play the game in order to write their reviews and most importantly decide their review scores. But what they were given to play was not simply the latest stable build of the game itself, but a specially created campaign scenario that also had a fair amount of scripting and sort of held reviewers’ hands through the experience more than the actual game would. And again, this was the absolute priority of the team while it was being finished. This build was a lot more representative of the final game than the Carthage demo had been, in that it did actually use the AI and the real game systems, but there was work done to hide away things that weren’t working properly yet, and all of that yet again took time away from core development when we were already way behind schedule and needed to get the actual game finished.
These marketing demos and special builds took time away from developers and used them as a service to the marketing department, and that should never have been allowed. I think leadership wanted to have its cake and eat it, to develop an ambitious game project on a tight schedule, while also getting to release slick trailers to promote the game along the way, without investing the additional resources that should have required.
Patching Rome II
The days and weeks immediately following the launch of the game were a surreal experience, especially for me personally. I felt the impact very strongly because I was being torn apart online for my appearance in the Rally Point video, but the impact was felt across the studio. There was also a strange business-as-usual attitude among leads, I suppose because many had been through that experience previously with Empire. There was a lot of talk about success and the high number of pre-orders and sales, and some key leadership individuals left immediately after launch to take part in marketing events to help promote the game. I felt like our project had gone up in flames and our leaders were nowhere to be seen, and marketing was still taking a priority over finishing the game, which was now live.
Initially, development on Rome II seemed to continue as though we were still pre-alpha, in that we were still figuring out basic issues with gameplay and designers were still planning new features. Despite the state of the game, it was decided after a short time that most of the team would be moved on to future projects and I was asked to lead a small team of programmers, designers and QA testers to fix Rome II — maybe 10 or 12 people in total. From this point onwards I think we were able to start getting the game finished but it took time for major differences to be noticed by players. By that time, the rumour had become established that I had been fired, and now that the game was improving, this was taken by many as proof that I was gone and my replacement was doing a better job. So I was having to come into work every day along with those on the patching team and chip away at the problems knowing that those improvements would be taken by many as further evidence of my incompetence. I cannot tell you how demoralizing that was, and the thought of resigning certainly crossed my mind, but I wanted to at least get the game working first.
Eventually we released Patch 14 which fixed the last of the most serious issues that were affecting gameplay in siege battles, and this was received well by many players. In my opinion this was the first point in time that Rome II became fully playable, but it was still far from finished and contained numerous gameplay, balancing, and AI issues that could yet have been improved. It soon became clear however that the state of Rome II at that point was considered good enough by leadership, and that the patching process would be wound down, the game rebranded as Emperor Edition, and myself and others moved onto new projects. This decision went against my wishes, as I would have happily continued to work on Rome II into the future, and believed that it should continue to be a priority for the studio. Rome II was selling well, and there was an extensive plan for further DLC development, so it seemed reasonable to me that we should continue to support and improve the core game itself.
The cost of keeping a small team of developers on the project would have been easy to justify, but there were now multiple new Total War projects in development simultaneously, and they needed AI programmers as well. Not only that, but it was explained to me that leadership was concerned that Attila would be perceived as being too similar to Rome II, and therefore improved AI would be a way to differentiate it and make it more appealing to consumers.
The Post Mortem
After Rome II launched, there were immediate discussions about why the game had not been delayed. The decision appeared to have been made largely on the basis of one management figure playing the game and deciding it was good enough for launch, and management acknowledged to us that they had made that decision knowing that there might be a backlash comparable to that which followed the release of Empire: Total War, but they decided to go ahead anyway. I found this very disappointing, especially considering the consequences that I was personally experiencing as a result.
Eventually we were given the opportunity to conduct a post mortem on the project, which was the process by which the development team reports and discusses things that went right and wrong on the project, with the goal of using those findings to inform changes to the way future projects are managed. This was standard after all of our projects but it was seen as especially important for Rome II as so much had gone wrong and a lot of people had important feedback to give. The post mortem was one of the only opportunities where developers were invited to give feedback to management, so it was the time to really get things off our chests. And we did. A lot of feedback was given, and there was a lot of criticism of management around fateful production and design decisions.
Given that I had expressed concerns during development and felt that I was not listened to, I had taken the launch problems as a kind of vindication, even if I was being pilloried in the outside world. I took a lot of the anguish and frustration I felt during that period and funneled it into action towards fixing these problems and making sure nothing like it happened again, and I was genuinely optimistic that now after Empire and Rome II, things at the studio were going to change. But it wasn’t to be. The first indication that leadership were doubling down on their decisions came in the form of criticism that we, the battle programming team, had been “too conservative” when it came to adopting new features. Despite all of the problems with Rome II and its many incomplete and broken features at launch, and despite all of the warnings that had been ignored, we were now being told that we had pushed back too often against new features and that we should be more agreeable in future.
After all of the post mortem feedback was given and discussed, it was collated by a central leadership figure who then sent out a team wide report stating their official conclusions. It was a whitewash. Production and design failures by management were minimized and largely absent, and an alternative narrative was presented that Rome II’s problems were caused by the new developers who had joined the team since the older games had been made. The more senior staff, the statement explained, had failed to impart to the wider development team knowledge of the “secret sauce” necessary to the making of a successful Total War game. The argument went that because the leadership had made games like Rome: Total War in the past, Rome II’s problems simply couldn’t have been their fault. Rome II, it was now being claimed, was really just a remake of its predecessor which was a success and so its problems must have been caused by those new to the team.
I viewed this as a transparent attempt by leadership to save face, and the claims made were obviously untrue. Firstly, beyond sharing the same setting, Rome II’s design was different to Rome: Total War in almost every aspect, and during development it had never pretended to be merely a remake of its predecessor. All of the communication internally and to the outside world was that this would be the biggest, most ambitious Total War game ever, far exceeding Rome: Total War in scope and complexity. Secondly, there was no question that all of the worst ideas and planning decisions had come from the most senior members of the team. During development they had pushed these ideas on us, ignored our concerns, but now they wanted to blame us for those choices. The decision to directly shift blame from leadership to the wider development team was deeply shocking to me, and had a noticeable impact on the team’s morale in addition to my own. In my mind, from that point onwards there wasn’t any room left for giving leadership the benefit of the doubt. I probably thought that this was as bad as things could get, but they were going to get even worse.
Total War: ATTILA
Even though leadership had largely denied the role they had played in creating the problems we were experiencing, I had been given some assurances about changes to project management, priority being given to battle AI, and communication of design changes. Much of the work I did on Attila was a continuation of work I was doing on Rome II, improvements to siege and battle AI, but after moving to the project it didn’t take long before I started to see the same old problems emerging on this project as well. The first issue was that once again we were not being included in design discussions, and features that impacted AI development were going into the game without anyone informing us. Since we had been given assurances that this situation would improve, I made sure to speak up about it each time I became aware of it, and that led to conflict with Attila’s leadership team, who didn’t feel they owed us any such communication. Not being informed of design changes meant I had no chance to develop AI for them, but leadership simply did not care.
I stopped getting invited to meetings to discuss features that impacted AI, and when I complained about that, I was told that they were very selective about who they brought into meetings so that it was easier to make decisions. I pointed out that of course it’s easier to make decisions if you exclude people who know of reasons why a particular choice might be the wrong one, but it greatly increases the chance of making the wrong choice. The design lead told me the only thing that mattered was that they made decisions as quickly as possible.
In addition to those very basic problems, two controversies emerged that specifically involved the AI. The first was a change being made to the true line of sight visibility system that I mentioned earlier in this statement. Because that feature had not had AI support by design, a decision had been in Rome II to impose a hard distance limit on it — I think it was 100 metres — so that enemy units would always be visible within that range even if you didn’t have line of sight. This would mean that you couldn’t exploit the AI’s lack of awareness by popping your units out of cover right next to them. This compromise had been made in part in response to our concerns about lack of AI support, but unfortunately one of the first things that happened in Attila was that designers found this distance threshold setting and reduced it to only five metres. In the context of a Total War battle, five metres may as well be zero; this meant that the player could draw AI units into ambushes and appear right on top of them. I explained all of this and the problems it would create but the designer responsible only seemed to think this was good gameplay and didn’t want to hear my complaints.
So the old habit of designing features that worked against the AI was continuing in Attila, and it was also continuing in Warhammer, which was the other game in development at that point. In the case of Warhammer it was a huge number of spells and elaborate special abilities that would create all kinds of gameplay which the AI at that stage was not planned to be able to participate in. My understanding is that Warhammer got more development time and eventually the AI was given more capability there, but when I was still at the company the design approach was to prioritize new features over AI ability. I made my feelings clear in the case of both games, that they were deliberately designing games with bad AI, but designers treated me dismissively and told me I was wasting their time.
The second issue that emerged on Attila was a new feature that would affect siege battles. We had just spent the best part of a year getting siege battles playable after Rome II’s launch and I was feeling protective towards the stability of that part of the game. I won’t go into the specifics of the feature but the essence was that players would be able to deploy some units inside the city walls in siege battles. My opinion was that this had the potential to disrupt not just the AI but also the gameplay, and I wasn’t confident that we could deliver the feature without regressing in terms of gameplay and stability in siege battles. I think it’s important to say that Attila was a shorter project and I’d spent most of it patching Rome II, so there wasn’t a lot of time left at this point, we were actually not far from the alpha milestone at which point we should have been feature complete.
So I put my concerns forward about risk and timing, and about the importance of not regressing siege battles given Rome II, and I asked what the rationale for the feature was, in order to be reassured that it was worth the risks I had identified. This is a very common question to hear in game development in my experience; if you see someone planning to do something that is risky or expensive, asking them to explain why it’s a good idea, or what problem it solves, is a good way of checking that a mistake isn’t being made. I don’t think it’s a question that got asked very often at Creative Assembly. At first it was ignored, so I asked it again, and probably another time, until I had to point out that we were still moving forwards with this feature despite my risk assessment and the lack of an answer to the question about rationale.
Eventually this led to a design lead sending me a multiple-page long email that attempted to draw the conclusion that having units that could spawn inside the city was a necessary feature for siege battles, even though I don’t think that had ever been the case before in Total War. This led to an argument which was escalated to senior production and design leadership who sided with the design lead and criticized me for complaining instead of just doing as I was told. I also asked these leadership figures if they could give me a rationale for the feature and the best attempt I got was “the rationale is that it makes the game better”.
The Showdown
All of this came to a head one day when the design lead accused me in an email of being difficult to work with and implying that I was failing to collaborate. I replied and said that I believed strongly in collaboration which is why I was critical of the design team who made decisions in a vacuum and refused to even communicate those decisions to the developers that were supposed to be making the game they were designing. This reply caused a commotion, even though I think it was very fair under the circumstances. I ended up in a meeting with leadership and management figures, minus the aforementioned design lead.
I was presented with a statement from that design lead saying that they couldn’t deal with my complaints and concerns, and I explained that I was simply pointing out the ways that Attila was repeating the mistakes made on Rome II, issues that I had been assured would improve. I reminded everyone that the dispute that had led to this argument was that they were refusing to even tell me about changes that affected battle AI, and that I obviously can’t be expected to do my job if they’re not even communicating with me. I wasn’t demanding anything unreasonable, not even to be involved in the design process as I believe I should have been, but at that point I was just fighting to be notified of changes that affected us.
But in that meeting room, Total War’s senior management applied a lot of pressure to me to get me to stop pointing out these problems, and one of them put words in my mouth multiple times, accusing me of saying things I had not said. I want to be clear by the way, that as far as I am concerned, all of my conduct during this dispute had been professional. I simply made my case politely and pointed out the decisions that people were making and how they went against earlier assurances that had been made, and what I feared the consequences would be for the project.
I think that meeting, with me as a low-ranking programmer being chewed out by management for expressing very reasonable concerns about their decisions, was clearly intended to silence me for the convenience of management figures who wanted to continue doing things their way no matter the consequences to anybody else. I suppose it worked, because from that point on I understood that I had made enemies in the team’s leadership and that it would probably affect my chances of promotions and things like that down the line. I considered a variety of options, including going down a formal complaints process with HR, but ultimately I decided it was best for me to leave the studio. I gave plenty of notice and used my time to write documentation and help onboard those who were going to follow me. HR at least reassured me over my conduct and told me that I would always be welcome back (although that may not be true after this statement is published).
Final Thoughts
My experiences at Creative Assembly were quite extreme. The mistake of allowing my reputation to become entangled with the company is my own, but it’s one that I would never have made had I understood at that point the extent to which the studio was being mismanaged. A lot of players and commentators have voiced strong criticism of the company over the years, but I think the behind-the-scenes reality of the Total War team was, at least in some ways, worse than even its harshest critics would have imagined. Despite the reputation I acquired after the launch of Rome II, I’m a developer who takes pride in the quality of his work, and Creative Assembly turned out to be a bad fit for me having had that mindset. Thankfully, I’m happy to say that I’ve had much better experiences elsewhere in the industry.
One question to ask is, how well do these experiences represent the Creative Assembly of today? Given the recent problems faced by the studio it seems clear that studio management and creative leadership continue to be a source of major problems, but I should be clear that it’s not for me to say how similar the details of recent problems are to those that I experienced. One thing I will say is that several of the individuals responsible for the problems I’ve described in this statement either still work at the company, or did until recent layoffs, which I think says something about ongoing problems with the studio’s management culture.
Another question is, why were these leadership problems allowed to persist for so long? Why weren’t changes made after Empire, Rome II, and subsequent controversies? I believe I know the answer and it’s very predictable. Despite ongoing problems with the games and a number of high profile embarrassments, the series continued to be profitable. This fact was used against developers like me who argued for better practices, and was often used by creative leadership as a metric to confirm the success of prior projects and decisions regardless of other ways that they might have failed. My view is that the continued success of the franchise is better explained by the patience and goodwill of its players than it is by the stewardship of Total War’s management.
My goal with this statement was to help the public understand the nature of Creative Assembly’s problems during the period I worked there, in order to better understand the role I personally played in Rome II and the Total War games of the time. It has felt good to unburden myself after living with the consequences of this situation for the last decade. Game developers like me got into making games in the first place out of a love of gaming, and in my case it was also a love of Total War — I had played every game in the series before going to work there. My earnest hope is that Creative Assembly evolves beyond these problems and does better in future. I’d quite like to play Medieval III one day.
