Progress:

This is my first week back in college after the summer break. In our team project class we put together our game team of 5. The team consists of me(Jason Lynch), Dylan Reilly, Oisin Murphy, Eoghan Maguire, and Kealan Murphy. We then discussed the roles that we would be filling in our team. After that we then began brainstorming and came up with an idea each to present to each other.

Things covered this week:

1. Team formed
2. Team roles assigned 
3. Game ideas pitched

Team & Roles:

• Jason Lynch (Lead Programmer & A.I Designer)
• Dylan Reilly (Scrum Master, 3D Modeling, and Level Design)
• Oisin Murphy (Art & Concept, Team Lead, QA Tester)
• Eoghan Maguire (Sound Design, Sound Production, and QA Tester)
• Kealan Murphy (3D Modeling, Character Modeling, and Animation)

Game Ideas:

Paper Chase Game:

This game involved the player traversing a city area collecting important documents the player dropped on the way to work.

Grandmas Garden:

This game involves the player having to manage and maintain a garden by watering plants, interacting with villagers, weeding, etc.

Astral Projection Game:

This idea behind this game is that the player is sneaking through a carnival trying to get to a fortune teller. The player is able to switch between reality and an astral realm in order to overcome obstacles.

Gaeilge Wizard:

In this game the player is a wizard who battles other wizards by casting spells in the Irish language.

Kingdom Game:

This game is a 2D game where the player has to manage relationships between kingdoms in order to keep peace.

The Thinking City:

In this game the player discovers a city in an underground cave and must uncover the mystery of what happened to the people and escape before they meet the same fate.

Problems Encountered:

We had a major problem this week when we found out that one of our team member Kealan will not be part of our 4th year class anymore. This came as a surprise and really messed up our assigned roles as his role as modeler, character modeler, and animator is a massive part of game development.

Problem Solution:

To fix this problem we had to divide Kealans work up and assign it to the remaining members of our team. In doing this I was given the task of Modular 3D level modelling, Oisin got the task of character modelling and animation, and Dylan got the task of 3D Asset Modelling. We are hoping that between us we can the workload.

Progress:

Over the weekend each member of our team was tasked with expanding on the ideas that we pitched to each other and come back with a clearer picture of the game and how it will play. I also set up a GitHub repository for the project and invited the team.

Things covered this week:

1. GitHub repository setup 
2. Flesh out game ideas 

GitHub Repository Setup:

 During this week I set up the GitHub repository that we will be using for our project in the future. I also got the team set up on "Source Tree" which will be the GUI we will be using to interact with the online repository. Here is a link to the repository for the project >> Link to project repository.

Flesh Out Game Ideas:

As a team we met up during this week to present our ideas and how we expanded on them covering topics such as story, mechanics, art style, objectives etc. Below are the fleshed out game ideas laid out in bullet points. You can see some of the brainstorming in the files attached.

#1 Paper Trail Game:

• Third Person Game 
• Puzzle Based Gameplay
• Tone: Fun, Silly, and light hearted
• Pick-ups: Umbrella (Player can glide), Sprint (Player can run but tires out), Jump/Wall run (Maneuverability)
• Map: Small city divided into districts 
• Intractable NPC's
• Sound: Over the top, exaggerated
• Goal: Collect documents scattered around town
• Win Condition: Collect quota of documents in time and return to your office
• Lose Condition: Run out of time before documents are collected

#2 Virus Game:

• First Person game
• O.S (Operating System) integrity as a health bar
• Viruses have personalities: Ad Ware, Trojan, Distortion
• Secret locations in form of task manager
• Several characters to play as each with different traits
• Goal: Hunt down viruses infecting the PC.
• Win Condition: All viruses are destroyed before O.S integrity reaches 0
• Lose Condition: O.S integrity reaches 0.

#3 The Thinking City:

• First Person Horror Game
• Stealth Based Game (Player avoids enemies)
• Tone: Dark, Horror
• Setting: City contained in a massive cave system
• Enemies: Automatons that once helped run the city
• NPC's: Districts Controlled by A.I's (T.R.I.S.H, Entertainment A.I, Industrial A.I, S.H.A.N.E, Living Area A.I)
• Sounds: Echo, Areas should feel creepy and empty of life
• Enemy A.I: Robots should have states, Patrol, Idle, Chase, Investigate, etc
• Goal: Escape the city
• Win Condition: Make your way through the city in an attempt to escape
• Lose Condition: Player is killed by the robots

After talking through these ideas and expanding on them we were all most excited about "The Thinking City" so we presented the idea to the lecturers along with the others as backup ideas. The lecturers seemed to like the idea of "The Thinking City" as much as we do so we agreed to meet again early next week in order to put together a more concrete story and mechanics for the game as well as scope it appropriately for the time frame we have to work with.

Problems Encountered:

The only real problem we encountered this week is the concern the lecturers had about the scope of the project. As a full game they feel "The Thinking City" is too big to complete in the time frame we have. 

Problem Solution:

We have agreed to meet up at the start of next week and work on scoping down the project to fit into the time frame we have to work with.

Progress:

This week is our first official sprint as a team. Taking on board the feedback from the lecturers last week regarding the scope of the project we made it a prerogative in our sprint to get the scope in order, the mechanics down, and the map flow laid out. Finally after settling on these 3 things we started development on the first draft of the paper prototype for the game. These things we did as a group while individually during this sprint I looked into general A.I that will be used for the enemy robots in the game. 

Things Covered This Sprint:

1. Project Re-Scoped 
2. Mechanics Laid out
3. Level Flow Designed 
4. First Draft Paper Prototype
5. A.I Researched

Project Re-Scoped:

 Using the advice of the lecturers from last week to re-scope the size of the project we met up as a team in one of the study rooms and went through the game in order to pick out a section we referred to as a "Vertical slice". This will be a small section of the game that we will use in order to show off the potential of the full game. We all agreed on using the "Science Labs" as our vertical slice as it was an area of the game that interested us the most. You can see in the files below the layout of the science labs once the project was re-scoped.

Mechanics Laid Out:

After we scoped down the project we focused on what mechanics the game should have. Below is a list of the mechanics in the game 

• EMP gun allowing player to stun robots
• Shield to block enemy fire and bash enemies
• Ability for player to crouch
• Places for player to hide
• Station for player to heal from 
• Hiding spots for player to hide from enemies

Level Flow Design :

From scoping down the game we drew out a basic design of the level layout indicating the areas that are inaccessible, rooms in the map, enemy placement, as well as the placement of the shield and gun. This will help us in designing our paper prototype later in the week. There is a picture of the level flow in the attached files.

First Draft paper Prototype:

Using the 3 topics above we were able to put together a first draft paper prototype out of Lego. The paper prototype focuses on the lab section of the map and helps show room placement, door placement, objectives, enemy locations, as well as shield and gun placement. By using Lego for the paper prototype it will make it easy for use to make modifications in later drafts as the game advances in development. Attached are photos of the construction of the first draft paper prototype.

A.I Research:

During this sprint I took some time to look into the process of developing A.I in Unity. After a couple of hours of looking through various tutorials online I was able to put together a very simple waypoint navigation system that allows "Agents" to move from one location to another on a map using an A* path finding algorithm. I will be building on top of this in later sprints to develop the A.I further. This will make it easier for me when building the game during the pre-production process.

Problems Encountered:

When Presenting the first draft of the game level and mechanics to the lecturers some felt that the EMP weapon and shield took away from the game. They also felt that the game was a bit too linear. However they really liked the story behind the game and expressed interest in seeing more of the story shown in the level.

Problem Solution:

To rectify these issues flagged to us by the lecturers we will be meeting again early next week as a team to address the issues.

Progress:

This and further sprints will be done over 2 weeks. During this sprint we looked into addressing the feedback from lecturers last week. We re-defined the final scope of the project and looked into the game mechanics a second time to adjust them in order to make the game more enjoyable. On top of addressing these issues we progressed the development further by play testing the paper prototype with ourselves and 3rd party people. This sprint my personal tasks were to investigate further into A.I with Unity and to define the behavior of the enemies A.I.

Things Covered This Sprint:

1. Re-define scope
2. Re-define Game Mechanics
3. Play test in house
4. Play test with 3rd party
5. Further A.I research
6. Define Enemy A.I Behavior 

Re-define scope:

Taking on board the concerns of the lecturers we adjusted the scope of the game again. This time the level will only consist of the main lab area where the objective takes place. In this area there will be a few sub labs with different themes e.g, Robotics, Medical, Chemical. There will be 2 robot enemies in the labs patrolling half of the map each. The players objective is to turn on the power to the labs and then lift the lock down and exit the map. During the second objective a 3rd robot known as the "Warden" will be constantly pursuing the player.

Re-define Game Mechanics:

Reflecting on the concerns the lecturers had about the mechanics and in particular the shield and gun we decided to remove them from the game. The reasoning behind this is that without any means of defending yourself the tension ramps up for the player and it puts more emphasis on the stealth mechanic of the game. We also decided to add a mechanic into the game which is the ability to throw objects as distractions to attract robots, and to remove the healing mechanic as from player testing it never seemed to be utilized and took away from the tension of dying. After sitting down and discussing as a group the current mechanics for the game are as follows:

• Jumping
• Crouching/Sneaking
• Throw objects to distract robots
• Hide from robots under tables, in lockers, etc

Play Test (In House):

This week we reserved time to play test our paper prototype in order to judge how the game plays and see if our mechanics worked. We found that removing the gun and shield has made the game a lot more tense as there is no way to defend yourself. We also found that the game does not give you any reason to explore the different labs which we will have to address later in the week. On the plus side we found the second half of the game where the warden is pursuing you is super enjoyable and extremely tense. Throwing distractions also help get the player out of sticky situations. Overall the game mechanics seem to play pretty well but we will need to polish them up a bit further.

Play Test (3rd Party):

After playing the paper prototype ourselves we tested it with members of our class and other game dev classes in order to see how well they picked up the game and if they enjoyed playing it. We found from several tests that people enjoyed the tension of the game having no guns against the enemies but they didn't enjoy that they had to reason to explore the map in full. We took note of that and will look into giving the player more of a reason to look about the map. The testers really liked the second half of the game with the warden pursuing them as a lot of them came really close to getting caught causing extremely tense and enjoyable moments where the player didn't know if they were going to get out alive. The testers however wanted a little more randomness in the game which we will look into.

Further A.I Research:

Delving further into Unity with A.I I managed to put together a waypoint network allowing the enemies to move along a patrol path. I also added a feature to the A.I that allows it to detect when an object has blocked its path (e.g a door) and plot a new path if possible to the waypoint. This will allow our robots to find new ways to reach the player if a door has closed between them and the player.

Define Enemy Behavior:

This week I set up the various states that the A.I can exist in. Below in the different states that the A.I need in order to work in the game:

• Idle State 
• Patrol State 
• Walking State
• Investigating State
• Chasing State
• Attacking State

Problems Encountered:

This sprint we encountered  a few different issues we needed to address. Below is a list of the issues that testing with third parties raised.

• More reason to explore map 
• More randomness

Problem Solution:

To give the player more of a reason to explore the map we have changed the first objective from simply reaching the power room to collecting 3 keys around the map which then allows them to restore power. Further testing during the second week of the sprint found that players enjoyed having a multiple item objective and that it gave them a reason to look around the various rooms.

To address the randomness issue we've altered the doors in the map to randomly open and close to give the appearance of the area being run down and malfunctioning. This gives the potential to have the player stuck in rooms with robots or have their escape cut off by a closing door or even an escape possible by one opening. Testing this in the second week of the sprint the testers really enjoyed the addition but their main concern was that doors weren't guaranteed to open. We will have to look into a solution to this in next weeks sprint.

Progress:

This is the final sprint before the first CA for the team project module. As a team we focused on doing as much user testing as possible before the start of reading week to test out our new "Hacking" mechanic. My tasks for this sprint was to look into animation state machines, humanoid re-targeting, asset preparation, and navigation & path finding. 

Things Covered This Sprint:

1. Further user testing
2. Animation State machines 
3. Humanoid re-targeting
4. Asset Preparation 
5. Navigation and Path-finding
6. Show and tell

Further User Testing:

Before the start of reading week we got as much user testing in as possible to test out our new "Hacking" mechanic which we added to allow the player to force a shut door into opening for the cost of a few seconds. From user testing we found that the addition of this mechanic in conjunction with the random doors gave the players the randomness they were looking for and a modicum of control at the same time. We are now happy with the current mechanics and feel they are polished enough for the time being.

Animation State Machines:

This sprint I looked into Unitys animation state machine. I built up several characters and created states for the characters to switch between depending on the current parameters. The characters in the state machine I built can go from idle, to walking, to turning. They can move between these states when certain parameters are met. I then used the animation state machines layering function to blend an attack animation over the other animations using a mesh avatar. You can see the state machine in the file attached.

Humanoid Re-targeting:

I worked a little on humanoid re-targeting this week. Humanoid re-targeting involves bringing in characters and animations into unity and classing them as humanoid so long as the character and animation have that bone structure. This allows any humanoid animation to be applied to any humanoid character even if that animation didn't originally belong to them saving on animation time. You can find the window layout for classing a character as humanoid in the attached files.

Asset Preparation:

Asset preparation involved sourcing different characters, animations, objects, etc and adjusting them so that they are compatible with unity. This will be important during pre-production so we do not end up encountering problems with importing any of our creations.

Navigation and Path-finding:

I did some more tinkering with A.I and navigation. This time I expanded on the current A.I further and gave them the ability to jump up and down from ledges. I am currently unsure if this will be needed in our game but in the event that it is I now know how to implement it.

Show and Tell:

During this weeks show and tell the lecturers seem to be really happy with our progress. We had a lot of concept art to show and some early A.I and Animation state machines. Our paper prototype was finished with refactoring as well. They seemed to be confident in our ability to pull off the game and are happy with the scope.

Problems Encountered:

We had no major problems this week which is great.

Progress:

During this sprint we had our first proper CA where we had to present our game concept to the panel of lecturers. Once that was out of the way I started development on the pathfinding system for the A.I that will allow them to navigate the map as character models. Simultaneously I looked into and developed proper movement with character models, the two main methods I investigated were root motion, where the animation controls the movement speed, and the Nav Agent System, where Unity handles the movement itself. Finally I began developing the core of the A.Is System which will be used in the final game.

Things Covered This Sprint:

1. Presentation Preparation
2. A.I Robot Pathfinding Navigation
3. A.I Mech-Anim with Navigation 
4. A.I System Core (Part 1)

Presentation Preparation:

The first few days of this sprint was spent assembling and rehearsing our presentation. We met up as a team a few times before the day of the presentation and ran over who was going to cover which section of the slides. I chose to cover the enemy robots behavior since I will be coding said behavior. Once we were happy with our parts in the presentation we did several run throughs of the paper prototype gameplay in order to make sure that we could fit it all into the time available to us. In the end we decided instead of showing a full playthrough we would take snippets of our users experience and simulate it to the panel. The presentation to the lecturers went fairly well in my opinion and we got some really good feedback which we will be taking on board during future development.

A.I Robot Pathfinding Navigation:

While earlier progress on the A.Is Pathfinding system was messy code all crammed into one script, this sprint I worked on developing the code so that it can work inside our A.I state machine in the future as it develops. This is necessary as the state machine needs to be in total control of all different scripts attached to it. I have also changed the Agents (previously cylinders) to actual character models to give a more proper look to the final product. You can see this in more detail in my personal portfolio.

A.I Mech-Anim with Navigation:

To further incorporate a realistic look into the A.Is movement I built an animation state machine where it plays an animation while the Nav Agent is moving from waypoint to waypoint. This can be done in a number of ways, I have explored two of these currently which is allowing the Navigation system to have complete control over the A.I Characters movement speed, and Root Motion animation which assigns a speed to the navigation system based on the motion contained within the animation itself. There is drawbacks to both which I will go into more detail about in my portfolio.

A.I System Core (Part 1):

The various A.I states are going to depend on some common and non-common function and properties. To save on having to build each state with overlapping functionality the core of the state machine will comprise of several scripts that the sates will inherit from allowing them access to things such as colliders that come into the hearing or sight range of the A.I Entity and to process the incoming information in their own respective way. This sprint I built a few of the scripts needed in order for the state machine to function, I will build the rest next sprint.  I explain this in more detail in my portfolio.

Problems Encountered:

A few problems have arisen this week. I tend to be the person who incorporates everyones development progress into Unity and this week there have been several issues while doing that.

This first problem was with Oisins robot models, while on his side there was no visible issues inside the modelling software in Unity the models had sections of them not showing up. I alerted him to this issue which I'm sure he goes into in his journal

The second problem that arose this sprint was with Dylans wall models. It is important for us that we save development time on this project. To do this Dylan has been modelling modular walls in order to make level creation quicker and models easy to reuse. The issue that arose was similar to Oisins where certain parts of the walls were not appearing. There was also an issue with certain parts not aligning properly in Unity which I brought to his attention.

Problem Solution:

 To combat the problems above I alerted Oisin and Dylan to the issues the models were having in Unity. They then looked into the issues I brought to them and fixed them before sending back the fixed models to retest. Some of these took a few iterations to fix 100% but after a few hours of working together and good communication we fixed the issues discovered.

Progress:

This week I implemented the fixes from last week into the game level. I also added the doors to the map and built a quick script to simulate the random opening and closing functionality from the concept stage. On top of that I finished off the core scripts required for the state machine to function. Have that done I was able to start on two of the states that will inherit from this state machine which are the idle and the patrol state. This has been a busy week as I had 4 different C.As due one day after the other this week. It's like they're trying to break us.

Things Covered This Sprint:

1. Build and test game level in Unity
2. A.I System Core (Part 2)
3. A.I Idle State 
4. A.I Patrol State

Build and test game level in Unity:

Using the new, fixed game assets from last week I rebuilt the game level to make sure that there was no issues with alignment or any faces/edges being culled without reason. Thankfully at the moment I can't find any issues with alignment or cutting. I also put in the doors that were modeled by Dylan and built a quick script that simulates the randomness of opening and closing. We will have to experiment with the time interval between the doors switching states to find out what one works best.

A.I System Core (Part 2):

This sprint I finished off the final few scripts needed to make the state machine work. One such script was the sensor script that will allow the A.I to interact with the environment around it such as visual threats, sound, etc. At the moment on their own the scripts do nothing. They will require state scripts to inherit from them for the system to work properly which I will begin shortly. More detail can be found in my portfolio.

A.I Idle State:

I developed the "Idle" state this sprint. This is probably one of the simplest of the states. The "Idle" state will be the default state of any A.I enemy in our game and will have a timer that controls how long it remains in "Idle" as well as conditions that will tell the idle state which state it should hand control over to next depending on requirements met. For example, if if there is no visible threat after the "Idle" timer expires the "Idle" state should hand over control to the "Patrol" state. If on the other hand a visible threat enters the A.Is field of vision before the timer expires then the "Idle" state should hand control over to the "Pursuit" state which I will build later. More detail can be found in my portfolio.

A.I Patrol State:

After I finished the "Idle" state I began development on the "Patrol" state. The "Patrol" state was a little trickier to build than the "Idle" state as it has more things to do than the "Idle" state but builds off the old code I used for navigation. The "Patrol" state holds a network of "Waypoints" that the A.I can traverse. Using the waypoints it also calculates the path required to reach them if possible and also calculates the Quaternion look rotation to get the angle to the target waypoint so it can use a turning animation to align itself with the target waypoint. The patrol state also contains the conditional tenses to allow it to hand over control to other states such as Idle, Patrol, Pursuit, Alerted, etc.

Problems Encountered:

 There were a few problems this week in terms of robot animations that Oisin was developing. When I brought them into Unity and played them in Unitys animation window parts of the robot would disappear. There was also a problem with scaling when the robot and animations were brought into Unity. I have flagged them with Oisin and he is looking into it.

There have also been some problems in the games level with the modular corner pieces overlapping some of the parallel wall panels behind it. I have brought that to Dylans attention and he is currently looking into it.

I have had some issues with building the "Idle" and "Patrol" script. It took me a while of thinking and testing from debugging to get the conditional requirements right for state transition.

Problem Solution:

Oisin is currently looking into what may be causing the the robot mesh to act up during animations and is hoping to have them fixed soon.

Dylan has decided to re-do the corner pieces to fix the overlap problems. I will implement them sometime next sprint when he has finished them.

I finally managed to get the state transition conditions working. After some testing I realized that the order of the conditional rules is important to make sure the state transition is correct. For example, the player should be the top priority on the conditional rules, after that sound, etc.