Tuesday 29th October, Monday 4th November 2019.
Release 1 - Sprint 2. Scrum Master: James Farrell
Overview
This week, we focused on the development of our level map and game environment.
Product
The main products of this week were:
- Implemented Tile-Based Level Layout
- Implemented Movement System
- Implemented Text-File Map Generation
- Loaded Models into Game
Process
Implemented Tile-Based Level Layout
I used a 3D array to store the x,y and z coordinates of each room in our map. This allows me to dynamically load models based on their position within the grid. For example, room 1 will be placed at the position (1, 0, 0), while room 2 will be placed beside it, at the position (2, 0, 0). The algorithm for this was easier to implement than I had originally expected - a pen and a piece of paper helped me to visualise the implementation. I worked out that each room could be placed using their x, y and z index within the 3D array. The position of each room would be multiplied by the width, height and depth of one cell, to dynamically place it in the game. For example, a room at the position (3, 0, 4) would be placed at the position (762, 0, 1016), as each cell is 254 units in length (3 * 254, 0 * 254, 4 * 254). A room adjacent would be placed at the position (1016, 0, 1016), exactly one cell width away from the previous room.
Implemented Movement System
For translational movement, the camera must move from the centre of the starting cell to the centre of the target cell. Therefore, the total translational movement must be equal to the length (or width) of one cell (remember that each cell is a square). For rotational movement, the camera must rotate 90 degrees toward the target heading, based on which direction that the player wants to turn (clockwise, or anti-clockwise). Implementing these algorithms proved to be simple enough. However, the camera would 'snap' into position, instead of translating over time. Christian mentioned that this made him feel disoriented while playing the game. I decided to edit the algorithm to make the camera translate over time. This was quite difficult to get working correctly. I discuss this process further in the issues section below.
Implemented Text-File Map Generation
I implemented an algorithm to dynamically load the map, based on a text file of numerical values. You can imagine this text file as being a top-down view of the map. The values 1 through 16 each map to a specific module. For example, the number 5 maps directly to the 3D model for room number 5.
I needed to design the file to represent 3D space in a 2D format. I decided to split the map up into 'layers', with each layer representing one 'y' component of the grid. This way, I can place 2D maps on-top of one another to create a multi-level 3D space. You can picture this as multiple floors in a building.
Loaded Models into Map
I designed an algorithm to dynamically place each model into the map, based on their position within the grid. The algorithm would take the current grid position (for example (3, 1, 5), and multiply each component (x, y, z) by the width, height or depth of a model to determine its position (relative to the origin). These inter-dependent set of algorithms will allow us to easily expand the game map going forward - the only values that will need to change are the values loaded from the external text file.
Issues
I spent much time trying to fix the camera's movement - I did not expect it to take as long as it did. There were many variables at play, making it difficult to map out the problem on paper. The debugger proved to be quite useful while solving this problem. Eventually, I came across a solution. Instead of setting an absolute value for the player's position, I decided to split it up into increments over time. The game will automatically move the player to their destination once they are within a certain range. This is to prevent floating-point inaccuracy, which may affect the player's position over time.