Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 22:21

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
 Betreff des Beitrags: Re: Swift Steel aka Yang
BeitragVerfasst: So Aug 29, 2010 21:32 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
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
}

(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();
    }
}

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

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel aka Yang
BeitragVerfasst: So Sep 19, 2010 21:25 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Ahoi,

kleines Update: In der nächsten Zeit werde ich vermutlich öfter dazu kommen, was am Swift weiterzumachen. Vielleicht gibt's dann auch wieder neue Screenshots. Mal schauen ;)

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel aka Yang
BeitragVerfasst: Do Nov 18, 2010 18:09 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Moin,

entgegen der letzten Aussage kam ich seitdem quasi gar nicht mehr dazu, wieder was zu machen. Das RL in Form der Schule fordert doch seinen zeitlichen Tribut.
Ein bisschen was neues gibt's jedoch:

Ein neues Zuhause
Ich steige gerade von git auf hg (mercurial) um, da dieses von der Syntax her und vom Funktionsumpfang deutlich einfacher gehalten ist. Bei git passiert es doch relativ leicht, einen neuen branch anzulegen, obwohl man sich eigentlich nur die Liste der bereits vorhandenen branches anzeigen lassen wollte (u.Ä. mehr). Mir reicht auch der Funktionsumfang von mercurial völlig aus.
SwiftSteel findet man daher nun bei bitbucket. Das ist quasi github in grün ;) Das Repository bei git existiert noch, wird aber bald gelöscht. Zwar muss man bei bitbucket auf ein paar hübsche Graphen verzichten, aber im Zweifelsfall kommt Usability immernoch vor Fancyness. Und da gewinnt hg haushoch.
Bei dem Umstieg bleibt übrigens die komplette Versionshistorie erhalten. Zwischen mercurial und git kann man sehr einfach hin- und herkonvertieren.

Kleiner Ableger
Anlässlich der jungen Diskussion um alternative Eingabemethoden hab' ich mich dazu entschlossen, meinen Code, mit dem man das Playstation 3 Gamepad (Den SixAxis Controller, und bald auch den Navigation Controller, da der ganz ähnlich arbeitet) unter Linux ansteuern kann, ebenfalls bei bitbucket hochzuladen. Ursprünglich wollte ich das vorher nach Scala portieren, aufhübschen und komplettieren, aber das mach ich dann halt erst im Nachhinein :)
Die Library (die aktuell noch keine ist, sondern lediglich ne Demo-Anwendung) hört auf den Namen JSixAxis (wie kreativ) und ist ebenfalls bei bitbucket zu finden.

Was hat das mit Swift Steel zu tun?
Später sollen die Hovertanks u.A. durch eben das Gamepad steuerbar sein. Ich hab's da auf die Neigungssensoren abgesehen. Wer das Spiel Flowers auf der PS3 kennt, weiß, wie genial so eine Steuerung sein kann.
Und da diese Anbindung an und für sich recht unkompliziert ist, hab ich sie nun auch getrennt zur Verfügung gestellt. Macht relativ wenig Mehraufwand und so haben noch andere Entwickler was davon.

~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel aka Yang
BeitragVerfasst: Di Nov 23, 2010 15:56 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Hi,

Umstieg ist vollzogen, gerade habe ich das repository bei github gekillt.
Falls es wen interessiert, hier mal die Schritte zum Konvertieren eines git-Repositories:

1. Convert-Extension
in der .hgrc (Der Mercurial-Config) sollte folgendes stehen:
Code:
[extensions]
convert =

2. Konvertieren
In das Verzeichnis gehen, in dem das git-Repository liegt. Dann:
Code:
hg convert --datesort <alt> <neu>

2b. (Bonus) Alte branches rauswerfen
Dazu aktiviert man die Extension "mq" (Wie oben)(Alles was bei mercurial die history verändert, läuft über mq), und macht folgendes:
Code:
hg strip <revision>

Dann wird diese Revision und alles, was an ihr dranhängt, gekillt.
War bei mir "nötig", weil man bei github (anders als bei bitbucket) die Website in Form eines Branches (namens "gh-pages") im Repository erstellt. Bei bitbucket macht man dafür ein eigenes repository.

Cya,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel aka Yang
BeitragVerfasst: Mi Mär 23, 2011 22:42 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Ahoi,

ein spontaner Denkanfall bewog mich dazu, mit einem kleinen Codeschnippsel zu erläutern, wie ich mir die Simulation in SwiftSteel vorstelle. Da unser tolles Syntaxhighlighting ja so gut geht (*hüstel*) hab ich mal einen Screenshot angehängt. Der ist einfach bunter :)
Dateianhang:
meowtemp.png
meowtemp.png [ 15.72 KiB | 7633-mal betrachtet ]

Einige von euch werden vllt. eine gewisse Ähnlichkeit zu Funktionen aus der Mathematik feststellen. Man braucht "position" nur "f" nennen und aus dem "t" ein "x" machen. Dann hat man das, was man in Mathe eine abschnittsweise definierte Funktion nennt. Die einzelnen Abschnitte sind die Zeitpunkte, in denen sich die Bewegung des jeweiligen Körpers geändert hat. In diesem Beispiel könnte der Spieler zum Zeitpunkt t = 0.2 beschlossen haben, in eine andere Richtung zu fliegen (Erkennbar an dem Vector(0.4, 0.4, 0) statt dem vorigen Vector(0.6, 0, 0)).
Feindbeschuss wäre aber auch denkbar. Wenn der Spieler z.B. von einer Rakete getroffen wird.

Nun, jedenfalls fällt am Ende eben eine solche abschnittsweise definierte Funktion heraus. Ultimativ liefert diese dann nicht nur die Position, sondern die gesamte Spielwelt, eingefroren zu genau dem Zeitpunkt t (den die Funktion dann bekommt), aber weiterhin abhängig von der Zeit.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel
BeitragVerfasst: So Okt 23, 2011 12:54 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Ahoi,

pünktlich zum Studium und diverser eher unspektakulärer Grundlagen-Vorlesungen habe ich wieder angefangen, an Swift Steel weiter zu machen. Nach so einer langen Zeit Inaktivität stand erstmal das Aufpolieren der Infrastruktur an. Ich verwende nun sbt 0.11.x, Scala 2.9.1 und steige demnächst auf die neue jME 3 Engine um, die komplett shaderbasiert ist und richtig geniales Wasser hat.
In diesem Zuge habe ich auch alle Reste von "Yang" aus dem Code entfernt. Die Packages beginnen nun alle mit org.swiftsteel. Außerdem werde ich, sobald ich auf jME 3 umgestellt habe, weder lwjgl noch jME3 mehr ausliefern. Das holt sich der Build dann automatisch aus dem Internet. Dadurch wird u.A. das Repository kleiner.
Bei dem ganzen Umgestalten habe ich mich mal wieder am Open-Source-Geist beteiligt und u.A. die Dokumentation von sbt ergänzt sowie einfach nur mal konstruktive Kritik zum lwjgl-Plugin für sbt, was ich verwende, geäußert, die auch gleich in einem "Hey great idea, I'll look into implementing this" resultiert hat :)

Neue Screenshots gibt es, sobald ich auf jME 3 umgestellt habe. Dann gibt's hoffentlich genau so hübsches Wasser wie im Showcase-Video von jME3.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Swift Steel
BeitragVerfasst: Di Okt 25, 2011 16:38 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Ahoi,

mittlerweile unterstützt der Build nun auch Code Coverage. Will heißen, man sieht, welche teile vom Sourcecode durch die Tests abgetestet werden. Habe da auch prompt eine Klasse gefunden, die noch nicht gecovered war und beim covern selbiger bin ich auf 2 Bugs gestoßen. Unit-Tests ftw!

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 26 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.123s | 19 Queries | GZIP : On ]