Hallo Besucher, der Thread wurde 68k mal aufgerufen und enthält 370 Antworten

letzter Beitrag von Shadow-aSc am

Caren and the Tangled Tentacles, enthusi & veto

    Beeindruckend. Ihr habt auch auf das volle Programm gestürzt, der Zeitrahmen für sowas Ausgereiftes ist ja viel zu eng. Respekt!


    Daher: Macht was kleines Feines für den Competition fertig (als Appetitanreger) und liefert dann später einen richtigen Knaller ab. Ich wünsch mir das zu Weihnachten, aber muss nicht mal dieses Jahr sein :)

    Hier noch ein kleiner debug-Shot ;-)
    Leider wird diese Uebersichtsgrafik erst hinterher an Hand der selbst eingegebenen Zahlen erstellt. Es hilft aber dennoch um die Walkingboxes (gelb) zu identifizieren und ueberpruefen und natuerlich zu schauen, was die 'Aktionsflaechen' der einzelnen Objekte im Raum sind (weiss).
    Jetzt fehlen nur noch etwa 10 000 Stunden ;-)
    Edit: das Bild selbst ist so dunkel damit man die Rechtecke sofort erkennt.

    Woooooooooooooooooooooooooooooooooow !!!!


    Ich komme aus dem Staunen echt nicht mehr raus.


    Da habt Ihr ja so ziemlich alles rausgekitzelt, was in dem Brotkasten drinsteckt.


    Früher habe ich immer davon geträumt, solche Spiele auf dem CeVi zu machen.
    Nur leider stieß ich mit meinem Know-How immer an irgendwelche Grenzen.


    Damals, im Alter von 9-12 Jahren fehlte mir das Geld, um mir die passenden Bücher zu kaufen.
    Außer dem berühmten Commodore-Handbuch und den Programmierbüchern von Data Becker stand mir nicht mehr zur Verfügung.


    Zwar konnte man mit den Beispielen schon mal anfangen, was zu programmieren. Aber die Beispiele waren meist nicht für die Spiele-Entwicklung optimiert.


    So kam bei mir auch nur die Zeichensatz-Grafik zum Einsatz. Hatte damals auch einen Code, um Zeichensätze zu verändern (allerdings kein Multi-Color). Aber die grafischen Möglichkeiten sind ja damit sehr begrenzt.



    Umso mehr bin ich von Eurem Projekt beeindruckt.


    Würde mich auch freuen, wenn es bald eine Projektseite dazu gibt.


    Bis schon sooo gespannt auf das fertige Produkt! :) :) :)

    Easyflash wird in Erwaegung gezogen :-)
    Und das fixen einiger/aller Scripts. Bisher sind alle gefundenen Bugs auf Script-logik zurueckzufuehren. Das fuehlt sich fuer den Spieler dadurch nicht besser an (naja, immerhin crasht das Spiel dann meist nicht komplett :) aber fuer uns ist das sehr gut. Der mit Abstand groesste Teil ging fuer die Programmierung der Engine und aller Tools inklusive Scriptcompiler drauf und natuerlich fuer die Grafiken die Veto waehrend dessen alle parallel gemacht hat. So viele wie moeglich, damit wir die Story bauen konnten die wir im Kopf hatten. Zwischendurch haben wir dann viel weggeschnitten damit es ein WENIG realistisch bleibt fertig zu werden :-)
    Erst die letzten Tage+Naechte war dann alles so weit, dass man die Scripte zu den dann fertigen Grafiken mit den neusten Enginefeatures schreiben konnte. Schliesslich wurde auch erst zum Schluss klar, welche Raeume und Items es in dieser Version geben wuerde. Sounds kamen teilweise im letzten Moment erst dazu. In sofern ist die Engine stabil, und die bugs und Schwaechen im Scripting brauchen zwar viel Zeit, aber sind definitiv loesbar ;-) Es war eher so: "schaffst Du es noch die Tuer zu animieren? Ja? Bis in 30 Minuten? Dann kommt sie mit ins Spiel." und leider auch:"Von Deinen 6 Frames nehme ich jetzt nur 2, sonst schaffen wir das nicht mehr.".
    Version 1.1 wird also z.B. eine animierte Bodenklappe haben, um auf das Beispiel zurueckzukommen :-)

    Ich habe gestern das Spiel bis zum Dead-End durchgespielt. Einfach ein Hammer, was Oliver und Stefan da auf die Beine gestellt haben.
    Selbstverständlich ist das Spiel noch verbugt, einige Fehler habe ich bereits an enthusi geschickt. Lasst denen mal ein paar Tage Zeit, da werden sicher noch einige Fehler ausgemerzt.
    RESPEKT!!

    Hallo Enthusi, hallo Veto,
    viele Dank für das Spiel. Ich habe die Compo Version noch nicht gespielt, aber hatte Gelegenheit auf der gamescom reinzuschnuppern.
    Ebenso sind Eure beiden Artikel in der RETURN sehr gut. Und die tolle Gespräche mit Veto auf der gamescom haben mir nochmal mehr Einblick in Eure herangehensweise gegeben.
    Was mich aber besonders noch interessieren würde, wäre Eure Tool-Entwicklung und den Scriptcompiler. Was für eine Sprache? Für was gibt es Tools? Was sind die Kriterien für die Entscheidung, jetzt braucht es ein Tool? Vielleicht ist da ja noch ein Artikel in der RETURN möglich.

    Ich habe hier ein sehr eigenartiges Verhalten. Testumgebung ist ein C64II, JiffyDOS (via EasyFlash) und ein SD2IEC Evo2. Geladen wird mit der Datei "kernal" um den Schnellader zu umgehen. Ich konnte spielen bis zum Kanaldeckel öffnen, beim Versuch die Kanalisation zu betreten war Finito mit "File not found". Betrifft csdb-Version und die hier im Forum angehängte Version gleichermaßen.
    Schreibe ich das Spiel auf eine echte Disk und lade mit LOAD "*",8,1 kann ich in die Kanalisation.
    Edit: Es liegt scheinbar am JiffyDOS und der Umgehung des spieleigenen Schnelladers. Jetzt hab ich auch von Disk Flimmerscreen und File not found


    Das andere ist wahrscheinlich einer der weiter oben erwähnten Scriptfehler: Wenn ich schnellstmöglich die Eisenstange hole habe ich in diesem Raum plötzlich Halsband und ID-Karte im Inventar, obwohl ich die gar nicht mitgenommen habe.


    So, genug gemeckert. Nun will ich abschließend noch loswerden, dass mir dieses Spiel in Machart und Schwierigkeit sehr gut gefällt, obwohl ich eigentlich nicht so der Adventure-Typ bin :D

    Huhu,
    An Domspitze und die die es noch interessiert :)
    Ich hatte auf CSDb ein paar Zahlen gepostet. Aus Interesse an Zahlen, nicht zum prahlen (reimt sich immerhin :).
    Ueber 11.000 handgeschriebene Assemblerzeilen (+ ca 1000 fuer Krills loader).


    Knapp 4.800 Zeilen an geschriebenen Scripten.
    Viele davon erst am Ende und darin liegen auch die bugs oder fehlenden Teile.


    Die Scripts werden zu 15.000 Zeilen Assembler compiliert (Aber auch mal Leerzeilen dazwischen und so).


    An Tools habe ich GIMP benutzt, um mal den ein oder anden Pixel zu versetzen oder Frames zuruechtzuschneiden oder fuer Tests.
    Alle Grafiken von Sprites ueber Pointer bis hin zu Animationsframes kamen als PNG von Oliver (Veto), der vielleicht auch ein
    paar Worte darueber verliert, aber auch in diesem Thread schonmal beschrieb wie er so an die Sache herangeht.


    Dann ein Tool zum finden der kuerzesten Wege zwischen den begehbaren Bereichen. Via Dijkstra-Algo.
    Insgesamt kann ich sagen, dass der Unterschied zwischen selbst steuern und point-and-click enorm war. Mehr noch als ich dachte.
    An sauberem Walking habe ich ziemlich lange gefeilt.


    Ein Tool (das ist erst kurz vor Ende schrieb) um die Walking-Boxes in das XFIG (vektor) Format umzuwandeln und natuerlich auch
    zurueck. Damit konnte ich dann die Boxes in XFIG anlegen und kontrollieren.


    Ein Tool das aus allen Skripten die Trigger-Areas und Walking-Boxes extrahiert und als overlay zur Raumgrafik anzeigt.
    Davon habe ich mal eines gepostet.


    Ein Tool um aus 2 Sprites ein 3. zu erstellen welches genau mittig liegt. Das brauchte ich als Uebergang.
    Wenn Caren hinter einem Zaun langlaeuft werden mehrfach die Spritemasken gewechselt. Veto hat den Zaun und die Masken flaechendeckend gepixelt, und dieses Tool
    erstelle mir dann die Zwischenbereiche.


    Ein Tool um die Daten zu verschluesseln und zu entschluesseln :)
    Man will ja verhindern, dass man durch umbenennen alle Raeume erkennt, hehe. Die Compoversion haben wir dann aber
    bewusst noch relativ einfach gehalten, damit man eine Chance hat, alles zu sehen.


    Ein Tool um alle Labels aus allen Skripten und der Mainengine zu extrahieren, damit alle Raeume auf alle Eigenschaften
    aller Gegenstaende und von Caren selbst zugreifen koennen. Das erzeugt viele Kreis-Abhaengigkeiten leider.
    Und durch last-minute-Aenderungen haben sich dort dann offenbar auch Fehler eingeschlichten beim letzten Build zur Compo.
    Zwei weitere 'make clean && make' haetten viele davon beheben koennen :(
    Aber Version 1.1 kommt hoffentlich bald :)


    Ein Tool welches fuer alle Raeume das Makefile generiert.


    Ein Tool das fuer alle Raeume, Zeichensaetze etc. die Load-Adressen der gepackten Daten ermittelt und die Engine
    damit patched.


    Ein Tool um ein passendes PNG in das interne Format der Engine fuer Inventory-Items zu konvertieren.
    Ein Tool um ein passendes PNG in das interne Format der Engine fuer den Textzeichensatz zu konvertieren.
    (und so weiter ... ;)


    Das Tool welches die Raumgrafik und alle Animationsframes konvertiert ist ein ziemliches Monster geworden.
    Schliesslich muss alles optimal aufbereitet und angeordnet sein.
    Das gesamte spiel laeuft in 50Hz ohne Doublebuffer (nur so haben wir genug Platz im Speicher fuer alles).
    Und auf NTSC Systemen muss es ja auch noch laufen.


    Ein Tool fuer Veto welches die haeufigsten vorkommenden Zeichen darstellt und listet. Das posteten wir mal, aber es kam
    eher wenig zum Einsatz.


    Zu guter Letzt natuerlich der Script-Compiler.
    Auch in python geschrieben. Er versteht etwa 30 eigene Befehle inklusiver einiger moeglicher Verkettungen und Varianten.
    Wie z.B.

    Code
    1. say "Im Regal steht ja ein Glas.",0,"Maybe the bowl over there might help.",0
    2. walk2obj shelfmiddleleft
    3. keep_listening
    4. keep_walking
    5. call game_face_nw
    6. break for 20 frames
    7. call _pickupbowl


    Das wird direkt in Assembler-Sourcen uebersetzt (nicht direkt in Bytecode).
    Das hat den Vorteil, dass ich eigene Routinen immer ergaenzen kann und nicht auf die
    bekannten Scriptbefehle beschraenkt bin. Z.B. sowas wie das abgedunkelte Badezimmer oder auch PONG :)


    Ich neige dazu fuer alles kleine Tools zu schreiben, die dann aber zu trivial sind, als dass ich sie hier aufzaehlen sollte :)

    Bei mir ist die Auswahl an Tools etwas übersichtlicher ;)


    Die Grafiken inklusive allen Sprites habe ich in Pro Motion 6.5 erstellt.
    Der Vorteil bei dem Tool ist, dass man beim Pixeln alle Freiheiten hat, die
    einem so einfallen. Es kann Animationen, Chars lassen sich über die
    Tile-Funktion simulieren und es bietet auch die Möglichkeit, nach Farben zu
    maskieren.


    Bzw es gibt dabei auch ein paar Nachteile, weshalb das alleine nicht reichte.
    Zum einen beherrscht PM keine nativen Formate, keine Layer im üblichen Sinn
    (das ist eher mit einer Lichttisch-Funktion zu vergleichen), Char-Tiles sind in
    der Auswahl nicht skaliert und entsprechend winzig. Zu guter Letzt kann man
    zwar mehrere Dokumente öffnen, aber zeitgleich immer nur eins bearbeiten, was
    so die Aufbereitung schwierig machte. Daher hatte ich noch eine Reihe weiterer Tools.


    Um festzustellen, wo sich Clashes befinden, verwende ich ein Tool, welches
    ursprünglich von Bitbreaker und Peiselulli stammt, was ich zuvor bei der Demo
    Comaland benutzt habe. Es ist an sich ein Kommandozeilen-Tool, welches eine PNG
    direkt zu Charsets umwandelt und dann auf dem Bildschirm die Screenmap
    darstellt. Colorclashes blinken einem direkt entgegen und die betroffenen Chars
    werden als Koordinaten protokolliert.


    Dann gibt es noch das Tool von Enthusi, welches die Häufigkeit der Chars zählt.
    Das ist Gold wert, wenn man Zeichen reduzieren muss und den Überblick behalten
    will. Es geht dort ja idr nur darum, dass man ähnliche Chars mehrfach verwenden
    kann und das betrifft idr Einzelne, die man sonst eher nur mit Mühe findet (gerade,
    wenn es am Ende nur auf ein-zwei ankommt, sucht man sich gerne einen Wolf).


    Das eigentliche Umwandeln der Grafiken hat dann Enthusi übernommen.


    Sprites wurden mit Spritepad umgewandelt, welches mittlerweile
    einen relativ zuverlässigen BMP-Import hat. Zum Testen der Charakter-
    Animationen habe ich dennoch auch den SEUCK benutzt.
    Die Körperpartien von Caren überlappen einander, insofern mussten da die
    Sprite-Prioritäten berücksichtigt werden und in der Hinsicht haben die ganzen
    Crossdev-Tools so ihre Defizite.


    Eine größere Baustelle war in dem Projekt die Verwaltung der
    Dateien. Durch die vielen Einzelteile und genauen Vorgaben, wie da was zu
    formatieren ist, war das lange eine ordentliche Fummelei. Ich hab letztendlich
    die Dateien in einem Webprojekt mit Dreamweaver verwaltet. Das hat sich doch
    als ziemlich praxistauglich erwiesen, da ich einerseits die Dateien ablegen
    konnte, wie Enthusi die braucht, und hatte selbst meinen Index mit Bildvorschau.
    Und falls da sich mal was von den Vorgaben ändert, muss man nicht an drei Stellen
    Korrekturen vornehmen. Umbenennen – Ordner neu zippen – fertig.

    Zitat von enthusi

    Ueber 11.000 handgeschriebene Assemblerzeilen (+ ca 1000 fuer Krills loader).


    Ist ja ein Ding, bei mir sind es mit 10741 Zeilen ohne Covert Bitops Loader tatsächlich praktisch exakt genauso viele ^^ ! Dafür sind meine Leveldaten mit 2849 Zeilen dann doch erwartungsgemäß um einiges übersichtlicher :whistling: