Luckily Xcode allows you to mix and match languages inside of the same project. Visual Studio would require me to put the C++ code into a different assembly if I wanted to use it with C# so in the end it’s slightly better than that. The slight problems are that it means that you need to get the two languages to coexist.

The problem I face is one akin to the managed and unmanaged code in Managed C++ for .NET. Obj-C has a layer of functionality that means that just consuming the C++ object is not going to work. A wrapper is needed in order to bridge between the two. Say I was going to wrap a nice C++ class that contains some nice cross platform graphics code I need something like this:

@interface OpenGLView : NSOpenGLView

{

Wrapper *openGL;

}

-(void)drawRect:(NSRect)dirtyRect

{

if(openGL == nil)

{

openGL = [[Wrapper alloc]init];

}

[openGLInitScene];

[openGL Draw];

}

I’m not sure that the lazy allocation of the object there is a good idea, but it works for now. Wrapper is an Obj-C class that looks like this:

Wrapper.h

#ifdef __cplusplus

class OpenGLBase;

#endif

#ifdef __OBJC__

#ifndef __cplusplus

typedef void OpenGLBase;

#endif

#endif

@interface Wrapper : NSObject

{

OpenGLBase* openGL;

}

-(void)Draw;

-(void)InitScene;

@end

Wrapper.mm

#import “Wrapper.h”

#include “OpenGLBase.h”

@implementation Wrapper

-(id)init

{

self = [super init];

openGL = new OpenGLBase();

return self;

}

-(void)Draw

{

openGL->Draw();

}

-(void)InitScene

{

openGL->InitScene();

}

@end

They key thing to notice is that the file is called Wrapper.mm instead of just Wrapper.m as that enables the object oriented features and allows a C++ class to even get close to it.

Now this solution does not seem neat to me by any means. There’s some serious redundancy in having Obj-C functions that just call through to the C++ object that could be a real mess for maintenance and I’ve not looked at any performance implications that they may have either. If the interface between the two is a small number of member functions then I’m not going to be too concerned for now, it works and allows me to bridge the gap. I can find a better solution when I know Obj-C better. I’m sure I can do something with interfaces to force me to implement functions or something, just as I would with an abstract base class in C++ or an interface in any other language. That is for the future, for now I have some working code I can use for playing around with OpenGL.

I’ve tried to rekindle that passion many times, but always I’ve hit the same old problems of motivation. The reason is, as I think I’ve now found out, that there just wasn’t a big enough chunk of “unknown” out there for me to delve into. I work with .NET every day and have a pretty good handle on enough of it so that I don’t have an urge to go and explore the nooks and crannies to find out what cool things are behind the next corner.

The iPad fascinates me for this exact reason. We are nowhere near to figuring out what having powerful devices like phones and tablets with us all the time means yet, and it’s exciting me in ways that are feeling very familiar. So it’s time to grab Xcode and learn Objective-C. It’s time to grab the iPad and iPhone and see what I can make them do.

One of the most exciting things for me is Airplay. The ability to get a second display onto a TV over Wifi has some really fascinating implications for games that might make Sony and Microsoft a little uncomfortable over the next few years.

A few bazillion GB of downloads later and I have the Stanford iOS 5 videos ready to go along with a bunch from WWDC last year. So far there’s been a lot of “Ohh, that’s really clever” moments about features and just as many “wouldn’t this be easier in a less mad language?” ones as well.

I do think that there is a non-zero chance of there being an app store on the next generation Xbox as it’s worked out well for Apple as a revenue source, but Microsoft are masters at not utilizing what they have and letting other beat them. I’ve always assumed that it’s various groups inside of Microsoft fighting away and pulling in different directions depending on who has won that month. XNA is being pulled towards phones and the Xbox UI is being pulled towards, well who knows what that mess of a UI is meant to be for now? It makes everything to do with games harder and hides some content so well that even Microsoft community people send you to youtube to find videos rather than the Xbox dashboard now.

It’s sad to see independent games on the consoles go away once again, but maybe we will get better support next time.

In order to do that I will need a game engine. When you put it like that it sounds all big and scary, so what I need to start with is a small first stage to work towards. This first step has to result in something that runs and then lets me interact with it in some kind of meaningful way. I also need this to happen as quickly as possible so that I have started with enough inertia to keep going.

This means I need to pair down what I’m doing to start with to the smallest core possible. Anything fancy needs to be discarded and anything difficult needs to go as well.

The First Iteration

The first iteration of the game will be a 2d sprite based top down game. There are two sides, red and blue, and the graphics are the same for both except for the colours. You will be able to create units from a fixed base and move them around the map. You win by moving a unit onto the enemy base and there are no enemy units or AI. The landscape will be a flat colour with no obstacles to cause path finding issues and it will all be visible on screen at the same time. There will be no zooming or panning of the camera. There will also be no menus, the game starts playing and ends when you win.

Yes, that is the dullest game ever and can be won by creating a unit and sending them in a straight line to the enemy base. It does however give me something with a win condition that is playable from this iteration onwards as I add new features.

From this I created a quick list of features I need for this iteration:

• Basic application window (on the 360)
• A World that is the same size as the display
• Bases (in the middle of the short edges of the window)
• Unit selection (need to select the base to create units, select the units to move them)
• Unit creation
• Unit Movement
• The ability to win (move unit into the opposing base)

No doubt I missed something massive here.

The reason for hitting the 360 from the word go is that it’s easy to do. In fact it sounds easier for me to always target it then to bring support in for it at a later date as I won’t have gone down any blind alleys along the way.

Potential Next Iterations

After I have this created I need to think about where step 2 will go. I think it is important to know where you are going next as that will guide your decisions for each iteration, but I’ll have to be careful not to look too far ahead and start coding things that aren’t needed yet. From this step on I’m thinking of very small iterations that just add one or two things and nothing should have as many features as the first one. The rules of iterative programming say don’t add features that you think you’ll need so this will basically be slap them in, refactor them in the future as I add new things.

The short list that I’ve come up with is quite simple:

• Local Multiplayer
• Menus
• Music (ability to play, not composing)
• Sound Effects

I think all of these are quite important for various reasons. The menus are needed in order to make it a “proper” looking game. Music will be needed at some point, as will sound effects and the earlier I get them in the sooner I can tick them off the list.

Multiplayer may seem like the odd one out here, but since the goal is to be playable at all times it gives a competitive experience with the least amount of effort compared to actually adding some AI which, I have to admit, I am clueless about at the moment.

I suspect I shall start with multiplayer and then add menus in order to satisfy my goals and design philosophy. Technically after I have these four features it could be considered a fully developed game (albeit a boring one) that is missing features required to actually sell the game on 360.

Along the way I’ve also gotten out of the habit of coding in my spare time. I used to spend a lot of (enjoyable) time poking around at the debugging layer of .NET and I feel the need to poke around at something again.

So basically I need to make a game to scratch that itch, but along the way play with a whole range of things that I find interesting. How hard can that be?

To start with I’m going to need a set of achievable goals. I’ve found over the years that the key to getting any software project successfully finished is to work in short steps with a working product at every step. For a game that means having something I can play from day one.

Next I need an idea. Luckily I have one, and it’s something I’ve wanted to explore for a long time. This question needs a console to be answered and so the choice of technology becomes limited to one possible solution: XNA.

What is that question? Can you make a good console RTS game?