Seite 5 von 6 ErsteErste 123456 LetzteLetzte
Ergebnis 81 bis 100 von 106

Thema: "Colors of Damnation" [Entwicklertagebuch] RM2K3

  1. #81
    Zitat Zitat von Penetranz Beitrag anzeigen
    Hintergrundstory in den Startpost reineditiert.

    "Die Welt im Jahre 3688: Der Planet, den sie Erde nannten, wurde bereits vor vielen Jahrhunderten erobert, seine Bewohner versklavt. Die Konquistadoren, eine Rasse farbiger, humanoider Lebensformen unbekannter Herkunft, haben bereits große Teile des kosmischen Raumes in ihren Besitz gebracht. Colonel Jack Urs, Anführer der größten, noch existierenden Widerstandsgruppe "Col.Urs" hat der scheinbar unbesiegbaren Besatzungsmacht den Kampf angesagt. Von einem kleinen Asteroiden aus fungierend entwickeln er und zahlreiche andere Lebensformen, die dem intergalaktischen Widerstand angehören, mächtige Waffen, mit denen es möglich sein soll, den Feind zu bezwingen und verlorene Planetengruppen, vielleicht sogar ganze Galaxien zurückzuerobern. Ist Colonel Jack Urs dieser Aufgabe gewachsen? Oder wird er bitter scheitern wie seine Vorgänger? Es liegt in deiner Hand."

    An dieser Stelle nochmal ein Dankeschön an caesa_andy für die geile Idee mit den Namen
    Geilo! ^^

  2. #82
    Zitat Zitat von MagicMaker Beitrag anzeigen
    Die Energieanzeige kommt mir irgendwie bekannt vor.
    Jojo.

    Zitat Zitat von Maister-Räbbit Beitrag anzeigen
    Geilo! ^^
    Danke, ich geb mir Mühe

    Derzeit wird eifrig an den Gegnern gescriptet. Da es pro Level c.a. 15 - 20 Gegner geben wird kann das eine Weile dauern und das nächste Update demzufolge etwas auf sich warten lassen. Aber ich halt euch weiterhin auf dem Laufenden.

  3. #83

    Umfrage:

    Wollt ihr ein Spiel, in dem es

    a) Um's Überleben geht ->> es müssen pro Level 15 - 20 Gegner unterschiedlicher Farben gekillt werden ohne Zeit. Manche Gegner können die Fähigkeit haben, willkürlich die Farben zu tauschen

    oder

    b) nach Zeit geht ->> pro Level bis zu 5 Gegner unterschiedlicher Farben, die wiederauferstehen nachdem sie gekillt wurden. Spielziel ist es pro Level in 5 Minuten eine bestimmte Anzahl Gegner unterschiedlicher Farben zu killen, um das Level zu bestehen.


    Meinung der Spieler: was würde euch mehr interessieren ???

  4. #84

    Hier wird nicht geterrort
    stars5
    Geht auch beides?
    Ich meine...wäre doch spannender, so mit verschiedenen Missionszielen

  5. #85
    Ich will mich eigentlich für eine dieser beiden Varianten entscheiden und das Gameplay dementsprechend darauf abstimmen.

  6. #86
    Beides!
    Bringt mehr Variation und Abweschlung ins Spiel^^
    Und bei so einem Game macht dieses doch das Spiel aus, oder nciht? ^^

  7. #87
    Ähm.... okay, anders gefragt: angenommen ich würde beide Varianten ins Spiel aufnehmen... WELCHE WÜRDET IHR SPIELEN?

  8. #88
    Kommt ganz auf meine Laune an^^
    Will ich was forderndes haben, dann Zeit-Angriff, sprich gegen die Zeit eine bestimmte Anzahl Ziele ausschalten.
    Wenn ich aber nur mal was rumballern will, Überleben-Kampf^^

  9. #89
    Wenn mich keiner überzeugt, dass eine dieser beiden Varianten das einzig Wahre dessen ist, was die Spieler ausnahmslos wollen, dann entscheid ich mich für 'nen Kompromiss aus beidem: Überlebenskampf + Zeitkampf = alle Ziele auf der Map niederballern in einem bestimmten Zeitlimit (5 Minuten und das Ganze ohne respawnende Gegner).

    Geändert von TwoFace (21.09.2012 um 02:34 Uhr)

  10. #90
    Sou, auf Maister-Räbbit's früheren Vorschlag hin, haben wir die "Gegner-Typen" mal etwas erweitert

    Neben den normalen Gegnern gibt es jetzt:

    - Farbtauscher Rot/Grün
    - Farbtauscher Blau/Gelb
    - Farbtauscher Rot/Grün/Gelb/Blau

    Diese Gegner kommen vereinzelt in den späteren Leveln (ab 5+) vor und fungieren als "Endbosse".
    Auch werden sie mehr HP haben als die standardisierten, einfarbigen Gegner und eine (etwas) höhere Angriffspriorität zugewiesen bekommen


    Momentan haben wir das Problem, dass viele Schüsse, trotz sauberer Trefferabfrage, durch die Gegner hindurch gehen. Dieses Problem haben anscheinend viele, die ein Schuss-KS scripten und ist (anscheinend) eine negative Eigenart des Makers.
    Zitat Zitat von Zitat von Kelven aus dem DEAD-TOWN-Thread der Spielevorstellungen Beitrag anzeigen
    Das liegt daran, dass die Koordinaten-Anfrage natürlich alles andere als genau ist. Wenn sich ein Event genau dann bewegt, wenn das andere über ihm ist, dann hat es schon die Koordinaten vom neuen Feld. Kein Treffer. Selbst wenn man die Pixelkoordinaten benutzt (quasi mit einer Trefferbox), tritt der Fehler noch auf (müsste aber seltener sein).
    Wenn jemand 'ne Idee hat wie sich dieses Problem zumindest eingrenzen lässt, der darf sich gerne bei mir melden.

  11. #91
    Bei mir taucht das Problem nicht auf. Ich mach das so, dass ein Geschoss sich immer in eine Richtung bewegt und dann immer (nach jedem Feld das das Geschoss zurückliegt) schaut, ob auf dem Feld, das sich von der Schussrichtung ENTFERNT befindet, ein Gegner steht. Wenn das der Fall ist, wird das Geschoss mit Phasing Mode noch ein Feld weiter bewegt und dann entfernt. Klappt immer.

  12. #92
    Zitat Zitat von Itaju Beitrag anzeigen
    Bei mir taucht das Problem nicht auf. Ich mach das so, dass ein Geschoss sich immer in eine Richtung bewegt und dann immer (nach jedem Feld das das Geschoss zurückliegt) schaut, ob auf dem Feld, das sich von der Schussrichtung ENTFERNT befindet, ein Gegner steht. Wenn das der Fall ist, wird das Geschoss mit Phasing Mode noch ein Feld weiter bewegt und dann entfernt. Klappt immer.
    Kannst du mir evtl. mal dein Script zeigen, damit ich sehn kann, wie du das konkret gemacht hast?

  13. #93
    Wäre zu kompliziert, weil im Script noch ne ganze Reihe anderer Sachen versteckt sind (z.B. sollen Projektile über Wasser fliegen, durch Verbündete hindurch gehen und an Wänden explodieren).

    Nochmal etwas detailierter.

    Bevor das Geschoss abgefeuert wird, musst du die Blickrichtung einstellen, dann platzierst du es in ein Feld vom Helden in dessen Blickrichtung entfernt.
    Du machst aus dem Geschoss einen parallelen Prozess, der erst aktiviert wird, nachdem das Geschoss platziert wird.
    Innerhalb eines Zyklus (einmaligem Durchlaufen des Parallelen Prozesses) machst Du folgendes.

    Koordinaten des Projektils nehmen.
    Wenn das Projektil nach oben "schaut", dann wird die Y-Koordinate -1 genommen, nach rechts X-Koordinate +1, etc.
    Du schaust jetzt, ob sich auf diesem Feld ein Gegner befindet (du musst von jedem einzelnen Gegner die X und Y Koordinaten nehmen und schaun, ob sie mit den (veränderten) des Projektils übereinstimmen).
    Wenn nicht, dann bewegt sich das Geschoss ein Feld weiter in seine Sichtrichtung (Move Event: Step Forward), wait von 0,1 +0,0*2 Sekunden (oder länger, je nachdem, wie schnell Dein Geschoss ist) und das ganze geht von vorne los.
    Wenn da ein Gegner ist, dann killst ihn, ziehst ihm leben ab, machst blut, etc, was immer passiert, lässt das Geschoss noch ein Feld weiter fliegen (mit Phasing Mode ON, damit es in den Gegner "hineinfliegt") und es danach verschwinden.

  14. #94
    Ich denke, ich versteh's. Danke, ich versuch's vielleicht mal so.

    Wobei mein KS ohnehin darauf ausgelegt ist, dass der Schuss durchgeht (also "durchgeht" im Sinne, dass man mehrere Gegner auf einmal mit einem Schuss treffen kann ... wenn man's gut anstellt

    Geändert von TwoFace (23.09.2012 um 15:27 Uhr)

  15. #95
    Zitat Zitat von Itaju Beitrag anzeigen
    Wäre zu kompliziert, weil im Script noch ne ganze Reihe anderer Sachen versteckt sind (z.B. sollen Projektile über Wasser fliegen, durch Verbündete hindurch gehen und an Wänden explodieren).

    Nochmal etwas detailierter.

    Bevor das Geschoss abgefeuert wird, musst du die Blickrichtung einstellen, dann platzierst du es in ein Feld vom Helden in dessen Blickrichtung entfernt.
    Du machst aus dem Geschoss einen parallelen Prozess, der erst aktiviert wird, nachdem das Geschoss platziert wird.
    Innerhalb eines Zyklus (einmaligem Durchlaufen des Parallelen Prozesses) machst Du folgendes.

    Koordinaten des Projektils nehmen.
    Wenn das Projektil nach oben "schaut", dann wird die Y-Koordinate -1 genommen, nach rechts X-Koordinate +1, etc.
    Du schaust jetzt, ob sich auf diesem Feld ein Gegner befindet (du musst von jedem einzelnen Gegner die X und Y Koordinaten nehmen und schaun, ob sie mit den (veränderten) des Projektils übereinstimmen).
    Wenn nicht, dann bewegt sich das Geschoss ein Feld weiter in seine Sichtrichtung (Move Event: Step Forward), wait von 0,1 +0,0*2 Sekunden (oder länger, je nachdem, wie schnell Dein Geschoss ist) und das ganze geht von vorne los.
    Wenn da ein Gegner ist, dann killst ihn, ziehst ihm leben ab, machst blut, etc, was immer passiert, lässt das Geschoss noch ein Feld weiter fliegen (mit Phasing Mode ON, damit es in den Gegner "hineinfliegt") und es danach verschwinden.
    Das löst Panetranz Prolem nicht, kann ich dir jetzt schon schon sagen. Der maker bewegt events schneller, als Sprites und da kann es nunmal passieren, dass das Schuss-Event und das gegner Event aneinander vorbei ziehen, wenn sie sich ungefähr gleichzeitig bewegen. Optisch trifft der Schuss dann, aber die koordinaten der Events stimmt nicht überein, also fliegt der Schuss durch den Gegner durch.
    Du prüfst lediglich ein feld früher, ob dort ein gegner steht. Das verhindert aber nicht, dass sich Events simultan aneinander vorbei bewegen.




    Ich würde das problem folgendermaßen Lösen:


    Platziere über jedem Hinderniss, dass einen Schuss abfangen Soll, ein Event, das auf "Above hero" eingestellt ist.

    Dann platzierst du ein unsichtbares Dummy-Event, das ebenfalls Above hero ist, und sich exakt so, wie der intendierte Schuss verhällt. D.H. es bewegt sich mit maximaler geschwindigkeit und Bewegungsrate vom Helden weg. Dabei bewegst du das Event aber mit "Move Event" befehlen, und zwar mit Maximal so vielen Moves, wie die Karte lang oder breit ist. Moves, die das Event nicht ausführen kann, MÜSSEN übersprungen werden.
    Das führt zu folgendem: Das "abgeschossene" Event fliegt die Flugbahn entlang. Da Events auf der selbene Ebene nicht aneinander vorbei können, bleibt das Event an anderen "Above Hero" events hängen und eventuell verbliebene Moves werden ignoriert. Nach dem "Move Event" speicherst du EINMAL die Koordinate, die das Event in dem Augenblick hat. Jetzt hast du die koordinate, bis zu welcher der Schuss maximal fliegen kann. Aus dieser Koordinate, sowie der Koordinate, die die Spielfigur hat, ergibt sich die Flugbahn des geschosses.

    Steht der held etwa auf 10/1 und das geschoss fliegt bis 10/10 und bleibt dort hängen, können alle felder zwischen 10/1 und 10/10 getroffen werden. Jetzt überpfüfst du mit einer schleife, ob auf einem der Felder zwischen diesen beiden Punkten ein gegner steht. Wenn ja , weißt du sofort, auf welchem feld der gegner getroffen wird und spielst du eine Animation auf dem gegner ab. Wenn kein gegner da ist... passiert nichts.

    Auf diese Art und weise hast du zwar kein sichtbares Geschoss, aber der gegner kann dem Schuss nicht mehr ausweichen.

    Geändert von caesa_andy (23.09.2012 um 15:03 Uhr)

  16. #96
    Zitat Zitat von caesa_andy Beitrag anzeigen
    Das löst Panetranz Prolem nicht, kann ich dir jetzt schon schon sagen. Der maker bewegt events schneller, als Sprites und da kann es nunmal passieren, dass das Schuss-Event und das gegner Event aneinander vorbei ziehen, wenn sie sich ungefähr gleichzeitig bewegen. Optisch trifft der Schuss dann, aber die koordinaten der Events stimmt nicht überein, also fliegt der Schuss durch den Gegner durch.
    Du prüfst lediglich ein feld früher, ob dort ein gegner steht. Das verhindert aber nicht, dass sich Events simultan aneinander vorbei bewegen.
    In meinem AKS ist noch nie ein Geschoss durch einen Gegner durchgegangen. Ich sollte vielleicht noch dazu sagen, dass die Geschosse auch auf Kontakt explodieren. Sprich: wenn sie innerhalb von einem kurzen Zeitabstand (2*0,0) noch dieselben Koordinaten haben, explodiert das Geschoss und verursacht ebenfalls schaden. Somit werden Gegner, die sich auf den Helden hinzubewegen immer getroffen.

  17. #97
    Zitat Zitat von Itaju Beitrag anzeigen
    Somit werden Gegner, die sich auf den Helden hinzubewegen immer getroffen.
    Und was ist mit denen, die sich im 90° Winkel zum helden bewegen?

  18. #98
    Im 90 Grad Winkel kann man sich nicht _zum_ Helden bewegen

    Hab mir das selbst nochmal angeschaut.

    Ich überprüfe sowohl dieselbe Koordinate auf dem das Projektil sich gerade befindet, sowie das Feld in Flugrichtung. In beiden Fällen kommt es zu einem Treffer.

    Wenn sich der Gegner auf dich zu- oder wegbewegt wird seine Variable immer auf einem der Felder sein. Wenn sich die Gegner jedoch häufig nach links- und rechts (aus Sicht des Schützen zu sehen) bewegen, wird's ein wenig schwieriger, die Gegner zu treffen, die exakt in diesem Monat ihre Koordinate verlassen, da der Maker immer sofort die Koordinate des Feldes ausspuckt, auf die sich der Gegner zubewegt. Das fühlt sich aber weitaus nicht so unnatürlich an, wie ein Gegner der sich klar auf einen hinzubewegt und trotzdem nicht getroffen wird.

    Geändert von Itaju (23.09.2012 um 18:46 Uhr)

  19. #99
    Zitat Zitat von Itaju Beitrag anzeigen
    Im 90 Grad Winkel kann man sich nicht _zum_ Helden bewegen
    Doch, wenn "zum" eine "modale Präposition" ist ... denn dann bewegt sich das monster "relativ zum helden im 90° Winkel" ... sprich: in einem 90° winkel von der Blick/Bewegungsrichtung des Helden abweichend.

  20. #100
    Um wieder zum eigentlichen Thema zurückzukommen:

    Es geht momentan gut voran.
    Level 1 von 10 wurde heute fertiggestellt.

    Wenn's in diesem Tempo weiterläuft, wird's zumindest bald mal 'nen Vorstellungsthread bei den Spielevorstellungen geben

Berechtigungen

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