Chaosfrog
Entscheidung!
Montag, 15. Juni 2009 von d-bug
Hallo liebe Gemeinde,
was ich euch jetzt mitteilen werde wird einige von euch enttäuschen oder gar erzürnen, aber aus ziemlich augenscheinlichen Gründen, auf die ich gleich näher eingehen werde, wird ChaosFrog bis auf weiteres auf Eis gelegt.
Zu den Gründen:
Mein neuer Arbeitgeber offenbarte mir heute, dass ihm mein bisheriger Arbeitseifer nicht ausreicht. Er wünscht sich, dass ich bis auf weiteres eine monatliche Mehrarbeit von 30-40h aufschlage. Das heißt für mich, dass zuzüglich zu meinem ca. 13h Arbeitstag (inkl. Fahrten) noch mal ca. 2.5 Überstunden täglich auf mich zu kommen. Außerdem darf ich mich auch noch mindestens jeden zweiten Samstag auf die weite Reise gen Köln begeben (60km) und meine ungeteilte Aufmerksamkeit meinen dortigen Aufgaben widmen. Wie dem auch sei, ich kann es verstehen, aber ankotzen tut es mich trotzdem.
Ich bin derzeit Mitglied eines Planungsteams, dass einen Firmenumzug mit ca. 100 Maschinen und 500 Mitarbeitern organisiert. Das hört sich einfacher an als es ist, weil gleichzeitig die neue Hütte auch noch gebaut wird, was wir auch noch zu koordinieren haben. Insgesamt gesehen haut einem die Menge an Arbeit ganz schön aus den Socken, aber trotzdem habe ich bisher versucht so viel Zeit wie möglich ins Programmieren zu investieren. Sieht man mal davon ab, dass ich ja nicht alleinstehend bin, hab ich doch noch eine Menge Zeit vor der Kiste hier verbracht. Das wird mir ab jetzt nicht mehr so ohne weiteres Möglich sein. Nach einem so langen Arbeitstag würde ich eh nichts gescheites mehr auf die Reihe bekommen.
ChaosFrog wird hoffentlich nicht für immer in der Versenkung verschwinden. Der Umzug als solches soll Ende 2010 über die Bühne gegangen sein. So der Plan! Die Wirklichkeit zeigt allerdings, dass wir diesen Termin nicht einhalten werden.
Was allerdings sein kann ist, dass ich nach so langer Zeit nicht mehr in den Code finden werde und stattdessen lieber gleich neu beginnen werde. Da ich darauf meinen Ar... verwetten kann, werde ich diesen Worklog hier im Laufe dieser Woche löschen. Der bringt euch nichts mehr und mir schon gar nicht.
Die Zeit, die ich jetzt noch ins Coden stecken kann werde ich an kleiner Projekte, wie z.B. ChaosKnuffel, verschwenden. Da muss man nicht die ganze Zeit wie ein Irrer hinterher sein und so viel Zeit kostet es auch nicht.
Momentan habe ich mir zum Ziel gesetzt ein alternatives CocoaMaxGUI Modul zu erschaffen, dass aber auf Basis von MaxGUI bleiben wird. Wenn wir OSXler nämlich mal ehrlich sind, bietet MaxGUI nicht die Hälfte der Features, die Cocoa parat hat. Als kleines Beispiel dienen schon normale Buttons. Cocoa bietet vierzehn verschieden ButtonStyles mit bis zu sieben verschiedenen Verhaltensweisen pro Style. Das macht grob überschlagen 14*7 Arten von Buttons, was aber so nicht ganz stimmt. MaxGUI dagegen holte daraus gerade mal drei ButtonStyles mit zwei Verhaltensweisen (Push-und Check-Verhalten). Wie auch immer, da SebHoll nicht im geringsten auf meine Requests einging, hab ich es eben selbst in die Hand genommen! Übrigens haben alle Kritiker von Objective-C Recht! Diese Sprache ist eine mittelschwere Katastrophe!
So, mault mit mir, haut mich und peitscht mich aus, aber noch gehen mein Beruf und meine Beziehung VOR ChaosFrog!
So long!
~edit (nur ein paar Minuten später)~
Auf Wunsch einiger, mir lieb und teuer gewordener Menschen, wird der Worklog nicht gelöscht sondern verschwindet im Nirvana. Das große fliegende Spaghettimonster wird ihn dann irgendwann zu sich nehmen.
cheers
...und wieder ohne...
Dienstag, 7. April 2009 von d-bug
So, nach mehreren Tagen ohne Worklog mal das neuste vom Tage!
Soeben habe ich einen dämlichen Bug in den ausfahrenden Spitzen am Boden beseitigt. Irgendwie hab ich wohl seinerzeit gemeint es wäre nicht nötig weniger als 8 von denen in einer Reihe zu haben. Komischerweise hab ich es dann aber auch noch so starr gestaltet, dass wirklich explizit die Nr. 8 abgefragt wurde. Nun gibt es aber stellen in Level 7, an denen es nun mal auch dreier Formationen dieser Dinger gibt. Stürzte natürlich alles prompt ab, als ich die eingebaut hatte.
Weiterhin hab ich die letzten Tage ein paar Versuche mit einem anderen Map-Format gewagt. Momentan nutze ich im Editor ja noch eine TMap um die Daten zu speichern und dann auf ein Array zu übertragen. Ich hielt das anscheinend damals für einen spitzenmäßigen Einfall. So toll, dass ich jetzt unter zu lahmen Levels im Editor zu leiden habe, was sich aber nicht auf das eigentliche Spiel auswirkt. Evtl. muss ich das mal angehen, wenn ich Lust habe.
Hab das Map-Format auch nicht wirklich eingebaut. Es wäre sicherlich leichter zu handhaben und wahrscheinlich auch um einiges schneller, da diverse Daten direkt im Array gespeichert würden. Allerdings bringt es Nachteile mit sich. Zum einen müsste ich alle Tunnel neu setzen, den Editor stark umschreiben, was ja noch handhabbar wäre, aber dann kam der Schock, die Kollision mit den Vektoren. Prinzipiell bleibt der Player schön überall pappen, es sei denn man befindet sich an den Stellen, an denen man von unten durchspringen können soll. Aus lauter Frust hab ich es erst noch mal beiseite gelegt. Ich hab nämlich so was von keinen Bock mehr auf erneute Kollisionsgeschichten! Heißt aber nicht, dass ich es nicht doch noch irgendwann angehe.
Sonst gab es eigentlich nicht sehr vieles. Hab noch ein Bisschen an Level 7 optimiert und auch schon ein wenig an Level 8 rum gepfuscht. Aber das kommt dann irgend wann im nächsten Worklog.
Verzeiht die Störung...
Bugs, Tiles, Bugs, Tiles...
Dienstag, 31. März 2009 von d-bug
Vorab: Heute gibts mal keinen Screen!
Gestern wurde Level 7 fertig. Damit hab ich alle Rekorde des Spiels gesprengt. Es ist das größte, schwierigste, umfangreichste Level, was ChaosFrog bisher hatte! Das ging sogar soweit, dass der Editor fast am abrauchen war. Da ich Tunnel immer hinterher setze musste ich den Editor nach jedem Tunnel beenden, den Speicher komplett aufräumen und den Editor wieder starten. Neulich hatte ich zwar schon mal eine kleine Änderung am Editor vollzogen, die das flooden des Speichers verhinderte (Kollisions-Objekte wurden immer erstellt, aber ResetCollisions() nicht mehr ausgeführt), aber irgendwie ist es bei großen Levels dennoch stark am Limit.
Außerdem muss ich mal die Tunnel wieder erweitern. Bislang hatte ich nur max. 16 pro Level vorgesehen. Die wurden in diesem Level komplett verbraten. Wenn da in den nächsten Levels noch mehr von kommen sollten, wird es eng.
Die Schalter für die Türen hab ich auch noch mal angepasst. Die wurden als normales Sprite behandelt, kollidierten also bei Schild oder Unsichtbarkeit nicht. Da musste noch mal kurz Vererbung von TSprite auf TShieldFilterSprite angepasst werden.
Die frisch eingebauten seitlichen Trampoline wurden auch noch mal angepasst. Drückt man jetzt während der Kollision links oder rechts, wird der Flug unterbrochen und der Player fällt wie nach einem normalen Sprung zu Boden. Das gabs im Original nicht, aber an manchen Stellen wünscht man sich das wirklich. Wenn man die Tasten loslässt, wird normal abgeschossen.
Die rutschigen, schleimigen, Flächen muss ich auch noch mal anpacken. Funktionieren ja soweit wie sie sollen, es sei denn man hat eine Wellenförmige Aufteilung der Tiles. Dann schaukelt sich der Player solange aus der Mulde wieder hoch, bis er wieder auf eine gerade Fläche kommt, oder aber eben auf Flächen ohne rutschige Tiles. Das hat zwar irgendwie was lustiges beim zusehen, aber diese Eigendynamik ist alles andere als erwünscht.
So, das war es dann für heute.
Erschreckend!
Freitag, 27. März 2009 von d-bug
Erschreckend, dass mir, uns, euch, keinem aufgefallen ist, dass man Tunnel auch aus der falschen Richtung öffnen konnte. Viel mehr erschreckte mich aber daran, dass ich in dem ganzen Code-Wirrwarr das öffnen der Tunnel an 2 verschiedenen Stellen realisierte. Wird wohl eine Restleiche aus dem Umbau von damals gewesen sein. 
Wie auch immer, hab dann heute mal Tunnel v3.0 realisiert. Jetzt können die Dinger nur noch aktiviert werden, wenn man mit einem, im Release-Modus unsichtbaren, Sprite kollidiert. Das hat den entscheidenden Vorteil, dass der Player am falschen Ende einfach nicht mehr eintreten kann. (Man konnte da vorher durch Wände gehen). Nun ja, dass ganze musste ich dann aber auch in allen Level nach frickeln, was mich heute vom Internet erst mal fern hielt. 
Die Fallgeschwindigkeit habe ich ebenfalls angepasst. In Level 6 kann der Player nämlich von ganz oben nach ganz unten durch das Level fallen. Das ging auch nur gut, wenn er gerade Lust hatte auf den Boden zu klatschen. Mit dem begrenzten YSpeed geht es nun wesentlich besser.
An vielen Tiles hab ich grafisch auch noch ein wenig gewerkelt. So ist die Statue nun etwas in den Hintergrund gerutscht und das Holz sieht nicht mehr so nach Eiche-Rustikal aus. *wärgs*
So viel zu den Bugs.
Zur Belustigung der Userschaft gibt es jetzt auch Trampoline, die einen in einem Winkel nach links oder rechts schleudern können. Lustige Geschichte, wenn sich 2 oder mehrere Trampoline abwechselnd gegenüber stehen. Sieht fein aus, wenn der Player im Zickzack durch das Level fliegt.
Level 6 ist Tile-Mäßig jetzt zusammen gesetzt. Ist wieder so ein riesiger Schinken wie Level 2 geworden. Ich fing damit ja bereits vor dem Urlaub an. Da hatte ich schon ein paar Stunden da rein investiert. Gestern habe ich dann noch mal den ganzen Tag da rein gesteckt, nur um die Tiles zu setzen. Sprites muss ich noch ... Auf jeden Fall beträgt der Tilecount für dieses Level im Moment 28649!
Als Screen gibts dann heute mal eine Stelle, an der es neue Tiles und diese Trampoline zu sehen gibt:
Ich lebe noch!
Freitag, 13. März 2009 von d-bug
So quasi als Beweis dafür, dass ich das Projekt nicht an den Nagel gehängt habe gibts mal einen Screen der Dinge, die ich die letzten zwei Tage daran gemacht habe:
Ihr seht also, ich war nicht ganz so untätig. Natürlich ist das nicht sehr viel, wenn man mal bedenkt, dass die letzte Alpha im November 2008 erschien. Nun ja, ich haben drei Monate lang gebraucht meinen Perfektionismus zu zügeln und mir selbst zu sagen, dass bei einer Anzahl der Downloads von etwas mehr als 600 die 3-4 Leute mit extrem veralteten Systemen nicht unbedingt ins Gewicht fallen. Es tut mir zwar leid, das sie das Spiel nicht spielen können, aber man kann wirklich nicht jedem lausigen PC gerecht werden. Ich habs echt versucht, aber dieser Neuanfang der Engine war mehr als demotivierend. Ich war nahe dran alles hin zu werfen und ChaosFrog sterben zu lassen.
Also, liebe Freunde der nicht OpenGL kompatiblen Rechner, ihr müsst auch weiterhin verzichten!
Der nächste Eintrag wird wieder ein wenig auf sich warten lassen, weil meine Holde und ich uns jetzt erst mal einen wohl verdienten Urlaub gönnen werden. Laptop bleibt daheim!
...gehabt euch wohl...
BUMM!
Samstag, 10. Januar 2009 von d-bug
Lange Zeit war es ruhig in diesem Worklog. Leider wird es auch erst mal so bleiben.
Letzterdings war meine Motivation vollkommen im Keller, aber ich orakel euch, dass Chaosfrog nicht gestorben ist. Im Gegenteil. Ich nutzte die Zeit um mir viele Gedanken bezüglich des Frameworks und der "Engine" zu machen. Es kommt wie es kommen musste, das geht so nicht weiter.
Alleine die Tatsache, dass DX7 massive Probleme mit der Anzahl der Tiles hat, verursachte mir unglaubliche Kopfschmerzen, da ich nie eine gescheite Windows-Version realisieren kann, wenn ich bei OpenGL bleibe. Zu viele Windows-Systeme haben Probleme mit OpenGL. Ich kann ja schlecht von der Menschheit verlangen auf gescheite Systeme umzusatteln.
Was bleibt mir also übrig, als die Tile-Anzahl drastisch zu reduzieren? Leider klingt es einfacher als es ist. Wenn ich nämlich die Tiles auf einen zu zeichnenden Layer reduziere muss ich mir auch Gedanken über die Kollision machen. Bei einem normalen Jump'n Run, so wie Mario, bei dem man nur geradeaus laufen kann und es keine Berge zum hoch laufen gibt, wäre das recht einfach. So muss ich mir aber Gedanken darüber machen, wie ich die Berge vernünftig und schnell realisieren kann. Die zwingen einen schon fast zur pixelperfekten Abfrage. Genau so ist es auch mit einem Großteil der Decken-Tiles in der ersten Welt.
Wie auch immer, ich bin dran...
buggy
Lange nichts Neues...
Samstag, 13. Dezember 2008 von d-bug
...und es gibt noch immer nichts zu vermelden!
Also eigentlich kämpfte ich die letzten paar Tage mit DirectX und kann nun vermelden, dass ich es auch weiterhin nicht unterstützen werde. Mir würde nichts weiter übrig bleiben, als ca. 80% des Codes neu zu schreiben, einen neuen Editor zu schreiben, ALLE Tilesets zu überarbeiten und das Parallax-Scrolling raus zu schmeißen. Mal ehrlich, darauf habe ich so was von gar keine Lust, dass ich es lieber gleich sein lasse!
Warum das ganze? Nun, an manchen Stellen werden sage und schreibe bis zu 970 Tiles (Ironie!) dargestellt. In BB2D, BB3D und B+ soweit kein Problem, aber da BMax komplett auf 3D basiert scheint es beim darstellen von 970 Tiles starke Performanceeinbrüche bei DX7 zu geben, was mir irgendwie nicht so ganz in den Kopf will.
Ich könnte das umgehen, wenn ich statt 2 Layer voller Tiles nur einen nutze und diesen mit SOLIDBLEND darstelle. Das würde aber bedeuten, dass ich das Parallax-Scrolling raus werfen kann, da es wohl ziemlich mies aussehen würde, wenn es hinter Treppen verschwindet statt hinter Berghängen. Den Editor müsste ich darauf anpassen, bzw. direkt neu schreiben...
Andererseits könnte ich das sehr wohl noch in Erwägung ziehen, denn so richtig zufrieden stellt mich diese Situation nicht.
Kommen wir nun zu dem Problem mit den Grafik-Bugs und den daraus resultierenden Abstürzen direkt im ersten Prolog.
Erst einmal, vielen dank für die Angabe deiner System-Specs, Quäiny! Ich fragte ja nur drei mal danach und bekam trotzdem nur so tolle Aussagen wie "Die gleichen Probleme habe ich auch"... Sehr sinniger Bug-Report, hm?
Okay, ich persönlich schätze einfach mal, dass eure Grafikkarten erhebliche Probleme mit Texturen haben die nicht quadratisch sind, also 32x32, 64x64, 128x128, 256x256... Blöder Mist das, aber dafür bastel ich gerade eine Lösung. Ich werde wohl die großen Images splitten müssen. Das Prinzip steht auch schon, aber um nicht mehrere Zeichenbefehle verwenden zu müssen, bastel ich mir doch lieber gleich eine eigene Image-Klasse! Außerdem werde ich wohl noch ein paar Sprites anpassen müssen. z.B. den Player *hüstel*. Der hat nämlich eine Frame-Größe von 64x96...
Insgesamt gesehen ist das alles total demotivierend! Aber was solls, ich beiß mich da schon noch durch!
ACHTUNG: peinlicher Noob-Bug
Donnerstag, 4. Dezember 2008 von d-bug
Hallo,
was passiert wohl, wenn man realtime ca. 200 Objekte ihr Image aus einer Hashmap mit ca. 50 Einträgen suchen lässt und 2 Befehle später auch noch einen Timer pro Objekt erstellt? Richtig, es schwächelt. Nicht mal so auf OSX, aber anscheinend auf Windows, sonst wäre es mir vielleicht früher aufgefallen. Also:
- major speedfix : Tunnel-Partikel haben nun einen gemeinsamen Timer und ihr Image wird nur noch ein mal geladen! (Ich hoffe es geht nun ordentlich auf Windows) (siehe auch da_pollers Kommentar)
- Ducken flackerte nach Kollisionsumbau (Rücksetzen einer Variable vergessen)
- Zufälliger Farbwechsel funktionierte nicht immer zuverlässig (gefixt)
cheers
P.S.: Ich befürchte die nächsten paar Einträge werden alle so kurz sein, da wie wir ja alle wissen, bugs suchen eine Ewigkeit dauern kann. Speziell dann, wenn es auf dem eigenen System 1a funktioniert aber auf anderen rumzickt.
Heutige Fixes + Features:
Mittwoch, 3. Dezember 2008 von d-bug
So, heute hatte ich recht wenig Zeit, drum gibts mal nicht so viel:
- Münzen bleiben nicht mehr an der Umgebung hängen (BoundingBox verkleinert)
- Player bleibt bei der neuen Kollision nicht mehr an Wänden kleben (CollideRect zu großzügig abgefragt)
+ Man benötigt nun wirklich den goldenen Schlüssel um Welt 1 absolvieren zu können. (neues animiertes Sprite mit 16 Frames)
+ Weicher Wechsel der Hintergrundfarbe zwischen den Seiten kombinierter Screens (bislang nur Highscore)
und das war es auch schon wieder!
Katastrophen und anders...
Dienstag, 2. Dezember 2008 von d-bug
Hallo,
nach den katastrophalen berichten über "Ich falle in durch den Boden"-Bugs bin ich die Kollision noch mal angegangen. Zu Testzwecken hatte ich, eigentlich nur kurzfristig, eine zusätzliche Abfrage eingebaut, die mir bei jedem Kontaktfehler der Vektorkollision ein sehr aussagekräftiges "Bumm" in den Output schrieb. Diese Abfrage bestand lediglich aus einem CollideImage und CollideRect Block. Jetzt das kuriose an der Geschichte: Die Vektorkollision versagt völlig willkürlich! Man stellt sich an eine Stelle und sie funktioniert. Zwei Sekunden später stellt man sich an exakt die gleiche Stelle und fällt durch den Boden. Es ist mir völlig schleierhaft, wie so etwas sein kann! Wie dem auch sei, ich nutze nun einfach den CollideImage und CollideRect Block dazu den Player bei versagen der Vektoren auf der Map zu halten. Ich hoffe inbrünstig, dass es damit nun abgegolten ist! Es bedarf allerdings noch einiger Testläufe um ganz sicher zu sein.
Bisherige andere Fixes:
- Pausetaste im Prolog brachte ChaosFrog in die ewigen Jagdgründe
- Schnelles drücken der Pausetaste zeigte "Paused" aber das Spiel lief weiter
- Pausetaste während GameOver blendete GameOver kurz aus und wieder ein
- In Prologen wurde der Frosch zu hoch angezeigt, wenn man eine Desktop-Auflösung von nur 600Pixel Höhe hat (ChaosCoders Laptop 
)
- Die letzte Eingabe im Eingabefeld des Highscores löste eine Tastenkombination aus (STRG+I auf Dosen) (Flushkeys vergessen *hust*)
Das war es dann ach erstmal!
Gehe zu Seite 1, 2, 3, 4, 5, 6, 7, 8 Weiter