Copy

The Lazy Designer Book 2: The Next Game

Hello!

I'm sorry for the long delay since the previous newsletter but I have been going through a major life event, which I've talked a bit about on my blog. 

I'd like to resume regular service, so I'm starting with the first excerpt from book two in the Lazy Designer series.

(On a side-note I've also returned to working in the games industry and I hope to talk more about that in the coming months!)

So let's get to it:

 Overview

In previous chapters I wrote under the assumption that you were thrown onto a project midway through production and had little say in the core design of the project. Here I will tackle things from a different angle... imagine you are on a project that is just beginning. You might not be the design lead or even a senior designer but you, along with your other coworkers, will be involved with developing and fleshing out the gameplay for this new title.
 

 What Game Will Be Made?                                                                               

A question I am asked often by outsiders is how a studio decides on which game to make. Sometimes this question is driven by the outsider's hope (a hope very much misplaced) that game studios are sitting around and waiting for the perfect new game pitch before they start their next project. Other times the question is more of an attempt to find out why a particular title was made instead of another.
So, what is the answer?
Well, what I can tell you is that even as the lead designer of several titles I only ever influenced the direction of a game. I never pitched my game or developed a game concept completely from scratch. In a large studio even senior leads might be only tangentially involved in the choice of which game to make, the decision resting at higher levels of management. On the other hand in a small indie house more of the team will likely be involved in the decision.
Even if you are not directly involved in this decision making it is advantageous for you to understand why the decision makers choose a particular path over another.
Developer and Publisher
I want to step back a moment to clarify the relationship between a developer and a publisher.
A developer is the company that builds the game, whether entirely on their own or assisted by various contracts with other companies (i.e., a development studio might outsource their art but do programming and design in studio).
A publisher distributes a finished game. Traditionally publishers had deals with major stores and controlled distribution. If you wanted your game on a shelf in Best Buy you had to have a publisher. Also the publisher would handle packaging, localization (usually) and marketing (sometimes).
The lines are blurred now because through portals like the App Store on iOS devices game developers can reach gamers directly. But for most major titles the traditional publisher-developer relationship still exists.
For the first few years of my employment with them BioWare was an independent developer making deals with various publishers to publish their games (i.e., Interplay, Atari, Lucasarts). Eventually, as happens to many developers, BioWare was purchased by a publisher (Electronic Arts) so they have merged.
Why Make *This* Game?
Let's discuss some of the more salient points when it comes to deciding which game to build. How is a particular concept chosen?
  • Sequel Perhaps a game the company has recently shipped has done well enough commercially to justify a sequel (or a sequel was in the works to begin with). This is the easiest game to justify. Companies want to build upon past success.
  • Gameplay/Technology Maybe somebody in the company has created a compelling new gameplay feature. This might be gameplay spun-off from another project that did not use it or the company may have access to a new game engine and are looking for a suitable design concept to exploit the technology.
  • Wish Fulfillment Sometimes a key stakeholder in the company has had a vision of a game for a long time and feels the company is finally in a position to make the game. They have already done the initial legwork to build support for the title and will likely have a great deal of expectations and past documentation/ideas that will influence the initial design.
  • Setting Opportunity Your company might have been approached (or approached) a third party and has been granted a license to make a game based on prominent intellectual property. This might be a game set in the Dungeons and Dragons universe or a Star Trek title, for example. For a small studio an opportunity like this is a great way to build exposure. There are a few things to consider here.
    • What do you want out of your setting? If you want to tell deep stories with branching plot arcs and grim but realistic characters the choice of setting has to support this. Likewise if your gameplay will be more similar to the light-hearted actions from a comic book then you should not choose a dour and depressing setting.
    • Does the setting you choose give you room to grow? Does it support the gameplay you want? A Mario-like side-scrolling game about jumping, for example, might feel out of place in a setting like George R.R. Martin's dark fantasy series.
    • Look for a setting that allows the art style to be distinctive and something that stands out from other games on the market.
    • Watch out for a setting that has heavy fan bias. It might seem attractive to develop a game for a niche setting that while relatively popular is not so hugely popular that it would be impossible for a small studio to obtain the game rights for it. The danger of these smaller franchises is that in addition to the franchise being unable to give you a large pool of potential customers, the fans it does have could be incredibly vocal. If they do not like the design direction you are taking with their franchise they can make development difficult.
Very often answering why will lead directly into answering what kind of game needs to be made.

Expectations

During the early planning genre (both in terms of gameplay, such as RTS or First Person Shooter and in setting, such as fantasy or science fiction) needs to be locked down. That does not mean every detail of gameplay will be solidified during the initial decision making but the broad strokes will be painted. This title will either be a game about controlling and managing multiple medieval battle units in battle against opponents or you will be playing a single character traversing hostile territory on a derelict spaceship. Or something else.
There are caveats to keep in mind when choosing genre however. Your company may have a predilection towards a particular genre of play and if the new game being considered has a radically different style of gameplay it is likely that the company's existing fan base will have some expectation that gameplay will resemble past titles.
This is where new studios have some advantages over others... once a company has success it starts to become known for a particular brand of gameplay and when it deviates from that it risks alienating its customer base (or at the very least rousing the customer base to vocal and distracting protest). These expectations influence more than just the genre and major gameplay... expectations define everything about the title.
And not just fan expectations but also internal expectations. Often these internal expectations are even more distracting because they are not necessarily codified anywhere. You have to ferret them out.
How do you do that?
Talk to team members who have been around longer than you. Find out what their experience has been in the past. This is important to avoid wasted effort. I've seen situations where a content generator has felt they have been given free reign to do something new only to find that their weeks or months of work has been wasted. Because of an unspoken requirement. An expectation that they did not fulfill.
You have to really understand not just what you are being asked to but also why. Often what is not said is more important that what has been said.
(And yes, this is a problem of communication... in a studio that communicates perfectly the unspoken will seldom be an issue... but I'm not sure how many perfect studios exist.)
At different stages in BioWare's evolution as a studio there were different mandates. Occasionally these were explicitly defined (such as being aware of how much time would be spent in combat versus exploration versus dialog). But there were invisible requirements as well — the requirement of a world map or the ability to never accidentally lose important plot items... even being able to have a particular in-game appearance was important. Often these sacred cows seemed unimportant but they were all pieces of a puzzle that somehow together manifested an overall BioWare experience.
Everything that is put into the game affects how player's perceive the game. For example if you are creating an online game with the hope that players will cooperate then you need emphasize design features that encourage cooperation and remove features that discourage cooperation. It might seem simple but it is not. Cause and effect can be murky when there are dozens of features influencing one another. It can be difficult to anticipate how particular features will be used... simply adding features X, Y, and Z is no guarantee of success. This is where your own expectations, as a designer, need to be analyzed.
And so that it does not go unmentioned, the concept of time and scale always needs to be realized when making choices. A game that ramps up to a hundred plus team members on a five year development cycle needs to be a fundamentally different game than the game made with twenty people in six months. These two different teams cannot possibly make (and should not attempt) the same game. The schedule itself is a form of expectation that you, as designer, need to be aware of.

Platform Choice                                                                                                                                                    

The question of platform should be addressed before any serious design work proceeds. It is possible to port games to various platforms but understanding the key markets — which platforms are most lucrative for your particular type of game — is essential because it influences how players will expect gameplay to function in your game. You might deviate — that is, not fulfill the player's expectations — on some features but on the balance expectations must match deliverables or the game will feel wrong and may not succeed financially or critically.
In many ways the choice of platform should define the way the game plays and as designer you should emphasize the strengths of the platform while minimizing the weaknesses.
Evaluating the Platform
Often the studio leads, or other management, will have already decided which platform(s) the game will ship on, and often, which platform will be the most important platform. If this is the case the design group has a couple of options.
1 - Plan around management's decision
As long as you (mostly) agree with the decision the most efficient strategy is to analyze the platforms being requested and tease out the key requirements that your game will need to fulfill to be successful. At this point it is important to have an idea of sales expectations from management across the various platforms and an idea of what the budget for the title will be. Though you are not the project manager it is advantageous to have a general idea of where money should be spent. Another way of looking at it: you need to know where sacrifices need (and should) be made.
When assessing feature inclusion you will want to focus on the features that are going to make the dominant platform most successful. Features that will increase the playability on lower priority platforms should then be marked as optional... but keep in mind that to have any success at all on the other platforms (and to avoid low critic scores) you still need to deliver a satisfying minimum slate of features on the other platforms. More important you must make sure you do not omit an expected feature. If a game is of a specific genre with specific expectations you must ship with that expected feature (i.e., multi-selecting units in a real time strategy game). Otherwise you will be (justly) accused of neglecting that audience.
Sometimes it might even make sense to drop a lower priority platform to avoid such negative attention.
You need to build strong gameplay on all platforms so rank features essential to that goal as mandatory. Then you branch out, prioritizing optional features that will make each individual platform even more enjoyable. Not all of these features will make it in... but where possible prototypes should be built so that decision makers on the project can assess them. Sometimes an optional but low cost feature that greatly improves a particular platform's experience might become a mandatory feature if prototype gameplay demonstrates its importance. There will be more discussion on prototyping in CHAPTER 7.
2 - Contest the decision
This is trickier territory but sometimes company's make bad choices and if you feel strongly that they have made a poor decision in regards to platform choice you may be compelled to advocate against it. How do you do this? Well, all of the details in the previous section apply, in regards to assessing feature inclusion and so on, but now you are using those details not to build a game but to make a case for this particular game not to be made on this platform.
How you present this depends on your position in the company. If you are a junior member of the team your responsibility extends to presenting a short report to your immediate manager, with clear and concise points, and if possible, actual facts and data supporting your conclusion. You should not go off with other team members and start planning a revolution. Handle your disagreement with maturity and save venting for other venues. If your manager does not pursue this it is best to drop the issue unless you truly have concrete data that suggests the company will implode if they continue this route (which I imagine is unlikely).
If you are the manager and have either received such a protest report or have reservations yourself about the decision you need to develop a more elaborate report, showing the pros and cons of management's decision. And you need data.... whether it is market research or an accounting of internal resources. If possible you need to present alternatives that will still satisfy management.
For example if you do not think it is possible for the title to lead with an XBOX 360 version of the game because the company lacks experience on that platform, you might present a hiring plan that allows a spin-off version of the game a year past the initial ship date on other platforms. Simply saying "this will not work" is never going to win arguments. If management wants to reach a particular destination they might be persuaded to take a longer, more reasonable path towards it but they'll seldom be convinced to abandon it completely.
Which Platforms are Good For What
As mentioned every platform has strengths and weaknesses. When assessing the various platforms it is a good idea to know some details about what the game will be like.
  • Long Games If the game requires concentration over a long period of time it may be best suited for a PC or console audience. As a rule of thumb the longer the intended gameplay experience the more comfortable the gaming environment should be. If the player is expected to concentrate or make notes, the PC, in an office environment, tends to be the ideal gaming location. If you intend the player to sit still for twelve hours and be engrossed in the experience, a small, mobile screen is likely not the primary platform for your game.
  • Pick up and Go Mobile devices such as iPhones, Android phones and such are great for delivering pick-up-and-go games — games that are played in small chunks of time throughout the day. Players are quite comfortable pulling the game out for a few minutes, playing a level, and then putting the game away. Mobile games should support, even embrace, this style of gameplay. Web-based games are also good venues for this style of game as a player can leap out of work for a few minutes, play a round in the game, and then return to work (not that I am advocating playing games at work... but it happens).
  • Competitive All platforms work well for competitive games, especially when wireless networks are available (for mobile platforms). It can generally be assumed that a console game might be more open for in person social interaction than a PC game (simply because the console is likely to be in a living room or entertainment room while the PC is in a room less beneficial to having a crowd around the screen). Therefore it might make more sense for a console game to allow multiple players to play split screen, for example, at the same time whereas that feature is of lower priority on a PC, which should focus more, when competition is desired, on having a strong multiplayer component.
  • Cooperative Games Mobile games are a great venue for cooperative games, especially those played by multiple players in the same location. They can take advantage of real world cues — such as facial expressions and posture — to facilitate cooperation (i.e., imagine kids on a lunch field, are looking over the shoulder of a player and commenting on the experience). These games might involve passing a single mobile device around among multiple users or users pairing up, each with their own device, to undertake a short-term activity together on a wireless network.
  • Social Games Again mobile devices excel at facilitating social contact. The other platforms can certainly support this style of gameplay but mobility allows games to integrate real world experience (where I have gone, what I have taken pictures of, what I have heard, et cetera) into the gameplay experience but augmented through the use of the mobile device (i.e., FourSquare).
Even if you are an indie developer, working on your own, considering the above points is still important. Your brilliant new game concept might in fact be brilliant but your intended platform maybe will not allow you to make it as playable as it should be. This is a danger with porting the wrong game concept onto a mobile device, for example, or striving for a AAA quality PC title when you could have taken the brilliant gameplay and made a simpler, and less costly, iOS version.
As an example, I'm still building games but they are always just for myself or my family... I have no intentions of polishing them to a level to be presented to a wider audience. But I still always sit down when I have a new concept and assess, with a simple pros and cons list, the best platform for the concept.
If its a game I want to be able to play from any of my various devices then I'll make a web app, using HTML5, which has a wide range of distribution. If it is a specific type of game, like a recent math-challenge game I created for the kids, I investigate which platform will be best to encourage the skills I want to encourage.

Digital Rights Management (DRM)                                                                                                                     

DRM is a layer of protective software that is used to protect some games (and other content like eBooks or mp3 files) from being copied (i.e, pirated). Many consumers are concerned about the use of DRM on what they buy. Because DRM depends on the target device being able to authorize the content on that device, it can often mean that a game you bought for your current computer might not work on your next computer.
Here's an excerpt from a post I did on the topic a couple years ago illuminating how DRM affected me with eBooks:
When I bought my first hand held computer (PDA) I immediately started downloading various book readers. I soon gravitated towards the mobipocket format and bought hundreds of dollars worth of novels through Fictionwise. But there was a problem.
The eBook files were stored with a proprietary format. They had DRM. I could not read the files on any other device. Years later I still own that PDA and I am still reading through the novels I bought on it even though it is not nearly as good an eBook reader as my newer devices.
That sucks.
As soon as I realized the potential of reading books on a digital device - huge convenience, portability, annotations, et cetera - I stopped buying print books. That was several years ago - I used to buy a couple dozen a year. But now I seldom buy eBooks either because I do not want to end up with content that will only be readable on one or two devices. I want to know I will have access to that content forever.
So I am no longer a purchaser of books, of any kind.

Why Should you Care?

If you end up in a senior role you are likely to discuss DRM at some point, whether to use it and maybe even deciding the type of DRM to use. Even as a junior developer you might end up having to message through your forums the company's position on why they are using DRM.

What Can you Do?

In all honesty you probably cannot do a lot. Even as a senior team member I was not involved in any of the core decision making regarding DRM. For many developers I suspect the choice of DRM is tied to the choice of publisher. As I mentioned earlier the developer makes a deal with a publisher to distribute the game. As part of that contract, whether explicit or not, this might mean that the developer has to accept particular DRM on the product.
If you are a senior team member and are involved in negotiating contracts at a developer you should work with other stakeholders and decide your company's stance on DRM. Decide which methods you are willing to accept. Use this criteria when looking for publishers and when deciding which offers to accept.
For other team members you can encourage your developer to look into other methods to encourage purchases over piracy. Add post-ship value to the game that encourages consumers to buy the core product. This might be add-on missions, downloaded items (whether free or for additional purchase) or allowing social networking commentary on the game while it is running (and hence requiring some form of user authentication).
Even something as simple as having the DRM expire a month after ship alleviates some user worry. Basically most sales of a game will happen during that time frame anyways. The company protects those initial sales from piracy and the consumer is not saddled with restrictive DRM, past that first month.

The True Cost of Pirating

While I am not convinced that pirating itself costs developers significant money it does cost developers time, in trying to prevent piracy through DRM and other means.
Basically  developers, generally near the end of a project, do spend time talking about DRM and about how to integrate it. I spent hours in meetings debating DRM and more hours on message boards or in interviews alleviating user's worries about DRM. This takes time away from the core game, translating into fewer features and lower quality features.
I should mention at this point that I do suspect now that piracy is costing developers some money, in addition to lost time. Downloading content for free is starting to become something everybody does... many people in my social networks have admitted to (or bragged about!) downloading content they would have bought otherwise... so it has to be costing something. But how much? I don't know.

What Game Should *YOU* Make                                                                                                                                                                                                                                                                                    

This is a bit of a digression from the actual requirements of the game being made instead to focus on the type of game that might be best in regards to your career development.
If you are still relatively new to game design you might be chomping at the bit to work on the next major AAA project in your studio. You might be looking forward to the five plus years of development time and a budget of hundreds of millions of dollars. You might... but you should not.
I advocate that new designers should start on projects with short time frames (and if possible, lessened sales/ranking expectations). Experimentation delivers a better opportunity for a designer to learn and to improve their skills but on AAA titles there's often little room for experimentation... which means little room for skill improvement.
I also think designers should rotate back onto smaller projects in between large titles as an opportunity to refill the creative tanks, so to speak. The grind of working on major title after major title is tiring (and is why you often find significant turnover between AAA projects even in otherwise stable development houses). In between scaling mountains it is pleasant to leisurely stroll across the occasional valley.
 
THE POOL
My first novel, "The Pool: Arrival" has excellent reviews already. I'm quite pleased by reader reaction to it! If you check it out please let me know what you thought.
http://www.amazon.com/The-Pool-Arrival-Brent-Knowles-ebook/dp/B00MVFG0TM


REVIEW OFFER: If you would like free copies of any of my books in exchange for fair reviews on Amazon, please let me know.

Finally -- If you are enjoying these excerpts, they come from the first book in the Lazy Designer series, available on Amazon: http://www.amazon.com/Start-Career-Game-Design-Designer-ebook/dp/B005KCM7DQ/
Copyright © 2015 YourOtherMind Media, All rights reserved.


unsubscribe from this list    update subscription preferences 

Email Marketing Powered by Mailchimp