> 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.
I don't really see the leadership problem here to be honest, because of feature is difficult to do (because ambitious) does not mean it does not deserve to be done. I guess the problem was more that the time to execute was too short. An healthier way to respond would have been "Sure, but because of X and Y difficulties please consider the time to finish development will be increased by Z"
The developper sounds like he may have been a bit difficult to work with at times.
However I was shocked to learn that the game was not playable until very late, how could this allow any meaningful testing and feedback before going live?
> An healthier way to respond would have been "Sure, but because of X and Y difficulties please consider the time to finish development will be increased by Z"
And what if the leadership/culture just responds 'screw you do it anyway, you're really elite right? You can do anything right?'. So the employees in the trench just goes on a death march because hey, passion and whatever.
And then at the postmortem leadership just plays the blame game for the broken product. Which is fine if you don't care about politicking, but now someone upside is convinced you suck and the layoffs come for you. In the author's case there seems to be even some sort of reputational harm. THIS is how the worker gets incredibly jaded.
> An healthier way to respond would have been "Sure, but because of X and Y difficulties please consider the time to finish development will be increased by Z"
Yes, and from the article it seems that the author also agrees. However from my reading the leadership was so top-down and closed minded that if you said this the best case is that you’d be told you’re wrong and it was completely achievable because they felt that it should be.
That reflects my experience with software team's management for my whole career (12 years).
I feel grateful I don't experience this at my job (so far).
What you're missing is the notes from the prior meeting where someone told the lead of the programming team "the delivery date is ABC, there will be no delays". The time to finish development was already bounded by that, so saying "please consider the time to finish development will be increased by Z" is like showing a cow a card trick.
> However I was shocked to learn that the game was not playable until very late, how could this allow any meaningful testing and feedback before going live?
This is a leadership and management problem, it doesn't actually have to be this way and is also why it can be hard to push back on requests that don't make sense because it's hard to tangibly demonstrate the issues when the game just doesn't function. And worse because games are a creative project watching something you've worked on for ages suddenly come together is a really compelling feeling and can be successful so the issue perpetuates until the grenade goes off in your hand.
I also think you're reading too much into the phrasing ten years on. In particular when he's speaking on behalf of his lead at the time rather than anything he directly said.
> we couldn’t guarantee that it would be stable by the end of the project.
He said that the time was not enough. Also, we don't know the exact way he communicated the problem.
As somebody who's worked in game dev, I can relate to the author.
You could totally argue that the incompatibility and non-modularity of the land + naval AI systems is bad design, but that does not put the blame on the author: they may not have had anything to do with it!
In my opinion, it is very much leadership who is at fault in this example. When the programming team says "this can't be done in time for release", and then leadership says "that's rough buddy, do it anyways", that's 100% leadership's fault.
I wouldn’t even blame the authors of the system that existed. Even in a perfect culture, compromises need to be made. If the time needed to adapt land warfare AI to the new sea warfare AI in Empire(?) is high, better to just focus on making the thing you’re building work well than to be “pure.”
Now consider a culture that wasn’t, as reported, particularly healthy and…
> An healthier way to respond would have been...
True in theory, but a lot of the time leadership doesn't care and wants it made NOW, with no care or consideration being given to bugs, because the execs don't play games and don't know (or rather, care) how much buginess can ruin the experience.
For them it's a battle between pushing the broken version ASAP, versus taking an unbounded amount of time to properly do it. To be an exec you have to be short sighted since the only thing that matters is the current and potentially the next quarter, so you get shit like this all the time, since they're incentivized to do it the idiotic way to earn money ASAP and leave for greener pastures right after the money settles.
> However I was shocked to learn that the game was not playable until very late
That seems rather common for many projects? If you have so many pieces developed in isolation, putting them together only really starts to happen when you get higher time pressure.
The part that's missing here is that Rome II is not a new project. The company has been working on this series of games for 25+ years now. They release them regularly and the bulk of the engine work was done years ago. The fact that they break the whole thing down and do it in isolation for every release is a mistake. They should just be iterating on top of the previous game.
> They should just be iterating on top of the previous game.
You can’t boot your whole game every time to do AI iteration. Whether or not the menu loads is completely irrelevant to your work. You don’t really want to integrate your broken shit with the currently working rest of the game either.
At least, that’s how I’d think about it.
You can always run the AI in a separate test harness to see changes more quickly. This is what they were doing throughout development. What they weren’t doing was putting everything back together to see if the game still worked or made any sense (until the very end).
If you don’t want to check in broken AI code then don’t; that’s what branches are for. But the fact that they weren’t maintaining a working master is inexcusable.
Even if it's common, I still don't think it's good.
Some games seem to be made playable way earlier then in the case of Rome 2. Look at Baldurs Gate 3 and soon for Path of Exile 2 - all the content is not there yet but the main "game loop" and features are there, this seems like a great way to get feedback, and have time to adjust if necessary. In the case of Rome 2 I guess the management imposed deadlines that did not allow this to begin with. The author does speak of a demo for E3 but it seems like a small piece that was artificially setup to look good.
This might be a partial explanation why indie studios can be in meaningfully competition with the AAA-developers. They often integrate early and use beta, even alpha, early access. As a layman I find that approach more understandable. In my work, I always favore incremental changes to large process overhauls. We do have to understand that 10 years ago early access was a lot less common.
In the specific case of Celeste, the game was playable before development, because it was preceded by the PICO-8 version.
Valve did this a couple times by just buying out teams who made mods or interesting games - Narbacular Drop becoming Portal, that goo thing becoming the goo thing in Portal 2, Counterstrike becoming Counterstrike, then a CS mod becoming Left 4 Dead.
"Every big program that works evolved from a small program that worked" is even true for games
Speaking as a manager, I’d much rather my team(s) tell me the plan is pure fantasy and a total joke than blow smoke up my arse. At least I have information to take to the other teams.
Generally, I’ve learned to accept that non-managers won’t communicate as well as managers because that’s the manager’s job: I’ll put the effort in to figure out what’s being said.
The only time I’d see someone as being difficult is, after bringing concerns, making a decision they don’t agree with, they continue to spout off instead of making an honest effort to get things done.
Giving the author the benefit of the doubt, I think they did the right thing: raised concerns, tried to make it work anyway, and were let down by the leadership team. I’m willing to believe this is what happened because I’ve played TW games and noticed how they just seem to get worse. I’ve also watched experienced TW streamers rip into the faults at a mechanical level and how they’ve persisted for years while CA progressively seems to put out games nobody wants.
> "An healthier way to respond would have been "Sure, but because of X and Y difficulties please consider the time to finish development will be increased by Z""
In practice this never goes as smoothly as you think.
It's a constant antagonistic battle between management and the people on the ground doing the work. Let's face it, the devs also want to have a chill time and develop at their own pace (because it allows them to not stress, slack off, but also because they can focus on quality and the art of it, etc). Management knows about this, they just suffer from a lack of ability to tell the difference between which one the dev is doing when when he asks for "more time".
Either way, you need engineering leadership that has clear goals and priorities. Having management with non-technical people that don't trust the technical people, along with conflicting and opposing constraints, will give you Boeing and this game disaster.
We need to bring back meritocracy.
But some management jobs are technical themselves. Take CFO for example. It would be very difficult for an engineer to become a CFO in any reasonable timescale.
Marketing, HR, Sales and the aforementioned finance are all things that a frequently trivialised on hn, but none of them would be an easy transition for your average engineer.
I am not in gaming but I run finance at an organisation that has a lot of engineers.
1) I spend a lot of time explaining what our organisation does to our finance team. This is rare in my experience. 2) giving up on engineering focus to want to become commercially focused is a big step, and not one everyone is going to want to take. Imagine suddenly being dragged into a meeting with your holding company to explain why your project is losing money?
Overall I can't believe that they develop games like this. If you have a game about battling in Japan, and you want to make a game about battling in Rome...why does that need any programming at all? New maps, new units etc.... then maybe use it as a chance to launch the latest version of your game engine
> If you have a game about battling in Japan, and you want to make a game about battling in Rome...why does that need any programming at all? New maps, new units etc.... then maybe use it as a chance to launch the latest version of your game engine
Well the new version of the engine is what makes the programming required :p
Each new Total War game introduces some new mechanics, so obviously it needs a rewrite sometimes. As the author said, they had 2 systems that now had to be merged together, and the engine wasn't built to handle the situation properly.
Even between the Warhammer games, they massively changed things around between 1, 2 and 3, with lots of new mechanics and tweaked old ones.
These companies somehow always at the brink of bankruptcy and have to ship shit