Hello, Guest the thread was viewed5.2k times and contains 94 replies

last post from ^MGR3SA^ at the

Individuelle Gründe für oder gegen Portierungen/Konvertierung von Spielen

  • Ich werfe mal ein anderes Beispiel in den Raum:


    [Externes Medium:

    ]


    Dieser Port ist grafisch auf jeden Fall "simpler" als das Original, aber es hat dennoch seinen eigenen Charme, und die vereinfachte Grafik passt halt auch grundsaetzlich zu diesem Spiel, da es eh schon eine sehr "schematische" Grafik hat, mehr wie ein Brettspiel, aber kein Grafikwunder a la "Sam". Zudem wirkt es auf mich so, als wuerde es rein von der Spielbarkeit her keine wirklichen Abstriche machen, und es ist zudem eben ein super bekanntes Spiel. Also 3 Punkte die aus meiner Sicht fuer einen gelungenen Port sprechen.

    Sieht aus wie Boulder Dash, klingt wie Boulder Dash und spielt sich offenbar wie Boulder Dash. Dürfte also eine ziemlich gelungene Portierung sein. Da wäre die Bezeichnung Demake vielleicht unangebracht.


    Aber gibt es nicht eine Umsetzung von Portal für Atari 2600? Ganz klar muss das ein deutlich anderes Spiel sein als die Vorlage. Wurde aber wohl trotzdem gut aufgenommen, soweit ich mich erinnere. Das wäre dann ein "krasses Demake" und funktioniert offenbar u.a. deshalb, weil das originale Spielkonzept das hergab.

  • Ja, Portal gibt es fuer Atari 2600, uebrigens auch fuer den C64 (aber beide Spiele schauen schon recht unterschiedlich aus).


    Hier noch das von mir irgendwann erwaehnte "Princess Rescue":


    Was Boulder Dash angeht, klar, das ist kein Demake, das ist einfach "nur" eine Portierung. Aber eben eine gelungene :)

  • Ports sind alle grundsätzlich erstmal leichter als Neuentwicklungen (bei vergleichbarer technischer Umsetzung).

    EotB oder Prince of Persia für den C64 waren sicherlich mehr Arbeit als Shotgun oder Not Even Human, klar. Aber außer Sam's Journey gibt es nur sehr wenige original C64 Titel in dieser Klasse. Aus gutem Grund.

  • Sollte es jemand schaffen, Sam in einer aehnlich gelungenen Weise auf ein schwaecheres System zu portieren, bin ich sicher der letzte, der da was dagegen sagen wuerde. Ich glaube aber eben, dass sowohl Grafik als auch Gameplay drunter leiden koennten

    Was ich ja mache, um festzustellen, ob sich eine Portierung (oder überhaupt ein Projekt) lohnt, umzusetzen, ist das Erstellen von Mockups. (Wobei mein Ansinnen nicht immer von allen verstanden/goutiert wird – es geht in erster Linie um Evaluierung und in zweiter Linie auch darum, evtl. einen Programmierer zu triggern, sich daran zu versuchen)


    Dazu versuche ich möglichst viel vom Zielsystem zu wissen und entwerfe darauf basierend ein oder mehrere Screens, die ein denkbares und technisch (wahrscheinlich) mögliches Endergebnis zeigen. Die Community und vielleicht auch ein geneigter Programmierer können dann entscheiden, ob das mögliche Ergebnis einen ausreichend hohen Habenwollen-Effekt erzielt (manchmal lasse ich die Community auch außen vor und kommunizieren direkt mit 8-Bit-Codern). Programmierer können/müssen halt abschätzen (weil nur sie das können), ob das Ganze dann den Aufwand lohnt – und ob man evtl. zusätzliche Abstriche machen muss, weil ich vielleicht in den Mockups bestimmte Einschränkungen nicht bedacht habe oder anderweitig zu optimistisch war. An anderen Stellen kann man vielleicht sogar "aufrüsten", weil technisch möglich.


    Zuletzt gab es solche Diskussionen bei meinen Mockups zu einer "aufgepeppten" Boulder Dash-Variante für den C64 (BD stammt ja vom Atari 400/800) – die seine Fähigkeiten stark beanspruchen (was mir erst im Laufe der Diskussion klar wurde) und der Hardware schmeicheln würde. Da hat sich z.B. kein Programmierer gefunden, der das konkret mit mir zusammen hätte umsetzen wollen – was nicht tragisch ist, weil der Thread selbst auch schon interessant und erhellend war. Man lernt ja (hier im Forum) immer dazu. ;)

  • Zusammengefasst: ich mag alle Ports, auch Demakes, die die Zielplatform gut dastehen lassen :-)

    Ports, die aber nur die Unzulänglichkeiten einer Platform aufzeigen, brauch ich nicht.

    Genauso sehe ich das auch. Wenn ich über eine mögliche Portierung oder ein Demake nachdenke, dann deshalb, weil ich zeigen möchte, zu was eine Zielplattform fähig ist – und nicht, was sie NICHT kann. Es muss also von Anfang klar sein, dass die Portierung (oder freiere Übertragung eines Spielprinzips) ein Gewinn für die Plattform wäre. Dabei bin ich gar nicht so sehr daran interessiert, einen 1:1-Clone zu entwerfen, sondern die Fähigkeiten des Zielsystems glänzen zu lassen. Gerade heutzutage, wo man jedes System haben (oder emulieren) kann, sollte eine Portierung etwas besonderes haben, die es vom Quellsystem abhebt – warum sollte sonst der Aufwand zu rechtfertigen sein.


    Zum Thema Demake kann ich die Diskussion um Zarch/Virus auf dem C64 beisteuern. Es ist vollkommen klar, dass das Original nicht auf den C64 zu portieren wäre. Aber man kann natürlich darüber nachdenken, wie vielleicht ein Zarch-Vorgänger auf dem C64 ausgesehen hätte – aus dem dann später das bekannte 3D-Spiel entstanden wäre.

  • syshack

    Changed the title of the thread from “Individuelle Gründe für oder gegen Konvertierungen” to “Individuelle Gründe für oder gegen Portierungen/Konvertierungen”.
  • Jogi

    Changed the title of the thread from “Individuelle Gründe für oder gegen Portierungen/Konvertierungen” to “Individuelle Gründe für oder gegen Portierungen/Konvertierung von Spielen”.
  • Ich glaub das Problem in dieser Diskussion zwischen dir und Zeha/mir ist, dass wir als Leute die schon Spiele entwickelt haben die Arbeit dahinter sehen. Und den ganzen Kampf mit der Motivation dahinter sehen.


    Während du argumentierst damit was DU gerne sehen tätest.


    Ja klaro, ich hätte ja auch gerne ein Zuckerwatte kotzendes Einhorn das mich zur Arbeit teleportiert morgens, aber ist halt leider nich.


    Also weiter von der Realität entfernt hättest Du mit Deiner Vermutung nicht sein können:roll2:


    Meiner ersten (600) XL habe ich Ende 1983 bekommen und die einzigen beiden Jungs in der Nachbarschaft, die auch einen Computer hatten, waren einer mit 'nem C64 und ein anderer mit 'nem Apple II. Also hat man sich (zwangsweise getroffen) und dann sind daraus Freundschaften entstanden, die bis heute halten.


    Was wir seither machen ist, alle unsere Programme sowohl auf der einen (C64) als auch der anderen Plattform (Atari) zu programmieren und immer auch zu portieren. Leider sind unsere Treffen manchmal mit großen Abständen dazwischen (z.B. während der 16/32-Bit-Zeit, da ist auch der AppleII-Freund komplett ausgestiegen, Retro ist leider nichts für ihn) und auch nicht mit kommerziellen Interessen. Also ich WEISS, was für eine Portierung C64<->Atari erforderlich ist.


    So ist mir z.B. bei Deinem Dragonwood aufgefallen, dass Du den Fehler machst, den alle Anfänger machen, d.h. dass Du Deine "Sprites" nur acht Pixel breit machst. Der Atari hat aber 10 Pixel breite Sprites, weil die Player und Missiles prinzipiell zusammengehören (z.B. haben sie, wenn nicht anders definiert, die gleiche Farbe). So sehen Sprites die nur aus Playern bestehen meist sehr unnatürlich schlank aus und bei der Konvertierung hat man es von den 12 Pixel breiten Multicolorsprites zu 10 Pixel breiten P/Ms auch einfacher.


    Das Wichtigste ist daher vor allem die exakte Kenntnis was geht und was nicht geht. Da habe ich manchmal den Eindruck, dass der Atari stark unterschätzt wird.


    Aber Bilder sagen mehr als 1000 Worte, daher mal ein paar Sam Impressionen auf dem Atari. Wer die sich die Dateien auf dem Altirra-Emulator oder sogar auf echter Atari-8-Bit-Hardware ansehen will, einfach die .zip-Dateiendungen in .xex umwandeln.


    Bitte beachten! Das sind jetzt auf die Schnelle per Rastaconverter erstellte Grafiken, natürlich sind da noch Pixelfehler drin.


    sam_level1.zipsam_title.zipsam_water.zip



  • LOL, du erstellst mit Raster Converter ein paar Stills, und das soll dann der Beweis von Machbarkeit eines Spiels sein, welches 8 fach scrollt und multiple Objekte verschiedener Größen auf dem Screen darstellt?


    Ich hätte hier gerne anhand eines Mockups gesehen, wie du da Farben reinbringst, und das über einen kompletten Level, plus wo die bewegten Objekte und deren Eigenfarben herkommen.

    Dazu gerne auch noch welchen Mode du verwenden würdest, wieviele Fonts du brauchst wenn du per DLI umschaltest um genug Zeichen auf den Screen zu kriegen, und wie das alles in den Speicher passt.

  • Aber außer Sam's Journey gibt es nur sehr wenige original C64 Titel in dieser Klasse.


    Sam ist wirklich ein ausgesprochen guter Titel, aber ich würde schon sagen, dass die C64-Bibliothek auch noch sehr viele weitere gute Titel in dieser Klasse hat (z.B. EnforceR oder überhaupt Games von Manfred Trenz)

  • LOL, du erstellst mit Raster Converter ein paar Stills, und das soll dann der Beweis von Machbarkeit eines Spiels sein, welches 8 fach scrollt und multiple Objekte verschiedener Größen auf dem Screen darstellt?

    Ich hätte hier gerne anhand eines Mockups gesehen, wie du da Farben reinbringst, und das über einen kompletten Level, plus wo die bewegten Objekte und deren Eigenfarben herkommen.


    Ja,

    Dazu gerne auch noch welchen Mode du verwenden würdest, wieviele Fonts du brauchst wenn du per DLI umschaltest um genug Zeichen auf den Screen zu kriegen, und wie das alles in den Speicher passt.


    Na klar, das Ganze natürlich innerhalb eines Tages.


    Such Dir Dein Einhorn woanders, ich bin jetzt raus.


  • Also das Game sieht in dem Video wirklich klasse aus. Toller Tipp, kannte ich noch nicht.


    P.S.: Habe nichts dagegen, dass der Atari als das schwächere System mit geringerer Bekanntheit bezeichnet wird, ist ja auch so.

  • Dann schreib halt wenigstens irgendwas was da bitte dein Konzept sein soll. Im Rasterconverter was schnell umwandeln was mit Ach und Krach und pro Zeile ein DLI samt Sprites die noch aushelfen müssen reinbolzt und die komplette Rastertime verbrät ist halt einfach nix wenn man ein Spiel machen will.


    Sorry wenn ich das so hart sage.


    Disclaimer:

    Ich mag den Atari sehr gern, und auch ich bin der Meinung dass der noch einen Haufen Luft nach oben hat was seine Spiele angeht. Aber das müssen dann Spiele sein, die genau auf die Hardware abgestimmt sind, nicht C64 ports für die die Hardware einfach nicht gemacht wurde.

  • Gibt es eigentlich Cybernoid für den A8?

    Nein, aber es gibt einen netten Thread auf Atariage wo Jose Perreira sehr schöne Mockups gebaut hat fürs komplette Spiel. Das könnte so evtl funktionieren mit ner guten soft sprite engine.


    ich verlinke mal auf die letzte Seite des Threads:

    https://forums.atariage.com/to…76-cybernoid-wip/page/13/

  • Disassemblieren der Apple II-Version

    Soweit ich weiß, war das Quelloffen. Da muß nichts disassembliert werden. Es ist also ein Port mit angepasster Grafik und Sound.

    technisch mit nur 64K statt 128 sowieso unmöglich

    Da muß man aber auch beachten, daß die Apple-Version nur auf Diskette erschienen ist, während die C64-Version ordentlich von der ROM-Unterstützung profitiert.


  • Also weil Du so lieb bittest :bgdev:saint: schreibe ich dann doch nochmal was, dann können wir uns weiter lieb haben :box:(soll lustig gemeint sein):



    - Grafikmodus: Antic Mode 4 (Char-Mode, vier Farben plus Hintergrund je Zeile, 160x200 Pixel), vermutlich Interlace für mehr Farben vielleicht auch Dithern (letzeres könnte aber :poop: aussehen), besser: DLIs, wo immer es geht (wegen der Performance siehe unten)

    - Sprites:

    PM-Multiplexing, wie man am Rastaconverter-Mockup von Level 1 gesehen hat, ist das oft auch ohne Flackern möglich, die PMs sind ja 256 Zeilen lang und können per DLI beliebig horizontal geschoben werden, nur mehr als zwei Mulitcolor PMs pro Zeile gehen halt nicht. Schwierig könnte es an den Stellen werden, bei denen die Knights of Bytes schon gesagt haben, dass sie dort selber multiplexen, das würde ohne Anpassungen am Leveldesign vermutlich nicht gehen, jedenfalls:

    Zwei Player/inkl. Missile für Sam, d.h. drei Farben (dritte geORt), wie man an den Rastaconverter-Images gesehen hat, muss SAM dann nicht völlig hässlich werden

    Die beiden anderen Player/Missiles (mit drei Farben) für die anderen bewegten Objekte, wie z.B. den Schmetterling oder die Seesterne in obigen Beispielen

    - RAM: keine Limitierung, die meisten Ataris haben ja heutzutage eine Speicherweiterung, im Zweifel gehen auch noch .car (sprich: Module), Sam's Journey lädt aber glaube ich auch nach, aber ich bin da eh nicht so der Purist, dass alles unbedingt mit 64K (eigentlich sogar 48K wegen der alten 400/800er) gehen muss.

    - Statuszeile: das volle Programm: DLIs, PM-Overlay, eventuell auch Midline-Colorchange, kommt auf die Anzahl der benötigten Farben an


    Von der Performance sollte es gehen, das Scrolling auf dem Atari benötigt kaum Rechenzeit (ist ja "nur" Pointergeschiebe) und trotz 30% für ANTIC-DMA bleiben immerhin noch grob 1,2MHz über. Da kann man schonmal z.B. was für die Lautstärkebit-Hüllkurvensimulation oder das vertikale Verschieben der PMs verbraten oder auch das Mitführen von DLIs für mehr Farben pro Zeile

    Disclaimer:

    Ich mag den Atari sehr gern, und auch ich bin der Meinung dass der noch einen Haufen Luft nach oben hat was seine Spiele angeht. Aber das müssen dann Spiele sein, die genau auf die Hardware abgestimmt sind, nicht C64 ports für die die Hardware einfach nicht gemacht wurde.


    Und ja, Games, die für den Atari gemacht sind, sind natürlich noch besser (nur zwei Beispiele Yoomp! oder seinerzeit Rescue on Fractalus)

    Offensichtlich haben wir aber ein fundamental unterschiedliches Verständnis, was auf dem Atari geht und was nicht.


    Klar, wenn man nur die Standardfeatures nutzt (also keine DLIs oder Midlinecolorchanges oder PM-Underlays oder kein Lautstärkebit beim Pokey um ADSR bzw. andere Hüllkurven als Rechteck hinzubekommen oder PM-Multiplexen) dann sehen viele Games schlecht aus bzw. hören sich schlecht an. Aber es geht eben fast alles. Natürlich angepasst an das jeweilige Game, Midlinecolorchanges gehen z.B. bei Games, die viel scrollen eher "nicht so gut".


    Was überhaupt nicht (auch mit der allertrickreichsten Programmierung) hinzukriegen ist:

    - mehr als ein Tastendruck gleichzeitig (Atari)

    - Highres-Sprites (Atari)

    - mehr als 2 16-Bit-Stimmen, da müssen es dann eine 16 Bit-Stimme und zwei 8-Bit-Stimmen tun (Atari)

    - größere Farbpalette (auf dem C64)

  • Aber außer Sam's Journey gibt es nur sehr wenige original C64 Titel in dieser Klasse.


    Sam ist wirklich ein ausgesprochen guter Titel, aber ich würde schon sagen, dass die C64-Bibliothek auch noch sehr viele weitere gute Titel in dieser Klasse hat (z.B. EnforceR oder überhaupt Games von Manfred Trenz)

    Oh, damit bezog ich mich ausschliesslich auf homebrew, natuerlich. Ansonsten gaebe es da durchaus einige.