We all know what beauty is. Dewdrops on roses. An explosive sunset. The Legend of Zelda… To me, the greatest beauty is climbing mountains. At the top of the world, surrounded by alpine lakes and jagged cliffs, time slows and it all feels rapturous, ennobling... sublime.
But in the philosophical field of Aesthetics, well-intentioned folks struggle with a shared definition of beauty. As David Hume put it:
Beauty is no quality in things themselves: It exists merely in the mind which contemplates them (Of the Standard of Taste, 1757)
Even my beloved alpine vistas are up for grabs. To the ancients (and even, some argue, up until a few centuries ago) mountains were disfigurements of the landscape -- dangerous and violent, the domain of gods and monsters.
In game development -- a field in which “beauty” is a complex interplay of form and function -- it takes real effort to define the quality of visual flair, balance, depth, breadth, and overall excitement that a hit game should encompass. By breaking the game into clear components and pointing to other games or media by way of comparison for the aesthetic of each component, the Double Coconut Game Agency goes through a rigorous design process with our clients to set clear expectations for a final delivery.
But when it comes to the Alpha Build, there’s often a lot of mismatched expectations, leading to tough discussions:
The definition of Alpha is similar to below, and often appears as such in our legal agreements:
Alpha is the stage when key gameplay functionality is implemented, and assets are partially finished. A game in alpha is feature complete, that is, the game is playable and contains all the major features. These features may be further revised based on testing and feedback.
But what does this really mean?
Alpha is typically 50% through the development process, so by definition the game should feel half-finished. But which half to focus on and which half to present in a raw, ugly, or undone state?
Just as beauty is in the eye of the beholder, different stakeholders have vastly different definitions of Alpha.
Below is a generalization of various client personas we work with, and their typical assumptions around the Alpha delivery:
The Scrappy Founder
- MVP.. MLP.. ship, learn, fail quick, double down on success.
- Wants to actually put the alpha in front of people.
- What to focus on: Find out in advance what questions they want to answer first, and have the Alpha help answer those questions quickly and with actionable data.
The Big Brand Manager
- Cares most about how their IP or brand is implemented.
- Anything that isn’t perfect reflects poorly on brand quality.
- If using characters, art, or story from a larger brand, get everything looked at and approved and vetted long before showing it higher up the food chain.
- What to Focus On: Make the IP perfect and the centerpiece and everything else shown should be minimal but ‘perfect’ in its final shippable state.
- All business. She has a marketing plan in mind and has hired you to create a product to sell units profitably.
- Cares about shipping on time and in a way that hits all the agreed items that will lead to sales.
- What to Focus On: The task lists and spreadsheet that shows clear progress and on-time and on-budget delivery.
PRO TIP: Bring your QA lead to the meeting to show a test plan and how buttoned-up your production is going.
- Some clients are hard-core game developers on their own; indies or smaller teams who have gotten their game to a certain level but need help with some additional engineering, QA, or art.
- Or the client may just come from a technical background and has hired you to build a fun game atop a new platform or device.
- Whenever the client has a technical background, they usually ‘get’ how the sausage is made and don’t care about sizzle -- they want to bite into some steak.
- What to Focus On: A tech demo showing the most risky tech - multiplayer, tons of sprites animating at a strong frame rate, AI, narrative engine, or whatever else is the toughest thing to pull off.
The Big Shot
- To sloppily attempt a pun, this executive is the prototypical alpha male (even when identifying as female).
- Has 20 minutes (if you’re oh so fortunate) to see the game you are presenting.
- Not into nuance. Cares about how the game looks and feels viscerally, not peeling back layers.
- If anything looks broken or unfinished, he starts to panic and worries the final game will be a buggy mess.
- What to focus on: A beautiful vertical slice with top-notch visual and animation quality -- with one small section working perfectly. Other levels can be half-done, the wider game economy can be a mess, any side menus can be missing, etc. Think of it as a shippable demo of the game that is meant to be awesome for one, quick play period.
PRO TIP: If you must include placeholder art, make it decent and literally write the word PLACEHOLDER on it.
The key isn’t to guess which persona your client is. If fact, the client is often a Game Producer at a Big Publisher and is responsible to balance approvals from all of the above personas -- a thankless diplomatic feat. The only way this can be feasible is to have an early and frank set of discussions, talking through all trade-offs between form and function.
Ultimately, we are big believers in documentation as the highest form of shared communication. Some clients prefer a subset of the Game Design Document indicating exactly what is (and is not) in the Alpha. But usually a chart similar to the below is helpful -- ideally filled out collaboratively during pre-production or playable phases -- before the Alpha phase of work begins.
This is a small example of a chart that can be shared far and wide and used as a checklist for alpha sign off:
| Alpha Target Date: Jan 1, 202X
Target Platform: Android only; Pixel 3
|Scene / Feature||Functionality||Art/ Animations||Polish / Balance / Audio
Call Out What Should NOT Be Ready
|Main Menu||Full; All buttons operational leading to all game sections.||Release-Ready User Interface Art
Basic, placeholder background music and SFX. NOT final music or SFX.
|Battle Scene + Characters||Able to play with 10 (out of the 50 final Enemy Characters for launch) and 2 Heroes (out of the 25 final Hero Characters for launch).
Melee attacks, ranged attacks, and magic attacks working with proper stat additions and deductions.
Expected to be able to execute all attacks and blocks.
|Release-ready sprite art for characters.
Enough frame animation to get sense of characters attacking, shooting missiles or magic, blocking, dodging, being hit, etc.
Simple red “HIT” overlay when hit or yellow “DODGED” overlay etc.
No other animations or visual feedback expected
|Zero Visual Effects
No user feedback.
No narrative / cut-scenes.
Basic, placeholder background music and SFX, non-synched and not procedurally generated.
Character attacks, defenses, and abilities are only balanced enough to show that systems work with basic progression and range, and all key variables implemented. Nowhere close to final balance.
|Multiplayer Mode||Should be able to create an anonymous account and connect and battle with another user directly.||n/a||No matchmaking.
No drop out / back in.
|Levels||One beginner level, one medium level, and one difficult level of the expected 200 levels at launch.
Level 1: 2 Chars, 1 Hero
Level 100: 5 Chars, 2 Heros
Level 190: 10 Characters, 2 Heros
|As needed for characters.||Enough balance to show potential between challenging and basic gameplay; not final balance.|
So let’s make something beautiful together! But first let’s pause and take the effort to articulate what we agree is “beautiful enough” for each major milestone of our epic climb up the mountain.