Difference between revisions of "User:Ayin/New terrain graphics system proposal"

From The Battle for Wesnoth Wiki
m (skeleton of the proposal)
m (Make terrain_graphics WML driven by terrain WML)
Line 60: Line 60:
 
==Proposals==
 
==Proposals==
  
===Make terrain_graphics WML driven by terrain WML===
+
===Part 1: Make terrain_graphics WML driven by terrain WML===
 +
 
 +
Part 1 of the proposal is to make <tt>terrain</tt> WML define which rules are to be associated to a given terrain. For example:
 +
 
 +
  [terrain]
 +
    id=grassland
 +
    name= _ "Grassland"
 +
    char=g
 +
    '''graphics=grassland'''
 +
  [/terrain]
 +
 
 +
  [terrain]
 +
    symbol_image=village-elven-tile
 +
    id=village
 +
    name= _ "Village"
 +
    char=t
 +
    heals=true
 +
    gives_income=true
 +
    '''graphics=grassland,elven-village'''
 +
  [/terrain]
 +
 
 +
  [terrain]
 +
    symbol_image=forest-tile
 +
    id=forest
 +
    name= _ "Forest"
 +
    char=f
 +
    '''graphics=grassland,forest'''
 +
  [/terrain]
 +
 
 +
The <tt>terrain_graphics</tt> rules would not apply on terrain characters anymore, but would, instead, apply on symbols like "grassland", "forest", "village", etc.
  
 
===Use modular terrain graphics code===
 
===Use modular terrain graphics code===
  
 
===Sanitize the vertical layering code===
 
===Sanitize the vertical layering code===

Revision as of 11:31, 15 October 2005

This page is a working document for a proposal for a complete rewrite of the terrain graphics system. It may be considered as a counter-proposal to the extended terrains proposal.

Motivations for the proposal

The current terrain-graphics system is a powerful, albeit complex, system whose purpose is to transform maps (which are, basically, 2-dimensional arrays containing 1-character terrains) into a list of graphics for each location in the map.

The base for the system, and the root of a terrain_graphics rule, is: "pattern of terrains => associated images". In my (Ayin (talk)) opinion, pattern-based rules are the way to go: those are simple to understand, and allow nearly anything.

However, the current system (see documentation here TerrainGraphicsWML, or, better, here) has several drawbacks, which I will try to detail below:

Very WML-intensive

The basic, pattern => images system, is quite hard to type effectively in WML.

One simple, standard rule takes about 20 to 50 lines of WML. Considering that completely defining a "castle" with a keep takes about 7 rules (using rotation symetries), and a basic transition takes 4 rules (again, using rotation symetries), this means about 200 lines of WML to completely define a transition.

To solve this problem, the WML macro system is used quite intensively. Considering that the terrain-graphics.cfg file only contains macros and comments, and is about 800 lines long, and considering each macro rule generates, more or less, 40 lines of WML, this amounts to many lines of WML for the engine. Some testing shown this amounts to about 13000 lines in Wesnoth 1.1-svn. This is about 1/4 of the WML cache.

The problem with this use of macros is that directly coding terrain_graphics rules is pretty much deprecated: it is recommended to use macros which re-use already-created rulesets instead of directly using new ones. We are more or less falling in the situation of Sendmail, where what was originally a "config file" became "program logic", and where the "config file" uses some macro system to transform higher-level macros into the actual low-level file which is then parsed by the compiled program.

This is a bad thing.

Relatively slow

Although there have been many optimizations in this way, rebuilding the list of terrain graphics (when, for example, a terrain has changed) still is pretty slow on older computers.

Quite a complex system

The pattern => images system is something very simple, conceptually. However, to be able to properly generate terrain graphics, the following subtelties must be taken into account:

Rule overlapping
The main problem with this approach is to specify precedence, and mutual-exclusiveness, of rules. For example, rules can be mutually-exclusive:
  • on an hex (only one rule of this "kind" can apply on a given hex)
  • on a hex border (only one rule of this "kind" can apply on a given hex border)
  • or on a hex corner (only one rule of this "kind" can apply on a given hex corner)
Furthermore, some rules have to be independant one from the other (for example, rules defining the base terrains and transitions, and rules defining the overlay graphics, are totally independant), and some rules are mutually exclusive (for example, all rules defining base terrain transitions are mutually exclusives on hex borders, all rules defining base terrains are mutually exclusive on hexes, all rules defining some kind of castle-like fence are mutually exclusive on hex corners).
To solve this problem, a rule may apply "flags" on some hexes, and check for the presence, or absence, of flags before being applyied.
Image ordering and adjustment
Images will necessarily have to overlap. The overlapping order of images is the source of many potential graphical glitches. A simple, layer-based mode to specify the overlapping order of images is not enough, nor is the "drawing in the order the rules are defined" solution.
The current system uses an ordering model based on 2 different shapes for images:
  • Images representing terrains layered over the floor. Those use a simple layer-based model
  • Images representing terrains standing vertically on the floor. Those have x,y coordinates, and are layered in the logical order. Specifying those coordinates seems quite hard to many terrain developers.
Using symetry properties
Most rules (hopefully) have 6-way rotational symetry properties. If they had not, the already huge amount of WML used would actually have to be multiplicated by 6. However, defining template-like rules which spawn 6 actual, rotated rules is not trivial:
  • The rule itself can be rotated, but not the images themselves. Said images must have different filenames. The rule rotation must then have a way to specify the name of those files.
  • Same for flags and rule overlapping
  • Same (worse?) for layering of "vertical" images.

Hard to understand

Overall, the system has many possibilities, which have successfully been used to expand the graphics possiblities on Wesnoth. However, it looks like that few (no?) people understand it enough to use it effectively, and that the only solution, for graphics designers, to implement new ideas or to fix glitches is to ask me, on IRC, how to do it. As said above, the system is split in two parts:

  • A WML part which can be considered program logic, which is quite complex. I (Ayin (talk)) was the only one to actually commit changes in this part.
  • A WML-macro parts which is more-or-less accessible to artists, but which still retains a large part of black magic. (For example: "{TERRAIN_ADJACENT_CORNER_PROB K q  !NQqCK 56,76 sunken-ruinkeep3-wall-1 25}": who know what those "56,76" numbers mean? And what would happen if those were changed?)

I've been starting to thing the problem is that the system is too powerful, and that going all-WML may not necessarily be a good idea. Being generic is good, being too generic may prove harmful.

Proposals

Part 1: Make terrain_graphics WML driven by terrain WML

Part 1 of the proposal is to make terrain WML define which rules are to be associated to a given terrain. For example:

 [terrain]
    id=grassland
    name= _ "Grassland"
    char=g
    graphics=grassland
 [/terrain]
 [terrain]
   symbol_image=village-elven-tile
   id=village
   name= _ "Village"
   char=t
   heals=true
   gives_income=true
   graphics=grassland,elven-village
 [/terrain]
 [terrain]
   symbol_image=forest-tile
   id=forest
   name= _ "Forest"
   char=f
   graphics=grassland,forest
 [/terrain]

The terrain_graphics rules would not apply on terrain characters anymore, but would, instead, apply on symbols like "grassland", "forest", "village", etc.

Use modular terrain graphics code

Sanitize the vertical layering code