Style Guide

[Osmic]

I was talking to Per the other day came to the conclusion that there isn't a comprehensive style guide to help keeping the visual style coherent. I think this is a problem when someone wants to contribute a model and there's a huge possibility that it ends up looking very different from the rest.

My suggestion is that each faction should have one defining thing in each category:

Geometry: The shapes the buildings are made of, like blocky and simple for the Nexus.
Texture Color: A color that captures the faction's feel, like rust for the Scavenger.
Texture Material: The material that the faction uses to make it's buildings and units, like shiny metal for player.
Texture Detail: An element that is present in all textures, like a shiny circle or a striped line.

These rules are fairly high level and I'd like to go to a little bit lower level and make a few sets of textures that artists can download and manipulate to use in the new model. This also helps to keep the look consistent and lessens the work needed to be made when the artist can re-use stuff.

Any thoughts?

[Buginator]

I think getting content over 'style' is the first objective.
When that content is released, then someone can change/fix the texture(s) up.

As the old saying says, beggars can't be choosers.

This applies to everything we currently need done.

[Per]

I was talking to Per the other day came to the conclusion that there isn't a comprehensive style guide to help keeping the visual style coherent. I think this is a problem when someone wants to contribute a model and there's a huge possibility that it ends up looking very different from the rest.

My suggestion is that each faction should have one defining thing in each category:

Geometry: The shapes the buildings are made of, like blocky and simple for the Nexus.
Texture Color: A color that captures the faction's feel, like rust for the Scavenger.
Texture Material: The material that the faction uses to make it's buildings and units, like shiny metal for player.
Texture Detail: An element that is present in all textures, like a shiny circle or a striped line.

These rules are fairly high level and I'd like to go to a little bit lower level and make a few sets of textures that artists can download and manipulate to use in the new model. This also helps to keep the look consistent and lessens the work needed to be made when the artist can re-use stuff.

Any thoughts?

I think these are very good ideas. I already added some notes at http://wiki.wz2100.net/Style_guide and feel free to add to or change it.

Buginator: We are not rushing to mock up something here, we working on an already well polished game, and we should be worried about visual regressions just as much as code regressions, in my opinion.

[Deus Siddis]

I think these are very good ideas. I already added some notes at http://wiki.wz2100.net/Style_guide and feel free to add to or change it.

What about the new paradigm? And so the collective are a dull grey now instead of blue?

Also, do you have a technical art guide, that tells what poly budgets and texture resolutions you are looking for, on new bodies, propulsions, weapons, structures, terrains, etc.?

[Osmic]

I think getting content over 'style' is the first objective.
When that content is released, then someone can change/fix the texture(s) up.

As the old saying says, beggars can't be choosers.

This applies to everything we currently need done.

Actually, there's two things I mentioned that in fact speed up the content creating process. First, when you have a clear set of guidelines for the geometry and texture, you don't have to start designing from scratch. They say that having some limitations force you to be creative inside those boundaries than when there's absolutely no limit. Second, pre-made base textures gives a jump start to the whole process of texturing and decreases the time needed to make the models look like they're carved from the same stone so to speak.

[Per]

What about the new paradigm? And so the collective are a dull grey now instead of blue?

No, we are not changing anything, so if what I wrote is wrong, please feel free to correct it!

Also, do you have a technical art guide, that tells what poly budgets and texture resolutions you are looking for, on new bodies, propulsions, weapons, structures, terrains, etc.?

Not yet, but that should also be added as well. Terrain tiles are 128x128, for example, and using more than 20-30 faces for a component is probably more than will look good at that size. Textures for a single component should be no larger than 256x256, and preferably fit into the same texture page that is likely to be used by the other components that make up the full game object. Droid and building main bodies should probably use larger textures and more faces than other components, since they are larger visually in the game.

[Rman Virgil]

Actually, there's two things I mentioned that in fact speed up the content creating process. First, when you have a clear set of guidelines for the geometry and texture, you don't have to start designing from scratch. They say that having some limitations force you to be creative inside those boundaries than when there's absolutely no limit. Second, pre-made base textures gives a jump start to the whole process of texturing and decreases the time needed to make the models look like they're carved from the same stone so to speak.

* That is so true & well put.

* It is also a cornerstone principle of "Concurrent Engineering" (also known as Simultaneous Engineering) which has some far-reaching advantages over a serial approach.

* While orginating out of the Cathedral Playbook it works just as well in a Bazaar Context (where, IMHO, it can have even more powerful results thru sheer force of numbers) .

- Regards, RV

[DevUrandom]

Also, do you have a technical art guide, that tells what poly budgets and texture resolutions you are looking for, on new bodies, propulsions, weapons, structures, terrains, etc.?

You probably need to experiment with that to find what looks best. Don't forget to write it down then.

[cathuria]

Having fumbled my way blindly through designing an ECM turret, I wholeheartedly concur with this one.  A complete brief will help immensely.
And don't forget to include technical details for contributions, such as limiting geometry to tri's (or quads, etc.) and the file format for image maps, etc.  It makes it a lot easier to design models and materials for the game knowing all of that stuff beforehand.

[Deus Siddis]

Textures for a single component should be no larger than 256x256, and preferably fit into the same texture page that is likely to be used by the other components that make up the full game object.

I'm not sure what you mean by this, shouldn't each component module get its own texture file?

You probably need to experiment with that to find what looks best. Don't forget to write it down then.

Experiments would be much easier if the models and textures used in legacy warzone were made easily available in a format that could be opened in freeware/opensource blender 3d and the autodesk commercial equivalents. This way, the new models can be built with the old ones in the same scene for reference, allowing the general proportions and shapes to be retained. This would be most helpful.

[Per]

Compressing more textures into less texture pages helps keep performance up. Texture rebinding is expensive.

I am working on a tool to convert PIE files to 3DS files. I will let you know when it is done.

[DevUrandom]

Experiments would be much easier if the models and textures used in legacy warzone were made easily available in a format that could be opened in freeware/opensource blender 3d and the autodesk commercial equivalents. This way, the new models can be built with the old ones in the same scene for reference, allowing the general proportions and shapes to be retained. This would be most helpful.

Kage's Blender PIE plugin should help you with exactly that.
If there is a problem with that plugin, someone understanding Python might want to have a look, as afaik Kage currently is lacking time.

[Deus Siddis]

Kage's Blender PIE plugin should help you with exactly that.
If there is a problem with that plugin, someone understanding Python might want to have a look, as afaik Kage currently is lacking time.

Alrighty, thanks. Where do I find the PIE files though, do I need an svn checkout or can I download them directly from someplace?

[doom3r]

you mean game pies? if so, you can find them in warzone.wz file, use 7zip for extracting.

[Deus Siddis]

you mean game pies? if so, you can find them in warzone.wz file, use 7zip for extracting.

Yes, that's what I needed, thanks.