Dollar Dash in Black

Crowdfund Calculus (or thereabouts) Part 1

By Red Coat | The Vernaculog | 12 May 2021

As those of you who've been following my posts may know, I've been working on preparations for a crowdfunding campaign that'll be going live in June. Among those preparations is figuring out starter goals and tiers. 

Now, figuring out what would be the proper numbers to use seems daunting at first. Especially considering how many kickstarters and the like have ended up blasting past their original release dates or overestimating their ability to deliver. In light of those realities I think its good to keep in mind a few specific things:

  • Dev Time projections
  • Monthly Costs for development
  • Individual Merchandise Costs
  • Fulfilment Costs
  • Cuts taken by your platform of choice
  • Cuts taken by your state and other governing bodies

I'll not be going through all of these today, but instead will simply take some time to consider dev time and dev costs

Firstly, when one is considering dev time the hardest bit is figuring out a way to gauge the amount of time it will take for your team to complete the game you're making. As video games are a rather complex thing to build, it would seem nearly impossible to predict work time. To be sure, when you're just getting started this is very much the case. However, if you pay attention to the work being done and listen to your team mates as they talk about level of difficulty when it comes to different tasks, you can start to get an idea of things.

To start, you'll want to keep track of the amount of tasks your team gets done during each week of your first months of development. Note how pressured everyone is during the time. Ideally you want to be moving at a comfortable pace, with no one working extra hours over what should be your normal working period. Make sure to note when tasks are more or less difficult than others in your team's estimations and also track the different task types.

After a month of work, you'll have a sample size of the time it takes for your team to execute on the various tasks required to complete the game. If you planned it correctly, you'll have run through most, or all of the different tasks that the game entails. Note, it's better to approach this in days rather than hours in my opinion, as thinking of the work in days instead of hours helps keep one from defaulting to overtime work. It is a personal opinion, but I believe overtime to be a last resorts tactic and should be treated as such.

At any rate, now that you have your dev time projections, take each of those and multiply the time by 1.5. The reason for this is to take into account the fact that things can (and likely will) go wrong on many occasions. The extra time is a buffer so that your team is able to handle snafus and mistakes without unnecessary stress or sleepless nights. 

After you've multiplied the times and added them together, you'll want to consider how familiar your team is with the game type they are making, and the programming/art that supports it. If your team is treading old ground entirely, the inset 1.5 multiplier should be enough. However, if your team is doing some new things with an old formula, you should consider adding an additional 50% time to the project, as there may be some mistakes or hurdles that your team will encounter that will require research and development outside of the normal required tasks. 

However, if you're going into entirely new territory, you may want to double the amount of time required. This is because in this scenario, you want your team to be able to make the mistakes they need to make while familiarizing themselves with the new development paradigm, and for them to have the necessary time to research new techniques, tools and approaches to successfully execute on their work.

I cannot stress enough, that what you are doing is making an estimated guess here. This in mind, when it comes to time, unless you're trying to finish before Bruce Willis fails to stop the apocalypse, you want to err towards overestimating the amount of time needed, rather than underestimating it. After all, while fixing an early arrival is just a matter of time, there is no time to wait if you are late.

So now that you have a rough estimate of your dev time, you need to consider your dev costs next. For this I believe there are 3 way to approach it:

Cost by Hour
Cost by Day/Month
Cost by Commission

So let us first consider the cost by hour approach. For this approach, you'll need to know roughly what the average amount of hours spent by your team mates on any given day is, and project out to the end of the project by multiplying those hours by the amount of days that you've set for the project. This will give you a rough estimate of the amount of money you'll need to pay your team for normal hours of work. However, this doesn't necessarily take into account overtime. To ensure that you have the ability to account for overtime costs, another 50% to 150% multiplier should be applied to the cost as you'll need to be able to cover the extra time spent if the project gets egregiously behind schedule.  This Cost by Hour variant is vulnerable to overreach on both the management and team side in a couple of ways.

On the management side, it can be forgotten that only a certain amount of hours can be worked in tandem before a worker's effectiveness and happiness wanes. No amount of company picnics or events will fix an overworked teammate. They need to rest, and you need to let them. 

On the team side, if one does not ration the hours that they decide to use for work, they could inadvertently balloon the cost of the project by drafting more hours than is in the budget. If one is not careful they could drain the team of their funds very quickly. Especially if hours are being taken even though work is not really being done.   

Now let us consider the cost by day/month arrangement. Of these choices I tend towards the cost by day/month method as it keeps things related to the development timeline while lessening certain possible issues when it comes to overdosing on overtime. Since your timeline is already annotated in days and months, it relatively simple to translate this into a cost, as all you need to do is determine how many funds you will distribute to your teammates each day or month. Ideally you want them to be able to comfortably live while working on the project so they can focus their creative energies towards the work at hand. 

A weakness of this method is the fact that it does not allow for an easy application of overtime in a paid manner should it be necessary. To handle this, one could implement a hybrid methodology, where a day's cost takes into account an average $/hour rate, and then use that rate with a multiplier to apply the cost of overtime hours. For this method, you'll need to set aside a portion of your budget for overtime hours. Perhaps take the additional 50% time that you added to the initial project projection and count those hours as overtime when seeking a projected cost. 

This weakness can also be perceived as a strength on the managerial side, as it makes one more hesitant to apply overtime work hours when they are in limited supply.

Finally, we have the commission model. In this format, instead of valuing the team mates work based on time spent, you value it based on the nature of the task they've undertaken. This version will require a good bit of negotiation between you and your teammates, with addendums to allow the costs to be corrected if a job is overvalued or undervalued. Theoretically, this can lead to a very static and predictable cost for the project, although it is a little harder to map on to the project timeline as such. This can be a double edged sword however, as the flat rate commissions can be inflexible when it comes to more nebulous workflows, such as research and brainstorming.

Ultimately, the big take away here is that you should take your time when considering the amount of time you need to allot to a project, and try to tailor your payment model to the team that you're working with. Ideally, your team should have enough time to work at a comfortable pace, and enough money to live in a comfortable manner.

Disclaimer: These are the musings of a random guy on the internet. If you want business advice or what have you, talk to a business guy that you trust and respect. (And obviously, don't take advice from the ones that you don't!) 







How do you rate this article?



Red Coat
Red Coat

I'm a game designer that dabbles in writing, music creation, and general content production

The Vernaculog
The Vernaculog

Hey there! I'm Red Coat, founder of Vernacular Games, amateur game designer, music composer, writer and (according to most people) an all around good guy. So what can you expect to hear from me? I'll talk a bit about some projects that myself or my teams are working on, comment on company culture in the tech industry, talk about various concepts in game design and even wax philosophical about this or that thing. So hello to you dear reader. I hope to add a little more value to your day. Ciao for now.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.