Casey’s Contraptions Weekly Update (Jan 7)

So much for “weekly” updates. Last time I wrote one was Oct 29. Oops! That’s what happens when I get really busy and then the holidays hit. But now that’s over (the holiday part at least), so I’ll write to write more frequent updates.

This Week

This week Miguel and I are wrapping up our current iteration with the main focus of the first five minutes of gameplay. The reason we’re doing this now is that we spent quite a bit of time on the user interaction experience and we tried to nail that before adding more items and more levels. All along, we’ve been testing the game with unsuspecting victims and we quietly watched over their shoulders as they fumbled with the game without any instructions or tutorials.

I really believe we made huge improvements. We designed the whole game with touch interface from the ground up, and it really shows. I think it’s a very direct and intuitive interface, but even so, there’s only so much you can do without any instructions.

So, the focus of this last iteration is to concentrate on what a new player will see in the first five minutes of gameplay. That way, we can continue testing the game on new players and get a much better feel for how they learn to interact with the game and what works and what doesn’t.

Iterations

For every iteration (roughly about 2 weeks each) we focus on one main area, based on what we feel needs to be addressed the most at that point. To give you an idea, these have been the focus of some of the past iterations:

Proof-of-concept prototype
New, non-physical items
Game screen flow and level progression
Final user interaction
New items and locations

One thing that we’ve been doing is trying to take each goal to completion. This is an idea from Scrum and Agile development that I really like. If you implement an idea to the 90% state, apart from the fact that the remaining 10% is going to take another 90% of the time, you probably don’t have a good idea how it will really be once it’s completed. That makes future planning and re-prioritizing more difficult.

Obviously there’s such a thing as going overboard. Trying to get every single, tiny effect and animation to fully complete before moving on would be crippling. I try to think about the impact that feature, even if it’s very small, will have in the final game. The exact effect when you pick up a star isn’t crucial (assuming you have some sounds and some effects already), but the animations for the item selection and manipulation contribute a lot more to the feel of the game, so they’re more important.

In some of my past projects I took a different approach and built the game bottom up. At the very end all the little niceties and polish touches went in, which made the game radically different. Now I’ve come to admit that all those little touches contribute a lot to the final feel of the game and should be considered all along and not as an afterthought at the end.

Data-Oriented Design Now And In The Future

There has been a lot of recent discussion (and criticism) on Data Oriented Design recently. I want to address some of the issues that have been raised, but before that, I’ll start with this reprint from my most recent Game Developer Magazine. If you have any questions you’d like addressed, add write a comment and I’ll try to answer everything I can.

Last year I wrote about the basics of Data-Oriented Design (see the September 2009 issue of Game Developer). In the time since that article, Data-Oriented Design has gained a lot of traction in game development and many of teams are thinking in terms of data for some of the more performance-critical systems. Continue reading →

2010: Living The Dream

It’s that time of the year again. We all look back at what happened and have high hopes for the coming year.

For me this marked my fourth year as an indie developer. It’s not a huge milestone by any standard, but the fact that I’ve been going at it for this long and I’m not broke yet means it’s a sustainable business. Actually, as you know if you followed some of my numbers posts, this was the first year that income from my apps finally became (reasonably) profitable. Now, *that* is something worth celebrating!

Doing this kind of small-scale game development is exactly what I would do if I didn’t have to worry about money at all, so this is truly living the dream for me.

Goals

All is not sunshine and roses in Noel indie-land though. I accomplished some of my goals for this year, but missed others by a mile and a half:

I released a bunch of Flower Garden updates and ran a bunch of promotions that kept bringing revenue up. That went very well. Check.

Miguel and I also submitted Casey’s Contraptions to the IGF (with three hours to spare the day of the deadline). I’m very proud of that one. Even if we’re not selected as a finalist, the experience of submitting it and finally participating in the IGF was fantastic. Check.

Games shipped. Hmm…. That’s the total fail. The only new game I shipped this year was Lorax Garden, a very short project in collaboration with Oceanhouse Media, mixing their Dr. Seuss license with the flower technology I had already developed. I didn’t even manage to ship Casey’s before Christmas like I was hoping to do. I could make excuses but there’s no point. Real life happens and things go slower than planned (that topic is already brewing for a future post).

My goal for next year is to ship three new games, but always of the quality that I can be proud of. I’ll have to be very careful about design and scope to achieve that (I’m hoping that hanging out with Ian and Dave will rub off some of that genius they have for making awesome games on a crazy-short schedule).

Games From Within

I started my blog, Games From Within, exactly 7 years ago today. I guess that counts as my longest-running project. Some years it was sorely neglected with just a few posts, but this year I spent a significant amount of time on it, thanks in large part to #idevblogaday.

These were the most popular posts for this year (based on page views, which RSS readers make much harder to track):

2011 should be an exciting year for me personally and for all indie game developers out there. Happy new year everybody!

Jigsaw Guru For The Windows Phone 7 Postmortem

This is a new guest post by Frederic My. Frederic and I worked together in the past in big console games development, and now we’re both enjoying the indie life and making games for mobile platforms. Frederic is sharing with us how the development of his first Windows Phone 7 game went. Thanks Frederic!

New beginning

When my job position got terminated last summer, I decided I would take a break from working for big companies, and try to make a game on my own at home. I’ve been in the video game industry since the late nineties, I’ve written code for a few released PC and console AAA titles and probably as many canceled ones, and I wanted to do something different at least for a few months. Go back to the roots of game development, when one or two guys could create something in their garage or bedroom, without spending years and millions of dollars on it.

Platform choice

I’m a C# fan, I won’t deny it, I even explained why back in 2007. I also toyed with XNA each time a new version was released, and I like how straightforward it is to use. When the beta version of the tools to develop for the Windows Phone 7 (WP7 for short) became available, just at the right time for me, it seemed like the obvious choice for what I wanted to do. And developing for a brand new platform sounded exciting as well, even if it was perhaps a riskier bet than targeting well established markets.
For those who don’t know much about WP7 development, I just want to highlight a few key points:

Applications are written in Visual Studio using C#, and either XNA or Silverlight. This may come in the future, but at this point you are not allowed to mix them, and use the controls of Silverlight with the faster rendering of XNA, for example.
In App Purchases are not supported yet.
Programmable shaders are not available for WP7 (they obviously are for the PC and XBox360) in the current version of XNA. Instead, you have 5 predefined shaders with features that can be toggled on and off (such as fog or per pixel lighting). These shaders should cover most of the usual needs, but if you want something very specific that they don’t support, you’re out of luck (or have to fall back to multiple passes and alpha blending).
Paid applications have a trial mode, that allows users to evaluate them before making a purchase. Unlike on XBox Live Indie Games (XBLIG), where the game just abruptly stops after 8 minutes, developers have a complete control over what they want to show in trial mode (for example, the first few levels of a game, with no time limit, or without the ability to save, etc). In theory, this means you shouldn’t have to make a free version of your game in addition to the paid one, but I’ll come back to this later.
The certification requirement document is only 27 pages long, table of content and change history included.

The project

I wrote a few ideas on paper, but they all looked too ambitious for a first project. One thing in particular that I wanted to avoid was to require a lot of content, since I didn’t even know how I was going to find an artist yet. During a bike ride, I thought about using photos, and that’s how I decided to make a jigsaw puzzle game. Not super original, I know, there are several of those on the iPhone and iPad, but there was none on the WP7 since it wasn’t released yet :), and it looked like a good project of the right scope to keep things under control and learn the platform. For example, I had never worked with a touch screen device, and it was pretty obvious from the start that I was going to spend quite some time iterating on the user interface part of the game.
ï¿¼
The game is called Jigsaw Guru, and you can go to http://www.fairyengine.com to see more screenshots and a video.

What went right

I actually already mentioned some of the things that went right in my opinion, but here is the full list:

Working on a short project, without too much content to integrate, instead of picking another more ambitious and time consuming idea, was the right choice. My goal was to have Jigsaw Guru on the marketplace the day of the WP7 launch, I submitted it on 10/18 and it got approved on 10/23 (the update I submitted in December passed even faster than that), two weeks before the US launch and two days after the other territories started getting their phones. At times I still had more items on my to-do list than I would have liked, and I made a good push in the last 3 weeks to get everything wrapped up in time, but it never got too crazy.
Knowing the tools beforehand, and using C# and XNA, definitely made me feel productive. The phone emulator was surprisingly stable in the beta, and the XNA forums were very helpful when I wasn’t sure about something. It’s also worth noting that the website used to submit bug reports allows everybody to see what other people have written, and vote on issues you think are important and should be fixed first.
Garbage collection is the one thing that can hurt your framerate really bad when using XNA on XBox360 and WP7. But it’s not that hard to avoid: when I had a look at my memory usage late in the project, I only found two spots where I was creating some amount of garbage each frame (both related to strings). Basically what I do is each time the player goes from one screen to another, I load everything I need for the new screen, and I force a garbage collection. This gets rid of temporary objects that may have been created during the loading process, and objects from the previous screen that are not used anymore. After that, I don’t allocate anything, and the garbage collector never has to do any work.
Finally: testing. Very few people tested my game while I was developing it, but my friend Alexis alone kept giving me more feedback than I thought I could handle. He never said anything was good just to make me happy, he reported every little detail he didn’t like, even and especially the ones I was aware of but never had time to fix (and maybe thought nobody would notice). Even if I sometimes felt he was nitpicking, this was exactly what I needed.

What went wrong

Developing for a new platform has its share of drawbacks, it’s just how it is. The final version of XNA 4.0 only came out mid-September, and before that I was working with the beta version. As mentioned before, it was pretty solid already, but there was no redistribution of the runtime. Which means you had to install all the tools to be able to just run the game, and you could only install them under Vista or Windows 7 because the phone emulator requires DirectX10, and some of my potential testers were still using Windows XP. So, even if what I was sending was a PC version of the game, they couldn’t run it on XP just because the phone emulator, which they didn’t need, requires a more recent operating system. To work around this problem, I made an XNA 3.1 PC version of Jigsaw Guru, but maintaining two versions side by side for several weeks and merging back and forth between them was not fun.

Coding for a device that wasn’t released yet also meant I could not test what I was doing on real hardware. I unsuccessfully tried to get a phone prototype, and basically the only way I found to run my game on a WP7 at the end of September was to go to a Microsoft event. Even there, I thought there would be phones locked to the tables, that developers could connect to their laptop and use for the whole day, but I was wrong: there was no such thing, and the 4-5 persons who already had a working application to test like me had to do it on the phone of the event’s organizer, when he wasn’t using it for something else. I was able to run my application twice for about 5 minutes each time, and fortunately everything seemed to be working fine, which is a testament of the reliability of the emulator.

When the game began to be really playable, with most of the screens that are in the final version, I started looking for an artist and a musician. I did it way too late, and I was lucky to find Aimee and Tim through the XNA forums, and that the time estimates they gave me just matched my own programming deadline. So, in the end everything worked out well, but even if I wanted to wait and be sure the UI elements were final before asking somebody to redo them, I believe I also waited just because I was more comfortable doing my programming tasks first, and that was a mistake.

Marketing was a difficult problem: I knew I needed to do some, but how? When Jigsaw Guru got approved, the WP7 wasn’t out yet in the US, and had just been released in a few countries of Europe and Asia, as well as Australia and New Zealand. Basically, nobody had that phone yet, and I couldn’t find any website reviewing its games. Even when I had a second look for the US launch, I only saw a couple of sites testing 2 or 3 of the official XBox Live games (that’s how they’re called even if they run on a phone), but nothing related to indie games. So, what ended up happening is I did nothing, and just hoped that because there weren’t too many applications on the marketplace yet (which is the reason for being a launch title, right?), people interested in jigsaw puzzle games would fine mine. Of course I was wrong, and the fact that the search in the Zune software didn’t seem to care about the keywords you enter when submitting your app, or couldn’t find my game when searching for ‘jigsaw’, didn’t help (this seems to be fixed now). I don’t know how other developers releasing WP7 games around the same time as me handled their marketing, but I would be curious to hear it, that question is still a mystery to me.

Downloads and sales

This could have been another paragraph in the “what went wrong” category, but I think this subject deserves its own section. Download and sale numbers for WP7 apps became available on Wednesday 12/08, and I don’t think anybody was thrilled. Don’t get me wrong: WP7 is a very young platform, there aren’t tens of millions of phones in circulation, sale expectations have to be low for now, and can certainly not be compared with those of competing platforms. No, what really surprised me is not the number of sales, but the number of downloads.

On the “top selling” tab of the Zune software (which is more likely based on downloads, like the Bing visual search), Jigsaw Guru has always been in the middle of the paid games from the puzzle & trivia category, the biggest category by far (about 45% of all games). Today for example, it’s 174th out of 363. How many downloads do you think this means on average? About 0.65 per day. This totally blows my mind, but is in line with a graph a developer made with the numbers from his 4 apps, that shows the relationship between the marketplace rank and the number of downloads.

One potential problem is it’s not obvious enough that lots of paid games support the free trial mode, and some players don’t know they can download them for free. But really, it all comes down to most players only checking the XBox Live and the free sections, and rarely visiting the paid one. Which is why although I said earlier that in theory, and thanks to the trial mode, you shouldn’t need to make a free version of your paid game, in practice it’s obvious this doesn’t work, and you have to do it. My friend Noel, who is an experienced iPhone developer, had actually told me I should release my game as a free, ad supported app; unfortunately, the ad SDK’s for XNA didn’t exist at launch and are still in their infancy, the one from Microsoft got released this month and only serves ads in the US, the other ones are either not finished or not stable yet.

So, what’s next? I’m submitting Jigsaw Guru Free (with the Microsoft ad SDK) this week, because as a developer, I still want people to play my game and hopefully have a good time with it. The two projects I started working on after Jigsaw Guru might follow the same path and be free apps from the start, whether it’s on the WP7 or another platform.

Sleep-Deprived Reflections On The 360iDev Game Jam

About 48 hours ago, I participated in the 360iDev Game Jam. I’m still recovering from the sleep deprivation and caffeine excesses, but here are some random thoughts about the game jam and why I highly recommend the experience to all developers.

This was my third 360iDev Game Jam, and it gets better all the time. It’s great to see that it has become a 360iDev tradition, and that the number of people participating is going up every time. The last couple of times we had one invited guest to participate remotely (and preside over everybody else in the big video screen), but this time we opened it up so anybody, anywhere in the world could join us and participate in the updates and discussions through the web site (big thanks for Mike Berg for all the excellent work on the web site!).

What’s The Point

Some people don’t understand what the point of the game jam is. Other people see the value in it, but disagree with what other people see. The point of a game jam is the same as a jamming music session: To create something while surrounded by other developers and feed off each other’s energy and enthusiasm.

In addition to the jamming aspect of it, different people have different goals, and they’re all just as good and valuable:

Trying a new game idea
Learning a new API or technique
Making a finished product
Starting something new
Being totally experimental
Stretching their comfort zone

There were even people using the game jam as a means to make progress in their own game or app they had already started. It’s a bit far from the original intent, but why not? It’s the jamming part that is the most important.

I was glad to see that most people decided to work the theme (“changing the world”) in the game somehow. I definitely find that having some constraints helps me focus and be more creative at the same time.

One of the most attractive aspects of a game jam for me is that it’s a very focused, but very short effort. Yes, it sounds epic: “A full night of pizza, coffee, and coding…” but it’s only 8-10 hours. That means the cost of “failure” is minimal. It’s about a work day. That’s it. So that means it’s possible to try new, risky, experimental things, and, most importantly, be OK if they don’t work out. You don’t learn by succeeding at everything.

Swapping Roles

The last two game jams, I experimented with different kinds of game designs (heavy use of multi touch and limited visibility). This time around I’m in the middle of a new project (Casey’s Contraptions), and Miguel and I did about 5-6 prototypes earlier this year, so I wasn’t itching to do another experimental gameplay prototype.

So instead, Miguel and I paired up again, but with a twist: He would do all the programming and I would do all the art. How’s that for crazy? Actually, he’s in a lot better shape because he’s a good programmer in addition to being a great artist. Me, on the other hand, I can barely find my way around in Photoshop to copy and paste images from Google Images, so this was definitely going to be way out of my comfort zone.

As you can expect, we didn’t make as much progress as we had hoped. On the other hand, I never had more fun or learned more new things at a game jam before! It helped a lot that I wasn’t just flailing around with Photoshop, but that Miguel was there giving me pointers and showing me what the right way of doing things was. I went from not knowing that there was such a thing as a path tool, to becoming relatively proficient with it over the course of the night. It was like drinking a potion of +5 to Photoshop skills.

Apart from learning a lot, I also developed an even deeper appreciation and admiration of game artists. I knew it wasn’t easy stuff and that you needed a lot of talent. What I wasn’t quite fully appreciating is how technically involved art creation is! It’s very different from traditional painting and drawing, and it’s very highly technical. In a way, it’s almost like 3D modeling in how it requires mastery of a very complex tool and you need to work on very small parts for a long time.

Here’s a screenshot of the game showing all the assets I created during the jam:

Lessons Learned

Some random, unsorted, lessons learned from this jam:

Come ready with an empty project you can start working on. The jam is not the time when you want to start stripping out old code. I learned that one in my first game jam, but didn’t come prepared with an iPad project (Hint: the iPhone -> iPad automatic conversion sucks–does anything automatic not suck?).
Everything takes longer than you think. If you think you’ll just finish the game by morning, it’s probably too big. Choose something smaller.
Learning stuff during the jam is great. Just adjust expectations about what you’ll create (we knew this going in, but still caught us by surprise).
Take a moment to interact with the people around you. We’re all in a hurry to make something awesome, but take some time to talk to other developers. It’s well worth it, and makes the long night more bearable (and energizes you more).
Pizza and coffee is a killer combination. I suspect I might never have to go to sleep if I keep the two in balance ;-b
When wifi sucks, it’s hard to take the time to post updates or read other people’s updates.
Hotel wifi always sucks.
The jam is not a popularity contest. Sure, it’s great to show it off the next day, but make sure you create what you want for yourself and not based on what will demo best the next day.

If you haven’t done a game jam, you should. I strongly suggest collaborating with at least one other person, and doing it live with a bunch of other developers. The energy is incredible and it will be an experience you’ll learn a lot from and will remember for a long time.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter. This will be my last post for iDevBlogADay for a while (need to give those people in the massive waiting list a chance!), but I’ll definitely continue posting regularly.