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.

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.

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.

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.

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

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:

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:

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.