Neue SCUMM-Engine für C64

Es gibt 76 Antworten in diesem Thema, welches 13.653 mal aufgerufen wurde. Der letzte Beitrag (3. Oktober 2008 um 17:31) ist von matthes.

  • Zitat

    Mal so zum Aufbau: Der Bildschirm müßte ja wieder Splitscreen sein, also oben Multicolor Grafik und unten Hires für Text. Die Verben sollten auf 9 reduziert werden, also Schau, Öffne, Schließe, Nimm, Gib, Benutze, Drücke, Ziehe, Rede. Die Verben sollten wie in Monkey Island links angeordnet werden, das Inventar rechts. Ist übersichtlicher als die zwei Zeilen unten.

    ich persönlich würde mich was aufbau der engine und bedienung angeht an monkey island 3 orientieren, das vereinfacht einiges und tut dem spielspass keinen abbruch.

    aber: auch das sind details ... :)

  • Nee, die Monkey 3-Version ist nicht so toll. Man kann zwar noch damit umgehen aber naja ja... In Sam&Max war's noch schlimmer. Die tollen Satz-Konstrukte aus den LucasFilm Games sind einfach immer genial. Beispiel: Benutze fiese Friteuse mit sauhund :bussi:

  • Zitat

    Nee, die Monkey 3-Version ist nicht so toll. Man kann zwar noch damit umgehen aber naja ja... In Sam&Max war's noch schlimmer. Die tollen Satz-Konstrukte aus den LucasFilm Games sind einfach immer genial. Beispiel: Benutze fiese Friteuse mit sauhund

    ich fand monkey 3 ehrlichgesagt mit abstand das beste aus der reihe - gerade weil das interface auf das nötigste reduziert ist.... die ganzen verschiedenen "aktionen" sind von der spielelogik nämlich total unnötig, weil eh immer nur eine davon sinn macht und funktioniert, oder aber verschiedene aktionen eh das gleiche auslösen.

  • Nee, die Monkey 3-Version ist nicht so toll.

    Also ich hab vor zwei Wochen nochmal die ersten 3 Monkey Island Spiele hintereinanderweggezockt und kann nicht nachvollziehen, wie Du zu dem Urteil kommst.

    Mal ganz abgesehen davon, dass - wie sauhund schon korrekt bemerkte - der Großteil des "Parsers" bei MI 1+2 quasi nutzlos ist hat man außerdem:
    - mehr Platz für Spielgrafik
    - weniger Mauswege

    Warum ist das Deiner Meinung nach weniger toll?

  • Monkey 3 selbst habe ich noch nicht durchgespielt, deshalb kenne ich's nicht vollständig. Die Grafik ist witzig, Guybrush kommt cool rüber. Aber das Feeling ist nicht mehr da. Unter einem Scumm-Spiel stelle ich mir halt eben einen Splitscreen mit oben Grafik und unten Text vor. Wenn man C64 hört, werden den meisten sicher auch erst an den Brotkasten denken, nicht an den flachen C64. Den mögen auch viele nicht obwohl er schicker aussieht, und so gehts mir eben mit den Scumm-Versionen. Retro ist eben in, das würde auch für eine neue Scumm-Engine gelten. Die Engine von Monkey 3 hat meiner Meinung nach nichts mehr mit den klasischen LucasFilm-Games zu tun. Die Grafik basiert zudem hauptsächlich auf dem Animationssystem Insane und das wäre auf dem C64 noch schwerer realiserbar, vor allem in Verbindung mit Fullscreen-Grafiken.

    Wenn wie sauhund das sagte bei vielen Verbkombinationen das gleiche passiert, muß man das Spiel eben so schreiben daß das nicht geht. Bei Maniac Mansion und Zak hatte man ja noch sehr viele Verben, wie z.B. Schließe auf, Schalt ein usw. Das war in dem Fall teilweise wirklich etwas nervig weil eben nur diese eine Kombination zum Erfolg führte. Bei dem einen selfmade-Zak2-Game wurden die Verben auf 6 reduziert, das sah doof aus. Die Version mit den 9 Verben wie bei Monkey 2 und Indy 4 war genau richtig. Und jetzt nur mal so: Wenn man die Steuerung von Monkey 3 als Text darstellen würde, sähe das reichlich komisch aus. Normalerweise hat man gar nichts auf dem Bildschirm, allerhöchstens 'Gehe zu'. Bei einem Objekt hätte man dann nur drei Verben, die sich je nach Verwendungszweck ändern. Das ist doch unsinnig, es nimmt dem Spieler viel zu viele Entscheidungen ab. Bei einem Adventure besteht doch der Reiz darin, aus einer größeren Anzahl von Verben eine korrekte Lösung zu erstellen. Das war bereits in Textadventures so. Nur übertreiben darf man es nicht. Und so nebenbei: Bei Monkey 3 konnte man weder Kommandos noch Inventar in Echtzeit nutzen. Man mußte erst immer die Maustaste halten, dann hält das Spiel an und man kann in aller Gemütlichkeit seine Entscheidungen treffen. Die Endzenen in Monkey 2 wo Guybrush schnell auf LeChuck reagieren muß wären so nicht möglich. Eine Interaktion mit dem Inventar wäre z.B. die Voodoo-Puppe (Benutze Spritze mit Voodoo-Puppe) oder wenn man sich mit dem Fahrstuhl schnell LeCucks Bart klauen muß, wenn er davorsteht (Drücke Hebel). Wer nicht schnell genug ist, bekommt mal wieder von LeChuck voodoomäßig eins übergezogen.

    3 Mal editiert, zuletzt von Naquaada (2. Oktober 2008 um 01:15)

  • Eine Interaktion mit dem Inventar wäre z.B. die Voodoo-Puppe (Benutze Spritze mit Voodoo-Puppe) oder wenn man sich mit dem Fahrstuhl schnell LeCucks Bart klauen muß, wenn er davorsteht (Drücke Hebel). Wer nicht schnell genug ist, bekommt mal wieder von LeChuck voodoomäßig eins übergezogen.

    Genau dieser Teil ist jedoch der oft kritisierte, denn Le Chucks unberechenbare Auftritte können schon etwas nerven, und wenn man dann drauf wartet, dauert's manchmal ewig.
    Grundsätzlich gebe ich dir aber Recht. Es gibt auch jede Menge gute Beispiele, wo das ohne Nervfaktor funktioniert: In MI1 die schmelzenden Grogkrüge, den Fisch vor der Möve aufsammeln, Le Chuck mit Malzbier bekleckern, in MI2 das Monokel aufnehmen, den Spuckwettbewerb gewinnen usw.. Mit dem Münzinterface wäre das zwar nicht unmöglich, aber in der Tat nicht das selbe. Ich würde aber auch nicht behaupten, daß es schlechter ist. Beides hat seine Vor- und Nachteile. Echtzeit wäre aber auch nicht das Problem. Man könnte es schließlich so programmieren, daß das Spielgeschehen währenddessen weiter geht.
    Mit der Echtzeit sollte man es aber auch nicht übertreiben, denn wenn es so ausartet wie in Larry 2, wo z.B. das Schiff unwiederbringlich davon fährt, hat das nichts mehr mit Spielspaß zu tun.

  • dieser echtzeitkram nervt total, finde ich. wenn man sowas will soll man doch lieber ein actionadventure basteln.

    und "entscheidungen abnehmen" tut einem dieses 1-aus-3 interface auch nicht wirklich. es bewart einen aber davor bei jedem kack erstmal 10 aktionen durchprobieren zu müssen.


  • Verdammt, an Kompatibilität habe ich jetzt natürlich nicht gedacht. Dabei fällt mir ein: Funktioniert IFFL i.d.R. eigentlich auf einer 1581? Das hab ich nie getestet.

    Man kann auch IFFL so erstellen das die überall laufen.

  • Zitat

    Man kann auch IFFL so erstellen das die überall laufen.

    jein. man würde für jedes laufwerk einen eigenen "treiber" brauchen. sprich es wäre ein heidenaufwand. komplett generisch gehts nicht. (bzw ja klar wäre schon. superlame immer das ganze iffl file von vorne durchackern. DAS will nun wirklich niemand =D)

    davon ab macht iffl auch auf "grossen" laufwerken nicht viel sinn - der zweck des ganzen ist ja eigentlich nur das man ein paar blocks auf disk spart, und/oder etwas das vorher t/s loader war filekopierbar macht. in sehr vielen fällen war und ist iffl einfach quatsch, grade die ersten iffl systeme (die nämlich keine t/s tabelle durch scannen aufbauen sondern sich durch das ganze file ackern) haben fast nur nachteile gegenüber einzelfiles.

  • Als Alternative zu IFFL vielleicht. Das FAT-Problem bleibt aber das selbe.


    Mal abgesehen davon das der Vorschlag nicht ernst gemeint war weil relative Dateien ziemlich starr aufgebaut sind: Wo soll es da ein FAT-Problem geben?

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Mal abgesehen davon das der Vorschlag nicht ernst gemeint war weil relative Dateien ziemlich starr aufgebaut sind: Wo soll es da ein FAT-Problem geben?

    Dann verrate doch mal, mit welchen standardisierten CBM-DOS-Befehl man mitten aus einer Datei lesen kann? Das mal so als Denkanstoß.

    Wir sollten nicht vergessen, daß es viele Massenspeichersysteme mit Festplatte oder SD-Karte gibt (üblicherweise FAT-formatiert), die keine Diskettenlaufwerke emulieren können, und nur die nötigsten Grundfunktionen für Diskettenimages kennen. Deswegen sehe ich keine Alternative, als für jeden nötigen Zugriff eine eigene Datei anzulegen.

  • Dann verrate doch mal, mit welchen standardisierten CBM-DOS-Befehl man mitten aus einer Datei lesen kann? Das mal so als Denkanstoß.


    Wenn es eine relative Datei ist dann mit dem Standard-Befehl P, der als Parameter den Kanal, die Record-Nummer (zwei Byte, high/low) und den Offset innerhalb des Records akzeptiert. Nur weil ein Laufwerk die Daten nicht im Commodore-Diskformat sondern via FAT speichert ist noch lange kein Grund den Befehl sowie relative Dateien nicht zu unterstützen. Im Gegenteil, bei FAT als Speichergrundlage kann man den problemlos so erweitern das er auch für andere Dateitypen funktioniert - IDE64 hat es (ok, mit einem Diskformat) vorgemacht.

    Zitat

    Wir sollten nicht vergessen, daß es viele Massenspeichersysteme mit Festplatte oder SD-Karte gibt (üblicherweise FAT-formatiert), die keine Diskettenlaufwerke emulieren können, und nur die nötigsten Grundfunktionen für Diskettenimages kennen. Deswegen sehe ich keine Alternative, als für jeden nötigen Zugriff eine eigene Datei anzulegen.


    Minderwertige Software... :wink:

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Am einfachsten dürfte es doch wohl sein, wenn man einfach die alten SCUMM-Interpreter umändert anstatt "einfach" alles neu zu schreiben, oder??

    Alles andere wird eh im Sande verlaufen da viel zu aufwendig.... :)

    Hab nur keine Ahnung, wer z.Zt. die Rechte an SCUMM besitzt...Immer noch LucasArts? :gruebel

    Sollte ein fähiger Programmierer der es wirklich ernst meint vielleicht einfach mal nachhaken, ob die das alte C64-SCUMM nicht als open-source freigeben können! Dann hat man wenigstens ein funktionierendes Entwicklertool und niemand muss mehr rätseln wie irgendetwas funktioniert! :prof:

  • Wenn es eine relative Datei ist dann mit dem Standard-Befehl P, der als Parameter den Kanal, die Record-Nummer (zwei Byte, high/low) und den Offset innerhalb des Records akzeptiert. Nur weil ein Laufwerk die Daten nicht im Commodore-Diskformat sondern via FAT speichert ist noch lange kein Grund den Befehl sowie relative Dateien nicht zu unterstützen. Im Gegenteil, bei FAT als Speichergrundlage kann man den problemlos so erweitern das er auch für andere Dateitypen funktioniert - IDE64 hat es (ok, mit einem Diskformat) vorgemacht.

    Immerhin sind die meisten dieser Systeme Open Source, so daß sich jeder daran setzen könnte. Ich denke mal, daß der Mehrwert von REL-Dateien zu gering ist, als daß viele diesem Vorbild folgen werden.

    Hab nur keine Ahnung, wer z.Zt. die Rechte an SCUMM besitzt...Immer noch LucasArts? :gruebel

    Die dürften wohl bei Ron Gilbert liegen. Der hat sie doch auch für Produktionen seiner eigenen Firma noch verwendet, soweit ich weiß. Ob das aber auch für die alte C64-Version gilt? Gute Frage. Von LucasArts werden wir jedenfalls bestimmt keine Quellcodes erleben.

  • Zitat

    Am einfachsten dürfte es doch wohl sein, wenn man einfach die alten SCUMM-Interpreter umändert anstatt "einfach" alles neu zu schreiben, oder??

    nein, im gegenteil. grad die c64 engine ist auch alles andere als generisch, damit wird man nix anfangen können wenn man die engine nicht auch auf codeebene sehr genau kennt.

  • Scheiss auf die neue Hardware fürn C64... Wer sich die gekauft hat ist selber schuld!
    Wenn man das ohne Ladezeiten will kann man doch einfach die vorhadene Scumm-Engine größer Systeme nehmen da gibt es dann auch so gut wie keine Ladezeiten. Vom Feeling gehören die eben zum C64 dazu, also C64 und 1541 Laufwerk dabei dann eben Dreamload oder eben einen anderen Speeder den man aber auch für die neue Hardware abschalten kann. Ich denke das gibt eh nichts, da wenn einem Programmierer sowas wirklich interessieren würde, er sicher so eine Engine schon entwickelt hätte oder noch dran ist an dieser. Davon zu träumen ist zwar schön aber Träume sind Schäume. Von Dr. Zoom gibt es ja zumindest ein Adventure Creator System, damit könnte sich ja hier manche beschäftigen das wäre dann wirklich mal was...