Soeben habe ich die erste spielbare Version (0.7.1) von meinem Versuch eines Retro-Fußballmanagers veröffentlicht: https://olipool.itch.io/boeckhams-football-manager

Boeckham’s Football Manager ist ein Management-Spiel in dem ihr die Herrschaft Verantwortung für ein Fußball-Team übernehmt. Um erfolgreich zu sein, müssen Spieler verwaltet werden, kaufen und verkaufen zählt dazu ebenso wie das Händchen halten, sollten sie in Schwierigkeiten geraten. Das Stadion will ausgebaut werden und natürlich auch das Umfeld. Spielerwaden müssen massiert und Jugendspieler gezüchtet werden. Um all das zu finanzieren dürfen die Verhandlungen mit Sponsoren natürlich nicht fehlen.

Aber das Team ist nicht einmal das Wichtigste am Spiel: ihr als Manager seid es! Strebt eine großartige Karriere an, sammelt Wissen durch Fortbildungen und Erfahrung und macht euren Namen bekannt. Startet als unbekannter Niemand in einem kleinen Verein und führt ihn an die Spitze. Oder nutzt euren Ruhm – solang er noch nicht vergangen ist – und heuert bei berühmten Klubs an. Was werdet ihr tun, um zu erreichen, was noch kein Manager zuvor erreicht hat?

Das Spiel ist im Geiste der Managerspiele der 90er Jahre entwickelt worden. „Bundesliga Manager“ oder „Anstoß“ standen in einigen Aspekten Pate. Das Hauptziel ist es, die überwältigende Komplexität von modernen Management-Simulationen herunterzufahren. Diese Spiele sind genial, aber wenn ihr mal ein oder zwei Saisons an einem Abend spielen wollt an Stelle von ein oder zwei Spieltagen, dann ist Boeckham’s Football Manager vielleicht etwas für euch. Präzise Simulation bis auf einzelne Zehen hinunter ist nicht beabsichtigt, Spaß und Spielfluß sind wichtigere Designziele.

Die Entwicklung ist noch nicht abgeschlossen und das Spiel wird sich noch verändern. Bitte seid euch bewusst darüber, dass es noch einige Bugs oder Probleme mit der Spielbalance geben wird. Das ist bei einem komplexen Genre wie hier in einem solchen Entwicklungsstand nicht zu vermeiden, selbst wenn das Ganze nach außen hin nicht komplex wirkt. Solltet ihr auf Probleme stoßen, so würde ich mich freuen, davon zu hören. So tragt ihr einen wichtigen Teil zur Reifung des Spiels bei. Speicherstände im Speziellen können auch mal das Los erleiden, mit künftigen Versionen nicht mehr benutzbar zu sein. Sorry schon mal dafür!

Umgesetzte Features bis jetzt:

• zwei Ligen mit unterschiedlichen Teams (Deutsch und Englisch)
• Stadion-Management: Ausbau und Preisgestaltung
• Sponsorenverhandlungen: Hauptsponsor und Bannersponsoren
• Spielerverwaltung: Kaufen und Verkaufen auf dem Transfermarkt, Einzeltraining, Vertragsverhandlungen etc.
• Ausbau des Umfelds: Fitnesscenter, Rehaabteilung, Parkplätze, Restaurants und einige mehr
• Manager-Management: nimm an Workshops oder mehrwöchigen Fortbildungen mit Quizfragen teil, um bestimmte Fähigkeiten und Features freizuschalten. Plant eure Karriere und wechselt zu anderen Vereinen
• Liga, Pokal und Champions League (naja, eine Variante davon mit Statistiken
• Dynamische Stories: von Einzelereignissen bis zu mehrere Wochen umspannende Handlungen, die eure Spieler oder euch selbst betreffen und von euch (und euren erlernten Fähigkeiten) gelenkt werden können
• KEINE Lootboxen, Punkte, Sammelkarten etc.
• KEINE Social Media Integration oder globale Zeitlinie: spielt in eurem eigenen Tempo!

Geplante Features:

• viele weitere Stories, um die Erfahrung eines jeden Spieldurchgangs immer wieder neu zu formen
• weitere Grafiken, insbesondere vom Stadionumfeld
• weitere Ligen, evtl. auch Nationalmanschaften
• Spieleraufstellungen direkt auf dem Spielfeld durchführen
• Kartenspiel (Gwent oder ähnlich) zum Erstellen einer Taktik für jedes Spiel, um einen Stärke-Boost für das Team zu erhalten
• mehr Einfluss der eigenen Biographie auf die Stories
• Mehrspieler an einem Rechner (Ja! Wie früher!
• GANZ VIELLEICHT online Mehrspieler, nicht im Sinne eines MMO, sondern 1-4 Spieler mit euren Freunden

Diesen Sommer hatte ich mir vorgenommen, ein bisschen mehr Routine mit Unity zu erlangen und wollte ein paar kleinere Projekte zur Übung angehen. Dabei hatte ich Remakes von alten Amiga-Spielen im Auge, die ich früher gern gespielt habe. Dadurch konnte ich mich auf die „Technik“ fokussieren und musste nicht viel übers Design nachdenken. 10 Spiele in 10 Wochen sollten es werden, was extrem ambitioniert klingt, so als ob ich nichts aus dem Escape Room gelernt hätte Aber ich wollte ursprünglich nur die ganz grundlegende Mechanik umsetzen und dann zum nächsten Spiel wechseln. Doch so unfertig konnte ich so ein Spiel nicht lassen und es kamen dann mehr Features und Artwork dazu.

Letzten Endes beschloss ich, mich auf drei Spiele zu konzentrieren, diese aber sehr orignalgetreu umzusetzen. Dadurch konnte ich vor keiner unbequemen Aufgabe ausweichen, Dinge, von denen ich keine Ahnung hatte, wie sie umzusetzen seien, mussten umgesetzt werden. Letztlich hatte dieses Vorgehen aber einen sehr großen Lerneffekt. Dieses erworbene Wissen möchte ich gerne teilen und plane, das Projekt inkl. Artwork und Code in den Asset Store zu stellen. Zur Zeit ist es in Prüfung bei Unity und ich hoffe auf grünes Licht.

Zusätzlich soll das Projekt mit Videotutorials in der Tiefe exploriert werden. Die müssen natürlich auch erst noch gemacht werden, so dass noch eine Menge Arbeit vor mir liegt. Aber ich hoffe, dass es angehende Devs bei ihren ersten und zweiten Schritten unterstützen wird.

Nach dem Besuch eines Escape Rooms im letzten November, fand ich die Idee sehr reizvoll, so etwas auch virtuell zu spielen (und zu bauen!). Besonders die Möglichkeiten von VR und Multiplayer versprechen viel Potential. Leider sind diese beiden Features noch nicht sonderlich in meinem Skillset verankert, so dass ich den Raum erstmal als reine Einzelspieler-Erfahrung nachgebaut habe.

Nach einigen Hürden, die ich zu überwinden hatte  – und durch die ich einiges gelernt habe! – ist nun die erste Version fertig für den Beta-Test. Mein Plan ist es, das Spiel zu Steam zu bringen, jedoch muss dafür noch die ganze Unternehmens- und Steuerproblematik geklärt werden, was vermutlich weitaus komplizierter sein wird, als das Spiel zu erstellen

Sollte ich noch mal in den Genuss eines VR Headsets kommen, so wäre eine Version dafür denkbar. Ebenso ist das Multiplayer-Thema nicht durch, aber für die Einarbeitung werde ich einige Zeit benötigen. Cool wären sehr große Escape Rooms, die permanent auf einem Server liegen und durch mehrere Spieler über einen längeren Zeitraum nach und nach gelöst werden. So ein bisschen wie die Suche nach dem Ei in „Ready, Player One“

Wenn du die Beta gerne testen würdest, schreibe mir einfach eine Mail, einen Tweet oder eine Nachricht auf Facebook. Die aktuelle Version ist vollständig in deutscher Sprache verfügbar.

Wir sind dabei zunächst dem Handbuch und dem Tutorial auf der Unity-Webseite gefolgt und haben alles zu einem simplen 2D-Autorennen umgestrickt: Supercars!

Wir wollen nicht verhehlen, dass es sich hierbei um ein Teilremake des alten Amiga-Klassikers handelt und wir momentan auch noch die Original-Assets benutzen. Da wir uns aber auf den Multiplayer-Part konzentrieren wollten, schien es uns unnötig, mit originärem Gameplay an den Start zu gehen, um die Zeit anderweitig besser nutzen zu können. Nachdem die erste lauffähige Version fertig war, haben wir nun eine schöne Testumgebung, um neue Features auszuprobieren. Wir haben das Originaltutorial z.B. um eine komplette Gameloop erweitert (warten auf Spieler, Rennen fahren, Zielzeiten anzeigen, …), die auf allen verbundenen Clients synchron läuft, wir haben einen Chat eingebaut und ein paar Bots, die solange mitfahren, bis sich ein weiterer Spieler verbindet und dann einen Bot übernimmt. Es macht schon ziemlich Spaß im Multiplayerbereich zu programmieren, jedoch läuft man ein ums andere Mal vor die Wand und muss sich genau überlegen, wie alle Komponenten zusammenhängen: Client, Server, lokaler Spieler, Funktionen auf dem Server (commands), Funktionen auf dem Client (RpcClient)…

Wir werden das Projekt nun noch einmal überprüfen und ggf. Fehler oder unglücklich gelöste Problemstellungen, die aus anfänglicher Unerfahrenheit her rühren mögen, zu bereinigen. Anschließend möchten wir das Projekt dann als Lernbeispiel anderen Entwicklern zur Verfügung stellen, da UNET noch relativ neu ist und wenig auf Erfahrung beruhende Beispiele zu finden sind. Wir hoffen dabei auch, dass unsere Fehler gnadenlos aufgedeckt werden ;).

Anlässlich des Jahreswechsels haben wir unser erstes Gameplayvideo zu The Slurping Dead fertig gestellt. Viel Spaß dabei, Anmerkungen sind wie immer sehr willkommen!

Nachdem wir uns ein wenig nach Engines umgesehen hatten, fiel die Wahl erst einmal auf Unity. Wir haben auch diskutiert, ob wir nicht eine offenere Variante nehmen sollten, in der wir tiefere Eingriffsmöglichkeiten hätten, denn als Informatiker hat man das natürliche Bedürfnis, auch an der letzten Schraube zu drehen und zudem auch den Ehrgeiz, Problemstellungen selbst zu lösen und keine Funktionalität von der Stange zu verwenden (fühlt sich ein bischen wie cheaten an). Aber letztlich entschieden wir uns dagegen; denn es verhält sich ja so: Natürlich kann man einen Textparser selber schreiben, natürlich kann man einen Szeneneditor selber schreiben, aber damit gehen die Monate ins Land und das eigentliche Kernstück des Spiels, das Gameplay, findet in dieser Zeit keine Beachtung. Und seien wir ehrlich: in fast jeder Sprache oder Engine wird man auf fertige Bibliotheken zurückgreifen, denn wer möchte sich antun, beispielsweise einen FBX-Importer selbst zu verfassen?

Als nächstes versuchten wir uns zu organisieren. Da wir keine klassische Kombo von Programmierer und Grafiker darstellen, war klar, dass sich Arbeitsbereiche überschneiden würden. Und da wir zudem an verschiedenen Standorten tätig sind, brauchten wir eine Möglichkeit der zentralen Ablage, der Versionierung und ggf. Zusammenführung von Arbeitsständen. Hierbei entschieden wir uns aufgrund von Erfahrung für BitBucket (https://bitbucket.org/). Dadurch erhält man eine kostenlose Online-Ablage für seine Aufgaben und seine Daten, auf die dann mittels eines Clientprogramms zugegriffen werden kann. Bei diesem haben wir uns für SourceTree vom gleichen Anbieter entschieden (https://www.sourcetreeapp.com/). Durch diese Konfiguration ist es nun möglich, lokal vor sich hin zu werkeln und einzelne Versionsstände zu sichern und zu einem beliebigen Zeitpunkt mit der Online-Ablage abzugleichen. So kommt man wieder auf den selben Stand wie die Mitstreiter und stellt die eigenen Änderungen den anderen zur Verfügung. Dies hat bislang ganz gut funktioniert, man sollte sich jedoch trotzdem ein wenig absprechen: Wenn zwei Personen an der gleichen Datei arbeiten, besteht immer die Gefahr, dass nicht beide Änderungen übernommen werden. Das funktioniert generell auch nur für textbasierte Dateien und nicht beispielsweise für Bilder oder 3D-Modelle. In Unity selbst lässt sich z. B. auch einstellen, dass Projekt- und Szenendateien textbasiert gespeichert werden.

Nun wollten wir ja mit unserem ersten Projekt alle Arbeitsschritte kennen lernen. Dennoch haben wir die Konzeptphase, ein Design-Dokument oder Styleguides mal komplett übersprungen und haben erst mal drauflos probiert. Im Nachhinein ist das auch nicht unbedingt ein schlechter Ansatz, denn so konnten wir Unity anhand eines eigenen Beispiels kennenlernen und neues Wissen gleich integrieren und verfestigen. Beim nächsten Projekt wird das selbstverständlich ganz anders werden ;). Nach und nach bauten wir also einen Testlevel auf, modellierten Gegenstände, schrieben C#-Skripte, versuchten uns an der Animation der Spielfigur, lernten die Physik-Engine und Ragdolls (Juhuu!) kennen und fügten immer neue Ideen ein. Übertrieben gesagt fragten wir nicht: Wie kann Unity unsere Anforderungen erfüllen? Sondern: Wie können wir dieses und jenes Feature von Unity für uns nutzen? Meiner Erfahrung nach ist das Lernen in dieser Art und Weise deutlich effektiver als reines Lesen oder Schauen von Tutorials auf Youtube. Diese sind aber dennoch nicht weg zu denken, sei es als Inspiration oder auch um Probleme zu lösen, über die man im Verlauf seines Projekts stolpert (einen Youtube-Kanal möchte ich an dieser Stelle noch erwähnen, der mir nach viel Herumprobieren letztlich am besten den Einstieg in Unity ermöglicht hat: quill18creates).

Der Nachteil dieser Herangehensweise ist uns natürlich auch klar geworden, insbesondere die Skripte mussten immer wieder umgebaut werden und gleichen mittlerweile einem Flickenteppich. Auch sind spätere Skripte anders geschrieben als frühere und somit etwas inkonsistent (Beispiel: Awake() oder Start() nutzen? Komponenten per getComponent() suchen oder im Editor verdrahten?). Das kann natürlich auch Frust erzeugen, aber unser Vorgehen hatte doch den großen Vorteil, dass wir schnell Fortschritte gesehen haben und so die Motivation aufrecht erhalten werden konnte.

Lässt sich also festhalten, dass uns die Wahl von Unity, das überschaubare Szenario und ein nur halb-geplantes Vorgehen schnell haben starten und lernen lassen. Für den Einstieg ist das eine schöne Sache, man sollte sich nur im Klaren sein, dass eben dieses erste Projekt vermutlich kein großer Wurf werden wird. Daher sollte man auch nicht gleich mit seinem lang gehegten Traumprojekt loslegen, sonst wird man letztlich nur enttäuscht sein.