Your Business Plan For Making Games
Most of the discussion on these forums (rightfully) focuses on making games, in terms of specific projects and in general, but I feel like there is a lot of effort that goes into more business-oriented efforts that surround this, and it is often not discussed. I think this is super risky for those involved - decisions are always based on assumptions that may not be correct (and are often dangerously wrong), and starting any sort of business venture is already pretty risky.
I’m really concerned that for every 1 plan we see posted here (usually asking for something other than feedback), there are 5 or more plans that go unchecked, and generally ultimately fail. Even scarier, some people decide to spend ages making a game without any sort of business plan. This is pretty much a recipe for disaster: making games is super difficult, and a well considered business plan is essential to having even a minimal chance of success.
There is a wealth of experience between the members of this forum, and I know (from personal experience) that this can make a huge difference to the chance of success of your plans.
My hope is that this thread can be a useful place where people can post business plans and get constructive feedback.
Some guidelines:
I’m really concerned that for every 1 plan we see posted here (usually asking for something other than feedback), there are 5 or more plans that go unchecked, and generally ultimately fail. Even scarier, some people decide to spend ages making a game without any sort of business plan. This is pretty much a recipe for disaster: making games is super difficult, and a well considered business plan is essential to having even a minimal chance of success.
There is a wealth of experience between the members of this forum, and I know (from personal experience) that this can make a huge difference to the chance of success of your plans.
My hope is that this thread can be a useful place where people can post business plans and get constructive feedback.
Some guidelines:
- Do not write up a formal business plan. We don't need to see your SWOT analysis or budget predictions, just like we don’t need to know what control scheme you plan to use for a hypothetical game.
- Try and be as specific as possible. Just saying "My friend and I are gonna make a game." is not specific enough to give useful feedback. Erring on the side of more detail is probably better, cause people can skip over things that aren't relevant.
- Be open to criticism. This should go without saying, but you need to be willing to listen to feedback that people are offering.
- Read advice given to others. It takes a long time for people to write considered feedback of plans, so please have a look if things that have been written to others applies to you.
Comments
We started with a team of 3 programmers early in 2014. We knew that it's difficult to make games, and while we were already experienced with programming, we only had some very limited experience making games. So our plan was to make multiple games in the year, learning and iterating as much as possible as we went, hopefully becoming minimally sustainable within the year. For each game, we planned to prototype a bit, select the best one, and then spend about 3 or 4 months to finish it off. That time frame is ridiculously quick, but we figured we could use our programming experience to ruthlessly keep the scope down and focus on games we had the skills to tackle. We had a blanket statement of things to avoid: multiplayer, 3D, narrative- or content-heavy, and some others I've probably forgotten.
After a few months we realised the first game wasn't going to get anything near the revenue we were hoping for, so we decided to re-evaluate our plan. We determined the major flaw in our plan was not prototyping long enough and well enough. So our plan changed to: make playable prototypes until one of them becomes too good to stop working on. We then spent a 10-week period where we released more than a prototype a week.
This was a really rewarding experience - some of those prototypes were more successful than others, and we learnt a lot, but none of them looked promising enough as-is, and we weren’t getting any income. We decided to take on contract work to bring in income, and without going into that unrelated side of things, we now continue to work on prototyping games on a part-time basis. We take advantage of jams and other occasions, and our focus is on enjoying ourselves making prototypes, while looking for something that we can take into production.
We don't have any definitive criteria to evaluate whether to take a prototype into production, but it would have to be quite remarkable - maybe we get some sort of viral following, win an award (we submit some prototypes to awards, especially those that are free), or experienced developers are basically salivating at our prototype. At the moment I'm enjoying the time I get to spend making prototypes, and maybe one day one of them will become something we can make sell and make some money from.
1) Making games for fun, and testing them amongst early adopter gamers (like this and most game development communities) sounds like a good approach.
2) You haven't listed any criteria for what prototypes you will initiate, only the criteria for how you will evaluate the prototypes already made. Do the results of previous prototypes affect what comes afterwards? Is the prototype you work on based on a flip of the coin? Are you looking to develop any particular skills? Are you edging closer to mastering a specific niche in game development?
3) Making prototypes in your spare time when you have presumably a full time job is definitely going to take much longer than your previous approach (of burning through your savings). I'm super glad you're still making games though.
4) Ruthless scoping sounds good in theory, but the market for ruthlessly scoped games is the most competitive (because ruthlessly scoped games are easier and quicker to make). I think making games that you actually can complete is important, as is knowing your limitations, but if you're making very minimalist games as a result that is a choice in style and should be treated as such.
5) I think if I were to write out one of these (which I plan to once we have a new plan) I would have included a bit more information about the team. Beyond being the main resource, the team is going to be a constraint in terms of finding a project that motivates all the team members. Unless the team are all interested in the exact same things? Or unless the team members are pursuing individual projects? Again, this mostly comes down to prototype initiation criteria, which doesn't feature in this plan, but also affects the evaluation of prototypes.
Definitely not trying to say you're on a bad path or you haven't thought this through. I realize there's reasons for all your choices, and that you were trying to be brief. Not sure if I mentioned anything that gave any new perspective (but I thought I'd try in case it helped).
I should maybe expand on this a bit: I think that prototypes should be ruthlessly scoped down, while a complete game's scope should be evaluated on a case-by-case basis, always based on some metric from the prototype (such as user feedback).
As I give it a bit more thought, I suppose it depends on how much I'm willing to invest into a prototype before it's playable and I can get feedback. So I guess the real criteria for determining prototype scope is TTP (time to playable) and how that can be minimized.
I do agree this is a limiting choice, and honestly I hadn't thought about this so much, but I wonder if an alternative approach would work for a small team without pretty substantial financial backing (which we don't currently have).
Great point, I completely agree that the team is a critical part of the process. We've found that, at least during the initial prototyping phase, it's most efficient if you can work on projects on a mostly individual basis, with the rest of the team acting as readily-available advisers. At the point when/if we decide to take a prototype further as a team, we will consider the team element more thoroughly and how that affects the project and its scope. It might even mean that we decide not to take a prototype further, or try do it with a subset of the team.
That said, I think the team culture/dynamics, including how well the team communicates, is much more important than the specific project. It certainly helps if there is overlap in terms of what you'd enjoy and be good at working on, but I don't think it's essential.
You've certainly given me some things to think about, and I'd be super interested to see your plan once you have one :)
Major Success / Risk factors:
1. Resources
2. Team
3. Marketing
i. Research other games - want to stop this since it actually makes me feel everything is done already.
1. Stop playing so much games since time is money, use it to play with prototype(s) - pff not sure if I can ever do this.
2. Point of Sales next focus and platform focus: Steam and PC only...(not HTML5, consoles, maybe not even mobile anymore)
3. Focus prototypes (programming) on 4 or less products, since I get distracted and want to do everything.
3.1 Can I sell any parts of it as I progress?
3.2 I will outsource all the art and audio and other services, as each milestone is backed up with results from real strangers wanting more.
4. Put milestone schedules on it all, adjust for life events, stay realistic.
5. Manage with Trello...
6. Figure it out as I go along.
7. Measure,
8. Update assumptions.
9. Set new plans and break into milestones.
10. Loop.
11. Rinse repeat, but update process with new assumptions.
Like I've tested mobile Android and HMTL5 markets and Websites a bit, and now need to learn and test Steam business model. Even after a year of testing I feel I'm still far from knowing where to focus or what niche to stick to...so yes until then try to make prototyping fun and sustainable whatever means necessary.
I do intend to write a proper plan, when I have the time and even know what our next plan is (and I also intend to leave feedback for @Boysano), but my plan at the time of jamming Broforce was to keep adding to promising prototypes until they looked good for a jam game. It was important that they didn't have too many rough edges because I needed them to be better than the audience's minimum expectations in order to get anyone enthusiastic enough to give the prototypes a chance (and give me feedback, and feed the cycle). I felt an idea wasn't tested while it still had glaring rough edges that distracted from the audience's ability to test the aspects that were intended to be tested, and the types of games that I wanted to make were (and are) fairly content heavy, so the prototypes couldn't be so minimal that they wouldn't have rough edges in the first place. In a naive way, as a kind of byproduct of this, what I wanted then (and want explicitly now) is prototypes that might get picked up, and look good, in a Let's Play.
I guess I mean to say is that my scoping is largely based on what I predict are the audience's expectations (and their minimum expectations are what I aim for in prototypes), and what I can achieve before I lose momentum. Often I quit prototypes before I feel the prototype is finished, because I've found myself in a position where I've made mistakes or I cannot improve the prototype without spending more time than the test is worth. Which isn't a failure, I've still learnt something about the game I was trying to make, and in the process I've acquired skills in trying to reach an audience's expectations.
Not sure if this is all that different to what you've described with your prototyping. I think it is a bit different at least to what you describe as ruthlessly scoping prototypes, and it feels like the way I treat prototypes amounts to their being something of a continuum between prototypes and full production products. Which isn't to say "Ruthlessly scoping prototypes is wrong", it's just to say there is at least one other valid way to go about it.
Beyond purely testing a game idea with a prototype, improving my ability then (and our team's ability now) to produce products that appeal to players was/is a part of my/our prototyping process, which I think is the biggest contributor perhaps to this different approach.
I'm not suggesting that Clockwork Acorn isn't improving its production skills through its prototyping process (of course it is), or that Clockwork Acorn is not going to perform any testing on how elements some might consider "polish" affect perception/enjoyment/appeal, but rather that we are explicitly seeking these kinds of improvements in the team through prototyping (and perhaps giving this part of the process more priority).
In terms of projections though, the game performed a little differently. Generally, sales were lower than our projections on those three channels (website, iOS, Android) but we had better pricing info to deal with that by the time we launched... Sales on our site only hit 15 000, but we had different price tiers at $15 ($10 pre-order) and $25 ($20 pre-order) with a special $75 limited edition for anchoring purposes - that helped move the average earnings per sale closer to $17 (yes, over half the people who pre-ordered bought the expensive version) and because this was development money, we got way more than the R300K we were looking for to "finish" the game.
iOS sales are sitting around 6 000, with Android approaching 2 000. That's pretty low compared to the estimates in that document. We did release on mobile way later and with much better information available (even though it still felt a lot like guessing, but they were more educated guesses than before) which meant that we went for a $10 price instead of a measly $2.50 - that means that both our Android and iOS earnings outperform those estimates even though we're still less than 6 months after release on those platforms.
And then Steam just blows everything else away completely. But that's Steam for you...
Other interesting things about this document:
-It spends time early on talking about the team. Knowing what's available to you to use is very important. It's super-important to communicate that to investors, who need to believe that you're all goddamn wizards.
-The marketing plan is pretty naive at best. It's about the bare minimum you have to do to get any sort of traction whatsoever and most of it relies on the goodwill of others, doesn't talk about advertising or even who our target audience is. We didn't do the passport thing at all, mostly because it just didn't seem necessary when we were doing pre-orders and then it was too much work when players were already passing around videos and the free game.
-You can see an early version of the sorts of prototype loops that people are talking about in this thread, as well as a link to a very interesting thinktank article that made me start thinking about this stuff differently ages ago. Note who's in the thinktank! Also worth noting, the prototype loop doesn't stop when you're sure you want to invest in a game, the game has to keep earning that investment by proving its perceived value - I think this is what @EvanGreenwood is touching on a little above.
I pretty much hate this document now, it's a silly plan. Plans like this are generally PR, I think the important things are the signals you look for to base decisions on, writing those down is much harder.
Were you not planning on selling on Steam when you wrote this document? (given that you'd already won an IGF that shouldn't have been a problem)
I wrote the first versions of this right after we got back from SF and were looking for funding (had been for a few months already) so it was important not to promise something we couldn't deliver at the time - Steam was definitely not within reach to an SA studio. It was only at E3 that year that I managed to both meet someone from Steam AND get them interested in DD. We figured we could do pre-orders, go to E3 and see what happened, then do whatever investment deal would give us just enough to finish. Getting that Steam deal is one of the major things that made us say no to outside investment.
@EvanGreenwood I really like the concept of a minimum quality, and feel actually a lot more is expected of prototypes than I thought originally. It seems difficult to balance the first impression of a game when made public online. Even though I would like to share things sooner, for feedback loop, I take it to personal and lose motivation if I do not get the reactions I'd like to see. However; I guess it comes down to respecting the time of the people you ask for feedback. I agree most people will only respond when they are genuinely interested.
So yeah. It just seems like it matches. If anything does, it's because we decided that's what we needed to achieve and then made sure we were going to achieve at least that by picking our milestones in ways that meant we could test if we were getting there.
And numbers were sucked out of my thumb based on as much as I could find out about similar games launching at that point in time. A lot more info has been made available (or been given to me privately) since I wrote that.
I'm aiming for a minimum quality before I consider the idea tested, because as long as players are more focused on the execution of the idea I'm not going to be getting adequate feedback on the idea. (I guess this betrays something of a distrust in players that they won't be able to evaluate the constituent elements of a game independently, that good music for instance will make players think that the game design is different to what it actually is, that happy music will make them think an activity is joyful, or sad music make them think an activity is depressing).
The point I was trying to make originally was that ruthless scoping of prototypes doesn't test how the elements of polish affect the player experience, that purely testing the mechanics still leaves all the questions of how to execute the idea on the table. (That and I want to learn to be good at polish, and also I want my prototypes to be enjoyable enough when I put them down that they promote my work).
I don't think first impressions are important. There are always more players out there, and as the prototype signals to players that more and more time has been spent on it it will be easier and easier to access that pool of players.
HOWEVER, having said all of that, I do think if you need to test a mechanical idea as quickly as possible that the barebones approach that @francoisvn advocates is useful as a start. It's a good place to start to have very minimalist everything except the idea that needs testing.
For instance these games (that have about 8 or so hours on them)... http://makegamessa.com/discussion/3267/post-mortem-free-lives-8-hour-jam-on-june-13th
I haven't worked on the game I posted here since the 16 hours I spent on it that weekend... but I don't consider the idea tested at all, I think my approach is a bit wrong in a few ways, I probably need to restart and tackle it from a different angle.