For our third week of lectures here at Bolton, we have had Nick Davis, CEO and head producer of Lucid Games; the same company Mark Craig hailed from, to run us through the business side of game creation; explanation the role of the producer, how to get a game signed up with a publisher, the development phases (as relate to business) and a comparison between working in small and large studios.
As a producer, your role is essentially somewhere between management and buffering, though things vary between studios and blur when the company is small. In Davis’ case, his job runs the whole gamut from team management and scheduling – setting up deadlines and keeping everyone aware of them – hiring and publisher and external relations; external meaning things like licensing, marketing, outsourcing and press. They essentially serve as a ‘shell’ around the company, ensuring the developers can do their work with as little interference as possible. That said, he did stress the importance of having a strong awareness of deadlines and pressures; keeping at least part of your mind on the bigger picture. This is particularly true in small-team studios, where the company’s position is a lot more precarious and dependant on striking its payment deadlines. The role can vary from company to company, though it’s generally a good idea for everyone to at least be aware of everyone else’s field.
Getting Games Signed
On getting a game signed with a publisher for funding with a new IP, he identified the following strategies. In all cases, the objective is to ensure the producers can understand your goal and what you plan to build.
Quite literally a pitch document. The wordier it is the worse its reception; the example he showed us was a powerpoint presentation with plenty of images and concepts. This is cheap for the developers, but risky to the producers, as there is no real indication of the final product; it’s just words on a page. No proof; essentially just promises on a scrap of paper.
Video / Ripomatic
Stepping up from a paper pitch, we have the Video/Ripomatic. These involve stitching together a video from footage of existing films, games, whathaveyou with the intent of getting across the feel and style of the game; good for providing an indication of art styles, environments and such, but awkward on displaying actual gameplay without saying the words ‘Like This But-’. Still, it serves as being more visual than the paper pitch for a similar time/cost investment on the part of the developer. Probably combined they could make a decent pitch… but there’s still a high risk to the publisher.
Probably the best option; a small prototype of core gameplay tossed together using freeware or existing technology (ie Unity,, Torque2D, UDK or any in-house engines the studio may have kicking around). This gives the producers a handle on the gameplay of the game and the core question of whether or not it shows promise and is worth investing in. Odds are you’re not going to have much in the visuals department here, so combining it with a paper pitch seems a wise idea. This is the highest so far in development costs and time as it requires actual coding and creation work ahead of a signing (with still no garauntee of sucess) whilst showing the lowest risk to the producer, as it proves you’ve gotten somewhere already.
Finally, we have the previs; quite literally faking ingame footage that looks representative of the final product. It is not cheap, and it is still not guaranteed not to fall flat on its face, but is the most likely to impress the publishers for being representative of the final product. But the downside is the cost; this is the sort of thing only available to a larger studio.
The whole point is the visuals; a picture speaks a thousand words and all that jazz. Words on a page can be misinterpreted and vague; something with a lot of visual imagery can get a clearer idea across much faster and much more successfully.
Alternatively, a more established studio may find itself approached by a publisher as opposed to the other way around; they come to you asking you to create a game in x genre or to reboot x franchise. This generally only occurs with studios that have proven their expertise in certain genres, and you are still expected to draw up a pitch; the advantage is the pre-established focus and budget estimate.
Once a game is signed off, contract negotiations can begin; always the most fun part of any business enterprise. This generally consists of the developer and publisher having teams of lawyers toss hefty 50-page documents of legalese at each other until someone calls a truce; usual sticking points being royalties, termination clauses, ancillaries, non-compete clauses and IP retention. As a developer, the further along you are in your development process, the stronger your position. It’s always a balance of risk and reward on both sides, with these points being the areas where the interests of the developer and the interests of the publisher most collide:
With royalties, obviously the developers want their share, but the publishers also need their return on their investment. With termination clauses, both need an escape if the other side isn’t holding up, but at the same time wants to ensure their hard work / money isn’t going to be unexpectedly ditched. With ancillaries… well, no-one really gets ancillaries. Non-compete clauses essentially tie the developer to prevent them making similar games for different competing companies (for example, you may be contracted to build a racing game with the NCC of not building another one for x number of years). The developer will want this as vague as possible and the publisher as explicit as possible; the publisher doesn’t want to be paying a studio that’s also making competing products and the developer doesn’t want to be tied down from accepting later contracts once they complete this one. It’s a balance.
IP Retention gets it’s own little subtopic; in an ideal world you would hold the rights to your intellectual property, and since it is generally you pitching your idea to the publisher, it seems obvious that it is your idea and you should keep it. On the other hand, if you sign with a producer, they are essentially agreeing to pay you to make your game, and this (in large studio projects) is not exactly cheap; they deserve some credit and IP control themselves. The more you ask for and the earlier you ask it, the more you should expect to lose your IP. And at the end of the day, if you don’t get the money to make your game, your idea is still worthless anyway. Generally, IP retention tends to amount in the developers getting first dibs on sequels, which generally makes sense, or else the publisher agrees to a multi-game (essentially a ‘franchise’) contract, with the IP being held by them for that period until the contract is complete. It’s a fuzzy one.
For an average console game, you can generally expect your split to fall along the lines of 60/40 Development/Marketing. This can vary of course; it’s just a rough average. This money gets spent internally; staff wages and overheads and externally; Outsourcing (typically 10-20%), Licensing, Legal, QA and Localisation.
When it comes to development costs, a large studio can generally expect staff of around 200; this was Bizarre Creations at its peak, with 100 staff per title. Davis introduced to us the concept of the ‘Man Month Rate’; essentially how much each staff member costs per month to employ, which goes beyond just wages. You have the equipment and software licenses they need, the premises they need to work in, the insurance and the utilities. As a general rule, he says to expect £5000-8000 per person per month. For a year, that’s £60,000-£96,000. For a 100 man team on a two year dev cycle, you’re looking at a cost of 6-10 million a year to fund a studio. Hence the need for publishers.
Outsourcing can help alleviate this to a degree; by outsourcing certain tasks (primarily 3D modelling grunt-work, motion capture, QA testing, music and voice acting) you remove the cost of having the facilities and staff set up ‘bespoke’ in studio complete with their equipment and premises. Obviously major tasks – design and programming – should never be outsourced, but designers and coders can generally be expected to be on-staff the full run through of the development process anyway. Speaking of…
The Development Process
(Davis had a very fancy chart for this that I have no means of recreating in wordpress, so imagine some fancy powerpointing here)
There are four main phases Davis identifies: Prototype, Pre-Production, Production and Mastering. To break them down on a dev cycle of 24 months, max 75 staff:
Working with a core team of programmers, designers and artists, build a functional proof-of-concept to show the idea is workable. This may be the point of pitching to the publisher, in any case the purpose is to have a very rough form of the game playable with the core mechanics complete. From here, the initial specifications of the project can be drawn out; scope, budget, team size and timeframe.
Here, the idea is to push for a ‘First Playable’ form of the game; complete, but unpolished and lacking a majorityof art assets. This is the sign-off phase before production starts; if the Pre-Prod still isn’t worth playing, go back to Prototype and hack at it until it works. This is where the team sizes and costs start to grow, so its best to do the majority of the comparatively cheap design work here; once an idea is proven, then it can go into production. In our example, the Pre-Production stage would last around 8 months of the total 24, with a staff of 10 or so building to 25 and ramping up to 75 for production.
The longest, largest and most expensive stage. This is where the grunt work of getting the game together comes in; it is pure content creation. If pre-production is the skeleton of the game, production is the meat. Outsourcing starts coming in here. For our example, production should be expected to last 12 months, running the maximum 75 staff with a wind-down towards 40 towards the end.
Essentially the polishing stage; this balancing, alpha and beta testing, polishing and to a degree clean up from the rollercoaster of production. QA is heaviest during this stage. Here, the game is finalised prior to release; in our example, 4 months running a staff of 40 to get it shipped.
Both the developers and publishers need and want a clear idea of the progress of the project, and to that end they introduce Milestones and Greenlights; Milestones are essentially a monthly or bimonthly deadline, saying ‘at this point in time we will have x feature implemented’. These are typically linked to payments, making them of crucial importance to smaller studios. Once again, developers will want these as loose and possible and the publishers as tight. Greenlights are run less often, and involve a full executive review from Business, Marketing, PR and so forth. These are the points where the game can get canned. Typically they come up at major milestones within a project; First Playable, Mid Production, Alpha and Beta. Fun for the whole family.
On Large and Small Studios
Davis’ experience on this topic stems from his work in Bizarre Creations under Activision, then his leading of Lucid Games when Bizarre was closed down. At Bizarre, as noted earlier, a staff of around 200 building high-end console games – primarily racing, whilst at Lucid, it was initially a core of 8 founding members that has expanded to a team of 28 + 10 contractors on 3 titles.
In common, the process and disciplines remain, but Lucid naturally has its scope reduced to meet its budget; this combined with the smaller size gives it much more flexibility but also makes it far more reliant on milestone payments, as it doesn’t have a lot of capital to keep it afloat in the event of a missed deadline. Smaller studios are in this sense naturally more precarious. Identifying the key features of large and small studios, Davis identified:
Gets the big projects and latest tech, and is generally filled with experts with a higher(?) sense of security, but at the risk of pigeonholing and a shrinking of the wider picture. Large-scale games can also be quite the dominating slog when you have development cycles measured in years.
Smaller scale and budget, but wider fields of knowledge; team members need to be versatile, as there are generally more tasks than there are people to complete them. This gives you a more rounded experience, but with less depth; there’s a lack of specialisation. As noted several times, they are also far more precarious, but with a faster project turnaround; games generally taking anywhere from 3 months to less than a year. It varies, naturally.
On Where To Start
As usual, the crux of Davis’ advice was research; knowing what you’re getting into and knowing to get into it at. Being willing to accept compromises early on whilst building up your experience is important, and having something you’ve made to show or better yet sell will get you further. Tailoring your CVs to each target will go a long way, and understand the place you’re applying to.