Entwicklungsaus im Early Access: Das kann nicht nur unbekannte Spiele-Start-ups treffen, wie der aktuelle Fall von „Hyper Light Breaker“ zeigt. Das Spiel des 2013 gegründeten und bis dato erfolgreichen Indie-Studios Heart Machine wird nicht zur ursprünglichen Vision fertig entwickelt, gestand das Studio dem Branchenmagazin Game Informer.

Stattdessen muss Heart Machine Angestellte entlassen und die Arbeit an „Hyper Light Breaker“ noch während der Early-Access-Phase einstellen. „Das war nicht der Weg, den wir uns gewünscht hätten, aber der einzige, der unter den gegebenen Umständen möglich war“, sagte Heart Machine gegenüber Game Informer.

Letztes Update im Januar

Im Januar soll zumindest noch ein Update erscheinen: „Wir planen, etwas Bedeutungsvolles zu liefern, so ausgefeilt und vollständig, wie es unter unseren aktuellen Umständen möglich ist.“ Ziel sei es, die Entwicklung von „Hyper Light Breaker“ zu einem „zufriedenstellenden Schlusspunkt“ zu bringen. Es ist gut möglich, dass „Hyper Light Breaker“ mit diesem Update dann offiziell aus dem Early Access gehievt wird – die Aussagen der Entwickler lassen aber wenig Zweifel daran, dass ursprünglich mehr geplant war.

Zumindest die Timeline passt: „Hyper Light Breaker“ war im Januar 2024 in den Early Access bei Steam gestartet und sollte etwa ein Jahr bis zum fertigen Release brauchen. Beim Early-Access-Konzept können Spieler einen Steam-Titel schon während der aktiven Entwicklung kaufen, um die Arbeit des Teams finanziell zu unterstützen und mit Feedback auf den Prozess Einfluss zu nehmen.

Doch das Konzept birgt stets das Risiko, dass ein Titel nie wirklich fertig wird und man sein Geld für eine Dauer-Beta ausgibt. In solchen Fällen gibt es das Geld nicht zurück. Im Großen und Ganzen ist das Early-Access-Konzept erfolgreich: Zu den bekanntesten Titeln, die per Early Access entwickelt wurden, gehören „Baldur’s Gate 3“, „Satisfactory“ und jüngst „Hades 2“.

Heart Machine macht weiter

Heart Machine galt bislang als weitgehend sichere Bank in der Indie-Szene. „Hyper Light Drifter“ gehört zu den besseren Indie-Spielen des vergangenen Jahrzehnts, auch „Solar Ash“ wurde gut aufgenommen und galt als Erfolg. Doch bei „Hyper Light Breaker“ wollte der Funke nicht so richtig überspringen – schon bevor das Entwicklungsaus angekündigt wurde, hatte das Spiel durchwachsene Nutzerbewertungen.

Die Entscheidung für den Entwicklungsstopp sei auf „Kräfte außerhalb unserer Kontrolle“ zurückzuführen, sagte Heart Machine dem Game Informer. Dazu gehörten Veränderungen bei der Finanzierung, Konsolidierung von Spielefirmen und die allgemein unsichere Marktsituation der Spielebranche.

Wie viele Angestellte entlassen werden, ist unklar. Mit einem kleineren Team will Heart Machine weiterhin Videospiele entwickeln – nach dem unrühmlichen Ende von „Hyper Light Breaker“ wird das Team aber mit Misstrauen aus der Gaming-Community rechnen müssen.

(dahe)

Die Rückkehr der pinken Lederjacke? Warner hat einen Nachfolger des im Frühjahr erschienenen „Minecraft“-Kinofilms angekündigt. Der Film soll am 23. Juli 2027 in die Kinos kommen, erklärt Warner – auf einem Teaserbild sind lediglich zwei Spitzhacken auf einer Werkbank zu sehen.

„Ein Minecraft Film“ kam im April 2025 in die Kinos. Nachdem der erste Trailer bei „Minecraft“-Fans eher auf Entgeisterung gestoßen war, entwickelte sich der fertige Film zum Hit: Am Box Office spülte er fast eine Milliarde US-Dollar in die Kassen. Ein Nachfolger war angesichts dessen alternativlos. Dass ein zweiter Teil kommen sollte, war in Hollywood daher erwartet worden, berichtet das Branchenmagazin Variety.

Allzu viele Veränderungen sind im Vergleich zum ersten Teil wohl nicht zu erwarten: Jares Hess kehrt als Regisseur zurück, Jason Momoa wird Producer – ob er auch wieder eine Schauspielrolle übernehmen wird, ist noch offen. Mit weiteren Informationen hält sich Warner Bros. aktuell noch bedeckt.

Auch zweiter „Mario“-Film in Arbeit

Videospielfans können sich neben dem zweiten Teil von „Ein Minecraft Film“ auch auf die Fortsetzung eines weiteren Gaming-Kassenschlagers freuen: Vor wenigen Wochen hat Nintendo angekündigt, dass auch der „Mario“-Film einen zweiten Teil bekommen soll. Der „The Super Mario Galaxy Movie“ soll im April 2026 in die Kinos kommen, teilte Nintendo mit. „The Super Mario Galaxy Movie“ folgt auf den „Super Mario Bros.“-Film, den Nintendo 2023 in die Kinos gebracht hat. Das Animationsstudio Illumination produziert erneut Teil 2. Auch die Schauspieler aus dem ersten Teil sollen zurückkommen – dazu gehören in der englischsprachigen Fassung Chris Pratt als Mario und Anya Taylor-Joy als Prinzessin Peach.

Der „Mario“-Film von Nintendo war sogar noch etwas erfolgreicher als der „Minecraft“-Streifen: Er hat über eine Milliarde US-Dollar in die Kassen gespült.

(dahe)

In der modernen Softwareentwicklung ist Nebenläufigkeit allgegenwärtig. Selbst kleine Anwendungen laufen oft auf Systemen mit mehreren Kernen, interagieren mit Datenbanken, warten auf Netzwerkantworten oder teilen sich Ressourcen wie Dateien und Speicherbereiche. In verteilten Systemen und Embedded-Software kommt noch hinzu, dass verschiedene Prozesse aufeinander reagieren müssen, oft unter Echtzeitbedingungen. Die Praxis zeigt: Sobald mehrere Dinge gleichzeitig passieren können, entstehen neue Fehlerklassen, die sich in seriellen Programmen nie gezeigt hätten.

Muster 3: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren

Ein berühmtes Beispiel ist der Mars Pathfinder, eine NASA-Mission aus dem Jahr 1997. Die Landung selbst war ein spektakulärer Erfolg – die Sonde setzte sanft auf dem Mars auf und begann, Daten zu senden. Doch kurz darauf kam es zu sporadischen Systemabstürzen und automatischen Resets, die das Team am Boden in Alarmbereitschaft versetzten.

Die Ursache war eine Priority Inversion, ein klassisches Concurrency-Problem. In einem Echtzeitbetriebssystem gibt es Aufgaben mit unterschiedlicher Priorität. Hohe Priorität bedeutet: Diese Aufgabe soll möglichst sofort laufen, sobald sie bereit ist. Niedrige Priorität darf sie nicht blockieren.

Auf dem Pathfinder lief eine solche hochpriorisierte Aufgabe, die Daten vom Wettersensor verarbeitete. Sie benötigte jedoch Zugriff auf eine gemeinsame Ressource – in diesem Fall einen Mutex, der von einer niedrig priorisierten Aufgabe gehalten wurde. Diese niedrig priorisierte Aufgabe wurde wiederum von einer mittel priorisierten Aufgabe ständig verdrängt. Das Ergebnis: Die hochpriorisierte Aufgabe wartete indirekt auf eine niedrige, die nie zum Zuge kam.

Dieses Phänomen der „Umkehrung der Prioritäten“ führte dazu, dass das System in bestimmten Lastsituationen hängen blieb und schließlich neu startete. Die Lösung war im Prinzip einfach: Die Entwicklerinnen und Entwickler aktivierten Priority-Inheritance im Echtzeitbetriebssystem VxWorks. Dadurch erbte die blockierende, niedrig priorisierte Aufgabe vorübergehend die hohe Priorität, sobald eine höherwertige Aufgabe auf sie wartete. Der Knoten löste sich, und die Abstürze verschwanden.

Dieses Beispiel ist lehrreich, weil es gleich mehrere typische Muster verdeutlicht:

• Nebenläufigkeitsfehler sind schwer zu reproduzieren: Sie treten oft nur unter bestimmten Lastprofilen auf.
• Redundanz oder Wiederholungen helfen nicht automatisch: Wenn der Fehler im Design liegt, trifft er alle Instanzen gleichermaßen.
• Kleinste Details im Scheduling können den Unterschied machen: Die Software kann tausendmal korrekt laufen und beim tausend-und-ersten Mal ausfallen.

In modernen Anwendungen können ähnliche Probleme in Form von Deadlocks, Race Conditions oder Livelocks auftreten. Diese zeigen sich meist nicht im lokalen Testlauf, sondern erst in der Produktion, wenn reale Last und reale Parallelität wirken. Doch wie lassen sich solche Fehler vermeiden?

1. Klare Lock-Hierarchien: Wenn mehrere Ressourcen gesperrt werden, sollte immer in derselben Reihenfolge gelockt werden.
2. Prioritätsprotokolle nutzen: Mechanismen wie Priority Inheritance oder Priority Ceiling sind in vielen Echtzeitbetriebssystemen und sogar in modernen Frameworks verfügbar.
3. Nebenläufigkeit entkoppeln: Statt gemeinsame Zustände direkt zu sperren, können Architekturen mit Message Passing oder Actor-Modellen Race Conditions vermeiden.
4. Deterministische Tests und Simulationen: Spezielle Testframeworks können Prozesse gezielt verzögern oder Scheduler manipulieren, um seltene Konflikte reproduzierbar zu machen.
5. Telemetrie und Monitoring: Auch im Betrieb sollte sichtbar sein, wenn Locks ungewöhnlich lange gehalten werden.

Für Teams, die Web-Backends oder Cloud-Services entwickeln, zeigt sich übrigens dieselbe Gefahr, nur in geringfügig anderer Form: Datenbanktransaktionen, verteilte Caches oder konkurrierende API-Requests können ähnliche Effekte haben. Ein langsamer Hintergrundprozess blockiert einen Lock, während eine Flut von parallelen Requests diesen Zustand eskalieren lässt.

Die Lehre aus dem Pathfinder-Vorfall ist daher zeitlos: Nebenläufigkeit ist kein kostenloser Performance-Booster, sondern ein komplexes System, das Entwicklerinnen und Entwickler explizit entwerfen und überwachen müssen. Wer Concurrency als Randthema behandelt, wird früher oder später auf schwer reproduzierbare und potenziell katastrophale Fehler stoßen.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Zeit, Kalender und Geografie: Wenn die Uhr nicht das misst, was man denkt.

(who)