View this email in your browser
Please toss questions to be ( if there's specific information you'd like covered ... I might answer those as an occasional break between chapters here!
Last time we looked at why you might want to make a particular game... now we discuss expectation setting and some major choices that will influence the game's direction. I can emphasize, even ten years after first writing these words, how important these decisions are!

The Lazy Designer: Chapter 4 (Part 2)


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 established entities... 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 maker 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 leadership, 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 avoid venting inappropriately. 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 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 (not mobile). 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.

Take the prior suggestions as just that... suggestions. Since I originally wrote this section, it would be easy to note several games made contrary to these suggestions. I think the general advice applies, but no rule is set in stone here.

Even if you are an indie developer, working on your own, considering the above 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.

And to contradict my past self, I am actually rebuilding an older "just for fun" game I built into something I intend to release. So... you never know. Also, I wish that past-Brent had put more comments in his code so I could better understand what I was doing back then...

Digital Rights Management (DRM)                 

DRM is a layer of protective software that is used to protect some games (and other content like eBooks or music 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. This can 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 (a 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 your 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. 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. But should you?
I advocate that new designers should start on projects with short time frames (and if possible, lessened sales/ranking expectations). Experimentation provides 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 contributes to why you sometimes find turnover between AAA projects even in otherwise stable development houses).
In between scaling mountains it is pleasant to leisurely stroll across the occasional valley.

Please let me know if you have any feedback on this content and expect an announcement in the next few weeks regarding something new that I've been working on...
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Copyright © 2021 YourOtherMind Media, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp