Wie siehts denn aus mit Animationen im Menü? Also z.B. Mouseovereffekte. Die ändern sich ja auch Zeitabhängig. Gibts dafür ne eigene Clock?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ahoi,

Bin doch ein bisschen von dem zahlreichen Feedback zu der Technik überrascht So revolutionär ist es doch eigentlich gar nicht...

Wie auch immer: Ja, es gibt erstmal nur eine Clock. Es wird nicht jede Animation ihre eigene Clock haben.

Gedacht ist es aktuell so:


und im update guckt der Button dann, wie weit er in der Zeit fortgeschritten ist und setzt sich dann entsprechend unsichtbar oder weniger unsichtbar oder sonstwas

Ich stell mir das ganze vor wie ein sehr dynamisches Video-Projekt, wo man lauter Timelines hat, auf denen man seine Animationen drauf ablegt. Jeder, der von euch mal Videos bearbeitet hat, müsste das eigentlich kennen... Oder wer mal Animationen mit 3DS Max oder Blender oder sonstwas gemacht hat - wobei es bei den Videos ne Ecke deutlicher ist Da hat man auch lauter Zeitspannen mit fest definierten Start- und Endpunkten und es gibt quasi eine "zentrale" Uhr, die das ganze dann Frame für Frame vorrantreibt.

Ich werde die Clock übrigens von Objekt zu Objekt durchreichen, denke ich... Aber dazu muss ich mir noch ein paar Gedanken machen

Vielleicht hat das etwas mehr Klarheit reingebracht. Ansonsten klären sich vielleicht die letzten Fragen, wenn ich den Spaß dann wirklich implementiert habe und die entsprechende Spezifikation (= Unit- und Integrations-Tests) geschrieben habe.

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

Naja... meine Frage zielte darauf ab, was passiert wenn du pausierst (du hast geschrieben, deine Clock steht dann still) und du das Menü bedienen willst. Dann brauchst du dafür schonmal eine 2.Clock.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Achso, du meinst, ich brauch eine zweite Clock, wenn ich während das eigentliche Spiel pausiert ist, noch eine GUI zeichnen möchte, die natürlich noch weiterlaufen soll, während das eigentliche Spiel eingefroren wird (Sei es, weil sie animiert ist oder schlicht Benutzereingaben entgegen nehmen will). Sag das doch *g*

Joa... hmm... interessante Frage... da muss man dann trennen - sind ja auch verschiedene Konzepte, die man nicht miteinander vermischen sollte:

Ich sehe ja das Spiel als eine Art Simulation + Interaktion mit selbiger. Wenn das Spiel pausiert ist, ist natürlich alleine die Simulation pausiert (Davon ist aber das Rendering und sowas total unbeeindruckt). Das bedeutet erstmal nur, dass sich an den Daten vom Spielgeschehen nichts ändert (Da wird auch kein update(...) mehr aufgerufen in der Zeit). Soweit sollte das klar sein.

Dann gibt's aber noch eine weitere Clock, die sich um die Darstellung des gesamten Spiels kümmert. Die muss in der Tat konstant weiterlaufen und darf nie stehenbleiben. Die kümmert sich dann um so interaktiven Kram und sowas...

Wie ich das genau konkret umsetzen werde, weiß ich noch nicht. Das hängt auch n bisschen vom GUI-Framework ab. Vermutlich aber wirklich mit zwei unterschiedlichen Uhren. Vielleicht werden das dann auch zwei Klassen: Eine Clock für die Simulation und eine Clock für das Spiel an sich. Mal schauen

Beantwortet das die Frage? ^^
~ Frase

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

Das, was die Clock kann und macht, hab ich hier spezifiziert. Da wird aber bald umgebaut, um meine mir-vorschwebenden-Gedanken dann mal in die Tat umzusetzen

Die Clock wird von außen weitergedreht. Die entsprechenden Updates dafür liefert mir jME. Mit denen füttere ich dann die Clock und mein Datenmodell wird dann auch nur die Clock verwenden (So der Plan).

Grüße
~ Frase

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

Für die Coverage benutzt du Sprach-eigene Methoden, sehe ich das richtig? Ich hab bei solchen Sachen wie Testcases immer das Problem gehabt: Wie teste ich sinnvoll? Und was mache ich mit Sachen, die eigentlich trivial scheinen? Außerdem gibt es einige Sachen, die echt schwierig zu testen sind. In Java mit JUnit ist es zum Beispiel notwendig, dass Methoden, die man testet public sind.
JUnit gefällt mir auch irgendwie nicht. Man kann sich damit ganz leicht selbst beschummeln. Der ganze Code wird grün angezeigt, man hat eine Coverage von 100% und es ist trotzdem nichts getestet . Ist das bei Scala aufgrund der Einbettung in die Sprache besser gelöst?

Wie beachtest du die Testcases in deinem Design und wie wirkt sich das Ganze auf dein Design aus? Ich denke, je stärker die Kopplung innerhalb des Designs ist, desto schwieriger wird es, das Ganze zu testen. Das würde also zu einem sehr Modul-orientierten Design führen. Wie sieht das bei dir aus?

Neuer Name fuer Yang? Ich find eigentlich der bisherige hatte dem Projekt einen gewissen Charme verliehen =/ Nun, .. man wird sehen


Ich hab jetzt deine IDE nicht so ganz rausgelesen aber zumindest für Javabasierte IDEs kannst du mit Maven als Builttool wirklich einiges erreichen. Grad was deine angepeilte Codeabdeckung im Hinblick auf Tests angeht, bieten die Maven Plugins da einiges an Support

Wir nutzen sowas hier im Projekt (standard Java) auch. Und zwar nehmen wir EMMA

Wenn du jetzt einen Namen hast, hast du vielleicht auch schon konkretere Ideen über das Spiel selbst? Ich hab noch Probleme das Spielziel/Mechanik zu identifizieren.
Wäre schon Cool wenn du ein Spiel mit einer "Toolchain" schreibst, die selbst noch relativ Beta ist.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Woaah ein Antwort-Wald
Mal schauen, ob ich die ganzen Fragen alle beantworten kann, oder nicht doch eine vergesse ^^

Für die Coverage verwende ich cobertura mit eCobertura als Eclipse-Plugin. Das beantwortet vermutlich auch gleich die Frage nach der IDE, die ich verwende Den Autor vom Plugin kenne ich übrigens persönlich. Das ist einer meiner Kollegen
Warum cobertura und nicht emma? Emma kenne ich von früher und es ist ganz bestimmt kein schlechtes Tool. Leider wird es seit Jahren nicht mehr weiterentwickelt, unterstützt keine Branch-Coverage und der Sourcecode ist alles andere als gut geeignet für Forks oder Erweiterungen. Kurz gesagt: Emma ist tot.
Cobertura dagegen unterstützt als ziemlich einzigstes Coverage-Tool Branch-Coverage, die imho wesentlich aussagekräftiger als Line-Coverage ist, aber dazu komme ich gleich noch. Daher: Cobertura.

Cobertura verändert (= instrumentiert) den kompilierten Bytecode und fügt an den interessanten Stellen seine Instrumentierung ein. Wenn der Code nachher ausgeführt wird, sorgen diese neuen Code-Teile dafür, dass die Coverage in eine Datei geschrieben wird. Wie das genau funktioniert, ist etwas versteckt auf der Seite von cobertura beschrieben. Diese Datei wird dann ausgewertet und das Ergebnis dem User präsentiert. Bei mir aktuell in Form von bunten Zeilen in Eclipse; demnächst aber auch als HTML-Report, wo dann alle Informationen enthalten sind.

Heißt auf gut Deutsch: Das ist keine sprach-eigene Lösung und daher auch nicht in Scala eingebettet. Im Gegenteil: Cobertura ist eigentlich für Java. Dadurch, dass Scala aber nach Java-Bytecode kompiliert, geht es prinzipiell auch mit Scala. Ein paar Spracheigenheiten tauchen etwas seltsam im Ergebnis auf (z.B. traits), aber der Großteil funktioniert ganz ordentlich.

Was das "Wie teste ich sinnvoll?" angeht... Dazu gibt's recht viele Papers im Netz und vor allem "Test Driven Development" von Kent Beck. In meinem Fall ist das aber einfach jahrelange Erfahrung, die mir da hilft, das richtig einzuschätzen

Kurz noch zu Java: Inwieweit es Sinn macht, private Methoden explizit zu testen, kann ich für deinen Fall jetzt natürlich nicht sagen. Generell ist das aber via Reflection auch möglich. Dazu empfehle ich uneingeschränkt FEST, das nimmt einem nämlich die ganzen Exceptions und den überflüssigen Code drum herum ab.

Wenn dir JUnit nicht gefällt, Seth, wirf doch mal einen Blick auf TestNG. Das ist imho auf jeden Fall das bessere JUnit

Wegen Beschummeln: Klar, die Coverage ist kein Garant dafür, dass du alles getestet hast. Sie zeigt vor allem, was du vergessen hast. Da man im Normalfall aber keinen Testcode schreibt, der das eben ausgeführte nicht abprüft, reicht diese Info im Normalfall aber

Die Tests wirken sich massiv auf mein Design aus. Alles andere wäre auch sehr fragwürdig. Wenn die Tests keinen Einfluss auf das Programm hätten (im Sinne von: Schwachstellen im Design aufzeigen), wären sie nur halb so sinnvoll.
Rein technisch liegen die Tests bei mir im gleichen Package wie die jeweils zu testende Klasse - allerdings in einem anderen Sourcetree. Damit kann ich im Bedarfsfall Teile vom eigentlichen Code package-private machen und habe somit in den Tests Zugriff darauf, im restlichen Programm aber nicht. Ist also ne Alternative zu Reflection

Was die Kopplung angeht... Ich habe keine dedizierten Module im engeren Sinne. Was soll ein Modul auch genau sein? Mein Code ist allerdings an den wichtigen Stellen getrennt. So ist das unterliegende Datenmodell vollständig von dem Code getrennt, der sich um die Anzeige kümmert. Außerdem sind meine Klassen so aufgebaut, dass man für diese nicht erst noch zig weitere andere Klassen instanziieren muss und die reingeben muss. Das Problem ergab sich da bisher (noch) nicht in einem kritischen Maße. Wenn es allerdings soweit ist, werde ich Teile des Modells wieder umkrempeln müssen. Das ist aber kein Problem, weil ich ja die Tests habe, die mir garantieren, dass der Code danach so funktioniert wie vorher.

Neuer Name für Yang? Jupp Yang ist ja nur ein Arbeitstitel. So toll und witzig der auch ist (Danke hier nochmal an Wilson ^^), so hat er nicht wirklich ne Assoziation zu dem Spiel, was da draus werden soll.

Ich verwende SBT als Build-Tool. Maven hasse ich wie die Pest, ich kann XML nicht ausstehen und Maven neigt dazu, schnell mal das halbe Internet herunterzuladen. Und so klein wie meine Projekt-Definition in SBT würde ich das gleiche nicht in Maven hinbekommen.
SBT hat außerdem das nette Extra, dass ich direkt in der Projekt-Definition (für die Maven-Leute: Das Pendant zur pom.xml) das Build-Tool erweitern kann. Schließlich ist das auch nur Scala-Code (Und deswegen besteht mein Sourcecode auch zu 100% aus Scala).
Fairerweise muss ich dazu sagen, dass mittlerweile Polyglot-Maven am Entstehen ist. Das Interesse daran war aber zumindest auf der JAX 2010, wo einer der Sonatype-Leute die Neuerungen in der neuen Maven-Version vorgestellt hat, ziemlich gering. Da haben sich auf die Frage, ob man das POM auch ohne XML machen können soll, neben mir nur zwei andere gemeldet (Und in dem Saal waren geschätzt ~200 Leute). Ist aber vermutlich nicht repräsentativ, der Sonatype-Fuzzy war nämlich auch von dem Ergebnis überrascht

Wie auch immer: Maven ist keine Option für mich. Mit SBT bekomme ich sehr sehr viele Scala-Features direkt in den Build. Mit einem einzigen Befehl bekomme ich z.B. einen Interpreter, der schon alle Klassen aus meinem Spiel importiert hat und wo ich direkt was ausprobieren kann.

Liebe Grüße, ich hoffe, mein Post ist nicht zu lang geworden ^^
~ Frase

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

Mir gefällt der neue Name.
Mit der Abkürzung meinst du wahrscheinlich etwas historisch belastetes.

Um aber den Bezug zu Yang nicht gänzlich zu verlieren (für die Nostalgiker unter uns), kannst du ja trotzdem noch ein paar Resourcen oder Klassen mit dem alten Namen versehen. Wäre nicht das erste Spiel, dass intern noch viele Verweise auf den ursprünglichen Arbeitstitel hat. Würde auch die Coolness der Namenskonvention enorm steigern.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Freut mich, dass er gefällt
Zumindest die Packages werden erstmal noch das yang im Namen behalten. Namenskonventionen in Form von "Jede Klasse mit irgendwas prefixen" hab' ich sowieso nicht, von daher stellt sich das Problem nicht so

~ Frase

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

Ein Easteregg, das auf den Alten Namen hinweist, wär doch wirklich cool ^^

Ich finde den neuen Namen super. Bin gespannt, wies weitergeht

ja der name ist echt ne gute kreation! Ich hoffe da gibts bald wieder ein paar schöne Bilder vom Projekt

_________________
Klar Soweit?

Ohne unvorbereitet mosern zu wollen:

SwiftSteel hat eher ungünstige initialien. Könnte im Logobau etwas ärgerlich enden... ansonsten aber gut

_________________
FinnO