The reality of being ‘indie’

Indie development doesn’t need to be like this

So here I am; 6 weeks into being ‘Mr Evil 27 Games Limited’.

I have to confess; being a one-person indie games development studio is almost as unnerving as it is exciting but then I do have “Wisdom Comes To Those That Stray” on my arm and I know from experience that trying something unconventional in your professional life doesn’t always end in ‘success’ but it does always end in useful experience and learning.

I’ve founded/co-founded three previous games/digital start-ups over the last 15 years and in a way they were all ‘indies’ in that we were largely in control of our own destiny (within fiscal limits of course) and developed our own games/tech/services which we then choose how we would commercialize. This time it is different though. This time I am (currently) alone, adopting my own commercial strategy, working on my own game concepts, designing 100% of the game mechanics and UI, defining the business model and IAP items/prices, cutting my own code, doing my own concept art and at the same time doing the bulk of the business admin, networking and social media marketing.

All of that take some hours! I’ve always worked long hours (typically 50 or so hours a week with SoshiGames and PIXELearning) but I’ve found myself largely in my office from just after 8am to gone midnight most days now. The interesting thing is that this doesn’t in anyway feel onerous, in fact I feel more energized and upbeat than at pretty much anytime in the last decade. I don’t think that is unique and in fact I think this is the very reason that so many games professionals opt for and embrace the indie route as an alternative to taking a ‘sensible’ role at an established studio. ‘Indie’ = creative/professional freedom. It shares much with the punk ethic; I’m sticking to what I believe in, my values and ideal irrespective of what ‘the system’ or convention may dictate.

That ‘freedom’ comes with costs; the aforementioned hours, lower/sporadic income, uncertain outcomes/risk etc, and it does not  (read: ‘should not’!) equate to “I’m doing this so I can sit in my bedroom pretending to work making games that only I want to play”. Going indie needs to be approached in a considered, researched and professional manner. You may want to focus on bringing your ideas to reality but nonetheless you need to put time and effort into the commercial aspects of your business. You need to be prepared to do (or find someone who can do) the accounts and other business admin (deal with Companies House, HMRC etc), craft and execute a commercial strategy (what are you selling to who for how much and how?) and you need to force yourself out of your ‘pit’ to go network often.

I come into contact with a lot of young/small games, digital media and technology start-ups, many of whom are founded/staffed by raw graduates. Many mistakes will be made (I’m sure I’ve made them all and will make many more myself) but you can reduce the number of and impact of these mistakes if you are sensible. Here’s a few I would recommend for indie games start-ups:

Have a clear focus: Here’s mine; EVIL27 Games will develop it’s own games for a casual-core audience that are optimized for  tablet devices and which (ultimately) enable players to create, share and recommend user-generated content through social networks. Having a focus doesn’t mean you have to plan to do one thing and one thing only. It’s about knowing what your end goal is, how you plan to reach it and also knowing what you won’t be doing.

Get the balance right: I’m not talking about ‘work-life balance’ (not that this isn’t important!) but rather the balance between the competing draws on your time by the needs of the business and the product (e.g. your game). You may be thinking “we’re nothing without a game”, and in a sense you are right of course, but you won’t get to finish that game and achieve your commercial goals, whatever they may be, without creating a sound foundation for the business. That means managing the cash (and acquiring it), it means filing all the regulatory information on time and it means making sure that there is indeed a ‘business’ at all, not just you and a bunch of friends having fun making games. It’s hard to stay on track with the game development if you are constantly distracted by other things so I personally have adopted a ‘week on/week off’ approach where I spend one week doing all the business admin, sales, finance, marketing, networking etc in order to earn the right to spend a week doing nothing but making the game. If you are professional, organised and manage your time well you may find that the business side only needs maybe 2-3 days – you just earned a few days bonus! Level up!

Set achievable goals: don’t go into this expecting or even hoping that you will create the next App Store or STEAM sensation. If that does happen then you were most probably very lucky (as well as very good!). If you plan for that ultra-big success outcome, you will almost certainly fail. Instead make sure that you have achievable goals on a practical timescale and that you have the financial resources/income to control that. To illustrate this here’s my 2013 goals:

• Build & release game 1 (a 2D iOS/Android puzzle game ). Commercial goals: get company known, master app development and submission process plus learn how to get the best out of 3rd party advertising and promotion services. Hopefully: start building a player community. Will it have ways to derive revenue? Of course. Do I plan for any revenue? No.
• Build & release game #2 (a point & click adventure game with a novel approach to freemium). Commercial goals: get to meaningful revenue generation e.g. it pays some of the (still carefully managed) bills, further enhances the company’s reputation/awareness and increases the contactable player base/community.
• Have commenced development on game#3 (a RTS game with a mobile-friendly approach to ‘modding’ as a central feature): Commercial goals: Position the company with a clear USP (‘mobile modding) and market positioning (mid-core/tablet devices), be on course to hit cashflow and revenue forecasts for year 2.

Network often: I’m not a natural networker. I’m not shy as such but I’m not at my most comfortable in crowds with strangers at professional/commercial events. Does that sound like you? Time to get over it! Force yourself to find and go to industry and related events on a frequent basis. I recommend seeing what events TIGA/UKIE are doing, looking ahead to games conferences (see www.games.confs.com), checking out local university/science park events and general digital, technology exhibitions. Birmingham Science Park Aston, for example, regularly run games and technology events. They are usually free or very cheap. Also, do regular searches on Eventbrite.com and Meetup.com – search for ‘games’ etc and see what comes up. Go along able to say clearly what you are doing, what your company/game is about and why you are doing it. Maybe think about things you may need (concept art, audio, help with QA etc?). I personally aim to go to at least one event per week. If there aren’t any formal events scheduled, then maybe try to arrange to get out and meet another company or game developer. Share ideas. See what they think about what you are doing. See if you can help each other. What goes around comes around, especially in the insular games industry!

Frequent sense-checks: take (regular) time to sit back and examine what you have done and what you are planning to do. A good game needs constant re-visiting, testing, optimizing and, most likely, 90% of the ideas thrown out. So does a business. It’s about refinement; finding what works on perfecting that essence. A game that is packed with every feature you can think of is most likely a bad game. A new/young business that tries to do everything for all people is most likely doomed to failure. You may be one person at home with a PC but if you say you are an indie game developer then you are also a business and you need to accept and embrace that. A business doesn’t make a product or service that there isn’t a decent chance that someone will pay money for. You may not be able to guarantee that but you had better be bloody sure that you have done everything you can to maximize the likelihood of that happening.

Your motivation to ‘go Indie’ may be to make the games you want to make because, ultimately, that is what you enjoy but that doesn’t release you from the reality that you need to do the ‘business stuff’ as well. Being professional is not about ‘selling out’. Look at it this way, even if you hate that aspect, doing it (well) earns you the right to make your game….and the one after that!

Kevin Corti
‘Chief Evil Officer
@kevcorti / @evil27games

Work for Hire – is there a better way?

As we at PIXELearning approach our 7^th year of trading, and with a pretty good picture of the overall sector, I find it strange that there remains, still, a predominance of the ‘work for hire’ business model.

Work for hire might work for professional services where you can charge out, for example, your auditors for $200 an hour because, although some projects will be more challenging than others, a firm will pretty much know what a typical audit engagement will entail. Looking closer to home, a traditional eLearning company will most likely work from a total cost/learner hour or n (development hours)/hour of learning basis and, barring major errors of judgement, be pretty much accurate.

From my experience to date over six years working in this space and spanning 40+ projects ranging from between $5,000 and $500,000, the work for hire model is undesirable for serious games developers and for a multitude of reasons:

[1] Clients are not capable of creating a specification

I have yet to see a specification, RFI or RFP document that clearly articulates the full extent of the client’s requirements in a way that covers organisational goals, instructional objectives,  content/curricula definitions, learning evaluation strategies, business impact/ROI approach, creative brief, technical guidelines and ,, somewhat fundamentally, the game/simulation vision. Some of these will be adequately covered – usually where that aspect is related in some way to what the issuing organisation actually does as its business – but I have never seen a comprehensive document upon which one could base an accurate price.

This is a problem as invariably the developer is required to provide a fixed price based only on the initial RFP information. It takes a brave developer to stand their ground on this issue and even if they do they will very probably lose the contract.

Now I don’t expect that your average insurance, automotive, banking or retail multinational should be able to create a proper serious games specification. Why should they? It isn’t their area of expertise. What I am surprised about is that even now, in 2008, why only a tiny few organisations employ a consultant at the scoping and procurement stage to help them define their true requirements. I would stand up in a court of law and testify that if they did do this they would save money, time and stress and significantly de-risk the project.

So what we end up with is a client that has taken a leap of faith, internal sponsors who have put their reputations (or careers) at risk, the involvement of a wider group of reluctant stakeholders and a developer who now faces delivering upon a project with no defined start point, specification or defined set of deliverables. What they do have is a defined (fixed) project deadline and contract price.

This situation is akin to a builder agreeing to design and build an ‘office’ without knowing where it will be built, using what materials and whether it is to house 10 or 1,000 office workers. Now I probably paint an exaggerated picture here, but I’ll bet that it is an analogy that resonates well with many a developer.

[2] Clients are usually very large. Developers are always minnows

This may not be a situation which is unique to the serious games space but the chances are that, when measured by revenue, balance sheet or head count, most clients will be at least several dozen times bigger than the developer. Often it will be a developer with an annual turnover of less than $2million working for a global multinational firm with revenues in excess of $1 billion. Big does not mean bad but it does mean that on the one hand you have a young, innovative firm with strong technological and creative leanings with a flat management structure and a dynamic ‘can do’ attitude. On the other hand you have a large, slow-moving goliath packed with 9 to 5 ‘staffers’, a risk-averse culture, big company politics, rigid administrative procedures and little or no understanding of what it takes to deliver a successful serious games project.

This clash of cultures can often make for personality clashes and client-vendor communication breakdown if not acutely-well managed. It is also worth noting that if things turn really ugly that the client’s lawyers are bigger than the developers! Managing expectations at both a macro and micro level is crucial. It is also a frustrating diversion when efforts are needed elsewhere.

[3] Design (scoping) comes after agreeing a fixed-price

The developer has agreed a price. The initial scoping, needs assessment and design have been undertaken. Now, however, the client’s project team have had a chance to get up to speed and they want to get creative. They have been shown some prior examples and possibly some prototypes. They have dusted down the SNES and PS1 from the attic and got all excited about the idea of contributing ideas to the game project. They have a much better idea of what is possible and want to get their hands dirty. Everybody gets a buzz out of getting creative and picturing what could be…. but the developer is working on a fixed price and time is tick tick ticking.

The biggest danger here is project creep. The client won’t recognise this as chargeable changes as you are still in the design phase….so no comparison point exists from which to measure change and besides, they engaged with the developer in order to benefit from a creative company to help them flesh out the ideas. “What’s the rush?” they are thinking. Meanwhile, the developer is asking, “where has my margin gone?” and, “how are we going to deliver on time now?”

I have rarely seen a project where the design phase is completed on time. For small discreet mini or casual games-based projects this is less of a problem. For large serious games or immersive learning simulations it is rather more of a challenge.

[4] There are always changes to a signed off design…but rarely extra payment

I spent nearly seven years working in the construction industry for a mechanical and electrical building services engineering firm. We worked rigidly from very detailed specifications, technical designs and Bills of Quantities. If the client’s team (e.g. the architect or design engineer) made a change of any kind then there was a well-understood process of quantifying the time, cost and other implications. The client’s team then, assuming they accepted the costs, issued a formal change request and the contractor (my employer) billed them for the work.

For the serious games developer it is not so easy. Firstly the client nearly always struggles to envisage what the finished application will look like and how it will function until they see it and try it. When they get the early prototypes, alpha and beta releases it gives them the opportunity to ‘suggest’ numerous improvements on the basis that only at this point are they able to appreciate the implications of the written design document.  It is highly unlikely that the developer’s tender bid included an explicit cost for ‘client mind changes’. An iterative approach to software development can be an excellent way of getting a perfect end result from a technical standpoint but it does not make for an easily quantifiable development schedule or controlled costs. Seeing as time deadlines and budgets are the two factors about which they client will most likely fixate upon, it is easy to see how this approach can easily lead to project failure for the developer, the client or both.

Harping back to the ‘clients are large, developers are small’ point, it is very hard for the under-pressure developer to fight to be paid for each and every change irrespective of how legitimate the basis. Refusing to carry out the change will most likely be viewed by the client as deliberate intransigence or even belligerence on the part of the developer and probably a withheld milestone payment.

Most developers, engage don a work for hire model, will seek a gross margin of between 40% and 60% in order to achieve genuine net margins. A project that involves numerous and frequent changes can quite easily go from sound profitability to a loss-making situation for the developer.

It is also fair to say that the client’s project team will nearly always fail to realise the level of impact for what, to them, appear to be very minor changes. A recent client of ours, for example, repeatedly asked us to make changes to some of the in-game characters. These characters featured in many pre-rendered animations.  To the client these seemed to be a quick job for an artist of, I guess, an hour or so. The reality was several weeks of artist time and a cost to the company of a few thousand dollars.

[5] The source code issue

For a developer targeting the learning and development sector this can be a major challenge. Clients for traditional eLearning are used to getting and owning the source code and IP to the finished product. This is not unwarranted as invariably, with eLearning, the end product and the source code are one and the same being made up of HTML, images and static content. JavaScript code to create a drag and drop ‘course interaction’ is hardly likely to form part of a developer’s core intellectual property and enterprise value.

For a serious games developer however, this demand is nearly always untenable. It is rare that a project will not involve some level of prior IP in the form of application code or source assets. These assets are the lifeblood of a serious games developer. They reflect significant R&D, prior capital investment, commercial risk and specialist know-how. Handing that over to a client is akin to commercial suicide yet developers will very often face a major battle on this issue.

The ironic fact is that the source code is practically worthless to the client as they are very unlikely to possess the technical ability to do anything with it. Even a competent 3^rd party developer will face a massive challenge in making sense of the code and the originating developer is hardly likely to help them in that endeavour.

In reality, the client probably only demands the source code because it wants to protect it’s development in the eventuality of the developer going bust. That eventuality can easily be handled by a source code escrow agreement. Philosophically however, the ‘work for hire’ model puts the client in a frame of mind where they feel that obtaining the source code is a normal request.

[6] The ongoing ‘input’ of the well-meaning amateur

This is (usually) a minor threat – and not unique to the WFH model – but when that ‘well-meaning amateur’ is a key member of the client’s team then their desire to input into the technical, creative and instructional design process can easily create problems for the developer.

At best it is a distraction for the developer’s project manager. At worst it ends up causing project delays (which will be seen by outsiders as the developer’s fault) and eating into that profit margin.

[7] The 20:80 rule

This is a reverse of the commonly referenced Pareto’s Rule. Whereas traditional web content or eLearning development is fundamentally linear – meaning clients get to see progress early and consistently – serious games development is all back-ended. A significant proportion of the project timeline is eaten up by design and preparation. Underlying software engineering invariably takes time before it yields demonstrable releases. All of this makes clients nervous as they are being asked to approve milestone payments yet cannot yet play anything.

Serious games projects will almost (always?) be based on milestone payments. Not being able to show anything tangible (in the client’s eyes) makes getting paid in accordance to actual costs incurred, very challenging.

[8] Its hard to create and leverage IP

For a developer to make the transition from a WFH services provider to being an IP holder in it’s own right, significant capital will be required. It is challenging to raise that capital on commercially acceptable terms in good times. The collapse of the private equity markets and the extreme cautiousness of commercial banks (especially towards small companies and start ups) in recent times makes it practically impossible.

It is not in a client’s interest to help the developer achieve this by way of a WFH contract as it complicates the contracting process (the legals get far more complex) and besides if the developers starts to own it’s core IP it can potentially lock the client in (never appealing to the client) and possibly even take the same IP to competitors of the client.

The flip side is that a healthy and sustainable serious games industry would give clients major benefits e.g. stability, innovation and cost reduction through reusability but those are benefits that come from long term thinking and clients, understandably, are driven by the requirements of current projects not possible future ones.

[9] N.D.A. hell

“Seeing is believing,” or so the saying goes. Serious games are a medium that is hard to convey the value of…until you see them and try them. Sales people need to be able to show stuff off in order to generate new leads and close new deals.

Clients do not like that for the understandable reasons that their project is most probably linked to a desired increase in competitive advantage in one way or another. Naturally they do not want their competitors to hear about this.

When it is the client that is funding the project through a WFH model then the developer is always locked into a frustrating Catch 22 situation where their future growth and sustainability depends on sales but it is hard to generate new sales when you cannot demonstrate (or even talk about) your prior experience and project successes.

[10] A fixed gross margin…that shrinks

‘Work for hire’ is very probably going to be on a fixed price basis. The developer will target a gross profit margin that they seek to achieve. Depending on a number of factors (use of prior IP, eagerness of the developer to win the project, direct and overhead cost basis etc) this is likely to be in the 40-60% range.

Whether this works operationally depends a lot on the capital base of the developer (do they have private equity investment and an aggressive growth strategy for example?) their approach to operational resourcing (a fixed-cost internal team or a burstable model based on variable cost contractors and freelancers?) and their underlying overhead cost base. It also depends upon scale. The overhead cost base should be fairly static. The developer will need to achieve a critical volume of profitable projects in order for the gross margin to flow through to cover (and hopefully exceed) the overhead costs.

Delays to projects starting, design creep, post-design feature creep and other factors will occur and will therefore eat into this gross margin. The danger is that this makes it very hard to cover the overhead base at times and the finance director and company owners will find this very uncomfortable.

[11] Projects fall into fiscal quarters

Big companies think in quarters. Invariably the required project timeline will be either three months or, if the developer is lucky, six months. We often think in terms of the 40:40:20 rule. That is 40% of the project time for design, 40% for core development and 20% for final QA and integration. Given the peculiar hybrid of skills, experience and content that goes into a serious game project and thus, the wide number of people involved in it on the client side (who all have day jobs) it is very hard to create and agree a robust design in anything less than two months.

Starting development for a three month project in month three is project suicide. Starting development on a large project without a robust, signed-off design is also project suicide. Inevitably this leads to a project delay of anything up to 50%. Whilst internal client stakeholders will feel the heat from their superiors, it is hard for the developer to overcome the perception that they are the cause of a ‘slippage’.

Invariably what this pressure leads to is an iteratively created design and for a substantial proportion of the design and development activities being run in parallel. The likelihood of achieving this without frequent design and/or development changes, delays to the process (whilst the developer awaits client sign off, content or clarification on a design aspect) are going to occur no matter how much effort the developer puts micro managing the project.

So, clearly I am not a strong advocate of a work for hire business model for the serious games space. The question is what are the alternatives and is it even possible for the development community to adopt these?

Answers on a stamped, addressed postcard please!