@XRPG:
Hui, danke für das ausführliche Feedback.
Och, das wär ich nicht mal so direkt sagen. Ich habe schon vor allem eine visuelle Sprache verwendet, um daraus selber Vorteile ziehen zu können. Ohne jetzt noch einen Wall-of-Text-Roman zu schreiben, die wichtigsten Punkte für mich (im Vergleich zu normalen Scriptsprachen) sind:Zitat
Wow ein visuelles Scripting System! Doing things the hard way, eh?
Da fragt man sich natürlich was genau du vor hast. Als Programmierer zieht man nicht wirklich Vorteile aus so einen System und du könntest bestimmt auch locker mit einer Skriptsprache arbeiten.
- Auto-Completion: Ist der beste Namen für den Punkt der mir eingefallen ist. Es geht einfach darum, dass ich ein Hirn wie ein Nudelsieb habe, und mir auch beim regulären Programmieren meistens nur die Anfangs-Bezeichnungen von Funktionen merke, und z.B. im C++-Code total auf Intellisense vertraue. Die Sache ist jetzt, dass die meisten Scriptsprachen keine gute Autocompletion haben (siehe Ruby, Python, ...). Allein daher hätte ich entweder C# verwenden müssen, oder für Angelscript (was ich davor benutzt habe), ein Auto-Completion/Syntax-Highlighting-Tool schreiben müssen. Und auch im Vergleich dazu ist Visual Scripting in dieser Variante nochmal einen Ticken besser. Du bekommst einfach immer nur das angezeigt, was du gerade verwenden kannst. Ich kann eine Linie von einem Bool-Wert wegziehen, und bekomme nur Funktionen aufgelistet die Bool entgegennehmen, und kann darin noch per Name suchen. Nächster wichtiger Punkt: Assets/Ressourcen. Ich kann Ressourcen einfach per Drop-Down Menü bei jeder Funktion die eine entgegennimmt auswählen. Ich habe das schon im Maker gehasst wenn ich im Script ne Grafik oder so gebraucht habe, überall erstmal Namen raussuchen und eintippen, das brauch ich hier nicht. Hier kann ich einfach "ArkRunJ" eingeben und bekomm schon bei Enter direkt die richtige Ressource reingelegt. Die Liste ließe sich beliebig fortsetzen, z.B. auf Variablen kann per Drag & Drop zugegriffen werden, etc...
- Timings/Delay Execution: Das kennt man ja schon aus dem Maker. Es gibt im Event-Coding Wait-Befehle, wo der restliche Code nach einer bestimmten Zeit ausgeführt wird. Im Endeffekt war das für mich ein Must-Have für die Scriptsprache, zumindestens was Cutscenes angeht. Und anstatt (wieder) zwei verschiedene System zu entwerfen, warum nicht einfach gleich eine dynamische Sprache entwerfen, die das kann? Auch für Arks Steuerung habe ich mich reichlich davon bedient. Ich kann jetzt eine Node setzen "PlayTextureAnimation", welche die Sprunganimation abspielt. Wenn diese Animation fertig ist notifiziere ich den Controller, dass er sich wieder bewegen muss - indem ich einfach "SetJumping:false" gleich dahinter setze, das wird dann ausgeführt wenn die Animation fertig ist. Parallel dazu (eigener Node) kann ich jetzt eine While-Schleife laufen lassen, welche die Höhe des Spielers jeden Frame richtig setzt (um die korrekte Sprunghöhe von Terranigma zu simulieren). Und das lässt sich beliebig fortsetzen - ich benutze dieses Feature einfach so gut wie überall. Ich kenne keine andere (dynamische) Scriptsprache die sowas kann. Klar, du hast yield, coroutines und was weiß ich, aber das erlaubt dir nicht diese Form von sowohl getimeter als auch paralleler Codeausführung. Würde ich also eine normale Scriptsprache in Textform wollen, würde ich definitiv so ein Feature wollen - und das heißt ich müsste mir selber eine Textsprache schreiben, und meiner Ansicht nach wäre das sogar viel, viel aufwändiger (Visual Scripting ist viel UI, aber das mach ich lieber als Textparsing).
Klar gibt es auch Nachteile, alles was mit Mathe zu tun hat artet gleich mal aus und wird arg unübersichtlich, und der PlayerController für Ark ist auch schon ein Monster geworden.
Aber wenn du mich fragst, ich würde auch als C++-Programmierer jederzeit Visual Scripting (in einer Form wie ich & Unreal es haben) über einer textbasierten Sprache verwenden. Die Liste der Argumente ließe sich eben vermutlich noch beliebig weiterführen. Mir fallen viele Punkte auch gerade nicht ein, und zu lange will ich es auch nicht machen. Aber ich bin definitiv tausendmal produktiver als ich es beim Scripten mit Ruby (und Angelscript) war.
Eine Veröffentlichung ist definitiv mal geplant, aber da steht noch viel, VIEL polishing an. Gerade in den 2D-Code hacke ich gut und gern mal Sachen rein die ich gerade brauche, und den Editor kann man auch keine 5 Minuten am Stück hernehmen wenn man nicht weiß welche Aktionen man zu welcher Zeit besser nicht ausführen sollte ^^
Ja, ne. Unity hat einfach ein enormes Featureset, Unreal sowieso. Da komm ich natürlich nicht wirklich ran, da steckt einfach zu viel Zeit und Manpower drin. Aber dafür hab ich eben totale Kontrolle und bin z.B. nicht auf C# angewiesen (würd in Unity vmtl auch ein Visual Scripting Plugin wollen).
Nein, nein, keine MP3s (also abgesehen von paar Soundeffekten), ich spiel aktuell gerade schon die originalen SPCs ab. Das läuft aber nur über einen Emulator ab - SPC-Binärdaten und Laufzeit rein, abspielbare Audiodaten raus. Alle anderen Soundeffekte werden unabhängig davon abgespielt. Bedarf hab ich gerade keinen für was extravagantes, auch wenn das technisch ziemlich spannend klingt - aber praktisch bin ich so ziemlich zufrieden, kann z.B. auch mehrere SPCs nebeneinander abspielen was mit dem Rpg-Maker nicht ging.
Kann das sehr gut nachvollziehen - habe gerade vor paar Tagen nochmal die Dialoge in Krysta gekürzt. Kurz vor Veröffentlichung der Demo hatte ich die Erzähl-Szenen von Melina eben nochmal in den Keller verschoben, um das ganze etwas besser zu verteilen. Ich werd wohl schauen dass ich nochmal hier und da bisschen unnötige Exposition rausnehme, und auch die Idee mit so einer Szene wo Ark gegen seine inneren Dämonen kämpft find ich eigentlich richtig gut. Ich suche eben immer noch nach neuen Ideen, gerade für den Prolog, da find ich solche Vorschläge auch richtig cool. Wobei ich mit der aktuellen Revision von der Story her im großen und ganzen Zufrieden bin, also vmtl kein kompletter Prolog/Story-Rollover mehr kommt, außer wenn ich eine wirklich gute Idee habe. Aber hier und da kürzen und vllt bissl mehr Gameplay in den Prolog einbauen ist schon keine schlechte Idee.
Mehr oder weniger Ende, danach kommt nur noch "Kapitel 1"-Text und ein Autosave. Was du tun müsstest, ist den Ring den du erhalten hast anlegen. Hm, aber wo du es sagst, wäre gut da entweder einen Text anzeigen wenn Ark versucht so ins Portal zu springen (falls eben jemand den Dialog übersprungen hat), oder gleich den Ring selber anlegen.
Insofern, danke nochmal für das ausführliche Feedback
Heh ja, das war irgendwie ne Art Notlösung - hatte den Text erstmal für mein eigenes Forum geschrieben, was solche Tab-Teile unterstützt, weiß nicht ob du das schonmal gesehen hast. Dann erst wieder draufgekommen dass das die meisten anderen Foren die nicht gerade BurningBoard als software verwenden nicht unterstützen, werd mir beim nächsten Mal gleich ne bessere Lösung überlegen.
@erzengel_222:
Danke! Ich will ja nicht zu viel versprechen, aber soweit ich aktuell mit dem Kampfsystem bin, spielt es sich schon ziemlich gut. Hab eben auch wieder die Original-Timings übernommen, es steht im Endeffekt schon alles bis auf den Amoklauf-Angriff (achja und Kollisionsabfrage von Arks Attacken, aber das ist bissl haarig). Sollte sich also hoffentlich auch weiterhin so gut wie im Original steuern.
Zitieren