“Rick, how do you paint metal?”, “Rick, where have all the texture tutorials gone?”

Well Jimmy, the truth is that it’s been a long time since I wrote any, and my old ones are out of date. Fortunately I blatantly stole this link to Skinning Tuts earlier. So read it and learn something new. Incidentally, these days I do a lot of skinning, and by that I mean binding a model to a skeletal rig. That is something I probably could write a tutorial on - but with deadlines and holidays and then the long run up to the release of our next game, I’ll pass on that for now.

A typical question that has been around for as long as I can remember is “How many polygons should I be using in a character/vehicle/environment?” Another common one is “How big should my textures be?”

There is only one answer that I can think of - “It depends.”

The reason for that answer is that the question is too vague - it’s like the old question “How long is a piece of string?”.

It depends. It depends on myriad things, such as the visual style of the game, the type of game, the capabilities of the engine and the target hardware. Some consoles can push vast numbers of polygons, and others can’t.

For example, a character for a 3rd person shooter like Gears of War on the Xbox 360 where you usually have a dozen models on the screen at once, in a small compact area of map would have a totally different target for polygons and textures sizes than you would if you were creating a character for a GTA game for the PSP.

The PSP simply doesnt have the processing power of the 360 to push around large numbers of polygons and it doesn’t have the memory to store large textures. The style of game is different too - GoW has smaller enclosed environments, whilst GTA is much more open. Compare both of those games to Fight Night Round 3 (on the 360 or PS3) where effectively all you have are 2 boxers moving around a small boxing ring. With these restrictions on the focus you end up with incredibly detailed boxers with muscles, tendons and sweat.

Finally, compare everything to Mario Kart on the Nintendo DS - there aren’t that many textures and lots of use of shaded flat colours. The hardware is less powerful, and the art is stylised.

So for those reasons, it’s impossible to answer a question as vague as “How many polygons do I use?”, which isn’t exactly much use to you.

So how do you figure it out? For one, you play games and have a look. Look at what details are modelled, and which ones are textured. Have a look at screenshots to see if you can spot repeating textures (remembering that most screenshots are ‘tweaked’). Have a look at game art forums where people not only display their work but usually an overview of it - and on those forums don’t be afraid to ask questions about the art.

An important thing to remember is that the polycount and texture sizes will fluctuate continuously through the project (usually getting smaller). Sometimes the programmers will come up with new compression techniques to allow more textures in memory, and all too often you’ll have to shrink or reuse textures to get them to fit.

We can encourage questions like “How many polygons should I use for the lead character in 3rd person hack and slash gladiator game for the PSP where I have wide open arenas and normally 2 other fighters on screen at once?” - but I think the answer would still be “It depends.”

As a game player, or an artist who modifies games, you will no doubt have heard of an engine in relation to games. However, many people are unaware what an engine actually is, what is does, and how it affects them as an artist. Many people confuse a game engine with the game itself. This is an attempt to explain what a game engine does and why they are used - but to stop this being a novel I’ll approach from the point of view of an artist.

Essentially, an engine is device for collecting, managing and using assets. You put art and sound and logic in one end, and a game comes out the other end.

There you go, that’s that cleared up.

More details?

As I mentioned, many people confuse the engine with the entire game - an engine is not a game, but the core around which a game is written. An engine contains no game, its a layer of abstraction, a layer of processing that sits between the game (fun, story, art, sound, controls) and the hardware.

In the old days games were essentially written for specific hardware. They were one off chunks of code - you came to your next game and you rewrote it from scratch. Quickly programmers built up a library of reusable code, so that, for example, once they written had a good system for handling sprites they could simply copy that code into their next game - perhaps verbatim, perhaps making minor or even major improvements.

Reusing code is a great idea - rather than starting everything from scratch each time, you get a major head start. Soon these little snippets of code build up, and then you realise that playing sound in your last game and playing sound in your next game is the same, it’s only the sounds that are different. Just record the new sounds, bung them in and hey-ho, away we go.

So, rather than writing a game from the ground up each time, an engine provides a core to work around. When developing a game, the artists export their models and textures and animations into a format that the engine can read, as do the sound engineers. The game programmers write a control system that maps buttons presses on a joypad or a keyboard to actions in the game, but the engine does the work of translating the signals from the joypad into something we understand, like ‘Up’ or ‘X Button’.

But what will all those programmers do now that we have engines? Lots of things - they’ll find and fix bugs in the engine. They’ll make the engine run faster. They’ll add new features (and then fix them. And then make them faster). And they’ll even write nice tools for us artists to make it easier to get our artwork out of our heads and into the game.

Hurray for engines!

What’s the point of the cold? It’s a rubbish sickness whose sole purpose seems to be simply to make you sleepy and give you a red nose. Mind you, since I was sick and have aching bones I suppose it could be a mild flu. Not a real flu, not one of those bastards that kicks you down for 3 days and makes you wish you were dead.

Still, I’ve had a few days off, and thought I could use it to get a chunk of my Streetfighter model done. No such luck, I’ve got the attention span of a gnat. I have managed to delete some old music, organise my bookmarks and listen to music. And consider making the switch from Bloglines to Google Reader. I had tried Google reader about a year ago and wasn’t that impressed, but after reading a post on Lifehacker I decided to give it another shot.

Oh, that SF character?

It’s getting there…

It’s getting there. Adding in some of the alpha planes and trinkets has helped add character.

I’ve been chipping away at this beast, and hopefully by the end of the weekend I’ll have the hair complete.

I spent last night and this morning working on the feet. Feet are not fun to model.

Not much yet in the way of Thunderhawk, but plenty in the way of solid base model.

Gordon is working on an Evil Ryu, and Lobster/Bear is working on Makoto

See everyones work at http://boards.polycount.net/postlist.php?Cat=0&Board=contest

Polycount are running a new 30 day challenge to redesign, model and texture a Street Fighter character in 30 days. The rules are fairly simple, and I’ve chosen to work on Thunder Hawk.

Some time ago I realised that my ability to draw is somewhat lacking, and fortunately a dear friend has kindly offered to work up some concepts for me. These will be posted when he’s had the chance to clean them up.