The following blog post, unless otherwise noted, was written by a member of Gamasutras community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

In a city builder game, the in-game graphic of a building is simple: a static image, plus a few simple animations. But in the production, we have a whole bunch of resources to manage: 3D files, textures, animation frames… Here in this article I share how our team manage these stuffs.

Make the graphic future-proof:

Make sure the image resolution is large enough, that you can port the game to HD devices which would emerge in the future.

For example, the size of this building is:

Making the images in bigger resolution won’t add much cost to the 3D team, but it would save you lots of money in the future.

A single texture for a building

First, let’s make clear what type of textures we need for isometric buildings.

In other types of games, we often need custom made texture for a creature, or an item, just like this:

However, we wouldn’t need this type of textures for isometric buildings, instead we only need plain textures, like these:

For we would add lots of treatment in rendering, and 2D post process, so textures like these are ok.

So far as I know, many studios would use a whole bunch of texture files for a building, each file for a type of material:

This might give you some convenience in the making, but would create lots of complications for the assets management. For example, next time if you want to re-use the 3D model of the building, you would often get a few texture files missing (in some bad management, you would find the texture files scatter among many PCs), and you would have to spend some extra time to get similar textures again.

In our studio, we put all the textures needed for a building in a single texture file, like this:

This makes the 3D assets a lot easier to manage: a 3D file and a texture file (or two, one for color, one for bump).

This texture file could be very large, it’s not a problem, for you won’t eventually feed this file into the memory. The size we use is 2560 x 2560 px, it’s enough.

Always use Presets for materials

In all the 3D applications, the materials are represented as balls:

In fact for isometric buildings, you only need a few materials: concrete, wood, glass, metal. That is 5~6 material balls(They all connect to a single texture file as I said above).

After you have completed a few buildings, you would have a full set of these common materials. Save them as presets, in most 3D applications you can do this.

By saving presets, you save the properties of a material: highlight, glossiness, reflectivity, etc. Next time when you need similar material, you only need to re-load it, and you need to change texture file though. This can save lots of time in the pipeline.

Use an universal 3D file to store rendering settings

When the 3D model and textures are done, you need to render the building. You would put in lights, cameras (I have a separate article about how to place camera in right position), and you would specify the render settings: basic image output settings, Global Illumination settings, Final Gather settings, etc.

After you done rendering the first building, you can delete the building, keep everything else(lights, cameras, reflectors…), then save the 3D file as an universal file for rendering. Next time you want to render another building, just merge in the 3D model, then do the render. For in this file it has stored the right render settings, you don’t need to setup all these again for another building.

Frame based animations:

Some animations are frame base, one image for each frame. It’s best to save each frame to an unflattened PSD file, it gives convenience for later editing.

Full assets for a building:

To this point, let’s see the full assets of a building:

A 3D file; A texture file; A layered PSD file, which include the 3D render output image, and the image after 2D post art; A folder to contain the animation frames.