This blog post will be shorter than the last blog post so you probably won’t fall asleep this time (but it’s never a bad idea to get a nice drink anyway). I do have a little bit to talk about this week though, mostly relating to project management and working together to create something together. I feel I could have been a much better project co-ordinator last week and the failure of that increased my own workload a little however I know how I can improve on this for the future. And as usual, I’ll be discussing the code I wrote as part of Project Dangerzone this week (which actually ties quite a bit into the project management).
Setting up the workflow
From the very start, I knew code management would be an issue with 5 team members so I proposed to our group that we should use Git for version management. Using Git means we can all work on the same code without constantly overwriting everyone elses changes as well as have a backup and different versions of the code. It also gives everyone experience with using Git which is used in a lot of major workplaces.
However just using Git would cause a lot of merge conflicts if we work on the same code and commit/push constantly so we needed a workflow that allowed us to use the full power of Git. This is why we went with the Gitflow workflow which has a main “develop” branch then you fork “feature” branches off that whilst you work on your stuff and merge it back in later. The advantages of this is it allows people to work and push their own code without constantly having to solve merge conflicts with other peoples work in progress code. It also means that others can pick up on someone else’s feature and we can work together more efficiently.
I have experience with Gitflow in some different projects so I wrote a guide (Which is still a WIP and something I’ll be adding onto in the future) on how to setup SourceTree to use it as well as what to do when you want to start a new feature, sync one etc. It worked quite well, a lot of people in the group picked up although there was some teething issues (such as someone working on the develop branch). To help resolve those teething issues, I created the “Overview” part of the sheet which was a simple step by step process on what needs to be done but I have encouraged my group mates to read further on Git/Gitflow to further understand how it works.
Assigning the tasks
This was probably the area I am least happy with myself this week as I got a little ahead of myself and failed to properly coordinate the team.
So about a week or two ago, we setup the base Trello board based upon Agile Scrum. Last week, I began going through our HCD and picking out the core features that we needs to complete this week and added them to our Release Backlog then into Current Sprint. I assigned time units (I’m using the Agile for Trello extension to see the little light bulb icons, you’ll just see them as numbers in brackets in the title) based on how I expected each task to take based on the overall team level. People then assigned themselves to the tasks they wish to complete and that was all good.
Unfortunately it didn’t work out that way. A few of the goals I had setup conflicted with the task we had been set for the week and not all tasks had been assigned to everyone leaving some of the “uglier” ones for people who have less experience with coding. So we had a small meeting on Wednesday with our tutor and we all agreed that in the future, I should try assigning people tasks to do for the week. I did mention to the team that if they was unhappy or struggling with a task that was assigned, that they speak up so we can help them complete it and they can work on other tasks if they wish to or have the time.
Overall, I should have waited for our task to be assigned rather than jump the gun and start creating tasks for everyone but next time I shall wait till Monday (when the task is assigned) before creating and assigning the tasks for the week. I also need to rework the time units slightly as I found that people completed the tasks a little faster than expected but it’s still something that will improve as I learn the teams’ abilities.
Working on the tasks
This ties into the last section quite a bit as I feel I didn’t organise the group enough to prevent code overlap. By now, we are all working on our tasks and it is actually proceeding very well. The others will talk about their own work in their own blog posts however I just wish to discuss the overall outcome from it and how we can improve on it as a group for next time.
Aaron worked on one enemy, the main fighter; Shannon worked on player movement, getting it to move via the keyboard; Eliot worked on a new enemy, one that moved left to right on the screen constantly; Charlie worked on implementing the bullet object and its collision code; And I worked on implementing some of the UI elements and ultimately getting all our code to work together. I will talk about my UI code later as for the moment I want to reflect on the last part, getting our code working together.
First off, everyone did an excellent job on their tasks, it all works with (so far) no noticeable bugs. The issue comes from all the different parts they worked on didn’t really mesh together , it’s something that I had to spend a little time adjusting at the end of the week. For example, Charlie’s bullets would fire and collide with Eliot’s enemy plane however not Aaron’s. This could have been prevented if we communicated about exactly what we was working on and used the Tags system in Unity so they would all automatically work together. It’s something we need to work on together as a team in the future and communicate between us more to prevent these issues.
Implementing the UI
One of my tasks these week was to get the UI for our game functioning for a PC however thanks to the way Unity functions, it also works for touch screens and mobile devices. Also as we had set up a UI canvas and all the button images separately, it was a bit simpler to convert them to buttons.
Firstly, to change them into buttons I added the Button component to each one then created a script with functions to get called each time the button is pressed. At first this didn’t work but after some research, I found out Unity hadn’t automatically created an EventSystem game object that captures input so I created that and it began functioning.
Next was to get the gun button functioning which was simple enough as we already had the bullet prefab set up. So I created an instance of it, spawned it on top of the planes position and set it to destroy after 1 second. I noticed another issue in that the bullet was colliding with our own plane so I told the physics engine to ignore collision between the two objects.
Another feature of the UI I implemented was the pause button which was less complex then expected. To pause (or slow down) the world speed in Unity, you can simply set Time.timeScale to another number where 0 is paused and 1 is normal speed. I also made it so the screen darkens when paused which was done by adding an UI Image component to the canvas (so that it always covers the screen), leaving the image as none and just changing the colour and alpha of it instead, creating an overlay. This darkening of the screen helps remind the player that the game is paused and when we implement the ingame menu, it will help the menu stand out against the game world which will be darkened.
The score system was also something I worked on but only to a basic functioning state, it still needs some visual improvement. I added a script to the score object which other objects can then call the AddScore function on it to add to the players score. This is setup this way so we can track a history of score as well as make the score text increment up over time instead of just adding the number directly on, making the game feel more alive (as who doesn’t enjoy seeing numbers increase?). I also created a Score script that can be attached to any object that should modify the score on their death.
Unfortunately I didn’t add much functionality to the Nuke or Missile button as we still need to implement those features which we will do so in the coming week. The health and shield also needs to be implemented but that may be possible to do via the use of the UI Mask component.
UI Manager Code
This week was very productive however there are certainly areas I can improve in and us as a team overall. We managed to get a working version of our game in which you can kill enemies, can gain score as well as have your own player plane be destroyed if you collide with an enemy plane. It is still far from complete as enemies don’t fire themselves and there is only a few enemies and there isn’t a level to complete to speak of.
Something both I and us as a team need to work on in the future will be improving communication between us all so we can worth together more efficiently and reduce the possibility of any issues arising. We can try to work around this by meeting more often to discuss what we’ve done and what needs to be done as well as consulting each other when we are completing tasks. Another thing I have been trying to improve this week is adding comments to my code to make it easier for the other team members (and future me) to understand why I am doing certain things and what those things are doing.
For next week, I’m hoping we can get the missiles as well as the nuke implemented and working as well as get some of the enemies shooting back at the player to add some game play. We can add some more enemies in that appear after a certain time to give the level some progression and challenge for the player. Health should also be implemented so enemies and the player doesn’t just die in one hit, further increasing game play and challenge of the game.