Building Virtual Worlds - Round 2 - The Pharaoh's Messenger

Building Virtual Worlds Round 2 is the Naive Guest round, the assignment is for students to build an experience for a user who knows nothing about their world.  At finals for the round a naive guest is given the controls and the team who built the world is permitted at most one verbal instruction to help the guest complete the world, all other instruction must be given from within the game.

My team's world, The Pharaoh's Messenger, used the Head Mounted Display platform as its interface.  The HMD is a set of goggles the guest wears coupled with up to four positional and rotational sensors that can be used any way a team wants.  Our team used two, one on the HMD goggles to update the guest's view of the world based on what direction they were looking and another attached to a physical ship's wheel prop that the team assembled that used rotation data to steer the ship.  The wheel was also meant to communicate as clearly and directly as possible to the guest what the interface was and how to use it.  Instructions in the introduction were given using pictures only since we did not want to assume the guest necessarily even knew English.



The key to the round was playtesting, the challenge being that once someone playtests, they're no longer naive about the world and further input about their experience on successive runs becomes less useful.  For instance, my initial implementation of the steering interface was actually rather counter intuitive, but since I had been testing so much from my workstation using the mouse and not as much on the HMD hardware in the lab I underestimated how off the interface actually felt.  Once I got some testers in front of the game that were not on my team and saw how much trouble they had steering, I scrapped the original implementation and started over and ended up with a much more natural feel for the steering.  Further testers we brought in were also very helpful in redoing the visual aesthetic based on what they thought they saw in the world rather than the reality of what we put there, which is how the game ended up being set in Egypt on the Nile river rather than on a generic river on a grassy plain.  Even the title ended up being a helpful tool to convey a ton of important information: who the player is, the time and place, and what their objective is.

Round 2 was an interesting learning experience for a lot of reasons, one of which was from working on a larger team of 5 instead of the usual 4.  I did a lot of things with the project to enable and encourage the other team members to contribute to the scene file in Unity, which had its pros and cons.  It got the team more involved in working with the project and Unity itself which was good for morale and educational for the people on the team who had not done a lot of hands on work yet with Unity.  Myself, our texture artist Sean, and our sound designer Ricardo could often all be working in the scene at once, but as Unity scene files are binary, not text, changes cannot be merged, only accepted or discarded.  We lost some balance and tuning tweaks at once point and old bugs crept back in that I thought I had fixed.  I had gotten into the habit of usually discarding my changes to the scene instead of committing them since I often assumed Sean was making level layout changes and that his changes would involve more work to reproduce than mine.  Better communication about who was working in the scene file at any given time would have made that process go a lot smoother.

Building Virtual Worlds - Round 1 - The Shaft

So I finally have a free moment to start sharing some of the fruits of my labors over the past several weeks of my first semester here at CMU's Entertainment Technology Center!  The central course of the first semester is Building Virtual Worlds, a rapid prototyping class where students are divided teams of 4 or 5 and are tasked with building interactive experiences over two weeks.  It's all about teamwork!  We all had one week to do a solo project to get the hang of the tools we would be using, C# and Unity3D in my case, and then we were off!

My round one project was The Shaft, an adventure game where the player wakes up at the bottom of a shaft in the earth in the middle of a heavy rainstorm and has to find his way out while avoiding hazards like drowning in rising waters, bats, and rockslides.  It used the Microsoft Kinect as it's player interface with a simple gesture system I built, which came together quite smoothly thanks to the Kinect wrapper for Unity written by our upperclassmen!



C# took a little getting used to but thankfully it is close enough to C++ that I was able to adjust quickly.  I still feel like I am being lazy letting the system do garbage collection for me, but I'll get over it!  Unity3D itself is also very nice, and uses a lot of the same paradigms I use in SFPC, which also helped make for a quick learning curve.