Today I’m going to write a little about my game’s core concepts as well as the basics of a project’s pitch.

Project Summaries

Whenever you tell people that you’re working on a screenplay/novel/game/iPhone app the first thing they’ll ask you is, “What’s it about?”  Depending on their relationship to you and how much time you have you’ll either give them a really succinct overview or an in-depth description.  Typically if you’re pitching to companies/executives/etc (either in person, letter, etc) they want as brief a description as possible first (we’re talking a sentence or two), and then if they’re interested they’ll want a little bit more (about a paragraph).  If you realise that they have dozens of projects pitched to them each week you’ll understand why they don’t want to have to review your ten-page treatment to decide if they even have some initial interest in your project.

So the two things you need to describe your project are a one-sentence pitch and a one-paragraph description.

The one-sentence pitch (also known as a ‘log line‘ or ‘higher concept‘) is exactly what is says on the box: a single sentence to describe the project.  It can be something as simple as a description of the gameplay (“It’s Mario meets Halo with RPG elements!”), or you could mention the game’s world or back-story to suck in producers (“A plumber wakes up in space surrounded by hostile aliens intent on eating his girlfriend!”), or it can even be something really abstract that helps to set the tone of the project (“There’s a reason they don’t send 4-foot plumbers into space, but that didn’t stop him going!”).  (All the exclamation points are entirely optional ;) )  As an example I remember reading that the higher concept for the TV show Firefly was something along the lines of, “Nine people look out into space and see nine different things.”

It can and should be tailored to the audience you’re giving it to (e.g., publishers might be more interested in whether the genre is selling at the moment more than the particulars of the game world), so you might want to have several different ones handy.  It’s also continually evolving as the project changes and becomes more refined; you might find that the game you end up with isn’t quite what your pitch describes and need to update it.  That said, it doesn’t need to cover absolutely every aspect of your project, and sometimes it simply can’t!  Your pitch might not have room to mention the vehicles or customisable pets your game includes.

The one-paragraph description (sometimes also called the ‘elevator pitch’) is, again, exactly what it says it is: a single paragraph going into slightly more detail about the core aspects of the project.  The way a lot of people describe this is to say that if you walked into an elevator with Steven Spielberg and only had 30 seconds to say, “Mr Spielberg! I have this great idea for a movie!”, how would you sell it to him?  Again it doesn’t need to (and probably shouldn’t) cover absolutely every aspect of the project, only what’s relevant.  For example if the art style was intended to be ‘standard’ for the day then you probably don’t need to bother mentioning it in the elevator, but if the fact that it’s cell shaded is a selling point then make sure you do.

Despite their obvious value when seeking funding, publishing, etc, both the one-sentence and one-paragraph pitches are great to help you focus your ideas, especially in the early stages of development.

My Project

Higher Concept: Play both sides of tower defence.

Elevator Pitch:  Build towers to defend your mining infrastructure while you repair your crashed mothership on a hostile alien world.  Launch drop-ships to spawn and send waves of infantry against your enemies to disrupt their own repair and upgrade efforts so you will be the first back into space.  Different towers will distract different unit types, so watch your enemy and built your strike forces and defences strategically.

Later this week I’ll go into a bit more detail, but hopefully this is enough to whet your appetite.

Firstly, a few definitions for the uninitiated, because people quite often get confused.

A Graphic Engine is a system that handles the display of, you guessed it, graphics onto the screen, manipulating meshes and lights and textures.  They often come with lots of helpers, such as file imports for meshes and textures, and most will render in OpenGL, DirectX and possibly even their own software renderer.  While learning about computer graphics and even game programming in general people often build their programs around the graphics engine, but it is really a component of a much larget system.  OGRE3D is a good example, and probably one all wannabe game developers (especially indy ones) are familiar with and one I highly recommend checking out.

A Game Engine is a system that ties together numerous sub-components (including a renderer, physics engine, scripting, audio, etc) into a unified package.  Some are highly specific to a genre (e.g, the Quake engines are geared towards FPS), where as others are genre agnostic (such as Unity).  Usually the engine will give you a way to load in your meshes, add some physics, give them AI through scripting and you manipulate them.  When rolling your own you’ll tend to base it around your own design patterns and coding philosophies, as well as (probably) tailoring it to fit the game you’re making at the time.

I’ve got several engines on my hard drive that I’ve built, one for PC and one for iOS, with the latter in a much more usable and feature-rich state than the former.  If you bake your own, your component shopping list will look nearly identical to mine:

• OGRE3D for rendering
• PhysX for physics
• RakNet for networking
• FMOD for audio
• OIS for input (not to be confused with iOS)

I read a recent interview with Davide Coppola where he says that he built his own iOS engine for his game, saying that it gives him valuable experience with the technology and it’ll benefit him when he eventually leads a larger team.  I do agree that the experience is invaluable, which I already mentioned in the previous post saying that my learning OGRE3D and PhysX helped me understand Unity quicker and in a deeper way.  Davide is, however, extremely dismissive of using 3rd party engines (such as Unity or UDK) because of some implied apparent limitation, and here I have to disagree, and I only have to point to practically all of Valve’s recent lineup as evidence.  Team Fortress, Portal and Left 4 Dead all started as mods to their Source engine, the results of which were so promising and impressive that Valve bought them and rolled the tech into updates to Source.

Granted, you may reach a point where your current engine isn’t adequate for where your company is going, and you might either have to extend the engine yourself or move onto a new one or, yes, even roll your own.  I believe experience working on other existing engines is just as invaluable when designing a new one, if not more so than living in the isolated bubble that is your own software.  Learning lessons (what works and what doesn’t) from other programmers is the best way to learn in this industry, and especially when you’re just going to be rehashing the same work of tying together a renderer and physics engine, then learn what others have done and why it wasn’t right for you will help with your design.

He also makes the point himself that one of his games has had a 4 month development cycle: 2 months to build the engine, 1 to build the game and another to port it to Flash (and if I understood him correctly, some improvements he made in the flash version he now has to go back and patch into the iOS version).  So literally 1/4 of his time, as a small indy developer, has actually been concerned with building his product instead of putting out another 3 games he could be selling to build his portfolio and coffers.  He’s obviously talented, resourced and able, so why isn’t he putting out more games?!

The decision, though, is yours on whether it’s more important to you to gain programming experience building your own engine, or whether you want to get more games out and under your belt.  Perhaps it’s easier for me to make my choice because I already have the engine building experience for if/when I need it, but I’m sure it’s not just me in this boat.

As state, a few of the general goals/features for the project are:

1. It needs to have a fast turn-around time
2. The technology requirements are pretty standard
3. A small/nonexistent budget

and this is all before I’ve even finished the design document (i.e., more work).

Using a pre-existing game engine takes care of #1, as I’d only have to invest a short amount of time in learning its systems.  Unity has the advantage in that it’s extremely easy to use and I’ve had some previous experience with it, so it really only took me a weekend to get up to speed.

Given #2 means my choice of engine can be less picky because any half-decent engine would be suitable.

Knowing that we can collect and commercially use all the major components of a game engine (rendering engine, physics, input, network, sound, etc), and knowing I have the technical experience to put it together, it becomes slightly harder to judge wether it’s (financially) better to build your own or buy a premium version of an existing engine.  The main way to estimate the cost of building your own engine when everything is free is to estimate the number of months it will take you to build it and multiply that by the monthly wages of each of the programmers on the project.  If we set this value at between £2,000 - £4,000 per month (approx. $3,000 – $6,000 USD, and would be a very conservative estimate for some programmers), and we assume at least a 2 months development cycle (which, again, is rather optimistic – and this is before you’ve even started on the game itself), the engine can cost you £4,000 - £8,000 per programmer.  It is quite tempting to think that you’re saving money by rolling your own bespoke engine, but the costs are very dramatic, even with free parts!

There’s also the time factor that you’ve spent 2+ months on the engine and haven’t even touch your game yet!  And if you read the first Developer Update you’ll know I’m keen to avoid this type of time (mis)management.

Unity covers all the bases for me.  It’s (obviously) pre-built and I’m already familiar with it, so when it comes time to start coding in earnest I’m not learning how to import meshes or modify transforms (even for those who are new to it, you can easily get going with it in less than a week).  Its features list is ridiculously impressive, and I highly recommend watching the keynote from their 2011 conference (skip to about 34mins in for the v3.5 tech preview).  I’d been iffy about Unity for a while during their 2.x branch; they had an impressive features list, but the indy license was several hundreds of dollars, and given that I’d been burned and disappointed before by game engines I wasn’t inclined to look too deeply into it (many games and graphics engines look perfect on the packet, but once you get several months into a project you discover all their short comings :S   Appcelerator Titanium has been disappointing like that).

With the 3.x branch the basic version (which isn’t lacking as many features as you might expect) is now free and is why I rediscovered it (I’d been keeping a keen eye on its development over several years).  I’m actually quite disappointed with myself that I didn’t jump on board when I first found it, because I can only imagine what I might have developed between then and now.  On the other hand, though, I did spend those years learning the component systems Unity uses, which has certainly helped me understand Unity better and faster.  The Pro version is also quite affordable, especially for a team putting out numerous releases.

I won’t bother republishing all of Unity’s features (just check the link), but one great thing about it is its ‘One-click Publishing’ to various platforms.  i.e., I can publish the same source build of my game to both PC and Mac, and with some minor tweaks of the input code (to handle touch) to iOS and Android.  This is a very important feature, especially as there is a significant market for gaming opening up on the Mac, especially with Steam now supporting it.  The mobile versions do require additional licenses but again, calculate the cost of porting your engine from PC to Mac alone, let alone to iOS and Android, and it’s easily worth it if mobile is the route you’re taking.  For mobile I’d argue that it’s important to use a tried and true engine, because I’ve experimented with a lot of open source iOS systems, and most run great for your typical app stuff with tabbed views and buttons and such, but most struggle with even moving half a dozen sprites around.

So for me the choice has been made and I’m extremely happy, confident and excited to be using Unity!

To anyone familiar with games development (or any sort of software development, really) one of the first things you need is a design document, which is what I’ve been working.  I’m roughly 1/4 to 1/3 through writing it, which sounds like a misleadingly small amount, but at this stage it’s more about getting down what I already know about the game’s systems rather than actually having to think them up.  I may (may) release the design document at a much later stage of development (certainly long after the document itself has been finalised), but for the time being it’s staying under wraps.

The other main thing I’ve been doing is researching and experimenting with Unity3D, which is the engine I’ll be using for the game.  In a later post I’ll discuss my reasons for using Unity versus the alternatives (including making my own bespoke engine).  This is always a contentious topic (Which engine do I use? Should I just make my own?  Am I crap because I’m a programmer and I don’t want to make my own engine??), and it’s a discussion I’ve had with myself countless times over the years, so hopefully I’ll have some valuable insights to save people some time :)

Speaking of Unity, my tests have been to not only refresh myself on the engine and editor (it’s been close to a year since I’ve touched it), but to also test out some coding concepts and evaluate some middleware (eg, the pathfinding solution Unity won’t have until 3.5).  The basic question I ask myself when concepting a project is: Could I program this game using cubes and spheres as the units?  i.e., by stripping away all the fluff, is the game logic doable?  In this case my tests have said ‘yes’, I’ll be able to dive into the project without the need to sit down and learn any major new skills, be it algorithms or otherwise.

Middleware is another contentious issue whether in web development or game development.  Sometimes it’s an easy choice because the middleware is so specialised and hardcore that you just can’t expect to make your own (DMM from Pixelux is a good example).  Other times, such as with pathfinding, the decision can sometimes feel more about laziness than anything else.  Can I write my own A* plugin for Unity to move my bots around? Sure.  Is it a better idea to use an established solution that lots of other people are using too?  Probably.

In an ideal world, sure, the basic systems like pathfinding that might be lacking from your engine you should probably just code yourself (or have a lackey do it) so that it’s all bespoke and ties neatly into your codebase and coding paradigm and plays nicely with your game objects.  When I worked in web development my IT Director boasted that he always wrote all his own javascript widgets (image sliders, mouse overs, etc) and refused to use plugins or publicly available code while the other developer and I used JQuery and the like with ridiculous amounts of success.  The results were that the other dev and I blitzed projects and released powerful functionality in days while the director took a week to have a div switch into a textbox (and it didn’t even run that well :S ).  The bottom line?  Sure, if you have the time, money, people and skills, and if it’ll really benefit your project, then do it.  But if time is a factor and there’s already a (FREE) solution sitting on a shelf for you to take (especially if its evolved into an industry standard with lots of tutorials and resources on the net), then you’re simply stupid not to grab it and use it.

And believe me, I’ll be taking as many of these opportunities as I can.  My goal is to make games, not spend weeks being the hundredth person to write a crappy A* script for Unity.  That’s the whole reason I’m using Unity: while I’m spending (for example) 2 months making my game they’re spending 2 months debugging my engine, giving me new graphics and AI related features and generally making it more badass for this and my next projects!  Sometimes it’s like they’re desperate for my approval, you know?  ;)

I’ve already said a little on what this project is: I, as one developer, will complete a solo game project within  a few months.

From this we have to imply a few other characteristics of the project:

• - Small budget
• - Small in scope (number of levels, units, etc)
• - Simple (but deep) game mechanics
• - Low price-point

My wish-list is:

• - It will be well-received so it can’t be cheap or tacky
• - Sales will fund my next project

These are all just challenges, though.  And like gamers know, all challenges can be beaten and I’ll show you how.

My situation is quite simple: I’ve been living and working abroad for the past year and a half but have recently quit my job to continue my travels, which, ideally, will last at least the next six months.  The situation has been engineered such that I can complete two major life goals that have been keeping me up at night for the last decade:

1. Finish the novel I’m 3/4 through writing; get it sent out to literary agents; keep writing!
2. Build one or two small indy games; each project should generate enough cash to fund the next.

One of the first things you realise when you study programming is that it’s all just about taking a large, unwieldily problem and breaking it down into small, manageable problems.  This is true for basically everything in life, not just when coding algorithms.  This project of ‘build an indy game with a team of one’ seems huge and daunting, and is why there are so many videos on Youtube of half-finished projects and demos, but it’s really not that big of a problem, it’s just a challenge that needs to be planned out and broken down.

My approach to being a one-man game developer is what I’ll blog about here over the coming weeks and months, so stay tuned.

Serenity: Float Out

I don’t tend to troll the Internet for new sources of Firefly / Serenity awesome, because these days they’re few and far between.  Hence when I found Wash’s face (which actually makes me think more of Alpha these days) staring back at me on the shelf I grabbed it immediately with the intent to buy without even opening the cover.

I was initially disappointed by reading ‘one-shot’ on the cover because, hey, who doesn’t want to see a regular Firefly comic?  Even another miniseries (although perhaps more substantial than three issues, Mr Joss?) would be kick-ass.  And, yes, at the end of the day, even a 24-page one-shot is better than nothing.  Well, usually.

The story revolves around three business partners about to christen their new ship, the Jetwash, named in honour of the late Hoban himself.  Unsure of a fitting toast, the trio instead each recount a tale of a past adventure with Wash, presumably their most exciting or fondest memory of him, and it is these three stories that make up the very fatty meat of the book, loosely held together by their conversation in the spacedock.

It’s these three stories that the comic is supposed to be about, but it’s hard to know what the writer’s intention for the book is.  None of the stories expand the Serenity universe, nor fill in anything that already existed, except to name a new planet.

They also don’t tell us anything new about Wash himself that we didn’t already know from the series or movie, and doesn’t give us any greater insight into his personal development before joining Mal and Zoe.  They even try to drum into us that Wash is a kickass pilot, but someone needs to tell the writer that, yes, that’s kind of the whole point of his character and something I didn’t need to be told once he pulled off a Crazy Ivan in the pilot episode.

And at their most basic level, they’re not even that interesting to read.  I can appreciate a short story, I can appreciate (and love) a vignette, but Oswalt gives us nothing to work with.  There’s no real tension because we already know Wash makes it out of every scrape with all ten fingers and toes – as well as the fact that we already know these stories are highlights of his past – and there’s no build-up of drama because they only last a few pages each, which isn’t really a valid excuse.

The writing itself is okay, and didn’t leave me cringing, but I did find myself internally commenting with the word ‘lame’ a bit too frequently for my liking.  Oswalt attempts to mimic Joss Whedon’s typical Buffyverse whit and lingo, but doesn’t even use so much as a ‘Gorram’.  And what he does use comes off as out of place and out of character and that he’s trying way too hard (eg, “Sure you don’t want to brood sexily for a few more seconds?”) to imitate what’s usually one of the best parts of Whedon’s writing and shows.  And given how little the three characters are actually developed (besides titbits about their joint pasts with Wash), being able to say that one seems to be talking out of character is really saying a lot about the overall quality of the writing.

The highlight for me was actually the two small strips at the end titled “Augie, the Littlest Reaver.”  In two panels Augie is able to tell more story (about visiting a family during Christmas) and exude more excitement and terror and emotion than any of the three short stories in the main book.

At the end of the day, all I can really say about this is what I did in the first paragraph: the only reason I bought this is because I am a Firefly / Serenity addict and this comic had a picture of Alpha – err, Wash – on the cover.  The only reason others will (and should) buy this is if they’re Firefly / Serenity fans too; all others, including hard-core comics readers, need not, and will not, apply.

~~

Serenity: Float Out is a one-shot Dark Horse comic set in the months after the movie Serenity, but contains three flash-backs set well before the original Firefly TV series.  It is written by Patton Oswalt with art by Patric Reynolds, with Joss Whedon credited as Executive Producer.

http://www.darkhorse.com/Comics/17-163/Serenity-Float-Out-Frank-Stockton-Cover

People should be thanking me, not screaming. The blood isn’t mine, it’s his; I don’t know why they look so concerned.

I don’t really want to go with the police; I have some friends to see. The nurse I meet is nice, though, and the room she puts me in is clean and comfy. The vitamin she gives me makes me feel a little sleepy. Maybe I’ll rest here for a little while.

[100 words, not including the (non-existent) title]