Mike Kasprzak has been a full-time indie game developer for five years now. He quit his job as Technical Director at Canadian game company Big Blue Bubble, with the words “being too ambitious for my own good”. What followed were 5 years of attempting to strike big as an Indie but, well, not doing so well after all in the XNA space. But things turned for the better when the iPhone SDK came along. In 2008 he created and released the puzzle game Smiles, it grew in popularity over time and from the lessons learned Mike began to make ports of the game, including Windows Phone 7. The game even won him a car!

Read Mike’s recap of his past five years being a full-time indie game developer.

Make sure you also check out his blog tooNormal ?! where you can learn a few more things about Mike. He is also running the Ludum Dare game competition and he wrote a chapter about writing portable code in the iPhone Games Projects book published by Apress.

Add your link to the Cocos2D Linkvent Calendar

Do you have something to share with the Cocos2D community? I haven’t received enough submissions to fill all the days until Xmas, although I do have enough links to post one each day, I’d rather post a link to your website or blog post.

Tagged with:  

Prefer Composition over Inheritance

On June 11, 2010, in Programming, Speaking From Experience, by Steffen Itterheim

When the question came up whether to subclass CCSprite or use some model class to build your game entity hierarchy in the cocos2d forum, i stressed that one should try not to use inheritance and keep the inheritance hierarchy to as few levels as possible. I’ve worked with codebases with hundreds of thousands of lines of code, and hundreds of different types of actors in the world. Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

The answer lies in composition, often referred to as Game Components by engines like TorqueX and the PushButton Engine (a Flash game engine from the original Torque developers). This video from the PushButton lead developer Ben Garney explains it very well and also illustrates the problem with inheritance over-use in game engines. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

You can read more about PushButton’s Components system in their documentation. How they implemented Components in TorqueX and what the differences are to XNA Game Components further enhances understanding of the concept.

For further reading and arguments read the Wikipedia article on component based software engineering. As a matter of fact, the Objective-C language was invented to be able to create re-usable software components!

Scott Bilas’ GDC 2002 talk about A Data-Driven Game Object System (PDF) as used by Dungeon Siege contains more pointers on why inheritance fails for game developers and what the advantages (but also some caveats) are with component-based game engines. The talk may be old but it’s still as valid today as it was back then. In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

During GDC 2009 a similar presentation was held by Radical Entertainment’s Marcin Chady. The talk was called Theory and Practice of Game Object Component Architecture (PPT).

Mick West wrote an article Refactoring Game Entities with Components which describes the challenges and benefits of changing the Tony Hawk codebase from an inheritance model to a game component system.

A somewhat more advanced read on component use is a collaborative paper called Dynamic Game Object Component System for Mutable Behavior Characters which talks about components in context of finite state machines and NPC behaviors with a rule-based activation system.

The Game Architect blog calls it an Anatomy of Despair and sums up very good what the cons of inheritance-based class design is and how composition solves them.