modding home
basic scenario creation
uniform modding overview
the order of things
variables reference
commands reference
map layout

The 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.

Whenever 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 modes.

The 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.

Column Explanation
A: Name 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.
B: File   This 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.
C: Width This 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.
D: Height This 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 the file.
E: Angles (across) This 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.
F: Frames (down) This 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 look.
G: Animation Speed This 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.
H: Action This 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.
I: Above Terrain This 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.
J: Sharp This 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.
K: Scale This 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.
L: Shadow Our 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.
M: Begin Loop Since 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 based.
The begin frame is the first frame of the loop.
N: End Loop This 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.