Why we chose Freemium

Original Author: Kyle-Kulyk

What choice did we have?

When we started Vex Blocks, is also planned as a freemium release.  The reasons just made sense to us and still do.

As a small indie team our resources are limited. When it comes to marketing our products we simply don’t have a lot of options available to us due to our financial constraints. We’ve spoken to other developers who have been successful in the mobile marketplace and a few of them maintain that paying for ads simply doesn’t pay. Certainly the response we’ve seen to the ads we ran in an attempt to test the waters back this up. The increased visibility and downloads we received when running our mobile ad campaigns simply did not pay for the money spent on those ads. Social marketing through our Twitter and blogging efforts probably put just as many eyes on our products and didn’t cost us anything but our time.

So that leaves really only two other factors that we have any control over as indie developers: the game we’re creating and the price point we choose for that game. Now game quality is an interesting topic. We’re not so arrogant as to assume our games will be of the same calibre as games made by more experienced teams, or made by larger teams with millions at their disposal. So we endeavour to make the best games we can possibly make given our talents and the resources available to us and that’s all that can be expected of us.

We’re not operating under any illusion that we’ll create the next runaway hit. Something that always strikes me about people I speak with in the industry and developer interviews I see from successful indies is that they never know if what they’ve created is any good. There’s always that nervousness as they release their product into the wild when you simply don’t know how you’ll be received. You’d like to think that you’ve made a game people will enjoy, that you’ve made something that stands out but what you think and what the reviewers, other developers and ultimately gamers think can be completely different. Opinion is opinion. The notion that if you simply create an excellent title people will flock to it is contingent on something you have no control over.  People’s opinions of what constitutes a great game. So you do what you can.  You set out and make the game you want to make and you make it to the best of your abilities. Then you learn from your mistakes and hopefully don’t go broke in the process.

So the only option left to us, the only other thing we can control is the price, and against the hundreds of thousands of other games out there – what chance do our little, independently made games stand against juggernauts that are already charging nothing right out of the gate? Freemium isn’t the only option for mobile developers, but realistically in today’s marketplace – what choice do indies really have? Convert or die. The notion that your games are super special and people will recognize this fact and line up to throw money at you may work in rare instances where the planets align just so but that’s like putting a video of yourself singing up on youtube in the hopes of being discovered.  Sure it happens, but so do lottery wins.  For us it makes more sense to level the playing field as much as possible to maximize our chances of success. That’s why we went freemium. There’s simply too many free games available in today’s mobile marketplace to risk alienating users by asking the price of a cup of coffee for our hard work. At least, not right off the bat.

Making the decision to go freemium doesn’t necessarily mean that you’ve sold your soul to Old Scratch either. Freemium games receive a lot of grief from “core” gamers for some very good reasons. There are companies out there that use freemium and combined with habit forming hooks they keep gamers addicted to apps that more than a few gamers would turn their noses up at. There are companies that try to obscure the actual price of in-app purchases. Other companies offer multiplayer games with the option to purchase powerups to gain an advantage over other players. All the above give the freemium model, in my opinion, a bit of a bad reputation but it doesn’t have to be this way.

I prefer to approach freemium games the same way people approached shareware. “Here’s the game to try and if you like the game, please support us by purchasing some of our other options.” No tricks.  Nothing hidden.  If you like it, please support us.  I view the the freemium pricing structure no differently than offering a demo version, but the key to me (and to my conscience) is to not waste gamer’s time with a mere taste but to make it worth their while.  There are a lot of products vying for gamers attention and I always keep that in the back of my mind to make sure our products are offering up enough gameplay that I would be satisfied, as a gamer, with the amount of play I’ve received.  Then, hopefully, gamers will like what they see and respond by opening their wallets.

Four Tips for Porting Your Game to the Web with Native Client

Original Author: Colt McAnlis

When people hear ‘web gaming,’ they usually get the image of a 2D game with bad artwork and simplistic gameplay.  With the power of Chrome and console-quality games to the browser.

A screenshot of Ubisoft’s  From Dust running in Chrome on Native Client. This game, originally an XBOX 360 title, looks beautiful on the web.

Since the official launch of Native Client in December of 2011, developers have shipped overgames middleware products now support Native Client.  My role as a Developer Advocate at Google has allowed me to work directly with these early developers to assist with their porting efforts, and to collect feedback to help improve Native Client technology as well as Google’s larger gaming platform efforts. This article details what I have learned through the course of this work, so that you can get the benefit of my knowledge, in bite-sized form, to fast-track your porting effort.

What is Native Client?

Simply put, Native Client is a technology that allows you to run C++ code in a web page, as safely as JavaScript, without a plugin. This is a sweet spot for game developers, who pride themselves on optimizing for current trends in mobile, console, and desktop development, but who also like to make their games available to the most users possible.  Running C++ in a web page opens the door to reaching a slew of new users on the Internet; and game developers and publishers are aggressively embracing this strategy.

With this motivation in mind, here are my tips for how to port your game to the web.

1. Learn the basics: Understand how the web, Chrome, Pepper, and Native Client work.

This article assuming that you’re a traditional game developer, coming from the desktop/mobile/console space, and that web development is new and scary to you. To demystify how things work on the Internet (you know, that 20 Things I Learned about Browsers and the Web; it’s a great introduction.

how Chrome works – this is useful both at a ‘how does the magic happen’ level, as well as a ‘this is where Native Client is processed’ level.

The Pepper Plug-in API (PPAPI), called Pepper for convenience, is an open-source, cross-platform API for browser plugins.  From the point of view of Native Client, Pepper is a set of APIs that allow a C or C++ Native Client module to communicate with the hosting browser and get access to system-level functions in a safe and portable way. One of the security constraints in Native Client is that modules cannot make any OS-level calls. Pepper provides analogous APIs that modules can target instead. For a short introduction to Pepper, watch this section of my recent talk at Google I/O.

Finally, it’s helpful to understand why Google created Native Client, from the perspective of both  security.

2. Understand how porting will affect the structure of your game.

As I describe in Tip # 3 below, I recommend a two-step porting process: Port your game to Pepper, and then to Native Client.  Before diving into the mechanics of these steps, it’s important to understand some basic considerations that will affect how your game is structured.

Porting to Pepper

You should consider porting to Pepper much like a port to any other platform. You’ll need to change your platform-specific APIs, maybe modify some assets, configure builds, and tune performance for the target platform. Here are some big hurdles to look out for.

There are three primary things you need to understand about the Pepper APIs :

  1. Pepper APIs must be called from the main thread.
  2. Pepper APIs are all asynchronous.
  3. Your main thread cannot spin-loop.

In combination, these three issues can create difficult problems for many developers.

For instance, developers who expect fread() to be blocking, and have written their code base expecting such, will be disturbed to find that the Pepper API for file I/O is non-blocking. This can be a difficult problem to deal with by itself, but when you combine it with the fact that all Pepper calls must be on the main thread (meaning all your file I/O must now come from the main thread), things get pretty tricky.

One other important consideration is that any call on the main thread of your Native Client application has to be non-blocking; this means that you can’t place your primary logic loop on that thread or it will halt the browser. To deal with this problem, some developers immediately start a worker thread when their Native Client module starts, and run their primary logic loop on that worker thread, adding proper inter-thread communication to allow them to issue commands to the main thread (sometimes called the ‘Pepper thread’). This setup enables you to get around some of the nuances of logic control, and as a side benefit also allows you to overload fread() to be a blocking command again.  ; )

Be warned however, that the OpenGLES2 APIs must still come from the main thread, so if you do spin up a worker thread, sooner or later you’ll need to relinquish control to the Pepper thread for GL do to rendering.

Before you begin porting to Pepper, it’s crucial to take stock of the WebSockets, which provides the same functionality though with a different API structure.

Porting to Native Client

Native Client comes with its own set of restrictions, the primary one being that you need to use a custom GCC compiler to generate the final static libs, dynamic libs, and executable binaries. This means that if your application uses 3rd-party libraries (middleware, for instance), you will need to compile the libraries with the same GCC compiler in the Native Client SDK.

Fret not, however:  You can search through a list of open source projects that have already been ported to Native Client to see if your software is already there. If not, feel free to contact us, or the middleware provider, and demand Native Client support!

You should also be aware that Native Client has restrictions on some APIs that are considered harmful / insecure (for instance, some inline assembly functions).

Running on the web

Another important consideration that will impact your application is the modifications you will need to make to distribute its assets on the web. Ask yourself, “Where are all my assets going to be served from?”

Native Client applications must currently be distributed through the Chrome Web Store (CWS), and must be one of two CWS application types: hosted or packaged.  Hosted applications are effectively bookmarks:  Your game’s web pages and Native Client modules are stored on a web server that you manage, and the user visits your web site to access that content.  Packaged applications work more like a digital distribution service:  Your game’s assets, web pages and Native Client modules are packaged, compressed, and stored in the Chrome Web Store, and installed on the user’s machine when the user clicks the ‘install’ button.

There are pros and cons to both hosted and packaged applications.  For example, with hosted applications, you are distributing large volumes of gaming content to users who may or may not be paying you; as such, it may be beneficial for you to invest in bandwidth capacity and asset segmentation.  (If you plan to distribute your game as a hosted application, you should take a good, long look at Google App Engine.) Packaged applications have a 100MB asset limit; if your game is over that size, you’ll need to stream in data from a web server while the user is running the game.

Whether you distribute your game as a hosted application or a packaged application, you should have a clear understanding about how your game is going to load asset files from the web. For instance, if you are going to distribute your game as a hosted application, you can reduce the amount  of data transferred over the web by fetching game assets using the caching and streaming.

There are a number of additional considerations that you should take into account when your game runs on the web, including user authentication, localization, and monetization.  For a rundown of some of these issues, see my GDC 2012 talk.

3. Port to Pepper first, Native Client second.

Pepper Plugin First

A technical look at demo at Google I/O). While the Native Client toolchains are powerful, at this time they are not as polished and complete as a solid development platform, so put the power of your IDE to work for you.

As announced at the Google I/O 2012 talk, a Visual Studio 2010 add-in will be available soon to aid development on Windows.  This add-in will allow you to create platform configurations for both Pepper and Native Client, so that you can use your natural workflow as you port your game.

Developing your game as a Pepper plugin grants you some nice abilities in addition to being able to debug and use breakpoints properly; for instance, you can mix Pepper API calls and platform-specific API calls in the same codebase.

Native Client Second

Once you’ve ported your game to Pepper, the final step is to modify platform calls in the code for Native Client. This may involve a number of tasks depending on how the code is set up.  For instance, if the code uses threading, you’ll need to replace platform-specific threading primitives with POSIX threading primitives.  (Depending on your platform, POSIX headers may not be available outside of the Native Client SDK, which means you wouldn’t have been able to port to POSIX primitives earlier).  You’ll also need to remove any last traces of platform-specific code in your game.

Another area of concern is if your game includes any sort of dynamic code loading. You must use the custom Native Client toolchain, and compile and load dynamic assemblies through a specific process.

4. The web is what you make of it.

Don’t be disillusioned about the economic nature of the web:  It’s a booming world of monetization, driving some of the most profitable companies around, but also burying many creative voices in the noise. Success on the web doesn’t happen overnight, and it doesn’t happen for free, especially with games. Successful web games (regardless of technology) really take advantage of the Internet as a platform. They aggressively work to break out of the ‘leaderboard’ model for content distribution that currently hinders most mobile and console distribution silos, striving to reach everyone, everywhere. They prosper by connecting people and by finding monetization models that work within a fickle and often skeptical ecosystem. This is the real challenge you have in moving your C++ game to the web – once you figure out success on this front, porting to Native Client is the easy part.

Ready to get your game on the web?  Start here: gonacl.com


More Adventures in Failing to Crash Properly

Original Author: Bruce Dawson

In last week’s episode we discussed how 32-bit processes on 64-bit Windows might corrupt the exception state after a crash, and how any processes on 64-bit Windows might actually continue running after a crash. Serious stuff.

This week’s installment of “Failing to Fail” is less dramatic, but still important for developers who want robust software, as we cover failure to terminate and failures to record a crash dump.

Update: a technique for handling abort() was added to the post and to the sample code, July 22, 2012.

As a special bonus I also mention how to record crash dumps from all crashing processes on your machine, to make debugging easier than ever before.

What we have here is a failure to terminate

Crashes happen. Any program more complicated than “Hello world” probably has some bugs. One measure of professional software development is how you deal with these crashes. What should happen is that the program should save a crash dump and then commit suicide (TerminateProcess() or _exit(), not ExitProcess() or exit()).

imageWhat you don’t want is for the doomed process to put up a dialog saying “Hey, I’m a doomed process”. But unfortunately that is what the Visual C++ C Run Time (VC++ CRT) does in some cases, as we see to the right.

If you accidentally call a pure virtual function (see the sample code for one possible way this can happen) then the handler for this brings up a dialog. If you’re a developer then you can attach a debugger and get a call stack, but most of the world is not developers. They don’t know what a pure virtual function call is, and they don’t care. Displaying this dialog just slows down the crash recovery process, while confusing your users.

But it’s worse than that. If you have a bevy of exception handlers ready to catch Win32 exceptions (access violations, etc.) then you will be disappointed because they won’t catch pure-call errors, even after someone presses OK. So, your in-house crash-dump recording system is helpless against this bug, which means it takes longer to get it fixed.

Worse yet, if this error happens on a server (I’ve seen it happen) then your headless server now has a hung process that is waiting for someone to click OK. Unit tests will timeout eventually, and servers may timeout if you have a watchdog, but the whole process is delayed by this dialog.

I wouldn’t be writing about this unless I had a solution to offer. The dialog above is the default behavior, but changing the default is simple enough once you know that you should. All you have to do is call _set_purecall_handler() with a function that intentionally crashes. My preferred implementation does a __debugbreak() followed by TerminateProcess(). If I’m running under the debugger this drops me into it quite neatly, and if I’m not then my unhandled exception filter will catch the exception and write out a minidump. The TerminateProcess() is there to discourage people who catch the exception in the debugger from trying to continue.

See the sample code for a concrete example of setting this up. You can use the menu options to try triggering pure-call errors with and without installing the error handler.

Invalid parameters aren’t technically crashes

The VC++ CRT detects a few types of invalid parameters to CRT functions and it treats them as fatal errors. This includes buffer overflow detection if you use the safer CRT functions (and you haven’t requested truncation), but the simplest way to trigger these checks is with “printf(NULL);”.

No dialog pops up – at least not in release builds – and the process is terminated, but it isn’t terminated through calling your carefully crafted exception handlers. Windows Error Reporting (WER) will be notified of the problem, which is good, but I want these invalid parameters treated like a crash so that my exception handlers get invoked. Luckily there is an easy solution for this problem as well. If you call _set_invalid_parameter_handler() then you can give it the same code (just with a different signature) as for your pure-call handler so that your exception handlers will notice something has gone wrong. And now your programs will be crashier than ever before. Which is a good thing. This technique is also demonstrated in the sample code.

WER is your friend

Windows Error Reporting (WER) is a handy feature built in to Windows. Most developers know that WER records crash dumps on millions of users’ machines and stores them, and most developers know that it is possible to get access to the crash dumps for your software. This is a fabulous way of finding out where your software is actually crashing on actual customers’ actual machines. There are a few hoops to jump through, but it’s worth getting it set up. However I have no special knowledge of how to arrange such access so I will say no more.

imageA lesser known feature of WER is that you can get it to record crashes on your own machines. All you have to do is set a few registry keys. I’m gonna go out on a limb here and say that every C++ developer on Windows should configure this. It’s trivially simple and WER will sometimes catch crashes that your other systems do not. WER is great at catching process startup and shutdown crashes, crashes in processes you forgot to add minidump handling to, and it even records minidumps for pure-virtual function calls and invalid CRT parameters.

The full documentation is available here. If you spend two minutes configuring this (I have the last 30 crashes saved as full dumps in c:\temp\crashdumps) then you will be better able to investigate crashes on your machine, regardless of what process is crashing.

Update – one more missed failure type

Stefan Reinalter pointed out that some libraries will handle errors by calling abort(), and this can be another way for a process to fail without your crash handler being called. He also supplied the fix, which is to call signal(SIGABRT, &AbortHandler); to install a handler which will be called if abort() is called. Signal can also be used to install handlers for other types of failures.


It’s not enough to read about this, you have to actually do a tiny bit of coding and registry work to get things crashing smoothly. Here are your tasks.

  1. Be sure to call _set_purecall_handler, _set_invalid_parameter_handler, and signal. If you use the DLL version of the CRT then once per process is fine. If you use the static-link version of the CRT then you need to call it once for each copy of the CRT – once for each DLL that statically links the CRT. The sample code available here should help.
  2. Configure the registry to save crash dumps on all of your machines, by following the simple directions here.
  3. If you haven’t already then be sure to follow the instructions in last week’s post, including configuring VS to halt on first-chance exceptions, calling EnableCrashingOnCrashes(), and using SetUnhandledExceptionFilter() to catch crashes.
  4. Set up a system for recording and uploading minidumps, using MiniDumpWriteDump or breakpad or the Steamworks APIs.

That’s it. Good luck with the goal of more stable software through crashing vigorously.

Programmer Moneyball

Original Author: Ted Spence

What’s the secret to hiring great programmers? Do you have to have a Google-style cafeteria, or Microsoft-style interviews, or Scrum or Agile? All of those things help, but keep in mind that it’s also possible to find great talent the major companies let slip through their fingers.

The Moneyball Strategy

For those of you who might not be familiar with Moneyball, it’s a book Michael Lewis wrote about a clever baseball club that hired undervalued baseball players and got great value out of them.

Here’s how it worked for them.

The club, the Oakland As, used clever statistics to discover certain kinds of players who were not being efficiently targeted by the market. They worked out an estimate of how much these players should be valued, and ruthlessly targeted them. Because these players weren’t in demand by the other clubs, the Oakland As could hire them inexpensively and give them a chance to play great baseball.

Think this would work with engineers? It’s gotten some press recently. In fact, IEEE Spectrum recently interviewed author Stephen Cherry about this topic. Cherry wrote a book about the disconnect between job applicants who are clearly qualified, and companies who claim there are no qualified applicants. TL:DR; he claims that companies write their job descriptions to be “exclusionary,” thus filtering down their list of applicants but yet failing to find a candidate they like.

This certainly seems like an opportunity for moneyball.

I’ll share with you another secret I discovered: in the 1990s, I briefly worked for a company that wrote resume processing software. During that era, companies would receive thousands of paper and fax resumes for an attractive job listing in a newspaper, and they had to somehow filter a huge pile down to a smaller, meaningful list. The software I wrote helped them filter candidates based on keywords that appeared in the resume. We wrote lots of search tools that helped people find complex and unusual skills…

But do you know what happened? Basically, every company filtered on “bachelor’s/master’s degree” and “years of experience”. Those two filters proved to be quick, simple, easy to find, and helped them narrow down their lists considerably. By excluding anyone without these magic items, the busy HR manager could focus on only the key 10-20% of the available resumes.

This clearly happens to this day. Take a look on any job listing website and you’re virtually guaranteed to find:

  • “Bachelor’s degree in computer science or a related field required” – this is exceedingly common today; ten years ago most job listings said “… or equivalent experience.”
  • “3-5 years of experience with [current fad technology]”
  • “3-5 years of experience with [development methodology]”
  • And, in the gaming field, “Must have shipped at least 3 AAA games.”

You might be forgiven for not knowing this, but C. Northcote Parkinson wrote about this strategy in his 1958 book, “job listing so fiendishly specific and devilishly challenging that you only receive one applicant, whom you can hire right away without wasting your time evaluating the rabble. When I read through a two page long job listing that specifies dozens of “requirements” for a candidate, I can clearly see that the HR person is really trying to cut down the number of resumes they have to read.

So now that we’ve covered a bit of the field, let’s get down to business and create a theory about programmers.

Who is being undervalued?

Given what you’ve read so far, I would argue that the software engineering industry tends to overvalue things that are easy to measure. First of all, if you want value, you can’t focus on people who have advanced degrees, those are already in high enough demand that they’ll be snapped up right away. Find programmers who have innate talent but for some reason didn’t want to go through a university; find open source programmers or hackers or people who write mod scripts in their basement while getting a degree in English Literature.

Second, we tend to overvalue experience with a specific current hot-button technology. The technology industry changes frequently, so look for programmers with experience in something that was hot five years ago but isn’t now. Remember, good programmers understand serious algorithms and can often switch languages without breaking a sweat. So if we see, according to TIOBE, that C++ and Perl are declining in popularity, maybe that’s a good indication to hire experienced C++ and Perl programmers while their skills are “out of fashion”.

Third, we overvalue people who have exactly the right number of years working in a specific field. Maybe the hiring manager has an idea that they want someone with 5 years or 10; but instead, we could look for people who have an opportunity to surprise. One example is a junior person who is chomping at the bit to get a chance to prove themselves; another is a senior person who has been seeking a specific opportunity. In either case, the degree of motivation or hunger this person has for your job opening can drive them to deliver much more value than if you narrowed it down to a limited time range.

All these criteria have one thing in common: measurable text on a resume is being overvalued. What’s being undervalued is the stuff that doesn’t show up in measurable “certificates”, “degrees”, or “years of experience.”

How can we take advantage of this?

It may not be possible to hire every programmer the “Moneyball” way, but an interesting feature of the way teams work is that they have a maximum size. When a team grows beyond 6-8 team members, new dynamics start to form, and the group tends to split up into lots of separate subgroups even if they are nominally all together.

This means that you can safely build teams with a few senior members who are well trusted and capable of mentoring and guiding junior members, and use moneyball strategies to attempt to fill out the teams to full productivity. So let’s give this a try.

Clearly, we’re going to have to attract different candidates, and review them differently. First, write your job listings to be very open ended. Don’t write a gigantic list of requirements; instead, describe what you are doing, and make the job description drip with excitement (of course your work is exciting!). Describe your office culture and the kind of work you do, but leave out all the details of the specific tools:

Searching for talented programmer who wants to write user interface script modules for a multiplayer app for phone and web customers. The programmer will work in a small group of 2-3 front end team members, frequently prototyping new ideas and implementing new graphical features for A/B testing.

The goal of your job listing is to get lots of resumes – probably more than you would get the traditional way. Then, don’t filter the resumes by experience; instead, read the cover letters! Call the people whose cover letters sound most exciting and relevant. Make sure they know how to communicate verbally and describe their desire to work in your field.

Do a phone screening first. Get an idea how much these people want this opportunity, and then gauge how suitable they seem for the work. Quiz them on whether they’re motivated enough to have done some research themselves.

Does it work?

Of course it works! The dirty secret of the recruiting industry is that recruiters live and die by exactly this strategy every day. They take piles of resumes and piles of job listings, then contact promising candidates and ask if they can make “just a few changes” to the wording of their resume to emphasize a particular feature or highlight something that makes them just right for an opportunity.

Here’s a common scenario:

Recruiter: Hi there, I read your resume and think it’s great for a job opening I have. First question, though, do you have any experience with Java?

Candidate: Well, I wrote a program in Java last year to organize my home media file server.

Recruiter: Great! Can I ask you to send me an updated resume with that project listed?

This kind of thing exposes how trivial the difference can be between a resume that gets dropped and one that wins the job. Companies that focus too much on resume details are missing out on candidates who happen to be very talented but lack a magic keyword.

At EEDAR, I decided to use a hiring process that brought junior team members into our group regularly as interns, and gave them each a chance to demonstrate their skills and grow into a full time programming position. I search for candidates who specifically had an interest in programming but had no experience – and many of them came through with flying colors.

So clearly it can work, but will it, in your case? You’ll need:

  • Persistence and resilience to keep trying experiments to find programmers the market may have missed.
  • Time and attention to pay to them to see if they really are worth their time. People overlook this frequently: in the book Moneyball, not every candidate was an instant success! Some of them needed mentoring, some needed time, and some failed and had to be traded away.
  • The ability to acknowledge when you make a mistake. If a programmer seems promising but doesn’t excel within your company, you have to be honest and forthright about it, and give them a chance to move on somewhere that’s right for them.
  • Above all, a desire to reach out to people who may have a hard time getting their foot in the door elsewhere.

If you do your part, we can all find new ways to hunt down talent the market may have overlooked.


I’d also like to mention one idea that may be relevant. Recently, “quirky interviews” have become the norm in the industry, such as the Microsoft Interview or Guerilla Interviews or Google Interview. These interview strategies are extremely challenging, and tend to weed out people who can’t think on their feet or who get overwhelmed with certain types of interpersonal pressure. It’s entirely possible that these interviews systematically exclude a certain class of person, but I don’t yet have a specific suggestion about how to leverage that idea. I’d welcome your thoughts and feedback.

Pursuing Excellence

Original Author: Aaron San Filippo

[Note: This was originally posted on Flippfly.com]

Awhile back, I argued that making an excellent game should be a game developer’s #1 priority.

I also suggested that in the absence of marketing dollars:

mediocre games usually fail,

good games often fail,

and excellent games rarely fail.

These ideas were a little more controversial than I expected.

There were two common responses.

One of them was: “Who gets to decide what’s excellent? Isn’t beauty in the eye of the beholder?”

So I thought I’d write a followup post to explore what it means make an “excellent game,” and hopefully arrive at some practical applications that will help us in our everyday development.

 The other of the two common responses was:

But mediocre games make millions all the time!”

So here’s an opening thought question: why is it that we have no qualms about labeling a game “mediocre,”  but the concept of excellence is relegated to the realm of philosophy?

If a game can be objectively bad, can a game also be objectively excellent? Are there no concrete goals and standards we can make for ourselves in pursuit of excellence – or do we really just throw our hands up in the air and say “Just do your best and love what you do!” and then hope other people enjoy what we make?

Before I go any further (and lose anyone who was hoping for a practical discussion here,) let me be clear that pretty much everything I say is through the lens of games as a business. Forest and I have quit our day jobs in hopes of making a living by doing what we love. So, I’m interested in “excellence” in terms of academic thought – but also in practical business terms: what makes a game highly valuable to a paying audience? When I argued that pursuing excellence should be priority #1, it’s because I think this is what makes the most business sense – and is incidentally more fulfilling.

Maybe we just need to be more specific.

So what is an Excellent game? 

In terms of games, I would suggest that Excellence is a transaction that happens between a game and the player.

To put it another way, a game is – by definition –  meant to be played, and a game proves itself to be excellent when an audience finds it to be so through play. You may disagree, but perhaps that baseline definition can get us out of the realm of philosophy a bit, and back towards practical working discussion.

Stephen Totilo recently argued (repeating a definition coined by Sid Meier) that what sets apart “good games” from “bad games” is that the good ones have interesting choices. He added after talking with Dylan Cuthbert and others that good games also have “Merihari,” – a Japanese word that’s roughly translated as a combination of rhythm, balance, and distribution. However, others are quick to point out that games such as Guitar Hero involve little meaningful choice, and would probably be appealing even without the little choice that is there.

I think Stephen is onto something here, but perhaps his definition is too narrow. “Meaningful choice” is a trait that we have come to value highly – but it’s not an essential trait, and it’s certainly not the only trait that matters.

The curious thing to me, is that perhaps there are no essential traits for games that are considered excellent.

Do all excellent games need to have interesting choice?

No – as pointed out already, games such as Guitar Hero are highly engaging without it. Bit.Trip Runner is another great example.

Accessibility, perhaps?

No: Minecraft is certainly not accessible, and people surely consider it to be excellent.

Great Graphics (whatever that means)?

Certainly not.


I don’t think so, although this is a very powerful trait.

For any given trait, someone could point out a game that doesn’t have that trait, but that’s considered excellent by many people.

So what do excellent, highly valued games all have in common?

Well, without exception, they always find something to be really good at.

And usually, these quality traits are both easy to identify, and surprisingly common.

For example, Minecraft is really good at player choice and exploration – better than most other games. It provides an infinite world that’s infinitely modifiable.

Half-Life is arguably very good at pacing, optimal challenge, technical competence, storytelling, and a lot of other things – some objective, some subjective. Some would say it’s “more than the sum of its parts,” and that all these “great” traits add up to excellence.

The point is – nobody ever considers a game excellent if it excels at nothing. And if a game really excels at something, this  can often (as is the case with Minecraft) make up for a multitude of sub-par traits, provided these lacking elements don’t get in the way of the player’s experience too much.

So what’s my point with all of this? This is, after all, meant to be a practical article.


Pick something your game is going to do really well. Don’t settle for “pretty good” in this area, shoot for best in class. Don’t try to be best in class at something that your team can’t pull off – but don’t be fooled into thinking that you can’t be best in class at anything. 


Think about some of the other quality traits that you and others value in games, and perhaps pick some of these as secondary goals – or at least measure your game’s execution on these traits as a helpful experiment. Maybe you’ll identify an area that’s seriously lacking that you hadn’t really considered, or perhaps you’ll identify a trait that it’s actually pretty darn good at. Ask yourself what would take this particular trait to the next level and make your game worth talking about!


For Pete’s sake, don’t make a game that you hope others are going to like. You’ve got to either know exactly what you like to play and make that, or you’ve got to be an expert at knowing what others want through years of experience and research. Developers have been successful with both methods, but one of them is intuitive and fulfilling, the other is difficult, expensive, and often unfulfilling.

Common Traits of Excellence

To wrap things up – here are a few traits that I think we as players and developers have come to recognize and value in games, in no particular order. Don’t read this as a list of things to put in your game – read it as a list of potential traits that may or may not be good goals for you to pursue. Some of these traits will make your game appealing to wider audiences. Some will make it more appealing to specific niche audiences. Some will make your game more interesting to talk about to journalists, and some will make it easier to monetize. Some will be more helpful on mobile platforms – others would feel really out of place there. Make no mistake: there is an an intersection of art and business here!

  1. Accessibility – the ability for a player to play your game without much instruction or confusion.
  2. Technical achievement  – can your game make people ask: “how did they do that?”
  3. Resonance in aesthetics – Can your game relate to your audience in a way that brings back memories of their childhood or their everyday life? Or is it made up of abstract elements that mean nothing to them at the outset?
  4. Resonance in gameplay  – Do the mechanics and objects of your game behave in a way that people will recognize? (For instance, compare Angry Birds’ slingshot to that of the ramp mechanism in Trucks & Skulls. Which resonates better with you?)
  5. Pacing – are the elements of your game introduced properly? Is there always something new happening?
  6. Intensity management – does your game have highs and lows, managed in ways that have proven to be effective?
  7. Fun  – A big topic, admittedly. But when you play your game, are you “having fun” with it?
  8. Social connectedness – For instance, does your game have a chatroom, or level sharing features?
  9. Competitiveness – does your game measure the player’s skill against other players?
  10. Addictiveness – again very subjective – but also measurable. How long to people play it on average, and how often do they come back?
  11. Visual appeal  – do you like the way it looks? Or do you find yourself thinking “well, at least it has good gameplay…”
  12. Humor
  13. Optimal challenge  – are people completing it? Do you get bored while you play because it’s too easy?
  14. Frustration. I added this after playing Spelunky. I think games can taunt a player with their difficulty, and turn this into a desirable trait, provided the mechanics are consistent and learnable.
  15. Uniqueness – This can be big in terms of PR and immediate appeal. Does your game give people an experience they’ve never had before?
  16. Variety of visuals
  17. Variety of player actions
  18. Expressiveness –  does the game allow the player to express herself in some way?
  19. Creative Gameplay – does the game allow a variety of solutions to the problems it presents?
  20. Longevity – how much time can one reasonably spend in your game without getting bored?
  21. Simplicity – for example: can it be played with one thumb if it’s a mobile game?
  22. Mastery – can one “master” your game if she is skilled enough and do measurably better than a beginner?
  23. “Storytelling”
  24. Randomness  – this can be a strength if used properly, and can affect longevity, challenge, etc.
  25. Emergence – do the elements of your game combine in unexpected or unpredictable ways?
  26. Fairness – does your game ever make the player fail despite the player’s perfect execution? (this usually results in a “bad” type of frustration.)
  27. “Tightness” – see Daniel Cook’s article on the subject.
  28. Emotion – does your game have characters or elements that humans will relate to in an emotional way?
  29. Interesting choices – is the player asked to make decisions, where the “right” choice isn’t always the same one?
  30. Use of Rhythm
  31. Use of Reflexes
  32. Use of puzzle-solving – is the player asked to think about how to solve a problem?
  33. Use of Memorization
  34. “Polish” – this is a fuzzy one. Experience helps.
  35. <enter your own here!>

I hope this was helpful. The goal is to help us look at our games through more objective lenses. Of course, “Excellence,” like beauty, is ultimately in the eye of the beholder and will defy explicit definition. But I think it’s critical to our success that if we want to make games that are worth talking about, worth buying, and worth remembering and playing 10 years from now, we need to identify the quality traits that each of our games will excel at.

So – what is your game excellent at?

How to succeed on Kickstarter

Original Author: Tyler York

Tim Schaffer’s DoubleFine campaign and many others, countless aspiring game developers have taken to Kickstarter to raise funds for their game. Yet many of these game developers are seeing their projects fail to raise funding, and without serious celebrity status it’s hard to generate significant interest about your project. I’m a member of the Stanford Graduate School of Business mailing list, and last week there was a question about how to effectively use Kickstarter as a game studio. What resulted was a treasure trove of valuable advice, which I wanted to summarize for everyone below.


What are your chances?

The first key mistake that many Kickstarter campaigns make is that they set their goals too high. Take a look at the Kickstarter Zeitgeist, slide 3: the median money raised is $19,058. A project in the $10 – $24k realm is much more likely to be funded than one in a higher fundraising bracket, so you need to consider that when pricing your project.

You can also see that on average, campaigns were oversubscribed by over 2.5X. This is because people will often only put their money in what looks like a “sure thing”, so they are much more likely to back projects that have a significant portion of their funding already closed, or are oversubscribed already. The best way to capitalize on this is to keep your funding target low, to the bare minimum of what you need, and then it’ll be more likely to get funded (and then hopefully oversubscribed).


Creating your project & video

Clear, concise explanation

When you’re creating your project and video, always strive to make it as concise as possible. So many Kickstarter projects are large essays accompanied by 10 minute long videos, and many netizens don’t have that attention span. Instead, make your project description and video clear and concise, preferably less than 5 minutes for the video and less than 2 pages for the project description. It also helps to put a TL;DR summary at the top of the project description.

Show over tell

Rather than having a clip of you telling people how great your game is going to look, show them a clip from what you have so far. The same applies for the description: make liberal use of graphics to show people what the game will be like and what they will be buying.

Compelling stretch goals

Stretch goals are goals that you create for the project if it passes significant funding milestones beyond its fundraising target (such as $30k raised for a $20k project). Tying in with the first paragraph, you should set your fundraising target at your bare-minimum budget and then entice Kickstarters with stretch goals. Make the stretch goals cool, unique, and a bit crazy: this is where you can really make your product stand out and get users excited long after you’ve passed your fundraising target.

Offer proof that you can really pull this off

Talk about your experience building XYZ types of games in your video. Make sure the audience knows that you can pull this off. That said, you want the audience to believe in you based on your past accomplishments, but bragging or being long winded about it will turn them off.

Be confident

Nothing smacks more of an amateur project video than a lot of “ums” and nervous looks away from the camera. You, and anyone in the video, need to be confident spokespersons for your project and your company. Echoing the point directly above, your confidence gives the audience more reason to believe that you can actually deliver on your promises.

Compare your project to others in your price range

When comparing your project, it’s worth comparing what you’re offering to other projects in a similar price and fundraising target range. Just don’t do it in a disparaging light, instead concentrate on what you’re doing that’s cool and unique. More importantly, don’t make the mistake of comparing your project to significantly more ambitious or expensive projects, Kickstarter or otherwise. Saying that your game will be “like Starcraft, but with a twist and on 1/100th of the budget” will not get people excited about your prospects.


Pricing your rewards

This is one of the most contentious issues with Kickstarter campaigns, particularly with games. But it doesn’t need to be complicated; in fact, simple, straightforward rewards actually perform the best for getting people to donate. Stick to the tried-and-true things that people like, such as t-shirts (low tier), unique in-game items (medium tier), and custom in-game NPC characters (high tier). Around those basics, try to build in a couple of rewards that are unique and compelling to your game. And for the godly top tier investments ($1,000 or more), try to make them feel very personal, such as a trip to the office and lunch with the team.

From the Kickstarter Zeitgeist slideshow, we can see that the average donation was $31. Kickstarters live and die by the $20-$80 reward tiers, and you should expect to do the same. To get ideas, look at other projects in your category: do you offer comparable rewards at competitive prices? Once you’ve mapped out what you want your prizes to be, you should make sure that your reward tiers build off of each other. Each reward tier should contain in the previous reward tier, with few exceptions. This entices people to donate more and also makes sure that people don’t have to choose between two donation tiers to get the rewards they want.

Lastly, you should read about Star Command’s experience funding their game on Kickstarter. They made a lot of prizes material goods such as t-shirts, and made those prizes only slightly more expensive than the shirt itself. What ended up happening was they spent a significant amount of their funding just paying out swag. The lessons to learn here are that you should aim to offer compelling virtual goods first, and save material goods for the higher tiers. It also means that you should factor the price of every reward tier into the final “cost” of the reward.


Keeping your audience engaged

Even well-set-up Kickstarter campaigns live and die by marketing. When you’re planning out your Kickstarter project, don’t save marketing planning for later, after the project has been put up. Often times, a big initial project launch burst can create the momentum you need to show prospective donors that your campaign is likely to succeed. Every project launch should be undertaken with a full marketing plan in place for launch day. This should include setting up press about the project (with an embargo for your project launch day), setting up a blog and writing the first post, and setting up social media profiles. In fact, the best campaigns utilize social media and player communities to build buzz about their game from day 1. In particular, submitting your project to relevant sub-Reddits and other content sites can help you get a lot of exposure for your project quickly.

Once you launch the campaign, follow Twitter religiously and make sure you personally follow and thank everyone that Tweets about your project. Be sure to employ similar tactics on social networks, forums, and Reddit. You want to be very engaged and grateful to donors, especially at this early stage. Doing so, you will also build an initial audience that you can use to power your marketing campaign for the rest of the project (even after funding closes!).

With this audience in hand, you want to keep them engaged as much as possible. Post frequent updates to the Kickstarter page, sharing your excitement with your following and giving them sneak peeks at what you’re building. These updates also make great meat for social media and give your audience the impression that you are working hard on your project. You can also opt to release more videos via Youtube of the product’s progress, or even just a thank you video from your team.


Unfair Advantages

While not necessary, there are some things that can provide unfair advantages to your Kickstarter project that you should definitely look into. A big part of why DoubleFine’s Kickstarter project did so well is because it was backed by the star power of Tim Schafer. While it’s not likely that you can get a Tim Schafer-caliber figure to support your project, there’s still something to be said for personally recruiting internet-famous people one-on-one to publicly support your project before you launch. An endorsement from someone dear to the specific player segment you’re targeting would be ideal (ie get Sid Meier to endorse a strategy game, not a racing game). This tactic is a long shot, but it’s the kind of thing that if successful can be a huge boon to your project.

Another unfair advantage is the intellectual property, or IP, associated with your game. While IP is tricky (this is a good slide deck explaining the negotiating process), it is not nearly as difficult to obtain as it seems at first glance. If you have a proven track record in the game industry, you can convince larger brands to partner with you, and if you don’t, you can still convince small or indie brands that don’t have plans to move into the space you’re addressing. When talking to these companies, be sure to lean on the Kickstarter magic and emphasize how your campaign is going to bring them a lot of press and exposure.



In conclusion, creating a successful Kickstarter campaign isn’t hard, but simply putting a project on Kickstarter doesn’t guarantee success either. You need to have a well-produced video, a concise description, compelling prizes, and a solid marketing plan that starts on launch day. And maybe even an unfair advantage or two. Just follow the tips in this guide and you’ll stand out from the countless dud projects that clutter Kickstarter. But remember, building and running a Kickstarter campaign is a full time job, as your project should be for the months after you successfully fundraise. Treat it as such, and you’ll be well on your way to having a successful campaign. Good luck!



A big thank you to everyone who contributed their knowledge to the Stanford GSB mailing list thread: Thomas Bidaux, and others. Your knowledge and advice made this post possible.

How not to go insane while working from home

Original Author: Kyle-Kulyk

Vex Blocks! 🙂

For the love of god, put on some clothes

You wouldn’t walk into your office dressed in sweats and a t-shirt and even if this was acceptable, you probably still shouldn’t do it. There’s been a few days when I’ve rolled out of bed and stumbled into my office, but I’m never as productive as I am when awake, showered, had a good breakfast and dressed for work.  I’m not talking about dressing up, I’m mainly talking about things like…putting on pants.  It may sound a bit clichéd but feeling good about yourself makes you more productive and until I’ve cleaned myself up and dressed first thing in the morning I just don’t feel like I’m ready somehow. If you’re content to work in your tighty whities all day with the windows open and your retired neighbours aghast, maybe just try cleaning up one day, spraying on some Axe body spray and getting dressed to see how you feel in comparison.

Regular hours

Set yourself regular work hours. The nice thing about working from home is you can usually be flexible with your working hours but that doesn’t mean you shouldn’t still have set hours. I found that having a schedule was valuable for maintaining my sanity and improving my productivity. For me, it’s like a switch flips on in my head. “Time for business!” If for some reason I find myself off my schedule it’s hard for me to get into my work groove when I do sit down at my desk. I’m sure there’s some behavioural scientist somewhere that can back me up on this one, but I’ve really found keeping a regular, scheduled work day improves the amount I can accomplish compared to days when I just “wing it.”

It’s also nice to have that end time to look forward to as well, and having a family it’s good to have that moment when “Daddy is available for play now!” You’re not a machine and you can’t work all the time. There needs to be a point where you can stop and focus on yourself, your friends and your family. Also, take breaks and take a scheduled lunch. I’m terrible when it comes to this and by the time my day is done my brain feels fuzzy. Taking a break keeps me from burning out, stressing out and helps me gain my bearings.

Office Rules

If you’re working from home, it’s also a good idea that you lay down some ground rules for the other occupants of your home. It’s hard to get anything done when you’re being interrupted by pets, parents, spouse, children, etc. My wife is currently at home on maternity leave and it’s nice to be available if she needs assistance with the new baby or our 2 year old son but I need time to do my work. You wouldn’t be able to work a regular office job with a toddler on your lap, yelling for Elmo videos so it’s understandable that there needs to be generally uninterrupted work time. So far having my family at home has worked out pretty well, with even our headstrong 2 year old grasping the concept that when Daddy’s office door is closed he’s working and he’ll be able to play later. My son even says “Bye!” to me now and waves when I’m going into the office to start my work day.

Separate work environment and minimize distractions

It’s also useful to have a designated work space. A “zone of work” that you can enter and exit. For myself, I’m lucky enough to have an office in my home but even if you don’t it’s not a bad idea to create a separate space that’s specifically setup for work. Even though it should go without saying, make an effort to decrease distractions. If you’re a PC gamer and you don’t have the willpower to not fire WOW up every couple of hours then perhaps you need a work machine that doesn’t have any games installed, or create a unique login that doesn’t have access to programs you may find distracting. I find it useful for my PC to be work only while receiving my gaming fix on the consoles setup in our den. It’s helpful for me to have that separation.

Don’t limit human interactions

After working in a busy office, this is something that I didn’t think would be an issue but it was. I found the transition from always being in communication with others to working primarily by myself to be a bit jarring. By the end of the work week I found I craved human interaction; that I’d even go a little squirrely without it. As I mentioned in previous blogs, regularly scheduled meetings with my team helps to break up the monotony of this lone programmer’s existence while keeping the team on task. It can never hurt to keep up communications with your team, even going so far as to have a voice chat session running in the background while working occasionally. This may hinder productivity in the short term, but in the long run I find it helps keep me from experiencing cabin fever. A change of venue from time to time couldn’t hurt either. If you can, take a laptop down to your local cafe and get some work done. Again, in the long run this will be beneficial to your working well being. At least it was for me.

These methods have all helped me over the past year and a half I’ve been working from home. Hopefully you find some of these useful as well. Cheers!

Unity, Replayed

Original Author: Eddie Cameron

Replaying actions in a game is a surprisingly common feature. There are match replays of course, but recorded actions are also used in cutscenes, ‘ghost’ players in racing games, and a variety of puzzles, like those for Clank in Ratchet & Clank:A Crack in Time. Many engines support at least a limited ability to record action in-game, as opposed to recording a movie, the demo command in Source for example. Unity, however, does not.

One of my current projects is heavily reliant on character replays. I’ve written several replay methods in past projects, and knew how much work it ended up being. I never want to have to go through that again, so decided to roll my own, generic, adaptable record/replay system for Unity. It went…OK…

(For anyone interested, but not enough to read about it, the script is on Github)

Past Experiences

I think the first time I had to record something in Unity was for the beta of Robert Yang for a gamejam at Babycastles. It’s an arcade style game with novel controls, and needed some sort of attract mode/tutorial. At first I tried recording a movie with Fraps or something. This never worked, to make the quality high enough meant the frame rate took too much of a hit, not to mention that tacking a 40Mb video on to a 3Mb webplayer game was kinda overkill. In the end, I just decided to take down the positions of the two players each frame, and when replaying just snap them to the recorded positions. Simple, and as long as you didn’t look too closely or have a really bad/good framerate, pretty robust. It was good enough for a gamejam, anyway.

Another game that Robert and I worked on for a while was Muckraker, about investigative journalism. This involved ‘filming’ certain events, and replaying (even editing) them, so some sort of in-game recording system was needed. I quickly rigged up a system where you would drop a ‘Recordable’ script on each gameobject you wanted to record. When the player started filming, a master recorder would take down the position and rotation of each Recordable object within the cameras view. Our recordings were all short, and we never got too far into production, so this system worked well enough. However it was unwieldy, completely frame-rate reliant, and inflexible. I couldn’t have two different recordings at once, and couldn’t easily take down any other events.

All rather dire. The next time, I vowed to do things right.


More recently, I started working on No Architect, a cooperative FPS platformer/short story/dull-party-adventure. I wanted the coop part to be available offline too, but it still needed at least some of the quality of live players. Recorded playthroughs could also be easily shared, so I could still have people playing with each other, without having to rely on enough players to keep live multiplayer going.

I decided to only record inputs, and deal with the expected inaccuracies at runtime. Mostly because syncing the position and rotation of an object every frame takes up a lot of room, precious on web based games. However it also gives me the flexibility to mess with the playback. If, say, a wall has appeared, a recorded agent will get stuck against it, rather than clip through.

I set up a basic script (InputVCR.cs, for those of you playing along at home) where the user chooses which named buttons/axes to record from those already set up in Unity’s input manager. Each frame, the VCR will record the status of these inputs, along with the position of the mouse. (As an aside, I set up my own recording format, but in hindsight should have just used JSON). Now, you can give this recording to any InputVCR, and it will spit out the same inputs in the same frames. Let’s painfully stretch the VCR metaphor. Say user Input is the signal from an aerial. You can plug this input into the VCR so gameobjects(TVs) can get their inputs from it rather than the direct user feed. A Gameobject now doesn’t have to know whether it’s getting live input or not, and a VCR can record, pause/rewind, or even swap recordings(VHS tapes) with other VCRs, all without having to care about what uses its output.

Pretty simple, and except for replacing static calls to Input ( like Input.GetMouseButtonDown() ) with a reference to an instance to an InputVCR, you don’t have to change existing scripts.

Of course, this didn’t work out so smoothly. Over my recordings of around 2 minutes, the characters would slowly drift off course as framerate differences started to add up.  And in a game about making long jumps onto small platforms, there’s not a whole lot of wiggle room. I added timecodes each frame, so that playback could slow/speed up if the recording frame times didn’t match the playback times. This helped somewhat, but if there was a spike during recording or playback, the character would still freak out. For short recordings, or those less reliant on physics calculations, this might be enough, but I needed some sort of position syncing.

I added the ability to record position/rotation information with any frame (as well as arbitrary information). For many uses, this would be all you need. Sync the position every second or so, and interpolate back to the desired location if the playback goes off kilter. Unfortunately, I was playing recordings in a changing environment, and still needed the real time character to override the recording if, say, a platform disappeared from under their feet. There’s also a bug in Mono that makes StringReader.ReadLine() impossibly slow, so parsing all that extra information was really unpleasant (I fixed it eventually, but at first thought it was just the large file size). I got around this by recording what platform (if any) the recording was meant to be on, and syncing the location each time the playback landed on the ‘correct’ platform. If a platform was missing during playback , the controller wouldn’t sync and would be allowed to fall, as expected. There are still some inconsistencies during framerate spikes, but at least they won’t kill the character.


Recording stuff is a pain! And, unfortunately, there is no all-knowing solution for every game. Syncing position/rotation of an object in guaranteed to be accurate, but the playback is stuck on rails and a changing world won’t affect it. Recording inputs allows for interactive playback, but in many cases won’t be accurate over time.

I found the best solution is to start with a recording of the input only, and add syncing until the playback is accurate enough for you. If there are events that rely on the playback, you can record them separately from the input to ensure they still happen. InputVCR still does the heavy lifting when dealing with recordings, but I’ve had to accept that you’ll always need a decent amount of human input to get the results you need.

Check out the source Asset Store(older version). If you use it or make any changes, I’d love to hear what you did!

Note: Reposted at my own site, grapefruitgames.com

Games are Art: an elephant in the room

Original Author: Julien Delavennat

Yup, that topic again n_n

I’m guessing posts with the same point as this one have been written at least a million times, but who knows, maybe you’ll find something interesting in this one, so here we go.

This article says there is a particular bond between video games and music, unlike cinema. Something about playing and interpreting or something.


The equivalent of games and music isn’t cinema, it’s theater. Actors play/interpret plays in theater, like musicians play music, and players play games. And then I realized, people seem to be getting something terribly wrong. They seem to think that the default thing to do with music is to listen to it, and that the default thing to do with games is to play them.

I don’t think so. You know, three hundred years ago, we didn’t have technology able to record stuff, only live performance. People didn’t just listen to the music, they sung and played it themselves much more often than nowadays.

Take a look at this table :

See what I mean ?

So, if playing a game isn’t the “default” thing to do the same way playing music isn’t the “default” thing to do for music, then video games become as much art as cinema or music. As much as special effects aren’t the core of a movie, special effects aren’t the core of Machinima or Frag videos. As much as theater is unedited, speed runs are “unedited”, since we don’t really add effects, we just show raw game footage.

The core is the concept, the story, the idea, the identity of the game / movie / song. Not the interpretation of it. The core is what you can do within the artwork, the play space, not what you actually do.

In that sense, the possibilities of games are equivalent to the possibilities of movies and songs.

Two examples of this are song remixes and director’s cut versions of movies. You’ll say “it’s the same song/movie, just re-mixed/re-edited”.

You just change the lighting and move the furniture around, and the room feels different, even though it’s the same. The only difference between live and recorded versions, is that a recorded version is a photograph of that room, whereas live has the players changing the lighting and moving the furniture around themselves continuously. Games are the same: if recorded, the furniture is in the same place every time, if played, the player moves the furniture and changes the lighting herself continuously.

Is Tetris art ? Is the set of what you can do within Tetris art ? Well, I think so yes, even though a player will have a hard time putting words on what happened in her last playthrough, she still got a kick out of it: all the actions, reactions, results and ramifications of what happened, however small and dirt-low the details go. To consider Tetris art, you have to consider its possibility space which enables players to experience all that stuff.

Arguably, there aren’t any video game master pieces, no academic recognition even for the best games, whereas theater, cinema and music have transcending and universal classics. It’s funny because arguably, some people get more of a kick out of playing some games than watching movies.

Do regular art critics compare game playthroughs to Shakespeare scripts ? What should be compared to a play script is the possibility/meaning space of a game, what they can be, and not just a playthrough experience. To make sense, your own game playthroughs should be compared to how pleasing it is to play a piece of music or act a role.

Maybe to make “better” games, we should make them pleasing to watch when played ? I know frag videos can be fairly intense, because the rules of physics and stuff aren’t made up by a narrator, so you know if a player manages to do something impressive, it’s impressive for real. The same way it’s impressive to hear a complex musical piece being played, or a breath-taking action scene being acted: did you know that for Mission Impossible 3: Ghost Protocol, Tom Cruise really DID climb the tallest building in the world in Dubai himself ? No kidding.

The same way a live performance relies on a skilled actor/musician playing a piece written by a skilled writer, a game playthrough can need a skilled player playing a game made by skilled developers :D.

With this post, I don’t mean to address the whole issue in one go. I just want to point out the inconsistency in people’s reasoning that I showed in the table, and offer my perspective.

I’m satisfied with this answer to the “Games are Art” debate: it’s the reason I’ve always supported the idea that video games are art. You know this because you’ve developed games for some time now, your work brings joy and happiness to people in a similar way that music or film does, so who cares ?

Feedback very welcome :]

Call for Industry Speakers to Address AltDev Student Summit

Original Author: Luke Dicken

The AltDev Student Summit will be held November 10th and 11th, with the aim of bringing industry veterans together to explain to students the reality of life making games. Individually, many of us already do outreach to local education programs to provide these kinds of insights, so the Student Summit aims to centralise this effort by providing an online forum for this engagement – industry experts gain a much broader reach for their presentations, whilst students benefit from the experience of a much wider pool of potential speakers. As for all AltDev events, the intent is to hold the entire event online and record the sessions and share them with the community afterwards to further enhance the reach of the speakers.

For the Student Summit 2012 we intend to host presentations centred around two core themes:

1. All the Things You’ll Never be Taught – In this track, we hope to see professionals sharing their insights into the aspects of the industry that aren’t taught by game development programs, whether this be bits that aren’t taught, or bits that are taught in a way that isn’t reflective of true industry practice or some other angle on the topic. We want this track to help better prepare for life in the industry.

2. A Day in the Life of… – This is somewhat self-explanatory. We’d like to be able to give students an insight into the day to day routine of various different positions within industry. What does a Technical Artist or a Tools Programmer do all day? Obviously one talk won’t necessarily be representative of a single role at all companies, but we hope it will give students a flavour of what to expect.

If you have an idea for a presentation that doesn’t fit within the two themes, we’d still love to hear about it, so we have also included an “other” category for you to propose your presentation in.

Key Dates

Proposal Deadline – 19th August

Notification of Acceptance – 10th September

Event – 10th November

To submit a proposal for the event, please complete this webform, including your name and contact information, a summary of your past speaking history (if any) and a description of your proposal.

Finally, we intend to invite students to submit their current projects as part of a third theme, centred around the students doing a live presentation and demo of the project, followed by industry experts providing feedback and critique, in a format not massively dissimilar to the “Dragons Den” TV show. If you would like to be a part of this, please complete this form.

Questions can be sent to submissions@altdevconf.com