developing-stress-blog

[developing-stress-blog]

The last development push I could fesably do - SSA Devlog 13.5

The biggest achievement I managed to accomplish was developing my biggest working script to date, using array functionality in order to reference multiple different objects, going on from my work on the menu. After it had saved the weapon decisons of the player, in order to select from these two different weapons,  The scripts applied to the functionality of of the object must only be turned on when the specified button is pressed.

I also updated the script on week 14 in order to apply finally apply materials to the

However I couldn’t get my game in a ‘playable’ state, I did get a friend to test it in the state it was in, while explaining the situation, and the ideas I managed to convey still struck rather positively with them, dispite it not being a completely playable experience.

My first thought fot this was my lack of knowledge with prefab objects, so I tried to wrap my head around them, and for the most part it worked. My main problem is that I didnt understand arrays, and that, like in my previous script, it is better to reference each instance of an array, rather than the one big array parent for creating an instance.

While this was good for practicing my workflow, this didnt solve my issue. When respawning, no matter what, a ‘rigid’ projectile would always be selected, I have an understanding as to why this might be the case though.

This is how my two projectile types are setup, one os a trigger, and the other is not, I seperated them like this because the trigger object would affect the powers which needed to have contack with the floor. the rigid, or non-trigger projectile type would control the powers that did not need the use of the stage’s floor tiles. 

The problem came when trying to switch between the two projectile types. I set up this script so that: When the rigid projectiles were selected, the normal projectiles would be stored (under swap) while the main game objects would be replaced by the alt objects. This same function would occur if the player wanted to switch their ammo type back for a different power. The bottom screen is the result, turning all of my ammo into the rigid type. My theory is below.

Unfortunately it was too late to make any final adjustments when I had realised, as I had given the PS4 controller back to my friend. If I was to redo this project with my new-found knowledge I think I would have just turned the triggers on/off to direct my powers.

[developing-stress-blog]

Controlling two players’ scripts - SSA Devlog 11.5

The most frustrasting part of the entire project was realising just how much work I’d have to put in to adding another controller, especially one that wasn’t for the same console. I started off by adding the relevant new input values, making sure they had a 2 to distinguish them. I also had to make sure that the ‘Joy Num’ for each of these actions was set to Joystick 2.

If you search the number 2 into the search bar of my project, you’ll see that I had to recreate 13 scripts in order for the functionality to work with the seperate controllers.

An example of what one of these ‘2′ scripts, in compariison to it’s original will see that it is the exact same script, but each of my values had a ‘2′ at the end of it. It asn’t hard making these scripts. I mostly copy-pasted them and added the all important 2 to each part. It was the testing and figuring out which scripts needed to be recreated or not. It was immediately disheartening when realising the character would start off with absolutely no functionality again.

Some scripts referenced objects that affected both characters, like the cube at the bottom of the stage, which is meant to kill upon any player making contact. I also had to figure out how to rewrite these scripts aswell

Here are some of my favourite issues I faced this week

When one player selected their weapon, this also selected the other character’s weapon, it registered the weapon selection on both characters, and what’s better is that they could also cancel out one another’s weapon choice.

Only one player could projecty their ammo at any given time, which was great for testing out if weapons were working.

The most agregious by far (that I could not solve on my own) was this incredibly odd character rotation, caused by Unity’s First Person Character Controller. I’m not posting the solutions to these problems, as I admit I had no idea what caused them. This required a tutors help to set right.

How complicated the solutions could be:

So to set up my discreet death menu, I decided to create some UI buttons in Photoshop, to show that at least a player knows that they have registered their selection.

However, when I pressed Square on the PS4 controller, it came up with the Xbox X button, peculiar

What’s even more strange, is that this exact same thing occured when I was out of the nemu, pressing on the Xbox’s A button, which was not registered in the death screen script.

It seems like, for me, the Joy Num function wasn’t working properly, and I had to type out Joystick 1 and 2 in the button function. It didn’t help that I’d accidentaslly switched around the sprites of the Xbox and PS4 controls.

I needed a break after this week to work on other projects

[developing-stress-blog]

Death and it’s associated code - SSA Devlog week 10.5

I then had to create the opposite reaction, dying, letting the menu and cameras set up upon death, Based on two different values, one for being hit with a regular projectile, and one by being hit with ‘Snowball Effect’ I created as health float. 

And when that float reached 0 (or less) then the bool Ded would occur to that player.

The next script is the setup of the camera and UI, but also, I used it to reset the characters life back to 1. I also tried to set up my score function here, by creating a UI int number, howeverm it went up once per frame, which was rather distracting.

I used this float to determin the length of a lift bar, which I placed over a character’s head, so that inly the enemy could see it. Setting this to 0 made the death screen magically appear.

Now that I could damage the player I decided to have a little fun with my Firewall, using the trigger to damage a player who dares step into it

And it works, great stuff.

[developing-stress-blog]

Menu madness - SSA Devlog week 9.5

The first person projectile ended up being a multi-layered object starting with the initial sphere used to represent the player’s weapon. This sphere wouldn’t simply just be projected. In order to uphold the seven ammo mechanic, the easiest way I thought to tackle this issue would be to make seven seperate projectable spheres seperate from the weapon.

The below script shows how I would use one of these as, essentially a part of the weapon UI, this would not have anyu other function than to render or not to give the illusion that the ammo in your hands was the one being projected, when in fact, each of the other spheres had thrust attached to tham, and would activte once they were active

And when it came into contack with a trigger, far off the screen, that game object would be destroyed

I made a little diagram of how this works, this also highlights how the cycle is not quite complete yet, as this should ideally continue a suitable amount of ammo has been destroyed.

But what I’ve mad so far, really does work well, attaching my turret’s ammunition to the player camera helped get the exact look and feel I wanted

However, more pressing matters were at hand, how could I even get this far, without baing able to select my weapon. I decided to leave in the buttons for powers that weren’t active, as this amount of buttons lead to clean looking UI. The red text buttons could just lead to regular ammo or something, it doesn’t matter too much.

I also made the set up two overhead cameras, in the exact same position for each of the players.

The way my menu is was set up, it used the sensitivity of the the analog sticks to determine where the cursor would highlight, that means, if you pushed the stick all the way down, it would reach the bottom of the menu, the same can be said for the vertical axis aswell, but this was achieved in increments of .25 and -.25

And this is it in action.

In order to be choose the selected powers, I used the X and Y buttons to register X values of the powers, and Y values. which would be saved by the game as bool selections. If the X and Y buttons were both pressed, the player would revive, taking away the menu and camera, and placing their character back into the game.

[developing-stress-blog]

Powerful scripts; what went well? - SSA Devlog week 8.5

If this was to work, it would mean I would have to create a hazard for every single small tile, as the reaction when the projectile hits the floor would cause just one particular instance of that object to appear, so I did just that, starting with the Firewall power.

This power didn’t really achieve anything yet, it’s just a placeholder, made up of three blocks that make up the wall, with a box trigger added to the inside, to detect various things- this will be iterated upon, but the more important thing at that moment was to replicate it for each tile.

So, than I had to create the script that allowed the spawning of these objects to occur

This is one of the various ‘Spawn...’ scripts in action, a key component in determining where a trap will be set (This is applied to one of the tiles, and a sphere which has both a rigidbody and a trigger collider set to it).

The relevance to the Firewall object comes in the form of the ‘Public GameObject’ text at the top, wich creates a menu that allows me to select which object appears when this particular tile hits. This is important bacause I wanted to use this script on many objects, referencing different Firewalls for each one. The same works for each and every other Spawn script, which refers to each of the stage affecting powers.

The powers themselves.. are placeholders at this stage (insert regret)

In order to achieve the full potential of these powers, I would first need a life bar/system in order to take away health and cause the player to die, however I was not confident enough to attempt it during this stage of development, so I got to work on designing the player interaction for these powers instead, which was still a lot of work. 

The next power was ‘Rain of Terror’, a power that involves a player placing an icicle on the ceiling, to fall when a player is exactly underneath it. However, it would require them to look up at the ceiling to check the area they must avoid, to distract the player.

Setting up the correct size of the stage’s walls was a big component in this design.

However, the conspicous icicle effect really came together then I realised you could turn an object’s shadow off.

As for the squares on the ground, I decided to make a roof object highlighting where the smaller tiles would be located, as this would make dodging the icicles more fair, but, also, it would help show where a player could aim their projectile.

One other thing the icicle would need to do was fall onto the player when they were located underneath them.

This trigger collider underneath the Icicle would detect whether the player was underneath it or not (Which was carried out by a tag).

And this float number laballed Fallspeed would determin how fast it would travel to the player. 

The Environmental Shields were up next, which requires a surprising amount of thought. It started off with a copy paste of the walls that made up my level, (I tried making other walls, but the player would walk straight through them for some reason) but I realise it would be a lot more interesting if, instead of one wall being assigned to a tile, two tiles would make up specific corners. This could lead to creative play styles, like sectioning off areas creating barrier, or designing a maze for the an opponent to navigate in a short number of shots.

(This for example would only take 3 shots with the method below)

The melting power is a little bit different, as this comes on the form of just a script that is attached to a projectile, in a way similar to the spawn script. so it’s pretty self explanatory how this works

Note: The fact that it destroys the object completely rather than just turns off the mesh renderer isn’t ideal, but it still works as intended.

This also lead me to come up with another stage idea, a lower floor that players who has fallen off the stage could potentially land on if a tile had been destroyed.

I also created a little turret object, in order to test how the powers would affect the player, I used this sphere to shoot directly at my player character. Well, if I could get it to, that is.

Nothing was wrong with my script, I just made some incredibly inept mistakes, that I’m glad I managed to learn form.

Like not setting the thrust value up from 1

And tthis one was the wrong direction

I did eventually figure it out though.

[developing-stress-blog]

Control over the project - SSA Devlog week 7.5

Part 1 - A change of control

I decided to scrap any work regarding keyboard related inputs to focus on transferring my knowledge straight to the gamepad. In my case this was an Xbox 360 controller, and wrapping my head around how this works was a little tricky for a first time user of this feature.

I decided to get myself ahold of another movemnet script, this time from unity itself, as part of their ‘Standard assets’ package. https://assetstore.unity.com/packages/essentials/asset-packs/standard-assets-for-unity-2017-3-32351

This didnt work immediately with the controller, in order for this script to be controller compatible, I had to get rid of the existing input options, making the game unplayable through method for a short while, which took me out of my comfort zone.

I had to find particular references in the script to completely reconfigure the game’s control scheme.

The dead zone refers to a how far a control stick should eb moved from the middle in order to register an action, and the sensitivity controls how much effort it takes to increase the value of movement. Movement in unity’s case is a float numberregarding how much pressure is put on a particular direction of the control stick. Also of note, the Axis menu shows which direction the pressure must be applied to to give out an action, and the Joy Num category is for the use of multiple joysticks.

The Vertical, Mouse X and Mouse Y Axes have the same values, apart form the Axis for Vertical and Mouse Y being set to the Y axis.

Part 2 - Setting the stage

The arena itself was a surprising design challenge, as I had to think about how the entire game would function, a basis for this was Overwatch, one of the biggest games in the hero shooter genre. One thing I wanted to replicate was it’s use of player controlled stage hazards.

For me, the stage was vital in achieving this effect from a beginners standpoint. My idea was a stage that had a floor made up of tiles, if a projectile hits one of these floor tiles, then the desired trap would be placed in the location of that tile. So I went to work on creating this stage.

(On the left, a view of what the player would be able to see, on the right an Xray view (using transparent materials) showing what lays underneath the floor)

My idea was that projectiles would be able to pass through the first layer of larger tiles, while the smaller tiles register whether they have been hit with the projectile or not.

[developing-stress-blog]

The scripts that made up my keyboard prototype - SSA Devlog 6.5

Making a first person character or two

In order to create my local multiplayer experience I would have to create two seperate characters, each of these characters would have to be able to move the position of their ‘body’ and rotation of their ‘head’. This seemed rather complicated for me to achieve at this stage, so I went to look for a project that would provide a useful jumping off basis.

I couldn’t find a local multiplayer or couch co-op first person shooters (I would later find out why) But I did manage to track a regular fps project, with a script that I would modify for blocking out a character https://github.com/RyanFleck/Unity-GoldenDie/tree/master/Assets/Scripts

Just taking the script meant that I needed to create a couple of characters by myself. In doing so, I took a capulse from unity, attached a camera and a cube in order to simulate a first person perspective

Creating the look of a split screen multiplayer game was relatively easy, it involved a copy, paste of the initial character object, as there were two cameras in the scene, all I needed to do was change the ‘viewport rect’ of each camera so that it only filled half the screen each.

The more complicated issue would be the script that I would use on these characters, though it didn’t start out complicated. One of the two goals for my script was relatively easy to accomplish, as the movement part of the scipt worked very well indeed.

The original script is on the right, in order to move around my second character, I changed the inputs to number pad keys, whis is why they are not shown on the keyboard in the above gif.

Moving the camera on the other hand would provide a much harder challenge.

(This was caused by attaching the script to the capsule (with a rigidbody component) and holding down the right mouse button)

I did improve upon this when attaching the script to a one of the cameras, and made the capsule a child to the camera.

(This time, the camera is rotating on ther vertical axis when I hold down the right mouse button, this could make for an interesting simulation of a 90′s fps camera, but this is not what would suffice for my project.)

But my success in getting the characters to move via different input finctions helped design the material changer, which took this same approach, but through a different source.

The tests I had accomplished this week had been a relative success, however, the biggest take away I got from this is that continuing with the keyboard would not be an option, as the second camera at the would require a seperate input in order to not replicate the first character’s actions. 

[developing-stress-blog]

Almost playable (Patching a broken product together) - SSA Devlog 14

(Originally recorded 8th December)

in a word: Rushed

Predictions: See week 13

What happened this week

There was too much work to do from other modules to get the game into a ‘playable’ state (after the first life of each player). The two issues preventing the game from being playable are the score update function, which refuses to update one player’s score component upon death, and the ever present issue of the ammo reset function. Unfortunately, for both issues, these fixes would not have taken long to solve, I was currently in the middle of fixing these issues, with one of the players already being able to update their score.

However the ideas behind the game, their mechanics and potential can still be showcased from each player’s first life. I couldn’t develop the game much this week before deadlines, so I thought a review of the whole process might be a more interesting last post.

Overall thoughts

While I am a little disappointed regarding the issues of Shoot-Shoot Arena’s buggy state at this stage of development, personally, my personal growth through this development process, from having a negligible amount of coding knowledge to almost creating a rather comprehensive prototype, is still rather impressive. For a good few weeks after deciding upon this project, I was heavily considering to scrap my work and develop a prototype that was more within my comfort zone, as it seemed an impossible feat.

The trade-off in this more complex prototype lead to a better understanding of unity coding languages, a myriad of unique selling points, a potential solution to design challenges within the genre and an independent game project I can proudly call my best thus far.

What went well

Dependence on myself to transfer skills between different mediums has increased dramatically. My ability in regards to researching the answers for the vast majority of complex barriers has been tested, and has been a standout aspect in this project.

The design challenges in particular I feel have been carried out really well. Imaginative solutions to a relatively new sub-genre of multiplayer FPS games have both iterated on inspirations while developing completely unique game play opportunities.

Learning experiences

Forethought regarding potential challenges, whether it be controller options or bugs should be accounted for when proposing achievable set goals 

Talking about controller options, given the opportunity to work with game pads, issues regarding repeat work for different input options will definitely be mitigated in the future

The inability to reward myself with even constant breaks has lead to some anxiety inducing moments, the stress of creating this game caused a week of burnout, and illnesses to pursue longer than they otherwise could of. This was the main cause of rampant solutions in the initial development phase.

[developing-stress-blog]

What remains of the undying bugs? - SSA Devlog 13

(Originally recorded 1st December)

In a word: Unsure

Predictions: There is no time for predictions, just got to finish what I can

Things that happened this week

My main issues this week involved fixing the bugs that made the game unplayable. The issues be broken down into two categories; bugs caused by broken mechanics (mostly surrounding the framework), and bugs caused by multiplayer implementation.

The deadline was fast approaching, and many many issues still lay rampant, some of which were caused while trying to fix others, and took a lot of effort to figure out the source to each and every step of these stacked problems. This again was something I had relatively little experience dealing with, and my amateurish ways dealing with these problems didn’t help.

- My discreet ‘death menu’ now showed input buttons, after creating some sprites in Photoshop. These are the only objects in the game that were developed outside of Unity 

The UI input buttons also caused a myriad of problems, caused by incompetent organisation or input values suddenly requiring more information.

- Learning how to write scripts that involve the use of prefab objects was also a huge learning curve this week. First of all, it required that I understand how to make objects appear from my files, and then how to control versions of those objects that don’t exist yet. 

On top of this, I was also concentrating on my other modules as well, trying to juggle this work, along with the stress of approaching deadlines, this had middling results.

What went well

The menu is now functioning properly, no issues with when selecting one’s powers

[developing-stress-blog]

Two controllers are harder than one - SSA Devlog week 11

(Originally recorded 17th November 2019)

In a word - Overwhelming

Predictions:

My predictions were becoming more erratic, juggling other schedules, along with the unexpected bugs and development troubles. By the end of this week I had to take a week off, things were becoming a little too stressful.

So what happened this week

- I borrowed a friend’s controller, a PS4 controller.                                                Up until this point, I had been using an Xbox 360 gamepad. This meant, in order for the game to function with two controllers, not only did I have to create secondary variables to each script and its components, but also map these to different buttons and axes.

This made up the entirety of the week, it may not seem like much, but everything had to be recreated in some form or another, some scripts had to be changed twice in order to fit the specifications of both controllers. Testing what incremental problem required an overhaul of code, finding every single bug in the game. As a designer, this was not satisfying..

Mechanics had to change on the fly in order to get the game to work, some issues became too much for me to handle, but were resolved when tutors helped debug.

Things were breaking with this added controller, like the power selections, which enabled/disabled based on an opponent’s input. An odd bug involved the player spinning on the wrong axis 

- On the plus side, I did get to play test this multiplayer game with someone else at long last, which resulted in some rather useful feedback such as: 

Changing the colour of the death menu to represent a weapon’s type

Add some animations to show that a weapon is reloading 

Change the movement speed

Add something to show off the hazards in the environment a little more (which would be lighting)

[developing-stress-blog]

Linking things together - SSA Devlog week 10

(Originally recorded 10th November)

In a word: Discovering

Predictions: Get input on week 11 - whether ‘playable’ or not

Things that happened this week

- Work was started on assigning the press of a button to the relevant highlighted power it was associated with. About 75% of my desired results were achieved this week, as any non rigidbody components seemed to comply with my scripts, while selecting the remaining projectile types would result in an inability to change through the selected choices. 

- Making sure the player could die was also essential to the framework of Shoot-Shoot Arena. Applying float values to both the projectiles and the players’ health bar would allow the comparison of these two values to determine whether the player had died (this was originally just a bool value).

- Connecting the ‘death screen’ to the death of a character was a success in that regard, but multiple deaths caused very strange issues to occur that I had not forethought, here’s a list of them: 

The game would would continue to register the same powers between multiple lives.

The screen would either skip the menu entirely, or not let the player progress through it.

Upon entering another life, the player could not let its health reach zero or under, therefore, they would be unable to die.

I managed to fix the underlined problems, however they are still relevant to discuss here, as all three problems would arise again the very next week.

What went well

Discovering that a project is a buggy mess is never fun, but it cannot be avoided. Despite this, it did not deter me like other overwhelming problems in this project, this may very well be due to the deadline getting ever closer. What’s more impressive is that I managed to get destroy a few of the worst ones thus far.

Learning to get scripts to call functions from one another, a problem I ran into when designing the prototype game from week 2 had now been discovered. I now had far more control over the functions of my scripts.

[developing-stress-blog]

Contempt through control - SSA Devlog week 7

The keyboard blocking out carried its way into the first half of this week, before realizing that I would have to change everything in order for it to work on a controller.

(Originally recorded 20th October 2019)

In a word: Relearning

Predictions: There is no way I’ll get this playable by week 8

Things that happened this week

- Looked at unity’s virtual axes, got confused how use them

- Realized I needed to change my character movement script in order for the movement to work, modifying unity’s first person character movement script did the job

- Playing around with the controller input, I decided to implement some of the different weapons into the game. In my approach to this I categorized the weapons based on how they were going to be implemented.

Each weapon is a sphere (for this 14 week long prototype), this sphere can either interact with the level, interacts with a character, or be turned on when a projectile hits a character. 

Going from week 7 to week 8, I started messing about with the level affected powers, which required the weapon projectile to become a trigger. This trigger would detect which area in the floor was hit, in order to place something in that area, be it a shield to block an opponent’s path, an object overhead that players need to be wary of.

In reality, most of the development of these powers occurred the next week, as it took me a little while to wrap my head around the controller inputs, especially the axis required for the trigger button.

What went well

It was time to face the biggest challenge in this module for me, creating an entirely original script, working in tangent with trigger boxes. While this is far from usable at this stage, practicing and developing these skills made me more confident in this alien approach to game development.

My approach to powers in terms of their creation process made it very easy to calculate the effort required to implement them into the game.

(not in original text) Dedicating the majority of the week to learning the ins and outs of unity’s controller input methodology was not a regrettable decision, knowing how the individual axis worked now only helped in the development of the movement script, but each individual power script as well as navigating the ‘death screen’ menu.

Learning experiences

Pursuing difficulties is also hard for me, sometimes when problems look overwhelming, it can take a while for me to come to a logical conclusion in how to tackle them, making me put off this process. In order to achieve a better workflow, I will have to learn to overcome this fear of the unknown.

[developing-stress-blog]

The game framework - SSA Devlog week 9

The powers were now developed, but the framework of the game was neglected up until this point. I could make walls appear, and provide damage increases, yet the player could not do the fundamentals like reload or choose their own powers. Designing my game this way round may have been the single biggest learning experience for me.

(Originally recorded 3rd November 2019)

In a word: Annoying

Predictions: Playable by week 11

Things that happened this week

- A lot of my time was spent creating a menu, one that the player could discreetly pick options from, this would also be attached to a button input for selection as and when a player needs

- I tried to figure out all of the functions on that death screen: 

Screen shows up                                                                                                    Overhead camera will activate                                                                                Opposing player will score point                                                                             Player will be recommended powers                                                                    Player will select 2 options, a power signed to a button                                      These powers, and their associated button will be remembered                          Once both buttons are pressed, screen will go away

While I spent a lot of time on the menu, it did function, mostly. By the end of the week, everything not crossed out managed to work.                                          The opposing player did score a point, but once per frame.                              The recommended powers were scrapped, as funneling players into a play style would result in less experimentation.                                                                      And, while the game would remember what buttons were pressed in the menu, I had attempted to link these to an animator and power, none of these functioned.

- The projection of a player’s projectile was now up and running. This meant that the button required to shoot had changed, and the ammunition followed the camera, this did lead to the projectile shooting off in opposing directions until a ‘detach’ script was made

I also tried to create a prefab for reloading one’s ammo upon re-spawning, without knowing exactly how to create a prefab, this resulted in this function also not working

What went well

My work regarding the projectile was made easy due to the constant testing of this feature throughout the project, if I took the same approach to other aspects of my project, I may not have had such difficulty developing.

Shifting my focus onto the framework arguably could have come at an earlier time, probably earlier than the more exciting job of designing and prototyping the various character powers; however, realizing my mistake and focusing my efforts to now fix a crucial part of the game is good practice for future projects.

The menu has a very clear layout, it doesn’t get in the way of the main game play experience and isn’t too intrusive to use, this is a very good thing indeed.

Learning experiences 

The importance of this menu, in my mind, was very secondary up until now, this screen allows players to select and register their saved powers, which turns out is one of the post important functions of the entire game. Thinking about these ‘less fun’ aspects of design and assigning their importance beforehand would not have lead to the biggest mismanagement decision in the entire project.

[developing-stress-blog]

Developing through constraints - SSA Devlog week 8

Week 8 came faster than I had anticipated, I only just started developing the game’s powers, and there was still so much to do. This project was far larger in scope than I had anticipated, especially while still learning the fundamentals of coding.

I’m becoming wary about planning for the future, but I realized if I continued progressing at this rate, the game should hopefully be in a playable state by week 11.

(Originally recorded 27th October 2019)

In a word: Addictive

Predictions: Playable by week 11

Things that happened this week

- After creating the stage affecting powers, I tried developing the other powers, starting with the player affected powers, there are a small amount of these in the game, which change the damage statistics to a weapon, makes projectiles bounce across the stage and provides a personal shield to the player.

The development of these three powers, while fundamentally different to one another, and to my previously established workflow, ended up being by far the easiest of the powers to implement thus far. However, the same cannot be said for the rest of the powers.

Some of my prospects for these powers seemed to be a little ambitious given the time constraints and my knowledge of the subject. I quickly abandoned these powers, thinking of ways to balance the existing powers. Though I ended up opting for creating them first, and once playable, seeing how each one would stack against one another. This would help find any particular play-style with the combination of power-ups that will need to be balanced.

- Also this week, I managed to get my turret to shoot its projectiles at a forceful speed towards the player. I used this to test the ‘snowball effect’ power, which was meant to come at the player at a noticeably slower speed (though I decided to change this due to the recent re-balancing of the powers).

What went well

The various ‘spawn’ scripts were completed, consisting of the action in which a projectile makes contact with a particular floor tile, this was my workaround for ‘get transform’, an action I was used to carrying out in visual scripting programs. Learning these differences is always helpful in understanding the vocabulary and context of the programming language.

Learning how to cut and scale down a project was also a new learning curve for me. And while, on paper, having less features makes for less of a feature-rich experience; it cannot be understated how useful adaptation is within any project.

Learning experiences

Hitting deadlines is a skill that I really need to work on, it seems I am not good at judging how long development takes. Due to my projects being mostly personal, which in turn having no allotted time frame, and being an absolute amateur when it comes to hard coding, the initial prediction did not account for this, or the countless hours of bug fixing.

[developing-stress-blog]

The categories: More detailed gameplay ideas - SSA Devlog 6

The game now has a title, as I have opened the editor for the first time on my main project, now it shall be known as: Shoot-shoot arena.

(Originally recorded 13th October 2019)

In a word: Structured(?)

Predictions: Playable at week 8

Things that happened this week

- A brain dump, focusing on a plan for the upcoming weeks, this can be seen here: https://drive.google.com/open?id=1zrKB7XrKjoDZ_ZIzxc8mV5A-71YFimxUTW26Y5kBsj4

- The majority of the week was spent creating a document showing the powers that would work for the game, how they balance against one another, and solving the category problem from last week. https://docs.google.com/document/d/1AQr9kDhn5Y5anVoLcXkhBVMAZiruDosqTejC1VE2-24/edit?usp=sharing (This document keeps updating, the information is not the same as it was on the original blog recording date)

- Blocking out occurred. I tested out my initial ideas using keyboard inputs. This includes: Changing ammo color (on input and category), creating a health bar, implementing a first person character controller, split screen cameras, and an overhead camera for each player.

- I also took a simple character move script from the web in order to tweak movement options such as speed and look speed, to see what felt satisfying

What went well

After finally overcoming the flu completely work was now being completed at a steady pace.

The major hurdle of learning to write complex scripts had a jumping off point, involving taking a relevant script off the internet and making modifications to fit a desired function.

Blocking out these ideas helped realise the potential for this game in its entirety, giving myself a visual indication for ideas in the future.

The powers each sound unique enough to warrant being in the game, and creating each one with the set mind to counteract another made this process far easier than it otherwise could have been.

Learning experiences

(Not from original text) Balancing out the powers in such a rudimentary way would lead to many problems within balancing, as certain powers could not be implemented due to their complexity.

(Not from original text) Using the desired control scheme within prototyping, while sounding like a daunting prospect, would have been a huge help to the management of the project, going back to change the mistakes from this week was one of the hardest challenges in the entire design process of the game.

Bad organisational workflow methods have made their way into my project due to working on too many things at once. Going headfirst into this week and diving aimlessly into the blocking out of the project, I managed to confuse the character hierarchies and abandon work regarding my first character setup.

[developing-stress-blog]

Gameplay ideas - SSA Devlog 5

(Originally recorded 6th October 2019)

In a word: Planning 

Predictions: Playable at week 8

Things that happened this week

How do you make a hero shooter for two players, on the same screen?

What makes a hero shooter: Unique situational powerups, constant change, asymmetrical multiplayer. Focusing on these three design philosophies would be key.

But this week was all about one key aspect of the design; fairness on the same screen, and the avoidance of ‘screen cheating’. A fundamental problem in split screen multiplayer games where someone can attain discreet information by looking at the opponent’s game section.

Ideas to tackle this - 

The health bars can only be seen on the opposite screen:                        Knowing one’s health is not necessarily important to the player, as they will try and avoid damage regardless, however, it is important to an attacker, as they can plan their actions based on their prey’s health. This also encourages planning more than action based gameplay.

A death screen with an overhead camera, showing the opposing player’s position:                                                                                                             This should give those constantly dying a way to plan out a way to make the score even. Along with this, the death screen could also give players recommendations on the best weapons to counteract their opponent.

Weapon obscurity:                                                                                        Similar in a way to the effects of a health bar. Currently in hero shooters, the weapons are shown to players in an obvious format; a character model. However this is designed so that multiple a team of players can see their enemy clearly. For a two player game, this could hinder the experience, trivializing certain play styles.                                                                                                  My ideas to combat this problem are-                                                          Making weapons less obvious through categorization (Eg; this weapon is a slow, powerful weapon, but it is not obvious which slow powerful, weapon it is).            And making the weapon selection screen more personal and secretive. What if a player could select a weapon without the other person knowing, with a menu that doesn’t highlight selections.

A player could also give a point to the opponent to change up their weapon at any time they want.

What went well

Each of these ideas helped the development process of the game's fairness, and conjured up interesting solutions to the various problems a player would fesably have.

Going on from the concepts highlighted here, many more ideas helped shape the identity of the game, bringing with it a myriad of unique selling points.

Learning experiences

Discussing these ideas with others could have helped highlight the challenges in their creation and a public opinion regarding these ideas. Doing this early on would help shape the experience towards the player from the start, leading to, what should be, a more satisfying experience.

[developing-stress-blog]

In bed, coming up with ideas - SSA Devlog 4

(Originally recorded 29th September 2019)

In a word: Reflection

Predictions: TBA

Things that happened this week

- Came up with three simple concepts for games

- For some reason, I liked the idea of developing a first person experience, this may have come from my game playing habits that week

- The ideas can be seen here: https://docs.google.com/document/d/157NBy7zbpU-qXkGF6OJ7uxkHvlMnxNX4mvOHYtbFNEw/edit?usp=sharing

- Idea 1 was scrapped, as it wasn’t very mechanics focused, instead just replicating an idea, with the main difference being graphics

- The last two ideas were based off common problems in first person games, designing for a genre that doesn’t usually accommodate for local multiplayer (the hero shooter) and first person platforming

- I ultimately chose the hero shooter idea, as there would be more experimentation and balancing opportunities.

What went well

The work I chose to do for this week was probably the best thing I could've done given the illness situation.

My ideas, while lacking in numbers, were comprehensible enough to expand upon.

Learning experiences

Mitigating stress was going to be a large hurdle in the development process going forwards. Even in this early stage, missing out on tutorials and lectures, I felt annoyed at myself, that I would be behind and unable to catch up. It may have been better to rest this week, I could've come up with more, better ideas the following week and achieve a suitable amount of rest. Coming into class the next week would be hard.