How Shadow of War works inside

A technical reference to the engine behind Middle-earth: Shadow of War: how the executable is organised, how the game streams, stores and renders its world, and how its AI, combat, animation and Nemesis systems work.

Everything here was established by reverse engineering the Steam release (game version 1.21): static analysis of the executable, inspection of the running game's memory, and parsing of the shipped archives. Code locations are given as offsets from the image base 0x140000000, so they apply to every run of that build. Questions that remain open are listed at the end of each chapter.

Foundations

• About this reference
  What this reference covers, which build it describes, how the facts were established and how to read addresses and layouts.
• The executable: sections, functions, vtables, libraries
  The layout of ShadowOfWar.exe: where code, vtables and globals live, how many functions there really are and why the exception table is not the list of them, vtables with and without run-time type information, the C runtime's initializer tables, the linked libraries, how the build's whole-program optimisation shows in the code, the engine's allocators and the most-called runtime primitives.
• Engine core: managers, globals and key objects
  The engine's top-level objects and the static slots that reach them: the game manager and its subsystems, the client shell, the main scene and the AI world, the engine interface and its services, the update root and object server, the UI and world-UI owners, time and frame counters, and the tests that say whether a world is loaded.
• Threads and the frame
  Every engine thread and its routine, how a thread is started, what the main thread does each frame and in what order, and how the render thread consumes the main thread's commands, renders the scene and presents.
• Resource streaming, bundles and the file system
  How a path becomes loaded data: the file system's mount vector, the resource table, the open / load / parse stages and their request object, bundles and their reference contract, and the creature-bundle manager that decides which creature models exist in a region.
• Archives and file formats
  How to open the shipped data: the LTAR archive family and its byte layout, name resolution and its traps, Oodle chunking, the archive config list and how the engine decides which copy of a file wins, the BNDL / EMBB bundle pair, textures and their tiers, meshes, skeletons and string tables, with the coverage measured on every shipped file.
• GameDB: schema, records and field bindings
  How the game's data database is stored and used: the GADB file, the loaded tables of categories, records and field descriptors, the slot rule that places every value, the value types and RecordLinks, name hashing and lookups, and the code side - the type table, the schema slots, the field getters and the compiled copies that decide whether a changed value is seen.
• World: regions, layers, placements and world objects
  How a region's world is assembled from streamed parts, what a world part holds (the object registry and its fourteen blocks, static placements, prefabs, terrain and vegetation), how placed objects look in memory, how the engine creates, binds and moves them, and the world data behind traversal (context-action lines), weather-gated effects and collision.
• Scripting: HavokScript, world scripts and natives
  The game's scripting layer: the HavokScript virtual machine and its bytecode, where every world layer's script lives, how layer scripts are compiled and cached, how scripts reach engine records and natives, the event dispatcher and the running-script stack that some natives require, and the shipped script corpus.

Graphics, media and motion

• Rendering: the D3D11 layer, passes, shaders and lighting
  How the renderer drives Direct3D 11, the wrapper functions and the 55 pass entry points, the deferred G-buffer and its lighting classes, the surface overlay and fog passes, shader trees and the node table that holds them, the 220 global shader constants and what they reveal, material parameters, and the atmosphere, colour-grading and weather systems that decide the world's look.
• Visual effects: ClientFX data and runtime
  The ClientFX effect system end to end: the .fxp format and its loader, the 36 node types and their property schema, the five effect managers that own live instances per time domain, the instance and resource layouts, the per-frame tick split between the main thread and the FX background thread, the request path, GPU particles and budgets.
• Audio (Wwise) and video (Bink)
  How the engine plays sound through a statically linked Wwise 2016 and video through Bink 2: the engine interface, the sound manager and its game objects, posting an event end to end, banks, the AudioHooks dialogue graph, and the movie manager, video resources and the movie data.
• Animation: clips, behaviour graphs and the runtime
  The engine's own animation system (Havok Animation and Behavior are not used): the .anix clip format and its codecs, where a loaded clip lives and how events are pre-parsed, which characters can play a clip, the .bvr behaviour graphs, and the per-frame runtime from the behaviour state through clip trackers to the pose job on the animation worker threads.
• Physics: Havok integration
  How the engine embeds Havok 2016.2: the new-pipeline (hknp) world with legacy-pipeline ragdolls, the engine's handle to the world, the world's layout and gravity, the material palette and its half-precision fields, what is live and what ships unused, the Havok heap, the tagfiles that carry navigation meshes and collision shapes, and the surface types that decide footsteps, climbing, shooting through and impacts.

Gameplay systems

• Characters, the player and the camera
  The character object and its key fields, the player, the camera pipeline and what the screen actually reads, near-camera dissolve, the character controller with its collision layers and trigger volumes, Wraith World and the wraith companion model, weapons and holders, runtime material slots, render IDs, mounts, and Talion's material controller.
• AI: planning, perception, spawning and group combat
  How an NPC decides what to do: the planner and its plan tree of steps, target selection and threat, perception, the sighting matrix, alertness and forgetting; how NPCs come into the world through the spawn manager, ambient spawners, spawn channels, templates and summon requests, with gangs, bands and mounts; the AI budget and constants the engine copies at start-up; and the fight pits.
• Combat: attacks, targeting, predicates and resources
  How combat is decided and executed: combat objects, the compiled attack cache and its 105 predicate evaluators, targeting and the three copies of a lock range, the player's input tree, ranged shots, cooldowns, Might and ammunition, the fight circle that decides who attacks, combat actions and states, area attacks and the player's execution companions.
• Items: inventory, gear, affixes, gems and skills
  How items and gear work: the inventory inside the visual component, the item instance, affixes as the only source of gear stats and their level-indexed values, equip deltas on the player's stat table, gems and sockets, what a save keeps, the item lists combat requires, skill rows and the Skills screen, weapon looks and slots, and gear effects.
• The Nemesis system: factions, captains and the army
  The faction system and its pools and 38 armies, the FactionMember object and its saved fields, the seat table of every army's rows, the nemesis flag word and its engine setters, faction events, turns and sim events, cheat death and the event history, the ambush queue, rarity and Training Orders, followers, bodyguards and mercenaries, and how story and DLC characters take seats.
• Captain appearance: bodies, armour, colour and scars
  How a captain's look is chosen, stored and drawn: the appearance object, the seed that rolls body, size, head and colours, armour designs and the items that carry them, the army's level-based outfits and title looks, painted skins, scars, limbs and shoulder pads, tint layers, eyes and decals on screen, how grunts are dressed, and when a changed look reaches the world and the Army screen.
• Captain traits, classes and personalities
  How a captain's traits are stored, rolled and re-rolled: trait slots and their gate word, the resolver and the rebuild loop, exclusive groups, what a save keeps, the trait card's rows and text markup, and how class, advanced class and personality are represented.
• Quests, story and scenes
  The campaign state store, the quest table and the quest object's state machine, how story characters are built, betrayals and region ownership, army transforms, and the presentation system that plays scripted scenes: relays, events, sequences, actors, cameras, the scene clock and slow motion.
• User interface: Scaleform, menus and the debug menu
  How the game builds and draws its interface: the UI manager, the generic view host and the UI render list, the Scaleform movies and the node API that drives them, menus and the HUD as GameDB data, the Army screen's 3D stage and camera, the title, save-select and loading screens, and Monolith's developer debug menu with the cheat backend and console behind it.
• Saves, the store and the network layer
  The save file format and its encryption, the typed section grammar and what each slot section holds, the engine's own save switch and the new-game flow, the client side of the old in-game store, and the dormant peer-to-peer network stack with the asynchronous online modes.
• Comparison with Shadow of Mordor
  How Shadow of Mordor (2014) differs from Shadow of War at the file and engine level: the executable, the archive format and its compression, container and asset format versions, the GameDB, the orc skeletons, materials and textures, the Army screen's arena, and the Mordor-to-War nemesis importer that ships inside Shadow of War.

25 chapters, 423 sections. Updated 2026-10-30. An unofficial fan research project, not affiliated with or endorsed by Warner Bros. Games, Monolith Productions or Middle-earth Enterprises. Middle-earth: Shadow of War belongs to its owners.