Tiles are 32x32 pixels, and can be changed fairly easily. Actually adding a tile is difficult, since the programs need to know about the tiles, and this is hard-coded.
There is a file called "allFeatures.png" that has 8 rows and 27 columns, each with a 32x32 tile. These numbers are chosen for various reasons. Typically, we use a power of 2, and we need to have a tile size that is large enough without being too large. Originally, the tiles were 16x16, but this turned out to be too small. The 32x32 size seems to work well. There is also a larger version, where each tile is 128x128. These are the same tiles designs, just made larger. The idea is that these can be used with a 3-D world view. We could have the software automatically scale them, but having the designs as the correct size means that we can add details to make them look better. The number of rows and columns in the allFeatures.png file is arbitrary. It would be a good idea to expand it by adding rows, instead of trying to add columns. Originally, the rows represented different things: rows 1 and 2 were decorative, something the player could always walk over, then rows 3 and 4 were collectible items, then rows 5 and 6 were barriers that might be removed (i.e. the keyholes disappear if the player touches them and has the correspodning key), and rows 7 and 8 were barriers that could not be removed. This made the programming easy, since the row implied a lot about the tile. However, I found that the decorative tiles were not very useful, abd the collectible tiles were too few. Now, the tile data is in another file, tile_template.xml. These files (allFeatures.png and tile_template.xml) are kept the same as much as possible for the "maze" game. However, each copy of the game has its own copy of these files, meaning that these files might be different from one version to the next. This is by design, so that you could keep the game engine the same, change the data, and have a new, different game.
To change a tile, the first thing is to figure out which one to replace. There are around 40 squares in the first 2 rows that are not used, as of this writing (January 2019). There are a few that should not be used: the first 3 in row 1 do not look like anything, but they are used a lot. Once you find a suitable one, change the allFeatures.png file with a utility like pixelEditor3.m (MATLAB), either pasting a new 32x32 image, or drawing a new design there.
With the new graphics, change the tile_template.xml file with the tile editor program (designTiles.html). Click on the tile, and change the fields as needed. Note that when "effect" is true, it means that the program should do something unique in response. For example, the "-1g" tile should block the player unless he has at least 1 gold piece, in which case it should deduct it, and remove the tile. Other tiles, like the keys, should have "collectable" set to true, but the program treats them the same: display the "Text", put add 1 to the item list, and erase the tile. There may be data errors in the tile_template.xml file, since many of these fields are populated with default values. For example, a tile might have walkOver set to true, but flyOver set to false, which does not make much sense, unless it were a tunnel tile?
Once the tile is in place, you should be able to use "designRoom.html" to place it wherever you want.
Hopefully, changing the graphics and the XML data is enough. It is possible that you want the program to do something related to this tile. There are some tile-related functions, like "check4specialTile", "destroy", "ice", "lightUpTheRoom", "restoreTrees", "weaponAffect", and "projectileAffect". The "check4specialTile" one has a switch statement in it for when TileList[cell].effect is true. This is where any special programming regarding the tile should probably go, and if I had to bet on what thing you need to change, that would be it. The "weaponAffect" and "projectileAffect" would be my next 2 guesses.
If the tile is associated with a weapon, you will need to add the weapon as an object. See below.
You may need to add to the "object_templates.xml" file, such as when adding a weapon or a new character. You might be able to copy an existing object's XML data, and paste it in the file. It should not matter where, though the objects have been arranged by type: monster (i.e. character), projectile, and weapon. The program needs a way to match a tile to an object, and the "name" in both object_templates.xml and tile_template.xml should match exactly (it may still be case-sensitive). Most of the XML data can be copied from an existing entry, and not all fields are used with all types of objects. The "graphics" tag is one that may need attention, since it specifies a graphics file that goes along with the object. For example, there is a sword in the game. One of the tiles (tile number 59) is the sword icon. If the player moves onto this tile, he will collect a sword. The object editor shows the sword object as template number 138. (The numbers are not important, and might change. Also, if you are adding a new character, you don't need to have a tile associated to it.)
The template object for the sword includes "graphics/swords.png" with the graphics tag. So when the player decides to use the sword, he clicks on the icon (from the tile file) shown on the status section, and the program switches weapons to the sword. When the player uses the sword, the program looks to the "graphics/swords.png" file to determine what to show on the screen. The file should contain at least 4 rows of graphics, for the sword's different orientations (left, right, up, down). It might have several columns, to show the sword swinging. Also, pay attention to the "width, height, rotatedwidth, rotatedheight" tags, as well as "cellheight, cellwidth". Each image of the sword on the sprite sheet should fit inside a bounding box, like 32x32, though the size can be whatever you want. This is the "cellheight, cellwidth". The graphic probably does not use the entire cell, which is fine, and the other tags ("width, height, rotatedwidth, rotatedheight") let you specify a bounding box for the left/right orientations ("width, height") or up/down ("rotatedwidth, rotatedheight").
For characters, the graphics file should have 3 rows, or more. Some characters, like the bats, look fine as simply facing left/right, and row 3 is for "hurt". Row 3 should have an image for hurt-facing-left and hurt-facing-right. Often, the graphics is the same, just colored differently to stand out when the character is hurt, such as turning it red. Other characters, like the player's, should have a graphics row for left/right/up/down, attacking, and hurt. The attacking and hurt rows should have at least 4 columns, which means that all other rows should have the same number of columns, too. The attacking and hurt have a column for left, right, up, and down. Characters with only left/right/hurt graphics can also move up/down, in which case the program maps the movement to the left/right graphic. If you only have 3 rows, do you need 2 columns for hurt (left, right) or 4 (left, right, up, down)? (I don't know the answer. I wrote that part of the software a long time ago!) I would like to add more to the graphics, like a row for a dying sequence, before the character disappears. Also, I'm not happy with the attacks having to be only along 4 directions, instead of 8.
If you have a problem with the graphic not showing up or not looking right, first check these tags' values ("width, height, rotatedwidth, rotatedheight, cellheight, cellwidth"), then check the graphics file, and make sure the program can find it. There could be other problems, like what if the alpha component for the png file is all 0, or 0 in places you don't want it to be? It could also be a problem with the program, so something you might want to try is to see if an earlier version gives you better results. More than likely, the tag values, or missing the graphics file, are the problem.
You may also want to see the instructions on how to add a graphic.
The animation is one of the most satisfying features to get right in a game. Adding a new character is done with a few steps. The most time-consuming part is to make the sprite sheet. The sprites should be arranged in rows, according to left, right, and hurt. This is all that need to be specified now. (I might change this in the future to require more rows.) When a character is shown, the image will update from left to right, then repeat on that same row. The sprite sheet should be in the "graphics" directory with the others. You need to know the cell width and height,
I have a sprite sheet with 3 rows, and 4 columns. Each cell is 32x32. Inside the cells, the largest image is 29 pixels tall, and 17 pixels wide. Since there are no different images for up/down, the rotated width and height are the same. The file is called "vampires.png". It looks like a troll, and if I get the time, I want to change what the troll looks like.
cascade:Desktop> cp -i vampires.png /Library/WebServer/Documents/demoMaze13/graphics/ cascade:Desktop> vi /Library/WebServer/Documents/demoMaze13/object_templates.xml I copied the 42 lines for a monster object (that might change if more attributes are added). Then I changed the "name", Width, Height, RotatedWidth, RotatedHeight, CellWidth, and CellHeight, to "vampire", 17, 29, 17, 29, 32, 32, respectively. I also changed the name of the graphic to point to the new sprite sheet. Other things can be changed, too, but that is not necessary for now.
Putting an entry in object_templates.xml does not mean that it will be in the game, just that it CAN be in the game. To see the character, I need to put a copy of it in the testAI.xml file, which specifies the data for the game. (The name is a hold-over from when I made a special version to test the AI capabilities. I might change it to something more meaningful.) The difference between object_templates.xml and testAI.xml is kind of like a class versus an object instance: the object_templates.xml gives the data defining the character, then testAI.xml can have as many copies of it as we want. In the future, I would like the testAI.xml to specify only the data that overrides the defaults. That is, the ogre characters might all have the same size, strength, weapon, etc, but there could be several in the same room, and might start from different locations. Or maybe we want one to have more health than another.
So, I copy the 42 lines of data from one file, and paste it into the other, into the second room (second instance of "roomData"). The "designRoom.html" program could be used to do this instead.
vi /Library/WebServer/Documents/demoMaze13/object_templates.xml /Library/WebServer/Documents/demoMaze13/testAI.xml After this, I can load the game, and see the character. I'm doing this as I am typing this, and now that I see the character actually moving around, I think I'm going to change it. It looks small, even compared to the player's character. The eyes don't show up, its head does not look well defined, the arms don't seem to move as much as I thought they would, and the walking looks jerky. These things can be fixed by updating the graphics file, and a few of the data values.