Beiträge von Quajutsi

    Herzlich willkommen!


    Keine Sorge, lass dich nicht vom guten alten Tw0Face erschrecken, der sitzt nun mal seeeeehr lange vorm Maker und braucht zwischendurch mal etwas Spaß ;)


    Fragen kannst du hier immer gerne stellen, und für's Testspielen und Bughunting finden sich hier auch Leute, falls du dann irgendwann mal ne Demo raushauen solltest oder Feedback haben willst. Ansonsten wünsche ich dir noch viel Spaß hier im Forum, und frohes Makern :)

    Was mir noch aufgefallen ist: Beim zweiten neuen Bild bei den oberen Rändern der unteren beiden Baustämme links und rechts (also die mit den Häusern drauf), ist das so gewollt dass da was an den Rändern außen übersteht? Weil für mich sieht das ein bisschen so aus, als ob da beim zurechtschneiden der Grafiken noch was übersehen wurde rauszuschneiden

    Felder:

    -Hindernis: Sobald dieses Feld betreten wird, wird das entsprechende Kart gestoppt und die restlichen Würfelpunkte des aktuellen Zuges verfallen.

    -Schub: Beim Betreten dieses Feldes +2 auf die restlichen Würfelpunkte des aktuellen Zuges

    -Schutzschild: Solange sich ein Fahrer auf diesem Feld befindet, erhält Schutz vor allen gegnerischen Items


    Items:

    -Blitz: Alle Gegner vor dem Anwender erhalten für ihre 2 nächsten Würfelwurfe -1 auf ihre Würfelzahlen

    -Eruption: 1 Gegner wird um 2 Felder zurückgeworfen. Alle Fahrer, die 1 oder weniger Felder vom gewählten Gegner entfernt waren, werden ebenfalls um 1 Feld zurückgeworfen

    -Bleifuß: Aktiviert sich automatisch beim betreten des nächsten Hindernis-Feldes, falls die restlichen Würfelpunkte größer 0 sind. Dieses wird dann ignoriert. Alternativ einsetzbar, um +2 auf den nächsten Würfelwurf zu erhalten

    -Hindernis: Der Anwender platziert ein Hindernis auf der Strecke

    -Überlasten: Der nächste Würfelwurf wird x2 gerechnet, dafür werden die darauf folgenden 2 Würfelwurfe halbiert (Aufgerundet)

    Finde die Idee auch gut; von meiner Seite aus könnte ich mit Mapping und Eventing aushelfen sowie Ideen liefern (Programmierlogik ist mir auch vertraut; da ich mich aber noch nie mit JavaScript auseinander gesetzt habe, könnte ich da höchstens aushelfen, wenn sich da jemand mit mir zusammensetzt, der sich damit auskennt und das mit mir zusammen macht und von mir eher nur Logik-Input kommt).


    Denke auch mal, dass eine kleine Gruppe am sinnvollsten ist (Bisher die großen Community-Projekte hier im Forum liefen ja nicht wirklich gut), wobei man sich ja immer noch Input in Form von Ideen oder einzelnen Grafiken etc. aus der Community holen kann.


    Hey, ich hab es mal geschafft, meinen Gegner zu besiegen!


    Also an sich ein schönes Spiel, aber wenn du es am Anfang nicht schnell genug schaffst, Blöcke abzubauen (entweder weil du nicht die ganze Zeit - im Gegensatz zum Gegner - die Fall-Beschleunigungstaste nutzt oder Pech bei den Blöcken hast), oder später den Flow nicht aufrecht erhalten kannst, überhäuft dich der Gegner mit Totenkopfblöcken und du kannst nichts mehr machen.


    Einen Storymodus fände ich schon interessant, vor allem wenn die Charaktere eigene Spezialfähigkeiten hätten, die das Ganze nochmal in jedem Kampf anders gestalten (bspw. eine Fähigkeit, die eine bestimmte Anzahl (oder alle) Blöcke eines bestimmten Typs (Totenkopf, Blitz, Feuer, etc.) oder generell eine bestimmte Anzahl zufälliger Blöcke entfernt, oder eine, die die untersten 2 oder 3 Reihen entfernt, oder eine, die alle Blöcke eines bestimmten Typs in einen anderen Typ umwandelt, oder eine, die eine bestimmte Zeit lang nur Doppelblöcke (also Blitz-Blitz, Feuer-Feuer, Wind-Wind, etc.) erscheinen lässt, etc.)

    Evtl. mit Aufladen, sodass man sie dann mehrfach in einem Kampf nutzen kann. Aufladen könnte dann z.B. entweder über Zeit oder durch Abbauen von Blöcken gehen. Wenn über Blöcke, könnte man den Charakteren ja vielleicht auch jeweils eine der Blockeigenschaften zuordnen, und wenn diese Blöcke abgebaut werden, gibt es einen Bonus für die Aufladung.


    *Nimmt einen tiefen Atemzug* Ok, ich glaub ich hab erstmal alles rausgelassen, was mir so auf- und eingefallen ist.

    Mir persönlich sind Episodenspiele deutlich lieber als ein ganzes langes 40-Stunden-Epos. Ein Episodenspiel bietet dem Spieler ja in sich abgeschlossene Kapitel, wobei sich Aufzug und Inhalt von Kapitel zu Kapitel durchaus unterscheiden können, was es meiner Meinung nach einfacher für den Spieler zugänglich macht als ein Epos, da der Spieler diese kürzeren Abschnitte des Spiels abschließen und zwischen den einzelnen Episoden auch mal Pausen machen kann, ohne dass er große Probleme bekommt, wieder ins Spiel einzusteigen, was in meinen Augen eine Schwäche von Epi sind, wo ja für z.B. die nächste Hauptquest nicht wieder eine Einleitung vorkommt, sondern der Spieler direkt "hineingeworfen" wird. Klar, wie auch die Episoden zum Teil, bauen diese Hauptquests wahrscheinlich aufeinander auf, jedoch lässt sich da nach langer Pause schnell mal der Faden verlieren, wohingegen man beim Start einer Episode in diese hineingeführt wird und sich dann durch Anspielungen und Referenzen einfacher an vorangegangene Episoden erinnern kann, als wenn man einfach einen Spielstand lädt und direkt wieder ins Weltgeschehen geschleudert wird.

    Bei einem guten Episodenspiel sollte meiner Meinung nach aber jede Episode auch für sich alleine stehen können, und die Verbindung zwischen den einzelnen Episoden quasi ein "netter Zusatz" sein, der zwar manches verständlicher machen kann, man ihn aber nicht zwingend braucht, um einzelne Episoden zu verstehen und zu spielen.

    Das Ansprechen funktioniert wahrscheinlich nicht, weil du ja in dem Moment, wenn du dich umdrehst und ihn anschaust, die 1. Eventseite auslöst die dann prüft ob die Taste OK gedrückt wird (Was du ja in dem Moment nicht tust) und dann direkt zur 2. Seite wechselt.

    Das Event muss halt in irgendeiner Form bereits auf der Map existieren, da die Events ja über die Map-Daten geladen werden und du nicht einfach mitten im Spiel sagen kannst, dass du plötzlich nen neues Event erschaffen willst. Wichtig wäre dann natürlich auch, dass diese NPC-Event immer die gleiche ID hat, da sonst das Common-Event mitunter das falsche Event ansprechen würde

    Denke teilweise hängt das auch mit der Erwartungshaltung zusammen. Je weiter dein Spiel fortgeschritten ist, desto weniger Fehler erwarten die Spieler darin zu finden. Gerade bei größeren Spielen ist es aber so gut wie unmöglich, alle Fehler in seinem eigenen Spiel ohne Tester zu finden. Gleichzeitig möchtest du deinen Spielern aber auch eine möglichst fehlerfreie Version präsentieren, weshalb kurz vor einem Release dieses Hinauszögern auftritt - du könntest ja noch Fehler in der Version drin haben und gehst sie lieber nochmal durch, oder zögerst das Erstellen der letzten fehlenden Grafiken hinaus.

    Ich denke, da hilft dir der Rat von Dezue weiter: Einfach mal Releasen. In einem frühen Stadium ist es natürlich ganz normal, dass in einem Spiel bisher von dir unentdeckte Fehler auftreten können, weshalb da die Erwartungshaltung noch nicht ganz so kritisch ist. Und wenn die Spieler sehen, dass du in den folgenden Releases die gefundenen Fehler immer wieder fixt, wird dir denke ich auch keiner beim End-Release vorwerfen, dass du ihnen da etwas halbgares serviert hast, da man den Fortschritt deines Spiels ja mitverfolgen konnte und gemerkt hat, dass du dich auch um bereits Vorhandenes kümmerst, falls nötig.

    Deinen Fortschritt mit den Spielern zu teilen und dich mit den Spielern auszutauschen, kann dir denke ich die Motivation geben, dein Spiel fertig zu stellen. Das Ganze birgt natürlich auch ein gewisses Risiko; wenn die Spieler dies und das kritisieren und sagen dieses und jenes würden sie anders machen, und das Ganze weicht recht stark von deinen Vorstellungen deines Spiels ab, oder generell einfach dein Spiel ohne Grund runtermachen, vielleicht einfach weil es nicht in ihr Genre fällt, dann kann es dir natürlich auch die Motivation nehmen, weiterzuarbeiten, deshalb würde ich dir raten, wenn du mit sowas nicht umgehen kannst, zunächst in einem kleinen Kreis deines Vertrauens zu Releasen, um zu Üben und Selbstvertrauen zu dir und deinem Spiel aufzubauen - es ist schließlich dein Spiel und du bist derjenige, der es entwickelt, und nicht die Spieler.

    Jap, und zwar für dich als meine Nahrung.


    Ich verarbeite alle meine Gegner zu Brei

    Nehme ihr Rückgrat und mache daraus Rührei.

    Gewürzt mit dem Geschmack meines Siegs

    Feiere ich die Stunde meines Aufstiegs.


    Kommt nur her, wenn ihr euch traut, ihr seid doch nur Lauch.

    Ne, studiere gerade Informatik, aber das meiste habe ich mir über das arbeiten mit dem XP angeeignet; da eigentlich solche grundlegenderen Sachen bei allen Makern recht ähnlich sind, kann ich da Referenzen ziehen, aber komplexere Sachen, wo ich mich erst in den Code von anderen Makern einlesen müsste, kann ich deshalb auch nicht wirklich beantworten.

    Da das meiste ja aber über Eventing gelöst werden konnte, kann ich da gut mitreden, weil das an sich in jedem Maker gleich bleibt, auch wenn hier und da mal neue Befehle dazu kommen oder alte wegfallen.

    Das Problem ist, dass du ja eine mögliche Bewegung erst abwarten musst, damit x und y korrekt abgefragt werden können. Es gibt bestimmt nen Skriptcall moving oder so, der abfragt, ob sich das event gerade bewegt, aber da solltest du dich dann besser an jemanden wenden, der sich mit den Skripts des MV auskennt, da ich da nur mit einfachen Sachen weiterhelfen kann.

    Ansonsten mit den Wand-Events.... Könnte mir vorstellen, dass du das über eine if-Abfrage machen kannst, wo du abfragst, in welche Richtung das Steinevent schaut.

    Glaub ich weiß wo der Fehler liegt; nach der Bewegungsroute müsste denke ich mal noch ein wait-Befehl rein, damit die Überprüfung erst wieder ausgeführt wird, wenn die Bewegung des Steins abgeschlossen ist (Das Wiederholen sollte dann auch raus können). Müsstest dann allerdings schauen, wie lange der warten soll, damit die Bewegung noch gut aussieht; würde da erstmal mit 60 Frames starten und dann mal schauen wie es aussieht und anpassen.