Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: LucasLearning's Star Wars DroidWorks
arrowPress Releases
May 27, 2019
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 3 of 4 Next

What Went Wrong

Actually, very few things went unexpectedly wrong in the creation of DroidWorks. The team just moved together so well that, time after time, what seemed to be insurmountable roadblocks from a distance proved to be minor bumps when we actually approached them. Not that we didn't have our share of mind-numbing challenges that left us with our hands in the air! We had aimed so high that we couldn't possibly include everything we had hoped for in the beginning, and many features we wanted to include had to be cut (Where's the print button? And why can't you plug an arm into the head socket?)

1. Jedi Knight

Ironically, the choice to use the Jedi Knight engine rather than rolling our own 3D world simulation system proved to be one of the worst problems we had to face, even though it's also one of the best decisions we made. In retrospect, we go back and forth trying to decide whether it was the right thing to do. Could we have saved the time and energy we put into working around its limitations by creating a new engine from scratch that would address our needs directly? We'll never know.

Game interface

In choosing the Jedi engine, we hoped to benefit from its physics simulator as much as from its rendering engine. We wanted our game to teach simple physics in an open-ended environment, and we hoped concepts of velocity, acceleration, and gravity, would just fall out of the simulator. How wrong could we have been! The level designers closely control the world of Jedi Knight, and the physics engine had been tuned to make maximum fun out of running characters and flying projectiles. We had hoped to teach interactive real-world physics, not cartoon game physics in which the main character could run 80 miles an hour, nothing bounced, and nothing could be pushed! We expected a fairly robust dynamics simulation but wound up with sphere-based collision detection in a system that often couldn't properly respond to the collision of two moving objects. The lack of rotational forces sure made it difficult to build levers and fulcrums.

By the time we discovered how difficult it was to create complex combinations of physical puzzles within the constraints of the existing system, we had no choice but to move forward with the game plan. We constantly had to redesign the missions to accommodate the physical quirks of the engine, ultimately scripting many key interactions where we had hoped the physics engine would "just work." With heavy scripting by our level designers and a few custom modifications to the engine, we managed to create missions that worked well within the engine, but unfortunately they fell somewhat short of our original design intentions.

Designing for the Jedi engine posed other problems as well. In a game like Jedi Knight, almost all significant player interactions with the world has been scripted by the level designers and the animators, in a situation where they know everything about the character ahead of time. The character has been completely modeled and animated ahead of time, and his or her strengths and weaknesses have been determined well in advance. In fact, many physical constants are hard-coded into the engine itself! DroidWorks, we felt, must give the player choices during droid construction that have tangible physical consequences when they take their droid into the game world. "Make the droid matter," we chanted. In Jedi Knight or Tomb Raider, level designers know exactly how tall the character is, how far she can jump, how much she can lift, whether she can pick things up… In DroidWorks, we couldn't even promise the level designers that the character tackling their worlds would have legs!

Another hurdle we didn't see coming was the Jedi Knight art path. They had used 3D Studio to model and animate their characters, while our artists wanted to use Softimage. The Grim Fandango team had also chosen recently to use the Jedi engine for rendering, animation, and collision detection, and they had proven in concept an art path from Softimage. What the heck, we thought, it's just data…. After outfitting our artists with Softimage and starting the production process, we discovered hidden bugs in the data path that caused glitches in our animations and scaling problems in our models, problems that often required a complete rebuild for us to fix. Time after time, we found ourselves manually editing text files containing pitch/yaw/roll values to fix problems introduced during the translation from Softimage… Ouch!

2. Complexity: "Make The Droid Matter"

The number of combinations possible in DroidWorks gives it its power. How many droids can you build from 87 droid parts anyway? At one point during development, we could build over 65 million fully functioning droids, but design decisions forced us to cut it back to "only" 25 million by the time we shipped. How do you deal with that kind of complexity?

To begin with, we knew we could never test the game completely. It would take one person 290 days working round the clock building one droid a second just to build them all, let alone test them. A team of ten testers building a droid every minute in a non-stop 8-hour day could do it in 14.25 years if they agreed to work 7-day weeks. Like a sim game, we knew we would ship the game without complete testing coverage. Our testers accepted that challenge and did a great job covering a huge variety of droid types.

Our level designers also saw the nightmare of complexity. They could never be entirely sure what kind of droid would be walking into their rooms, and they had to leave the levels as open as possible. In many cases, they created ingenious physical filtering mechanisms that would guarantee certain types of droids beyond certain points in the level: a steep hill would weed out biped droids in favor of droids with tractor treads, a chasm would weed out wheeled droids who can't jump, a narrow canyon would weed out wide droids, and a short door would weed out tall droids. They used the terrain leading up to key puzzles to reduce the complexity of the puzzle itself, giving kids a chance to uncover the mission requirements themselves within the context of the game rather than being told "you can't bring that kind of droid here."

3. Positioning

In part because we used the Jedi Knight engine, and in part because we designed it for fun, DroidWorks looks more like an entertainment title than a traditional educational product. In our minds, the real beauty of DroidWorks lies exactly in that constant tension between entertainment and education. If we hoped to attract the attention of eight- to twelve-year-olds, we felt we had to give them something that could compete for their attention with the likes of Quake or Jedi Knight, something that would interest them and that they would have fun playing — a game! We believed we could combine traditional game-play elements with new and interesting kinds of physical puzzles, creating a game you think through rather than shoot through, and we pushed hard to steer the company in that direction.

From the beginning, our Kid Advisory Groups gave the game rave reviews, but many adults greeted it with confusion. How could something that felt so game-like be educational enough the be called a "Learning" title? How would we explain it to the public, who expects to find products on the "game" shelf or the "education" shelf? At some point, reality hit us full in the face, and we had to decide how to position the product and the company. Which shelf should be our home: entertainment or education?

We had very little data, other than hunches. Who made the purchasing decisions in this age range? Parents typically look on the Education shelves, while teenagers and pre-teens typically look on the Game shelves. Teens wouldn't want to play a game they found next to Barney or Barbie, would they? Additionally, we were piggy-backing on the LucasArts' sales force in order to get into CompUSA, Best Buy, WalMart, Costco, and other big stores… and all their distribution channels led straight to the entertainment shelf. In the end, that's where DroidWorks landed, too.

Landing in the entertainment category proved problematic for DroidWorks. On those crowded shelves, DroidWorks disappears amongst action-oriented shoot-em-up games. Its bright blue box stands out from the dark tones of the adult games and catches the eye, and it feels strangely out of place. Furthermore, retailers have shorter attention spans for products on the entertainment shelves than they do for educational products: if a game doesn't disappear in the first two weeks, the stores send it back. Despite its great reviews and the press coverage we garnered in the month or two prior to its release, DroidWorks had a difficult first month of selling, and we started thinking our particular education/entertainment blend might be just too confusing for consumers. Luckily, stores gave it a break — thanks to the Star Wars name and the muscle of LucasArts' distribution — and by the end of the month, sales had improved and things were looking up.

4. Timing

DroidWorks also had its share of timing problems. We originally planned a fairly luxurious development cycle that had us landing on shelves in time for Christmas 1998. About half way through production, after looking at the numbers, Marketing decided we should aim for Labor Day instead, the official kick-off of the back-to-school buying season. Everyone agreed, so we took a deep breath, re-worked major pieces of the design, and made some heavy cuts. The team rallied behind the new date, and we managed to hit our sign-off date.

As the game took final shape, the company marketing effort began to kick into full gear. Until that time, Lucas Learning had no public presence. Our mission and message had never been projected to the outside world, so we weren't just marketing a product, we were marketing an entire company. We had lived in the cocoon of secrecy that typically surrounds George Lucas' endeavors, and the time had come to start opening that cocoon to let the world know what we were up to. That process turned out to be harder — and more time-consuming — than expected.

While the development team cranked away making the product, the marketing team cranked away designing the box, advertisements, and collateral materials. The entire company watched in frustration as complete materials were proposed, created, and shot down in their final moments. Labor Day came and went, and we had no approved box. Magazine advertising deadlines came and went, and we watched in horror as the ever-present Christmas holiday approached. Finally, an approved package came down, and we landed on shelves in October, with our first magazine ads poised to hit newsstands in December, barely in time for Christmas.

5. Growing Pains

Although we had several aces in our hands, including guaranteed private funding and one of the most popular film licenses in the world, Lucas Learning was still a startup. We had to hire staff, find space, clarify our vision, define our culture, and adopt processes for doing everything. On DroidWorks, almost everything we did we did for the first time, and even though we had a lot of industry veterans on board, we often ran on hunches, not having time to pause the project to figure out the "right" way to do something.

C3PO, R2D2 and some jawas

Building a company while building a groundbreaking product is a difficult task. We tripped a few times, and we cobbled together many of our processes from bits and pieces of past experience. It turned out all right, and many of them worked well enough to be common practice in the company now. Others, however, fell apart when the light of day shone on them after the project, and there are many cases today where we look at what the Droids team did and say "this is exactly the wrong way to do this."

Ah well, we all learn from our mistakes… Centralize your asset database, even if you're working with outside contractors — we ended up using Access, FileMaker, and Excel to track various kinds of assets, depending on the format used by our suppliers. Don't try to track art production too closely, as collecting, processing, and keeping up-to-date all that information takes more time than it saves. Keep whatever assets require internationalization in a single database from the beginning, not scattered around in several obscure files that also contain non-internationalized assets. These are just a few of the things we did while we devoted our brains to other urgent tasks.

Article Start Previous Page 3 of 4 Next

Related Jobs

Gear Inc.
Gear Inc. — Hanoi, Vietnam

Technical Director
Dream Harvest
Dream Harvest — Brighton, England, United Kingdom

Technical Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Animation Programmer
Ubisoft RedLynx
Ubisoft RedLynx — Helsinki, Finland

Senior/Lead Graphics Programmer

Loading Comments

loader image