Werbung

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Point and Click adventure - Schulprojekt

Dieses Thema im Forum "Pascal" wurde erstellt von SammySam, 10. Januar 2018.

  1. SammySam

    SammySam New Member

    Hey, wir müssen im Unterricht nun ein Programm erstellen und da haben wir uns dummerweise für ein kleines Point and click adventure entschieden, wenn man es so will.
    Gibt es eine nette Seele, die bereit für spezifischere Fragen wäre und diese auch wirklich beantworten kann? Also ein Pascal-Spezialist, wenn man so will..

    (Wir wollen nur ein paar Anhaltspunkte, kein vollständig geschriebenes Programm bekommen :x)
  2. coding-board

    coding-board Member

    Werbung
  3. Xpyder

    Xpyder Active Member c-b Experte

    Falls die Anfrage hier noch aktuell ist (sollte sich ja nach 10 Tagen nicht schon erledigt haben?), gebe ich hier mal meinen Senf dazu:

    Da ich seit ca. 25 Jahren in Pascal (und seit knapp 20 Jahren auch Assembler unter Pascal) programmiere, denke ich, daß ich hier VIELLEICHT helfen könnte.

    Aber: Ich programmiere in Turbo Pascal 7 von Borland, unter MS-DOS.

    So, zuerst einmal: Bedenkt man, wieviel Zeit man normalerweise für ein Schulprojekt bekommt, wird das für ein Vorhaben wie "Point and Click Adventure" ziemlich knapp werden.

    Denn: Egal wie groß/klein bzw. lang oder kurz ein SPIEL wird, so gibt es immer auch einen Entwicklungs-Anteil dabei, der gleichbleibend lang ist.

    Was braucht man? Naja, wenn es Point&Click werden soll, wird das Ganze wohl grafisch werden müssen - es sei denn, Ihr wollt das Ganze in grob"pixel"igen Textmode-Bildern machen.
    Also muß man einen Grafikmodus setzen können und wissen, wie man Pixel darin setzt. Es gäbe hier die relativ einfache Variante des Modus $13 (hex), auch MCGA-Mode genannt: Auflösung 320x200 Pixel, bei 256 Farben. Pixel setzen wäre relativ einfach, weil man quasi nur über den Grafikspeicher ein großes zweidimensionales Array legen müßte.

    Natürlich kann man mit VESA-Modi größere Auflösungen hinbekommen und mit diversen VGA-Tricks kann man eventuell auch ziemlich coole Dinge machen - aber dazu braucht man auch etwas Ahnung - und Borland-/Turbo-Pascal ist, was Grafik angeht, ziemlich dürftig ausgestattet, um es mal milde auszudrücken.

    So, weiter im Text: Ihr braucht "Sprites". (Weil es Software-Sprites wären, eigentlich korrekt "Shapes" genannt). Wieso? Naja, normale PC-Grafikkarten haben keine Hardware-Sprites (außer manchmal einen Mauszeiger).

    Wofür? Naja, zumindest der Pfeil/Fadenkreuz/wasauchimemr Ihr zum "Pointen und Clicken" nehmen wollt, muß ja da sein. Außerdem wahrscheinlich auch herumlaufende Figuren. (Es gibt allerdings auch Adventures mit Standbildern, die trotzdem Point&Click sind.)

    Das heißt, FALLS es herumlaufende Figuren (zumindest der vom Spieler gesteuerte Charakter) sein sollen, muß man diese als kleine "Daumenkino"-artige Grafiken in einem Malprogramm basteln und im Bild darstellen - dabei eine der Farben als "durchsichtig" definieren, damit man die -eigentlich rechteckigen- "Sprite"-Bildchen nicht als Rechtecke sieht, sondern nur die Figur und nicht das "Drumherum". Die Einzelbilder wären dann z.B. eine Schrittbewegung, damit es so aussieht als würde die Figur laufen.
    D.h. so werden die dann ins Bild gepixelt. Vorher muß man natürlich jedes Mal das Stück Bild irgendwo speichern, wo die Figur hingesetzt wird, damit, wenn sie sich wegbewegt, das Bild wiederhergestellt werden kann. (Es gibt auch noch die Methode, das Bild bei jeder Änderung komplett neu in den Grafikspeicher zu kopieren mit den Sprites - und auch noch andere Methoden, die etwas komplizierter sind.)

    Der "Zeiger", also das, was auf die Gegenstände/Figuren usw zeigt, ist quasi auch ein Sprite - der muß immer als letztes "oberstes" dargestellt werden, weil er alles im Bild "überdecken" muß.

    Soweit also nur zur Technik der Grafik. (Die Hintergründe, also die "Welt" muß natürlich auch irgendwo gezeichnet werden.)

    Dann kommen wir zum Anklicken der OBJEKTE. Solange ein OBJEKT ein Sprite ist, braucht man nur prüfen, ob der "Zeiger" wenig genug Abstand zu einem OBJEKT hat - dann ist es "anklickbar" (wie sowas geht, sollte klar sein).
    Wenn die OBJEKTE Teil des "Hintergrund"-Bildes sind, und nicht extra als Sprite gemacht werden sollen, muß man zusätzlich zum Bild noch ein "virtuelles Bild" im Speicher haben, das vielleicht etwas "grobpixeliger" sein kann, z.B. 80x50 oder 40x25 "Pixel".. Diese enthalten nur für die ungefähre Fläche, so sich auf dem Bild ein anzuklickender Gegenstand oder Person (also ein OBJEKT) befindet, die Nummer des Gegenstands. (Ja, Personen werden hier zum Objekt reduziert...)

    Desweiteren - wenn man es "cool" haben will - kann man so auch "Wege" im Bild festlegen, die die Figur nehmen kann, d.h. daß sie nicht überall durch gedachte Gegenstände laufen kann - es gibt auch Techniken, wie die Figur "hinter" den Bildobjekten entlanggehen kann - außerdem gäbe es auch die Möglichkeit, solchen Wegstücken eine "gedachte Entfernung" zuzuweisen - so daß die Spielfigur, wenn sie weiter "hinten" im Bild ist (es ist ja eigentlich nur 2D!), kleiner dargestellt wird, um diesen räumlichen Eindruck zu simulieren. Das setzt natürlich voraus, daß die Sprite-Darstellungs-Procedure sowas auch hergibt.

    Achja: Bei der Darstellungs-Procedure am besten gleich die Möglichkeit zum Spiegeln (zumindest horizontal) einbauen - da Lebewesen ja, biologisch bedingt, meist "symmetrisch" sind, braucht man so nur Laufen/Stehen usw. in EINER der beiden Richtungen animieren und für die andere nimmt man die gespiegelten "Bilder". (Spart übrigens auch Speicher.)

    Das wäre erst einmal die billige grobe "Mechanik", die so ein grafisches Point&Click-Adventure braucht, damit es erst einmal ein solches werden kann. Über das Spiel selbst (d.h. den "Adventure-Teil", ist dabei noch gar nichts gesagt worden.

    Der Adventure-Teil besteht aus einer Liste - ein großes Array also.
    In diesem Array sind Kombinationen von Aktionen und Objekten vermerkt. Eine Aktion ist eins der Adventure-Verben. (Je mehr Verben man unterstützt, umso mehr Fälle muß man berücksichtigen.) Verben sind so etwas wie GEHE, NIMM, GIB, SCHAU, BENUTZE, REDE, ZIEHE, DRÜCKE, usw.
    Objekte sind alle Gegenstände UND Figuren, mit denen man irgendwie interagieren kann. Selbstverständlich, da wir uns in einem Computer befinden, sollten sowohl Aktionen als auch Objekte intern als Zahlen verwaltet werden, das macht es einfacher.
    Wird nun eine AKTION und dann ein OBJEKT angeklickt, ergibt sich eine Kombination aus beiden.

    Die Liste wird nun jedesmal, wenn sich durch Klicken so eine Kombination ergeben hat, nach einer gültigen Kombination ivon AKTION und OBJEKT durchforstet - am besten von hinten. Die Erklärung dafür ist einfach: An den Anfang der Liste einfach für alle Aktionen ein Dummy-Objekt (0 oder -1 oder $FFFF oder wasauchimmer) setzen. Dann wird, falls keine Kombination gefunden wird, die mit dem Dummy-Objekt benutzt und bei NIMM kommt dann z.B. die REAKTION: "Das kann ich nicht nehmen." Dann braucht man nicht alle möglichen und unmöglichen Kombinationen ("REDE MIT SCHAUFEL") unterstützen.

    Die Liste hat also pro Index mindestens 3 Einträge:
    AKTION, OBJEKT, REAKTION.
    Die Reaktion ist ein "Unterprogramm", das dann aufgerufen wird, wenn die entsprechende Kombination gewählt wurde.
    (Im Point&Click Adventure wird normalerweise das Verb, also die AKTION angeklickt, dann das OBJEKT. Man kann es auch umgekehrt machen oder so, daß z.B. ein Verb IMMER Standard ist, z.B. GEHE ZU. oder daß wenn man jedem OBJEKT noch intern ein Standardverb zuweist, das automatisch aufleuchtet -
    und dann genommen wird, wenn man die rechte Maustaste statt der linken benutzt... Wie komfortabel man das machen will, muß man selbst wissen...

    Die coolen Leute haben dann noch die AKTION "BENUTZE" zur "Super-Aktion" gemacht, indem jedem OBJEKT (oder jeder Kombination, die BENUTZE enthält) ein Flag (Bit) mitgegeben wurde, die auch 2 OBJEKTE erlaubt (der Satz wird dann so ergänzt: "BENUTZE SCHAUFEL MIT" und wartet noch auf ein zweites OBJEKT, bevor er in die Kombinationsliste zum Suchen wechselt.

    So, nun zu den REAKTIONEN:
    Im Normalfall baut sich jeder, der ein größeres Adventure machen will, dazu eine Art Skript - weil man sonst wahnsinnig wird. Man müßte sonst jede REAKTION einzeln einprogrammieren, das artet in Arbeit aus. (Nicht, daß ein Spiel zu machen nicht sowieso generell schon in Arbeit ausarten würde!)

    So ein Skript besteht aus einfachen "Befehlen", die irgendwelche Dinge tun können, z.B. die Spielfigur irgendwo hin laufen lassen, ein neues Bild (also neuen "Raum") laden, einen Gegenstand ins INVENTAR legen oder daraus entfernen, eine der Figuren etwas sagen lassen (wohl eher Textausgabe, es sei denn, Ihr wärt so verrückt, da auch noch Sprachausgabe einbauen zu wollen). Für dieses Skript baut man einen einfachen Interpreter, der alle möglichen Aktionen, die im Skript festgelegt werden können, ausführen kann. Das sieht dann aus wie die "einfachste Programmiersprache der Welt".

    Achja: Für Textausgabe im Grafikmodus sollte man vielleicht auch eine Procedure bauen - man wird es sicher irgendwann brauchen.

    Das INVENTAR kann man auf zwei Arten realisieren: Entweder man gibt jedem OBJEKT ein "Flag" (ein Bit), ob es sich gerade im INVENTAR des Spielers befindet oder nicht - in diesem Fall haben die OBJEKTE bei der Anzeige immer die gleiche Reihenfolge; die nicht im INVENTAR befindlichen OBJEKTE werden dann bei der Anzeige "übersprungen"...
    Oder, man macht es für den Spieler etwas "naheliegender", indem man dem INVENTAR ein eigenes Array spendiert und darin die Nummern der OBJEKTE vermerkt. Auf die Art könnte man Objekte in der Reihenfolge anzeigen, in der der Spieler sie erhalten hat. (Werden dazwischenliegende Objekte später entfernt, muß man dann die restlichen "eins hoch" kopieren. Man kann hier natürlich stattdessen auch mit sogenanntem "Daisy-Chaining" verketten - da muß man aber aufpassen, damit man sich nicht vertut.)

    Achja: Auch über Klangausgabe (Geräusche, eventuell Musik) nachgedacht? Muß nicht sein, aber dann ist es eben still im Raum.

    Ich sag's mal so: Ich habe (in den letzten Jahren/Jahrzehnten selbstprogrammiert) ALLES hier, was man zum Bauen eines Point&Click Adventures (sowie jedes anderen denkbaren 2D-Spiels und auch einfachen 3D-Spiels) brauchen würde, vieles davon auch in Teilen in Assembler, aus Speicher- / Geschwindigkeitsgründen. Alles in meinen vielen Pascal-Units:
    Grafik/Grafikmodes (VGA/VESA), Farbpaletten, Sprites (skalierbar, drehbar, spiegelbar), Textanzeige, dynamische Speicherverwaltung, Soundausgabe über Sound-Blaster (und kompatible) und PC-Speaker("digital" per PWM), natürlich auch Sounderzeugung (Musik, Effekte) dazu. Außerdem ein Steuerskript in 100% Assembler, das auch automatische Kollisionsabfragen unterstützt... und vieles mehr... Dazu Malprogramme, Level-/Sprite-Editor, Musik-/Soundeditor... Tja, was man nicht alles macht, wenn man sonst keine Hobbys hat.

    Aber naja, ich selbst lasse mir mit meinem nächsten Spiel noch Zeit (baue gerade wieder an zwei Dingen, die ich noch gerne hätte) und ich frage schon gar nicht mehr, so wie früher, bei Leuten herum, ob jemand mit mir zusammen Spiele machen will: Wer will schon ein Spiel für MS-DOS machen heutzutage (das bis maximal Windows XP lauffähig wäre)? Den meisten geht's ja nur um Ruhm und Geld, Hauptsache den eigenen Namen unter 'nem fertigen Spiel haben und dann am besten als "APP", damit einem die Leute dafür auch noch Geld hinterherwerfen.... die ganze Arbeit daran kann ja dann ruhig jemand anders machen... seufz...
    -- egal --

    Tja, also soweit dazu.
    Seid gewahr, daß so Adventures - so lustig sie auch aussehen und zu spielen sind, sobald sie erstmal fertig sind - eine Menge Arbeit gemacht haben: Die ganzen Grafiker und Skripter und Texter, die Musiker und nicht zuletzt die Programmierer haben da eine Menge Zeit und Mühe reininvestiert in jedes dieser Spiele, das ist nicht "in drei Wochen gemacht" - außer man hat vielleicht so 3 WIRKLICH ENGAGIERTE LEUTE, die jede freie Minute ihrer Zeit am Rechner sitzen, um zu programmieren, pixeln, skripten, komponieren: Dann könnte es VIELLEICHT ein KLEINES Point&Click-Adventure werden.
    beepsoft und -AB- gefällt das.
Die Seite wird geladen...