Home

Introduction

The engine version this program focuses on is "The Godfather (2006)" and later. This game was originally released in 2006, with numerous 'upgraded' editions such as the "Blackhand Edition" and "Don's Edition" arriving later for Wii, Xbox 360 and PS3. The engine uses Renderware 3.7, with a custom proprietary portion of the engine to support non rendering requirements such as sound, gameplay and UI. The name of this is unknown, however some resource types refer to this as "EARS" (EA Redwood Studios?).

For "The Godfather II (2009)", the engine has had significant changes. Renderware is completely gone, StreamTOC data now lives outside of the Stream File and does not seem to be as important (maybe?), They developed their own proprietary model and texture format, which was used for all subsequent games and for "Dead Space 2 (2011)" they did a large refactor on the SimGroup system - the data which contains all the balanceable and logic data in the game. "The Godfather II (2009)" also has full networking support as well.

Between "The Godfather (2006)" and "Dead Space (2013)", EARS seemed to have lots of proprietary pieces of middleware too - The UI is powered by 'APT' (Used in Battle For Middle-Earth II), Cutscenes are developed using 'Trinity', and the VFX is called 'Alchemy'. More pieces of internal Middleware are expected to exist. It would not suprise me if these are used in other Non-Visceral games.

Almost all platforms have their data in Little-Endian, except PS3 and Xbox 360 (for obvious reasons). The format of the Wii files have not been explored. The PS2 assets are stored in the 'compact' format, so they lack more of the verbose information provided in other platforms.

Streaming

Note: In this section, we will be referring to two versions of the Engine. We will call them "V1" (The Godfather I) and "V2" (The Godfather II and beyond).

The game uses a streaming system to load in portions of the game - The "Stream File (.str)" is loaded at runtime either by using the filename or a unique 32-bit identifier (4 byte integer). The game then walks the StreamTOC and searches for the ".str" linked to the identifier. If one is found, its loaded. In V1, these files are split up into sections and have their own allocation sizes. Some sections are compressed by "RefPack" (Mostly seen in PS2, PS3 and Xbox 360 files). The sections are always aligned by 2048. In V2, sections are gone, and its a chunk based stream. The chunks are easily identifiable. The majority of the game content is compressed using "RefPack".

Stream files can contain "global" in their name, which usually means one of their resources is a StreamTOC. (We will revisit resources later.) The StreamTOC is essentially a large list of stream files associated to this "global" Stream. They are not loaded all at once. It seems that entries in this file also have some kind of parent-child hierarchy to them, but this has not been completely understood yet. The interesting part of this file is the section information for each entry - this is extremely important to adhere to when editing V1 games. Stream Files have their own allocation in their header, but this is seemingly unused if loaded via the StreamTOC. The allocation is packed into a smaller number of bytes, two used for the allocated size of the section, and the third byte is the type of allocator the game uses for the section. The types of allocators and how they differ is unknown, but it must be somehow important if the game needs to know for each section. The game will crash if the allocation in the StreamTOC is less than the amount required for the section to function. (eg. Stream File uses 16384 but the StreamTOC has 8192.). This does not appear to be as important in V2 and beyond.

The sections of a Stream File is pretty straightfoward. A section is comprised of a number of chunks, which are handled by the chunk system driven by "Renderware" (or is it driven by RWS?). For example, 1814 means this chunk includes a usable resource, such as a model or texture dictionary, and 1826 means it's a "SimGroup" format, which isn't a usable resource but should be considered as data to be fed into the Simulation (Such as entities in levels).

Resources

Each resource has a unique 128-bit identifier. The first 32-bit is usually shared with the 32-bit identifier found in the StreamTOC, and could of been generated using the name of the Stream File (this has yet to be confirmed). The remaining 96 bits seem to be split into smaller 32bit, 4 byte integers and are seemingly identical. The way these unique identifiers are generated is still unknown.

The header of a resource is very strict when it comes to memory alignment and padding. It is still unknown how to align the data properly, but the "Header" needs to be padded and so does the resource data (in some instances.) Then some resource types, such as VFX or ITXD_Dictionary (xbox original) need to have their own padding. It's all a confusing mess.