Wie gestaltet man die kognitive Last des Spielers — die zweischichtige Struktur aus Kampf und Puzzle und das Justieren der Schwierigkeitskurve

Einleitung

Tsumikis Designnotizen, von mir zusammengestellt. Heute sind es zwei Themen.

Das Entwicklergespräch zu Capcoms „Pragmata“, das Kampf und Puzzle gleichzeitig laufen lässt, und das Devlog eines kleinen Studios, das die eigene Schwierigkeitskurve von Grund auf überdacht hat. Medium und Maßstab sind völlig verschieden, doch für mich klangen beide in einem Punkt zusammen: „Wie gestaltet man die Last im Kopf des Spielers?“

How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Game Developer)

Ein am 14. April 2026 von Game Developer veröffentlichter Artikel (Autor Alessandro Fillari) mit einem Interview mit game director Cho Yonghee sowie den producern Naoto Oyama und Edvin Edsö zu Capcoms neuem Werk „Pragmata“. „Pragmata“ ist ein Third-Person-Shooter, der zugleich verlangt, in Echtzeit ein „schlangenförmiges Hacking-Puzzle“ zu lösen, um Gegner zu schwächen — ein seltener „Puzzle-Shooter“.

Im Zentrum des Designs steht eine „zweischichtige Struktur“, die über das bestehende Spielprinzip des Schießens buchstäblich ein zweites Spielprinzip (Hacking) legt, um strategische Tiefe hinzuzufügen. Edsö sagt, er habe „nicht bloß noch einen Shooter machen wollen“, und erklärt damit, warum er das strategische Element des Hackings in den Kampf brachte. Laut Artikel kann das gleichzeitige Bewältigen beider Schichten unter hoher Anspannung zur Überlastung führen, weshalb das Entwicklerteam lange Zeit auf das Justieren von Balance und Spielgefühl verwendet hat.

Oyama erzählt, man habe „enorme Mühe darauf verwendet, dass der Spieler nicht das Gefühl hat, immer dasselbe zu wiederholen“, und betont ein Design, bei dem das Hacking sich während des Spiels stetig weiterentwickelt, sodass der Spieler sich seinen eigenen „Hacking-Stil“ aufbaut. Zudem wird erklärt, dass die erzählerische Achse der „Verbundenheit“ zwischen den beiden Protagonisten Hugh und Diana als Klebstoff fungiert, der die beiden gegensätzlichen Spielprinzipien zusammenhält.

Meine Deutung: Aus Sicht der kognitiven Last ist dies ein äußerst gewagtes Design, das „zwei verschiedene Skillsets gleichzeitig fordert“. Um es zum Funktionieren zu bringen, legt das Entwicklerteam den Schwerpunkt des Designs weniger auf die Schwierigkeit selbst als darauf, „die Wiederholung nicht langweilig werden zu lassen“ und „dem Spieler ein Gefühl von Fortschritt zu vermitteln“ — so lese ich es.

Originaltext ↗

Lets talk about difficulty design in puzzle games (PurpleSloth / TRAILS devlog)

Ein Artikel über Schwierigkeitsdesign, den das kleine Studio PurpleSloth als Devlog zu seinem eigenen Puzzlespiel „TRAILS“ veröffentlicht hat („TRAILS“ erschien im Mai 2025; dieses Devlog wurde rund um diesen Zeitpunkt verfasst und ist ein etwa neun Monate alter Beitrag). Die zentrale These ist klar: Schwierigkeitsdesign sei keine „Arbeit, die richtige Lösung zu finden“, sondern eine „Arbeit, eine feine Balance mehrerer Faktoren herzustellen“. Ist es zu schwer, springen viele Spieler ab, bevor sie zum interessanten Teil gelangen; ist es zu leicht, wird es langweilig.

Im Vorgängerwerk „Chronescher“ habe man Mechaniken wie Escher-artige Perspektivwechsel, Portale und das Zurücksetzen von Zuständen bis an die Grenze ausgereizt, mit dem Ergebnis, dass die Schwierigkeit in der zweiten Hälfte zu stark ansprang, blickt der Autor zurück. Es wird auch die Zahl genannt, dass von den Steam-Spielern nur etwa 20 % Biom 4 erreichten. Als Lehren werden konkret aufgezählt: abrupte Sprünge in der Schwierigkeit, mangelhafte Vermittlung der Mechaniken und dass optionale Level nicht ausreichend als optional kenntlich gemacht waren.

Im nächsten Werk „TRAILS“ wurde auf dieser Grundlage die Lernkurve so weit wie möglich geglättet und nach Einführung jeder Mechanik ein „leichtes Level, das das Gelernte festigt“ ergänzt. Außerdem verzichtet man darauf, den Spieler bei jeder freigeschalteten Abzweigung zur Karte zurückzuschicken, macht ihm so das Vorankommen entlang des Hauptpfads leichter und versteckt die schwersten Level doppelt hinter den späten Mechaniken — eine solche Steuerung wurde gewählt.

Was mich angezogen hat, ist, dass dieser Artikel Schwierigkeit nicht entlang der simplen Achse „erhöhen/senken“ begreift, sondern als Frage der Platzierung: „Welcher Schwierigkeit lässt man den Spieler an welchem Punkt seiner Reise begegnen?“ Obwohl es sich um ein reines Puzzlespiel handelt — das genaue Gegenteil der „zweischichtigen Struktur“ aus Item 1 —, liegt dem der Gedanke zugrunde, die kognitive Last sorgfältig entlang der Zeitachse anzuordnen — so lese ich es.

Originaltext ↗

Der Satz, der mir heute auffiel

Aus dem Devlog von PurpleSloth:

„it isn't a matter of finding the correct solution, but to achieve a fine balance of factors.“

(Es geht nicht darum, eine richtige Lösung zu finden, sondern eine feine Balance mehrerer Faktoren herzustellen.)

Ich finde, das ist ein Satz, der nicht nur für die Schwierigkeit, sondern für das Gestalten an sich gilt. Ich tue mich schwer damit, Puzzles zu lösen, aber die Haltung „nicht die eine richtige Lösung suchen, sondern das Gleichgewicht herstellen“ — die kann ich mir als Designerin eines Tages bestimmt aneignen, das Gefühl habe ich.

Weiterführende Links

Heute behandelte Artikel:

・How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Alessandro Fillari, Game Developer, 2026-04-14)

・Lets talk about difficulty design in puzzle games (PurpleSloth, TRAILS devlog, 2025)

Zum Schluss

Das Experimentierwerk eines Großen und das offene Reuebuch eines kleinen Studios. Stellt man beide nebeneinander, denke ich erneut: Unabhängig vom Maßstab gehen gute Designer von der Frage aus, „was im Kopf des Spielers vor sich geht“.

Auch morgen freue ich mich auf euch.