I recently started modding Fallout 3 which is a lot of fun and a painful experience at the same time. But before I start to explain why there is so much pain when modding Fallout 3 let me tell you first what you may expect from this post.
I am no veteran in game modding. The Universal Whiz Perk is the very first mod I ever created. But I am a software engineer with more than 25 years of experience in software development and a passionate gamer.
This blog tries to explain in detail what I learned after creating my first mod, which tools I used and why they are helpful. Which concepts in Fallout 3 are related to concepts in object oriented or procedural programming and how to avoid the many traps found along the way when creating a mod. But most importantly: I will tell you a lot about principles and practices used today by professional software engineers.
If all this sounds interesting to you, you might enjoy the post. So keep reading. Otherwise the chances, you won't like the rest of this post and get bored soon, are high. It's up to you ... make your choice!
Where does all the pain come from?
If you work as a professional software engineer you are used to the comfort and feature richness modern IDEs like Eclipse, Visual Studio or IDEA provide. Don't expect anything close to it from your main modding tool G.E.C.K. (The Garden Eden Construction Kit). This tool is just as rudimentary as a minimal productive development tool could be. For example: there are some editor windows (not only one) used to edit scripts which do not resize their editing region when resized. Damn! That's horrible, isn't it?!
The scripting language used in modding Fallout 3 has been reduced
to a bare minimum of commands, leading to lots of code duplication.
There is no language construct for a loop! You can't define your own functions
or procedures. I suggest you install FOSE (Fallout Script
Extender) to enhance your modding experience. It adds the commands
label
and goto
to the scripting language
providing a way to define loops and mighty branching. But when overused it
increases complexity and reduces readability instead of improving readability
and reducing duplication of code, which you want to avoid as much as
possible.
Refactoring, the act of renaming and restructuring source code, is not
supported by the G.E.C.K., even so it has all information necessary to
do it. Objects defined in the G.E.C.K. all have an
Editor ID
as well as a Form ID
used as a handle. All objects know about other objects using them. But the only
information shown when renaming the Editor ID
of an object is a
warning and the amount of objects potentially affected by the renaming.
If you are lucky, the affected objects refer to the object to be renamed
using its Form ID
, leaving them unaffected. But if they refer to
the object to be renamed using its Editor ID
, like source code
of a script mostly does, you are screwed!
But as I wrote before: creating a mod and watching it in action is still fun and I am already addicted. So lets get started creating a perk mod.
How should the perk mod behave?
The Universal Whiz Perk is the first perk mod I created. In this post I will use a slightly simplified variant of it to explain how modding in Fallout 3 can be done.
The Perk
we are about to create should reward the player with one additional
perk for every level. The additional perk should be granted when the player
has collected at least half the amount of XPs required to reach the
next level. The perk comes with a cost, the reduction of all XPs
gained by 50%. It's an attempt to balance the power of the perk.
Now that we know what to expect from the perk mod the next question is: how to start putting things together? There are two popular approaches in software development we may choose from:
- The Top-Down approach
- The Bottom-Up approach
Let me quickly explain the trade-offs of both approaches:
Top-Down vs. Bottom-Up
We could start creating the object representing a Perk
, give
it a name, attach an image and provide a description. This perk would be
immediately visible in the pipboy, even so it wouldn't do anything useful yet.
This approach is called Top-Down. You always start with the top-most
interface a user or system requires to interact with the software to be
developed. Behavior is added piece by piece while making progress down the
execution stack.
The positive aspect of using this approach is that you develop those requirements first, which you have the most complete understanding of. Furthermore you are able to inspect behavior added, by using the same interface you intend to be used when development has come to an end. A down-side of this approach is that you are likely to detect problematic issues, those that can't be implemented as envisioned, very late (most often the tricky technical details are found toward the bottom of the execution stack).
An alternative approach would be to first create the Script
(an
object type available in the G.E.C.K.), that brings the Perk-Selection-Menu
up. For testing purposes we could trigger the execution of that script by
attaching it to an Item
(another object type available in the
G.E.C.K.) and declare the block type of the script as OnAdd
.
This would trigger the execution of our script whenever the player would add
such an item to his inventory. This approach is called Bottom-Up, always starting with functionality sitting immediately above functionality that already exists.
Obviously one of the positive aspects using this approach is, that verifying if a critical aspect (how to provide additional perks to the player) can be implemented as envisioned, is done early. If the proof fails and we can't find any other implementation, we wouldn't proceed developing more software leading to a dead end.
A negative side of this approach is that we have to guess how to provide early implemented functionality to not yet implemented functionality intended to use it. Its similar to start building the interior walls of a house before its exterior walls. Where will the front door be? Where the windows? To test this functionality we often have to implement software we do not need later on, which is a waste of time.
Which of those approaches should we use?
We will use both! The Top-Down approach is the one we favor whenever we feel to be in control of what to develop next. It avoids to make us guess how functionality not yet implemented will access functionality we are about to develop.
But when we are in doubt if a requirement is even realizable or how the collaboration structure of G.E.C.K. objects may look like, we switch to the Bottom-Up approach, explore a bit and collect enough information to become confident again that everything can be implemented as intended, switching back to our favored Top-Down approach.
It requires experience, talent and discipline to know when to switch from one approach to another. You have to practice it over and over again and have to avoid driving on autopilot. Stay aware of what you are currently doing and don't get tired asking yourself: Am I doing the right thing?
Setting up the development environment
Before we can start to develop anything we have to install the G.E.C.K. Many articles already exists describing how to solve problems that may arise on different operating systems. Therefore I avoid to repeat everything here and instead provide direction where you will find those valuable information.
- Download the G.E.C.K. and install it to the same folder where Fallout 3 is installed.
- Download and install the G.E.C.K. 1.5 Patch as well.
Now find the file GECK.exe
inside your Fallout 3 installation
folder and start it. If everything went fine the G.E.C.K. should
startup. Make sure the version number is 1.5.0.19 by selecting
the menu entry Help > About
. In case the G.E.C.K. won't start up,
try to find a solution at the
G.E.C.K. wiki.
Close the G.E.C.K. for now.
The last thing we need to
do is download and install
FOSE.
It is provided as a 7-zip archive we must explode (if you don't have
a file archiver, download 7-zip).
Copy all files having an extensions of .exe
or .dll
into your Fallout 3 installation folder.
Create a windows shortcut pointing to the FOSE Launcher
executable and pass in the argument -editor
(see the screenshot on
the left).
That's it! Start the G.E.C.K. using the windows shortcut just created.
All functions as well as the commands label
and goto
provided by FOSE should be available in the G.E.C.K. now.
Creating the plug-in file
We have to create our plug-in file first. Hit the disc button or select
File > Save
from the menu. Name the mod file
Extra Perk.esp
(the G.E.C.K. will append the file
extension .esp
for Elder Scrolls Plugin by itself). We
have created an empty Fallout 3 plug-in but currently all resources
defined by Fallout 3 are not available in the G.E.C.K. To
get access to those resources we need to load the Elder Scrolls Master
file Fallout3.esm
as well. Hit the folder button or select
File > Data...
from the menu.
Notice that our plug-in file Extra Perk.esp
is already ticked and
has the status Active File
. This means that every changes we will
make in the G.E.C.K. will alter the active file only when
saving. It does protect us from accidentally altering files we never wish to
change (like the Fallout3.esm
). Add an author and description to
the plug-in file. Tick the Fallout3.esm
by double-clicking it and
hit the OK button. Watch the status bar showing the progress of loading
objects into memory (which may take a while).
Making the perk available in the pipboy
We will start using the Top-Down approach because we know what to do
to make the perk visible in the game. By default you should find the
Object Window
on the left side of the G.E.C.K., where
every object loaded from the files ticked (in our case the Fallout3.esm
and Extra Perk.esp
) can be accessed. You
can filter objects by selecting the object category they belong to. If you do not know to which category an object belongs select the category
labeled *All
.
In addition the Object Window
provides filtering of objects by
their Editor ID
. At the top left corner you can enter an
infix into the field labeled Filter
. All objects not
matching the infix won't be shown.
Some advices about naming objects before we start to create our perk. It is a good idea to choose a (hopefully rare) prefix for all objects we are about to
create to avoid naming conflicts with objects provided by Fallout 3
and other mods. It is an attempt to create an exclusive namespace wherein
names defined by our mod are unlikely to conflict with names defined by other
mods. This attempt does not guarantee to always avoid conflicts but it will
reduce its likeliness. For all my tutorials we will use the prefix
QWE
which is a very selective prefix and easy to remember
(look where the characters on your keyboard are located).
To create a new perk we have to select the Perk
category, place
the mouse into the right window and right-click. From the context menu select
the menu entry New
. The perk dialogue will show up where we
define:
- an unique editor
ID
used as a handle by objects referencing this perk - the perk
Name
as displayed in different views of the pipboy - the
Perk Description
as displayed in different views of the pipboy - a
Perk icon
as displayed in different views of the pipboy - the
Level
the player must have reached before he may pick the perk
Because the perk we are about to create is just an example, we may use an
arbitrary perk icon. I found one which is free-to-use, provided by
Bronod as part of his
Perk Pack 1.
I picked image 12.dds
, renamed it to extra perk.dds
and placed it into the folder <Fallout 3>\Data\Textures\Interface\Icons\Pipboyimages\Perks\QWE
. As you can
see it is a good practice to choose your own folder(s) for resources you
provide as part of your mod. It makes it easier to identify to which mod
resources belong.
It is relatively easy to create your own icons using GIMP and the DirectDraw Surface Plug-In. But I won't explain the how-to in this post, perhaps in an upcoming post. But feel free to find out by yourself, as I did.
The last thing we have to do is: save our changes! Before you start to test your mod, always check if you have to save first. The G.E.C.K. does indicate changes not yet saved by appending an asterisk to the file name of your mod displayed in the window title. Let's save
Installing the perk
Before we are able to see our perk in action we have to overcome some tricky technical issues.
First: we have to tell Fallout 3 to load our
mod as well. To achieve this we can use the Fallout 3 Launcher or we
edit the plugins.txt
file (which enumerates all files to load and
in which order) directly. The loading order can't be defined using the
Fallout 3 Launcher. You can find the plugins.txt
file on
a Windows 7 Operating System at the path
C:\Users\<Account>\AppData\Local\Fallout3
. If you use some
other Windows Operating System just search your drive for the
plugins.txt
file located inside a Fallout3
folder.
Open the file with any ASCII editor (like Notepad) and add the name of
our mod Extra Perk.esp
to the bottom of the file.
Second: we have to force Fallout 3 to not only
search for resources inside .bsa
files
(Bethesda Software Archives) but also from the Data
folder where our mod Extra Perk.esp
is located at. We have to edit
the FALLOUT.INI
file which on a
Windows 7 Operating System can be found at
C:\Users\<Account>\Documents\My Games\Fallout3
. Open the
file with an ASCII editor and change the line starting with
bInvalidateOlderFiles
from 0
to
1
. Otherwise the pipboy will display an error message
instead of the perk icon.
There is a good article about how Fallout 3 handles resources provided by mods. So if you are interested in a detailed discussion about this topic go and read the article .
Have you got the feeling all this configuration was very cumbersome? I would like to suggest you grab either Invalidation Invalidated which takes care about proper loading of resources provided by mods, regardless of if they do replace an existing or add a new resource. An even better choice in my opinion would be to install Fallout 3 Mod Manager instead. It contains Invalidation Invalidated already, provides a nice GUI to activate and define the load order of all mods you like to load. It detects the existence of FOSE automatically, using it instead of Fallout 3 Launcher to start Fallout 3.
Fallout 3 Mod Manager provides much more convenient features we are likely to use while developing our mod. Both tools are no must have. I will continue to explain how to achieve everything needed to create our mod even without those tools. But nevertheless they will make your life much easier, therefore worth your consideration.
Picking the perk In-Game
We are about to pick our yet-do-nothing-perk! Run
Fallout 3 by using the FOSE Launcher (which is the
fose_loader.exe
located inside your Fallout 3
installation folder. Load a game where you already have completed the
Vault 101 tutorial quest and have not yet reached the maximum
player level (which is 20 for Fallout 3 and 30 with the DLC
Broken Steel installed). Enter the in-game console and type
advLevel
. Here you go! After distributing your skill points you
should see our perk in the list of available perks. Congratulations!
Conclusion
This is the end of the first part of my tutorial. We have implemented the bare minimum necessary to see something of value inside the game. Besides we set up the majority of tools required to develop Fallout 3 mods.
Part 2 of my tutorial will cover the scripting of the perk, adding behavior to it. In addition I like to introduce the use of a Source Code Management System helping us to manage a flawless history of all changes we make to our mod. It is capable to restore the mod to every state it was in the past. So stay tuned!
I hope you enjoyed the post so far. Feel free to contact me either by e-mail or leave a comment on the Fallout 3 Nexus Site. If you think this tutorial is worth to be recommended, please consider to endorse it.
Logged Off: Harmlezz