|
|
|
 |
|
|
 |
I don't want a real job - Part 2.
Posted by Mark
on Thu Apr 17, 2008 3:15 pm |
|
 |
| |
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?
|
|
 |
|
 |
| |
|
|
 |
Notes from the Slippery Slope, Part 4
Posted by Chris
on Wed Apr 09, 2008 2:45 pm |
|
|
| |
So we’ve finally announced it – our fourth game Multiwinia is coming out on Xbox LIVE Arcade and PC simultaneously, with Darwinia and Multiwinia bundled on Xbox LIVE Arcade under the name Darwinia+. Somehow I doubt this announcement took many people by surprise. For those who were paying attention it’s pretty obvious – in the last couple of years we have publicly ported the game from OpenGL to DirectX, added in support for the xbox controller, redesigned the menus to work on living room TVs instead of computer monitors, added in Multiplayer, and teamed up with Microsoft to release a Vista specific version of Darwinia. How obvious can it be?
One of our primary goals for many years has been to escape the peril of “sequential game development” – ie releasing one game at a time, once every couple of years, hoping that each game does well enough to pay the bills until the next one. Ultimately we don’t ever want to be in the situation where money is running short – because it forces us to make the choices we really don’t want to have to make. Multiwinia’s origins stem from our attempts to run two game projects at once during late 2006 and early 2007 – Microsoft had signed Darwinia for Xbox LIVE Arcade, and we were ready to go on game number five : Subversion. This seemed to be an ideal situation – porting Darwinia to Xbox LIVE Arcade was (we thought) a purely technical task, so Johnny (our Technical Director) took charge of the “Darwinia+” team and I went into fulltime Subversion development. Goodbye sequential game development, hello financial security. It took us a few months to realise this really wasn’t going to work.
Microsoft for all their faults made several big decisions when designing the Xbox LIVE service, decisions which in hindsight seem incredibly forward thinking, and as a result of those decisions the Xbox is still years ahead of the competition when it comes to it’s connectivity and online features. One of Microsoft’s requirements is that all Xbox LIVE Arcade games must include a multiplayer component, and here is where we made our fatal mistake – we designed the most minimal multiplayer implementation we thought would be acceptable. We’d made the classic mistake so many companies make – designing new gameplay purely for the purposes of cash in the bank. Our primary aim for multiplayer Darwinia was to satisfy Microsoft’s requirements enough to get Darwinia onto their service and gamer dollars into our accounts, and we set to work thinking of it as a purely technical task of grafting networking code onto Darwinia and throwing in a few interesting map layouts for players to battle over. And completely predictably, multiplayer Darwinia was a sterile and dreadfully tedious game to play for many months, before we finally plucked up the courage to admit to ourselves that we’d made a mistake.
Astute readers may have noticed an air of desperation in the blog postings around March/April 2007, as other indie creations like Little Big Planet put us completely to shame and reminded us of the kind of passion we’d discarded in pursuit of financial security. There had been no one single moment when we’d consciously decided to “sell out”, and yet here we found ourselves, knowingly producing one turd game to pay the bills and rationalising it by telling ourselves we were expanding onto Xbox and also paying for Subversion with the proceeds. It’s an incredibly slippery slope and a deeply seductive idea that one game can be made for business and can fund another more creative idea at the same time, but ultimately as a games company we make Video Games, and our success at that aim comes down to the quality of each and every one of the games we put out the door. The games absolutely must come first, regardless of the business deals we are arranging along the way, and as soon as that priority is reversed we’ve crossed the line and it’s all over for us creatively.
So we held a series of crisis meetings in London, made some hard decisions, and threw away pretty much everything we’d done for multiplayer Darwinia so far. Crucially we made the decision that multiplayer Darwinia would effectively be a brand new game for Introversion – our fourth – it would be called Multiwinia, and we would treat it with the same respect and attention that any of our other game projects received. Subversion once again took a back seat for a while and I took charge of the new Multiwinia project, acting as Creative Director over the whole project. From a gameplay point of view we went right back to the drawing board, discarding most of the work we’d done and stripping it down to the basics. Our biggest mistake had been trying to graft multiplayer onto Darwinia, which was fundamentally a single player experience. We began to think of Multiwinia as a standalone project, dropping many of the control mechanisms and rules and themes of Darwinia that previously we considered set in stone. Over several weeks we met many times in person and worked on developing a small prototype map for just two players with the most basic of rules, while Johnny focussed on providing a working multiplayer system over the internet. Once we had this multiplayer system it enabled us to do daily playtests on our single map, sometimes several times a day, slowly changing and adding new ideas and features until finally there was no doubt in our minds : it was fucking great fun to play.
And this is how we solved the problem of Multiwinia, and avoided the fate of releasing a game we knew internally wasn’t good. Would we have committed to Multiwinia as our fourth game if it hadn’t been for Microsoft? Probably not, but this is the situation we found ourselves in through our own design, and ultimately we had to follow through. During the remainder of 2007 we gradually added more and more maps, building up slowly through three player and then eventually four player when we felt we had a handle on things, and after that we started to expand into different game modes and styles. And something strange happened - once we had the foundations of a good game in place, there was a period of around four months when we were bursting with new ideas, and every day something new and fantastic appeared in game. We were jamming, exploring game design instinctively and following our creative whims into often dark and hilarious places. We were back on track.
Multiwinia eventually made it out of the woods late in 2007 and I began to step away, withdrawing to a safer distance where I could concentrate on Subversion once again and give higher level help to Multiwinia when it was required. We’ve definitely learnt a lesson along the way, although I’m not 100% sure I can get it down accurately in words. But it’s something like this: The creation of a game can’t be rushed, it can’t be faked or passed off, it can’t be excused for business purposes, and it can’t be done in half measures – you either do it at full speed with all guns blazing, or you accept and live with the low quality of your game and the certain knowledge it was your own fault as a consequence.
|
|
| |
|
|
| |
|
|
|
It's all in your head, Part 10
Posted by Chris
on Mon Mar 24, 2008 7:43 pm |
|
|
| |
Continuing the topic of user-made content, let’s talk about Map Editors. Ultimately if we want people to be able to make content for our game, there will have to be a map editor and there’s very little doubt that it will be clumsy, difficult and awkward to use, and fairly unintuitive. This may sound harsh, but try using a commercially available map editor like Hammer or UnrealEd, or a Pro tool like 3d Studio or Maya. And let’s be fair about it – anyone who has made a map using the Darwinia map editor will know we’re no better. What they all are is _powerful_, what they are not is user friendly. We have a map editor for Subversion, and true to form it’s very powerful, and not very user friendly. Here’s a picture of it displaying a map imported from Doom.
A couple of weeks ago I had a very strong image of a particular type of map editor for Subversion, that would be extremely easy for me to create, and (far more importantly) extremely easy for pretty much anyone to use. I was thinking about older games like Dungeon Keeper, and newer indie stuff like Dwarf Fortress, and they don’t bother with any complex geometry – they restrict the whole game world to squares, and do everything on a grid. It’s like drawing on graph paper, and every square can be empty or it could be a wall, or water, whatever. Initially this might seem extremely limiting, but both of those games manage to exhibit lots of possibilities to the player and don’t feel particularly restrained because of their grid like nature. I decided to run with this concept for a while and threw together a simple graph-paper prototype in a few hours.
It’s actually a lot of fun to use, and you can build quite complex geometry extremely quickly. Left clicking/dragging creates a room, ie an empty space with a 1 square wall around it. You can hold the shift key to fill the area with solid wall, and you can hold the ctrl key to delete whatever is in your dragged area. You can just left click on any square and doodle freehand if you like. In a possible future version, you could rotate the camera to be facing one of the walls and you could use the same mouse moves to cut out a window, a door, whatever you wanted. This system could also be easily extended with 45 degree angles, so it doesn’t have to be locked down to a grid. Dead simple, lots of fun to play with – both excellent properties of an editor designed with user-made content in mind.
I felt this was a pretty good prototype, but I could already see the technical limitations. Lets say for example you have a grid of 100x100, and each cell represents 1 metre square, that gives you 100 square metres, but the bad news is that all your walls have to be one metre thick. I’m not currently planning on setting the game inside NORAD or inside a dwarven fortress, so this clearly isn’t acceptable. But if you make your cells (say) 10cm square, then a 100x100 grid gives you just 10 square metres to play with, which isn’t big enough for anything. Why is the grid limited to 100x100? Because we’re rendering the world on a cell by cell basis, a 100x100 grid is already giving us 10,000 polygons just for a flat surface. Ultimately if you want large areas but the ability to edit fine detail, you can quickly find yourself blowing the whole render budget on geometry that’s no more advanced than D-Generation.
I quickly realised this was a stupid way to go, and set about working on an improved version using Quad Trees. Quad Trees are related to BSP trees commonly used to get FPS games running at a decent frame rate, and basically give us a nice way to partition the world so that we can have big empty areas that use up very few polygons, but still have the extremely high detail exactly where we need it. If you imagine a 100 metre square area, a quad tree would recursively divide this area into 4 blocks of 50 metres square each, one in each quarter. Each of those blocks would be further divided into 4 blocks of 25 metres square each. You can continue this subdivision all the way down, until you end up with areas that are just 10cm or even less in the areas where you need the detail. This is a much more efficient method of storing the same geometry, and is much quicker to render. This screenshot shows the same system, with red lines to represent the division of the world into a quad tree.
So four paragraphs and two pictures later, why am I still banging on about this when it’s clearly so limited? This method actually has some serious advantages over any modern system that are not immediately obvious. For example, the scenery is completely dynamic – there’s no need for any pre-computing, you can render everything via the quad tree extremely fast. You could blow the walls down with explosives or drill holes through the roof from one section to the next – genuinely dynamic game geometry for free. You can also render the world in correct back-to-front order, meaning you can do transparency without first having to depth sort your geometry. I tried to do this with the existing system a while back and concluded it was impossible without generating a BSP tree first – an extremely slow process that results in static geometry. Ray casting in this system is extremely fast – meaning you can do realtime shadows over everything for very little cost. Ultimately though, the biggest benefits are for the user – editing a world in this way is extremely simple and intuitive.
There’s already an example of a first person shooter that has been built using this core idea – and it’s called Cube. If you’re still thinking this form of map editing is very limited, I suggest you have a look at some of the game maps in this game.
http://cubeengine.com/
To really hammer the point home, while playing Cube in a Multiplayer environment you can press E to open the map editor and start building new geometry, and other players will see it too. You can knock down walls, build new ones, whatever you like, in real time. Try doing that in Unreal and see how far you get.
Here's another example showing what you can achieve if you take this to extremes. This is a Voxel demo using very similar (but more advanced) concepts, with completely destructable terrain in 3d space. This is from Ken Silverman, author of the Build engine used in Duke 3d et all. This demo also uses ray tracing to render the world, rather than polygon rendering - which probably makes more sense (it makes the polygon limit go away) but it's just not how modern graphics cards want to operate.
http://www.advsys.net/ken/voxlap/voxlap03.htm
Ultimately I’m not totally sold on the idea, because although you can approximate complex geometry, you can’t really do anything with totally weird angles. Looking at the pic of the doom map above, this sort of map would be extremely difficult to emulate in a grid based system. But I also know that perhaps ten times less people will be willing to edit maps with the kind of system that leads to doom maps like the one above. So ultimately some kind of hybrid may be the way forwards – using the grid system as a scratch pad for quick and dirty editing, and converting that into a more complex system if the user wants to.
On a totally unrelated note, today is 24th March, which some of our hardest-core fans might recognise as the starting date for Uplink (2010 of course). It also happens (not entirely un-coincidentally) to be my birthday, which makes me 29 today – just 12 months to go until the scary big Three Oh. I already own the slippers, and the dog is looking more and more likely every day.
|
|
| |
|
|
| |
|
|
|
I don't want a real job - Part 1.
Posted by Mark
on Wed Mar 12, 2008 3:26 pm |
|
|
| |
There are many fantastic things about my job, but there are also many frustrations. Perhaps one of the most trying of these is when I get e-mails that read:
“Hey Mark, I really loved DEFCON, Darwinia and the other one and I admire what Introversion has achieved. In fact I have my own game idea and I wander if you had any advice on how to start my own games company.”
How am I supposed to answer that? It’s not that I’m unwilling to help, or don’t have the time - quite the opposite in fact, I’d love to see more independent studios set up. It’s the fact that I can’t possibly dump all of the experience we have built up into one e-mail. In my more mischievous moments I am tempted to reply with something like, “Don’t eat yellow snow”, or “Check your paper supplies before you begin”, but more often than not I go back with the classic one liner: “What would you like to know?”
Very rarely do I get a response to this and when I do it is hardly ever specific or directed in a way that I can actually answer. I can’t help these people and that is what frustrates me. I’ve got visions of developers hooking up at GDC and asking “Did you talk with Mark from Introversion?”, “Yeah he was about as useful as tits on a fish”.
So I’ve decided to do something about the problem. I’ve decided to write a guide to building a video games company. I’m not an industry analyst so I’m not going to compare different business models or analyse case studies, but I’m going to dig into my mind, and the minds of my pals in the industry, and try to build a guide to “doing it the Introversion way”. That’s not because I think we are a perfect company or that we have “cracked it”, but because I know everything about Introversion and I think we’ve done well for three guys who started out with a small stash of left-over beer money and one potential game idea.
So let’s start at the beginning, which in our business is finding the idea for your first game. People often ask about our sources of inspiration and the “creative method”, but the truth is that ideas come from all around us. We have no idea when an idea will hit or what will trigger a thought process that ends in an embryonic game design, but we need to be ready to capture it when it does arrive. What we also know is that the more we experience, the more we expose ourselves to and therefore the higher our creative potential. Chris, the creative master-mind at Introversion, describes this as feeding his inner creativity. If that part of his mind becomes starved then the ideas begin to dry up. So perhaps the first piece of advice I will impart is to expose yourself to as much stimulation as possible, read books, play games, watch films, get out there and give your brain something to work with.
Most people know all that though. Many people don’t need too much help coming up with ideas and if they do, well then they tend to be more interested in being accountants than working in the video game industry. In fact, most people who want to start a games company already have a game idea, but it seems to me that many of them don’t seem to be able to tell when their game is crap.
Now I need to be very careful at this point. It wasn’t that long ago that we experienced around twenty publishers telling us that Uplink was crap and wouldn’t sell. A few years later we were looking for distributors to shift boxes of Darwinia however it took as a long time to find someone who didn’t think it was crap. By the time we released DEFCON we’d pretty much given up on publishers, but we thought we’d give it one last go, but I think you can probably guess the response we received.
We’re not publishers and I try to be as positive as I can about new game concepts (even if I don’t understand them), but there are some features of an idea that make it bad. If we can avoid those obvious pitfalls than perhaps we have something worth taking forward.
Firstly, don’t make a game that only you are going to play. In order to be successful there has to be some market potential. Perhaps that market can be very small – with a team of three people, ten thousand sales can be a good result, but you still need some people to want to play your game. If you get your rocks off thinking about a third-person bunny slaughter set in a steam-punked Tehran fair enough, but you need to ask yourself what non-freaks will make of this idea.
Secondly don’t try to beat the big boys at their own game. “It’s like EON but better”…is not a good way to begin a pitch. The big companies spend millions developing their games and you and your mates are not going to be able to get anywhere near the production quality of these AAA titles. “It’s a cross between EON and WoW”, is another great way to shoot yourself in the foot. These are massive franchises with established players and if you create a second rate blend you’re not going to attract either group of fans. Ask yourself, what am I doing to convince a player to put down what he is playing and pick up my game?
Finally, make sure that your idea is feasible. Figure out how much work it will take to complete your game. Figure out how much work your team can complete in a day and figure out how many days it will take to get to the end of your project. Double that number. What you end up with is a realistic estimate of the time taken to get your game out the door. If you are looking at several years than you really need to find out if you are committed to the concept. All too often student teams have ideas that are way beyond their practical reach – don’t make this mistake. Keep the scope small, and sleep safe in the knowledge that you can always put more of the cool stuff in the sequel.
If your idea passes those three tests than you are on to something. What exactly you are onto is yet to be seen, but at least you know that you cleared the first hurdle!
So there we go. Here beginneth the advice. Any use anyone?
|
|
| |
|
|
|
|
