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

Aktuelle Zeit: Fr Okt 19, 2018 13:52

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



Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Swift Steel
BeitragVerfasst: Mi Dez 23, 2009 20:22 
Offline
Forenkatze
Benutzeravatar

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

ich wollte schon länger mal wieder was mit OpenGL machen und hab mich entschlossen, einen kleinen Clon von einem Spiel namens Thunder Brigade zu basteln.

Es geht dabei um folgendes: (Man möge mir die Faulheit, das ganze wieder ins Deutsche zu übersetzen an dieser Stelle nachsehen ^_^)
Frase hat geschrieben:
Settled in the remote future, yang is an action-packed, interactive 3D game making heavy use of hover tanks. You are the pilot of one well-armed flying tank finding yourself in the everlasting war between three rivaling corporations. While they do leech for the reign about six planetes, your only wish is to live your old, peaceful live you left behind again.


Es geht also wieder mal darum, die Welt zu retten. Das ist natürlich so an sich nichts sonderlich neues und meist auch nichts, was man alleine auf die Beine stellt. Daher findet man sich in den meisten Missionen - von denen ich noch nicht sagen kann, wie viele ich davon einbauen werde - an der Seite eines oder mehrerer Flügelmänner wieder. Das sind KI-gesteuerte Hovertanks, denen man grundlegende Befehle geben kann. Dinge wie: Sei aggressiv, fliege zu Punkt XY, warte hier...
Die meiste Zeit werden diese einfach in Formation neben einem herfliegen. Sollte sich jedoch ein Gegner zeigen (Auf dem Radar), werden die Flügelmänner (je nach befohlenem Verhalten) anfangen, den Gegner zu verfolgen und das Feuer eröffnen.
Das mit dem Radar ist aber freilich so eine Sache. Denn es wird ein aktives Radar und ein passives geben (Von denen - man ahnt es - natürlich nur eines gleichzeitig aktiv sein kann). Das passive Radar verlässt sich darauf, die aktiven Radarimpulse der Gegner aufzuschnappen und sie dadurch zu orten.
Das aktive Radar (das kann man sich jetzt auch denken...) scanned dagegen selbst die Umgebung, hat eine etwas größere Reichweite und erlaubt vor allem das Nutzen der Lenkraketen.
Ja richtig, Lenkraketen. Wäre ja langweilig, wenn man zwar einen flotten Schwebepanzer unterm Hintern hätte, aber nur mit Wasserpistolen bewaffnet dem Gegner zu Leibe rücken könnte. Je nach Schwierigkeitsgrad hat man davon entweder begrenzt viele oder unendlich viele und kann sie nach Herzens Lust und Laune verballern. Sinnvollerweise nimmt man sich als Zielscheibe einen gegnerischen Hovertank und zerlegt so (oder mit einer der anderen Waffen) fröhlich seinen Schild.
Geht man dabei einigermaßen gewieft vor, wird man sich gezielt Schwachpunkte an der gegnerischen Panzerung heraussuchen und diese attackieren, um etwas Munition zu sparen.
Komm ich noch kurz zu den zur Verfügung stehenden Waffen, denn nur mit Lenkraketen ausgerüstet zu sein, ist zwar irgendwie cool, wird auf Dauer dann aber doch langweilig. So wird es auch noch ungelenkte Raketen, eine Railgun (Die Standard-Knarre, die sich selbstständig wieder auflädt) und einen Ziel-Laser geben, mit dem man ein Ziel markieren kann, das von einem freundlichen, stationären Raketenwerfer dann bombardiert wird (Sofern die dabei abgeschossene Langstreckenrakete nicht vom feindlichen Radar entdeckt und zerlegt wird).
Die Railgun lädt sich, wie oben erwähnt, selbstständig auf. Der Kernreaktor, der in jedem Hovertank integriert ist, stellt die dazu nötige Energie zur Verfügung. Ist das Schild beschädigt, wird ein Teil dieser Energie auch dafür hergenommen, die Panzerung soweit möglich zu reparieren. Das geht natürlich nur bis zu einem gewissen Punkt, ab dem die Panzerung irreperabel beschädigt ist. Wenn das der Fall sein sollte, ist eine schnelle Flucht anzuraten, um nicht als Kanonenfutter zu enden ;)
Nebst schwebenden Panzern gibt es auch ein paar Gebäude, die einen in der Mission unterstützen bzw. von der Erfüllung der Mission abzuhalten versuchen. Mit letzteren sind keine Vergnügungsparks o.Ä. gemeint, sondern schlicht die gegnerischen Verteidigungsanlagen. Denn auch dem Gegner ist natürlich daran gelegen, nicht so einfach von der Bildfläche radiert zu werden und so setzt er alles daran, selbiges zu verhindern.
Dazu hat er u.A. Radarstationen (Die für das Abfangen der Langstreckenraketen verantwortlich sind), Railgun-Türme (Ihr ahnt schon, dass das keine Aussichtsplattformen sind), Hovertank-Depots, Kommandozentralen, Raketenwerfer, etc... Mal schauen, wie viele tatsächlich in das fertige Spiel wandern, aber die genannten sollten auf jeden Fall dabei sein :)
Einem selbst steht je nach Mission nebst diversen Gebäuden auch ein eigenes Panzerdepot zur Verfügung. Das wird aber vor allem im Multiplayermodus interessant: Dort kann man nämlich seinen Hovertank parken und in einen anderen wechseln.
Ob der Multiplayermodus es in das fertige Spiel schafft ist auch etwas, was noch in den Sternen steht. Ich hätte ihn natürlich sehr gerne drin, aber Multiplayer ist etwas, was doch einigermaßen tricky unter Kontrolle zu bekommen ist. Und - wie jedes Feature - will auch das erstmal mit der nötigen Zeit implementiert werden.

Soo... Soviel zum kleinen Überblick über das Spiel selbst :)

Einen Meinungsthread gibt es mittlerweile auch! *g*

Projektstatus

Das Spiel selbst ist im Moment pre-alpha und ich bin aktuell am Unterbau beschäftigt. Sprich: Sehen tut man noch nicht wirklich viel außer ein paar Testrenderern, die es aber allesamt nicht verdienen, hier verlinkt zu werden.


Lizenz

Neue BSD-Lizenz.


Technik, Sprache & Bibliotheken

Als Sprache kommt die recht neue Sprache Scala zum Einsatz. Sie wird auf der Java Virtual Machine ausgeführt und zu 100% Java Bytecode übersetzt und erlaubt u.A. das Mischen von funktionaler und objekt-orientierter Programmierung. Damit einhergehend werde ich die einzelnen Klassen weitestgehend immutable machen, was große Vorteile in Bezug auf Multi-Threading und ähnliche Scherze bietet :)
Denjenigen, denen funktionale Programmierung fremd ist oder der Überblick auf der Scala Website zu umfangreich ist, sei der entsprechende Wikipedia-Artikel ans Herz gelegt, der genau diesen Sprachüberblick "Introducing Scala" nochmal kurz auf Deutsch zusammenfasst. Ich denke, das ist sinnvoller als wenn ich hier jetzt großartig erzähle, was Scala ist ohne zu wissen, welchen Hintergrund der geneigte Leser (= Du!) so mitbringt :)

Im Gegensatz zu früher habe ich auch erstmal nicht mehr vor eine komplett eigene Spiele-Engine aus dem Boden zu stampfen: Denn Projekte sind nur gut, wenn sie auch mal fertig werden. Daher verwende ich die JMonkey Engine, eine ebenfalls open source Game-Engine.

Dem nicht genug, werde ich die Implementierung so weit es sinnvoll ist durch automatisierte Integrations- bzw. Unittests absichern. Die Tests dazu schreibe ich mit specs, einem Behaviour driven development Framework (kurz: BDD). Für die, denen sowas gar nichts sagt... Das sieht dann z.B. so aus:

Code:
object ClockSpec extends Specification {
  "A new clock" should {
    "start with 0" in {
      new Clock().time mustEqual 0
    }
  }
  "Advancing the clock" should {
    "do what it's supposed to do" in {
      val clock = new Clock
      clock advanceBy 42
      clock.time mustEqual 42
    }

    "only work for positive values" in {
      val clock = new Clock
      (clock advanceBy -123) must throwA[IllegalArgumentException]
    }
    // ...
  }
}

Und das macht - wie das ganze Projekt - ne Menge Spaß, Tests so "informell" zu schreiben :)
(Der Code da oben ist übrigens 100% Scala und stammt aus meiner Testspezifikation zur "Clock" meines Spiels)

Als Build-Tool kommt sbt (Simple build tool und nicht Scala Build Tool) zum Einsatz, das seinerseits Scalas Anspruch, eine "skalierbare" Sprache zu sein, wunderbar demonstriert :) Das Buildfile selbst ist nämlich ebenfalls in Scala geschrieben (So wie sbt selbst natürlich auch).

Ich hatte vorher buildr im Einsatz, was auch nicht übel war. Allerdings waren die dort unterstützen Scala-Versionen nicht mehr so super aktuell und vor allem läuft buildr auf meinem Fedora nicht so toll (Das zickt sich dort mit 64 Bit Java vs. 32 Bit Ruby oder so...). Davon abgesehen sind meine ruby-Kenntnisse nicht so prall ;)

Vorteil von sbt ist zudem, dass man dort ganz einfach in eine Konsole kommt, in der die ganzen Klassen vom Projekt schon richtig geladen sind. d.H. man kann einfach mal schnell was innerhalb seines Projektes ausprobieren :)

Wo finde ich es?

Gehostet ist das Projekt mitsamt seiner Projektwebsite auf github.
Dort werde ich dann auch, wenn es irgendwann mal was gibt, was man sehen kann, mehr oder weniger regelmäßig Releases hochladen.

Bis dahin gibt es nur den direkten Link, der die jeweils aktuellste Version aus dem Repository nimmt: Entweder als ZIP oder als tar.gz. Die Links gibt's aber auch nochmal auf der Homepage :)


Bilder!

Da ich, wie gesagt, im Moment am Unterbau bastel, gibt es noch nicht so wahnsinnig viel zu sehen. Hier ist aber dennoch der obligatorische Screenshot:
Dateianhang:
Dateikommentar: Screenshot der Modultests :P
spec.png
spec.png [ 15.31 KiB | 9328-mal betrachtet ]


Grüße,
~ Frase

€dit: Bild anders positioniert und Link zum Meinungsthread hinzugefügt.
€dit 2: Build-Tool eingefügt

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


Zuletzt geändert von Frase am So Okt 23, 2011 12:43, insgesamt 5-mal geändert.
Lizenz-Informationen ergänzt


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Fr Jan 29, 2010 23:02 
Offline
Forenkatze
Benutzeravatar

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

sollte es jemandem aufgefallen sein, dass es seitens Yang grad irgendwie wenig Aktivität gibt, hier ne kleine Erklärung:
Wie ich ja schon anmerkte, kommt bald Scala 2.8 und damit u.A. bessere IDE Unterstützung. Bis dahin werd' ich die Arbeiten an Yang bewusst etwas stiefmütterlich halten ;) Die kleine Pause ist also durchaus beabsichtigt.

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: Yang - Yet another nameless game
BeitragVerfasst: Do Feb 18, 2010 23:36 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1900
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Pause beendet!

Wie übrigens diese kleine Grafik hier zeigt, ist der Traffic von der Yang Projekteseite zufälligerweise genau in dem Zeitraum, wo ich hier die Projektvorstellung gemacht hab, sprunghaft angestiegen:
Bild

Zurück zum wichtigen: Habe den Code jetzt soweit umgezogen, dass er mit 2.8 kompiliert, es sind noch ein paar wenige deprecation warnings drin, die werd ich aber auch noch beheben und dann wird weiter implementiert :)

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: Yang - Yet another nameless game
BeitragVerfasst: Fr Feb 19, 2010 19:35 
Offline
Forenkatze
Benutzeravatar

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

wie im Meinungsthread gewünscht gibt's jetzt eine Beschreibung von der Spielidee selbst. Die hab' ich in den Anfangspost verfrachtet, da sie dort imho auch am besten aufgehoben ist (Auch wenn der jetzt freilich etwas arg groß geraten ist...).

Und damit dieser Post nicht so verloren dasteht, gibt es noch etwas technische Infos zur geplanten Umsetzung...

Da das hier ja vornehmlich ein Forum ist, was sich um Graphikprogrammierung im weiteren Sinne dreht, werde ich noch ein paar Wörtchen zu selbiger verlieren:

Das ursprüngliche Spiel, von welchem ich einen Clon zu schreiben in Begriff bin, hatte für das Rendering der Landschaft tatsächlich eine hausgebackene Voxel-Engine eingesetzt. Das hatte zur Folge, dass die Landschaft... nun... einfach extrem toll aussah. Gut - die Auflösung vom Spiel selbst war jetzt nicht so wahnsinnig der Brüller, aber vom Detailgrad war die Landschaft einfach super. Ich denke, jeder, der mal ein Voxel-gerendertes Terrain gesehen hat, weiß was ich meine :)
Das werde ich anders machen, so sexy ich Voxelgrafik auch finde. Aber eine eigene Voxel-Engine aus dem Boden zu stampfen, die dann noch einigermaßen performant... nein danke *g*
Stattdessen wird das Terrain ganz altmodisch in Quadtrees verpackt und ganz langweilig dreiecksbasiert gerendert. Dabei kommt Multitexturing + Detailtextures zum Einsatz.
So in der Art werden auch die beweglichen Objekte dargestellt. Vornehmlich also die Schwebepanzer. Und auch die Gebäude (Wobei die freilich eher unbeweglicherer Natur sind): Multitexturing mit einer Detailtextur.
Beleuchtet werden wird das ganze mit Per-Pixel-Lightning (aka bumpmapping) über GLSL. Damit werd ich jetzt sicher niemandem hinter dem Sofa hervorlocken, da es ein doch recht abgedroschener alter Hut ist, aber imho sieht Per-Pixel Lightning mit Bumpmaps einfach zu super aus, um es wegzulassen :)
Wenn es die Zeit zulässt, wird es optional auch eine reine OpenGL-Licht-basierte Beleuchtung geben. Dann halt nur Per-Vertex und ohne Shader für die Fraktion, die eher schwächere Maschinen ihr eigen nennen.
Entstehen werden die Models vermutlich in Blender, ich werd mir dazu auch Sketchup angucken. Aber letztendlich besticht Blender einfach durch seine Exportmöglichkeiten und den niedrigen "Price-Tag" :)
(Und ja, ich weiß, die Bedienung soll göttlich sein, aber da ist es vielleicht wie mit allem Göttlichen: Wenn man nicht dran glaubt, ist's auch nicht wahr... Und ich für meinen Teil glaub' nicht dran ^^).
Exportiert werden sie dann in das jME-Binary Format. Das unterstützt allen möglichen Schnickschnack + Animationen. Und dafür gibt's bereits einen Exporter für Blender. Da spar ich mir also auch nochmal den Code für Ex- und Importer.
Was Animationen angeht: Da bin ich natürlich fein raus. Ich hab' quasi nur Rigid Body Animations, da ein Schwebepanzer i.d.R. relativ wenige bewegliche und verschluckbare Kleinteile hat und Gebäude normalerweise auch nicht dazu tendieren, sich in der Gegend herumzubewegen.
Als GUI werd' ich die Themebale Widget Library verwenden. Die hat von den verfügbaren Java-GUIs den besten Eindruck gemacht, ist - wie der Name bereits suggeriert - skinnbar und hat als Bonus sogar ne eigene Scala-API :)
Ganz generell wird das ganze ja mit jME gerendert, einer Scenegraph-basierten OpenGL Game-Engine (Wie im ersten Post erwähnt). Die bietet mir auch bereits Abstraktionen für Controller (Nein, ich mein' nicht die Dinger, die man in den Pfoten hat und an Konsolen anschließt). Mit diesen Controllern (Um mal das Kind beim Namen zu nennen: ThirdPersonController u.Ä.) lassen sich die Models in der Szene steuern. Da muss ich aber noch sehen, inwieweit die verwertbar sind, oder ob ich den Teil nicht selbst mache.

Ich hoffe, ich konnte damit ein paar offene Fragen zum technischen Unterbau beantworten ^^.

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: Yang - Yet another nameless game
BeitragVerfasst: So Apr 25, 2010 18:41 
Offline
Forenkatze
Benutzeravatar

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

wie versprochen (hö?) hab ich... vorwiegend unter der Haube was gemacht ;) Wer auf Screenshots aus ist, wird trotzdem nicht enttäuscht (naja vielleicht doch) und darf gleich ans Ende von diesem Post springen, wo selbiger anhängt.
Für die paar neugierigen, die wissen möchten, wie der entstanden ist: Ich hab Yang gestartet, die Kamera ausgerichtet und F1 gedrückt. Fertig :p
Ernst beiseite: Sehr viel Hokuspokus steckt nicht dahinter, die Arbeit nimmt mir JME (JMonkeyEngine) eigentlich komplett ab. Ich hab lediglich ein paar Wrapper außen herum gemacht, damit sich das ganze natlos in meine Infrastruktur einfügt.
Das Terrain wird in einem Quadtree verwaltet (Die eingeblendeten weißen Linien), die Normalen sind geglättet (Die rot eingezeichneten Linien) und beleuchtet wird der Spaß auch schon (Rest vom Bild, kommt aber dank Wireframe-Darstellung nicht so wirklich gut zum Tragen). Der optisch ansprechende Hügel entstammt einer HillHeightMap, die mir von jME zur Verfügung gestellt wird. Alles in allem einigermaßen unspannend ;)

Grüße
~ Frase


Dateianhänge:
Dateikommentar: Zur Abwechslung mal ein Photo von meinem letzten Urlaub auf dem Mond...
terrain_3.png
terrain_3.png [ 129.21 KiB | 8942-mal betrachtet ]
Dateikommentar: Ain't it a beauty?
terrain_2.png
terrain_2.png [ 73.36 KiB | 8946-mal betrachtet ]

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Mo Apr 26, 2010 20:22 
Offline
Forenkatze
Benutzeravatar

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

das sprichwörtliche Spiel mit dem Feuer ist ja bekanntlich nicht ungefährlich und drum hab ich mich erstmal für seine kühlere Variante entschieden und damit ein wenig herumgespielt. Was rausgekommen ist, hab ich mal angehängt. Wäre das Terrain texturiert und gäbe es nen Himmel, der nach was aussehen würde, wär's vielleicht sogar hübsch - so bleibt es mehr ein proof-of-concept oder so ;)

Grüße
~ Frase


Dateianhänge:
terrain_water.png
terrain_water.png [ 70.32 KiB | 8912-mal betrachtet ]
terrain_water1.png
terrain_water1.png [ 75.49 KiB | 8912-mal betrachtet ]

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Di Apr 27, 2010 19:28 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1900
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Shader sind toll :)


Dateianhänge:
terrain_4.png
terrain_4.png [ 217.35 KiB | 8870-mal betrachtet ]
terrain_5.png
terrain_5.png [ 233.42 KiB | 8870-mal betrachtet ]

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Sa Mai 01, 2010 15:53 
Offline
Forenkatze
Benutzeravatar

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

mal wieder was zum Anfüttern...

Grüße
~ Frase


Dateianhänge:
terrain_6_scaled.png
terrain_6_scaled.png [ 591.76 KiB | 8798-mal betrachtet ]
terrain_7.png
terrain_7.png [ 506.3 KiB | 8798-mal betrachtet ]
terrain_8.png
terrain_8.png [ 649.39 KiB | 8798-mal betrachtet ]

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: So Mai 02, 2010 12:57 
Offline
Forenkatze
Benutzeravatar

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

heute gibt's statt bunter Bilder mal neue Info :)
Ein weiteres Feature, was ich mir gut in Yang vorstellen könnte (= was also gute Chancen auf ne Implementierung hat), ist situationsabhängige Musik.
Aktuell stell ich mir das so vor, dass, wenn die feindliche KI sich auf den Spieler aufschaltet und der Spieler diese KI im Blickfeld hat, sich die Musik ändert - mit einem einfachen Crossfade z.B.. Denke, das gibt dem Ganzen nochmal etwas mehr Dynamik :)

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: Yang - Yet another nameless game
BeitragVerfasst: So Mai 16, 2010 18:54 
Offline
Forenkatze
Benutzeravatar

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

aktuell bastel ich wieder am Unterboden von Yang. Will heißen: Am Datenmodell. Da mein Datenmodell unveränderlich ist (Zu Neudeutsch also: immutable datamodel), erlaubt es mir ein paar Extras, die anderweitig relativ schwierig einzubauen wären.
Eines dieser Extras wäre beispielsweise eine Demo-Funktion, bei der Spiele aufgezeichnet und später wiedergegeben werden können. Das sollte, was das Datenmodell angeht, relativ leicht zu implementieren sein, da ich das gesamte Spiel als "Simulation" aufbaue. Für die Mathematiker: Im Idealfall kommt am Ende eine Funktion raus, abhängig von t (= Der Zeit) und solchen Details wie dem Input (Also wenn der Spieler irgendwelche Tasten drückt). Den Input vernachlässige ich jetzt aber mal, der sollte sich (hoffentlich) als nicht so schwierig herausstellen ;)

Durch das immutable datamodel habe ich in Yang quasi Snapshots von der Spielumgebung. Ich habe also immer das komplette Spiel zu einem bestimmten Zeitpunkt im Speicher. Im Normalfall wird es genau einen dieser Snapshots pro Frame geben. Ich will das mal an einem kurzen Codebeispiel verdeutlichen:
Code:
class Simulation {
  private var clock = new Clock
 
  private var environment: Environment = _
 
  def advanceBy(time: Float) = {
    clock advanceBy time
    environment = environment advancedBy time
  }
}


Die Klasse befindet sich gerade in der Entstehungsphase, man möge mir also die aktuell ungenutzte "clock" verzeihen ;)
Wichtig hier ist die Zeile "environment = environment advancedBy time". Oder für die, die mit dieser Scala-Syntax nicht so viel anzufangen wissen: "environment = environment.advancedBy(time)".
Hier wird dann unter der Haube das komplette Spielfeld wieder neu zusammengestöpselt und es fällt ein neuer Objektgraph (anderer Name für: Eine Klasse hat Beziehungen zu anderen Klassen und die wiederum zu weiteren Klassen usw.) hinten raus, der das Spielfeld zu einem anderen Zeitpunkt enthält.

Sollten jetzt die ersten anfangen aufzuschreien "Aber das Spielfeld ist doch rießig, da ist doch die ganze Landschaft drin und alles - das braucht doch ewig zum Kopieren bei jedem Frame" - stimmt, würde es ;) Aber da das Spielfeld selbst ebenfalls immutable ist, kann ich die Referenz darauf einfach in das neue Spielfeld mitgeben. Da wird also lediglich der Pointer kopiert und das sind nur ein paar Byte. Der alte Snapshot vom vergangenen Frame dümpelt dann noch kurz im Speicher herum, irgendwann springt dann der Garbage Collector an, weil der Snapshot nirgends mehr referenziert wird und räumt ihn auf.

Um das ganze einigermaßen einfach zu halten, hab ich den Spaß etwas eingeschränkt: So erlaube ich nur, in die Zukunft zu schreiten und nicht stehenzubleiben. Der Versuch, um 0 oder einen negativen Betrag in der Zeit fortzuschreiten wird daher mit einer Exception quittiert.

Zurück zum Ausgangsproblem, der Demo-Funktion: Dafür müsste ich mir nun einfach jeden Snapshopt merken und auf Platte speichern. Sei es ganz faul bei jedem Frame oder in festen Intervallen (so wie man es bei Physik-Engines auch macht - da läuft ja meist auch ein Thread nebenher, der z.B. alle 60 ms die Physik updated). Wenn die Demo dann abgespielt wird, muss man nur noch ganz dumm jeden dieser Snapshopts rendern (So wie das im normalen Spiel auch der Fall ist). Das einzig problematische ist nur das Speichern: Hier darf ich logischerweise nur die "Diffs" speichern - also das, was sich zwischen den Snapshopts wirklich geändert hat - ansonsten käme da ja eine rießen Datei raus ;) Aber das sollte auch gehen - mein erster Ansatz wird sein, die hauseigene Serialisierung von Java dazu herzunehmen und da den kompletten Objektgraphen einfach abzubilden. Das müsste eigentlich ganz gut funktionieren und würde mir die "Diffs" erhalten.

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: Yang - Yet another nameless game
BeitragVerfasst: Fr Jun 18, 2010 20:11 
Offline
Forenkatze
Benutzeravatar

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

ich werd' demnächst wieder mal an Yang weitermachen. Als kleines Schmankerl hab ich mein Projekt mal bei ohloh.net registriert.
Wer Ohloh.net nicht kennt: Das scannt regelmäßig Sourcecode von Opensource-Projekten und analysiert ihn. Dabei fallen so interessante Metriken raus wie: Sind die Lizenzen miteinander kompatibel, wie viel Prozent des Codes sind dokumentiert (Und wie sieht das bei anderen Projekten mit der gleichen Programmiersprache aus), wie viel LOC (Codezeilen) hat das Projekt, wie viele Autoren, wie lange läuft das Projekt bereits, etc.
Die Dinger kann man dann in HTML-Form und sonstigen Formen verwursten - ein bisschen was davon findet sich ab heute auch in meiner Signatur ;)

Auch nett: Anhand der LOC und einem Durchschnittsgehalt eines Software-Entwicklers (vermutlich in Amerika) schätzt Ohloh ab, welchen Wert das Projekt hätte, wäre es in einem Unternehmen entstanden. Yang kostet demnach aktuell über 18.000$ mit seinem 1.600 Zeilen Code ;)

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: Yang - Yet another nameless game
BeitragVerfasst: Fr Jun 18, 2010 21:09 
Offline
Forenkatze
Benutzeravatar

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

ich dachte mir, ich tue euch mal meine neusten Erkenntnisse in Sachen Datenmodell kund. Es geht um Animationen und alles, was nen zeitlichen Verlauf hat:

Klassischerweise löst man sowas in Spielen mit Timebased Movement ja so, dass alle Objekte ne update(timeSinceLastFrame) Methode haben (oder sowas in der Art), die einmal pro Frame mit der Zeit, die seit dem letzten Frame vergangen ist, aufgerufen wird.
Das ist einfach und schnell gecodet, ist aber mitunter nicht die eleganteste Lösung:

Man stelle sich einen Pfad vor... von A nach B (meinetwegen eine gerade Linie) und auf der befindet sich ein Punkt.
Der soll binnen zwei Sekunden von A nach B wandern (linear interpoliert).
Das könnte beispielsweise ein Partikelsystem sein (Funken), das sich entlang einer Lunte bewegt, die langsam abbrennt.

Wenn man das mit der traditionellen Methode modelliert, addiert man laufend Floats auf Floats, hat dadurch Rundungsungenauigkeiten (und bei längeren Animationen kann das schon was ausmachen), man weiß erstmal nicht genau wie viel Prozent des Weges man zurückgelegt hat und damit nicht genau, an welcher Stelle man ist.

Klar, geht alles, aber der Weißheit letzter Schluss ist es nicht für diese Art von Problemen. Im Idealfall möchte man ja etwas haben, was ähnlich einer mathematischen Funktion (z.B. Sinus) einem ganz simpel für einen bestimmten, absoluten Zeitpunkt einen Wert zurückliefert.

Und genau darauf ist der Ansatz ausgelegt, den ich seit heute verstärkt verfolge:
Eine Animation hat zu aller erst eine Zeitspanne (In diesem Beispiel 2 Sekunden). Zeitspannen sind definiert durch ein Anfang und (welch Überraschung...) ein Ende. Dadurch, dass die Animation weiß, wann sie angefangen hat und wie lang sie insgesamt dauern muss, kann sie mit "einem einfachen Blick auf die Uhr" immer genau feststellen, wie weit sie schon ist. Diese Uhr heißt bei Yang tatsächlich schlicht und ergreifend Clock. Deren Spezifikation gab's ja schon im Eröffnungsthread zu begutachten ;)
Die Uhr weiß immer genau, wie spät es ist und es ist auch nur diese eine Uhr, die mitverfolgt, wie die Zeit sich verändert hat.

Die Objekte kümmern sich also selber darum, festzustellen, wie weit sie sich updaten müssen. Die Logik dazu werde ich in einem Trait implementieren oder in einer Klasse, die eine Zeitspanne symbolisiert. In jedem Fall wird der Code nicht dupliziert - der Spaß wird also nur einmal implementiert :)

So... hoffe, das war nicht zu verwirrend geschrieben ^^
~ Frase

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Di Jul 20, 2010 21:49 
Offline
Forenkatze
Benutzeravatar

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

mal wieder ein kleineres Update, dafür mit viel Wirkung:

ich habe bei meinem Repository auf github ein paar Änderungen vorgenommen, bei denen sich v.A. die Clone-URL geändert hat. Das ist nicht weiter tragisch - und die wird sich (vermutlich morgen) auch bald nochmal ändern. Mir schwebt mittlerweile nämlich ein konkreter Name für Yang vor ;)

Damit verbunden ist dann eventuell auch ein Umzug nach mercurial (hg) und damit nach google code (Weil der github-Klon bitbucket nicht so wirklich überzeugend ist). Aber der Umzug kommt vielleicht auch erst später ;)

Was hat sich an Yang selbst geändert? Nicht so wahnsinnig viel. Ich habe die Test-Struktur geändert, die Tests sind nun auch aus der IDE heraus ausführbar.
Außerdem entfällt nun das komplette Setup in der IDE. Das wird nun durch das build-tool (sbt) übernommen.
Dem nicht genug, habe ich nun angefangen, meinen Code auch zu covern. Wem Begriffe wie Line-Coverage, Branch-Coverage und Conditional-Coverage was sagen... genau sowas ;)
Im wesentlichen ist die Code Coverage eine Metrik / Auswertung darüber, wie viel meines Codes durch die Tests tatsächlich abgedeckt wird. Dadurch sieht man relativ schnell, an welchen Stellen man vergessen hat, Tests zu schreiben.
Auch das geschieht direkt aus der IDE heraus, wobei die Zeilen im Sourcecode dann grün bzw. rot eingefärbt werden (je nachdem, ob sie abgedeckt sind oder eben nicht). Eventuell werde ich da aber beizeiten noch was fürs build-tool nachrüsten, um genauere Auswertungen zu bekommen.

Das war's erstmal...
~ Frase

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Yang - Yet another nameless game
BeitragVerfasst: Mi Jul 21, 2010 19:37 
Offline
Forenkatze
Benutzeravatar

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

Yang hat nun einen Namen! Für die, die es aus dem bisherigen Thread nicht herausgelesen haben: Yang ("Yet another nameless game") war nur ein Arbeitstitel. Es war also abzusehen, dass der nicht ewig halten wird. Zugegebenermaßen gibt es auch manches Projekt, was seinen Arbeitstitel sein Leben lang auch als finalen Produktnamen behält, aber Yang gehört da gewiss nicht dazu ;)
Die Entscheidung viel nicht gerade leicht - ich wollte zwar irgendwo eine Parallele zum Ursprungsspiel Thunder Brigade herstellen, aber das wollte nicht so recht klappen: Squadron (Analog zu Brigade) hätte noch gute Chancen gehabt - vor allem, da Squadron (zu Deutsch: Geschwader) eigentlich was für die Luftwaffe ist. Ein bisschen Queerdenkerei vorrausgesetzt, käme man damit zu Hover Tanks ;)
Wie auch immer - Squadron war mir ne Idee zu militärisch und vor allem war nahezu jede Kombination, die irgendwie was mit Panzern und Geschwadern zu tun hatte, schon vorbelegt. Hauptsächlich durch irgendwelche "wie-auch-immer"-benamsten Geschwader in diversen Kriegen.

Nach weiteren Herumdenkens kam ich dann gestern auf:
Dateianhang:
swift-steel.png
swift-steel.png [ 3.1 KiB | 8367-mal betrachtet ]


"Swift Steel" ist eine der wenigen Namensideen, die mehr als 24h überlebt haben. Auch wenn es im ersten Moment nach einem melee-lastigen Spiel klingt, bei dem es hauptsächlich um Schwertkampf geht, denke ich, dass der Name eine gute Wahl ist. Er ist kurz, hat sogar eine Alliteration drin, drückt einen wichtigen Aspekt des Spiels aus und hat sogar einen Bezug zu (Schwebe-)Panzern.
Ich habe auch eine Engländerin zu dem Namen befragt und ein "excellent choice!" als Antwort erhalten. So schlecht kann er also nicht sein :)
Einziger Wermutstropfen: Die naheliegendste Abkürzung ist leider etwas unglücklich. Aber das Problem hatten schon unzählige vor mir: Nicht zuletzt System Shock, was dank DOS und 8.3 Ordnernamen sogar zu einer Abkürzung gezwungen war und dann eben "sshock" nahm. (Nur so nebenbei ^^)

Da es doch einige gibt, die dem Namen Yang nachtrauern... Namen sind Schall und Rauch! Das Spiel selbst wird hoffentlich noch viel cooler als der Arbeitstitel und tröstet dann hoffentlich über die Aufgabe selbigens hinweg ;)
(Und vielleicht lasse ich yang erstmal auch im Sourcecode stehen ;) )

Aktuell bin ich gerade am Umstellen der Repositories - wenn da also was nicht geht, liegt's vermutlich am Namenswechsel ;)

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: So Jul 25, 2010 22:55 
Offline
Forenkatze
Benutzeravatar

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

und wieder mal was organisatorisches:

Ab sofort ist die Projekt-Website wieder erreichbar und zur Feier dessen gibt's nun auch die Domain zum Spiel (Am Film arbeite ich noch *hust*):
http://www.swiftsteel.org

Hoffe, sie gefällt ;)
~ Frase

_________________
"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 1, 2  Nächste
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 2 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:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.078s | 19 Queries | GZIP : On ]