Ask a studio how long it takes to make a game and you'll usually get a confident answer. Ask how long it takes to ship one and the answer tends to start with “it depends”.
That gap in confidence tells you something. Building a game is a creative discipline studios have spent years getting good at. Shipping a game is an operational discipline, and most studios treat it as the last step of the first.
Two jobs with different shapes
Building is iterative. You prototype, test, throw things away and try again. The feedback loop is internal and fast: the team can play the build today and change it tomorrow. Success is judged on whether the game is fun, whether the maths holds up and whether it looks and sounds the way it should.
Shipping is sequential. Things have to happen in a particular order, and many of them depend on people outside the studio. A test lab can't certify a build that's still changing. An operator can't schedule a launch until the game is certified for its markets. A contract can't be finalised until everyone agrees on reporting. The feedback loop is external and slow, and success is binary. The game is live, or it isn't.
Studios that treat these as one job tend to run shipping the way they run building. They keep it loose, start it late, and expect to iterate their way through. That's precisely the approach that makes shipping take longer.
Where the handoffs break
Most shipping delays don't come from any single task being hard. They come from the moments when work passes from one set of hands to another. A few handoffs cause more trouble than the rest.
- Design to maths documentation. The maths model exists, but the documentation a lab needs is written after the fact by someone who wasn't in the design meetings.
- Build to certification. The build is “final” until the lab raises a finding, and then it goes back through development, QA and submission again.
- Certification to market variants. A second market needs a different RTP profile or a feature switched off, and that turns into a new build rather than a setting.
- Studio to operator. Every operator has its own integration checks, asset specs and launch calendar, so the same game is effectively onboarded again and again.
- Launch to reporting. Once the game is live, revenue data arrives in different formats from different partners, and somebody reconciles it by hand.
Each of these is a place where context gets lost. The people who understand the game best are rarely still involved by the time the question arrives.
Different skills, different owners
A strong game team has designers, mathematicians, artists, engineers and testers. A strong shipping operation needs people who know how labs work, what different regulators expect, how operators run QA and how commercial terms are normally structured.
Those skills rarely sit in the same small team, and they're expensive to hire before you have enough games to justify them. So early-stage studios end up in an awkward position. They're strong at the part that makes a game worth playing, and short on the part that decides whether anyone gets to play it.
What a shipping plan actually contains
A shipping plan doesn't need to be elaborate, but it does need to exist before the build is finished. At a minimum it answers who owns each step after gold build, what each outside party needs from the studio and by when, and what happens when something comes back rejected.
It should also name target markets and operators early. Those two decisions set most of the constraints on shipping: which lab standards apply, which game variants are needed, which integrations have to exist and which assets have to be produced. Leaving them open until the game is done is the most common way a shipping plan turns into a scramble.
Finally, it should cover what happens after launch. Reporting, support and updates are part of shipping too, and they last a great deal longer than launch week.
Treating shipping as a system
The studios that ship well don't necessarily work harder at the end. They move shipping work earlier and make it repeatable.
They design with target markets in mind, so certification requirements are known before the maths is locked. They keep documentation alongside the build as it changes. They express market differences as configuration. They ship through distribution they already have, so a new operator adds a launch date rather than an integration project. And they standardise what comes back, so reporting is something they read instead of rebuild.
The more of that lives in infrastructure rather than in people's heads, the less each new game has to start from zero. The tenth launch should be noticeably easier than the first. For a lot of studios, it isn't.
Where Raise fits
Raise Engine is built on that split. Creators use it to build their games, and the shipping system, the operational layer that usually turns up as a surprise after the build is done, is already underneath them. The short version: you ship the game, and the infrastructure ships everything around it.
For operators, brands and studios that need a whole title made, Raise Studio builds on the same infrastructure, from concept through certification. Either way, the aim is the same. The people who are good at building games should get to spend their time building them.
.gif)
