Not Just a Piece of Cake: Why Vertical Slices Fall Flat in Game Development

In the complex world of game development, creating a successful game is far from a piece of cake. It requires a delicate balance of innovation, quality, and timeliness. As developers, we navigate the long road from concept to launch, planning key milestones to evaluate progress along the way. This journey often involves securing funding or attracting publishers, making certain milestones crucial for the project's survival and success. These become make-or-break points for every game. They go by many names depending on the studio (Vertical Slice, MVP, Proof of Concept, First Playable, etc.), so let's call this critical milestone the Cornerstone for now.

The Cornerstone Milestone: A Crucial Turning Point

Typically the need for a Cornerstone Milestone is triggered by a development critical

event:

• Convincing a publisher/funding partner to join

• Gain support from existing stakeholders to allow continued development

• Building confidence on the team and solidifying understanding of the vision

It also typically marks the point that a project moves from pre-production into full production. Traditionally, the game industry has borrowed concepts from product development like the Vertical Slice (VS) or Minimum Viable Product (MVP) to solve for those purposes. However, these approaches have consistently fallen short for this stage of game development, highlighting a crucial need for change.

To understand why these frameworks fail, let's examine the core goals of the Cornerstone milestone:

1. Validate the game’s concept hypotheses

2. Demonstrate value to stakeholders as quickly as possible

3. Understanding and controlling development cost in the production phase

At first glance, Vertical Slices and MVPs seem to align with these goals. It’s easy to see why we adopted them. So why do they fall flat?

The Problem with Vertical Slices and MVPs in Game Development

The issue lies in the nature of creative work itself. For many game developers "Minimum viable" in MVP often translates to "nearly complete". Handing over a less than fully realized experience for feedback feels like it is far below the minimum. 

A Vertical Slice is expected to deliver "a complete slice of the experience", which necessitates polished quality assets and features. Polish requires full development pipelines to be in place, which doesn’t happen on AAA games for years.

This mindset creates several problems:

1. Unrealistic Timelines: Producing a polished, shippable slice can take years, delaying crucial feedback and potential pivots.

2. Resource Intensive: Creating a "complete" experience, even for a small portion of a game, requires teams to ramp up to a larger, less nimble size earlier in development, exacerbating scaling issues like communication and putting strain on the budget too early.

3. Limited Flexibility: Once a polished MVP exists, teams may resist significant changes, even when feedback suggests they're necessary.

Clearly, we need new tools for these make-or-break moments in the lifecycle of our games.

The Shape of the Cornerstone

The audience for your Cornerstone should be what determines the form that it takes. Let’s evaluate two of the most critical and common audiences for these types of milestones:

• High trust and high level of experience in evaluating games during early development

• Low trust and/or little experience evaluating in progress games

To be successful, it is critical that you both understand your audience and you have chosen a single primary audience to focus on. Too many game teams try to accomplish it all and end up wasting valuable time and eventually failing. If your goal is to make everyone happy, no one will be. Your team will resort to crunch and the Cornerstone will fail.

To better understand our needs, let's take a closer look at what the challenges are for each of these audiences and then look at tools to solve them. We’ll tackle the easy one first.

A High Trust and High Experience Audience

This is the path for teams that have a highly receptive and knowledgeable group as their primary audience. Both high trust and high experience must be qualities they possess to use this path.

Path qualifiers:

• Trust in the development team to realize the vision

  • The development team has completed similar work successfully in the recent past

  • The development team has already established trust on this project through previous deliverables

• Experience seeing and evaluating games at early development stages

  • The audience have been developers on similar games in the past

  • The audience are experts at evaluating early builds and have a history of successfully working with development teams from this stage of development

  • The build will not go above the experienced audience to a less experienced one

If these are all true, we can choose a path that minimizes work that won’t be in the final release. This path also allows us to keep a smaller team for longer in the development cycle.

To address these constraints, let’s evaluate a new project milestone: the Minimum Usable Product (MUP).

What is the MUP?

The MUP has a few key focuses that differentiate it from an MVP or VS milestone:

1. Emphasis on Usability, Not Perfection: Work doesn't need to be finished or polished, it needs to be usable and ready for feedback.

2. Earlier Vision Realization: Teams can grasp the true nature of their creation much sooner.

3. Reduced Stress: Removing the pressure for perfection allows more focus on establishing the core gameplay elements and mechanics.

4. Clear Expectations: Using the term “Usable” instead of “Viable” aligns both teams and stakeholders to understand they're viewing an early, unfinished version.

5. Faster Iteration: Lower initial presentation standards enable quicker feedback and more opportunities for that feedback to be incorporated into future iteration.

6. Improved Resource Allocation: Focus on core functionality over polish in early stages allows the team to ramp slower, reducing the budget burn at early development stages.

7. Better Stakeholder Engagement: Regular, early MUP presentations keep stakeholders involved and informed.

Let’s compare MUP against the key characteristics of the MVP and VS before we move on.

	MUP (Minimum usable Product)	MVP (Minimum Viable Product)	Vertical Slice
Core Gameplay	Functional Core Loop A playable version of the primary gameplay mechanic May use placeholders or simplified versions of planned features Should demonstrate the basic flow of the game	Polished Core Loop Segment Fully implemented primary gameplay mechanic Refined and balanced to represent the game’s quality Often includes secondary mechanics that support the core loop	Fully Polished Gameplay Segment A complete, playable level or mission that showcases core mechanics All intended gameplay systems fully implemented and interconnected Balanced and tuned to represent final game quality Refined difficulty curve within the slice
User Interface (UI/UX)	Basic User Interface Rudimentary menus and HUD elements Functional but not necessarily aesthetically pleasing Includes essential information and controls to navigate the game	Completed User Interface Fully designed and implemented critical menus and HUD for the showcased segment Polished visual design that represents the game's aesthetic Completed animations and transitions	Polished User Interface and Experience Fully designed and implemented UI for the showcased segment Polished visual design that represents the final game's aesthetic Polished animations and transitions
Art	Placeholder Art and Assets Simple or placeholder representations of characters, environments, and objects Can include basic models or even colored shapes Conveys the general idea without investing in final art production	High-Fidelity Visuals High-quality models, textures, and animations for characters and environments Represents the intended visual style and quality of the entire game May include special effects and particle systems	Final-Quality Art Assets Final or near-final quality art assets for characters, environments, and objects Represents the visual fidelity of the final game Fully implemented special effects, lighting, and post-processing
Game Systems	Foundational Systems Basic implementations of key game systems (e.g., inventory, scoring, character progression) May not include all planned features but should showcase the core systems	Comprehensive Game Systems Fully implemented key systems (e.g., inventory, crafting, skill trees) Balanced and tested to ensure they work as intended in the vision	Final Game Systems All systems in the showcased segment fully implemented   Balanced and tested to ensure they work as intended in the final game
Playable Content	Sample Content A small selection of in-progress level(s), characters, or scenarios Enough to demonstrate variety and potential without creating the full content for the selected section	Representative Content A selection of completed levels or scenarios Showcases the variety and depth planned for the full game	Complete Feature Set A selection of polished levels or scenarios All features planned for the final game are present in some form May need to include systems not fully used in the slice but implemented to show their integration
Technical Framework	Core Technical Framework Basic implementation of essential technical features (e.g., saving/loading, input handling) Performant enough to be evaluated Groundwork for future expansion and optimization	Robust Technical Framework Fully implemented key technical features Optimized performance for target platform	Technical Optimization Final-quality implemented key technical features Framerate and performance tuned to target specifications Stability and bug-fixing to near-shippable quality
Audio	Placeholder Audio Basic sound effects and background music Can use stock sounds or simplified versions of planned audio Placeholder or TTS VO	Professional Audio High-quality sound effects and music Voice acting for key characters or moments Adaptive audio systems that respond to gameplay	Polished Audio Final quality sound effects, music, and ambient audio Fully Implemented audio systems (e.g., dynamic music, 3D audio positioning) Voice acting for all characters in the slice
Quality Assurance	Stability Focused Simple debug menus or shortcuts Allows for quick testing and demonstration of various game states Stability testing to reduce crashes and impactful performance issues	Performance Focused Thoroughly tested for bugs and balance issues Optimized for performance on target platforms Time in the schedule for multiple passes from QA after content has been locked	Polish Focused Thoroughly tested for bugs and balance issues Optimized for performance on target platforms Pri 1-3 bugs resolved. Time in the schedule for multiple passes from QA after content has been locked
Narrative	Minimal Narrative Overview of game's story and world Placeholder assets for narrative scenes Minimal lore and world-building elements	Narrative Elements Introduction to the game's story and world Fully voiced and animated cutscenes Implemented lore and world-building elements	Polished Narrative Full implementation of story elements for the chosen segment Final-quality voice acting Cutscenes or in-game storytelling mechanics fully realized
Monetization (for applicable games)	Placeholder Placeholder in-game stores or microtransactions Daily rewards or other retention mechanics Social features or leaderboards	Basic Implementation Implemented in-game stores or microtransactions Fully implemented retention mechanics (e.g., Daily rewards) Implemented social features or leaderboards	Polished Monetization and Retention Polished and balanced in-game stores or microtransactions Final-quality economy funnel features implemented Final-quality social features or leaderboards
Marketing	Unsupported Opportunity for Marketing to play and give feedback early in the project Unblocks Marketing to begin planning for feature or content requests	Early Support Screenshots and trailers that represent final game quality Feature descriptions and artwork	Marketing-Ready Build can be used to create high-quality trailers and screenshots Polished enough to show to press or potential publishers
Documentation	Filling in the blanks Clear explanations of what is and isn't included in the MUP Notes on planned features and how current placeholders relate to the final vision	Onboarding and support Player tutorials to support onboarding outside of the selected gameplay Detailed design documents for further development	Feedback Supporting information to provide the targeted experience (e.g., Narrative onboarding) Detailed design documents for further development

As we can see, the MUP is much better suited to early development stages. This tool allows teams to achieve their goal and continue to build trust with their stakeholders over time.

Implementing MUP in Your Development Process

To adopt the MUP approach successfully, consider these strategies:

1. Define Clear Goals: Establish what "usable" means for your specific project.

2. Prioritize Functionality Over Aesthetics: Focus on making features work before making them look good.

3. Regular Feedback Sessions: Schedule frequent playtests and feedback rounds.

4. Embrace Iteration: Be prepared for significant changes based on feedback.

A Low Trust and/or Low Experience Audience

Now that we’ve reviewed the high trust, high experience crowd, let's talk about a much more common audience that has either a low level of experience at evaluating and providing valuable feedback to early development builds or an audience that has not yet built trust with your development team. If either of these are true, the MUP won’t lead to success. Instead, we need to look at a different tool.

An Infamous Solution

Let’s take a moment to reframe our perspective and review our constraints to pass this Cornerstone Milestone.

• This experience must be early enough in development to allow for significant pivots and the incorporation of feedback from critical stakeholders

• The experience needs to be high enough quality for non-developers to realize the vision of the game

• A successful Cornerstone is required to ramp up to the resources that will allow the team to create the final quality features and content for the game

• Without this Cornerstone, development towards realizing the vision will not be possible

Looking back on our tools, MUP, MVP, and VS don’t meet these requirements. 

For projects requiring early vision realization with an audience that needs to build trust and provide quality feedback on the vision, let’s consider the often-maligned demo as a tool to accomplish our goals. 

The game development community mostly dislikes early, stakeholder-focused demos because they require work that won't ship with the final game. This is very understandable. These features and assets need to show a potential future version of the game so early in the development process that it requires work to be completed before pipelines are solidified, usually causing significant revisions.

Instead of considering this work “throw away” we should look at it as necessary work required for iteration. It isn't a waste if it moves the project forward. But the risk of real waste is extremely high. Demos can offer spin out of control without a very clear outline and prioritization. A demo by nature should be as small as possible while still conveying it’s message effectively.

What is a Stakeholder Demo?

The Stakeholder Demo has a few key focuses that set it apart from others like Marketing or Trade Show Demos:

1. Small and Mighty: As small and short of an experience as possible that communicates the vision of the game

2. Emphasis on experience, not perfection: A stakeholder audience does not require a perfect experience. Minor inconveniences or breaks from immersion will not sink the milestone.

3. Reduced Stress through clear expectations: Knowing the specific audience and purpose allows teams to focus on the critical aspects of the experience.

4. Time Controlled: There is a clear beginning and end to a Stakeholder Demo development cycle. Once that time is over, it is no longer a focus.

5. Earlier Vision Realization: Teams can grasp the true nature of their creation much sooner at a final stage and make corrections based on learnings along the way.

Implementing a Stakeholder Demo

To integrate a Stakeholder Demo, consider these strategies:

1. Be Aggressively Small: Each moment working on a Demo is a potential for waste. Our aim should be to thread the needle and only create what is necessary to accomplish the goals of the milestone.

2. Transparency and Clarity: Clearly outlining the purpose and goals to the development team is critical. Without context, a demo can feel like a sisyphean exercise.

3. Prioritize Experience Over All: The feel is the most important part. Hacks and behind the scenes tricks are sometimes the best tools if they are quick and easily replaceable.

4. Regular Feedback Sessions: Schedule frequent playtests and feedback rounds.

5. Embrace Iteration: Prepare the team for significant change after receiving feedback. Celebrate the success of their work in getting to the feedback you receive this early in the process.

Challenges of Implementation

Implementing a major change like the one we’ve explored here is always going to encounter some form of resistance and require expectation setting. We will need to adopt a two pronged approach, one for the development team and another for the stakeholder audience.

Let’s tackle the stakeholder audience first since they are the make-or-break lynchpin in this scenario. The first step is, of course, understanding your audience properly.

• Interview your stakeholder audience

  • Understand the stakeholder’s constraints and goals

  • Determine the reach of your audience. Is this staying with a small group or going wide within their organization?

• Propose the business case

  • Highlight the problems with the current process and show how the new process will address them

  • Focus on long-term benefits while acknowledging short-term challenges

  • Quantify the potential benefits using data and metrics

• Address risks and concerns

  • Anticipate the problems your stakeholder audience will encounter

  • Outline mitigation strategies

• Involve the Stakeholder

  • Seek their input and incorporate their ideas where possible

  • Emphasize the increased involvement in the final product this process allows

Be prepared to compromise and find a solution that works for both teams. Stakeholders often work within their own set of constraints.

Implementing this change on a development team will take a similar approach with some key differences. In my experience, game development teams will have two major concerns. Experienced team members will be concerned about creating unpolished work. Many teams have completed high quality work previously in their careers, only for it to be reviewed by an audience that wasn’t prepared or capable of judging the quality of the delivery at that stage of development. If you have already completed your assessment and pitch to the Stakeholder Audience, you will have the information to ease their concerns. This will, of course, require a trusting relationship built with your team.

The secondary concern I commonly see from developers is about their work being wasted. To address this you can have a transparent discussion about the project goals and constraints. Your goal is to come to a decision that everyone understands. Consensus is not the target, understanding the purpose of the proposed solution is. This will allow the team to work toward the goals confidently. To accomplish this level of transparency, we must come prepared.

Preparation for Team Implementation:

• Define clear, specific, realistic goals

• Develop your implementation plan (timeline, resource plans, schedules)

• Communicate the change thoroughly to all team members, explaining benefits and addressing concerns.

• Monitor progress closely and gather feedback regularly

• Be reactive! Make adjustments based on the team’s feedback

• Celebrate the successes and recognize the team’s efforts

Don’t Throw out the VS!

With all this being said, a good Vertical Slice still has a place in game development. It just isn’t appropriate for the turning point of a project from pre-production to production. I have found that Vertical Slices are still a critical milestone for projects as they approach the halfway point of a healthy development cycle. Completing your pre-production properly, without crunching to hobble together something unrealistic will give you the data needed to understand your true timeline on completing the content needed for a true VS or MVP milestone. This could be critical for a game reveal closer to development or a key milestone in the middle of your production phase to garner support and feedback. At that point, the goals of these tools will match your development team’s phase of development.

Conclusion

As the game development industry evolves, so must our approaches to creating and evaluating early-stage products. The shift from Vertical Slices and MVPs as the turning point from pre-production to production to Minimum Usable Products and Stakeholder Demos represents a more realistic and beneficial paradigm for game developers.

By embracing the best fitting tools for the situation, development teams can foster creativity, improve resource allocation, and ultimately create better games through rapid iteration and feedback. 

Remember, game development isn't just a piece of cake—it's a complex recipe that requires the right ingredients and methods. By adopting the right approach, we can ensure that our Cornerstone milestones truly support and enhance the development process, rather than becoming obstacles to overcome.