This is an interview I had left over from a feature, and it seems a shame to waste it. It’s with a Mac developer, James Brown, who is the entire staff of Ancient Workshop and it’s about Mac gaming.
To the tune of: Belle and Sebastian – Funny Little Frog
Tell me about you.
I worked in the mainstream games industry for 10 years (including stints at EA & Lionhead) but recently went indie. I have a game called Ancient Frog which is currently out for the iPhone and, in expanded form, iPad. Internally I also have versions running on OS X, Windows, Android and Palm Pre, each at a different stage along the release pipeline.
What differences in tech are there between developing for Mac and PC?
I develop simultaneously on Windows and Mac – they’re side by side on my desk like something from a Stevie Wonder song, and so far neither of them has managed to completely oust the other. I prefer OS X as a general development environment (it’s funny how the Mac ended up with a far better command line, given the history of the two platforms), but there’s still nothing to touch the Visual Studio debugger on Windows.
In terms of developing for them, they’re only as different as you allow them to be. Apple wants you to use Objective C, Microsoft wants you to use C# and DirectX, but in neither case is this enforced. If you develop in straight C++ targeting OpenGL, the differences are entirely superficial.
What needs to be adapted to make games on it?
Games are probably the easiest type of application to adapt from PC to Mac. Where you run into difficulty porting an application from one platform to another is in the user interface. If you’re making a traditional utility application, you have to either make something generic (which feels clumsy and wrong on every platform), or you have to bite the bullet and rewrite huge swathes of code for each version.
With a game, though, it’s different. A game pretty much is a user interface – it exists solely as something to be interacted with, and that interaction is something which shouldn’t be shoehorned in to the platform’s general look and feel. Imagine writing a puzzle game that conforms to the Mac OS human interface guidelines; it would just show you the completed puzzle – after all, users shouldn’t have to fiddle around solving problems that the computer can solve for them.
So it’s a given that a game handles all of its UI in its own way. Everything else is, to a certain level of abstraction, identical. You have a C compiler, a file system, a graphics unit that will draw triangles with textures on them really quickly. The higher level stuff that each operating system can do for you doesn’t really come into it.
Are simultaneous releases tricky?
From a technical point of view they needn’t be tricky. The easiest way to handle multi platform development is to make sure you’re building on each platform right from the start. One of the reasons I’m constantly switching back and forth between the Mac and PC is that I catch any non-portable code immediately, while it’s still fresh in my mind and it hasn’t burrowed its way to the heart of the codebase. It’s a natural extension of this development approach that when the game is finished on the Mac it’s finished on the PC. (I also target iPhone, iPad, Android, Palm Pre and so on, but the tighter constraints on performance and resolution mean that they each need a bit of individual care and attention before they’re ready for release.)
Marketing is a bit trickier – a big publisher is able to reap the benefit of one big marketing blitz covering every platform. As a one man indie, I’m chipping away trying to get reviews within my particular niche, so I feel I’m better off releasing one version at a time.
There are dangers in closed systems and Apple love them – do you think Apple will ever implement a system similar to the iPhone’s app store for Mac? Or has Steam already taken that function?
I really can’t see them implementing an app store in the same form as the iPhone / iPad store, where it’s the only way to install applications – Microsoft failed to achieve that with Palladium, and I’d expect any attempt by Apple would suffer the same fate.
An app store in the Steam mold is another matter, and in fact I’m a little surprised they haven’t already done it. (I can’t see Steam itself being any barrier – they already have the iTunes infrastructure in place, and it’s not as if they’d have any difficulty attracting developers.)
The old barriers to entry for Mac development were the alien processor architecture for PC developers, the limited RAM & the lack of DirectX. Are any of them still problematic? Are there any more barriers that I’ve not mentioned?
Pre-OS X memory management was a pain, but endianness and the specifics of the graphics API were never the real difficulty. Or at least, they were only a difficulty when the Mac was an odd niche market that publishers didn’t look at until they’d finished the game and wondered if there was any more cash to be squeezed out of it.
If you develop with multi-platform in mind from the beginning, you just need a slim little abstraction layer and it’s all pretty straightforward. The real change that’s happened here is not so much the hardware as the general resurgence in Apple’s fortunes. It’s no longer a niche; it’s something you develop for as a matter of course.
Are there middleware licensing issues porting to Mac? Do you use any middleware?
The less middleware I use, the happier I am. My current engine has no external dependencies – if a platform has a C compiler and something resembling OpenGL, I can build my games on it.
Are porting houses necessary with these changes?
If you’re a Windows developer making Windows games, then a porting house will save you an awful lot of work. But you’re paying someone else to do what is really your business, and for your next game you have to get them in again to do pretty much exactly the same work.
I’m definitely a believer in controlling that side of things myself. If you have a codebase that builds on two platforms, you’re most of the way to having something that builds on absolutely anything. There are odd little devices popping up all over the place at the moment, and I like being in a position to take advantage of them.
That’s the case for games at any rate. As mentioned before, while a game UI is a game UI, a native application really needs a native UI. If your target platform isn’t also the computer you use every day, you’ll probably make something that feels all wonky and wrong to people who do use it every day. That’s where a porting house can shine.
Do you find any differences between Mac Gamers and PC Gamers?
Of course! Mac Gamers are smarter, wittier and more attractive. FACT.
Why is GSB going to be SO AWESOME on the Mac?
Well, GSB is indeed going to be SO AWESOME, but you’d have to ask Cliffski for the specifics.
The Mac version of Ancient Frog is going to be startlingly prettier than the iPhone version. I’ve re-shot the textures (some of the iPhone originals were captured using a little 5MP compact digital – the new ones are hot off the full-frame sensor of a Canon 5D mk II), so it really shines fullscreen on a hi res Cinema Display.
Thanks and stuff!