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.

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!

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!

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.

TOJam

TOJam is Toronto’s big annual game jam. This year there were over 250 game devs all making crazy games for 3 days straight. Everyone got there on Friday and worked through the weekend. Some people even slept at the building (or didn’t sleep at all!). It was held at the George Brown College Autodesk Building, and there were tons of great computers (dual quad core Mac Pros with 12gb ram) and great monitors (Apple 24″) for everyone to use.

Being at TOJam was a great experience. Everyone had a ton of energy and enthusiasm the whole weekend long. There seemed to be a pretty even mix of artists to coders, so I got to see tons of game art getting made over the course of the weekend. Lots of people were using Unity to make their games, although I think the most popular tech was still Flash.

Bonus

One of the best things about TOJam was how much free food there was. It was completely free to attend, and yet throughout the weekend there was a TON of stuff being given away. There were bagel and pastry breakfasts, a chinese food dinner, a pizza dinner, and an unending supply of candy, chips, and drinks. I was given the opportunity to sponsor something at TOJam, and so I decided to sponsor the candy area, which was named “Trainyard’s Candy Yard”.

Who?!

I didn’t dare do my first game jam ever by myself. I partnered up with Owen Goss and Whitaker Blackall. Together we formed Team RGB (Rix, Goss, Blackall). The plan was for Owen and me to do art and coding, and then Whit, who lives in Chicago, would do all the sounds and music remotely.

What?!

Alright, so what did we actually make? Well, the theme of the jam was “What Just Happened!?” and so we decided to make a gameshow style party game called “What Just Happened?!” (note the punctuation, hah). The idea was that something would happen, and then as a player, you’d have to answer a question about what just happened. The key was that each player would have their own device to play on, and so we could do things like giving different information to each player and making them work together (or not) to answer correctly.

How?!

Neither Owen or I had done much work with HTML5 Canvas stuff, yet we decided that it was the best option. It was kind of a strange choice considering that we’re both professional iOS developers, but it really just made sense. We wanted to make something that anyone could play just by going to a website on their phone, rather than having to download a specific app. Creating it in HTML5 also meant that it would work on all kinds of devices, including iPhones, iPads, Android phones, and even Playbooks.

The golden rule of game jams is that you should use tech you’re very familiar with, but we blatantly disregarded that. Luckily, we found a framework called EaselJS which let us get up-and-running with HTML5 dev pretty quickly. The backend multiplayer code is written with Node.js and Socket.io, which I had used once before when creating Nodetris.

We split up the coding work pretty evenly between us. Owen did the majority of the frontend UI work, and I did most of the backend stuff and minigames, although we definitely switched roles a few times over the weekend (the Goat minigame was 100% Owen, for example). All of the work on art was also split between Owen and me, with some small debates about what style to use for the buttons and the logo, among other things

We gave Whit the rough guideline of “create music that sounds like an old game show, something like The Price Is Right or Jeopardy”, and he did an amazing job. Whit also did all the announcer voices and other sound effects as well, all of which were spot-on.

Whit’s The Price Is Right style theme:

Whit’s Jeopardy style theme:

The Result

So after 3 days, TOJam ended at 8pm on Sunday night, and we finished right on time. The final game has six different minigame types (clock, robot, numbers, colours, penguins, goats). Each minigame has 3-4 possible questions that could be asked. For example, in the number game, it puts a different number on each person’s screen for a few seconds, and then asks a question like “which number was on the most screens” or “what’s the total of all the numbers that were shown”. Every minigame has tons of random variables, so no two games will ever be the same. Below is a quick quick demo video I made of the game:

Try it out

If you want to try it out right now, just go to WhatJH.com. It’s set up so that you can create a room at whatever subdomain you want. You can play it by yourself by opening up a few browser tabs, although it’s a lot more fun to play with real people. It’s worth noting that if you want the awesome sounds+music, the host should be run in a real browser with Flash, because HTML5 audio support is awful.

So that’s about it! Let me know what you think in a comment or on Twitter. I’ve also included Owen’s demo video of it below, because he does a great job of showing what it looks like to go through a full game.

I’ve been exchanging emails over the last couple weeks with Parker, the developer of an iPhone game called MicroSquares. He originally emailed me to ask some questions about what he could do to improve the popularity of his game, and wondered if I had any tips to help bring his game to the next level. After looking at his game, I realized that it had potential, but there were definitely some things that could use improvement.

In the same timeframe I also had some similar conversations with other developers, and I realized that it would be great to make my suggestions for MicroSquares public, so that other developers could adapt them, learn from them and discuss them. Parker hasn’t heard any of these suggestions yet, but he did give me permission to post this on my blog.

I should point out that I’m definitely no expert at any of this stuff; these are just my opinions and sometimes they may be completely wrong. My marketing advice comes from my experience with Trainyard, my design and usability advice comes from my days as a Flash developer, and my gameplay advice comes from hundreds of hours playing iOS games and working on games of my own. This post will probably come across as a bit critical, but I’m just being honest about the things I think Parker will have to do to make MicroSquares succeed. There are plenty of great aspects to the game, but I’m intentionally focusing on the negative because that’s the stuff that needs improvement. He’s got the core of a good game here and it really does have potential, but there’s still some solid work ahead.

What is MicroSquares?

MicroSquares (iTunes link, 99c) is Parker’s first and only iPhone game. it works like this: you’re a square floating among other squares of varying sizes. You tilt to move, and grow if you eat smaller squares and die if you’re hit by bigger squares.  The game is relatively simple and not entirely unique, but it’s fun. Some extra flavour is added via powerups that give you abilities such as “boost” and “magnetism”. I’d highly recommend downloading the game so you can “follow along at home”, it’s only 99c and I’m sure Parker would appreciate it! I’ll be providing screenshots here in the post so you can see what I’m talking about.

Visuals

I want to get the visuals out of the way, because I think that’s the area where the game needs the most tweaking. I heard this simple rule from someone who is a much better designer than me: “never use gradients with vector art”, and I think it’s true 99% of the time. There are definitely some high-end graphic artists who can pull it off, but for us mere mortals, it’s best to stay away from it. Gradients give vector art a cheesy “amateur Flash animation” vibe. If Parker replaces all the little gradients with flat colours I think it’ll give the whole thing a cleaner look.

On the topic of the squares, the main square is just a green box. That’s OK, but this’d be a great place to create a character with some personality. It doesn’t have to be Pixar level stuff, just slap a couple eyeballs on him and see how he looks. I think this is the sort of game that could really benefit from having a unique lead character. It would give the game a bit more of a “fun” vibe, and it’d add the potential to create other characters, sequels, and a eventually a whole brand.

It’d be cool if the powerups had icons on them instead of letters like “B” and “I”. Icons are a handy way to let users build up associations quickly, and I don’t think there would be any trouble coming up with icons for each power-up.

The score seems to be the most important stat, so I feel like it should be given more emphasis, right now it’s tiny and tucked away in the top corner.

For the menus, the font needs to change. Fonts should always match and support the subject matter, and I feel pretty strongly that marker/handwritten fonts should only be used for drawing apps and kids apps.  The rest of the game has a fairly clean look, and the story is “sciency”, but the font *really* throws it all into confusion. A nice clean font would do wonders for the look of the entire UI. In my opinion, this is the number one problem with the overall look of the game right now.

Audio

The music is *very* ambient and drone-y. At first I didn’t like it, but it started to grow on me. That being said, I still don’t think it suits the feel of the game. Music that’s upbeat and intense would make the game much more exciting.

The sound effects also need some love. Some are just subtle but others are non existent. The current “eat” sound is just a click, but I think it should be an upward “growth”sound. The powerups hardly make any sound, and there isn’t even a sound for when you die. This could all be remedied with a few well-picked sound effects.

Gameplay

Overall, I think the gameplay is great. It takes a little getting used to, but it’s fun to float around eating and avoiding. I like the on-screen “re-centering” button, but the tilt controls need to be a bit more sensitive. I found I was tilting my device too much while playing. Any time I’m giving advice on a tilt game, I always have to recommend Tilt to Live and Dark Nebula. These games aren’t just good examples, they’re the absolute pinnacle of tilt control on the iPhone. Parker should have a close look at both of these games to try to model his controls after them as closely as possible, as they really are perfect.

I think Parker needs to decide whether he wants this game to be a “zen” game, or an intense “survive-at-all-costs” game. Right now I think it feels too mellow, and the pace just needs to be amped up a couple notches. The game offers four difficulty modes: Easy, Normal, Hard and Insane. I think that’s too many. Most games like this only need a normal mode and an insane mode. The normal mode should start easy, but get hard pretty quickly. With too many difficulty options the player will just get confused about whether they’re playing in the right mode or the best mode for them, and they’ll be frustrated. As I was playing the current game, in the easier modes (all the way up to hard), the game was really too easy and it took a long, long time to finally die. I think it’d be best to keep the average “normal” game time in the 1-3 minute range, right now it feels like it’s way longer.

At this point, MicroSquares only has local highscores. I think it’d be in Parker’s best interest to invest some time into learning and implementing OpenFeint or GameCenter. I think he’ll be surprised at just how easy it is. Online scoreboards could help a game like this to thrive and build a following.

Marketing

I know most of us developers hate the marketing side of things, but it’s a necessary evil. MicroSquares doesn’t have a YouTube trailer, but it needs one. A video is a fantastic way to show people what your game is all about, and you can reuse it all over place, especially on your promotion site instead of a wall-of-text explaining your game. Making a trailer really isn’t that hard to do, even if you’ve never done it before, and there are plenty of people out there who’ll be happy to point you in the right direction if you need help.

The actual content in the app description for MicroSquares is great, but the order needs some tweaking. Users often only see the first two lines, so make sure you say the most important bits there! I like to follow this up those lines with a bunch of bullet points, and then finally the paragraph-heavy description stuff last.

Just one small note for the credits screen. It’s great to ask for reviews, but Apple actually allows devs to link directly to the review page, so that’s something every single developer should utilize. Do everything you can to make it as easy as possible for users to review your game!

I’m not a designer, so I can’t say exactly what needs to change here, but this icon definitely needs some work. This is one of those places where a professional designer can really come in handy.

Miscellaneous

Just a few random notes for MicroSquares:

• It seems to crash on the iPad. Not the end of the world since it’s not Universal, but still should be fixed.
• Currently the pause button gets shown when we’re already in the pause menu (and in every menu), which seems a little weird.
• I love how Parker is tracking tons of stats, but I think they need to be presented in a bit more of a fun way, right now it’s just a plain bulleted list.
• The red titles on the blue background in the menus clash heavily. I think if it was just blue and green with no red, that’d probably be best.
• The tutorial is basically fine, but it needs bigger “left”, “right”, and “exit” buttons.
• The powerups are decent, but I think they’d be way more fun if there were more visual effects, like particle trails and other cool stuff.

Wrapping up

That’s about it! I realize this post is strange compared to the sort of things I usually post, but I really wanted to try something different as an experiment. It was fun. I’m sure Parker will find this handy, and I hope that the rest of you will pick up some useful things too.

PS: I’m going to check in on MicroSquares “after the transformation” to see how things have changed, watch for that post in a few months.

UPDATE: I’ve heard from Parker that he got a lot out of this post, and he’s going to be working to implement most of the changes that were suggested. Stay tuned!

A foreword: I know a lot of people are expecting me to talk about how Trainyard Express has performed since being released last Thursday. Well, it’s been doing amazingly and blowing away all of my expectations. It’s currently the #1 free app in Italy and it’s climbing quickly in the UK and in Canada. There’s a lot I could say about it, but I feel like it’s only getting started and I really don’t have any hard conclusions to provide yet… Only to say that doing a lite version was 100% the right thing to do. I feel like I’m probably giving away too much content, but I think that’s what I have to do to get noticed, and it’s working, so I’m ok with that. Now back to your regularly scheduled post:

What are in-game tutorials?

In-game tutorials are a visual way to show a user how to play your game within the game itself, usually using the game’s own engine. I think it might be easier to explain what they are by explaining what they’re not: They’re not instructions screens, controls screens, or long-winded paragraphs of text.

Why use in-game tutorials?

If you want users to enjoy your game, they’re going to have to be able to actually play it. I know it seems simple, but I’ve played way too many iOS games where it felt like figuring out HOW to play was a puzzle in itself. A paragraph of text is never a good way to teach somehow how to play your game. Your instructions will probably introduce all sorts of terminology that the user won’t be familiar with, which’ll just confuse them. I’d be willing to bet a lot of money that most users don’t read ANY of the text they see in games anyway.

I haven’t done any localization in Trainyard, but my two biggest sales regions this past week were Japan and Italy. I believe this is in large part to the in-game tutorials, because players can get a complete understanding of how the game works even if they don’t understand English. As a part-time dev, I can’t justify spending money on localization, but having great in-game tutorials is the next best thing. Here’s an interesting challenge: replace all of your game’s text with wingdings or some other gibberish font, then give it to someone who’s never played it before, and just watch (no helping!) as they try to ∂learn the game.

I know the usual alternative to a “wall of text” is to create a few pages of instructions. These are usually quite visual, with screenshots of the game itself and little arrows showing what certain things are and what they do. This approach is much better than text, and it’s good enough for some games, but it’s still not ideal. You’ve got your whole game engine sitting there, why not use it? If it’s at all possible, you show what it looks like when the game is actually being played. I know I learn way more about how a game works from watching a Youtube video of someone playing it than I do by reading it’s instruction screens. There’s something to be said for “discoverable mechanics”, and you definitely don’t have to give it all away, but the user shouldn’t ever feel like they might be playing the game wrong.

How did you do tutorials in Trainyard?

The tutorials in Trainyard are spread out over the first 10 “cities” of puzzles. That means that there’s a tutorial roughly every five puzzles. I didn’t want to swamp the user right at the start, so I only gave them the bare minimum amount of information they needed at any given time. I think it worked out pretty well and gave the game a nice flow.

The tutorials are made from a few components, but the key thing is that they look like the game and they use the game’s engine. I made a hand that dispatches fake touch events on the Trainyard grid just like real touches do.  The ridiculously ugly hand has an over-the-top tapping animation so that it’s really easy to see what it’s doing at any given point in time.

There are multiple tutorials on each different concept, and each individual tutorial is broken into steps. A step is a section of the tutorial that plays out and then waits for user input to continue. I never assume the player has a certain reading speed, so any time there’s text on the screen, I let them choose when to continue. Each step is broken into actions, which are basically any of the things that can happen, like moving the hand, showing text, and resetting the puzzle.

I wanted everything to be dynamic and easy to edit and tweak, so I built a simple xml file to describe the tutorials. I won’t go into details about what I do with each node, but feel free to ask me if you’ve got questions about how I implemented any specific part of it. I know the schema is a bit weird, but it makes a lot of sense once you get how the system works. You can see the xml for all the tutorials here: http://struct.ca/files/trainyard/tutorials.xml

Random Tidbits

In the original 1.00 build of the game, there was no tutorial skip button. It was a common request from beta testers, but I decided against it because I was willing to risk aggravating users early on to keep them from getting aggravated later (by not knowing a technique to solving a puzzle). This was such a common request after release that I eventually caved and put it in, but with a little adjustment: If players try to skip a puzzle, they’ll get an “Are you sure you want to skip this tutorial?” popup, so they have to think hard about their decision.

Another first-release complaint was with the speed of the tutorials. Everyone complained that they were way too slow, so I shortened every single delay and generally made it all run much faster. I also took out quite a few of the text popups, and even took out one tutorial entirely (the one that explains how to go around rocks).

It wasn’t until the last 20% of Trainyard’s development that I switched to using in-game tutorials. I had written and implemented a whole pile of text-only instructions/tutorials for the first set of puzzles, but it just seemed rushed and amateur. The in-game tutorial system probably added a month’s work to the project (working part time), but I think it was worth every minute I spent.

PS: The whole “text vs. gameplay” thing also plays an important role in marketing. Why have bunch of bullet points about your game on your site, when you could put a video of someone playing it instead? (ala minecraft.net).

What is 8-bit?

The 8-bit name comes from 8-bit computer architecture, but the 8-bit style itself is really based on games from the 8-bit console era (NES and Master System). These days, the name “8-bit” seems to cover stuff from the 16-bit era as well. 8-bit graphics are called pixel art, and they have low resolution and low colour depth.  The music in 8-bit games has a very distinct sound and is often called “chiptunes”.

Why 8-bit?

Let’s be honest: it’s just plain cool. Unlike doodle graphics, I get the sense that using pixel art adds credibility instead of taking it away. It’s been used a lot, and yet it never really seems overused. Pixel art is also a ton of fun to create. It requires a certain amount of skill, but it’s much easier to make (for me) than the style I was originally considering for my next game (pre-rendered 3D).

8-bit inspired music is also awesome, with a style all its own. I’m planning to make the music for this game myself, mostly because I’d love to dabble in making music that sounds like this: http://georgeandjonathan.com/.

Implementing 8-bit

I’m not 100% certain of the approach I’m going end up taking to get the graphics to look right. The general idea I’ve seen in most 8-bit iOS games is that they double the pixel sizes, so that each in-game pixel takes up four real screen pixels(sixteen on the Retina display). For now, I’m actually using double-sized assets and rendering in 480×320 but I may move to using a half-size buffer and assets so that it’s truly low-res.

I’ve seen different 8-bit games use different approaches. For example, Super Quick Hook has low res in-game sprites, but the text is actually pretty small and high res:

8-bit tools

Sprite Something

Sprite something is *awesome*. It’s an iPad app for creating pixel art sprites, and it’s what convinced me that 8-bit was the right style for my game. You can use it to easily create pixel drawings, which it’ll export as transparent sprite sheets. Well worth the $2.99

SFXR

SFXR is a simple 8-bit retro sound generator that was created as a way for devs at Ludum Dare to create sound effects really quickly.  It’s open source, and has been ported to Flash for convenient in-browser use: http://www.superflashbros.net/as3sfxr/

SunVox

SunVox is a free cross-platform music making application.  I have to admit that I haven’t used SunVox yet, but it looks really cool, and I’ve heard some awesome music created with it. For music creation on the go, there’s also a SunVox iPhone app ($4.99).

Inspirational 8-bit iOS games

The Incident

Super Quick Hook

Canabalt

Gravity Hook HD

What is a doodle game?

If you’ve only played one doodle game, it’s probably Doodle Jump. Doodle Jump is the granddaddy of all doodle games. There were other doodle-style games before it (like Crayon Physics), but Doodle Jump’s 5 million sales are what really brought the style into the mainstream. Since then a bajillion doodle games have popped up on the app store. It’s important to note that “doodle” is just a graphical style, not an actual genre, so there are doodle games in just about every games category. The vast majority are terrible, but there are some truly great ones like Doodle God.

Why make a doodle game?

The first and most obvious reason to make a doodle game is to cash in on some of Doodle Jump’s success. Having “doodle” in your game’s name means it’ll be more likely to come up when users search for Doodle Jump. When doodle games started appearing after Doodle Jump got popular, it was a common reaction to think they were sequels to the original game. I imagine a lot of users still think the same thing upon seeing games with “doodle” in the title and hand drawn visuals.

The second reason to consider making a doodle game is because it’s easier to produce the graphics. Let’s be honest, a lot of us developers don’t have great artistic abilities. Doodle visuals are a great way for us to make passable art pretty quickly by ourselves. Some developers seem to take the opportunity to make their doodle games look as awful as possible, but I really think that even doodle games take a lot of polish and planning to get everything just right. Take a look at the Doodle God screenshot below for an example of a well polished doodle game.

What’s wrong with doodle games?

Nothing, when it comes to the visual style. As long as the hand-drawn looks makes sense for the type of game you’re making, I see absolutely no problem using it. With games like Crayon Physics, the doodle style totally makes sense, but with other games, the style really feels like a stretch. The real problems have to do with using “Doodle” in your game’s name. It just feels icky and unoriginal. It makes it seem like you’re trying really hard to mooch off Doodle Jump’s success. It’s purely a business decision, rather than an artistic or creative one, so it’s pretty much the closest thing in the iOS world to “selling out”. This leads me to the next question:

Why do you make games?

Do you make games to express yourself, or do you make games to make money? These two things aren’t mutually exclusive, but I’d bet most people who read this blog would be slightly closer to the “express yourself” side of the scale. I know that’s definitely the side I was on when I made Trainyard, but as I’ve been working on my next game and deciding its brand, I’ve arrived at the real Doodle Dilemma: is it worth selling out in the short term so that I can make the games I really want to make in the long term?

Decision time

I’ve decided to not make my next game a doodle game, or even in the hand-drawn style. If making a doodle game guaranteed a hit, then maybe I’d do it, but I’d rather not put the reputation I’ve built from making Trainyard on the line. However, it is seriously tempting to set up a secondary “crapware” company, just to see what sticks. I’ve also made a promise that if my next game doesn’t do well, I’ll rebrand it as a doodle game (perhaps under the crapware label) and do some good old a/b testing. Maybe you’ll even see “Doodle Trains” at some point in the future.

Sidenote A: I’ve always wondered if Doodle Jump’s success was influenced more by having ”WARNING: HIGHLY ADDITIVE” in its title rather than its actual visual style.

Sidenote B: Ngmoco just released “We Doodle”, which is basically a rebranded freemium version of their “Charadium” game. I’d say this shows that even the big studios aren’t immune from making doodle games.

Random thoughts: There seems to be a lot of pressure in the indie games world to constantly create new and unique game concepts, and for some reason, along with that, intentional marketing and business tactics are often frowned upon. I get the idea that the devs of some games, like Canabalt, even feel that having a 99c sale would be a form of selling out. I’ve also noticed that indie iOS devs take a ton of flak about things like in-app-payments, often moreso than their big studio counterparts.

Trainyard is my iPhone game. It’s a grid-based logic puzzle game where the goal is to get each train from its initial station to a goal station. Every train starts out a certain colour, and most puzzles require the player to mix and merge trains together so that the correctly coloured trains end up at the right stations. The player’s only method of input is drawing tracks for the trains to follow. It’s kind of hard to explain with words, so if you’re confused you should watch the trailer.

I came up with the idea for the game a year and a half ago, during a period where I was actually working on ideas for Flash games. At that time I didn’t have any iPhone development experience, and had barely even looked into Objective-C. I did, however, have an hour long commute by train which gave me plenty of time to come up with interesting game ideas. My main game prototyping tools were (and still are) a notepad and an Acer Asprire One netbook. Yes, a netbook. I’ll probably write more about that little guy in a future post. For now let’s focus on the notepad.

Every game designer should carry around a notepad as much as possible. You never know when the spark of a great game idea is going to come to you. I went through notepads and notebooks of all shapes and sizes while working on Trainyard, so I really don’t think it matters which kind you use as long as you’ve got one. I suppose you could try an iPhone app for recording ideas, but there’s something special about being able to sketch with a pen.

A notepad is more than a place to write down the gist of an idea, it’s also a great place to flesh concepts out and figure out how you’re going to execute them. In the case of Trainyard, my initial idea (as you can see on the page above) was “each train starts with a solid colour that they have to mix and deliver”. So far so good. Ok, let’s look a little further down that page: “[trains] can collide, have two cars, and pick up paint”. That’s quite different. My original idea was that each train had several cars to pull, and each train would also have its own control panel where you could adjust the speed before pressing “Go”. Confusing? Yes. Would it make for a good game? Maybe, but it’s definitely not Trainyard.

On this second page you can see some more questionable ideas: “Game could be hex based instead of square”, “limitations include fixed quantities of pieces”.  At this point in the process I was thinking of limiting the user’s selection of pieces like a lot of other similar puzzle games do. After thinking through the mechanic over the next few days, I realized that I could make it work without limiting the user’s piece selection. I think the flexible unlimited-track nature of Trainyard is now something that really makes it unique. At one point a lot later in the prototype process I even made a hex based prototype (flash link)  just for fun, but it felt weird and confusing.

After those first few sketches, I worked over the course of a few days to eliminate most of the extraneous ideas and the concept gradually got closer and closer to what it is today. About a week after coming up with the initial idea the core gameplay mechanic was transformed into something nearly identical to what it is now. Keep in mind that at that point I still hadn’t coded anything; it was all on paper. I even have a sheet of paper with a detailed solution to the very first Trainyard puzzle ever created, which actually made it into the game as The Original. Unfortunately I couldn’t find that piece of paper in time for this post, but when I do I’ll be sure to put it here.

The moral of the story: as developers, we’re often tempted to go straight to our computers to make prototypes and tests, but sometimes it’s good to just sit down with a pen and paper and flesh out an idea.

I hope you enjoyed this first little look into the Trainyard development process. I’m planning to post at least a couple times a week, so please add http://struct.ca/feed/ to your RSS readers and whatnot. I’ve never had my own blog, so my writing style is going to be a bit rough for a while, but bear with me, it’ll get better over time If you didn’t come here from iDevBlogADay, make sure you check all those other blogs out, there’s some great stuff there.