Beiträge von Grandro

    Ich glaube das, was du erreichen willst, wird eher mit einem CanvasLayer gelöst.

    CanvasLayer bewirkt, dass dessen Children statisch am Bildschirm und nicht auf der Karte "kleben".


    Die Kamera machst du dann einfach als children des KinematicBodies des Spielers und setzt einen Haken bei "current".


    Aber grundsätzlich zu deiner Frage: Ja, das würde auch gehen, ist aber in dem Fall unnötig kompliziert.

    Mein erstes Godot-Projekt

    Bestimmt haben manche von euch schonmal den Godot-Editor gestartet, ohne bösen Hintergedanken ein neues Projekt erstellt und dies zum bearbeiten geöffnet... Doch dann kommt die Frage: Was mache ich jetzt?

    Dieser Beitrag soll dazu dienen, diese Frage in eine weniger verzweifelte Lage zu rücken.


    Godot Engine arbeitet mit sogenannten "Szenen": Die meisten werden vermutlich denken, dass Szenen quasi nur als verschiedene Karten gebraucht werden, auf denen sich der Spieler bewegt, wie es zum Beispiel beim RPG Maker der Fall ist, aber dem ist nicht so. Der Spieler kann zum Beispiel selber eine Szene sein, welche dann auf einer anderen Szene instanziiert oder einfacher, platziert wird.


    Bei Kartenwechsel würde man also eher überlegen den alten Spieler zu löschen und auf der neuen Szene einfach einen neuen Spieler zu platzieren, als man im spielerischen Sinne wohl denkt, dass der Spieler teleportiert wird.

    Oder man hat einen Gegner, welcher andere Gegner auf der Karte spawnt, hier würde man die Szene des neuen Gegners einfach in die momentane Szene instanziieren, quasi Duplikate erschaffen.



    Gucken wir uns doch zunächst einmal die oberste Leiste an. Hier kann man wählen zwischen


    2D: Zeigt die 2D Ansicht der momentanen Szene an (2D-Spiele sind für Einsteiger empfehlenswert).

    3D: Zeigt die 3D Ansicht der momentanen Szene an.

    Script: Zeigt den Script-Editor an.

    AssetLib: Öffnet einen Libary Store, in dem man sich kostenlos Ressourcen oder vorgefertigte Demo-Projekte herunterladen kann.


    Weiter rechts findet man dann


    Pfeil: Startet das Projekt mit der ausgewählten "Anfangsszene".

    Stopp: Pausiert die Anwendung des Projektes (Spiel muss gestartet sein).

    Abbrechen: Stoppt die Anwendung des Projektes (Spiel muss gestartet sein).

    Filmklappe mit Pfeil: Startet das Projekt mit der momentan geöffneten Szene.

    Filmklappe mit Ordner: Tool um Szenen schnell zu starten, wird aber meistens nicht gebraucht...


    Wenn wir nun aber versuchen durch Drücken auf den Pfeil unser Spiel zu starten, erhalten wir folgende Meldung:



    Abbruch, die Engine ist verbuggt... schnell noch zu Unity wechseln...


    Nein ^^ Godot möchte uns nur höflich darauf hinweisen, dass er gar nicht weiß, mit welcher Anfangszene er das Projekt nun starten soll. Und wir wollen ja nicht, dass der Computer entscheidet womit unser vollkommenes Spiel beginnt... Versuchen wir uns also eine Test-Szene zu erstellen, welche dann standardmäßig jedesmal gestartet wird, wenn wir auf diesen lustigen Pfeil klicken:


    Deshalb müssen wir erst einmal eine Szene abspeichern, bevor wir diese dann als "Anfangszene" festlegen können. Wenn wir dies nun aber versuchen, kommt folgende nette Meldung:


    Hmmm... Eine Wurzel... Und damit herzlich Willkommen zu meinem Kräuterkundeunterricht!


    Doch womit uns Godot eigentlich konfrontieren möchte, sind sogenannte "Knoten", oder wie sie unser englischer Freund nennen würde: "Nodes"!


    Nodes bilden quasi unseren Werkzeugkasten für jede gelungene Szene: Es gibt für fast jede Funktion ein dafür angefertigtes Node!

    So wie der Automechaniker also zum Schraubenschlüssel greifen würde um eine Schrauber festzuziehen, greift der Informatiker zu einem Sprite-Node, wenn er eine Grafik anzeigen lassen will.

    Praktischerweise sind diese Nodes auch noch in Farben unterteilt um grob eingliedern zu können, in welchem Bereich man sich gerade befindet:


    Blau: Node2D. Alle Nodes welche zu dieser Gruppe angehören sind dafür bestimmt im 2D-Umfeld verwendet zu werden und zeichnen meistens auch etwas auf den Bildschirm (Bsp.: Sprite-Node)

    Sie haben eine Position und sind somit in der Szene verschiebbar


    Rot: Spatial. s. Blau nur für 3D


    Grün: Control. Wie der Name schon sagt sind alle Nodes dieser Gruppe für Steuerung zuständig


    Tiefer ins Detail will ich da auch nicht gehen... Ich empfehle einfach sich im Internet über die einzelnen Nodes explizit zu informieren. Denn man weiß nur was man machen kann, wenn man weiß was man hat ;)


    Erstellen wir also einfach ein Node. Ein graues Node ohne jegliche Funktionen als einfach nur da zu sein. Es hat keine Position, ist somit unbewegbar, und dient quasi nur als "Vater" welcher dann irgendwann über seine kleinen "Kinder"-Nodes wacht. Dieses Node können wir nun mit einem Doppelklick darauf umbenennen. Es empfiehlt sich einen Namen zu wählen welcher die Szene gut zusammenfasst, in unserem Fall wäre "game" sicher ganz passend...


    Wenn wir das nun also endlich hinter uns haben, können wir nun die Szene abspeichern (Über effektive Dateistrukturen bei Godot-Projekten komme ich vielleicht wann anders zu sprechen...) und sie beim Drücken auf den Pfeil dann als Hauptszene auswählen. Nun sollte sich ein Fenster öffnen, bei dem nichts anderes als ein grauer Bildschirm zu sehen ist. Keine Fehler... Schön, wird haben etwas erreicht! Unser Spiel ist bugfrei!

    Doch was wird nur passieren, wenn wir uns selbst ein kleines Script basteln?... Mir graut es schon...


    Scripting


    Godot Engine kann man in 2 verschiedenen Varianten downloaden:

    - Standard (GDScript, wird von mir immer verwendet)

    - Mono Version (C# Support)


    Die Mono Version ist glaube ich noch nicht komplett ausgereift, aber viel habe ich mich damit nicht beschäftigt...


    Doch wo liegt nun der Unterschied?

    GDScript ist eine Programmiersprache, welche extra für Godot entwickelt wurde. Sie ähnelt dabei sehr stark Python.

    C# ist eine andere populäre Programmiersprache welche eben bei Leuten welche schon programmieren können gerne verwendet wird.


    Ich kann da nicht viel sagen, ich weiß aber das es einen leistungstechnischen Unterschied gibt bei logischen Operationen bei GDScript gegenüber C#.

    Wer also eine Schach KI zum Beispiel oder eine Echtzeitsimulation entwickeln will, versucht wohl besser mit der C# Version klar zu kommen. Ansonsten merkt man diesen Unterschied allerdings nicht.


    Erstellen wir also unser erstes GDScript-Script-Script..Scr... GDScript-Script!


    Dazu klicken wir auf unser "game"-Node und dann auf die Schriftrolle mit dem grünen Plus oben rechts. Nun öffnet sich ein Optionsfenster, welches wir allerdings unberührt lassen können.

    Wir müssen aber bei "Pfad" unser Script irgendwo abspeichern, es empfielt sich dieses Script irgendwo in der Nähe der Szene abzuspeichern, damit irgendwann kein Tohuwabohu entsteht...


    ('#' Sind in GDScript Kommentare)


    extends Node: Dieses Script erbt von diesem Node-Typ. Eigenschaften, Funktionen... Wird immer benötigt um auf die Funktionen der spezifischen Nodes zuzugreifen. (Heißt dann aber je nach Node anders!)


    func _ready(): Funktion welche jedes Node besitzt: Sie wird aufgerufen wann immer das Node in der Szene instanziiert ist und quasi "betriebsbereit" ist.


    func _process(delta): Funktion welche jede Frame aufgerufen wird. Delta wird verwendet um eine Zeitkonstante zu haben und beinhaltet die Zeit, welche seit dem letzten Frame vergangen ist.


    pass: Eine Funktion muss Befehle beinhalten. Dieses Statement dient jediglich dazu einfach nichts zu tun, umgeht aber den Syntax-Fehler, welcher ohne dieses Statement entstehen würde.


    Dieses Script macht nun genau soviel wie unser Spiel: Nichts.

    Wenn wir aber unser berühmtes "Hallo Welt"-Script erstellen wollen, säe das wie folgt aus:


    Code
    1. extends Node
    2. func _ready():
    3. # Node ist bereit, bist du es auch?
    4. print("Hallo Welt!")


    print: Schreibt etwas auf die Konsole (In dem Fall: "Hallo Welt!")


    Nun können wir unten auf unserer Konsole eben diesen Hilfeschrei unseres Programmes begutachten und uns laut auf die Schulter klopfen: Wir haben es geschafft. Es tut!


    Nachdem unser erstes Godot Projekt diesen Meilenstein überwunden hat, frage ich mich wo es unser unschuldiges Projekt wohl als nächstes hinziehen wird...

    Herzlich Willkommen im Forum :)


    Zu dem Problem wendest du dich am besten direkt an den VD 2 Remake Thread, da sollte dir am besten geholfen werden können.

    Vampires Dawn 2 Remake - Everlasting Blood (Version 1.9!)

    Bitte beachte: Man kann dir am besten helfen wenn du dein Problem so gut wie möglich beschreibst:


    Was hast du vor dem Absturz gemacht?

    Was ist der Absturzfehler? (Detailliertere Beschreibung durch Drücken von F8 bei der Absturzmeldung)

    Andere Informationen die zur Behebung des Problems hilfreich sein könnten


    Ansonsten wünsche ich dir hier viel Spaß!


    Ich habe weiter an meinem Schach-Spiel gearbeitet. Man kann nun:


    1) Speichern und Laden

    2) Jeden davor gezogenen Zug zurücknehmen


    Zudem ist jede Regel die in Schach existiert bereits eingebaut, wodurch ich "nur noch" eine KI und einen Online-Modus einbauen muss.

    Die KI geht einfach nach Prioritäten:


    1) Spieler rausschlagen

    Da es dem Gegner am meisten bringt, wenn er den Spieler schlägt, überprüft er ob er den Spieler schlagen kann.


    2) Essen einsammeln

    Da es das Ziel ist für den Gegner Essen einzusammeln, guckt er ob er das tun kann.


    3) Essen einsammeln vorbereiten

    Wenn der Gegner weder den Spieler noch Essen einsammeln kann, bereitet er das Essen einsammeln vor, indem er auf ein Feld zieht, bei dem er als nächstes Essen einsammeln kann


    4) Zufälliger Zug

    Wenn alles nicht funktioniert, macht er einen zufälligen Zug


    Bedingung aller Züge: Gegner darf nicht vom Spieler geschlagen werden dürfen, nachdem er gezogen hat!


    Da das aber zu einer unbesiegbaren KI geführt hat, musste ich noch eine Fehlerrate einbauen. bei der der Gegner dann ignoriert ob er vom Spieler rausgeschlagen werden kann oder nicht.

    Also ist es möglich, dass er einen Fehler macht, das muss aber nicht zwingend der Fall sein.


    Sonst kann ich dazu nicht viel sagen. Das Projekt ist sowieso Open Source, aber ich glaube man kann da nicht soviel raus ziehen.

    Der MV war leider noch nie der hellste Stern am Himmelszelt, was Leistung betrifft.


    Im Grund genommen ist der MV nur ein Browser mit einer sehr veralteten Chromium Version (Auch wenn die ab 1.6.0 wohl mal upgedated wurde).

    Ich fürchte, da lässt sich nichts verbessern.

    Es würde sich vielleicht nochmal lohnen die Preise zu aktualisieren und zu erwähnen, dass man beim MV die Bildschirmgröße via Plugin verändern kann.


    Edit: Ich habe gerade gemerkt, dass die Preise aktuell sind :S


    Das Spiel wird über den Editor geöffnet nehme ich an? Der Debug Mode funktioniert nämlich logischerweise nur im Playtest.


    Und andere Tasten wie Esc, F2, F4, F5, F8 funktionieren?


    Irgendwelche Plugins installiert?


    Sonst kann es sein, dass du den Editor auf die Version 1.6.1 geupdated hast, dein Projekt aber immernoch auf einer älteren Version ist:


    https://forums.rpgmakerweb.com…6-1-stable-release.96715/

    Zitat

    Everyone, please read the instructions carefully. The bugs that are being reported shouldn't happen if the correct files were even copied properly. Such examples like the "CTRL BUG" shouldn't happen if you copied index.html, package.json, the rpg*.js files and so on.


    https://forums.rpgmakerweb.com…6-1-stable-release.96715/


    Dort siehst du wie du dein derzeitges Projekt auf die Version 1.6.1 updatest, und vergiss bitte nicht ein Backup zu machen!

    Der Origin Wert ist nicht so wie du ihn dir vorstellst:


    Er kann nämlich nur 2 Werte haben, entweder 0 oder 1:


    0: Verankerung links oben

    1: Verankerung in der Mitte


    Auch kannst du nicht von der Größe der Karte ausgehen um den Mittelpunkt zu setzen, ein Bild wird nämlich nicht auf der Map angezeigt sondern statisch auf dem Bildschirm.

    Du musst dir also die Bildschirmgröße angucken.


    Wenn du also die Standardmäßige Auflösung hast sind die Werte bei dir:


    X: 816

    Y: 624


    Die Hälfte davon wäre:


    X: 408

    Y: 312


    Nun sollte folgender Scriptcall funktionieren:


    Code
    1. var ID = 6;
    2. var name = "Stern";
    3. var origin = 1;
    4. var x = 408;
    5. var y = 312;
    6. var scalex = 100;
    7. var scaley = 100;
    8. var opacity = 255;
    9. var blendmode = 0;
    10. $gameScreen.showPicture(ID, name, origin, x, y, scalex, scaley, opacity, blendmode);

    Mr. Fu Keinesfalls. Die Variablen werden mit var deklariert und sind somit nur für den Scope des Scriptes vorhanden.


    Problematisch wird es erst wenn das Script nicht mehr in einen Script-Command reinpasst, wo es sich lohnen würde alles so kurz wie möglich zu halten.

    Dies ist hier aber nicht der Fall.


    Hintergrund dass ich alles einzeln aufgelistet habe war einfach, dass man beim editieren immer weiß welcher Wert für was steht bei der Bildanzeige.