An official update on the project is long overdue, so I'll try to make the most of this one.  We have been so focused on production that we have not communicated as much as some people would like. We will look to improve the frequency of our updates and have the dev team post on the forums about the specifics of our development. The good news is that things continue to move along rapidly and I am very pleased with the writing and level designs we have so far. The players were vocal in their desire for mature, violent and strange and that is what we will be serving. 

Beyond tone it is the individual moments I remember most when playing a great RPG.  The curiosity of wondering how things might have changed based on my actions kept me engaged and wanting to re-play. And our job as designers is to make sure that the different scenarios that play out based on your choices cause real consequence. There is a small moment in the new Rail Nomads camp in which you hear a boy calling out for help as he is drowning. This time it would be a lack of action that could cause his death. Do you swim out to middle of the lake and save him or ignore his plea? And what happens when you are spotted ignoring his plea by a local resident? Do you shoot him before he can let others know of your behavior? These are situations that play out in the Wasteland. Each area has so many combinations and permutations of playing that it is almost statistically impossible for two players to have the exact same experience playing through the game for the first time. This design philosophy is what made the first Wasteland so great and why people continued to play it decades later.

Although not part of our original design for Wasteland 2, we felt that having portrait pictures of the enemies would add much color to the game. We have several artists helping to shape the look of things and we are quite happy with the vibe of bleak, violent, and unusual.

 

And some fans have had a little fun morphing the two together for extra creepiness.

The composer, Mark Morgan has now turned his attention to the music that the player hears while exploring in the Southwest. We asked for the music to have that bleak, edgy, lonely vibe mixed in with a dark western ambient. It's unusual to be working on music this early in the process but once again it allows for iteration time and for us to be as creative and nuanced as possible. Another excellent benefit of having fans fund the game.

The sample of the music is at the bottom of this update.

We have been very focused on getting the writing wrapped up by end of October so that we can do a table read of the entire game. Things are on track for about 95% of it which will allow all of us to get in a room for days on end to step through the game play. We look for flaws in logic, world consistency, keyword consistency, adding personality, adding ways to solve problems, creating visual cues, extra word descriptions, etc. It is quite a bit of work but it is a process that creates cohesion so that it feels like one world. There is so much content that the only way to grasp it all is to sit in a room for days for everyone to absorb.  And quite often the best moments will come from the random ideas that spring forth from it all.

One of the qualities that makes for a strong technical director is their ability to build systems around the philosophies and aims of the game itself. John Alvarado has done an excellent job for us in the past and continues to do so for Wasteland 2. At the end of this update is a write-up by John that dives a bit deeper into the programming side of creating a deep RPG.

And now, I give you John Alvarado….

--Brian Fargo

Wasteland 2 Engineering Update: Decisions, Decisions

Brian has emphasized that Wasteland 2 will put the player in the position of making tough choices that have deep affect on the unfolding story.  Every decision comes with some tradeoff—some known, some only to be revealed later.   There are so many paths through the adventure that it is likely no two players will have the same experience.   This is an apt metaphor for the process of game development.  In this update you’ll learn about some of the game systems the engineering team has been developing, and I’ll delve into detail on important decisions we’ve made around our story-scripting and localization systems.

Every game system we build involves making decisions about how to solve a challenge.  Thankfully, Unity gives us a big head-start by providing many built-in solutions, saving us the work and reducing the decisions we have to make (in a good way).  Using Unity was one big decision we made early on that has paid dividends.   But there are still challenges particular to Wasteland 2 that we must overcome, and that means making tough choices that will have consequences for the rest of development and the final product. 

As we weigh different approaches to a challenge, we attempt to gaze into the future and discern how the consequences of different decisions will play out with respect to design requirements (known and potential), content pipeline, run-time performance, and development time/cost.  Fortunately, our engineering team has decades of experience over dozens of successful projects that help us make most of these decisions with confidence.  So far we have made engineering strides on the following systems:

·         World Map System

·         Movement and Turn-Based Combat System

·         Saved Game System

·         Character Animation System

·         Inventory system

·         World State Tracking system

·         Story Scripting System

·         Localization System

We now have a player-controlled Ranger character moving with animation in a game-level and interacting with NPCs, triggering conversations and changing world states that affect future interactions.  This is where we wanted to be at this time and we are right on schedule.  Brian stressed to the engineering team the importance of having this ready by the time the writers are finishing up their level designs and story so we can begin implementing, testing and iterating.   That priority and the desired iteration process informed some important engineering decisions.

Conversations

There are many ways that the systems supporting conversation functionality could be structured.  I built such a system for The Bard’s Tale, <shameless-promotion> inXile’s first game which was released to critical acclaim back in 2004/2005 for consoles and PC, and which is now storming the top-10 charts on mobile devices with 5-star reviews as the funniest and biggest RPG’s on mobile. </shameless-promotion>   The Bard’s Tale was a very large game and handled a lot of dialogue with many branches and world states to track.   Here is a breakdown:

4,594 Lines of Dialogue

6,412 Localized Text Strings (including dialogue and UI)

1,720 World State variables

 

Wasteland 2 promises to be even bigger in the amount of dialogue and world states.  A world state is any information that must be remembered for the story to advance properly, such as what quests have been completed, what NPCs have been talked to and what information they have given.

At first glance it made sense to reuse the Bard’s Tale system, but one major difference is that The Bard’s Tale dialog was all voiced by actors. That meant all the dialogue and story was going to be fixed very early on in order to record the audio in voice acting sessions.  There would not be much iterating on story/dialogue in The Bard’s Tale.  The exact opposite is true for Wasteland 2 as there will be a light amount of voice acting in order to give us the freedom during development to modify, extend, and polish the dialogue and story right up to the very end! 

Localization Challenge

However, all that dialogue still has to be localized (translated to multiple languages) and that presents an engineering challenge.  In The Bard’s Tale we used a rather cumbersome system that required entering text into a spreadsheet and assigning unique labels to each piece of text before you could use the text in a game script.   The designers referenced the text with the unique label.  In this way the localization system could present the proper language text based on the unique label and the game’s current language selection.

While cumbersome, the text-entry only had to happen once and the story was very fixed so the designers didn’t need much flexibility with respect to modifying the text while scripting.  For Wasteland 2 it’s important for designers to be able to modify text quickly and easily throughout development, so that old cumbersome system just won’t do.  

For Wasteland 2 I’m relying on today’s faster CPU’s and larger RAM capacities to lighten the localization burden on the designers.   I’m allowing designers to place the English text of their dialogues directly into the scripts.  They just have to include a unique label at the start of the text.   At runtime the game localization system parses out the unique label from the string and then, depending on the language setting, will display either the English text it has in hand, or lookup the translation with the unique label and display the translated text.   Currently that means if a non-English language is active then more memory is used for a level because both the English text and the local language text is loaded. 

 

Text Auto-Extraction

The missing piece in what is described above is how all that embedded English text gets organized to send out for translation.  I’ve written an offline tool that parses all the scripts to extract the English text strings and create the spreadsheet that we can then send out for translation.  That tool is written in Ruby, a language that features powerful regular expression functionality that makes it easy to parse the C# script files to pull out the English text strings.  Helping that process is the fact that each string starts with a distinctive syntax to specifies its unique label.  It looks like this:  “<@label>text”.   For example:

"<@AboutRobotStrength>Robot strength is 10 times human strength, but we only use it for peaceful applications, such as mixing drinks."

The Ruby tool finds and extracts that string and generates an entry in a spreadsheet like this:

Label: AboutRobotStrength

English: Robot strength is 10 times human strength, but we only use it for peaceful applications, such as mixing drinks.

Because some English strings are also entered as game object properties inside game levels (Unity scenes), the tool also must parse the Unity scene files to extract strings.  Fortunately Unity provides the option to store its scene files in text format, which we are using to allow the extraction tool to do its work.  The tool also uses the script file references in the scene files to figure out what strings from the scripts need to be loaded up for each game level. 

I’m leaving out some details, and the extraction tool will likely evolve a bit as development progresses, but this is basically how it works.  It was a tough decision to abandon a system I already had working (from The Bard’s Tale), but it was the right choice to spend some development time to give the designers the tools they need for the special demands of Wasteland 2. 

Conclusion

Hopefully this peek behind the scenes gives you an idea of where we are in development of Wasteland 2 and helps you understand the factors we consider in our careful approach to engineering decisions.  Choices we make early on have a major affect on the team and how our story of developing Wasteland 2 will unfold.  Experience gives us some wisdom to guide us, and sometimes reusable tools and a bag full of tricks, but every project is different, and we must always step back and re-evaluate the current demands in light of current technology and the time and budget we have available in order to make decisions that will bring you the best product possible.

John Alvarado

Technical Director