{"id":109,"date":"2021-11-19T13:44:21","date_gmt":"2021-11-19T13:44:21","guid":{"rendered":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/?p=109"},"modified":"2022-01-07T14:48:46","modified_gmt":"2022-01-07T14:48:46","slug":"2d-games-development-diary-week-6","status":"publish","type":"post","link":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/2021\/11\/19\/2d-games-development-diary-week-6\/","title":{"rendered":"2D Games Development Diary Week 6"},"content":{"rendered":"\n

Welcome to Week 6 of my Development Diary. The focus of this week is to continue developing the prototype further by adding the features needed to meet the brief and exploring adding extra interaction to the game. As a reminder, the brief around the prototype is that I need to develop a game that features collectable items that the player can collect, enemies that the player can interact with and a means of a win condition to what the player must do to win the game. In this instance, the player must reach a door within the level to which they must also find the key to open. Finally, instructions on how the player can play the game need to be displayed to them, such as the games controls and the overall objective to win the game.<\/p>\n\n\n\n

In the previous blog entry, the requirements for the collectables and enemies have been met to function fully. These functions include two different types of enemies, grounded and flying, and in terms of collectables, various items can be collected, and they all do different things to the game. These include ammo box to which increases the player ammo of a specific weapon based on the colour they collected, e.g. green equal pistol, coins that increase the player score, coffee that give the player an increase in speed temporally, cookies that increase the player health and important the key to allow to complete the game. From having these features and the basic mechanics adequately made for the game, last week was successful, to which all were left to get the win condition working and instruction to playing the game.<\/p>\n\n\n\n

\n
\n

To carry on from where the prototype was last left from last week, I focused on making the instruction by first creating a text image screen through photoshop with text that include how to play the game and the controls on how to interact with the game. These instructions are essential to the game because they tell the player their primary goal is to complete the game and outline the features of what they can in the game through the controls. Below is a screenshot of the instruction to which tell everything of what is essential to the game.<\/p>\n<\/div>\n\n\n\n

\n
\"\"
Figure 1 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n
\n
\n

To ensure that the gameplay is not interactable when the instruction is displayed, a boolean called “startGame” is used to check if the player has started the game or not, which is set to true upon the player pressing the “Enter”. When this boolean is set to true, it allows the player to begin playing the game and hides the instruction screen. This may be useful when a pause menu screen was planned to be implicated if further development to the prototype was to be made. However, the main focus is the shooting mechanics since I am experimenting with this project. Disabling the controls this way can prevent some bugs, such as allowing movement while unable to see the player, which could put the player at a disadvantage, such as losing health before the game is even active.<\/p>\n<\/div>\n\n\n\n

\n
\"\"
Figure 2 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Following creating the instruction, the next thing to work is creating an end game screen to which the player is greeted once they have collected the key and standing next to the exit. The end screen was designed similar to the instruction screen but required to say something different to the player. While I could easily write a simple congratulations message of them completing the game, I went further toward asking other questions of what the player could do differently when they next play the game again. These questions include whether you could win the game as quickly as possible, try to attempt to win without defeating a single enemy or try to achieve the highest score possible. These questions help to encourage the player to try the game again and does increase the replayability.<\/p>\n<\/div>\n\n\n\n

\n
\"\"
Figure 3 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n

To create the functions around the end game screen, I first get the foreground layer of a specific tile index I want the game to end at, and when the player is at that index, a function is run in the background. This function checks if the player is pressing the “Enter” key down and has collected the key within the level. If these statements are both true, the game will end to prevent movement, set the end screen to be visible for the player to read the text, remove the key UI, and finally set the key collected back to false. The code is written this way because if the game over is not set to true upon doing this function, this could cause a bug that allows the player to keep playing and cause further problems around the game. <\/p>\n\n\n\n

<\/div>\n\n\n\n
\n
\n
\"\"
Figure 4 (Self Generated.)<\/figcaption><\/figure><\/div>\n\n\n\n
\"\"
Figure 5 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n

Now that I have all the basic requirements met toward the brief and, importantly, having a shooting mechanic in the game, I decided to use the spare time I have remaining around the project but improving the mechanics around how the bullets travel and including new weapon types. First, I created an if statement section known as weapon switching, which set the type of firing mode the weapon is set to. The firing mode acts like the type of bullet the player will fire when they click on the mouse after setting their mode. For example, if the player pressed key 2 during the game, the code will run by setting the icons of the pistol and shotgun to be not visible and the smg icon to be visible. Along with this, the ammo text is changed to reflect the current counter of the amount of smg ammo the player is currently holding and then finally setting the firing mode to 2. The code function like this gives clear feedback on the currently selected weapon the player is using and later on expand the “fireBullet” function created in the previous blog. <\/p>\n\n\n\n

\n
\n
\"\"
Figure 6 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n

By creating the firing mode for the weapon, I can then explore expanding the “fireBullet” function by having many other else if statements in this function. Before creating the new statements around adding the new weapon types, I looked into improving the bullet travel of how far the bullet can go before it falls. I did this by setting a timeout at the end of the statement to set the gravity back to true after 750 milliseconds have passed. This works very well because it creates a great balance around preventing bullets from going off-screen from the player and preventing enemy death if the player were to fire their weapon repeatedly. To show how much the statement around the bullet has changed, two screenshots show the before of the additional weapon types and the after of them being implicated.<\/p>\n\n\n\n

\n
\n
\n
\n
\"\"
Figure 7 (Self Generated.)<\/figcaption><\/figure><\/div>\n\n\n\n
\"\"
Figure 8 (Self Generated.)<\/figcaption><\/figure><\/div>\n\n\n\n

With how I created the different weapon types for the player to use, I first added more to the if statement that checks if the firing is set to that specific, and if it is, it will run that part of the code. For example, if firing mode is set to 2 while the player has one or more smg ammo, they can fire that type of weapon. With the process of generating more bullets when the player fires the shotgun’s weapon, I created a for loop to repeat generating the bullet until the loop is completed. I adjusted the “bullet.Player.rotation” to have a “Math.Between” of specific numbers within this loop. This helps to achieve the spread effect of the shotgun of each of the bullets that are generated. To make the firing of the shot noticeable based on the weapon you are using, I adjusted the speed and the timer of when the bullet will travel and fall to take into consideration of balance. You can see the code of how both weapon types are created on the right. <\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\"\"
Figure 9 (Self Generated.)<\/figcaption><\/figure><\/div>\n\n\n\n
\"\"
Figure 10 (Self Generated.)<\/figcaption><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n

With this week development of the prototype done, I am pleased with precisely how the different weapon types turn out, and I was able to learn something out of how I am I could create future weapons if I were to go further with this. For example, I could make a long-range sniper rifle where the bullet travels very fast at a long distance before falling to the ground. This could create different strategies of weapons to use throughout the game and expand my knowledge of creating weapons in general for games that feature weapons. With the instruction and win condition made for the game, the game is at a playability state to where everything is ready for anyone to play.<\/p>\n\n\n\n

You play the finished version of the prototype by clicking HERE<\/a>.<\/p>\n\n\n\n

\"\"
Figure 11 (Self Generated.)<\/figcaption><\/figure><\/div>\n","protected":false},"excerpt":{"rendered":"

Welcome to Week 6 of my Development Diary. The focus of this week is to continue developing the prototype further by adding the features needed to meet the brief and exploring adding extra interaction to the game. As a reminder, the brief around the prototype is that I need to develop a game that features… Continue reading 2D Games Development Diary Week 6<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-109","post","type-post","status-publish","format-standard","hentry","category-uncategorised","entry"],"_links":{"self":[{"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=109"}],"version-history":[{"count":8,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/109\/revisions"}],"predecessor-version":[{"id":162,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/posts\/109\/revisions\/162"}],"wp:attachment":[{"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/stevenraven.nuacomputerscience.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}