On Stage at the Fall 2011 BVW Show!

Great news!  Two of my teams' worlds from this semester's Building Virtual Worlds class were selected to be featured in the Fall 2011 BVW Show!  Each year BVW students are allowed to submit worlds from any round to the BVW Jury for review, who then assemble a show from the best worlds to be put on stage in front of a live audience.  This semester over 90 worlds were created, 60 were submitted to the jury, and fourteen of those were selected to be in the show!  Here are clips from the show of the two worlds I was a part of.  I was a performer on stage in both of them.

Mouse <3 Mouse (yes, that's me in the mouse costume)


Electro Techno Corps (playing the role of Captain Electro in the middle)


The entire show was a huge success!  You can watch the whole thing online here:
mms://wetc-tv.etc.cmu.edu/stream/2011_semester_3/class/bvw/bvw-pgh_2011-fall-show.wmv

This marks the end of my first semester at the Entertainment Technology Center!  Next up is a short winter break, during which I might find a little time to get back to work on Shining Force PC!  After that the next semester starts in mid January which will be a whole new adventure working on a full semester long project as opposed to the short 2-3 week rapid prototyping rounds of BVW.  I have to say that this semester has been the most exciting three months I can remember in forever!  I've made so many great friends and had a wonderful time creating amazing things together with them!  I only hope that the rest of my time here at the ETC will be this rewarding!

Building Virtual Worlds - Round 5 - Electro Techno Corps

The theme of Round 5 of Building Virtual Worlds is Its Showtime!  Students are given one month and are tasked with building a world that is big on showmanship and spectacle with the goal of being featured in the Building Virtual Worlds Show at the end of the semester.  Unlike previous rounds, students are permitted to form their own teams and pitch a concept to the professors or take the luck of the draw and be assigned to a random team like in previous rounds.  I was placed on a random team and the world we came up with was a giant robot themed game called Electro Techno Corps (a pun on ETC.)  The world is in the vein of saturday morning cartoons and the Mighty Morphin Power Rangers. Three performers share two Wiimotes and two nunchucks to pilot a giant robot against a mad scientist whose giant creations run amok in the city.  The current video only has the game aspect of the world on display, if and when a version that also includes the live performers becomes available I will update this post. Update: a version with live performers is now online, check it out in this post!



Despite the large time frame, one of the major challenges of the round is time management and proper scoping of the project.  Many teams reached too far and ended up having to scale way back or start over completely around the halfway point in the round.  My team just barely managed to finish our world based on our original plan, which was way too close for comfort.  I wish we would have cut one of the events early on and spent more time on polish, playtesting, and fine tuning, but thankfully everything worked out in the end.

One of the more interesting aspects of the project was using CityEngine to model the city rather than doing it by hand.  Our texture artist, Anisha Deshmane, spent a lot of time in undergrad working with CityEngine and we were able to get the city modeled, exported to 3DSMax, trimmed down, and imported into Unity in under 2 days!  It saved us a lot of time and effort and looked great in game, which let us spend more time and effort on other aspects of the project.

Building Virtual Worlds - Round 4 - Mouse Heart Mouse

Building Virtual Worlds Round 4 is the Storytelling round.  Groups are given three weeks to build a world that lasts 3 to 5 minutes that tells a complete story.  Students have two days to come up with and pitch two story ideas to the professors and the class and receive feedback from them.  They then choose one of these ideas to build storyboards for, which are presented at the end of the first week.  Over the next two weeks students build the world laid out in the storyboards.

My group’s story told the tale of a mouse who meets a computer mouse atop a desk in a messy dorm room while scavenging for food.  The two fall in love at first sight, but are separated when the owner of the room returns and sits down at his desk and reaches for his computer mouse but grabs the furry mouse instead.  Shocked, he flings the mouse away and runs from the room screaming.  Our hero must find a way back to the top of the desk to reunite with his love, and then the two must find a way to escape the room and enjoy their freedom and their new life together.



My team this round worked exceptionally well together!  We all really liked the idea we came up with and that lead to very good buy in from all the members of the team.  Everyone made strong creative contributions to the project and we all worked very hard to make Mouse <3 Mouse a big success!  One of the things that I believe greatly contributed to that success was our choice of platform, the Nintendo Wiimote.  Since this was a small, simple piece of hardware, we were free to use it at our desks and we could playtest and iterate constantly unlike the rounds where I worked with the Kinect.  Since the Kinects and televisions were in very short supply, teams had to schedule limited time slots to playtest and it was harder to get a feel on how the world plays and make adjustments when working with that platform.  The freedom to playtest regularly on the Wiimote made it easier to fine tune the controls and left more time to polish the room and make it as lively and interactive as possible.

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.

Exciting Changes Ahead!

I have some great news to share!  I've been accepted to Carnegie Mellon University's Entertainment Technology Center graduate program!  I'll be working very hard towards earning a Master of Entertainment Technology degree over the next two years.  First semester begins tomorrow!  It's very exciting.  I have several friends who are graduates from this program who all speak very highly of it, and it was their tales that inspired me to reach for the stars and apply.

What does this mean going forward?  Odds are, you'll be seeing a lot fewer SFPC updates, but with any luck and a little free time (I hear that's in very short supply for ETC students!) you'll see some new posts on some much bigger and much different projects that I'll be working on in the months ahead.

For those of you who have been eagerly following my progress on SFPC, please know that the project remains very important to me and I intend to work on it more in the future when I have the time.  All my hard work on SFPC was what earned me this opportunity, and I don't intend to abandon it.  Ultimately this is a very good thing for the project.  I'll be making lots of new friends I could possibly recruit to help out with graphics, sound, or code.  My own skills will undoubtedly grow far greater and I'll be much better equipped to make SFPC even better.

And with that, I'm off to have my world turned upside down and inside out, and have my mind blown.  Wish me luck!

SFPC - August 2011 Update

So, it's been a while since I've done any updates on SFPC.  I'll admit, things definitely slowed down for a while, what can I say, I needed a break (or two)!  Despite the lack of posts, I have gotten a lot of work done over the past few months, though the bulk of it was not really video or blog post worthy.  This release represents the sum of the year's changes so far, which includes lots of bug fixes, a major revamp of the movement code for performance reasons, and some new editor features and engine enhancements. 

There's no new gameplay map to try, hence the lack of a video.  The main draw of this release is the enhanced editor, which includes several features which should be a big deal to anyone interested in making maps.  Press the Home key to toggle between Play and Edit modes.

- The engine now supports variably sized maps, anywhere from a minimum of 28x20 tiles (two screens wide by two screens tall) to a max of 255x255.

- The editor now supports a sort of command console, think of the ~ menu from shooters like Quake.  From within the editor, press F12 to open the console script.  It opens a regular script window in Notepad.  Enter whatever script commands you like, save the file, then press F9 to run the script.  It is meant for one-and-done commands, and the file is wiped each time it gets loaded.  Two new script commands have been added specifically for use with the console:

• TileFill tilenum layer x1 y1 x2 y2  -  Does a fill on the active map from x1, y1 to x2, y2 of the specified tile on the chosen layer.  Must be a valid, in bounds rectangle, or nothing will happen.  The editor UI now shows the corresponding integer version of the active tile for use with this command.  Layers are background = 0, overlay = 1, foreground = 2.  Great to make a large space, or even the entire map, get set to a specific tile, for instance an indoor map might use a pure black tile on the edges instead of a grass tile.

• CreateNewMap "mapname" width height  - Creates a new folder structure in the /maps/ folder for the specified map name, as well as blank default map and event scripts.  The editor does not load the new map immediately, the choice to save unfinished work (press F5 to save) and switching to the new map with either F1 to load maps or the Warp command in the console script is left up to the user.

- The editor itself now has a more robust tile editing system:

• The editing cursor now supports brush sizes.  Increase or decrease the size of the brush with the Page Up and Page Down keys, from 1x1 up to 5x5.  Changing the brush size fills the brush with the active tile.

• The editing cursor now also shows the contents of the current brush at half transparency over top of where it is pointing.

• The C key is still used to copy tiles, and will now copy the contents of the selected area to the entire brush.

• Any time the user changes layers or modes within the editor, the contents of the brush is erased and the size is set back to 1x1. 

For those curious enough to give the new editor a try, you can download it here.  The maps from the previous demos are included, you can open them up and tinker with them if you like.  There is also a scripting cheat sheet in the readme, along with the list of controls.  You may want to associate .sfs files with Notepad for ease of use, just double click one, tell it to open with Notepad, and leave use this by default checked.  You may also want to refer back to some of my older posts and videos for a refresher on how to use the editor.

Please feel free to email me if you have any questions on making maps or scripting or to let me know about bugs, or you can post in the comments below.  If anyone makes a map and would like to share, let me know, I'd love to see them!