Announcing Petunk for the iPhone and iPad!

Hey everyone, I hope you’ve been busy working on your projects. As for me, I’ve been helping my friend Jason Lust over at Stellar Games port Petunk to the iOS platforms. I honestly can’t take much credit here. Jason has put a ton of work into this project and as a result I feel that the iOS version of the Petunk is the best one yet. Anyway, if you have an iPhone, iPod Touch, or iPad please check out our game! If not, well, please share Petunk with your friends. And of course, there’s always the web version of Petunk, too.

Global Game Jam 2011, a post mortem

Over the weekend I locked myself away at the Art Institute of Seattle with the hopes of creating a compelling game in 48 hours. Now that the Global Game Jam is over I’d like to share the fruit of my labor and some parting thoughts.

Eat, Prey, Love

The event’s theme was “Extinction” so we all had to come up with game ideas around that concept. My team settled on a puzzle game where you match different links in a food chain to balance your ecosystem. We call the game Eat, Prey, Love. Click on the screenshot below to try it out!

Rather than telling you all about Eat, Prey, Love I thought I’d take a step back and reflect on the process of making it. After all, you can always click the play the game and see it for yourself.

What Went Well

This year, I’m happy to say that I think a lot went well with this project:

1. I found an excellent set of teammates. Justin, Luke, and Nicole were all very talented and contributed a ton. What’s even better is they were a blast to work with. Thanks guys!
2. We picked an achievable idea. Instead of trying to create a more complex simulation or go for spiffy 3D graphics we settled on an idea that was pretty well understood and easy to execute. It helped that I have experience making match-3′s, too.
3. The tools. We decided to use C# and XNA. Both Justin and I are experts in the language and have made several games with XNA, so we didn’t waste time learning about our tools.

Overall, my main goal for the game jam was to make a polished game I could take pride in. Thanks to everyone’s hard work I think I achieved that goal.

What Went Wrong

I really don’t think a lot went wrong during the weekend. Still, in the interest of balance here are a few bullet points:

1. The gameplay didn’t turn out as fun as I had hoped. I thought that a bejeweled-like match-3 mechanic would mix well with our ecosystem idea. In the end, it proved too difficult to remember what things match and not clear enough how matches impact your ecosystem.
2. Getting feedback. We didn’t ask other people to play our game often enough throughout the jam. I think if we had gathered more feedback — especially from non-jammers — our game would have been more fun.
3. Not designed for web. This is a pretty small complaint, but as we wrote the game Justin and I did not think about porting it to Silverlight. As a result when it came time to do so a fair amount of code needed to be rewritten. We should have researched the constraints sooner and built our game with them in mind.

Conclusion

Overall I’m really happy with what our team was able to accomplish during Global Game Jam. I think our game is really well polished considering it was made in under 48 hours, and I believe that the underlying idea — a game where you have to balance different species in order to preserve the natural order — holds a lot of potential. In addition, I am really happy to have gotten a chance to work with such talented and friendly people!

So, what were your experiences like?

What are XNA Game Components?

Recently, while working with XNA I came across a few classes I hadn’t noticed before. It turns out that interfaces I often write myself, IUpdateable and IDrawable, already exist. When I found them I wanted to know more. They rarely appear in the MSDN code samples I’ve seen, and searching online, it appears most people are as perplexed as I am about what to do with them. So after playing around with these interfaces and their sibling the GameComponent here are some thoughts on what they are and how they fit into a larger project.

The Good

The starting point for a game in XNA is the Game class. It so happens that this class has a collection of GameComponents which manages updating and drawing each GameComponent. Because of this making your game objects GameComponents seems like a good way to hook directly into the XNA game loop.

In fact, it almost feels like adding DisplayObjects to the stage in Flash as GameComponents have a lifecycle which the Game will follow. What this means in practice is that as long as you’re dealing with GameComponents it’s really easy to add things to the game. Want to add a tween? Just create one and add it to the list of GameComponents. No need to hold a reference or manage its life cycle.

The Bad

In my book those are some pretty compelling features. So what’s not to like? In my opinion there are three main problems with the GameComponent class which make me recommend against adopting it throughout your code.

1. Inheriting from the GameComponent class requires taking a dependency on the Game object

In practice, your game objects will likely need some means to communicate to the game in order to add or remove other game objects, and it would be fair to solve this problem by holding a direct reference to the Game object. However, by using GameComponents you are forced into this decision. This means no event mode or interfaces — no indirection between your game objects and the game.

2. GameComponents need services; Services lead to questionable design choices

GameComponents will often query the Game’s list of registered services in order to function. Due to their fancy name, services sounds rather innocuous. In truth, a service is really nothing more than a global object with a thin layer of indirection wrapped around it. So while I believe it’s possible to write against services without tightly coupling your code to, say, the SpriteBatch. In practice I’ve found services let me be lazy at the expense of good design.

3. Your classes will be hard or impossible to unit test

It follows from the above that in order to instantiate one of your game objects you will need an instance of the Game class. Unfortunately, the game class is sealed meaning that you cannot subclass it or swap out its implementation. In my opinion, if you have to create an instance of the Game class in order to test your game object’s AI then you’ve failed at unit testing. In effect you’re having to fly the plane to test its coffee maker!

Conclusion

So I wouldn’t recommend writing against the GameComponent class, but what about the IUpdateable and IDrawable interfaces I mentioned above? As it turns out both those interfaces are free from references of the Game class. So if they make sense for your project I’d go for it. However in practice, I’ve found that I don’t really need all of the behavior defined in these interfaces. While I feel like the XNA needs something akin to the Stage in Flash I’m not ready to make a deal with the devil quite yet.

Calling all Game Developers, or Global Game Jam 2011

Guys, it’s that time of the year again! The days are shorter, the air is colder, and we’re still getting back into the swing of things after the holidays. Of course, that can only mean it’s time for a game jam, and not just any jam but the Global Game Jam! If you’re unfamiliar with the Global Game Jam, it is a 48 hour event wherein game developers break into teams of four or five and try to whip together a working game. Even if you are an experienced game developer, I encourage you to join us; when else do you get to enter this type of high energy, passion fueled environment? To get a sense of what you can accomplish in a weekend check out The Cleaner, a game my team and I created for the last game jam.

If you’re in the Seattle area I hope to see you at the Art Institute of Seattle. Either way, I hope you’ll share what you’ve created! The jam is happening around the world on January 28-30, 2011.

5 Reasons I’m Excited to Develop Games for the Windows Phone

1. Write games using C#

I don’t want to start any fiery debates about programming languages, as clearly many languages can get the job done when it comes to game development. That being said, after making games in many languages I hold a special place for C#. The language is strongly typed, which in my opinion helps catch certain kinds of errors and makes for more readable code. Even better, the language has seen a number of improvements over the years. Some stand outs include support for weak types, LINQ expressions, and lamba functions. As a result, I am more productive in this language than any of the alternatives.

2. Taking advantage of the XNA framework

XNA is a framework developed by Microsoft to accelerate game development. Like the Slick game engine, XNA is a glue framework. This means I can take the parts I want and leave the rest letting me code in my own style. It’s true that I sometimes find things missing, but more often than not there’s a code sample on MSDN to help fill the gap. Overall, I’ve found XNA to be a solid foundation to get a game up and running.

3. Target the Windows Phone, PC, Xbox, and the Web

Obviously I want people to play my games. So oftentimes the size of the audience is more important than the technical aspects of a given platform. In this case I feel like I can have my cake and eat it as it’s possible to target a large number of platforms with XNA. Microsoft supports running games written in XNA on the phone, PC, and Xbox and if you take advantage of the open source Silversprite library it’s also possible to target the web through Silverlight. With all of that said, I still think there’s an important space left for Flash to fill.

4. Release on the iPhone and Android

Today, Novell ships a product named MonoTouch which allows developers to create C# applications for the iPhone. Combine it with the XNA Touch library available on CodePlex and you can deploy your XNA based games on Apple’s platform. Novell is currently working on a similar library for Android called MonoDroid. I plan to try MonoTouch soon. If it all goes according to plan I believe C# will be able to target every mobile platform!

5. Great tools and documentation

Finally, I’d like to talk about the developer experience for the Windows Phone. First and foremost there is Visual Studio. As these things go I think Visual Studio is a pretty solid IDE. That being said, I have found it lacking in certain regards which is why I also use the ReSharper plug-in. Taken together, I find that writing code in C# is much faster and easier than anything I’ve found for Actionscript or Java. These two tools provide an amazing array of code completion and refactoring tools. In addition, there is great support for tasks such as unit testing, profiling, and static code analysis. Backing all of this is a wealth of documentation both from MSDN and the larger web.

Conclusion

I’m not going to try to lie or whitewash things, developing for the Windows Phone is certainly a gamble. That said, in my limited experience I’ve found that when it comes time to release a game and break through in the marketplace there’s always a high degree of luck involved. With that said, I’m excited to try my hand on this exciting new platform. I hope you’ll join me as I continue this experiment!