On milestones
Disclaimer: milestones in the production of F2P mobile titles. Some of the rules of thumb can be utilized in the development of Premium (paid) games in the Console and PC space (timelines are very different).
When I first set out to make a mobile game, I saw videos of Pre-Alpha and Beta gameplay, but for me, raw execution mattered more than anything else. Time has proven that execution without a framework is rudderless. Milestones are more than a process, they are the validation of work and effort within a timeframe, as they can be easily visualized (even if you don’t have a term for them). Time is the most valuable resource, and Milestones in the games industry, help harness it.
“Milestone - Foundations” is part one of a series of four articles that include: prototyping, Alpha & Beta Milestone, and Live Operations. Whether you chose the publishing or self-publishing path, as a solo dev or as part of interconnected cross-functioning teams, there’s always a certain Milestone tied to it all, even if it’s explicitly defined or not.
It is impossible to DO everything - achieving things hastily and well is not sustainable, as every decision involves trade-offs. That’s why knowing what Not to focus on in any particular Milestone, can help your team navigate the volatile field that is the game dev industry.
So you have a great idea about a game
Game development is an artistic endeavor mixed with business and technology - you can’t have one without the other. So when starting out on this artistic and very real journey of skill and character, find long-term people that aren’t afraid to fail. I’d stay away from opportunism, blind planning, and unachievable forecasts that focus on “success stories”. These narratives aren’t as robust, nor as meaningful as staying true and lean. Establish clear internal decision-making processes. Rule-based governance, hierarchies, flat within reason, or anything to avoid infinite discussions with 0 solutions.
Make sure you have a game project that actually makes sense to develop within your budget, without relying on (potential) future investments. If outside parties are interested in investing in your game and team, it means you’ve already done something right.
Be brutally honest about the skill set and level of experience your team possesses. Learning as you go is not something all studios and teams can have the luxury of doing. Everything has a cost: emotional, financial, and time-dependent (the great equalizer).
I believe that individuals working on indie titles like Stardew Valey, Return to Obra Dinn, Vampire Survivors, Cult of the Lamb, and AAA - God of War, Mario + Rabbids Sparks of Hope, X COM 2 - connect personally to the games they develop. Games are a reflection of their creators, their temperament, reasoning, premises, and purpose. The 6 games above, tackle issues, myths, and contexts that spring forth entire universes…and there are hundreds of thousands of games out there (across platforms). What I’m trying to say is - pick to work on a game that feels personal.
Before we begin, a small detour regarding pitching as this isn’t a Milestone. That’s something that teams do from the moment they have some idea popping out in their heads and all the way to release. So start early by setting up the USP (unique selling point), core and meta-game loops, business model, roadmap, costs, and team composition in a visually appealing presentation. Not in the classic sense (lemon stand case), but you’ll sell your games or studio potential to family, friends, journalists, and later on to interested parties at gaming conferences. If you are disciplined, tenacious, and lucky, you’ll be pitching to the global player community and industry.
But I digress… let’s jump into Milestones.
The four-part series uses the following as context and framing: niche markets and target player audiences, with the potential to scale in case of success. In case the game doesn’t perform well, the team presented here can remain sustainable via art production and outsourcing. The aim of Game “X” is to push boundaries with a new concept/narrative/mechanic and there’s Publisher “Y” that’s interested in it.
Contract signing
In particular, I’ll be presenting this milestone from a game developer -> publisher standpoint, but you’ll be signing contracts with platforms, outsourcing studios, and VCs. My go is - be honest, up-front, and diligent. In law, there is the “spirit and letter” rule set. Just the same with contracts. The legal text and its content are responsible for the letter, while the people are accountable for the spirit by operating in good faith and correcting mistakes, as we are error-prone. Read them, question them, and make sure both parties interests and expectations are aligned. I went through many contracts, but they still haven’t prepared me for the uncertainties and complexities of today’s multidimensional, interconnected interactions.
Getting legal counsel, if the budget permits, is highly advisable.
Pre-production: - note teams in AAA projects can spend years in this phase, something that Indies and Mobiles games should definitely NOT do. If you are an indie team, make sure you have the Pitch and Pre-production documentation ready before you quit your jobs and go out on the journey. I didn’t and it bit me hard on the buttocks.
This would be a minimum requirement doc list:
Game Design Document - the living breathing organism of the game that evolves with your team, development milestone. It should reflect what a player experiences in the game. If it’s visual enough it can encompass more than just mechanics
Resource planner - you can make it as financially complex as needed. Simply put, it’s who works on what and how much.
Cover the basics: Art assets creation, Programming (front-end engine scripting, UI, and backend), Game design, and maybe project management (depending on the size of the game). Note in small teams an individual can be part of more than one discipline but don’t over-stretch talent.
Other documents can come as requests from stakeholders, to “see inside the mind” of a team:
Creative Design Document - that presents the artistic direction for your title: Concepts, references, feel and mood of the game
Wireframe - how players navigate through your game, where UI elements are placed
Technical Design Document (TDD) - the world of code, engines, and “how, what, where”
Risks and Mitigation plan - the known risks, unknown risks, and the “unknown unknowns”. Uncertainty and volatility come from the fact you can’t know about all the risks that will appear. I try thinking in asymmetries by trying to position teams in a way where (potential) upsides of the decision taken during development outweigh the downsides.
Avoid an overly bureaucratic documentation culture. Roadmaps and project progress tracking within an Agile mindset and framework are required and welcomed, but always ask to what purpose or end goal?
Separate the internal - used by the team - and the external ones - used by parties you’ll be cooperating with.
This covers the basics, so part II continues with prototypes where we will search for the elussive “fun” factor and build upon it.
Credits: Artwork created by Tanya Timosina
