I don't want a real job - Part 2.

[Mark]

Last month I wrote the first in a series of articles, aimed to help budding game developers found their own studios and how to avoid being developed, trained, integrated, educated and moulded by the mainstream until all creative spark has been utterly extinguished. Last time we looked at ideas and I tried to gently provide some guidance on what is a bad game idea and this time I want to talk about the prototype.

It is important to note that I have not written – “How To Get Funding For A Prototype” – because it is virtually impossible to secure money before you have something to show. Even if you have the most fantastic idea in the world, you have a much, much better chance of getting somewhere if you have an actual tangible game, than if you only have a few scribbles on paper (even if those scribbles do include some amazing concept art and a ton of design work). Now I’m sure that there are people in the world who have managed to get development money for a prototype (and there are grants out there to give you some funding), however these people are few and far between and my view is that you have a much better chance of getting funding for principle development if you have a prototype worked up. So if we assume that you and your mates are going to have to work in the evenings, weekends, during lectures and on the tube, we’d better start to look at what you are trying to achieve.

There are two main objectives for the prototype, the first is internal, the second external. Once you have a game design (or even just an idea in your head) it is necessary to start experimenting with bringing that design into the real world. The major challenge with game design is that the end product must be fun to play, and sadly it is very easy to take the fun out of the game. You can produce an incredible game that looks stunning, includes an amazing back story, has great game-play mechanics, but if you get the control mechanism wrong the whole thing will collapse before your eyes. Of course in different games, different aspects are more important (the story is perhaps less important in Half life than in Mass Effect), but you may not be able to determine this at the start. The point is that until you actually have the game in front of you, then you do not necessarily know which areas of the design work, which need tweaking, and which are fundamentally flawed. This is where your prototype comes in.

At Introversion we loosely adhere to a spiral software engineering paradigm and I would recommend this approach for developing a prototype. The first stage is to sit down and determine the scope of the project. Whether you are aiming to produce one complete level, or small area of your game world, or perhaps a large area with only some elements included, you need to understand and stay focused on achieving this objective. When you choose the scope you need to try to deal with the most uncertain part of your design. Which areas are you least confident in? Which areas are of most importance to the player? Where are the technical challenges? Asking yourself questions like these should help you determine what to include in your prototype and what to leave until later.

Once you have determined the scope I would recommend a quick first pass to get something playable as soon as possible. Try to avoid getting bogged down with low risk detail, at this stage you should not be making the game look great or worrying about implementing your maps perfectly, just get something working. Once you have completed your very raw first version, you can then complete a second pass where you start to deal with the next layer of detail and finally (if there is time) you may want to do a final pass for polish.

The above approach provides a good deal of momentum for your initial work. It enables you to tackle the hard problems first and not get caught up in something that might ultimately prove impossible. If you get stuck, try to solve the problem for a couple of days, and if you don’t make progress just move onto the next problem and worry about it in the next phase. It’ll inform you about the quality of the game design and enable you to make massive global changes without having to go back and re-do all the detail. The method has served us well in the past and if you have been reading Chris’s Subversion development blog you’ll see that he is constantly switching between different aspects of the game whilst he improves his design.

I also mentioned that prototypes have an external (secondary) objective and that is to convince someone (publisher, investor, government body etc.) to give you some money. If you find yourself in a position to use your prototype in this manner then you need to bear in mind one fact. The publisher will run your .exe once and once only. If it doesn’t work, game over. If it is not obvious what he needs to do, game over. If it crashes in the opening few minutes, game over. In short do not expect any slack what so ever – you will not get it. This means you must test your prototype, fix the bugs, and make 100% sure it will run. This sounds simple, but I once told a developer that I was off to see Microsoft and I would show them his prototype if he could get it to me. He sent me three e-mails, each with a different build (he kept fixing last minute bugs), and none of them worked. Sadly that was his chance blown for an XBLA deal. I’m not going to deal with testing in this column, because there are a ton of books out there on the subject, but I leave you with this thought: If Uplink had crashed when Kieron Gillen put it in his PC, where would Introversion be now?

[skull13]

Dead. Utterly dead...

Without knowing, I have actually followed this design. Wow...

If anyone wants to see my game, then go to thiscompletely shameless advertising link right here!

The next step is upgrades, then autoturrets, then autoturret upgrades, and a final graphical polish. Wish me and my partner good luck![/url]

[martin]

I love project Crash martins web browser ¬¬

once again, another most interesting insight into IV

[skull13]

Wait, what? Mine isn't crashing...

Is something wrong with your computer that would prevent my totally legit project from working?

Edit: The scratch viewer is a java applet. Just an FYI.

[KingAl]

I love the fact that this happened after Mark's final paragraph. Go Go Irony!

[Mas Tnega]

I can't live in a world where that's not a massive parody of bad game design. It's too well thought out.

[skull13]

Shut UP! It's NOT my fault. Several computers work with it, including all of the ones at my school. My computer at home runs it fine. Odds are, its MIT's fault (They made the applet and website) rather than mine.

[Pox]

Oh yes, all MIT's fault.

[skull13]

Well, I would package it in an exe file for you, but I am running OS X so, just DEAL WITH IT and cut me some....

In short do not expect any slack what so ever – you will not get it.

GODDAMMIT!

Edit: Have you even SEEN the game yet?

Edit again: [meanie] Any IDIOT who doesn't have at least TWO browsers is an...idiot...[/meanie]

[Pox]

Worked fine in Konqueror for me, must be all those windows people with their "universal compatibility" and "corporate stability".

Also, if it's written in java, can't you package it as a cross-platform brick of bytecode for the JVM to read? Isn't that the whole point?

[shinygerbil]

Worked fine in Opera/Windows for me. Must be all you people out there with that badger browser. Or was it hedgehog? Something about a fiery hedgehog. Firebadger sounds about right. Either way, it's a useless piece of junk, you should ditch it, and go with Opera.

[KingAl]

I dunno, I'm liking the "martin can't use browsers properly" theory better

[Andy``]

The publisher will run your .exe once and once only. If it doesn’t work, game over. If it is not obvious what he needs to do, game over. If it crashes in the opening few minutes, game over. In short do not expect any slack what so ever – you will not get it. This means you must test your prototype, fix the bugs, and make 100% sure it will run.

This is, obviously, very important and I can imagine quite easy to slip up on when you're not used to presenting projects to publishers (or anyone really) all that often, but I'm curious - how much weight is given to the possibility of outside interference causing the game to break? I'm thinking of PC games mainly here since consoles are a much more tightly run ship, but how much of a concern does the possibility of virus scanners, other programs or simply odd settings in Windows ever become when you're giving your shiny new game to publishers and journalists so they can install it and play it on computers you have no control over? Sounds like a silly question, because once the game is released you wouldn't expect to have control over their computers and how they use them, but some pretty nasty problems can be observed in released programs being run in combination. Windows Media Player used to like crashing Firefox on my PC a while ago (pre-FF2), and I've had one game I bought - when run along with another often-used-by-many program - crash my graphics card to the point where I nearly thought I needed a new graphics card.

And this came to mind because that could be what happened to martin with skull13's game, I suppose. The game ran fine for me on IE7, FF, Opera and Safari (Windows), but how would skull13/[insert developer here] know that martin/[insert publisher or other interested party here] couldn't run the game because of an out of date driver, a different operating system, or another program running in the background: like anything ranging from an obscure program nobody else has really heard of to the enterprise edition of something which could be a little difficult to get a hold of to test on but the interested party in question needs for their operations.

What's the best way to go about avoiding problems with outside influences besides a brute force checking with every program that you can find, and (mainly for the less well-funded startups or independents) when you can't check your program on an especially large range of hardware?

Oh, and good luck skull13

[Pox]

The problem is that the person you're sending the game to most likely doesn't care why it broke - they're going to throw it away and your chance is blown. The best bet is to test your game on as many test platforms as possible, and to ensure you include absolutely everything it depends upon.

[zach]

Either way, it's a useless piece of junk, you should ditch it, and go with Opera.

Actually, Firefox was alright before the 1.5 update (and obviously the 2.0 update didn't make things better).

If you can do without flash, I recommend Mozilla Phoenix. I've had my hands on Opera for some time, but found it too ... I don't know how to put it. Where IE is slimy, and Firefox has rounded borders (metaphorically, of course), I think Opera is a bit too square.

Agreed, Opera beats any Firefox browser past 1.5 (and since they're not updating that anymore, it must by definition currently beat Firefox).
I've never tried Safari in Windows, and I just don't like Konqueror - or KDE at all for that matter.

Obviously martin's game doesn't work in Links, either