Welche Software nutzt Nintendo für die Spieleentwicklung – Tools, Programmiersprachen, Engines, Frameworks und Versionsverwaltung?

**Ja – aber nur teilweise öffentlich. Sicher bekannt ist: Nintendo entwickelt viel in C/C++, nutzt eigene interne Engines und Middleware, erlaubt auf seinen Plattformen auch Unity, und für Switch 2 wurde die Toolchain samt SDKs und Asset-Tools weiter ausgebaut. Nicht öffentlich belegt ist dagegen, dass Nintendo konzernweit auf Git setzt.** ([careers.nintendo.com](https://careers.nintendo.com/jobs/4094467009/)) ## Was man mit hoher Sicherheit sagen kann Nintendo veröffentlicht nur einen kleinen Teil seines internen Tool-Stacks. Deshalb ist die präziseste Antwort nicht „Nintendo nutzt Tool X“, sondern: **Nintendo nutzt je nach Studio und Projekt eine Mischung aus eigener Technologie, Plattform-SDKs und ausgewählter Drittsoftware.** ([developer.nintendo.com](https://developer.nintendo.com/)) Klar belegt sind vor allem diese Punkte: - **Programmiersprachen:** vor allem **C/C++**; bei einzelnen Rollen und Studios auch **C#**. Das zeigen aktuelle Nintendo-Stellenanzeigen sehr deutlich. ([careers.nintendo.com](https://careers.nintendo.com/jobs/4094467009/)) - **Toolchains/Compiler:** Nintendo-nahe Teams arbeiten mit **LLVM, GCC und MSVC**. Das ist ein starker Hinweis auf plattformnahe, performanzkritische Entwicklung statt „nur Engine-Editor anklicken“. ([nerd.nintendo.com](https://www.nerd.nintendo.com/files/Job%20Offer%20SYS2025%20EN.pdf)) - **Engines/Middleware:** Nintendo hat eine eigene Linie namens **NintendoWare**, darunter die **NintendoWare Bezel Engine**. Für Switch 2 wurde diese Umgebung weiterentwickelt. ([siliconstudio.co.jp](https://www.siliconstudio.co.jp/en/news/pressreleases/2025/250701switch2/pdf/NewsRelease_switch2_20250701_en.pdf)) - **Externe Engine-Unterstützung:** Auf dem Nintendo Developer Portal ist **Unity** offiziell als Middleware gelistet; die Distribution für Wii U und New Nintendo 3DS wurde beendet, was zugleich den Plattformwandel zeigt. ([developer.nintendo.com](https://developer.nintendo.com/tools)) ## Engines, Frameworks, interne Tools Der wichtigste Unterschied zu vielen anderen Publishern ist: **Nintendo scheint nicht auf eine einzige Konzern-Engine zu setzen, sondern auf mehrere interne Frameworks und projektspezifische Technik.** Öffentlich greifbar ist vor allem die **NintendoWare Bezel Engine**. Besonders aufschlussreich ist eine aktuelle Mitteilung von Silicon Studio: Dort steht, dass das Unternehmen Nintendo bei **SDKs**, **Shadern** und einer ganzen Suite von **Asset-Creation-Tools** unterstützt hat – darunter **Model-/Material-Editoren, Effekt-Tools, Layout-Utilities und Shader-Entwicklung**. Außerdem wird Bezel ausdrücklich als Engine hinter „many Nintendo Switch titles“ bezeichnet. ([siliconstudio.co.jp](https://www.siliconstudio.co.jp/en/news/pressreleases/2025/250701switch2/pdf/NewsRelease_switch2_20250701_en.pdf)) Die praktische Konsequenz: Nintendo arbeitet nicht nur mit einem „Game Engine Editor“, sondern mit einer **kompletten Produktionsumgebung** aus Engine, SDK, Shader-Workflow und spezialisierten Content-Tools. Das ist deutlich näher an einem klassischen AAA-Inhouse-Stack als an einem reinen Unity/Unreal-Workflow. ([siliconstudio.co.jp](https://www.siliconstudio.co.jp/en/news/pressreleases/2025/250701switch2/pdf/NewsRelease_switch2_20250701_en.pdf)) ## Programmiersprachen: was wahrscheinlich intern läuft Für **Core-Gameplay, Systems, Middleware und Hardware-nahe Features** ist **C/C++** der klare Standard. Das passt auch zu Nintendos Fokus auf feste Hardware, Performance und enge Verzahnung mit Plattformfunktionen. ([careers.nintendo.com](https://careers.nintendo.com/jobs/4094467009/)) **C#** taucht in einer Nintendo-Software-Engineering-Stelle ebenfalls auf. Das heißt aber nicht, dass „Nintendo hauptsächlich in C# entwickelt“. Wahrscheinlicher ist: **C# wird dort genutzt, wo Tools, Editor-Erweiterungen oder bestimmte Gameplay-/Engine-Kontexte davon profitieren.** Das ist eine belastbare Einordnung, aber als Schlussfolgerung formuliert. ([careers.nintendo.com](https://careers.nintendo.com/jobs/4094467009/)) Skriptsysteme sind öffentlich kaum dokumentiert. Bei Nintendo ist deshalb Vorsicht wichtig: **Aus einzelnen Credits oder Leaks sollte man keine konzernweite Regel ableiten.** ## Git, Perforce, SVN **Öffentlich bekannt ist nicht, dass Nintendo konzernweit Git nutzt.** Dafür gibt es in den hier belastbaren Primärquellen keinen Nachweis. ([developer.nintendo.com](https://developer.nintendo.com/)) Das heißt nicht, dass Git ausgeschlossen ist. Es heißt nur: **Wer behauptet, Nintendo arbeite sicher mit Git oder Perforce, spekuliert meist.** Große Spielefirmen nutzen oft Perforce, manche Teams Git, manche Mischformen – aber für Nintendo selbst ist das öffentlich nicht sauber belegt. Der wichtige Punkt ist also: **Bei Versionsverwaltung endet das gesicherte Wissen schnell.** Genau dort werden viele Online-Antworten unnötig selbstsicher. ## Wie sich das über die Zeit verändert hat ## Früher: stärker hardware- und teamzentriert Historisch war Nintendo noch stärker von **studiospezifischen Engines, proprietären Libraries und hardwarebezogenen Workflows** geprägt. Das war auf älteren Plattformen normal: kleine, stark spezialisierte Teams, viel maßgeschneiderte Technik, wenig Standardisierung über alle Projekte hinweg. ## Switch-Ära: mehr Middleware, mehr Standardisierung Mit der Switch wurde die Entwicklungsumgebung klar **zugänglicher für externe Studios und Indies**. Das sieht man am Nintendo Developer Portal und an der offiziellen Unity-Unterstützung. Gleichzeitig blieb Nintendo bei internen Produktionen offenbar stark proprietär. ([developer.nintendo.com](https://developer.nintendo.com/tools)) Der eigentliche Wandel ist also nicht „Nintendo nutzt jetzt plötzlich Standardsoftware“, sondern: **Nintendo hat seine Plattform-Entwicklung professionalisiert und modularisiert, ohne den Inhouse-Charakter aufzugeben.** ## Switch 2: Ausbau der Toolchain statt kompletter Bruch Für **Nintendo Switch 2** ist der Trend noch klarer: Silicon Studio nennt ausdrücklich neue oder weiterentwickelte **SDKs**, **Shader-Tools**, **Layout-Utilities**, **Material-/Model-Editoren** und die Weiterentwicklung der **NintendoWare Bezel Engine** für neue Hardware-Features. ([siliconstudio.co.jp](https://www.siliconstudio.co.jp/en/news/pressreleases/2025/250701switch2/pdf/NewsRelease_switch2_20250701_en.pdf)) Das spricht eher für **Evolution statt Revolution**: keine komplette Abkehr von Nintendos eigener Technik, sondern eine modernisierte, breitere Produktionspipeline. ## Was viele Suchergebnisse meist zu ungenau sagen Typische Web-Antworten bleiben oft bei „Nintendo nutzt eigene Engines“ stehen. Das ist zu grob. Die nützlichere Einordnung lautet: - **Nintendo nutzt nicht die eine Nintendo-Engine für alles.** - **C/C++ ist der technische Kern.** - **Unity ist auf Nintendo-Plattformen offiziell unterstützt, aber nicht der Standardbeweis für First-Party-Entwicklung.** - **Switch 2 bringt vor allem modernere SDK- und Asset-Tooling-Schichten.** - **Git/Perforce sind öffentlich nicht verlässlich bestätigt.** ([developer.nintendo.com](https://developer.nintendo.com/tools)) Der überraschend wichtige Punkt dabei: **Die eigentliche Stärke von Nintendo liegt offenbar weniger in einer berühmten Universal-Engine als in der Verzahnung aus Plattform-SDK, interner Middleware und spezialisierten Content-Tools.** Genau das erklärt auch, warum Nintendo-Spiele technisch oft sehr eigen wirken, obwohl die Hardware vergleichsweise konservativ ist. ([nerd.nintendo.com](https://www.nerd.nintendo.com/files/Job%20Offer%20SYS2025%20EN.pdf))