313 lines
9.7 KiB
Plaintext
313 lines
9.7 KiB
Plaintext
Crossfire Archetype Guide
|
|
=========================
|
|
Crossfire Development Team <crossfire@metalforge.org>
|
|
1.70.0-dev, March 2014
|
|
:numbered:
|
|
:toc:
|
|
|
|
Pixmaps
|
|
-------
|
|
The color bitmap files use the XPM library (called xpm-3.4f on
|
|
most ftp sites. A later version may be out now.)
|
|
|
|
This library is needed in order to compile crossfire with the color
|
|
pixmap support.
|
|
|
|
The pixmap files have the same name as the bitmap file with ".xpm"
|
|
concatenated to the end. If your system has short filename length
|
|
limits, this may cause a problem.
|
|
|
|
I use `pixmap` to edit the xpm files. This should be available the
|
|
same place the xpm library can be found. It does require the xpm
|
|
library.
|
|
|
|
All of the XPM files have been colored. However, only a small number
|
|
have actually been done so properly - that is, by hand, and with the
|
|
proper outlines. Many people are working on fixing more of these up.
|
|
|
|
If you do start to work on colorizing the other directories, please
|
|
let me know. Otherwise, you may start working on something that someone
|
|
else has already done.
|
|
|
|
The file xpm.template in the dev directory is a XPM file that has all of
|
|
the colors that are allowable for XPM files. This is to limit the total
|
|
number of colors used, in order not of overrun color spaces on systems.
|
|
If you really need a color not in that file, please send mail to Mark
|
|
Wedel (mwedel@pyramid.com), and it might be added to the list of
|
|
acceptable colors.
|
|
|
|
For a list of colors to use, look at the 'dev/xpm.template' file.
|
|
|
|
Mark Wedel
|
|
mwedel@pyramid.com
|
|
|
|
Perspective
|
|
~~~~~~~~~~~
|
|
Some coloring/perspective hints/clarifications from David Sundqvist:
|
|
|
|
Perspective in Crossfire is based on the XY coordinate system of possible
|
|
player movements, with a slight tilting of the graphics to allow for
|
|
greater detail and more interesting graphics, since walls have to be in
|
|
that perspective to allow joining. X and Y in graphics should correspond
|
|
to X and Y in the object. Z in the object is represented with 2 Y/X.
|
|
Keeping perspective consistency is mainly important in fixed objects
|
|
like buildings, walls and other background.
|
|
|
|
Light should generally come from the right side, so the left side of
|
|
buildings should be darker or shaded, as needed.
|
|
|
|
Wind is generally coming from the left side, so smoke or other things
|
|
affected by wind should be travelling towards the right side.
|
|
|
|
Naming Conventions
|
|
------------------
|
|
|
|
Archetype File Name
|
|
~~~~~~~~~~~~~~~~~~~
|
|
The name of an archetype file should be no more than 10 characters long, for
|
|
a total of 14 characters in the entire file name. This is to ensure maximum
|
|
portability across different systems.
|
|
|
|
NOTE: Is this still a limitation?
|
|
|
|
Archetype file names should end with an extension of '.arc'. Image files
|
|
have a 3-digit extension in the form of '.PDA', where:
|
|
|
|
P - part number
|
|
D - coding, or any other instance
|
|
coding in
|
|
A - animation phase
|
|
|
|
Numbering (PDA)
|
|
^^^^^^^^^^^^^^^
|
|
|
|
- 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
|
|
- Alphanumeric
|
|
- Can be thought as hexadecimals
|
|
|
|
Part Numbers
|
|
^^^^^^^^^^^^
|
|
|
|
3x3 : 1 2 3
|
|
4 5 6
|
|
7 8 9
|
|
|
|
2x2 : 1 2
|
|
3 4
|
|
|
|
3x2 : 1 2 3
|
|
4 5 6
|
|
|
|
2x3 : 1 2
|
|
3 4
|
|
5 6
|
|
|
|
Codings
|
|
^^^^^^^
|
|
|
|
.Direction
|
|
|
|
8 1 2
|
|
\ | /
|
|
7- 0 -3
|
|
/ | \
|
|
6 5 4
|
|
|
|
Same as in Crossfire
|
|
|
|
.Turnable (reflecting objects)
|
|
|
|
- 0 to left, vertical
|
|
- 1 to right, horizontal
|
|
- also in gates, signs, ...
|
|
|
|
Walls
|
|
~~~~~
|
|
|
|
Name format: 'name_X.arc', 'name_X.PDA.png'
|
|
|
|
1
|
|
|
|
|
8 -+- 2
|
|
|
|
|
4
|
|
|
|
X is a bit-wise combination expressed in hexadecimal form. For example,
|
|
8 + 4 + 2 + 1 = F describes a vertical cross, and 4 + 1 = 5 identifies a
|
|
vertical wall.
|
|
|
|
P, D, and A are always 1.
|
|
|
|
.Object Names
|
|
|
|
When creating '.arc' files, the object name is determined by a similar,
|
|
but distinctly different, scheme. See the server code in
|
|
'server/build_map.c' and 'random_maps/wall.c' for the source of the
|
|
information that follows. The arch name (ie. awall) must not have any
|
|
underscores. A suffix in the form _U[_V[_W]] is appended to the arch
|
|
name.
|
|
|
|
U is the number of connection points (ie. for a pillar U == 0, and for
|
|
a cross U == 4).
|
|
|
|
At the time of this writing, the formulae for calculating V and W is
|
|
not known, but, U, V, and W can be determined as follows. Calculate a
|
|
value called "connect" by adding the values of the connecting points:
|
|
|
|
4
|
|
|
|
|
1 -0- 2
|
|
|
|
|
8
|
|
|
|
Then use "connect" to pick a suffix:
|
|
|
|
0: _0
|
|
1: _1_3
|
|
2: _1_4
|
|
3: if (has_window)
|
|
_win2
|
|
else
|
|
_2_1_2
|
|
4: _1_2
|
|
5: _2_2_4
|
|
6: _2_2_1
|
|
7: _3_1
|
|
8: _1_1
|
|
9: _2_2_3
|
|
10: _2_2_2
|
|
11: _3_3
|
|
12: if (has_window)
|
|
_win1
|
|
else
|
|
_2_1_1
|
|
13: _3_4
|
|
14: _3_2
|
|
15: _4
|
|
|
|
For a complete example, a vertical cross wall graphic in an awall arch set
|
|
is named awall_F.base.111.png. Face information is kept in awall_F.face,
|
|
and the archetype data is in awall.arc. Inside awall.arc, the Object name
|
|
is awall_4.
|
|
|
|
Diagonal Walls and Roads
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
The legacy wall-naming convention is used in conjunction with the extension
|
|
to the name format described here to provide a uniform naming scheme that
|
|
supports corner connections. Legacy names do not need to change to simply
|
|
add diagonal versions of the legacy graphics.
|
|
|
|
The name format is 'name_XY.arc', 'name_XY.PDA.png'
|
|
|
|
X follows the same rules as used for the legacy wall format, except that
|
|
when there are no NSEW connecting points, X == 0.
|
|
|
|
Y may be omitted, or may be 0 if diagonal connecting points are not offered
|
|
by the arch. If diagonal connecting points are implemented, Y is a bit-wise
|
|
combination computed in the same manner as X, and is also expressed as a
|
|
hexadecimal digit. The difference is that it refers to corner connections:
|
|
|
|
1 2
|
|
\ /
|
|
X
|
|
/ \
|
|
8 4
|
|
|
|
For example, name_0F refers to a diagonal cross, or connecting points in
|
|
all four corners. name_05 and name_0A refer to pure diagonals.
|
|
|
|
Since diagonal pieces require corner fills, P is used to differentiate the
|
|
component parts of the diagonal.
|
|
|
|
P (part number) ranges from 1 to 3:
|
|
|
|
1 : used for "normal" pieces that connect direction points.
|
|
|
|
2 : used for a top corner fill needed to complete diagonal
|
|
connections.
|
|
|
|
3 : used for a bottom corner fill needed to complete diagonal
|
|
connections.
|
|
|
|
Examples of diagonal files are 'dirtroad_05.211', 'dirtroad_05.311',
|
|
'dirtroad_0A.211', and 'dirtroad_0A.311'. The archetypes for these are stored
|
|
in 'dirtroad_05.arc' and 'dirtroad_0A.arc'. The corner fill is a "part" of a
|
|
diagonal, and is not really useful on its own.
|
|
|
|
The '.211' and '.311' file names are based on the full diagonal, but are used
|
|
for all diagonal connecting points. Usually it is not necessary to
|
|
customize the corner piece to fit each and every possible XY combinationi
|
|
that incorporates a diagonal connecting point.
|
|
|
|
.Object Names
|
|
|
|
When creating object names, use a different format (_U_XYP) unless
|
|
the legacy naming format can be figured out and adapted to the
|
|
diagonal set - in which case, it should be documented here. This
|
|
format allows consistent object naming in the event that renaming is
|
|
desirable in the future, and it does not collide with the legacy
|
|
object naming.
|
|
|
|
U = Number of connecting points.
|
|
XY = Where X and Y are re-used as described above.
|
|
P = Where P is the part number.
|
|
|
|
Rivers
|
|
~~~~~~
|
|
WARNING: Consider deprecation of this format in favor of the extended wall
|
|
naming. It is more flexible than this format.
|
|
|
|
Simple diagonals, like non-branched rivers, are saved as 'name_XY.arc' and
|
|
'name_XY.PDA.png'.
|
|
|
|
X and Y use the direction scheme shown above (and copied here for ease of
|
|
reference). For example, river_15 runs north/south; river_26 runs from the
|
|
northeast to the southwest.
|
|
|
|
8 1 2
|
|
\ | /
|
|
7- 0 -3
|
|
/ | \
|
|
6 5 4
|
|
|
|
X and Y do not define direction of water flow. They are simply connecting
|
|
points to neighboring arches of the same set. X and Y are ordered low to
|
|
high, so it is not expected that a river_62 exist; instead the piece is
|
|
named river_26.
|
|
|
|
A cul-de-sac, or dead-end could have X == 0 and Y set to the connect point.
|
|
Conceptually, a pool could follow this same naming convention and set
|
|
X == Y == 0.
|
|
|
|
D and A are presently always set to 1.
|
|
|
|
P ranges from 1 to 3.
|
|
|
|
1 : used for "normal" pieces that connect direction points.
|
|
|
|
2 : used for a top corner wedge used to fill in diagonals (i.e. A
|
|
wedge in the top right or top left corner).
|
|
|
|
3 : used for a bottom corner wedge used to fill in diagonals (i.e.
|
|
A wedge in the bottom right or bottom left corner).
|
|
|
|
Examples of wedges are river_48.211, river_48.311, river_26.211, and
|
|
river_26.311. The archetypes for these are stored in river_48.arc and
|
|
river_26.arc. The wedge is a "part" of a diagonal, and is not really useful
|
|
on its own.
|
|
|
|
River junctions, add another digit to the format used by simple diagonals,
|
|
and are stored as name_XYZ.arc and name_XYZ.PDA.
|
|
|
|
X, Y, and Z represent the three directions the river exits. 367 would be
|
|
east,southwest, and west. Junctions, or branchesi, may also have multiple
|
|
parts - this happens when the junction has a diagonal direction.
|
|
|
|
By convention, directions for the river parts are in ascending order. That
|
|
is, if the exit locations are 2, 6, 3, the name could be branch_236 (not
|
|
branch_326, or branch_623, etc).
|
|
|
|
Complex branching paths could be set by adding digits to allow four or more
|
|
connecting points, but use of the extended walls format is recommended
|
|
instead.
|