Cargo Pod Challenge

The main problem for a game developer (these days) is that the gamer is (typically) far more savvy and gameducated (yep, made up word) than us lucky first generation gamers were.

We were grateful for ‘go collect a cargo pod’ runs as a Mission, because we’d never had games that allowed such ‘open’ gameplay before; it was all new.

Nowadays it’s all old hat, and ‘run of the mill’ grunt work no one really cares about, or cares to do.

Players (rightly) want more challenging, more complex, more diverse. This is all well and good, but the costs of this can be very, very high to a developer. All these shiny things require more game features, which all require more design, more infrastructure, more development, more assets, more support, more QA. I’ve been watching the AAA game studios from afar – with interest – as they paint themselves into an ever more demanding corner. Content gets better, detail ever more richer, costs go up, budgets go up, prices for the games go up… but the gameplay itself isn’t keeping pace, overall. Sure there are superb examples of stellar gaming with these stupendous budgets, GTA 5 leaps out, but the majority of others are starting to look ‘damned fine’ but play pretty much ‘the damned same’.

I do wonder if/when this cycle will collapse entirely… with big budget games with big resource demands and big price tags simply leave game buyers refusing to shell out… or will they be upheld by a larger and ever growing gaming population? Every new generation wants more games, more content… it’s an interesting time for the games industry, now challenging (if not beating) Hollywood movie budgets, and movie industry revenues.

It’s such a shame the (UK) funding model for games is still so shite. Especially for indies and new talent.

Anyway, that all said – pardon my diatribe – Dominium won’t be falling foul of becoming resource bound in a quest for AAA challenging visuals 🙂 I simply don’t have the time or (any) budget. Perhaps (my hope) is that with time that may come. For now, I have to rely on good gameplay, as it’s (ironcially) the cheaper option!

So how come I’m poking at ‘other’ games with poor gameplay, and then banging on about doing ‘missions’ which involve collecting a cargo pod? I shall explain…

Consider every mission you’ve ever tried in any game you’ve ever played – yes any. No matter how complex, how convoluted, how involved or varied it is, there is a fundamentally basic pattern underlying it, one that is frankly unavoidable for most ‘missions’;

  • You (in some form) go to a location (level, area, building, planet, whatever).
  • You perform a task of some form – blow something up, collect something, etc.
  • The task succeeds. Something happens to progress you – the player – or the plot, or both.
  • The task fails. Something happens to punish/thwart you – the player – or the plot, or both.


If you can think of an example which doesn’t fall into the above pattern in some form, please think about it again very carefully.

If you can still think of an example, please let me know 🙂 because I want to add it to my research board!

With that pattern in mind, getting the infrastructure of the game engine to support collecting a cargo pod pretty much should (more or less) provide the support for a diverse range of mission types. When I say ‘mission’ at the moment I mean ‘job’ or task. A job being ‘do this, get paid, thanks’.

Missions will be more involved and (generally) be for enforcement entities (police, intel, navy, etc.) or some of the larger corporate entities in the game universe.

Building that infrastructure is onerous – trust me. That’s what I’ve been doing for a while. I want missions to be configured from easy to author files, and therefore easy for anyone to mod to produce campaigns and the like. Supporting that is a big challenge, and I can’t do it from day one, but the intent is to create something flexible that will support it in the future without the need for major restructuring or refactoring.

I have to bind text in these files to game objects, their parameters and methods in run-time code. I have to be able to instantiate objects at run-time based on the requirements of a mission. So that means parsing these files, checking everything it parses, reporting errors, binding text descriptions to objects, methods, parameters and messages. Then all the objects that this creates have to interact with each other, so success and failure can be determined, the UI also needs to know which missions you can currently undertake, so it needs to know the mission requirements and check them against your current capabilities, and so on, so on, so on. Lots and lots of really boring stuff, before I’ve even got to being able to see the Cargo Pod I’m supposed to go and collect.

And I haven’t even got to the meat and gravy yet… something I hope to achieve and promised back in the original Kickstarters. Everything you do in Dominium (success or failure) will generally have consequences…. and did I mention that this Cargo Pod you collected… what if you decide to deliver it to the job owners enemies instead…

Anyway, no whinging, just a lot of coding, but I’m getting there… 🙂


  • Facebook
  • Twitter
  • Myspace
  • Google Buzz
  • Reddit
  • Stumnleupon
  • Delicious
  • Digg
  • Technorati
Author: Mak View all posts by

Comments are closed.

Subscribe to The Dominium Observer Newsletter!