Red Ocean — The Opportunity Cost of Starting a New Project
What risks can be assessed before starting a new game project? Stanislav Stankovic draws on his personal experience to answer this question
“A beginning is the time for taking the most delicate care that the balances are correct.” — F. Herbert
As game makers, we want to make games. There is a certain profound feeling of accomplishment from bringing joy to other people. Yet making games is hard. Making good games is even harder.
There are many ways how one can start a new gaming project. You can do it alone. There have been many successful games created entirely by one person. See for example Braid, Stardew Valley, or Cave Story. You can go about it with a certain dose of artistic naivete, conscious or not, and just start making whatever feels good to you.
However, most likely you will be starting a new project as a part of a team, with some sort of strategy aimed at minimizing the risk of failure.
I have seen and been a part of many discussions about how a team should approach starting a new game project. These discussions often touch upon a wide variety of topics, from how to evaluate the potential game ideas and marketability, to development schedules, to the optimal team sizes, etc. These are all valid discussions and certainly worth paying attention to. However, it is sometimes very hard to walk away from these with any actionable conclusions. Sure, there is a multitude of things to try or to avoid, but how do you know what is the right strategy for your team?
At least a part of the problem, it seems to me, comes from the fact that our industry is actually quite diverse. It is diverse especially in terms of the types of game development teams and circumstances in which they operate.
Broadly speaking, the game development teams working on their own projects fall into three big categories:
- Gaming startups fueled by investment money and looking for a secure revenue stream.
- Established independent companies with a portfolio of solidly performing games.
- Teams working within large gaming companies such as EA, Zynga, ActivisionBlizzard, Bethesda, Ubisoft, Tencent, etc.
When embarking on a new game development project, teams from these three categories face fundamentally different challenges. Surprisingly, this difference is not always entirely clear even to people with extensive industry experience.
KEY IDEA: If you are part of a startup, the biggest risk you are facing is releasing a game that will not perform.
As always I am writing this from the perspective of launching a game as a service, where the live service of the game is supposed to keep bringing revenue for a prolonged period of time.
Teams in startups usually do not have many people from the outside insisting on particular design solutions. They operate on tight budgets and their survival depends upon the game hitting certain key performance indicators (KPIs), be it retention numbers to justify additional investment in user acquisition or monetization as a direct source of the revenue. During the development phase, external stakeholders will focus on the team hitting the schedule and after launching the game they will focus on its KPIs.
A limited runway is not a problem if the airplane you are launching actually takes off into the sky. But, if your product stalls, crashes, and burns, the fire can easily swallow the whole team. Investment fuel has been spent on something that flew like a brick.
Teams working within large companies operate in a different world. Typically, such teams need to get organizational support in order to even launch their game. Organizations are not monolithic. They have a complex internal structure defined by departments with different functions and operating with different sets of goals. The team effectively needs to get buy-in from a shifting set of different operators. In general, all these people will try to minimize the risk to their own small and carefully demarcated part of the organization. Their interests often do not align with the best interests of the team and the project.
This can create an environment that pushes projects into development limbo.
In this case, the task of the project leadership is not so much to deliver a great product but to convince the rest of the organization that their product is worthy of their support.
Big companies offer stability. They can take punches. Teams working from within can usually afford a mediocre launch. What they can’t afford is getting stuck in production hell.
KEY IDEA: If you are a part of a big established company, the biggest risk is that you will end up not releasing the game at all!
This is counterintuitive. Being a part of a large company should, in theory, put at your disposal enough resources, manpower, and know-how to complete your project with less risk than a small startup team can have.
This difference stems from the way these two types of entities perceive the opportunity cost.
By definition, the opportunity cost is the difference in profit that would be incurred if a business entity chooses one course of action instead of another.
For a startup that is entirely focused on a single project, the choice is simple, either release the game that you are making or don’t. The opportunity cost of not releasing the game is equal to any profit the game would make plus the development investment that was already made. No matter how small, this profit is likely to be bigger than zero. Thus, the odds are in favor of releasing the game no matter for its quality or revenue potential.
A big multi-studio company typically has the capacity to develop several projects at the same time. It doesn’t have infinite resources to invest in marketing, user acquisition, live service, etc., and it tries to allocate them in the best way. The opportunity cost calculation can easily become a comparison between a real project, imperfect as it is, and the idealized imaginary better game that they could be making.
Any concrete, but imperfect, project will always lose this comparison with an idealized imaginary game. Concrete projects have concrete weaknesses that can be judged, examined, and discussed. Imaginary games are by definition utopian and perfect. They are a product of wishful thinking, and usually have a form of vague ideas and lofty goals.
I have seen this happen over and over again in at least two large companies I have been working for. Projects will sometimes drag on for years before ultimately being canceled, taking with them the sunk cost of the development. Launching a game that would perform even badly would be preferable from a financial standpoint, simply because it would stand a chance of recouping just a part of the initial investment. I am not even going to mention the devastating effect that being stuck in a development limbo can have on the psyche of the creative team.
Working in an established, but independent company, seems to me, can be the sweet spot. My perception can be clouded by the fact that I have never worked for such a team. I might not know all the perils of working in such an environment.
The catch here is that the line between categories can be blurred. The company might have a solid portfolio of well-performing games, but a risky new project can bring it in the same financial danger as if it was a startup. On the other hand, a sufficiently large independent company will inevitably start behaving like a big corporation. This happens as soon as the mid-management layer becomes thick enough to obfuscate the responsibility of decision-making.
Links
- Definition of Opportunity Cost at Investopedia
- List of games made by (almost) a single person
- Opinion: Starting a new game project — ask the hard questions
—
Disclaimer: From time to time, we invite guest bloggers to post on our site. Although ironSource reviews the content for accuracy and relevance to our audience, the views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of IronSource or any subsidiary or affiliate of the same. The accuracy, completeness and validity of any statements made within each article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to Stanislav Stankovic and any responsibility related to alleged infringement of intellectual property rights remains with them.
