Unity3D for teams of 6 people or more

I’ve done this rant live to various people, but I thought it was time to write it down.

First of all: I like Unity3D. I sincerely think Unity3D existing makes the games industry a better place.

But, basically, I don’t see how it can be used for efficient, professional game development, with teams of 6 people or more all actually using Unity. I’m sure people are doing this, but I’d like to know how.

This rant is based on my experiences on a project that used Unity 3.5. Maybe Unity 4 is better. It was our first Unity3D project, but to be honest we spoke to a lot of other Unity developers and if there were any major rookie mistakes we made I don’t know what they are.

Final caveat: It’s been a while since I’ve gotten my hands dirty on this, plus I wasn’t the one who set up the project, so I might get some details wrong.

We used Unity3D with Perforce, with a team of 6 to 8 people, most of whom had to work within Unity itself, as opposed to just making bitmaps or something. The daily workflow for pretty much everyone on the team was:

  • Check out everything in the Unity folder in Perforce. Not ‘get latest’. Check out.
  • Open Unity3D.
  • Do your work and test it.
  • Save, then quit Unity3D. You must do this.
  • Go into Perforce, reverse unchanged files, then try and guess if any files, particularly all of those tiny .meta files, have been added or removed and tell Perforce about those.
  • Repeat.

Unless you want to change a scene, then you must yell through the office that you’re going to change a scene, lock the scene file, then do all of the above. So this was pretty much like not having a repository. We had things set up so scenes and other data are text files, but to be honest, just because it’s now YAML doesn’t mean you can just merge scenes – all those internal references don’t necessarily match up.

That’s a pretty sucky workflow, and it took us a while to get it through everyone’s heads that they really, really had to do all this. I personally suspect – I never investigated this – that we had to quit Unity because of one plugin that saves important files on exit. But to be honest if that’s the case I still see that as a design flaw in Unity.

So, internet: what did we do wrong? What are your experiences with Unity3D and teams of more than a couple of people? We did not use the Team License – could that have solved our problems, and if so how?

The three most common techniques for telling stories in games

Mainstream games, or at least a significant subset that I’m too lazy to define here, make use of three big techniques to tell stories:

  • Cut-scenes.
  • Invisible boxes.
  • Environmental storytelling.

I think both game developers and players understand these techniques by now, and in fact I think players are getting tired of them. I know I am. And that means it is time to surprise people again, to innovate, by moving beyond these tools or by using them in new ways.

Cut-scenes

Cut-scenes are the most conventional and, perhaps not incidentally, also the most controversial tool. We’re splicing another medium, film, into our games. It is an effective medium to convey information and evoke emotion. Players and developers both understand cut-scenes, important reasons for their popularity. The effectiveness of cut-scenes balances out the fact that they are not interactive, and therefore tend to break immersion and take away agency. But it’s an uneasy balance. Cut-scenes, by definition, do not fit well in an interactive medium.

Over the last 20 years, innovation in cut-scenes has been about technology (how complex a scene can we show), production (how do we economically make more complex cut-scenes) and filmmaking craft (how do we make effective cut-scenes). There has been almost no innovation in the interactive aspects of cut-scenes, and this is to be expected since cut-scenes are pretty much defined by not being interactive.

(I classify dialogues as cut-scenes for the purpose of this article. How to do dialogue better or make it more interactive is beyond the scope of this blog post. People tried cool stuff in the 80s and early 90s, we did some reasonable things in the role-playing games I worked on, by now people have kinda stopped trying to invent new things, at least in AAA. I haven’t played enough Mass Effect or Skyrim to have an opinion on how they did, but I didn’t get the impression it was groundbreaking.)

Invisible boxes

Invisible boxes (or planes, spheres, volumes, etc.) are the tool that level designers use to trigger events. When you walk around a corner and a ceiling collapses, enemies come running towards you, or some characters act out a little scene (just out of your reach), then you just hit an invisible box. When you’ve seen them once, you see them everywhere.

And that is the problem. As a player, you develop a sense for these things. You know stepping into that big room or walking around the corner will trigger something, just as you know that if you just stay there, nothing is likely to happen, forever, except for the eerie and foreboding music. (The tendency for games to get stuck, when nothing happens because the player isn’t doing something, is a big immersion breaker.)

Invisible boxes are used to orchestrate events just so for the player’s enjoyment, to make sure she meets the right challenge at the right time, sees the right thing at the right moment. They are an easy tool to understand and to use, although hiding them requires finesse.

But they can never be fully hidden. At some point, the player realizes that the world arranges itself around her, and then the reality of being on a well-orchestrated ride dominates the illusion of being inside the fictional world of the game, and her behavior changes. She knows what to expect.

Invisible boxes are stupidly easy to implement, so there has been no innovation here for decades. We’ve become more sophisticated in how we use them, but the scripts in the games I wrote in the early 90s are conceptually the same as the scripts in current games.

Note also that invisible boxes are orthogonal to interactivity. We can use them to orchestrate spectacles, but they are not inherently interactive, they do not in themselves create or enable interesting choices for the player. In fact, they are often used to trigger or to artfully replace cut-scenes. Characters talk or interact in real time, scientists are drawn into ventilation shafts, but in such a way that the player doesn’t notice that she cannot interact with them.

Environmental storytelling

Environmental storytelling is telling a story through a game’s environment, specifically a story about what happened before you arrived in said environment. I believe the term was coined by Henry Jenkins, but I’m not an academic so I’m not going to research it. I first saw it used in System Shock. Remember finding those little cubby holes with a corpse and some empty food containers and recordings telling increasingly bleak tales of the bad stuff that happened before you arrived? Well, that was kind of the best use of that technique, and it’s been used more or less like that ever since. It was used well in Portal and Manhunt. It’s a useful technique, but limited. I recently saw a blog post critiquing the diaries and recordings in Bioshock 1 or 2. I surprisingly felt a bit disappointed at the start of Dishonored when early on, in the sewers, I found a little cubby hole with a corpse and some empty food containers and letters. I remember thinking “Oh no, it’s the 90s again.” For all I know it was a homage. Dishonored is great, you should play it.

So?

These three techniques have a number of things in common. They’ve been used a lot over the last 20 to 30 years, especially in ‘mainstream’ AAA games. Players understand how they work, they’ve learned the conventions. Developers understand how to use them, and have refined them over the years.

And there are signs that people are getting tired of them. I’ve got a whole different blog post on a back burner somewhere about techniques and gimmicks and genres. I don’t have an opinion why this is happening, whether people just get tired of any technique. Maybe they do. Maybe you can see this when you look at the evolution of TV and cinema and comics, how things are rebooted and reinterpreted. But I claim it’s happening.

Finally, none of these techniques are very interactive. Only invisible boxes can claim to be somewhat interactive, in the sense that they react to the player.

(Just a few days ago I read this profile of Mohammad Alavi in Edge:

Once more, Alavi charged into the wilderness alone, eventually writing over 10,000 lines of scripts that anticipated every way the player might disturb or be noticed by the patrolling soldiers, handling each case with different animations and behaviours. “It was crazy and jury-rigged together, but the end result is that you can enter the situation from any angle and it’s legit – if they thought they saw you from a certain distance, they’d behave differently than if you popped up right in front of their face.”

So maybe you can do some cool stuff with invisible boxes if you’re crazy. But they rewrote his scripts and turned it into proper AI.)

And I believe this shows that all of the current techniques we currently have are smoke and mirrors. Well-executed, cunningly used smoke and mirrors, perhaps. But we’ve taken things that we as developers understand and that our players understand, and have tacked them onto games. We’ve taught our players how to overlook the joins and seams, that we all know are there. And we’ve taken this as far as we can. Now the end is in sight. We’re close to not being able to do better, to not being able to afford to do more, and players have caught on to us.

We’re on a local maximum, a beautiful hilltop where things are great, but any movement leads downward. And that’s scary, because that means we have to leave behind what we built, pack a small backpack and trek through the wilderness to find new beauty. And we only have a vague idea of where to go. Some of us won’t make it.

I’ve been thinking about storytelling in games for a long time, since before I became a professional developer even. For years I chased immersion and used the techniques I described above. But I knew there had to be more. Now I am seeing hope, in games like FTL, in Spelunky, in Rebuild, in Dwarf Fortress, perhaps in Minecraft. It’s not the discovery of something blindingly new, but more suddenly looking at things in a different way. (And then seeing a trail leading from these games back in time to older games. It was there all along.) I don’t know where this trail will lead. I’m sure it will be different from where we were before. I can’t wait to find out.

Why we called our game Albion

Some time in 1994 we (the Albion team) were thinking of a name for our new role-playing game. We knew it would involve Celtic culture somehow. As well as spaceships and aliens, of course.

Some of my personal criteria for game titles were:

  • It’s nice when a game’s title starts with an “a”, because then the game shows up at the top of alphabetized lists.
  • It’s nice when the game’s title is not truncated by the operating system. Albion was a DOS game, so it’s nice to have a name of eight characters or less.

However. Albion started off as an Amiga game, and Amiga’s operating system allowed longer filenames than DOS. So either we came up with the name after we made the decision to switch to DOS (because Commodore had gone bankrupt), or we were just lucky in this regard.

So someone, maybe me, came up with “Albion”. We didn’t know what it meant, but we knew it sounded vaguely Celtic. As this was before we could have looked this up on Wikipedia or Google, we had no idea Albion meant England… In retrospect it’s a weird name that creates associations that have nothing to do with the game. This is probably how Japanese developers pick names all the time.

Anyway, that’s how we came up with the name.

A rant about games and how they’re perceived

Last night I had a discussion on Twitter with Luke Dicken about game definitions, and why they matter. It reminded me of some strongly-held views I’ve had for some time about attempts to place games in a larger context: art, society, culture, et cetera.

I don’t care if games are a legitimate art form, medium or whatever. I don’t care if they have a pedigree going back to 1971, the 50s or the 18th century. I don’t care if they’re older than the novel, older than writing. I am not convinced, nor do I particularly care, that computer games are direct descendants from board games, children’s games or play in general. I don’t care if animals used play to learn before humans learned storytelling to transmit knowledge. I don’t care if play is an essential part of human culture.

If someone were to convincingly prove that computer games are not a legitimate art form, I’d still be making games. If someone could convince me computer games were a trivial hobby, I’d still be making games. If computer games were not derived from something else, if they had been invented ex nihilio, out of whole cloth, sprung fully formed from the brow of Nolan Bushnell or whoever, I don’t care, they’d be even more miraculous.

What unites most people making computer games is their passion. We want to make games. We know how to make games. We strive to make better games. But it makes absolutely no difference to me where we fit into other people’s questionable value systems. Fuck ’em if they don’t get it; they will die out anyway.

If we have to play power games to protect our medium, if we have to argue that games have cultural value in order to gain legal protection or subsidies: why not, it needs to be done. But let’s not mix that discussion with actually making games, with making people happy, with evoking emotions and giving people means to express themselves which are fundamentally new.

We’re working in the newest and most exciting medium in the world. That doesn’t make it a ‘better’ medium – I don’t even know what that means. It doesn’t make our lives easy. It doesn’t mean we bear less responsibility, that we don’t need to work hard to do better every day.

But it is a good thing, no matter what anyone else thinks.

Pushing ideas to different parts of your brain

A couple of months ago The New Yorker published a profile of Hilary Mantel by Larissa MacFarquhar. I found this paragraph particularly interesting:

When she’s starting a new book, she needs to feel her way inside the characters, to know what it’s like to be them. There is a trick she uses sometimes, which another writer taught her. Sit quietly and withdraw your attention from the room you’re in until you’re focussed inside your mind. Imagine a chair and invite your character to come and sit in it; once he is comfortable, you may ask him questions. She tried this for the first time when she was writing “The Giant, O’Brien”: the giant came in, but, before sitting down in the chair, he bent down and tested it, to see if it would take his weight. On that occasion, she never got any further, because she was so excited that she punched the air and shouted “Yes!” But from then on she could imagine herself in the giant’s body.

This reminds me of the Rubber Duck debugging technique:

The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

Peter Reiterer, a programmer I work with, occasionally uses this technique. (I myself have used a similar technique but using a graphic artist instead of a rubber duck. I have not compared the two approaches but my method is also quite effective, if perhaps more boring and confusing for the participant.)

The way he explained it to me, or rather the way I remember his explanation, is that this technique forces you to express thoughts and then absorb them again through a different part of your brain, and this allows you to see them in a new way.

I always thought the mere act of expressing your thoughts to someone (or something, I guess) forces you to reorganize them and in the process discover new insights. A bit like learning by teaching, and incidentally the reason why I do public speaking or write blog posts. The difference is subtle and I can’t think of a way to test which explanation is better.

But the interesting thing, to me, is seeing two techniques to unblock yourself, to get a new perspective on things, that involve forcing a different part of your brain to interpret something. Of course it’s just me saying that is what’s happening in Hillary Mantel’s head, and I am not a neuroscientist. I don’t know for sure if she is using two different parts of her brain: this is just my intuition.

After discussing this with my wife it struck me that prototyping is similar to these techniques. It is easy to imagine a logical, abstract structure for a user interface, but once you visualize using it in your head, or, even better, prototype it on paper, you see it in a different way and can perceive things you couldn’t in your abstract model.

Of course, this raises the question: does prototyping work because you’re perceiving something using a different part of your brain? Or ‘merely’ because you’re seeing an approximation of the real thing? It is unlikely that I can better understand a game design idea by using, say, interpretative dance.

Food for thought, perhaps. Can this approach be generalized? Can we express, transform, and re-experience our ideas in other ways?

Game definitions and the designer’s toolbox

When you hear someone say “that’s not a game,” they usually mean “this is not what I was expecting from a game”.

Game definitions are like tools. You need to get something done, so you open your toolbox, pick the right tool, and then use it. As a craftsman, you care about your tools, you polish and clean them, you try to make better use of the ones you have, and judiciously add new ones to your toolbox, all in service of the craft.

A game definition based on Huizinga’s magic circle allows me to do different things than a game definition based on Crawford’s toy/puzzle/game taxonomy or Costikyan’s resource-based definition. All of them are useful, they all make sense and are ‘true’. But each operates in completely different perspectives.

And this is the value of a varied and well-selected set of tools. They allow you to look at things from different angles. When you have a screwdriver, you look for screws, for things to open.

Similarly, when you’re using the magic circle perspective, you might be thinking of how playing relates to non-playing, how people can be drawn into a magic circle, how their behavior can be changed, or how you can draw attention to their behavior by manipulating the magic circle.

When you’re using the toy/puzzle/game perspective, you might be thinking of player goals and replayability. Do you give explicit goals to the player, or do you let them select their own goals? Is the game about figuring out a problem and then moving to the next one, or is it about dealing with an opponent or a complex system?

Costikyan’s definition of game draws your attention to resources and allows you to design independent of whether you’re working with cardboard and tokens or on a computer. It makes economics applicable to games.

A final perspective – I hesitate to call it a definition – is that of ‘it’s a computer game because it looks like a computer game’. Here we get games like Proteus or Dear Esther. They are sold and discussed alongside other games. They contain 3D worlds we can navigate through. They don’t have a ‘serious’ purpose – they’re not email clients. Note how none of the previous definitions of games said anything about navigation in 3D worlds, or any kind of navigation or worlds at all. Yet the representation of and navigation in worlds is an unspoken assumption underneath a lot of people’s idea of what a game is.

The toy/puzzle/game taxonomy is the clearest about games like Proteus and Dear Esther. In this system, seen from this perspective, these games are toys. This helps me understand them. It makes them tractable, understandable, ‘known’, even before I play them. This doesn’t mean they’re boring or predictable: just that I can recognize them from a certain perspective.

Game definitions are tools, and knowing your tools well, understanding their differences and their strengths and weaknesses makes you a better designer. In the case of mental tools, knowing exactly which tool you’re using is perhaps one of the most useful things to learn.

Game definitions can also be used in a rhetorical way, as a form of argument. This is always about power, and thus political. I define games this way, therefore your game is not a game and thus you lose power. I define games this other way, therefore games become more worthy than your medium and thus you lose power. I define games like so, therefore it should not be a part of your department and I get to raise my own funds.

There is nothing inherently wrong with rhetorics, politics and the use of power. But it’s important to distinguish between politics and the truth inside your toolbox.

Andy and Jurie are looking for jobs

TL;DR: Game designer Andy Schmoll (profile) and grizzled veteran developer Jurie Horneman (profile) are looking to move to an English-speaking country in the near future. Hire us while we’re hot!

Continue Reading »

The Stagconf budget

I thought it might be educational, both for you, dear reader, and for myself, to write a blog post about the budget for Stagconf, the conference on storytelling and games I co-organized last year.

Here is our final budget:

Income Expenses
Ticket sales € 6380.25 Location € 3726.00
Sponsoring € 4450.00 Speaker hotel € 1545.00
Other € 300.00 Speaker flights € 3666.60
Catering € 1739.85
Speaker dinner € 750.00
Recording € 1150.00
Taxis € 275.00
Other € 564.21
Total € 11,130.25 Total € 13,416.66
Budget for the 2011 Stagconf conference

So what can we tell from this?

Final score

We made a loss of € 2286.41. This wasn’t a catastrophe. We didn’t expect to make a profit. On the other hand, the conference was not part of some larger enterprise where the loss becomes an investment. It wasn’t a marketing activity, for instance. And while we didn’t end up living under bridges, we can’t afford to lose this amount of money on a regular basis. This is one of the reasons why we haven’t made any concrete decisions for a Stagconf in 2012.

Speakers

Over 40% of our budget went to the speakers. We treated them very well. Not every conference pays for travel, hotel, taxis, dinner, etc. Our U.S. speakers brought their partners: we didn’t pay for their flights, but we did pay for the double room for 3 nights.

Was this necessary? Yes, I think so.

At academic conferences, speakers are typically expected to not only pay for their own travel, but even for their own entry tickets. This makes sense because speaking at a conference is important for academic careers.

I’ve never attended any open source or web conferences, but if EuroPython is typical, then there it is also expected that speakers pay for their own travel and entry. This fits the open source spirit, plus there is a sharing with peers aspect that not every conference has.

At industry conferences, such as GDC, speakers typically get in for free. The value of attending and of being a speaker are high enough that it makes sense to expect speakers to pay for their own travel costs. Plus, speaker supply is very high.

I think there was no strong case for speakers at this conference to invest more than their time, which is already valuable. This should not be underestimated. In my work on the advisory board of Game Forum Germany I have seen speakers turn down an all expenses paid trip to Germany simply because they couldn’t justify the time cost, and I myself have also turned down speaking invitations for this reason.

In the end it’s simple: we wanted to have the best speakers we could imagine, and the way to achieve that is to pay their travel costs. And it worked: everyone we contacted said yes right away.

Food

Our food wasn’t cheap, but it was worth it! Feedback on the food was unanimously positive. Paolo’s did a great job.

The location

The cost of the location made up almost 28% of the budget. I’ve been told this price was low for a conference location, and the Museum of Natural History definitely has a charm that added to the experience. Still, we’ve since come across options that might be even cheaper while still being very nice.

Ticket sales

This is a big topic that involves marketing, PR and pricing. I will save it for a future blog post.

Sponsors

We are immensely grateful to our sponsors. Without them, Stagconf would have been financially ruinous and/or less cool. (For instance, everyone loved the notebooks from Scout Books and the after party at Grande cocktail bar.)

Having said that: finding sponsors, especially financial sponsors, wasn’t easy. Not just because it’s never easy to get people to open their wallets, or because we had never handled sponsoring before, or because we were an unproven event. I think the business case for sponsoring Stagconf is a bit different from other games conferences. If you focus on graphics, you can talk to Nvidia or Autodesk. If you focus on AI (for instance), there are AI middleware providers that have marketing budgets. But who do you talk to for storytelling in games? We pretty much stumbled across Nevigo by accident in early August 2011, and were very glad we could convince them to sponsor us. But apart from that it’s difficult.

One target I had in mind was the HR departments of big developers. I tried quite hard to get in touch with Ubisoft HR, because I think it would have been a great fit: they’re looking for people all over the world, and most of their games involve storytelling. But despite all of the people I know there, I wasn’t able to reach the right people in time. And it might have been tough simply because HR departments might not have sponsoring budgets. Still, I’d want to try this again in the future.

The future

Speaking of which: what about the future? As I mentioned before, organizing Stagconf was fun but also incredibly exhausting. So if we do another one, we won’t do it the same we did it last year. What does that mean exactly? We don’t know. We have been talking to people and discussing various options (different formats, different locations, partnering with other events), but we haven’t made any concrete decisions so far.

But you can help! If you have feedback on our budget, let us know. If you have tips on organizing conferences, talk to us. If you know sponsors, definitely get in touch.

Meanwhile, I hope you found this informative.

Good food in Paris

Paris is a huge place that caters to a lot of different tastes, and there’s an entire industry listing the best places to eat. Here I am just going to list some places that I have personally been to or that I have heard good things about from people I trust, plus some resources to find more.

Let’s start with Jeu de Quilles, a great little restaurant with excellent organic wines. My wife and I had one of the best meals of our lives there in 2010 (thanks again Camille!). Very good ingredients – they’re next door to the butcher shop that provides meat to the Palais Élysée. Very good quality for the price, meaning they’re not cheap but the food is really, really good. (If you watch the 100th episode of No Reservations, you can see Anthony Bourdain eating there.)

Nearby there is Le Cornichon, recommended to me by the same friend who took us to Jeu de Quilles.

If you like sweet stuff, I have been told by Noah Falstein that Angelina is a must, although sadly I haven’t been there myself yet.

I have never gone wrong following the advice of David Lebovitz, at least where food is concerned. David knows his stuff regarding chocolate and sweets, and he has lived in Paris for a long time. Paris Pastry Guide is an ebook and iPhone app listing his favorite pastry places in Paris.

Although it’s a chain, I have a weakness for Boulangerie Paul, which can be found pretty much everywhere in Paris. I love their pain au raisins.

When I’m in Paris, I am often near Les Halles, and I like to eat at Le Père Fouettard. It’s not mind-blowing, but it’s good French food.

I also like the Crêperie Beaubourg because it has decent crêpes and it’s right next to the Centre Pompidou.

Opposite the Centre Pompidou is Amorino, a very good ice cream place. There’s also one in Le Marais.

Completely by accident my wife and I had the best burger we’ve ever tasted in Les Têtes Brûlées. Or, rather, she had the burger, and I had a mediocre salad. There’s a lesson in there somewhere. Anyway, not something to go out of your way for, but boy that was a great burger.

After dinner I can recommend La Rhumerie. They have great rums, plus the best virgin mojito I’ve ever tasted. Once again, it was my wife’s. She just has great taste.

Marketing/PR vs Product development: A false dichotomy

(This is a quick blog post to reply to a conversation on Twitter about marketing, PR and product development. It was started by Dylan Cuthbert based on a quote from the Steve Jobs biography. Very quickly Javier Arevalo, Mike Acton and Thaddaeus Frogley got involved, and I dragged in poor Adam Saltsman for perhaps no good reason. Anyway, see this tweet if you want to try and make sense of it.)

So I claimed somewhere somehow that I think it is a good thing if developers not only understand but actively participate in marketing, PR and other non-development activities (sales, tech support, biz dev, etc.). This goes way beyond including functionality to allow PR people to make nice screenshots (useful as that is, hi Thad). I see this as exactly equivalent to programmers understanding how game designers and artists work – or rather, what game designers and artists do. (And vice versa of course: it helps when artists understand programming, etc.). A programmer who understands game design can achieve things another programmer cannot, simply because she doesn’t have to spend as much (or, sometimes, any) effort coordinating and communicating with someone else.

Naturally I would say this since knowing just enough about most disciplines is my thing. I am not saying it is bad for people to focus on one discipline. But game development is the most multidisciplinary art form – more so than film or opera in my opinion – and so it logically follows that dealing with the synthesis of all of these disciplines is key to getting the most out of the medium. And multi- or inter-disciplinarity is a really great way of doing that.

Anyway. Over the last couple of years I’ve come to the conclusion that this goes for disciplines outside of pure game development as well, in other words: PR, marketing, sales and biz dev (and tech support and IT but I’ll leave those out for now). Classically, as a developer, you would outsource PR, marketing and sales to a publisher or it would be taken care of by different people in a different department and floor. Biz dev was this thing your boss’s boss did and the result was someone coming in and telling you what game you were going to make next. I’ve worked like this and I think this attitude is still prevalent.

But the rise of the internet has changed all this in a mere 5-10 years. You need fewer permissions, fewer gatekeepers, fewer middlemen, less capital. You can do more with a much smaller company. But that means you need to pay attention to, and take care of, those aforementioned disciplines that are not development.

I think it is imperative that developers see their work as part of a larger whole. The odds are that, in one way or another, you are trying to bring interactive joy to people and somehow be compensated for it. (I would argue that this is the case even if you make art games, but let’s not derail this by arguing about edge cases.) ‘Compensated’ typically means making a living and staying in business. (If you’ve taken money from investors, you also need to produce a return on investment, or *shudder* achieve growth.) Anyway, to do so you need to reach people, then convince them to play your game and give you money. And that is marketing, PR and sales.

These days, as a game designer, your work has already been impacted by marketing and sales, if you’re making free to play games. (Right now, I can think of only two development companies in Austria that are not working on free to play games. Crazy.) But beyond that: what about accessibility, in the sense of people quickly grasping what your game is about? This starts way before the moment the player starts your game. It starts when they hear about it. And what do they hear? The title, and the story. Not the story in your game, but the story about your game – hopefully the one you wrote, in a press release. They read what other people are saying about it, be that press or just someone on the internet (a distinction that’s rapidly fading anyway). Then they see a logo and some screenshots. Then perhaps they read a description and some user reviews in an app store. Then maybe they download and install it.

What is that if not game development? Game design (setting, title, core concept), art (logo, style, screenshots, videos), programming (writing installers, getting the downloadable size below 50 megabytes). What are things like user testing and closed betas if not looking for market fit? And I didn’t even get into analytics.

(For years I resented being asked to explain my game in one sentence. After 21 years I finally get it. A topic for some other time.)

Somewhat paradoxically, indie developers, despite often having a certain ‘we’re not part of the industry’ vibe, are often the most savvy about marketing and sales. At least the successful ones. They run blogs and have multiple Twitter accounts (content marketing), distribute their game through multiple distribution channels (Steam, Flash portals, app stores), participate in special sales (e.g. the Humble Indie Bundles). Super Meat Boy had excellent marketing. Sword & Sworcery’s in-game tweet functionality was great for viral marketing. Etc.

To come back to the original discussion: How should a company divide its priorities between marketing/PR or product development? My answer is that a company should try to eliminate (or at least keep a concerned eye on) internal divisions, and make decisions based on something beyond this the false marketing/development dichotomy. Apple had its way of doing this (I haven’t finished the biography yet but Jobs was a master at marketing and sales. Your company needs to find its own way. As always, remember Basho: Do not seek to follow in the footsteps of the wise. Seek what they sought.

Relevant blog posts by other people:

Previous blog posts by me that may be of interest: