Difference between revisions of "Basics of developing a simple map with tunnels"
(Created page with "In my RPG game, the cube faces comprise a maze of tunnels, that connect rooms where things happen (finding new party members! buying potions! Attacking monsters!). There a...") |
|||
| Line 11: | Line 11: | ||
Based on initial topology of the cube on application startup (to be explained), I determine for each screen face the map piece I want on it, and the needed rotation (based on adjacent map pieces and the known orientation of that screen) for the map piece. The ON_Render routine is then able to just look at the two values for each screen to determine how to draw the tunnels (to be explained further) | Based on initial topology of the cube on application startup (to be explained), I determine for each screen face the map piece I want on it, and the needed rotation (based on adjacent map pieces and the known orientation of that screen) for the map piece. The ON_Render routine is then able to just look at the two values for each screen to determine how to draw the tunnels (to be explained further) | ||
| − | Since I also need to be able to indicate where on the face the party can exist, I also set a "cell array" of size [9] (indexes 0..8) where the screen is divided into a 3x3 grid and the cell array for a given cell is 1 if the party can be there or 0 if it cannot: | + | Since I also need to be able to indicate where on the face the party can exist, I also set a "cell array" of size [9] (indexes 0...8) where the screen is divided into a 3x3 grid and the cell array for a given cell is 1 if the party can be there or 0 if it cannot: |
0 1 2 | 0 1 2 | ||
Latest revision as of 10:31, 22 August 2023
In my RPG game, the cube faces comprise a maze of tunnels, that connect rooms where things happen (finding new party members! buying potions! Attacking monsters!). There are no doubt a number of approaches on implementing this in Pawn code, but I am using the following method:
- A 2D matrix with the first index being a module # and the second index being a screen # yields the ID # of the "map piece" that is on that screen
- Another 2D matrix with the first index being a module # and the second index being a screen # yields the "rotation count" of that map piece on that screen
- There are a small number of map pieces and each is initially designed as if the top of the screen is at the top of the piece:
- A straight tunnel (that will go top to bottom or left to right on the screen)
- An L shaped tunnel (that will connect left to bottom, left to top, right to bottom, or right to top)
- A cross shaped tunnel (that connects all four sides together)
- A dead end tunnel (that opens at the top, left, bottom, or right, but closes off 2/3 of the way down)
- A stairs tunnel (that opens at the top, left, bottom, or right, but the final third of the tunnel is a green square indicating stairs up or down to another level)
Based on initial topology of the cube on application startup (to be explained), I determine for each screen face the map piece I want on it, and the needed rotation (based on adjacent map pieces and the known orientation of that screen) for the map piece. The ON_Render routine is then able to just look at the two values for each screen to determine how to draw the tunnels (to be explained further)
Since I also need to be able to indicate where on the face the party can exist, I also set a "cell array" of size [9] (indexes 0...8) where the screen is divided into a 3x3 grid and the cell array for a given cell is 1 if the party can be there or 0 if it cannot:
0 1 2 3 4 5 6 7 8
If the map piece is a cross, it would always be the case that indexes 1,3,4,5, and 7 would be 1. For an L piece, it would be one of the following based on the rotation: (1,4,5), (4,5,7), (3,4,7), or (1,3,4).
