Game dev, Life, and Everything

Magic Formula for Killer Game Ideas

Fri, 04 May 2012 10:01:00 +0200

100% GUARANTEED EFFECTIVE GAME IDEAS PITCHES DOCUMENTS SUPER SUCCESS IN MONTHS OF SHIPPING 20MM DAU TOP 10 GROSSING ORDER NOW!

You might have been scammed.

I know a lot of smart people who try to figure out the science behind exceptional games. Other more humble (and better educated) people are still trying to figure out what is a “game” in the first place. It’s hard to tell what makes something good if the subject itself eludes definition, but it’s also hard to make something good if you have no plan. I don’t have anything definitive so here’s some observations instead.

Let’s start by stating that nobody knows how this stuff works. I had a previous post about the structure of an experience and the interesting part is how relative everything is to the current context. In short if you have a single plan of action on delivering a game and repeat it a few times you will end up out of touch with your surroundings and overtaken by other developers. There’s a reason why even the nearly unlimited expertise and experience of our industry veterans can be one-upped by some random dude making their dream game for iOS.

So how should we approach coming up with new stuff? I wanted to write pages and pages of philosophical BS it but instead here’s some practical approaches because to be creative you first have to come up with boundaries:

Market analysis

Henric Suuronen wrote some pieces on how he approaches trend spotting (http://henricsuuronen.com/blog/themespotting-part-1/ for starters) and I think this strategy is totally valid. You basically look at everything that’s out there and try to pre-empt where it’s going to be by the end of your dev cycle. Maybe zombies are coming in again (and again and again and again) with massive Hollywood investments so how about we use that as our theme? Maybe there’s an opening for freemium games on your favorite mobile platform? Maybe publisher/investor X is lacking this combination in their portfolio?

Different forms of market analysis can give you nice creative boundaries with an empty, game sized hole in the middle.

+ Easy and fun, just like in the movies!
+ Helps you validate your business case
+ You need to do it anyway to impress your boss/CEO/publisher/investor
- Very low chances to lead to something disruptive
- Everyone else will be doing the same thing so expect stiff competition

—

Mimicry

~~Cloning~~ being heavily inspired by other existing games doesn’t have to be an ugly concept. What people really care about is execution and how the game feels, not what it was based on. It’s a perfectly good idea to take a classic concept from the 90s and bring it over to the social f2p context of today. That way you have something people already know they like to play but with a completely new and fresh twists that let them enjoy the classic gameplay again.

+ The game is already fun (unless you mess it up)
+ Your audience might be already warmed for it
+ Makes communicating your vision to outsiders and juniors much easier
+ Less risk = more room to innovate elsewhere
- You must make your game better than the original (escalating arms race?)
- Again low chances of really disruptive products if done blindly

—

Bio Mimicry

Bio mimicry is a word used in natural sciences to describe inventions that are discovered by seeing what else is out there in nature and trying to replicate it. All my favorite artists say that the key to their creativity is to absorb other forms of culture. In the same spirit we can look outside of video games to see what people enjoy doing and how could we make a compelling video game out of that. This way you end up with interesting new ideas that let people play out their fantasies (football managers), make their existing experiences more convenient (async. board games), or keep active (motion sensor fitness games), etc.

+ Might lead to something truly new and disruptive
+ Still inherently familiar to the players
+ Might solve a problem and thus have utility value to players
- Tougher sell to get green lit
- Good chance of simply not working out in action

—

Blue Ocean

My god, is that even a game?! Do something that has never been done. Redefine what’s possible in interaction, push the boundaries on what it means to “play” a “game” and possibly create one of the games to define that year forever. Switch off your logistical thinking and surrender to the creative parts of your brain to come up with concepts that are freed from the normal self-censorship of western adults. This is usually what game jams are all about.

+ Very, very interesting
+ Definitely something disruptive (if it works)
- Takes a lot of time and iteration
- Super likely to not work in action
- Does not necessarily fit to your favorite business model
- Good luck pitching this approach to your boss

—

Aesthetics First

Carefully consider what you want your end result to be like. Maybe it is to have the players experience a certain feeling (fun? anxiety? remorse?) or to learn something. Then extrapolate outwards from there by figuring out what kind of interaction would lead to that end result. After a few rounds of thinking you might end up with something interesting.

+ Clear focus and vision from the start
+ Flexible to other constraints like business models
+ Might lead to something new and interesting
- Requires serious game design skill and experience to understand How Stuff Works(tm)
- Often looks better on paper than in action

—

Just Fucking Do It

Also sometimes called “just make shit”. Popular with indies, the idea is to make as much stuff in a short time as possible and wait for something to work. Petri Purho pointed out in his Assembly presentation about Crayon Physics that it seems to be some sort of rule that about one in ten game ideas is any good. So do ten game prototypes and you might end up with one that is the next big thing. I like this approach because it gets the bad stuff out of your system quickly and keeps you from attaching too much to the first two things you come up with.

+ All the cool indie kids do it
+ Very agile while still directed by your other restraints
- Very agile and thus not directed enough if you ask your boss
- Requires devs who can abandon work frequently

—

Closing Thoughts

Eric Zimmermann had an interesting insight in GDC12 where he pointed out that this discourse is very similar, if not identical to what has been going on in fine art since forever. It’s still on my personal to-do list to dig deep in to the history of art and draw parallels from that to the evolution of game development. One of they key insights there is to stop looking a single way of doing successful results, but rather try multiple different angles as the cultural surroundings (or “market situation” for the emotionally challenged) develop over time.

Stay humble and keep shipping.

Structure of an Experience

Fri, 27 Apr 2012 10:02:00 +0200

Semi-original content ahead! I recently read an interesting and actually somewhat provoking feature on Gamasutra named The Origins of Fun by Christian Philippe Guay that mainly discussed the structure of an experience that makes fun happen. While I really liked the article, I don’t completely agree so here’s my version of how I see it might work. I’m really only expanding on his work so all credit to the ones who deserve it.

Disclaimer: I will assume that you are already familiar with some game theory, basic positive psychology, and most importantly understand that there are different kinds of fun. If not, google for this stuff. In any case I will use “fun” to refer to all these different kinds of positive feelings to keep it simple. Also I might be wrong.

The Structure

Ok so I agree that to find the origins of fun we should be looking at more than the gameplay. Fun originates from many different points of a product so we should look at the whole experience. Since experiences are often evolving as a function of time, we can create an approximate structure to try and make sense of it all.

So here’s the big picture with some pimp ASCII visuals in a rough order of experiencing them:

############################
# Hype / expectations #
# —————————————- #
# High concept Presentation #
# —————————————- #
# Gameplay / MDA #
# —————————————- #
# Rewards #
# —————————————- #
# Structure #
############################
# Realization #
############################

If you read the original article you can already see that my list is different from the one presented there. I also use different terms for what I believe to mean the same things because these ones are more familiar to me. Now the details:

Hype / expectations

Before you even install the game you are already experiencing it. This point describes the attitudes and expectations you have for the product based on everything you have seen or heard about it beforehand. For example you might have very high expectations for a sequel of the game you loved and that will change how you experience the product. As a developer we can affect this with our external communication (press, betas, community engagement etc.)

High Concept

What the game is about. Different people prefer different concepts even without actually playing them. Maybe you are a fan of platformers but not driving games. Or maybe you like experimental gameplay as a concept even if the game isn’t super fun. The concept itself has some value regardless of it’s execution. (remember: good execution is always more important than a good high concept)

Presentation

Presentation in this case covers everything you can see or hear in the game including UI, app icon and art style. Like the high concept, the presentation of a game can make or brake the game even before it was bought. Mediocre games with great graphics/sound execution might still sell and give a fun experience. Maybe you prefer a WWII theme over modern warfare, but masses certainly don’t based on CoD sales. Also the presentation of a game often evolves as the game progresses so for example you might have better feelings about level 1 environment than level 5 environment.

Gameplay / MDA

Okay this is a big one. Gameplay described the core gameplay, level design, and other things that affect what you actually do in the game. I think to be useful we need to break this down in to smaller pieces and so far I believe the MDA design framework to be superior for analyzing interactions inside a game. The short version is that Mechanics describe game rules (your clip has a maximum of 5 ammo), Dynamics describe the player actions/strategies resulting from your game rules (you have to reload all the time because of the small clip), and finally Aesthetics describe the feeling you get from your interactions with the game (reloading all the time is annoying).

Overall the gameplay is usually a loop of sorts that repeats and the rest of the items on this list happen some time during the gameplay.

Rewards

Rewards (or feedback in general) are such a big thing in games that it deserves it’s own category. Rewards might be explicitly built in to the game (get 3 wood after chopping down a tree with sound effects etc.) or emergent from the game system (other players cheering you after playing well in a multiplayer game). There are all kinds of ways to reward players from different actions and these will be very important to some types of games but not others. For example casual games are all about positive rewards while horror games have more emphasis on the desperate/helpless mood with simply a small break being a major reward. Right kind of rewards will have a major contribution to the overall fun factor.

Structure

As gameplay progresses and more and more rewards are being given out, a game structure starts to emerge. It can be very obvious like experience levels or game levels, but also very transparent like in Half-Life 1 where you can’t necessarily tell when you are for example 50% through a level or when one level starts or ends. Still many people will intuitively recognize a certain rhythm to how the game works and using that knowledge allows them to foresee what might happen next in the game (like those ammo crates just before a big room will tell you that a boss fight is incoming). In fact many good games reinforce the psychological state of flow (extreme concentration) by pacing the gameplay and rewards just right to keep you in the maximum fun zone.

Realization

This was a really interesting one to me personally. Realization is the moment when you take a step back from the game and look at the experience you just had, basically giving it an overall rating and forming an opinion. Maybe you know the feeling of playing a really good game for some time and after a while realizing that this might very well be one of the best games you have ever played and that you just want to keep going for as long as you physically can. Or maybe you realize that while the game is really good, it’s also exactly like all the other five FPS games you played this year and thus not all that exiting. This moment of realization is heavily dependent on your past experiences and the cultural context of evaluation. It explains why the exact same game was successful 12 years ago but nothing special today.

So… Why did I care again?

If we assume that the above list is complete enough to be practical, then it could help you understand what makes some games fun and not others. It might help you find the weak/strong points of your own game. It might help you appreciate the complexity of designing a full experience, not just a single part of it. Or maybe most likely: it could serve as a reminder for you to take another angle to think about your game before launch to make sure that you have optimized it to be as much fun as it can be.

But in the end I’m happy if it made you think about how to make better games.

Social Games are Real Games, Honest!

Fri, 20 Apr 2012 10:02:00 +0200

Right, I’m kind of tired about hearing all this crap about social games not being “real games”. As a core gamer I get why people might feel this way, especially because a big part of what’s available in the social gaming market is crap.

But let’s face it: a big part of all games are crap. We should talk about the ones that are actually good.

Here at Wooga (we’re hiring, apply here and mention my blog) we approach game development like any other big company. We concider the target market (everyone), what they want to do (play with their friends) and what environment would be most comfortable for those experiences (Facebook/mobile/next big thing). It’s NOT about doing bad games for stupid people. Let me elaborate on that.

As a gamer you, the reader, have a lot of experience accumulated over years and years of religious training. This means that as you play a new game you have a huge database of existing game knowledge that you use as a comparison to figure out how this new game works. Theory of Fun (a good book, remember those?) presents the idea that a big part of attraction in games comes from figuring out new things (gameplay patterns), so all good games essentially present something new in the context of what you’ve already experienced.

Armed with that idea, please consider what kind of game experiences a typical +40 years old mom has had. Not much beyond Scrabble (enter trademark lawsuits!), Minesweeper, and some card games (inaccurate, depends on your definition of a game). In this context seeing a game that allows you to manage your very own farm and see how your friends are doing is actually pretty mind blowing. All of the current top 10 Facebook games are very simple from the core mechanics perspective, but revolutionary from the target audience experience perspective.

Furthermore you can’t play too hard games that jump too far from your existing knowledge base. For example a lot of RTS players are still having a hard time with the extremely offensive and noob-bashing DotA that is still an absolutely brilliant game. It’s like the game doesn’t want to played and you win by doing it anyway with your years of extremely competitive gaming knowledge. In the same way while designing social games we have to carefully evaluate and adapt to the experience of our target audience and deliver something that is new and exiting, but at the same time familiar enough to recognize.

In short: it’s game development.

So there. Next time someone comes to me and starts to flame about social games being shit, I’ll just silently shake my head and label them ignorant. I encourage you to do the same.

The Axis of Evil... Game Design

Fri, 13 Apr 2012 23:26:00 +0200

Long time no blog because of NDA and what not but this just became too interesting not to share. GDC12 happened lately and one of the many things I took away was this ongoing discourse about the morality and ethics of game design and their business models. Before concluding anything, let me paint a picture of how I currently feel the discussion is flowing with a few practical examples:

Art for the sake of art

These people feel that design should always map completely new ways of interaction and introspection. Players will do things they never dreamed of and discover things they have never discovered, either about themselves or the universe. Each new title is a contribution to pushing the cutting edge of our collective understanding of interactive design. Money is completely secondary and will follow if your design achievement is great enough.

Good cases: Minecraft, Defcon, Narbacular Drop (renamed to Portal), Braid, Crayon Physics etc.

Bad cases: The millions of forgotten indie titles/mods that never made it

Business for the sake of business

Money makes the world go around and big money is a big achievement. Games are a good way to form habits around things that people like to do and then allow constant spending on their infinite journey. We can optimize for player profiles to maximize revenue and make non-paying players as viral as possible to get in more paying customers. Who cares about all this fuzz about art when there is big money to be made, your next mortgage is calling and afterwards you can buy all the art in the world?

Good cases: League of Legends, World of Warcraft, Diamond Dash(?) etc.

Bad/evil cases: FarmVille, gambling and other habit forming money machines

Now, I hope you were already pissed off by the two rough categories. My point is that there are clearly different people doing different games for different reasons. This would be a non-issue, but game design affects business and vice versa. That means that we can’t ignore one over the other but actually have to choose. An economist would suggest that the optimal strategy is to do as much art (or business) as possible with minimal business (or art) necessary, assuming art means taking risks and endangering reliable business. The problem of course is that we don’t know exactly where the sweet spot exists and what things affect it.

I’d like answers to the following questions:

Is business always ~~evil~~ counterproductive to making great design?
Is it inherently evil to design for what users want? (as opposed to what they don’t know they want)

Or in a bit more depth:

Does including business in your game design corrupt the design itself? One could argue that to create a game that requires hundreds of man-years to make you need money somehow and designing a sustainable game business is a worthy goal.
Is it reasonable to expect every successful art project to become a well monetizing hit without any regard to user consumption patterns? Why are you designing downloadable one-off products when over 90% are known to pirate it that way?
If spending money on virtual energy is evil, then why subscribing to WoW is ok?
If paying money instead of playing (skipping progress) is evil, then how do we explain massive off-game money selling operations in MMOs? Could WoW be made free for everyone if Blizzard directly sold this money to players?

Conclusions!*
(*may not include any conclusions)

After pondering about all this for a while I think many game designers have a problem with the marketing side of business: you make people do bad decisions (buy stuff they shouldn’t have). Still they price their games at 9.95 to make it seem cheaper and do impulse buying inducing “90% off” sales. To me this contradiction means that we have become used to some amount of marketing psychology and take it for granted. This makes it very hard to draw the line between the art/business sides of thinking while remaining consistent with your internal logic**.

Maybe all this could inform a “fair trade” style business where people have more transparency in to what they are paying for (Kickstarter style) and how it’s being used to give them that consumer story that justifies otherwise unnecessary spending? Ideas welcome!

**Also I think in the end it’s important to note we don’t necessarily HAVE to be internally consistent. Like quantum physics or women, I think it’s fine to be in a superposition or different opinions even if you end up contradicting yourself. At least you have an opinion.

iOS != Cool for Games As a Service

Tue, 06 Dec 2011 23:45:00 +0100

Lately I’ve been involved a lot in the F2P side of mobile gaming (Sherlock points for people who know why) and it’s actually a bit trickier than one might think. I’ll skip all the nonsense about what platforms to use and why because ultimately I’m only interested in the one where paying users are: iOS. Feel free to laugh at me when you’re reading this in five years and everyone know the big thing is J2ME again.

So: F2P on iOS. Sounds fun and profitable, the CEO says, let’s do one. The thing about F2P, tho, is that those games act like services. They continue to require your attention after release and nowadays involve very, VERY large backend operations that make all the cool social network action happen. Many F2P games actually also have some sort of persistent state world going on that also is very taxing on backend. Also those games require customer support 24/7 on all available languages, so in fact at least 50% of your operation is just that: an operation. Did you have an operations team in place? No? Time to go shopping.

But beyond the problems of running an international service, you need to worry about how that service will feel like to users. A big deal in FB F2P is frequency of patches that allows for a really rapid bug fixing and under-the-hood development. Most games get weekly patches with new content and all kinds of elaborate changes in them. This means that you can truly release early and release often, because you can scoop that water out very quickly if your ship starts to sink. Not so on iOS.

Submitting stuff to App Store is a big hurdle. I’m not just talking about the actual submission process and all related dealings of making a release in multiple languages, but also getting your users to install that update. You can’t just change some files online and boom. A large part of your user base will forever use the buggy release from months back and miss all the cool stuff you implemented since to actually get some money out of the game. You simply have to support all of your versions forever with your backend, so you can’t just deploy the latest and greatest API without taking steps to ensure that the experience is satisfactory to all of your paying users. Even the ones who don’t give a shit about your updates.

Then there’s the little thing about handling customer support. Say, if you spend 10€ in an iOS game to buy premium currency and you lose all of that because of a bug, what do you do? It’s not like there are any customer support buttons in the app, and you’re using a phone while driving in the freeway and juggling two babies so no time or energy for googling the issue. At best, you will leave a flaming review in the App Store, because that’s apparently the channel you are meant to use to give feedback about apps.

Well then, as a developer you see all these one star reviews about stuff going wrong. What do you do? There’s no way to a) know who the users are in your game, b) contact them for a compensation or c) find out what caused the error because of the previous two points. Simply put, you can only watch your “community” write reviews and that’s it. It’s a one way channel like buying Kellog’s from your groceries.

What a wonderful platform for service models.

All that ranting said and done I’m gonna shut up and continue to develop our next mobile F2P game that will in any case be one of the best experiences of that genre on any platform. Mobile is still the king, even if it tries not to.

Implications of UI Heavy Development

Tue, 22 Nov 2011 22:33:00 +0100

This time I want to weight in on something that seems to happen over and over again in pretty much every project I’ve been part of or that I know extensively about.

Everyone underestimates their UI.

I’ll skip the part about why UI (in-game HUD, pause menus, main menus, tutorial crap, social features, multiplayer lobby stuff etc.) is super important to your total user experience so let’s just assume it is. Let’s say you have a game prototype (because mere ideas have no value, right?) that is proven to be fun and will lead to Awesome Gameplay™. How long do you suppose it will take to package that to be a product? Making the prototype took about a weekend so let’s say 24h of work.

An arcade game that’s all about repeating environments (no, procedural-environments-and-textures-and-evolving-ai says the designer shortly before getting decapitated) and fairly simple game mechanics might need some five times more content, so 120h. Then it needs a decent amount of polish, at least twice as much as you spent doing it in the first place, 240h. Depending on the platform you then use one week to do all the required menus (splash, main menu, achievements/leaderboards, loading, pause, win/lose, and some extra) and spend one more week to iron out random bugs from the whole thing, 320h. Multiply that with the team size, add in 2x more time for marketing and then some for every non-senior member. Making even small games takes a long time and I’m being pretty conservative here.

But what if the game was not an arcade title on one dedicated platform, but a multiplatform (Unity 3D platforms for example) equipment grinding RPG with FB, Twitter, Game Center, OpenFeint and WhatEverHere integrations? Why constrain yourself to just one platform or social service when the technology and design easily supports all of them, right? Well mainly because every feature you add needs their own UI flow.

I started to write a case study about our current game and how many screens or notifications we needed to add for different features, but I realized it would take literally an A4 or more to just list everything. We went from a very, very small core game (one screen + results, menu) to well over 60 unique screens and maybe another 40 different pop-up messages and sub-selection screens just by adding all the platform specific features, social network logins, settings, achievements and thousands of different edge cases of what-happens-when-you-do-this.

So: if you want to keep your game manageable and/or it’s a hobby project and/or has VERY limited resources, minimize your problems by avoiding everything you can. You can either release the game or spend three more months to do that next piece of packaging/multiplatform support/updated external SDK integration that you simply won’t have time to deliver.

iOS Build Size Limit

Tue, 25 Oct 2011 19:11:24 +0200

So you want to make your own iPhone/iPad game. Or maybe port an existing product over to the platform(s). Here’s one of the things I bet you didn’t think about yet (unless you’ve done it before): you WILL run out of space. The iPhone build size limit is 20mb for apps that can be downloaded over 3G and believe me, you want to be in that crowd.

Here’s some simple math for a universal 2D game. 3D games have a smaller problem, but still face the same challenge. In the same build you have to include a) all your normal iPhone assets, b) all your retina assets (4x pixels), and c) all your iPad 1024x768 assets. That’s two supported aspect ratios and two DPIs of one of them. Ouch. And just wait for the upcoming retina display iPad (2048x1536). Think of how much one lossless menu background image is going to weight with that resolution! Also don’t event think about skipping the lower resolution assets and just scaling down, because you will run out of memory on older devices and also your art director will murder your face for ruining their graphics with scaling.

Now obviously something needs to be done here. It doesn’t really matter what’s your solution as long as you consciously try to make everything fit with a reasonable effort to get it done some day. Vector graphics are one good contender, but then again tell that to your Photoshop-breathing UI artists and already overworked programmers.

A thing I’ve done in the past is to actually design the iPad UI with retina and normal iPhone assets. The size differences are big enough to allow for versatile design and in my current project we were able to recycle over 90% of all our UI assets. Some downscaling was done to buttons, but our art style was simple enough to still make it work like a charm.

Bottom line: iOS is not a single environment. You will have to think of it as a multiplatform project from the start and how you are going to manage all the details, starting with your build size. Not a super hard problem now that you’ve got it on your list, right?

Make Stories, Not Products

Mon, 10 Oct 2011 21:27:00 +0200

Here’s a short one about what I’ve been thinking for the past year. Why do you buy games? Why do you prefer some game companies to other ones? Why is Minecraft so much cooler than CoD XXXII? Why is your own game so much better than anyone else’s?

I believe a part of the answer comes from behavioral psychology. Apparently we as humans don’t really get attached to things, but rather what these things represent. Consider the story of black pearls. Originally they were found well after white pearls were considered the hottest (and most expensive) thing to have and they didn’t really sell to anyone. Then the clever people decided to put a ridiculous premium price on them and make adds that placed these pearls among the most expensive vanity objects in the world, and suddenly they started selling like hot cakes. They changed from mundane looking misty objects of no value to a symbol of extreme wealth and status.

So: what does your product represent?

Another story tells about this person browsing an antique store. He found this very old looking silver watch that had detailed carvings of a ship in a storm and beautiful, time worn details. He imagined the generations of captains wearing this watch on their perilous adventures and how he would be showing the watch to his friends and recounting all these tales of past heroes, now symbolized in the watch. He was ready to pay well over a hundred, maybe several for the thing and asked the shop keeper for it’s price. As it turns out it was a normal replica with a price tag of around 20 dollars. He didn’t buy it.

What is the story of your game that your players can a) be a part of or b) tell to their friends?

I think this is what separates very successful indie developer apart, they create their own public presence and imago that people want to be a part of and don’t mind supporting the company with either money or social activity. This is called dealing within social norms. It’s like being friends with someone and exchanging favors. Only a few companies can truly keep this up, but the ones who do gain an immense social status and a loyal community of supporters that will carry them for a long time.

Business School of Game Design

Fri, 23 Sep 2011 11:00:00 +0200

In today’s game development it should be fairly clear that game designers have a huge influence in the overall success of the game as a product. I mean this in a deeper level than just avoiding “the game sux lol” reviews. Get your thinking hat on because the next few chapters are a bit abstract.

Primary responsibilities for a game designer would of course include figuring out the core mechanic, game setting, “packaging” (meta-level objectives etc. that facilitate the core mechanic), and so on. These choices have a huge say in the marketability of the game and how people will approach it. The obvious example is to consider games like Tekken and Def-Jam that have a relatively similar approach to what the game is all about, but go about it in a different way and end up selling to a different market segment with different key selling points.

This is very much emphasized with freemium games where the monetary success of a title is directly influenced by the game designer’s ability to keep the game fun and fair to both paying and non-paying users while nudging people to pay. You just can’t design a successful freemium product without having both the product and design angle included from the start. Now this is where we start to make an already hard task near impossible.

At the moment I’m aware of two effective ways to tackle this problem. First one is to have a solid executive team that fights a lot and always ends up with the best possible compromise. This could mean a CEO representing marketing (I can’t sell that!), a creative director representing design (We need more helicopters!), and a development director representing reality (That feature will not happen in time!). Each individual can fully immerse in their mindset and angle of view to come up with the best possible ideas regarding their field and ensure that all bases are being covered. Sadly, these solutions are reserved for the big development studios because of their big overhead.

The other alternative is to do away with dedicated designers and producers and have product managers instead. These people will develop a schizophrenic ability to consider both design decisions and their market impacts at the same time. This is a very lean way to do things, because product managers basically become The Man that can rapidly answer any question about the game without constant meetings. The dark side is of course that it becomes very hard (or impossible) to think outside of the box, because the role requires constant self censorship. The remedy here is to empower other team/company members to come up with the blue ocean stuff and then merely filter it down to the most effective/realistic ideas.

So what is the bottom line here? As a designer, get a grip on the reality and how design does not happen in a vacuum any more. As a business person learn to understand how changing critical design mechanics affects the whole game experience and why making fun games is hard.

Then again you could also just have another meeting.

Schedule Margins

Mon, 19 Sep 2011 19:23:00 +0200

Here’s something dangerous: padding time estimates. We all know how hard it is to even try to give a realistic estimate on producing world class art. Especially if it requires innovation in development techniques or artistic vision. At the same time developments simply need to have boundaries and limits to function as a business and to actually get something done.

The argument basically goes that padding time estimates is a dangerous road, because it might cause a variety of different emerging problems. One of the biggest ones is accepting and/or tolerating lazy work practices or mistrust if people figure out that you aren’t taking their estimates seriously. On the other hand you might also have a chain of baddings done on different managerial levels and the final estimates won’t then in turn have a lot to do with how much time people think they will take, etc.

At the same time, you simply have to pad the estimates. Especially in a junior team. They will not be able to figure out the complexity of their tasks before hand and also some very basic human psychology traits tend to sway these already erroneus estimates on the over-positive side. You have to take this in to account and usually yelling people to make better estimates isn’t the immediate answer.

There are a lot of percentages out there that work as cool guidelines on how much air should be added on everything, but I prefer to do it case-by-case. It is important to understand the reasons why people go wrong with their estimates and then prepare accordingly. Overall I believe it’s a very bad sign if you feel like the schedule is packed and there is no room for error or unexpected developments even for just one week.

Of course in the long term you need to aim for better work estimation to make better games in the time you have. Going back to my earlier posts on double loop learning, I believe it’s crucial to let people know how they are doing with their estimates and try to collectively aim for more accurate results. It is a very, very long process that won’t necessarily ever end, but just having that conversation regularly will give everyone critical insight in how game development really works.

Here’s some context for my blog: a prototype we delivered...

Tue, 30 Aug 2011 11:00:05 +0200

Here’s some context for my blog: a prototype we delivered on time without any crunch. Mad props to the whole team!

Playing Tag with Dependencies

Sat, 27 Aug 2011 23:14:00 +0200

Long time no blogging and now it’s time for insane dependency noodles! Dependencies are a familiar thing for programmes and they will get painfully obvious as you try to do any complex team work. In short a dependency relation is created when you need X to happen before Y can get done. Usually X and Y are performed by different persons. That’s not the hard part.

Dependencies cause interesting challenges (read: stress, confusion and inefficiency) when way too many factors have to be considered at the same time by so many people that there’s no way for everyone to have the big picture in their heads at all times. I’m going to illustrate this with the magic of a real life example from my last project. Consider the following (simplified) situation:

Three programmers are divided to work on their own areas and all of them need specific stuff from design/art to inform or test their systems.
Four artists again all work on their own assigned areas to produce the required assets. This time they also have dependencies from other artists as well as the designer and producer (models before animation, concepts before models, asset reviews all the time, etc).
The designer has a lot of R&D related tasks on his own and generally needs to provide materials for other team members not to make their stuff stall.
The producer (me!) has regular presentations/other handouts to deliver that require a constant stream of deliverables from everyone as well as maintaining and developing the internal workflow etc.

Now, in this situation all people have ideas of what they’d like to do next. That usually isn’t what should be done.

The correct answer is to carefully talk to everyone involved and craft ~~an illustrative flowchart~~ a messy noodle that gives you an idea about how the workflow will play out. I find it hard to predict this more than a week accurately, so I don’t bother. The key thing here is that no blockades are created that would prevent people to do what they do best.

And that’s what you, the producer/lead, are there for, right?

Maybe Logic

Tue, 21 Jun 2011 11:00:00 +0200

This post gets a bit philosophical but still very relevant to day-to-day game development. This time I’m all about distinguishing facts from assumptions and perceptions.

Consider what you think of as facts. People eat because they are hungry? The sky is blue? Tampere is cooler than Helsinki? Wrong. These kinds of things actually aren’t pure facts, but generalizations based on your earlier experiences. They simplify facts and allow for rapid decision making on-the-spot with the expense of accuracy. Sometimes it is obvious that our generalizations might not hold water under all circumstances. I might eat snacks because their taste, not my nutritional levels and Tampere might appear uncool to people from other cities. However, sometimes it’s far more complex and you might jump to erroneus conclusions. For example the sky isn’t technically blue. Its color is largely based on the prismatic scattering of light in the atmosphere and is thus affected by sun’s relative position and the quality of air. In many cases the yellow and purple tints make skies so much more interesting in pictures and paintings.

The point here is that sometimes being sure about things is counterproductive. Portraying opinions/perceptions/generalizations as facts in conversations can lead to polarized arguments that are hard to resolve. During the game development process being too sure about anything is also a good way to notice critical problems too late.

Solution: maybe logic. The idea in all its simplicity is to avoid saying “is” and instead fix it with “maybe” in some form or another. This will transform “That idea is fool proof” in to “That idea might be fool proof”, or “The game needs more zombies” in to “The game might need more zombies”. The very simple switch in words causes you and your listeners to be more open to other options and different interpretations of the situation at hand. Things aren’t always as they seem at first and this is a good way to make sure that other views are considered.

Or maybe all of this is just philosophical bullshit.

The Art of Zero Inventory

Thu, 16 Jun 2011 19:53:00 +0200

Throwing away perfectly fine stuff is never cool and game development isn’t an exception. It is the easiest thing in the world to “pre-empt” what the game might need in the future and develop assets or technology to support it. Before you realize, that feature is getting cut and all your work will end up collecting dust or worse: erased.

Sometimes feature cutting can’t be avoided. For example my team just lost a considerable amount of work on our current project because we had to switch platforms in the middle of pre-production. New platform means new controls means new gameplay means new visuals etc. While there is definitely something to be gained about doing all that extra pre-production in the first place (better understanding of our project, our team, etc.) it still frustrated everyone because you usually get no credit for work that never gets released. I would agree with the saying that art only becomes art when viewed by someone and that’s where most artists get their passion to continue. So how do you prevent the loss of work?

The best answer I’ve worked out thus far is strict inventory management. The idea is to avoid doing work before it’s needed, thus building an inventory of unused assets (or code or design or what ever). This approach makes a lot of common sense (model three houses instead of one while you’re at it) but is dangerous because it’s betting that those assets will be required later on. In a way you are then committing to features before they are explicitly required and that can cause problems. In game development it’s completely normal to have rapid design changes that cause complete levels and features to get cut relatively late in to the production cycle. It’s very dangerous to assume that something will get eventually implemented if it’s not in the very immediate roadmap.

So, if changes are bound to happen often in the production, it makes more sense not to build an inventory of stuff that might get scrapped next week. Lean development methodologies take this very seriously and they like to view production as a long pipeline. It takes a certain time for an asset to travel through the pipeline (concept to final polish) and in a perfect world there will be no choke points in that pipeline. For example if it takes one day to concept a character but two days to model it, we have a problem because we will build up an inventory of unused character concepts. Instead of concepting extra characters, could the artist work on something else that has more immediate benefits for the project? That way no work will be lost if we decide that there is no more time to implement all those characters we wanted earlier. In a programming world this might refer to over-engineering background systems to prepare for features that never get implemented.

In short: aim to only do work that is absolutely certainly going to get implemented and you’ll end up with more freedom to change the design and/or get more work done for the final build.

Slick Presentations 101

Fri, 27 May 2011 15:23:00 +0200

I’ve gotten a lot of positive comments from my presentations lately and figured it might be worth it to recap some of the basic delivery techniques that I use every time.

Disclaimer: these are only your average presentation best practices that I continue to evolve on-the-fly, but a successful presentation has a lot more to it. For one the content and structure will have to be custom built for the audience every time and that is separate to how you present it. I’ll only touch on presenting so it should apply to everything from school presentations to professional pitches and training events.

1. Prepare for the worst

Never assume that things magically go like you want. You will not have an Internet connection, they will not have checked sounds, their computer is +12 years old and has software from that era, their projector lacks the required cables and in any case only takes in VGA (or DVI if you only have a VGA adapter), etc. Get in early, troubleshoot your system (you are running off your own laptop, right?), and even then brace for an EMP. Most often I see people having troubles with their PP slides when they design them for a larger resolution and “suddenly” their text layouts completely wrong because it was never tested.

2. Have alternatives for your software

This kind of ties in to the last point. Using some sort of audiovisual backup is a good idea, but you should always make sure that what you do can be used. What if you can’t use your laptop because it exploded and they use a different PP version or only have Linux systems? Or your slides are online but they can’t connect? I’ve had to present my Keynote (Mac) presentations from static .jpg images more than once because the situation couldn’t accommodate anything else.

3. Know your software

If you are committed to using a specific presentation suite (like PP or Keynote), take the time to know how it works. Little things like what video formats it supports and what it requires from machines to run those presentations. Saves you A LOT of grief.

4. Colo(u)rs

Get a sensible color palette for your presentation. No black on white. Or white on black. Or yellow on blue. Or green on brown. Get online, go to a color community (such as the excellent Colourlovers) and pick what ever people like. They like it for a reason that you don’t have to understand. You can also use a nice presentation template, like I always do.

5. Typography

For the love of god, PLEASE pick something else than the default PP font! You don’t want your presentation to give a generic copy-paste feeling. Again, get online to a font directory with free fonts (such as Dafont) and get what ever makes sense. Don’t be afraid to use different typefaces for headers and label text, as long as it looks good. Good templates also usually have cool font choices.

6. Less text, more pictures

In presentations you want the people to listen to you and have their attention on you, not the slides. Basically if you have more than three sentences in a slide I will classify it “very bad”, because people will read all those things in a different pace than you talk, thus throwing their attention off the track. It is simply not a good choice. Instead try to include interesting pictures and short texts that have a lot of impact and support what you are saying. Impact is the key work here. Everything in your slides must be meaningful and interesting in the context of what you are talking.

7. Animations

Depending on what software you are using, adding animations is a breeze and really pops off your presentation. They will guide the viewer through your presentation in subtle ways that really add to the whole experience. For example I usually fade some things in on the slide after the main transition so people understand what is the main content and what is kind of a side note from my part. Or fade images in one by one to tell them what to look at next. In any case, transitions do add a lot of wow factor to your stuff if used correctly.

8. Clear flow

You might be familiar with the Hollywood arch of story (the monomyth) that loosely act as the skeleton of almost all compelling stories ever told. You need to have something similar in your presentation. No pressures. Basically you need to think about the flow of your presentation and how you build suspense and/or excitement before reaching the epic finale. It all goes to making sure that people get sucked in to listening what you’ve got next.

9. Engage the audience

In my opinion all good presentations are ever so slightly interactive. Don’t stay behind a podium, look at the audience, react to them, and use you bodily language to deliver your message. Make it feel more like you’re in the audience and telling a good story.

10. Don’t drag on too long

Time your presentation before hand and make sure not to get stuck explaining about obscure technical details. It’s boring. If they get interested, they’ll ask. Also too long presentations feel unprofessional and badly structured/bloated.

11. Practice

Practice it silently in your mind.

12. Practice more

Practice it with your mirror.

13. Practice even more

Practice it with your friends.

My setup:

All that said, my process of making a presentation is very simple. I always use Keynote from my own laptop with contingency plans in place. I always put some time in figuring out what to say, when, how and what kind of visual material would support that message. Then I let the presentation rest for a while before picking up again and polishing the corners with any other changes that I feel like making.

Basically as someone said last month, I give a shit about my presentations.

Is Dropbox Cool for Serious Development?

Mon, 23 May 2011 10:20:00 +0200

I assume everyone in the Internet knows about Dropbox at this point. If you don’t, you should seriously consider making a free account (help me out and use my referral link, pretty please), because it is one of the best synchronizing services ever made. We all know how brilliant it is on personal usage, but how about as a part of your game development workflow?

It makes no sense in a huge team for a few reasons, so I’ll set the context to a small development team: 2-4 artists, 2-4 coders and 2-3 other people (design, audio, production etc.). There are a few pros and cons that I have faced using Dropbox in a team like this.

Pros

1. Always in synch (duh!)

It is a no-brainer that you always want to keep everyone in synch as much as possible. It is very easy to accidentally start to work with an old version of a file and there’s a lot less overhead when compared to the traditional flying USB-drives. It will also keep multiple workstations from one person always up-to-date (desktop, laptop, etc.). There are other ways to synch files, more about them later.

2. Online and mobile access

Sometimes you might need access to some assets away from your workstation. Even tho I usually use a laptop and have a copy of everything in it, I might want to spontaneously pitch the game to someone or get a second opinion on some asset. In those cases nothing beats up getting my iPad out and surfing the Dropbox app to access the files in question, or doing the same with any web browser.

3. Automatic version history

Never ever underestimate automatic and frequent backups! In our latest project a Maya file got corrupted and the artist would have lost a full day’s work had he not used Dropbox as his save location. We could just fire up the web browser and roll back to a slightly older version.

4. Multiplatform

Works just as advertised on all relevant platforms, so people can use what ever OS they prefer to do their daily tasks.

5. Decentralised

While Dropbox is based on SVN that is by nature an authoritative system, every user retains a completely working copy of all files on their computer. Very handy (as in mandatory) feature in case of connection loss or backend problems. Never lose access to your files.

Cons

1. No real collaborative features

Aside from sharing folders you can’t work with the same file at the same time or see any project-specific metadata on them. It is not uncommon to get lost in to a sea of work in progress files and folders if the naming conventions slip up. It also doesn’t really integrate any workflows to see who is working on what in the spirit of lean development.

2. Not cool for code

Dropbox wasn’t made to manage codebases and thus lacks a lot of features one might expect for that purpose. Programmers are better off using their own parallel solution for The Build. Preferably GIT for maximum reliability.

3. Free isn’t enough

Unless you pull off a ton of referrals and do all the available tricks to get more space for every member in the team (not going to happen), people will end up having to pay the monthly fee. Artists require tons of HDD, especially when working in HD resolutions.

4. Not a completely encrypted protection

While in my opinion Dropbox is doing a good job with encryption, they do retain keys to decrypt your files and are bound by law to give those keys over to any government agencies that feel like taking a look. Now, depending the country you are working on and the type of your project, I for one would hate to potentially expose all that work, especially if it’s mission critical. I have zero trust for governments not to abuse their power.

Alternatives?

While I do think the mentioned pros out weight the cons, it’s always good to remain open for alternative solutions. Here’s a few that I have considered this spring:

1. Random version control solution

There is always the option to using SVN, GIT, Perforce or what ever else to all your project files. I have found all those systems really heavy for non-programmers. It makes a lot of sense to have The Build on one of these and have everyone commit their assets there once they are complete enough, but for other states they are simply not agile enough when compared to Dropbox. And not all files that need to be shared belong to The Build, such as various internal documents, marketing material etc.

2. Google Docs

Google has been upgrading their online office suite to include file sharing. It is still not even remotely automatic enough to surpass Dropbox on anything art related, but as of this writing it is supreme for shared text and spreadsheets. Nothing beats having multiple people work on a single document at the same time and having those accessible to all instantly, with a full version history. I plan on keeping all my project documentation there in the near future.

3. Dropbox ~~clones~~ competitors

There are a lot of new services trying to dethrone Dropbox. To me the most interesting one comes from LaCie, something called Wuala. Their relevant key features over Dropbox are complete encryption and storage space trading. Trading is an alternative to buying space: you can allocate any amount of space from your drive (externals included) to be used by others and you will gain the same amount for free, multiplied by your uptime percentage. So 100gb traded * uptime of 90% amounts to 90gb gained. I will strongly consider evaluating Wuala for our next small project because these features. It’s hard to beat free!

4. Network drives with VPN access

Solution from the ’90s! Using internal company servers is a cool idea, but it lacks a lot of the features available in Dropbox, such as automatic version control, asynchronous synching with offline availability and web/mobile access. Also, file system compatibilities are completely and utterly [offensive social minority joke here] at the moment for different OS combinations.

5. Flying USB drives

No. Just no.

Conclusions

There are always a few drawbacks to every possible solution, but I think Dropbox and its competitors are a very nice fit for small projects. They have no place in a massive scale production and they don’t cater to every situation, but all that is in my opinion offset by the sheer ease-of-use and agility offered by at least Dropbox. Combined with a good version control, Google Docs and n+1 whiteboards, I feel confident in being (as of this writing) always on top of my projects and not the other way around.

tl;dr Yeah its good.

Hack Your Own Game

Mon, 16 May 2011 11:00:00 +0200

Computer security, what a boring sounding topic! It is in fact so boring, that you don’t care at all. Until you’re Sony and someone steals all your unencrypted customer data (some of which you shouldn’t be saving anyway). Or until you’re Valve and someone steals all your Half-Life 2 source code before release. Or until you’re [place any online game company here] and someone develops [place any game balance breaking hack here].

I’m not a hacker or a security expert or even a real programmer, but it takes none of them to know how stupidity can and will lead to security breaches. Some of this stuff really isn’t all that relevant to single player experiences where hacking the game only affects that single instance. Basically it becomes just a form of cheating. But then there are the two other levels that you should be very interested in:

1. Cheating in Online Games

I admit to doing this. After a period of time I get bored with a given online game, such as an MMO. After the game no longer gives me meaningful goals but I’d still like to interact with it, I ask myself: “Right, so how can I game the system?” Let’s pick WoW as an example. Using a simple macro tool it took me one evening to do a fully functional and reliable fishing bot during the open beta of WoW. Unsurprisingly, I think I got server’s first max. fishing when the game actually launched. Later I combined that to simple wall hack to make it completely fool proof.

Now, making a fishing bot in WoW is probably the simplest thing on earth and the developers noticed it immediately during closed beta. That’s why for the longest time fishing had no value what so ever, unlike other trade skills. Blizzard responded with their Warden Client, an anti-hack tool that does all kinds of messed up stuff to flag cheaters (you’ve read the EULA and ToS after every patch so you know they read your email and IM chats, right?). Of course, my fishing bot has remained unaffected for all these years because I wrote it in a way that they can’t detect despite all that. Sucks, huh?

This is an ongoing battle in online games and usually it seems like cheaters kind of win, especially in MMOs. If you are planning on making an online game that will be messed up by people tinkering around with it, consider making a highly authoritative server structure or make a game like Minecraft where cheating is pointless and/or does not mess up the whole experience for everyone.

2. Actual Crimes

Unfortunately nowadays it’s about much more than generating virtual currency and items. There is value in personal details, because they help the real criminals in their evil deeds, such as emptying your bank accounts or doing corporate espionage. You also happen to be sitting on a pile of this information if you run a service like an online game. How do you protect it? Can you really, honestly say that your customers can trust you with all that data?

So… Any solutions?

I recently had a talk with a very senior ethical hacking person and he was just laughing about how easy it is to by-pass security if you really want to. That’s why they train people like ethical hackers. They know all about how to break things. They will examine your system bit by bit and bring it down in ways that you thought was impossible and expose all those vulnerabilities. And then they will help you fix all that so someone else doesn’t do it. There is no such thing as perfect security (Stuxnet, anyone?) but at least they make breaking in to your system very, very hard.

Sounds expensive? Well, don’t worry. I’m sure your service will be juuuust fiiine. Like Sony’s.

Design by Intuition VS Knowledge

Fri, 13 May 2011 15:55:00 +0200

A few weeks back I started to read a book about the underlying theories that guide all great photography. In it’s preface the author makes a clear distinction between two types of approaches to photography: one based on knowledge and the other on intuition.

There is nothing inherently wrong in relying on one’s intuition when designing things. A good “eye” for enjoyable game design does go a long way and can produce incredible results. However, other fields of design show that knowledge based design does work better. But what could knowledge based game design mean anyway?

Example: 2D platformer protagonist jump height

Have you ever noticed how great platformers tend to feel somewhat similar when it comes to jumping (arguably the most important part in them)? It’s actually not because they copy each other, but because certain jump heights/lengths feel more satisfying than others. In fact, the Mario games (for one) have apparently hit the sweet spot in what simply is the best feeling platformer jumping possible. (I didn’t make this up, there was a study about it somewhere and it has to do with the world scale, duration etc.)

Now, armed with this knowledge you could either randomly start testing from some jump parameters (that the programmer came up with after reading some tea leaves) and iterate towards that Golden Jump based on your intuition (assuming you have one). Or you could analyze the competition and read some theory on how jumping works to arrive at the same conclusion.

In real life I have seen great designers use a combination of both approaches, mainly because there isn’t that much solid, practical theory out there as of this writing. The best practice seems to be simply to use user testing instead of intuition, because generally our intuition sucks. And that’s where things start to get really, really complex and expensive as a development process.

What I would like to see in the future is a nice book (with a lot of pictures and big, round font) that would discuss the elements of game design. Understanding contrast, guides, resonance and flow of interactivity just to begin with. Actually it should be an interactive book on a tablet with real gameplay examples. If anyone is interested in developing one, email me!

*edit: I got a good comment about how data driven game design could be viewed as knowledge design. I meant to cover this originally but kind of forgot, oops. Personally I think pure data driven design is just constituting intuition with user feedback. We still take a very reactive attitude in to design rather than a theoretical approach in to how it possibly should be in the first place according to what we know about ludology, graphical design etc. User testing is still of course a very smart way of validating your design, but that’s only after some design have been made based on either knowledge or intuition. And remember: either way is cool as long as it works and you got there efficiently.

Forget Games, Make Demos!

Thu, 12 May 2011 13:09:00 +0200

As it stands out, us western people are very, very technical in our approach to making games. We often consider the possibilities of our available platform(s) in tandem with our game concepts to make most of what’s there. Sometimes the reason might be to make the game feel right/novel in according to what’s the platform’s unique selling point (touch screen, online connectivity, etc.) but quite often I find it’s just about using as much power as possible. We all (apparently) want to (try to) create the ultimate audiovisual experience on a given environment.

We could go deeper in to this reasoning, but that’s not the point. The point is that if we (the artist, the creators) have this urge to create mind bending multimedia, what does it do to the game itself? All decisions in game development are tradeoffs. You do something at the expense of not doing something else. So what are we overlooking when we allocate resources to better particle engines, shaders and animations “because it’s cool”? While the answer is not simple, I’ll put my neck out and say it’s the game design.

If the game is defined as an interactive experience for the purposes of this argument, the question is if improved graphics really contribute to your vision to make the best game ever or to your vision to make the most awesome graphical masterpiece ever created? I think they often end up being separate goals that get pursued on a personal level during many game projects. It is one of the things that keep certain developers interested in the industry. I find all this very problematic at times when hard decision need to be made.

So to cut a long story short, I think those developers should make demos on their free time. With demos I’m of course referring to the demoscene. If you are not intimately familiar with the demoscene, please have a glance at the Wikipedia description and download a highly ranked demo from Pouet.net or watch some recording online (for example this 4k is amazing). Demoscene is all about pursuing those artistic visions that can’t always be the focus of game projects. It think the main benefit is to recognize the goal of making realtime art and not involving interactivity (gameplay), because that way you can keep the scope to a minimum. Not spending two months on user testing for starters. Making a demo also contributes to portfolios and overall is an excellent showcase of raw talent, something that people sometimes want to embed in game projects.

Conclusion

Games shouldn’t be all about technology and graphics. They should be about experiences. If you are all about tech, consider contributing to a demo and not mess up the game by channeling all those ambitions in to it. There’s an audience and they’ll love you for it.

Translating is not Localizing is not Culturalizing is not Fun

Fri, 22 Apr 2011 16:39:00 +0200

I don’t know if you have ever considered localizing your games to other languages, but depending on the market you’re after you will think about it a lot. Here’s a few tips that would have gotten me started a lot better:

1. It’s more than translating

Really it’s not just about taking a few hundred string data types and running them through Find.CheapTranslators().Translate(); You have to consider how your game experience changes as words get considerably longer or shorter and probably completely out of synch as some locales need to add or remove lines to convey the same (or equal) meaning. Think of it as localizing your game instead of simply translating a piece a text.

2. It’s more than localizing

We have the beautiful benefit of all these different cultures and religions around the world that seem to use most of their time disagreeing with each other. Some themes and messages that are completely ok in the (arguably morally bankrupt) USA are totally and completely banned in the east with pretty much everything banned in Australia. Instead of simply localizing your content to another language, sometimes it is necessary to completely culturalize your game to appeal to them. This is a big topic in itself, but even just keeping these issues in mind will help when designing multicultural games.

3. It’s definitely a pain

Ok, creating multicultural content can be fun, but it requires a lot of effort. Pile that on top of the effort of actually making your game work in the first place. Then add in that user testing you forgot, now with different locales to test. And the marketing materials that now have to also be with every language. Oh, and localized customer support. And… sigh.

4. It’s nearly impossible if done as an afterthought

Imagine that game you made with someone walking in and telling you that it needs to be localized within [place too little time here]. No problem, you get the strings from your game and order some professional friends of friends to do a jaw-droppingly good translation with proper testing and all.

Then your artist leaves in fury because she has to now recreate all UI graphics to fit the different text sizes to all locales.

Then your programmer leaves in fury because the game does not support unicode characters or anything other than left-to-right languages in general.

[Place too much time here] later you will definitely get it done, but it’ll look and sound like Final Fantasy X at best.

5. Actual tip: images > text

Using symbolic imagery can save you from using a lot of text that needs to be localized. On a more depressing note not a lot of people are qualified to work with symbols, just ask Microsoft about how long they have been tuning their Windows Phone 7 icons.

I guess the bottom line here is that what ever you do, please take localizing your games seriously. Don’t do a half-assed job just because it seemed like a quick way to add value to your product.