Game Maker Domäne

   Spoiler

Zitat von »Klaus C. Haber«

Schon mal die Idee, dass man sich nur mit Hilfe eines Sonars orientieren kann ist genial. Kaum ist eine Mauer vorm Sonar, schon ist auch Schluss mit der Sichtweite.

Die Idee von einem Spiel mit einem Sonar anstelle von freier Sicht hatte ich schon länger im Kopf. Ursprünglich wollte ich einen Rätsel-Platformer daraus machen, in dem man einen blinden Jungen spielt, habe mich letztendlich jedoch entschieden, lieber eine Art "Exploration"-Game daraus zu machen. Die Spielmechanik bietet sich dafür deutlich besser an, wie ich finde.

Zitat von »Klaus C. Haber«

Man sieht zwar immer nur die weiße "Grenzlinie", aber mann kann sich doch einiges vorstellen von der Welt.

Genau das wollte ich in diesem Spiel erreichen. Dadurch, dass die Welt quasi unsichtbar ist, sollte umso mehr der Fantasie überlassen werden. Deshalb gebe ich auch keine Erklärung vor, wen man spielt oder wo man sich befindet. Im weiteren Verlauf des Spiels merkt man noch einige Veränderungen um sich herum, was diesen Effekt hoffentlich noch verstärkt.

Zitat von »Klaus C. Haber«

nach schon 5 Minuten Spielzeit brauchen meine Augen ein weilchen, sich wieder an das "normale" Tageslicht zu gewöhnen.

Hast du im Vollbild gespielt? Mir war die Optik eigentlich nie ungemütlich, das ist aber sicherlich Geschmackssache. Vielleicht solltest du einfach das Tageslicht meiden.

Zitat von »Klaus C. Haber«

hab das Spiel kurz angezockt und die ersten 3 Levels n'paar mal durchprobiert.

Zitat von »Moos«

Ich habs bis jetzt nur bis zum 2. Level geschafft, die bewegende Umgebung ist echt verwirrend.

Zitat von »kevb0ard«

bin erstmal bis ins 3. level gekommen später versuch ichs nochmal weiter zu schaffen

Das mit dem Schwierigkeitsgrad war für mich von Anfang an ein Problem. Da ich der einzige Tester war und die Level selber schon kannte, konnte ich nur ungefähr schätzen, ob sie auch für andere schaffbar sind. Verzeiht mir daher, wenn es teilweise etwas gemein ist. Ab Level 3 sind die Zielobjekte schon meistens recht gut versteckt. Umso wichtiger ist es, auf das Piepsignal zu hören.
Ich will euch aber auf jeden Fall ans Herz legen, das Spiel durchzuspielen. Wenn ihr im dritten Level seid, habt ihr schon fast die Hälfte vom Spiel geschafft, und im nächsten Level wartet eine kleine Überraschung auf euch.

Zitat

Stand mit meinem Dreieck in einer Ecke, als der Piep-Ton schon fast durchgängig ohne Pausen kam, aber ein Ziel oder anderes wo ich hin muss habe ich nicht gesehen.

Zitat

Wüsst gern zu welchem Trick aus Der GM-Trickkiste gegriffen wurde, sowas zu realisieren

   Spoiler

(Wenn euch nur das Endergebnis interessiert, schaut euch den letzten der drei Codes an!)
Mein erster Ansatz war, mithilfe von einem Schleifengebilde jeweils den ersten Punkt zu finden, an dem in einer bestimmten Richtung eine Kollision mit dem Wandobjekt vorliegt und diesen Punkt dann zeichnen zu lassen. Das ganze sah dann ungefähr so aus:

GML

1 2 3 4 5 6 7 8

var i1,i2; for (i1=-45;i1<45;i1+=1) { //diese schleife geht durch alle gradzahlen von -45° bis 45° i2 = 0; do { // diese schleife überprüft die koordinaten für jeden abstand, bis eine kollision vorliegt oder der abstand >300 ist i2 += 1; } until (i2>300 || collision_point(x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1),oWall,true,true)); draw_point(x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1)); // an jeder der koordianten wird ein einzelner punkt gezeichnet. }

Das Problem hierbei war, dass es nicht annähernd performant genug war, vor allem wenn keine Hindernisse in Reichweite waren und somit jede Schleife bos zum Ende durchgezählt hat.
Also habe ich versucht, das ganz ein wenig zu dezimieren, indem ich i1 und 12 (Richtung und Abstand) in größeren Schritten erhöht habe.
Nachdem ich einige Werte ausprobiert hatte, kamen weitere Probleme auf: Erhöhte ich den Abstand in zu hohem Maße, wurden die Umrisse der Hindernisse verzerrt und ungenau; erhöhte ich den Winkel zu schnell, lagen die einzelnen Punkte in zu weitem Abstand von einander und es sah nicht mehr nach einem Radar aus.
Am ersten der beiden konnte ich wenig ändern, also musste ich eine alternative Darstellungsmöglichkeit anstelle der Punkte finden. So kam ich auf die naheliegende Idee, die Punkte nicht einzeln darzustellen, sondern mit Linien zu verbinden:

GML

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

var i1,i2,i3; for (i1=-30;i1<30;i1+=3) { //i1 wird nun jeweils um 3 erhöht, was die gesamtdauer der schleife um 2/3 verringert //das sichtfeld wurde von insgesamt 90° auf 60° verringert, was die dauer um 1/3 verkürzt i2 = 0; do { i2 += 2; //i2 wird jeweils um 2 erhöht, was die gesamtdauer nochmal halbiert } until (i2>200 || collision_point(x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1),oWall,true,true)); //die sichtweite und somit die schleifendauer wurde im 1/3 gerkürzt draw_line(x+lengthdir_x(i3,dir+i1-3),y+lengthdir_y(i3,dir+i1-3),x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1)); // anstelle eines punktes wird nun eine gerade von der jeweils letzten zur aktuellen koordinate gezeichnet i3 = i2; // in i3 wird die letzte koordinate gespeichert (bzw der letzte abstand) } draw_line(x+lengthdir_x(i3,dir+i1-3),y+lengthdir_y(i3,dir+i1-3),x,y); // linie zurück zum spieler // insgesamt ist die dauer der schleife nurnoch 0,074mal so lang wie vorher; das ganze geht also (theoretisch) 13,5mal so schnell wie vorher //(vorrausgesetzt die schleife wird bis zum ende ausgeführt)

Bei diesem Kompromiss bin ich quasi bis zum Ende der Entwicklung geblieben, bis mir eine Alternative eingefallen ist, welche besser funktioniert hat. Anstatt einzelne Punkte auf Kollision zu untersuchen und dabei den Abstand zu erhöhen, habe ich einfach collision_line benutzt und solange geprüft, bis KEINE Kollsion mehr vorlag. Ich hatte die Möglichkeit anfangs verworfen, da ich davon ausgegangen bin dass collision_line rechentechnisch aufwändiger als collision_point ist und somit vermutlich länger brauchen würde. Die Schleife wird aber mit der neuen Technik sofort beendet, wenn keine Kollision vorliegt und spart damit deutlich mehr Rechendurchläufe als die collision_point-Methode.
Mein Code sah also letztendlich so aus:

GML

1 2 3 4 5 6 7 8 9

for (i1=-30;30;i1+=3) { i2 = 200; // i2 startet nun mit 200 und zählt runter do { i2 -= 2; } until (i2<8 || !collision_line(x,y,x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1),oWall,true,true)); // schleife wird beendet, wenn keine kollision vorliegt draw_line(x+lengthdir_x(i3,dir+i1-3),y+lengthdir_y(i3,dir+i1-3),x+lengthdir_x(i2,dir+i1),y+lengthdir_y(i2,dir+i1)); i3 = i2; } draw_line(x+lengthdir_x(i3,dir+i1-3),y+lengthdir_y(i3,dir+i1-3),x,y);

Mit der neuen Methode hätte ich theoretisch die Kompromisse die ich anfangs der Performance wegen eingegangen bin, rückgängig machen können, und das Sichtfeld wieder vergrößern. Das Leveldesign und der Rest der Engine war nun aber schon so sehr auf die Werte abgestimmt, dass ich es dabei belassen habe.