FMP BLOG | joshuagunnett

Turbulence Final Major Project Blog

Week 1 (2 October - 8 October)

This week is the first week of my development for my Final Major Project. During this week, I had to design and produce an idea that would be substantial enough for my FMP that would perfectly advertise my skills and proficiencies. I have had an idea to create a game for a while beforehand and wanted to plan out what I wished to develop before presenting said idea to my peers for feedback and approval.

My initial idea for my game is to create something akin to that of Beyblade in a 2D art style; with there being a diverse use of both arenas and 'superpower's within the game to further enhance the aspect of the gameplay. The idea is for the game to be kid friendly and keep the game replayable, with the options to customise your tops, along with there being a fair range of abilities and customisation options available to the player.

Current Turbulence Version (Playable) (03/06)

Week 2 (9 October - 15 October)

For my second week of development for my game, I decided to first lay out the foundations of my game in terms of it's mechanical play-style, and it's visualisation. Therefore, this week was the week of creating the prototypes and bases for my game.

As you can see above amongst this collection of images and concepts, these are just a few examples as to how my thought process has been for how I would like my game to visually turn out. The top left of the images details that of a few concepts and shapes of the tops within the game, with simple and effective shapes to help distinct between the few, as well as an example of alternate colours; the top middle example of my idea of the games HUD, with it being a simple design that won't take away too much from the game; the top right example is a few fonts I've considered for my games text, as well as a general idea for the games logo; bottom left is an example of what the menus will look like, with there being simple controls and easy to read text, with easy on the eyes visuals, and finally, the middle right example, being an idea for what the main menu buttons may look like, with a sleek and crisp style that would feel fluid if it had a motion to it.

Week 3 (16 October - 22 October)

For the third week of development, my main target is to create the movement system of the spinning tops, as well as get to work on completing my first arena that I shall be primarily testing the mechanics of combat within: The Bastion. This is due to the plan of The Bastion being a simple rectangular arena with plenty of space.

From what can be seen above in these images, I have started laying out the basic parts for my game. The top left image shows a Canvas with a placeholder HUD that will be displaying my spinners health & current speed when I get around to programming it. The top right images show the structure for my spinners within the game, with there being an Empty within the top known as TopMove, and the top itself as it's own GameObject. I have purposefully done this as to keep both the movement script and the 'spinner script' separate, as I am concerned that if I placed them both within the same model, the movement of the spinners would become quite difficult, as it will only be going in circles. You can also see that I have binded both Player 1 and Player 2's controls for now, as while I do have the intention of internet play, for test reasons, I'm going with LAn controls of WASD and Arrow Keys. The bottom left image is an example of both the Bastion floor being used as a background for the top, so I can get a sense of scale for the game, as well as the spinner GameObject within the scene. As of current I am using a small white box as an indicator to see if the spinner is spinning around. The bottom right image is of the current progress with The Bastion, with the floor being made to represent a castle tile-esque floor.

Now, what was achieved within the games development this week was the 'spin script', which is the script that will visually show the spinners circular spinning inside the game. How it is operated is through a was by script that made the GameObject constantly spin 60 degrees every frame, as to accurately portray the spinners great speed. When the spinner health script is created, I wish to attach this spin script to the speed, so that the spinners speed may degrade, depending on the current health of the spinner.

Week 4 (23 October - 29 October)

For the fourth week of development, I wish to get to work on my second arena for my game, with that being the Infernal Lair; a stereotypical super villain-themed evil lair. I also wish to aim to get The Bastion arena to an acceptable level of detail, as the arena will need it's walls.

Week 5 (30 October - 5 November)

As you can see from the above images, I have started work within Photoshop to create the second arena for my game: the Infernal Lair. I had first created the background of lava for the game, as to give the stereotypical essence that this arena had an ‘evil’ appearance to it. From there, I had created a simple circular design from the centre of the lava and built up the design so that it would appear as if this were some kind of rocky mound within the middle of this lava. I then darkened a few areas within the mound to give it more depth, and to make it seem as if some areas are more scorched than others. You can also see the Bastion with it’s additional details placed in, with its walls, grassy areas and dirt marks. As of current, the Bastion is in a solid spot for its development, so I do not wish to add on anything more to it until the other arenas are developed. With the Bastion finished, I can add it into the game for more thorough testing.

For the fifth week of my games development, I wish to continue work on the arenas available, as well as get to work on creating the damage system for my game. The initial plan for the damage system is for the system to start at a high number, and slowly degrade with every frame until it reaches 0.

As evident with the images above, I have constructed the SpinnerHealth but implementing it into the SpinnerScript. With this implemented, I had the script set so that once a milestone was reached for the overall spinner speed, the spinners overall spin speed would start to decline, until it stopped moving once it reached zero. The image with the multiple numbers is that of the script printing a log of the spinners current health, which currently degrades at .5 a second.

I have also set the movement of the spinners to that of a simple Translate on an X & Y axis. When the appropriate key was pressed, such as for example the W key, the top would Translate along the Y axis by .3 every frame, that way movement would be simulated and easy to control. I had also developed it so that whenever the key wasn’t pressed, the speed would reduce by 1 every frame, until zero was reached. This way, the movement wouldn’t be perpetual and aggravating for the player, as well as give off a more realistic motion for the spinners. Also, since the Bastion’s full design was implemented, I could create the necessary collisions for the arena using both Empty’s and Box Colliders.

Week 6 (6 November - 12 November)

For week six, now with the movement system out of the way, it was time to move onto the damage system for the game. I also will be working on finalising the design of the Infernal Lair.

Above, you can see that one of the tops has been given circle colliders. The tops have two; one for the actual collisions between the two tops, and the other, much larger one is for the scripts actual collisions. The second circle needed to be this size as the collision script works off of an OnTriggerEnter2D, and having the circle being small would not be suitable for my script. As for the script itself, I made it so that the script, as aforementioned, would activate upon the opposing top entering the second circle. Once done so, the script would then take the current movement speed of the top and take that away from the opposing tops Spinner Health. I’ve also made it so that the spinners have their movement speeds reduced by half whenever they collide, to better simulate an accurate collision between the two tops, as well as made it so that when a top collides against a wall within the arena, it will also take damage.

You can also see that I have added more detail to the designs of the Infernal Lair, with there being spotlights/towers at each point. I aim for these to be obstacles for the spinners to strike and take damage from, as well as add as small barriers that can prevent a player from driving off the arena and taking damage from the lava; a feature that will be most prominent within this arena. I have also added a little logo for the arena, to add to the flavour of the scene and for a little light-hearted humour.

Week 7 (13 November - 19 November)

For the seventh week, I have been conducting tests based upon the motion and I have come across two notable issues with my current movement system: the spinners have the capability to move through the wall collisions of the arena, and that the movement feels too abrupt and cut. This is probably due to the fact that I am using Translate as my way of motion. Therefore, I wish to change the movement system within my game.

From what can be seen above, the left photo indicates as to my original problem in the previously mentioned text; when pressed against the wall, the motion will continue to build and increase, despite the collisions halving the movement speed. I consider this to be an alarming issue, as it can lead to exploits within the game. Therefore, I have opted to change the movement to instead using Translate, but rather adding Velocity to a Rigidbody2D along an X & Y axis. This turned out to be the better version out of the previous form of translation, due to the fact that the movement feels more natural, what with there being an element of acceleration to the movement. The tops also do something that wasn’t previously possible: they bounce off of each other. This adds for much more realistic collision within the game and makes these spinners feel much more like tops. With this new movement system in place, I now have to consider changing my damage script, as it was built to incorporate the Translate version, rather than the velocity version. Due to this, I could not perform much work on the games’ visuals this week.

Week 8 (20 November - 26 November)

For the eighth week of my games development, now that the movement system has been changed, I will also need to change the damage system to compensate for the new movement within the game.

Now, for my damage system, I have had it set to be based on a float rather than an int, due to the idea that the SpinnerHealth operates on a float, as well as the movement speed of the spinners. What I have found, based upon the damage that is dealt, is that when the damage is applied to the spinner health, it starts creating complicated decimal values on the spinner health. Another issue that I had found is that the values of the movement speed would also come back as negative values, as when the spinner starts going left or down far enough, the value of the speed becomes negative. Thus, to make things easier for myself and for the players to understand, I have changed it so that the movement speed is still applied to the spinner health, but, the movement speed value that is taken will be converted into a positive number, and that it is converted into an integer, so that way when damage is applied, it’s easy to read. You can see in the image above, the log of the damage that’s being kept within the log.

During this week, I also went to London to visit the well-known studio of Bossa Games; the creators behind such titles like I Am Bread and Surgeon Simulator. The nature of my visits cannot be officially disclosed for legal reason; however, the knowledge and experience I gained there is invaluable to me.

Week 9 (27 November - 3 December)

For the ninth week, I have managed to create the new damage and movement scripts for my game, thus, laying out the ground work for the simple mechanics of my game. Currently, what next on the agenda is the addition of Damage Text, which I shall be working on during the week, as well as a continuation of the arenas being developed.

How the damage text has been implemented is through the use of TextMeshPro, as by using TextMeshPro, I can have the text be instantiated once a collision has been made, without having to resort to using Canvas for the display. I’ve created a script that allows for the text to spawn in using the exact locations of where the tops are upon collision, as well as scripting it so that it would display the damage value for the player to see. When it was tested however, the text was spawning at the locations of which the spinners are, but the locations are way off the side of the map, and even if the text is within the area of the arena, the text somehow appears behind it. I will have to find the solution to this issue soon, as it is a feature I would like to implement within the game. Due to the efforts of trying to fix the bug also, not much work could be done on the visuals of the Water Temple, but the progress is going steady so far.

Week 10 (4 December - 10 December)

For the tenth week of my games development, I continued work on my arenas for my game, as I felt that with the core mechanics placed down, it would give me time to work more on the visual aspects of the game. Due to the bug also being present within the game, and for myself to not find the solution as of yet, I have placed that development on pause for now to focus on the visuals.

I have decided to work on my arenas more and get them out of the way, as they are integral parts of my games’ mechanics. Using Photoshop once again, I began work on creating the aesthetics for my arenas. When it came to the Water Temple, I wanted to get this done first as the water ducts that funnel towards the centre will act as a slow-down mechanic for the tops once they enter them, allowing for a much more diverse style of play. There are still a few details and additions that need to be made to the arena, but I like the progress so far and I believe it will be ready to be added in soon. Skywire is another I have planned on making, as it allows for a much tighter way of playing, what with there being a large hole in the centre of the map.

Week 11 (11 December - 17 December )

Week 12 (8 January - 14 January)

For the eleventh week of my games development, not much work could be done this week due to preparations for the games meet on the Friday, as well as other projects needing my attention. So for this week, I have been able to start working on the design of the Colosseum, as well as build off the designs of the previous arenas from last week. More additional details were made to the Skywire, and the Day at the Beach has had more fleshing-out than it’s base design. I’m holding back on Day at the Beach for the moment since it will have similar mechanics to that of Water Temple, as well as it’s design is pretty much a hybrid of the Bastion and the aforementioned arena.

For the twelfth week of my games development, after coming back from the Christmas break, I went straight to work on wanting to add more mechanics to my game, as my game is in much greater need of fleshing out. One of which of course being the Power Ups, Super Powers & Menu Designs of the game. This week, I've been at work thinking about what Power Ups that could be added. As of this moment, I have developed four Power Ups and icons for said power ups, that will be implemented into the game. From the image below, from left to right, they are: Bolt (Increases the speed of the spinners by the power of 2), Shield (Makes the spinner invincible for 5 seconds), Slow (Slows the speed of every spinner for 10 seconds) and Damage (Doubles the damage of the spinner for 10 seconds).

At this current moment, I plan for these icons to be the prototypes, so they are not the confirmed icons to be used. When they are implemented into the game, however, I will be using a spawning script system utilising an wherein the script will randomly choose a number between one and ten, with there being a cool down of about 30 seconds each time it's called. Once called, four of the power-ups will be tied to one of the ten numbers, as a means to have a rare occurrence to their spawning. Once spawned, when the spinner collides with said power-up, the effect will be added to said spinner (E.g.: If Damage is spawned and then touched, the script will call upon the spinners damage output and double it for 10 seconds).

As you can also see, I have planned out my Menu design, and a basis for 'spark' particle effects, to be implemented into my game. This menu will also be a placeholder for now, but I do quite like the design of the buttons.

During this week, I had also decided to obtain some feedback from my fellow peers, as I felt like I needed to gain some insight from multiple third parties on how they see the development of the game going so far; if they enjoy the core mechanics of this game, then they will enjoy what the rest of the game with shortly have to offer. Please see attached below the Questionnaire I had devised for my peers to answer:

From what I can indicate from the feedback that I was given, the results are generally positive for how the mechanics so far. Of course, there are plenty of things to be left desired, but I already am aware that there is much more to be done and to be added. I will be adding more particle effects, arenas and sound effects that will help further improve the atmosphere and 'replayability' of my game.

Week 13 (15 January - 21 January)

For the thirteenth week of developing my game, I've decided to take on the feedback of my questionnaire and make a few changes to the game itself. I have first decided to drop the Damage Text for now and come back to it later, since there are much more simpler ways for the damage to be displayed. I had added to the CollisionScripts of both Tops a public variable that calls to a Text placed below their respective prototype HUD's. There, whenever the two collide with one another, or when they collide with a wall, they can see the Damage/Self-Damage they have inflicted upon their opponent/themselves.

I have also decided to add a screen shake effect to my game, to further give the game some energy and excitement to it. I have done so by utilising the Animator within the engine to simulate the screen shaking via having the camera move around slightly upon a certain damage threshold being met. The screen will become more rampant with shaking if the damage amount is also high enough, as the Collision script will activate a function within a separate ShakeScript that will activate the appropriate animation, based upon the damage value. The image on the right below is a visual example of how the first shake was formed, as whereas the image on the left is a visual example of the many different shakes available.

During this week, I have also noticed an issue with the tops, in which they were dealing an egregious amount of damage within a short amount of time. I had then found out that the bool that was meant to be in place to prevent the script from spamming wasn't within the if statement that checked on the collisions. To prevent this from being a persistent issue, I have not only corrected the issue by placing the bool in the statement, but also to give enough time for the damage float to reset, I had incorporated an IEnumerator that resets the bool every fifth of a second.

Week 14 (22 January - 28 January)

For the fourteenth week of developing my game, I have continued work on my games assets, so that they may be imported into the game for use. I wish to also work on the games logo during this week, and see about importing my games's UI into the game.

One of the main focuses of this week that I want to work on is the games logo, as it sets the identity and designs for the rest of the games' U.I and visual outlook; there's no point having a logo that looks drastically different to the games' theme. Thus, I am using Photoshop once more to design my games' logo. Ideally for my game, I wish to show something that's going to represent the fast paced, dramatic combat style that is Turbulence, since the word 'turbulence' hints to something quick and shocking.

Above are the three logos I have developed before settling on the third and final design. While developing these logos, I had feedback from my peers about what they thought for the designs. The first one, while it had a motion blur-esque effect, felt too overblown with effects and, to me personally, it seems more fit for a racing game, rather than a game such as this. The second one was more simplistic than the previous designs and I had kept the triangle arrow underline as I felt that added to the effect of the logo. While I do like the tops within the B and the C, I wasn't keep on this one as it felt more like a toothpaste logo than what I had intended. The final, third logo is the one I am most proud of, and seems most fitting to what I had intended; it's simplistic and it shows the style of turbulence, what with the two sections of the world seemingly coming together to clash in the middle.

During this week, I have also finalised the designs for my power-up icons that Ill be used within the game. Each icon will perform a different task and will grant the user a benefit, or drawback, based upon what they pick up; Boost (Blue) will increase the spinners speed; Shield (Purple) will make the spinner invincible for a short duration; Damage (Red) will immediately deal damage to the opposing spinner; Health (Green) will grant the spinner HP back; Slow (White) will slow down time within the battle and Burn (Orange) will deal continuous damage to those who pick it up for a short duration.

Week 15 (23 January - 4 February)

For the fifteenth week of my games' development, I'm looking into the power-up spawning for my game, now that the assets are done. I will also be working on any extra mechanics for the game, including the games official timer.

To create my timer for my game, I utilised an IEnumerator that would constantly tick down every 1 second while the timer remained above 0. If it does end up reaching zero, then it will actively compare the two spinners' health. If one is higher than the other, the display text for the timer would change to display Player 1 or Player 2 wins, depending on whoever's highest.

As for the Spawning system for the Power-Ups, I have utilised a script that calls upon a list of prefabs (Power-Ups) and a list of Spawners (Empty's). From there, the script will only activate on a third chance, using Math.Random. If selected, the script would activate and randomly spawn a power up between a randomly selected empty.

During this week, I have also been working on the Power-Ups' scripts that would replicate the idea for the intended mechanics for the power ups in the previous week. I intend to get all of their mechanics done for the next week, as Vertex is around the corner.

Week 16 (5 February - 11 Feburary)

For the sixteenth week of my games' development, I can add these extra mechanics to the game, and the game should be almost complete in terms of mechanical gameplay. I shall almost be importing the rest of my U.I assets into the game this week, and making the game look more visually exciting.

I have decided to import into Unity the HUD displays that will be used to contain the stats of each top, replacing the prototype black bar that covers the two. This is making the game really starting to show in terms of it's visuals and how I had intended for the game to look visually.

During this week, I have also created the health bar system that will be used to display the health of each spinner, rather than it being displayed as a number, though I am considering having both on display. I have used a simple square sprite that scales itself in the X axis based on the amount of health the spinner has. Currently, the value is set to 3000, so the initially the length of the health bar was incredibly long. This issue was fixed by creating a separate float value and dividing it by 1200 (2.5) of 3000. This made it possible to have the health bar be of a reasonable size, without affecting the main SpinnerHealth value.

Week 17 (12 February - 18 Feburary)

For the seventeenth week on my games' development, I have worked on importing my U.I into the game itself, while also creating a few extra details to help further update the games visuals.

I have created a separate scene for the menu features, and I intend to have a script translate between the two scenes that's paired to one of the buttons. I already have the button sprites and the background pieces available, so I imported them in for them to be used.

For my game, I have also created some Spark Effects for my game, utilising both the Spark Sprite I have already developed, and a TrailRenderer that helps to further detail the sparks. Utilising the collisionscripts already set damage amounts for the ScreenShake effect, whenever a damage threshold is met, a shower of sparks will also emit when the blades collide.

The power-ups for the game have also been completed and imported into the actual scene, as they were being tested out in a separate scene beforehand; the Fire & Shield power up both call directly to the HealthBar within the game, and visually change it's colours so that you know when these power-ups are in use.

Week 18 (19 February - 25 Feburary)

For the eighteenth week on my games' development, I have been using my time available to prepare my game for Vertex, going over a few extra mechanics and bug testing to ensure that the game wouldn't have any particular game-breaking issues.

I have also linked up the MenuScene of the game to the Games overall scene within a script that's paired with a button, allowing for there to be infinite play between the two scenes. I do not intend to go visually overboard with my menu's visuals, aside from a few pieces here and there, such as a large spinning top in the bottom left corner of the menu, and some scrolling tops in the background. I intend to get the scrolling completed within the coming weeks.

Week 19 (26 February - 3 March)

For the nineteenth week of my games' development, I have been preparing my game to present to Vertex 2020 for others to view it and gain feedback for my game, so I have been hard at work making sure that the games' mechanics were within order and look presentable for all to see.

Going there was of a great benefit to me as I was able to network and interact with multiple developers and artists there who were a part of the industry, and a few did come over and see my game being presented on the TV screen there. I was able to talk them through the intentions for my game and what I aim to achieve by making this game. While the game isn't the most aesthetically pleasing, the mechanics of the game were present and solid, and I was pleased with how it turned out.

Week 20 (4 March - 10 March)

For the twentieth week of my games' development, I intend to further expand into the games' features, including a Player vs A.I mode, with one of the tops being fully controlled by an A.I, as well as looking into placing in a second arena for my game, and creating the customisation features for my game also.

The AI utilises a similar system to how the player moves, in which it uses the AddForce part of the Rigidbody2D. The A.I is notably more 'slidey' in terms of an actual player, but it has the capability to damage as much as a player Top. I have also added in the feature for the player to play Player vs A.I within the menu of the game, and duplicated the Bastion level to load up for now whenever Player vs A.I is selected, for ease of access and testing purposes.

On the right, you can see the aspects of the script that were used

publicly, as the A.I top actively looks for the players location and

charges towards them, as long as they do not exceed the distance of

how close they are to the top.

Corona Period (11 March - 3 June)

Due to the Cornonavirus shutting down most areas that I used to work at and access, work on the game had slowed down to focus on other projects and other aspects of life. This had not stopped the game from continuing it's development however, as I aim to get as much as possible completed before the deadline.

Firstly, I had completed the A.I for the game to ensure that the player is continuously followed and attacked, regardless of the area of the map. Then, I had made sure that the games' other arenas were completed so that they could be added into the game, with the images below being the completed versions of the arenas that have been added. I had chosen to leave out the Colloseum arena personally due to the fact that it felt very low-effort to me in comparison to the other arena designs.

Now, what I had also aimed to achieve within the game was to have the lava and water arenas of the arenas damage tops that went inside of them. Therefore, utilising OnTriggerEnter & Exit, and similar mechanics to that of the Fire power-up, I had sections of the arena become triggers that would deal continuous damage to the tops, as long as they were present within the area. I had also reduced some of the power up spawns within certain arenas to allow for combat to be less reliant on the spawns, and make them easier to fight over with the other player.

For ease of access for level selection, I separated the levels into Player vs Player and Player vs A.I versions of each other, so that when in the level selection menu, clicking on the right button will load the level of the game that you wish to play. You can also see within the image

next to this text what the arena selection screen looks

like, displaying all five arenas that are paired with buttons.

Once selected, the player will be transported to the level,

and depending on if they select Player vs Player or

Player vs A.I, the buttons will link them to the A.I level or

the player level.

FMP Evaluation

In regards to my FMP, I wish to evaluate how well the game had been produced, as well as how I felt my performance was when it comes to the development of the game.

Firstly, the game itself: I am pleased with how the game turned out when it was finally submitted; most of the mechanics that I had desired to place into the game itself were present at the time of submission, and I a especially proud of the spark effects and A.I that I was able to develop during this time. The art for the game, I am happy with how it had turned out, since I do not consider myself to be the most artistically gifted in comparison to other persons, but nonetheless, I am pleased at how the arenas turned out. Unfortunately, there are parts of the game that I had not placed in that I wished to use but was unable to due to time constraints, this being the additional arena of the Colosseum, which while I was displeased with how it is basic, I could have improved it. I am also unhappy that I was unable to develop some form of top customisation within the game, as that would further add a dynamic to the gameplay and keep the game feeling more fresh and personal to the player. While I did also include the Power-Ups that spawned within the arena, which I am happy to have developed, I am also displeased that I could not create personal powers for the tops themselves. Along with this, but I was unable to add in sound effects to the game also, which I am also displeased about. While these drawbacks are prominent, I am pleased nonetheless with how the end product turned out.

Next, my personal evaluation: I am happy with what I had set out to do initially when developing this game; the objective was to not create something massively visually appealing or striking for the eyes, but rather something that could demonstrate my mechanical and programming skills for those that are interested. I believe that this game has shown my skills in the UnityEngine and the C# language, and though I was not able to add in additional features to the game that would show off more of my skill, I am still pleased with how the game had turned out, and my performance in that regard. I do believe that there were areas in which I had lacked and struggled with due to a lack of foresight in areas, leading to less time being available to me to complete what I had wished to place in the game.

What I shall look to in the future is to continue work onto the Turbulence game and place in the desired features that I had sought out to place in before the deadline. I also wish to further refine my time management skills to be able to produce exactly what I want to place in. I see no reason to not continue developing the game and honing my skills, as I believe I have a lot of time on my plate to further perfect and refine my programming prowess.

I AM

JOSHUA GUNNETT