re1601127

[re1601127]

Prototype - 01/07/2019

I have finally managed to add enemy movement into the prototype in a way which is satisfactory for the prototype. This was done using a NavMesh and a NavmeshAgent within the enemy Prefabs. 

As can be seen, I have made it so that for some enemies, they walk towards you when you are within a certain radius from them. For others such as the enemies on the walls, they look at you all the time but do not follow you. 

As the deadline is so near, instead of trying to add any more features, I will instead work on the final postmortem.

Takeaways from this assignment -Iteration is incredibly important -Prototyping is important too before moving onto the final production

[re1601127]

Prototype - 28/06/2019

Here is the progress made on the 28th of June. However, the video was taken on the 29th. One of the improvements I made after testing was the way movement worked in both modes (i.e. the “aiming” and “moving” mode) Now, in the aiming mode, the player can only turn 90 degrees either horizontally and vertically, this is to make aiming easier while at the same time ensuring that the player has to switch between the two modes in order to complete the level. Furthermore, while aiming the player can only move forward and backwards but not side to side. Without this restriction, the player would be able to search the entire level in aim mode. Another addition is the implementation of part of the combat mechanic; now the player is able to slow down the enemy when the enemies legs are hit (represented by the lower capsule). On that note, I changed the capsule sizes in order to better mimic the reaction to models with more anatomically accurate shapes and hitboxes. However, enemies still need to be sorted; they currently walk away from the player and the can still hurt each other. Hopefully, this will be sorted today.

[re1601127]

Prototype Progress - 26/06/2019

This is the progress of the prototype as of today. As can be seen, in order to test the mechanic so far I chose to put the play in three different sized environments. This is in order to test how the mechanic could be used. In the smallest environment, the enemy is still; this is to allow the player to get a basic idea of the controls for the purposes of this prototype.

In the middle environment, the player gets introduced to moving enemies. Although it has not been implemented yet, the enemies in this prototype will be able to damage the player too. Although it appears that at the moment there is a bug causing the enemies to damage each other if they touch. I want to sort this in time for the next show of the prototype.

In the largest environment, the player is introduced to elevated enemies. This is to demonstrate to the player the aim part of the mechanic; they just need to press L-trigger to look through the eyes of their character, this will allow them to aim at enemies higher or lower than them. While previously I considered having the player flip if they pressed straight up on the right analogue stick, I found that it made aiming even more difficult and thus removed it.   

[re1601127]

Construction: Player PoV - 25/06/2019

Above: The view the player gets while they’re not aiming.

Above: The view the player gets while they’re aiming.

[re1601127]

Construction: Enemy Health  - 25/06/2019

Now that the input and response have been considered, I have started building the prototype in Unity.  In the image above, the player is the cube on the left and the enemy is the object on the right.

Above: The enemy at full health.

Above: The enemy after one hit to the head. (The top cylinder)

Above: The enemy after one hit to the torso. (The middle cylinder)

Above: The enemy after one hit to the legs(the bottom cylinder)

[re1601127]

Discussion of Context - 24/06/2019

Since this mechanic is for a “beat-em-up” style game, a wide open space would be normal to expect, however, due to this mechanic focusing on ranged weapons, for the prototype, I suspect I’ll focus on things that force the player to use their ranged weapon- mostly enemies but maybe distance switches. For the purpose of this prototype, I’ll say “bow-and-arrow” from here on as that is what the prototype will be using. For the purpose of the prototype and playtesting, I will experiment with various sizes; smaller to bigger, see which one the player prefers the best.

[re1601127]

Discussion of Response - 24/06/2019

Now that I’ve looked at what each action should be assigned to each control, I should look at how the game will interact with the inputs.

Fire

Although I have mapped this action to an analogue button essentially - I feel that the situation requires the response to be as binary as possible. That is, the projectile gets fired the moment the player presses down fully on the button. However, I feel that this would be for the benefit of the game for one reason; it provides a satisfying feeling when the player slams down on the trigger and watches the projectile fly.

Aim Toggle

Like the “fire” action, I feel like the response for this action should be instant too. However, unlike the reaction to fire, the aim action would be held as long as the player holds down the Left-Trigger. This is to allow for fluid movement between the two states: the aiming and not aiming state. 

Aim Move Out of the three actions for this mechanic, this would be the only one to actively make use of the analogue input provided by the input method.

While in the x-direction the input would be relatively raw as it would break the gameplay for the player to move in a full circle. If the camera flipped then the player would be taken out of the experience.... however, if a reason or purpose was given to the player for a “flip” then that might help.  Therefore, the player would be restricted as presented below.

[re1601127]

Discussion of Input - 24/06/2019

Throughout the development of the prototype, the player's experience must be at the forethought of the design as, without that, a game has no chance of performing well. Therefore, for the prototype, I should consider the two types of controllers (methods of input) that I have to hand. Moreover, I shall attempt to do so using Steve Swink’s book “Game Feel” as a guideline. 

Micro-Level:

As this mechanic would not constitute the main aspect of the gameplay I feel like I should analyse what specific actions the user would need in order to determine what buttons the player should not need to press for the mechanic.  These actions would be:-

fire

aim toggle (switch between aiming and not aiming)

aim move(the actual aiming part of the mechanic)

note: for actions such as moving, let’s assume the classic controls (i.e. WASD for PC controls and the Left-analogue stick for the XBOX 360 controls)

Fire

For most games with a ranged weapon system, the Right-Trigger is used on an XBOX 360 controller to fire guns or bows and arrows. As this is almost an industry standard, I feel like that would best remain the same in the prototype. On the other hand, for PC games, the normal control that fires a weapon is usually either the Left-Mouse button or the spacebar. However, as I would like the player to be able to focus on moving and shooting at the same time, I will choose the Left-Mouse button as the default. This is with the expectation that should a player not like the control scheme then they would be able to freely change it to something they prefer. Another reason to use these two buttons in order to fire the weapon is that a player would generally use their index or middle fingers which are easily the most manoeuvrable and so the fastest for the player to mash no matter if they decide to use a melee weapon or ranged weapon. On that note, I feel like it would break the flow of the game if they (meleed-hit and ranged-hit) were mapped to different buttons depending on the weapon. Aim Move For most games, this kind of control is mapped to movement of the mouse and either the Left-Analogue stick or the Right-Analogue stick for PC and Console (in this case, XBOX 360) respectively. This is due to the sensitivity provided by both controls say over the D-pad of the Xbox controller; the D-pad only allows for On or Off controls vs the -1.0 to 1.0 range of the analogue sticks. For this reason, I too shall map this action to these buttons (either or, depending on which control scheme I chose in the end) Aim Toggle

For most games, this kind of control is mapped to Right-Mouse button and Left-Trigger for PC and Console (in this case, XBOX 360). This is due to the speed with which the player can press the button over say the Q button on the keyboard or the X button on the controller.

Macro-Level:

On the Macro-Level (i.e. how all the buttons feel together) I feel like the Xbox-Controller would work better with the game (and as a result the mechanic I wish to prototype) than the controls provided by the PC. While the PC, does provide a valid input system, I feel like there are almost too many inputs for a relatively simple game.  For this reason, I feel like the Xbox controller would work better for the Prototype.

Tactile-Level:

On the Tactile-Level (how the controllers actually feel), I feel like the Xbox-controller would be better than the mouse and keyboard. This is because the XBOX 360 controller is specifically designed to feel good to play with, unlike the keyboard and mouse.

[re1601127]

Expanded Pitch - 24/06/2019

I am thinking the mechanic would fit into a game much like that of Hyrule Warriors (a spin-off of Nintendo’s “The Legend of Zelda” franchise - in which the player has to defeat swarms of Enemies in order to complete the objective. However, I picture my mechanic fitting in a slightly slower version of the game; the player would still have to defeat swarms of enemies but instead of sticking mainly to melee weapons, I would like to focus on a ranged-weapon system.

One of the reasons I would like to develop such a mechanic is because in many games with “ranged” weapons that I have played ( many fps’s and fantasy games) I feel like you could switch out the ranged weapon with the melee weapon and the gameplay would not change a whole lot. In most games, a player could react to a whole lot of different scenarios with blind shooting. 

[re1601127]

Pitch - 22/06/2019

This game will feature a strategic combat system. The player has to choose between moving in order to avoid the enemies or standing still in order to attack the enemies weak spots. The enemies will spawn in a way which will balance the game so as not to be too easy or too difficult for the player. I would like to also create a rock-paper-scissors style system that would force the player to pay better attention to the enemy; that way the player is not simply attacking at random.