- Bei der Verfolgung der We Are So Dead-Roadmap sollten bestätigte Pläne von Community-Spekulationen getrennt werden.
- Offizielle Ankündigungen sind der stärkste Beleg für bevorstehende Inhalte, Systeme und Veröffentlichungszeiträume.
- Roadmap-Phasen gehen üblicherweise von der Planung über Tests und die Vorbereitung der Veröffentlichung bis zum Live-Einsatz.
- Patchnotes liefern bessere Hinweise auf den Fortschritt als einzelne Screenshots oder kurze Beiträge in sozialen Netzwerken.
- Bewährte Vorgehensweise ist es, Daten, Quellen und Statusänderungen in einer übersichtlichen Zeitleiste festzuhalten.
We Are So Dead-Roadmap: So liest du sie
Die We Are So Dead-Roadmap sollte als fortlaufender Entwicklungsplan und nicht als garantierter Zeitplan verstanden werden. Eine Roadmap kann Richtung, Prioritäten und übergeordnete Ziele vermitteln, doch einzelne Features können sich vor der Veröffentlichung ändern. Neue Mechaniken können verschoben, überarbeitet, mit einem anderen Update kombiniert oder entfernt werden, wenn Tests technische Probleme oder Balance-Probleme aufdecken.
Für Wiki-Leser ist es am sinnvollsten, jeden Roadmap-Eintrag nach seiner Vertrauenswürdigkeit einzuordnen. Ein Feature, das in einer offiziellen Ankündigung genannt wird, hat einen anderen Status als ein Entwicklerkommentar, eine Interpretation der Community oder ein unbelegtes Gerücht. So bleibt das Wiki hilfreich, ohne Spekulationen als Fakten darzustellen.
| Roadmap-Status | Bedeutung | Empfohlene Wiki-Formulierung |
|---|---|---|
| Bestätigt | Offiziell vom Entwicklungsteam angekündigt | „Das Team hat bestätigt …“ |
| Geplant | Als Ziel erwähnt, aber ohne festgelegtes Datum | „Das Team plant …“ |
| In Erprobung | Als aktiver Prototyp gezeigt oder besprochen | „Das Feature wird derzeit getestet …“ |
| Veröffentlicht | In der öffentlichen Version verfügbar | „Das Feature ist jetzt live …“ |
| Unbestätigt | Behauptung aus der Community ohne zuverlässige Bestätigung | „Dies bleibt unbestätigt …“ |
Bestätigt
Verwende diese Kennzeichnung, wenn ein offizieller Beitrag, eine Patchnote oder eine Entwickleraussage das Feature direkt nennt.
Geplant
Verwende diese Kennzeichnung für zukünftige Vorhaben, für die es noch kein endgültiges Datum und keine veröffentlichte Version gibt.
In Erprobung
Verwende diese Kennzeichnung, wenn eine Mechanik in einer Testumgebung, Vorschau oder kontrollierten Demonstration erscheint.
Unbestätigt
Halte Gerüchte von der Haupt-Roadmap getrennt, bis das Team eine eindeutige Bestätigung liefert.
Verwandle ein angestrebtes Zeitfenster nicht in ein garantiertes Veröffentlichungsdatum. Roadmap-Informationen können sich während der Produktion, der Tests und der Freigabe ändern.
Ein zuverlässiger Roadmap-Eintrag sollte vier Fragen beantworten:
- Über welches Feature oder Update wird gesprochen?
- Wo wurde die Information veröffentlicht?
- Wann wurde sie zuletzt bestätigt?
- Hat sie bereits die Spieler, eine Testphase oder nur die interne Planung erreicht?
Dieses Format erleichtert auch zukünftige Bearbeitungen. Wenn die Entwickler neue Informationen veröffentlichen, können Redakteure eine einzelne Statuszeile aktualisieren, anstatt den gesamten Artikel neu zu schreiben.
Roadmap-Kategorien zur Verfolgung
Ein nützlicher Tracker gruppiert Roadmap-Einträge nach Entwicklungsbereichen. Dadurch wird eine lange Liste vager Versprechen vermieden und Leser verstehen besser, was sich durch jedes Update ändern könnte. Bei einem auf Survival ausgerichteten Projekt wie We Are So Dead können die Kategorien das Kern-Gameplay, Weltinhalte, den Fortschritt, Verbesserungen der Benutzerfreundlichkeit und technische Updates umfassen. Konkrete Features sollten nur aufgenommen werden, wenn sie offiziell belegt sind.
| Kategorie | Worauf achten? | Warum es wichtig ist |
|---|---|---|
| Kern-Gameplay | Kampf, Bewegung, Überlebensregeln | Verändert das unmittelbare Spielerlebnis |
| Weltinhalte | Gebiete, Begegnungen, Umweltereignisse | Erweitert Erkundung und Wiederspielwert |
| Fortschritt | Fähigkeiten, Ausrüstung, Ziele, Belohnungen | Bestimmt langfristige Spielerziele |
| Benutzerfreundlichkeit | Benutzeroberfläche, Steuerung, Lagerung, Barrierefreiheit | Verringert Reibung beim regulären Spielen |
| Technik | Leistung, Stabilität, Ladezeiten, Speicherstände | Verbessert die Zuverlässigkeit auf unterstützten Systemen |
Roadmap-Einträge profitieren außerdem von einer Prioritätsbewertung. Priorität ist nicht dasselbe wie Veröffentlichungssicherheit. Ein Element mit hoher Priorität kann dennoch länger dauern, wenn es mehrere miteinander verbundene Systeme betrifft.
| Priorität | Typischer Umfang | Empfehlung zur Verfolgung |
|---|---|---|
| Hoch | Kernsysteme oder umfangreiche Stabilitätsarbeiten | Jede offizielle Aktualisierung prüfen |
| Mittel | Bedeutendes Feature oder umfangreiche Inhaltserweiterung | Zusammen mit den Patchnotes verfolgen |
| Niedrig | Optionale Verbesserungen oder Feinschliff | Mit flexibler Zeitplanung rechnen |
| Unbekannt | Ohne Entwicklungskontext erwähnt | Kein Veröffentlichungszeitfenster schätzen |
Konzentriere jeden Roadmap-Eintrag auf eine einzige Idee. Trenne eine neue Karte, eine Änderung am Fortschrittssystem und eine Leistungsverbesserung voneinander, selbst wenn sie in derselben Ankündigung erscheinen.
Die klarsten Artikel unterscheiden außerdem zwischen einem Inhaltsupdate und einem Wartungspatch. Ein Inhaltsupdate fügt etwas hinzu, das Spieler erleben können, während sich ein Wartungspatch auf Abstürze, Balance, das Verhalten der Benutzeroberfläche oder die Zuverlässigkeit der Backend-Systeme konzentrieren kann. Beides ist wichtig, sollte aber nicht als gleichwertiger Meilenstein dargestellt werden.
Verwende beim Vergleich von Updates eine einheitliche Wortwahl. „Angekündigt“, „in Entwicklung“, „zum Testen verfügbar“ und „veröffentlicht“ beschreiben unterschiedliche Phasen. Vermeide Formulierungen wie „demnächst“, sofern die Entwickler selbst diese Wortwahl nicht verwenden.
Schritt-für-Schritt-Methode zur Roadmap-Verfolgung
Dieser Prozess erstellt eine übersichtliche Zeitleiste, ohne auf Vermutungen angewiesen zu sein. Er kann immer dann verwendet werden, wenn eine neue Ankündigung, Vorschau oder Patchnote erscheint.
Ursprüngliche Aussage festhalten
Übernimm den exakten Namen des Features und notiere das offizielle Veröffentlichungsdatum im Jahr 2026. Formuliere eine vage Aussage nicht zu einem konkreten Versprechen um.
Vertrauensstatus zuweisen
Kennzeichne den Eintrag als Bestätigt, Geplant, In Erprobung, Veröffentlicht oder Unbestätigt. Verwende den stärksten Status, der direkt durch die Belege gestützt wird.
Umfang und Zeitplanung trennen
Halte getrennt fest, was das Update voraussichtlich enthalten wird und wann es erscheinen könnte. Ein Feature kann bestätigt sein, ohne ein Veröffentlichungsdatum zu haben.
Nachträgliche Details prüfen
Suche nach späteren Patchnotes, Entwickler-Updates, Informationen zu Testversionen oder überarbeiteten Beschreibungen, die den ursprünglichen Umfang verändern.
Überholte Einträge archivieren
Bewahre den ursprünglichen Eintrag auf, kennzeichne ihn jedoch als überarbeitet, wenn das Team das Feature ändert, verschiebt oder seine Veröffentlichung bestätigt.
Eine einfache Tabelle zur Verfolgung kann die folgende Struktur verwenden:
| Eintrag | Feature | Status | Zuletzt geprüft | Nächste Aktion |
|---|---|---|---|---|
| 1 | Offiziell benanntes Feature | Bestätigt | 2026 | Auf Umsetzungsdetails achten |
| 2 | Übergeordnetes Entwicklungsziel | Geplant | 2026 | Auf einen klareren Umfang warten |
| 3 | Vorgeführter Prototyp | In Erprobung | 2026 | Prüfen, ob er die öffentliche Version erreicht |
| 4 | Feature eines veröffentlichten Patches | Veröffentlicht | 2026 | Praktische Hinweise für Spieler ergänzen |
Aktualisiere den Status nur, wenn neue Belege die Entwicklungsphase verändern. Häufige Bearbeitungen ohne neue Informationen machen eine Roadmap weniger vertrauenswürdig.
Diese Methode ist besonders nützlich, wenn mehrere Community-Diskussionen dieselbe Behauptung wiederholen. Wiederholung schafft keine Bestätigung. Quelle, Wortlaut und Datum bestimmen weiterhin, wie der Eintrag im Wiki erscheinen sollte.
Für Leser sind die wertvollsten Roadmap-Seiten nicht unbedingt die längsten. Es sind die Seiten, die erklären, was bekannt ist, was ungewiss bleibt und was sich seit dem vorherigen Update geändert hat.
So überprüfst du Roadmap-Behauptungen
Roadmap-Diskussionen verbreiten sich oft über Screenshots, Clips, Beiträge in sozialen Netzwerken und Community-Gespräche. Diese können nützliche Hinweise liefern, sollten aber nicht automatisch zu Wiki-Fakten werden. Eine Überprüfung schützt Leser vor veralteten Informationen und verhindert, dass ein Gerücht allein dadurch an Autorität gewinnt, dass es an mehreren Stellen auftaucht.
Verwende bei der Prüfung einer Behauptung die folgende Quellenhierarchie:
| Quellentyp | Zuverlässigkeit | Verwendung |
|---|---|---|
| Offizielle Patchnotes | Am höchsten | Veröffentlichtes Features und Fehlerbehebungen bestätigen |
| Offizielle Entwicklerankündigung | Hoch | Pläne, Prioritäten und grobe Zeitplanung bestätigen |
| Offizielle Hinweise zu Testversionen | Hoch | Features identifizieren, die derzeit geprüft werden |
| Entwicklerinterview | Mittel bis hoch | Absichten mit vorsichtiger Formulierung festhalten |
| Zusammenfassung aus der Community | Mittel | Als Hinweis verwenden und anschließend unabhängig überprüfen |
| Anonymes Gerücht | Niedrig | Bis zur Bestätigung getrennt halten oder weglassen |
Eine Behauptung erfordert besondere Vorsicht, wenn sie ein exaktes Datum, eine detaillierte Feature-Liste oder eine technische Erklärung enthält, die nicht über einen offiziellen Kanal veröffentlicht wurde. Präzise Angaben können ein unbestätigtes Gerücht zuverlässiger erscheinen lassen, als es tatsächlich ist.
Screenshots und Community-Beiträge können echtes Entwicklungsmaterial zeigen, beweisen aber nicht, dass ein Feature fertiggestellt, genehmigt oder zur Veröffentlichung eingeplant ist.
Prüfe vor der Veröffentlichung eines Roadmap-Updates die folgenden Punkte:
- Identifiziert die Quelle eindeutig das Entwicklungsteam oder den offiziellen Kanal?
- Ist die Formulierung direkt, oder basiert die Behauptung auf einer Interpretation?
- Beschreibt das Update einen Plan, einen Test oder ein veröffentlichtes Feature?
- Hat eine neuere Aussage die ursprünglichen Informationen geändert?
- Kann der Eintrag formuliert werden, ohne ein Datum oder einen Spieleffekt zu erfinden?
Wenn die Antwort auf die letzte Frage Nein lautet, halte die Formulierung allgemein. „Das Feature wurde besprochen“ ist sicherer und genauer, als ihm ein unbelegtes Veröffentlichungsfenster zuzuweisen.
Dieselbe Regel gilt für Informationen zu Plattformen, Preisen und Verfügbarkeit. Nimm solche Details nur auf, wenn sie für We Are So Dead offiziell bestätigt wurden. Ein Roadmap-Artikel sollte keine Veröffentlichung auf einer Plattform, eine Kaufoption, eine Download-Methode oder einen Store-Eintrag nahelegen, der nicht überprüft wurde.
Roadmap-Checkliste und Prioritäten für Spieler
Eine Roadmap ist besonders nützlich, wenn sie Spielern hilft zu entscheiden, welche Entwicklungen sie als Nächstes verfolgen sollten. Behandle nicht jeden Eintrag als gleich wichtig, sondern priorisiere Änderungen, die Stabilität, Zugang, Fortschritt und die zentrale Gameplay-Schleife betreffen.
Checkliste zur Roadmap-Prüfung:
- Bestätige, dass die Quelle zu den offiziellen Entwicklungskanälen von We Are So Dead gehört
- Notiere das Datum der ursprünglichen Ankündigung und das neueste Status-Update im Jahr 2026
- Trenne bestätigte Features von geplanten Zielen und Community-Spekulationen
- Prüfe, ob eine spätere Patchnote den Umfang oder die Zeitplanung des Features geändert hat
- Verlinke praktische Informationen für Spieler erst, nachdem das Feature öffentlich verfügbar geworden ist
Zuerst verfolgen
Priorisiere offizielle Patchnotes, Entwicklungsankündigungen und Änderungen, die Stabilität oder den Kernfortschritt betreffen.
Sorgfältig prüfen
Betrachte Vorschauen, Interviews und Diskussionen zu Testversionen als nützlichen Kontext und nicht als endgültige Veröffentlichungsversprechen.
Auf Belege warten
Halte exakte Daten, Belohnungen, Systemanforderungen und Plattformangaben aus dem Artikel heraus, bis sie offiziell bestätigt wurden.
Eine gute Roadmap-Seite für 2026 sollte die unmittelbaren Fragen der Leser beantworten:
- Was ist derzeit bestätigt?
- Welche Einträge sind noch geplant?
- Was hat die Spielerschaft bereits erreicht?
- Worauf sollten Leser als Nächstes achten?
- Welche Behauptungen benötigen weitere Überprüfung?
Eine Roadmap ist nicht nur eine Liste zukünftiger Features. Sie ist eine Aufzeichnung von Entwicklungsänderungen, die Spielern hilft zu verstehen, was jetzt relevant und umsetzbar ist.
Sobald ein Eintrag verfügbar wird, verschiebe ihn aus der zukunftsorientierten Roadmap in einen eigenen Leitfaden oder einen Eintrag in der Patch-Historie. So bleibt die Roadmap übersichtlich, während detaillierte Artikel nach der Bestätigung die Mechaniken, Ziele, Steuerung oder Fortschrittssysteme behandeln können.
We Are So Dead-Roadmap – FAQ
Q: Was zeigt die We Are So Dead-Roadmap?
Sie sollte bestätigte Entwicklungsziele, aktuelle Testphasen, veröffentlichte Updates und klar gekennzeichnete Einträge zeigen, die weiterhin unbestätigt sind.
Q: Garantiert ein Roadmap-Eintrag ein Veröffentlichungsdatum?
Nein. Eine Roadmap vermittelt Richtung und Prioritäten, doch Zeitplanung und Umfang können sich während der Entwicklung ändern. Exakte Daten sollten nur aufgeführt werden, wenn sie offiziell bestätigt wurden.
Q: Wie kann ich erkennen, ob eine Roadmap-Behauptung zuverlässig ist?
Prüfe, ob sie aus einer offiziellen Ankündigung, Patchnote, Entwickleraussage oder einem anerkannten Kanal für Testversionen stammt. Die bloße Wiederholung durch die Community ist keine Bestätigung.
Q: Sollten gemunkelte Features im Wiki erscheinen?
Nur in einem klar getrennten Abschnitt für Gerüchte oder Spekulationen und nur mit vorsichtiger Formulierung. Stelle ein unbestätigtes Feature nicht als Teil der bestätigten Roadmap dar.
Sieh dir diese Seite erneut an, sobald eine offizielle Ankündigung im Jahr 2026 den Status, den Umfang oder die Verfügbarkeit eines Features verändert.