The Starting Point for a Train Game with Freeform Tracks

On July 12, 2012, in idevblogaday, by Steffen Itterheim

If you ever wanted to build your own 2D top-down view train driving game, here’s … well, the things you need to consider plus a rudimentary source code example. Because a train following tracks is not as simple as it might seem, unless you restrict curves and switches to 90° angles and allow only very short cars and locomotives.

Here’s a video of my example project. Any stuttering is due to the screen recording software taking a toll on my system combined with the video playback framerate not rendering 60 fps (I assume it’s the standard 24 or 30 fps for Youtube videos). The video shows a sequence of three runs with a medium curve radius, a large curve radius and a ridiculously small curve radius. The yellow line indicates the track being followed by the axles, the purple line indicates the car chassis position (center point between axles).

Continue reading »

Xcode 4 Debugging Crash-Course

On October 6, 2011, in idevblogaday, by Steffen Itterheim

What do you do if your app doesn’t behave as it should, or even crashes?

Answer A: Post your problem in just about every programming forum.
Answer B: Use the Xcode Debugger to analyze what’s going wrong.

Since most of you already know how to do A I’ll focus on B in this Xcode 4 Debugging Crash-Course. It’s kind of aimed at beginning Xcode developers but that’s just because I hope – against better knowledge – that experienced developers already know that … thing … that debugger stuff. Ya know?

Continue reading »

From Dogfooding to Catfooding

On September 22, 2011, in idevblogaday, Kobold2D, by Steffen Itterheim

Most developers have heard of the phrase “Eat your own dog food”. It refers to the habit of actually using what you’re creating.

A typical example would be a company building Yet-Another-Issue-Tracking-Tool™ while using said issue tracker to manage their Yet-Another-Issue-Tracking-Tool™ project. And you’ll surely have heard of a game engine that was initially only developed as a necessity to build a game, then polished and released to the public to great success, while the developer continued to create games with his own engine.

Dogfooding is considered a good practice, actually a best practice. You know that the tool you’re building works, and that it satisfies your needs.

But “your needs” is also the achilles heel of dogfooding, and it’s just a small step away from forever “perfecting” your product (known as “gold plating”). So sooner or later, you’ll have to do some catfooding, too. Meaning: to feed the user’s needs.

Continue reading »

Kobold2D: Polling User Input with KKInput

On September 15, 2011, in cocos2d, Kobold2D, Programming, by Steffen Itterheim

Kobold2D is about solving annoying, recurring problems, or simply making all things Cocos2D more convenient. The new KKInput class does both! (*)

Continue reading »

Tutorials for Cocos2D for iOS are a plenty on the web. But I managed to find one that’s not very well known and provides a more technical introduction to the Cocos2D concepts and how to program menus, animations and detecting collisions. By technical I mean that the focus is clearly on providing working code.

Written by Hans Hamm the Tutorial Programming iPhone Games with Cocos2D is divided into four parts:

  • Part 1 – Cocos2D Architecture Overview
  • Part 2 – Buttons & Menus
  • Part 3 – Sprite Animations using a Texture Atlas
  • Part 4 – Scheduling updates & detecting collisions

Hans is also a co-founder of Anima Entertainment, they created the iPhone games Crash Birds (free) and Earth Defender:

Linkvent Calendar, Day 13: Balloon Ride Postmortem

On December 13, 2010, in Cocos2D Linkvent Calendar, by Steffen Itterheim

Today’s Linkvent Calendar entry comes from David Sutoyo. His second Cocos2D game, Balloon Ride, was published on the App Store on Dec 1st. David took some time to write a postmortem about making Balloon Ride. He starts out by saying that programming in Objective-C is hard, game design is even harder but marketing is the hardest part. However, he concludes that the overall design process is fun and he is now toying with the idea of using Corona because programming in Lua is simpler than Objective-C.

David also wrote a mini-postmortem about his first Cocos2D game Memory Flash.

Watch the Balloon Ride gameplay video:

Regardless, this may be the answer. Or as close to it as any publicly shared link list not hosted on link aggregator sites could ever be. I’m talking about Amit Patel’s Game Programming Information pages. There’s something for everyone, but specifically a lot of articles about pathfinding, AI and tile-based games including procedural world generation.

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.

Page 1 of 212