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.

 

Scope

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.

 

 

Documentation

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.

 

Conclusion

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 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.

 

 

Prototyping

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.

 

Documentation

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.

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++ slither.io 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.

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

 

Mathematics and Game Aesthetics (Shader and Ballistic Curves)

Shader (Slather Client)

I chose to write a shader for Studio 3’s slither.io 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.

When Not Boosting

When Boosting (Inverted Colour)

 

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.

 

 

Library

 

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.

 

 

Xbox One Limitations

Specs

RAM

8GB

CPU

8 Core AMD Custom CPU 1.75 GHz

GPU

853 MHz

768 Shader Cores

 

Performance Limitations:

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

 

Frame Rate:

30-60fps

 

Visual Quality:

720p

1080p

4K

 

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.

 

Studio 2 Self-Reflection

Good

Strong Work Ethic

Throughout the trimester, whenever there was a hard time limit on completing work I was able to complete the work before the specified time. An example of this is when I was working on the game Anti-Gravity. Whenever there was a playtest coming up, or a date that everything needed to be fixed by, I would go through my task list and make sure to do all the things that needed to be completed. For example in before the final playtest/gallery, I needed to fix the problem of the boxes falling through the floor, I fixed this by making it so that the boxes ray cast from the top instead of the bottom. This allows players to put boxes partially through the floor and they will float back up to the position they originally should have been at. I also made sure that this bug was fixed before the gallery showing.

 

Problem Solving Skills

Throughout the trimester, I was able to solve problems given to me. An example of this is when I had to set up an xbox 360 controller to work for Anti-Gravity. Setting up a controller to work in game was a new task that I had never done before. When converting the controls, I found the best way to do this was to use the unity input system to convert Keyboard and Mouse to Controller.

 

Positive Attitude (?)

Whenever I completed a task/work and was given feedback, I took this objectively and worked to improve myself from the feedback. For example, during the project Anti-Gravity, my team members informed me when my work did not work the way it should have, or when I wasn’t doing my job properly. Then from that feedback, I was able to fix what wasn’t working.

 

Bad

Time Management

Throughout this trimester, I had poor time management. Due to this poor time management I was unable to do all the things I wanted to this trimester. For example, I was working on a side project for the first 5 weeks of the trimester, however, I got sick for 2 weeks and this caused me to stop working on it. Due to poor time management, I didn’t get back to working on this project until the last week of trimester. To deal with this poor time management, I found it is essential to create goals for any task I am working on. Setting this time limit will allow for my ‘Strong Work Ethic’ to complete the task on time.

 

 

Terrain Generation with Linear Interpolation and Noise In Unity

Since the first week of Studio 2, I have been working on a Minecraft Style terrain generation with linear interpolation and noise. When starting this tool I knew that I needed to accommodate a few cases. These include: Using single meshes, using objects, and using Unity Terrains. At the moment I have only implemented it for using objects as I am using this for a project of mine.

 

My Procedural Terrain Generation

 

 

 

The Basics of How I Implemented It:

• If it is the starting position, then pick a random height from 2 set values (min/max difference in height) and add/minus it from the transform.position.y. This is the ‘Chunk’ 1 Starting Height.
• Else if it is not a starting position, we check for surrounding points and use them as the initial values. (As we want all the chunks to connect together seamlessly).
• For the 4 corners of the ‘Chunk’ (if they aren’t set) add or subtract a min/max height difference value from the connecting corners. Since we set from the 0,0 co-ordinate inwards, we do 1,1 last and this value will always firstly average out the 0,1 and 1,0 values before adding or subtracting the chosen value from min/max height difference.
• For this chunk, we need to linearly interpolate between the 0,0 to 0,1, from 0,0 to 1,0 and from 0,1 to 1,1 and from 1,0 to 1,1 and add a bit of noise. Thus creating smooth ground. (The values for ‘Chunk Size’ and Object Size and Noise amount all affects this interpolation). We also need to set values in concentric circles from the outside inwards. Since we cannot linearly interpolate if the values next to the middle aren’t known yet.
  • Linear Interpolation Methods In Read More (Along with Noise Methods)
• Then we try to spawn a chunk on every corner of all the chunks we can see (Set by our ‘soft edge’ value).

 

Included are a few problems I ran into whilst implementing:

Problems & Solutions:

• I had a few problems with the chunks not checking if there were surrounding chunks and to use their values for the generation.
  • The solutions were: To check all the methods for which corners I wanted. One of these was wrong. I was grabbing the wrong corner from an object on the left side. Instead of grabbing its 1,0, I was grabbing it’s 0,1 and setting it as my chunks 0,0.
  • Another Solution was: I wasn’t checking the diagonals at all, so if there was an object diagonal of it, it completely neglected the value. I didn’t even think of doing this until I was a couple of weeks into the project and had been having this bug for ages.
• I had another problem where it would re-generate on top of another object. This was due to bounding box checks that weren’t intersecting due to the y value being so different that they didn’t touch.
  • I had to expand the bounding box to a default value and check against another created bounding box which is the default size of a chunk instead of checking a bounding box against a position.

 

Link: https://bitbucket.org/saeunitycommonlib/saeunitycommonslibrary/downloads

 

Writing Tools for Unity: InspectorGUI

What is InspectorGUI:

InspectorGUI is what Unity uses to allow you to edit values from the inspector. Whenever you put a public variable in a class, Unity allows you to edit it in the inspector by showing the value. This is exactly what happens when you use EditorGUI to customise how you wish to display your values.

 

Where Should I Use InspectorGUI:

When coding, I’m sure you have come across a value that you wish to be public, but you don’t want the designer that is going to use your code to edit it. Instead of setting up functions or using setters/getters, you can use EditorGUI to force the inspector to only show what you want it to. It also allows you to customise how you wish to display it. It also allows you to give it labels instead of just using what the variable is called. So if you name a variable something quick, you can still display the long name.

 

Advantages (See examples (After Read More)):

• Only show designers what they need to edit.
• Custom display things how you want. (For example Sliders and Toggle Lefts (LHS Bool))
• Add help boxes before and after variables to tell designers exactly what they need to do.
• Dynamic Editing by using bools to only display values when you want. (You can also use floats (if it is greater than certain value))
• By using EditorGUI you no longer have to murder designers when they touch something they shouldn’t have.

 

Disadvantages:

• The time it takes to type out all the variables and re-arrange them. (Although this should be fairly simple as you do not want to show the designer hundreds of variables. If you can automate it in code, that is one less variable to display.)

 

Expand For an Example Class and Example InspectorGUI Class: