Development Blog [Cursed]

Team: Nico and Cassie

April 2

Initial thoughts

  • smashing/hitting apples from a tree (falling?)
    • Protecting Newton
  • Protecting or moving a dragon egg
    • Something flying at you
    • Have to protect the egg with a shield or weapon
    • Combine with apple idea
      • Protect the egg from falling apples
      • Bird in a cage
      • Instead of an egg, magical stones to be protected
        • Protect from things running towards you
  • Something with cooking
  • Maze or quest for the player
    • Boulder following the player, have to constantly move
  • Skydiving
    • Starting in an abandoned location

Expanding on Protecting Egg/Item Idea

  • Instead of falling with gravity, objects run from in front of player
  • Instead of protecting item, protecting self
  • Indiana Jones sort of scenario
    • Player has stolen an item, now has to protect self and item
    • Evil doers are coming for the player
    • Survive a certain amount of time or monsters/evil doers
    • 3 possible outcomes
      • Drop the item
        • Release the curse
      • Evil doer gets to the player
        • Releases the curse
      • Survive a certain amount of monsters
        • Item transforms
        • Final location, nice scene

Final Idea – Cursed (Protecting the Statue)

  • Initial scenery (first scene)
    • Large open sky area
    • Cave not so prominent
    • Nice lighting
      • Light green
      • Bright yellow
      • Sky blue
    • Outside
    • Large old tree
    • Old run down brick walls surrounding player
    • Mystical statue on a platform closeby to the player
    • Throwable rocks around the statue
  • Picking up the statue (second scene)
    • Lighting changes
      • Nice lighting changes to darker and more evil like
      • Red lights appear above 4 caves, each at a cardinal direction
      • Caves become prominent
    • Statue has a glow
    • Platform lowers
    • Sword falls from above (can be picked up)
    • UI message appears
      • The curse has been released
      • Tells player to protect themself (logic to use sword and stones)
    • Monsters slowly start to appear
      • More start to appear faster
      • Localization of monsters is random
      • Appear behind cave and move towards the player
  • Monster hits player or player drops statue (losing scene)
    • UI message appears
      • The curse has permanently taken over
      • In order to restart
        • Grab another object
        • Maybe no restart
        • Automatically restart
      • Lighting al turns off except for the statue’s glow
  • Destroy X number of monsters (winning scene)
    • Statue is replaced with animated “god” or something
    • UI message appears
      • You have defeated the curse
      • You have destroyed all the monsters
    • Lighting becomes merry
  • Involved scripts
    • Changing lighting
    • Initiating sword
    • Throwable sword, rocks, statue
    • Lowering platform
    • Moving monsters
    • Collision detector for destroying monsters
    • Collision detector for monster touching statue
    • Sound effect
    • UI messages
    • Score in top left/right
    • Potential animation of monsters
    • Animation of final scene statue
    • Restarting game
    • Initiating monsters (randomly) (increase amount with time)
    • Moving of monsters towards statue

Possible Scenery Inspiration

April 13

Today’s goal was just to set up the testing area and prepare the Unity file for the project. In order to do that I downloaded all the necessary assets for the project (fig.1). This included all the building blocks for the dungeon, the statue, the sword, the lights, and the stones. After obtaining all the assets, I went ahead and started placing some into the “Dungeon” scene (fig.2). I found a suitable platform for the for the dragon statue, floors that looked decent, and gates that matched. I tried to scale everything to an entertaining size and then tested it out. It is all looking pretty nice, I can see with lights, trees, accessories, and blocks added it, this scene will look a lot like a fully-fledged dungeon room (fig.3). The only issue is that the statue is a bit out of style (too shiny) but that might be useful in catching the player’s attention.

April 14

Today we paper player tested the concept of our games. Cassie fabricated the basic items that were going to be involved in the game and then we gathered a friend of ours to test out the scenario. The items included: the head mounted display (fig.1), the monsters (fig.2), the statue (fig.3), the rocks (fig.4), the sword (fig.5) and the lights, and the podium for the statue.

From the testing (vid.1 & vid.2), we gained some insight into the changes and improvements we needed for our game. The important ones had to do with the voices and narrative structure. It was suggested that we clearing state the goal of the game with a phrase such as “protect the statue” instead of keeping the goal too ambiguous (but don’t go too detailed by saying exactly how). Also more monsters and large ones if possible would be desired. Lastly the idea of being able to place the statue down would make it easier to both throw stones and fend with the sword at the same time. The last idea might not be followed but it was good advice.

April 16

Today, a lot of work was put into the project in order to develop a fundamental basis to continue work off of. Stones were added and scripts were added for each of the object that will need a function (fig.1 & fig.2).

Next, a bunch of work was placed on the monster. The monster came from an asset pack that also involved its animations. The animator was removed just for now, just to keep everything simple for now. A rigid body was added to the monster as well as the script (fig.3).

The monster script was quite simple, it caused the monster to move forward one value every second as well as making it vulnerable to any object that has the tag “HurtMonster” (fig.4). The next script that was worked on was for the statue. This script simply kept the statue still and unaffected by gravity until it was moved, at which point it would no longer be kinematic and would also trigger the “hasMoved” Boolean to be true (fig.5). This was used by the control script as an indicator to spawn monsters.

The control script had many parts to it as well (and will have even more with time) (fig.6). It requires the prefab for the monster that is going to be spawned as well as the connection to the statue. Once the statue has been moved, the script will start spawning monsters every 2 seconds. This parameter will eventually be changed to spawn monsters more often as the timer float increase more. The spawning of the monster is also random (placing randomly out of 4 possible gates). This was quite annoying to set up being it required the accurate position and rotation of the monsters to be correct (so that it would walk towards the center). Ideally another script would eventually be added in order to have monsters randomly appear from the diagonal directions as well (just to make it so that the player can’t just move out of the way of the monsters to protect themselves.

April 21

Today a lot of the project and its foundation were worked on. Many scripts were written and many object placement and game testing took place. I continued working on the control script, the statue script, and the monster script but also added scripts for the sword, stones, and podium (fig.1). The two prefabs that were created, with the appropriate scales, details, scripts, and components attached were the monster and sword (fig.2)

Four major additions were made to the environment. The 4 types of stones were placed around the podium in a circular manner and brought down in scale from before. The terrain was flattened out a bit because it was interfering with the monsters movements. A suitable light source was found and placed were it will be visible and blend it with the gate. The gates and monsters were scaled up in size to give a larger affect; this required some rearranging of objects as well. (fig.3)

The prefab for the monster had a few features that were worked on in detail. The animator was turned back on and the walking motion was placed on loop (fig.4). I tried turning on root motion to use as more aesthetic walking behavior but it didn’t move the monsters so the previous code to move was retained. The rigid body also needed to be played with a bit in terms of parameters being locked because the monster occasionally would bump off something and start walking into the sky.

The sword prefab also had some features worked on. The original sword was taken from an asset pack and edited down in terms of scale. It was also made intractable and throwable using the SteamVR asset pack’s scripts. A collider was added and made convex so that it could interact with other object in the game. It was important to mess with some of the boxes in the throwable script because the sword would fall out of your hand slowly as it was being held due to gravity not being turned off. The same issue occurred with the stones, this was an easy fix to apply to everything. (fig.5)

The monster script was kept simple. Since root motion didn’t work the moving forward script had to be kept. A collision detector based on tag names was also implemented. Now items could either have the “NoHurt” or the “HurtMonster” tag that permitted the object to either destroy or damage the monster it hit (fig.6). For now this would be used solely on stones and the sword (at specific times when they were being used).

The sword script was created with several features. The original position and rotation was recorded so that the sword could be respawned there if the game were to restart. Also the alternating tags (between hurting and not hurting the monster) was coded for. This was important so that the sword could not hurt the monster when it was on the ground (fig.7).

The podium was finally given a script that permitted it to disappear out of sight when necessary). The script recorded its original position and rotation so that it knew how to move and also so that it could be brought back if needed. The podium only moved down (at a reasonable speed one fourth of the scale per second) if the statue was moved (fig.8). It would also not move further than -1.5, just to keep it relatively close and not cause lag to the game.

The script that was written for the stones required a good deal of work and thought. First their original position and rotation was recorded. The stones were also originally set as kinematic so that they didn’t move. If the stones were moved, the kinematic was turned off and a timer would start counting down to respawn a stone at the original location. The respawning doe was written in such a way (that was kind of crude) that it would respawn a new stone only once (this was necessary because otherwise stones would start overlapping and cause the game to have serious lag and issues. The script also check every update to see if the stone could hurt the monsters, the parameters to allow such behavior could be easily altered (for now it had to be at a certain height). Another parameter could be based off of the location, if it was still close to its original location then the stone would not be able to hurt the monsters (meaning it hasn’t been thrown far). There is currently a glitch that I don’t know how to resolve: the first stone that is spawned doesn’t gather any velocity from the hand when it is first thrown (so it doesn’t fly forward but drops down) but once picked up it works normally (fig.9). The stones that then spawn from that stone all behave normally. Also, every now and then the stone loses gravity and just flies away once thrown or bounced on something. These are glitches that could either be maintained to cause difficulty to the player or worked on later on.

The last script that was worked on was the control. I just added some code to this script to spawn monsters more logically and spawn the sword. Once the statue has been moved, a sword will spawn from overhead (the prefab) 3 seconds afterwards (after the podium has gone down) and fall down. This relies on a Boolean variable to not spawn the sword repetitively. The script will also start spawning monsters. It will start spawning monsters every 5 seconds (not shown) but then after half a minute it will spawn monsters every 4 seconds, this will continue increasing till after 135 seconds (about 2.5 minutes) where it will spawn a monster every 2 seconds (fig.10). This mean that after 3 minutes about 60 monsters would have spawned. These times and frequency of spawning can all be easily changed but for now these seem ideal. The spawn frequency cannot go below 1 a second because that is how long it take for the monster to move entirely forward (don’t want monsters spawning on each other).

Lastly in addition to the tags, the layers were played around with a little bit. Two layers were created to make the game more efficient in coding, a “seeking statue” layer for the monsters and an “avoiding monsters” layer for the objects that should not interfere with the monsters movement or behavior (fig.11).

Finally, some important code that has to be worked on: fixing any glitches that were discovered, changing the lighting once the statue is picked up, animating the death of the monster (this should also place them in the avoiding monster layer so it doesn’t interfere with other monsters), having a start or end screen, and implementing a winning and losing condition. Up to this point a lot of work has been put into the project and it looks like a bunch more will have to be put in (especially solving glitches), hopefully it works out!

April 27

Today was another successful day of coding, a substantial amount of progress was made. I started off by tackling the monster movement issue. The very first thing I did was move everything around the monsters trajectory, including the terrain, into a layer that wouldn’t interact with the monster (fig.1). Since I did this, I had to make sure the monster wouldn’t fall through the ground, so I fixed the y position (along with the x and z rotation to keep straight) of the monsters rigid body. After getting the monster’s movement fluid and without stopping, I wanted to animate the dead when hit by a rock. I did this in the animator component of the monster’s prefab. I added a new action (called “Dead”) to the current walk and made a Boolean parameter (called “isDead”) that had to be turned on in order for it to occur. When the monster is hit by something that has the “HurtMonster” tag, then the Boolean within the script for death would turn on as would the Boolean in the animator (fig.2). The falling monster would also be moved to the layer that doesn’t interact with other monsters (“Avoiding Monsters”) as to not inhibit the movement and trajectory (fig.2). A really cool effect of this is that the corpses stay present after their death. An issue I came across was that the dead monster still interacted with other, to fix this I inputted a script I found online that would change the layer for all the children and grandchildren within the monster prefab, function called “SetLayerRecursively”, which worked in the end (fig.2).

Since I noticed that the monsters would be blocked by the stones that were newly spawned (thus not reaching the middle or the statue) I added to the code to fix the issue. I made it so that newly spawned stones were placed in the layer that didn’t interact with monsters (fig.3). I also lowered the time for the stones to respawn since it seemed to take too long. If the player threw the stone at a monster before a new one respawned then it wouldn’t respawn, this was a way to punish the player for using stones at a close distance.

To add to the convenience of the game a bit I made a function that brought the sword back to the original position if it was thrown too far. Since the stones respawned I thought it was only fair that the sword does too. I did this by using the math library and making it so that the position of the sword, along with its rotation and velocity, were set to original if thrown further than 2 in any x or z direction (fig.4).

Finally I attached a losing behavior for the game to the statue’s script. Currently, only if the statue fell below a certain level (on the ground) would the player lose (fig.5). I gave room for the possibility of cheating the system, you could make a platform of stones or place the statue on a dead monster and you would not lose.

I made a change in scenery for the when the player supposedly lost. With a lot of difficulty I found the main camera within the player and found a way to alter the skybox so that it became black when the player lost. I found this through trial and error. Turns out that if you change the “Clear Flags” of the main camera from “Skybox” to “Solid Color” then the beautiful skybox would be turned to a single color quickly (fig.6). This gave off a strong effect for when the player lost. I also made it so that the ambient light intensity would be set to very low when the layer lost, which turned a lot of the environment dark (fig.6). I found out that this would only work on non-static objects. Ideally, I would find a way to turn everything dark.

The control script is getting a bit hectic because I am slowly realizing how inefficient my coding is (stating things more times than they need to be and writing too many lines). It is a bit too late to fix this because it would take a lot of time to redo but it is a good learning experience. I think so far the game is looking good. The next few steps necessary for the coding is: adding more losing conditions, fixing the losing condition, making a winning condition, counting the number of monsters killed, and making a method to restart the game (perhaps with SceneManager.LoadScene(SceneManager.GetActiveScene().name).

April 30

Having in mind what I wanted to do today, I created 2 new materials and a new prefab that I was going to use (fig.1). I created a dark looking material for the planes from which the monsters will emerge (fig.2, naturally set in the “Avoiding Monsters” layer as not to interact with the monster) and a glowing purple material for the respawn sphere that will let you restart the game if desired (fig.3).

I then went ahead and made it so that the player could indeed restart the game if they lost. I did this in a roundabout way, when the player loses everything turns dark but a sphere will appear. This sphere (which is glowing) can be interacted with. A voice will tell the player that they can try again by grabbing the sphere. Grabbing the sphere will then reload the scene (fig.4). When I first tried running this code I noticed that some objects would be carried over into the reloaded scene. This caused issues because some of the scripts would malfunction due to there being multiple objects with the same name. Also, there would be too many statues, swords, and stones, which made the game very different. I added a section to the code that deleted the sword, player, and statue before reloading but I decided to keep the stones (fig.4). I think this would be enjoyable because it would give the player a bit more of a head start and would also allow them to strategize their placement of stones ahead of time (simply gave a bit more character to the game). I noticed that in the reloaded scene the stones and statues would have the issues of not taking velocity from the hand after being thrown (the first time). I don’t know how to fix this but I think it might be reasonable to keep it in the final version of the game because it is a disadvantage that balances out with the advantage the player obtains from restarting.

I also noticed that the monsters would continue to spawn and walk towards the player once they had lost (or won) which seemed aesthetically displeasing. There was also the issue of them (and the corpses) being reloaded to the next scene after a restart. To fix this I made a very simple addition to the code for the monsters. I simply made it so that when the player lost, the monsters would delete themselves (fig.5).

Though I didn’t actually code for the winning scene I wrote the code that prepared for it (as well as the losing scene entry way). If the monster collided with the statue or the player (depending on the name of the objects) the player would lose (fig.6). I might have to change this later on so that it is only the statue because the monster can quite easily collided with the player (even when as a corpse). I also made it so that the player would gain one point every time a monster is killed and will win once they kill 60 monsters (fig.6 & fig.7). As I am writing this blog I noticed an error in the code that needs to be fixed; currently the sword will get destroyed once it interacts with the monsters because it has the “HurtMonster” tag. This needs to be made into an if condition. Also the current if condition needs to have the “or’ operator turned into an “and operator”; currently the player could win simply by hitting a corpse repetitively with the stone or sword.

I think the coding for the game is getting close to its end point. To finalize, I think I need to code the winning scene and fix some bugs with the reloading and the throwing. If necessary, I can also make it so that monsters spawn form the diagonals every now and then. I like how the game is looking so far.

May 5

I started off by fixing something that I thought was made the game unnecessarily inconvenient. I made it so that the losing condition only took into account when the statue touched a monster and not when the player touched a monster (fig.1). I also placed the player in the “Avoid Monsters” layer. This made it so that the monsters would walk through the player to reach the statue.

Another aspect I wanted to fix was the difficulty level of the game. From player testing I understood that the game was a bit too difficult because monsters spawned too quickly. To fix this I decreased the spawn rate. I started at every 7 seconds then 6, 5 and finally 4 (fig.2). This meant that after 2 minutes close to 25 monsters would have spawn. This is the amount of monsters to kill to win.

Next, I wanted to add a blood effect to the monsters. I made a particle system that looked mildly like blood splatter and attached it to the chest of the monsters (fig.3). I found the right parameters mostly through trial and error. I then added code in the “death of monster” section so that it would play the particle system when the monster died (fig.4). This meant that the blood continued inevitably till the player won or lost. Also, the particle system didn’t collide with anything which fixed a few bugs I had in the previous project.

I fixed the losing condition from dropping the statue. Originally it was based on the y position of the statue but do make the system more accurate I based the touching on collisions. Now, if the statue collided with an object named “Terrain” (the ground) then the player would lose (fig.5). This also permitted me to add into the game a small Easter Egg which I do later.

To balance the losing condition, I added a winning condition. Now if the player did indeed kill 25 monsters then the previously turned off directional light would be turned on (fig.6). This made the scene a lot brighter and does indeed feel like success. I had to destroy the statue in the winning scene or else the player would still lose when dropping it. I made it so that there was no more replaying after winning; that is the end of the game.

Finally I worked on the Easter Egg portion. I first made it so almost all of the objects were not static. This made it so that I didn’t have to deal with the baking of light maps and so that everything turned dark or bright with the change of light (fig.7). This is not a perfect method but since there are not too many objects in the game there won’t be much lag. There is one hollow shape that doesn’t turn black when the player loses (fig.7). If when the player is defending themselves, they can throw the statue in the hole and not lose. This makes it so that the player doesn’t have to worry about the statue when fighting. I am thinking of making it so the player automatically wins when they throw it in there.

So I think all the coding for the game is pretty much done. Now all that has to be done is the addition of sounds and a few touch ups.

May 10

I spent way too much time trying to fix the glitch where the stones would not fly after being thrown (only after the scene reload). I found out that it had nothing to do with my script though a lot of trial and error. In the end I found it to be a problem with the throwable script. I just had to prevent the script from turning the object kinetic when it was being picked up (fig.1). This was done in the “Attachment Flags.”

I then went ahead and corrected the blood splatter particle system. I found out that adding an animation to a character doesn’t move all the objects within the prefab. I order to make it so blood came out at the right place when the monster died I just placed the particle system where the chest would be when they fell (fig.2).

Lastly I added a flat sphere (since there are no circles) to the bottom of the statue (fig.3). Originally the statue was see through at the bottom so this fixed that issues.

Done.