Kinect Star Wars
In Kinect Star Wars players get to use the magic of Kinect to live out their Jedi lightsaber fantasies, destroy iconic locations as a monstrous rancor, race through familiar planets in pod racing, and thanks to a computer glitch even compete in a galactic dance-off against their favorite Star Wars characters.
While working on Kinect Star Wars I worked on three of the four modes and made contributions ranging from concept, prototypes, and final levels. I also had to extensively learn the intricacies of the vast Star Wars universe to make sure everything placed in each level would meet canon and please even the most meticulous fans.
Kinect Star Wars challenged me in every way a project can challenge someone and I learned a great deal from this project.
While working on Kinect Star Wars I worked on three of the four modes and made contributions ranging from concept, prototypes, and final levels. I also had to extensively learn the intricacies of the vast Star Wars universe to make sure everything placed in each level would meet canon and please even the most meticulous fans.
Kinect Star Wars challenged me in every way a project can challenge someone and I learned a great deal from this project.
Kinect Star Wars - Terminal Reality
Main Rancor Designer / Level Designer - Xbox 360 - August 2009 - April 2012
- Trained designers at Microsoft studios to use the Infernal Engine.
- Prototyped many different 3D movement control schemes for Kinect.
- Created concept and tracks for Pod Race mode in 3DS Max and Houdini
- Built Pod Race tracks with artists that fit within Hoth, Mygeeto, and Tatooine.
- Prototyped all Rancor Rampage gameplay modes in script and built Rancor Rampage levels set in Mos Eisely and Theed.
- Created and maintained common script for Rancor Rampage that all levels used.
- Balanced scoring models and enemy spawn tables for all Rancor Rampage levels.
- Rebuilt existing Jedi levels set on Providence and Felucia based on feedback and new gameplay to a finished state.
- Implemented in-game cinematics in Jedi levels with cinematic designers and animators.
How Do You Move a Character With No Controller?
For nearly the first year of development on Kinect Star Wars I and another designer tried to tackle the problem of how you move a character from point A to point B in 3D space with no controller. During this time we created concepts and prototyped many different controls that ranged from didn't work at all to worked really well but was near impossible to teach someone. We created control schemes where players had very little control over where they positioned themselves in 3D space and other control schemes where the player had complete control. During this time, we were also building the Jedi game mode along with other Kinect enabled mode prototypes.
Eventually, given the target audience, we moved closer to a scheme where players had less movement control. These schemes did not allow the player as much freedom as we would have liked but it was something young or inexperienced players could quickly pick up. Figuring out how to control a character without buttons on a completely new device was a difficult but rewarding experience. It stretched my imagination and taught me a lot about how different types of players approach a game.
Eventually, given the target audience, we moved closer to a scheme where players had less movement control. These schemes did not allow the player as much freedom as we would have liked but it was something young or inexperienced players could quickly pick up. Figuring out how to control a character without buttons on a completely new device was a difficult but rewarding experience. It stretched my imagination and taught me a lot about how different types of players approach a game.
Pod Racing
Eventually I moved away from Jedi mode and starting working on the pod racing mode. During this time we were working on the level creation pipeline so we could quickly create levels since the general control scheme was already decided upon (though would still evolve over the course of the entire project). I started creating levels in 3DS Max but we soon moved to Houdini because it was quicker and easier for designers to create spline based tracks.
While previously working on Jedi I had already created speeder bike prototype levels so I had a good feel for how to make pod levels. I learned that it was difficult to do very fast vehicles with obstacles like trees in the level and that Kinect required wider courses than I had built, especially for more casual players. With what I learned in mind, I created a Hoth pod race track that took place during the Imperial Attack. This let me build wider tracks but still have opportunities to narrow the track. It also allowed me to have a wide variety of obstacles for the player ranging from falling ice-cycles that changed the path of the track to AT-AT's walking across the track.
Eventually, a rough story was created for the pod race mode and the Hoth track did not fit into that story. To save some work, I reworked the track in Houdini to fit into the crystal planet Mygeeto. In place of the ice-cycles I used crystal formations and in place of the AT-AT's I used large crystal worms that moved throughout the track and provided dynamic obstacles. After my first iteration, I worked with a Microsoft artist to make the track truly unique and moved away from the original Hoth layout. We created a fun track where players traveled around Mygeeto spires, crystal canyons, and even worm tunnels.
Unfortunately, since this level required many unique assets and no other gameplay modes took place on Mygeeto, this level was eventually removed.
While previously working on Jedi I had already created speeder bike prototype levels so I had a good feel for how to make pod levels. I learned that it was difficult to do very fast vehicles with obstacles like trees in the level and that Kinect required wider courses than I had built, especially for more casual players. With what I learned in mind, I created a Hoth pod race track that took place during the Imperial Attack. This let me build wider tracks but still have opportunities to narrow the track. It also allowed me to have a wide variety of obstacles for the player ranging from falling ice-cycles that changed the path of the track to AT-AT's walking across the track.
Eventually, a rough story was created for the pod race mode and the Hoth track did not fit into that story. To save some work, I reworked the track in Houdini to fit into the crystal planet Mygeeto. In place of the ice-cycles I used crystal formations and in place of the AT-AT's I used large crystal worms that moved throughout the track and provided dynamic obstacles. After my first iteration, I worked with a Microsoft artist to make the track truly unique and moved away from the original Hoth layout. We created a fun track where players traveled around Mygeeto spires, crystal canyons, and even worm tunnels.
Unfortunately, since this level required many unique assets and no other gameplay modes took place on Mygeeto, this level was eventually removed.
Rancor Rampage
Midway through the project I was moved onto rancor mode. What started out as nothing more a rancor in the pit at Jabba's Palace turned into a full mode taking place in large fully destructible cities.
Learning from my experience in pod and Jedi where I had to restart work often as gameplay evolved, we set out to make Rancor Rampage as easy as possible to quickly iterate on. This required large amounts of planning and forethought up front but was very much worth it in the long run. As the Rancor Rampage mode evolved and new systems came along, I had to redesign the layout for levels multiple times. Instead of like other modes where it could days or weeks to completely redesign a level from scratch, it took only hours to implement a redesign for Rancor Rampage levels.
We did this by making everything systemic. Except for unique one-off events, everything was handled through the buildings the designer placed and the common script I wrote. The buildings designers placed handled where enemies would spawn. Any enemy could spawn next to any building where there was room and if they were out of sight. Enemies themselves used dynamic obstacle avoidance. Because of this, designers did not have to worry about spawn points or what would happen when the massive amount of physics objects started cluttering up the level.
On my side, I created the rampage common script. This handled setting up the game mode, setting up the point goals, and setting up the enemy spawn tables. The script also took care of how the rancor handled their health, how enemies behaved, and other systemic objects that appeared throughout the rampage levels. Every rampage level used this script and all a designer had to do was call a few functions and the level was ready to go.
Because of all the work being front loaded, we were able to spend a large amount of time on balance, controls, player camera, and fun. While developing Rancor Rampage, we received the highest fun rating in Microsoft's internal focus tests for a Kinect title and consistently met or exceeded that fun rating because we could quickly make changes and were able to concentrate on the fun.
Learning from my experience in pod and Jedi where I had to restart work often as gameplay evolved, we set out to make Rancor Rampage as easy as possible to quickly iterate on. This required large amounts of planning and forethought up front but was very much worth it in the long run. As the Rancor Rampage mode evolved and new systems came along, I had to redesign the layout for levels multiple times. Instead of like other modes where it could days or weeks to completely redesign a level from scratch, it took only hours to implement a redesign for Rancor Rampage levels.
We did this by making everything systemic. Except for unique one-off events, everything was handled through the buildings the designer placed and the common script I wrote. The buildings designers placed handled where enemies would spawn. Any enemy could spawn next to any building where there was room and if they were out of sight. Enemies themselves used dynamic obstacle avoidance. Because of this, designers did not have to worry about spawn points or what would happen when the massive amount of physics objects started cluttering up the level.
On my side, I created the rampage common script. This handled setting up the game mode, setting up the point goals, and setting up the enemy spawn tables. The script also took care of how the rancor handled their health, how enemies behaved, and other systemic objects that appeared throughout the rampage levels. Every rampage level used this script and all a designer had to do was call a few functions and the level was ready to go.
Because of all the work being front loaded, we were able to spend a large amount of time on balance, controls, player camera, and fun. While developing Rancor Rampage, we received the highest fun rating in Microsoft's internal focus tests for a Kinect title and consistently met or exceeded that fun rating because we could quickly make changes and were able to concentrate on the fun.
Jedi Destiny
When the Rancor Rampage mode began to finish up, I was moved back onto the Jedi mode to help finish it. My first goal was to create common functions like those I had for rancor that all Jedi levels could use. These functions were used for background elements such as wookies fighting and ships flying overhead. After I finished those, I moved onto two Jedi levels that had already been started by other designers.
The first, the first on-foot Providence mission, several designers had already made passes at but still needed work. I integrated feedback from the Product Owner to keep the gameplay interesting while keeping with the proposed mood of the level. The second level I received, the last on-foot mission of Felucia, required a complete redesign from the ground-up. I worked with the Product Owner to design something he was happy with and had to quickly build that level to bring it to an alpha state. Once the gameplay was updated for both of these levels, I continued to work on them for the remainder of the project while also working to integrate the many cinematics for the game.
The first, the first on-foot Providence mission, several designers had already made passes at but still needed work. I integrated feedback from the Product Owner to keep the gameplay interesting while keeping with the proposed mood of the level. The second level I received, the last on-foot mission of Felucia, required a complete redesign from the ground-up. I worked with the Product Owner to design something he was happy with and had to quickly build that level to bring it to an alpha state. Once the gameplay was updated for both of these levels, I continued to work on them for the remainder of the project while also working to integrate the many cinematics for the game.
