The Wisp Trimester 2 (of 2) Progress Reflection Report

‘The Wisp’ has been in development for 26 weeks. Since the last report, time has been spent developing the game and all the appropriate systems that go with the game. This report will be on the 13-week trimester that I have just completed.


Team Communication

Due to being in the final trimester at university, we also had a subject called ‘Work Placement’. For this subject we needed to get an internship at a local company. Due to having different schedules for our internship, our group was unable to have meetings. Because we had different times that we were available, during the first 6 weeks, communications dropped off. This meant that no one was reminding people of the work they had to do and people were not messaging when they had completed work. This meant that our team communication channel was pretty much silent for 6 weeks.

However, after the initial 6 weeks, we learnt that not much work was being done due to a lack of communication. Thus we decided to pick up our act and actually work. We had a meeting and discussed how much work we need to do in the last 6 weeks before presenting and how much effort needed to be put in. We then discussed that everyone needs to check the channel at least once a day and inform the group of what work we had done that day. After doing this, our team communication picked up again and we maintained contact. Thus allowing us to do more work and complete the project on time.

Being out of touch from the team caused us to be unable to track when tasks were complete effectively. This meant that when tasks were being blocked by other tasks, we were unable to start them until we met up face to face and reported the task complete. Our team communication when we were face to face was very good compared to our team communication whilst away from each other. When we were together working on the game we were able to ask questions and complete tasks efficiently. This is one of the reasons we didn’t fall too far behind in our work, even though when we were not together we were not working much.

I would recommend that when working in a group you set up a team communication channel and have everyone do daily check-ins. This will encourage group members to do more work and will also allow the project manager to know whether or not people are doing work. At the start of the project, we also should have rechecked our schedules and set up new meeting times. This would mean that we could set up times for us to have a meeting even if we had to do it late at night through a video call/conference call. Since teams normally work better when they are able to talk face to face.


Time Management

Due to poor time management (and over-scoping), we were unable to put everything we wanted into the game. At the start of the trimester, we had a project plan which showed all the work we had to do each week. However, once we started the trimester, since team communication was terrible, the planned work that was supposed to be completed was not done on time. This caused blockers and made tasks that were further down the line unable to be completed. Since the team did not effectively plan for our internships, time that should have been originally free and able to work on the project was taken up by the internship. This caused us to fall behind on work as our planned rest days needed to become our project work days since our original project work days became internship work days. Having a work calendar will solve this problem. If we had all updated our work calendars after knowing which days we would be working, we would have been able to reschedule when to work. However, due to poor team communication and schedules not lining up, we did not find any time for meetings. I recommend in future having effective team communication in order to ensure people are working on their tasks. Through this communication we would also be able to re-assign tasks, ask about blockers and see what we are not going to have time to do. Through the effective team communication, we would also be able to make times to meet face to face (for meetings) and times when we all work from home in a conference call. This would allow us to get more work done and ensure that everyone is working their required hours per week.



Due to having a large scope, during week 6, when we completed alpha we realised that we our scope was too large and decided to cut a few features that we would not be able to complete. At the end of the project, we had a playable game, but it had no story elements. The game would generate the level; generate the clutter (enemies, furniture, pickups and keys); spawn the player; then the player will fight the enemies whilst searching for keys; and once the player has all the keys, search for the exit door, then repeat. As you can see this is the core game loop, however it is missing elements that would make it a game such as story, tutorial and other things. This is due to us over-scoping with features. During the early weeks of production, we designed the game, and everyone had a good idea of what the game is about. However, even though we planned and brought our scope into an achievable range, we underestimated how long certain things would take. Thus even though we thought it was achievable in the time frame we were given, we still over-scoped. In future projects to stop this from happening, there should be a project schedule we should be following which shows whether we are on track and whether we are over-scoped. In this project we did have a schedule, however we did not use it when we lost team communication. Tasks ended up being done in a different order to the original project plan. Thus we were unable to tell we were over-scoped until week 6 when we had to push our alpha build.




Due to having effective documentation, we were able to create the game according to the specifications of the designer. This happened many times during the project, one of these times was when I was creating the Clutter Generation system. I asked the designer to write up documentation for the clutter generation system and to write what it needs to do and how it needs to do it. By following the documentation, I was able to create a clutter generation system that worked how the designer wanted it to. The reason we were able to create the documentation for clutter generation so easily was due to knowing what the game is. To have good documentation I recommend spending time before planning out the game and documenting so you have a very good idea of what the game is. Not only will this help with documenting it will also help you have a very clear idea of what you want to make.

During the project, after our initial creation of documentation, we did not go back to fix it. Although we edited what systems did, we did not go back and update the documentation. This means that if we were without our designer, we would be unable to update the old systems due to not having updated documentation. I recommend that after changing anything, team members go back to the documentation and update it. This will allow the team members to just follow the documentation without needing the designer to be present.



In conclusion, team communication is the backbone to having a successful project. If your team doesn’t communicate effectively then the project will fail. Luckily for our project we communicated well face to face once a week (during class) and started communicating more after week 6.


The Wisp Trimester 2 (of 2) Progress Reflection Report

The Wisp Trimester 1 (of 2) Progress Reflection Report

Currently ‘The Wisp’ has been in development for 13 weeks. The first 6 weeks were designing, iterating, planning and documentation. The last 7 weeks were spent re-iterating, locking down the design, re-scheduling, re-scoping, prototyping and fixing documentation to match the new design.


Planning & Scheduling

When Planning ‘The Wisp’ there were a number of things we did right. We created a task list with time estimates, and a project schedule. Creating this schedule early really helped with allowing us to know when everything needs to be done and what we need to be working on. Since the planning was done early, this set the pace for the project as a whole. When starting a project it is recommended to spend time creating a project schedule and a task list, complete with time estimates, due dates, and dependancies. This schedule will serve as the backbone for the whole project and will allow the team to know what work is required, how long it will take to be completed and when it needs to be done by.


Although we created the schedule and task list early on in the project, we did not follow the exact schedule and instead prototyped and completed tasks in a different order from the schedule. Although this did not affect our project much, if we failed to follow the schedule completely, this would have led to a disaster and we would have needed to re-scope the whole project. The reason that we did not follow the schedule was due to redesigning and needing to check what feels good in the game. Whilst doing prototyping, we failed to update the schedule and instead worked on things that needed to be tested instead. We found it is imperative to either follow the schedule or update the schedule proactively to follow what the group is actually doing. This will allow foresight and show whether or not the project is on track or out of scope.




When designing ‘The Wisp’ we discovered that there were many things that needed to be tested to check whether or not they would work in the project. Thus we decided to prototype the parts of the game that needed to be tested. We found prototyping to be very helpful throughout the design process as this gave feedback to the designer, thus allowing them to know the limitations of each system. Thus allowing them to design around these capabilities and limitations. In future projects, prototyping should be used to test anything that designers are unsure about the limitations and capabilities of. Prototyping should also be taken into account when writing a project schedule. This should happen after the design is almost complete and the designer needs to check how certain mechanic works and it’s limitations. Then after prototyping, the design can be iterated on and ‘finalised.’


Team Communication

Our team communication was good throughout the project. This is due to using a platform that everyone on the team had used before and was familiar with. This program was Slack. At the start of the project, we immediately joined everyone to the slack team and made sure that everyone had the app in an easy to access place, namely installed on their phones. Since we were already a part of a team in slack we only had to create a private channel to chat. This was a near instant set up. Since we already had slack installed on our phones and had notifications enabled, we almost all of the time got instant replies. In future projects, it is recommended to use a platform that you are already familiar with and also install it on your phone to allow for the highest chance of seeing messages.



During the project, we took into account time to do documentation in the project schedule. This allowed us to follow our scheduling during the weeks 4-6 and complete our documentation before starting work on the project. This allowed us to all have a good idea of what the project was and how the project would work. This meant when it came time to work, we knew what we each had to do and what it entailed. We also used prototyping to help with documentation and in finalising the design. Since we had the documentation done, whenever we iterated, it was normally just entailed the changing of a few sentences in the documentation. The reason we had the documentation completed so quickly was because we planned to do documentation and everyone had a clear idea of what the game was. Also whenever we had questions, since team communication was good, we were able to get quick answers and move on during documentation.


At the beginning of the documentation process, we did not put all the documentation in one spot. This led to duplications of work, people being unable to find where the documentation was stored and people thinking that documentation hadn’t been completed. When we realised how split our documentation was, we took a few days to move all of the documentation into centralised documents and make sure all the information was concurrent.

Even though we finished our documentation fairly early in the project, we didn’t update it very often after completion. This meant that during the project, since we weren’t regularly updating, we had to rely on team communication to get answers. It also meant that we had to spend time going over documentation at a later date to update it, which took longer than if we had just updated it as we went. If our team communication was not very good, it might have led to parts of the project being created/implemented incorrectly. This may have also held up the work flow. In future, the team needs to make sure that if they change anything, it needs to be reflected in the documentation.


Project Processes

Throughout our project, we used the project management method of an adapted scrum. We did not follow the full method of our adapted scrum as we did not fully work through our sprints or decide on a goal at the end of the sprint. However, we did follow the philosophy of scrum, where everything we did was re-discussed on how it works and how it affects the overall project. In future, we should follow the project plan for our sprints. We should also continue to discuss how what was completed during the sprint affects the overall project.

The Wisp Trimester 1 (of 2) Progress Reflection Report

Studio 3 Critical Reflection

Throughout Studio 3 I have worked individually both in a team and individually. At the start of the Trimester, I worked individually and completed tasks such as optimising a ray tracer, creating a network game and creating a shader. I have also worked in a group, using my programming skills to help create a 2D puzzle game called ‘Slime Herder’. I have also undertaken an internship from week 2 to week 7 as extra work during this trimester.


Whilst working in a team, I have performed fairly well. I learnt about the process of Git Flow, how Unity Cloud Build works and learnt how to implement Unity’s in-built analytics and in-app purchases. I employed the technique of Git Flow throughout final project, but we decided to use a repository with everyone pushing to master for Studio 3 as the group was much smaller. This however did cause a few issues with merge conflicts. Since both of the programmers in the group (Ben and I) worked on the slime behaviors and it was a single script, this caused a few merge conflicts. However, even though we encountered this problem, we were able to successfully released ‘Slime Herder’ on the Google Play Store.


When working individually I have learnt about Mathematics (Shaders and Ballistic Curves (For ‘Slime Herder’)), Optimising, and Networking. Due to having an internship during the early weeks of the trimester, and due to having poor time management, I was unable to work on the optimisation and networking as much as I would have liked. However, towards the end of the trimester, I started managing my time better and was able to complete more work. This allowed me to create a C# Network Client for the C++ clone server that we created during class using .Net. I also worked on the Studio 3 game ‘Slime Herder’.


The components that I worked on for this project was creating the Ballistic Curve Math Library that allows the slimes to follow a ballistic curve, which means that they will always jump the same distance. Since Slime Herder requires all the jump distance to be consistent, we could not just leave it to Unity’s physics to simulate. I also worked on the Menu and also created an Audio Manager. This audio manager took into account the maximum amount of sounds that can play at once. It also had a queue that could wait until an AudioSource is available and then play the queued sound. It also had a priority setting which would make an audio clip play no matter what. If there were no available AudioSources, it would create a new one.


I believe I performed fairly well throughout the trimester, completing work assigned and being able to successfully release a game on the Play Store.

Studio 3 Critical Reflection

Ray Tracer Optimisation

Start Time: ~30 seconds


What Optimisations Did I Use:

  1. Enabled OpenMP (Multi-Threading)
    • Enabling Multi-Threading allowed the computer to use multiple cores.
  2. Dynamic Scheduling (Speeds up Multi-Threading)
    • Using dynamic Scheduling allowed the cores to take work from other cores, allowing for the slower rendering areas to be done by multiple cores when a single core was falling behind.
  3. Optimisation Settings in Project Settings of Visual Studios
    • Optimising the settings in visual studios allowed for a speed up in rendering, as visual studios settings are not defaulted to the most optimised settings.
  4. Removed Ambient Light Addition (As there was no ambient)
    • Since there was no ambient light, doing the calculations was unneeded, so I commented it out.
  5. Removed Reflection Colour Addition
    • Since there was reflections, doing the calculations was unneeded, so I commented it out.
  6. Used Spatial Partitioning
    • Oct Tree


Final Time: ~6 seconds


Ray Tracer Optimisation

Mathematics and Game Aesthetics (Shader and Ballistic Curves)

Shader (Slather Client)

I chose to write a shader for Studio 3’s clone Slather. I needed the snakes in Slather to change colour whilst they are boosting. This is so that players can tell when the other snake is boosting.


The shader currently inverts the colour of the snake when the player is boosting.


Ballistic Curves (Slime Herder)

The reason for implementing ballistic curves was because we needed slimes to jump a set amount of distance. This distance needed to be consistent so that players would always know what the slimes were going to do. It also meant that there would be less bugs because the game would always play the same for everyone.





Mathematics and Game Aesthetics (Shader and Ballistic Curves)

Risk of Data Storage and Privacy

Protection of information is a major concern for many people. People need protection for information such as passwords, bank account details, addresses, and other personal information. If others have access or are able to decrypt the data then people may be subject to fraud or identity theft.


When Data is stored on the Cloud (somewhere around the world), there are risks. Risks may include: loss of data, data being stolen, and the Cloud going down. Data may be stolen if the Cloud does not encrypt data and someone is able to get into the Cloud’s network. Loss of data may occur if the Cloud storage is down temporarily or permanently. A Cloud storage can be shut down due to government investigations. To guard against this, people can have a local copy of the data. For example if using google drive, also downloading the google drive app that downloads any new changes whilst you are connected to the internet is a way to keep a local copy and an online copy. The local copy will also update with the online copy and the online copy with the local copy. Thus you will always have a backup.


Data being stolen may occur through many methods. Data may be stolen due to deliberate attacks against the network or an individual who has access to the network. There are many ways these attacks can occur. One way is targeting an employee who has access to the data. This can occur by sending an infected email to said employee.



Continue reading “Risk of Data Storage and Privacy”

Risk of Data Storage and Privacy

Xbox One Limitations





8 Core AMD Custom CPU 1.75 GHz


853 MHz

768 Shader Cores


Performance Limitations:

Most games are locked FPS at 30-60 frames per second


Frame Rate:



Visual Quality:





Download and Install Size Issues:

Games are normally no larger than 75 GB

500GB Hard Drive

1TB Hard Drive

2TB Hard Drive


Since the Xbox One has the specs of a Low-Med PC, it has almost no limitations to running games when locking the frame rate to 30 frames per second.


Continue reading “Xbox One Limitations”

Xbox One Limitations