Most game projects do not fail because nobody had a good idea. They fail because the team scaled production before proving that the idea could survive contact with players, hardware, schedules, and content pipelines. Across 16 years in game development, I have learned to treat the vertical slice as a decision-making tool, not a miniature trailer. A useful slice exposes risk while change is still affordable. A bad one hides risk under polished art. Whether I am evaluating a Unity client project, maintaining Touch Camera PRO, or thinking back to Eagle Flight Arcade at Ubisoft Montreal in 2016, the same principle applies: prove the difficult parts before multiplying them.
Key Takeaways- A vertical slice should test production assumptions, not merely demonstrate a game concept.
- Start with the risks most likely to invalidate the project, including feel, performance, content cost, and platform constraints.
- Use enough architecture to test repeatability, but avoid building a speculative framework.
- Set measurable acceptance gates before polishing the slice.
- Greenlight, pause, or cancel based on evidence rather than enthusiasm or sunk cost.
What Should a Vertical Slice Actually Prove?
A vertical slice is a small, representative piece of the intended game at something close to the target quality bar. That definition sounds simple, but teams often confuse it with a prototype, demo, or pitch video. A prototype asks whether an idea might work. A demo communicates an idea to an audience. A vertical slice asks whether the team can repeatedly produce the real game.
I expect a slice to answer five questions. Is the core interaction enjoyable after the novelty wears off? Can the technology support the intended experience? Is the visual and audio target achievable on the target hardware? Can the team build more content through a repeatable pipeline? Finally, does the result communicate a coherent product to someone who did not help create it? A beautiful room that took heroic effort to assemble does not answer those questions.
The common mistake is selecting the easiest content. Teams choose a safe level, scripted encounter, or controlled camera angle because it produces attractive footage. That approach removes exactly the uncertainty the slice should expose. If enemy density, touch input, save data, network latency, or procedural layout is central to the product, the slice must include a representative version of that problem.
As a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016, I worked on a VR flight game targeting PSVR, Oculus Rift, and HTC Vive. That kind of development makes hidden assumptions expensive. Controls, frame timing, readability, and player comfort are part of the product, not finishing touches. The lesson applies outside VR too. Your slice should contain enough real pressure to reveal whether the design survives its delivery conditions.
The final test is repeatability. If the slice works only because one developer remembers a fragile sequence of editor steps, production has not been proven. A strong slice leaves behind documented settings, reusable prefabs, clear ownership, and a credible path to the next piece of content.
How Do I Choose the Riskiest Part of the Game?
I begin with a risk register before I build a scene. For each major assumption, I record what must be true, what evidence currently supports it, and what happens if it is false. I then rate uncertainty and consequence on a simple scale from 1 to 5. Multiplying those ratings is not scientific, but it forces useful comparisons. A feature with high uncertainty and project-ending consequences belongs near the front of the slice.
Design risk is only one category. Technical risk covers performance, platform services, simulation, networking, input, and persistence. Production risk covers asset throughput, level assembly, localization, testing, and build creation. Product risk covers whether players understand the premise and want another session. Team risk covers missing expertise, unclear ownership, or a tool that only one person can operate. A real slice usually combines one or two risks from several categories.
Maintaining Touch Camera PRO has made me particularly suspicious of the phrase “input is easy.” Input is easy in an isolated happy path. It becomes difficult when gestures overlap, devices report differently, UI competes with world interaction, and a project needs custom behavior without modifying package code. If touch control is central to a game, I would rather test gesture conflicts and customization in the slice than demonstrate one perfect swipe.
Do not automatically select the largest feature. Select the uncertainty that could force the largest redesign. A procedural world might sound technically impressive, but the bigger risk could be whether players can read the combat at the chosen camera distance. A multiplayer architecture may deserve investigation, but perhaps the immediate product risk is whether the cooperative action is enjoyable in the same room.
I also write a failure statement before implementation. For example: “If new players cannot identify the next valid action without verbal guidance, this interaction model needs revision.” That is far more useful than “make the tutorial feel good.” A clear failure statement tells the team what to observe and makes it harder to redefine success after seeing disappointing results.
Which Unity Architecture Belongs in a Vertical Slice?
A throwaway prototype can tolerate shortcuts. A vertical slice cannot depend entirely on them because it must test whether production is repeatable. However, this does not justify building a universal framework. I want narrow seams around the systems most likely to change: input, game rules, presentation, content configuration, persistence, and platform services.
In Unity, I usually separate authored data from runtime state. ScriptableObjects can hold tuning values and content definitions, while scene objects own temporary state. I keep input behind a small interface so keyboard, controller, touch, or XR implementations can change without rewriting the gameplay rule. The same principle applies to audio, achievements, analytics, and save systems. The interface should represent what gameplay needs, not every capability the provider offers.
using UnityEngine;public interface IAbilityInput
{
bool PressedThisFrame { get; }
}public interface IPlayerAbility
{
bool TryActivate();
}public sealed class PlayerAbilityController : MonoBehaviour
{
[SerializeField] private MonoBehaviour inputSource;
[SerializeField] private MonoBehaviour abilitySource;private IAbilityInput input; private IPlayerAbility ability; private void Awake() { input = inputSource as IAbilityInput; ability = abilitySource as IPlayerAbility; if (input == null || ability == null) { throw new System.InvalidOperationException( name + ": Sources must implement the slice interfaces."); } } private void Update() { if (!input.PressedThisFrame) { return; } ability.TryActivate(); }
}
This example is intentionally small. The controller understands an intention and an ability, but it does not know whether the intention came from a touchscreen or gamepad. It also does not contain cooldown visuals, sound effects, or platform code. Those boundaries let a team test alternative implementations without dismantling the core loop.
I apply two tests to every abstraction. First, does the slice already have at least two plausible implementations or a known platform variation? Second, will this boundary make a production risk observable? If both answers are no, I probably do not need the abstraction yet.
The architecture has succeeded when another developer can create a second representative encounter without copying a scene and repairing references by hand. Prefab variants, validation tools, automated tests for stable rules, and concise setup notes are more valuable than an impressive inheritance hierarchy. The goal is controlled repetition, not theoretical purity.
How Much Polish Should the Slice Receive?
A vertical slice needs enough polish to test the intended experience, but polish must be attached to a question. If hit effects are necessary for players to understand combat timing, they belong in the slice. If a cinematic transition exists only to make a presentation feel expensive, it may be hiding the unfinished production problem underneath.
I divide polish into readability, responsiveness, coherence, and spectacle. Readability tells the player what is happening. Responsiveness connects input to visible and audible feedback. Coherence ensures the art, animation, UI, and sound appear to belong to the same product. Spectacle creates memorable peaks. I fund those categories in that order. Spectacle cannot rescue an interaction that players cannot parse.
Performance is also part of polish because unstable delivery changes how controls and animation feel. Choose an explicit hardware target and frame-rate target before profiling. A 60 Hz game has roughly 16.7 milliseconds for a frame, while a 90 Hz target has roughly 11.1 milliseconds. Those are total budgets, not CPU allowances. The slice should measure representative scenes on representative hardware instead of assuming the editor reflects the final build.
I recommend setting content budgets early, even when the first values are provisional. Track texture memory, material complexity, visible characters, physics activity, audio voices, loading behavior, and garbage collection. In 2025 and 2026, Unity teams commonly target several hardware tiers and storefront environments. A slice running on a powerful development machine proves very little about the weakest supported device.
Do not polish every surface equally. Pick the player path that represents normal play, bring it to the intended bar, and leave secondary areas visibly temporary. Label placeholders so stakeholders do not mistake them for final decisions. This creates an honest contrast between proven quality and unresolved work.
I stop adding polish when the team can answer the slice questions without apologizing for missing feedback, but before improvements become indistinguishable from content production. The slice is an experiment with production-quality ingredients. It is not permission to build the first ten minutes of the game while the remaining pipeline stays hypothetical.
How Should Players Test a Vertical Slice?
Developers are poor substitutes for first-time players because we know what every object means and what every broken interaction was supposed to do. I want external observation early, including when placeholder visuals are uncomfortable to show. Waiting for presentation quality usually means preserving design mistakes for too long.
I use three waves of testing. The first is guided and diagnostic. I can interrupt, ask what the player expected, and inspect obvious failures. The second is silent. The player receives only the instructions that the final product would provide, while the team watches without rescuing them. The third approximates the target context, including the intended device, input method, session conditions, and build installation process.
Questions should test comprehension and intention rather than request design solutions. I ask, “What were you trying to do?” and “What did you expect to happen next?” I avoid “Did you like the controls?” because politeness makes that answer unreliable. Behavior is stronger evidence. Repeated hesitation, missed feedback, accidental actions, and ignored options show where the design model differs from the player’s model.
Basic instrumentation helps, even without a production analytics service. Record important state transitions, failed interactions, restarts, completion paths, and settings changes. Use anonymous local logs when that is sufficient, and review privacy requirements before collecting anything remotely. A timeline often reveals that a supposed difficulty problem is actually a comprehension problem three steps earlier.
Test the second attempt as well as the first. The first attempt reveals onboarding and readability. A repeated attempt reveals whether the mechanic gains depth or merely becomes routine. A vertical slice should not only produce one successful session. It should offer evidence that the central loop can sustain repetition.
Most importantly, define in advance what result triggers a change. If three testers struggle, a team can always call them outliers. If the acceptance condition says that unassisted players must identify the primary objective and perform the core action, failure is harder to rationalize. The exact threshold depends on the project, but the threshold must exist before the room becomes emotionally invested in the result.
What Do Real Hardware and Delivery Constraints Reveal?
My only AAA studio credit is Eagle Flight Arcade, where I worked as a Gameplay Programmer at Ubisoft Montreal in 2016. It shipped across PSVR, Oculus Rift, and HTC Vive. The enduring lesson was not simply that VR needs performance. It was that hardware assumptions shape design, controls, testing, and content from the beginning. You cannot validate the experience on one convenient setup and treat the rest as a packaging task.
The same principle applies to mobile devices, desktop configurations, event builds, handheld hardware, and browser delivery. Different aspect ratios can invalidate UI composition. Thermal limits can turn a stable opening into an unstable longer session. Storage and loading behavior can break pacing. Controller disconnection, focus loss, permission prompts, and suspended applications can expose missing state transitions.
Client-facing work, including Loreal Viva Tech 2024, has reinforced another point for me: a build is experienced inside a delivery context. The person launching it may not be a Unity developer. The network may be restricted. The display may be different from the one used during development. Recovery after an interruption can matter as much as the ideal path. A slice should therefore test startup, restart, failure recovery, and shutdown, not only the playable middle.
I create a small platform matrix before greenlighting production. It lists target device classes, input methods, performance targets, display assumptions, platform services, and known failure modes. I then identify which combinations are mandatory for the slice. This prevents “supports controller” from meaning that one developer connected one controller once.
Build automation should enter the process here. The team does not need an elaborate release pipeline, but it should be possible to produce a clean version from source control without relying on undocumented local files. Test that version outside the development environment. Confirm scenes, configuration, shaders, addressable content, permissions, and persistent data behavior.
A delivery constraint discovered during the slice is good news. It may be frustrating, but it is cheaper than discovering the same constraint after dozens of levels, characters, or client milestones depend on the wrong assumption.
Which Production Gates Prevent Scope Creep?
Scope creep thrives when a slice has no exit criteria. Every new idea can be described as necessary for “proper evaluation,” and the experiment quietly becomes full production. I prevent that by defining gates before the implementation backlog expands.
Gate zero is a written hypothesis. It states the target player, core loop, riskiest assumptions, target platforms, and the evidence required for a decision. Gate one is functional proof. The complete loop works with temporary presentation and can be played from start to finish. Gate two is representative quality. The chosen path reaches the intended standard for feel, readability, art, audio, and performance. Gate three is repeatability. Another piece of content can be assembled through the documented pipeline without exceptional intervention.
Each gate receives a green, yellow, or red result. Green means the evidence supports the assumption. Yellow means the result is promising but a bounded follow-up is required. Red means the current approach failed. A yellow item must include a specific question, owner, and time limit. Otherwise, yellow becomes a polite word for permanent uncertainty.
I also freeze a “not in slice” list. It might contain secondary game modes, broad progression, cosmetic variety, advanced settings, optional narrative content, or final storefront integration. The exact list changes by project, but writing it down protects the slice from attractive distractions. New requests must either replace existing work or wait for the production decision.
In the 2025 and 2026 market, teams face intense discoverability pressure and may feel compelled to prepare trailers, festivals, store pages, and community beats as early as possible. Those activities can be valuable, but marketing readiness and production readiness are different gates. A clip can generate attention while the content pipeline remains unsustainable. Do not let public enthusiasm erase technical evidence.
A weekly review should focus on resolved assumptions rather than completed tasks. “Implemented inventory UI” reports activity. “Players can equip, compare, and discard items without guidance, and the workflow runs within the performance budget” reports evidence. That distinction keeps the vertical slice aimed at decisions instead of velocity theater.
The best gate is one the team is genuinely willing to fail. If every possible outcome leads automatically to full production, the slice was never an experiment. It was only a delayed announcement.
When Should a Prototype Be Greenlit, Paused, or Cancelled?
I evaluate the completed slice across four dimensions: player value, technical viability, production repeatability, and product clarity. A greenlight requires credible evidence in all four. Strong game feel cannot compensate for a content pipeline that takes heroic effort. Reliable technology cannot compensate for players misunderstanding the central activity. A clear pitch cannot compensate for a loop that becomes dull after the first attempt.
Pausing is appropriate when the concept remains promising but a specific external dependency or missing capability blocks an honest decision. The pause should have a written restart condition. “Wait until we have better art” is vague. “Resume after validating whether the target device can sustain the representative scene within the chosen frame budget” is actionable. Without a restart condition, paused projects become invisible commitments that continue consuming attention.
Cancellation is the correct result when a core assumption fails and the affordable alternatives no longer support the original product. That does not make the slice wasted work. It purchased information before the team multiplied the mistake. Useful tools, shaders, interaction experiments, and pipeline knowledge can survive, but they should be extracted deliberately rather than used to justify continuing the wrong game.
Publishing Unity products such as Touch Camera PRO, Assets Manager, City Builder, and Level Designer has reinforced the difference between a one-off solution and a repeatable system. Reuse requires clean boundaries, documentation, predictable setup, and testing outside the original scene. A game vertical slice does not need Asset Store-level packaging, but it should show that the team can reproduce its success without relying on the exact people and conditions that created the first version.
If the project is greenlit, I do not immediately expand every dimension. I turn the slice into a production template, identify remaining yellow risks, estimate content from observed throughput, and schedule another review after the first repeated content set. The slice provides evidence, not immunity from future mistakes.
My strongest advice is to make the decision explicit. Write a short greenlight, pause, or cancellation memo that cites the evidence and unresolved risks. Months later, that document will be more valuable than anyone’s memory of how exciting the demo felt. Good game development is creative, but it is also the discipline of paying for uncertainty in the smallest responsible increments.
Top comments (0)