Ich spiel gerade mit dem Gedanken die Musik für das Spiel selber zu schreiben. Vor allem würde dann endlich mal ein Song von mir „zum Einsatz“ kommen. Als ich noch aktiv in einer Band gespielt hatte, hab ich mit Songwriting angefangen. Leider hat sich die Band aufgelöst als mein erster Song fertig wurde…zumindest war es der erste Song den ich in seiner Roh-fassung für Bandwürdig halten würde (hatten schon 2 Songwriter die echt gut sind und wollte den dann gemeinsam mit denen während der Probe verfeineren. Songtext hätte der Sänger geschrieben). Um den fertig zu bekommen hatte ich mir extra Gitarren- und Schlagzeugunterricht geben lassen. .
Dann hat sich meine Freundin ein Keyboard zugelegt und eigentlich wollte ich mit Ihr auch ein Musikprojekt durchstarten. Mein bester Kumpel sollte dann Gesang machen - ansonsten wären hier dann Keyboard drin und Bass (ich). Aus dem Projekt wurde aber leider irgendwie nix. Einen Song hatte ich trotzdem geschrieben (diesmal allerdings mit etwas Wissen über Musiktheorie):
Und nun ja: alle guten Dinge sind 3 was? Der könnte es dann ins Spiel packen und veröffentlicht werden
Hab mir gestern mal Trello näher angeschaut. Ist eigentlich ne ganz nette Möglichkeit ein Kanban-Board abzubilden, so wie ichs gerne hätte. Außerdem kann ich damit eine wirklich permanente Roadmap anbieten die auch up-2-date bleibt. Des weiteren bietet es mir auch die Möglichkeit meine Releases zu dokumentieren. Also, die aktuelle Roadmap findet Ihr hier:
Des weiteren hab ich ziemlich gute Performance-Verbesserungen erreicht. Eigentlich hatte ich für das nächste Release ein paar mehr Tickets geplant. Aber da ich mit meinen gestrigen Optimierungen jetzt endlich wieder mit dem Spiel zufrieden bin, wird 1.9.1 wohl früher veröffentlicht werden
Wie schon angesprochen hab ich die neue Version eben veröffentlicht (win+android). Wie immer gilt: es kann noch etwas dauern, bis das update im PlayStore bereit steht.
So, brauch mal eure Kritik. Hab jetzt das erstemal mit Synthesier gearbeitet. Geschrieben in Guitar Pro wo ich dann eine MIDI-Datei rausgelassen hab und mithilfe von Cubase hab ich dann eine Audio-Datei exportieren können. Ich weiß ehrlich gesagt nicht, obs mir gefällt - ob zu viel oder zu wenig. Ich brauche zu sowas immer erstmal ein paar Stunden abstand, bevor ich mir eine Meinung bilden kann. Aber vielleicht könnt Ihr mir ja schon Input geben:
Gespielt werden soll das ganze als Endlosschleife im Hauptmenü.
Bisher find ich Trello ganz gut. Sehr simpel gehalten und ich kann mein Zeug priorisieren. Sollte ich da an die Grenzen kommen, werd ich mir hacknplan aber mal genauer anschauen.
Hab jetzt mal das Spiel gestartet und parallel dazu meinen Track … Irgendwie würd der besser zu einem Spaceshooter passen
Hab jetzt mal noch ein wenig mit den Synthesisern rumgespielt. Mit violine klingts find ich richtig cool … nur leider nach wie vor unbrauchbar für mich
(update: hintergrund-gesäusel geändert)
Oder ich nehms halt doch und mach mein Spiel dadurch „epischer“ als es ist
Streich das Vielleicht. Bin jetzt auf Hacknplan gewechselt und ich glaub das war die richtige Entscheidung gewesen. Wenn es wirklcih alles passt werde ich vllt auch mal auf eine Premium-version davon umsteigen (ist ja mit 4-6€/Monat nicht wirklich teuer).
Ich hab gestern viel Zeit mitn Hacknplan verbracht. Ich konnte meine bisherige Organisation sehr gut darauf abbilden und das schöne: Ich kann auf andere Tickets verweisen!
Natürlich ists nicht so mächtig wie Jira, aber das tut dem ganzen kein Abbruch. Das ich meine Elemente gruppieren, blocker einstellen und andere Tickets über deren Id in der Beschreibung erwähnen kann hilft ungemein. Subtasks hatte ich in der Form auch bei Trello (Dort waren es halt Checklisten). Und die Basisfunktionalität davon find ich auch ordentlich. Die kostenpflichtigen Varianten bieten mir eigentlich nur nice-2-haves an.
Alles in allem eignet es sich auf jeden Fall besser als Trello! Hab gestern Abend irgendwann einfach nur mal durch mein Backlog geklickt und hat Spaß gemacht zu sehen, wie geordnet das doch auf einmal ist .
Einige Sounds sind nun drin (ich würde mal behaupten: die wichtigsten ^^). Hinzu kommt, dass ich bisher noch etwas am Sprung-verhalten geändert hab. Es sollte nun (hoffentlich) besser klar sein, wann der Character springen kann. (Ihr könnt euch nicht vorstellen wie kacke kompliziert es ist fest zu stellen, ob die Figur am Boden ist oder nicht!).
Des weiteren sind Dirt-Blöcke nun nicht mehr blockierend. D.h. man kann durchrennen - aber auch durchfallen.
Dennoch wird ein Update noch etwas auf sich warten lassen müssen, denn mit den Sounds soll auch endlich mal ein Menü komme, wo man Einstellungen vornehmen kann. Und die ersten Einstellungsmöglichkeiten werden sein: Sounds ein-/ausschalten.
Glaube nicht, dass ich diese Woche noch alles fertig bekommen werde.
Ich hab mir heute morgen nochmal Gedanken über meine Architektur gemacht und mich entschieden - ein erneutes Refaktoring bald zu starten. Dabei bin ich mal einige Ideen durchgeganen:
Oben links
Hier seht ihr die Ursprüngliche Idee. Dabei kannten sich die Manager gegenseitig und haben auch Methoden von anderen Managern aufgerufen. Wie man an den 3 Klassen schon sehen kann: Man hat hier einen geschlossenen Kreis aus harten Abhängigkeiten. Das macht Probleme, denn die Manager müssen sich Gegenseitig wirklich gut kennen, damit dieses Model funktioiniert.
Oben rechts
Dat hatte ich mit dem Gedanken gespielt, einen Service dazwischen zu packen. Allerdings konnte ich auch hier sehr schnelle harte Abhängigkeiten erkennen. Ergo: Es würde mein Problem von der ersten Architektur einfach nur verlagern. Leicht angepisst hab ich das Model also auch wieder verworfen.
Mitte
Hier seht Ihr die aktuelle Architektur mit dem Problem daneben: Wenn ich auf Events direkt bei einer Änderung reagiere, dann kann das fatale Folgen haben. Denn diese Architektur war der Grund für meine üble Performance. Desweiteren hab ich diese auch nie 100% Umgesetzt bekommen, da die Manager z.T. noch immer von anderen Klassen verwendet werden.
Unten
Sehr Ähnlich zu der aus der Mitte. Soetwas wie ein Hybrid aus der Initialen Architektur und der aktuellen. Die Kommunikation geht zurück zu den Managern. Aber anstelle von harten Abhängigkeiten möchte ich weiche zu den anderen Manager einbauen. Also ja: event-basiert. Allerdings wären die Sachen (imho) etwas einfacher und klarer hier zu händeln. Wenn nur noch die Manager die Models verändern, dann könnte ich z.b. mit dirty-flags arbeiten und hätte es damit einfacher in den vorgesehenen Methoden auf die Änderungen zu reagieren.
Nachdem ich den Manager für die Einstellungen gleich mit der neuen Architektur umsetzen wollte, hab ich gemerkt: Die Idee ist kacke.
Ich glaub ich hab ne neue - diesmal tolle Idee gefunden. Ich belasse es doch bei dem Konzept wie es ist - baue aber eine Verzögerung der Events ein. Beispiel:
namespace Model {
public class SettingsModel : MonoBehaviour {
[SerializeField] private bool _enableGameSounds = true;
[SerializeField] private bool _enableMenuSounds = true;
private readonly HashSet<string> _changedProperties = new HashSet<string>();
public delegate void SettingsHandler(object sender, string propertyName, SettingsModel settingsModel);
public event SettingsHandler SettingsChanged;
public bool EnableGameSounds {
get { return _enableGameSounds; }
set {
if (_enableGameSounds == value) return;
_enableGameSounds = value;
_changedProperties.Add(nameof(EnableGameSounds));
}
}
public bool EnableMenuSounds {
get { return _enableMenuSounds; }
set {
if (_enableMenuSounds == value) return;
_enableMenuSounds = value;
_changedProperties.Add(nameof(EnableMenuSounds));
}
}
public bool Dirty => _changedProperties.Count > 0;
public void FireSettingsChanged(object sender) {
if (SettingsChanged != null) {
foreach (var changedProperty in _changedProperties) {
SettingsChanged(sender, changedProperty, this);
}
}
_changedProperties.Clear();
}
}
}
Wenn irgendwas an den Daten geändert wird, dann kann ich das über das Dirty-Flag prüfen. Und um das Senden der Events kümmert sich dann der SettingsManager:
So. Hatte heute doch überraschend mehr Zeit gehabt als erwartet und konnte so einiges noch fertig stellen. Die neue Version ist im App-Store eingereicht und auch die Win-Version hat Ihr Update bekommen.
Zu den Änderungen:
Es gibt Sound
und den könnt Ihr in den Einstellungen deaktivieren (falls gewollt)
Verbessertes Sprungverhalten
Ich hab die Prüfung - wann gesprungen werden kann - weiter angepasst. Vorher hatte ich als Prüfung drin, ob der Spieler eine Beschleunigung auf der Y-Achse hat. Dummerweise ist das mehr als oft false-positiv, wodurch ein Sprung verhindert wurde. Das hab ich jetzt umgebaut und zwar berücksichtigt die Spielfigur nun seine relative höhe. Wenn sich diese nach dem Verlassen eines Box-colliders um mehr als 0.5f unterscheidet - dann findet ein Sprung statt. Ich hoffe damit erziele ich besser Ergebnisse.
An die Windows-Leute: Der Build-schaut etwas anders aus seit dem heutigen Update von Unity. Irgendwie spuckt das jetzt mehr Dateien als sonst aus (hatte extra den Ordner nochmal gelehert) und er nennt die exe auch liebevoll win.exe. Habs jetzt erstmal alles so gelassen und in die Zip gepackt.
Hallo liebes Tagebuch. Heute muss ich dir ein Geständnis machen, von dem keiner wissen darf:
die letzten zwei Tage war ich sehr faul und hab praktisch nur gezockt. Einzige Ausnahmen waren Schlafen, Bad, essen und Deadpool 2 (welchen ich sehr witzig fand und mir deswegen das ein oder andere mal den Arsch abgelacht hab). Ich gelobe Besserung und will heute wieder damit weiter machen an dem Spiel zu arbeiten (also halt hat nach der Arbeit).
Hallo Ihr anderen die meinen Tagebuch-Eintrag gelesen haben obwohl er offensichtlich nicht an euch gerichtet war! Für diejenigen unter euch, die das respektiert haben hier eine kurze Info: war die letzten Tage leider sehr beschäftigt und konnte deswegen nichts am Spiel machen.
Aber ich hatte davor schonmal grob meinen “Sprint” für das nächste released geplant. Vorgesehen sind bis jetzt:
Verbesserung der Architektur (die oben bereits erwähnten Änderungen)
Ich möchte die existierenden Level mal etwas überarbeiten.
Einen Shop für alles. Also die existierenden Shops (Feature Shop, Power-UP Shop) zu einem zusammen fassen. Das ist u.a. ein wichtiger Schritt für den kommenen Premium Shop. Außerdem ist diese Aufgabe (Einen Shop für alles) der momentan einzige Blocker für die Aufgabe “neu gestalten des Hauptmenüs”.
Ok. Das mit dem Refactoring stellt sich als doch nicht so leicht heraus wie erwartet. Ich hatte schon ein ganzen haufen fertig und hab dann so einen üblen Bug eingebaut, dass ich alles wieder reverted hab. Also hab ich effektiv 0 Fortschritt gemacht -.-
Bisher hab ich mich auch drum gedrückt mir anzuschauen, welche Test-frameworks es für unity gibt. Und zumindest Unit-Tests sollte ich eigentlich haben. Das will ich mir auch direkt als nächstes anschauen. Auf die schnelle hab ich zumindest mal rausgefunden, dass Unity dafür eigene Tools anbietet:
Und einen Blog mit ein paar Beispielen hab ich auch gefunden:
Und mal wieder sag ich: bye bye Ziel-architektur. Hallo neue Architektur xD. Ich hab zuviele Models und Manager die ich eigentlich zusammen fassen kann. Außerdem will ich meinen Code ja (wie angesprochen) Testbar haben. Was aber kacke ist, wenn ich diese als GameObjects habe (was aktuell der Fall ist, damit ich diese in die Szene ablegen kann). Also werde ich Services extrahieren, die von den Managern verwendet werden. Die Services verändern das Model und Events werdne über die Manager gefeuert. Hoffe inständig, dass das funktioniert - ist mehr oder weniger durch die Tests so vorgegeben. Ansonsten bin ich gerade fleißig dran, meinen ersten Manager neu zu schreiben und die ersten Test sind auch schon da :
Hoffe mal, dass das mein letztes großes Refactoring sein wird :’)
