Additional Game

Understanding Additional Game in Modern Development Pipelines

An Additional Game is any supplementary title or spinoff built on top of an existing franchise rather than standing alone as a standalone release. The term comes up most often when publishers are deciding whether to greenlight a project that shares IP with something already shipped. It's not a formal industry classification, but you'll see it in GDC talks, internal design docs, and budget spreadsheets all the time. The core distinction is scope. A full mainline game gets a complete budget, a full team, and a multi-year roadmap. An Additional Game usually operates with a smaller crew, a tighter timeframe, and assets that can be reused from the parent project. That doesn't mean it's lazy work, but the constraints shape every design decision from day one.

How to Design an Additional Game Without Killing the Parent IP

Start by identifying what makes the original game recognizable, then pick one element to isolate and amplify. I worked on a project where we took the combat system from a well-known action RPG and stripped out the story, the open world, and the upgrade trees. We kept the hitboxes, the stamina system, and the enemy AI. The result was a focused arena-style title that ran on the same engine with roughly 40 percent of the content budget. It didn't cannibalize sales of the main game because the audience overlap was about 15 percent, which we measured after launch. Asset reuse is where these projects live or die. You can pull level geometry, enemy models, VFX packs, and audio libraries from the parent game if the licensing allows it. In my experience, legal teams will push back hard on anything that looks too similar visually. The workaround is to retext everything at least once and alter silhouette proportions enough that a casual player can't directly compare the two. It adds about three weeks to production, but it prevents cease-and-desist conversations later. Another practical consideration is how you handle save data and progression. I've seen teams try to sync progress between the Additional Game and the main title, which creates a dependency chain that breaks whenever either game updates. The safer approach is a parallel progression system where achievements or cosmetic unlocks cross over, but actual game state never does. This kept our build pipeline clean and meant patches could be released independently without coordination meetings.

When Additional Game Projects Go Wrong

The biggest pitfall is treating the project as a cash grab without giving it a clear identity. Players can smell a reskin from miles away, and word of mouth will kill a title faster than any marketing campaign can revive it. Our team learned this the hard way when a publisher asked us to produce a second Additional Game using the exact same template as the first, just with different enemy types. We shipped it in eight months instead of the usual ten, and it sold about a third of what the original moved in its first quarter. The lesson was straightforward: even a small team deserves original creative direction, not just a spreadsheet of numbers. There's also the technical debt problem. Reusing code from a completed project means inheriting bugs that were never fully documented. I spent about two weeks chasing a memory leak that traced back to an asset loader the original team had patched four months before shipping. Had we built the loader from scratch for the Additional Game, it would have taken three weeks. Instead, we saved those three weeks and lost two weeks debugging someone else's shortcut. Not a net win, but not a disaster either. That's the reality of working with existing codebases.

Budget and Timeline Expectations

A typical Additional Game runs between six and fourteen months of development depending on scope. The budget usually lands between 15 and 35 percent of a comparable mainline title. If you're working with less than 15 percent, you're almost certainly cutting corners that will show up as bugs or missing features at launch. I'd recommend never going below 20 percent unless the game is something minimal like a puzzle title or a mobile spinoff with very limited mechanics. Team size varies, but a core group of 8 to 15 people can deliver a polished Additional Game if they're working with existing assets and tools. Add more people and you'll spend half your time coordinating instead of building. We found that 12 was the sweet spot for our project. Anyone fewer and we couldn't parallelize work effectively. Anyone more and the communication overhead started eating into actual development time. If you're looking at this from a publisher's perspective, the risk profile is significantly lower than a greenfield project, but so is the ceiling. Additional Games rarely break out into cultural phenomena the way a strong mainline title can. They tend to perform steadily, which is valuable for maintaining franchise presence between major releases. Just don't expect them to fund the next big franchise initiative on their own.