Sat down as a group to come up with possible ideas we could use as our game over the allocated 4 hours..

Ideas that were discussed were:

• Labyrinth/Monkey Ball style game where the player has to tilt the phone left and right to move. Forward and backwards to speed up or slow down. This was rejected ideas were hard to come by to make it interesting.

• Weight lifting style game where the controls were simply tapping the screen as fast as you can. This however would have been less of a game as it is based around animation more than mechanics.

• Golf Style game where it would be a race to the hole but the idea got complicated very quickly.

• A line drawing game (Winner) to get a ball from one side of a level to the other side by drawing a line using your finger which to ball will roll along with goal being to get the ball into a bucket. This was agreed to have the most potential and clear idea on where to improve the game in the future

Starting off the week, one of my group members came in with a start of the core game mechanic with that being able to draw a line on the screen using the mouse and a ball in the scene that can drop down on command and react to the line and roll down it.

This left us in a good spot to try and work on the goal of the game which is to get the ball into a bucket on the other side of the level. To do this, we first had to make an actual bucket to have the player aim for which was a simple task as three rectangles all it required was creating three rectangles of equal length and placing them all under the same parent and positioned each of them to have one rectangle as the base and the other two as the sides of the bucket leaving the top open.

Once tested to make sure that the ball goes into the bucket a very small problem arose which was that the ball was able to bounce out of the bucket which is not intended. This had a very simple fix with a trigger box being created and placed within the empty space in the bucket where the ball will land. The speed of the ball would then get changed when detected by the trigger box from which the speed of the ball gets set to zero to eliminate any chance of the ball bouncing out unintentionally.

Alongside creating the bucket for the game, I setup the Google Play Store account which allows us to be able to publish the game onto the Google play Store which is key to be able to get the game marked as well as allow people to test the game and get feedback off them to try and improve the game. This did cost $25 (£18) to create the account but was split between each member of the group meaning each had to pay £4.50.

The previous week consisted of less programming to try and improve the game as the game as we attempted to try and convert the game from running only on a PC to be able to get the game running on an Android device.

The first thing that had to be done to get the game to be playable on an Android was to create a button that does the same job as the spacebar which is to make the ball start to drop down and be affected by gravity as without this, there would be no way for any user to test the game.

When trying to get the game onto an Android device we ran into an issue with that being that the screen was not scaling properly and therefore meant that the player was unable to see the bucket or the newly created drop button, instead just the ball floating. The user was also unable to draw any lines which was a big issue as that meant the game wasn’t working at all. This problem was eventually fixed but instead of the problem being a coding problem, it turned out to be an error when building the game as the build did not include the correct scene.

Apart from this annoyance, some improvement was done as the ball did not behave in the ideal way when it comes to momentum as if a ramp is created, the ball most likely does not make it off the ramp. One method of fixing this was by having the ball go a certain speed when touching the line but this does not work as the ball my be barely moving or traveling perpendicular to the line and still get its speed increased when it shouldn’t.

Instead, the method used to try and have the ball act in a more intended way is by firstly detecting whether the ball is moving downwards towards the ground and secondly checking if the ball is colliding the line created by the user. If both of those conditions are met, the ball speed gets increased by 1.2 giving the impression that the ball is gaining momentum.

I also uploaded the first working prototype of the game onto the google play store which took much longer than expected with there being issues about having to create a privacy policy. I eventually submitted the game but sadly it got rejected with the reasoning being "metadata".

Moving away from the behaviour of the ball, the user had to be able to collect stars along the way towards the bin to try and add a challenge to the game but take away the casual part of the game if the user doesn't intend to spend too much time on the game.

To start with, I created a very basic star prefab by using two squares coloured yellow, rotated one of the squares by 45 degrees and then placed them on top of them to create the illusion that its a star. This is only a place holder to be able to write the code to have the user pick up the star. The coding part of the stars was relatively simple as all I had to do is a simple "OnTriggerEnter" and check to see if the object's tag is "Star". If so then it would need to increase a variable called "starscollected" by 1 and delete the star object.

The length of the line was also fixed as previously the user could draw more lines than expected. This was also a very simple solution but me and another member of my group were overthinking on how to fix this problem.

To fix this, every new point in the line that was created sent a message using "SendMessage" to the "Line Manager" to increase a variable counting how many points the user can have. Now when the number of points the user draws reaches the maximum number they are allowed, the user wont be able to draw anymore.

For the beginning of the week, I moved away from programming for a bit to be able to focus on creating the questionnaire that will be given to users that are going to test the game at a later date. To be able to design a good questionnaire, I had to look at previous questionnaires made by groups from previous years and see what kind of questions are asked as well as the response that is expected from those questions.

Alongside creating the questionnaire, the API had to be changed in the build settings of the app as the only android version that the game could be played on was on Android 11, compared to the first prototype which was able to be played on multiple Android versions. This was a bit of an issue if this was not changed as the number devices that could play the game greatly decreased. This was a very simple to change though as a setting in the build settings had to changed to the lowest API down to Android version 10 with the target still being Android version 11.

Later on in the week I shifted my focus back onto the programming side of the game with the main aim being to try and get a save and loading system working to allow the user to be able to save the progress they have made in regards to the number of stars they have collected in each level. This took some time as initially I had to be able to learn how to create a file, save to it and load it. To do this I followed a Youtube video by "Brackeys" called "Save and Load System in Unity". The way I have the data stored in the file is by having an array stored in it with piece of data inside of it being the number of stars collected by the user in a certain level. For example, array[0] saved the score the user obtained in the first level of the game.

From this video, I learnt about how to safely store data in a binary file however this wasn't much of a concern as the data being stored was not personal and would not be putting the user in any danger if it was to get leaked.

This week was more focused on small bug fixes and quality of life improvements after getting initial feedback from people such as menus overlapping which prevented the user from being able to press certain buttons to be able to return to the main menu and improving the ability to reset a level by having the reset button not hidden in the pause menu. These were very simple changes that were made quickly when working with my group.

There is however a bug that neither me or anyone in my group has yet been able to figure out how to fix which is that the ball will sometimes interact with an invisible directly in the middle of the screen even though there is no object placed there.

As we were getting close to the end of the development time, there wasn't much to be able to add in the limited time frame that was left. Instead, I focused on trying to fix an issue that occurred with the saving and loading system that I created in a previous week.

The issue that existed was the users weren't able to save any of their progress that they made on each level as no file could be found which was very interesting as it was working for me on my laptop. After some messing around with the code and asking people for any ideas, the problem was realised to be that I had already had the file created on my laptop from when I was setting up the saving system. Therefore I had to write some code to be able to check to see whether a file with a chosen name exists and if not, the game would create a new file with an array stored in it with all the values in that array being 0. This then allowed the users to save there scores and have it displayed on the level select screen.

As this past week was the penultimate week, I didn't add any new features into the game to prevent the risk of damaging the game and making it unplayable. So instead I focused on tying to identifying any glitches that existed as well as trying to remove any error messages that were constantly appearing to make sure that the game didn't crash.

One of the most noticeable error messages was when the user would load up the main menu screen and an error message appeared stating the a game object could not be found. This was because the main menu screen and the level select screen are in the same scene but when one is enabled, the other is disabled. Once I understood this was the problem, the issue turned out to be a simple fix as all I had to do was to check to see if the game object that was for the level select screen was enabled and then try to display the text for the total number of stars collected. After doing this, the error message disappeared, never to be seen again.

This was the final week of the project with all the focus going into getting the Game Design Document completed as well as the individual report for the game and the peer assessment. No coding was completed this week apart from doing last minute tests to check for any errors which there was only one with that being that someone in the group added a new sound file and had it filled in, in the first level only. Because of this, all the other levels would bring up errors when the ball entered the bin and the win screen did not appear as expected.

After talking with the group to get this sorted, the sound files just had to dragged into the slot in each level and afterwards, each level worked as expected.