Kids Explore Space with MoonBaseOne

When I was in elementary school in southern Idaho, I spent my summers reading books at the library. (Yes, I was a nerd. How do you think I landed this job?) My favorite series was a collection of hardback books based on the nine planets in our solar system. I re-checked them out several times over the span of three years, revisiting the moons of Jupiter or the dry surface of Mars whenever the "astronaut bug" bit me. But space shuttles are hard to come by in rural America, so I contented myself with books as a means to explore the depths of space.

If only technology had been more readily available in my formative years. I might have played MoonBaseOne, an educational video game meant to expose kids to science, technology, and math. The game centers on the life of an astronaut on the moon in 2030. Players compete in a variety of adventures aimed at mining the lunar Regolith.




A group of volunteers from the Federation of Galaxy Explorers (FOGE) developed MoonBaseOne over the span of 18 months. It was originally developed as an educational tool at summer space camps, where 15,000 kids first encountered it, but grew more popular once released onto the Internet, delighting over 40,000 children around the world. GarageGames donated copies of Torque Game Engine to the developers of MoonBaseOne and recently donated new copies of Torque 3D for new space adventure games. While working out the details of the donation, I spoke with Jay Crossler, Senior Game Designer on MoonBaseOne, to talk to him about the challenges of creating this career-inspiring video game.

What is the Federation of Galaxy Explorers (FOGE) and their mission?

The Federation of Galaxy Explorers (FOGE) is a youth group seeking to inspire and educate kids in space related science and engineering. Similar in some respects to Boy Scouts and Girl Scouts, FOGE sponsors monthly "Mission Team" meetings, where adult volunteers teach space subjects and lead the participants in space science, earth science, engineering and rocketry projects. Participants can earn ribbons and patches indicating mastery of certain subjects. Space-themed summer camps are held, offering younger participants the chance to design and build a simulated moon base. High-school aged participants have the opportunity to build and launch rockets with simulated satellites (instrument packages) that can reach altitudes of up to two miles, which are recovered by parachute while transmitting real-time telemetry data on position, attitude, temperature and other parameters. Scholarships and directed mentoring programs are in place to help exceptional and motivated kids. While not directly sponsored by any government organization, FOGE has a number of volunteers and guest-teachers from NASA, the Naval Research Lab, and non-profit companies like MITRE.

What makes your game unique?

It's aimed at kids ages 11-17. When you think about it, this is a pretty wide age distribution to make something that is both educational and fun. It took a good deal of testing with kids from each age to make sure that it wasn't too heavy handed, but also helped them learn about the important sub-systems involved.

There are a few unique parts of MoonBaseOne that we haven't seen in any other games. The first is a pretty involved lunar mining subsystem, which encourages players to adventure outwards to dig for minerals. Different types of terrain yield different types of minerals (as realistically as we could make it based on real world Lunar data). Also, materials run out, so there are different strategies of where to mine and where to place mining robots.

The mining robots are my favorite subsystem, and the one that kids most often send an email about. I probably spent 200 hours just getting those to be fun. Robots have add-on packs that make them smarter, faster, or able to carry more minerals. They use swarm algorithms to tell each other where good minerals are (if you add in WiFi cards to the robots), and they can have better scanners to look farther out for good mineral locations. If you upgrade their CPUs enough, you can give them advanced commands.



The mining robots took about 200 hours of development time alone to make them fun and educational for the game's young audience.

What was your development process like?

I come from a government software engineering background and have built a number of large and small software applications ranging from a few thousand dollars to many millions. I found that working with volunteers is particularly challenging and fun. No one really "works for me," and so most people respond best by encouragement and motivation. We ranged from having just me working on the game, to a max of 6 people working on various parts. There were probably 10 people total who helped over the course of 18 months. We had volunteers from Fox Sound Studios helping with the audio, which was extremely useful in adding ambiance. About halfway into the project, we decided to mentor college kids for summer internships, and so I hosted four interns that each worked on one piece of the game.

We made this game because we want to help kids learn about space and science. We feel like we've helped make positive impacts on a lot of future scientists. None of us were paid, and everyone involved had full-time jobs and lives. Most of us put in our own funds to purchase all the other software needed, though we were very lucky that GarageGames donated a few licenses of Torque to us. That was really the key that made this all possible. Also, my company MITRE gave me 40 volunteer hours to work on it each year, which was great and very supportive.

What challenges did you face managing volunteers rather than paid developers?

Volunteers are really motivated by knowing that their contributions matter. They all have real jobs and usually very full lives. Most of the time, they'd like to put in 4 hour chunks and never really can commit longer than a month out. We probably interviewed 50 volunteers who expressed interest in helping when we put out various "call for volunteer" applications online. Out of these, only 2 people ever contributed to the game, though this is where we discovered Andre Morales, our top modeler. He made all of the excellent interiors of the Moon Base.

Also, most volunteers might have played many games, but I really needed people to help with the C++ engine code or other niche skills. Luckily, I was able to also get many volunteers, including a professional writer who helped with the dialogue and a professional musician who did the theme music. Again, these people are paid in karma, not cash, so I became very good at thanking them and showing them how much their efforts were appreciated.

This overall experience was amazingly useful for me. I think it really changed how I work with my developers and team members during my day job. I try to treat everyone like a volunteer, whether they are employees are not. This makes for a much better, more energetic work experience. I think this is something that a lot of software managers could learn so that they behave less like the manager in Dilbert.

What tools did you use?

We initially started designing in Flash, but that became too cumbersome. As soon as GG donated the Torque licenses, I jumped into them wholeheartedly. At the same time, I was appointed as the Serious Games lead for a lot of government organizations (day job stuff), which also encouraged me to move towards the 3D environments of Torque. The clincher was when a few coworkers made a very cool UAV-flying simulator using Torque for a different project - I then knew that I could do something really fun with this. I put together the first version of the Moon Base using 3D Studio Max and did all the scripting in Textpad (yeah, that was painful). All the textures were in Photoshop and doing UV-mapping and animations took forever to get right.

Every time we got a new volunteer who could put in a few hours, I pretty much reinvented the tool chain to aim to their experience. We probably used every tool imaginable, based on what the volunteers had software licenses to. For example, on graphics, we rotated through Photoshop, GIMP, MS Paint, and eventually some free web graphics editors. After about a year of this, I had one of the interns write up a "how-to" manual that described what tools to use, how to use them, and what free counterparts were available. This was really helpful. We wound up working with LightWave 3D for models, Visual Studio.Net for programming and scripting, Photoshop for graphics, and Audacity for audio. We used Subversion for code checkin-checkout and Basecamp for project planning. The best overall tool wound up being our developer blog, which gave us a central rallying point to quickly get people up to speed. Giving commands or having conversations with other characters was done using the YackPack.



"Managing volunteers really changed how I work with my developers and team members during my day job. I try to treat everyone like a volunteer, whether they are employees are not. This makes for a much better, more energetic work experience." - Jay Crossler, Senior Game Designer

What technical hurdles did you face during development of MoonBaseOne?

Technical Hurdle 1: Buzz Aldrin yelled at me because the dirt didn't look realistic.

I'm serious - he was pretty ticked off about it. I presented the first version of MoonBaseOne to the Board of Directors of the Galaxy Explorers. Everything was going very well until Buzz Aldrin, who is on the board, saw how the dust plumes were coming off of the astronaut's boots. He really thought that it looked very unrealistic and let me know in a lot of detail what moon dust really felt like. This was both amazing and horrifying to hear such details from a guy who was really there. I had to really tap-dance to explain the trade-off between graphics cards, 3D models, and graphics shaders. Also, he really wanted us to strive for a better balance of STEM (Science, Technology, Education, and Math) in the mandatory lessons that were built into the game. He put it pretty well - some parts of the game were too "space invaders" and others were too "boring and lecturing." They needed some optional incentives to learn. That really prompted us to do some more testing to make sure kids thought it was fun. We wound up going to space camps, watching the kids play, and then made a list of updates to try out the next week. Eventually, we had to even take out the dust plumes because we just couldn't get them perfect and they wound up being distracting.

Rather than making a lot of the tests and classroom quizzes mandatory, we made them optional to get add-ons for your robots. We originally just had six different robots that you could buy, each costing more than the last and being faster and more powerful. If you look through the code, you'll see there's a lot of complexity involved with the robot updates. The "Lunar Academy" has a list of text files in the client directory, and each text file lists the question, the correct answer, and then any number of wrong answers on separate lines. The final line (if present) is the type of robot add-on best associated with the question. Thus, when you answer a question about GPS navigation satellites, you get a Navigation add-on for a robot. You can collect these add-ons from the academy or as quest items from other NPCs. The more add-ons you have on your robots, the better they perform, and it all came from that one comment from Buzz. I released the source code for the Lunar Academy as Creative Commons if anyone wants to use it.

Technical Hurdle 2: Getting a timer to count down the game play and to trigger events, even if the user switches away from the game.

We noticed early on that during the space camps the lines to play the MoonBaseOne game got really long. We had multiple laptops in a kiosk that could be played, but some kids would play for 30 minutes and so the lines would get to be hours. We came up with the idea that we would make an adventure mode that recorded your score in 10 minutes of game play. I initially built the timer in TorqueScript, which counted down from 600 to 0 seconds and would update a display.

Some kids eventually found out that if you alt-tabbed out of the game right when an event was to occur (such as the game ending) then tabbed back, those events wouldn't get fired. I found one kid that had a huge score because he'd been playing for an hour. Whenever the clock approached 0, he'd alt-tab about twenty times so the event would get lost. This inspired me to go into the engine code and build a new countdown script that had an array of events in it. Thus when an event was fired, it would mark it as complete even if a trigger was missed. This also gave me the ability to better add time to the clock or to dynamically add events "30 seconds from now," etc. Again, a small observation turned into a real capability that we could use. Adding in a scoreboard that tracked scores really got the kids to want to play harder and increased the excitement. A current problem I'm seeing is that some kids that download the game are hacking the HTTP streams that send their scores up to the server, so I've started working on an encryption scheme to lock those in, but haven't yet implemented it.

Technical Hurdle 3: Getting the game to play on older class-room level computers and Macs.

This was our hardest challenge. The first few versions of the game had a lot more robots, items, and particle effects. We started getting the feedback that it was running way too slow on a lot of classroom computers that we'd test it on. Most of these classrooms had PCs that were 5 years old and didn't have graphics cards, and so were getting frame rates less than 10fps. This wasn't working, so we took a purge to really reduce the polygon count. This hurt - we had to yank out a lot of the content that looked really nice. This was even harder because some of our volunteers that built 3D models only gave us the final DTS shapes and not the .3ds or .lwo shapes needed to build them. The terrain was too big, and all of the textures were 512x512 pixels. So, we went through and reduced the number of events and triggers, took out some of the initial robots and reduced most of the texture sizes to aim for 64x64. We eventually got it so that older machines would hit about 20fps, a playable frame rate.

The other problem is that most classroom machines are Macs, and we wrote this only for the PC, a big mistake not understanding our "customer." Because I had done so many engine changes and recompiled the kernel with Visual Studio, I just couldn't figure out how to compile it to the Mac. It's still a problem that we haven't fixed, and it doesn't really run well on VMWare or Parallels. This actually led us to decide to use Torque 3D when Beta 3 was announced to have full Mac support. We really want to get Mac support for the next games, as that's what most students these days use and work with. Plus, I've now converted to being a Mac fan, and I really see the benefit that Macintoshes bring to education and students.

Did you face any unique challenges in creating a serious educational game, rather than a traditional video game?

We had to have everything pass a number of reviewers - the kids of course (who let us know if it wasn't fun), but also a number of teachers, science enthusiasts, and volunteers very passionate in this area. There were quite a few conversations like: "The space suit you are using is the wrong color, has pipes in the wrong place, and should have a control panel here" or "Why mining spiders? NASA's currently funding wheeled robots" or "Why is this set in Shackleton crater? The chances of ice there are 4% less that in this other crater." We can only acknowledge these observations and ask for forgiveness. We took a certain amount of poetic license. Someone shared the code for a jet pack on the GarageGames forums, and it was so much easier to just use that than to get all the details perfect. Plus, the kids LOVE the Jet pack. Other than the spider robots, they're the second favorite thing in the game. We really tried to get as many core concepts right and add drama and emotion.



Making the game fun while also maintaining its educational balance was something the developers worked hard to accomplish.

If you had to do it all again, what would you change about creating this game?

I would have spent more time working on getting a team together from the beginning and getting them to commit. We really needed to have one Business Lead that could manage people, time and resources in addition to the Technical Lead. Doing both at once was overwhelming. Also, having an experienced Torque Developer to help would have saved me a hundred small false-starts. Finally, releasing small pieces aligned to functions, rather than planning for everything to just gel together at the end, would have been smart. That would have made it easier to get more buy in and more help.

Also, I would have spent more time getting the dirt plumes perfect before showing it to Buzz.

What does FOGE have next up its sleeve?

We're currently working on the next major video game from the Galaxy Explorers. We feel that MoonBaseOne was very successful. Getting out a published game to 40,000 players is wonderful. This was the stepping stone to bring in even more volunteers, and we have another team (also from MITRE) that are making a multiplayer space game that runs on Xbox Live. It's pretty cool and very, very fun. We also are extremely excited about Torque 3D and will start putting together some trial ideas. We'd like to have a game integrated in a web site to make it easier for all of these schools to let their kids experience our games. Torque 3D looks like it will drastically cut down on our development time, especially when getting new team members up to speed on using all the game building tools. We're very excited and are so glad that GarageGames is helping us to help kids!


==

Thanks again, Jay, for your time and your energy spent on this game. I sincerely wish I would have had access to it in between reading those planetary books. But if Buzz thought your space plumes weren't realistic enough, he probably wouldn't have gone for graphics on the Commodore 64! ^_^

For more stories like this, check out GarageGames' Developer Interview series.