In Defence of Freemium

Posted on October 21, 2011 by Matt

Note: this was originally intended to be a comment on Adam Saltsman’s “Contrivance and Extortion II” post on Gamasutra, but it got way too long, so I decided to post it here instead

Hey Adam, I’m glad that you’re bringing all these issues up and starting this discussion, and I think (maybe) I can convince you of the benefits of freemium games, or at least present an alternative viewpoint. I should also point out that I’ve never made a freemium game, and that I usually make the kind of games I imagine you’d enjoy.

To start off, I think we need to talk about perspective.

You (just like me, and a lot of other people here), approach games as a game designer first. This has a bunch of interesting side-effects. The first is that we have “game-designer-itis”, where we play a lot of games, but usually only play them long enough to grok what they’re about and to experience whatever it is that makes them unique. This is why people like us love games like Braid where there’s very little repetition. Every single level introduces a new element, a new twist. There’s no fluff, no filler.

On the other hand, we never finish most blockbuster games for the same reason. They just get too repetitive. I’ve never finished Halo, Gears of War, GTA, etc. It’s not because I couldn’t finish them, in fact, it’s just the opposite: I knew I could finish them, so I didn’t see the point; I had already explored all of the systems that the game had to offer.

Now let’s be clear, there’s absolutely nothing wrong with the way we approach games, but I don’t think it’s fair to assume all gamers are the same as us. A lot of people play games purely as a form of entertainment, and so they want as much of it as they can. They’re not nearly as concerned about whether each moment they’re experiencing is unique or not, they just play games as a way to escape normal life, a way to kill time, a way to be someone they aren’t.

Ok, so how does this all tie in with freemium games? There was a fantastic presentation at GDC 2011 called “The Fantasy of Labor”. If you have access to the GDC Vault, I highly recommend you check it out. The ideas I’m writing about here are rooted in the concepts that were presented there.

The core idea of the talk is that all games require three things from a player, in varying amounts depending on the game: skill, luck, and labor. A game like Street Fighter requires mostly skill, a game like roulette requires mostly luck, Farmville requires mostly labor, etc.

The common attitude in both the game development and “hardcore gamer” communities is heavily biased towards skill-based games. These games are appealing to the majority of the traditional gaming community, but they have flaws. The talk goes into detail into quite a few issues, but the most important take-away is this: *a lot of players do not want to play games that require skill*.

Now let’s move from skill to labour. There are a huge number of players (a large portion of the “casual” demographic) who *enjoy* games that are labour based, and dislike games that are skill based. They want a game where they know that the longer they work, they will always improve, no matter what.

It took me a long time to come to grips with the fact that some players really don’t want a game with interesting gameplay or systems for them to grok. They just want something where the more time they spend, the more results they’ll get. They aren’t looking to be rescued by some well-meaning game designer, saving the day, saying “no, this is what games really are! Try all these interesting systems, look how intrinsically motivating this game is!”, instead they just want to check boxes on a checklist. They *want* to.

Alright, now for the final piece of the puzzle. In your post you implied that the only reason someone will pay to skip ahead is if their urge to complete the extrinsic checklist overpowers their enjoyment of the intrinsic mechanics of the game. I heard someone summarize the main take-away of your post as this: “If a game lets you pay to skip playing, it’s not fun. Why wouldn’t you want to play?”.

One issue with this argument is that it doesn’t consider all of the other elements that make up a game, especially the aesthetics and mythology. I think we can agree that it’s possible for these to motivate certain players way more than “the desire to experience the mechanics” or “the desire to improve their skill”. Players will sometimes want to advance just so they can experience more of the story or more of the aesthetics, and there’s nothing wrong with that.

Now coming back to the checklist. I think this is probably the main point I want to make: some people actually enjoy filling out the checklist. And really, it’s not just some people, but a large portion of players in the casual gaming space. Even more importantly, they don’t enjoy the kind of games that *you or I* wish they would enjoy. Specifically, they don’t want games that require skill, and they don’t want games with interesting mechanics (unless there’s also a checklist attached).

One more thing: even if you think I’m completely fabricating the existence of this type of player (I can assure you, I’m not), I think we can probably agree that even regular gamers can become this type of player *some of the time*. For example, long after I’d grokked all of the core mechanics of Tiny Tower, I kept playing for weeks because of the desire to see my tower get taller, and I loved every minute of it.

So to wrap up: freemium games are giving players what they want.

 

An afterword: I really want to be clear that I’m not saying “freemium games can do no evil”, because they can, and a lot of them do. I simply want to point out that the core mechanics of these games are not inherently evil, and that they fulfill the needs of certain types of players.

Posted in Game Design | 22 Comments

Luna Soul

Posted on September 17, 2011 by Matt

This iDevBlogADay post is about Luna Soul, the game I made during the game jam at the 360iDev conference last week.

The Conference

I really want to keep this post short, so I won’t go into too many details about 360iDev itself. I could spend more than a few paragraphs just talking about all the things I ate, but instead I’ll  summarize the whole conference: it was great.  I loved learning and being inspired by presentations, I loved eating copious amounts of meat and fried food, and I loved hanging out with “old” friends and meeting new ones that’d I’d previously only known through Twitter.

The Jam

A game jam is usually where a bunch of people get together and make games over a short period of time, and the 360iDev game jam was no different. It started on Tuesday at 8pm and went through the night. There was no defined end time, except that the games had to be done by noon on Wednesday so they could be presented to everyone else. This was a pretty crazy schedule, especially considering that Wednesday was a regular conference day.

The Theme

The theme for the jam was “opposite”, which was announced at noon on Tuesday, giving everyone about 6 hours to come up with a game idea. I had already decided that no matter what the theme was, I wanted to make a “freemium style” game. This isn’t really because I enjoy that kind of game, but more because I wanted to try that genre out so I could learn more about it.

I struggled with combining “opposite” and “freemium” for a while, and actually didn’t come up with an idea until 45 minutes *after* the jam had started. I considering things like magnets and “opposites attract”, but it wasn’t until I thought about actual opposites, like “hot and cold” and “up and down”, that I found my starting point: “night and day”.

The Result

I spent the first 7 hours in the jam room, and the last 5 in my hotel room, where it was quieter, finally finishing at 10am. The result is a game I call “Luna Soul”, a play on luna (moon) and sol (sun). The game features a constant day-night cycle. In daytime, flowers grow, and at night, mushrooms grow. Your job is to harvest both types of plants and combine them as herbal “recipes”, which you then sell. You can use the money from selling plants to buy more complicated recipes.

I developed the game in Flash, because of just how fast it is to develop in, and because I knew I wanted to have a bunch of animations. I used Adobe’s AIR-to-iOS packager, so people could actually play the game on my iPad at the jam. Due to the magic of Flash, you can even play the game right now. This is the *exact state* the game was in at the end of the game jam after 12 hours of work. I haven’t changed anything since then.

The Music

The final thing I wanted to mention is the music. The multi-talented Phil Hassey (creator of Galcon) brought his fiddle to the game jam and offered to create music for anyone that wanted it. There were four games that ended up using his music, including mine. It really helps to signify the exact change between night and day, and more importantly, it adds a lot of character to the game. I’ve included a video of him performing at the jam below.

Wrapping Up

Luna Soul is far from perfect but I’m pretty proud of how far I got with it. I’m not sure if I’m going to do anything else with the game, but I do have a bunch of ideas for how it could be improved.

One last thing: make sure you check out all of the other game jam entries,  there were lots of really impressive games demoed at the jam, so it’s worth browsing that site to see how much stuff was made in a single night. If I had to pick a favourite entry, I think it’d be Vocab Bots by Ray and Vicki Wenderlich. Great idea and great execution.

Thanks for reading this post. As usual, if you have any feedback, you can post it here or send it to @MattRix on Twitter. Cheers!

Posted in Game Design, iDevBlogADay, iOS Development | 6 Comments

Engineering An Update – Part Two

Posted on September 5, 2011 by Matt

Recap

I wrote a post last week about my struggles and dilemmas while creating the new Trainyard Engineer Update. This week I’d like to talk about what I actually did in this update. I’m not going to get too technical, but if you have technical questions about anything I did, I’d love to answer them, just ask in the comments section.

Backend

The backend for this update was probably the biggest area of concern for me. I was seriously considering switching to something like Amazon Web Services, but eventually decided to stick with my current backend (PHP+MySQL on Dreamhost PS). I finally got around to learning a whole lot more about SQL (big thanks to Jim McGinley) and optimized the database with better indexes and smarter queries. I also wrote dozens of new scripts for handling uploaded puzzles, solutions, and other user data.

I rewrote most of the frontend code on the website, creating “AJAX-style” puzzle and solution browsing systems. I added the ability to comment on puzzles, and the ability to open puzzles directly from the site if you’re browsing on an iOS device with Trainyard installed.

The editor

The in-game puzzle editor itself was a huge amount of work, and took a ton of planning to get right. I went through pages and pages of sketches and potential interface designs before I settled on its current look and flow. I’m really happy with how it turned out, but man, it took a lot of effort to get there.

Although creating the puzzle editor itself took a lot of time, I spent even more time creating all the extra stuff to surround it. For example, there’s a screen to enter the puzzle name and description, a screen to let you solve your own puzzles, and even a screen to show you the data you’re about to submit, so you can verify that it’s correct before submitting it.

On top of all that, there are also tons of little subtle features that most people will never see. One small example: if you submit a puzzle that’s identical to a puzzle someone else submitted, it’ll warn you and even allow you to download their puzzle instead.

If you want to see how the editor works and the whole process of creating a puzzle,  just watch the video below:

Browsing

Creating the system for browsing puzzles was also a lot of work. One of the key issues for me was discovery; I needed players to be able to find great puzzles without having to shuffle through thousands of so-so puzzles. The solution I arrived at is now called “featured puzzles”. This is a list of puzzles that I’ve hand-picked, and that I can update online at any time. This ensures that there will always be a stream of fresh, interesting puzzles.

For players that are brave enough to explore all of the user-made puzzles, I made a “worldwide puzzles” section. There are a bunch of different search options there, so for example, you can find puzzles that are new, popular, or unsolved. I also created a Facebook-ish “like” system where players can choose to like a puzzle after they’ve solved it. As of writing this 5 days after release, there have already been over 10000 likes submitted.

The last two areas of puzzles are “my puzzles” and “saved puzzles”. “My puzzles” is a list of puzzles that the user has created, regardless of whether they’ve been submitted or they’re still being created. “Saved puzzles” is a list of all the puzzles that a given user has tried, whether they’re solved or not.

The video below shows me going through all the different puzzle browsing sections so you can see how they work:

Wrenches

If you’re familiar with the normal game in Trainyard, you’ll remember that all puzzles award “stars” when solved. I decided to do the same thing in engineer mode, but with “wrenches” (spanners for you UK people). I let users assign their puzzles an arbitrary wrench count between 1 and 30 when they submit the puzzle. In theory the wrench count represents the difficulty of the puzzle, but in reality it’s not always accurate, which is totally fine. I considered some more accurate systems for determining puzzle difficulty, but it just wasn’t worth the effort, because wrenches really don’t matter for anything anyway.

Goodies

The last major thing I added to the game is the “Goodies” section. Goodies is essentially just a catch-all for all the features I had wanted to add but didn’t have a chance. It’s also very flexible so it’s super easy to add more features to it in the future if needed. Here are the items that are there right now: News, Achievements, Tutorials, Mailing List, Tips & Tricks, Solutions.

Goodies: News

News is a list of Trainyard related news items for users to read. The data comes from an xml file hosted on Amazon S3. Each news item has HTML content that can be shown in a webview, which allows for stuff like embedding YouTube videos.

If I want I can also specify that a news item is an “alert”, and then it will pop up when the user starts the game. I can also do things like targeting news alerts to specific users, for example, to those who have a certain version of the game, or to those for whom this version is an update (rather than the first time they’ve played).

Goodies: Achievements

One of the biggest requests for Trainyard has been Game Center support, so I finally decided to put it in this version. The tough part of integrating it was that Trainyard allows you to have two local users, so I had to figure out how to make that work with Game Center.

What I ended up doing is making it so that the local data is authoritative on achievements. The game will never download achievement progress from Game Center. Instead, if an achievement has more progress locally than in Game Center, it’ll automatically push that progress to the server.

This has the benefit that both of the local users can still earn achievements by themselves independently. It doesn’t matter what has happened in Game Center. It’s almost like Game Center acts like a “high score list” for your achievements, they’re only submitted when they’ve improved.

I also have a really cool technical system for keeping track of the achievements. I won’t go into it here too much, but basically any time something good happens, an “achievement source” gets incremented. You can base multiple achievements on a single achievement source (ex solve 1 puzzle, solve 5 puzzles, solve 10 puzzles). It also has a system for tracking uniqueness, so that if you solve the same puzzle 10 times, it’ll only count as one puzzle in the “solve a puzzle” achievement.

All of this was pretty complicated to create, but now I have an extremely robust and flexible way to do achievements that will work for any kind of game in the future.

Goodies: Compare Stars

It’s not in the actual “Goodies” list, but Compare Stars is an option under Achievements. It’s basically just a Game Center high scores list where you can compare how many stars you’ve earned to how many your friends have earned.

Goodies: Tutorials

A tutorial list has been a highly requested feature for a long time. Normally the tutorials are interspersed throughout the levels, but this makes them a lot easier to browse through.

Goodies: Mailing List

I’ve had a Trainyard mailing list set up for a long time, but it’s always been on an obscure area of the Trainyard site where it was super hard to find. I decided I’d finally make it easier to sign up in this update. I’ve been using MailChimp, and they have a super easy API that was really easy to integrate.

Since the update went live 5 days ago, more than 200 people have signed up for the mailing list. That’s not too shabby considering there were only 300 people in the list a week ago. The way I look at it, that’s 200 people who are likely to buy whatever my next game is. I wish I’d put it in sooner.

Goodies: Tips & Tricks

I really wasn’t sure about this section but I threw it in at the last minute. It works similarly to the news section, but each item just contains a single YouTube video. Each of the videos is a short tutorial on some aspect of the game. You can watch them all in this YouTube playlist if you want.

Goodies: Solutions

Not much to say about this. It’s just a link to http://trainyard.ca/solutions. I’m hoping it’ll cut down on the number of “How do I solve *****?” emails, and if I’m really lucky, it’ll cut down on the number of “Trainyard Solutions” copycat apps as well.

Wrapping Up

Phew. Ok, a golden horse to everyone who made it this far. There were a ton of other smaller features that I didn’t cover in this post, but I think I hit on most of the major ones. Once you consider creating all of these elements and integrating them all cleanly (and mostly buglessly), I think you can probably see why this update took me 3 months to make, hah.

I hope you enjoyed these last two posts. If you have any questions, especially about technical stuff, I’d love to hear it, so just leave a comment down below. As usual you can also reach me on Twitter at @MattRix, cheers!

Posted in App Store, Game Design, iOS Development, Trainyard | 6 Comments

Engineering An Update – Part One

Posted on September 2, 2011 by Matt

I’m finally back doing iDevBlogADay after many months away. This post is the first in a two part series about my struggles and successes while creating the new Trainyard ”Engineer Update”.

A promise

Never promise anything. Seriously. Ok, well at least never promise anything if you’re a game developer, no matter how tempting it is, and no matter how much you think you’re going to be able to deliver it.

So here’s what happened: Back in December I was wrapping up my old job, and I was super excited about finally starting to work for myself as an independent game developer. I was thinking “oh, I’ll get so much work done now that I’m working full-time”.

So I did something silly; I put out a Trainyard update with a video message that was seen by around 80,000 players, and in that video I promised that a massive new Trainyard update with a puzzle editor would be coming in the first couple months of 2011. Whoops.

Dread and fear

January came and for a few weeks I got caught up in a bunch of company-forming stuff, but I eventually started thinking about the Trainyard update. When I began to figure out the logistics of it, it quickly dawned on me just how much work it was going to be. And then I did what most people do when they’re faced with a daunting task: I procrastinated. A lot.

I worked on all kinds of other projects, including a Playbook app, a multiplayer HTML5 Tetris game, and a music generation toy, as well as a ton of game prototypes. The one thing I didn’t do was actually work on the update.

In late March I wrote a post about what I’d been up to for the past four months, where I said I was hard at work on the Trainyard update, although in reality, I hadn’t even started. Time and distractions kept dragging on. In fact, it would take a few more months, until June, when I would finally, actually, for real, start working on the update.

Decisions

What was holding me back? Aside from being overwhelmed, there were a few tough choices that every other new feature hinged on. One of the biggest decisions was whether I was going to rewrite the backend code from scratch on “the cloud”, or just retrofit my current backend code. Among other problems, I also had to decide how to integrate Game Center achievements with my current dual-user system, and how to squeeze Engineer mode into the rest of the game.

Along with the technical decisions, I had to make numerous choices about the design and user experience of the new content. There were over a dozen new screen types to add to the game, each with its own special caveats and issues.

Scope

It’s worth taking a second to talk about the scope of this update: I bit off way more than I should have been chewing. Note my wording: just because you can do it, doesn’t mean you should. If you learn nothing else from this post, you should at least learn to keep your updates small and quick.

I decided that with this update, I’d add all of the little things I felt were missing from the game, including a news feed, mailing list signup form, “tips and tricks” video list, tutorial list, and more. I created a section called “goodies” to hold all of them.

There were a few times when I seriously considered releasing a web-based puzzle editor. It would have been way simpler, and it would have still accomplished my goal of allowing people to make their own puzzles. It also would have literally saved me two months of work. I just couldn’t do it though. I knew it’d be a second-rate solution, and I didn’t want to cut corners.

Buckling down

Ok, so how did I eventually get focused? At the end of May I went on a vacation, and when I returned, I was determined to get down to business. I created a carefully structured schedule that I forced myself to follow every single day. I gave myself rules and stuck to them. I won’t go over my new focusing methods here because I’m planning to write a post about them soon, but they worked like a charm, and I spent the next three months working on Trainyard for over 8 hours every day.

The results

I was originally planning to write all about what’s actually in the update, but this post is already way too long so I’ll save that for part two (coming in the next couple days).

For now, let me just leave you with this: I’m really, really happy with how the update turned out, and I’m proud to have created it… However, there are zero good business reasons for making an update this large. If I’m lucky, it’ll give Trainyard a temporary boost in sales, but even then it’ll quickly drop back down to where it was before. If I knew just how long this update would take to make, there’s no way I would have done it. Let me be even more clear: I hated working on this update; it was a bad idea.

What’s the moral of the story? Never promise anything.

Posted in App Store, iDevBlogADay, iOS Development, Trainyard, Workflow | 28 Comments

Big Runner

Posted on July 14, 2011 by Matt

This past Sunday I attended the first ever Guelph Game Jam. In this post I’ll explain a little bit about the game jam, and then I’ll talk about the game I made (note: it’s a Flash game, so you can actually play it, woot!).

The Guelph Game Jam

This is the second game jam I’ve participated in. The first was TOJam, which I wrote about back in May. I enjoyed TOJam so much that when I heard about another game jam in the area, I just had to go. The jam was organized by Owen Goss, and despite being the first Guelph Game Jam ever, it went really smoothly (great job Owen!).

If you’re not familiar with what a game jam is, it’s basically just when a group of people get together to make games over a short period of time. In the case of the GGJ, it went from 12pm until 7:30pm (with a 30 minute dinner break), so it lasted only 7 hours. This may seem like a really short amount of time, and it was, but everyone was still able to make some cool stuff. The theme of the jam was “Big”, and there were a total of 16 participants. If you want to see the other games, I encourage you to check them out on the GGJ site, there are some really interesting games there.

Ideas and Technologies

I spent some time during the week leading up the jam trying to come up with an idea for a game, but I was having a hard time arriving at a solid idea that could also be executed in only 7 hours. Knowing that the theme was “Big”, I came up with a lot of concepts for physics games, but none of them really stuck out to me.

At this time I also wasn’t 100% sure of what technology/platform I wanted to create the game with. I had just received my iCade, so I knew I wanted to create something that used it, but I wasn’t sure whether I wanted to create a game for the iPad or a Flash game. After a ton of internal debating, I finally settled on going with Flash. Using Flash would give me a lot more development flexibility and speed, especially when it came to making art and animations.

On the morning of the jam, I knew what tech I was going to use, but I still didn’t have a game idea. The trip from my home (in Mississauga) to Guelph takes about an hour, so I figured I could finalize the game as I was driving. The game I came up with on that trip became “Big Runner”.

The Big Idea

The gist of “Big Runner” is that the main character is a skinny guy, but his goal is to burn as many calories as he can, so he’s trying to get as fat as possible so he can burn more calories. The catch is that the fatter he is, the slower he’ll move, and the screen is constantly moving, so he can’t get too fat or else he’ll go off the edge of the screen. I realize this game makes no sense, and I can’t be bothered to make up a decent story for it, so you’re just going to have to invent your own.

I decided that there’d be cake in the game as the food that makes him fat, because I love cake. Nom. I knew I was using the iCade and wanted him to be able to do more than just move around, so I planned on giving him two actions: puke (to make him lose weight), and jump (to burn extra calories – I later took this out).

The Big Animations

When the jam started, I quickly sketched out what the guy might look like as he gets fat, and then I then started making all the assets in Flash. If you have Flash enabled, you can see some of the awful sketches and the animation above. I knew I had to work fast, because with only 7 hours, I couldn’t afford to spend very much time on art.

I made the guy, the cake, and the street background. I also had to make a bunch of UI elements (main menu, score, etc.).  The key with the guy was that I wanted him to visibly get fat, and do it gradually, rather than simply snapping to different fatness levels. Flash’s shape-tweens really helped to create a seamless transition between different amounts of fatness.

Late in the jam, I still needed some sort of “enemy”, and I happened to overhear Connor Pridham (son of @madgarden) jokingly saying something about how every game should have tanks. I realized that tanks would be a perfect fit for Big Runner, so I decided to put them in. Oh, and it turns out that Connor was working on a sweet mix of tanks and Minecraft called TankCraft.

The Big Finish

I spent 2 hours on art and animation, and the rest of the time coding. I finished implementing the tanks right as the jam ended at 7:30 (ok, a few minutes after). The “finished” game was playable with the iCade, and it was actually kind of fun. The music was made by Guelph local Tyler Shaw. My request to Tyler was “music that sounds kinda super-nintendoish, and upbeat, with the melody from Happy Birthday”, and he nailed it (Tyler also made the music for a few other games during the same time period – impressive!).

That 7-hour version had a bunch of things missing, including sound effects and a jumping mechanic. There are also some weird bugs and the hit areas on the tanks are really bad. I hadn’t finalized what I wanted to do with the puking mechanic, so you can puke almost all the time. Through the magic of Flash, you can play the original version right now.

Polish

On the drive home from the jam, I came up with a bunch of ideas for how to tweak the game. The next day, I spent two hours adding sound effects, changing how the puking works, and fixing most of the bugs. I decided it was good enough to put on Kongregate (a popular Flash games site), so I spent another hour implementing the Kongregate API (highscores, achievements, etc), and then I put it up there on Wednesday, after a total of 10 hours of work. You can play the Kongregate version here. See if you can beat 1500 calories.

Game Design

The game is a simple side-scroller with very few elements, and yet it has a surprising amount of depth. The original version allowed you to puke whenever you wanted, so you could control your weight precisely, but I realized that having that much control actually took a way a lot of the decision making and planning. The final version has the limitation that you can only puke when you’re at your fattest, which adds a lot of interesting dynamics.

I really wanted the way you play the game to naturally change and evolve as you play it, and that’s exactly what happens. At the start of the game, you want to eat all the cakes you can, so you’re running around trying to collect cakes. By the later stages of the game, you actually want to stay skinny, so you start having to avoid the cakes. I think twisting something good into something bad over the course of a run is a pretty novel way to create depth and choices for the player, and at the end of the day, this is a game about trade-offs.

There were many happy accidents with the game design of the game, and one of them was with the tank; I really like how the tank’s turret gives a visual warning that the tank is coming. It comes far ahead of the tank’s hit area, so in the early stages of the game, you can tell exactly where the tank is going to come from before the full body of the tank arrives on screen – a subtle but interesting element.

Wrapping up

I think that’s just about all I have to say about Big Runner. Please try out the game and let me know what you think! Feel free to send it around on Twitter and Google+ too, I’d love to see how high the scores can go. Also, make sure you check out the other Guelph Game Jam games, there are some cool projects there. As usual, you can post your comments here or send them @MattRix. Cheers.

Posted in Flash, Game Design, Other Games | 2 Comments