Nothing wrong with programmer art

2011-01-14

The one thing I like the most about game development in the 21st century is that it's possible to do it alone, like in the good old days. Developing alone means you have freedom to experiment and to do what you know is right, and as the indie market proves, that's a good thing. But there's a downside to it as well: you have to be good at everything. Graphics, programming, sound -- it's all on you. And it's hard enough to become an expert at one of these things, let alone all of them.

The obvious solution, then, is to look for a co-developer. But what if you can't find one from the beginning, or at all? In such cases, sound is usually the first victim; you simply omit it. But with graphics, it's not that simple.

A real possibility nowadays is to search a stock art website, such as Open Game Art or the Model of the Week section at Planet Quake Trouble is, generic art is generic; you'd have to be very lucky to find assets that fit your game and especially each other. Yes, it's supposed to be replaced at some point, but you know how temporary measures tend to remain definitive. One way to prevent that is not having any graphics at all initially.

Wait, what? Obviously, they can't laugh at you for pathetic attempts at art when you don't have any; just do a prototype of your game with colored boxes for graphics. It's what the authors of Canabalt did, as explained on their blog:

[tuning]: http://blog.semisecretsoftware.com/tuning-canabalt

...the very earliest prototypes were just big green boxes with gaps between them. It took very little imagination to see the little white box as a dude, and the big green boxes as buildings...

(I reviewed Canabalt in october 2010.)

You may even discover that your game works well enough with abstract graphics. Just add more colors, more shapes, some particle effects, and poof! It's essentially what I did with Square Shooter. Several times I seriously considered making the ship a cute little flying saucer, and the bubbles into asteroids, but gave up: it's not worth ruining the game's distinctive minimalist look.

For some games, though, that won't work so well. And you'll want to have tailor-made art, at least in places.

For that case, a solution that should appeal to any programmer is software that can generate assets for you, such as HemaHema for terrain (thanks, Nightwrath) or Arbaro for trees. Procedural generation for the win! Unfortunately, they are inherently specialized. What to do when you need something else?

Fellow programmers, I present to you (drumroll) exhibit one.

pine tree

Not bad for someone with little artistic skill and no mastery of advanced graphics software, if I may say so myself. But how did I do it, then? Thanks to a little-known piece of software named POV-Ray, which allows me to leverage my specific talents. Namely, to create decent-looking art by... writing code!

Now, POV-ray is capable of generating stunningly photorealistic images, but that requires considerable effort, and it's too much for my needs anyway; hence the deliberate plastic look. In case you're wondering, the ground is only there as a reference, and so that the tree would have something on which to project a shadow. And yes, more complex shapes are perfectly possible. But for my little tech demo, it was easier to stick with unmodified geometric primitives.

snowman

Amazing what you can do with simple spheres. I've even been lazy enough to not place the eyes and buttons properly; they're actually floating a little in front of the snowman. But it doesn't matter because 1) I'm always looking at it from the front and 2) in the demo it doesn't get bigger than this:

ballistic snowballz 2

(Edit: I fixed that in a later version.)

You can also see how the background is drawn as a simple gradient, while the snowballs are simply two discs on top of each other. Not something you'd want in a commercial game, but good enough that you don't need to be ashamed of it. And that's the whole point.