Ergebnis 1 bis 5 von 5

Thema: To grid or not to grid?

  1. #1

    To grid or not to grid?

    Ist zwar keine akute Frage, aber als ich mal mit dem Gedanken gespielt habe ein grundlegendes (j)RPG-System zu programmieren kam mir die Frage auf und ich hab damals keine finale Entscheidung treffen können.

    Sollte der Protagonist (und ggbf. sein Gefolge) gridbasiert herumlaufen oder komplett frei losgelöst von einem Grid.

    Vorteile die ich in einem Grid sehe:
    - Man ist immer automatisch an 1-Tile breiten Gängen/Türen ausgerichtet und trifft diese entsprechend mühelos ohne an Kanten hängen bleiben zu können.
    - Beim interagieren mit NPCs und Gegenständen ist immer eindeutig klar wem die Aktion gilt.

    Vorteile bei Verzicht auf ein Grid:
    - Diagonales (45°) Laufen oder auch gänzlich freies erkunden via Analogstick möglich.
    - Entsprechend besser geeignet für Realtime Action Kampfsysteme ala Zelda/SoM.
    - Präzisere Sprung/Lauf Passagen wo es um Geschicklichkeit geht umsetzbar, da die Steuerung sehr direkt und pixelgenau kontrollierbar ist.

    Wenn es um ein Zelda-artiges Spiele mit Echtzeitkämpfen geht stellt sich mir die Frage nicht, aber könnte/sollte man bei einem klassichen jRPG mit rundenbasierten Kämpfen aufs Grid verzichten oder überwiegen da die Vorteile die damit einhergehenden Einschränkungen.

  2. #2
    Also das Raster kann meiner Meinung nach ruhig weg. Zweckmäßig wird's aber wohl erst nachdem auch die Umgebung nicht nur im Rasterschema begehbar ist (Tilesets ok, aber nicht alles nimmt die ganze Fläche ein).
    Engen Gängen kann man entgegenkommen, indem die Spielfigur selber nicht ein ganzes Tile einnimmt (zumindest in der Kollisionserkennung, optisch egal) und die Steuerung nicht alle gedrückten Richtungen blockiert nur weil es in einer nicht weiter geht. Man könnte auch so weit gehen, dass der Spieler quasi um Ecken flutscht, aber das fand ich in meinen Fällen bisher nicht nötig.

    Überlappende Interaktionen sind bestens komplett vermieden, aber als Kompromiss wäre es wohl gut das am nächsten stehende Objekt zu bevorzugen (gemessen von der unteren Mitte der Kollisionsmaske die man hoffentlich hat).

    Wobei man richtig enge Passagen und überlappende Interaktion auch einfach im Designprozess vermeiden könnte.


    Raster machen Sinn wenn es um präzise Positionierung geht. Auf Distanz oder für mehrere Einheiten ist es sonst doch nicht so einfach in einer sauberen Reihe zu bleiben.
    Es ist auch eindeutiger ob ein Weg passierbar ist oder nicht. Das geht aber wieder mit dem Designprozess einher.


    Letztendlich ist keine der Varianten für ein klassisches Rundenbasiertes RPG ein Beinbruch.
    Rasterbasiert könnte eventuell sogar etwas mehr Aufwand bedeuten, wenn man es von Grund auf selber schreibt (Pixelposition zum Rendern + Rasterposition + laufende Zwischenbewegungen). Ist aber nur meine grobe Einschätzung.

  3. #3
    Ich denke Raster-Bewegungen können bei Action-Komponenten ein Hindernis sein. Also ich denke man ist da wesentlich eingeschränkter wenn man komplexere Situationen einbauen möchte die Geschick abfragen.
    Dafür kann man derlei Einschränkungen besser akkumulieren wenn es darum gesteht Puzzles zu designen, ich denke da macht eine Rasterbewegung durchaus Sinn.

    Bei Rollenspielen mit rundenbasierten Kampfsystemen die bestenfalls noch auf einen anderen Bildschirm stattfinden, ist es mir persönlich egal ob ich mich auf einen Grid bewege oder frei herumlaufe. Wenn aus der freien Bewegung ja letztlich doch nichts gemacht wird, außer dass man genau so durch die Gegend läuft um mit NPC's zu quatschen, finde ich sie auch nicht wirklich besser oder angenehmer. Ich glaube Pokemon hat ja irgendwann diesen Wechsel vollzogen bei 3D Umgebungen. Hat sich da irgendwas an den Spielen und der Erkundung verbessert? Habe ich nicht das Gefühl.

  4. #4
    Ausgegangen von einem Spiel in der üblichen Maker-Perspektive, würde ich nur dann zu einer pixelgenauen Bewegung greifen, wenn sie absolut notwendig ist. Und vielleicht nicht mal dann, wir haben ja schon öfters Action-Kampfsysteme mit dem Raster umgesetzt.

    Geändert von Kelven (01.05.2022 um 09:24 Uhr)

  5. #5
    Ja, wenn man von einem rundenbasierten KS auf einem gesondertem Screen ausgeht und es außerhalb davon neben der Erkundung der Spielwelt und dem ein oder anderen Schalter/Schieberätsel wenig Gameplaymechaniken gibt bleibt eigentlich nur noch das "Freiheitsgefühl" auch mal querfeldein schräg laufen zu können um ein wenig die Laufwege abzukürzen. Ob dies alleine es wert wäre?

    Zitat Zitat von Kelven Beitrag anzeigen
    Ausgegangen von einem Spiel in der üblichen Maker-Perspektive, würde ich nur dann zu einer pixelgenauen Bewegung greifen, wenn sie absolut notwendig ist. Und vielleicht nicht mal dann, wir haben ja schon öfters Action-Kampfsysteme mit dem Raster umgesetzt.
    Ja, Action-Kampfsysteme im Raster hat man in einigen RPG-Maker Games gesehen und sie funktionieren (halbwegs), aber war das nicht mehr ein "mit den Einschränkungen des RM2Ks leben" als eine bewusste Design Entscheidung? Vorteile sehe ich da keine, eher Nachteile was "clumsy Kämpfe" sowohl im Nah- las auch Fernkampf angeht.

    Mit der "üblichen Maker-Perspektive" sprichst du aber was wichtiges an. Ich hab damals tatsächlich mit einer isometrischen Pixelartperspektive geliebäugelt. Daher mit Grid würde man ausschließlich diagonal laufen und die Richtungstasten würden nicht exakt mit der Laufrichtung übereinstimmen. Könnte sein, dass das der Knackpunkt war was mich dazu hat tendieren lassen auf die Gridbewegung zu verzichten. Wobei es vllt auch doch Vorteilhaft ist mit nur einer Richtungstaste parallel zu den (meisten) Wegen und Wänden laufen zu können, da die Spielwelt entsprechend um 45° "gedreht ist" und alle Geraden-Wege und Wände dann schräg verlaufen.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •