Fallout's writing

[Jesterka]

...start smal...

Hey, and what about "learn to swim or get drown" method?

Look I'm swimming as hell after 4 years! Eastern Europeans are tough to destroy.

Anyway, cruel conditions of yours. Will be interesting to see whether or not are possible an exceptions. Like most of that naive TC guys (alike me).

 

[Ardent]

When modders have limited time, the solution isn't to skip the process of making a design document. The solution is to pick a smaller, less-ambitious starting point.

Design documents are a way to pre-think your material so that you don't run into problems later. As a cogent example, during the development of Fallout (1) I discovered a problem with Gizmo. As written, there was a particular entry point that you could take (dialog-wise) for which he had no initial response. Since Gizmo had animation and recorded voice, this was a serious problem - we couldn't go back and record new material; it was already done. Luckily we had the float_msg system and it was an entry point for which Gizmo could brush off the player, so we added a float_msg and called it a day. I never would have caught this bug if I hadn't been looking at the design document and then realized that there was a fall-through case for Gizmo when the player entered dialog. It probably would've been found later in bug testing, but that would not have been a great time!

As an example, I've been (very slowly) working on a Fallout 3 addition. It's very small: two areas, about 5 characters. That's deliberate. I don't spend 8-10 hours per day on this, so I am keeping it to a scale that I can reasonably handle. IF I finish this mod and it all works, THEN I can start on something more ambitious and large-scale.

I applaud the notion of total conversions and big-time whole-cloth creations. Just realize what you're getting into! A full-time (and overtime) staff of paid professionals takes YEARS to make a game like Fallout. Expecting a team to do it part-time in a shorter period is a recipe for disappointment.

Start small. Build a proof-of-concept. Work from established elements. When you have a functioning component, expand. Plan tight. Ruthlessly cut extraneous elements and focus on the essentials. After you have successfully produced material, move on to something newer and better. There's no sense trying to make a massive mod or a totally new set of script commands when you haven't become fully familiar with the original material in small, controlled conditions. Even the professionals made plenty of mistakes, after all . . .

Thank you for this post. Although you are 100% right, many modders (including myself) will try to pull the trick off nevertheless. I guess it's because for some, the sheer process of making a mod is a satisfying enough experience.

Your advice is to start small. Does starting small in the scope of something BIG still counts? I mean, doing a small and straightforward (script-wise) quest, or a shopkeeper's script/dialogue, but all in accordance to the design docs for the whole game?

When I'm comfortable with the simple things, I move on to the more complex ones, but all of it is part of the "Total Conversion Project Name What Be It". Does that sound feasible? I guess I'll find out soon enough...

Anyway, thanks again for the post - I do very much appreciate your taking part in the discussion.

 

[Jesse Heinig]

During Fallout 1 dev we had some instances in which a particular design document was incomplete and we worked out a skeleton of an area, then went back and filled it in later. Often this is a good way to lay down a foundation, but having a design doc in advance is always a good idea because you don't want to wind up going back and re-doing all of the work that you already did. Not only is it time-consuming and error-prone (because you'll change something in one place and it will have an effect on a dialog or quest elsewhere) but it's tedious, because it's not fun to go back and redo material that you were enthusiastic about three months ago.
A good way to do your modding is to start with a proof-of-concept. Design a single zone with a specific pair of characters or a single instance of a new item that you want to implement. Finish it entirely and then move on to the next task.
If you plan to make your proof-of-concept material part of a larger mod, like a total conversion or a restoration mod, then make sure you have at least an outline for the later material. In general - though it's not always possible - have a complete document for the area you're doing and at least an outline for any area that ties to it, by exit grid, quest, character, or item interaction. Ideally you'd have that outline for your whole project before starting.
Design docs aren't just useful for a personal reference. If you're working on a total conversion or restoration mod, you are unlikely to be doing so alone. Discussing all of your changes with your team via email is a good way to lose your old design choices, and if you bring on new talent later in the process they may not have the easiest time coming up to speed. A design doc or design wiki allows all of your team members to be on the same page and to make changes that everyone else can immediately read and understand. It's not just pointless bureaucracy; it's a means to give your team a way to stay on the same page and avoid later consistency issues.
Last recommendation: Before you jump into a total conversion or restoration mod, start with practice on a small-scale mod. Work up a document and then implement, say, a single new quest with a new character in an existing zone, or make one new map and populate it. This gives you time to familiarize yourself with the tools and get a handle on how long it takes to perform various tasks. Once you're better acquainted with the tools you will have a good idea of what you can handle, and what may require a lot of work (like making new script commands or building a whole new zone and adding it to the world map).

 

[Ardent]

Thank you, Jesse, that's exactly how I'm trying to proceed.

I learnt most of the script commands and the rest toying with a test location. Then I started making maps for my mod, and adding NPCs to them. The first town took the longest, of course, but it helped me master or at least "apprenticiate" the tools Now map-making takes only half the time it used to and scripting goes 4-6 times faster than before.

My team isn't very big - I only work with my brother who takes care of most of the graphics side and helps me with the storyline, dialogue and NPC design. Thus we have very little problems with keeping our builds up to date.

Before we start a location, we have a complete, or at least 90% complete design document with all the necessary info - descriptions, map layouts, NPCs (with descriptions and tips on dialogue style), quests, etc. We also have a series of docs about general things in game, such as how the XP numbers progress, or how the equipment evolution progresses. There is a separate design document for the main quest and its elements, as well as changes to the world as the story unfolds.

Since we're only two, we avoid some of the cumbersome elements of modding, such as new critters, talking heads, loading screens, worldmap, movies, etc. Instead, we concentrate on the storyline and tying quests and NPCs together, since it were the different and complex relationships between the communities, organisations and single NPCs that we liked best in F2.

I hope we'll be able to finish one day. Keep your figers crossed!