Skip to main content

Second generation tileset planning.

I've already talked a bit about how I'm handling the layout of the new tileset, with offset tiles and overlays and different objects for walls and floors etc... In this post I want to talk a bit about how I make the textures, and what I've learned from the first (partially successful) generation of tilesets.

Experiments with using different lighting for tiles and characters.
If I wanted I could continue to make the game using the old style of tilesets, they're not that bad, but they just don't satisfy me. I know they could be much better and I've learned a lot in the last 2 years that I'd like to include in a revision of the tilesets.

Some of the things I want to consider when making the new tilesets are:
  1. Don't make doorways "covered", the doorway area should be open to the sky, otherwise it's difficult to arrange your characters in a doorway, somewhere where combat is very likely to take place. In the MKI tilesets I made the doorway like a tunnel, it looks nice but it interferes with play.
  2. Don't make the walls too high. We can imagine high ceilinged rooms, but if we actually make them it can obstruct our view of the characters. It is possible to write a script to remove blocking walls from view, or have things such as arches or upper parts of walls become transparent when you walk in to a room, but it's best to start with low walls and work from there. Just make sure they are at least as tall as your character or it will feel strange.
  3. Don't make the textures too detailed, or too high contrast. The tileset is supposed to be background, you don't want to lose important characters or items in an over-busy texture. I've been doing experiments with using different lighting ranges for tiles and characters (Tiles: 0.0-0.3, Characters 0.0- 1.0) this really brings out the characters from the background. Interactive objects should stand out like painted miniatures, while everything else should fade in to the background. It's not realistic, but I'm not looking for total visual realism in such a game, it's supposed to be somewhat stylized without being cartoony. Our point of view is like that from a window in a tall building looking down at the street. It would be easy to lose track of who is who and what they are doing from such a vantage point if we adhere directly to photorealism, especially in a dark, cramped dungeon.
  4. Avoid creating lots of unique texture/tile variations for a single tileset. It's better to create several tiles which look very similar but are subtly different. The human eye will quickly see when two tiles are identical, but will be fooled if most tiles are similar but different. When faced with a mostly homogeneous map, our minds will fill in the details, our imaginations will do the work for us. If the map is too cluttered with unique texture or fussy details our minds will block it out and all that hard work will be wasted.
  5. Try not to use mirrored or rotated textures too much. This can save on texture space, reducing texture sizes or giving higher resolution textures, but it is very obvious and quite ugly. It's better to have lower resolution but nicer textures.
  6. It's important to do some post processing on your base textures. One thing that can improve them astronomically is to bake shadows and ambient occlusion, for this, first create a prototype of physical parts of your tileset and make sure there are no places where texture space is duplicated or repeated. Later you can do this, but for the baking it will cause artifacts and strange results.
  7. Instead of using a single complex texture, use two simple ones and mix them together using a perlin noise mask which repeats at the same size as your tilesets (in this case 16x16 blender units). I've already done this with more recent versions of the MKI tilesets and it really makes it look more alive. The wear and tear looks integral to the tiles, rather than just being painted on. The best way to do this is by mixing the textures on the prototype tileset and then baking them in your 3d engine. The end result will be the same as you'll see in game.
When it comes to making the textures for the tilesets, I already have a good workflow which I will be modifying, but mostly continuing. First I create a texture mask:

Each color is a different type of material.
Red is "wood", blue is "recessed wood", Yellow is "plain stone", green is "recessed stone", white is "metal" magenta is "detailed stone or brick" etc...

I then feed this in to a procedural texturing program (I'm using MapZone, a somewhat old but free program but you can find others or even write your own).

 This splits each material in to a separate layer and then procedurally paints the layer to your specifications. You can use stock images or procedurally generated textures, both give good result. At first I used to do this by hand in The GIMP, but I've found procedural texturing so much faster and easier. If you change the layout of your tilesets, for example moving or enlarging a door or window, you can just feed the edited layer texture mask back into the program to get an instant result.

After running it through the generator.
Hopefully with all these points in mind, the future MKII tilesets should be a real improvement on the old ones.


Popular posts from this blog

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …