The FOV "editors" are the text files located in the FOVs folder. There is a file for each of the eight directions the player can look. For example, this is the rightUp.txt:
0000000000000000____________0000000
00000000000_____________________000
000000___________________________00
0000______________________________0
0__________________________________
___________________________________
___________________________________
___________________________________
0__________________________________
00________________________________0
000_______________________________0
0000_____________________________00
00000___________________________000
000000_________________________0000
0000000@______________________00000
00000000_____________________000000
000000000___________________0000000
0000000000_________________00000000
00000000000_______________000000000
0000000000000___________00000000000
000000000000000_______0000000000000
The description of each character:
- The '@' character represents the player, there should be exactly 1 of these characters per FOV file because it acts as the anchor point between the .txt and the map on which the information about the field of view is pasted onto (the function that does this can be found here). (As of version 2.0.3. the position of this character does not get automatically parsed by the engine, so if you want to change it in this file you'll need to hard code that change into the correct function as well. Fixing this issue is a planned goal for version 3.0.0.)
- The '_' characters represent cells that are in the player's field of view.
- The '0' characters represent cells that are not in the player's field of view.
You can freely redraw any part of these .txt files, with the '@', '_' and '0' characters. The engine will parse the information and produce the new fields of view in the game. (When dealing with the '@' character please refer back to the description of it to make sure everything will work properly)
All of these .txt files have a set height (21) and width (35). I wanted to make FOVs that are symmetrical, because it doesn't make sense if for example the player has a bigger field of view when he is looking right than when he is looking up. Since the console window is 24 cells by 80 cells the maximum width of the field of view can only be roughly equal to the height of 24 cells. That comes to about 39 cells in width (mileage may vary depending on the command prompt settings you have hopefully by 3.0.0. this won't be a factor). I also wanted to make a margin around all of the field of views. The reasoning behind this decision was that I think it looks weird if there is a cell that is in the field of view and also on the edge of the screen. Any such cell could mistakenly communicate that the field of view stretches beyond the screen which is (in my opinion) not something we want. As a result of all of this the field of view files shrunk to 21 by 35 (however upon further thinking for an easier time interpreting the editors I plan to expand their dimensions to 24 by 39 for the 3.0.0. version of the engine).
Since the dimensions of the field of view are this small there is plenty of space on the console window for other stuff to be displayed. For the unused half of the console window I plan to add basic functions and/or editors that could produce a menu or an inventory system. If you want to expand the dimensions of the FOV files you'll need to change the value of FOVROWS and FOVCOLS which are defined in the system.h header file, but be prepared, if you change it to anything that is bigger than the dimensions of the newConsole array (which is 24 by 80) you will run into complications. But before you do anything with any of these values or the files please read the part about using the map editors, there is a note referring to possible problems that might surface.
The material "editors" are the .txt files located in the materials folder. One of them (walkable.txt) contains characters that don't block player movement, and the other (solid.txt) contains characters that block light, thus creating shadows. Both of them function exactly the same, so I am only going to discuss the workings of the one concerned with the characters that are blocking light. Characters in the editor should be separated by an enter. When you are updating this file, make sure that the value of SOLIDCOUNT (which variable is located in the system.h file) equals that of the characters in this file, otherwise the function that loads these characters would go over too few or too many of them. Till 3.0.0. I plan to make this process more streamlined so you don't need to hard code changes into the program's files, just rewrite a number in the correct .txt file.
The map "editor" is the text file located in the maps folder. It is a huge 231 by 63 .txt file, as with the other editors if you want to alter its size you should alter the value of WORLDROWS and WORLDROWS in the system.h file as well. You might wonder why it's filled with 'i' characters, thats because I didn't figure out a way to read spaces, so any 'i' you see in any of the editors will be parsed by the engine as a ' ' character. You can write anything into this .txt (except for spaces I guess) and it will be visible in the map of the game. Any character that you write here and also into at least one of the material editors will have the properties associated with said editor.
Note: As of now it is recommended that you leave out 19 cells on the top and bottom and 35 cells at the sides of any map you create. Make sure the player can't pass into any of these left out cells (there is an example of how you can do this in the default world.txt file). The reason for this is that if the player would be in any of these cells, looking in the wrong direction, the engine would make calculations with variables in the newWorld array that simply do not exist, leading to all sorts of problems. If you alter the dimensions of the FOV files this recommended 19 and 35 cells might be too little to avoid any such catastrophe (or they might be too much, which can be a problem if you want to make bigger walkable maps). Hopefully the 3.0.0. update will solve this issue and we can finally use the map editor in its intended way.
I have explained the coordinate system once before, but just to be sure I will reiterate here. The coordinate system only deals with positive coordinates, and it is flipped, meaning that the (0; 0) cell is on the top left, and the (231; 63) cell is at the bottom right of (in this case) the editor (this is because the windows header uses a coordinate system like this, and I use this header for certain tasks that involve the manipulation of the console window). Columns run along the x axis and rows run along the y axis, the conversion between these names is often needed to understand the code of this engine.
Cells and points should NOT be confused! Cell coordinates refer to the coordinate of a character in for example the map editor, or in the newWorld array, and they are often used with col and row variables instead of the x and the y of a normal coordinate system. Points on the other hand refer to actual coordinates. These point coordinates are used in casting the lines from the player to the different obstacles in the environment, to produce shadows.
Coordinate of the upper left point: Coordinate of the upper right point:
(a; b) _____________________________ (a + 1; b)
| |
| |
| |
| |
| Coordinate of the cell: |
| (a; b) |
| |
| |
| |
Coordinate of the bottom left point: |___________________________| Coordinate of the bottom right point:
(a; b + 1) (a + 1; b + 1)
Each cell has four point coordinates associated with it. If the cell's coordinates are (a; b) then the point on the upper left is (a; b) the point on the upper right is (a + 1; b) the point on the bottom left is (a; b + 1) and the point on the bottom right is (a + 1; b + 1), as the figure above shows.
The animation pipeline as of 2.0.3. consists of two functions, the initNewAnimation function and the playAnimation function, and the animation structure. A detailed description of all these elements will be found in the next big chapter of this documentation. To create a .txt file that contains an animation and can be initialized by the engine you'll need to do the following:
-
In the first row of the file you'll need to write the number of frames the animation contains
-
In the second row you'll need to write the number of rows each frame of the animation has
-
In the third row you'll need to write the number of columns each frame of the animation has
-
After these three numbers you must "write" all the frames of the animation with no division characters between the frames (except for enters and spaces)
If you have done all these you now can initialize the animation from this .txt file with the initNewAnimation function. For an example of a parse able animation file check out the animation .txt of the intro animation, this animation for example has 24 rows and 80 columns in each of its 220 frames, and this information can be clearly seen from the file's first three lines.