Excerpt: Mobile Game Development - Going Into Production

Key Chapter Questions

What are the pros and cons of being a third-party studio vs. independent developer?
What are the key members of a development team?
How can you keep a game from getting too big to finish?
What is the average time to market for an indie game?
How can going solo affect design choices?

Every mobile game is different, and the production process is sometimes reinvented to fit the resources and staff on hand. Budding game designers often carry notebooks full of ideas-some questionable, some with potential, and perhaps one that might change the world of games as we know it.

Putting an idea into action can get a little scary sometimes, especially for those who are experiencing their "first runs" at being producers. Game production involves managing the hands-on, moment-to-moment development process and working with a team-encouraging, cajoling, and occasionally shouting (but hopefully not too often) to bring a project to fruition. Even an indie developer must understand the needs of the team members. Indie projects are sometimes developed after hours-in the dim time between the day job and before the alarm screams again. Due to this reality, there are special considerations and precautions that should be taken.

Development Phases

The production process for mobile games is different from what is seen in "formal" video game development for console and computer platforms. In traditional game development, there is a "mandate" to make sure the entire product is perfect and complete before it ships-but in mobile games, there is a much greater degree of flexibility. Game elements can be added and expanded upon for months or sometimes even years after a product is released into the market. Gone are the thousand-page design documents with reams of technical detail. Instead, mobile teams use limited documentation that is flexible and changes dynamically on a regular basis. While traditional console games might take years to complete, the entire mobile game production cycle might take place within just a few months.

Pre-Production

Whether the developer is a single-person studio or an in-house team, pre-production is the phase in which what game will be produced and how are both decided. What elements and functions need to be included and at what point can the game be released? The pre-production phase involves setting a "plan of attack." Keep in mind that for mobile, this master plan must stay flexible-so rather than building out an entire production plan (which is often done for a console title), focus instead on individual functionalities and break the project down into small chunks that can be completed and checked off the ‘to do' list.

Production

During the production phase, the goal is to get the game up and running as quickly as possible in one form or another; this is a key component to solving unseen design issues. In an ideal situation, the goal is to have a working build of the game functions every week or two; this means that the product as a whole is constantly being prototyped, rather than having a single distinct phase for the process.

Alpha & Beta

Traditionally, by the alpha phase, the game is code complete-playable from start to finish, with all art assets in place. Not everything is necessarily final; there may still be a few bits and pieces here and there that need improvement. This is where the team makes a shift from game creation to game refinement. Code is locked, and the majority of time is spent making the game as polished and complete as possible. This is one of the major divergent points from more traditional game design. With a console-based product (3DS or PSVita) with a longer development cycle, the Alpha and Beta stages are more clearly defined-but with mobile projects, these stages tend to get mashed together. The end goal for mobile is a viable, shippable product that can be polished as needed through updates after it has been released.

Gold

Goooooooooooooooooooooooooold! If you're working with console style handhelds, Gold is still the standard: A complete, finished, shiny product is needed for delivery; once it goes out the door, there are only very limited opportunities to change it. However, the Gold stage has become indistinct in mobile releases. Getting a product into the app store is paramount-so if it ships with a few issues, there is still an opportunity to push updates and changes that allow for fixes and upgrades.

Post-Production

Wait-there's more? Even after a mobile product is pushed out the door, there are still changes to be made. By reviewing the metrics (information collected about player habits and monetization), the design team can see where players have issues with the product, where they might be getting stuck, or how long they play before the put the game down. These elements drive changes to the design that can then be iterated upon and pushed back out as updates (the mobile version of "patches") to an installed user base.

Agile Development

The production process for games is constantly evolving. Traditional processes derived from manufacturing and product development just can't keep up with the ultra-high-speed pace of mobile development. These methods were reinvented by game developers working with console and PC products. For mobile game development, these processes are still a bit on the slow side and need some modification if they are going to work. The game industry has a long history of reinventing any process that gets in the way of the intended result-and the mobile game industry is no different.


Games for mobile tend to work better when utilizing an Agile development process-a type of software development methodology that involves incremental and iterative components, focusing more on response to change and team members rather than tools and plans. Due to the relatively small team sizes, Agile processes such as iteration become much quicker and simpler to manage. Instead of being pushed forward at the same rate, the entire product is instead broken down into smaller pieces. As each game element is taken from the list of "to-do" items and put into production, the prototyping of that individual element is handled-which results in the occurrence of some sort of prototyping process on an ongoing basis.

Scrum

Scrum is one of the more broadly known of the Agile development processes. In a nutshell, it is a predefined framework designed to allow a single, cross-disciplinary team to be able to work aggressively and iteratively-producing many versions of a product during its development cycle. The product is broken down into "stories," and the development of those stories is further broken down into "sprints"-with team members pushing one element forward to completion, then returning to the backlog of stories to reassess the remaining tasks and choosing the next element to "sprint" on.


Scrum is a teachable process-and a studio might hire a producer who holds a Scrum Master Certificate or bring in an outside expert to teach an entire production team how to work within a Scrum framework. However, while Scrum works well for large studio teams, it is still a bit unwieldy for the speed at which mobile development operates. Many studios have adapted the Scrum methodology by integrating it with other models to create hybridized production methods that suit their own needs and ideals.

Kanban

Part of JIT (just in time) production-developed by Japanese businessman, Taiichi Ohno-Kanban is a scheduling system that yields larger pieces reflecting several interrelated elements. In most Agile systems, these pieces are pushed to full functionality; the developers then return to the "to-do" list to start on another piece, rather than trying to push production on the entire piece of software forward at the same pace. Kanban begins like Scrum, with the needs and wants of the client determined by assembling a list of "stories"; it also allows features to move from the left of the board (where they are essentially still ideas or stories) to the right (where they are declared completed). However, unlike Scrum, Kanban allows elements to move back toward the left if more time is needed, whether during production or another part of the development process; it also makes room for urgent components-elements that can be fast-tracked to rise to the top of the queue and pass through production on a high-priority basis.


Just like any good production methodology, even the "named" forms of Agile development (there are a great many ways to develop using an Agile process, but not all of them are common enough to be given names or be taught in a formal setting) maintain some flexibility and can be adjusted to better fit the team in question. Keep in mind that Agile is a production philosophy, rather than a hard and fast set of rules.

Development Team Roles

Although setting up a development team depends on a number of factors, mobile-specific issues are surprisingly not that relevant early on. Most game design elements are still important, but they're just abbreviated due to device constraints. One of the attractions in developing for a mobile title is that it's unnecessary to have a large team-due to the relative speed of development and simplicity of design. In fact, an entire game can be developed with just a single individual, one laptop, and a dream. However even a single developer must be able to distinguish between different production team roles and how they all fit together in order to lay out a proper plan of attack.


Management

The key management position in a development studio is often the producer, who is responsible for making things happen and ensuring that everything ships on schedule. In the case of a mobile title, the producer could also be anyone from a team lead (design, art, programming) to the marketing director. For very small and indie studios, the producer often ends up being the person who initially developed the concept (often the designer). This can be a difficult job to juggle-but in the case of a two- or three-person team, it becomes a necessity.

Within a larger studio, particularly when sharing resources across multiple projects, the producer position becomes an absolute essential. Even then, it is not always possible to have a wholly dedicated team-particularly in mobile where development times are short, and a single product may need to be pushed out across several thousand devices simultaneously.


Design

In a smaller studio, game design is almost always doubled up with another role. The primary role of the game designer, regardless of the studio's size, is to not only create the initial concept of the game but to work with the rest of the team to develop and incorporate any fixes, changes, and new discoveries into the game design as seamlessly as possible.


Programming

In full-scale games, programming tasks are broken down across multiple disciplines (e.g., graphics, audio, artificial intelligence, engine, tools, network). In mobile, programming teams usually max out at two and more commonly involve just a single programmer. The exception to the rule is when teams program engines for licensing purposes (e.g., GameSalad, Unity).

Art

In full-scale game development, art involves specializations (e.g., concept, texturing, modeling, animation, character, environment). The industry has rapidly moved away from a few generalists handling all aspects of art production into massive specialization. In contrast, a mobile artist needs to have a "jack of all trades" mentality. In mobile, a single artist often handles concept art and all aspects of the in-game art-from the title screen and backgrounds to cinematics and cut-scenes.


Audio

Regrettably, audio in mobile games is still in its infancy. With small budgets and tight time constraints, audio is sometimes "kludged" together by a team member. In larger, publisher-backed titles-including stripped-down versions of existing console titles such as Assassin's Creed-the audio has already been produced for the larger game and can be re-tasked as needed. The good news is that more audio professionals are getting involved in mobile games-and indie developers are beginning to understand the importance of high-quality music, sound design, and dialogue in their games.

Testing & Quality Assurance

Testing and quality assurance (QA) (whether internal or external) does exist in mobile games. Even single-person micro studios hand the game around to a group of friends and let them bang on it for a while to be sure the worst of the bugs are found. Publisher-backed studios often have access to a more extensive and formalized QA group for testing. Without this luxury, the primary QA tasks need to be handled by the existing team members. Mobile developers can distribute iOS apps wirelessly for "ad hoc" testing purposes-and recipients are easily able to install these pre-releases. TestFlight has further refined this process by letting developers invite testers via email and see who has tested which builds. Android developers can put their Beta builds on the Android Market or send the APK to any number of people who can then side load it onto their systems. When using this method, it's a good idea to build a mechanism within the game so that the testers can easily provide feedback.


Scale & Scope

Mobile games need to be smaller in both scale and scope. In traditional game development, it is often said that "more is better"-and many developers begin with a larger, grander idea that is trimmed to fit within constraints. In contrast, many mobile developers prefer to "keep it simple"; by initially focusing on mechanics-the nuts and bolts of gameplay-the design process naturally provides constraints than help to keep the game on task.

Feature Creep

Feature creep, sometimes called scope creep or "featuritis," has been the death of more great game concepts than anyone is willing to reveal. The producer and game designer need to spend time engaging in scope control-reining in scope creep and ensuring that the team focuses on the core elements of the game-with additional features kept on a separate "feature list" in case there is time and budget to add them later. Any new feature or design element must be carefully evaluated with two questions in mind:

Will including it positively affect the gameplay?
Will omitting it hurt the game?

If the new feature will negatively affect the game or will not be absolutely essential to it, then it should not be added to the feature list.

Time to Market

Mobile games are quick to conceptualize and develop-and they're also fast to hit the market, bloom, and fade away. It's a known fact in software development that 10 people cannot dig a hole 10 times faster than a single person. The more people that are added to any given project, the more it will slow down simply due to supporting the project (e.g., everyone plays well together, all the ducks are in a row, Programmer A delivers code that works well with Programmer B's interface, artists deliver assets that fit with the overall visual style). The more complex the team, the easier it is to break something. Time to market alone in mobile games necessitates smaller, faster, more Agile team structures-even within the confines of large publishing houses.

Going Solo

It's 2:00 A.M., and the very last build complies without a hitch. There's no boss to call, and no milestones to meet. It's just you, with your trusty code library and all the coffee you can drink. Sound like a dream job? With the advent of app stores that are specific to a single smartphone, the market for individual and independent developers has broken wide open.

Individual Scope

In theory, there is no limit to what can be done with mobile games as a lone developer. However, to see a return-which should at least cover the costs of coffee and sugar packets consumed during development-it's important for lone developers to pick and choose their battles. Develop quickly and cleanly-and keep developing. Producing, developing, and publishing a single game is an achievement that not just anyone can match-and the second game is even more difficult to finish. Single developers or even very small teams who earn incomes doing this often push beyond that single title. First, it's important to decide just why you're doing this. Is it because you love games? Do you have the coolest idea ever and the programming skills to back it up? Are you looking at this as your entré into the larger world of game development? Fame and glory? Money? Bragging rights? The look on your dad's face when you download your game onto his new iPhone?



The exact reasons don't matter, but it's important to know what they are. Your games will need to address these reasons, or the great swampy middle of the development process will bring you to a standstill.

Design Choices

Going solo means working within your own capabilities. If you have a full-time job and are building games as a hobby in your spare time, make sure to "keep it simple" by first creating a game you know you can finish. Keep in mind that a complex game isn't necessarily going to be better. Elements such as gameplay, platform suitability, short entertaining play sessions are the hallmarks of great mobile games. Puzzle and physics games are often perfect starting choices, since there are so many great examples available that can be created using a very simple set of rules.

Platforms

The Android, iPhone, Windows Phone, and BlackBerry hardware platforms are best suited for individual or small-team developers. This is due primarily to the relative ease of publication and distribution on these platforms. With handheld devices such as the PSVita and 3DS, the environment is much more hostile to individual or small-team developers-in part due to the licensing and development kit costs involved.

iPhone

Developing for the iPhone requires registering as an iPhone developer. This allows access to iPhone developer forums, software needed to develop titles, sample code, instructional materials-almost everything needed outside of the original game concept itself. One of the greatest benefits of developing for the iPhone is the limited number of devices that the developer needs to address.

Android

Android is the new kid on the block. The operating system was developed by Google and is available on devices from a number of different manufacturers. And therein lies the rub: While the Android is an extremely open system, and the Android Market approval process is swift and straightforward, the game must be run on several different devices-each with slightly different configurations.

Windows Phone

Developing for Windows Phone is similar to developing for the Android operating system. There are many different Windows Phone devices on the market-but due to the relatively closed nature of the Windows Phone OS, there may be less variation among them.

BlackBerry

With a limited set of devices available on the market, the BlackBerry has something in common with the iPhone. Much like Apple, the differences in these devices are largely generational rather than related to hardware customization for specific carriers-so it's possible to develop and test on just one or two devices rather than a dozen or more.

Publishing

For each development platform, there is an individual publishing process required to make the game or application available for all to see. Until the broader adoption of platform-specific stores such as the Android Market and Apple App Store, distribution for mobile titles was primarily handled through a carrier-specific mobile store referred to as a carrier deck-and a rotating list of titles was promoted and distributed by a mobile carrier through its own purchasing option. Verizon's "Get It Now" is one of the widest known examples.

Since many carriers require developers to support a large number of their devices, often all with different operating systems and requirements, this process becomes prohibitive for individual or small-team developers. In an attempt to push applications designed specifically for their own devices, several manufacturers launched their own, smartphone-specific stores (e.g., BlackBerry's App World-which could be found through the associated web site, but not directly through the phone). The manufacturers didn't have as much ability to push applications developed for their devices; consumers still needed to either go through the carrier's deck, the web or other sources to find and download the programs they wanted. The direct link from the phone to the manufacturer wasn't there.

Independent mobile developers are faced with the question of just where to publish. There have been a number of smaller web sites that will allow sales of games and applications designed for a single device, but these sites also have no quality control; in some cases, site operators don't even check to be sure an application downloads and plays on the advertised smartphones. These content aggregation sites also contain games by larger publishers that have slipped off the carrier decks because they either weren't generating enough revenue to be worth the associated fees or had outlived their life cycles.

For a game to have a chance, it needs to be available through OS-specific app stores: Apple App Store (Apple), App World (BlackBerry), Android Marketplace (Android), and Windows Phone Marketplace (Microsoft). Each of these outlets has a separate publication process, and all submitted games will undergo a review in some form or another. Registered developers for any of these operating systems have access to the associated app store publication requirements and processes-and they should read and understand the most current set of restrictions. For example, Apple is continually refining and modifying its restrictions for publication based on consumer feedback and Apple App Store abuses. Developers interested in pushing the acceptable boundaries of the iPhone and iPad run the risk of getting an app pulled if these rules shift to the more conservative.

Studio Development

Starting a development studio comes with its own set of problems, not the least of which is funding. It is a common misconception among new developers that having a contract in hand with a publisher is enough to get up and running-but most of the time, putting together a formal development studio requires upfront capital in the form of cash funding or sweat equity (working for free for the first game or two until capital increases enough to allow for a more formal salary arrangement).

Needless to say, starting a studio with a fat wad of cash is a lot easier than bootstrapping (discussed in the Financing section). Although there are many enthusiastic new developers who are willing to take financial risks, one of the biggest sticking points across the board is the need to eat; this means getting or keeping a day job, freelance work or other opportunities that will interfere with game development time and may result in the loss of team members at some point during production. Many studios launch with the promise of an equity share in the games expected to be released, but this also means that developers aren't paid until months after products ship.

One advantage of mobile games is the speed of development. The time commitment to develop a game is usually less than six months and can often drop into weeks depending on the simplicity of the title. This means it's possible to develop a game using the good graces and spare time of the other team members, but it doesn't mean that a whole catalogue of games should be developed the same way!

One-hit wonders are as common in mobile games as they are in traditional console and computer games-and even high-quality games aren't always enough to ensure long-term sustainability (Pictured: Marroni's iBailout!! and BurstStudio's Kitten Cannon).

Office Space vs. Virtual Team Building

There are advantages and disadvantages to leasing office space and working out of a home office with a distributed (or "virtual") team. On one hand, having a virtual team means you don't have to pay the overhead; all team members function as independent contractors, maintaining their own equipment and holding responsibility for their own piece of the project. Meetings can be held on a weekly or even daily basis via various types of multi-party or multi-location conference software and systems (e.g., Skype, WebEx, Google+ Hangouts). A virtual setup requires more discipline and greater personal responsibility on the part of the team members-who must be relied upon to do the work with only limited oversight. If something goes wrong and they stop returning phone calls or vanish from the virtual space, how will you handle this? Drive to their house and camp out on the front lawn? When building a virtual team, it's necessary to have controls in place-including checking art and code assets in and out each day from a common location (whether online through version-control software such as Assembla or Google Docs, or on a private company server). If a team member suffers a personal tragedy (or if the programmer goes to Burning Man and comes back having eschewed all technology), the damage to the project will be minimal. If there's a centralized office space where everyone physically puts in their time-even if it's the basement of your grandmother's house-the discipline is imposed from the outside. All the resources and materials are in one place-and when someone fails to show up for work, everyone else will notice.

Keep in mind that there is a difference between an independent contractor and an employee. Be sure you know the rules, even if you and two of your best buddies have all agreed verbally to work "on spec" for the time being. For example, California workers are classified as employees when they're required to work in the company's office space (even if it's in a private home) at set hours each day on company equipment. Although everyone might be "best friends" when the studio starts up, this might change as time goes on-and one employment-related lawsuit can break a struggling startup.

Profit Share vs. Salary

There are two key issues to consider when bringing on developers to work for profit share, rather than cash or a salary.

1. The return is likely to be very small. Becoming a sustainable mobile game developer isn't so much about having one hit title but developing a long string of moderately successful or even low producing titles that continue to trickle in cash over a long period of time. This means that the return on investment (ROI) for any individual team member may be fairly low-especially if there are several different people each working on just one game each. While the return over time may cover development costs, the length of time it takes to see a return can simply be just too long for your team members to stick around.

2. If all the revenue is divided up among the team members, it's not going back into the company. Sustainability means continuing to pay employees for a while even if there is no new work coming in. This type of sustainability means that a developer can publish original games when it isn't working with a publisher on a third-party title. There's an "ebb and flow" associated with publishing contracts; no matter who you know or how many friends you might have in the industry, the timing might just be off-and your company must have the working capital to survive the shortfall. If you've promised it all away, then it will be necessary to come up with a plan to survive or close your doors. The world of game development is littered with the corpses of studios whose founders came together to develop a game for a publisher but were unable to land a second title quickly enough to keep the momentum going.

Financing

Financing is the great sticky wicket of forming any company. In games in particular, actual saleable assets (tangible and intangible items an investor might guarantee against in case of failure) are extremely limited: A handful of computers that will be obsolete in a year, any devkits that have been purchased, and lots of great ideas. (Don't be fooled: There are countless great ideas out there-and having one or even 100 in the company's portfolio doesn't mean it has any value!)


Investors

Intellectual property only becomes valuable after it's been developed-so unless a prototype has already been created, a company must have something more to offer that's worth the investment. Every so often, this company or that company is reported to have secured $10 million or upwards of $30 million in venture capital financing. Most of the time, these companies are already established-with products and processes in place, a management team with years of successful shipped games at well-known companies, or some sort of track record that gives investors confidence.

An angel investor is the first choice for companies that are just starting out; "angels" are usually individuals who invest $50,000, $100,000 or even $500,000 (usually under $1 million) in a small company for a big fat return in a few years. The best way to meet an angel investor is through an introduction-preferably by someone that has already done business with them. There are also investment summits and conferences that provide opportunities to network with small investors. Angels actively looking for investments are often willing to talk directly with visionary entrepreneurs who are willing to shake things up.

Out-of-Pocket

The majority of small, formal studios get started with out-of-pocket funding. Perhaps either you've saved up the funding to begin production on a game, you've been a part of a previous startup that was bought out, or you have a wealthy uncle who passed away and left you his prize collection of Victorian-era spittoons; for one reason or another, the cash is in hand to get the process started. This might look at first like total freedom-but your investment could run dry very quickly. It's important to consider the time it will take to secure contracts to continue doing business. Staff lightly at the outset; mobile games in particular take far fewer people to build, so start out with a single programmer and move up from there as the contracts get lined up.

Bootstrapping

Bootstrapping is most common in single developer situations; it's difficult to get four or five passionate people together who are financially secure enough to work on an unfunded project. However, if investors and out-of-pocket funding are not options, consider bootstrapping one or two very small projects as a single developer until enough cash can be saved to grow the company through self-funding. At that point, other financing options might be on the table-if they're still needed!

After assembling a team and growing a game development studio, it will be time to make a decision. Will you sustain a "lifestyle" business (one intended to support the founders/employees for as long as possible)-or will you make a play for bigger money by selling to a larger firm? In mobile development, both of these are equally viable options-but if you have pulled in an outside investor, then the bigger play is where you want to be looking.

The Fast & the Flexible

When it comes to production, mobile games move faster and require a lot more flexibility during the development process than more traditional console or PC games. The same key roles and elements are there, but they're handled in significantly different ways. Especially important is the overall flexibility of the mobile production process. Due to the way mobile games continue to evolve based on player feedback and metrics gathering processes, a single game may go through the production process multiple times over the course of its life.

Fonte:gamecareerguide