Tamriel Rebuilt’s Development Pipeline
Since Tamriel Rebuilt is a very large project, we follow a mostly informal pipeline system to develop our content. The myriad tasks needed to release a new piece of the Morrowind mainland to players are broken up to be handled by different developers in a sequential manner. If you’re looking for a rundown on how far along in development we are, check the progress report.
Concepts
The first stage in developing a new district, region, faction, culture or other thing is to collect "canon" information about it, primarily from TES III books and dialogue, often from sources earlier in the series (most commonly TESA: Redguard, AESL: Battlespire, or the Elder Scrolls Travel series; less commonly TES II or TES I; only very infrequently TES IV; and (almost) never from TES V and ESO), or from out-of-game Bethesda sources of the era (developer roleplays on the forum, promotional interviews, etc). See more on our lore choices »here«.
Most commonly, however, the available canon information is only snippets, far less than what is needed to bring the subject matter to life inside the game world. Often, we will need to invent regions or factions out of whole cloth, as the sum total of TES III-era information on the Morrowind mainland is simply too thin. Therefore, experienced Tamriel Rebuilt developers with a good grasp of Morrowind lore and a similarly good understanding of what has been implemented in Tamriel Rebuilt so far will build a cohesive plan around the few canon snippets, fleshing out the subject's history, characteristics, and a first idea of how the practical in-game implementation will look like. Regarding a faction, they will often propose a questline for it. Regarding a region or district, they would propose a plan on how to divide it into several releases (i.e. expansions), so that players could access new content in an episodic manner.
Commonly, all this results in a long-form planning document first developed among a small circle, then opened for feedback to all developers and tweaked accordingly – hosted either on Google Docs or our forum. Sometimes, the plans are contained exclusively in long discussions on Discord, although that is far from ideal. Ideally, once a consensus has been reached regarding said plans, it will be transfered to the internal wiki we share with Project Tamriel, although as of early 2025, only very few of our latest plans are on there (volunteers needed!). Much of the information is also implicitly present on our in-development gridmap, which reflects our latest thinking on how the game world ought to look.
A large part of conceputalization is concept art – wider acceptance or rejection of an otherwise cool idea can hinge upon art that supports it, be it the tone of a new faction or a the look of a new region. Hence, developers planning a new district often cooperate with an artist; in fact, it is often the artists who drive conceputalization of new areas or factions.
Assets
The line between paper concepts and video game reality can only be breached by our asset developers. Without new assets – models, textures, sounds, etc – we are left reusing the same old vanilla region and faction assets on the mainland (see old Telvannis and much of our 2012-2013 Indoril lands), something we dearly wish to avoid in the future. Hence, developers who are willing and able to create new regional asset palettes hold a lot of power in deciding which direction the project can move.
New assets are organized and stored on the asset browser, where other developers will often post requests corresponding to assets need to be made, be they landscaping assets, architecture, furniture, clutter, clothes, equipment or creatures. Assets will be categorized and prioritized based on which of the proposed episodic expansions they are needed in, often explicitly stated on the wiki. Since most of what we need are 3D models, the tool of trade is typically Blender. Textures are typically made with Gimp, Photoship, Krita, or Paint.net, among other programs.
To start development on a new region, we first need a ton of unique flora, rocks, ground textures and sometimes architecture. Ideally, most of these will be made by a single dedicated asset developer, to best maintain a coherent style. More commonly, several developers collaborate in a process that can stretch years. The actual asset needs often become apparent only after an extensive iterative process in which asset and exterior developers collaborate in creating a test area.
Interior cave and architecture tilesets, furniture, and clutter are needed next, as they are crucial for building out the dozens to hundreds of interiors needed for a new expansion.
Clothes, equipment, creatures, and races (rarely) are, in theory, needed last, as they only really come to play once level design is done and NPC, dialogue, and quest creation commences.
Once an asset developer has made a new model or texture, and implemented it in the Construction Set so that level designers can use it, it will need to be reviewed by an experienced asset developer for technical quality, consistency with vanilla Morrowind art style, cohesion with our organizational structure regarding filenames, folders and Construction Set IDs, and all sorts of technical gotchas that the finicky TES III engine has. Much of this information is contained on our modding wiki.
Once reviewed, the asset will be merged into the in-development version of Tamriel_Data, the large asset repository that we share with Project Tamriel, and which is hosted on Github.
While ideally we'd like all assets to be in place in a timely fashion, in reality, asset development extends throughout a release cycle, with many assets created and added to the game world only days prior to release.
Exteriors
Once regional and architectural assets are done, level design can begin in the venerable TES III Construction Set. For performance reasons, the Morrowind worldspace is divided into the comparatively austere exterior and into many hundreds of more detailed interiors.
Both types of level design tasks are broken into "claims", i.e. chunks of work sized to be made by a single developer. All of these are first planned on the gridmap and then posted on our claims browser, where exterior developers can "claim" a certain portion of the game world, post in-progress CS plugin files for safekeeping, and present their completed work for review.
Typically, prior to development starting on a region, an experienced exterior developer will start with a reference claim, working with asset developers to make sure all needed assets are available and figuring out the best practises for using them region-wide. This work ideally results in an exterior design guide hosted on our wiki (e.g. »here«), needed for ensuring consistency within a region – although such a guide is not always made.
Prior to claims being opened, a senior developer will plan out their spatial positioning and the main points of interest present and post claim descriptions on the browser. This is where interior and quest developers should be closely involved, since the decisions made here will most affect their future work. Often, a region will also have a heightmap made prior to the claims opening, so that larger landforms could stay coordinated across exterior claims.
Once the exterior claim is more or less finished – something that often takes months – a task particular to exterior development is bordermatching, i.e. ensuring that the landscape seamlessly transitions between different in-development exterior claims and finished section files. This is usually done by "borrowing" neighboring exterior cells from other exterior claims, connecting the terrain and features across the border, then returning the modified border cells to the other claims.
Like assets, exterior claims are meticulously reviewed by experienced exterior developers to ensure that they are interesting, stay consistent with our design principles, and lack mistakes like jagged terrain or unintended floating/bleeding objects.
Once the first exterior claim of a particular area is done and reviewed, it is turned from an .esp file into an .esm file, becoming a section or release file into which all other reviewed implementation work on an area or expansion is merged, be they an exterior, interior, dialogue, or quest claim. These are essentially one-file containers for a full-blown Tamriel Rebuilt expansion.
Interiors
After an exterior claim is done, experienced interior developers will look over all of its points of interest – buildings, ruins, cave entrances, etc – and craft interior claim descriptions on the browser, giving prospective interior level designers a general idea of the purpose, needed architecture tileset, size, shape, and the overall wealth of the interior location. Here, quest designers also have a lot of input, given they have to work with the results produced by interior developers. Once interested parties agree with the plan, the claims are opened for level designers.
The time to complete an interior claim is often much shorter and the work less stressful than for an exterior claim – hence our interior department is typically the biggest and it is common for us to run out of new claims to give our developers. Interior claims are, therefore, commonly made and opened even for unreviewed or in-development exterior claims if it is reasonably sure that the placement of interior entrances won't change substantially.
After what is typically a comparatively short development cycle, an interior developer will post their finalized interior for review on the browser. Reviewers will then look at much of the same things as is done for exteriors, although the smaller scope typically allows for more detailed inspections. Finished interiors are merged into the section file.
Often, reviewers will have to go over interiors that have been merged previously in order to unify cluttering styles, lighting choices, and other aspects, should there be too much inconsistency within, say, a single town's interior. This duplication of work can be mitigated if a single reviewer reviews all interiors within a town or subregion – but that is often impractical.
NPCs, Dialogue, and Quests
Once level design is complete, quest developers can start populating the section file with NPCs and creatures, also done in the Construction Set and posted on the claim browser. Many hundreds of NPCs need to be added to an expansion's landmass and hundreds of lines of generic dialogue must be written for informational topics, in order to give regions and towns an overall character and inform the player of our lore. A relatively light sprinkling of unique dialogue is also added for many NPCs, as is the custom in the vanilla game.
This work is typically divided into claims corresponding to individual towns (or districts for larger cities) and wilderness regions, with each claim description mentioning important characters that an area is already planned to include. Since interior reviews tend to be a bit of a bottleneck, NPC and dialogue addition claims tend to open as soon as all interiors corresponding to an NPCing claim are reviewed and merged. The NPCer is given a lot of leeway in creating most of the needed characters and generic dialogue, so their choices largely dictate the tone of a town or region.
Once NPCs and generic dialogue is in place, quest development can start in earnest (although in practice, it often proceeds parallel to NPC and dialogue addition, as the later tends to be a bit of a bottleneck). Quest designs are typically planned out on brainstorming sessions on Discord, posted as design claims (or, for larger factions, as design documents) and opened only once most interested parties agree on them.
Ideally, all quests planned for an expansion would be known beforehand, and level design could proceed perfectly informed of the plans. More commonly, however, most quest designs only materialize at the trail end of level design, meaning that many tweaks and additions to exteriors and interiors are typically needed during the quest development process.
Experienced reviewers ensure that both NPC+dialogue and quest claims adhere to our design standards and lack bugs, once finished. A relatively large responsibility can rest on the shoulders of playtesters, as testing various cornercases and failstates can be a daunting task to a single reviewer, especially for relatively complex quests. As with exteriors and interiors, finished quests finally end up in the section file.
Bugfixing
Bugtesting and -fixing is a crucial step in development. It starts the moment a new section file is made and its pace intensifies all the way up to the day of release – or, as is unfortunately common, for weeks afterwards. Developers and players can post bugs on our bugtracker, where others can take them up to fix them, posting respective .esp files in the comments. Senior developers can then merge these fixes into our TR_Mainland.esm file or various section files.
Bugs can range from something small like an object placement error or dialogue typo, to larger and prevalent design issues, although very substantial tweaks that require review are encouraged to be posted as a claim, instead.
Often, newly added assets are distributed in the gameworld through "bugfixes" posted on the tracker, or deprecated assets can be switched out in a similar manner.
Release
Once a section file contains all of its exteriors, interiors, NPCs, dialogue, and quests, and is relatively free of major bugs, it is merged into our main TR_Mainland.esm file, which we distribute to players.
Any substantial expansion must conincide with a new release of Tamriel_Data, which contains all the new assets that have inevitably been added or switched out on the mainland during the development cycle.
Much work is also needed prior to the release in crafting a trailer and other PR materials, packaging, and updating documentation (see »here«).
Once the new version of our mod is uploaded, developers will post announcements on various Discord servers and other social media sites.