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
