Latest Posts

Changes in GraphicsDevelopment

Editor Comment

Added section on Blender Materials and Textures


Revision Differences of Revision 11

## Graphics Development ¶

Everything from buttons to buildings, from windows to workers, in short everything that is visible with regard to Widelands falls into this category. ¶

[TOC] ¶


### A Word About Style ¶
The overall style of Widelands aims for a "gentle" player experience. In visual terms, we attempt to achieve this through the use of muted colors and some softening of photo-realistic images. Careful attention also must be made in the use of colors that will not distract and clash with other screen elements. In other words, we try to keep it visually interesting without assaulting the player's senses. It should also go without saying that a consistent use of colors and patterns is very important to tie the player's experience into one cohesive whole. ¶

### Links to Existing Art-related Wiki Pages ¶

* WidelandsArtEthics - Do's and Don'ts ¶
* AboutColors - The use of Player Colors ¶
* BlenderPerspective - 3D Modeling ¶
* DevelopmentgameContent - Descriptions of tribes, story lines, etc. ¶
* GenericMovementSuggestions - A short brainstorm of animations ¶
* ImmovableProgramReference - WARNING: Technical Content :) ¶
* WorkerCommands - A short list of commands for worker conf files ¶
* CampaignUi - Explanation of the structure of campaigns in Widelands ¶
* TriggerAndEventsReference ¶
* [Productionsite Program Reference](http://widelands.svn.sourceforge.net/viewvc/widelands/trunk/doc/productionsite_program_reference.xhtml) - conf file commands for production sites ¶
* MarkupReferenceForRichtexts ¶


### 2D Graphic Development ¶
Every graphic, even those modeled in 3D, ends up as one (or more in the case of animations) 2D image by the time it is usable in the game. The predominant graphic file type in Widelands is PNG due to its lossless compressibility and support of alpha channels. Some jpeg files are used as loading scenes (pictures that are displayed on the screen while a game loads) due to their superior handling of photographic images. ¶

#### 2D Formats and Tools ¶
Any 2D graphics program may be used to create content as long as it can ultimately generate png or jpeg. Because neither png nor jpeg support multiple layers, the Media Trunk contains a large number of source files in the xcf format (native to the Open Source graphics tool [GIMP](http://www.gimp.org/).) Maintaining these original files as sources in the Media Trunk, makes future modifications to those images much easier. ¶

#### User Interface Graphics ¶
The User Interface, "UI", is that part of the game that conveys information to the player through logos, menus, pop-up windows, splash pages, etc. It also supports input from the player with buttons, check boxes, icons, and so on; and it makes the whole experience more pleasing to the eyes with backgrounds, borders, fonts and the like. When designing an element for the UI, strict attention must be given to the specific dimensions that have been coded for it by the programmer who has painstakingly plotted its placement in relation to other elements that will appear on the screen with it. ¶

#### 2D Game Graphics ¶
The purpose of any game, of course, is that it be played. Game graphics bring the playing experience "to life". Whether it is a building or a worker or the ground that they stand on, the visual representation of these elements must echo what has already been said about style and color. The scale of the game engine (i.e. the size of the playing elements on the screen) is such that great detail in a particular image can easily be lost when it is reduced to fit on the game board. So some shortcuts can be made when designing. But the fact that a worker can pass with balls for hands, brings with it the need to perhaps over-emphasize features that are desirable to be seen. (Is that a "fishing pole" or a "walking stick" that little guy is holding?) ¶

#### WL Editor 2D Graphics ¶
The graphics utilized in the Widelands Map Editor, aside from its User Interface graphics which it shares with the game engine, are housed in the ~/worlds folder of the main trunk. They fall into three basic categories: terrain textures, bobs and immovables. ¶

* __terrain textures__ - These are seamless 64x64 pixel png files that are used to paint the ground surface of the game maps. They are housed in the /pics folder of every world. They can even be animated to represent surfaces like water and lava. ¶

* __bobs__ - [definition](http://en.wikipedia.org/wiki/Blitter_object), in Widelands are virtually every object that can move around on the gameboard that isn't a worker. This, of course refers mostly to the "critters" (animals) that can populate a game map. ¶

* __immovables__ - in addition to objects like stones and trees that appear in the game, this category also includes indicators which map-makers use to represent player headquarters positions and resources such as coal and iron. Immovables can be animated for use in the game to show things like a burning building or tree leaves rustling in the wind. ¶


### 3D Graphic Development ¶
While all of the images used in Widelands are 2D, animation is made much easier when rendered from a 3D model. With very few exceptions, the great majority of objects on the game board (indeed all of the animated ones) have their start as a 3D model. ¶

#### 3D Modeling in Blender ¶
The 3D models (or "meshes") for Widelands are stored in the Media Trunk as .blend files. The .blend file format is native to the Open Source 3D modeling tool [Blender](http://www.blender.org/). Unlike some 3D modeling tools, Blender has a wide set of features that support everything from importing and modeling 3D meshes to generating fully rendered 2D images and animation. All of the .blend models in Widelands have been created and stored from [Blender version 2.49](http://www.blender.org/download/get-blender/). ¶

#### Blender version 2.5x ¶
Development of Blender has certainly not stood still and beta version 2.55 has recently been made available for user testing. As tempting as it is to jump right into using the latest development release, we remain using version 2.49 for Widelands 3D files for two compelling reasons. First, Version 2.49 is Blender's most current "stable" version and for a developer having reliable tools is a "good thing". Secondly, the python scripts upon which we have come to strongly rely do not work in version 2.5+. So for now, we are staying with version 2.49. :) ¶

#### The Templates ¶
A consistent appearance of the images on the game board is very important. It would look strange to see a building from one angle and another building next to it from a completely different angle, possibly with different light and shadow patterns as well. So everything on the playing field should be presented from the same specific camera angle and lighting. In other words, they should all be rendered on the same "stage". ¶

To make consistency of these elements as easy as possible, two "empty" .blend files exist as templates which the artist can use either right from the start as he/she creates the model or as stages into which the model can be appended and not have to worry about setting up the camera and lighting. ¶
These template files are: empty_building_template.blend and empty_worker_template.blend and can be found in the ~/graphics/stock_sources/blender_set_templates folder in the Media Trunk. ¶

#### Blender Materials and Textures ¶
Because much modeling work is done in folders outside of the Trunk, we request that ALL materials that are used in a model be embedded (i.e. not linked from an external library) and any 2D graphic images used for textures be packed with the model. (There is a button to toggle the packed status of the image at the right of the filename in the Image tab of the Blender Textures panel.) External libraries can be nice, however omissions can crop up if the material/texture is linked to other models where the library is not available. In other words, we like to see the .blend files as self-sufficient as possible regarding the materials used in them. Scripts are another matter as modifications to them have more wide-ranging impact. ¶

#### The Scripts ¶
Through Blender's Application Programming Interface, functions that are repetitive and/or common to some task can be scripted to run automatically. The following Python 2 scripts have been written for the Blender 2.4x API to automate the rendering of animation frames and their player color masks. They are housed in the ~/graphics/tools/ folder of the widelands-media repository: ¶

>__menu.py__ - automates the rendering process and displays a menu for specifying output destination, view direction, number of animation frames, etc. Calls the automask.py script if playercolor masking is requested. ¶

>__automask.py__ - generates playercolor masks for rendered models ¶

>__crop_animation.py__ - This script takes a list of conf files as arguments and crops ¶
the correponding animations to their proper size. ¶

These next two scripts load the menu.py script from the graphics/tools directory of the widelands-media repository, so they need to have the /tools directory with its contents somewhere in the .blend file's tree. ¶

>__innerBuilding.py__ - calls the menu script for rendering building models and other models for which viewing is required from only one direction. (internal to empty_building_template.blend) ¶

>__innerWorker.py__ - calls the menu script for rendering standard models. It supports views of the rendered model from multiple directions. (internal to empty_worker_template.blend) ¶


#### Animation ¶
When it comes to adding interest to a game, certainly animation plays a major role. The AnimationPage describes how the workers, buildings, animals and other objects are brought to life in Widelands. ¶


### Conf Files for Graphic Elements ¶

#### Description ¶
Programmers can use many different methods to control how and when a program runs and provide it with information that can vary. In Widelands, one method we use are text files named "conf" which are associated with specific objects in the game. A conf file contains information to describe the object to a program and thereby allow that program to perform tasks that are common to many different objects. Conf files also can contain commands to control how the program performs those tasks. Because it is a plain text file, conf files can be edited or created by any text editor. ¶
> __NOTE:__ Care should be taken when editing conf files to prevent accidentally changing program control information that effects game play. ¶

A wide variety of objects have conf files associated with them, and in almost every case the conf file and the graphic files of the object(s) to which they refer are placed in the same folder, (or at least in the same directory path for collections of objects like worlds and tribes). ¶

Here is a list of graphic objects with which conf files are associated: ¶

* __workers__ including carriers, manufacturers, harvesters and soldiers ¶
* __wares__ the raw materials and manufactured goods which are the basis for a tribe's economy ¶
* __buildings__ including production and harvesting sites, military sites and training sites ¶
* __critters__ (animals) ¶
* __trees__ ¶
* __immovable objects__ like stones, ruins, fossils, etc. ¶
* __productive areas like farm fields and vineyards__ ¶

And as stated above, even tribes and worlds have their own conf files to describe their contents and environment. ¶

#### Artists and conf files ¶
Not all artists are coders, nor should they have to be, but there are some elements in a conf file for which the artist is responsible. ¶
Conf files that are associated with graphic objects like those listed above contain at least one animation section that specifies the graphic file(s) associated with the object. I'll call these _"animation sections"_ even if the object has only one graphic file, like a ware for instance. ¶
Let's take a look at some common parameters that the artist should know and can appear in an animation section. ¶
Section headers are always bracketed, e.g. __[walk]__, and parameters are listed on separate lines. ¶

##### Picture, Pics/Dirpics There is a difference. ¶
These parameters have a value that is the name of the object's graphic file. In the existence of multiple graphic files, a value will contain "wild card" place holders for the parts of the file name that differs. ¶
The __Picture__ parameter is often used with immovable objects and can appear anywhere in the object's conf file. ¶
The __Pics__ parameter is used in an animation section as is the __Dirpics__ parameter which is used when the images have more than one orientation such as walking east and west. ¶
> _Example 1:_ Picture=Stone1.png ¶
> _Example 2:_ Pics=Stone1.png ¶
> _Example 3:_ Pics=tree_??.png - which would point to tree_00.png, tree_01.png, tree_02.png, etc. ¶
> _Example 4:_ Dirpics=walkload_??_!!.png - points to walkload_00_e.png, walkload_00_se.png, etc. ¶

##### Hotspot ¶
Hotspots define a place on a graphic image through its x and y coordinates that can be used as a handle or reference point to provide control over positioning the image on the game board. ¶
For example Hotspots help carriers stay on the road and control how high or low, left or right they carry any wares. "x" coordinates are the number of pixels from the left edge of the image. "y" coordinates are the number of pixels from the top edge of the image. ¶
> _Example:_ hotspot=17 12 - where 17 is the x coordinate and 12 is the y coordinate ¶

##### playercolor ¶
The __playercolor__ parameter, when used, has a value of "true" to indicate the existence of playercolor mask files for the object. For more information on playercolor see the AboutColors page. ¶

##### fps ¶
The __fps__ parameter is used to specify the frame rate, i.e. playback speed, in frames per second of an animation. ¶
> _Example:_ fps=20 ¶

#### Buildings ¶
Conf files for buildings, depending on their nature, can contain many unique parameters. Most of which should not be adjusted by artists. ;) But buildings can have animation, of course. Hotspots for buildings denote where the road ends at the building. ¶

The following animation sections can be found common to all buildings: ¶
>* __[build]__ - this section defines the building's construction animation (usually 4 frames) ¶
>* __[idle]__ - this animation section depicts the building in a non-working or resting state ¶
>* __[working]__ - this section depicts the building in a productive working state ¶

As for those many other parameters that can be found in a building's conf file? Most of them control the building's influence on game play and can be found on the ConfFileCommands page. Also see, the ImmovableProgramReference page for more information pertaining to building animation. ¶

#### Worker Parameters ¶
Conf files for workers will also contain an [idle] animation section. (Hey, they have to rest sometime!) :D ¶
Other animation may also be represented in the following sections: ¶
>* __[walk]__ - ¶
>* __[walkload]__ - depicts the worker carrying a ware ¶

Special programs unique to certain workers can include these animation sections: ¶
>* __[hack]__ - used for lumberjacks and stonemasons (and occasionally programmers) ;) ¶
>* __[plant]__ - used for farmers, foresters, etc. ¶
>* __[harvest]__ ¶
>* __[breed]__ - like plant, but used for gamekeepers and fish_breeders ¶

Soldiers have these specific animation parameters for their unique battle graphics: ¶
>* attack_success_w= ¶
>* attack_success_e= ¶
>* attack_failure_e= ¶
>* attack_failure_w= ¶
>* evade_success_w= ¶
>* evade_success_e= ¶
>* evade_failure_e= ¶
>* evade_failure_w= ¶
>* die_w= ¶
>* die_e= ¶

Other programs unique to workers will be associated with their own animation sections. For more information, see the ConfFileCommands and WorkerCommands pages. ¶