sprites.csv file was the very first csv file that we created.
It defines all of the in game sprites. If it's not listed here,
it's not in the game. All of the sprites here are kept in memory
during the entire game (not on the main menus). There is a filtering
method to not load sprites that are not referenced, but once it's
loaded, it stays. This is important to remember because the number
of sprites that we have is directly related to why we demand a
64MB video card. These things take up a lot of memory that has
to be switched to the video ram for display. That's why if you
boost your system ram very high and your video card very high,
you sometimes can get the game to run on less than a 1Ghz processor.
I've had it running on a P3 600Mhz, with 1Gig system ram and a
128MB video card. I had to run in low mode, but it ran. The number
of sprites that we use has been a constant battle between Adam
and myself. Him looking to make the best looking game and myself
trying to make it run well. We comprimised.
you make a 3D game you must understand the payoff of using sprites
vs. 3D models. 3D models are cooler and use less memory because
you only need a small texture to map on the model. You don't have
to create a seperate texture for each frame of animation. But
the problem is that 3D models use a lot of polygons. This is what
affects video performance. Each sprites uses 2 polygons, where
as a 3D model could use 10-20 plus and it wouldn't look that good.
By using sprites we are able to get a lot more men on the map.
We have over 20,000 sprites on the map at any given time. We could
never do this with 3D models. Everyone would have to buy a $500
video card. So the payoff is that we can show a lot of guys, but
we have these gigantic animation files and require lots of video
ram and system ram. The houses, stone bridge, fences, and walls
are actually 3D models. These things can hog down the system which
is why we remove them in the low and medium video performance
top of the sprites.csv file starts with a small list of sprites
that must exist. That means that the game itself will be looking
for the sprite name and if it's not there it may crash. You can
change the graphic and anything else about the sprite, but the
sprite name must exist.
This is the identifier by which this sprite will be called
in all of the other csv files and sometimes directly from
the program. It cannot have spaces. I suggest using some type
of naming convention because as the sprite list grows, you
can lose yourself in the detail.
is the name of the graphic file on disk that this sprites
name refers to. Now the graphic directories are split up into
sub directories just for organization purposes. All sprites
referenced in objectives.csv are in the misc
directory. Sprites used in the unitsprite.csv are in
the units directory. Sprites in units.csv, which
are only the flags, are in the flags directory. Sprites
in effects.csv are in the effects directory.
Sprites in map_name.csv are in the terrain directory.
Sprites in toolbar.csv are in the toolbar directory.
Graphics can be 24bit TGA files with a seperate alpha channel
or PCX files with solid black as the alpha. I believe they
both will work in all cases. The only problem with PCX files
is that they have a hard alpha and don't look as nice, but
the files are smaller.
is the width of one frame of the sprite in pixels. It is not
the entire size of the file unless the file only contains
one graphic. Since video cards will always change the size
of the sprites to the next power of 2, there is no point in
making a sprite 60x60, since the game will automatically move
it up to 64x64 which is the next power of 2. It may reduce
the size of the file, but there will be no performance boost.
is the height of one frame of the sprite in pixels. It is
not the size of the file unless there is only one frame in
is the number of cells across that the file has. Currently
we use 16 frames for our units. This is because it looks much
nicer in the game. Previous sprite based games only had 8
angles, which showed a lot of popping as their direction changed.
By using 16 angles the popping is greatly reduced but the
file size and memory image is greatly increased. You can define
how ever many angles you want for your sprites. That is completely
up to you. I suggest that you keep them to a power of 2, otherwise
it would look weird. Our toolbar buttons also use this as
they are referenced by specific cell in the toolbar.csv file.
One note: When creating a new unit you must follow our facing.
The first cell must be facing away from you, looking at it's
back. They then continue rotating to the right across the
row. They must rotate to the right up until the last cell,
which would then rotate to look like the first cell. This
is easily seen by opening up any of our units graphics files.
is the number of cells down each column. The frames of animation
go down a column. With each cell down being the next frame
and the last cell continuing back to the first cell at the
top of the column. Any unit or terrain sprite can have angles
and frames. They will automatically be handled by the program.
Currently our trees and terrain sprites only have 1 cell in
their files. But it would be easy to add animated trees with
multiple angles to give the forests a must more realistic
is the speed of the animation in ticks. As you can see each
sprite can have a different animation speed, which is the
amount of time it takes to switch from one frame cell to the
next. Ticks are defined as 60 ticks per second. So if you
wanted the animation to take place once every second, you
would put in 60. This is a float, meaning that it can have
decimal places in the number.
is the action or firing frame. It is only used for unit sprites
that show the men firing their weapons. We sink up the program
to always fire when they reach this frame. There is more on
this in column M and N, as it's a little hard to understand
how it all works. Remember that frames are 0 based. Meaning
the top frame is frame 0, not 1. So if you have 20 frames,
you have frames numbered 0-19, there is no frame 20.
is the number of game units above the terrain that the sprite
will be drawn. This is not in yards or any other standard
unit of measure. For our scale, we have 32 game units per
yard. So if you want to convert, just do the math.
is tells the engine how to load in the graphic. The value
can be 0 or 1. Basically this determines if the graphic is
loaded in exactly as defined (sharp=1) or if the engine can
smooth out the graphic (sharp=0) and blur it a little. I can't
notice much of a difference, you have to have a picky eye
like Stephen or Adam to see the difference. We use sharp for
our toolbar, because you can definitly tell there. Remember
that the units and terrain sprites are somehow resized when
they are drawn. We don't know why, it's one of our complaints
with this engine. Our unit sprites are actually tall and thin,
but the engine shortens and fattens them.
is tells the engine what size you want the sprite to be in
the world. You can shrink or grow the sprites depending on
your needs. For example if you put 0.5 here, the sprite will
be 50% of it's original size in the world. If you put 2.0
here, it will be 200%. You can leave this empty if you want
it the same size as in the file.
forests are dynamic, meaning that our game fills them in when
the level is loading. See the map_name.csv file write up for
more detail. When the terrain graphic is placed we can draw
a shadow for it right on the terrain. This really adds to
the realistic look of the world. Without a shadow it looks
kind of dumb. The shadows for the units are drawn in the cells
of animation. So if you create a terrain sprite, you'll want
to fill this in. The name BigRock, is just a model from our
map that is used to draw the sprite on the ground. We don't
have any others, so if you want a shadow, just fill this in
with BigRock like all of the other terrain sprites.
it would not make sense to have the weapon firing rate depended
on the number of frames of animation, we have defined a firing
time in the weapons.csv file. Certain unit skills can modify
this time, so it's variable. In order to pull this off, we
need to know what to do while we're waiting to fire the weapon.
That's were this loop comes in. This loop will tell the engine
which frames to continuously go through until it's time to
fire the weapon. We use this for our infantry. They will continue
to push in the ramrod until it's time to fire. This must be
defined for any firing animation, even if it's only 1 frame.
Also, these frames cannot depend on circling back to the first
frame. For example: Our men fire on frame 35, but loop between
frames 13 and 19 while waiting to fire. The engine calculates
how long it will take to reach frame 35, then will loop between
frames 13 and 19 until it's time. You could not have them
loop between frame 26 and frame 5 because it would require
going back to frame 0 and the game won't handle that situation.
For best results have the firing frame towards the end of
the frames, because it looks better while falling back and
retreating. Remember that these frames are 0 based, not 1
The begin frame is the first frame of the loop.
is the last frame of the firing loop. If it is not time to
fire and this frame is reached, the next frame will be the
one mentioned in the Begin Loop.