The concept of Black Leaves was a horror RPG where you, the player, are put into the situation of a character who suffers from nightmares. From the beginning, you are put into an unsettling situation where you are awoken in the middle of the night by a sound and a nightmare. The beginning of the game has you play through the day-to-day life of the character, in which the world starts to deteriorate around you as the days go by. There are three chapters, the first being mostly completed at the end of the fall semester 2014. This game was created in Unity with one other person in the class. I have included the initial documentation and ideas that we had come up with at the beginning of the course and looking back at them, the game has changed quite a bit.
Our original ideas were written down and kept as a loose idea of what we could come up with, given that a part of the game should be finished and playable by the end of this semester. Since the genre of the game is horror RPG, we figured that we should have one over-arching evil throughout the game. There will be various quest lines that the player can choose from, only they wouldn't know that they were picking a quest line. It is to be a subtle aspect of the game that the player is to be performing daily tasks and what they choose to do affects the quest line they are on. A game's save point should be attainable within 30 minutes, that is, the player wakes up and performs the quest lines for that day. There will be NPC relationships seen at a later installment of the game once the player reaches the second chapter of the game - going outside the house. A few ideas we have are decapitations, deaths, and unsettling images seen throughout the game. We also like the idea of having the ability to leave a situation if the player gets too uncomfortable by running away. Some items we are considering for defense are a kitchen knife and a baseball bat. the ending of the game will not have a happy ending, just tragic and disturbing. There will be an inventory implementation because just like real life, you can carry more than one item. During the brainstorming of this game, my teammate mentioned an image he came across which was an eerie cherry blossom mural. This mural looks innocent from a distance but as you approach it, you realize that the 'blossoms' are reddish-pink hand prints. This leads us to a few of the example quests and situations that will be described later. We plan to build the basics fast so that we can spend more time on debugging and adding our own personal touches. These personal touches are graphics and auditory - my teammate more of the graphics while I am more of the audio.
The basic introductory scene that I thought of for this game was to have the player start the game where it is complete darkness. The player would hear a sound and then a panting sound coming from the avatar to indicate that the sound is unsettling. Eventually this will lead into the beginning of the game, which will be the tutorial. Learning the game in the beginning is always a helpful feature, especially when the game plays into the emotional level of the player. One example we plan to use is to have the player do a task in which the screen blurs with a sound effect. The avatar will then complain about having a lack of sleep due to having nightmares.
A few other examples that we have come up with are in the three chapters that we thought of. The first chapter will be at home which will include the tutorial. Some situations that will occur will be: the pet dog dies, items go missing, areas of the house get 'wrecked', bloody paw prints from the pet dog (a sound occurs where a dog whine is heard draws the player to investigate the blood filled bathtub or a wrecked room with bloody paw prints), shadow play, and finally objects can move in plain site or in and out of view. An example situation that will appear will be the dog being gored open in the bathroom where the player can look away. When the player returns, everything is normal as if nothing had happened. Another idea we have is when the player goes to splash water in the avatar's face via the bathroom sink, the camera moves towards the bathtub when looking for the towel. The player is given an indication that the curtain can be moved and when done, the dog is cut open and the camera starts to shake. If the player decides to leave the area, the camera stops shaking. If the player puts the curtain back, then the camera will stop shaking as well. If the player looks at the mirror, the camera stops shaking but an unsettling image will be seen in the mirror reflection. This event creates several events to follow: the player goes down the hallway in which a loud sound is emitted from the living room, bloody paw prints seen throughout the house, pillows being torn apart as if by a dog, whining heard throughout the house, and panting. Both of the audio sounds will become distorted the longer the player plays that particular quest line.
The second chapter will be outside which is the transition between home and work. A quest we though of was one that deals with an elderly neighbor. the player will have her mail in which he/she can choose to return it or not. The neighbor usually has a calming remedy for a sore throat or for anxiety so maybe she has something for nightmares. If the player decides to return it to her, he/she goes to the neighbor's house during a tea time party with other people from the neighborhood. When the player goes, the neighbor lady is seen missing her lower jaw, yet she is talking and having a great conversation. All NPC avatars will act like it's normal. To continue using the neighbor lady, any other time the player interacts with her, the avatar looks normal and is sitting on the couch watching television.
The third chapter will be in the avatar's workplace which is an elementary school. The mural mentioned above will be incorporated into this scene as to provide the unsettling factor. A few situations in this chapter will include: missing children, unknown source of laughter, lockers opening and closing, paint peeling, hands seen in slightly opened lockers, oozing floors under doorways, basketball bouncing sound being heard down the hallways, and finally the ending scene. The ending scene would be in a dark room where a television is flickering on and off. The quest that leads to this room is where the player has to locate a missing child. All clues lead to this dark room in which the player will see a dark silhouette of a child. When a flashlight is shown onto the silhouette, the child quickly turns towards the player's avatar in which the television has a burst of sound and light. This distraction will more than likely cause the player to look towards the television in which the child will teleport to the feet of the player's avatar. When the player looks down, the child smiles, showing sharp and unnatural teeth and then the child lunges at the player's avatar. This will be the ending of the game.
A few other considerations in the design and development of this game are as follows. The game will be played with WASD keys as well as the left-mouse and right-mouse. Q will be for inventory access while Esc will pause the game. We really want to us the scroll wheel for weapon swapping as well as designating the left mouse click to use current equipped item and the right mouse click to pick up the item.
The atmosphere that we want to create in the game is a variance of happy and hopelessness. The beginning of the game will have a stronger sense of happiness and being content which will lead to the ending of the game where the feeling of hopelessness and fear are the most dominant. As the game progresses, the rich saturation transitions to gray colors, indicating the sense of becoming 'lost' or 'consumed' by the overarching evil. The art style will be very close to being realistic but provide a sense of art deco seen in the 1920s of American history.
- First video
- Second video
- Third video
- Fourth video
- Fifth video
- Sixth video
- Seventh video
- Eighth video
- Ninth video
- Tenth video
- Eleventh video
- Twelveth video
- Thirteenth video
- Final video - part 1
- Final video - part 2
Available gameplay demo
var isQuitButton = false;
function OnMouseEnter()
{
//change the color of the text - this is current level to next level
renderer.material.color = Color.white;
}
function OnMouseExit()
{
//change the color of the text
renderer.material.color = Color.red;
}
function OnMouseUp()
{
//are we dealing with a quit button
if(isQuitButton)
{
//quit the game
Application.Quit();
}
else
{
//load level
Application.LoadLevel(1);
}
//When Light Intensity = 0, Transition to Game Over Scene
//When Player Clicks all 5 objects; Transition to Win Scene
//After X amount of time on Ending Scene; Transition to Credits Scene
This code is created in Javascript that loads at the beginning of the game. This allows for the player to choose the Play Game, Options, or Exit Game buttons and allows for the game to execute what was selected. The script itself was not challenging per say in it's entirety, but he level loading was a tough concept to grasp. When I originally created it, the button scripting was in working order but when I wanted to load the next level, the idea wasn't as easy as I had originally hoped. Instead, I made it so that the level that is pointed as has to be in the build of the game, inside Unity.
static var savedPosition : Vector3;
function Awake()
{
DontDestroyOnLoad(transform.gameObject);
}
This code is created in Javascript which, when executed, it does not allow for the coordinates to be destroyed when a new level is loaded or the future save option. This was a little tough to figure out at the beginning because I didn't have it originally set to Awake. Once I changed it, it worked as I wanted it to.
using UnityEngine;
using System.Collections;
public class NewBehaviourScript : MonoBehaviour
{
public static NewBehaviourScript Instance;
void Awake()
{
if(Instance)
DestroyImmediate(gameObject);
else
{
DontDestroyOnLoad(gameObject);
Instance = this;
}
}
}
This code goes hand-in-hand with the Don't Destroy on Load code above. This was created in C# in which I originally created the basic form from my 1302 class at SPSU. What this code does is decide whether or not to destroy the object once the level has been loaded. If the game object has the DontDestroyOnLoad script, it will not be destroyed upon loading the scene/level.
Wrong and Right:
There was a substantial amount of what went right and wrong with this project. In the end, we did create a game that was horror RPG based, but we didn't have open communication for the entire semester. This caused the game to change from what was originally documented and started, to what it is today. Below I will share what I feel went right and wrong for this project.
I originally wanted to do the horror RPG genre because I felt that it would be fun to do and I could display all of my skills that I have learned over the years. My teammate wanted to join up with me in the creation of a horror RPG in which we sat down and wrote out what we wanted in it. At first I offered to create the model of the house so that there was adequate areas for events to occur in and have it close to reality as possible. The original model was then replaced by my teammate for a smaller, more 'economical' version of an apartment which lessened the playing field for events to occur. No communication was made about suggesting the model change, it was just done. Seeing as I wasn't going to be the main graphical designer, I let it stay in the new form. If I had known that there were going to be other changes done without communication, I would have put my foot down at this point and asked for reasons why it was changed.
Given the fact that I have not taken any classes in scripting or animation, I've self taught a little bit. My teammate has taken one or both of those classes, so he was quick to create scripts and create the animations. I have provided the code that was in the game at some point but were removed in later versions. During this semester, I dusted off a few of my books that explain java scripting in which I was able to write the two separate codes. I furthered a C# script from my 1302 class where the game decides if an object should be destroyed or not upon scene load. The only code that is still used in the final version is the level transition code, which is used to start or exit the game. My teammate never communicated to me what needed to be coded or added to the game let alone what he had done already.
I took it upon myself to create the GUI that is seen in the game as well as the soap bubble icon with Equipped Item next to it as part of the inventory implementation. When I ran into programming/scripting errors with the inventory, I ended up importing a basic inventory I acquired earlier this year. I never had the chance to connect the currently equipped item from the inventory system to the GUI soap bubble icon. The inventory took some time to adjust for the needs of the game in which altering pre-existing code was problematic for me. My teammate seemed to have adjusted it correctly so that it did meet our requirements. The inventory was not needed at the conclusion of this semester because it was taken out at some point by my teammate.
When it came to audio, I used original recordings from my residence for use in the game. I created an ambient sound that follows the player around so that it can create a slightly unsettling sound, but also provide sound in the game. I've created audio samples and music in the past so I knew what I was doing when it came to the recordings. The recording software was something new for me in which I noticed that I get a bit more background/feedback in the sounds. I cleaned these up the best I could. There were more sounds I wanted to implement into the game but was unable to due to the fact my recorder broke. To go along with the original documentation and ideas, I had recorded the introductory scene where a sound occurs and the player hears a voice asking "What was that?". This was then to lead to the main menu screen in which the codes I had created would be utilized. This was not implemented in later versions of the game due to unknown reasons (lack of communication).
Originally the game was to have trigger or access points that would create an event that the player would see. For example, after the player did X, Y, and Z then sat down on the couch, there would be small objects that would move around. These were to be subtle yet noticeable by most people. When the model layout changed, this was dismissed due to the smaller area for utilization of said events. This then led to a simple quest list of tasks to do in order to progress in the game. The original events were as follows:
Introductory
- Get up out of bed
- Put clothes on (drawer opening)
- Get pants in closet
- Go downstairs to check weather
- First event occurs
- Watch tv
- Make a waffle
- Look through drawer near couch for something - keys
- Feed the dog
- Look for the dog (fail)
- Use bathroom + shower
- Do paperwork/comp work
- Laundry
- Play games
- Make dinner
- Do dishes
- Go to bed
- Same as day 1 - bathroom lights flickering
- House
- Turn on TV (very subtle movements occur here)
- Fix breakfast (make a waffle to wake up)
- Go back to TV (very subtle movements occur again - maybe not as noticeable)
- Hear something upstairs so go investigate
- Checked out upstairs- nothing there
- Hear dog get hurt in the bathroom as well as a drilling sound
- Shower running and see dead dog in bathtub
- Look away because sounds are heard downstairs as if something is running around and crashing through things
- Look back and dead dog scene is gone and shower is no longer running
- Go downstairs to check things out - bloody paw prints everywhere - decide to go outside
- Check mail - a) take mail to neighbor b) don't take it
- School
- Find 2 kids - a) find them with another kid b) find them on your own
- Find 1 kid who got hurt (this is the kid at the end of the game in the corner) - a) find him on own b) don't find him