Cube-Wars 2010

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite 1, 2, 3, 4, 5, 6, 7  Weiter

Worklogs Cube-Wars 2010

April, April! (Mehr oder weniger)

Samstag, 2. April 2011 von Kernle 32DLL
Moin moin,

Tja, wer hätte das gedacht, es gibt ausnahmsweise mal kein reboot des Spielprinzips nach ein paar Monaten Wink Das meiste aus meinem Eintrag war natürlich frei ersponnen. Allerdings waren auch ein paar Wahre sachen drin. Genaueres folgt:

Ja, ich habe in letzter Zeit wieder ein paar Momente für Cube-Wars gefunden, aber dabei ist nichts bedeutendes rausgekommen, da mir wie gehabt momentan die Zeit fehlt. Die Form des Spielfelder und der Cubes ändere ich nicht, ergo bleibt auch der Name gleich. Was aber durchaus stimmt ist, das ich mir gedanken über die Form der Cubes gemacht habe. Man darf hier aber keine wirklichen Neuerungen erwarten.

Bezüglich der veröffentlichung auf mehreren Plattformen: Ja, das ganze ist so in etwa geplant. Aber im kleineren Maßstab. Cube-Wars erscheint natürlich weiterhin primär für Windows, Mac und Linux im Rahmen von BlitzMax in Kombination mit Irrlicht. Eine Android Version schwirrt in meinem Kopf, aber diese würde ich definitiv erst angehen sobald das Primäre Spiel fertig und released ist. iPhone fält ganz flach, da ich keinerlei Erfahrung mit dem Gerät, oder der Programmierung dafür habe. Das ich eine etwagige Android Version für einen kleinen Unkostenbeitrag (1,19) verhökern würde stimmt, aber die PC Variante wird durchwegs immer kostenlos bleiben.

Mit diesen Worten verlasse ich mal wieder das Spielfeld, und schaue vom Rand aus zu Very Happy Auf das ich irgendwann Zeit fidne Cube-Wars fertig zu stellen.... Very Happy

So long,
Kernle

Kompletter Reboot

Freitag, 1. April 2011 von Kernle 32DLL
Moin,

Überraschenderweise habe ich zwischen all den Klausuren und anderen Dingen doch noch Zeit gefunden an Cube-Wars zu arbeiten. Während der letzten Wochen ist mir klar geworden, dass ich die ganzen Jahre einer dummen Idee hinterhergelaufen bin. Würfel - Cubes als Spielfiguren ist eine gähnend langweilige Idee. Was als Anfänger funktionierte, genügt mittlerweile weder meinen Ansprüchen an das moderne Cube-Wars Konzept, noch wird es von der Community brauchbar aufgenommen.

Aus diesem Grunde habe ich mich entschlossen, Cube-Wars etwas offener zu gestalten. Aus Cube-Wars wird Polygon-Wars. Im Prinzip wird das letzte Konzept im großen und ganzen beibehalten, aber das Spielkonzept verabschiedet sich von der langweiligen Würfelform. Statdessen wird die Palette um hochpoligonische Formen erweitert, z.B. Dodekaeder.

Wie das Spielfeld aussieht weiß ich noch nicht genau, aber ich denke ich werde hier auf Hexagons setzen. Wie gut sich damit Spielfelder erzeugen lassen, zeigte neulich erst Civilization 5. Ein leicht veraltetes Konzeptrendering noch ohne die Hexagon Felder, aber mit den angesprochenen Dodekaedern wollte ich euch auch nicht vorenthalten:

user posted image

Eine ebenfalls große Neuerung wird sein, das Polygon-Wars parallel für PC, Mac, Android und iPhone entwickelt wird. PC und Mac werden mit BlitzMax und Irrlicht verwirklicht, die Android Version via jPCT-AE. Für die iPhone Variante steht noch nichts fest, aber vermutlich werde ich auch hier auf eine der vielen verfügbaren opensource Grafikengines setzen. Wichtiger Hinweis: Aufgrund der hohen Entwicklungskosten wird nur die PC/Mac Variante kostenlos sein. Die Android Variante wird 1,19 Euro kosten, die iPhone Variante 2,19 Euro.

Wenn alles gut geht, wird Polygon-Wars im November diesen Jahres für PC und Mac, und im Dezember für Android und iPhone veröffentlicht.

Ich bin gespannt auf eure Kommentare zu der neuen Einstellung meines Langzeitprojekts.

So long,
Kernle

Schon wieder zu viel zu tun...

Sonntag, 6. Februar 2011 von Kernle 32DLL
Moin Leute,

Leider werde ich in nächster Zeit mal wieder nichts Interessantes zu Cube-Wars schreiben können, da ich in nächster Zeit nahezu keine Zeit zur Weiterarbeit an Cube-Wars haben werde (und wenn dann nur kurz und sporadisch).

Nicht nur kommen meine Abschlussklausuren immer näher, auch muss ich mich in letzter Zeit immer intensiver um mein Auto kümmern, diverse Android Auftragsarbeiten erledigen, bei einem Zeitintensiven Theaterprojekt mitwirken, meinen Führerschein (Motorrad) komplettieren, sowie mich bei der Planung eines größeren Events im August beteiligen.

Der aktuelle Stand von Cube-Wars ist nicht viel anders als er sich aus den letzten Einträgen erschließen lässt. Die Spielmechanik ist de-facto fertig, aber im Grafischen Bereich habe ich mich festgefahren.

Ich denke dass ich erst frühestens Juni, aber eher September diesen Jahres wieder Zeit haben werde intensiv an Cube-Wars arbeiten zu können. Vielleicht finde ich hier und da mal ein Wochenende, oder gar eine Woche Zeit, um wieder ein wenig an Cube-Wars zu arbeiten, aber solche Zeitrahmen werden eher die Ausnahme bilden befürchte ich.

Erfreulicherweise habe ich diesmal den Code ein einem Zustand hinterlassen, auf dem man zu einem späteren Zeitpunkt problemlos wieder aufsetzen kann, und nicht wie bei vorherigen Anläufen komplett neu anfangen muss. Ich denke, vor allem die Trennung von Grafik und Spielmechanik haben hier ihren Teil dazu beigetragen.

So, das war wohl der letzte Eintrag für Cube-Wars auf lange Zeit... Bis dann, auf das Cube-Wars irgendwann doch noch fertig wird Wink

So long,
Kernle

Einstellbare Texturqualität

Freitag, 14. Januar 2011 von Kernle 32DLL
Geschafft, der XML Loader für Texturen (Und Materials, yay) ist vollständig implementiert, und läuft. Derzeit arbeite ich noch an der Auslagerung der Partikel Effekte in ein ähnliches XML Format, und werde die Tage auch das Mesh XML Format basteln.

Während ich die Materials implementiert habe, habe ich direkt mal versucht nebenher etwas zu implementieren was mich schon länger interessiert hat: Einstellbare Texturqualität. Im Prinzip ist das nicht besonderes oder schweres, aber ich empfand es einfach als eine praktische Sache für schwächere Systeme. Als erstes realisierte ich folgendes System:

1. Mehrere Dateien
Die einfachste Methode. Für jede Textur gibt es mehrere Dateien, die dann mit "Medium" oder "High", etc. zusätzlich betitelt sind. Der Entwickleraufwand dahinter ist minimal, es müssen nur die Texturen als zusätzlicher Punkt im Material XML eingetragen werden. Der Große Nachteil hierbei ist allerdings der enorme Mehraufwand der Erstellung der Textur Varianten (selbst mit batching). Der aber noch viel gewichtigere Punkt dürfte aber der ungleich höhere Speicherverbrauch auf der Festplatte sein.

2. Dynamische Skalierung
Eine vermutlich Effektivere, und auch besser skalierbare Methode, ist die der dynamischen Textur Skalierung. Da ich die Texturen zuerst als Pixmaps lade, verschwende ich erst mal keinen Kostbaren Grafik-, sondern nur Arbeitsspeicher. Dort wird die Pixmap dann gemäß der gewählten Qualitätseinstellungen bis auf ein 4tel der Originalgröße Skaliert. Danach beginnt der ganz normale Ladevorgang über Irrlicht. Das hat den Vorteil dass das Verfahren ohne Probleme auf sämtliche Texturen anwendbar ist, ohne Speicherplatz zu verschwenden. Die Zeit die für die Skalierung drauf geht ist meiner Meinung nach vertretbar. Muss ich die Tage mal auf anderen PCs testen....

Nun ja, das war es auch schon wieder. Ich denke ich brauche noch 1-3 Tage, bis der XML Loader komplett fertig ist. Ich muss mir noch ein paar Gedanken zum Mesh Format machen, da ich dort auch direkt Sachen wie Multi Meshes (ein Mesh was aus mehreren besteht, z.B. ein Wald Feld), Mesh Variationen (für Felder, etc.), und weitere Dinge wie Partikel Emitter, etc. unterbringen muss. Alles in allem wird’s noch Spannend.

So long,
Kernle

Lebenszeichen

Donnerstag, 13. Januar 2011 von Kernle 32DLL
Moin moin,

Das Jahr 2010 ging doch schneller zu Ende als erwartet. Und plötzlich wurde ich mit Arbeit wortwörtlich überhäuft, wodurch keinerlei Freizeit mehr für Cube-Wars übrig blieb. Schade, aber nicht änderbar.

Passiert ist passiert, und jetzt sitze ich wieder frisch an Cube-Wars. Ich habe die letzten Tage genutzt um mich wieder in den Code rein zu lesen, und musste bei der Feststellung der Themen die ich vor fast 3 Monaten habe liegen lassen direkt wieder das Gesicht verziehen.

Zwar funktioniert wie im vorletzten Eintrag gesagt die Verbindung zwischen der FreeImage Lib und Irrlicht, aber leider funktionieren Texturen mit Transparenz Werten noch nicht. Warum? Weil Irrlicht und Blitzmax andere Formate benutzen, die ironischer weise die jeweils andere Seite nicht versteht. Was heißt das genau?

Blitzmax unterstützt folgende (relevanten) "Pixelformate" für Pixmaps:

Zitat:
PF_BGR888 - Blue, Green, Red - jeweils als Byte
PF_RGB888 - Red, Green, Blue - jeweils als Byte
PF_BGRA8888 - Blue, Green, Red, Alpha - jeweils als Byte
PF_RGBA8888 - Red, Green, Blue, Alpha - jeweils als Byte


Das heißt, Blitzmax unterstützt nur Formate, bei denen der Alpha Wert am Ende der Bit folge steht. So, und welche Formate kennt Irrlicht nun? (Irrelevante Formate ausgelassen)

Zitat:
ECF_R8G8B8 - Red, Green, Blue - jeweils als Byte
ECF_A8R8G8B8 - Alpha, Red, Green, Blue - jeweils als Byte


Genau das Gegenteil. Nur ein Format mit dem Alpha Wert am Anfang.

Da ich wenig Lust habe das gesamte Pixmap Modul dafür umzuschreiben, werde ich vermutlich einen sehr "hacky" Weg nehmen: Sicherstellen das die Pixmap im PF_RGBA8888 Format ist, Pixel für Pixel die Farbwerte einlesen, und entsprechend ECF_A8R8G8B8 verdreht reinschreiben. Dann ist das Bild zwar aus BlitzMax zum anzeigen zu nichts mehr gut, aber da ich das eh nicht mache, sondern das Bild direkt in Irrlicht einfüttre (was dann natürlich gesagt bekommt das es sich um eine ECF_A8R8G8B8 Grafik handelt), sollte es keine Probleme geben. Muss ich die Tage mal ausprobieren.

Fast nebensächlich sei zu erwähnen dass ich die Tage auch den XML Loader fast fertiggestellt habe. Texturen werden vollständig ausgelesen und geladen, Materials fehlt noch die Auslesung der Shader Implementierung, und Meshes habe ich mich noch gar nicht dran gegeben. Naja, gut Ding will Weile haben heh? Wink

Das war es auch erst mal wieder für Erste. Ich werde schauen das ich jetzt zügig das Technische Brachland das Cube-Wars momentan ist aufbereitet bekomme, und möglichst viel Hart gecodedetes Zeug über das XML Interface auslagern kann. Sobald das alles quasi "automatisiert" ist, kann ich auch endlich ohne großes Tricksen das bisher entwickelte Gameplay integrieren.

So long,
Kernle

Threading is dead

Montag, 8. November 2010 von Kernle 32DLL
Der Eintragstitel verkündet es, ich habe das Thema Threading aufgegeben. Zu viele Probleme für die ich schlich keine Zeit, keinen Nerv, oder schlicht kein Wissen hatte, um sie zu umgehen. Darum habe ich mich dafür entschieden mir viel Stress zu ersparen, und das Thema Threading einfach in die Ecke zu werfen. Der Profit für Cube-Wars daran wäre eh nur minimal gewesen, von daher ist es kein großer Verlust.

Endlich Zeit für andere Dinge, habe ich zum einen das Material System komplettiert, und zum anderen den Usage Stack vollständig integriert. Das System weiß nun selbstständig wann Texturen noch verwendet werden, und wann sie ggf. zum Speicher schonen freigegeben werden können. Fein fein.

Auch der XML Parser funktioniert rudimentär, aber es gibt noch genügend Dinge zu tun (vor allem mögliche Fehleingaben abfangen, etc.). Im moment schraube ich ein wenig an den Texturen rum. Mal schauen ob ich die vorhandenen ein wenig aufhübchen kann Wink

So long,
Kernle

Wasser marsch!

Donnerstag, 4. November 2010 von Kernle 32DLL
Moin,

Wieder ist Cube-Wars ein Stückchen weiter. Das Textursystem ist komplett funktionsfähig, das heißt die Brücke zwischen der FreeImage Lib und Irrlicht ist gespannt, Animierte Texturen werden zudem korrekt geladen, verwaltet und animiert. Ein dynamisches Lade- und Entlade System steht auch schon, nur funktioniert der UsageStack, ein Stack der alle Elemente enthält die gerade die Textur benutzen, noch nicht vollständig.

Der Weiteren habe ich mich ein wenig mit Threads in BMax beschäftigt. Das Thema ist, wie mir so oft im Chat an den Kopf geworfen, ziemlich heikel in BMax :/ Dennoch habe ich alles rudimentär am Laufen, auch wenn es noch ein paar willkürliche Abstürze gibt um die ich mich kümmern muss. Wenn ich das Problem nicht in den Griff bekomme droppe ich ggf. auch einfach den Thread kram wieder.

Zu Guter Letzt, hat sich auch am Content des Spiels etwas getan. Nach vielen herum probieren ist es mir endlich gelungen, ein ansehnliches Wasserfeld zu kreieren, sogar animiert Very Happy

user posted image user posted image
Wasser!

Zwar hinkt der XML Parser noch etwas hinterher, aber viel ist nicht mehr zu tun bis ich mich endlich an das wehleidige Thema geben kann. Wenn der Parser erst mal läuft, ist es auch nicht mehr weit bis ich den ersten Content auslagern kann, und die bisher gezeigten Grafischen Spielereien mit dem Hauptspiel kombinieren kann.

Stay tuned Very Happy

So long,
Kernle

Edit: Da im Chat vorgeschlagen, hier ein kurzes Video zum Wasser.

Ende der Ferien

Dienstag, 26. Oktober 2010 von Kernle 32DLL
Die Ferien sind vorbei, und Cube-Wars ist nicht ganz so weit wie ich es gerne hätte (größtenteils aufgrund meiner eigenen Faulheit Sad), aber immerhin, es geht immer noch weiter. Zum einen habe ich das neue, funktionierende Pathfinding ins Spiel integriert, was wesentlich schmerzloser von statten ging als erwartet. Ein wenig Optimierungs Spielraum habe ich noch, aber fürs erste reicht’s.

An der 3D Front geht es auch langsam weiter. Derzeit unternehme ich Tests bezüglich animierter Meshes und Texturen Smile. Per dirtycoding habe ich schon diverse Sachen getestet, und alles funktioniert bisher wie ich es erwartet habe, und so schreibe ich im Moment das dazugehörige System. Die Grundform des ganzen ist schon da, und die weiteren Coding Arbeiten werden fließend in den ersten Teil des XML Parsers, nämlich den für die Texturen und Materials übergehen (Material = Texturen + Shader).

Das wars auch schon wieder für diesen Eintrag. Vielleicht gibt es die Tage wieder was cooles zu sehen Wink

So long,
Kernle

Hephaistos, gib mir Feuer!

Dienstag, 19. Oktober 2010 von Kernle 32DLL
Guten Abend Community. Nach mein erster und zweiter Versuch eine A* Pathfinding Implementation zu schreiben kläglich gescheitert sind, habe ich unter n-Halbleiters wachsamen Auge endlich eine funktionierende schreiben können. Danke!

user posted image
Funktionierendes A* Pathfinding

Nach großer und ausgiebiger Diskussion im Chat, und Abwägung verschiedener Alternativen, habe ich mich nun endgültig dazu entschieden bei Irrlicht als Engine zu bleiben. Der einzige Nachteil den ich mit Irrlicht habe ist der, dass ich 2D Grafiken nicht rotiert darstellen kann (wer weiß, vielleicht finde ich da aber noch einen Workaround). Falls sich jemand dafür interessiert warum ich mich gegen Leadwerks, Softpixel, Ogre, und miniB3D entschieden habe, mag mich in den Kommentaren danach fragen.

Des Weiteren habe ich mich ein wenig mit Irrlichts Partikel System beschäftigt, und einen ganz anschaulichen Effekt für das Lava Feld erzeugt.

user posted image
Feuer!

Und weil das Ganze in Bewegung noch schöner aussieht, gibt es sogar ein kurzes Video.

In einer ganz anderen Richtung, nämlich dem Dateisystem für Cube-Wars habe ich mich die Woche auch schon rudimentär beschäftigt. Das alte CGD Dateiformat von mir fliegt raus, dafür wird jetzt alles über XML Dateien geregelt. Ob ich jetzt Irrlichts XML parser nehme, oder doch Brucys muss ich mir noch genauer anschauen. Ein Beispiel wie die Definition für ein Feldelement aussehen könnte habe ich auch noch in der Tasche:

Code: [AUSKLAPPEN]
<?xml version="1.0" encoding="utf-8"?>
<FieldElement>
  <Name translateble="true">#LAVAFIELD</Name>
  <Mesh>../../Meshes/Fields/LavaMesh.xml</Mesh>
  <CubeBonus>
    <Element>#FIRECUBE</Element>
    <Value type="percentage">2.0</Value>
  </CubeBonus>
  <CubeBonus>
    <Element>#WATERCUBE</Element>
    <Value type="percentage">0.5</Value>
  </CubeBonus>
  <Script File="../../Scripts/Fields/Test.lua" />
  <Script File="../../Scripts/Fields/Test2.lua" />
  <Script File="../../Scripts/Fields/Test3.lua" />
</FieldElement>


Bis zum nächsten Eintrag,
Kernle

"Normal" ist das nicht

Mittwoch, 13. Oktober 2010 von Kernle 32DLL
Nach anfänglichen Problemen habe ich mich nun doch dazu durchgerungen mit Irrlicht zu arbeiten. Nachdem ich einige Sachen recherchiert habe, und einige Sachen durch mühseliges Probieren endlich raus habe, bin ich mit dem aktuellen Stand auch ganz zufrieden.

user posted image
Aktueller Entwicklungsstand des Spielfelds

Was mir momentan noch ein paar Probleme bereitet ist das sog. "Normal Mapping", was zum einen Per-Pixel-Lightning ermöglicht, viel wichtiger aber auch Tiefenwirkung in Flachen Flächen ermöglicht. Irrlichts Weg Objekte zu Texturieren legt mir da einige Steine in den Weg, aber ich denke ich habe da schon eine Idee im Kopf wie ich die Probleme aus dem Weg räumen kann. Noch sind in NRW ja noch Ferien Wink

Spieltechnisch hat sich wenig getan, bis auf die Tatsache das ich die Player-Relations endlich eingebaut habe, und die Siegesbedingungen für einzelne Spieler daraufhin angepasst habe. Zudem habe ich den Code generell etwas aufgeräumt, und ein paar Vorbereitungen getroffen das Spiel mit dem bisher davon getrennt entwickelten 3D Spielfeld zu verbinden.

Das einzige was mir bisher immer noch wirklich Bauchschmerzen verursacht ist das Thema Pathfinding. So sehr ich mich auch bemühe, ich kriege es einfach nicht vernünftig hin. Falls mir ein geduldgier Coder hier dazu Nachhilfe geben will: Gerne.

So long,
Kernle

Gehe zu Seite 1, 2, 3, 4, 5, 6, 7  Weiter