Wochenrückblick: Zwei weitere Hub-Games, ChargePools und neues vom Citybuild

Kreativ-Team

Wie im letzten Wochenrückblick bereits angekündigt, hat sich das Bauteam wieder den Bauarbeiten auf der ersten Citybuild Shard gewidmet. Zuvor wurde hier der erste Quadrant der Karte vollständig abgeschlossen. Nun wurden im zweiten Quadranten weitere Städte ausgelegt und mit Straßen verbunden. Das Team hat sich dazu entschlossen erst im gesamten Quadranten alle Straßen und Grundstücke zu errichten, bevor dann in einem Rutsch die gesamte Vegetation nachgezogen wird. Dies soll das Entstehen von unschönen Übergangen zwischen unterschiedlichen Bauabschnitten vermeiden.

Entwicklung

Auch in dieser Woche haben sich die Game-Entwickler mit viel Eifer an die Weiterentwicklung der Hub-Games gemacht. Für das "Archergame" wurde eine Einstellung hinzugefügt, die es jedem einzelnen Spieler ermöglicht die Farbe zu konfigurieren, in der seine Ziele hervorgehoben werden. Dazu haben wir uns entschlossen, da es bereits innerhalb des Teams keine klare Meinung gab, welche Farbe besser zu erkennen ist. Um hier für jeden Spieler das bestmögliche Spielerlebnis bieten zu können, haben wir uns dazu entschlossen, die Wahl der Farbe in die Hand des Spielers zu geben.

Bei der Entwicklung des "Fishing-Games" sowie des "Endless Parkours" stehen Gemuese_Hasser und Infynyty kurz vor der Fertigstellung der ersten funktionierenden Versionen der beiden Spiele. Diese erste Fassung dient uns dann dazu um herauszufinden, in welche Richtung wir die Spiele entwickeln möchten, und um genau zu sehen, auf welche Aspekte der Spiele wir einen besonderen Augenmerk legen wollen.

Bei der Implementierung der Kuhkatapulte, über die wir in der letzten Woche berichtet haben, wurde festgestellt, dass wir ein System benötigen, dass es uns ermöglicht eine bestimmte Anzahl an freien Benutzungen zu gewähren, ebenso aber auch die Nutzung von zusätzlichen Aufladungen zu einem bestimmten Preis. Hinzu kommt, dass diese Benutzungen innerhalb eines bestimmten Zeitraums auch wiederhergestellt werden sollen. Da dieses Muster in unterschiedlichen Formen des Öfteren in unseren Spielen und Plugins benutzt wird, haben wir uns dazu entschlossen eine entsprechende Abstraktion (ChargePools) zu schreiben, um den Aufwand in der Zukunft bei der Benutzung dieses Musters möglichst gering zu halten. Um einen etwas detaillierter Einblick zu gewähren ist hier ein Ausschnitt aus unserer Dokumentation dazu:

Ein ChargePool stellt eine Quelle bzw. Sammlung von Aufladungen für beliebig viele Ziele dar, die isoliert voneinander verwaltet werden. Jedes Ziel verbraucht also unabhängig von den anderen Zielen die Aufladungen eines ChargePools. Zusätzlich zu normalen Cooldowns, bei denen eine Aktion immer nur entweder gerade verfügbar ist, oder gerade darauf gewartet wird, dass die Aktion wieder verfügbar gemacht wird, beinhaltet der ChargePool ein Konzept von Aufladungen, deren Auffüllung über die spezifischen Implementationen geregelt wird.

Ein ChargePool mit einer einzigen Aufladung entspricht dabei der traditionellen Vorstellung eines Cooldowns, der einmal genutzt werden kann und danach wieder aufladen muss. Es ist nicht nur möglich ein Limit der erlaubten Aufladungen anzugeben, sondern es kann darüber hinaus auch ein Limit der zusätzlichen Aufladungen hinterlegt werden, deren Nutzung an bestimmte Kosten, Sanktionen oder Modifikationen geknüpft werden kann.

Damit kann das eigentliche Limit effektiv überschritten werden, sofern der Nutzer der Aktion für sich abwägt, dass der Vorteil des Überschreitens des Limits die damit einhergehenden Konsequenzen rechtfertigt. Wie die einzelnen Aufladungen wiederhergestellt werden (also ob sie zum Beispiel alle gleichzeitig oder einzeln wiederhergestellt werden, bzw. wann diese Wiederherstellung erfolgt) wird in den Implementationen festgelegt und ist nicht Teil dieser abstrakten Repräsentation des Cooldowns.

Durch die Einbindung verschiedener Speicher für die Daten von ChargePools, kann modular entschieden werden, ob die Daten des ChargePools nur in der aktuellen Laufzeit zur Verfügung stehen sollen, oder ob sie auch darüber hinaus (beispielsweise in einer Datenbank) verfügbar gemacht werden sollen und so über mehrere Sessionen hinweg Cooldowns festgelegt und abgefragt werden können.

Nach der Fertigstellung des Teamspeak Links ist Hydrofin nun mit der Entwicklung des Discord Links beschäftigt. Die Implementation basiert auch bei diesem Link auf dem gleichen System wie bei allen anderen Links. Allerdings gibt es hierbei nun andere Schwerpunkte zu beachten, die es vorher nicht gab. Dazu gehört zum Beispiel die Verwendung eines anderen Mechanismus zur Authentifizierung eines Nutzers, sowie die Anfrage von Berechtigungen.

LucaDev hat sich diese Woche in der Infrastruktur mit der Anbindung von unseren verschiedenen Systemen an Loki gekümmert. Dies hat zum Vorteil, dass nun alle generierten Logausgaben an einer Stelle zentralisiert gesammelt und aufbereitet werden können. Des Weiteren wurden alle unsere aktiven Webseiten umgezogen und dabei technischen auf den neusten Stand gebracht. Mit der Einführung von Limitation auf das Herunterladen von Images aus DockerHub haben wir mehrfach festgestellt, dass uns die standardmäßig gewährte Anzahl an Downloads uns nicht ausreicht. Als Maßnahme dazu haben wir einen Cache aufgebaut, der nur dann eine Anfrage an DockerHub weiterleitet, wenn das entsprechende Image zuvor noch nicht vorhanden war.

Ausblick

Mit der Implementation der ChargePools hoffen wir nun beim weiteren Refactoring des PvP schneller voranzukommen. Mit der Fertigstellung der ersten Versionen der beiden anderen Hub-Spiele erhoffen wir uns ein klareres Bild zu erhalten, wie wir diese weiter vorantreiben wollen. Das Kreativ-Team wird sich weiterhin dem Bau des zweiten Quadranten auf der ersten Citybuild Shard widmen.

Zusammengefasst gab es in dieser Woche also wieder viele spannende Neuerungen. Folgt uns gerne auf Discord, Instagram oder Twitter, um stets auf dem Laufenden zu bleiben. Bis zum nächsten Mal!