Overview

Asteroids 3D was from the start a very uncertain sort of project. We started with a great idea of what we wanted the game to be in an ideal situation. However, we knew that all the new technologies we'd have to deal with could prove to be too time-consuming to integrate all the features we wanted. So with a list of core features and optional fringe features, we dove into the murky black. In the end, we came out with the core game mostly intact, plus a few of the optional features to boot.

Commentary

A Completely New Language

The biggest challenge we faced was in learning a completely new programming environment. Lua scripting for Luster was thankfully similar to Actionscript 3 in a few ways, but there were more than enough quirks and new types of syntax to get used to. Most of the differences were only slight, such as trace statements being printed to a file instead of on the screen. Some were quite strange though, such as having to use colon syntax in place of dot syntax in certain situations. Additionally, programming with that extra 3rd dimension brought along its own set of challenges to the table. Our saving grace was having close contact with Brian Johnstone and Colin Doody, who were always more than happy to help us through any kinks or unusual problems we came across.

Preparation for New Media Team Project

One of our primary goals for this project was to simply become proficient in this new environment. That way, we would be prepared for what's to come in Team Project next quarter. The tasks of learning how to import art assets, program functionality, and human-computer interfacing have all been taken care of. Ideally, we've cleared the way so that next quarter our team can concentrate on content creation and not worry about issues with the new technology.

Technologies:

DOME

Standing for Digital Omnidirectional Multiuser Environment, the DOME is our main platform, and sort of the centerpiece of the user experience. Made of a set of 4 screens that form a box of rear-projected imagery around the user, it gives us the capability to put players inside a 3D environment like no other platform. We had a few difficulties due to the physical constrictions imposed by such a setup. We couldn't include Wiimote IR sensitivity in this release due to both the user's physical proximity to the screen and the fact that there are screens on all sides.

Luster

Luster was our chosen 3D platform for this project. Luster is a wrapper for the Ogre3D realtime 3D engine. It is currently under development by Brian Johnstone and Colin Doody, and has offered us some very nice advantages over our other options. Firstly, Luster is focused towards rapid 3D-development with users like us (new media designers) in mind. This means that not only is scripting for Luster similar to Flash, our most familiar environment, but it also boasts the ability to import and run Flash within itself! Swf files can be embedded as textures and interface elements, and are able to communicate in both directions between Lua and AS3. Luster is in a very early phase, so it had a few unusual quirks to deal with, such as manually altering a shortcut to the .exe file to reference the xml files used.

Ogre3D

Luster at its core is actually a packaged up version of the Ogre3D engine. This presented a few challenges, the biggest one finding a way to get models made in Cinema 4D into a format usable by Ogre. We first tried to tunnel through Maya and 3D Studio Max, but we eventually found a direct-from-Cinema 4D conversion method buried on the Ogre3D site.

NewtonPhysics

NewtonPhysics is the physics engine that was incorporated into Luster. It gave us some difficulties when its behaviors started conflicting with the behaviors we had already programmed into the world. However, in the end, it provided us with proper set collision detection and reaction solutions.

WiiMote

While we didn't get as much WiiMote functionality as we wanted, the stuff we did include added a great deal to the success of our project. The WiiMote allowed for an intuitive, wireless controls scheme for players. We started our WiiMote experimentation in Flash, but eventually moved it into Luster once their development team completed direct WiiMote integration. A lot of effort was spent in getting infrared pointing included in our game. This would have allowed the gunner to simply point his controller around to fire at asteroids. However, we had to settle on using only accelerometer, tilt sensitivity, and button presses. These features only required us to use a USB Bluetooth receiver to pick up signals sent from the controller.

Flash

Flash was our lifeline to the world of familiar and (comparatively) reliable things. It provided us our interface elements, and integrated beautifully into Luster, allowing our Flash interface to react to what was happening in the 3D world.

Cinema4D

Cinema was our other bastion of reliable, familiar ground. It allowed us to easily produce the needed 3D assets used in the game. As mentioned previously, the only issue we had was in porting over our models into a format usable by Luster.

Gameplay Design

Controls

After a quick learning curve, the controls ended up being quite intuitive. The WiiMotes are familiar, easy to hold, and responsive to player movements. The additional features we added, such as a reverse for the driver and a reticle slow-down for the gunner added an extra level of sophistication to the controls.

Cooperative Play

We solved the problem of overwhelming the player by splitting up the game into 2 jobs. This also added considerably added to the fun. Two pairs of eyes were good for spotting asteroids on all sides, and fun close-call cooperation of the driver and gunner made for tense moments such as the gunning down of asteroids as the driver flew directly at them.

Things that Went Well

3D Programming

Overall, getting things to work flowed rather well. Joe was highly dedicated to the task, and with the assistance of Brian and Colin and the occasional creative solution by Brendon, we were able to include many of the features outlined at the beginning of the project.

Graphics Programming

While initially a little intimidating, we eventually realized the utility and power of the graphics capabilities available to us. Some stuff was pretty easy, such as setting up lights in the 3D world or embedding a swf as a texture. Even better, our swf textures could be programmed within themselves, taking info from Luster and reacting to it. Getting deeper into texturing, we learned how to edit material files, which allowed for advanced effects like bump mapping and multiple levels of detail for varying systems.

WiiMote Integration

Getting WiiMotes to work in Luster wasn't a very difficult task. As mentioned earlier, we didn't integrate WiiMotes in as full a capacity as we hoped, but we came up with some creative solutions that really added to the gameplay experience.

Developer Collaboration

Brian and Colin were immensely helpful resources in learning how to use Luster. We hope we were a good resource for them as well, acting as early testers for their platform. Additionally, our close contact with them allowed us to request new features and changes as they developed it. This was what allowed us to so successfully integrate physics and WiiMote support into our game.

Art Asset Creation

For this aspect of the project, we got to work in familiar environments like Flash, Photoshop, Cinema, and Illustrator. This allowed us to concentrate on aesthetics without much worry about technology issues. We found a good workflow for swapping art assets in the 3D world, allowing us to quickly test and refine new assets until we were satisfied. In the end, these advantages allowed us to have a very good looking environment and interface.

Final critique

The response of the class was very positive. They probably didn't know what to expect, and we hope they were pleasantly surprised. A few classmates got really into the game, yelling and reacting to both the game and to cooperating players, which was a very satisfying experience for us.

Things that Went Poorly

Some performance issues

Having never worked in Lua before, we had no idea how best to optimize our code. As a result, we've run into some issues with garbage collection, and later in the game, the display begins to chug a little. As Luster is still under development, we'll be working closely with Brian and Colin over the next quarter to iron out these issues both on our end with the programming optimization, and theirs with the API.

No starting menu or win/lose screen

Given the difficulties we had in other areas, some parts of the project ultimately hit the cutting room floor. Unfortunately one of these areas was the menu structure, game over screen, and reset functionality. We lacked the time to put a polish to our game and make it a full, robust application. We see this acceptable within the scope of the class, but would like to revisit it at a later date.

Rotational 3D Programming

Rotating elements in 3D space is a pain, really. Without formal training in quaternions (look it up!), we had to rely on nesting hierarchies to achieve our desired rotations. The area most affected by this difficulty was our explosions. Originally a single swf movie we planned to place it at the point of collision, and orient it towards our camera while it played. This proved ineffective as we had intermittent success with this strategy. Brendon ended up suggesting we stack together 3 planes of explosions on the same point, oriented in such a way as to approximate a sphere. This works for the time being, but we'll eventually have a better understanding of rotation, and particle physics for our explosions.

Sound

There is no sound in space! An aspect of the game we were worried about from the get-go, we just didn't have the time to give it the justice it deserves. Luster currently only supports sound through Flash, and has plans in the future for OpenAL support. Rather than put in some cheesey explosion and laser sound effects, we opted to hold off until we can really sing. In the meantime, we're scientifically correct.

Conclusion

All things considered, this was a very successful project. It was great working with Brian and Colin on a developing system. We felt really good about our final product, worked out a lot of speed-bumps for next quarter, and have ideas for further improvement. We can't ask for much more than that.