However, the question I was asked over and over was why am I making games? What are my answers to that question? As I said before, there are no right or wrong answers. Everybody needs to find their own answers, so in that respect, my answers don’t really matter.

On the other hand, since what I write here is purely personal, and a lot of people are curious about it, I figured I would give it a shot and answers those questions publicly.

Another thing I also want to stress is that these are not even permanent answers for me. These are my answers for the projects I’m working on right now. Whenever it’s time to start a new project, I will ask myself this question again and probably come up with different answers. That, I think, it’s key to be able to focus on some aspects at the expense of others, instead of always compromising and trying to achieve a bit of everything.

Why I Am Not Making Games

You thought I was going to get right away to the reasons why I was making games? No, it’s not that easy. I need to start with the reasons I thought I was making games, but turns out I discarded (for this time around).

Innovation/awards

I’ve always felt an urge to innovate and create something original. Something that would be worthy of getting some awards and recognition. Even back in the Power of Two Games days, Charles and I (half) joked that if we won an IGF award, we would eat a whole cheesecake from E Street. Unfortunately (or fortunately, depending from your point of view), that never happened, and the cheesecake remained safe behind the glass. Flower Garden was pretty innovative (even to this day, there aren’t many similar games–if you can even call it a game). Casey’s Contraptions had some original aspects, but its main strength was in polish of execution.

For this time around, I decided that this was not going to be one of the main reasons behind me making games though. I’m sure I’ll come back to this one very soon though.

Money

It’s hard not to think about money when one of your main target platforms is iOS. I know they’re mostly the exception, but looking at the huge financial success of some indie developers, or the revenue of some of the games on the Top Grossing chart, it’s only natural to want a slice of that pie.

Since free-to-play is one of the most profitable approaches on the App Store, I originally started out some of my designs by trying to do “free-to-play done right”. I was going to show the world how you can make a free-to-play game, treat players as human beings, not play any psychological tricks, not make the game suck on purpose, and still make a boatload of money.

Along the way, two things happened:

1. It’s a lot harder to design a game that does all those things than to write it out in a neat, little sentence like I just did.
2. Chris called me on it. He asked the really pointed question of “if you don’t need the money, why focus your design around that idea when there are so many interesting design aspects out there to explore?” He was totally right! At this moment, I don’t have the financial pressure to ship a game, so why limit my game artificially like this?

Those two things, combined with the fact that I hate most games in the Top Grossing chart of the App Store, means that I should not even try making a game aimed at that audience.

Since money eventually runs out, I will have to consider money more seriously in future projects. Even so, I will probably go the route of making more personal, niche games that appeal to a small percentage of people, rather than try to go after a pure mass-market approach.

Expressing something

I fall in the camp of people who believe that games are (or can be) art. That’s especially true of indie games, which carry the strong creative touch of an individual or a small team. Starting from something you want to express. For this one time, I was going to put that aside and focus on other aspects.

Why I Am Making Games

After removing all those reasons (and lots more that I didn’t talk about), why am I making games? Or rather, why am I making the games I’m currently making? It turns out, the reasons for these game are mostly selfish.

Enjoy the development

I wanted to make a game where I would enjoy the actual development as much as possible. This is a lot more constrictive than it may seem at first glance, and it means many things:

• I wanted to avoid games with large components that are uninteresting to design and implement (in-game stores, credits, managing users, etc).
• I need to be exploring new concepts (to me) and trying new things to really enjoy the development process, so the game needs to be substantially different from other games that I made in the past: no growing virtual plants, or creating physics puzzles to share with friends.
• The focus of the game should be on the design itself, not some technology. Even though most of my past experience comes from programming, I’m only interested in design these days. Programming is just a means to quickly convert my ideas into something the computer can do, but I’m not interested in programming for the sake of programming (as anyone who looks at my code can attest to).

Create something I’ll be proud of afterwards

This is an easy one. It doesn’t matter how much money the game makes, but I wanted it to be something I can be proud of afterwards. Interestingly, the “innovation/awards” point is a subset of this reason, but this point is more general, and I can be proud of the games I make for many reasons.

You would think that this point should go without saying, and nobody should be making games they’re not proud of. Unfortunately, just a glance at the App Store will quickly convince anyone that’s not the case.

One more thing…

Indie game development can be a pretty solitaire affair, but that’s not something that bothered me too much (maybe growing up an only child had something to do with that). I never needed someone else to keep me motivated in or committed to a project.

I am currently working on not one, but two different projects at once. Soon I’ll be able to start talking about them in detail. Both of those projects are collaborations with other people. After working on them for a few months, I have come to realize that working with the right people can be really invigorating: Bouncing ideas back and forth and see them grow into something bigger than they started, or just pushing and motivating each other has become completely invaluable for me. I’m hoping to be able to continue working and collaborating with amazing people in my future projects.

Why are you making games? No, I don’t mean “why are you making games?”. Also, I don’t mean “why are you making games?”. And I certainly don’t mean “why (on earth) are you making games?”. I mean the question in the purest, most abstract sense. Just “why are you making games?”.

This was a key question for me last year, I spent a lot of time thinking about it, and I thought other people might benefit from asking themselves the same question. To see where I’m coming from, let’s do a quick flash back.

It’s late 2011. Miguel and I finished working on Casey’s Contraptions and my daughter was born. I took a couple months completely off from work (new dads will understand why), and then, right at the turn of the new year, I decided to start working again. The plan was to prototype a few of the juiciest ideas, pick one that really stood out, and make a new game in a few months. How hard could it be, right?

Right?

It turns out it was a lot harder than I ever imagined. I was confident in my list of hundreds of game ideas that I had been adding to over the years. I picked one idea, made a quick prototype in a day or two, and decided that I wasn’t as excited about that idea as I thought. So I picked another one, and another prototype that didn’t go anywhere. Then another, then another, and then another. This went on for months.

By the time I realized that my prototype icons weren’t fitting in a single page on my development iPad, I started worrying that something was wrong. Prototyping is great, it allows you to find the truly great ideas and all of that, but I wasn’t any closer to a game idea I wanted to make than when I started.

At this point, I even started prototyping game ideas I knew I was not going to make, just to remove any pressure on me, as well as to get it out of my system how much I hated those game genres. It was an interesting effort, but, as you can imagine, it didn’t lead to any shipped games.

I did, however, help me start figuring out what was going on. I realized that the prototypes I was creating were dissatisfying because my intentions were unclear. I wanted too many conflicting things out of this next game, and that was pulling the game in all kinds of opposite directions.

I wanted to make a unique a different game, yet at the same time I wanted it to reach a huge audience. I wanted to ride the wave of financially successful iOS games, but I didn’t want to sell my soul with freemium-based games, and instead, I was going to make a “good” freemium game. I wanted to make something innovative, but I wanted to do it in just 6-9 months. I wanted it all, and I wanted it yesterday. Bad combination.

That’s when I sat down and asked myself point blank “why am I making games?”. Or at least the more concrete version “why am I making my next game?”. That’s a surprisingly hard question to answer really honestly. I had to peel away a bunch of layers until I found the answers to my question.

My specific answers don’t matter because there isn’t a right and wrong answer. Any answer is good as long as it’s honest, from the bottom of your heart. There are as many valid answers as game developers out there. Some people make games because they want to be famous, others because they want to make money, others because it’s the only thing they know how to do, others because they want to win awards, others because they want to reach as many people as possible, others because they want to tell stories, etc, etc.

It’s actually amazing it took me this long to ask and confront this question. When you’re working on a game company things are different, and you don’t need to do that level of introspection. But once you go indie, it becomes really important. Even though I’ve now been indie for 6 years, I’ve been going in automatic pilot all this time, kind of skirting around this issue and winging it. I see a lot of indie developers out there doing the same thing, with greater or lesser success, but still conflicted internally about what they’re doing.

Once you have the answer to your question, you can use it to guide you in any big decisions related to game development, and even in life in general. Which projects to tackle, or even what features to add to your game, will often be easy to decide if you keep your goals in mind.

For me, within two weeks of answering the question, I had settled on not just one, but two different projects that I was super-excited about. Both projects are still moving along and I hope to start sharing information about them soon.

So I encourage anybody reading this to make some quiet time in the next few days, and pose yourself the question “why am I making games”. Once you find your answer, not only will it help you with future decisions, but it will make you more satisfied with them.

Right now I have a couple of game ideas in hand that I’m pretty excited about. I prototyped one of those, but I quickly realized it might be a game better suited for desktops rather than iOS, so I decided to write my next prototype for that game on the Mac. Maybe another day I’ll write a post about prototypes, but what I want to write about today is my experience moving over my prototyping code to the Mac.I’ve been working on MacOS since 2007, when I switched because of iPhone development. For the most part, I’ve been loving it as an OS, but I never actually targeted it as a platform in my development. I figured it wouldn’t be very hard at all to compile my simple C/C++ + OpenGL code that I use as the basis for all my iOS games on MacOS. After all, that code started on Windows and DirectX, and porting it to iOS was pretty quick and easy. On top of that, I can use Xcode 4 for Mac, just like iOS (I’m not sure that counts as a plus though). How card can it possibly be?

The answer is, not hard at all, as long as you’re aware of a couple gotchas along the way.

Xcode project

I figured I would start from scratch, so I created a new Xcode project targeting MacOS. First surprise was that, unlike iOS, there wasn’t a template to create an OpenGL application. Instead, I need to create an empty Cocoa application and set things up by myself. No big deal.

I used the samples from Apple to get me started. I could have grabbed those and started adding stuff, but for some reason they have all the logic built into the OpenGL views, and I like to keep my views as simple as possible: they hold the surface to render, and they collect input and other window events. Done. So I had to do some moving around of code and responsibilities, which at the same time allowed me to make it more like the structure I used on iOS.

The AppDelegate does most of the initialization and creation on applicationDidFinishLaunching, and the OpenGL view gets created through the minimal nib file (with just a menu, window, and a view). AppDelegate is also responsible for setting up the display link callback, and then all the rest of the execution happens in my own code, away from those classes.

That was all pretty smooth. The only weird gotcha I ran into is that, unlike with previous Xcode 4 projects on iOS, I was no able to add any files to it that were not under the project root. They would turn red and not be available in the project. I tried adding them in every possible way and always got the same result. So, in the end, I gave in and just moved my External dir under the same directory as the Xcode project. Some people on Twitter had the same experience, while others didn’t, so there’s something fishy going on in there.

I have all my game static libraries (I refuse to call it an “engine”) as a separate Xcode project. I was able to add the project to the workspace and just change the target to be MacOS, and everything worked without a hitch.

OpenGL

I knew I was going to have to make some changes to the graphics code because all my iOS code uses OpenGL ES 2.0, and the Mac supports OpenGL “non ES” version. But I never did any graphics programming on the Mac, so I had no idea what to expect.

I decided to start with this sample code from Apple. After all, it seemed to be exactly what I was looking for: A simple project that sets up OpenGL both on iOS and MacOS. Score!

Once I started digging into it, I realized that it wasn’t going to be as straightforward as I realized. It turns out there were lots and lots of differences between OpenGL ES 2.0 and the OpenGL version on the Mac. Some were easy to catch, like different syntax for the shaders (“varying” became “in”, “uniform” was “out”, etc). Some were a pain to track down (needed to bind some Vertex Array Objects, and I was forced to use Vertex Buffers).

The documentation wasn’t clear on this point at all, but fortunately I got some good tips from Twitter. It turns out that the sample I used as a starting point created an OpenGL 3.2 context, and OpenGL 3.2 is very different from OpenGL ES 2.0.

	NSOpenGLPixelFormatAttribute attrs[] =
	{
		NSOpenGLPFADoubleBuffer,
		NSOpenGLPFADepthSize, 24,
		NSOpenGLPFAOpenGLProfile,
		NSOpenGLProfileVersion3_2Core,
		0
	};

	NSOpenGLPixelFormat* pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs];
	NSOpenGLContext* context = [[NSOpenGLContext alloc] initWithFormat:pf shareContext:nil];
	int swapInt = 1;
	[context setValues:&swapInt forParameter:NSOpenGLCPSwapInterval];

It turns out that leaving out the last attribute (NSOpenGLPFAOpenGLProfile) creates an OpenGL 2.1 profile, which is very similar to OpenGL ES 2.0 (GLSL 1.2 is the shader version that OpenGL 2.1 uses and that’s also very similar to GLSL ES). With that change, all the OpenGL code worked perfectly, with the only exception of the precision modifiers in shaders. Fortunately, I we can wrap those up in a simple #ifdef like this

#ifdef GL_ES
precision lowp float;
#endif

Unit tests

Apart from input, which will require a total re-work, the last major thing I had left was running unit tests after each build. I’ve seen references to Xcode’s unit testing functionality, but I was hoping to reuse UnitTest++ and run it like I do on iOS projects. It turns out it was even easier because you can run them natively without the extra step of the simulator like on iOS projects.

All I had to do was create a new phase in the Debug scheme to run a script. The “script” is just the name of the executable that was just build with the -unittest parameter added to it. I suspect that there’s probably a “better” way than hardcoding the .app/Contents/MacOS/ string in the middle to find the binary itself, so if someone knows the correct variable that includes that, let me know.

The only other thing that came up is that apparently Xcode adds the parameter -NSDocumentRevisionsDebugMode when you debug it from the IDE. No big deal, unless you have your program exit with an error if you pass an unrecognized parameter. I just made it accept and ignore that parameter, and everything worked like a charm.

Conclusion

It took a bit longer than I expected, but I finally have my code base running on MacOS. Iteration time is faster because it doesn’t even launch the simulator, and I suspect graphics performance will also be a lot faster (the iOS simulator does all the graphics processing in software), so I might end up doing more prototyping on the Mac unless the touch input is an integral part of the game.

I’ve been receiving a lot of questions about how it happened, how’s affecting me, and what my plans for the future are. So here’s my attempt to answer some of those questions.

The Game

It might come as a surprise to a lot of people, but selling Casey’s Contraptions was never in our minds. Miguel and I put all our energy into making a great game and infusing it with lots of personality. Half way through development we realized we had something special in hand, and when Apple selected it as the iPad game of the week and the reviews and comments came pouring in, we knew the game had connected with a lot of people. We were thrilled.

We were in for a big surprise when sometime after the iPad release, Rovio approached us and offered to buy Casey’s Contraptions. We were understandably very attached to the game we had just released, but Rovio eventually made us an offer we couldn’t refuse.

Rovio is one of the biggest players in the mobile market, and sometimes people get tired of seeing the top 10 charts full of Angry Birds. I’ve always had a lot of respect for them: Angry Birds wasn’t just a fluke, it’s a super approachable game, perfectly suited for mobile phones, and crafted to perfection. They deserve all the success they got. I don’t think I would have agreed to sell Casey’s Contraptions to most of the other big game companies.

As the co-creator of Casey’s Contraptions, I’m super excited to see it reach a much wider audience we could have ever dreamed of reaching ourselves. Every developer’s dream is to see people playing your games, and Rovio can make that happen with their huge marketing power and influence. Just look at all the media sites covering the news for the Amazing Alex announcement (most of those sites never talked about Casey’s Contraptions at launch ).

Miguel and I chose not to be involved in future development of Casey’s Contraptions/Amazing Alex. As an indie developer, your time is the most limited and precious resource. Every game you release takes some of that time away even after it launches: new content, higher-resolution graphics, fixing problems with the latest OS version, porting to other platforms, etc. This was a great opportunity to pass the baton to Rovio and be able to focus 100% on new creative projects.

Yes, it’s hard to let go. Not like I have experienced that yet, but it probably feels like sending your kid to college, knowing that he’s starting a new life without you. At least we can rest easier knowing Casey is in good hands. Whenever Amazing Alex becomes a worldwide hit, we can proudly point to that and say we started that game.

Personal life

On a personal level, my life hasn’t changed at all. Flower Garden has been doing a good job at keeping my family fed for the last few years, so getting more money doesn’t have a huge impact. This unexpected deal bumped up those numbers in the bank, but hasn’t otherwise changed much for me. No Ferraris in the garage, or even, for those who know me, no fancy new road bikes (still riding my trusty 12-year old Trek 5200). The only splurge was buying a 30″ Apple Cinema Display.

The deal has, however, definitely affected my future projects. At one level, it means I don’t have to worry about funding for my next few games, which is great. Both Flower Garden and Casey’s Contraptions were done on a minimal budget. Now I can afford to spend more money in areas where it can make a difference, and be able to offer people money up front instead of just some percent of royalties.

One thing I never want to do is have full time employees though. Full time employees bring constant burn rate, and start adding a sense of pressure I do not want. One of the best things about being indie is the flexibility that it brings. Collaborations with other indies have worked really well so far, and I’ll continue to do that as much as possible for future projects.

The other way the deal has affected my future projects is that there will be more pressure to follow up Casey’s Contraptions with a great game. Even though Casey’s Contraptions is the same it was a few months ago, the fact that it was bought by Rovio will make a lot of people take notice and compare it to any of my future games.

I’ve already been struggling with those effects for several months. I’ve been making and discarding prototype after prototype. More than half of those would have made for fine games, but I have no desire to release a “just OK” game for the sake of releasing something. I’ve also decided that I’m not even going to consider potential for financial success for my next game. It’s not going to be aimed at the mass market, it’s not going to be full of zombies, and it’s certainly not going to be a typical freemium game.

Whatever my next game is, it’s going to be a more personal, more niche game. Something that I can be really excited about working for however many months it takes, and something I can be really proud of after launch.

Bye, bye Casey! We’ll miss you, but we can’t wait to see what you do out there!

Here are a few pictures from the new office. Things aren’t completely set up yet (that bare wall is waiting for some Flower Garden and Casey’s Contraptions posters that should be arriving today).

The thing I like the most about this office is the light. It’s a corner office and it’s aiming north, so that means great, indirect light all day long. Oh, and the windows can be opened to let some fresh air in. That might seem like an odd detail to mention to some of you, but you’d be surprised how many office buildings in the US have windows that can’t be opened. Really.

Both desks are adjustable, standing desks. The main desk in the pictures is the large frame GeekDesk one. I used to have the small frame because I didn’t have the room at home, but I love the extra space, especially with the 30″ display! I’ve kept the small desk to the side, that way I can invite other people to come work from here for the day (indie work day!) or even (gasp) hire someone if the right time comes.

The rest is pretty standard: whiteboard (I prefer use one much larger, but that’s what I had around), bouncy ball (gotta have a bouncy ball!), and couch (pretty important to unwind, or just to take a break from standing all day).

So far, I’m very happy with this setup. Working from here is definitely invigorating, and the separation between work and home helps a lot in both locations. Maybe once our daughter is older and going to school I’ll consider working from home again, but this is perfect for now.

What does your work setup look like? Post some pictures and let me know. I love seeing other devs work setups.

There were even a couple of cases during Casey’s Contraptions that we wanted a particular effect, and couldn’t get it quite right, but it would have been trivial to whip up a shader if we had been using OpenGL ES 2.0. In the end, we had to resort to texture combiners (yuck), and it wasn’t exactly what we had in mind.OpenGL ES 2.0 requires that you write shaders for any different kind of “thing” you render, whether it’s a simple 2D quad, or a fancy skinned character. I wanted to provide at least a basic 2D rendering shader in my graphics library, but the workflow was a bit awkward.

First of all, shaders on iOS are compiled at runtime [1], so we need to access the shader source and compile it. Initially I was thinking of having the shader source files as text in the graphics library, but for the game to access those files, it would have to explicitly add them to its resources so they can be copied during the build phase. That’s error prone (I would always forget to do that with every new project) and just plain ugly.

Another possibility would be to include the source text as a string in the library. That would simplify things, but it would mean that:

1. You would lose shader syntax highlighting.
2. You would need to have the annoying \ at the end of every line.

After asking on Twitter and getting some good suggestions, I decided the easiest way would be to use xxd. It’s a shell tool that comes preinstalled in all Macs (and Linux) that takes a file and converts it into a C array that can be included in a program directly.

I liked xxd even better than the old standby of bin2c because it already comes installed, and it generates the whole file, not just an array that then needs to be included from another file. Yes, it would be easy enough to modify, but why bother when you have a perfect tool for the job already?

Now, I can set up a custom rule in Xcode 4 like this:

Update: The array generated by xxd isn’t null-terminated, so we need to add a zero to the array. The easiest way is to use sed. Thanks to SixEcho Studios for the heads up. Also, I updated it to use the varaibles INPUT_FILE_DIR and INPUT_FILE_NAME thanks to Miguel’s comments.

Now, whenever the shader source changes, it generates a header file like this:

unsigned char PassThrough_fsh[] = {
  0x0a, 0x0a, 0x76, 0x61, 0x72, 0x79, 0x69, 0x6e, 0x67, 0x20, 0x6c, 0x6f,
  0x77, 0x70, 0x20, 0x76, 0x65, 0x63, 0x34, 0x20, 0x44, 0x65, 0x73, 0x74,
  0x69, 0x6e, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x43, 0x6f, 0x6c, 0x6f, 0x72,
  0x3b, 0x0a, 0x0a, 0x76, 0x6f, 0x69, 0x64, 0x20, 0x6d, 0x61, 0x69, 0x6e,
  0x28, 0x29, 0x0a, 0x7b, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x67, 0x6c, 0x5f,
  0x46, 0x72, 0x61, 0x67, 0x43, 0x6f, 0x6c, 0x6f, 0x72, 0x20, 0x3d, 0x20,
  0x44, 0x65, 0x73, 0x74, 0x69, 0x6e, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x43,
  0x6f, 0x6c, 0x6f, 0x72, 0x3b, 0x0a, 0x7d
,0x00};
unsigned int PassThrough_fsh_len = 91;

To compile that shader in the game, all I have to add is two lines:

#include 
//...
const int fs = ShaderUtils::CompileShader(PassThrough_fsh, GL_FRAGMENT_SHADER);

Done! Clean, simple, and minimal cruft.

Update: I haven’t tried it yet because I haven’t had the need for any expensive shaders, but I hear really good things about Aras Pranckevičius GLSL optimizer. In that case, I would add it before the xxd step. You would still use the shader the same way, but it would be optimized and perform faster.

[1] That’s a huge mistake and I hope Apple fixes that ASAP. Loading times for any amount of non-trivial shaders adds up really quickly. That’s the last thing you want on a mobile device! The OpenGL ES 2.0 standard provides an optional way to load binary shaders, and all that Apple has to do is provide a tool that will compile shaders for the iOS hardware. To be completely future-proof, you they can even mandate that if the binary load fails, you still need to compile from source.

Fortunately, display technology caught up over the years and I’ve been happy with the LCD monitors I have since then.

Until now.

I’ve been looking into large LCD monitors to set up in my new office with my Macbook Pro, and I find myself pushing into the limit of technology once again. The results: I went through 3 monitors of about $1K each. Two fell completely short, and one was perfect.

The Shiny: 27″ Apple Thunderbolt Display

The top contenders starting out were the 27″ Apple Thunderbolt Display, and the 27″ Dell U2711. I read reports that they both use the same display technology, and the differences between the two were relatively minor. After some conflicting reviews (that should have been the first warning), I decided to go with the Apple Display.

This display seemed perfect for me. It looks gorgeous, like an oversized iPad. The image quality is fantastic, with text being sharp and clear and having a great resolution. Since I’m only connecting a Macbook Pro to it, the connections are perfect: The Thunderbolt cable is great because it deals with display, USB, ethernet, and even audio in one fell swoop. The display also has a power cable for the Macbook Pro, so it’s like a perfect docking station.

It really was almost perfect. Almost.

The glare was simply horrible and I could see myself reflected on the screen, even with a white background. The shiny display was almost a perfect mirror. It might be the ideal display if you like to work in a dungeon, but I like light, the more the better. Even though my office has no direct sunlight, just the indirect light coming in was enough to see everything brightly reflected on it.

One possible way to work with the Apple Display

What’s worse, if one day I had to rearrange things or move to a different office and I had a window behind me, it would go from distracting to impossible to see anything.

Another annoying aspect of that monitor is that the stand height wasn’t adjustable. I like to look at a monitor straight while my arms are about a 90-100 degree angle, so the monitor ended up being several inches too low. I can do the old phone book trick, but it seemed ridiculous having to do that on such a beautiful display.

As much as I liked that display, it just wasn’t for me.

The Ugly: Dell U2711

In spite of some comments complaining about “over aggressive” anti-glare coating, I decided to give the Dell U2711 a try. I had used Dell monitors before and I was never bothered by the screen. And after all, the antiglare coating could fix the problem the Apple display had. Apart from the antiglare, it had some attractive options: Multi-card reader, several video inputs, and better color options. It could be the perfect screen.

It turns out it was far from that. It was the opposite of the Apple display in many ways. Connecting it to the Macbook Pro was a hassle since it shipped with a Displayport cable, but not a Mini Displayport one. I tried using my Mini Displayport to DVI adaptor, but it turns out it was single-link and you need a dual link to drive the full 2560 x 1440 resolution.

Once I finally got it up and running (with a Mini Displayport to Displayport cable), the resulting image was plain ugly. The colors were off, but more seriously, the antiglare coating really was horrible. It made the screen look like there was a fine coating of dust on it, or like it was film with a very obvious grain to it. I had to strain my eyes to focus on the text because the graininess kept throwing me off.

I suppose I could have gotten used to it, but since I use the Macbook Pro display next to it, going back and forth was torture. One moment I would see this clean, sharp, beautiful display, the next moment I would see this horrible grainy mess.

To make sure I wasn’t hallucinating, I took a picture of both displays with my iPhone displaying the same content. The differences are obvious (click on them to see them full size).

Macbook Pro with antiglare

Dell U2711

In case that wasn’t enough, the colors were severely off. I played around for an hour with the custom settings and some advice from the internet, but I just managed to make them a bit better. I still liked the colors on the Apple Display (or the Macbook Pro) way better.

The Good: 30″ Apple Cinema Display

At this point I thought I was out of luck, and that I was going to have to settle for either one of those two monitors (I would take the 27″ Apple one), or something smaller but without those problems.

Fortunately, several people on Twitter encouraged me to try out the 30″ Apple Cinema Display. I never saw paid attention to one, but apparently they had fantastic image quality and a good antiglare coating. That sounded promising!

One of the pleasures of being a small company is that once I decide to do something, I can do it right away. There’s no paperwork, approval, ordering through certain channels, or any of that overhead. Since Apple doesn’t make that display anymore, I hopped on Craigslist, called a guy up, and picked it up a few hours later. Done!

And boy was I glad I did! That monitor is everything that was cracked up to be and more! Since it’s an older display, it doesn’t have Mini Displayport cables, so I had to use a Mini Displayport to Dual DVI adaptor. The image quality is indeed, outstanding, and the colors are quite good (although maybe a touch redder than the laptop).

I actually love that it’s a 16:10 ratio instead of the more common 16:9 in most monitors today. That gives results in a resolution of 2560 x 1600, which gives me some much-needed vertical space when writing code (which is 80-90% of my day).

As a totally minor, but nice side effect, the brightness controls on the keyboard control the screen brightness (which is kind of surprising considering it’s connected over the dual DVI adaptor, but there’s also a USB cable going into the display, so maybe it’s communicating through that channel).

The only drawback is that the back only has two USB ports (I wish it had 4 or more). It does have two Firewire ports as well, although I don’t have any devices that use those.

For completeness sake, I took a picture of the new monitor with the same image I used as a test earlier. It shows how much cleaner the image is than the Dell.

30″ Apple Cinema Display

Conclusion

From left to right: The shiny, the ugly, and the good.

If you’re picky like me about the quality of your displays, and you’re looking for a large monitor, I can’t recommend the 30″ Apple Cinema Display enough. It’s a shame that Apple stopped manufacturing it, so check Cragislist or Ebay for it. If you work in a dark place, maybe the 27″ Thunderbolt one will work as well. Whatever you do, stay far, far away from the Dell one.

We can only hope that Apple will make a revision of the 27″ Thunderbolt Display soon with a high-quality antiglare coating like the laptops. In the meanwhile, I’m thankful both Apple and Dell have good return policies.

That future is a reality today for some games and apps (Netflix, Kindle), and I’m convinced that players will expect that in most games in the next year or so. So obviously, the next bit of new iOS tech I decided to try was iCloud. I would love to turn Flower Garden into that kind of seamless experience, independently of the device you use to access it.

As a quick spoiler, it turns out I won’t be able to make Flower Garden quite so seamless without a lot of extra work. But I learned a lot along the way and I should be able to take a small step in that direction.

Design considerations

iCloud promises to be the “available from everywhere” storage solution that will be a key component towards the scenario of playing on any device at any time. Unfortunately, it’s just a component of that whole scenario and still requires quite a bit of work on the part of the developer.

Since I’m just retrofitting Flower Garden to work with iCloud, I wanted a simple way to simply replicate the game state on iCloud. Then, whenever you play it from any device, you get the latest state and everything works as expected.

The big problem with that approach is that you can’t always count on having an active (or fast enough) internet connection. iPod Touches, iPads, or even iPhone in a plane or a cell tower black spot will make it so your device has no way to communicate with iCloud. So what happens if the player plays without an internet connection, then comes home, grabs another device, plays for a bit with internet connection, and finally launches the original device, this time with internet connection. You’ll end up with two conflicting game states. Not fun!

I can think of two different strategies to deal with this situation:

• Require internet connection to play. Some games do this today. It can be quite frustrating not being able to play your favorite game in the plane, but it does solve the game state conflict problem because they can always communicate with iCloud, so they usually provide seamless multi-device play.
• Detect changes on both game states and intelligently solve them. Sounds good in theory, but it’s a pain in practice. Unless you have a very simple game state (a percentage completion for example), it means not only do you have to record the state, but you have to record the events that led to that state, and be ready to examine them, compare them, and marge them in the case of a conflict. And the worst part is that even if you put lots of care into it, there will be cases where the merge is not ideal and the player will feel like he lost something in the merge.

For Flower Garden, neither solution is particularly attractive. It’s the proverbial rock and a hard place. So for the moment I’ve decided to implement just a small step in that direction: Sync things that only progress in one direction, without any danger of conflict. That includes purchased IAPs and unlocked seeds. Later on, once that’s working solidly without any problems, I can consider adding counts like Fertilizer, Color Dust, or Green Thumb points. That will be a bit trickier because there’s still chance for conflict since the count can go up and down, but it’s possible to change each amount into two different values that always go up: Earned amount, and spent amount. That way I can always grab the maximum value that I find either local or on iCloud and things should work smoothly. (Update: What I wrote there about separating them in two different values is totally wrong, and any DB programmer worth his salt would be laughing at that. Separating them in two different values won’t help at all. That’s what I get for doing brain-dump posts on the fly

Apple provides two APIs to store data in iCloud: key-value storage and file storage.

Key Value storage

Initially, this seems like a great way to go. It’s a very simple API, and it’s very familiar to most iOS programmers because it’s just like NSUserDefaults.

Don’t be fooled into thinking you need to store data in strings or one field at the time. You can stuff whatever binary chunk of data you want with NSData, so it’s quite versatile.

It does have three pretty big drawbacks thought:

• Size. You can only store up to 64KB of data. That’s definitely a big deal if you’re planning on storing large data files. Even for Flower Garden, each pot is about 30KB, so I wouldn’t be able to save the full garden state this way.
• Syncing. The Apple docs say that “Keys and values are transferred to and from iCloud at periodic intervals.” Ouch! What does that mean? Clearly this is intended for non-crucial data (like settings), so the potential delay isn’t a big deal. In my tests, I found that data was often not available when starting the app, but would become available a few seconds later.
• No way to check state. When starting the app, there’s no way to find out if the values you’re reading are up to date. Combined with the slow syncing, it makes it less than idea for important data. On the flip side, you can be notified when the data changes, but that means having to deal with changes while the game is running (which I was hoping not to do).

File storage

File storage might be a better option then since it doesn’t have any of those drawbacks: there’s no size limit, data is synced much more aggressively, and you can check if the data is up-to-date, and wait until it is otherwise.

What’s not to like about file storage then? The cumbersome and intrusive API that Apple created around it. If you read the docs, they make it sound like you need to inherit from UIDocument and load all your data through that class. I like to keep things simple and portable, so I’d really rather not introduce UIDocument into the file-loading process if I don’t have to.

It turns out that Apple’s docs on the iCloud SDK are quite sparse and lacking details. I was able to put together a demo from those docs and some experimentation, so hopefully this will be useful to other devs as well.

The device has an iCloud storage daemon running, monitoring specific directories for changes. You get the directory assigned to your app by calling URLForUbiquityContainerIdentifier.

To add a new file, the docs recommend first creating the file somewhere else, and then calling NSFileManager:setUbiquitous:itemAtURL:destinationURL:error: to move it to iCloud. Interestingly, I accidentally skipped this step and just wrote to the iCloud directory directly, and the files were stored correctly anyway. Might as well leave it just in case that behavior changes later on, or there’s some side effect I didn’t notice.

After that, every time you write to the file, the iCloud daemon will detect the changes and push them out to iCloud. This is an important point because a) You don’t have explicit control to say “start send it now” or even “This file is ready to be sent to iCloud” (that would be my choice), and b) I don’t know what it does with partial updates, so I would be very careful about writing to those files and make sure it’s an atomic operation (save somewhere else, and them move the file in one operation).

To get the latest version of the files on iCloud, you can check whether they’re fully downloaded or not by calling NSURL:getResourceValue:&isDownloaded forKey:NSURLUbiquitousItemIsDownloadedKey error:. If they are up to date, you can move on, otherwise, you can initiate a download of the files by calling NSFileManager:startDownloadingUbiquitousItemAtURL:error:.

One weird thing is that the startDownloading function doesn’t have a callback (that I can see). So I had to set up a timer to check periodically if the files are synced.

Since all the syncing happens at startup, there’s no complexity involved with data changing while the app is running. If that’s a case you need to handle, you might be better off using UIDocument since it at least detects conflicts. If you do it this way, the latest one will overwrite any past changes.

Also, working this way, it seemed easier to keep the files in Application Support (or Documents), and only move them to/from iCloud when I wanted to. That has the advantage of iCloud not changing things from under you while the game is running, and the fact that, if for some reason the files in iCloud are corrupt, you always have good local files to fall back to.

Demo

iCloudTest.zip

The demo iCloudTest saves data both with the key value pair, and the file storage system directly like I described above. If you run it from different devices, you’ll see that it’s amazing how quickly file data gets propagated, but key-value data takes a few more seconds.

The demo project also works in the simulator (there’s no iCloud support, so it just uses local files), and it even works with iOS4 (also using local files, and it avoids using any iOS5 symbols while detecting iCloud support).

Sharing Data Between Multiple Apps

Once you’re at this point, sharing data between multiple apps is really straightforward.

First you need to make sure the app IDs of both apps start with the seam Team ID. For some unknown reason lost in the midsts of time, Flower Garden and Flower Garden Free use different prefixes, so that option is out for me. Hopefully most people having been using the Team ID only.

Then you need to decide which type of data you want to share. If you want to share files, you need to add the app ID of the other app to your iCloud entitlement, and then as for the correct app ID (including prefix!) when you call URLForUbiquityContainerIdentifier. If you just want the app’s own iCloud data, you can pass NULL as the parameter.

As far as I can tell, each application can only have one set of key-value data. So sharing it between two apps means changing one app to use the app ID of the other app in the com.snappytouch.icloudtest field of the iCloud entitlements file. As long as both apps use the same Team ID prefix, it should work fine without having to do anything else.

One of the first features I looked into adding was multisample antialiasing (MSAA) support for OpenGL, which was originally introduced in iOS 4.0. The geometry generated for the petals in Flower Garden is fairly high contrast, and since it’s not like the textures were carefully created and laid out by an artist, the result is pretty bad aliasing around the edges. Perfect candidate for multisampling!I based everything on the Apple documentation on multisampling. It was very straightforward and it works for both off-screen and view-based render targets. It was also extremely helpful to keep both the ability to use regular and multisampled render targets. That way I can easily run performance and visual comparisons, and, if necessary, I can disable multisampling on a particular device.

The main gotcha was making sure I used the GL_RGBA8_OES color format on the multisampling color buffer (otherwise it won’t work, and all you’ll get are 1282 “invalid operation” OpenGL errors). Also, if you’re in the same boat as Flower Garden, which uses OpenGL ES 1.1 and the fixed function pipeline, you’ll have to add _OES to just about every constant in the documentation.

Visual results

I will let the screenshots speak for themselves.

In this screenshot you can see the rendering of the pots using off-screen render targets.

Pretty impressive improvement, even if I say so myself! The improvement is even more striking in-game because the animation of the flowers moving in the wind doesn’t have jaggies popping in and out.

The improvements are more noticeable on the iPad because the pixels are bigger, and, not surprisingly, less so on retina-display iPhones. But even on the retina displays, jaggies are less noticeable during the flower wind-swaying animations.

Performance

So, no doubt: They look pretty. But how about performance? Under the hood, the rasterizer is generating four samples for every pixel, and then combining them at the end in a separate step. So you’ll get more of a performance hit with complex pixel shaders. Edit: My bad. I spaced out and I forgot that MSAA only evaluates the pixel shader once, so performance doesn’t depend on pixel shader complexity. Instead, the performance hit probably comes from the extra writes (four per pixel) to the render target, and should be fairly similar between games.

It turns out that Flower Garden is still using OpenGL ES 1.1, which is implemented using shaders at the driver level. Fortunately, even though I’m using some texture combiner operations and several input textures, those pixel shaders aren’t all that complex.

These are the frames per second I recorded with one particular flower pot on the different devices I have for testing. Notice that the lowest device I have listed is the iPhone 3GS. That’s because I have also stopped supporting arm6 CPUs to keep things simpler (and the market share is minimal).

Update: I was only running the game loop at 30 fps, so the initial performance numbers I had listed are pretty meaningless. Here are the correct numbers running at a max of 60 fps.

Of the devices I tested, MSAA didn’t slow down things much on the iPhone 3GS, and the iPhone 4S was maxed out at 60 fps both ways. The iPad 1 was a different story, and performance crashed from 60 fps to 18 fps. Like Rory pointed in the comments, looking at the actual time instead of the fps gives a better insight. Using MSAA adds 38.9 ms to each frame! The iPhone 4 also suffered from a big performance hit due to all the extra pixels in the retina display. I don’t care how pretty the flowers are, that’s just not acceptable (and no, I’m not adding user-tweakable graphics settings like PC games).

I should also add that Flower Garden is hugely CPU bound. It generates all that geometry every frame on the CPU, and that’s a lot of vector transforms. So if your game is GPU bound, you’re likely to see higher performance hits.

I was initially very surprised to see that the performance on the simulator tanked big time (as in, going from 30 fps to 5 fps). This was news to me, but apparently the iOS simulator runs completely in software, so the quadrupling of pixels brings it to its knees. I’m really, really, impressed at how smoothly it usually runs for being in software though. It had me fooled thinking it was using OpenGL under the hood!

As far as memory goes, after an animated discussion on Twitter, it seems that the iPhone does create full buffers for the multisample frame buffers, so there is a significant increase in memory usage. It’s not something easy to track because it all happens at the driver level, but it’s something to be aware of. Because of this, I might consider turning multisampling off on retina displays, since the improvement is not mind-blowing (and the extra memory is very significant because of the amount of pixels). I’ll also probably turn it off in the simulator so I can achieve a decent frame rate during development.

Conclusions

Multisampling only required adding a few lines of code and resulted in an impressive visual improvement and minimal performance impact in some devices. It’s a no-brainer on the 3GS and iPad 2. I’m wishing I had implemented it earlier!

Then along comes the iOS5 SDK and someone decided that it would be good to “fix” that behavior, but doing it silently. By silently I mean no compile-time errors or warnings, but apparently it wasn’t deemed worthy of including in the iOS5 release notes either. I’m sure they thought they were doing us a favor. After all, if someone had a problem with it, it’s because they hadn’t structured their code correctly.

So now every view you add/remove will get those notifications. Which is fine, except if you had decided to call those by hand yourself. In that case, now they get executed twice, so you may be allocating things twice, making multiple network calls, and just causing general mayhem.

I also noticed that if you call presentModalViewController with a view controller, all the views underneath the modal view controller will get the viewWillDisappear/viewDidDisappear event. In my case this causes total chaos because those events trigger the freeing of some views that the modal view controller will need.

But wait, it gets even better! From what I’ve been able to tell, if your app compiled with the iOS5 SDK runs on iOS4, then you don’t get those events! That means that now you need to be ready to both deal with receiving them and not receiving them at the same time. Is that useful to anyone (other than devs making iOS5+ apps)?

Fortunately, existing apps compiled with the iOS4 SDK are consistent running both on iOS4 and iOS5 (no view events automatically generated). Phew! Dodged that bullet.

It seems I complain a lot lately, but this seems like another very justified complaint. Wasn’t there a way for Apple to add that behavior to new functions without changing the old ones? For example, they could have introduced UIView:addSubview:withNotifications: and eventually deprecated the old ones. Yes, that means that they would have had to duplicate 10-20 functions related to adding/removing views, but they wouldn’t have broken half the iOS code out there.

This is probably my fault for relying on viewDidAppear events and calling them myself. I started working around this problem by being super-careful about how and when I call viewDidAppear, but as soon as I realized that iOS4 does it differently, I threw in the towel and went for a different approach. Now, I just implement my own function in the different view controllers and call that instead of viewDidAppear. That way Apple can change those events all they want and it won’t affect me anymore.

Of course, all of this only matters if you’re making heavy use of view controllers (which unfortunately I am doing in Flower Garden). I’ve already said that my future game projects are going to be UIKit-free, so I won’t have to deal with this kind of problems again.

Brewing

A new game for me starts as an idea somewhere, sometime, that got jotted down into my “game ideas” personal wiki page. I have that page accessible 24 hours a day on my computer, iPhone, or iPad. Only while I’m running/cycling or in the shower am I away from that page (and unfortunately, that’s the time when most ideas seem to spark). I make a point of not censoring any ideas: If I thought that something would be neat (not just gameplay, but a setting, a visual, a mechanic, or anything), I jot it down.

Over time, I accumulate quite a few ideas. Every so often I review them and I might expand on some and flesh out sub-ideas. Or they might spark different ideas of their own and I jot them down too. I never delete any of them, because I’m consciously trying to not censor anything yet. This is purely brainstorming mode. I’ve even sent emails to friends about possible game ideas straight out of this list, crappy ideas and all.

During this time I’ll rearrange the list. I’ll move more likely ideas up, or ones that I’m more excited about. That has the effect of a kind of bubble sort, so the better ideas somehow rise to the top (except for the brilliant ones hidden in the depths somewhere).

This list is particularly useful when I’m in the middle of a project and I have what seem brilliant game ideas. Do I put the project aside to do this great idea instead? No. Instead, I add it to the list with all the others. If I’m really excited about it, I’ll flesh it out as much as I can, but it needs to wait its turn. As you can imagine, after a few days, the idea doesn’t seem so shiny anymore, so it was a good thing it didn’t derail the current project.

Struggling

Eventually the time comes when I need to pick a new project, and this is where the fun and the pain start.

You would think a good approach might be to read the list and start evaluating ideas. In a way, that’s what I do, but before I evaluate ideas, I need to some frame of reference to decide what’s a worthwhile idea and what isn’t.

In the past my criteria for considering a project involved the intersection of three requirements:

• The game must be interesting for me to work on. I want to learn something new and be excited about what I do. Not interested in cloning something or making a derivative game.
• A game I can realistically implement with the resources at my disposal. I’m not an artist, so that usually means not having a content-heavy game, and relying on code as much as possible (like the procedural geometry in Flower Garden–no artist modeled those flowers by hand).
• A game that has potential to sell well on the target platforms.

Unfortunately, meeting all those three requirements at the same time isn’t easy, especially given the astounding number of games already on iOS.

Before I go any further, I need to step back and ask myself a very important question: Why do I want to make this next game? This is a question we indies have the luxury of asking (and answering). I think most big (and small) studios are too busy staying afloat to be able to ask anything like that (besides, the answer is almost always “make more money” for them).

It turns out the indie life is treating me very well, so making lots money isn’t one of the main reasons to make this next game. That means I can safely remove that requirement from my previous list, which grants me a lot more freedom.

I’m probably going to spend the next 6 to 10 months working on this project, so it needs to be worthwhile. Does it need to be innovative and break new ground in a way no one has seen before? Does it need to make hard-core FPS players cry to be worth considering? Does it need to be radical, pixelated, mash up 5 different genres, an win the IGF and respect of my peers?

It turns out none of those are the reasons that drive me to make games. In the end, when I look deep down, the reason I want to make games is for the pleasure of taking a vision from the initial idea to something people can play. It’s the creativity involved that drives me. I imagine it’s the same reason people are driven to write or paint. If along the way, some of those games manage to be innovative, make money, or win an IGF award, that’d be fantastic, but in any case, the development process is its own reward.

Given all those factors, I can go down the list of games and evaluate each one. Does it have potential to meet those requirements and be a satisfying project? This might not come as a surprise for those of you involved in creative activities, but this is hands-down, the most difficult time of development for me. As long as I don’t have a project picked, my mind is constantly going over this. Anything I read, see, or hear is filtered and analyzed thinking of how it would fit in a game. During this time I’m often moody, volatile, and prone to depression if this goes on for too long.

Even though it seems I’ll never going to be able to come up with an idea worth doing, eventually something comes along, and the next phase starts.

Prototyping

I’ve already talked about prototyping at length before. I take the idea I’m considering and I try to answer the key questions in the shortest possible time. This is the time to shoot down any bad ideas, or prove why they’re not feasible or just boring.

The prototyping phase is a big high for me. It often involves manic activity and I can get a prototype done in a day or two from the initial excitement on the idea. The bad part is that most prototypes prove not to be that great, and they go back to the drawer of game ideas, and I’m left scrambling for another idea.

Struggle. Prototype. Discard. Repeat.

I usually repeat this cycle multiple times. Each time around I get more anxious, and the lows and highs are a bit more extreme.

Fortunately, at least so far, eventually I find a prototype that seems worth doing. Something I can see spending the next X months of my life doing. I usually run it by a few friends whose opinion I value highly, and if they’re excited about it too, then it becomes an internal green light and I move on to the implementation phase.

Tips

Apart from asking yourself why your making a game, here are a couple of things worth keeping in mind when picking a new project. They’re not new things and I’ve heard them before in one form or another, but they’re worth reiterating:

• Don’t compete with big companies. They can throw a lot more resources, and, most importantly, lots of marketing behind their titles. Don’t try to take Zynga head on. Do your own thing.
• Don’t chase trends. Take risks. Be different. You’re indie and have low overheard. Take advantage of that and do things the big boys would never dare risk $50 million on.
• Keep the scope of the project small and focused. It will be bigger than you envision anyway. By being small, you can come up with new ideas faster than big companies.

How about you? What’s your process for deciding to work on something? Do you struggle until you pick the project? Do you stick with an idea, or do you change and restart?

I was having a discussion today about free games with other developers and I thought I would post here some random thoughts and open it up for discussion.Free-to-play (or freemium–even if they aren’t exactly the same, I’m bundling them all under the same category for this discussion), have have a fairly bad reputation, and they’ve been under fire recently from developers. It’s true that a lot of those games have been rather poor from a game design point of view, while raking in loads of money from players who are apparently happy to play them.

It’s important to separate the financial model (free with other ways for players to spend money in-game), and the quality of those early games or the intentions behind them. I am convinced that free games is the future of mass-market games (it’s already pretty much the present, so that’s not much of a stretch).

There’s no doubt that the financial model of game affects its design. Compare arcade games, retail console games, and subscription-based games just as an example. Free-to-play has a huge impact on the design as well.

Free-to-play games are in their infancy. Not only are they a relatively recent happening, but they were also wildly successful, which encouraged a lot of copying and not much innovation. So they’re stuck in a type of design that results in a local maximum of profit, while providing a not very satisfying experience for a lot of players. As game developers, we need to find out how to make great games while using the free-to-play model.

I’ve been going around this quite a bit recently, because I’m in the stages of deciding what my next game is going to be. The reality of the App Store are pushing me towards free-to-play, but I’m not interested in making a Farm/Store/Pet game.

These are my random thoughts on what we can charge for in a free game and how it affects game design:

• Reduce delays. This is very effective, but feels cheap and somewhat manipulative (yes, this is coming from the guy who did Flower Garden… but that was before IAPs and the whole point of the game was the nurturing/waiting part). It also falls in the category of the question I often ask myself: If I remove this from the game, will it be better or worse? The answer is (almost) always “better” by removing those delays.
• In-game currency. This is seems like a better approach as long as there’s no competitive multiplayer. However, it does wreck havoc with the game balance. Either it becomes too easy and not fun for those who paid, or boring and grindy for those who didn’t. Still, especially on mobile, it’s not a totally bad way to go. You’re letting people make a choice how they want their experience.
• Extra content. That seems to be the traditional, developer-approved way to go. PC and console games have been doing that with DLCs for a long time. The main problem is that not many players want that content, the amount of content you can sell is limited, and it often requires a lot of extra effort to generate.
• Extra choices. This includes different characters, clothes, weapons, etc. I see this as the sweet spot between the last two options. What you buy doesn’t completely throw off the game curve, but it’s also not just new levels or missions. Combine that with letting players earn credits to get those choices (by grinding if they want to, but it’s all optional) and it seems like a good way to go. You can also go the way of League of Legends (which I have yet to play!) and you can rotate in that extra content for limited amounts of time, so players get a taste and they have the option of buying them permanently.
• Cheats. By cheats I mean more lives, rewind/replay, invulnerability, etc. It feels like a throwback to the arcade days. Some players will be put off by it (either by the fact it exists, or by the fact that they finished the game too quickly with the help of those cheats), but it can work in the right game. You’d probably want to do something about high scores, like putting players who used those cheats in a different leaderboard.

What are your thoughts on this? What are some other ways that players can pay for in free games and still allows us to make a great game?

Each pot is a UIButton with a custom image (rendered from OpenGL into an off-screen target). So when I enter edit mode, I need to wobble them like the launchboard. Easier said than done.

I searched online and asked on Twitter, but surprisingly, nobody had done a perfect, reverse-engineering of the wobble movement. Most mentions just do a z rotation on a sine wave, which is not that close of the launchboard animation.

I found that to get closer to the real thing, you need to do that rotation around a random point offset from the center. That’s better, but it’s still not perfect. There’s an additional extra twitch in the original Apple animation. I’d love it if someone already reverse-engineered it and has a better model for that animation.

In the meanwhile, I figured I would share the core I’m using. It’s all very straightforward, except for the part about rotating a UIView around a different point other than the center. I initially thought I could just concatenate transforms, but no matter how you do it, UIKit always interprets the transform around the center.

To be more precise, it interprets the rotation around the anchor point, and that’s what you need to modify. The anchor point is defined in units that are a percentage of the layer’s size, so by default it’s 0.5, 0.5. When you move the anchor point, the layer itself will move, so you need to fix it up by moving the layer’s position by the same amount in the opposite direction.

This is what the final code looks like:

void StartPotWobble(UIButton* button, Random& random)
{
	const Range posOffset(0.10f, 0.2f);
	const float amplitude = random.GetFloat(1,1.5f);
	const Vec2 startCenter(Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset), Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset));
	const Vec2 endCenter(Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset), Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset));

	CGPoint center = button.center;	
	button.layer.anchorPoint = CGPointMake(0.5f + startCenter.x, 0.5f + startCenter.y);
	CGRect bounds = button.bounds;
	button.layer.position = CGPointMake(button.layer.position.x + bounds.size.width*startCenter.x, 
									button.layer.position.y + bounds.size.height*startCenter.y);
	button.transform = CGAffineTransformMakeRotation(-amplitude*DegToRad);
		
	[UIView beginAnimations:nil context:NULL];
	[UIView setAnimationRepeatAutoreverses:YES];
	[UIView setAnimationRepeatCount:FLT_MAX];
	[UIView setAnimationDuration:0.12];
	[UIView setAnimationDelay:random.GetFloat(0,0.09f)];
		button.transform = CGAffineTransformMakeRotation(+amplitude*DegToRad);
	[UIView commitAnimations];
}
	
	
void StopPotWobble(UIButton* button)
{
	[button cancelAllAnimationsRecursively];
	button.transform = CGAffineTransformIdentity;
	CGPoint anchor = button.layer.anchorPoint;
	CGPoint offset = CGPointMake((0.5f - anchor.x)*button.width, (0.5f - anchor.y)*button.height);
	button.layer.anchorPoint = CGPointMake(0.5f, 0.5f);
	button.layer.position = CGPointMake(button.layer.position.x + offset.x, button.layer.position.y + offset.y);
}

Ah yes, and I couldn’t find a way to loop the animation infinitely (without using the new UIView animation syntax), so FLT_MAX will have to do Any cleaner way?

If someone has an animation that more closely resembles the iPhone launchboard, I’d love to hear about it. Let me know and I’ll update this post.

Contrary to popular belief, I’m not that picky when it comes to a development environment. Or at least, it doesn’t feel that way to me. I want the basics, that’s all. Doesn’t everybody want this?

• Have 2-3 source code windows opened side by side.
• Build and see the output.
• Do everything with keyboard shortcuts.

There are lots of other things I want (project configuration, debugging, run tests), but those are the ones I’m doing 99% of the time. I never had a problem doing any of those things with past development environments.

The hit list

Having more tools and options is great. I love having the option to do advanced operations on my code, but I want to decide when to use those tools, not being bombarded by them. That, in a single sentence, is why Xcode 4, out of the box, is completely unusable for me.

Attempting to do something as simple as type code and build it is extremely frustrating. Xcode will react to me doing that by flashing all sorts of stuff on screen, bring up sidebars with messages, change which source files are displayed, draw squiggles all over my code, and flash alerts overlays. All of that, while not showing me the build output.

Working on Xcode is an extremely noisy (visually) and distracting experience. I understand it’s trying help me, but it’s failing miserably at it. I’m trying to concentrate on what the code does, and I feel I have a parrot yelling stuff from my shoulder and flapping in front of the screen in some misguided attempt to help me code better.

That might work for some people, but not for me. I’m the guy who turns off “spell check as I type” everywhere because I don’t want to be taken out of flow while I’m typing (I’ll do a spell checking pass later on, thank you). I don’t have notifications on my mail or Twitter; I check them explicitly when I want to. Now take that kind of annoyances and multiply it times 10 and you start getting an idea of what working on Xcode 4 is like. Xcode 4 feels like it’s squarely designed for the texting/ADD generation.

Fortunately, most of it can be remedied and turned into a half-way sane environment.

Here’s how to tame the noise in Xcode 4:

• Autocomplete is one of the worst offenders. Turn it off! Good autocomplete is awesome, but I’d rather ask for it (with a keystroke) than have it bombard me constantly. Not just that, but it’s so badly implemented that it will a) put shadows on top of the text I’m typing b) replace the text I’m typing on the fly so I can’t even see what I typed (see screenshot below). Off with it!



• Having the whole screen flash with squiggles on and off while I’m typing isn’t helping in any way. Xcode is trying to “highlight instances of selected symbol”, which is a really useful tool, but not while I’m typing/thinking! Not just that, but half the time it will add extra squiggles to the screen to make sure I can’t even read the symbols themselves. So off with that one too.

  

  Here’s one very frustrating thing: When I turn off the option to automatically highlight instances of the selected symbol from the settings, I lose the ability to do that at all. Yes, you heard that right: I can’t (as far as I can tell) press a key and have the IDE highlight all the instances on demand. No sir, that’s not the way it was intended.

• Continuing with the theme of noise and distractions, having a sidebar popup and start showing me errors with my code as I’m typing is also definitely NOT helping. Fortunately we can turn off “Show live issues” in the general settings.
• One thing that Xcode 4 appeared to have gotten right is the idea of showing multiple source files at the same time. Now many IDEs do that by default these days, so that was a plus. Unfortunately, it’s part of the “smart” assistant. As a general rule, I end up turning off anything with the word “smart” in it, and this is no exception. The assistant tries to present “relevant” files to the one I’m working on. No, no, no, no! *I* want to decide what to display and what to work on. Just get out of the way and let me do that easily. You can turn off the view to “Manual”, which helps a huge amount.

Just those changes make Xcode 4 into something that at least I can type into and not get sick at my stomach. We’re making progress.

Now I can finally build and… everything goes wrong. Xcode doesn’t show me the build output and it decides to flash a “build completed” screen overlay in case I looked away in the two seconds it took to build. Seriously? Maybe my attention was drawn into some of the flashing squiggles and I forgot it was building.

Fortunately for my sanity, it’s possible to fix both those things. The alert is easy: Go to behaviors, “Build succeeds” and turn off “Show bezel alert” (make sure it’s off for all the others while you’re there).

The other one is a bit trickier, but it’s certainly possible. Set up the “Build starts” behavior to open a named tab and go to the current log. Like this:

Now when you build your project, you’ll get to see something sane like this. It might initially be as a tab, but you can drag that out and make it into a separate window of its own so it doesn’t obscure the source code window:

You should be able to navigate through any issues found during the build with Cmd + ‘, or, if you like the fancy issue display, press Cmd + 4. Things are so much better when you initiate them on demand rather than when they’re forced on you!

Finally, a couple minor UI annoyances that are easily fixed:

• The toolbar is positively huge. I feel crammed in the high-res 15″ MBP (1680 x 1050), so I can’t imagine how anyone works with something smaller. In any case, hiding the toolbar helps tremendously. As a bonus, the setting is per window, so your source code windows get the extra real estate, but the build output window keeps the toolbar so you have easy access to changing the target platform.
• Line wrap is on by default. Seriously? Off.

The suck list

If that was everything, I’d be happy. It means that even though Xcode 4 ships with retarded defaults, it can be whipped into shape into something usable. Unfortunately, there are a two major things I haven’t found a workaround for:

• Can’t build a single file. Someone at Apple, in their infinite wisdom, decided that building a single file was obsolete with the awesome new feature of “show live features”. Except that “show live features” sucks and has to be turned off. Apparently you either take it their way, or the highway, because there isn’t an alternative. As with the case of highlighting symbol instances, there isn’t a command I can use to “show live features” on demand.

  The alternative is doing a full build. Most of the time that’s fine, but whenever you’re doing one of those refactorings that breaks half the codebase, then you’re really screwed. The only way I can stay focused in a case like that is by cleaning up one file at the time, but this makes it impossible as you keep getting errors from all over the codebase. And as you fix one, the first error in the next build might be in a different file. Very annoying to say the least, especially because this was working and they removed it on purpose. I never file radar bugs (long story), but I made an exception just for this.

• Build configurations and schemes. Did you notice that when you built the project earlier there was no option to choose debug vs. release or some other configuration? That’s another one of those decisions that make you wonder if Apple uses Xcode to manage their own projects (and if they do, what kind of developers or projects they have).

  They turned something simple like project configurations that nobody ever complained about, into something byzantine worthy of some of the best efforts from Redmond. This gets the award for “most complicated feature nobody needed or wanted”. It seems now we have an extra layer of indirection. So you act on a scheme, which then decides which configuration to build and what to do. That’s why there are “Build for analysis” (debug), “Build for running” (release), “Build for testing” (WTF?), “Build for archiving” (distribution?).

  After spending some time with it, I’m still confused how I would go about running the release configuration, or how to mass-edit all the schemes at once (every target seems to get a different scheme).

  The whole schemes thing leaves me completely speechless, and that vein on the side of my forehead is pulsating just from thinking about it, so let’s just move on.

The good

After you take the time to fix Xcode 4 into something usable, and (somehow) put up with the new broken features, is there something to like?

I had to dig deep, but I found a couple of things that I like better than Xcode 3:

• Much better project settings UI: Multiple panes, showing multiple values for different configurations, etc. Way better than Xcode 3.
• Better semantic analysis. During the build process, Xcode 4 was able to correctly flag some problems in my code that Xcode 3 never warned me about. Mostly to do with constness of parent-scope variable when using blocks.
• Better keyboard shortcut support for opening files in different windows (assistant pressing the Option key). I never found a way to open a file in a specific window in Xcode 3 without having to use the mouse.

And that’s pretty much the whole good list that I was able to find

Conclusion

Xcode has been progressively evolving from version 1 until version 3.2. I have no doubt that’s the reason for some of the quirks in the later versions. Xcode 4 seems to be a total re-design and re-implementation, and suffers from the classic second system effect. It’s change for the sake of change, most of the time scrapping useful features and not offering useful alternatives.

I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it. I didn’t look very closely at the debugger or the Interface Builder (saving those for another day). I keep hearing about developers with stability problems with Xcode, although I didn’t run into any crashes (but I hardly did any real work with it).

Overall, my recommendation is that, if you’re comfortably working on Xcode 3, stay as far as possible from Xcode 4. We’ll all be forced to move there sooner or later, but in the meanwhile you can continue being productive. Maybe by the time they discontinue Xcode 3, Xcode 4 will have improved a bit.

These are mostly quick notes to myself so I remember what to change when I upgrade my main machine, but I thought other developers hesitant to upgrade to Lion might find it useful as well.

Things that had to go

I found Snow Leopard (and Leopard before it) to be very palatable out of the box. I don’t remember any things I absolutely had to do. Lion, however, had some questionable defaults. Or at least, ones that I just can’t take.

After making these changes, Lion was quite usable:

• Turn off “natural” scroll direction. The fact that before you can run Lion for the first time it forces you to scroll that way should be a tip off that people aren’t ready for this one yet. Maybe in a few years it will make sense to have it as the default, but now it’s just against every single computer out there (including most Macs).

• Autocorrect. This is not an iPhone. It *has* a perfectly fine keyboard. Thank you.

• Setting up Spaces. Oh, excuse me, Mission Control (sigh). This is the one I was really afraid of. I absolutely rely on having about 8 spaces (2 monitors in each) open at all times and swapping with a keystroke. That’s something that I’ve been using for many years (first in Linux, then hacked onto Windows XP, and finally in Leopard/Snow Leopard). I just absolutely have to have that.

  Update: There are still a couple annoying things with the new setup. You can’t see the number of the desktop you’re currently on, like you did with earlier versions of OS X. Daniel Collin pointed me to an interesting thread on StackOverflow where people are discussing how to get access to desktop numbers. Give it a few more weeks. Also, when you restart the computer, Lion is smart enough to restore all the apps to their last state… except that they’re all opened in the first desktop, not in the one they were when the system restarted. How difficult would that have been? Here’s hoping it’s fixed in a patchupdate soon.

  The good news is that it’s possible to set up Lion that way. The bad news is that by default, it’s quite far from that. Bring up Mission Control and create by hand as many desktops as you want. Then go to System Settings | Keyboard | Keyboard Shortcuts and turn on one for each desktop. And for the love of god, please go to Mission Control settings and turn off “Automatically rearrange spaces based on most recent use”. Clearly Apple doesn’t think people want to go to a space directly, and instead prefer to browse them one at the time.

The next few changes just made my experience better, but they’re not absolutely musts:

• This might sound dumb, but Finder didn’t have a good way to easily browse my files. Instead, it has this weird “All My Files” view that jumbles together all your junk there. I have no idea who thought that was a good idea. Maybe Apple is trying to wean users from browsing around the file system. In any case, you can drag your home directory to the sidebar in Finder and that makes it much easier to browse. While you’re at it, turn off the “Hide extensions in files” dumb setting.

• Having used a Mac for several years, I’m much more sensitive to ugly UI elements. That’s why it’s so weird that, by default, Lion has the sidebar font in all programs just very slightly larger than the regular system font. Fortunately I wasn’t the only one bothered by that and it’s an easy fix.

That’s about it. Lion is not very nice and usable (i.e. looks like Snow Leopard). You have that weird “full screen” button on the top right of all windows, but that’s much better ignored (which funny that, was the feature Apple really pushed in their PR for Lion). I have no idea why anyone would want to use that other than the usual word processor that blocks out everything else. If I want to have crippled multitasking, I’ll just use the iPad.

Good things about Lion

So far, if all I’m going to do is disable new features so it looks like Snow Leopard, is there there any reason to upgrade to Lion? I surprised myself, but the answer is yes (although they’re all very, very minor).

• Resize a window in any corner and cursor feedback (finally, only 20 years late to the party).
• Perfect contact and calendar syncing with Google. I can’t tell you how much I appreciate that. I use Google as the backend for all my mail, calendar, and contacts. With Snow Leopard you could sync them, but you had to do some digging and mess around with the sync program. With Lion it works out of the box. Totally awesome. That alone makes it worth the upgrade.
• Much improved Mail UI: Better layout, better shortcuts, better conversation view, and, my favorite by far, finally an Archive command for Gmail. Archive doesn’t exactly do the same as archiving in Gmail, but it’s close enough. Finally I can have two different keyboard shortcuts: One for trashing an email and another one for archiving it.
• The jury is still out on how Lion restores the application state when you launch an app. I’ve been pleasantly surprised a couple of times, and annoyed a couple other times that I had to close a bunch of useless tabs. Maybe there’s a shortcut like Shift + Cmd + Q that quits and app without saving state? That’d be handy (OK, that one is not it Oh wow, it’s Option + Cmd + Q! I love it when something makes sense like that and you can guess it. OK, so that makes this feature very cool.
• Slightly improved Safari (better download management). I really don’t see a reason to use Firefox or Chrome when you can use the preinstalled Safari. But then again, I can’t stand web UIs and I use native clients for lots of things.

Must-have apps

It’s actually quite refreshing to use the bare minimum number of extra apps beyond what comes with the OS. But there are some apps I just have to have in order to do anything. The main two are 1Password and Alfred. I can’t recommend them highly enough. They completely change how I work and make me ten times as productive (you’ve probably noticed by now that I’m not a mouse person).

After those two awesome super-apps, is the second tear of very useful ones: JustNotes, Things, and TextWrangler.

Probably Dropbox should be there somewhere, but for some reason, I still haven’t felt the need to use it heavily. I know some people put almost everything on Dropbox and can use across computers. Maybe it’s because I only have one that I haven’t felt the need for it too much. 1Password and Things both sync from the iPhone so it was really handy restoring all my data. I probably could have done the same thing with Dropbox.

Tomorrow I’ll post similar quick notes about Xcode 4. Those might not be quite as positive though.