James Farrell - GD3 UDP - Journal 2019

Tuesday 10th, Monday 16th December 2019.

Release 2 - Sprint 3. Scrum Master: Christian Rafferty

Overview

This week, we focused on testing and polishing each aspect of our game. My main role involved testing our game with a select group of users.

Product

The main products of this week were:

• Conduct User Tests
• Implement User Feedback
• Create Powerpoint
• Practice Presentation

Process

Conduct User Tests

Caoilinn and I conducted user tests on Wednesday, Thursday and Friday. We monitored our user's behaviour, paying close attention to the things that we expected them to do, and the things that we did not expect them to do. We asked each tester to adopt a user persona; we also advised them to also speak their thoughts out loud - this would allow us to further understand the player experience. I made note of any reactions that our testers had to various game elements within our game (such as enemies and items), and I wrote down any questions that they asked. We ensured to provide minimal input, as we did not want to influence decisions. Once each test was complete, Caoilinn asked each tester a number of questions to further encourage feedback from our users.

Implement User Feedback

We met as a group on Friday to discuss our user feedback. We looked at the different areas that we could improve throughout our game. Many of our 'novice' users felt lost and disoriented while playing our game, as many of the walls and rooms look the same. I decided to add some decorator objects throughout the scene, to add variation throughout the game. I built upon the bit-shifted array, to place object that Nathan sourced into our scene.

Create Powerpoint

I created a Powerpoint presentation for use within our final demo. I created a simple outline in notepad, to get a better idea of how to structure the slides. I decided on a simple format - introduction, overview of game, user personas, game demo, universal design, user feedback, reflection and going forward. I then applied similar styles to each slide to develop a theme throughout the Powerpoint. 

Practice Presentation

We met as a group on Monday to practice our presentation. We outlined our roles and talked about our plan for the demo. I created a simple script for us to follow while we played.

Issues

I ran into a number of problems while submitting our project to Moodle. I originally uploaded the project before I created a screencast. However, while I was recording the screencast, I realised that there were bugs within the game. I removed the upload, fixed the errors, and uploaded the project again. I decided to check the project one last time before completing the submission. Much to my dismay, the 'ShrineToTheDarkGod' project folder was empty - I had noticed an error while zipping the project, but I thought nothing of it. I fixed this problem, and uploaded the project - however, it was uploaded late. 

Tuesday 3rd, Monday 9th December 2019.

Release 2 - Sprint 2. Scrum Master: James Farrell

Overview 

This week, we focused on completing the sound design aspect of our game. My main role involved the implementation of a 3D sound engine. 

Product

The main products of this week were:

• Implement Controller Mapping
• Update Level Layout
• Design Billboard Effects
• Configure 3D Sound
• Implement 3D Sound Effects

Process

Implement Controller Mapping

I implemented XNA's GamePad class to add controller mapping support. This change will allow players to interact with our game using a gamepad. I connected each input (controller buttons) to relevant outputs (in-game actions). I also implemented a system that automatically detects a gamepad, once it is connected. This means that the player can easily switch between keyboard and controller. I hooked up an Xbox controller to make sure that everything works

Update Level Layout

I updated our in-game level using the additional assets that I created in Sprint 10. I imported each file into XNA and re-named them where necessary. I numbered each room to keep track of its position within the grid. In total, there were 36 rooms. I realized that I would need to allocate more space within my bit-shifted 3D array (currently, there are only 5 bits allocated to rooms, providing me with a maximum of 32 different types of rooms - 2^5). I edited the algorithm to allocate 6 'room' bits instead. This consequently updated the starting bit position of all remaining grid elements. I then edited the 'map data' text file, to place each room into the map. I tested everything out once I was done, to make sure that everything worked.

Design Billboard Effects

I designed a set of billboard effects for use within our game. These effects will appear on-screen when the player performs some action. For example, a 'slash' billboard will appear on-screen when the user attacks an enemy - this will provide visual feedback for the player when in combat. I used pen and paper to outline a set of effects, before re-creating my designs using Photoshop.

Configure 3D Sound

Previously, we used 2D sound effects throughout the game. This felt rather flat as our sound seemed to have no dimension. We decided to update our game to support 3D sound effects. I began by placing audio emitters at each audio source within our game. I then updated the position of the audio listener, each time that the player moved. The audio listener represents the in-game player position. These two systems work in tandem, to make audio appear as if it coming from a set source within the game. For example, if the player is standing adjacent to an item, they will hear the 'item_twinkle' sound coming towards them. This is relative to the direction that the player is currently facing (if the item is to their left, they will hear the sound coming from their left earphone/speaker). This adds a layer of realism and depth to our game.

Implement 3D Sound Effects

I used our updated engine to place 3D sound effects into our game. I replaced all 2D diegetic sounds (such as footsteps and combat actions), with 3D sound effects. This was a relatively quick process, as it only involved placing an emitter at each source. I also edited existing sound events, to publish 3D sound events instead of 2D sound events. I ran into a problem while testing my code - I realised that the audio would only play from one speaker. After some time, I discovered a 'forward vector' member in the audio listener class. I decided to assign the players 'look' vector to the 'forward' vector, assuming that they were meant to mirror each other. Thankfully, this fixed the problem.

Issues

I forgot to update our Scrum board on Tuesday. Although work had been completed, it had not been recorded. Annoyingly, this created a flat line in our burndown and burnup charts.

I felt quite under pressure this week, as multiple assignments were due at the same time. I often found myself switching between projects, as I tried to progress evenly in both. This was made worse towards the end of the week, as I realised that our UDP journals were to be submitted on Monday. Overall, this resulted in a busy weekend, but I was thankfully able to submit everything on time. 

Tuesday 26th November, Monday 2nd December 2019.

Release 2 - Sprint 1. Scrum Master: Caoilinn Hughes

Overview

This week, we focused on adding various elements to our game. This included updating the layout of the level, designing various assets for our final game, and updating the in-game UI, 

Product

The main products of this week were:

• Redesign Level Layout
• Create Additional Level Assets
• Record Foley Sounds
• Update Game UI 

Process

Redesign Level Layout

Christian and I worked together to re-design the level layout. We felt that our game was too linear. We decided to expand our map, by adding enemies and rooms. We sent some general ideas to one another through Facebook messenger. We agreed to add an additional room to our game. This will allow the player to interact with more entities within the game. 

Create Additional Level Assets

Additional assets were required to satisfy our redesign. I studied the layout of our map and began to outline the various elements that we would need. I re-used assets where possible to cut down on development time. My previous experience creating these models helped me to quickly complete this task. I knew what process to follow, and what to avoid. I exported my models as .FBX files, and uploaded them to Google Drive. From there, Nathan would be able to download and interact with each file. Nathan would need to re-apply textures to the updated models.

Record Foley Sounds

I recorded various sound effects using Foley methods. Nathan created an outline of the final sounds required for our game. I used this list as a reference point while recording. I recorded the sound of various items around my house. For example, I recorded fireplace utensils hitting off one-another, to simulate the sounds of swords clashing. I also recorded vocal noises (such as snarls and throat singing), to represent monster growls and cultist chants. I then reviewed my recordings and named each file appropriately, before uploading my finished files to Google Drive. From there, Nathan can download and interact with each file. Nathan would need to create layered sound effects from the recordings that I gave him.

Update Game UI

I updated the game log to provide additional information to the player. For example, the game will notify the user about an item that they have picked up. A message - 'Sword added to inventory' - will appear once the user picks up a sword. I also changed the font size, font family, and font colour, to make it easier to read for those with dyslexia. I also implemented a UI inventory system that displays inventory items on-screen. For example, a sword will appear in the in-game inventory once the player has picked it up. This provides visual feedback for the player. Additionally, items are removed from the inventory, once they have been used (for example, when a key is used to open a gate). Finally, I added player health & XP bars to the user interface. These bars represent the player's current health and experience points. The health and XP bars are scaled based on the player interaction in battle. For example, the player will gain XP as they deal damage but will lose health as they take damage.

Issues

There were no issues of note this week.

Tuesday 19th, Monday 25th November 2019.

Release 1 - Sprint 5. Scrum Master: Caoilinn Hughes

Overview

This week, we focused on polishing our game ahead of the presentation on Tuesday. We conducted user tests throughout the week to gather feedback about our game.  

Product

The main products of this week were:

• Redefined User Personas
• Selected Test Users
• Conducted User Tests
• Reviewed Tester Feedback
• Implemented Test Feedback
• Refactored Codebase
• Create Presentation

Process

Redefined User Personas

I felt that our user personas needed revision. I discussed the possibility of re-designing our user personas with the group. I wanted to cover a range of experience - young to old, novice to expert. This resulted in the creation of three user personas - the grandfather (has experience playing role-playing games, has experience using a keyboard and mouse, but has no experience using a gamepad), the father (has some experience playing role-playing games, has some experience using a keyboard and mouse, and has some experience using a gamepad), and the daughter (has no experience playing role-playing games, has no experience using a keyboard and mouse, but is experienced using a gamepad). Through these personas, we are covering a wide range of preferences and ability, which is fitting with our design principle of flexibility in use.

Selected Test Users

We invited various students from around the college, to come and test our game. We selected testers based on our user personas. We were looking for experienced gamers and novice gamers. We were testing against three main metrics - experience playing games, experience playing role-playing games, and experience playing with a mouse and keyboard. Through these metrics, we can determine how intuitive our game is, how simple the mechanics are, and how perceptible the information provided is. 

Conducted User Tests

We conducted user tests on Thursday and Friday. We encouraged our testers to adopt a user persona before the test began. We used over-the-shoulder techniques to gather feedback from our players, based on their interaction with the game. We paid particular attention to our player's behaviour - both expected behaviour and unexpected behaviour. We also recorded any questions that they asked while playing our game. Once the test was complete, we asked the player a number of pre-determined questions. We recorded their answers via Google Forms.  

Reviewed Tester Feedback

We reviewed our test data to improve the quality of our game. A common comment among testers was the lack of in-game visibility. Although this was a design choice (we implemented fog to add atmosphere), we decided that it was better to listen to our users. There were also comments about combat-balancing - many users felt that the game was too easy to play. Users also felt that the camera's control scheme was difficult to pick up. However, they further described it as quick to learn, and easy to master. 

Implemented Test Feedback

I edited the fog effect to improve in-game visibility. The player can now see further in every direction. I was careful to not extend this distance too far, however, as I wanted to retain the atmospheric effect. 

Refactored Codebase

I was unhappy with the structure of our codebase - I felt that too many systems were inter-dependant, instead of being self-contained. This was a recipe for disaster going forward. I spent considerable time on Sunday refactoring the codebase. I restructured major elements, and completely re-worked the collision system. I implemented a grid manager to keep track of elements within our grid - this includes the player character, enemy objects, and collectable items. Through this, I can considerably reduce the number of collision checks, by detecting collision based on the position of an object, rather than its collision skin. This also has the benefit of improving in-game performance, by reducing the usage JigLib. I pulled the collision detection system from the CollidableFirstPersonCameraController class, into the CharacterObject class, so that the PlayerObject and EnemyObject classes have access to it. This allows me to add collision behaviour to enemy objects, such as preventing them from walking through walls.

Create Presentation

I created a simple background presentation to assist in our demonstration on Tuesday. I adapted our previous presentation to save time. We decided to cover to main points in our presentation - our universal design principle, and our plans going forward. I also created a simple script for us to follow throughout the demonstration.

Issues

My updates to the codebase on Sunday caused many issues while merging our work on Monday. Luckily, the overall impact was quite small, and we were able to effectively merge all branches.  

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.

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.

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. 

Tuesday 22nd, Monday 28th October 2019.

Release 1 - Sprint 1. Scrum Master: Caoilinn Hughes

Overview

This week, we focused on the presentation and demonstration of our Paper Prototype.

Product

The main products of this week were:

• Tested Prototype
  
• Practised Presentation
• Presented Paper Prototype
• Designed Environment Models
• Developed Environment Models

Process

Tested Prototype

We continued to test our prototype ahead of the demonstration on Tuesday. This allowed us to make simple changes to refine our demonstration.

Practised Presentation

We practised our presentation as a group on Tuesday. We began by reciting our lines while looking at the screen, this helped us to remember our cues. Eventually, we were confident enough to practice while looking away from the screen. We timed each practice session to get a feel for how long our presentation was going to be. 

Presented Paper Prototype

We presented our prototype on Tuesday. The demonstration went quite well, but the presentation lacked in some areas. I had to stop at one point to review my lines. The demonstration, however, went quite well. Our usage of sound effects was a great hit.

Designed Environment Models

I was tasked with designing the environment models. I already had an idea of how I wanted this to look. I used a pen and paper to draw out my designs. The modular nature of our game meant that I did not have to draw many designs, as each design could be re-used multiple times. I designed three variations of walls, three variations of floors, and three variations of ceilings. I also designed doorways and portcullis gates. 

Developed Environment Models

I used 3D Studio Max to develop each of my designs. Christian sent me a placeholder character model as a reference point for my dimensions. I used a 3D camera object to give me an idea of how the environment would look through the eyes of our player. I set the camera field of view to 90, which will reflect the in-game field of view. I created three wall models, three ground models, three ceiling models, one doorway model and one gate model. I also created three variations of columns that would act as a link between each module. I used these variations of these models to create each module. I then used these modules to create the map.

Issues

We began our fourth sprint before beginning release 1. Thankfully, we were notified about this by Gerry. We worked quickly to fix this problem.

The completion date for release 1 was incorrectly set. The date was set to December 10th, although it should have been set to November 26th. Thankfully, Gerry notified us about this. We worked quickly to fix the problem.

Tuesday 15th, Monday 21st October 2019.

Paper Prototype - Sprint 3. Scrum Master: Nathan Hill

Overview

This week, we focused on finalizing our paper prototype. We developed and practised a presentation ahead of our demonstration on Tuesday. We also began to test our prototype among the students in our class.

Product

The main products this week were:

• Outlined Triggers
• Painted Prototype
• Created Presentation
• Practised Presentation
• Tested Prototype
• Uploaded File
  

Process

Outlined Triggers

I used coloured pieces of card to outline trigger volumes in our game. Different colours were used to outline different trigger volumes. For example, red pieces of card would be used to indicate 'battle' trigger volumes. If the player steps on a red piece of card, they would enter a battle with an enemy. Blue would represent the start-and-end-points of the level, green would represent collectable items. Yellow represents sound volumes, and orange would be used to identify interactive objects. Caoilinn suggested placing small squares of the card into each module to represent a trigger. He also suggested removing the centre from the card to expose the texture below.

Christian bought a book of coloured-card in the college shop. I used this to create triggers. I measured and outlined each piece of card before cutting out the shapes. I then placed each trigger into the grid.

Painted Prototype

Christian and I continued painting the paper prototype throughout the week. We blacked out the interior of the box and coated the outside with a layer of brown paint. Christian painted a yellow design along the brim to make the box represent a treasure chest. We outlined the yellow paint with a black permanent marker to complete the look.

Created Presentation

I was tasked with creating a presentation ahead of our demonstration on Tuesday. I wanted to create a themed presentation that would represent the branding of our game. I decided to use Google Slides to create the presentation - this would allow me to easily share the file among the group. I searched online for a template to use as a starting point. I then edited these slides to reflect our style. I outlined a 'plan' for our demonstration to get an idea of how the presentation should be laid out. I communicated with the group throughout this process to receive feedback and suggestions on the slides.

Practised Presentation

We met as a group to practice our presentation. We used a timer to keep track of our speed. We aimed to spend around 4 minutes on the presentation, leaving 6 minutes for the demonstration.

Tested Prototype

We asked volunteers to test our prototype on Monday. The feedback that we received encouraged us to change our combat mechanics. Originally, the current health of each entity was recorded manually (with Caoilinn keeping track as the battle progressed). This proved to be ineffective, as gameplay would essentially halt as Caoilinn performed calculations. We opted to display the player health via a HUD instead. Additionally, we discovered that each battle took too much time to complete. We decided to drastically reduce the health of each entity, to speed the overall gameplay up.

Uploaded File

I was tasked with organizing and uploading the CA submission file. I contacted my teammates on Sunday to collect their journal links. I placed each link into a text file and added them to our folder. I checked the submission guidelines, and carefully adhered to naming conventions. I ensured that each required element was present in the folder before submission.

Issues

I forgot to factor wall-width into my measurements while outlining triggers. As a result of this, the triggers were too large to fit in our prototype. I decided to start again with more accurate measurements.

Tuesday 8th, Monday 14th October 2019.

Paper Prototype - Sprint 2. Scrum Master: Christian Rafferty

Overview

This week, we focused on the design and continued development of our paper prototype. This included outlining sounds, and finalising Moscow.

Product

The main products of this week were:

• Paper Prototype
• Sourced Sound Effects
  
• Edited Sound Effects
• Moscow Outline

Process

Paper Prototype

We continued the development of our paper prototype throughout the week. We worked as a group to finish the development of our modules. Nathan sourced a set of textures for us to print. We then outlined each set of textures using a ruler and pencil. Once complete, we could begin cutting each texture out. We applied our textures to the modules using Pritt-stick glue.

I wasn't happy with how our prototype looked - there was little cohesion to it. I decided that we should add paint. I asked Fiachra if I could use paint from the Art Studio - he agreed. I decided to use brown and black coloured paint. The inside of the box would be painted black, while the outside of the box would be painted brown. This would help to make the box look more like a fantasy chest - something that Christian had suggested.

Sourced Sound Effects

We decided to add sounds to our paper prototype. This will allow us to communicate the emotion and atmosphere of our game. Additionally, it would allow us to demonstrate one of our key design features - descriptive sound design.

I was tasked with sourcing a list of sounds. First, I needed to identify each sound that would be in our game. I decided to split this into two categories - Diegetic and Non-Diegetic.

I decided to place myself in the main character shoes. I asked myself questions like 'What sounds can the character hear?' and 'When can they hear them?'. The first obvious sound that came to my mind was music. Music will play throughout the game. I also considered interaction sounds, such as footsteps, combat, user interface and enemies.

The full list of Diegetic and Non-Diegetic sounds can be seen below:

Diegetic

• Fist Attack, Weapon Attack
• Miss Attack, Block Attack, Dodge Attack
• Footsteps, Turn Around, Bump Into Wall
• Drink Potion, Item Twinkle, Collect Item
• Door Locked, Door Unlocked, Use Key
• Player Take Damage, Player Death
• Enemy Take Damage, Enemy Death
• Enemy Growl
• Cultist Chants

Non-Diegetic

• Atmospheric & General Music
• Victory Music
• Death Music
• Battle Music
• UI Interactions
• Low Health

Once my list of sounds was complete, I was able to begin my search. I sourced most of my sounds online. I used Audacity to record various sounds and songs that I found on YouTube. These sounds will be placeholders for the time being. I used a Zoom recorder to tape myself and Caoilinn making various sounds. This includes the 'Player Take Damage' and 'Enemy Death' sounds.

Edited Sound Effects

I sorted through my collection of sounds to determine which clips sounded best. I associated each sound with an item on my list. For some items, I decided to select two or three sounds which can be used interchangeably. This will be used to break-up repetitive sounds, such as an attack.

I used Audacity to edit my clips. This allowed me to layer and trim each clip to suit my needs. For example, I layered multiple similar sounds to create the 'death' sound effect.

Once complete, I downloaded the tracks onto my phone. From there, I used a soundboard application to store each sound. This application will allow me to trigger each sound in real-time, as events happen throughout the presentation of our game.

Moscow Outline

I worked with my team to outline our project features. We then organized them using the Moscow system - Must have, Should have, Could have, and Would like to have.

Must-Have

• Movement System
• Turn-based System
• Health System
• Chance-base Combat System
• Tile-based Level System
• Collectible/Item Pickup System
• Interactive Objects
• Enemy Logic/AI
• Win/Lost State

Should Have

• Checkpoints/Save Points
• Customizable Keybindings
• Inventory System
• Descriptive Audio
• User-friendly UI

Could Have

• Auto-Save
• Party System
• Dungeon Designer
• Text-To-Speech

Would like to Have

• Multiplayer
• Random Map Generation

Issues

We reviewed the burndown of our previous sprint on Tuesday. The chart revealed that we agreed to dedicate 50 hours of work to the project during sprint 1. However, only 20 hours of work were completed. We realised that our original approach to allocating hours was inappropriate for the tasks that we were doing. We amended our approach for the current sprint.

Tuesday 1st, Monday 7th October 2019.

Paper Prototype - Sprint 1. Scrum Master: James Farrell

Overview

This week, we focused on finalising our idea, fleshing out our game, and beginning the development of our paper prototype.

Product

The main products of this week were:

• Scrumwise Setup
• Paper Prototype
• User Personas
• Technology Outline

Process

Scrumwise Setup

On Tuesday, Gerry briefed us on Scrumwise - he explained how to set up our first sprint. We decided that I should be Scrum Master for week 1. We also decided that we would rotate this position each week. We outlined our total hours, added backlog items to the project, and created our first sprint. We aimed to divide the workload evenly among each member of the group. We took into consideration external pressures (such as work and personal health) into consideration when assigning tasks.

User Personas

We decided to split our demographic into two major groups - primary and secondary targets. Our primary target is the older gamer, who grew up playing these games as a kid. Primarily male, aged between 28 and 40. Our secondary target is younger gamers, who are looking for an entry-point into dungeon-crawler games. This demographic includes males and females aged between 12 and 20. Of course, there are outliers to each group, such as females (group 1) and players that are currently younger or older than our selected demographic. 

We decided that each person should develop two user personas, based on our primary and secondary targets. This would allow us to capture a broad range of users. These personas can then be condensed into two or three primary/secondary personas.

I developed a father/daughter pair of personas - the father grew up playing these games, but now has limited time to game. He looks fondly upon his old favourites, such as 'Rouge' and 'Sword of Fargoal'. His daughter, on the other hand, never played any of these games, but is looking for a way to bond with her dad. She hasn't played a dungeon-crawler game before but loves to spend time on her Nintendo DS.

Paper Prototype

Once we developed a strong understanding of our main idea, we could begin to work on our paper prototype. On Tuesday, we spent some time designing a map of our game. I explained to the group how our modules would work. Each module would be a 1x1 square on the grid, that would come together to build hallways and rooms. Each module would have a floor, a ceiling and zero to three walls.

We outlined a map of our game on a whiteboard. This would be our main point of reference while developing the paper prototype. We split our map into modules, covering 16 tiles on a grid. This means that we would essentially need to create 16 'rooms'. We begin to discuss the placement of weapons, enemies, and collectables on the map. We also added a locked door that prevents the player from progressing until they complete some objective.

We decided to build our paper prototype from cardboard. To do this, we would need to source some equipment, such as cardboard, newspaper, cutting utensils, and general stationery. I brought cardboard in on Wednesday to begin the development of our prototype. I also brought in sellotape, a box cutter and some general stationery (pencils, rulers, erasers).

We began the development of our paper prototype on Wednesday. I worked with Caoilinn to build the modules for our grid. We drew our map on a white-board and used it as a reference point. We labelled each room to help us keep track of our progress. This also allowed us to keep track of their position in the grid.

Technology Outline

Christian and I worked together to outline the main technologies that we plan to use for this project:

• 3D Studio Max - Environment Assets (Modules)
• Blender - Character Assets & Animation
• XNA - Game Engine
• Audacity - Audio Assets
• Photoshop - Textures & Image Assets
• Scrumwise - Project Management
• Daily Meetings for communication at college
• Discord Voice-Chat for communication outside of college
• Facebook Messenger for general communication

Issues

It turned out that we each shared a different vision of what our game was going to be. Thankfully, we realised this early-on and were able to fix the problem.

Christian and I were unsure of what 3D software we were going to use. Christian prefers to use Blender, while I am more comfortable with 3D Studio Max. Ultimately, we decided to work separately, agreeing to share our assets by exporting them in standard .fbx format.

Tuesday 24th, Monday 30th September 2019.

Paper Prototype - Design Stage. 

Overview

This week, we focused on developing an idea for our game. Our initial pitch was to take place on Tuesday. We discussed ideas throughout the week and developed a shared understanding of the project. We also focused on our group dynamic, to ensure that each member was comfortable within the team. 

Product

The main products of this week were:

• Team Formation & Project Plan
• Project Brainstorming
• Universal Design Research
• Project Pitch
• Finalizing Idea

Process

Team Formation & Project Plan

I met with my team on Monday to discuss our project. Caoilinn and I had some catching up to do as we were abroad during week one. Christian and Nathan explained an idea that they had for the project - a 3D turn-based dungeon RPG.

Once everyone was on the same page, I decided that we should clear the air by discussing our group dynamic. We have worked together in the past, so we are aware of the many issues that may come up. I suggested that we provide critical (but constructive) feedback to one another, based on our previous experience. As a team, we agreed to be transparent with one another - any positive or negative feelings should be shared, and all criticism should be constructive. We made an agreement as a team to place our project first.

We established communications means through Facebook Messenger. We also set up a Google Drive for file-sharing. 

Team members and roles:

• James Farrell - Project Manager, Environment Modelling
• Christian Rafferty - Character Modelling & Animation, Programming
• Caoilinn Hughes - Programming, Sound Design
• Nathan Hill - Narrative & Concept Design, Texturing

Project Brainstorming

Idea 1

We gathered on Monday to build upon the idea that Christian and Nathan proposed - a 3D retro-style turn-based dungeon-crawling RPG. 

We looked at 'Legend of Grimrock' for inspiration.

The player would progress through a dungeon, fighting monsters, collecting items and solving puzzles. The map would be based on a grid. The player can move one grid space per turn. Each grid space would be built from modular 3D assets (imagine a 1x1 room, or a 1x1 hallway). This system of modular assets would allow us to easily expand or contract our level. Players can collect items that are scattered throughout the map. Items may include potions, keys, weapons or health. Players can improve their character skill rating by slaying monsters and completing levels.

Idea 2

Christian proposed a multi-player fighting game, where two players would control a character on-screen. It would be '2.5D' based (3D assets loaded into a 2D space). This is similar to how modern games like 'Mortal Kombat 11' are made.

We talked about simplifying the control scheme. Each player would only need access to four buttons. Using this technique, we could effectively allow two players to play from the same keyboard. We imagined that 'Player 1' would use the AWDF keys, and that 'Player 2' would use the HJIL keys. The controls would be as follows:

Player 1

• A - Retreat Slowly while Blocking (Move Left)
• W - Jump
• D - Advance (Move Right)
• F - Attack

Player 2

• H - Attack
• J - Advance (Move Left)
• I - Jump
• L - Retreat Slowly while Blocking (Move Right)

A player can move in two-dimensions (up and down, left and right). Player 1 begins on the left-hand side of the screen, player 2 begins on the right.

As the match goes on, the playable area begins to shrink. Players outside of the playable area will begin to slowly take damage. This mechanic would work similarly to the storm in 'Fornite Battle Royale', and 'PLAYERUNKNOWN'S BATTLEGROUNDS'. The goal of this mechanic is to encourage both players to advance on one another.

Players are at risk of taking damage while blocking an attack. This is because the 'block' button is tied to the 'retreat' button (remember, a player will take damage if they leave the playable area). This adds to the overall tension, as it encourages players to be more aggressive.

Universal Design Research

We designed our dungeon crawler with mature gamers in mind. We want to appeal to their nostalgia, by building games that are similar to those that they would have played growing up. Additionally, our turn-based mechanic allows players to walk away from our game, without worrying about the game advancing. This suits busy players, who may not have much time to interact with our game. 

We designed the controls of our fighting game to accommodate a range of users. Our limited control scheme allows users to easily re-map the layout. This is inviting for disabled users, who may wish to use an adaptive controller. Our limited use of control also means that it is not difficult to play our game. This is inviting for children, who typically play by 'mashing' buttons. Alternatively, experienced users may utilise simple combos that we build into our game. This allows us to capture a wide range of users, regardless of their experience.

Project Pitch

I created a Powerpoint on Tuesday to outline our ideas. I asked Christian and Nathan to take charge of the presentation, as it was their ideas that we were pitching. We set aside some time on Tuesday to practice our presentation.

Final Idea

We reviewed the feedback that we received from Gerry, Enda and Niall. This helped us to finalise our idea. Niall recommended that we merge our two ideas - we should take the mechanics from game 2, and place them into game 1. We talked about incorporating a multiplayer aspect into our RPG game. We also talked about adding a shrinkable playable area, to encourage players to advance on one another. If these mechanics were successfully implemented, we could create a really exciting game.

However, Christian, Caoilinn, and Nathan felt that it was more appropriate to focus on the singleplayer aspect of our game. They argued (given our time restraints) that it made more sense to build a singleplayer experience first. They also suggest adding multiplayer later, if enough time was available towards the end. I ultimately agreed, as it makes more sense to focus on the singleplayer experience first. However, we have considered putting multiplayer into the 'Would like to have' section of our Moscow outline.

Issues

Caoilinn and I were absent during week one. As such, we needed to spend some time as a group to catch up on the work that we lost.

Time was against us - a presentation was due to take place on Tuesday. We needed to discuss our ideas and plan a presentation in a limited amount of time.