Difference between revisions of "User:Mesilliac"

From The Battle for Wesnoth Wiki
 
Line 1: Line 1:
 
a.k.a. Yobbo
 
a.k.a. Yobbo
 +
 +
= Terrain WML Cleanup Proposal =
 +
 +
I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.
 +
 +
Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.
 +
 +
== Terrain Macros ==
 +
 +
=== Current system ===
 +
 +
Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.
 +
 +
=== Proposed change ===
 +
 +
Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.
 +
 +
=== Benefits ===
 +
 +
* Easier to maintain, as macros are separated from terrain declarations
 +
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg
 +
 +
=== Drawbacks ===
 +
 +
none
 +
 +
== Randomly chosen images ==
 +
 +
Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
 +
{TERRAIN_BASE_PROB  Uu                  cave/floor2       20}
 +
{TERRAIN_BASE_PROB  Uu                  cave/floor3       25}
 +
{TERRAIN_BASE_PROB  Uu                  cave/floor4       33}
 +
{TERRAIN_BASE_PROB  Uu                  cave/floor5       50}
 +
{TERRAIN_BASE      Uu                  cave/floor6}
 +
This gives an equal probability of each listen variation appearing on any given hex.
 +
 +
The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.
 +
 +
=== Current system ===
 +
 +
All random terrain variations must be explicitly specified and a probability given in _final.cfg.
 +
 +
=== Proposed change ===
 +
 +
In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.
 +
 +
=== Benefits ===
 +
 +
* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
 +
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary
 +
 +
=== Drawbacks ===
 +
 +
none
 +
 +
== Standard set of terrain graphics macros ==
 +
 +
There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.
 +
 +
=== Current system ===
 +
 +
Macros are added as necessary.
 +
 +
=== Proposed change ===
 +
 +
The addition of a set of standard macros for common terrain types:
 +
 +
; Base Terrain
 +
: A simple flat terrain.
 +
:* Transitions are used if present.
 +
:* Variations are used if present.
 +
:; macro arguments: Terrain_identifier, base_image_name, layer

Revision as of 06:05, 13 March 2008

a.k.a. Yobbo

Terrain WML Cleanup Proposal

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

Terrain Macros

Current system

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

Proposed change

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

Benefits

  • Easier to maintain, as macros are separated from terrain declarations
  • Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

Drawbacks

none

Randomly chosen images

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:

{TERRAIN_BASE_PROB  Uu                  cave/floor2		       20}
{TERRAIN_BASE_PROB  Uu                  cave/floor3		       25}
{TERRAIN_BASE_PROB  Uu                  cave/floor4		       33}
{TERRAIN_BASE_PROB  Uu                  cave/floor5		       50}
{TERRAIN_BASE       Uu                  cave/floor6}

This gives an equal probability of each listen variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

Current system

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

Proposed change

In new macros, add the probability macros for equal probability automatically, using the image stem plus the numbers 1-9 for additional variations.

Benefits

  • This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
  • New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

Drawbacks

none

Standard set of terrain graphics macros

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

Current system

Macros are added as necessary.

Proposed change

The addition of a set of standard macros for common terrain types:

Base Terrain
A simple flat terrain.
  • Transitions are used if present.
  • Variations are used if present.
macro arguments
Terrain_identifier, base_image_name, layer