Why this pipeline is different
Game development elsewhere follows a familiar pattern: build, release, observe, iterate. The ability to change things after launch shapes how the work is organised, allowing teams to ship earlier and refine based on real behaviour.
Casino game development cannot work this way, for a specific reason. A certified game that is modified requires recertification, in every market where it is live. That is expensive, slow, and involves coordinating with laboratories, operators and aggregators.
The consequence is that the discipline shifts earlier. Problems must be identified before release, because fixing them afterwards is disproportionately costly. This makes the checkpoints in the pipeline considerably more important than they would be in software where shipping is reversible.
The pipeline
Concept. The premise, the mechanic, the target audience and the intended volatility profile. The valuable work here is deciding what the game is for, since a game without a clear intended player tends to satisfy none.
Mathematical design. The model, constructed and simulated as covered in the previous lesson. This should precede substantial art investment, because a model that does not work invalidates everything built on it.
Prototype and vertical slice. A playable build with the core loop and at least one feature, using placeholder art. This is the most valuable checkpoint in the pipeline and the one most often skipped under schedule pressure.
Production. Art, animation, audio, full feature implementation, and the integration work required for platform compatibility.
Internal testing. Functional, mathematical and compatibility testing across devices and browsers.
Certification. Laboratory testing against each target market's standards.
Integration and release. Deployment through aggregators and operators, with the commercial work of securing placement running in parallel.
Live monitoring. Performance observation and the portfolio decisions covered later in this course.
The vertical slice and why it matters
The vertical slice answers the question that determines everything and is usually answered too late: is this game actually enjoyable to play?
A playable build with placeholder art, the real mathematics and one working feature can be assessed honestly. Does the base game hold attention between features? Does the feature deliver a satisfying moment? Does the pacing work? Is the core loop something a person would return to?
Assessing this properly requires playing it, at realistic stakes relative to a notional balance, for a realistic session length, and preferably by people who did not build it. Studios that test only internally with the team that made it get answers shaped by investment in the outcome.
The value of the checkpoint is that cancelling here is cheap. The art has not been produced, the full feature set has not been implemented, and certification has not begun. A studio willing to cancel at the vertical slice avoids spending the majority of a production budget on a game that was not going to work.
Very few studios cancel at this stage, which is worth noticing. The reasons are organisational rather than analytical: the concept was approved, the schedule assumes the release, and nobody wants to be the person who stops it. A studio that has never cancelled at the vertical slice is either extraordinarily good at concept selection or is not using the checkpoint.
Certification in practice
Certification is a documentation exercise as much as a technical one, and understanding that changes how it is approached.
The laboratory receives a submission pack containing the game build, the mathematical specification, evidence of the random number generation, documentation of features and their behaviour, and market-specific declarations. It verifies that the implemented behaviour matches the declared behaviour and that both meet the jurisdiction's standards.
The failures that occur are mostly not mathematical faults. They are mismatches: the specification describing a feature trigger frequency that differs from the implementation, documentation omitting a behaviour, a market-specific requirement not addressed, or evidence that does not demonstrate what is claimed.
The practices that make certification smooth are consistent.
Write the specification as the game is built, not afterwards from the finished code. Specifications reconstructed retrospectively contain the errors that cause failures.
Simulate thoroughly in advance, so that the studio's own figures match what the laboratory will find.
Understand each market's specific requirements before building, since minimum round durations, prohibited features, mandatory displays and configuration constraints differ, and discovering them at submission means rework.
Maintain a relationship with the laboratory, since queries handled quickly shorten cycles considerably.
Sequence markets by commercial priority, certifying first where the revenue justifies it and expanding as the game performs, rather than pursuing broad coverage for every title.
That last point is a real cost decision. Certifying every game into every market is expensive and unnecessary, since most games will not earn enough in most markets to justify it. A studio with a clear view of which markets matter for which types of content spends its certification budget considerably more efficiently.
Managing the schedule
The production pressure in a studio comes from the cadence requirement established in the first lesson: portfolio effects need enough releases, which means the pipeline must sustain throughput.
The tensions this creates are familiar and have specific forms here.
Concurrent productions are necessary for throughput and create resource contention, particularly for the scarce specialists in mathematics and certification management.
Scope discipline matters more than usual, because features added late affect the mathematics, which affects the simulation, which affects the specification, which affects certification. A late feature addition in this pipeline is more expensive than in most software.
Certification lead time must be planned rather than assumed, and it varies by laboratory workload and by market.
Release windows are commercially significant, since operators plan promotional calendars in advance and a game arriving after its intended slot loses the placement it was built for.
Technical debt accumulates in the shared tooling and framework that games are built on, and studios that never invest in it find production slowing as the codebase ages.
The discipline that matters most is stopping work that is not going to succeed, so that capacity moves to work that will. This is the same portfolio logic as the operator-side discussion in the Operations Strategy course, and it fails for the same organisational reasons.
Soft launch
Releasing to a limited set of operators or markets before wide distribution provides something the studio otherwise lacks: real performance data from actual players.
What it reveals is substantial. Whether the game holds attention beyond the first session. Whether the feature trigger frequency feels right in practice rather than in simulation. Whether the volatility is being experienced as intended. Whether any technical issues emerge across the range of real devices. And whether the game's performance justifies the certification investment for broader markets.
The constraint is that a soft launch requires operator cooperation and delays wider release, and commercial pressure generally favours launching everywhere at once. Studios that soft launch nonetheless make better decisions about which games to promote, which to expand into more markets, and which to quietly let go.
After release
A game's life after release involves less than a studio would like, given the recertification constraint.
Monitoring is available and is covered in the portfolio lesson later in this course.
Promotional support through operator campaigns, tournaments and featured placement is the main lever, and it is commercial rather than technical.
Technical fixes for genuine defects are possible and require recertification where they touch certified behaviour, which means the threshold for what counts as worth fixing is higher than elsewhere.
Configuration changes, where the game supports them, allow limited adjustment without full rebuild.
Sequels and variants are the common route to acting on what a game revealed, since building a new title incorporating the lessons is frequently cheaper than modifying the existing one.
That last point explains a pattern visible across the sector. Successful games spawn sequels not only because the brand is established but because the sequel is how a studio applies what it learned, and the alternative of substantially revising the original is structurally impractical.
Team structure and how work flows
A note on organisation, since production quality depends substantially on how the studio is arranged.
Dedicated game teams assign a stable group to each title from concept to release. This produces ownership and coherence, and it creates resource contention when specialists are needed simultaneously across concurrent productions.
Functional pools hold specialists centrally and allocate them to productions as required. This uses scarce capability efficiently and weakens ownership, since nobody follows a game throughout.
Hybrid arrangements, with a core team per game drawing on shared specialists for mathematics, certification and audio, are what most studios of any size settle on.
The genuinely scarce roles determine the shape. Mathematicians are few, are needed at the start of every production, and are frequently the constraint on how many concepts can be developed concurrently. Certification managers are needed at the end of every production and become a bottleneck when releases cluster. Senior game designers shape whether a concept is worth pursuing, and their judgement is the highest-leverage input in the pipeline.
The practical scheduling consequence is that productions should be staggered rather than run in parallel with identical timelines, so that the scarce roles are used continuously rather than being idle and then overwhelmed. Studios that plan release dates without modelling specialist availability discover this through repeated slippage.
Tooling and the shared framework
Most studios build games on a shared internal framework, and its quality determines production efficiency more than any other single factor.
A good framework provides the reel mechanics, win evaluation, feature scaffolding, platform integration, responsible gambling display requirements, and market configuration in reusable form, so that each game builds on it rather than reimplementing it.
The benefits compound. Production is faster. Certification is smoother, because certified framework behaviour does not need reproving in the same way each time. Market requirements can be implemented once in the framework rather than per game. And defects fixed in the framework are fixed everywhere.
The risk is that framework debt accumulates invisibly. Each game adds a special case, the configuration grows, and eventually the framework constrains what can be built rather than enabling it. Studios that never allocate capacity to framework maintenance find production slowing gradually with no single identifiable cause.
The discipline is to treat the framework as a product with an owner and a roadmap, funded from production capacity rather than from whatever is left over. That is a difficult argument to win against release commitments and is the difference between studios whose throughput improves over time and those whose throughput declines.
Quality assurance in a certified environment
Testing in this sector carries weight it does not carry elsewhere, because a defect in a live game is a regulatory matter as well as a customer one.
The categories that must be covered are broader than functional correctness.
Mathematical verification. Confirming that the implemented game produces the modelled distribution, which means running the actual build rather than the model and comparing.
Feature behaviour. Every trigger condition, every edge case, every interaction between features, and every retrigger path.
Display correctness. What the player is shown must match what occurred. A win displayed incorrectly, a balance shown wrongly, or a paytable inconsistent with behaviour are all serious.
Interruption handling. Disconnection mid-round is common and the required behaviour is defined by regulation. The round must complete or resume correctly, and the player must not lose their stake or their outcome.
Device and browser coverage. Real devices across the range players actually use, not only current flagship hardware.
Stake and configuration ranges. Behaviour at minimum and maximum stakes, and under each RTP configuration where the game supports several.
Market variants. Each jurisdiction's specific requirements, since a build that passes in one market may not meet another's display or timing rules.
Responsible gambling elements. Session information, net position display, and any mandated interruptions behaving correctly.
The distinguishing point is the consequence of failure. In most software a defect is fixed in the next release. Here a live defect may require the game to be withdrawn, may trigger an operator's regulatory notification obligation, and may require player compensation. That asymmetry justifies a level of testing rigour that would be excessive elsewhere.
What goes wrong
A short catalogue of the recurring failures in this pipeline, since recognising them in advance is cheaper than encountering them.
Art produced before the mathematics is settled, so a model change late in production invalidates completed assets.
Scope added after simulation, meaning the verified model no longer describes the game and everything must be redone.
Specification written retrospectively, introducing the mismatches that cause certification failure.
Market requirements discovered at submission rather than at design, producing rework on a finished build.
Concurrent productions colliding on scarce specialists, so several games wait on the same person.
No cancellation discipline, so weak concepts consume full production budgets.
Certification scheduled optimistically, with no allowance for laboratory queries or resubmission.
Release timed without reference to the operator's promotional calendar, so the game launches into no placement.
Each of these is a planning failure rather than a capability failure, which is encouraging, because planning failures are addressable by anyone willing to hold the checkpoints.
Working with aggregators and operators during release
The final stage of the pipeline is commercial as much as technical, and studios that treat release as a delivery event rather than a coordinated launch systematically underperform.
Integration lead time. Aggregators and operators have their own release schedules, testing requirements and certification checks. A game delivered without regard to those cycles waits.
Asset requirements. Operators need promotional artwork, descriptions, thumbnails and specification details in defined formats. Late or incomplete asset delivery delays placement.
Placement negotiation. As established, placement determines earnings, and it is agreed in advance rather than granted on merit after release. This work should run in parallel with production, not after it.
Promotional coordination. Operators plan campaigns, tournaments and featured slots weeks or months ahead. A game arriving outside that planning window receives whatever is left.
Launch monitoring. The first days of live performance are informative and are the point at which technical issues surface across the full range of real devices and player behaviour. Somebody should be watching.
Post-launch reporting. The performance data the studio receives depends on what was negotiated, and studios that did not secure useful reporting cannot manage their portfolio properly, which the next lessons in this course depend on.
The general point is that a studio's product is finished when it is released and its commercial outcome is largely determined by work done before that. Studios organised so that the commercial function engages only at delivery consistently launch good games into poor positions, which is the most avoidable failure in this business.