Wie du eine Steam-Next-Fest-Demo baust, ohne dein eigentliches Spiel aus der Spur zu bringen

Eine Steam-Next-Fest-Demo ist kein zweites Spiel. Sie ist ein öffentlicher Test der ersten 15 bis 30 Minuten Vertrauen: Startet das Spiel, versteht die Spieler:in den Loop, passt das Versprechen auf der Steam-Seite zu dem, was spielbar ist, und endet die Demo, bevor sie sechs Monate aus der echten Roadmap herausleiht?

Dieser Guide gibt dir einen produktionssicheren Workback-Plan für eine Steam-Next-Fest-Demo. Am Ende hast du eine Methode, um das richtige Fest zu wählen, den Demo-Scope einzufrieren, Demo-Hacks aus dem Hauptspiel herauszuhalten, Steam Review mit genug Puffer zu überstehen und Festival-Traffic in brauchbares Feedback zu verwandeln statt in einen neuen Stapel halbfertiger Systeme.

Was du brauchst, bevor du startest:

• Eine Steam-Coming-Soon-Seite oder einen datierten Plan, eine einzureichen.
• Einen spielbaren Core Loop, auch wenn die Art drumherum noch rau ist.
• Ein Taskboard mit einer harten "nicht für die Demo"-Spalte.
• Mindestens eine externe Spieler:in oder mitwirkende Person, die die Demo testet, bevor Steam es tut.

1. Wähle das richtige Next Fest, bevor du etwas baust

Steam Next Fest ist für unveröffentlichte Spiele mit spielbaren Demos. Valve führt es derzeit dreimal pro Jahr durch, im Februar, Juni und Oktober. Jedes berechtigte Spiel darf nur an einem Next Fest teilnehmen, also ist die erste Entscheidung nicht "wie schnell kann ich eine Demo bauen?" Sie ist "welches Fest gibt diesem Spiel die beste Chance?"

Prüfe die aktuelle Steamworks-Next-Fest-Dokumentation, bevor du den Plan festziehst. Am 21. Mai 2026 listete Valve das Juni-2026-Fest für den 15. bis 22. Juni, mit bereits geschlossener Registrierung am 27. April und erforderlichen Einreichungen bis 3. Juni. Das Oktober-2026-Fest ist für den 19. bis 26. Oktober gelistet, mit Registrierung bis 31. August und erforderlichen Einreichungen bis 5. Oktober. Diese Daten ändern sich für künftige Events.

Berechtigung ist das erste Gate. Valve verlangt einen Steamworks-Account in gutem Zustand, eine öffentliche Store-Seite für das Basisspiel, eine öffentlich spielbare Demo vor Beginn des Fests und ein Spiel, das bis nach dem Fest unveröffentlicht bleibt. Dein Spiel darf außerdem nicht schon an Next Fest teilgenommen haben und darf kein Prolog, Kapitel, Preview oder Kurzformat einer bereits veröffentlichten Sache sein.

Es gibt keine Exklusivitätsanforderung, keine Neuheitsanforderung und keine vorgeschriebene Demo-Länge. Das gibt dir Raum, vernünftig zu bleiben. Wähle das Fest, das zu deinem Produktionskalender passt, nicht das Fest, das deinen Optimismus streichelt.

2. Schreibe das Demo-Versprechen in einem Satz

Bevor du einen Demo-Build machst, schreibe den Satz, den die Demo beweisen muss.

Nutze dieses Format:

In 20 Minuten soll die Spieler:in verstehen, dass dies ein [Genre] über [Kernhandlung] ist, [konkrete Fantasy] fühlen und wishlisten wollen, weil [konkretes offenes Versprechen].

Beispiele:

• In 20 Minuten soll die Spieler:in verstehen, dass dies ein taktisches Cooking-Roguelike über Rezeptketten unter Druck ist, sich clever im Chaos fühlen und wishlisten wollen, weil die Zutatenkombos später eindeutig seltsamer werden.
• In 15 Minuten soll die Spieler:in verstehen, dass dies ein Cozy-Exploration-Spiel über das Reparieren verlassener Maschinen ist, ruhig, aber neugierig werden und wishlisten wollen, weil die Insel größere Systeme andeutet.
• In 25 Minuten soll die Spieler:in verstehen, dass dies ein Precision-Platformer über das Wechseln von Gravitation ist, merken, wie die Mechanik klickt, und wishlisten wollen, weil der letzte Raum zeigt, wohin Mastery führen kann.

Das Demo-Versprechen ist eine Schnittlinie. Alles, was diesen Satz nicht stützt, ist nicht in der Demo. Nicht das Crafting-System, das du immer noch liebst. Nicht das zweite Biom. Nicht das lange Intro-Cinematic, das Lore erklärt, nach der noch niemand gefragt hat.

Konkurrenz-Guides sagen oft "scope deine Demo." Schon gut. So scopest du sie: ein Satz, ein Versprechen, eine Spielerfahrung.

3. Friere eine reine Demo-Scope-Liste ein

Öffne dein Taskboard und erstelle drei Spalten:

Spalte	Was dort landet	Regel
In der Demo	Arbeit, die nötig ist, um das Demo-Versprechen zu beweisen	Muss vor Code Freeze shippen
Aus dem Hauptspiel geliehen	Bestehende Systeme oder Inhalte, die unverändert wiederverwendet werden	Nicht nur für die Demo ausbauen
Nicht für die Demo	Alles Verlockende, aber Unnötige	Geschlossen, außer es fixt einen Blocker

Die dritte Spalte ist die, die dich rettet. Eine Steam-Next-Fest-Demo bringt das Hauptspiel aus der Spur, wenn jede nützliche Idee zu "klein genug, um sie noch reinzunehmen" wird. Ist sie nie. Ein neuer Gegner braucht Animation, Sound, Tuning, Tutorialisierung, QA, Screenshots, Lokalisierungsstrings und Save-State-Entscheidungen. Das ist keine kleine Ergänzung. Das ist ein Ast des Spiels, der sich als Task verkleidet.

Nutze die mikroskopische Regel aus Game-Jam-Denken: Wenn die Demo ohne etwas funktionieren kann, startet es außerhalb der Demo. Du darfst ein Item nur befördern, wenn es ein konkretes Scheitern im Demo-Versprechen fixt. "Die Demo fühlt sich dünn an" ist nicht konkret. "Vier von fünf Testern verstehen den Loop vor Raum drei nicht" ist konkret.

Hier verknüpfst du die Demo wieder mit dem Hauptspiel, statt sie die Roadmap kapern zu lassen. Die Demo darf leihen. Sie darf nicht zum Produktionsplan werden.

4. Baue den Demo-Branch, ohne das Hauptspiel zu vergiften

Erstelle einen Demo-Branch, ein Demo-Build-Target oder einen Demo-Content-Ordner. Die genaue Einrichtung hängt von Engine und Projektgröße ab, aber die Regel bleibt gleich: Demo-Arbeit muss nach dem Fest leicht zu erkennen sein.

Markiere alles, was nicht dauerhaft werden soll:

• DEMO_ONLY für Szenen, Maps oder Content-Packs, die nur für Next Fest gemacht sind.
• PLACEHOLDER für Art, UI, Audio und Text, die vor Release ersetzt werden müssen.
• FAKE_SYSTEM für hartcodierte Menüs, Progression-Gates, Inventory-Abkürzungen oder geskriptete Momente.
• DO_NOT_MERGE für Hacks, die nur existieren, um den Demo-Pfad stabil zu machen.

Das klingt pingelig, bis das Fest vorbei ist und du nicht mehr weißt, welche Abkürzungen harmlos waren. Ein Transcript-Kandidat hat das Risiko sauber benannt: Eine kleine Variable zu ändern kann alles aus dem Gleichgewicht bringen. Das gilt doppelt, wenn der Demo-Branch unter Deadline-Druck entsteht.

Entscheide die Merge-Back-Regel, bevor du startest:

• Bugs, die in geteilten Systemen gefixt wurden, dürfen zurückmergen.
• Neuer Content darf nur zurückmergen, wenn er im Full-Game-Plan existiert.
• Demo-only-Onboarding darf erst zurückmergen, nachdem du es gegen das volle Spiel getestet hast.
• Fake-Systeme mergen nie zurück ohne Ticket, das den Fake durch die echte Version ersetzt.

Wenn du mit anderen Mitwirkenden arbeitest, vergib Ownership hier. Eine Person besitzt den Demo-Branch. Eine Person besitzt den Hauptspiel-Branch. Wenn das für ein kleines Projekt zu formal klingt: gut. Kleine Projekte sind genau dort, wo versehentliche Branch-Vergiftung passiert.

5. Setze ein Code-Freeze-Datum vor dem Steam-Review-Termin

Valve sagt, Entwickler:innen sollten den Demo-Build mindestens zwei Wochen vor Start des Next Fests zur Review einreichen, sonst riskieren sie die Teilnahme. Build Review prüft grundlegende Funktion. Es ist nicht deine QA-Abteilung.

Arbeite vom Fest-Datum zurück:

Workback-Punkt	Mindest-Timing	Was wahr sein sollte
Fest startet	Tag 0	Demo ist vor Valves Event-Startzeit öffentlich
Steam-Review-Puffer	14+ Tage vorher	Demo-Build eingereicht und Store-Assets bereit
Interner Code Freeze	18-21 Tage vorher	Keine neuen Features, nur Blocker-Fixes
Externer Playtest	25-30 Tage vorher	Frische Spieler:innen testen den ganzen Demo-Pfad
Scope Freeze	6-8 Wochen vorher	Demo-Versprechen und Task-Spalten sind gesperrt

Der Code Freeze ist der Teil, den du mit dir selbst verhandeln wollen wirst. Tu es nicht. Ein Launch-Transcript hatte den richtigen Instinkt: "I'm just not touching it." Eine andere Zeile aus derselben Quelle nennt den Grund: Ab einem bestimmten Punkt gibt es nichts mehr, was du tun kannst, außer das Spiel kaputtzumachen.

Nutze nach dem Freeze Bug-Gefahrenstufen:

• D1: Crash, Save-Korruption, Launch-Fehler, harter Progressionsblocker. Fixen.
• D2: Spieler:innen-Verwirrung, die das Demo-Versprechen blockiert. Fixen, wenn begrenzt.
• D3: Visual Polish, Balance-Tweak, Nice-to-have-Feature, kleine Content-Lücke. Vor Review nicht anfassen.

Wenn der Fix riskiert, einen schlimmeren Bug zu erzeugen als den Bug selbst, wartet er. Eine leicht hässliche, aber stabile Demo schlägt einen hübscheren Build, der beim ersten Streamer crasht.

6. QAe den First-Session-Pfad, nicht das ganze Traumspiel

Deine Next-Fest-Demo braucht keine Full-Game-QA. Sie braucht First-Session-Vertrauen.

Führe den Test so aus, wie eine Spieler:in es tun wird:

1. Von einer sauberen Maschine installieren.
2. Aus Steam starten, nicht aus dem Editor.
3. Mit Standard-Einstellungen beginnen.
4. Ohne Dev-Kommentar spielen.
5. Beenden und neu starten.
6. Prüfen, ob Progress, Settings oder Save State so funktionieren, wie die Demo es verspricht.
7. Wishlist-, Feedback-, Discord-, Newsletter- oder Survey-Links anklicken.
8. Controller und Keyboard testen, wenn deine Store-Seite beides verspricht.

Dann beobachte eine frische Spieler:in bei derselben Sache. Nicht erklären. Aufschreiben, wo sie zögert.

Deine QA-Checkliste sollte abdecken:

• Installation und erster Launch.
• Hauptmenü und Settings.
• Erster Input-Prompt.
• Erster Tutorial-Beat.
• Erster Win- oder Failure-State.
• Jedes Save- und Load-Verhalten, das du zeigst.
• Audiolevel und Subtitle-Basics.
• Steam Overlay, Wishlist-CTA und Feedback-Link.
• Crash-Pfad, falls die Spieler:in mitten im Run beendet.
• Steam-Deck-Basics, falls du Support behauptest oder Deck-Traffic erwartest.

Valve empfiehlt, Feedback-Links in die Demo zu setzen, ein Demo-Feedback-Subforum einzurichten und Demo-Deaktivierungsnachrichten klar zu machen. Mach das, bevor der Build öffentlich wird. Feedback, das in fünf verstreuten Discord-DMs liegt, ist kein Feedback-System. Es ist Hausaufgabe, die du vermeiden wirst.

7. Richte die Steam-Demo wie ein echtes Store-Asset ein

Eine Steam-Demo hat ein eigenes App-Setup. In Steamworks sollte der Demo-App-Typ "Demo" sein, und die Demo sollte in den General Application Settings auf die App-ID des Basisspiels verweisen. Nach Release sagt Valve, dass du die Store-Seite des Basisspiels neu veröffentlichen musst, damit der Download-Demo-Button erscheint.

Behandle das als Produktionsarbeit, nicht als Admin.

Deine Steam-Setup-Checkliste:

• Demo-App erstellt und mit der App-ID des Basisspiels verknüpft.
• Demo-Build hochgeladen und aus Steam getestet.
• Basisspiel-Store-Seite nach Demo-Release neu veröffentlicht.
• Demo-Button auf der Basisspiel-Seite sichtbar.
• Demo-Capsule, Screenshots und Trailer aktualisiert, falls du eine separate Demo-Seite nutzt.
• "Wishlist the full game"-CTA im Spiel und auf der Store-Seite sichtbar.
• Feedback-Link aus dem Live-Build getestet.
• Deaktivierungsnachricht geschrieben, falls du die Demo später entfernen willst.
• Press-Preview-Readiness geprüft, falls du sie nutzt.

Verstecke die Demo nicht hinter cleverem Messaging. Spieler:innen sollten wissen, was sie herunterladen, was sie bekommen, wie lange es ungefähr dauert und wo sie wishlisten, wenn sie fertig sind.

8. Nutze Next Fest als Feedback-Capture, nicht als Wishlist-Wunder

Steam Next Fest kann viele Spieler:innen schicken. Es schuldet dir keine Conversion.

Ein lokales Transcript hatte die nützliche Warnung: Eine Demo bekam 80.000 Downloads, während Next Fest selbst für Wishlists nicht so viel Wirkung hatte. How To Market A Games 2026 Survey fand in der Stichprobe, dass Demos, die deutlich vor Next Fest gestartet wurden, besser abschnitten, mit ungefähr 2,5x mehr Wishlists für frühere Demos. Der praktische Schluss ist nicht "Next Fest ist schlecht" oder "früh starten und entspannen." Er ist: Das Fest belohnt Demos, die schon Kontakt mit Spieler:innen überstanden haben.

Tracke während des Fests fünf Dinge:

Signal	Warum es zählt
Launch-to-menu-Erfolg	Basales Vertrauen
Tutorial-Abschluss	Ob der First-Session-Pfad funktioniert
Erster Quit-Punkt	Wo Verwirrung oder Langeweile trifft
Wishlist-Klicks	Fit zwischen Store-Versprechen und Demo
Schriftliche Feedback-Themen	Was im Hauptspiel gefixt werden muss

Schreibe die Demo während des Fests nicht um, außer ein D1-Bug erscheint. Der bessere Move ist, sauberes Signal zu sammeln. Wenn die Hälfte der Spieler:innen an derselben Tür aufhört, sagt dir das etwas. Wenn du Tür, Tutorial und Enemy-Timing auf einmal patchst, hast du gerade das Experiment zerstört.

Die Demo ist Marketing, aber sie ist auch Recherche. Lass sie dich etwas lehren.

9. Räume Demo-Arbeit nach dem Fest auf, merge sie zurück oder kill sie

Die Woche nach Next Fest ist der Moment, in dem Demo-Schulden versuchen, zum Spiel zu werden.

Plane ein Post-Fest-Decision-Meeting, bevor das Fest startet. Wenn du solo bist, setz es trotzdem in den Kalender. Triff vier Entscheidungen:

1. Demo live lassen. Nutze das, wenn der Build stabil ist, Feedback brauchbar bleibt und die Demo noch zum aktuellen Spiel passt.
2. Demo einmal patchen. Nutze das, wenn ein kleiner Fix einen großen Blocker für künftige Spieler:innen entfernen würde.
3. Demo zurückziehen. Nutze das, wenn die Demo das Spiel nicht mehr repräsentiert oder Support verlangt, den du dir nicht leisten kannst.
4. Learning ins Hauptspiel mergen. Nutze das für Onboarding, Store-Copy, Level-Reihenfolge, Bugfixes und Spieler:innen-Sprache.

Patche die Demo nicht weiter, nur weil sie der einzige Teil des Spiels mit Publikum ist. Genau so wird ein Marketing-Asset zum neuen Projekt.

Der Merge-Back-Review sollte langweilig sein:

• Welche Shared-System-Fixes sind sicher zu mergen?
• Welche Demo-only-Dateien werden gelöscht oder archiviert?
• Welche Fake-Systeme brauchen Replacement-Tickets?
• Welche Spieler:innen-Beschwerden ändern die Full-Game-Roadmap?
• Welche Beschwerden sind demo-spezifisch und sollten die Produktion nicht steuern?

Wenn du diese Fragen nicht beantworten kannst, war die Demo in Schritt 4 nicht klar genug markiert. Fixe die Markierung jetzt, bevor die nächste Deadline das Chaos dauerhaft macht.

Häufige Fallen

Das nächste Fest wählen. Das nächste Fest fühlt sich motivierend an. Oft ist es einfach zu früh. Wähle das Fest, das dir Scope Freeze, Playtest, Code Freeze und Steam-Review-Puffer gibt.

Neue Systeme für die Demo bauen. Wenn das System nicht Teil des Full-Game-Plans ist, baue es nicht für ein Ein-Wochen-Event. Fake es, markiere es oder schneide es.

Onboarding zuerst kürzen. Neue Spieler:innen wissen nicht, was du weißt. Wenn die Demo eine Sache poliert braucht, dann sind es die ersten fünf Minuten.

Die Demo für immer patchen. Die Demo sollte entweder aus gutem Grund live bleiben, einen geplanten Patch bekommen oder zurückgezogen werden. Dauerhafte Demo-Wartung stiehlt vom eigentlichen Spiel.

Ohne Feedback-Capture launchen. Ein Feedback-Link, der nach dem Launch ergänzt wird, verpasst die Spieler:innen, die du am meisten gebraucht hättest. Baue den Capture-Weg, bevor du bei Steam einreichst.

Wishlists als einziges Ergebnis behandeln. Wishlists zählen, aber Quit-Punkte, Bug-Cluster, Streamer-Verwirrung und die genauen Wörter der Spieler:innen zählen auch, wenn das Versprechen klickt.

Was du als Nächstes tun solltest

Starte mit dem Demo-Versprechen. Wenn du es nicht in einem Satz schreiben kannst, geh zurück zu The Vertical Slice Protocol und entscheide, was dein spielbarer Chunk beweist. Wenn der Satz klar ist, aber die Scope-Liste weiter wächst, nutze Scope Creep Is Killing Your Game, um sie zurückzuschneiden. Wenn die Demo fast bereit ist, du aber weiter polierst statt einzufrieren, ist The Last-Mile Decision der nächste Read.

Deine Steam-Seite muss ihren Teil des Versprechens ebenfalls tragen. Dafür nutze How to Write a Steam Page That Actually Sells Your Indie Game.

Das fehlende Stück für die meisten kleinen Teams ist nicht noch eine Checkliste. Es ist eine Person, die hilft, die Schnittlinie zu halten, wenn die Deadline schlechte Ideen vernünftig aussehen lässt. Melde dich bei Clowdr an, wenn du Mitwirkende willst, die die Demo pressure-testen, den QA-Pass übernehmen und das eigentliche Spiel in Bewegung halten, während Next Fest versucht, den Zeitplan zu fressen.