Geoffrey Zatkin, president and COO of Electronic Entertainment Design and Research (EEDAR), gave an interesting talk about what strategic questions developers should ask themselves before diving into game development. While I don’t believe that this is 100% relevant to the Flash games market, it did raise some interesting questions for me on how smaller indie devs can look for market data in planning their games. It may not be to this level, but it’s a great framework to think about what questions you could ask! I’d love to hear anyone who has thoughts on this.

A Strategic Approach to Game Design

Zatkin defines strategic game design as focusing on the WHAT and the WHY, all in advance of the tactical execution side where you focus on HOW you implement and build the game. What and why are all about the big picture and why you’re making the game in the first place, and is strongly based on the purpose and atmosphere of the game and planning for any anticipated problems. He makes the argument that many teams during production lose sight of the strategic vision, reverting to tactical decision making.

He started off by asking about your planned goals as a developer, such as whether or not you’re building a commercial or independent game. Are you hired to do it or trying to make $$? If your goal is to ship a game, then your goal is really making a game that will sell well. You can take that one step further and ask where you’re planning to have it sell, because that has implications that can incur cost afterward. If you’re launching in Asia, gamers must be able to play with one hand so that they can drink/smoke with the other. In Germany, you can’t build a game with red blood but you can have green blood. Overall, there are a lot of considerations to explore early because it’s expensive to adjust this later.

“The most common reason why games suck is lack of resources or money and then re-working and re-engineering it,” Zatkin said to the crowd. To him, it’s about planning the core of the game and setting a clear vision that can be communicated to everyone in charge of building it. Decide what you’re making early on and disseminate it to your team so that they are surprised as little as possible. “Write it down, use lots of adjectives, make a lot of references to other games,” he urged.

Gathering Data

  • Sales and sales projections
  • Sales from comparable games
  • Check your hardware and see if gamers can actually play it
  • Who are your competitors? What’s their launch schedule?
  • Look at your feature set

Zatkin presented a bunch of interesting data/graphs as an example. I snapped a few photos from his presentation, please don’t mind people’s hair/shoulders getting in the way.

PAX 2009

This graph indicates that the first three months of a console game represents the bulk of sales for the game title. There’s a little bump comes from the holiday wave. The big problem is that games don’t have a secondary distribution channel (e.g., movies can go on dvd, tv, airplanes) so for big-budget and even mid-budget games, you should be careful.

PAX 2009

This is a boxplot graph of racing genre games — light blue is 25%, dark blue is mid 50%, bottom blue is bottom 25%. The average revenue price is misleading, since the high performance games drag the average up to 110k but the median is 65k. In general, 25% sold 18k units or less and devs get 20–30% of box sale prices.

PAX 2009

This was Zatkin’s example of a competitive matrix with a listing of features. Creating these can be helpful for competitive information and to understand what your audience expects. Also, market size can defer dramatically based off of a couple big factors (e.g., teen shooters and adult shooters).

Zatkin makes the point that developers need to be thinking about data like this. While everyone can make a game, making a game that does well requires forethought about how to get the game out and sell and market it. From the game design standpoint, he says that you need a strong leader in the group that pushes a clear vision along.

Pax 2009

In the console world, Zatkin’s data indicates that game quality is a strong indicator of game sales. Realistically, since all games are compared relative to other games, not every game is going to get a 8/10 or higher. Looking at groupings of game reviews and sales. getting a 90+ game sells three times on average. Looking at 5,267 games across consoles. game reviewers have a strong correlation to the gaming audience. In short, quality really does make a difference.

Making a Game

  • Fun — It’s important not to lose sight of making a game fun. Fun is a nebulous concept and contextual. However, while it’s hard to make a game fun there are some very concrete things that will keep a game from being fun. Keep those not-fun elements out of control so that the fun elements can shine through.
  • Priorities — No team has ever gotten everything they want into a game, you have to prioritize. Discipline in making a list of what you want pays off because it helps you prioritize and place new features onto the list and show what will drop off. This helps make sure you have time to focus on finding the “fun” level.
  • Feedback — start getting feedback early on m1 or m2, especially if you’re an indie developer. Getting feedback early is important to make sure you’re building the right thing. Consumers vote with their dollars.
  • Marketing — integrate with your promotional group. As a game developer, find out early what your marketing and promotion group needs and when. Is it a demo for GDC and a separate demo for PAX? Knowing these things early helps you plan for knowing when the engine is in a good enough state. This also avoids the classic developer and marketing clash. While many developer teams think that if they have a great team, the game will sell by itself. However, data seems to indicate otherwise.

This graph was interesting — these compare game sales between games which release: demo & trailer, demo only, trailer only, no demo or trailer. The vast irony is that some games just aren’t very fun once you actually play them.

This is a re-post of an article I wrote last week on MochiLand. Original post linked here.