Getting Games Done Part 2: Priorities

Getting Games Done in 2020 Part 2: Priorities

Welcome to part 2 of my “Getting Games Done” article series.

In my previous article, I’ve covered how establishing a routine can help turn your string of unfinished games around and help Getting Games Done. At the end of that article, I left you on a cliffhanger of sorts:

In my next article, I’ll cover how your ‘what’ affects your plan and how to adapt to a development strategy that is consistent with your goals.

Michel Mony

Today, I’d like to start taking a first stab at this all-encompassing question.

Where to Start

Every project starts differently, but before delving into what we’re making, it is important to consider where we’re coming from. Some projects are defined from day one, while others require further experimentation. In certain cases, the developer may feel confident they can pull off the project on their own, or with friends, while in others, it is abundantly clear that additional resources are going to be pooled for the project to be a success.

Consider the table below as a simple expression of the three general starting points a developer might find themselves in bearing in mind that reality is oftentimes not as clear-cut.

Scope is knownScope is unknown
Resource-independentExecutive developmentIterative development
Resource-dependentFundraising developmentThink again

For the purpose of this article, we’re going to define the following items:

ScopeWhether you know the scope of the game, that is, whether you have fully fleshed out the entirety of the mechanics in a GDD, confluence, or other medium, and have the intent to deliver on this vision specifically.
ResourcesThe exhaustive list of everything you may need to complete the project, be it skills / talent (programming, art, audio, etc.) or other (money, time, etc.) and whether these are available to you, or may require external help and support.

If you find yourself mostly depending on external resources and your scope remains undefined, the project is unlikely to lead anywhere, so I’m not going to bother covering this. The other three scenarios, however, deserve a closer look.

Executive Development – A good example of a project where the scope is mostly known, and the developer is mostly resource-independent would be a sequel, reskin or clone to a pre-existing game. Presumably, the developer has some experience (programming namely) and an established vision of what the game should be. 

In practice, few indie developers are ever in this position, so we’re not going to focus on this one for this article.

Iterative Development – Iterative development is the situation in which many lone developers find themselves, particularly programmers. They have the ability to do most of the work (or at least a significant amount) on their own, but often don’t have a fully fleshed out idea. Consider Dwarf Fortress, or even Minecraft, games that started out as constantly-evolving prototypes with very limited art.

There are various advantages to iterative development, such as being able to capture the ‘fun’ when it is encountered (which in games, is almost assuredly by accident) and pivot the game’s scope in favor of making a better game at the detriment of a unified vision. But most importantly perhaps, the advantage of being able to carry the vision forward with limited needs, specifically, with regards to money – possibly the bane of all indies.

Fundraising Development – More often than not, this is the type of projects indies are involved with: They have a very limited ability to carry the project forward before they become resource-dependent, at which point the project typically dies. 

Because this problem is so prevalent among developers, this is the case we’ll focus on the most. If you find yourselves in a different situation, feel free to raise any question, I’ll be happy to cover in subsequent articles, particularly anything pertaining to the Iterative development described above.

A Project Like Any Other

In Executive development, logic dictates that the developer is pursuing a risk mitigation strategy, that is, to start development with the higher risk items first, so that confidence in the ability to complete the project increases quickly early on. For example, if one was to make a clone of an MMOFPS such as Planetside 2, the first step would logically be to try and demonstrate one’s ability to have 100+ players play concurrently in the same match, a feat not so easily achieved. Regardless of the complexity of most other mechanics of the game, achieving this first is almost assuredly going to prove instrumental in decreasing the remaining risks. In other words, if you can get 100+ players into a single room and moving about, even without any shooting or gameplay proper, you’re off to a much better start than if you had built the menus instead simply because every feature that remains on the backlog is strictly easier to pull off than what you’ve done, and thus, is de facto proven to be achievable. 

Makes sense right? How could you possibly fail after that? It will just be a grind, but the game will happen (not without its share of Murphy’s Law, but that’s a topic for another day).

The core problem with Fundraising development projects is that the developer in charge typically makes a critical assumption: they believe it is a project like any other. Unfortunately, while the nature of the scope (known or unknown) is within a developer’s controls, the resource-dependency isn’t, and that dependency is the key item that changes everything. This becomes particularly critical when trying to determine priorities early in development, and where to allocate the limited resources a developer actually has at their disposal.

In Fundraising development, the interests of the project need to take a backseat to the interest of whoever can provide the resources they need, and this is a critical distinction. In other words, tackling risk is strictly inferior to demonstrating value to prospect investors, or willing team members (which, for the purpose of this article, we’ll also call investors due to the fact they do invest time in the project).

What I mean by taking a backseat to the interests of the investor is that the developer’s role shifts from working on what would typically make sense, and instead, must demonstrate intent. Unlike a properly-developed game where everything you see is equally supported by sturdy ‘under-the-hood’ infrastructure, faking it is not only accepted, it should be what is being pursued. The developer has to think far more creatively about how they’re going to evoke the key selling points of their game without actually having 80% of the project built, and this is always a challenge. There’s a lot of ways to go about demonstrating intent for each key feature, and typically, this varies from game to game based on its own individual unique selling points (USPs). 

The bottom-line is that Fundraising development is unlike any other format. This key distinction is why, oftentimes, developers from the AAA scene fare rather poorly in the indie realm (unless they bring along resource-independence) and why indie-hardened developers tend to have a somewhat alienating approach to development compared to the industry (often out of pure necessity).

It requires us to think more about the opportunity we’re presenting to investors than the needs of the project.

Identifying The Opportunity

There is a general misconception around first-time developers with regards to investment in general (which I’ll address at length in a future article). Although fundraising itself is not within the scope of this article it is nonetheless important to make a radical distinction about the opportunity the developer is presenting as it will define the focus of development.

As a developer, there are two different paths one can take to seek funding and/or resources to facilitate the development of their projects. The key component here is understanding whether what you’re presenting is your company or your project.

Under most situations, indies tend to be selling their project. There are exceptions of course, but since this is an introduction, I’m going to assume that your intent is to present the project to potential investors and have them focus on this particular project.

As a first time developer, what you’re really asking a potential investor is to gamble on latent value: you’ve never released a game, your game is probably not that far along, and you’re likely ‘nobodies’, at least insofar as the game industry is concerned. If any of the previous statements are incorrect, then you have extra ammunition – hooray! – they might improve your chances if used right, but don’t make the costly mistake of assuming any of the things you may have done before is a guarantee of success. Remember that most of the developers that attain any level of success with a game tend to fail on the next one.

When investors are presented projects, they are always going to try to answer three key questions:

A – Is it the right project?

B – Is it the right deal?

C – Is it the right team?

Let’s break that down, shall we.

A – Is it the right project?

Is it a project worth making, can it attain a sufficient level of success, is it in-line with their portfolio (if they’re a publisher), etc. This is assessing the merit of the game itself, and how valuable it may be to the investor and to the market. This is typically where indies fare the best. 

Developers often focus on passion projects stemming from the existence (and success) of previous games that have demonstrated there’s a market and an opportunity, but they also often neglect to connect the dots for the investor and show them how it is relevant to them, specifically. This warrants its own article, centered around branding and the ‘narrative’ behind the game (which is also relevant when contacting the press for example) so I’m not going to expand much further for now.

B – Is it the right deal?

So it is the right project, but is it the right deal? What’s the budget ask? Can they reasonably make their money back and then some? What sort of evidence do you have of its profitability beyond the infamous SteamSpy?

But beyond that, is it aligned with their organisation’s goals? If they’re a hands-off publisher for example, have you come along with needs in localization, marketing, and other services that another publisher may be best-suited for? The more you can tie your needs with their services and interests, the better your chances will be. 

This is, sadly, a question most indies answer clumsily. The reason is simple: most developers look at it as their need for resources (possibly a “money problem” if I’m to quote Jason Della Rocca) and reasonably try to pitch it as an opportunity for them (getting said resources). But a proper pitch should include why this is an opportunity for the investor, in fact, this should be the only thing being discussed. You already know why you need it, and why it’s good to you, all they care about is why it’s good for them.

On that note, there is a fine line between being pragmatic and selling the dream. Given my varied experience with the industry and investors, I’d err on the side of pragmaticism: It might get fewer people excited, but if your plan stands their scrutiny, you improve your odds more so than if you sell them on an impossible project to make, or impossible sales figures to attain. Remember that, ultimately, at least two people are going to look at your project (even if they inhabit the same brain): the one that cares about the product, and the one that cares about the numbers. You have to satisfy both.

C – Is it the right team?

That can be a very tough one to tackle. For most first-timers, there’s very little evidence that you can deliver on your promises, and no amount of ‘trust me’ is going to convince them – rightfully so. There are a lot of ways you can improve your chances, such as having advisors from the industry, which have agreed to be named, or tying related activities you’ve been involved with to improve your profile, such as organizing events.

One of the best ‘confidence’ pitches I’ve ever heard dates back when I was working retail (a lifetime ago) and had one of the sales guy, a new police academy recruit, respond to his boss that had refused him access to the safe room: “The government trusts me with a loaded gun, and you’re not going to let me in?”. You see, JC leveraged the severe rigorous vetting process he had undergone from the government to pry open a gate that would’ve otherwise remained shut, regardless of his actual relevant skills. Believing a team can achieve on a project is part science, and part gut, and there’s always a means of coming from the sidelines and making them understand that you intend to see things through without making empty promises. Now you just have to do it without alienating them in the process: some crowds respond poorly to someone that comes across as cocky, so there is one instance where meeting face-to-face as an event can help you steer the pitch.

Demonstrating Intent

So we know we’re pitching a project, and we have a broad sense of the types of investors we’re after. We know what’s important to them, and we have a fair grasp of what’s important about the game. The next step is not an exact science, but we’ve put together enough information to make it a worthwhile process. 

What’s important is to demonstrate intent, sure, but in correlation with what’s important to them. If you’re pitching TellTale Games, you’d probably best focus on the narrative elements of your game and put that at the forefront. Note that I’ve specifically taken this as an example because you couldn’t pitch them as the organization is defunct now. 

The important item to take away from this is that every publisher has things they’re looking for in a game, and don’t be afraid to ask them outright, many will be rather candid about it (if they’re not tired of being asked and have them already pinned on a section of their website).

This, in turn, will help you define priorities. In putting together a demo version of your game with your limited resources, you’ll know which features to focus on. I’m certainly not trying to downplay it as something trivial, in fact, it can be one of the hardest things you’ll do throughout the entire game, where any mistake may cost you the ability to get funded (no pressure at all). In essence, this is the key step in optimizing what you should work on to improve the odds of securing investment at the other end.

Unfortunately, demonstrating intent has more to do with experience than theory, and there aren’t any other ‘rules’ I could shoehorn into this article because it has more to do with gut, and can be outright subjective. But if you’ve followed the above, you should be better-prepared to put together your priorities for the build, and possibly to start identifying how you’ll frame your pitch deck!


In my next article, I’d like to cover the ‘money’ issue, and also tell you why it’s not the devil that corrupts game design, at least, as long as you don’t let it.

About the Author

With over a decade of professional experience in the industry, and 100+ projects under his belt, Michel Mony founded Cathar Games in 2017, turning his lifelong passion for games into a full-fledged startup. Cathar works on both ambitious projects, and indie co-productions, providing services to aspiring indies on the side to give them a fair chance in this rapidly-changing industry. 

Linkedin contact: https://www.linkedin.com/in/michelmony/

Business inquiries: http://www.cathargames.com/

Leave a Comment