Jan 2015: Early Access the Platforms Missed Opportunity
Note to the reader: This is something I wrote up for my Wordpress Blog back in 2015. My move to Medium was an effort to get away from having to manage/host/worry about that damn WP Blog. However, I did not want to lose my occasional ramblings about my field.
Disclaimer: It should be noted that these are my personal musings and reflections, and do not reflect the official stance on design for any project I am associated with, nor the official position of my employer.
Full disclosure: I have used the Early Access model to distribute a title.
Now, I do spend a lot of time playing — promoting — discussing other Early Access titles on Steam (eg: The Long Dark, Project Zomboid, Wasteland 2, etc). So take this tirade as having very little to do with the catalog of Early Access titles, and more specifically to do with the program and how it is managed by Valve.
It was always my understanding that the intent of Early Access was to give consumers the option to gain access to your titles development as early as possible. Think something along the lines of your first submission to a publisher. In this way, the Early Access consumers play the role of the traditional publisher and gain access to your milestone submissions (or interim builds) as you progress through your development cycle. However, without any clear definition on what and how you enter the Early Access program, the consumers are left with loose terminology and definitions of the state of a project.
No one can fault the end user for their frustration with most Early Access projects. The “Alpha” term gets thrown around fairly liberally, and without any uniform definition. Even though Valve has taken steps recently to lay down some more concrete base rules for use of the Early Access model, they still have not made any public strides in addressing the elephant in the room. Without regard to a titles specific publishing model — the intent, and practicality of Early Access use means like it or not, your active user base during this phase -will- have a large impact on the ongoing design of your project.
– Users who have access to your builds will provide (intentionally or not) near instant feedback on the mechanics and systems of said builds.
— This data -will- make it to your designers, your stand ups, your scrums, and so on. If you’re doing Early Access right, this will evolve your game in ways the traditional method would not.
— Early Access titles live and die by the word of mouth between your users and your prospective future users (Early Access, and Post — Early Access targeted users)
Get Hicks’s stories in your inbox
Join Medium for free to get updates from this writer.
These points just further what I’ve mentioned above — your Early Access consumers should be treated (when applicable) in the same fashion you would treat your publisher. They should know the “state” of your projects development, and the overall progression through your intended design (via your original G.D.D.) against your milestone dates, or goals. With a traditional publisher, you have a bit more leeway on how this is communicated. You can obviously assume they are familiar with the standard software development cycle, its structures, risks, and so on. With the Early Access base you have to assume you are targeting the lowest common denominator with your communications, milestone deliverables and so on.
However, even with an ideal world in which all Early Access projects do this — you still run up against the elephant in the room (previously mentioned). While some terminology is shared across all game developers, not all of us will end up using these terms or goals in the same unified way, at least not without an enforced structure. Developer-A will use terminology like “Alpha” or “Beta” one way, while Developer-B might use them in a completely different way. Not to mention the same terminology tossed around outside the Early Access market for things post Release-Candidate phase for balancing, and volume/load testing just prior to mastering/ZBR milestones at the end of a projects development cycle.
Users end up confused, not understanding why one project in “Alpha” is earlier on than another, or why one title only spent a few months in Early Access, while yet another spent twice as long within the Early Access umbrella (scope and size of projects withstanding).
If we are going to continue to use the Early Access model, Valve (or someone with the initiative and platform to support it) needs to step up and lay down guidelines and structure to what Early Access is.
In addition to the already existing Early Access rules (which can be found here) I feel the following steps should be taken to increase consumer understanding of both Early Access, and the software development cycle should be taken:
- Unified milestone definitions: The platform should step in and set down some basic high level project milestones that all Early Access titles must define their current state off of. Projects entering Early Access should clearly define where within these milestones they are upon entering Early Access and what each platform major milestone means for their feature sets.
– First Playable: Users can enter the title and perform basic gameplay functions. Title starts and exits without major crashes, and the G.D.D. for this project is publicly available.
— Alpha: Title framework is present. Core representation of feature framework is present. Gameplay is at a basic level possible, and users can begin to see the foundation of the projects gameplay.
— Code Complete: Core gameplay features are in and functioning, interruptions in gameplay are acceptable — but new systems work has ceased. Focus is now on bugfixing, and content creation for created systems.
— Content Complete: Major content for systems is complete, critical bugfixing is also complete. Polish, and balancing begins.
These are very loose examples of potential Early Access platform milestones, but the key intent is there. Projects can enter Early Access at any state they desire, as long as their current position within the platform milestones is -clearly- communicated. Developer-A could choose to enter Early Access at or near the start of their development, while Developer-B could use Early Access as more of a balancing, and polish opportunity. So long as both developers clearly communicate where their projects are against the platforms own milestone definitions.
- Visibility on projects milestone position -WITHIN- Steam. The store page, and the titles library page should both clearly display where the Early Access title is within the platform milestone definitions. Be it on a progress bar, a thermostat, anything honestly. As long as it is easily visible, and easily update by the developer.
- Increased visibility within Store and Library pages for developer blogs, video updates, etc: Steam already has functionality for developers to release blogs, updates, and announcements. However the visibility is far from where it could be. Everyone participating in Early Access, from Valve all the way to the end user can only benefit from these communications being more eye catching, in your face, and easy to access.
I could go on ranting about this subject for quite awhile, and I might look into the possibility of doing a talk at PAX Dev, or GDC on the future of Early Access and where it can go — it really depends on the interest of it. I speak to a lot of Early Access developers, and I know they’d all be interested in throwing out their two cents. Either way, thanks for reading — leave your comments below.
