Conscious Grasp: A Port-Mortem

The following is a post-mortem on my game, Conscious Grasp. You can find the game here.

Conscious Grasp is a game made solely by me over a two week period. The game attempts to create a feeling of disorientation and being lost, eventually finalising with a sense of belonging.

The inspiration for this game came from the earliest memory that I have. The first thing I remember is opening my eyes in a park, facing the playground. The park was not familiar to me but, as I turned around, I saw my parent’s house. I don’t know how I knew that that was my parent’s house. I just knew. I walked from the park, across the road and into the house, all around the age of 3.

To try and evoke the feeling of disorientation that I had in the park, I created a map that has tiles added and removed through a script. This means that there is a form of randomisation. When a player moves a set amount in any direction, a row of three tiles will be spawned ahead of the player and a row of three tiles will be removed behind the player. This results in a map that is constantly changing, even when the player doubles back. You can read more about the programming behind it here.

I’m really happy with how the tile spawning system turned out. I started this project without too much programming knowledge, so I am glad that the system works as well as it does. The system uses a list of tiles and can be expanded just by making more tiles and adding them to the list. It has a lot of potential and, if I had more time, I would of have made more tiles in order to add more variety into the map.

If there is one thing to improve, it would be the fog that obscures vision. It’s purpose is to hide when tiles are spawned but visually, it looks very ‘hacked’ in. There is too much contrast in light between objects in the fog and objects out of the fog. If I had the time, I would remove the fog and the directional light then replace them with a spot light that looks in the same direction as the player. This would create a similar, view limiting, effect but would be less obvious than the fog.

 

Advertisements

Creating a Random Level Generator

For the first project of Studio 1, I created a random level generation tool. This tool relies on a collection of ’tiles’ and spawns three tiles perpendicular to the direction that the player is moving. It spawns tiles so that there are no gaps, regardless of which direction you move.

lvlgen.gif

This tool works by using a separate collider for each cardinal direction and a collider above, as can be seen in the image below.

DirectionColliders.png

The use of the four colliders is to run the following function:

TiggerCode.png

What this function does is it moves the Spawner, which is an empty in the middle of the colliders, to the next row of tiles. It then moves the Generator to the tile that the player has just moved to. The Generator is the parent of all of the colliders and the Spawner. This results in the Spawner being in the perfect place to put a tile.

The script then instantiates three tiles that are randomly taken from the TileDatabase, which I will mention later. It places one tile in the same position as the Spawner and then one on either side of the first tile. This makes a row of tiles that perfectly lines up with the previous tiles..

After spawning the tiles, the function then moves the Spawner back to the middle of the Generator and moves the Remover (the collider that sits above the others; also a child of Generator) to the row of tiles that are behind the player.Remover1.png

The Remover then runs the following function:RemoverCode.png

Since all the tiles are tagged as Land, the Remover destroys the tiles it touches.

Remover2.png

Then, the Remover is moved above the player so that it doesn’t accidentally touch any other tiles. Remover3.png

Now, the TileDatabase. This is a script that has references to all the tiles and puts all the tiles into a list (not the best way to do this, would be easier to just have the list and assign in the Inspector).

TileDb2.png

TileDb1.png

 

 

 

 

 

 

 

 

This script links to all of tiles in the game folder.

Tiles.png

So it is here that the Spawner pulls three tiles from.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Softskill Plans and Improvement

As Studio 1 began, I became focused on the work that presented to me. Throughout Project 1 I focused too heavily on creating art assets and throughout Project 2 I prioritised the completion of group work over personal work.

My problem was that I didn’t have any personal management. Whenever I had time free to work on something, I found that I spent a lot of time just figuring out what I needed to work on. I always knew what group work I had to do, thanks to Hack n Plan, but when it came to write Dev Diaries or report my work, I struggled.

To help remedy this, I created a personal Hack n Plan where I listed all of the work that I had left to do. Anything from Dev Diaries to Audio to Scripting were placed in the Hack n Plan. It was a valuable tool for organising my free time and making me far more effective at completing my work.

It allows me to track my remaining work and monitor my week-to-week work ethic. The time spent updating Hack n Plan is more than made up for by the amount of time I save when finding something I want to work on.

I also attempted to use a work calendar, along side Hack n Plan. I found it useful at the start but, once I had memorised the times that I had set aside to work, I found myself not using it very often. I found that I worked better when I kept Hack n Plan opening, using it as a visual reminder of all of the work I had to do.

I plan on using Hack n Plan as often as possible. As it is now, Hack n Plan has been a valuable tool in helping me finish all the work that I needed to do. Additionally, I believe that, once I am more familiar with Hack n Plan, I can gain the benefits of a work calendar from Hack n Plan as well.

Coding the Player

Project 1 was a solo project, so it was up to me to make or source everything. The most involved script that I had to write was my Player script. It controls player movement, player animation, player attack and more. I am going to go through exactly what my Player script does, as well as the scripts that it is dependant on.

First off, let’s go through the references and variables.

PlayerCode1.png In my references there are three that are assigned in the Start() function one that is assigned in the Inspector and another that is assigned later, in the Attack() function. Of the three that are assigned in Start(): the Rigidbody2D is used to move the player, the Animator is used to change which animations are applied to the player and the AudioManager is used to play audio. The bullet GameObject is used as a base in the Attack() function.

Next are the variables playerSpeed and playerHealth. The variable playerSpeed is a factor in how fast the player moves and playerHealth determines how much damage the player can take.

 

Now on to the functions that are called in FixedUpdate(). The first function called is Movement().

PlayerCode2.png

This function is a list of if, else if and else statements. If one of the first four statements is true, then the player moves in a direction dependant upon which key is press. Pressing W, A, S or D moves the character up, left, down or right. Each statement also determines whether or not the bool ‘Moving’ is true.PlayerAnimation.png

If the ‘Moving’ bool is true, then the character transitions from whatever state they are currently in to the ‘PlayerWalk’ state. When the character is in the ‘PlayerWalk’ state, the character sprite plays a looping 2 frame moving/walking animation.

 

The next function is the Attack() function.

PlayerCode3.png

This function only runs when the player clicks the left mouse button. When that happens, a Vector3 is made that contains the X,Y and Z coordinates of the mouse cursors current position. Then the Z coordinate of the Vector3 is reduced to 0 (since this game is 2D). After that, the Vector3 is changed from screen coordinates to game coordinates.

Now, a copy of the bullet that was previously referenced is spawned and assign to the bulletPrefab reference. The bulletPrefab is then rotated to face the mouse cursor. Then force is applied to the bulletPrefab’s rigidbody, making it travel toward the location that the player clicked.

As well as spawning and firing the bulletPrefab, a sound effect is played. You can read more about that in my pitch shifting audio blog.

Finally, after a two second timer, the bulletPrefab destroys itself.

 

The bullet has its own script as well. It detects if it collides with anything and, if so, tells them to take damage and then plays audio.

BulletScript.png

The Bullet script references and assigns the AudioManager, since it plays audio when it collides with certain objects. There is also a variable that determines how much damage the bullet does.

The OnCollisionEnter2D() function retrieves the tag of the object that it collides with. If it collides with an object tagged either Enemy or Enviro, it will tell them to take damage, play a sound effect and then destroy itself.

 

Now, back to the Player script.

PlayerCode4.png

Both the ApplyDamage() function and the Death() function are in all scripts that have the ability to take damage and be destroyed. When a variable named damage is sent to this function, it reduces playerHealth by an amount equal to damage. Then if the variable playerHealth is less than, or equal to, 0 the GameObject that this script is attached to is destroyed.

Pitch Shifting Audio

I have added further to Project 1. I decided to make three more sounds effects. There is now a sound effect for: an enemy getting hit with a bullet, firing a bullet and destroying the environment.

As usual, I opened Audacity and recorded three different tracks. If you would like more info on how I did this, you can check out my previous audio blog.

AudacityBulletRip.png

I then exported all of the tracks and named them Bullet, BulletHit and Rip. Then I moved the exported files into my Unity project.

The first thing to do was to add more public references to the AudioManager script. So now my script looks like this:

AudioManagerCode.png

Then I can just drag and drop the audio files that I have into the appropriate spot in the Inspector.

AudioInspector.png

Now for the interesting part. To make the audio change pitch when it play, all we need is one line of code.

PlayerCodePitchAudio.pngI put that one line of code in the Attack() function in the Player script, which might seem familiar if you have seen some of my other Project 1 blogs.

It is line 62 that does all the work. When the bullet shoots, it travels toward the mouse cursor and plays the ‘bullet’ sound effect at a pitch that ranges between 0.6 and 1.4 (with 1 being the original pitch). The pitch changes every time the player shoots a bullet.

However this setup has a flaw. Since all audio plays through audioManager.audio, every sound effect is going to play at the same pitch as the last bullet fired. There are two ways to solve this and one way takes much longer and requires more work than the other.

The more difficult option is to add an extra line of code to all scripts that play audio. In this case I have five other audio clips whose pitch I don’t want to change. This means that every time I use audioManager.audio.PlayOneShot() (the same function is on line 63 in the code above), I need to add the following code on the line above it:

AudioHardFix.png

This line will change the pitch back to 1 meaning that the next line, the line to play audio, will play at the normal pitch.

The easy fix is to add an extra AudioSource to the AudioManager GameObject. After doing so, the AudioManager code will also need to change to the following:AudioManagerEasyFix.png

The Start() function that found the AudioSource will not work anymore since there are two AudioSources. So instead, we remove the Start() function and add another public reference for the second AudioSource. Now we can just drag and drop the AudioSources in the Inspector.

Finally, lines 62 and 63 in the Player script change to:

PlayerAudioEasyFix.png

Instead of playing the audio through audioManager.audio, it now plays through the second AudioSource audioManager.bulletHit. Also, only the Pitch of the second AudioSource is change. This means that all audio played through the first one will not have a change in pitch.

Win/Lose Scripting – Scene Change With a Key Press

For Project 3, I implemented a ‘Lose Screen’ and a ‘Win Screen’. At first, it was just a Canvas with a white Panel spread across it with some text and a button that said ‘Restart’ in the centre. This really hindered gameplay however, since gameplay was limited to a joystick and a single button. The button meant that players would have to move a hand from either the joystick or the single button to the mouse and click the on-screen button, Then, from there, they would have to quickly move their hand back to where is was previously.

I decided to fix this problem by writing a script that reloads the current level, if you lose, or the next level, if you win, with the Space Bar, the single button that was used for gameplay. This process involved writing three scripts: one that detects when the player has lost, one that reloads the current scene and one that loads the next scene. The first script that was written was HitDetection.cs and it contains the following:

HitDetectionScript.png

In this script, lines 7 and 8 are are public references to the Win and the Lose Canvas’. This allows you to drag and drop the appropriate Canvas in the Inspector. The next line is a public reference to the PlayerController script (which contains all the code for how the player moves their character), however this is set in the Start() function instead of the Inspector.

The Start() function disables both the Win and Lose Canvas, then finds the PlayerController script that is attached to the GameObject tagged as PlayerBody. Disabling both Canvas’ is a crucial step because it stops them from appearing as soon as the game starts.

Finally, the OncollisionEnter2D() function. This function detects if the object that this script is attached to has collided with a GameObject tagged either Ground or EndZone. If it collides with the Ground, the LoseCanvas is enabled, however, if it collides with the EndZone, the WinCanvas is enabled instead. Either way the PlayerController script is disabled. This is because, when the player wins or loses, we want to stop them from being able to control the character afterwards.

Now to the LoseScreen script. It is a really small script that looks like this:

LoseScript.png

The Update() function in this script checks if the player presses the Space Bar and, if so, loads the active scene. Remember to include line 4 in any script that uses the SceneManager. Lines 1-3 are generated whenever you make a C# script in Unity, so you don’t need to worry about them, but line 4 is not.

The only difference between the LoseScreen script and the WinScreen script is line 11. Line 11 in the WinScreen script is this:

WinLoseChange.png

Instead of loading the active scene, this load the next scene. The next scene is determined by the order that the scenes are placed in File > Build Settings in Unity.

Writing A Film Script (Screenplay): What I Learned

For Project 2, each team was required to come up with their own scenario to a board game. This involved: making a unique set of rules that could be attached to a common set of rules that every scenario had, making crises that players had to solve which were specific to the scenario, and making film scripts to deliver to Film students. The Film students would later set up and record a professional actor to perform the scripts. These recordings would accompany the board game, to be played along side the crises.

In order to write a screenplay that would be presentable, I researched how to properly format and write a professional film script.

Screenplays are notorious for being finicky when it comes to their layout. Descriptive text must have a certain indent, while speech text must have an increased indent beyond that. In terms of layout, each page should follow these specifics:

  • Top Margin: 1 Inch
  • Bottom and Right (outside) Margin: 0.75-1.25 Inches
  • Left (inside) Margin: 1.5 Inches
  • Font: 12 point, Courier
  • Dialog Indent: 1.5 Inches, on both sides

Every page should follow these rules and the reason for this is because it will take one minute for each page to play out on-screen. This allows readers of the screenplay to accurately guess how long it would run for.

Beyond that, there are some specific terms, references and capitalisation that must be used in writing. For example, the first line of a screenplay should read ‘FADE IN:’, without the quotation marks, as this signifies that this page is the beginning of the screenplay. From there, scenes are split up by their location.

After ‘FADE IN:’ but before any other text, you must write a one line description of the location that the next scene is going to take place in. It must specify whether there is an INT. (interior) or EXT. (exterior) camera at the start of the description and, at the end of the description, you can whether the scene is shot during the day, the night or at the same time as the last scene if need be. Finally, the entire description must be capitalised.

Whenever a new character is introduced their entire name must be capitalised and must be accompanied by a description of them. From there you can write normally about what characters are doing, until they speak. When a character speaks, their entire name must be capitalised and indented on the left by an additional inch. If dialog runs over the page, then (MORE) must be added to the bottom of the page that the dialog started on. Then on the page that the dialog runs onto, the characters name is placed at the top of the dialog, all capitalised again, but with (CONT’D) placed next to it.

There are also certain terms that must be next to a characters name at the top of their dialog depending on the characters’ location on-screen. If the character has dialog but is not mean’t to be on-screen when saying it, then you must add (OS) next to the characters’ name at the top of dialog. However, if the character is purely voice, e.g. a narrator, you must add (V.O.) next to the characters’ name at the top of dialog.

Lastly, if a specific transition is required between scenes then it should be noted at the end of the scene. To do this, write the transition in capitals with a colon at the end (e.g. DISSOLVE:), and align the text to the right. Note, however, that is should be done for every scene change.

 

It doesn’t contain everything that has been discussed but below is an image of the screenplay that I wrote for the first crisis of my team’s scenario.

FilmScriptSample.png

Future Uses:

This research obviously helps with writing dialog and planning cutscenes in games. Beyond that, I believe that this provides me with a valuable first step into an aspect of game development, even an entire genre of games, that I am yet to explore. It allows me to begin experimenting with narrative-driven games in a form that is easily understood and is still useful later in the development cycle.

This also gives me a medium in which to express ideas and stories not only in a structured manner, but in a professional manner as well. It allows me to write in a format that is common in the industry (in the film industry at least) and can be easily read by veterans and amateurs alike.

Finally, this research is the first step into opening avenues for me in the film industry should I ever wish to transition to another creative industry.

Improving Enemies with Particle Effects

Yet again I am back on Project 1, making improvements. This time I decided to add some more visual features to the enemies. I wanted to make the enemies stand out because they can be hard to see, since both the enemies and the background have similar cream colours. Also, since the enemy sprites just disappear when they have lost all their health, I wanted to have a fade or a transition just so it looks better.

What I added is a particle effect that sits behind an enemy and fades after the enemy dies. The effect is intended to make the enemy appear as if they have an aura.

To do this I created a Particle System in Unity, set its Shape to Mesh and its Mesh to Cylinder.

ShapeMesh.png

The reason I selected Mesh > Cylinder instead of Circle is because particles spawn in the centre and around the edge of the Cylinder, whereas Circle has particles spawning inside the Circle. You can see the difference below.

ShapeCompare.png

ShapeCompareSettings.png

The Particle System on the left is the Cylinder and the Particle System on the right is the Circle. Both have the same settings, which you can see in the image above.

The Cylinder Shape suits my needs more because, when speed is set to a negative, all the particles centre in a single spot. This gives me the kind of fading effect that I am looking for. Below is an image of the Cylinder Particle System with Start Speed set to -0.5 and Emission > Rate Over Time set to 500.

Cylinder.png

For the actual Particle System I used the following settings and got the following result:

CylinderSettings.png

CylinderDone.png

Now to put the Particle System underneath an enemy sprite.

CylinderSprite.png

In order to make the Particle System linger and fade after the the Enemy sprite has been destroy, we need to write some code. We can’t make the Particle System a child of the the Enemy sprite because when the Enemy sprite is destroyed the Particle System will be destroyed as well.

The first that we have to do is reference the Particle System.StopLoopCodeStart.png

Also, set up a bool that we will use later.

StopLoopCodeBool.png

Then, in the function that controls when the enemy is destroyed, line 41 of the code below retrieves the Main section of our Particle System and line 42 retrieves the Loop setting of our Particle System and changes its value to the bool made earlier.

StopLoopCode.png

Be sure to put the code above the Destroy code, otherwise the Enemy will be destroyed and will not run anymore code.

Now we have a Particle System that fades when the Enemy sprite is destroyed, but what happens when the Enemy sprite moves? Well the Particle System, at the moment, doesn’t follow the Enemy sprite. Let’s change that.FollowCode.png

The above code has a public reference to a GameObject, meaning that we can drag and drop the specific Enemy sprite that we want to be associated with this code. Then the Follow() function finds the Enemy’s position, if available, and makes the Particle System’s position equal to it. Finally, this function is called in Update().

Now the Particle System follows the Enemy sprite and fades away shortly after the Enemy sprite is destroyed.

Importing Assets From Collaborators

When I imported the art assets, that I received from Hayden, into the Unity project, I encountered a problem. The assets could be dragged into the scene and the preview of the assets had some form of artefacting.

It turns out that the cause of this problem is that the assets’ Texture Type was set to Default.

Standard.png

In for the asset to be useable in the way that I want it to, I just needed to change the Texture Type from Default to Sprite (2D and UI). This immediately fixed all the problems that I was having.

However, all the art assets that Hayden sent me were huge when compared the to size of our levels and, well… pretty much everything else.

Huge.png

I tried adjusting the size of the head by changing the scale of it, but that had me working in decimals and it was just a headache to deal with.

Fortunately, there is another way to deal with this problem. It is called Pixels Per Unit.

PPU.png

Adjusting Pixels Per Unit to 2500, instead of 100, shrunk the size of the asset down to the small head that you can see below the big head in the 2nd image above this.

From there on out it was a simple Texture Type change and a Pixels Per Unit adjustment to each assets that Hayden sent and they all became useable.

Creating a Playtest Questionnaire

Throughout Project 3, there were two playtesting sessions where people from all over campus could come and play the games we had made. In order to get the most information that we could from the playtester, every team had to come up with three questions to ask playtesters about their game.

The purpose of these questions is not to see whether they liked it or not or where there could be improvements, but to make sure that the game that we are creating is giving players the experience that we intend them to have.

As such, our questions need to be carefully tailored so that there aren’t subtle indicators that might influence the answers that we are given.

During our teams’ brainstorming we came up with questions such as:

  • How difficult did you find balancing the head? (1-5)
  • Were any parts of the game too frustrating?
  • Does the game have a message?

The above three questions all contain subtle hints toward what we want the answer to be. The first two lead the playing into thinking that we want them to find the game hard and will likely skew their answers, perhaps unconsciously, towards suggesting that the game is hard. The third question leads people to believe that the games has a message just by virtue of bringing it to attention.

So we can’t use language similar to that, but we also can’t use a scaling system that you can see in the first question. The scaling system tells us very little. While it certainly tells us what they thought, it doesn’t tell us why they thought that way and gives us no indication as to whether the rating was a result of design or something else.

After culling a few more questions and having more discussion, we decided that the best way to go was to ask open-ended questions that required an answer that was at least a few words. Asking questions that can be answered with a yes or a no aren’t very helpful and questions that require a paragraph are too daunting to answer, so those types of questions aren’t viable either.

The initial three that the team chose were:

  1. Describe a moment when you nearly lost your balance but recovered.
  2. Describe a moment when you chose not to boast to someone.
  3. Describe a moment in the game where you failed on a ramp. How did that impact your strategy?

When asked what answers we wanted to receive from these questions. They didn’t hold up very well. The answers we gave were fairly mundane and didn’t really tell us much about the feel of the game. Our answers were:

  1. Second time I went up a ramp
  2. Before I went up a ramp
  3. I failed the ramp the first time I took, so I moved slower next time.

All these answers really tell us is that ramps exist and are difficult. Plus it is far too ramp-focused in a game about boasting. Also, the third question was a bit too leading, so the team reworked the questions into:

  1. Please describe a moment where you feel like you boasted too much.
  2. Please describe a moment when you nearly lost your balance but recovered.
  3. Please describe a moment in the game where you changed your strategy – why did you choose to change it?

These questions are far more open in terms of responses that the team believes they will receive.

 

When it came time to playtest, the team never changed questions between any of the playtesting sessions. The last two questions stayed because they made sure that the changes made to how the player moves and to the levels didn’t interfere with the experience that we were trying to create. However, in hindsight, the first question should have been changed because the team received everything from joke answers to confusion as to what boasting was.

The game, in the state it was in at the time, didn’t properly notify the player of who they could boast to or even the fact that they could boast at all. This means that some players missed that mechanic entirely, leaving the question obsolete.