Tuesday 12th, Monday 18th November 2019.
Release 1 - Sprint 4. Scrum Master: Christian Rafferty
Overview
This week, I mainly focused on adding a collision detection and response system to the game. Much of my work going forward will depend on this system.
Product
The main products this week were:
- Implemented Collision Detection/Response System
- Implemented AI Logic System
- Implemented Collectable Item System
- Implemented Proximity-Based Collision Events
Process
Implemented Collision Detection/Response System
I implemented an algorithm to search for collision around the player. This algorithm works by beaming a ray, from the players' current position to some distance ahead of them. If a collision has taken place, the algorithm will store data about the collision. A function then handles this data, to determine an appropriate response. For example, if the player is currently facing a wall, the algorithm will mark this path as 'blocked'. This will prevent the player from walking through the wall. A ray is sent out in each cardinal direction (north, south, east and west), to detect collision around the player. As each collision is recorded, they are added to a set. By adding each collision to a set, I am ensuring that the algorithm handles each collision only once. The collision set is cleared when the player completes their turn.
Implemented AI Logic System
I developed a simple algorithm that adds movement behaviour to AI objects. For example, enemy characters will turn to face the player, before beginning to move towards them. The algorithm simply turns the enemy in-place, rotating them until they are facing the player. The enemy then moves towards the player. An enemy follows the same rules as a player - they can rotate for free, but they can only move one cell per turn.
Implemented Collectable Item System
I added to the collision detection and response system, to register collisions with collectable items. Various events are published when the user collides with an item - a sound is played to provide feedback, the item is removed from the world, and the item is added to the player inventory.
Implemented Proximity-Based Collision Events
I developed this system further, to detect collisions in cells that are adjacent to the player. For example, the system should detect items, that are in front, behind, to the left, and to the right of the player. A function then handles this detection to determine the appropriate response. For example, a sound event is published, once the player enters a cell that is adjacent to an item. This builds upon the ray-based collision detection/response system that I previously implemented. A calculation is used to determine where the collision took place, based on the distance to the collision. This allows the 'collision detection' algorithm to separate each collision into two categories - collisions that are taking place in this cell, and collisions that are taking place in an adjacent cell. Ultimately, this decides the collision response.
Issues
I found it quite challenging to implement a suitable collision detection and response system. JigLib typically handles collision by checking if one object is overlapping with another. This caused some problems, as our objects are not meant to overlap. This is because the player moves between each cell as if they were on rails. Imagine the scenario where our player wants to move between Cell A and Cell B, but there is a wall in-between. We do not want the player to move through this wall. We also do not want the player to move towards this wall, as by doing so, they will move off the 'rail'. However, this creates a catch twenty-two, as the player must collide with the wall before we can detect a collision. If the player cannot move towards the wall, then they cannot collide with it. If we cannot collide with the wall, then we essentially cannot prevent the player from moving. This would essentially create a situation, where the player would move slightly towards the wall before the collision is detected. This is undesirable, as the player is now no longer in the centre of the cell. This causes a string of problems going forward, as many of the movements calculations are based around the cell centre.
I spent a huge amount of time this week trying to identify a solution to this problem. I often found myself quite frustrated at the lack of JigLib documentation. Additionally, Niall was attending a conference, so I was unable to ask for his assistance. Once Niall returned, we were able to discuss this problem. As a work-around, Niall suggested using a ray-based system, to detect collision around the player. Thankfully, this worked.