Sunday, April 26, 2015

Dark Awakening

The concept of Dark Awakening was originally derived from a Game Jam game back in 2012. It is a horror based FPS where the player finds their-self in a hospital, but the hospital doesn't look like the normal hospital. Armed with just a flashlight, the player must survive each level against enemies. One important factor about the flashlight is that it loses power over short durations of time, so the player must replenish the flashlight. There are a total of 9 levels in the game, to represent the 9 levels described in Virgil's the Divine Comedy. Each level has something in it that makes it different from other levels, such as the Gluttony level where the player moves slower than other levels. This game was created in Unity 4.6 by myself with the assistance of assets from the Unity store via my university.

Game Title: Dark Awakening
Genre: Survival/Horror
Theme: Modern times in a hospital
Developers: Nicole Jameson
Audience: PG-13
Platform: PC

One sentence: Dark Awakening is a survival horror game in which the player is immersed with darkness. All that is available is their wits and a really bad flashlight.

Backstory: The player wakes up in a room which is in the top level of a hospital building. They have no recollection if they were a patient or an employee let alone why they are there. They see words written on the walls and a desk with a flashlight on it. The player is completely alone and there is no way to contact the outside world. The only thing to do is to get out of the hospital alive. 

  • Items (placement determined via random generator) 
  • Light Sources (As the light intensity fades, the less damage it does to a monster) 
  • Standard Flashlight (indicate when getting low on battery life) 
  • Reload with batteries 
  • Flashlight has range and light dissipates 
  • Light gets dimmer as the batteries grow weaker 
  • Flares 
  • Blue spotlight light source that will run out overtime 
  • Health Items 
  • Med pack 
  • Obstacles 
  • Blockades (placement determined via random generator) 
  • Prevent a player from going straight to the other side. 
  • Save Points 
  • Phone - either the player will have one available at all times or has to find one in the level.

Dynamics: Self exploration, discovery, survival

Aesthetics: 3D graphics, minimal user input for actions, accurate sounds to indicate to player where something is, and appropriately placed light sources to indicate to player where they need to be heading towards. Ambient music is going to be ambient sounds which include sounds from the monsters and possibly other office sounds like a computer humming.

Overall game play: The player starts the game in a semi dimly lit room with only a flashlight (with partial battery life as all batteries will have) and words written on the walls which have important messages. Some examples of messages would be “Light is the only way to survive” or “Light kills them!”. The player has no idea what is going on nor what to expect of the game. They are to exit the room with the flashlight, go down the well-lit stairs, and are thus placed in the introductory level.
This stage is the introductory level as to teach the player what to expect and to get use to the controls before the game's next level. The following level is the actual first level in the dark. In the introductory level, the player sees a vast floor of office cubicles (dimly lit) and a light on the other side. The player is currently in a well lit area at the base of the stairs which indicates a safe zone (monsters cannot go into the light). There will be a pre-made path that the player must follow which will take them through various obstacles or things that they will run into later on in the game. In the introductory level, the player will meet every monster and will have to figure out how to kill them. Naturally, all monster types will die by light but the player may or may not know about this yet. There will be small lit areas in which med packs will be located at and a radio could be playing (subtle) where batteries or other light sources are located at. There will be no music playing during the game due to the player needing to hear for things. It is of given thought that the player will find out that the flashlight batteries do not live long so conserving the battery life is of utmost importance. Once the player reaches the other side of the level in the well lit area, the player is then taken to the actual game play. Load screens occur in between the levels. The rest of the levels are in complete darkness and no set path but the other attributes such as radio and lights indicating where something might be, still exist. A player will not know when battery life is getting low until the light gets dimmer. The player will not see any health bar of the monsters nor their own health. They will know, however, their health status when playing due to the screen becoming more fuzzy and unclear. If the player dies, they restart that level. Object of the game is to get out of the hospital

Monsters: There are three types of monsters – aggressive, passive-aggressive, and passive-until-aggravated. The passive-until-aggravated monsters will not mess with the player unless the player shines the light on them or runs into them. These monsters have a moderate distance of what they will follow once aggravated. These monsters will wander the level and will generally stay to themselves. The passive-aggressive monsters are “stuck” monsters. These monsters are literally formed to the floor, ceiling, or wall in which they don't do anything until the player comes within reach. The aggressive monsters actively hunt for the player once the player reaches a marker (unknown to the player). These monsters have a longer range to follow. Each level may have a boss monster in which it will stop at nothing to kill the player. Each boss will be different in appearance.

Art/assets needed: Monsters - need 3 types for the standard monsters encountered in each level. Will need a few extra for the bosses. Hospital and office objects such as beds, chairs, computers, clothing, flashlight, medical kit, and body parts.

Estimation of cost: In total, the game is estimated to cost around $3 million to complete. This takes into account the pay for everyone involved, the time taken to complete, and marketing. These estimates are based off of the cost of development for games between 2008 and 2014.


Introductory room of game
Battery pickup example
General room concept during gameplay

  • First video - next 3 things: add extra "clutter" to help conceal the spheres, finish the GUI tutorial, and create a flashlight.
  • Second video - next 3 things: create a replenish and depletion mechanic for the flashlight, create a menu, and create an option to exit game.
  • Third video - next 3 things: pretty big implementation for super basic AI, paths for the monsters, and add clutter.
  • Forth video - next 3 things: continue AI and path finding for monsters, create a battery recharge, and implement some sounds.
  • Fifth video - next 3 things: create 2 separate AI for the 2 monsters in game for now, fix the lighting and battery implementation, and start applying this to all levels of the game.
  • Sixth video - next 3 things: finish the 2 separate AI (even though AI is never truly finished - there are some fixes that need done before I feel it will be passable), clean up the tutorial level with the monsters, and create the 3rd type of monster.
  • Seventh video - next 3 things: implement the 3rd enemy, create player health and combat with the various enemies, and begin work on the 3rd type of level since assets will be available. 
  • Eighth video - next 3 things: same from previous week. Had an unexpected emergency this past week in which I was unable to do the "things". There are some small updates in this week's video.
  • Ninth video - next 3 things: continue work on player health, continue work on enemy combat with flashlight, and implement assets into game for a more enriched environment.
  • Tenth video - next 3 things: finish player health (indicator mostly), finish enemy combat with flashlight, and finish other levels (hopefully assets will become available).
  • Eleventh video - next 3 things: these are very dependent on getting the assets requested - redesign the levels, adding ambient lighting, and being starting on the final game design.
  • Twelfth video - next 3 things: continue asset implementation, fix the enemy upon death, and see about restarting level upon player death.
  • Thirteenth video - next 3 things: do what I listed for previous week. I had 3 other classes with projects due so unfortunately this project didn't get much done.
  • Fourteenth video - last finishing touches: fix enemy spawners in some of the levels and finish the final boss level.
  • Fifthteenth video - demonstrates the fixed enemy spawners. Further player testing needs to be done to correctly spawn the right amount of enemies because as seen in the video, I gave up on one of the last few levels.
Images from the available game demo.

An image from an office level.

An image from a hospital level.


An image from the final boss level.

The final demo is available below. I do plan to continue this project in which assets will be replaced by my own and the game levels will have expanded.

Final demo for Capstone

Flashlight script:

using UnityEngine;
using System.Collections;

public class FlashlightController : MonoBehaviour 

        public Light flashlightObject;
        public float powerLevel = 3.14f;
        // Use this for initialization
        void Start () 
                //This means the flashlight is disabled when the character spawns.
                flashlightObject.enabled = false;
        // Update is called once per frame
        void Update () 
                //if the player presses the F key...
                //if(Input.GetKeyDown (KeyCode.F))
                if(Input.GetKey (KeyCode.Mouse0))
                        //The flashlight will turn off if it is on.
                        if(flashlightObject.enabled == false)

                                flashlightObject.enabled = true;
                                //If it is already on, it will turn off.
                                flashlightObject.enabled= false;

                //so we want to give a source of power to the flash light.
                //This was done above in the public variable powerLevel
                //In this if statement, we are reducing the powerlevel by 1
                //if the flashlight is enabled.
                //then we also reduce the spotAngle and intensity
                if(flashlightObject.enabled == true)
                        powerLevel -=0.001f;
                        //flashlightObject.spotAngle -= 0.02f;
                        flashlightObject.intensity -= 0.001f;

                //if the powerlevel reaches 0
                //turn off the flashlight
                //also make sure that to powerlevel gets set to 0, if you don't do
                //that, it turns into a negative number.
                if (powerLevel <= 0) 
                        flashlightObject.enabled = false;
                        powerLevel = 0;


This script is for the flashlight light power. Here is where the power level is controlled as well as using the flashlight and the decreasing power of the light. I created this using a few different tutorials and customizing them into a full, single script.

Enemy spawner script:
using UnityEngine;

namespace ProjectDA


    public class EnemyManager : MonoBehaviour


        public PlayerHealth playerHealth;       

        public GameObject enemy;                //the prefab goes here

        public float spawnTime = 3f;           

        public Transform[] spawnPoints;         //all of the spawn points that enemy comes from

        void Start ()


            InvokeRepeating ("Spawn", spawnTime, spawnTime);


        void Spawn ()


            if(playerHealth.currentHealth <= 0f)




            //randomize the index between 0 and 1 less than spawn points

            int spawnPointIndex = Random.Range (0, spawnPoints.Length);

            //create the prefab and rotate

            Instantiate (enemy, spawnPoints[spawnPointIndex].position, spawnPoints[spawnPointIndex].rotation);




This is a general enemy spawner which I use to control the enemies spawning. It uses the prefab of the enemy, places it at a spawn point, and upon creation it is rotated toward the player. This script was a bit challenging due to the numerous ideas I had early on in the game. I originally tried waypoints but that proved to be useless due to the various objects in the way. Most of the time the enemies got stuck on a cubicle or a box. The instantiation inside the spawn function was a bit hard to get written correctly due to spawn point naming convention. 

Enemy movement script:

using UnityEngine;

using System.Collections;

namespace ProjectDA


    public class EnemyMovement : MonoBehaviour


        Transform player;               //player's position

        PlayerHealth playerHealth;      

        EnemyHealth enemyHealth;        

        NavMeshAgent nav;               

        void Awake ()


            player = GameObject.FindGameObjectWithTag ("Player").transform;

            playerHealth = player.GetComponent <PlayerHealth> ();

            enemyHealth = GetComponent <EnemyHealth> ();

            nav = GetComponent <NavMeshAgent> ();


        void Update ()


            //handle enemy and player health

            if(enemyHealth.currentHealth > 0 && playerHealth.currentHealth > 0)


                //set the enemy after the player as a target on player

                nav.SetDestination (player.position);





                //disable nav mesh object when dead

                nav.enabled = false;





This script goes in hand with the enemy health, enemy movement, enemy attack, and enemy manager scripts. Creating all four scripts was challenging for me because when I would name one thing as XYZ, I would accidently change it on another script without knowing it. Other than that, this script was derived from a few scripts online in which I compiled into what I needed.

Related classes for this course would be all of my programming classes up until now along with the original game jam that this idea came from. The game was originally thought up to be completed in 48 hours and it was going to be completed between 3 people. I figured that I have 16 weeks to complete this game along with my other classes and coursework so I should be able to do it. I've continued the audio knowledge from CGDD 4003, CGDD 3103, and CGDD 4803 and feel like I have come a long way with it. I do plan on looking into FMod this summer to expand my skills further. I applied my SWE 4324 knowledge of what players would want in the game which was a minimum HUD and a challenging activity for the enjoyment level. I took Data Structures this semester as well as Application and Scripting which provided me a refresher on clean and proper scripting, more the Data Structures than the latter. Using my previous psychology class helped me when creating a good balance of enemies, level structure, and sound. Creating a sense of possible failure heightens the engagement of an activity. This was an aspect I was focusing on primarily since the game consisted of simple concepts.

Wrong and Right:

Looking back at this semester and this game's creation, not much went wrong. I had the idea in my mind from the beginning let alone it was originally a game jam game. In the end, I'm satisfied that the game turned out as it has which allows me to make some improvements to make it better. As mentioned above, I do plan on continuing this game after this semester, exchanging the assets and textures for ones I make as well as expanding the level sizes.

When this class started, I knew what I wanted to do for the project. I chose to not work with a partner since the previous class was a horrible experience for me. This decision let me provide myself and others what I can do alone as well as give myself a more realistic challenge in completing tasks once I enter the game development career. Through applying my gained knowledge and discipline, I came to a fully functional game which does as I wanted it to. There are still some minor adjustments that will follow due to player testing, but that will change with time.

During this semester, I was taking an application and scripting class which helped me improve my scripting skills. Each time we learned something new in the book, I tried to see about applying it to my game. Sometimes it worked, other times it didn't. I have yet to take the AI class, which is actually next semester for me. After that class, I feel that my knowledge from this class will be greatly improved so that I can create better AI in my games.

The part that was hardest for me was designing the enemies. As mentioned before, I originally tried for waypoints for my enemies which proved harder than I thought. The enemies would get stuck easily inside cubicles or around the clutter, thus rendering them useless as far as enemies go. When I searched online for enemy ideas, a few sites discussed the nav mesh for them. This is actually what I ended up using and it does exactly what I wanted it to do: find the player and attack without hang-ups. When I initially created the enemies, I had asked for some pre-obtained models from the asset list Dr. Chastine had. I learned quickly that I didn't understand how the legacy animator worked in Unity 4.6 which prevented me from using a few of the models. To this point of writing this post mordem document, I still have no clue as to how the legacy animator works. Balancing the enemy spawn rate, enemy health, and enemy damage took time and a few play tests to get to an acceptable level. Much like AI, I will never be done adjusting this because just a little more or a little less can always be seen as an improvement.

For this game, the part that took me the longest to do was once I acquired the assets from the requisition I submitted. The office models, the hospital models, and the textures took me about 3 weeks to fully implement. Once these assets were fully implemented, the game changed considerably for engagement purposes. The purple, white, and green textures were no more. Placing the smoke and spiderweb effects was pretty enjoyable and I will definitely include things like this in future games.

The audio in the game is made from me and one of my pets. I used Audacity to change the pitches and reverse the sounds. This summer will be great for me to look into FMod for further audio education. The player as an ambient sound attached to it so that there is always a sound going on. Each enemy has a unique sound associated with it when it gets hit by the flashlight and when it comes to the final boss, that enemy has a constant sound being emitted. Later versions will have all enemies having a constant sound being played which will be separate from the being attacked sound.

At one point of the game, I attempted to put in trigger points so that a jump scare could occur. I quickly decided not to continue on with this until the game was fully completed and had a few solid test runs before introducing this. The jump scares could create a very difficult path to become impossible to pass, in which I'd rather the player pass those parts and continue on in the game. I plan to implement these jump scares in later versions.