Week 7 - Engine Optimization

Tuesday 5th, Monday 11th November 2019.

Release 1 - Sprint 3. Scrum Master: James Farrell

 

Overview

This week, I focused on optimising our game engine. My goal is to create an engine that will allow us to easily build-up our game, by linking external files to game assets.

Product

The main products of this week were:

  • Implemented Trigger Volumes
  • Implemented Win Logic
  • Implemented Save System
  • Updated Engine

Process

Implemented Trigger Volume Class

I created a simple Trigger Volume class for firing events when a user enters a cell. For example, a sound effect should begin playing, once a player enters a tile adjacent to a collectable item. The trigger volume class stores information about its position and its dimension. This allows us to check if the player is standing within the trigger volume. 

Implemented Win Logic

I hard-coded a 'win' trigger into the game. This currently has no implementation aside from playing a 'boing' sound effect when the player enters the trigger volume. This can be linked up to a win screen later.

Implemented Save System

I developed a simple function to store and load the players current level to (and from) a text file. Game level data is loaded from a separate text file. The players current level determines which level is loaded from this text file. For example, level 1 is loaded when the player starts a new game. If the player enters a 'win' trigger volume, their level will be updated. This, in turn, will load the next level of the game. 

Updated Engine

I added support to the file-loading algorithms for initialising player spawns, enemy spawns, collectable pickups and trigger volumes. To save memory (and to therefore increase performance), I decided to store all of the data about each cell in one 3D integer array. For example, the element at position [x, y, z] in the 3D array holds all relevant information about that cell. This includes information about what room model should be used, what collectable item model should be used,  and what enemy model should be used. This will also allow us to specify if there is a trigger volume in this cell. I essentially needed to 'stack' the information on-top of one-another in at each position in the grid. To achieve this, I used bitwise operations to manipulate each index, by shifting elements onto the array by a pre-determined 'bit-shift' amount. I can then reverse this operation to access a specific range of values. For example, bits 0 through 5 store data about what type of room is in this cell. This means that I can essentially place up to 32 different types of room (2^5 = 32). This can be expanded, of course, if more room types are necessary.

Issues

I realised on Monday that I would need to update my environment models to accommodate textures. Previously, my room models were split into a set of components. For example, a room may be made up of a floor, three pillars, two walls and a ceiling. This configuration would not allow us to easily map a texture onto each room. I spent some time in 3D Studio Max editing each model to create solid, 'one-piece' rooms. I had anticipated that this might happen, but I did not account for how long it would take.