14th November 2010
Managing repetitiveness
This is the third article on my development of an online game with very small viewing dimensions.
This time I'll talk about my approach to developing the graphical assets.
The case for expediency
When planning an exploration game, I believe that the first consideration should be maximising interest in the environment. To put this another way, the developer needs to avoid the appearance of repetition. This rule should be applied to all structures of the game, for example including graphical textures and level design. If the budget is large, many man-hours of effort can be spent for example making every location unique - the limit is what the technology can handle. However, in the case of independent developers with limited resources like myself, this essentially means maximising the novelty imbued per developer-hour. A pragmatic approach must be taken, and assets used multiple times.
Advert
Repetitive textures
Having settled on a tile-based environment, one thing I'm eager to minimise is a repetitive appearance of the background. If a single tile is used many times on the screen, then on inspection the repeating unit can quickly stand out. Even if several tiles are used, this merely increases the size of the repeating pattern. There is a conflict between adding interesting texture and blatently revealing the structure the gameworld.
There are several approaches to mitigating this:
- Use a very uniform tile; flat colour or a straight dither.
- Generate a texture programmatically - essentially, an infinite texture
- Use several small interchangable tiles.
The first option is essentially a cop-out. Option two can work well, but does need effort to be spent up-front, is generally a programmer rather than artist technology, and isn't easily applicable to all cases.
The last method is really quite effective, as demonstrated in the figure below.
A) repeated 24x24 pixel texture. Even though the design was intended to have very little variation, repetition can still be clearly seen. B) The same bitmap data treated as nine randomly chosen 8x8 tiles. (The top-left has tiles placed in the same order as A.) Repetition is much less evident.
I think that a good strategy is to have several low-impact tiles for the majority of the fill, and a few detail tiles for occasional use. This is similar to giving your textures something of the nature of a fractal - that is, having detail on all scales. Give some of your tiles only subtle, small-scale texture, a few a more noticable detail and maybe have a couple with a large, obvious feature.
In general, the more visible a structure, the less often you can actually use it.
Advert
My application
However good it is, a single texture will only go so far. A player will, for example, quickly get tired of brick walls, even if every brick is subtly different. The only solution here is to have many different styles of environment. For architectural reasons I decided to limit myself to 256 different tiles for the main tileset, equally split between solid and empty. This restriction should help reduce the file size of the final game. Aided by the fact that 8x8 does not require much detail, I drew many different styles of tile, following a few basic rules intended mainly to speed up the process:
- A very limited standard palette, covering the whole monitor gamut.
- Use only a few colours in each tileset
- Background tiles to use dark hues, forground tiles predominantly vibrant or light colours.
- The larger the area planned for a style, the more tiles allocated.
- The more potential combinations or interesting uses of a tile, the better.
- Break the above rules occasionally
- If an idea can be done with just a few tiles, try to do it.
To emphasise the variety, I also tried to make each texture vary in different ways. Some are completely interchangable, some have structure like a larger quasirepeating unit or a surface layer on one or more sides. It turns out that some of my textures work better than others, but rather than throwing some away I've generally just used them in relatively small areas. This is again in the interest of expediency - in a huge map, even the disappointments are useful for increasing the diversity of the environment.
A potential issue with the 'alternate tile' method is that choosing every tile in a map editor becomes increasingly problematic.
The solution I've chosen still uses a map editor to lay tiles, but only to specify type. The output map is then processed to choose which particular tile in the group is used, according to a specific function for each style. This seems to work fairly well. The main drawback is that each level build changes in cosmetic details, so I don't know exactly what I'll get. If this is an issue, an obvious fix would be a deterministic random number generator, seeded with the tile's coordinates.
Another potential issue is that for the more complex textures, writing a full rendering function takes time. If many textures all vary in the same way this will pay off, but I have opted to leave some of this to the tile editor. I have found that manual placement can highlight serendipitious combinations of tiles which create interesting effects - which a fully automatic function probably wouldn't find.
Unfortunately, showing the current tileset would spoil some of my surprises, so I can't do that. However, next time I will reveal how I hope to give more depth, and a more organic feel to my growing world.
Advert
Comments