This week we presented a presentation of our game in the current state as well as updated our hardware report based on feedback we received. Some development work was also done on the game however some of it was a quick fix to get a working demo for the presentation and other was not completed in time for it.
Git and Unity
Getting Git and Unity to work together requires quite a bit of fiddling about but it is possible. By default, you can use Git and Unity out of the box however you’ll run into quite a few issues, the main one being merge conflicts when merging scenes and prefabs causing scenes to break and Unity to crash. I have spent at least 2 hours in this project fixing merge conflicts and there has still been issues afterwards so I looked into possible solutions. Some classmates referred me to GitMerge For Unity however unfortunately it has some issues with Unity 5 but Unity now provide their own tool known as UnityYAMLMerge.
I wrote a guide on setting up UnityYAMLMerge and Git here. Overall, I’m pretty happy with the guide as I tried to keep it as generic as possible to accommodate for everyone’s different setups. It is broken down into sections and I attempt to explain each step without going into too much detail so the user knows why they need to take those steps. I plan on updating it in the future to talk about more merging programs and git tools as well hopefully some more images to make it easier to understand.
Our task for this week was to make and present a presentation on our current game development progress so far. For this, we decided on a basic layout for the presentation then split the tasks up amongst everyone to get it completed faster. I myself worked on the Timeline, the live gameplay as well as creating the Gifs for the Player and Pause Menu slides. An online version can be seen here or an offline PDF can be downloaded here. The demo version that we used of the game is available here.
To create the timeline, I used a tool called Visio by Microsoft which is a flowcharting tool that has built in support for creating timelines. This tool made creating it much easier as I could re-arrange elements easily as well set colour schemes and global styles without having to edit everything individually. It did have its draw backs though, as exporting it as PNG with a transparent background degraded the image quality so I had to specify a background colour to prevent this. However the timeline itself accurately displayed the information we wanted to put across. I could have improved on it by having a second timeline for our future plans but it was not something we had discussed as a team yet.
The live gameplay section of the presentation was I believe our strongest point. It allowed everyone to see the progress we have made clearly and we was able to demonstrate that it is functional and playable. There was some downsides unfortunately such as about a 1-2 second lag behind when I seen something happen on the tablet and when it was shown on the main screens. The first time we had also tried to get it working just showed a frozen screen however we had created some backup slides (The Player, Pause Menu and Enemies slides) as a just in case. Thankfully, after the presentation we restarted the application and was able to show it working.
Overall, I am happy with the outcome of the presentation but there are areas we could have certainly improved. The slides themselves were rather bland and we rushed through the presenting to try and show the gameplay. We didn’t go into a lot of depth such as talking about code and how features evolved over time, instead focusing on what we currently had and the impact it had on the current and future gameplay. This wasn’t entirely avoidable however as we had a 7 minute limit on presentations so we wanted to make sure that we could show the live gameplay.
As score and leaderboards will play a large part of the game, I decided to work on improving our current scoring system as well as tracking scores last week. Leaderboards are something we can work on in the future when the game is closer to completion as we’ll only start tracking score globally when released. For reference, I treat scoreboards as local, current player score only and leaderboards are global boards with multiple players scores.
The first thing I wanted to work on was getting multipliers working as well as being able to show what enemy you killed and the score it was worth. For this, I created the struct ScoreData to store this data. I chose to use a struct here as all I wanted this object to do was to store data with no logic in it and a struct is the best solution for that. I then updated the Score script and AddScore method in ScoreManager to support the new ScoreData and used the name of the GameObject for the name parameter and multiplayer set to 1 as default.
The updated AddScore saves all ScoreData’s into a scores List which currently isn’t used for much at this time but in future, it could be displayed at the end of the level so the player can see what enemies gave the most score and a breakdown of their score. It could also be serialized and saved so the player can review it at a later date or when a high score is submitted to the leaderboards, the ScoreData list is also submitted to try and reduce cheating via score manipulation.
Now the framework was complete for receiving score data and storing it, next step was to display it on screen for the player to see it live. For this, a GameObject with a Text component was used that spawns below the current score display then scrolls up and eventually fades out. This is to allow the player to see how much score they got for killing the enemy as provides a bit more visual feedback when an enemy is destroyed.
Each new ScoreInfo created will spawn below the current one preventing them from overlapping and becoming unreadable and with the current pace of the game, this works well. Currently, the score list will generally reach about 3-4 entries long at most at one time which takes up a small portion of the screen however in the future, if we add more enemies at once or the player kills them faster, this list can grow very long and possible run off the screen. For this, the moveSpeed and fadeOutTime can be adjusted so the entries scroll up faster ensuring that this code is future proof against any possible balance changes.