Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: LucasLearning's Star Wars DroidWorks
View All     RSS
December 12, 2018
arrowPress Releases
December 12, 2018
Games Press
View All     RSS






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: LucasLearning's Star Wars DroidWorks


August 13, 1999 Article Start Previous Page 2 of 4 Next
 

What Went Right

Imagine the scene: a bunch of Star Wars fans with over-active social consciences, culled from the computer game industry and the world of education and curriculum development, are dropped into a room and told by George Lucas to "make software that is as educational as it is entertaining, make it better than anything else on the market, and don't spend a lot of money." They're given a blank slate and are released from the starting gate, ready to create products that grab kids and parents with Star Wars, hold them with great game play and production value, and satisfy them with intelligent, thought-provoking content. What could possibly be more right?!

1. Simplicity, Freedom and Vision

George's three-point mandate to the design team was brain-dead simple. His philosophy — and ours — was equally simple: when kids play, they are experimenting, and by experimenting, they are learning. George gave us the freedom to innovate, just as our products would give our users the freedom to experiment and learn. He directed us towards software products that would give players the freedom to build, explore, and learn from the experience, that would mimic Erector Sets and Legos. He asked us to allow kids to make mistakes, learn at their own pace, and direct their own learning in a fun and open environment, then he let us go.

Droid heads

Collette Michaud, the project leader, started dreaming up product ideas. She had often thought about a Star Wars game in which you build different types of droids, and she eventually simplified the concept into one sentence: give players the opportunity to build any kind of Star Wars droid and see it animate. To any computer-savvy fan of Star Wars, that sentence immediately conjured a complete vision, and as soon as anyone heard it, they said "of course." George had been pondering a similar idea, and he immediately approved it as the product to launch this new company.

Distilling an idea always renders it more potent, and all of the ideas behind DroidWorks had been distilled to their very core before we started building. This made it easy to communicate the idea quickly, to get people excited, and to align them with a central vision that drew on all the good memories they had of their own childhood toys. We could see from the very beginning how cool the game would be, and the ideas were so concentrated they never lost potency for the life of the product.

2. Kid Advisory Groups

Usually, we as computer game designers have the luxury of designing games for ourselves. We are the target audience and we are the judges, so if our game makes us say "wow," it's a good game. For many of us making the transition from adult games to kids games, we had to realize we were no longer the target audience — we couldn't just build something we thought was cool, we had to build something the kids would think was cool. So we enlisted the help of a Kid Advisory Group, and building that into our production process was very Right.

We gathered a group of about a dozen kids in the product's target age range to help critique and design the product while their input could still change the game's evolution. Involving kids in the design process helped us make important design decisions, gauge the level of educational appropriateness, and make sure the game remained fun as we moved through the development process. Seeing the kids react to our ideas, seeing them grabbing onto the game, energized and enlightened us month after month, and working with the Kid Advisory Groups proved to be one of the most rewarding and useful parts of the development process. Their responses, always blatantly honest, could threw us into tears of laughter or depression, and their visits always gave us something new to think about.

Frodo

These were more than focus groups. Our kid advisors came back several times and grew emotionally attached to the project themselves as they saw some of their own ideas filtering through the game. They became part of the team, helping the rest of us step back from our adult lives and watch the project through the eyes of our audience. Regular consultation with KAGs from the early formation of an idea has become standard practice at Lucas Learning, and each project gets new groups about every six months, "retiring" one group in order to assemble another with a fresh perspective. The experience we had working with kids on DroidWorks made clear to us the importance of timely, appropriate, constant feedback.

3. Subject Matter Experts

We also consulted on design issues from the opposite end of the classroom by enlisting Subject Matter Experts, fondly called SMEs. The SMEs are adults with interest, expertise, and experience in the field of study at the core of our games, invited to help brainstorm, give feedback, and check in periodically during the course of the design process. Like the kids groups, subject matter expert groups quickly became a standard part of the Lucas Learning product development process.

As game designers, artists, producers, and programmers, we spend most of our days working with computers, piecing together code and artwork, working out budgets and schedules, and keeping the project on track. To create a game, you don't need too much else—you make most of it up, possibly based on historical research. To create an educational product, you have to check every detail, make sure everything you're teaching is correct and well-presented, and, like a teacher, you have to know your audience. We can't possibly do this full-time, so we look to the SMEs for their expertise.

Spider

For DroidWorks, our original team of SMEs consisted of a variety of science and math teachers, curriculum experts, science museum coordinators, and engineers. We spent a day with them at Skywalker Ranch, tossing around ideas and playing with the DroidWorks concept. We continued to talk with them during development, but focused on two — one a middle school science teacher from the Sacramento area and one a retired science teacher now working at the Exploratorium in San Francisco. We continued to meet with them every other month until the end of the project to discuss the status of the game and the educational content we had incorporated into each of the missions. These two helped us immensely in designing the product, pointing out flaws in our physics, and helping us present things in kid-friendly ways.

4. LucasArts, Jedi Knight, and the Lucasfilm Family

Lucas Learning benefited immensely from their family tree. A small, brand-new educational software company would have a very difficult time starting up without a powerful license, and our ability to use the Star Wars universe was never in doubt. Furthermore, we enjoyed a special relationship as the sister company of LucasArts, and they made many of their resources available to help us jump start our own efforts. We contracted with their Sound, Voice, and Music departments, used their testers, and took advantage of their cutting-edge game technology, including their proprietary Smush video compressor and, most significantly, the Jedi Knight 3D engine.

When we first started adding details to the DroidWorks concept, interactive 3D graphics seemed an obvious fit, but we weren't sure we could do it. Time and budget constraints meant we didn't have very much time to devote to core technology, and with all we had planned, starting from scratch would mean cutting several key features we had hoped to include. When we realized we could use the Jedi Knight engine, then nearing its beta phase, the doors opened up for us. Not only would we have a real-time 3D engine, we would also have a custom-built level design tool (Leia) and an animation previewer/editor (ModelX), and we'd be able to find artists who had used both — in fact, two of our three level designers had worked on Jedi Knight. Better yet, we'd be able to grab the code immediately after it had gone through years of development and debugging.

Mission Briefing

Significant work had to be done to adapt the Jedi code, though. Pieces had to be ripped out, twisted around, and somehow welded into a new framework to turn a first-person shooter engine into a creativity tool. Then, a software funnel would have to be fitted to translate all the information from the workshop area of the game into a form the world simulation engine could handle. The final structure felt like a digital Frankenstein's monster, but the first time we saw a custom droid standing in an empty room in place of Kyle Katarn, the hero of Jedi Knight, we breathed a huge sigh of relief and thought "maybe this can work!"

DroidWorks would have been a very different project without the Jedi engine. We could have tried to build a new simulation engine, using some high-level 3D API such as OpenGL for rendering, but it could easily have ended up taking much longer. We could have created a new level design tool, or hacked something into an existing 3D modeling package, but we would have had to solve a whole host of other technical issues. We could have written our own scripting language and interpreter, prone to bugs. We could have thrown our hands up in the air and made DroidWorks in 2D… and what a different game it would have been!

5. The Violence Issue

Almost as soon as we settled on creating the game in an interactive 3D environment using technology from a first-person shooting game, our Director of Content, Jane Boston, spearheaded a debate that raged up until the very end of the project. DroidWorks exists in the Star Wars universe, a universe of explosions, guns, death, and violence. How much of that should we include in DroidWorks? What level of violence was acceptable? How could we create a story about saving the world from the evil Assassin Droids, in a game with "wars" in the title, without resorting to violence? And how do we even define what "violence" is?

Eventually, we decided to avoid violence at all costs, to bend the design in any way necessary to avoid a problem that would otherwise end in violence. There would be no gratuitous explosions, no laser guns, no death (just total loss of power or shields), and the Assassin Droids would have to get by with only their "shock" value — literally, since they disable you by touching you to drain your power. The gamers among us groaned, but everyone got behind the idea, and, remarkably, it turned out to be one of the better decisions we made.

Missoin Wet

Implementing the non-violence mandate often proved next to impossible as we drew trick after trick from our game design tool chests, throwing away idea after idea when we realized how much violence had become part of our everyday game vocabulary. As game designers, we're used to looking for the fun solution, the easy solution, so we resort to standard game vocabulary like bad guys hidden around corners or doors guarded by adversaries so difficult you avoid them until you've completed enough puzzles to have gained enough power. We had to throw away that vocabulary and try to find a new palette, and many times we banged our heads for days trying to find an interesting solution, wishing we could just hand over a laser gun or blow up a bad guy. Imposing the constraint forced us to get creative and pushed us into new territory.

We're very proud we created missions that require the player to think rather than react, and in the end, some of the kid advisors who had complained of not having violence or guns thanked us, saying they enjoyed it more. They described having the time to really use their brains and learn something while having fun, rather than shutting off their brains in order to react to violent situations. Needless to say, parents thanked us too.


Article Start Previous Page 2 of 4 Next

Related Jobs

Miami University
Miami University — Oxford, Ohio, United States
[12.11.18]

Armstrong Assistant Professor or Lecturer in Game Development
Game Changer
Game Changer — Remote Work From Anywhere, Kansas, United States
[12.11.18]

Mobile Game Programmer
Lockwood Publishing
Lockwood Publishing — Nottingham, England, United Kingdom
[12.11.18]

GO Backend engineer
Ubiquity6
Ubiquity6 — San Francisco, California, United States
[12.10.18]

Augmented Reality Prototyper





Loading Comments

loader image