USS Rivet City – Presentation from Games for Change 2012

Article, Katelyn Procci No Comments

Katelyn Procci | July 23, 2012

When we were but two mere semesters into graduate school, Alen scoured my Facebook and made this. Well, a few years later, I was lucky enough to present RETRO’s work on our Rivet City mod at the 9th Annual Games for Change Festival. Rather than show off what we did, instead I was presenting on the lessons I learned while we attempted to use a mod to make a serious game. Below you can watch the presentation, download the slides, and read a very abbreviated version of the presentation. And people did show up. Take that, Alen!

Source: Games for Change Livestream [slides]

USS Rivet City: Lessons Learned from Modding Fallout 3 for Serious Games Research
Katelyn Procci, Daniel Brown, and Clint Bowers
Presented June 20, 2012 — 9th Annual Games for Change Festival

The ability to mod games is a powerful tool for anyone who would like to make a game but doesn’t have the resources to do so. It’s something we can all do. Rather than show off a mod we made, I instead will share what I learned about modding games so that you may learn from my experience and apply these lessons to your own development projects.

When I am talking about modding here, I mean making use of software tools provided by the developer to change a game to add in original content – quests, maps, skins, you name it. Modding games prolongs the shelf-life of a game, increasing replay and making them more commercially viable. User communities generate new missions and content for games, and mods themselves can become games. Half-Life mods gave us Team Fortress Classic, Day of Defeat, and Counter-Strike, a franchise which continues to be a commercial success. Mods encourage innovation, and provide useful feedback to the developers themselves [1]. Nevermind that really great modders can be hired, so they can turn their passion into a career: Example 1, Example 2.

The utility of modding transcends benefits to the gaming industry. Modding tools provide invaluable resources for those interested in creating game-based experiences, but don’t have a lot of money or personnel to do so. Rather than attempting to create a game using an existing engine, modding tools are more accessible to those teams that have less programming experience and for those who maybe don’t even have their own artists.

We created a mod to help train shipboard navigation skills in US Navy recruits. We decided to create a game environment in which recruits had to use their knowledge of the compartment marking system to play. When we were trying to brainstorm what kind of game we wanted to make and how we would do it, one of our researchers suggested that we just mod Fallout 3 and add a quest in Rivet City, rather than develop something from scratch.

In Bethesda’s Fallout 3, one of the major in-game locations, Rivet City, which is a large US Navy ship modeled in-part after a World War II aircraft carrier, the USS Oriskany. Fallout 3 comes with an extensive editor, the Garden of Eden Creation Kit, or GECK. It was perfect. Rivet City is a big ol’ confusing ship and we could mod it by putting the placards over every door in accordance to the navigation system and then build quests into the game that required players to go to those doors.

With our very small amount of funds, we hired Dan Brown for three months, who was then an undergraduate at UCF. He had a programming background, knew how to photoshop, and was very interested in modding and game design. Our team was made up of the two of us. Our project, codenamed USS Rivet City, was broken up into three major phases: planning, development, and testing. I would watch the presentation for the juicy details and further explanation, but here’s the gist of it:

Step 1: Plan

1. Have a plan with defined goals. Clearly state your objectives. What do you want to achieve? Be explicit so you know exactly what you want.

2. Determine what tools and capabilities you need to meet your needs based on your goals and objectives. Consider the following:

  • Dialogue – Are you allowed to interact with NPCs and hold conversations?
  • Levels/Quests – Are there quests you can edit, can you add new ones to create unique missions?
  • Assets – Are you able to edit and create new objects, textures, skins? How extensive is the library and what is already in it?
  • Environment – Can you change the physical environment?
  • Support – Is there community that you can draw upon for help?

For each of these, you need to think about whether you want to be able to change what exists, or if it already aligns with your specific needs.

3. Explore your options. Many games come with level editors and construction kits. For you, we’ve selected a few newer games (newer because they’re more likely to have advanced editing options and active community support) that may be fairly promising for creating new serious games:

  • Creation Kit (Skyrim – Bethesda Softworks)
  • Hammer SDK (Source engine games – Valve)
  • Electron Toolset (Neverwinter Nights 2 – Obsidian Entertainment)
  • WC3 World Editor (Warcraft 3 – Blizzard Entertainment)
  • Dragon Age Toolset (Dragon Age – BioWare)
  • With such detailed editors and incredible support from both developers and the modding community, what you can create pretty much whatever you want. My advice is that if you are low on people, time, and money, really think about the kinds of assets in these games. We didn’t have an artist, and having higher fidelity was more important for us, so modding a ship that already existed was perfect for us. But, if you can hire an artist, then you can create whatever objects you need and then focus on capabilities (quests, dialogue, etc.) rather than art constraints.

    Step 2: Develop

    1. Set a timeline, and then give yourself double that time. These tools have a learning curve, things will go wrong, and you’ll wish you had given yourself more time later. When I asked Dan what he’d do differently, he said that he would focus less on editing the environment and more on refining the quest itself.

    2. Ask the community for help.. When I asked Dan what was awesome about the GECK, his answer was the community behind it. You are NOT alone. Trial and error is a great way to learn, but chances are, someone else has had the same problem that you are having and now knows how to fix it.

    Step 3: Test

    We tested the mod… And it was a total failure. Even though they just had 30 minutes of practice using WASD+mouse controls before playing our mod, most participants spent their time running into corners, staring at ceilings, and walking awkwardly into walls. It seems we had made the most rookie mistake possible — we failed at user-centered design in our mod.

    1. Make use of user testing at some point. Iterative user testing, beginning early in the design process, would have alerted us to this problem earlier and we may have been able to fix it.

    This is a critical methodological issue for serious games research at universities. We often don’t have access to our target population and have to make the best of participant pools, usually made up of first-year undergraduate students taking a psychology class as a part of their gen-ed requirement. This is a problem for both design and development in that both usability and validation testing samples what is potentially the wrong population. I have no idea if our mod would’ve worked with recruits because didn’t have access to them. Build it into your contract, plan on collecting, beg, do what you need to get real user input, even for a mod. Which leads me to my second point… Even if you do have access to members of your target population:

    2. Understand that your player may not be a gamer, but the game you’re modding was probably meant to be played by one. The interface may be confusing, the controls may be difficult to master to someone who is, essentially, a noob. One solution is to provide more training – build a better tutorial into your mod, make it a part of gameplay, ease the player into the action. You should simplify gameplay and the interface, if possible. Another option is to provide alternative control inputs. Maybe, because the corridors were so tight in our mod, those not great at using the keyboard for moving the player-character would have fared better using an X-Box 360 controller.

    These were our more important lessons-learned. User testing is critical, even for something that is “just a mod.” You must understand your future players’ level of gaming knowledge, experience, and expectancies, and cater your design to them. No one learns from something that they can’t figure out how to even play.

    The Seven Lessons Learned from Modding Rivet City

    So, if you are a small dev team, with not a lot of people, time, or money, and you want to make a game, to either encourage change or to contribute to the science of serious games, please, consider undertaking a modding project. It seems daunting, but it’s not that scary, as long as you keep the following seven lessons in mind:

    1. Define your goals
    2. Determine your needs
    3. Pick the most suitable game/tools
    4. Give yourself more time than you think you need
    5. Ask the community for help
    6. Make use of early and iterative user testing, even for “just a mod”
    7. Design with your player’s level of gaming familiarity in mind


    References

    1. Kücklich, J. (2005). Precarious playbour: Modders and the digital games industry. The Fibreculter Journal, 5.


No Responses to “USS Rivet City – Presentation from Games for Change 2012”

Leave a Reply


9 × nine =