Spieleentwicklung
Erst muss der Kern Spaß machen. Dann wächst das Spiel.
Eine Spielidee lässt sich beurteilen, sobald jemand spielen, eine Entscheidung treffen und noch eine Runde versuchen kann. Wir entwickeln klar abgegrenzte digitale Spiele und spielbare Prototypen mit verständlicher Steuerung, Fortschritt, vereinbarten Leistungszielen und klarer Verantwortung für das nächste Release.
DIREKTE ANTWORT
Spieleentwicklung verbindet Regeln, Interaktionen und Assets zu einem spielbaren Erlebnis. Wavect grenzt einen Prototyp, einen repräsentativen Vertical Slice oder ein definiertes Release ab und implementiert und prüft Gameplay, Spielzustand und Auslieferung.
Geeignet für
- Teams, die eine konkrete Spielmechanik oder eine erste spielbare Version testen
- Lernspiele, Serious Games und Markenspiele mit klarer Zielgruppe
Ein anderer Einstieg passt besser
- Eine Produktidee ohne geklärte Zielgruppe oder Zweck
- Ein Produktviewer ohne Gameplay, Herausforderung oder Fortschritt
Was macht der Spieler immer wieder?
Am Anfang steht eine sinnvolle Aktion mit einer Konsequenz: ein Rätsel lösen, eine taktische Entscheidung treffen oder eine Lernaufgabe bewältigen. Wir beschreiben Einstieg, Erfolg, Scheitern und erneuten Versuch, bevor weitere Level entstehen. Ein Prototyp prüft die Mechanik; ein Vertical Slice zeigt zusätzlich die vereinbarte Produktionsqualität. Sind Zielgruppe oder Geschäftsziel noch unklar, gehört diese frühere Entscheidung in die Software Discovery.
Erst das Zielsystem, dann die Engine
Browser, Desktop und Mobilgeräte stellen unterschiedliche Anforderungen an Steuerung, Ladezeiten und Veröffentlichung. Wir vereinbaren zuerst Zielhardware, Engine-Version, Abhängigkeiten und Test-Build. Unity, Unreal Engine, Godot oder ein Browser-Stack kommen je nach Projekt infrage. Benötigte Engine- und Art-Kapazitäten bestätigen wir vor der Beauftragung. Headset-Interaktion, Tracking und Komfort gehören zur VR- und XR-Entwicklung.
Was bleibt nach einer unterbrochenen Sitzung?
Wir halten fest, welche Einstellungen, Checkpoints, Gegenstände und Belohnungen erhalten bleiben und was jede Runde zurückgesetzt wird. Dazu gehören die Verantwortung für Spielstände, Versionskompatibilität und die Wiederherstellung nach einem unterbrochenen Schreibvorgang. Die Godot-Dokumentation zum Speichern zeigt, warum persistente Objekte und ihre Rekonstruktion ausdrücklich geplant werden müssen. Lokaler Fortschritt, Kontosynchronisation und Wettbewerbsergebnisse haben unterschiedliche Vertrauensgrenzen; der Brief benennt die maßgebliche Datenquelle.
Beobachten, wie Menschen den Build tatsächlich spielen
Ein Spieltest prüft, ob Menschen das Ziel verstehen, Rückmeldungen erkennen und nach einem Fehler weitermachen können. Wir vereinbaren Teilnehmende und Aufgaben, dokumentieren beobachtete Hürden und trennen Balancing-Entscheidungen von reproduzierbaren Fehlern. Steuerung, lesbare Oberflächen, Audioeinstellungen und Pausenverhalten werden auf den Zielgeräten geprüft. Jeder Befund nennt Build-Version und Testbedingungen. Änderungen an Schwierigkeit oder Rückmeldungen werden anschließend erneut mit der vorgesehenen Zielgruppe geprüft.
Beispiel für die Abnahme: abschließen, beenden, zurückkehren
Ein Spieler schließt eine Aufgabe ab, erhält die Belohnung genau einmal und erreicht einen Checkpoint. Nach dem Schließen und erneuten Öffnen des vereinbarten Builds sind Fortschritt und Einstellungen korrekt wiederhergestellt. Ein wiederholter Abschluss erzeugt keine doppelte Belohnung; ein unterbrochener Speichervorgang folgt dem vereinbarten Wiederherstellungsverhalten. Zusätzlich hält der Build die vereinbarten Grenzen für Laden, Speicherbedarf und Frame-Zeiten auf dem benannten Mindestgerät ein. Das ist ein vorgeschlagenes Abnahmeszenario, kein berichtetes Kundenergebnis.
Ein Build, den auch jemand anderes erstellen kann
Zur Lieferung gehören Quellcode-Repository, Build-Anleitung, vereinbarte bearbeitbare Assets, Abhängigkeits- und Lizenznachweise, bekannte Probleme und Abnahmeergebnisse. Wir klären die Verantwortung für Entwicklerkonten, Einreichungen, Updates und Support. Über die Store-Freigabe entscheidet der jeweilige Betreiber. Ein Release-Meilenstein endet mit den vereinbarten Ergebnissen; laufende Inhaltsupdates, Moderation und Serverbetrieb benötigen eigene Zuständigkeiten und Budgets. Dein Team soll den nächsten Build selbst erstellen und prüfen können.
Fragen vor dem Start
Ein Prototyp eignet sich, um eine Mechanik mit Spielern zu prüfen. Ein Vertical Slice hilft zusätzlich, repräsentative Grafik, Audio, Leistung und Produktionsaufwand einzuschätzen. Legt zuerst die Frage fest, die der Ausschnitt beantworten soll, bevor weitere Inhalte entstehen.
Nur bei ausdrücklicher Vereinbarung. Spielerkonten, maßgeblicher Spielzustand, Matchmaking, Wiederverbindung, Missbrauchsschutz, Lasttests und Serverkosten brauchen eigene Entwurfs- und Abnahmekriterien. Ein erfolgreicher lokaler Prototyp klärt diese Anforderungen noch nicht.
Ja, mit einem klar definierten Brief. Wir verbinden das Lernziel mit Spielerentscheidungen und Rückmeldungen und vereinbaren, wie das Verständnis bewertet wird. Ein Abschlusswert allein belegt keinen Lernerfolg und zertifiziert niemanden für eine reale Aufgabe.
Vor der Schätzung vereinbaren wir Asset-Liste, Qualitätsreferenzen, Lizenzen und Produktionsverantwortung. Die 3D-Modellierung übernimmt eigenständige Asset-Arbeit. Spezialisierte Grafik-, Animations- und Audiokapazitäten müssen für das Projekt bestätigt werden; sie sind nicht automatisch Teil der Programmierung.
Hilfreich sind Quellcode, Engine- und Plugin-Versionen, ein reproduzierbarer Build und das konkrete Problem. Wir prüfen Zuständigkeiten und Kompatibilität und grenzen anschließend eine Funktion oder Stabilisierung ab. Eine unabhängige Release-Prüfung lässt sich über Software-QA vereinbaren.
Dein Spieleprojekt besprechen
Beschreibe die Zielgruppe, die Geräte und das kleinste vollständige Spielerlebnis. Hilfreich sind ein vorhandener Build oder ein Design-Dokument sowie Angaben dazu, welche Rechte an Code, Grafik und Audio bereits bei dir liegen.