Please click here if you do not see a Nav Frame at left

Financial Aspects of Game Development

By Tom Sloper

April, 2001

 

The creation of a computer game or videogame is a time-consuming and expensive process. The purpose of this article is to shed some light on the financial side of that process, for those unfamiliar with it (and curious about it).  I've been in the business of making games for many years, mostly as a producer working for a software publisher, and mostly working with external developers. My experience with the external studio method of development is the focus of this article, but I also touch briefly upon a few other development models used in the making of games, each one of which embodies a different financial model. 

Very briefly, there are four main models under which games are developed:

 

1. THE LONE GUNMAN.  One person designs and programs the game all by himself, possibly using some graphics and sounds created by someone else, and the designer/programmer also publishes the game himself.

 

2. THE ONE-MAN STUDIO.  One person programs the game all by himself, possibly using some graphics and sounds created by someone else, under contract from the publisher. Essentially, this is the same as the Lone Gunman model above, except that the One-Man Studio gets paid by the publisher prior to the gamefs publication. And it's also very similar to the External Studio model below, only on a much smaller scale.

 

3. THE EXTERNAL STUDIO. A team of talent (programmers, designers, artists, sound engineers) creates a game, under contract from the publisher. This is the model most widely used today, and the model I am most familiar with.  Hopefully it is also the model that the reader is most interested in!

 

4. THE INTERNAL STUDIO.  The publisher employs a full-time staff of programmers, designers, artists, and sound engineers to make the game(s).  The team works at the publisher's location, as employees, making games to be sold by the publisher.

 

Let's take a quick look at these models (especially the External Studio model) in order to get a fairly broad overview on financial aspects behind the cost of games on the market today. 

 

 

THE LONE GUNMAN and THE ONE-MAN STUDIO

              In the early days of making electronic games (late 1970s through 1980s), the games were typically pretty small. Games were often conceived, designed, and programmed by one talented individual.  Today we still see small one-man games being created, usually as shareware or freeware or small online games, or the one-man game is likely distributed through other non-mainstream channels. That is to say, you arenft likely to see a one-man effort for sale on the PS2 rack alongside FINAL FINTASY IX and CONKER'S BAD FUR DAY. It is an internal or external studio, rather than a one-man operation, that creates a mainstream game.  It's more likely that the one-man game of today is created for the personal computer (Mac or Windows or Java) or even for cell phones, rather than for a console.

              The main difference between the Lone Gunman and the One-Man Studio (terms that I have coined for this article, purely to differentiate between the two and for no other reason) is the financial model.

              The Lone Gunman is self-financed, and typically self-publishing.  This is not a job for the weak-hearted.  It can take months (even years) to program a game, even a small game. The Lone Gunman is driven by his own passion for the game in hopes of making money when people start buying his game.  I'm not going into much detail about this model, for several reasons:

 

a.      I don't know much about it, my experience being in mainstream games;

b.      I don't recommend this route for beginners because of the enormous financial risks involved;

c.       It's not a mainstream model.

 

              The One-Man Studio is essentially a Lone Gunman who has a contract with a publisher.  As we discuss the finances of the External Studio model (below), the same principles also apply to the One-Man Studio.

              I expect that some readers of this article are fervently wishing to get a gig as a One-Man Studio, but if you are just starting out, forget it.  You need to begin by getting a job at a game company (either with a developer or with a publisher).  I've written extensively about that at my website (sloperama.com).

              It is rare that a Lone Gunman creates an original game concept and subsequently finds a publisher to license it from him. The tedious task of pitching one's brainchild to publisher after publisher is time-consuming, expensive, frustrating, and usually fruitless. Thus the Lone Gunman typically has to self-publish.  The Lone Gunman has to bear all his own costs, in hope of making it back when he finds customers to buy his game.

It is much more usual for a publisher to seek and hire a One-Man Studio to create a specific (and small) game that the publisher has in mind.

              The reason a publisher might hire a One-Man Studio is because the individual is highly experienced, having worked for several years in the development of games, and has proven himself or herself to be accomplished and trustworthy.  Publishers don't want to commit the finances to an inexperienced lone programmer without a proven track record of hits. The only time publishers hire a One-Man Studio is when the publisher has a need for a small game, usually something specific that falls within the specialty of the One-Man Studio. 

Most of the time, though, a publisher is trying to create a mainstream product -- a large game that requires the use of a team, or even multiple teams, rather than a one-man show.  So now we get to the External Studio and, after that, we'll finish up with a brief discussion of the Internal Studio.

 

 

THE EXTERNAL STUDIO

              Typically, the publisher approaches an external development studio and asks the studio to create a specific game that the publisher has in mind.  It also sometimes happens that an external studio independently creates a game and pitches it to publishers, hoping that one of them will license it.  These two different paradigms I call (for the purposes of this article) the PUBLISHER-CONCEPT model and the DEVELOPER-CONCEPT model. 

             

THE EXTERNAL STUDIO, creating a PUBLISHER-CONCEPT game

              When the external studio is hired to create a game based on the publisher's concept, the external studio may have to work for a flat fee, payable in chunks at key points (milestones) during the project.  Or the studio may negotiate with the publisher to work for less up-front money in exchange for royalties later on, when the finished game is sold.  So, to further subdivide the already subdivided models, we also now have the FLAT-FEE model versus the ROYALTY-BASED model. Let's take an in-depth look at the simplest one, the flat fee, first.

             

THE EXTERNAL STUDIO, creating a PUBLISHER-CONCEPT game (for a FLAT FEE)

              Typically the contract is set up so that the external studio gets some money at contract signing, so that the external studio can begin work.  Then, other payments are made at key points (milestones) during the project.  Let's say that this particular project is scheduled to last 16 months, using a developer team consisting of a line producer, 4 programmers, 4 artists, a game designer, a level designer, and a sound engineer. 

              [Sidebar: You may wonder why I list a game designer on the team, if the concept comes from the publisher. The usual scenario is that the publisher says, "We want you to create a sequel to our hit game, 'Final Beginning III' -- we want you to create 'Final Beginning IV' for us, according to some guidelines we'll provide."  It is then up to the developer to take that basic request and work out all the details.  Thus a designer is needed. And, even though the developer is creating a new version of 'Final Beginning,' the developer is performing a 'Work For Hire,' not creating a new original intellectual property of the developer's own.  What I'm saying is, the publisher still owns the 'Final Beginning' intellectual property rights, even though the developer is designing a game in the series.  But I digress.]

Let's say that the total personnel cost to the developer for this effort is roughly $416,000 as shown in this table: 

 

 

Months

Involvement

Salary/yr

Salary/mo

 

Programmer 1

16

100%

$90,000

$7,500

$120,000

Programmer 2

16

100%

$70,000

$5,833

$93,333

Programmer 3

12

50%

$50,000

$4,167

$25,000

Programmer 4

5

100%

$50,000

$4,167

$20,833

Artist 1

5

100%

$50,000

$4,167

$20,833

Artist 2

4

75%

$30,000

$2,500

$7,500

Artist 3

3

75%

$45,000

$3,750

$8,438

Artist 4

3

50%

$40,000

$3,333

$5,000

Sound engineer

1

75%

$50,000

$4,167

$3,125

Game designer 1

4

100%

$50,000

$4,167

$16,667

Game designer 1

6

50%

$50,000

$4,167

$12,500

Level designer

9

100%

$35,000

$2,917

$26,250

Line Producer

16

50%

$85,000

$7,083

$56,667

Total personnel costs

 

 

 

 

$416,146

Overhead

 

 

 

 

20%

Profit

 

 

 

 

20%

Total

 

 

 

 

$582,604

Rounded - final bid

 

 

 

 

$580,000

 

Table 1. Developer's worksheet for arriving at bid amount for flat-fee project.

 

              You may note that each individual member of the team doesn't work 100% of his or her time for the full 16 months of the project. That has to be factored in.  For example, the line producer does work for the full 16 months, but he or she is splitting his/her time with another project, thus the line producer cost is only 50% of the line producer's salary.

Having arrived at the total personnel costs, though, the developer can't just bid that amount.  The developer also needs to cover overhead expenses and make a profit, so tacking on 20% for each of those (a number I just pulled out of my hat), we arrive at a figure slightly over $580,000.  Let's say the developer calls it $580,000 even. (Mind you, this is all just numbers I pulled out of thin air.  The salaries and timeframes are all just stuff I made up.  This would be pretty cheap for a mainstream game, and 40% may not be enough to cover a developerfs overhead and profit.  It is also likely that the developer has already created a billing rate for each employee, and uses that to calculate the bid, rather than doing it the way I outline above.)

              Now the developer bids $580,000 and the publisher agrees on this amount.  Next, terms need to be hammered out.  For example, the payment structure might wind up looking like this:

 

Signing

$60,000

Tech spec

$40,000

Engine integration

$40,000

First playable

$60,000

One complete level

$60,000

Alpha

$60,000

Demo CD

$50,000

Beta

$60,000

Release

$60,000

European version(s)

$30,000

Japanese version

$30,000

OEM version

$30,000

Total

$580,000

 

Table 2. Milestone payments schedule for flat-fee project.

 

              The contract will include details about how the two parties (publisher and developer) will determine and agree that a deliverable has been met, and in what format deliveries are to be made, and in what form payment will be made.

              So. All done. That takes care of the flat-fee model, for an external developer creating a game as a work for hire for a publisher.  (My apologies if I have glossed over a lot of stuff -- it all looks straightforward to me, but it might look like hocus-pocus-gobbledygook to someone not familiar with the process, for all I know.)

              In actuality, it's not always the case that a publisher-concept game will be developed on a flat-fee basis as shown above. The developer most likely wants to earn royalties if the product sells well, and the publisher wants to pay less up front money (reducing the risk and increasing the ROI or Return On Investment), thus it is likely that, rather than a flat fee model, a given project will use the royalty method instead.

 

THE EXTERNAL STUDIO, creating a PUBLISHER-CONCEPT game (for a ROYALTY)

              The developer, believing that the game will be a success, wants a piece of the sales moneys, and in exchange for this, is willing to reduce the up-front payments.  It's a risk now for both parties, not just for the publisher. This adds to the publisher's comfort level in taking the risk of entering into this venture.  And it incentivizes the developer to make a great game.

              Let's say that the developer cuts the up-front cost by 20%, slashing each milestone payment commensurately.

 

 

Fee milestone

Minus

Royalty milestone

Signing

$60,000

20%

$48,000

Tech spec

$40,000

20%

$32,000

Engine integration

$40,000

20%

$32,000

First playable

$60,000

20%

$48,000

One complete level

$60,000

20%

$48,000

Alpha

$60,000

20%

$48,000

Demo CD

$50,000

20%

$40,000

Beta

$60,000

20%

$48,000

Release

$60,000

20%

$48,000

European SKUs

$30,000

20%

$24,000

Japanese SKU

$30,000

20%

$24,000

OEM

$30,000

20%

$24,000

Total

$580,000

20%

$464,000

 

Table 3. Developer slashes milestone payments by 20% in order to get a 10% royalty.

 

              This is much more palatable to the publisher, of course. In this fictional case, the developer has cut into their overhead and profit (they are still making enough money to cover personnel costs, with a little extra towards overhead).  Hopefully the developer is also bringing in royalties from past projects to cover the rest of the overhead cost of running a business. The hope is that the game will sell well enough so there will be profit further down the road.  If the developer can't afford to operate on this money, the developer should not accept a deal like this.  Perhaps less is cut off the top (so that the developer's overhead is still covered), and perhaps the publisher pays a lower royalty. Or perhaps not. Everything is negotiable.  Each case is different.

              Anyway, the parties sign a contract, and make a game according to the amounts shown above. Let's say it all goes fine, without any contract amendments having to be made.  (I like keeping things simple!)

              So now we've pretty much taken care of the up-front side of the finances.  There are royalties to be taken into account too, so now let's take a look at the back end. 

The game is now finished, released, and is selling in the stores (and through online stores as well). 

I find it easier to explain all this financial stuff by the use of examples. The following numbers (like the previous numbers) are entirely made up, just to illustrate a simplified view of how things work in the business of games. The game design and game development newsgroups and websites are full of information that shows how much more complicated it really is, and what kinds of numbers real developers have seen in their projects.  As noted before, each case is different.

 

Retail price per unit

 $  59.99

Retail markup

20%

Wholesale

 $  47.99

COGs

 $  21.00

Publisher's gross

 $  26.99

Publisher's costs

50%

Net profit per unit

 $  13.50

 

Table 4. Calculating net profits on per-unit sales

 

              In this table, the game is a console game that sells to the consumer for $59.99. The store paid the publisher (who has their own distribution setup) $47.99 for each unit (I'm just pulling numbers out of a hat -- retail markup may well be a very different figure from the 20% I've shown here).  The publisher paid $21.00 each to have the game manufactured (including some licensing costs to the game console manufacturer, as well as costs for shipping the games by cargo ship and truck) -- this is called "Cost Of Goods" (COGs).  So the publisher's gross earnings on the game is $26.99 per unit. For simplification's sake, let's say that all the other costs incurred by the publisher amount to 50% of the gross earnings (actual number differs depending on many factors).  So now the net profit for the publisher (not counting advances to the developer) is approximately $13.50 per unit (actually $13.49 and six tenths of a cent).

              This is the amount that will be used to calculate royalties to the developer.  Now we get into the meaty part.  How many units of the game (how many discs or how many cartridges) will be sold, and what percentage royalty does the developer get?

              Notice how, in the following table, as sales increase, the minus signs disappear, and we start seeing more commas and zeroes!

 

Unit Sales

Publisher net profits

Minus developer advance

Developer royalties

at 10%

10,000

$134,960

-$445,040

-$44,504

20,000

$269,920

-$310,080

-$31,008

30,000

$404,880

-$175,120

-$17,512

40,000

$539,840

-$40,160

-$4,016

50,000

$674,800

$94,800

$9,480

100,000

$1,349,600

$769,600

$76,960

200,000

$2,699,200

$2,119,200

$211,920

300,000

$4,048,800

$3,468,800

$346,880

500,000

$6,748,000

$6,168,000

$616,800

750,000

$10,122,000

$9,542,000

$954,200

1,000,000

$13,496,000

$12,916,000

$1,291,600

2,000,000

$26,992,000

$26,412,000

$2,641,200

 

Table 5. Unit Sales' effect on publisher and developer profits.

 

              Let's say that the developer negotiated an across-the-board 10% royalty, just to keep things simple. If the game sells less than 50,000 units, both the publisher and the developer lose money (see all the minus signs on the righthand side at the top of the table). 

50,000 units is a critical row on this table (it's the first one where we don't see minus signs). Take a look at the 50,000 unit sales row. The publisher made $674,800 on the sale of 50,000 units, but because the publisher paid $464,000 to the developer (as was shown in Table 3), the publisher's actual profit is about $95,000.

              Because the publisher is now out of the red, this is the point at which the developer starts earning royalties. Publisher cuts a royalty check to developer for $9,480 (10% of the net profits).

Our fictional developer, however, is still not yet in the black.  The developer's royalty check still does not cover its desired overhead and profit margin (recall that, above in Table 3, the developer had reduced its up-front payments by 20%)! 

 

Developer's personnel costs

$416,146

Developer's overhead costs (20%)

+$83,229

Developer's total costs

=$499,375

Milestone payments

$464,000

Developer in the hole to the tune of

-$47,854

Royalties on 50,000 units

$9,480

Developer profit

-$38,374

 

Table 6. Calculating developer's losses if sales only reach 50,000 units

 

              So. Lack of minus signs in Table 5's 50,000 units row still isn't enough to make the developer happy.  But let's take a look at what happens if the game sells 100,000 units. As shown in Table 5 above, developer gets a royalty check of about $77,000.

 

Developer's personnel costs

$416,146

Developer's overhead costs (20%)

+$83,229

Developer's total costs

=$499,375

Milestone payments

$464,000

Developer in the hole to the tune of

-$47,854

Royalties on 100,000 units

$76,960

Developer profit

$29,106

 

Table 7. Calculating developer's profits if sales reach 100,000 units

 

At this point, our fictional developer is finally making a profit on the game. Not much of a profit, though.  The developer is breathing more easily, but still isn't very happy (profits of under $30,000 on a 16-month project is nothing to brag about). The fictional publisher is not too unhappy having made about three-quarters of a million dollars, but both parties really want more from the venture than this.

              Breaking even is never good enough. The whole reason to make these games is to make a LOT of money.  All sales above a hundred thousand units (see bottom of Table 5) make good profits for both parties, publisher and developer, in this fictitious example.  So both publisher and developer are incentivized to make a title that will so enthrall the buying public that they the game will sell in multiples of a hundred thousand units. 

In actuality, that probably requires a much larger effort than the half-million-dollar venture I've outlined in this made-up example -- it probably takes more like one and a half to two million dollars (or more!) to make a game that will stand far enough above the crowd to earn that kind of triple-A hit status.

 

THE EXTERNAL STUDIO, creating a DEVELOPER-CONCEPT game (royalty-based)

              Remember that the lengthy example above is about a game that the publisher hired the developer to create.  The publisher owns the intellectual property behind this game ("Final Beginning IV").  If the game is instead based on an idea wholly of the developer's creation, well, that's a completely different matter.

              Rather than creating a sequel to the publisher's existing "Final Beginning" series, then, the developer has created a brand new concept, like for instance, um, "Ducks At War."  Because this is the developer's intellectual property, not the publisher's, the developer has a stronger negotiating stance and can get a higher royalty. 

I won't make more tables to illustrate this point.  You can just use the principles given above, plug in different numbers, and off you go.  It should be self-evident that the higher the royalty, the earlier the developer breaks even and starts earning money.  That's why developers are desirous of selling their own game concepts rather than working on an assigned concept from the publisher.  Now all that remains to be done is find a publisher who thinks "Ducks At War" will be a million-seller.  Lotsa luck!

 

FURTHER MUDDYING THE WATERS

              But there is even another part that is often added to the equation. If the intellectual property behind the game is the property of a third party, then the publisher has to pay royalties to the IP owner as well as to the developer (thus the developer most likely has to accept a smaller royalty, if any).  For example, if the publisher goes to a movie studio and acquires the rights to make a game based on the upcoming Hollywood movie "Gladiatrix," then the royalties to the movie studio have to be factored in as well. The publisher and developer both get a smaller piece of the pie since the movie studio gets a piece too.  All parties hope that the movie title will add cachet to the game, and that the game will sell in bigger numbers thereby.  (Yeah, right.)

 

              And, finally, there is one more model that we haven't examined yet...

 

THE INTERNAL STUDIO model

              When a publisher creates a game using its internal staff rather than an external studio, different costs come into place.  In addition to salaries for the people making the game, the publisher must also pay benefits to those people, as well as for the office facilities and maintenance, and the nebulous thing called "overhead" comes even more into play.  Overhead (in the case of an internally developed project) means that there are a lot of people working at the company whose salaries and benefits cannot be charged directly to the project, but those costs must be accounted for somehow.  Overhead company costs are typically amortized (spread out) among all the studio's projects.

              Above I estimated (read "guessed") the developer overhead cost at 20% -- regardless of how far off I may be on that figure, the overhead cost for a publisher is definitely much higher. 

              The trend these days is to less and less internal development, and more and more reliance on external studios to do the actual work of creating the games.  The publisher has enough on its plate, dealing with the process of deciding which games to focus on and the actual process of getting them licensed, produced, manufactured, sold, and supported, globally and (increasingly) digitally.  The costs associated with maintaining an internal studio are so high that it is usually to the publisher' benefit to work with external sources, thus I have focused on external studio models in this article.

 

I'M OUTTA HERE!

              The figures given above are vastly simplified examples, and are not necessarily representative of typical project costs. The reality of business is that there are a lot more things that need to be factored in (especially, I have squeezed a lot of such things into the over-simplified category "publisher's costs" in Table 4).  But I think I've bored the reader enough with figures and tables.  Nevertheless, I think I've gotten the point across... It's easy to see why games can cost so much.

 


Name = Roger Cheng
Email = Aeroshark2000@yahoo.com
Age-Ed-Occ = under 20
Date = 8-17-2004
Comments = >Hi, I was thinking more about the profit percentage of game development.

 

"More"? So, are you saying that you were thinking about this once before, and now you're thinking about it again? You never told me! (^_^)

 

>I was wondering where the money goes from selling a game. For example, say you released a game retailing for $50. Where would the royalties and fees go (ie. to retailers, to distributers, to publishers etc...) if it was released from an independent game studio? About how much of the $50 would the game studio as a whole actually see?

 

I think I covered a little of this in article 35 (see above left), and in my article on Game Finances. But let's do it again here:

    • End user pays (retail price) - $50
    • Store pays (wholesale price) - $33
    • Publisher pays Sony (PS2 mfg/lic. price) - $15 (this may be an out of date cost)
    • Amount left over (publisher profit per unit) - $18

Now then, you asked how much of that goes to the developer. Only problem is, you haven't told me what kind of deal the developer negotiated! And you haven't told me how much the publisher spent on marketing, how many units were made, how many were sold, and how much the publisher spent up front on developing the game. EACH OF THOSE IS A VARIABLE - thus there is no one answer to your question. Here. I made up some numbers. Let's say for instance that the publisher paid the developer $3M in advance against a 15% royalty. Let's say they manufacture 1M units, with 10% of those wasted as samples, returns, defectives, and they spent $3M on marketing...

So the answer IN THIS HYPOTHETICAL CASE is that the developer gets a royalty of 69 cents per unit. If that doesn't answer the question, then you didn't ask the right question! (^_^)

 

>And as a second side question, would a small game studio need a lawyer to manage its finances and contracts and everything? I'm actually not sure if you've answered it in your lessons, but I haven't seen it so far. Thanks.

 

Lawyers don't manage finances. Lawyers don't manage "everything." Lawyers only advise during the negotiation of contracts.
Tom Sloper
Los Angeles, CA
August 10, 2004


Before you write me to ask where you can get statistics and data, read my March 2007 IGDA column, "The Games Game: Data In The Haystack," archived at http://www.igda.org. (Note: in 2013, the IGDA site was reorganized; links on that legacy archive need to be edited before they'll work and take you to other columns, until such time as the IGDA reinstates legacy content.)

You can get some game sales data at http://www.game-sales-charts.com/cms/index.php


Got a question about this article? Click here to go to the bulletin board. You'll get answers!

Click here to go to the previous FAQ.
Click to go ahead to the next one.

Click here to return to the School-A-Rama main page.

© 2001 Tom Sloper. All rights reserved. May not be re-published without written permission of the author.