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