Ahoi,
Es lebt noch!
die recht infrequenten Updates hier im Forum zu Swift Steel vermitteln wahrscheinlich den Eindruck, dass an dem Projekt nicht viel gemacht wird. Der Schein trügt allerdings
Wer die Commits bei github mitverfolgt, dürfte feststellen, dass aktuell mal wieder viel dran gewerkelt wird. Da das meiste davon aber Refactoring ist und eher schlecht mit einzelnen Features beschreibbar ist, verzichte ich meist auf ein Update hier im Thread. Heute mach ich mal ne Ausnahme ^^Und hier kommt sie:
Aktuell in der Mache ist beispielsweise der Dogfight-Modus (Oder wie auch immer er nachher heißen mag). Dabei wird eine Zufallskarte generiert, zufällig Basen platziert und man darf gegen einen oder mehrere Gegner kämpfen, ohne großartig was einstellen zu müssen. Also ne Art Sofortgefecht.
Teile davon werden gerade implementiert. Hauptsächlich der Teil mit dem Spiel-"Inhalt". Da mal ein kleiner Auszug aus dem Code:
Code:
package yang.model.unit.armory
object Weaponkind {
val Railgun = new Weaponkind {
val ammunitionNeededPerShot = Energy(23)
}
val GuidedRocketLauncher = new Weaponkind {
val ammunitionNeededPerShot = Projectile(1)
}
// ...
}
trait Weaponkind {
val ammunitionNeededPerShot: Ammunition
def canFireWith(ammunitionAvailable: Ammunition) = ammunitionAvailable >= ammunitionNeededPerShot
}
object Weaponkind {
val Railgun = new Weaponkind {
val ammunitionNeededPerShot = Energy(23)
}
val GuidedRocketLauncher = new Weaponkind {
val ammunitionNeededPerShot = Projectile(1)
}
// ...
}
trait Weaponkind {
val ammunitionNeededPerShot: Ammunition
def canFireWith(ammunitionAvailable: Ammunition) = ammunitionAvailable >= ammunitionNeededPerShot
}
(Ich will wieder Syntaxhighlighting im Forum... - Wer dem obigen Link folgt, bekommt auch ne kolorierte Version
)Das ist eine Art, Java-enums in Scala nachzubilden und das einzigste (Fällt mir zumindest spontan ein), was in Scala tatsächlich weniger hübsch ist als in Java. Dort sähe der Code (auszugsweise) so aus:
Code:
package yang.model.unit.armory;
public enum Weaponkind {
RAILGUN(new Energy(23)),
GUIDED_ROCKET_LAUNCHER(new Projectile(1)),
// ...
private final Ammunition ammunitionNeededPerShot;
private Weaponkind(Ammunition ammunitionNeededPerShot) {
this.ammunitionNeededPerShot = ammunitionNeededPerShot;
}
public Ammunition ammunitionNeededPerShot() {
return ammunitionNeededPerShot;
}
public boolean canFireWith(Ammunition ammunitionAvailable) {
return ammunitionAvailable.getAmmount() >= ammunitionNeededPerShot.getAmmount();
}
}
public enum Weaponkind {
RAILGUN(new Energy(23)),
GUIDED_ROCKET_LAUNCHER(new Projectile(1)),
// ...
private final Ammunition ammunitionNeededPerShot;
private Weaponkind(Ammunition ammunitionNeededPerShot) {
this.ammunitionNeededPerShot = ammunitionNeededPerShot;
}
public Ammunition ammunitionNeededPerShot() {
return ammunitionNeededPerShot;
}
public boolean canFireWith(Ammunition ammunitionAvailable) {
return ammunitionAvailable.getAmmount() >= ammunitionNeededPerShot.getAmmount();
}
}
Man beachte, dass Java-enums Parameter und Methoden haben können. Sind im Endeffekt relativ normale Instanzen der enum-Klasse "Weaponkind" in diesem Fall... So in der Art zumindest
Noch kurz ein paar Worte zum Scala-Code
In der Datei ist sowohl ein Object namens "Weaponkind", als auch ein trait (= Interface, grob gesagt) mit diesem Namen deklariert. Im Objekt selber gibt's mehrere Implementierungen dieses traits (innere, anonyme Klassen in Java). Das liest sich womöglich etwas seltsam
Was soll das jetzt sein?
Der Code ist meine Antwort auf die Problematik, wie man in diesem Fall am besten festhält, ob eine Waffe nun Energie oder Projektile benötigt und wie viel von welcher Sorte (ohne irgendwelche flags und sonstwas zu verwenden).
Ich merke mir nun also nur, wieviel Munition pro Schuss verbraucht wird. Dadurch weiß man automatisch, welche Munition die Waffe nimmt und wie viele Einheiten selbiger sie benötigt. Und das alles typsicher. Hätte ich die Menge von Munition einfach als integer gespeichert, wäre es durch einen Fehler möglich gewesen, dass z.B. die Railgun (Die Energie als Munitionsart hat), den Wert vom Raketenwerfer abbekommt und plötzlich sehr viel billiger schießt. Denn der Raketenwerfer verschießt immer nur 1 Rakete, während die Railgun hier immer 23 Energie verschießt. Währe das plötzlich nur noch 1 Energie, würde sich der Spieler sicher freuen; gut fürs Balancing wär's allerdings nicht
So fängt bereits der Compiler diesen Fehler ab, indem der Code einfach nicht kompiliert. Deswegen sagt man auch, dass man sich durch ein gutes Typsystem bzw. statische Typenprüfung generell eine Menge Unit-Tests spart. So auch hier: Ich brauch hier keinen Test mehr, ob ein Raketenwerfer nicht aus Versehen mit Energie und die Railgun nicht mit Raketen betrieben werden kann
Und wo bleibt der (versprochene?) Weltfrieden?
Apropos seltsam: Aktuell jage ich auch mal wieder einer kleinen Ungereimtheit in specs, dem Testframework, was ich verwende, hinterher. Dort kann ich nämlich bestimmte Klassen (case classes) instanziieren, ohne einen eigentlich benötigten Parameter mitzugeben. Der Code sollte eigentlich nicht kompilieren, tut es aber. Aktuell würde ich auf einen Bug in specs tippen. Wäre nicht der erste, der von mir reportet wird. Und damit trägt Swift Steel indirekt schon jetzt dazu bei, diese Welt ein kleines Stückchen besser zu machen
Das war's jetzt erstmal wieder,
~ Frase
