Treasure Trackers Final Documentation

Treasure Trackers Documentation:

Group: Findlay, Lily, Julie

Description of Game:

In our underwater video game, we start off with a little bit of backstory of a sunken treasure. A father and daughter are on a diving trip in the Cayman Islands, having a conversation about sunken treasure, and the daughter decides to embark on a diving adventure to find the treasure. Now you are diving from the perspective of the daughter and must help her find the treasure! As you are diving, you must navigate her way through the sea’s dangers (stinging jellyfish) and receives hints along the way to continue your search (guiding the way to find the shipwreck) and clues once you find the parts to continue the journey. However, throughout this adventure, you have a time constraint because your oxygen tank is slowly diminishing. And getting stung by jellyfish stunts your oxygen level even further. Once you reach the treasure, you have one more task: bringing the treasure back up before your air runs out!

Process:

From the start, we knew we wanted to focus mainly on the sound aspect of a game to create a more realistic environment to immerse the user in. And we stumbled upon the idea of an underwater themed game. We were inspired by Assassin’s Creed: Black Sail and Uncharted 4: a Thief’s End. We all acknowledged how different the environment sounds when you are underwater, and wanted to recreate that feeling and allow everyone to experience these feelings through a game.

We decided on a first person perspective of the game to allow the user to feel immersed into the scuba-diving experience. Firstly, we focused on creating and solidifying the storyboard of the game. As described above, by creating a solid story along with realistic and quality sounds/sound effects, we feel that the user would have the best experience playing our game, rather than trying to focus on visuals and other aspects, which we know will only fall short.

Once our story was solid, we began to prototype on Unreal.

Prototyping on Unreal:

Our first step in the Unreal Engine was to start building our underwater world. We first drew a sketch that would help us design our prototype in Unreal. We wanted to make a gamebox like area that the user would be put into and map out a route of exploration to the treasure.By drawing these figures, it helped us get a better idea of what we wanted to put into Unreal.

We began by building a ship, that would be used as the boat the player starts on, then we duplicated that model, and created a dilapidated, broken version for the shipwreck the treasure would be in.

Once we created the ship, we moved it up into the air, and created a large box with a floor to create our “underwater world”. From there, I used the landscaping tool to sculpt a sand-like ocean floor with mounds and cliff-like hills. I designed these to be obstacles that guided the user intuitively towards the next clue, and ultimately the treasure. I also used the erosion tool to create more realistic like coral reefs that would have been underwater for years.

After this, I added on a layer of sand texture to create the feel that the ground was the bottom of the sea.

Further Goals:

We want the beginning of the game to be a cinematic cutscene of the father and daughter speaking on the boat that leads cleanly to the user’s first action: jumping into the water. We will lay a mesh the gives the appearance of the ocean’s surface, and once you jump in the water/ pass through the mesh, it will initiate a post processing to give the player the effect of swimming/ scuba diving.

We want the user to use WASD and the mouse/trackpad to give the user full 360 degree movement about the map and the ability to go to any depth.

We want to create the O2 tank meter and a subset that increases O2 usage if the player is stung by jellyfish.

We want there to be prompts given both with text and audio once you reach certain areas/ find certain clues that guide the user along towards the treasure.

Here are some of the logo ideas we have:

Difficulties:

Initially, we had a difficult time figuring out the logistics of our game and the feasibility of creating the ideas we were throwing out. We had a lot of really cool ideas such as a panic meter, but it would have been way too time consuming or too experienced for us to realistically play out. We had to use our rationality to consider all the features we wanted to include.

Halfway through our prototyping, the computer we used crashed and we were unable to open the file containing all our stuff! After trying four times with avail to open the project, Findlay went to see Brett. They tried re-downloading unreal engine, reformatting the hard drive, and tried to save the project locally, but afterwards he agreed the file was corrupted. Julie and Findlay are going to figure out how to store the project using Github. Lesson learned that using a hard drive to save the game file, rather just leaving it on one desktop, leads to difficulties. Also this go around Findlay hopes to model the boat, coral in ship wreck in Maya so that the assets are not lost again. We spent a lot of time modeling these assets, and quite sad to have lost them. We didn’t take screenshots, so the only remaining photo of this version is the thumbnail used in the Unreal project selection menu (inserted below). Also below is a picture of Findlay’s screen freezing red when we tried to open the file for the 7th time.

After our project was unable to open again, we restarted our project on Unreal again. I was able to recreate the box, sandbox, and map out our clues. I began the process by creating the game box and sandboxing the area the user would navigate through. I used the landscaping tool to create the mounds and layered the sandstone texture onto the bottom layer to give the world a more realistic feel to it. I also placed the clues and important landmarks.

So to restart the modeling process, taking Brett’s advice, I (Findlay) used Maya! It took me about an hour and a half to figure it all out, but the result was this simplistic diving boat.

It has about 9 scuba tanks and two life buoys. The boat itself started off as a box, but using maya, it became the boat. The scuba tank was my favorite thing to model out of the three, because it looks the most realistic. Next steps modeling-wise would be to model some coral and the two objects that act as clues in the game: a canon and driftwood.

Once we modeled the boat and put it into the Unreal, we created a player. The player requires 360 degree motion, so its actions include: forward, backward, left, right, up , and down. We are currently having some operational difficulties with getting the actions to actually take place, but the framework is all there.

We also began the framework for our O2 meter, sometimes called PSI, as you can see below. It only contains the visual elements, but our next steps are to create the timer and increased count down when encountering jellyfish. The ‘tank’ will begin with 3000 PSI, and slowly decrease. The player will be prompted with a recommendation to surface once the ‘tank’ reaches 400 PSI.

Here is what it looks like so far!:)

Treasure Trackers 2.0 (VR edition)

After presenting our game design, we decided it would be more fitting to make our game a VR experience. We first began by prototyping player movement with the Vive VR headset and handsets. After looking at our world through the VR headset, we were very happy with how realistic our world looked and were sure about our decision to transform our video game into a VR game. Throughout the process of creating our VR game, we used a guinea pig play testing strategy to make our game most suitable to the user. Each time we added an element, one of us would put on the headset and play to see if the hands (spheres) were too big, or if the speed we were moving was too fast, or if the atmospheric fog was too dense, etc.

UI Findlay

The UI consisted of a timer counting down to a restart. This timer was meant to represent a slowly draining O2 tank, so we gave it the unit of PSI. We attached the ui to the left hand of the player. We did this so that the timer would not distract from the immersive experience of a VR environment. This aspect was intended to create a sense of urgency to explore quickly, and make the player want to try multiple tries when he failed.

Movement

Our next goal in VR was to simulate movement by action mapping the trigger function of the VR handset to forward movement. While blueprinting this simple action may seem easy, we ran into a few problems along the way. But first, we needed to set ‘forward’ as the value you are looking at. The approach we took as we were prototyping was the the ‘guinea pig’ approach, where we took turns to attempt programming while the other groupmates looked through the VR headset.

Our first idea was not too successful, while we were able to create movement, this movement was not triggered by any action other than to move along the direction the headset was pointed in. Our second idea was also not too successful, but definitely on the track. We were able to move the player a specific amount of distance every time the trigger was pulled (using the multiplying element in the blueprint), however the player didn’t continue to move forward as we had hoped. The player only moved forward a specific distance every time the trigger was pulled, so if we wanted the player to continue moving, they would have to continue to pull the trigger.

Our next attempt was to create a boolean function and it also didn’t work out. While our idea/mindset was there, we didn’t know how to translate it into blueprint logic. We also realized that the reason we were stuck on ideas was because we were never printing strings that gave us feedback of what was working and what wasn’t, thus making the blueprint process longer and more frustrating than it should have been.

Finally, we called for help and realized that we didn’t need the AddActorLocalOffset and we could instead use the event tick where it plays the game on a continuous loop. From there, we were able to use the branch to include the boolean idea of true/false of pulling the trigger to induce movement.

Once we figured out movement, we wanted to make the landscape of the game solid so the user wouldn’t be able to go through the ground or the sand dunes.

Brief summary of new game elements Lily

Upon receiving feedback from everyone when we shared our game design document in class we were able to apply some to our game design and vision moving forward. Firstly, we decided to shift from a desktop game to a VR game. Thankfully with this change we could keep much of our original work and shift it to a VR headset!

We also decided to make a few adjustments to our original, more ambitious, game design document due to the time constraints of the prototype timeline of our game. We took our original idea of being multi-level and condensed it to one level so we could focus on a more immersive world.

VR Prototyping

Landscaping Julie

Our main level/game box design represented something similar to a very large maze. We used the same landscape design from before changing our game to VR, but decided to touch it up and add some more realistic aspects after seeing what it looked like in VR. We decided to use the erosion tool more, sculpt the sand hills larger, and put the assets (treasure, driftwood, cannon) semi-submerged into the landscape sand to resemble “sunken treasure”.

Once we were content with our underworld map of our sea, we added a layer of atmospheric fog to create the feel that you were underwater without having to actually create water. We played around with the fog density and color, as well as the volumetric fog section. We also touched on the fog’s chromatic aberration to try and make the fog as “water-like” as possible.

Assets Findlay

The player held the bulk of our code and work hours. It began as a pawn with no hands. We focus first on creating accurate movement. Then we began to create the hands. Each hand we left as a simple white sphere. Each attached to it correct controller. Aldo attached to the Player is the audio of the bubbles.

The next assets focused on were the clues and treasure. The Driftwood and Cannon asset where the clues. When the player comes upon them in the game we wanted to have an audio clip play that would help direct the player along. We used a collider. The code required us the child a sequence of static meshes and audio clips to each asset. The same theory was done to the treasure as well.

Next are the boats, both the starting point and the shipwreck. These assets were modeled, aforementioned, in Maya. Although they were not the intended beginning and end we had envisioned, they ended up sufficing quite nicely.

Sound (background noise + collision sound bits — audacity)

• Audacity Lily

Sound design became an aspect of this project that we really wanted to keep exploring. In this pursuit we transformed our original idea of text and visual based clues to audio clues. Once this change was implemented the text for our clues became the script for the audio we would then record to be our audio cues upon bumping into our physical clues.

To do this, we recorded in audacity, in a quiet room with good acoustics. Next we made sure we edited the audios clips by normalizing them to take out harshest loud sounds and make it easiest on the ears.

Next we saved all the files separately with easy to discern naming conventions.

• Collision julie

Once we had our sounds in the most suitable format and we imported all our sounds into Unreal, we wanted to attach them to our actors. Since we changed our original idea of having clues pop up once the player reaches a specific distance near the object to playing audio, we needed to recreate our solid objects as actors so they could have the function of playing an audio track when the player reaches a specific distance.

We created a corresponding actor for every object and created a collision box around so when the player reaches a specific distance near the object our audio track could play. For example, the screenshot above shows the collision box we created around the treasure box. To test if our collision box was working, we attached print strings to see if when the user collides with the box, Unreal registered that the user did collide.

Once we knew the collision box was working, we began to prototype the trigger of audio when the player collided with our collision box. We started with an Event BeginPlay, and from there could set a specific audio sound to play when the user collided with our static mesh collision box for each actor.

• Bubbles + beginning sound findlay

The sound in our game very early on became the main focus. We felt that to truly immerse the user in an underwater experience, that sound would be paramount. Thankfully we had some audio from a recorded dive, so the bubbles sound was accurate and exactly what we wanted. With this sound the code pictured below was utilized. It helped to keep the loop and attach the sound onto the Player. This is one small and simple aspect of the game, but I think without it the game wouldn’t have felt complete.

Treasure trackers 3.0

What happened on last day julie

On our last day, we decided to add some finishing touches to our actors and world. We noticed the VR headset wasn’t connecting and planned to restart the computer. As we were saving the project to start the restart, we ran into some issue of not being able to save some files. We asked Dave (who was so awesome and generous to help us through everything!!!) to help us figure out what was wrong, so he looked up a quick fix to be able to save the project and we continued to restart the computer.

When we reopened our project, our main level map was reset with the default Unreal page with the chairs…! We had Dave and Christian try to find our old world, but Unreal kept crashing. It turned out that since we had our main level page (stupidly) named “minimal_default” had been overrode with the Unreal default main page. And since Dave had tried the quick fix, our original main level map had gone into the depths of the computer and was unable to open without crashing.

As you probably can imagine, we were all panicking a bit, despite it being the SECOND time our project had crashed. Since we were supposed to present to the other groups what we had been working on, we quickly rebuilt as much of our old world as we could in about 30 minutes. It definitely wasn’t as good as it could have been, but it would suffice for the general idea. But if not for Dave and Christian, we would have not been able to pull it off.

For the future findlay

This game was the idea that we picked because it was bursting with potential. I will try and detail a few of the many aspects we wished we could have explored.

I will start off with the UI. We had big plans for our VR O2 tank. We wanted it count down accurately to the bubbles audio, like the player was actually draining a breath from it. We also wanted to have jellyfish in the map. When the player touched one, the bubbles track would increase, and so would the rate at which his air depleted.

We wanted to implement more audio into the many interaction VR creates. The forward movement to a sort of water sound, interaction with the ground, such as a thud, and lots of detail.

Speaking of detail, our original vision for the landscape was a coral reef, but we never got to really focusing the visual details.

We would recommend to someone who would want to further the project to focus on the small details in the audio and interactions, because we believe the best thing about any adventure games are the details and discovery. Some examples would be creating more obstacles on the way, and perhaps enemies, like sea urchins or lionfish. The possibilities are endless when you have a whole ocean!

Lesson Learned lily

Overall, this was an incredibly educational and rewarding experience. To see our idea go from conception through the different stages of prototype and eventually to a playable stage was incredible. However, this wasn’t to say that this was without obstacles. Having gone through our first VR rapid prototyping experience, we learned many lessons for next time.

The biggest lesson we learned was to manage expectations and start with a manageable scope of the project. As Christian mentioned, the projects we had conceptualized in our class would take years with full-time development teams. Thinking about how to boil the bigger vision for a game down to something tackle-able in 4 weeks became the challenge.

Additionally, learning to ask for help in strategic moments rather than doing a lot of work only to find out that method wasn’t feasible. Lastly, through all of our challenges regarding crashes, we have learned to save often, rename default names and BACK-UP BACK-UP BACK-UP our work.