Late in production, a AAA project can start to slip in ways that are hard to see from inside. Milestones move, the bug count climbs faster than the team can close it, performance targets keep getting missed and certification is getting closer. The team is working hard, but the remaining work is bigger than the time left.
Bringing in a co-development partner at this stage can help a great deal, but only if it is done carefully. We have joined projects in this position many times, and this is how we approach it.
What are the signs a late-stage project needs help?
- Milestones are being met on paper but key features are still not working end to end
- The open bug count is rising, or the fix rate is falling, week on week
- Frame rate and memory targets are still being missed on one or more platforms
- Certification or a platform submission date is close, and requirements are not yet covered
- Senior people are spread across too many problems to solve any of them fully
Any one of these can be managed. Several together usually means the project needs more senior capacity aimed at specific problems.
Why is adding people late risky?
Adding people to a late project can slow it down. New team members need onboarding, take time from the people who already know the code and add communication overhead. Fred Brooks wrote about this in the 1970s, and it is still true in games. The way around it is to add a small number of experienced people, give them clear ownership of specific problems and keep them out of the way of the core team.
How does late-stage co-development work?
Start with an assessment
The first week or two should be spent understanding the real state of the project: the build, the bug database, performance on each platform, certification requirements and the schedule. The output is a short list of the problems that matter most and a plan for each.
Embed senior people with clear ownership
Experienced engineers and designers join the team and take ownership of agreed areas, such as performance on a particular platform, stability, online features or certification. They work in the studio's tools and processes and report through its leads.
Focus on what blocks release
Late in a project, the work that matters most is the work that stops the game shipping: crashes, performance, platform requirements and broken features. Nice-to-have improvements wait. A partner should help the studio protect that focus.
Keep the core team leading the game
The studio's own team knows the game and owns its creative direction. A good partner takes pressure off them so they can concentrate on the decisions only they can make.
Work in short cycles
Short milestones, often a week or two, with clear goals make progress visible and let the plan change quickly as problems are solved or new ones appear.
Plan past launch
Release is only the start for most AAA games today. Day-one patches, server load, live operations and the first content update all follow quickly. Planning for them during stabilization avoids a second crunch straight after launch.
How Rocket Science Group helps late-stage projects
Rocket Science Group is a video games solutions company with more than 25 years of experience building and running games. Atomic Theory, our studio for co-development, gameplay and UX, embeds senior people with studios to stabilize projects and drive them through to release. Terminal Velocity strengthens backend and online systems, and Multiplay hosts game servers and runs live operations once the game is out. That means the same group can help you finish the game, launch it and keep it running.
If your project needs help getting over the line, talk to us.
Frequently asked questions
Can co-development help a late-stage AAA game?
Yes, when it adds a small number of senior people with clear ownership of specific problems, such as performance, stability or certification, and keeps the core team focused on the game.
How quickly can a co-development partner get started?
An experienced partner can begin assessing the project within days and have people working in your pipeline soon after, depending on access and onboarding.
What should a partner focus on late in production?
The work that blocks release: crashes, performance targets, platform requirements and broken features.
