Scheduled system upgrade on Sunday 21 April 2024 15:00-16:00 UTC - On that day, the wiki and other services might go down for 5-15 minutes.
Overview: Difference between revisions
Jump to navigation
Jump to search
→Code: Fix link
imported>Leoetlino No edit summary |
imported>Leoetlino (→Code: Fix link) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This article provides an '''overview''' on the implementation of ''The Legend of Zelda: Breath of the Wild''. | This article provides an '''overview''' on the implementation of ''The Legend of Zelda: Breath of the Wild''. | ||
''Breath of the Wild'''s internal project name is U-King<ref>The [[executable]] binary is called U-King, and numerous other assets refer to the game as U-King.</ref>. | |||
== Framework and engine == | == Framework and engine == | ||
''Breath of the Wild'' is a modern Nintendo game which was released in March 2017 for the Wii U and the Switch. | ''Breath of the Wild'' is a modern Nintendo game which was released in March 2017 for the Wii U and the Switch. It shares a lot of code with contemporary first-party Nintendo games such as ''Splatoon 2'' and ''Super Mario Odyssey'', notably the '''sead''' (Nintendo's in-house framework and utilities for first-party titles) and '''NintendoWare''' (GFX, audio, effects, and UI) [[Software libraries|libraries]]. | ||
''BotW'' is the first major Nintendo game to use '''XLink''' (EffectLink and SoundLink) as a system to make | ''BotW'' is the first major Nintendo game to use '''XLink''' (EffectLink and SoundLink) as a system to make bridging code and graphics or sound effects easier, and also marks the first significant use of event flows (via the EventFlow or '''evfl''' library) to implement in-game events such as cutscenes and NPC interactions. | ||
=== Engine === | |||
A completely custom engine – which Nintendo seemingly calls [[KingSystem]] – is used for ''Breath of the Wild''. It appears to have been written from scratch as nothing significant is shared with previous Zelda games or even older Nintendo games. In particular, ''Breath of the Wild'' does '''not''' use LunchPack or ''SMO''<nowiki/>'s engine, even though games using the former appear to use a ''BotW''-inspired ROM structure. | A completely custom engine – which Nintendo seemingly calls [[KingSystem]] – is used for ''Breath of the Wild''. It appears to have been written from scratch as nothing significant is shared with previous Zelda games or even older Nintendo games. In particular, ''Breath of the Wild'' does '''not''' use LunchPack or ''SMO''<nowiki/>'s engine, even though games using the former appear to use a ''BotW''-inspired ROM structure. | ||
=== Physics === | |||
The game relies on the [[Havok]] physics engine for [[wikipedia:Ragdoll physics|ragdoll physics]], [[wikipedia:Collision detection|collision]] (Physics2012), navigation (NavMesh), and [[wikipedia:Cloth modeling|cloth modeling]]. ''Breath of the Wild'' does not use Nintendo's KCL library. | The game relies on the [[Havok]] physics engine for [[wikipedia:Ragdoll physics|ragdoll physics]], [[wikipedia:Collision detection|collision]] (Physics2012), navigation (NavMesh), and [[wikipedia:Cloth modeling|cloth modeling]]. ''Breath of the Wild'' does not use Nintendo's KCL library. | ||
== Architecture == | == Architecture == | ||
Just like any other Switch game, executable code is stored in the ExeFS – with the game code in the main [[executable]] – and [[content]] files or assets are stored in the RomFS. | Just like any other Switch game, executable code is stored in the ExeFS – with the game code in the main [[executable]] – and [[content]] files or assets are stored in the RomFS. In the context of ''Breath of the Wild'', the latter is referred to as the game ROM. | ||
=== Code === | === Code === | ||
| Line 18: | Line 22: | ||
The codebase appears to be compiled with high levels of optimisation enabled for both Wii U and Switch releases, with code on the latter platform being better optimised. Since 1.6.0 (Switch only), the game is additionally built with [[wikipedia:LTO|LTO]] enabled, which results in massive amounts of code bloat. All known public releases are stripped, i.e. don't contain any debugging symbol. | The codebase appears to be compiled with high levels of optimisation enabled for both Wii U and Switch releases, with code on the latter platform being better optimised. Since 1.6.0 (Switch only), the game is additionally built with [[wikipedia:LTO|LTO]] enabled, which results in massive amounts of code bloat. All known public releases are stripped, i.e. don't contain any debugging symbol. | ||
The game is divided into several components and makes heavy use of managers, which are singletons that are usually responsible for one specific task (e.g. PlacementMgr for actor placement, EventMgr for in-game events, etc.). Unlike older Zelda games, most managers are dynamically allocated, not stored in BSS. In general, ''Breath of the Wild'' makes use of the heap and virtual functions a lot more. | The game is divided into several components and makes heavy use of '''managers''', which are singletons that are usually responsible for one specific task (e.g. PlacementMgr for actor placement, EventMgr for in-game events, etc.). Unlike older Zelda games, most managers are dynamically allocated, not stored in BSS. In general, ''Breath of the Wild'' makes use of the heap and virtual functions a lot more. | ||
In total, there are 130+ [[subsystems]]. | In total, there are 130+ '''[[subsystems]]'''. | ||
=== ROM === | === ROM === | ||
Resources are organised by type into a [[Content|directory tree]] with nested directories. | '''Resources''' are organised by type into a [[Content|directory tree]] with nested directories. | ||
Each resource type often has its own distinct file extension even when the file format is exactly the same. For example, [[Bgparamlist|Bgparamlist (GeneralParamList)]] and [[Blifecondition|Blifecondition (LifeCondition)]] are both [[AAMP]] files, but they have different file extensions because their types and purposes are different. | Each resource type often has its own distinct file extension even when the file format is exactly the same. For example, [[Bgparamlist|Bgparamlist (GeneralParamList)]] and [[Blifecondition|Blifecondition (LifeCondition)]] are both [[AAMP]] files, but they have different file extensions because their types and purposes are different. | ||
==== Archives ==== | ==== Archives ==== | ||
Because the game tends to load several resources at the same time, related files are grouped and packed into archives to improve performance. Resources are packed [[Actor pack|at the actor level]], or [[Beventpack|at the event level]], or based on the moment they are loaded by the game, which is the case for [[Dungeon pack|dungeon packs]] and top-level [[Pack|packs]] for instance. | Because the game tends to load several resources at the same time, related files are grouped and packed into '''archives''' to improve performance. Resources are packed [[Actor pack|at the actor level]], or [[Beventpack|at the event level]], or based on the moment they are loaded by the game, which is the case for [[Dungeon pack|dungeon packs]] and top-level [[Pack|packs]] for instance. | ||
This archive system does result in content duplication, but it is a fair space-time tradeoff. | This archive system does result in content duplication, but it is a fair space-time tradeoff. | ||
| Line 44: | Line 48: | ||
=== AI system === | === AI system === | ||
{{empty section}} | |||
=== Event flows === | === Event flows === | ||
{{empty section}} | |||
=== Demos and cutscenes === | === Demos and cutscenes === | ||
{{empty section}} | |||
=== GameData flags === | === GameData flags === | ||
{{empty section}} | |||
=== Maps === | === Maps === | ||
| Line 56: | Line 64: | ||
=== Stages and stage binders === | === Stages and stage binders === | ||
{{Link to article|link=Stage|include=}} | {{Link to article|link=Stage|include=}} | ||
Maps which share characteristics with each other and use the same set of [[subsystems]] usually require very similar initialisation and main loop code. In order to avoid code duplication, ''Breath of the Wild'' moves such shared code into '''stages'''. As an example, all Hyrule and Trial of the Sword maps are handled by OpenWorldStage. | Maps which share characteristics with each other and use the same set of [[subsystems]] usually require very similar initialisation and main loop code. In order to avoid code duplication, ''Breath of the Wild'' moves such shared code into '''stages'''. As an example, all Hyrule and Trial of the Sword maps are handled by OpenWorldStage. | ||
| Line 68: | Line 75: | ||
=== AutoPlacement === | === AutoPlacement === | ||
{{empty section}} | |||
=== Resource system === | === Resource system === | ||
{{empty section}} | |||
== File formats == | == File formats == | ||
| Line 79: | Line 88: | ||
Other commonly seen file formats include [[BFRES]] (models), [[BFSTM]] (sound streams), [[BFLYT]] (layouts) and various other standard NintendoWare formats. | Other commonly seen file formats include [[BFRES]] (models), [[BFSTM]] (sound streams), [[BFLYT]] (layouts) and various other standard NintendoWare formats. | ||
<references /> | |||