Cockpits

I stumbled upon a pretty cool article from Wired. It shows an amazing array of different types of cockpits, ranging from fighter planes to cruise ships.

Spy Plane cockpit

The amount of variables and knobs to tweak varies enormously. There was one big takeaway for me: The number of variables you need, depends on the agility of the thing you’re trying to control. The captain of the cruise ship says the following:

“When we’re going into port, we typically push the chairs out of the way and stand up. It makes us more agile”. And how does he steer? “The port and starboard command chairs have built-in joysticks for controlling the ship,” Wright says. But those are typically operated by other officers. “Captains should be mentoring and teaching.”

Which is different from flying an airplane: The Boeing 787 has a 8- by 4-inch fold-down, heads-up displays (corner of each windshield) to let pilots do instrument scans without shifting their focus from the horizon.

What’s also nice is that in the more advanced ships, most of the trackable data is tracked. The most extreme case is the Blackbird: “If a pilot screwed up, we could download the tapes and say, ‘OK, buddy, here’s what you did wrong,’” says Rich Graham, a flight instructor and retired SR-71 pilot.

We are currently working on our own dashboard for our upcoming games, something which we will probably share with you in the near future. The beauty of these real-life examples really makes you look at a software dashboard in a different way.

So what do you think? What is the ideal team size for game development? Should you be delegating and coaching, or should you be at the steering wheel making turns and shifting gears? And equally important, what’s the ideal dashboard for that product you’ve launched? Which variables are you tracking? How many knobs do you need? Are those the right ones?

Use the right tools for the job

Let me start a with bold statement: Apple Macs suck. To be more precise, I don’t like OS X and I don’t care about cool window animations, fading etc. I’m the guy who likes Windows and still uses the classic theme.

Anyway, that’s not what I wanted to blog about today ;-)

As you probably know, we have forced our self to learn the iPhone platform in two weeks. To do so we had a great idea: “Hey, Paladin Studios is a game company, why not make a game?” If you want to achieve anything interesting in such a sort time, you need to use the right tools. Normally we use a lot of tools like Pivotaltracker, SVN, Paint .Net, Visual Studio, Max and Unity.

To put in another bold statement: Unity rocks! It’s a 3D engine which allows you to use C# for programming. To use their marketing one-liner: “Taking the pain out of game development” which means you can concentrate on the gameplay and not having to do all rendering, physics etc yourself. It does take (most) of the pain out of game development. As an example why we love Unity I’m going to show you the simple and speedy way we can create and test scenario’s.

A scenario is no more then a bunch of settings on our Obstacle Factory which has one job: spawn objects. The Unity editor allows us to play our game and change that bunch of settings while it keeps running. As pictures tell more then words…

Top: Scene editor Bottom: Playing game Left: All objects in scene and project files Right: Object settings editor

Zoomed in on the object settings for the Obstacle Factory. There are a bunch of scenes, some settings and a check to override the current scene and let it use the settings we tweak realtime. Spawn type Pathed is really cool btw.

To break it down, Unity is the tool for us. The iPhone version is Mac only, which makes sense.

Too bad I can’t use Paint .Net and Visual Studio anymore though…