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)
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.
“and the G.D.D. for this project is publicly available”
This kinda sums up this whole post, you’re looking at it way too traditionally, not every game has (or needs) a GDD to use this as an example, and the whole point of Early Access is to be able to break traditional, rigid models of development.
As the statement says, these are loose milestone definitions – by no means what is or should be required.
That said, any title of any decent scope (read: Anything aside from mobile, facebook, etc type titles) -does- need a GDD. Especially a project that does not have traditional publisher oversight. If you don’t put to paper what the scope of your design is, you can and will run rampant with “good ideas” and inspiration. A GDD will, and does serve to focus the development once the greenlight has occurred.
Edit: Also, thanks for the comment 😉
It might be helpful to have a sort of at least somewhat public discussion on specifics of Early Access titles. There are some influential among them (yep, DayZ), affecting not only other games, but also streaming/youtube letsplays. But even though many things about development are being carefully explained, there are always tons of misunderstandings in the community and client is not always right. Which, I imagine, makes it harder to notice the sensible feedback and thus hurts all. So in my opinion, the level of mainstream discussion could be higher, but apart from streamers I dunno who could help that.
I’m entirely a supporter of having a more open discussion on how we can improve the Early Access model. -Definitely-
A am very happy that a prominent name in the games Industry -you- have taken the time to write out this. I have been on the receiving end of the Alpha tag on games both good and bad. I am very much for this as recent encounters have put me off buying Alpha on -ANY- game that is not free alpha. I believe that a few companies use the term Alpha to actually fund the game when it is no where near a playable state, even some that are do not ever make it to full release. I hope that -the powers that be- do look into this further and like how steam is beginning to put some -rules- in place.
Look forward to your talk at PAX should you choose -able- to do one.
We’ll see where this goes. At the least, I’ve talked with the PAX Dev folks about doing an Early Access panel. So – September!
Hi Brian,
really appreciate your deep thoughts on that topic. Steam should definitely improve the Early Access (EA) system by standardizing the way progress of such games is measured. This would “protect” both the developers and the platform owners (e.g., Steam/Valve) from exaggerated/unjustified customer expectations.
I could name several EA games where quite a number of customers refused to read and understand available infos on the development process but instead confronted them with a fair amount of (de facto unjustified) accusations. The reasons for this kind of behaviour are manifold and have most likely the potential to fill a doctoral thesis in psychology *g*. But since I cannot imagine how this climate could possibly have a positive effect on the devs’ mental health as well as the game progress itself, this aspect is in urgent need of improvements.
Game development is a hard and costly business and this alone already provides for a lot of pressure on all the people involved. Now, if it was possible to avoid the above misinformation-based debates and to further constructive communication instead, this would mean huge gains on both sides (customers and developers).
For this reason, I would suggest a so-called “progress page” (PP). It should contain:
– the above mentioned progress score
– information on how this score is composed of
– a list of all the implemented major features and infrastructure work including a brief description (there should be a permalink available for each item)
– the required development time (e.g., approx. in weeks/months) of these features (to document how complex these tasks actually were)
– whether or not a respective feature has already undergone optimization
– a full road map from start to end
Clearly, the latter item should gently “force” developers to devise a game development document (GDD) *prior* to the submission of their game.
This is just an example, but I hope you get the point, i.e., a page which serves as a public authoritative “facts hub”. Forum moderators, developers, supporters and other interested people should be able to link to the PP whenever discussions are based on guesswork but not on facts. You could call it a wiki but I’m rather thinking of something which is more boiled-down, easy to grasp and visually appealing. In practice, if someone on the internet is claiming “no progress has been made in a year”, that PP should be able to output an according summary for either a whole or partial time frame.
Finally, the EA platform itself should provide some insights into phases of game development. “What is an alpha?”, “What is beta?” to make people understand that, for instance, optimizations are usually done in a later phase (beta) and that complaints won’t change this.
PS: Happy New Year 2015! 🙂
Hey Jan,
Sorry for the delay on approval on this, was pretty busy the first few days back in the office. I really appreciate the feedback. I think you hit some important points here.
Brian,
The success of the ‘demon/dark souls’ series should ease your mind a bit on people like hardcore games no?