For our group project, Shenuka and I worked on Galaxyze, an open-ended VR environment that allows the following interaction/engagement:
user controls the stars in the night sky by rearranging pebbles on a beach.
user is able to impact on a cosmic level with a trivial action.
The goal for this project is to let the user become a creator in a fictional world that is also quite relatable, in the sense that it’s a deserted island surrounded by the sea (much like Saadiyat bubble). The user can draw patterns in the sky with trails and constellations, feeling powerful but also isolated by their limited mobility in the world.
This idea first arose from a chapter from Italo Calvino’s Invisible Cities and we wanted to explore the “stuff of story” – about makes a story, the lack of a narrative and he open-endedness of it.
The environment consists of the following, based on the idea that the user must feel small in the vastness of the cosmos above and the ocean below.
Island: Terrain tool
Pebbles/ Water: Unity Asset Packs
Stars: Spheres with glowing material
Sky: Night sky skybox
Trails: Particle systems set to fade with time
the environment
The scripts we wrote are the following:
Mapping the position of the stones (x and z values) to the positions of the stars.
Detecting when all the stones have been thrown in order to play the ending animation.
Switching from the ambient music to the ending music.
Galaxyze in its final stage
Looking back, our project came out differently from how we imagined it in the first place. We were able to complete this project thanks to multiple player testing, experiments, and feedback from peers and Sarah.
Here’s a footage of Craig testing it out at the IM Show exhibition (mute sound, a little noisy):
Galaxyze in IM showcase
Some challenges we faced were mainly in writing the scripts because it was the first time for both of us to use C#. However, after ample research, late-night experiments, crazy amount of logs, tests, and help from friends, we were able to solve them all!
If we had more time, I think we could work more on the environment and making it feel more alive. This could involve adding:
splashing noises and wave sounds
dolphins jumping out of the water from afar
more stars in the sky
shooting stars here and there
different types of assets to pick up – not just pebbles, but also shells and other broken/abandoned remnants that we find on the beach these days. I think this could add more to the backstory and give more contextual evidence as to where they are
Inspired by my first project of creating a meditative space and the second project of observing users hijacking the intended goals of my project to throw trash as far as they could, I wanted to create a stress relief room that would explore users’ destructive tendencies in VR and also challenge myself to depart from the normally slow, poetic experiences I design. I had seen several videos of “Rage Rooms” where the players just started smashing plates and breaking computers. All for the price of $45/hour (or along those lines). The existence of such rooms seemed terribly wasteful and also inaccessible to the everyday person who could not afford to shell out so much money in the name of self-care. I also knew that I wanted to create a project that had a compelling need to be done using the medium of VR. Thus, I began thinking of interactions I could create in this room. I began with smashing plates, hitting a punching bag, and burning things in a fire.To create a sense of story, I thought of dividing one wall into three partitions-one for each interaction. As each interaction was done, one part of that single wall would fall onto the ground, revealing an open forest sky. The room itself was going to be a typical living room with a couch and TV and a shelf of china plates. I decided though that I wanted to have a more peaceful environment to promote stress relief, but I also didn’t want it to be soothing because I wanted players to feel motivated to break things apart. Thus, I was inspired by Japanese training dojos, I created an environment in the same spirit…meditative but still conducive to action-oriented interactions.
The interaction of smashing plates turned out to be very satisfying. Once I fixed performance issues of instantiating so many objects at once, I made the plates the focal piece of my experience by placing them in the center of the room near the player. I placed them on wooden tables to match with the ambience of the room, but if I’m being honest, I would have liked to design my own tables had I more time as I was pretty dissatisfied with the aesthetic of the tables in the asset store.
I had a fire in the middle of the room and when one threw a notebook in the fire, the notebook would dissolve. This was pretty dissatisfying and the fire looked weird, so I scrapped this almost immediately. An interaction that I felt sad destroying was the ball throwing. I really liked how if the player threw the ball in the box, a white line appeared, marking the site of a successful throw. I thought players would be excited to get the ball in from further away, but in comparison to the plate smashing, less satisfaction was derived from the ball interaction. Furthermore, the ball was just annoying to get inside the box and its bounciness differed too much from the rhythm of the plate smashing, so I had to scrap it, though I felt a bit sad doing so.
awkward fire!
I began with a sunset skybox that was slightly dark with stars in the sky. I intended it to be spiritual, but playtesting revealed that it was really just spooky. I loved the aesthetic of it, but did believe I needed to have a more relieving feeling outside the room. I ended up creating an open sky so that there would be a more openness juxtaposed with the constraints of the room.
the scrapped sunset
I found a cool hatchet in the asset store, so I decided to incorporate it into the experience. I thought it would be fun for the player to smash printers with it and break the printer into pieces. However, the breaking of the printers was into awkward clumps that I couldn’t seem to adjust no matter what in Blender. Thus, I decided to just destroy the printers and have an explosion, which I hoped would create a satisfying feeling.
Having a hatchet though added a specific affordance to the piece. In having access to a hatchet, the player would expect to be able to smash more things beyond the printer. Thus, I added the ability to destroy the walls…instead of having a partition for each interaction, I just split the walls evenly separated by columns. I tried to change the texture to crack the wall everytime it was hit with the ax to give it a stronger depth of experience and make the user feel more powerful, but it looked quite horrible as the crack was not at the site of collision. Thus, the wall was destroyed with each hit.
With the destroying of the walls, the sky looked quite open and I wanted to add something that contrasted with the interior of the room. Something that felt playful and nostalgic. I began with bubbles, but they felt too light. Clouds looked too bad. Then, I settled on balloons and ended up having bubbles blow out each time the balloon was popped just because I really like bubbles (I originally had a laser gun). I decided to replace the laser gun which felt too light with a bow and arrow because I remember how powerful I felt using the bow and arrow in the VR Maze experience during our class trip.
However, having balloons when the walls were opened up really contrasted with the remaining floor in the room and I also wanted to convey a sense of resolution to the player. I ended up switching the floor to white and removing the roof, creating a colorful marquis at the end and adding bright white particles that danced to the floor and changing the music. The combination of all this with the balloons conveyed a sense of nostalgic playfulness and magic.
I tried to make the logic of the space clear through the placement of objects. I tried to make the plates the first things the player saw so that they used their hands to pick them up and throw them. On the right, the hatchet was placed on a table, but the printers were on the floor so that the player knew not to try to pick them up. The longbows were placed on the ends of the room, one on each side so that the player could use them to pop the balloons.
In terms of music, the main background clip was an instrumental of Do I Wanna Know by Arctic Monkeys because it is quite pumped up and energetic but not overly intrusive. Listening to it makes me feel ready for anything. For the ending song, I chose a specific piano cover of Kygo’s Firestone because the song conveys a sense of happiness with a tinge of melancholia and is light in tone to contrast with the heaviness of the first song. I also tried to provide feedback to the user through sound. The shattering of the plates was accompanied by a glass shattering sound that I think contributed to the satisfaction of that interaction. Hitting the hatchet produced a thud sound. Popping the balloons also had a satisfying popping sound. Smashing the printers also produced an explosion sound, but to be honest, I wish I had used a shorter sound as the one I used was a bit too unnaturally long of an explosion for that specific collision.
Reflecting on the overall experience, I am proud of what I accomplished as a one person team. I really wanted to challenge myself to become more comfortable with Unity script, so I wanted to create interactions that didn’t necessarily rely on the SteamVR interactions (though I love the Throwable script. Makes life so much easier). I had a lot more scripting than my last project and feel quite comfortable now. I also really enjoyed hearing the positive user feedback at the showcase-no one noticed the bugs surprisingly. It was nice to hear a couple of people expressing how it was a stress relieving experience despite me not mentioning my objectives to them. Overall, I have a tendency to go off on tangents, which is great when trying new things creatively that improve your project or take it in a new direction, but it’s not so great when you divert too much off course that you end up breaking something. I broke my project so much I don’t know which branch is the real one. I also realized that because I don’t necessarily have clear objectives of what I want to accomplish, but rather just see what happens through the process, there’s never a finished state…there’s always more you can do.
There is definitely a lot of room for improvement. For one, I’d fix the buggy walls: the walls that just would not register a collision and break. I’d polish the design of the interior in terms of the objects in the room. I’d make the explosions smaller and closer to the site of collision. I’d improve the aesthetic of the instructions. I’d add the restart button. I’d fix the particles so they only started coming down during the ending.
Project Description: describe the space, the “storyness” it conveys, and the inter-relation between modes of interaction and the logic of the world.
As a kid, I was always fascinated by computers. How could they achieve tasks that are so inherently complex in a matter of seconds and with seamlessly little effort? Now that I am studying Computer Science, I know that every single computer-based task takes hours of algorithm design and coding implementation that breaks down the difficulty for the end-users. As such, I wanted to convey the difficulty of a computer-based task as simple as submitting an assignment through Gmail by taking full advantages of the features lent by Virtual Reality through the Unity Game Engine. In addition, I wanted to explore the idea of space, and how space is defined in a medium as nascent as Virtual Reality where the artists have a full range of control of the experience they want their audience to feel, see, listen, and fully engage in. As such, me and my partner Juhee decided to bring back a vintage piece of technology in Virtual Reality: the Windows XP computer. We want the users to feel enthralled by the space inside of a Windows XP computer, to enjoy the iconic green mountains laying against the beautiful blue sky. This scenery will be juxtaposed by the clock-ticking task of submitting an assignment via email. The user has to enter the computer, physically juggle through a bunch of documents that come from the folder icon to look for the assignment, enter google chrome, and submit the assignment. However, the former task is not as easy as expected as the internet connection is lost and our player must face the jumping dinosaur from Google Chrome. To submit the assignment, the user must kill the dinosaur with giant cactus. This allows for the mailbox to appear, where the user can submit the assignment and win the game.
Our project is a combination of a linear-storyline game with the abstractive storytelling of an iconic space. We hope that combining both elements will provide users with an experience that is both sensory satisfying and competitively fulfilling.
Originally, the theme we chose for this project is “close the door”. However, after implementing the project, we believe the scope of our theme expanded. The theme is touched upon when the internet connection is lost and the user is stuck in the Chrome environment with the dinosaur, with no escape other than to garner the courage to fight the dinosaur or succumb to their inevitable death. However, given the exploratory nature of our ideation process, the user can interpret the storyline the way they best see fit. Is the door really being closed after entering inside a computer or are we opening the door to a world where humans can live in a digital environment? Is the dinosaur a friend or a foe, acting out of spite towards an intruder or merely following the strings of ones and zeros that tell it to jump on top of every obstacle that lies in front of it? These are the questions we hope our users take with them, and we expect that our projects leave users with more questions than answers.
2. Process and Implementation: discuss how you built the space and design choices you or your group made. What did the brainstorming process involve? How did you go about defining the logic of this world? What were the steps to implementing the user’s role? Share images or sketches of visual inspiration or reference, including the storyboard/layout.
Idea Development:
Initially, our team was just excited to play with the idea of entering inside the Windows XP Environment. However, given the limitless provided by this idea, we relied heavily on several playtest sessions and feedback from different individuals in order to narrow the scope of our project to the point where it was playable, achievable, and entertaining enough.
Prototype for feedback generation:
Our initial prototype we relied for user-feedback and playtesting was composed of two scenes. One scene was just a monitor and that was interactable and the second scene was just a green terrain with three computer icons.
We partook in a total of 4 playtest sessions and one idea-critique session with our Professor Sarah Fay Krom. After the playtest sessions, we decided to use the task of submitting the assignment in order to give the users some form of direction in this highly exploitable world. The storyline after the playtest sessions was the following:
Initial storyline diagram
However, after talking with Sarah, we fixed several logical mishaps that were affecting our storyline. The first one was that the Google chrome Dinosaur signified lack of connection and it didn’t make senses that the user would get stuck in the internet after loosing against the dinosaur. The second one was that initially we wanted to kill the dinosaur with the assignment itself. Sarah recommended that we instead kill the dinosaur with the cactus as this is what happens in the real-life version of the game. We incorporated this two pieces of feedback into our ultimate version of our storyline:
Storyline
User is in a room, the user clicks on computer
The user is inside the Windows XP computer
The user must get the assignment from the folder file
The user must go to google chrome to submit the assignment
The user is inside google chrome. The dinosaur approaches the user and attempts to jump on him/her. The user must grab the cactus to hit the dinosaur three times and kill it.
If the user gets attacked by the dinosaur three times, then he is sent back to the initial room scene. Go back to step 1
If the user attacks the dinosaur three times with the dinosaur, then the dinosaur disappears. Go to step 6
Gmail icon appears and the user must put the assignment in the icon. Game ends
Technical Implementation
Scene Design:
Scene 1: Room with Windows XP compouterScene 3: Combat StudioScene 2: GreenMountains, icons, and blue skyAll three scenes merged into one
All three scenes were placed in the world and the transform.position of the player was changed in order to bypass the issues provided by the Scene Manager in Unity. The initial scene was the monitor was located in was designed with the early 2000s look in order to match the old-look of the monitor. The 2nd scene was designed to emulate the Windows XP background, with mountains created by modifying the height of the terrain and the skybox changed with one found in the asset store that we believed best resembled the cloudiness and blueness of the Windows XP background. The third scene was a combination of a combat studio and the style of Google Chrome’s design. .We wanted to give the world an appearance similar to that of a combat studio because the user would be confronted, 1v1, with the dinosaur. As such, we went with a confined box environment, which creates the solitary, depredatory aura that we want the user to feel. We also decorated the box with Google Chrome’s iconic green, yellow, red and blue colours on the sides of the cube, with one side being the google chrome icon itself in order to let the user know where they are at all times. The entirety of the project was accompanied by the Windows XP startup music in order to fully encapsulate the user with the illusion of being trapped in a Windows XP computer.
Scripts
Destroy Monitor: This script is attached to monitor in initial scene to ensure it is destroyed after the player is moved to the next scene.
Mailbox Script: Script attached to the mailbox that ensures the game is restarted after the user wins the game by submitting the assignment to the mailbox
Follow Target: Controls the behaviour of the dinosaur and ensures that the dinosaur follows the user by using the Vector3.Movetowards function. A force is added to the rigid body to simulate the jumping. And counters (namely “lives” and “hits”) are used to know the times the dinosaur is being hit.
Important code design in this script;
Vector3.Movetoward: This function simplified my code immensely. It boils down a lot of the code that I did before to make the dinosaur follow the target as it literally makes the object follow the object with an incremental change in position after every frame and it also changes the rotation of the object so that it looks at the target.
Rigidbody.addforce: Before, I was trying to literally hardcode the position the dinosaur had to be when it jumped, which seemed unnatural as the dinosaur would disappear and then appear somewhere in the air and then fall down. By setting the ForceMode to Impulse and determining the position in space you want the dinosaur to be after the jump, this line of code creates a natural jump of the object to the desired height.
Quaternion. Euler: Something that was happening after the force was added to the rigidbody was that the dinosaur would move amongst its own axis in space. In order to stop this, I froze the rotation of the Game object using the quaternion.euler function in the Update function so that it remains in place within its own axis after every jump.
Lives and hit counter: The lives and hit counters are an essential variable in the dinosaur that determines a lot of functionalities in my project. Whenever the number of hits is equal to the number of lives assigned to the dinosaur in the inspector, the mailbox appears. The mailbox then detects a collision between itself and the assignment to determine the win condition. This can be further appreciated in the mailbox script I attached to the mailbox.
Coroutine and Delay function: I also learned about coroutines and implemented them in the script as well. I used them to cause a delay between every jump as the jumps were happening very frequently frame after frame. I also added the coroutine on the collision detection so that the number of hits between the dinosaur and the player was reduced as a lot of collisions were happening frame after frame too.
Foldercoll: Script that instantiates papers and the assignment when the folder icon touches the ground.
Sceneswap 2_1,scenesawp 2, and sceneswap: Changes the transform.position of the user whenever the user throws the monitor (scene 1 to scene 2) , the user puts the assignments in chrome(from scene 2 to scene 3). In scene swap 2 and 2_1, 2 detects a collision between assignment and chrome icon and sets the assignment collide boolean to true, which is then referenced be Sceneswap 2_1 to change the transform of the user to the next scene.
Dino attack; Script that keeps track of the number of times the dinosaur attacks the player. If the lives are exhausted, the user loose and the game is restarted.
Reflection/Evaluation: This should discuss your expectations and goals in the context of the what you felt was achieved with the finished piece.
All in all, the project succeeded in raising questions on the possibilities allowed by VR by allowing us, the designers of this world, to exploit the untethered territory of vintage technology by bringing it to life. We believe that this project was able to achieve its goal from an ideological perspective as it proved to spark questions and positive comments on every user we player tested it with. Indeed, most users started questioning the reason why they had to fight with the dinosaur. Others saw the dinosaur as an immediate threat as evidenced by their screams after they first had the majestic creature in sight. Others would just spend a couple of seconds enjoying the scenery of the Windows XP background. This was really fulfilling as we wanted each user to have a different experience when playing our game under the same assigned task of submitting the assignment and fighting the dinosaur. However, there are some technical bugs that need to be fixed:
In chrome world, the assignment goes far away
In the hastiness of fighting the dinosaur with the cactus, some players would throw the assignment far away and wouldn’t be able to catch it after beating the dinosaur so they could win the game. Maybe adding teleportation would have solved this problem, in order to give the user more freedom of movement. Also, teleportation would have made the final fight scene against the dinosaur more exciting as the user could escape the dinosaur and fight it at the same time. This problem could have also been solved by adding box colliders to prevent the assignment from going beyond reach.
The initial scene is too big
Scaling our scene was a big issue. When we made the scenes, they were done at a very small size, which also affected the gravity of our objects. Resizing all of the game objects to an appropriate Unity-unit size would have made the experience more enjoyable.
Make a more robust, complete UI system
Definitely, the UI we implemented in our project wasn’t as complete as it could have been as we still needed to vocally guide users through our game despite the fact that we added the UI canvas with the instructions. Maybe incorporating audio feedback in every scene would have helped the users know what to do at every step in a more succinct manner.
In retrospect, this project was a nice way of culminating a semester long endeavor of exploring the possibilities brought forth by Virtual Reality and it empowered me to be an artist,designer, technological philosopher, and software engineer all at once.
For this project, we will go back in time to revisit a staple piece of technology: a Windows XP computer with the classic green valley and blue sky background. Our inspiration came after a rigorous brainstorming session were we touched base on a lot of ideas that interested us. After presenting some of the ideas to the class and after further deliberation amongst our group, we decided that this idea provided the best balance between abstract storytelling and realistic implementation considering the timeframe and themes available. The theme our piece will be based on is: “close the door” and we hope to do so in an interesting way, giving the user the possibility to decide the ending of a story where, inevitably, the door will be closed.
As seen in Scene 1, the user will be in a room with his old-style windows computer appearing in front of him/her. As he/her clicks on it, he will be sucked inside the computer, shadowing the idea presented by Richard Moore in the Disney Animated film Wreck it Ralph 2. In order to escape the computer, the user will have to click on a set of icons in a predefined sequence. Each icon will transport the user into a different scene, and it is up to the user to click on the right set of icons to escape.
Possible Assets:
Windows XP Icons
Furniture for the room
Laptop
Paint brushes (Paint Program)
Interactions to Design and Code:
Clicking on the icons
Scene Manager to move from one scene to another
Sound:
God-like voice that tells the user the situation he is trapped in and gives him clues to possibly escape the computer
Sound effects for clicking on different icons
Sound effect of getting absorbed into the monitor
Peaceful background music when the user is in the green valley
Lighting:
Stark contrast in lighting between the room and the inside of the computer.
April 12
In preparation to this project, I decided to start looking into different logistical things that need to be figured out later on but will be beneficial to do so early in order to maximize workflow efficiency amongst all of the team members. First off, I thought it would be a good idea to think of ways we could use GitHub in order to work simultaneously on different portions of the project. As such, I created a GitHub repository to ease collaboration:
Something else I decided to start looking into was the different options we could look into when designing the User Interface of our project. The UI can be manifested in different ways, but one of the clearer options is to add a beginning and end screen to add a conclusive narrative to our piece.
In preparation for the rough prototype deadline tomorrow, we decided to build a rough version of our two initial scenes in order to show the class the direction our project might go into.
We started with a blank scene, and we added a monitor we got from the asset store. One of the problems the monitor was giving us was that its screen had a predefined animation sequence. We had to remove that and change the canvas of the screen to the Windows XP background.
We also created the second scene, which was composed of a terrain object we modified by changing its colour to green and by playing with the edit height/edit texture tools to create mountains (really bad ones as it is a prototype).
We also added the interactable script (and all of its dependent scripts) from the SteamVR library to the monitor and the icons. We also added a sceneswap script to the monitor. This script checks a change in the transform.position.z (any coordinate variable could be used to make this logic work) of the monitor and unloads the current scene and loads the new scene whenever this change occurs.
April 15
Playtest Session #1
In class, we were able to get meaningful feedback from the class from our Playtest session. One of the problems our project has is that it can go into many different directions. Since there is a lot of staple icons we could recreate in our project, each of them would require an ample amount of work to the point where each one could be a project in it of its own. For example, recreating a Paint icon that would allow users to create any form of Paint-generated artwork could be a project that exploits the artistic capabilities of Paint in a 3D virtual-reality environment. As such, we heavily rely on Ideation and Feedback sessions like this one in order to narrow the focus of our project.
This is some of the feedback we received in class after playtesting our prototype:
Keep interactions and everything in one scene
Virus takes over the computer. You need to defeat the virus
Maybe after you defeat the virus you become king
Generally, people would like to fight against some of the iconic enemies you can find in a computer (a.k.a a virus). Maybe giving the user a predefined task like this one could narrow the focus of our project as it is really open-ended as of right now.
April 17
Having Sarah Rotberg in class was definitely useful as it brought to our attention something that we did not previously consider. She recommends her students in her VR class that their projects should keep the users entertained for a minimum of three minutes. Even though we didn’t have time in class to present our project idea to her, this feedback is useful as we are looking at ways of narrowing the focus of our project. Maybe giving the user a task to do could be too short of an experience. The idea that we have right now is to make the user submit an assignment. However, in terms of the VR context of our project, how could we recreate a physical manifestation of such an Internet-based task that is engaging enough to keep the user entertained for a minimum of three minutes?
April 21st
Playtest Session #2
In order to have a better, more complete idea of the way we would like to direct the user towards a sequence of actions he/she must complete in our project, we decided to playtest our prototype with our friends without giving them any clue of what our project is about. Attached is a video of our playtest session:
Lauren
Steven
After letting our friends play our prototype, this is some of the feedback we received from them:
Things they liked:
They liked playing with the boxes
They had the sense that they were getting inside the monitor
Things they didn’t fully understand:
The transition from the monitor scene to the inside of the monitor scene wasn’t clear. Maybe have a loading screen or a shaking of the camera that creates a pause and indicates a transition from the room to the inside of the computer.
Things we could do to make the experience better:
Interact with something iconic on the internet (error 404 guy, google chrome dinosaur)
Based on our playtester’s feedback and our previous idea of submitting an assignment, we would like to combine both ideas into one. The iconic character our users would be interacting with is the jumping dinosaur in google chrome. We chose this character in hopes that it is iconic enough for any common user to familiarize with and to incorporate the internet on a controlled environment that is both technically feasible and significant enough to send our message across. This message, we hope, is to allow users to physically engage in a computer-based task in a way that takes full advantage of Virtual Reality.
Task Division:
Junior (Interactions):
Scene swap (done)
Throwing objects (done)
Make a bunch of papers appear from the folder after its thrown
Grab one of the papers and put it close to the google chrome icon
Make a dinosaur appear that jumps
Dinosaur wants to get close to you and jump on you
Attack the dinosaur with the folder
Juhee (Scene Design):
Room scene
Green valley (inside the computer) scene
Stuck in the internet scene
Google chrome scene
Adham (User Interface and sounds):
Beginner and ending screen(2) (one for each ending)
Instruction to users on what to do on each step of our story (either by a UI canvas or through sound)
When inside the room, the user must touch the computer
When in the green valley, the user must throw the folder to make a bunch of papers appear, grab the final version of the paper, and put it in google chrome
When inside google chrome, the user must attack the dinosaur with the assignment three times and he shouldn’t let the dinosaur jump on him
If the user wins, then he should go back to the original scene and he should be notified(somehow) that he has successfully submitted the assignment
If the user loses, then he should be indicated that he has been stuck on the internet.
Sound effects that indicate transition from one scene to the next.
April 24
Today I had a really useful Idea-critique session with Sarah. She mentioned a couple of things that we must bear in mind as we try to finalize our project’s concept:
Google Chrome dinosaur signifies lack of connectivity: This is an important piece of information that we must keep in mind. Our original premise was that after the dinosaur killed the user, the user would be stuck on the Internet and lose the game. How can the user be stuck on the Internet if the dinosaur only appears when there is no internet connection in the monitor? As such, we fixed this logical mishap by making the user restart the game. This not only fixes our storyline’s logic but also extends the playtime to the user as it makes him/her play the game a couple of times until they are able to beat the dinosaur and submit the assignment.
Kill the dinosaur with a cactus: Before, we wanted the user to kill the dinosaur with the assignment. However, Sarah recommended that we could give the user a cactus to kill the dinosaur as that is what actually kills the dinosaur in the real-life version of the game.
April 27-28
One of the main things that we must accomplish is to make the dinosaur jump and follow the user. As such, I created a script that follows the user (namely the target) and starts jumping after if it reaches a certain distance from the user. In every frame, I calculate the vector3 distance and the magnitude between the dinosaur and the player and I make the dinosaur aim at that direction and change its transform every frame with a predefined speed.
Made the jumping dinasour script
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class followTarget : MonoBehaviour
{
public GameObject target;//the target dinosaur will go to are going too
public float speed;//the speed of enemiess
public float jumpingdistance;//distance between object and target
public bool jumped = false;
public float jumping_height;
void Start()
{
}
// Update is called once per frame
void Update()
{
Vector3 path = target.transform.position – transform.position;//calculate the path to target
path = path / path.magnitude;//calculate only the direction of the path
transform.position = backwards;//make the enemy go backwards if it collied with the player
jumped = false;// set the boolean backl to false to restart the jumping action
}
}
}
I also made the destroyer script that destroys the player after it has been jumped on 3 times. Instead of destroying, the player will be sent back to the initial scene to start all over
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class objectDestroy : followTarget
{
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
if (jumpcounter==3)
{
Debug.Log(“You died”);
Destroy(target);
}
}
}
One of the problems I encountered while making this script was that the user could not be detected during game time. This comes as a result of using the Scene Manager, which has two simultaneous scenes running: the scene the user is currently in and the “DontDestroyonLoadScene” which carries the user (and any other objects the user was carrying from the previous scene) into the new scene. I didn’t fully comprehend the complexity of this problem as I was prototyping the jumping interaction in my computer with boxes.
Given the little time, there is between today and the project submission, one solution that was proposed to me by my classmate Max is to include all of the scenes into one and just change the transform.position of every object into the position of the new scene.
May 3-5
This weekend I worked on Instating Paper objects whenever the folder Icon collides with the ground. We also worked in finishing up the green valley scene and in uniting all 3 scenes into one to bypass the “DontDestroyonLoad” Issue.
What this script does is that it instantiates a new paper Game Object after every collision the folder has with the terrain. The paper was created out of an empty cube object that was then given its paper look by adding a paper material on it. There is also a counter that limits the number of papers that can be created after every collision with the terrain (10 collisions maximum). I also created a Random Number generator function that creates a random number between a range of number (for this project, this range is set between 1 and 10) so that an assignment paper can be instantiated only once and randomly. The assignment paper is the same as the other paper objects with the addition that canvas was added on top of it with the text “Assignment”.
Juhee and I also worked on doing the final touches in our Green Valley scene. We fixed the mountains and changed the skybox to one with more clouds that are vanishing as we thought it gave the scene a more invigorating, powerful feel to it. The mountains were also carefully designed for, not too big or not too small, in order to best recreate the vintage Windows XP look.
Juhee also spend a fair amount of time designing the dinosaur object. She made it out of a lot of cube objects to give it its iconic, pixelated look.
We also decided to create a Google chrome world, one that sends the message across that the user just landed in Google Chrome but it an abstract way. We also wanted to give the world an appearance similar to that of a combat studio as the user would be confronted, 1v1, with the dinosaur. As such, we went with a confined box environment, which creates the solitary, depredatory aura that we want the user to feel. We also decorated the box with Google Chrome’s iconic green, yellow, red and blue colours on the sides of the cube, with one side being the google chrome icon itself in order to let the user know where they are at all times.
Finally, we decided to merge all three scenes into one scene in order to bypass the “DestroyonLoad” issue that we had as our player traversed one scene with the other. In order to do so, we made all the Game Objects in the 1st scene and the 3rd scene as children of one empty game object respectively. Then, to avoid any issues as this is a major change, we copied the entire Project File to perform all the major changes in a copy. We then copied the two game object’s from the Project copy’s assets’ folder in the into the Original Project’s Assets Folder. This allowed us to drag and pull the entire scene from our projects asset’s folder inside the 2nd scene(Green Valley Scene).
This merging also required us to change the sceneswap script we had. Instead of using the SceneManager, we just changed the transform of the object to the position we wanted them to be inside the scene.
May 7
Playtest Session #3
Given that we have the scene transition and the dinosaur script done, we wanted to see how the an user would react to this additions so we could get feedback on the experience we are subjecting our players to.
Steven beating the dinosaur
Here is some of the feedback we got from this playtest session:
The size of the dinosaur is nice because it makes you feel like there is a threat.
Add some form of feedback that lets you know where the dinosaur is once you arrive at Google Chrome
The premise of the game is cute, and I would like to continue playing it even more.
May 10-12
This weekend, we focused on finalizing the final interactions necessary for our game to be complete. So far, we have the assignment instantiation, the scene swap, and all three scenes merged into one. Now, we need to finalize the winning and restart conditions, finish the dinosaur script and fix the monitor’s destruction (the object is still carried by the user as it moves from scene 1 to scene 2).
To fix the destruction of the monitor’s script, a simple script attached to the mailbox sufficed.
As highlighted above, after there is a change in the transform.position of the monitor, the object will be destroyed.
Another major change that we had to achieve to achieve our project’s full fruition is the dinosaur script. This script has a lot of major components that deal with major parts of our project and such will be explained further in the upcoming paragraphs.
Vector3.Movetoward: This function simplified my code immensely. It boils down a lot of the code that I did before to make the dinosaur follow the target as it literally makes the object follow the object with an incremental change in position after every frame and it also changes the rotation of the object so that it looks at the target.
Rigidbody.addforce: Before, I was trying to literally hardcode the position the dinosaur had to be when it jumped, which seemed unnatural as the dinosaur would disappear and then appear somewhere in the air and then fall down. By setting the ForceMode to Impulse and determining the position in space you want the dinosaur to be after the jump, this line of code creates a natural jump of the object to the desired height.
Quaternion. Euler: Something that was happening after the force was added to the rigidbody was that the dinosaur would move amongst its own axis in space. In order to stop this, I froze the rotation of the Game object using the quaternion.euler function in the Update function so that it remains in place within its own axis after every jump.
Lives and hit counter: The lives and hit counters are an essential variable in the dinosaur that determines a lot of functionalities in my project. Whenever the number of hits is equal to the number of lives assigned to the dinosaur in the inspector, the mailbox appears. The mailbox then detects a collision between itself and the assignment to determine the win condition. This can be further appreciated in the mailbox script I attached to the mailbox.
Coroutine and Delay function: I also learned about coroutines and implemented them in the script as well. I used them to cause a delay between every jump as the jumps were happening very frequently frame after frame. I also added the coroutine on the collision detection so that the number of hits between the dinosaur and the player was reduced as a lot of collisions were happening frame after frame too.
The winning and losing conditions of our project were determined by two scripts attached to the mailbox and the player respectively.
This script detects the collision between the mailbox and the assignment. If this happens, the entire scene is reloaded as the player won the game. Dealing with the SceneManager was definitely one of the biggest challenges I had with Unity this semester. Something that I learned after hours of testing different strategies in order to restart an entire scene was that the best way to achieve this is by deleting all of the game objects of the scene (including the player) and then loading the new scene. As such, I found this function “DestroyAllGameObjects()” that iterates through the entire hierarchy and deletes every single game object. I call this function before unloading the current scene and loading the same scene in order to achieve the scene restart condition.
Similarly, this script also detects for a collision between the user and the dinosaur. If the number of attacks supersedes the number of lives allocated to the player, then the scene is restarted. The restart process entails the same logic of destroying all game objects and unloading and loading the scene.
I also added a simple UI element to my project. I added a set of instructions that followed the player as most playtest sessions required me to explain to the user what to do.
May 14
Playtest Session #4
After presenting our project to the class, we wanted to add an additional playtest session so we could fix (if time allows) any last minute bugs in preparation to the IM showcase.
Alex playtest session
This is what Alex said after playing our game:
Add a counter in the UI that shows the number of lives you have left and the number of lives the dinosaur has.
May 16: IM SHOWCASE!
The IM Showcase provided the culmination of a month-long endeavor. It was a nice way to end the semester with a positive note and to show an audience of new playtesters the progress of our project. Generally speaking, people enjoyed the premise of our project. They liked the idea of getting inside the Windows XP computer and playing with the different icons, throwing the folder to the ground to generate papers, and fighting against the dinosaur. Most players would generally react in awe (to put it lightly) to the size of the dinosaur, and would generally loose against it as they had no idea of how to react to it. Attached is the different videos of player’s reactions to our game:
After this two-hour long playtest session, these are the main takeaways I collected from the players to improve this project:
In chrome world, the assignment goes far away
In the hastiness of fighting the dinosaur with the cactus, some players would throw the assignment far away and wouldn’t be able to catch it after beating the dinosaur so they could win the game. Maybe adding teleportation would have solved this problem, in order to give the user more freedom of movement. Also, teleportation would have made the final fight scene against the dinosaur more exciting as the user could escape the dinosaur and fight it at the same time. This problem could have also been solved by adding box colliders to prevent the assignment from going beyond reach.
The initial scene is too big
Scaling our scene was a big issue. When we made the scenes, they were done at a very small size, which also affected the gravity of our objects. Resizing all of the game objects to an appropriate Unity-unit size would have made the experience more enjoyable.
Make a more robust, complete UI system
Definitely, the UI we implemented in our project wasn’t as complete as it could have been as we still needed to vocally guide users through our game despite the fact that we added the UI canvas with the instructions. Maybe incorporating audio feedback in every scene would have helped the users know what to do at every step in a more succinct manner,.
Project Description:describe the space, the “storyness” it conveys, and the inter-relation between modes of interaction and the logic of the world.
The prompt that I decided to extend on was “close the door”, and the reason for choosing it was the idea of having doors as portals. When creating my projects “storyness”, I always kept the passing through the door as the middle, as a way to go from the beginning to the end.
THE STORY
You wake up in a room with no knowledge of who or what you are.
Clues around the room written on post-its, posters, books assist (or remind) you of what you should do.
Going through the wardrobe using the key, you get teleported to your spaceship, now taking your natural form (an extraterrestrial).
You are presented with a choice of what you should do to the Earth you have left behind, Destroy or Spare.
After choosing, a button appears and you move on to your next mission elsewhere.
Process and Implementation:discuss how you built the space and design choices you or your group made. What did the brainstorming process involve? How did you go about defining the logic of this world? What were the steps to implementing the user’s role? Share images or sketches of visual inspiration or reference, including the storyboard/layout.
I had a hard time choosing where the ending will be, I knew I wanted to start in an ordinary mundane room. And I wanted it to end in a location that would juxtapose that, but at the same time have the player be able to interact there as well. Because when I was play testing in the beginning, when the user would reach the second part their reactions would be “oh thats it?”, as if the clues in the room, the key, the leading up to the hidden door, all that climax was to something that did not satisfy. So deciding to make the location in Outer Space, with a busy, colorful, noisy environment achieved what I hoped to. And including even simple choices made the user feel like they had a mission, they accomplished something.
My projects inspiration mainly came from two ideas;
Doors as portals; Narnia, Monsters Inc., Howls Moving Castle
By this video I saw about how escape rooms are incorporated into a VR environment
Reflection/Evaluation:This should discuss your expectations and goals in the context of the what you felt was achieved with the finished piece.
This project was a great learning experience for me. In my two other projects, I didn’t really expose myself much to scripts and code writing. That made the beginning quite hard for me, but I was determined to use my resources to make what I had in my mind into the project space I have now.
I would often get carried away in the process, wanting to add more and more. Restricting myself from doing too much but at the same time letting myself be able to include what I saw as needed or fitting was important.
I’ve always had a special fondness for games that required the user to pay attention to the details to receive the “full experience”. I wanted to implement that ideology into my game; thus having every item in the room tailored specifically to bring more “story” to the story. I really enjoyed that part, creating details and seeing how different users catch up on different things.
I was debating before whether to put the hint on the UI canvas “Use the post its as clues” or not. I figured that since they stand out and are scattered around the room, they would act as the singular item that is constant. But I noticed I tended to tell users that post its are clues to use. Another thing was the issue with door #1, which required the pushing of a button. The issue was that when you’d press the button, the animation and sound would take a second, and that would prompt the user to press the button again. That makes the door open and then close. I noticed other users that would try the key at the first door, ignoring the button. So maybe if I put a label on top of the button to make it more obvious and to have the animation/sound start immediately it would fix that issue.
Going to the VR Park after our growing knowledge and interactions with Unity VR the past semester made me appreciate and see the games through a different perspective and appreciate and notice the little things I wouldn’t have otherwise.
The way the games (at least most of them) were presented was that the player was strapped to a seat in both real and virtual life which helped in immersing the user in the game without facing the issues of having the player walk out of frame or break through virtual walls
The games that included physical movements that I tried out were the maze game and the multiplayer game fighting zombies. The maze game had physical walls built into the area so even if the player tried to walk through the virtual walls they physically won’t be able to due to the barriers. On the other hand the zombie multiplayer game although the only barrier to limit the player was only located in the virtual world, but due to the scary zombies running and charging towards you, your “fake” barrier would actually prevent the zombies from reaching you, thus making the player realize where they are is actually the safest place to be, and this barrier is protecting them
1.Project Description: describe the space, the “storyness” it conveys, and the inter-relation between modes of interaction and the logic of the world.
The story is set in a dungeon-like room where there are various objects scattered inside. Although the room has a dark and spooky mood, the lighting has been coordinated so that the user can clearly see the various objects. This is because the task of the user is to find the various objects that are randomly generated onto the recipe clipboard and throw those ingredients into the cauldron so that the user can create the antidote, and thus win the game.
The story is set in a dungeon-like room where there are various objects scattered inside. Although the room has a dark and spooky mood, the lighting has been coordinated so that the user can clearly see the various objects. This is because the task of the user is to find the various objects that are randomly generated onto the recipe clipboard and throw those ingredients into the cauldron so that the user can create the antidote, and thus win the game.
Side View of the SettingTop View of the Setting
The user can interact with both the surrounding space and the various objects. The size of the actual space matches the size of the virtual space so that the user really feels that he/she is in that fictional environment. For example, when the user moves closer to the birdcage, the birdcage appears larger. However, some parts of te room were difficult to access and so we added the teleporting points in order to solve that issue. Some of the objects in the environment are interactive. For example, the user can use the trigger of the Vive to pick up the broom in the scene and throw it around, as well as the cat statue, clipboards, potions, etc. Another crucial interaction is the caldron responding when the objects are added into it. When any object is put into the caldron, the caldron spits out a blue-to-purple-to-pink bubbles, replicating the chemical reaction.
The Colorful Bubbles from the Cauldron
The logic of the world can be followed through with the narration, background clock ticking sound, the recipe, and the congratulating/game over scene. The introduction narration allows the user to understand what situation he/she is currently in. The recipe shows the task the user has to complete, and the user will get the congratulating scene or the game over scene, depending on how the user performs.
2. Process and Implementation: discuss how you built the space and design choices you or your group made. What did the brainstorming process involve? How did you go about defining the logic of this world? What were the steps to implementing the user’s role? Share images or sketches of visual inspiration or reference, including the storyboard/layout.
In order to create the space and design of our project, we first drew a rough sketch outlining the overall atmosphere and the placement of the objects in the scene. We then looked through the asset store on Unity and found different objects to use for building the setting and the scene.
Storyboard Sketch
Because this game is based on the idea of “poison(ed),” we had to place the user in the way that the user would know that he/she is poisoned, and thus, need to find the ingredients to make the antidote. We used two steps to achieve this – first one being the fact that we placed the user in front of the cauldron when they begin the game, and the second being the fact that we recorded a voice narration at the very beginning of the game explaining the user that he/she has been poisoned and his/her mission is to find the ingredients that are scattered around the room in other to create the antidote.
Top View of Cauldron
Side View of CauldronFloating Objects
We also wanted to make the game playable multiple times. Therefore, we decided to randomize the list of ingredients that show up on the recipe clipboard. That way, when the user plays it for the first time, the recipe might show, blue potion, broom, small green potion, cat, and brownish potion, but when the user plays it for another time, the recipe might show cat, skull, plant, plant, and blue potion. That way, the user can enjoy a different experience every time the user plays the game.
Some Example of the ScriptsMore Scripts
3. Reflection/Evaluation: This should discuss your expectations and goals in the context of the what you felt was achieved with the finished piece.
I am very happy with the outcome of this project. After building the base setting, we gathered various objects from the asset store to decorate the dungeon. Then, we wrote the scripts which were for the list of the ingredients, randomization of the ingredients, verifying if the ingredient that was put into the cauldron matched the ingredient listed on the recipe, the Timer, the If condition for winning and losing condition, the Text FadeIn, and the Blackout FadeOut.
During one of the earlier playback session, we received a feedback to include a voice narration that explains the situation and some kind of ticking clock sound that emphasizes the mood of having a time limit. In order to build the sense of time pressure, we used Audacity and created a background sound of the ticking clock, which begins ticking faster and faster as the two-minute time limit approaches. After incorporating this, we received feedback that the sound was well suited to the atmosphere and the mood of the game and the task that was given to the user.
What I realized during the IM showcase was that because the introduction narration does not explicitly say to put the ingredients into the cauldron, some of the users were simply collecting the ingredients onto one of the tables. To others, this was more instinctual, and the moment they saw the cauldron, they knew that that was where they had to put the ingredients.
Another thing I noticed during the IM showcase was the fact that some users could not locate the recipe from the first place. Because the recipe is originally on the floor, some users did not look down, but rather were always looking around (eye-level). Such users were confused and did not know where to start.
In order for this project to be improved, we should find ways to clarify that the task is to collect the ingredients AND put them into the cauldron from the introduction narration. As for the recipe, instead of having it placed on the floor, it should be placed next to the cauldron so that it is easier for the user to refer back to it. Overall, the game appeared a little difficult for first-time players, but many of the users got used to it quickly, and even if the user did not succeed the first time, the same user were “detoxicated” when playing for their second time.
Goal of game: The goal of the game is to gather ingredients on the list (which is generated randomly) and put the items into the cauldron to cure yourself from poison.
Was the goal met? Yes it was. The list is generated randomly each time the scene is started. 5 items of 34 are picked from the list using random number as an index to that list array. The game changes its state to won as soon as the items in the cauldron match the items in the winning list (with up to 5 mistakes possible).
Randomized list.Cauldron feedback after an item is put in.
Space description: The space was a dungeon looking area, with random objects flying around like potions, skulls, books, cat statues and etc. In the middle of the room there was a sarcophagus with a cauldron on it.
Room design.
Light: Light emission was used as the main source of light. None of the direct light sources was used. The emissive texture was placed on the chandeliers and the light probes were scattered around the room for the non-static objects to receive lights.
Light design.
Process and implementation: Since our topic was poison, we came up with the idea to make the user be poisoned and make him do an antidote. The initial expectations matched the result and we are extremely happy with that. It can be imagined like an escape room where the user has to meet the goals to escape. We started of with just placing a cauldron and and a sarcophagus in the middle of the room and tried writing the scripts.
Beginning of the project.
Then we added a collider inside of the cauldron to destroy the objects when they are collided.
object_destroyer collider
Afterwards we added the particle system to play on the collision with that object)destroyer collider
Particle system on collision
Then we added the list of object and made it randomize
List of objects.
Later on we added the winning list and made sure the it is randomized each time and printed on the clipboard. We also made a list that keeps track of objects that are being put in the cauldron and the winning condition became true as soon as the winning list matched the items in the cauldron. Also sounds were added. The main sound was the ticking clock sound which made the user feel more pressured.
scripts.
Reflection/Evaluation: The goal of the game was to make the user to gather ingredients on the list (which is generated randomly) and put the items into the cauldron to cure yourself from poison. As can be seen above, the goal is met and the user feels pressured due to the ticking sound. As soon as the user meets the goal, it makes him/her feel free and continue, alive or dead it depends on how the game goes (:
Our group has two different ideas. We are thinking of escape room, or having a experience that lets the user get absorbed into a different scene. We want to have a murder mystery room where the user can explore what happened in the room. The second idea is the user being absorbed into the computer screen and exploring what is inside the computer.
After discussing different ideas in class, our group has settled on the idea of the user getting absorbed into computer and landing in windows xp background. Based on this brief idea, I have created the storyboard.
We will try to have a room scene as a starting scene, and have a second scene – the windows xp desktop background (bliss).
Project Development
We are planning to divide the task into two different parts: scene building and interaction. I will be working on scene designing and building, Junior will be working on the interactions, and Adham will be working on both scene building and interaction. Our plan is to first make sure the absorbing interaction works before starting with the scene building.
For the scene the goal is to make the room look as realistic as possible. I am thinking of a typical student’s room with books, and a computer. For the Windows XP scene, I am still wondering whether it should be realistic or look more like it is still inside the computer. I will be finding different room assets and try to build the room. For the Windows XP scene I am wondering if I should build it from terrain tool.
We got the computer interaction working. Now we have a desk (a cube that looks like one) and a computer with Windows XP Bliss background on it. When the user lifts the computer it changes into scene two. It mostly looks like this.
This is going to be our rough prototype and we will move on from here after the feed back
Review Rough Prototype
We got the feedback from class. We need to narrow down the story. Although the initial idea was easy to come up with I was having some issues when it comes to narrowing down the story. There are so many different icons on a computer and I am not sure which icons should be part of the game and which shouldn’t. We were discussing as a group and we decided that we would need a goal in the game to have a set storyline. So we have decided on the goal as submitting an assignment. We wanted it to be relatable to players, who are mostly going to be students.
We also got some ideas from our classmates:
Keep interactions and everything in one scene
Virus takes over the computer. You need to defeat the virus
Maybe after you defeat the virus you become king
I have started with the room scene. I have built the walls and started with changing the desk. After that I added different furnitures that would be in a room. We found an room assets and a classroom assets that had all the things we needed. It was pretty simple to build, but I made sure everything looks realistic. I refrained from using any low-poly assets. The room is all done.
I tried playing it and the stair case seemed very off. I decided to remove the staircase and instead put another furniture in that space. The interaction of the computer works. Junior and I met and deciding on the story line. We have decided we would need a folder, where the homework would be placed. I thought it would be also fun to have different documents and have the player figure out the right one. We also decided on having chrome and email, where the player could submit the assignment.
Share Progress Update
We have created different icons in the second scene. We also tried using the terrain tool. We are having some issues with it because it tends to raise the terrain in a very unnatural way. We made different cubes and tried using the logos on icons to go on the boxes. We landlocked the player so the player doesn’t see how far the plane goes on. We need to improve the terrain and need to find a sky box that looks more like the bliss image. We are trying to figure out what kind of interactions would work with these icons.
I figured out how to make the terrain look better. We could change the smoothness of the brush and the size of it to make it look more like the Bliss image. I also found a sky box that looks exactly like the image. I also want to add some grass texture to the ground, because it looks like a green carpet right now.
We had our friends come and play test our game. They mostly enjoyed throwing the boxes. We were glad that they enjoyed the game itself. However, they also suggested we should add more features to make the absorbing part more obvious.
They gave us very interesting feedbacks such as : interacting with something iconic on the internet (error 404 guy, google chrome dino)
This is the story line we ended up with after talking to them
We could use the dinosaur as an enemy and have the player fight against it to be able to submit the assignment. So I have started building the dinosaur. I tried several different methods. First I looked at the image of the dinosaur and tried cutting out a shape that looks just like it. When I did that the problem was that the image of the chrome dinosaur was two dimensional
So when I cut out a shape using the outline of the dinosaur, it remains two dimensional. When the dino runs towards the player, it wouldn’t look like a dinosaur. The one option is to build the dinosaur from scratch. I started building it by using cubes but ended up with an ugly prototype version of it.
After talking to the professor we also decided we would use a cactus to fight with the dinosaur instead of an assignment like we initially thought.
As it became the very last few weeks till the due date. Junior and I started added some final touches to the scene. While Junior was working on different interactions such as dinosaur and its jumps, I started finalizing the dinosaur. I used small cubes to make sure the dinosaur looks three dimensional but still has the same look of the chrome dinosaur. Also I added some grass texture to the ground. We also found the right cactus asset that could be used to fight the dinosaur.
We are trying to figure out what sounds would be adequate for the game. We are planning to add voice over that explains the rules. I am also looking for different sounds for the game itself. For example, sound of paper rustling, serene background music, etc.
The dinosaur is finally done!
Before the due date we also moved the room scene into the second scene. It made the interaction building easier.
Now the room scene, the dino scene is all on the windows xp scene but put far away from where the player is so they wouldn’t be able to locate the other scenes. On the final weekend we focused on working on the interactions. We tried to make sure we have the assignment instantiation, the scene swap, and all three scenes merged into one working. We also need to work on finalize the winning and restart conditions, finish the dinosaur script and fix the monitor’s destruction.
We managed to have most of the features working but we still have some few bugs that needs to be fixed.
In chromeworld, assignment goes far away
In green valley, papers fall through terrain collider
Add teleportation to allow for world exploration
Initial scene is too big
Scaling problem: The entire world is too small
Assignment can sometimes be thrown really far away. Add invisible colliders to prevent this from happening
We have fixed few of them before the IM showcase, but haven’t been able to figure out all of them. Hopefully in the future we get to fixed these bugs and improve the game overall.
Windows Xperience is a project that lets the users to have a immersive experience in an environment that we are all aware of — Windows XP background. The aim of the project was to build an experience that opens up to new scenes, in order to make the game more complex and deep. The experience was set in three different scenes. Diverse scene experience lets the users to explore different scenes. The experience is made for the users to imagine what it would be like to be absorbed into a computer, in this case specifically into windows XP. When the user gets absorbed into the computer the user gets to play around with three different icons that are very distinct. There are Chrome, Paint, and Document Folder icons. Users can interact with two of these icons — Chrome and Document Folder. When following the instructions, the user can pick up and throw the Document Folder, which brings out objects that resemble assignments. Once the user finds the right assignment he/she can put it inside Chrome icon. Once the assignment is dropped inside Chrome icon, the user is placed in another scene. In this scene user has to fight the Chrome dinosaur using a cactus. Once the user has successfully defeated the dinosaur a mail box appears, and the assignment can be dropped in the mail box.
This project idea came from the routine of every university student. Once done with our assignments, we send it in through email, and sometimes we have obstacles such as not having wifi connection. We wanted to gamify this whole process and think about how the experience would be different inside the computer.
Process and Implementation
The process started with ideation. When we met as a group we both had in mind that we wanted to play around with different scene, and wanted the game to be relatable to the players. While we were brainstorming, we thought of an image that is so closely related to computers.
The image above is called bliss. Growing up a lot of us saw this desktop background. Surprisingly this image is a picture of a real existing field. So we thought, “What would it be like to build this beautiful field and blue sky?” Then we planned out the game. We wanted to have a initial scene that leads up to the desktop background scene. Below is our first sketch of our idea.
After creating this sketch we divided our tasks into two parts — environment and asset building, and interaction. My first approach to the project was starting off with building a room. After we got the interaction of being absorbed into a different scene figured out, I started building a room. The room consisted of several different objects. I wanted to make sure it looked like it was a room where someone was working on their desk. After placing objects like a desk, a chair, books and etc. the room resembled a students room. Below is an image of the room scene.
Next I started building the field. The field was the main scene, but was the easiest scene to build. I have used the terrain tool to raise the hills. Also found a sky box that is most similar to the image. The assets were created into a cube box with the logos on them.
The last scene was a box that contains the dinosaur, cactus, and a mailbox. The cactus and the mailbox was part of the asset packages that we have downloaded. The Chrome dinosaur on the other hand was built using cubes. Based on the pixel two dimensional image of chrome dinosaur, I have created a three dimensional one using cubes. Below is the image of the dinosaur
Reflection / Evaluation
After several user testings we were pretty happy with the result. However, there were several things that could be improved. For the storyline, in the future, we could expand the story by using different icons. For example, one of the suggestion was that we could make use of the Paint icon and let the user choose the color of the dinosaur they would fight in chrome. This is one example of how it could be improved, and I believe there would be several different ways to add more scenarios to the story.
For the scene building, the room scene scaling was off. If we had more time, it would make the experience more realistic if the scales were better done. Even during play testing, few of my friends mentioned how the chair seemed too big. Moreover, for the icons in the Windows XP scene, I want to to create 3D assets of these icons, making them look more realistic, and let the users to feel like they are actually inside the computer. Lastly, I would like to add more small plants into the scene to make the field look more natural.
For the sound, we had an issue of having a dinosaur sound in the beginning of the game. Because of lack of time, we didn’t get to figure out what exactly was the issue, but later I would like to add different sounds into different interactions to make the experience even more immersive.
This project was a huge learning experience, from ideation to implementation, and we are hoping that we would be able to improve this game in the future.
