Interview: Paul Dean and Simon Roth on Maia.

You were one of the early, shock Kickstarter successes. How much pressure are you feeling from that?

Paul: Personally, it’s a feeling of considerable obligation. There’s always the awareness that people have already paid you, that they’ve invested up front, and now it’s your job to justify that financial faith they’ve put in you. And you’re reminded of that quite starkly whenever you meet someone who happens to mention they’re a backer. It reminds you that the money is very real, the people are very real and that you’re being counted on to do the project justice.

Simon: Prior to the alpha release, it was a source of intense anxiety for me. I had no idea what sort of reaction the game would get and had an awful lot of people waiting to download.

Once we started releasing alpha’s, the pressure has dropped off significantly. Having tried out builds and seen the prototype of my vision they seem really happy to sit back and allow me to engage my creativity. It’s fantastic to have that level of trust put in our vision.

Maia was pitched as Dungeon Keeper in Space. Has it changed through development?

Simon: The foundation of game has been set in stone in my head for quite a while and few of the core features have changed since the Kickstarter. Having to describe the game in detail over the course of the crowdfunding allowed me to clarify and lock down down my ideas.

A lot of the smaller components have been tweaked for usability reasons, and a lot of extra detail has been designed into the game’s simulations as I’ve iterated them and brought them to life. Due to this, things have been slower to develop than I’d of liked, but the end product is turning into something far more rounded and detailed than my initial plan had foreseen.

You’ve never hidden your contempt for some old-school game developers. What is it about the old AAA developers that riles you so?

Paul: I’m interested to see what Simon says here. Personally, one of my favourite things about indie development is how relatively transparent it is and how the usual membrane of PR is absent. People are able to be much more frank about what they think, about what their jobs involve, about how they’re doing. That benefits all of us, whether developers or journalists or audiences, because with transparency comes truth.

Simon: Hard to nail it down really. I guess at a fundamental level it’s their loss of imagination. Chasing after mythical mass audiences at the behest of publishers has really killed the wonder that brought a lot of people to this medium.

Stemming from this I am really frustrated at how they run their businesses and treat their staff. The concept of crunch flies in the face of a hundred years of research into workforce productivity, common sense, and frankly, quite a few laws.

Maia seems to have attracted a truly international audience (and it was certainly weird being asked, deep in rural Croatia, ‘do you know Simon Roth?’) What does that mean for development, as an indie? Are you trying to support other languages?

Simon: The wide audience is very cool. Having twelve thousand people testing and picking at the game is far less of a weight on development as I had expected and provides me with some serious QA grunt.

One of the interesting effects on development was receiving instant feedback from gamers who usually struggle to get their voices heard. I’ve had detailed advice and critique from colour blind users and even talked to a couple synaesthetics who reviewed the game on how it tasted!

Language support is something I am building in from the core so we can translate all the text quickly and easily. I’ve left the formats open, so anyone can do their own version of the game. This will let us crowd source the bulk of the work and then have it proof-read and cleaned up professionally. I can see some interesting challenges in moving some of our dryer British humour into other languages.

Paul: I know that Simon’s dropped in a character set to support Norwegian characters and we hope to include room for other language versions of all of the text I’m writing. I won’t be doing that myself, mind, but the simplicity of the game’s XML files means anyone could add a translation, probably for any language (with a Latin script) they wanted.

Paul, can you reveal anything about the story you’re working on? How are you differentiating it from the usual SF games tosh, which would be flattered to be called pulp fiction?

Paul: The basic framework of the story was already in Simon’s head before I joined. We’re keeping some of the details secret, but we’ve already revealed that the ultimate goal of Maia’s first colonists, those you’re controlling, is to build a space elevator. This towering structure sits on the equator, reaches up through the atmosphere into space and works far, far more efficiently for transporting materials to and from the surface than any number of space flights and landings. Really, the priority of Maia’s pioneers is nothing more glamorous than extraterrestrial infrastructure, paving the way for more and bigger projects. It’s just a job.

Hopefully, we’ll get a sense of this through the game’s writing, which I’m trying to make dry, droll and occasionally irreverent, a lot like many of us are when we find ourselves in day-to-day drudgery. This is a reality where contracts are awarded to the lowest bidder, where space travel is slow and boring, where corners get cut and where tired people are sometimes negligent. Also, the people sent to other planets are practical, they aren’t poets who have romantic notions about what they’re doing.

The idea is that it won’t be high drama and it will also be somewhat underwritten. Too many games have too much story. They’re too concerned with writing lots of plot and then serving up lots of plot and then pointing at that plot to make sure you’ve seen it. We should be showing rather than telling. That goes for directing players, too. Simon very much likes the idea that we don’t have a patronising tutorial where we tell players they have to feed and hydrate colonists, just that we have the simplest, most succinct reminder of how long a person survives without food, without water or without oxygen. Who honestly needs a game to say “Don’t forget that people need food?”

How many people are working on the project? Where are they distributed?

Simon: The team is fluid and can be five people one day and twelve the next, depending on what our current focus is. I’m keen not to enter people into exclusive and controlling contracts, allowing people can work on their own projects or even for other companies. It keeps everyone on their toes creatively and stops me having to worry about things becoming stale or stagnant – like a lot of full-time AAA work can become.

Geographically, we are mostly in the UK, but the Team is multinational. Interestingly, we also have a solid gender balance in the team, something that I eagerly point out to certain AAA developers who claim that women are unrepresented in industry. From my standpoint I haven’t seen much a differentiation between numbers of quality male and female candidates ( There are more unskilled male applications, but when you whittle them down it’s far more even). I think larger studios are perhaps misreading their own PR and HR problems as a gender skills gap.

You’ve made very early alphas of your game available to backers. Do you think this ‘endless beta’ model is the best way for developers to go?

Simon: I think for some games, especially ambitious indie projects, it will become the de-facto method of development. Obviously your design and processes need to gel with it, but the benefits are huge. In my case, without it Maia, in its current form, just couldn’t happen.

Paul: Sometimes. It’s a strange thing for me to see games grow like this, but once you have a core that people can play with, you can keep building around that to add new elements. The big question is how soon you release that core. Too early, and you give people too little to play around with.

Naturally, this doesn’t work for every sort of game. It’s ideal for games that are different every time you play. It worked for the first incarnation of the roguelike platformer Spelunky, or for Minecraft, but it’d hardly suit a point and click adventure or a plot-driven RPG. Something linear like that doesn’t invite replaying with new elements added in.

Spaniels? Chickens?

Simon: With the game drawing inspirations from Dungeon Keeper I wanted to have a few direct references. Chickens were the natural choice, as they could fulfil the role of livestock in the early game. They have an AI that acts purely on base impulses, without any forethought or risk assessment, which leads to some amusing emergent behaviours and will hopefully provide an interesting contrast to the more complex higher-order intelligences of the other lifeforms.

Adding the pets of our Kickstarter backers to the game has been really fun, and allowed us to focus on them as solid characters in the game-world. Cats and dogs have had a symbiotic relationship with humans since the dawn of mankind in the palaeolithic and will likely continue to evolve along side us well into our futures. Having them fulfil rolls in future space colonies is pretty much inevitable.

It’s also important to note that more dogs have been into space than British people!

Paul: There are cats, too. In bee costumes. Admit it, it’s what you’d send to another planet.

When do you envisage the project being done?

Simon: The 1.0 release is sitting in early 2014. I’m not entirely sure when we will be able to nail that down, however we have some key milestones coming up this year, such as the Steam release and the addition of the alien food chain. The game in my head in massive, yet the design is complete, and I am quick to stamp out feature creep. Whether I will ever be happy enough with it to call it “done” is an interesting question…

Not to mention, I’d love to pick up the final stretch goal from the Kickstarter and produce different planet types as free expansions next year.

And, then, what next?

Simon: I have a lot of embryonic games in my head, on paper and even a few prototypes kicking about my hardisks. Firstly there’s a technoir adventure game I’ve been wanting to make for a while, a primordial life simulator, and a first person survival RPG set in the Maia time line.

Any merchandise? T-shirts, thumbdrives, board games…?

Simon: At some point I may put some together (beyond the posters, wristbands, and other stuff produced for the Kickstarter). Currently it’s too much of a distraction, doing physical manufacturing in an ethical manner really eats up time and money.

A board game would be fantastic, mind you. I’m sure Paul could flex his muscles on that one. I’ve also been thinking about getting some Maia mission branded survival tools; dehydrated foods, flint-steel fire starters and even military dog tags.

Once the game is demanding less of my time, I’d like to put together an anthology of short science fiction stories from different writers, exploring aspects the world we are creating. The game has sparked the imagination of a lot of excellent writers and I’d love to see their take on it.

I’m also working with Nick, our composer, to release an album of the game’s 70’s inspired synth-heavy soundtrack. We’ve had a lot of interest from composers in doing a compilation of music inspired by the game for B-side for it.

What sort of situations will players end up in the game? Can you walk me through an example scenario?

Simon: The game, due to its various interconnected simulations will yield all sorts of unforeseeable scenarios for the player to deal with. Here’s one based off our food-chain simulation:

A player focussing on rapid expansion of their base has large power needs and decides to build a large wind farm on the surface of the world. To do so she defoliates an area and sets up heavy defenses. Clearing a large area of grass and plant life unbalances the food chain, killing off the native herbivores through starvation and the odd 7.62mm round to the head.

This causes the larger carnivores, usually reliant on the herbivores to plug the new gap in their diet with the player’s colonists. Through trial and error, they eventually learn their way around the players turret systems and start intruding into the colony looking for tasty morsels.

The creatures tear through the airlock seals, rapidly depressurising the hastily designed base, the lights drop, alarms sound and the colonists start to asphyxiate. By the time the creatures find the colonists, the poor souls have slipped into unconsciousness and in their helplessness, are eaten alive.

Paul: Maia is being colonised partly because it’s similar enough to earth that colonists can make use of its natural resources to complement what they’ve arrived with, since there’s only so much you can cart twelve light years. Mining and excavation will provide many of the same metals and materials you’d find in the earth’s crust, while it’s also possible to use solar stills, wind turbines and solar panels to gather energy or clean water. We have a very humid hydroponics bay where vegetables can be grown and regrown but, who knows, maybe some of Maia’s own life might be edible? Eating cats surely has to be a last, resort, right?

That said, the surface of the planet is largely inhospitable. Everything’s happening underground because that’s out of the wind, solar flares and meteorite impacts.

Interview: Transgaming & CCP on Mac Gaming

To the tune of: Tim Curry – Sweet Transvestite

Another interview that I felt guilty about woefully under-using in a feature. Still about making games for Apple Mac, but this time I was talking with Transgaming, who convert PC games to Mac for large publishers and developers, and with CCP, who’ve used Transgaming to transfer Eve: Online to Mac.

Gavriel State


(Which is an awesome name.)

What differences in tech are there between a Mac and a PC?
From a hardware perspective, Macs and PCs are very similar these days – they share elements like the CPUs, graphics cards, and memory. The biggest hardware difference is on the desktop side, where most PCs use add-in cards for graphics, while the iMac has the graphics chip built directly into the system. Only Mac Pros have upgradable graphics cards on the Mac side.

The real differences come in the software side, where the operating system and driver layers for the systems are radically different, as are the APIs used by applications.

What needs to be adapted to make games on it?
TransGaming’s Cider technology makes it very easy to bring PC based titles to the Mac, by bridging the API gap that is the most important thing separating the platforms. For example, Cider takes care of the work of adapting a games’s DirectX API usage for graphics and sound to OpenGL and CoreAudio. Beyond that, TransGaming’s work typically focuses on user experience areas – components such as launchers, patchers and the like need to be rewritten using Apple’s Cocoa APIs. In the case of EVE, we worked hard to ensure that components such as the in-game browser were built with Mac-based browser code, so that UI elements inside the browser on the Mac match what they look like outside the game.

Eve graphs make me happy.

Are simultaneous releases feasible?
They definitely are! Mac updates for EVE Online expansions and patches are released simultaneously with updates on the PC. A close working relationship between CCP and TransGaming, built on constant communication, has been paramount in ensuring that updates are prepped in advance for such dual-platform releases.

What disadvantages and advantages are there in developing for the Mac?
One nice advantage to developing for the Mac is that there are relatively few system configurations that must be supported compared to PCs. Most Mac gamers are quick to adopt the latest OS updates, especially compared to what happens with PCs.

On the flip side, because the Mac OS is so tightly integrated with hardware, Mac users only get new updates to video drivers as part of the OS. This is great for users, since they never have to think about whether they have the right driver version, or finding out where to get updates or what particular version of the driver to get. But for developers, it means that sometimes a fix for a game has to await Apple releasing that new OS update. It also means that its much harder to support older versions of the OS which are no longer receiving updates.

There are dangers in closed systems – do you know whether Apple will implement a system similar to the iPhone’s app store?
On the contrary – traditionally, closed systems have been much easier for game developers to deal with, since they tend to further reduce the complexity of having multiple configurations to deal with, whether on the software or hardware side. That said, while Apple may well at some point in the future introduce an app-store type system for the Mac, the Mac is by its nature an open platform where anyone can develop software. That’s something that will never change.

The old barriers to entry for Mac development were the alien processor architecture for PC developers, the limited RAM & the lack of DirectX. Are there any more barriers that still cause problems?
While some of the old barriers such as CPU differences are behind us now, there are still many significant impediments to developers who try to do traditional porting. Doing so can require massive changes to a game’s source code just to get the game to compile on the Mac, especially when complex middleware is being used. In some cases, developers don’t have source code access to their middleware, making a traditional port impossible. And all of that is still ignoring the need to write new graphics and audio paths in the game, which in some cases can require changes to the actual content data.

This is where TransGaming’s Cider technology really shines, since developers can maintain their existing build systems, continue using the same middleware they’ve adopted, and fully use their existing graphics paths. At the same time, areas that touch on user interface can still be customized for the Mac, and other places that need attention require much less effort to deal with than a traditional port. Finally, some of the changes that TransGaming recommends developers undertake to improve the Mac version of a game are just as applicable for improving the Windows version, so the code ends up remaining the same for both platforms.

Spaceships, yesterday.

Are there middleware licensing issues porting to Mac?
While we can’t speak to specifics, it all depends on the middleware provider. Some have platform restrictions in their licenses while others don’t. Aside from middleware components from Microsoft, we have yet to experience a situation where a middleware issue made it impossible to bring a game to the Mac.

Are porting houses still necessary? What’s this Cider app we’ve heard all about?
The kind of porting house that used to be typical of the Mac gaming world is likely to have little place in its future. As the Mac becomes a bigger and bigger percentage of the overall PC market, more and more game developers and publishers are looking at getting into the platform directly, rather than trust their IP and profit margins to third parties. For more and more of these players, Cider is the technology they turn to when they want to go this route. By engaging with TransGaming and licensing Cider, game developers and publishers can bring their games to the Mac far more quickly than was ever possible before, and they can be directly in touch with their customers instead of going through a third party.

What’s more, the same technology behind TransGaming’s Cider is now being deployed on next generation TV set top boxes through a platform we call So developers who move to the Mac with TransGaming also have the opportunity to reach an even bigger audience in the future!

Gabe Mahoney


Will CCP continue to develop all its games for the Mac?
As long as we have a strong contingent of players playing on the Mac, then absolutely yes. And there are no signs that are Mac subscriber numbers will do anything but continue to grow. We have more and players using the Mac client as time goes on as OSX gains market share and becomes more of a gaming platform.

Do you find any differences between Mac Gamers and PC Gamers?
To be honest, not so much anymore. While the Mac used to be more of a specialty OS for graphics designers, musicians and other creatives it is now gaining a lot of traction with business and general home users. This means that more people are using Macs as their general purpose computer and are expecting it to run games as well as their PCs. I think this trend will tend to create homogeneity between Mac and PC gamers and wise developers will embrace both platforms equally.

Interview: James Brown, Ancient Workshop

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

The Frog Prince

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!