"Colors of Damnation" [Entwicklertagebuch] RM2K3

Zitat:

---

Zitat von Penetranz

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 :hehe:

---

Geilo! ^^

Zitat:

---

Zitat von MagicMaker

Die Energieanzeige kommt mir irgendwie bekannt vor.

---

Jojo.

Zitat:

---

Zitat von Maister-Räbbit

Geilo! ^^

---

Danke, ich geb mir Mühe :D

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.

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 ???

Geht auch beides?
Ich meine...wäre doch spannender, so mit verschiedenen Missionszielen

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

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

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

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^^

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).

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

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.

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.

Zitat:

---

Zitat von Itaju

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?

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.

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 :)

Zitat:

---

Zitat von Itaju

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.

Zitat:

---

Zitat von caesa_andy

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.

Zitat:

---

Zitat von Itaju

Somit werden Gegner, die sich auf den Helden hinzubewegen immer getroffen.

---

Und was ist mit denen, die sich im 90° Winkel zum helden bewegen? ;)

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.

Zitat:

---

Zitat von Itaju

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. ;)

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 :)

Level 1 ist wie gesagt schon fertig und ich habe einen ersten Screenshot vom Game gemacht,
damit sich jeder einen Einblick verschaffen kann, wie das Ganze optisch aussieht.

[IMG][IMG]http://www10.pic-upload.de/thumb/24....5vzueld2nk.png[/IMG][/IMG]

Ein "Speedrunner" ist auf diesem Bild aktiv, genauso wie die rotfarbige Waffe :)

Euer Hud gefällt mir leider gar nicht...nicht das klitzeklitzekleinste bisschen.

Ich erkenne die Mühe an, die da drin steckt ... aber es ist VIEL zu dominant. Echt jetzt. Die Pistole belegt alleine schpon ein 8tel vom Bildschirm, dazu dann ein riesen HP-Balken, und von oben zumpelt auch noch irgendwas ins Bild.


Verkleinert die Pistole um mindestens 50% ... das Bild ist doch wohl eh egal, es geht nur um die farbe. Den HP-Balken würde ich quasi als "Rahmen" um das pistolenbild herum legen, so in etwa:
Anhang 15435

Und den rest ... muss dieser Schwarze rand hinter dem Oberen Hud unbedingt sein? Tun es die Symbole nicht auch einzeln? Je weniger zeug ständig auf dem Bildschirm zu sehen ist, um so besser.

Vielleicht mach ich die Bilder der HUD irgendwann mal halbtransparent, wenn's 90% der Spieler stören sollte bzw. die Sicht behindert. Momentan bin ich aber so sehr zufrieden damit.

Zitat:

---

Zitat von Penetranz

Vielleicht mach ich die Bilder der HUD irgendwann mal halbtransparent, wenn's 90% der Spieler stören sollte bzw. die Sicht behindert. Momentan bin ich aber so sehr zufrieden damit.

---

Keine Gute Idee, dann kann man ihn möglicherweise schlecht Lesen. Mach doch stattdessen den Kasten um die Waffe weg und färb die je nach Waffenart ein. Mach die Balken schlanker und das relevante Symbol oben nur doppelt und nicht dreimal so groß und schon hast du gleich doppelt soviel Platz :0

Danke für eure Tipps, Leute :)

Vorerst lass ich alles mal so, da ich damit zufrieden bin. Sollte sich das letztenendes ändern, wird sich auch die HUD ändern. Aber schaun wir mal ;)

... hab ich mich dazu entschlossen einen Vorstellungsthread zu eröffnen. Was spielbares rückt also in greifbare Nähe.

Der neue Thread löst diesen hier fortan ab.