It’s a been a bit of a while since I wrote anything. Just trying to recover from the trip to China to be honest. I’m knackered and in an ‘everyway’ kinda way – deeply weary from the whole adoption process from start to finish, and now we actually have him we are finding that as we get older dealing with a one year old is more than we remembered.
Still, it’s all good.
I am off for 4 weeks paternal leave and I’m doing some website stuff – finally going to get this blog on MySQL and I’m going to update MilaSimpson.com to be script driven rather than having to write HTML everytime I want to update it, and also get CameronSimpson.com up and running too.
Anyway, lets talk about Games Stuff, since that’s what this blog is about.
My good friend Bruce Everiss, who runs the PR oriented blog Bruce on games recently dropped an interesting set of thoughts on game development and I thought I’d chime in with my thoughts on his thoughts. I’m sure someone else can do the same and we’d end up with a seven degrees of Kevin Bacon scenario. Anyway, lets talk.
Cut scenes are mini videos put into games as a way of presenting information to the player of that game. To me they look like lazy short cuts to doing the job right. The advantages of a video game are interactivity, connectivity and non linearity. When you have a cut scene you throw all of this away. It is far better to do the job properly and get the information over in the game play. Why should we be dropping our standards down to those of an inferior media? It is interesting that Valve, one of the most highly rated game developers, don’t use cut scenes.
Actually Bruce, yes they do. The thing that Valve has done in terms of making them better is two fold – a) you can walk away from them since they don’t control you or your camera while the cut scene is unfolding and b) they do it from the scene in front of you – they don’t cut away to other camera positions. They sort of do it by using view screens in front of you to show other points of view, but ultimately it’s still a cut scene, it’s just one that you don’t have to watch.
Cut scenes are often necessary to push narrative along. Without going too deeply into it, narrative is the enemy of interaction since narrative requires a set state of affairs in order to move forward – people need to be in the places they need to be in, not dead, etc, in order for the story to move forward. Most of the time the only way to do that is via a cut scene.
It’s also worth noting that while Bruce bemoans the requirement for them, he doesn’t actually suggest how to push narrative along without them, besides saying “get the information across in game play” – yes, but how exactly? Some examples?
The QA department is a key component to the development of a video game. They graft through all the complexity to make sure that everything works as it should. Frequently they are looked on within the company as being lower down the food chain than the artists and programmers. This is something I never understood because it is QA that ensure the quality of the game. What I would like to see is a very greatly upgraded QA department. Renamed Polish, Focus and QA. Their job would be to polish the gameplay to get it to Super Mario Galaxy like level and to work continually with a whole range of focus groups to ensure that the game is what the public want. Obviously to do this would require a few more staff to work on some of the extra job functions. But the result should be commercially more successful games.
I think most of this is right on, excepting the fact that polish isn’t the remit of QA – QA is there to find bugs. It’s NOT the design department (which is there to push polish) and shouldn’t get the idea that it is – that’s already a problem with QA contractors sending in bugs that are design decisions rather than bugs. Polish time should be scheduled (and most of the time it’s not), but that’s not the QA departments remit.
On the other hand his point about QA being looked down on is right on – and that needs to change. But it’s got a lot to do with the fact that a) QA if full of frustrated designers and b) it’s very transitory – lots of QA testers are brought on as part time contractors and then let go pretty quickly. They just aren’t around to gain much experience. It’s a shame but understandable.
Outsource all your art to low cost countries. It is a long, long slog to create all that content, so why pay Western prices for it when it can be done just as well for a lot less money? Hollywood learned this lesson many years ago and so now 90+% of their animation is done this way. All that needs doing in the West is the storyboard, the characters, the set and key frames. The long graft of converting this into a finished film is done in the Philippines, India, Vietnam and other places with their low labour costs. There are companies you can sub contract to, but the ultimate savings come with setting up your own art studio in one of these locations. Choose a place where there is already plenty of film animation and you will have a ready trained work force.
Yeah, I think there are specifics where this is a good idea, and others where it is not. In terms of outsourcing, you’d better be geared up for this from the start – with people on board with experience in how to expose your pipelines and how to expose what’s required and educate in the use of your animation rigs and so on. Outsourcing is all about education, in terms of how to use the tools provided, what the standard of returned assets are and what exactly is required in the first place.
It’s also worth pointing out that you can only do this with a stable pipeline in the first place – if you are still developing it then this is a hiding to nothing.
Lastly I would point out that basically penalizing every 3d artist / modeler / texture artist because they live in a western civilisation (which is effectively what outsourcing becomes) is a slightly dubious way to move. I do believe that you will always need people on staff capable of creating assets just to a) prove your pipeline and b) fix up that which is gotten back by people from Bangalore. If you could outsource PR I doubt that Mr. Everiss would be recommending that.
Design multiple languages into the game from the very beginning. Some languages take up more space to say things, some languages need different character sets and you can make life easier for your lip sync talent. If you take these into account then language conversion will be a lot easier and cheaper. As the installed base of platforms rises so quickly in so many markets it is essential to keep on top of the cost/benefits of language conversions. Very many more must be viable now than they were just a couple of years ago.
Note entirely sure what the problem is here? Most dev’s have good localization systems in place that handle this, and lipsynching is almost always done against phoneme generation (phonemes are the guttaral sounds that make up speech – there are particular lip shapes against all the sounds we use to make speech and you basically run your voice samples through a tool that generates a phoneme script, which then lipsynchs the lips / jaw to the sounds being made. It works against any language, just run the other language voice samples through the same tool and it Just Works) anyway, so it’s all good?
Frame-rate is more important than content. I have seen this so many times, overambitious game designers trying to put too much on the screen and do too much with it. So the frame rate drops to embarrassing levels. Our job is to entertain and that means suspending disbelief. Nothing brings that disbelief back quicker than a stuttering frame-rate.
I’d tend to agree, although I’d rephrase it as “Consistent frame rate is more important than content”. While consistent 60fps is the goal, consistent 30fps is fine too – I’d rather have 2x on screen and be at 30fps than less than at 60fps, but that’s just me.
Once you start dipping into the 10-15fps range, bad things happen.
It’s worth pointing out that a lot of the problems people have with stuttering framerates has more to do with input sampling speed than anything else. Once your input rate is at 10fps then nothing moves as you expect it to and framerate gets blamed, since often input speed is tied to rendering speed.
Development crunch is just bad management. That is all there is to it. Mankind has developed management systems to control far bigger and far more complex projects than game development. Aircraft carrier and fighter aircraft design and manufacture for instance. In fact games are still pretty small in management terms. The tools, techniques and training are out there to run game development projects properly. It is not rocket science.
Yeah, I’d generally agree – certainly death marches are a management problem. Most problems are a result of one of four things – lack on scope management (trying to do too much with too little or experience), lack of visibility into what is being done when and by whom and to what degree of quality, lack of a plan for specifics of what should get done first and when (changing direction on the game, not sticking to a dependency chart of what gets done when, depending on external services that don’t come through etc) and lastly, total idiots in control who change their minds with their underpants.
But while that’s true it can also come about that the developers themselves can be their own worst enemies too – how many times have you heard the ’2 weeks’ to a question of “When will this get done by?”?
On the other hand there are also external circumstances when things can change and create crunch like situations – publishers suddenly demanding that all assets get bump mapped, or a requirement for a new demo, or the addition of a multiplayer section that was never part of the original demand. It’s possible to lay that at the door of the management team too, since these should be caught at contract time but there are *always* holes in contracts that the unscrupulous will attempt to exploit.
And then there are situations where events outside a developer managers control occurs – someone crucial suddenly leaves for a new job, someone else gets married, someone else has a kid – all focus changing situations.
Sometimes life just occurs and makes work for you; that’s reality.
In overall terms I think Bruce is fairly on with his points; I think some examples are lacking in terms of how to fix it or do it better, but generally for a non in-the-trenches developer he’s not that far off.