In 64k intros, programmers use all kinds of tricks to keep file size down. One of the big methods is procedurally generated graphics. The mantra in the indie downloadable game business is keep your download size down, and I wonder if the same tricks could be used effectively for games. I think you could procedurally generate a lot of content at runtime with rough descriptions. A couple of ideas:

-use vector graphics instead of bitmaps
-use noise\procedural textures
-use texture\image composition
- use l-systems
- use rougher descriptions of objects (primitives, etc, similar to the vector idea.)
-subdivision surfaces\displacement mapping
- psuedo random or algorthmic levels

The only problem is the game will feel a little "procedural", but if you do things right I don't think that will be very noticible. Note, the goal here is to keep the download (not necessarily the installed) size small, not to create "infinite universes" or "unlimited replayability", although those would be nice side effects depending on what type of game it is.

It's a tough call...

the download size needs to be small enough not to limit players trying it out due to large download times, however, once downloaded the player may require the game to be more visually stimulating than a procedural design can provide.

If a procedural feel doesnt take a way from the "awesome" gameplay then I guess its a good idea.

But some players base a download decision entirely on your screenshot(s) - so it may work against you too.

Yeah, that is an issue. As you see, a lot of the techniques I'm proposing are somewhere between generated and procedural. It's not like all the graphics would be entirely random, but a lot of things would be algorithmic or made from higher level descriptions as opposed to storing things per pixel or per vertex in images or meshes.

Some 64k intros (the dot product, recent asm 2003 winner Zoom3) generate a lot of procedural data and it looks good enough, not as good as hand created stuff does, but pretty impressive nevertheless.

2 to 10 mb gives you a lot more room than 64k (although there could be an advantage to games that are less than a few hundred k) so I think you could do some impressive stuff. More complex games (RPGs, complex action games, strategy games) benefit more from this than simple action games or puzzle games. Basically, you need to know the strengths and weaknesses of procedural content. It works well for environments, plants, even machines to some extent, but it doesn't work very well for organic characters. There are some techniques that organic characters could benefit from though, like subdivision surfaces, displacement mapping and composite textures.

I did some of this with Dweep. Many of the game's interface elements like screens, buttons, and dialogs are composed on the fly from a small # of flat textures. For instance, the menu buttons are created at run time, including adding the button shading and text. The laser beams in the game are also procedurally generated (no bitmaps). Aside from the title screen, there are no other screens in the game that are stored as full bitmaps.

I use the "random" function quite alot in Charlie II. For example, all the backgrounds are built up when you start a level. Most use only a few small sprites, which are placed at a random position in a random shade, etc. Apart from these sprites, each background is stored in only a few hundred bytes (of which many represent carefully selected random seeds!).

In the levels, all tiles can be used in different colors and with different shading (at runtime), which greatly reduces the total number of tiles. Besides, there are actually two layers of tiles instead of one, so I don't have to store a separate tile for each new tile combination.

Because the game was originally written for DOS, I had to do a lot of these kind of things just to resolve memory problems. However, it did keep the total size below 1 Mb.

For one of my next games, I'm working on a kind of composing algorithm for music. I've been experimenting with this for some time now (with kind of disappointing results so far, but I'm sure it can be done!). This should also save lots of space.

Mike

Having made a 64k intro (which was actually a self playing platform game) that was in fact only 32k, I know how incredibly much work lies behind that kind of size.

Use generating only where it is easy and give great gains, or you will end up wasting time.

Randomly using data with variations in color, size and shade however is a good example of aneasy method with big gains.

There's quite some information about the making of the 64k intro "the.product" at www.theproduct.de (http://www.theproduct.de) and how they went about creating procedural content.

I especially find this shot interesting, from their texture tool, showing a really clever way of having artist-controlled procedural textures.
http://www.theproduct.de/jpgw/T1B.JPG

Anyone remembers the game "Rick Dangerous"?

For those interested, here's a DirectX-version of it, in only 32k:http://pouet.net/prod.php?which=8309

I was just to a seminar at Assembly held by Dierk Ohlerich. He is currently a game programmer but has a long history of demprogramming under the alias "Chaos". He held the talk about the tools they use at Farbraush http://www.farb-rausch.de/ to create their demos and intros. The talk was really enlightening and quite impressive.

Almost everything is procedurally generated and the tool used was extremely simple and intuitive. It was essentially a tree view coupled with a preview pane. Output was constructed by "stacking" functions together in an evaluation tree. The tools was completely tailored for artists, they could work their way through the demo without any help from the coder. Really impressive stuff. Take a look at FB-025 for a quite interesting view.

The problem with procedural generation is that you have to understand the problem domain much better than with normal editing and modelling. Even if you could analyze the procedure for making a excellent 2D texture, there is still a long way to go with different functions required to be able to generate the output. An even harder problem is to generate data belonging to a certain class and have the instances varying. Eg. generate several tree textures from one procedural source.

An an extra note to the above, when you look at 3d meshes these are mainly simple objects deformed, so you can build stuff like spheres, cubes, toruses in code having paramteres to skew or generally deform them although some decent editor would be required but would make your models into bytes rather than megs. the other biggy is sound which tends to each at lot of bytes.. but generated sound is an area I don't even wish to think about ;) although creating ogg's rather than wavs would certainly compress data size for you.. saying that it does depend on the game.. say a pacman clone would benefit ideally from procedural data.. you could even base your game around precodural creation. but I don't think it's worth doing if it means changing the whole appearence.. thats enough of my random babble again for another day :)

Thanks for the links. It's nice to see that people are into this stuff. The fr-* intros where the major inspiration for this post.

Kai-Peter, do you know when the assemby 2003 seminar videos will be up?

I have written several D3D 64k intros, though not as technically sophisticated as the farb-rausch ones they're still pretty complex and took a lot of work :)

Here are some links if any of you are interested, by definition very small downloads of course :)
http://www.pouet.net/prod.php?which=5196 (won a compo)
http://www.pouet.net/prod.php?which=6225 (won a compo)
http://www.pouet.net/prod.php?which=2411 (third place)

And also an OpenGL 4k intro:
http://www.pouet.net/prod.php?which=5199 (won a compo)