Another Early Morning

New company, new blog

2013-04-18T08:25:00Z

Hi everyone, about a year ago I moved to Amsterdam and started a company Spotted Zebra. Since then I’ve released versions of Adlib and Petunk for Windows 8 and am hard at work on a third game titled Scramble Legends!

I’ve finally gotten back into blogging about game development. However this time my posts will be on my new blog: Spotted Zebra’s blog. I’d like to invite you to join me as I explore the design and development of Scramble Legends in a series of blog posts: Making of Scramble Legends. Please be sure to update your RSS feeds as well!

I hope you’re all creating awesome games and look forward to sharing more details about my experiences.

Announcing Petunk for the iPhone and iPad!

2011-08-18T08:10:08Z

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

2011-02-02T05:48:28Z

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:

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!
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.
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:

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.
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.
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?

2011-01-24T19:52:56Z

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

2011-01-12T00:58:07Z

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

2011-01-12T23:12:29Z

Microsoft's Windows Phone 7

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!

Petunk: a charming new putt putt game

2011-08-18T08:12:45Z

Petunk is a simple pick up and play physics puzzler. Featuring putt putt golf-like game mechanics, Petunk challenges the player to hone his skill at aiming, shooting, and timing his shots at the target. Featuring hand crafted artwork wrought from real world materials and brought to life on screen, play Petunk today!

Play Petunk online
Or download Petunk for the Xbox
Have an iOS device? Play Petunk on your iPhone or iPad!

Adopting a Component Model for Game Development

2011-01-04T04:38:46Z

For Colorfull one of my goals was to explore the component design pattern for game architecture. For those of you who are unfamiliar with the pattern it goes something like this:

Instead of using inheritance to add new types of behavior to game objects, the component model seeks to extend a game object’s behavior by adding or removing components. Thus, if you want objects to be affected by gravity you might add the GravityComponent.

In this model every object in the game is an instance of the same type. What components are used to construct an entity is what distinguishes, say, the player from a NPC.

Motivation

Why should we adopt a component design? The reason is pretty straightforward. In the traditional model we start with a GameObject base class and gradually extend it to add new functionality. Thus, we might have a PhysicalGameObject and later a PlayerGameObject. The problem is that there are often concerns which cut across our hierarchy but don’t fit somewhere at the top. In these cases we end up having to duplicate logic. The component model addresses this by collapsing the hierarchy and moving behavior into components which can be added or removed as needed.

How it Works

In Colorfull our component model looked like so:

Each component would implement the above interface and add additional methods as needed. For example, the RenderComponent might add Render(Graphics g). The game loop would then query each entity for it’s RenderComponent and draw things.

Benefits

In my view there are a number of benefits to adopting a component model. They include:

Components follow the Single Responsibility principle making them easier to maintain
Since components are isolated it’s easy to test each individually
It’s easy to add or remove behavior at runtime by adding or removing components
Higher re-use of code as a component can be mixed and matched as needed
You could possibly take advantage of spatial locality to speed up memory access
Lends itself well to a visual editor like Unity which trades in components

Drawbacks

That said, there are costs associated with the pattern. As you probably expect, adopting a component design leads to considerably more complicated code. Some problems include:

Components which depend on other components can lead to run-time errors
Communication between components within the same entity breaks encapsulation
Entity-to-entity behavior is awkward since it now goes through components
Duplication of state for certain component pairs, e.g. rendering and physics

Conclusion

Alright, we’ve covered a lot of ground about the component design pattern, so what can we say about things? Personally, my conclusion is that this model makes a lot of sense for a large game where different game objects may mix and match various attributes that don’t necessarily form a natural hierarchy. The ability to more easily test things is a nice side effect, too.

That said, the complexity that springs out of splitting behavior which is similar but not quite logically the same is a problem. I believe more research is warranted to look into ways to bind and constrain components in a more explicit manner — ideally complete with build time errors. For instance, we need a clear way to document the relationship between components.

Overall, I would recommend using this model for engines or more complex games, but I would hesitate to adopt it for a simpler game. Finally, it’s worth noting that moving between a traditional hierarchy and a component model is not very hard, so there’s an opportunity to start simple and refactor as things get more complex.

August is over: time for show & tell

2011-01-04T03:42:21Z

It’s September already, so it’s time to pony up and show you what I’ve been working on. To be frank, this month’s game, Colorfull, hasn’t turned out as pretty as Petunk. The biggest culprit by far was Starcraft 2. That game is great. (P.S. send me an invite if you want to play, I’m on the US servers as Asterix.) At any rate, I am happy to say that Matthias and I accomplished our main goals. Now we have to decide whether to let the game die or put more time into it. At any rate, let’s have a quick post-mortem to review the month. At the end I’ll even link you to a Silverlight version of the game I cooked up!

What went well

The game architecture

One of the main goals of this project was try to alternative design patterns. Instead of going with a hierarchy of GameObject’s we used a component model. In this model each object in the game was merely an Entity filled with different Components. This and other decisions in the design allowed us to more easily test the game and eventually port it to the desktop and web with only a few changes.

Unit testing

While we failed to practice TDD — which is mostly my fault — we did manage to write a fair amount of tests. By using a component model we were able to easily test each component in isolation. In addition, when it came time to test larger pieces of the system we could oftentimes omit non-essential components, say the rendering component. Overall, I think we learned a fair amount about UI testing. I might conclude that the goal for game engine is to make the view as thin and simple as possible so that even if it goes untested it’s relatively less risky.

Making a game with C# and XNA

This was our first full game with XNA so in addition to testing out design and gameplay ideas we wanted to put the platform through the paces. Now that the game is done I think I have a much better sense for the pros and cons of working in XNA. I really like the language — it’s a big improvement from Flash — and XNA is a great framework, but it’s not without it’s warts either. Too often the developer is left to implement libraries that we take for granted in Flash or Java.

What went poorly

Time management

Honestly, I didn’t work enough this month. The problem really boils down to one thing: on July 27th Starcraft 2 came out. This game could have turned out a lot better. If I had put more time into the project I think some of the game’s faults would have been fixed.

Levels/Features

To be completely frank, the game is missing some important elements. There’s no real end, you just beat the last level and nothing happens. In fact there’s really not enough rewards in place at all. There’s also no sound effects. For a game like this that’s not so bad, but, going back to rewarding the player, it would be nice to have some chimes or something to encourage you to continue. And lastly, there just aren’t enough levels or variety among levels. We have great ideas on how to extend the gameplay but we haven’t implemented most of them.

The art style

I think the game is quite ugly. Unlike with Petunk, I couldn’t come up with a clever way to get around my non-existent art skills. As such the game is sporting obvious programmer art. If we do spend more time on this game we will have to hire an artist to help make things shine.

Final thoughts

So in conclusion, I made a half game this month. It didn’t turn out quite like I wanted but I did learn a lot of important things. Hopefully over the next couple weeks I can find some time to write some of what I learned down. Like, you can target the Windows Phone, Xbox, Windows, and Web with the same code base incredibly easily, or that Kongregate and Newgrounds don’t seem to support Silverlight. For now, I think I’ll go play one more match of Starcraft :-)

Oh, and please try the Silverlight version of Colorfull and let me know what you think.

It’s August, time for a new game

2011-01-04T04:30:28Z

Hello everyone, I hope that things are going well. We’re well into August now and it’s high time I share a little bit about my current project.

Once again, I’m trying to complete a game in a month. In July I created Petunk. One goal with that project was simply to prove I could make something decent in the timeframe. This time around I have a couple goals in mind:

Explore a component model design
Create more tests for each component of the game

I’d like to tell you more about my progress towards each of those goals in future posts. First, let me tell you a little bit more about the game I’m working on. The game is tentatively titled Colorfull and it’s a game about mixing colors together. In fact it’s something of a puzzle game which revolves around combining colors in different ways. Check out a mock up screen shot:

Prototype interface for Colorfull

So far I’ve completed the core framework for the game and generated some ideas I think will lead to great levels. At this point I’m focusing on getting the level editor working. Once that’s finished I think I will be able to finish extending the gameplay and then turn to polishing the game.

So what do you think of the mock up? And what are you working on this month?

One more thing, this project is being written in C# and XNA for the Windows Phone. This might make it harder for some of you to play, but I hope you won’t mind. Additionally, a good friend from work, Matthias B., is joining me. So far he’s proven very useful :-)