On Lisp

As part of the language complexity article I'm writing I'd thought I'd look at lisp. Getting back to lisp is tougher than I thought. Maybe it's because of
the beta-ish nature of the implementation I'm using (Steel Bank Common
Lisp). Nothing seems to 'just work', in the manner you'd expect from
the more common configure; make; make install triad. I understand that
SBCL was actually an attempt to address this and make LISP much easier
to compile and bootstrap onto other platforms. If so, it's a step in
the right direction.

The other issue is the asdf system. Some thought has gone into it, but
I still had problems with it. It took me about half an hour to figure
out how to use asdf-install to configure a package. There were
websites about the internals of asdf, but not an idiots guide. It took
me awhile to realise that installing cl-ncurses was as simple as
typing (asdf-install '"cl-ncurses") but when I did, I was very
impressed - a simple way of downloading definitive packages off the
web. Definitely one of the things lisp needs.

The other problem I'm having is with the packages themselves: cl-sdl
crashes after awhile when an sdl app is running. I'm told this is a
drawback fixed with 1.2.7, so I'm off to try that. And cl-nucurses apps
just can't be used from SLIME for love or money. (initwin) causes the
SLIME prompt to hang. Problems, problems. Meanwhile, pygame works
flawlessy...LISP has a lot of catching up to do, but at least it's
headed in the right direction.

I upgraded from SBCL 0.8.8 to 0.8.11 to try and deal with all
this. Now cl-sdl and cl-ncurses refuse to load because the .fasl files
contain out-of date versions of the compiled bytecode. How the hell do
I recompile? If only I could find a page that dealt with all this for
newbies. It's the sort of thing one could pick up in an hour - or -
two's conversation with a lispmeister, but such people are hard to
find.

Strfry

There's one fringe benefit to working in Free Software land, and that's that sometimes (just sometimes) the documentation has a sense of humour. Witness the strfry function.

Ok, so the gag is spread all around the net. But it's still new to me

Quantity of Art.

This is our first, and particularly thorny problem. Procedural techniques are the mooted solution. They can be used effectively as this demo shows. However, the tool used to create this is the product of several years on/off work.

Here are some examples of procedural techniques at work: firstly for textures.

The Unreal engine uses procedural textures to animate fire and other things in real time. Perlin noise is the old standby for generating textures for wood, marble, and fire, but has become something of an artistic cliche.

The most interesting technique I have seen on my travels around the web recently is that of using Steerable Pyramids which seems to be able to synthesize a promising range of textures.

Secondly: landscapes.

landscapes are another natural subject for procedural generation as they are closely related to textures - indeed, a terrain can easily be seen as a huge bumpmap. I am only point to a couple of open source tools here: Terraform and Demeter as terrain generation techniques are already well known and plastered all over the web.

Thirdly: interiors.

Interiors are a subset of cityscapes, a city being a set of interiors. The classic "interior" however, is the dungeon crawl dungeon.

There's a nice a-life technique for carving out 'interesting' dungeons and a 3d counterpart.
I suspect the former technique could be extended to 3d by having the ai creatures carve out voxels on a 3d grid instead of rectangles on a 2d grid, or perhaps a different approach via extruding a floor plan, similar to this Doom level generator would be more fruitful?

Fourthly: cityscapes.

Not much seems to be extant in this area. This strikes me as strange, as buildings are regular structures and should be inherently easier to model procedurally than the 'organic' forms of terrain, clouds, and fire which are often modeled procedurally.

The virtual terrain project has a set of notes on the subject which indicate the magnitude of the problem.

It must be said that they are setting their sights pretty high by trying to model the architecture of all possible schools in all areas of the world over all history. A more limited means range may be achievable via a set of suitable shape grammars. Just to prove I'm not talking out of my hat here, I can point to a paper written by some researchers who have actually implemented this to generate a viable cityscape.

Fifthly: and most importantly...Characters

For generating and manipulating character models there are plenty of tools available commercially that could conceivably save a procedural representation of a generated character: Character Studio, Poser and Creature Creator to name a few.
Blender also has the open source "make human" script. However, these don't deal with the thorny issue of animating the results. Inverse Kinematics is a nice technique for procedural animation, but constraining it to realistic - looking solutions is a non-trivial problem. I suspect the solution lies in the domain of
evolutionary computing or genetic algorithms, but until a good, cheap procedural model of bipedal and quadripedal locomotion comes along (and it's a hot research topic) I don't know.

Managers should be up to the job.

I've come across several interpretations of the role of "project manager" in the industry - it seems to vary a great deal from shop to shop, and sometimes even from project to project. The range covers the completely hands - off: "sit in the back room and play quake all day" to the completely hands - on: "necromancy the developers with daily reports from them and double - check all their decisions". Needless to say, somewhere between these extremes lies the ideal.

There are some things project managers *must* have - recent development experience: they should have been through two or three projects as a developer, otherwise they can't really understand the process they have to manage, and the results are hopeless. They must also play the current crop of games so that they have a good idea of the playability and visual quality required of the project so that they can identify what is lacking. Anyone who doesn't meet these requirements is bad news.

The worst case scenario is a 43 old bowling alley manager who knows nothing about games leading the team because he looks "safer" at shareholder meetings. Ok, this never happened to me, but I have seen enough similar things in the past to lead me to believe that particular horror story

Of course, never having managed a project myself, I would not presume to offer a critique of others who have managed me, but I can point to an excellent source of advice for such people.

Game development

Cutting edge game development is bloody complicated, expensive and now, nearly impossible. This is a truism. Only large publishers and mega-developers can produce games in this day and age. There are several problems entwined.

1. Quantity of art.

It can take six people a year to fill a 600 MB CD with artwork. They will need good knowldege of a suitable tool such as 3DS Max, Maya, Gamespace, Blender, whatever, plus artistic talent. These people are not easy to find or particularly cheap to hire.

2. Managers need to be shot.

Oh, the management is crap. Another truism. Most projects suck. Are over-time, and over-budget? So, what else is new? The person leading the team has to be multi-skilled. They have to manage in the classical sense of scheduling. They have to be able to program, they have to be able to tell when people are bullshiting them about schedules, and spot possible dependencies well in advance. They should also be able to design a little - it helps if they can spot easy wins that enhance the game and can structure or steer the codebase to obtain them. In short, they need to be superhuman. The strongest industry franchieses - at least on the PC are those with a strong programmer/designer figure at the helm.

3.Workflow is crap.

We use monolithic tools. Max, VisualStudio, and usually a custom per-game editor application. Remember the old days when Spreadsheet, Database, and Wordprocessor used to be seperate apps? Why are these seperate apps?

4.Language complexity.

C++ is an order of magnitude more complex than C and supports about five different programming paragadims. Which is great, but not when you have thirty programmers mixing them at will.

5. The base functionality you need is more complex.

In 1987 a sprite blitter engine was sufficent. In 1999 something that drew
textured triangles really fast cut the mustard. Now you need something that can still draw triangles fast, but also needs to be able to animate objects, do numerical integration to do realtime physics on them, plus
collision detection, and scene management...

I will deal with each of these problems and their solution one by one in individual posts, but now we have another deadline to hit today, for Driver Three I really shouldn't be writing this...bye..!