Vom Hobby-Gamer zum Hobby-Programmierer, Teil 4 User-Artikel

VR und zufällige Levels

LRod / 29. Dezember 2017 - 1:24 — vor 46 Wochen aktualisiert
Nach einem Abstecher zu Blender geht es weiter mit Unity. Das Projekt soll nun um VR-Support und zufällig generierte Dungeons erweitert werden.
Nach einem längeren Abstecher zu Blender, bei dem ich einige Modelle für Gegner und Räume erstellt hatte, wurde es Zeit, wieder zum Ursprung des Projekts zurückzukehren: Den Herausforderungen beim Programmieren. Meine C#-Kenntnisse hatte ich in der Zwischenzeit dank des sehr empfehlenswerten Buches „Schrödinger programmiert C#“ von Bernhard Wurm etwas aufpoliert und zwei Themen, mit denen ich mich beschäftigen wollte, standen auch schon fest: Zum einen bekam die Unity-Engine vor einiger Zeit eine interessante VR-Unterstützung spendiert und da ich die Möglichkeit habe, eine HTC Vive zu nutzen, war es naheliegend, auch einen VR-Modus einzubauen. Zum anderen interessierte mich das Thema zufällig erzeugter Inhalte schon länger. Zumindest die Erzeugung von Levels sollte mit meinem Kenntnisstand doch machbar sein.


Dungeons in VR

Ein weiterer Gegner aus Blender.
Erste Erfahrungen mit VR in Unity hatte ich tatsächlich schon zuvor gesammelt, denn neben SteamVR unterstützt Unity auch die GearVR. Damit hatte ich mich schon vor einiger Zeit kurz beschäftigt, es dann aber schnell wieder sein gelassen. Wovon ich an dieser Stelle abraten muss ist das Buch „Unity Virtual Reality Projects“ von Jonathan Linowes, da es schlicht zu alt ist und SteamVR noch gar nicht kennt. Zwar war es mit den beim Plugin mitgelieferten Pakten relativ einfach, die Kamera auf VR-Darstellung umzustellen, aber die Blicksteuerung hatte mich fast so sehr abgeschreckt wie die erhebliche Anpassungsarbeit an Modellen und Texturen, die die schwache Smartphone-Hardware erfordert hätte.
 
Zumindest letzteres Problem hatte ich mit der Vive zunächst nicht: Anpassungen waren nicht nötig. Und die ungewohnte Eingabemöglichkeit mit den Vive-Controllern sollte doch irgendwie beherrschbar sein! Also schnell ein kurzes Tutorial gesucht, das kostenlose SteamVR-Plugin aus dem Asset Store heruntergeladen, die normale Spielerkamera durch die im Paket vorkonfigurierte VR-Kamera ersetzt und im Grunde war es das auch schon: Nach einem Klick auf den Play-Button konnte ich meinen Dungeon in VR betrachten und – sofern ich unter der Brille die „WASD“-Kombination ertasten konnte – mich auch schon darin bewegen. Erfreulicherweise funktionierte das gut und ohne Übelkeit, was sicher auch daran lag, dass ich die schrittweise Bewegung noch als Sprung und nicht mit einem Gleiten von Feld zu Feld umgesetzt hatte. Auf die „richtige“ Teleport-Bewegung verzichtete ich erst einmal – allerdings eher aus spielmechanischen Gründen, denn das Aktivieren oder Sperren von Feldern für den Teleport ist ebenfalls recht einfach umzusetzen.
 
Was ich jedoch unbedingt verwenden wollte, waren natürlich die Controller. Sicherlich würde es jetzt mit dem Programmieren losgehen? Wieder falsch: Auch für die Belegung der Controllerbuttons gibt es großartige vorgefertigte Lösungen, vor allem VRTK, eine kostenlose Weiterentwicklung des SteamVR-Plugins, die durch umfangreiche Tutorials auf YouTube ergänzt wird – sehr empfehlenswert! Enthalten sind unter anderem vorgefertigte Scripte für die Belegung aller Tasten, aber auch für die „Laserpointer“, mit denen in VR etwa Buttons auf der Benutzeroberfläche angewählt werden können.
 
UI-Schriftrolle und Controller im Bild. Einige VRTK-Scripte sind rechts zu sehen.
Die Benutzeroberfläche stellt in Sachen VR dabei eine Besonderheit dar, denn die gewohnte 2D-Oberfläche mit Menü-Buttons oder Lebensenergie wird im VR-Modus erst einmal nicht angezeigt. Es ist zwar möglich, diese auf einem Umweg wieder im Sichtfeld einzublenden (Doom VFR macht dies etwa), das wirkt jedoch im Helm eines Marines immersiver, als in einem Fantasy-Setting. Eine beliebte Alternative ist es daher, diese Informationen auf einem Gegenstand, etwa im Stile eines Fallout 4 VR auf einem Armband, einzublenden. Dafür blendete ich das Modell des linken, im VR-Modus standardmäßig sichtbaren Controllers aus und ergänzte das Controller-Objekt durch eine schnell in Blender erstellte Schriftrolle, die wiederum mit Textfeldern für die Lebensenergie und mit durch den „Laserpointer“ des rechten Controllers anwählbaren Buttons für die Menüs ausgestattet wurde. So lässt sich nun der Zustand der Gruppe oder das Menü des Spiels über einen Blick auf die in der linken Hand „gehaltenen“ Schriftrolle ablesen. Spätestens jetzt war ich hellauf begeistert von dem Ergebnis. Selbst meine eher bescheidenen Gegner aus Blender wirkten plötzlich viel plastischer!
 
Ein klein wenig programmiert habe ich am Ende doch noch: Die Drehung um die eigene Achse habe ich schließlich nicht auf einen der etwas spärlichen Buttons gelegt, sondern tatsächlich die Blickrichtung der VR-Brille genutzt, um zu erfassen, in welche Richtung der Spieler gerade einen Schritt machen will. Und ich habe ein paar Scripte um einen „VR-Modus“ ergänzt, der etwa die richtige Kamera (klassisch oder VR) aktiviert, damit ich am Ende nicht zahlreiche händische Anpassungen für beide Versionen vornehmen muss.
 

Performance-Probleme

Allerdings fiel mir auf, dass die Framerate an einigen Stellen immer deutlich abfiel. Das war auch in 2D der Fall, erst mit VR wurde es dann aber kritisch. Die Ursache war schnell gefunden, denn immer wenn der Blick in Richtung des Inneren des  – eigentlich durch Wände verdeckten – Levels und nicht in Richtung einer Außenwand ging, stürzten auch die FPS ab. Die Lösung brachte für mich durchaus spannende neue Erkenntnisse zur Bildberechnung in 3D mit sich. In PyGame und 2D war die Sache ganz einfach: Zuerst wurde ein Hintergrundbild auf eine Fläche kopiert, dann wurden nach und nach die weiteren Spielobjekte darüber gelegt bis am Ende das fertige Bild zusammengestellt war. Wie es in Unity und 3D eigentlich funktioniert war mir bis dahin nicht so wirklich klar, denn die Bildberechnung wird einem hier abgenommen.
 
Bildberechnung ohne Occlusion Culling.
Diese Entfernung zu den konkreten Abläufen im Hintergrund führt natürlich dazu, dass man erst einmal keine Ahnung hat, wenn Probleme auftauchen können. Nach ein wenig Recherche durfte ich dann feststellen, dass die Bildberechnung in 3D im Wesentlichen wie die in 2D funktioniert: Die Kamera berechnet auch hier das am weitesten entfernte Objekt zuerst und platziert dann nach und nach näher am Betrachter liegende Objekte davor. Kein Wunder also, dass die Bildrate nach unten geht, wenn plötzlich der ganze Dungeon berechnet wird! Einfach wäre es nun gewesen, nur die Weitsicht der Kamera zu reduzieren. Aber dann gäbe es auch keine langen Gänge mehr und auch Abschnitte im Freien waren angedacht.

Eleganter ist die Verwendung des in Unity auch verfügbaren Occusion Culling: Hier wird zunächst geprüft, welche Objekte überhaupt sichtbar sein können. Durch eine Wand verdeckte Objekte werden also direkt übersprungen, in meinem Fall entfiele also die Berechnung des Dungeons. Um dies zu nutzen, müssen die entsprechenden Daten allerdings vor Start des Spiels berechnet werden. Kaum hatte ich dies nachgeholt, war die Bildrate konstant und das Problem erst einmal gelöst!
 
Bildberechnung mit Occlusion Culling.
Dann musste ich das Vive-Projekt allerdings erst einmal zurückstellen, denn um Kleinigkeiten wie die Button-Belegung oder die Auswahl der Zauber abzuschließen, müsste ich mir erst einmal darüber im Klaren sein, welche Buttons und Zauber ich überhaupt verwenden möchte. Die erzwungen langsame Bewegung beim Fallensuchen in vielen AD&D-RPGs nervt mich etwa schon seit Jahren. Mein bisheriger „Fallen suchen“-Button war da eher noch schlimmer. Gleiches galt für die Suche nach Schätzen und Themen wie dem Einbau einer Automap. Solche Fragen sind aber umfangreich genug für einen eigenen Teil dieser Reihe und ich wollte vorher ohnehin ein anderes Thema angehen, das durchaus Einfluss auf darauf haben könnte.
 

Zufällige Dungeon generieren: Die Theorie

Das Erzeugen zufälliger, neuer Levels interessierte mich einerseits wegen der technischen Herausforderung. Andererseits war mir klar, dass ich letztlich wahrscheinlich der einzige Nutzer meines Spiels sein werden würde. Mit zufällig erstellten Dungeons könnte ich mich wenigstens beim Leveldesign noch selbst überraschen.
 
Auch wenn ich schon eine grobe Idee hatte, wie es funktionieren könnte, las ich mich erst einmal ins Thema ein, wobei eine ältere Blog-Reihe von Andrew Doull hier besonders hilfreich war. Dort stellte er zwei mögliche Herangehensweisen vor: Bei der ersten wird das Spielfeld (also etwa 50x50 Felder) in Abschnitte unterteilt (etwa 10x10 Abschnitte à 5x5 Felder). In einigen (oder allen) Abschnitten wird dann ein zufälliger Raum platziert. Bei der anderen, eher für Höhlensysteme geeigneten Möglichkeit, werden von den Mittelpunkten der jeweiligen Abschnitte in alle Richtungen zufällig lange Strahlen ausgeschickt. Jeder berührte Punkt wird zu einem begehbaren Feld. Natürlich lassen sich auch beide Möglichkeiten kombinieren.
 

Zufällige Dungeon generieren: Die Praxis

Ich entschied mich zunächst für die erste Variante. Vorgefertigte Räume in Unity zu erstellen und in einer Liste abzulegen ist kein Problem. Entsprechend begann ich, ein Script zu entwerfen, das bei Spielstart geladen wird, die genannten groben Abschnitte anlegt und in einem dieser Abschnitte einen ersten Raum mit dem Spieler platziert. Danach geht es in eine der vier Himmelsrichtungen mit einem benachbarten Abschnitt weiter wo ein neuer Raum erstellt wird, bis die eingestellte Anzahl an Räumen fertig ist. Lässt sich ein Raum nicht platzieren (etwa weil in der ermittelten Richtung die Spielfeldkante erreicht ist), geht es solange zurück, bis eine andere Abzweigung möglich ist. Sind alle Räume platziert, tragen sich alle Teile dieser selbst als Wand, Möbelstück oder als begehbares Feld in einer übergeordneten Liste ein, in der verwaltet wird, welches Feld frei ist und wo sich Spieler, Monster und Wände befinden (hier hatte ich ja mein altes PyGame-Grundgerüst übernommen).
 
Interessant wurde die Frage, wie die Räume miteinander verbunden sein sollten: Einfach wäre es gewesen, alle Räume gleich groß zu gestalten und immer direkt passend aneinanderzusetzen. Dann wären aber die Türen in allen Räumen immer an den gleichen Stellen. Wenn ich den Level aber schon zufällig erzeuge, dann auch richtig, dachte ich mir und wählte den komplizierteren Weg. Nach der Platzierung eines Raums griff dieser nun auf mein Monster-Wegfindungsscript zu, das den Weg vom Mittelpunkt des alten zum Mittelpunkt des neuen Raums ermittelte. Indem ich in den verschiedenen vorgefertigten Räumen einzelne Wandabschnitte als fest und andere als mögliche Türen definierte, waren sie nun auch jedes Mal etwas anders platziert. Schließlich wurden die neu erstellten Gänge noch mit Seitenwänden versehen und fertig war ein spielbarer Level.
 
Anzeige
Ein zufällig generierter Level (mit farbenfrohen handgezeichneten Texturen, die ich erstmal wieder gestrichen habe).
Das Schöne daran: Durch die Veränderung weniger Variablen lassen sich verschiedene Räume mit anderem Setting wählen (etwa Liste 1 im Minenlook, Liste 2 dann wie eine Gruft), die Anzahl der Räume und der Querverbindungen zwischen diesen verändern und Art und Anzahl der Monster steuern.
 
Leider waren mit den zufälligen Dungeons auch wieder die VR-Performance-Probleme zurück, denn das oben erklärte Occlusion Culling erfordert ja eine Berechnung der Sichtlinien im Editor, was natürlich bei zufällig erzeugten Dungeons nicht möglich ist. Auch die Lichtberechnung, die für feststehende Objekte ebenfalls im Vorfeld im Editor vorgenommen werden kann, muss bei zufälligen Levels vollständig in Echtzeit erfolgen. Auch längeres Suchen in Foren half mir nicht weiter, eine nachträgliche Berechnung bei Start des Levels ist wohl nicht möglich. Es blieben also – neben Optimierungen wie dem Erzeugen der Monster erst beim Öffnen einer Tür und nicht schon bei Berechnung des Levels – zwei Möglichkeiten: Das Erstellen einer großen Zahl zufälliger Levels im Voraus, um bei diesen dann Licht und Sichtlinien zu berechnen, was aber nachträgliche Änderungen am Spiel erschwert, einen großen Berg Daten mit sich bringt und generell irgendwie witzlos ist. Oder bei zufällig erstellten Levels jedenfalls im VR-Modus die Sichtweite deutlich reduzieren und beim Erzeugen der Levels längere Gänge zu vermeiden (da diese sonst im Nebel enden würden).
 

Wie soll es weitergehen?

Die weiteren Teile:
Teil 1: Python und PyGame
Teil 2: Unity und C#
Teil 3: Blender und Make Human
Teil 4: VR und zufällige Levels
Es blieb natürlich eine dritte Möglichkeit, nämlich auf eines der beiden Features zu verzichten. Diese Entscheidung schob ich etwas frustriert erst einmal auf und begann, mich einer grundsätzlichen Überarbeitung der Spielmechanik und ersten, auch außerhalb des Editors spielbaren Testversionen zu widmen. Beim Erstellen der fertigen Spieldateien bietet Unity wieder sehr spannende Optionen, wodurch ich hoffentlich im nächsten Teil dieser Serie auch eine spielbare Version bereitstellen kann.
LRod 29. Dezember 2017 - 1:24 — vor 46 Wochen aktualisiert
Slaytanic 24 Trolljäger - P - 49234 - 29. Dezember 2017 - 0:46 #

Damit hätte ich dieses Jahr nicht mehr gerechnet. War wieder sehr interessant zu lesen und einen Upvote gab es von mir auch gleich noch dazu. :)

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 13:50 #

Vielen Dank :-)

Und auch ein Dankeschön an Chris und Admiral Anger fürs Redigieren!

Larnak 21 Motivator - P - 27817 - 29. Dezember 2017 - 3:28 #

Ich beneide nach wie vor deinen Fleiß und deine Ausdauer :)

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 13:43 #

Das wirkt manchmal besser als es ist :-) Ich brauche auch immer mal wieder etwas Abstand und auch wenn es etwas interessantes zu spielen gibt pausiere ich immer wieder. Aber es macht halt doch soviel Spaß, dass ich immer wieder weiter daran arbeite.

ruerob 12 Trollwächter - P - 1043 - 29. Dezember 2017 - 14:22 #

Hahaha! Das kenne ich! Manchmal mach ich wochenlang gar nichts und dann die Nächte durch! Haha! Das kommt bei mir in Schüben! :0)

Larnak 21 Motivator - P - 27817 - 29. Dezember 2017 - 17:19 #

Naja, es ist in jedem Fall besser als bei mir :D

Aladan 24 Trolljäger - P - 49418 - 29. Dezember 2017 - 6:01 #

Du machst wirklich gute Fortschritte. Wenn du so weiter machst, kannst du dir vielleicht irgendwann das programmieren einer echten Gegner-Ki durchziehen.

Verfolge dein Thema wirklich gern, kann vieles nachempfinden.

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 13:44 #

Ja, das ist ein spannendes Thema, in das ich mich auch schon etwas eingelesen habe. Aktuell läuft es noch sehr einfach ab - die Gegner können ja auch noch nichts außer Nahkampf-Angriffe. Aber das werde ich früher oder später (evtl. bei einem etwas freier gestalteten Projekt) einmal in Angriff nehmen.

euph 26 Spiele-Kenner - P - 65015 - 29. Dezember 2017 - 6:59 #

Kudos von mir und wieder sehr interessant zu lesen. Bitte mehr davon.

X-mas (unregistriert) 29. Dezember 2017 - 8:09 #

Wie taucht man am besten in Blender ein?

Ich kann mit 3DMax, SketchUp, SolidWorks, Creo und FreeCAD umgehen. Und alle haben eine normales Windows Interface mit üblicher Menüleiste, üblichen Tastenkürzel, üblicher Maussteuerung, etc. Außer Blender, das hat ein sehr sehr eigenartige Steuerung erinnert an 1990er Unix und in-house Level-Editoren-Bedien-Katastrophen der 1990er Jahren ala Tomb Raider 1-5. Und jedes Tutorial das ich ausprobierte stellte sich als veraltet heraus und die Blender Oberfläche war nicht mehr so wie im Tutorial. Und man kann sehr leicht mit einem falschen Mausklick das Blender-Interface verstellen und kommt dann nicht mehr zurück. Leider sind sogar die Maustasten vertauscht und rechtsklick macht das was in normalen Programmen ein linksklick macht, usw.

Wäre echt froh wenn die Blender Entwickler mal über den Tellerrand blicken würden und ein neues Interface andecken würden. Selbst die GIMP Entwickler haben das inzwischen gemacht.

Kannst du aktuelle Tutorials zum Einstieg in Blender empfehlen? Leider sind die beiden Blender-Video-Tutorial-Empfehlungen aus deinem letztes Artikel (Teil 3) bei Amazon nicht mehr verfügbar.
(ggf auf Youtube)

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 13:49 #

Gute Einstieg-Tutorials kann ich dir leider nicht empfehlen. Bis ich diese Reihe gefunden habe, hatte ich da auch große Probleme mit dem Einstieg (die Mausbuttons müsstest du aber in den Einstellungen tauschen können). Youtube ist super, was einzelne Themen angeht, etwa das Modellieren von Haaren etc. Aber ein richtigen systematischen Einstieg samt Erläuterungen habe ich da nicht gesehen (heißt nicht, dass es den nicht gibt).

Die Kurse gibt es noch als Download beim Verlag:

https://www.rheinwerk-verlag.de/blender-27_3629/
https://www.rheinwerk-verlag.de/das-blender-training-charakter-design_3549/

crux 15 Kenner - 2909 - 30. Dezember 2017 - 0:23 #

Ich hatte eigentlich keine Muehe, mich in Blender einzuarbeiten, aber ich kenne die anderen Programme nicht und bin daher vielleicht nicht vorbelastet gewesen. Ich finde, man kann ausgezeichnet und schnell mit dem Programm arbeiten, und finde anderes (wie GIMP) im Vergleich inzwischen schmerzhaft unpraktisch.

Die rechts/links-Vertauschung laesst sich konfigurieren (File/User Preferences/Input/Select With).

Was Tutorials angeht, sollte man sich von allem erst einmal fernhalten, was unterhalb von Version 2.6 behandelt. Danach hat sich glaube ich nichts grundlegendes geaendert. Ich glaube, da muesste sich einiges finden, aber ich weiss nicht, wo es bei dir hakt, daher weiss ich nicht, ob irgendwelche der folgenden Links hilfreich sind:

https://cgcookie.com/lesson/first-steps-with-blender
https://www.youtube.com/watch?v=6Yxrke72isQ
https://www.youtube.com/watch?v=JYj6e-72RDs

Nuetzliche Tastaturkuerzel: N und T, um die beiden Seiten-Panels zu verstecken oder wieder aufzurufen; Ziffernblocktasten fuer Perspektive, und (sehr nuetzlich) Space, um jede der Editierfunktionen zu suchen.

X-mas (unregistriert) 30. Dezember 2017 - 10:06 #

@LRod und @crux:

Danke für die Blender-Einstiegs-Tips!

@crux: wg Vorbelastet, das kann in der Tat da helfen. Bei keinem PC Spiel tue ich mich schwer die teilweise komplizierte Bedienung mir schnell anzueignen. Und bei Windows UI programmen aber auch Linux und MacOS Programmen hatte ich noch nie ein Handbuch benötigt, auch bei 3D Programmen wie 3DMax, Maya, SketchUp, etc. Nur bei Blender halt, das hält sich an keine mir ersichtlichen Konventionen und es macht vieles einfach anders als die Konkurrenz, warum auch immer. Im open source Bereich gibt es leider keine Alternative, da heißt es nun halt durchbeißen.

Gurumeditation 12 Trollwächter - 1119 - 29. Dezember 2017 - 8:41 #

Danke erneut für die schönen Einblicke. Ich frage mich ob ich nächstes Jahr endlich wieder den hintern hoch bekomme für weitere Programmier-Übungen in Unity :), aber zum ende dieses Jahres war so viel noch zu erledigen da muss man doch erstmal Zeitverzögerungen hinnehmen.

Ghost0815 14 Komm-Experte - 2382 - 29. Dezember 2017 - 9:03 #

Danke für den 4. Teil.

xan 17 Shapeshifter - P - 8433 - 29. Dezember 2017 - 11:10 #

Ich habe deine Erfahrungen wieder gerne gelesen. Freue mich auf weitere Teile!

Maryn 13 Koop-Gamer - P - 1531 - 29. Dezember 2017 - 12:20 #

Vielen Dank für den Beitrag!

Wegen meines langweiligen Jobs bin ich selber gerade dabei, mich nebenher programmiertechnisch weiterzubilden. Ich mache das nicht mit Büchern, sondern mit Onlinekursen auf edX.

Da tut es gut, solche Beiträge zu lesen von Leuten, die vor ähnlichen Herausforderungen stehen. Ich weiß, wieviel Überwindung und Ausdauer darin steckt, sowas nebenher zu machen und drücke daher meinen größten Respekt an Dich aus!

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 23:39 #

Danke, spannende Angebote gibt es auf der Seite. Die werde ich mir bei Gelegenheit noch einmal genauer anschauen!

ruerob 12 Trollwächter - P - 1043 - 29. Dezember 2017 - 14:19 #

Das trifft sich ja! Haha! Ich hab heute ein Spiel in den Play Store gestellt! Hahaha!

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 23:39 #

Verlink das doch mal :-)

ruerob 12 Trollwächter - P - 1043 - 30. Dezember 2017 - 3:13 #

Ist aber nur was kleines für zwischendurch. :0) Ich verlinke hier mal die kostenlose Web Version. :0) Obwohl es auf Smartphone mehr Spaß macht. :0) Hehe.

https://gamejolt.com/games/dotty/307708

Auf der Seite weiter unten gibt es auch einen kleinen Bericht über den Entwicklungsverlauf. Aber nicht so ausführlich wie bei dir. :0)

Brackenburg 13 Koop-Gamer - 1479 - 29. Dezember 2017 - 15:10 #

Mit dem Problem mit dem Occlusion Culling bist du nicht alleine, man findet unter "dynamic occlusion culling" sicherlich Einiges.
Es gibt fertige Scripts im Asset Store dazu ("InstantOC" für 25$ zum Beispiel), oder du kannst ein eigenes System mittels Triggercollidern machen: Wenn man einen Raum betritt guckt man, welche Räume man von dort sehen kann oder nicht und aktiviert oder deaktiviert diese entsprechend.
Wenn jeder Raum über seine Türen und seine Nachbarräume Bescheid weiß, sollte das ganz gut gehen.

Ansonsten weiter viel Erfolg! Bin gespannt auf die Stunde der Kritiker.

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 23:41 #

Danke, das deaktivieren der nicht sichtbaren Räume wäre wahrscheinlich nicht einmal schwierig. Das werde ich einmal ausprobieren, wenn ich mich wieder mit der VR-Fassung beschäftige.

Brackenburg 13 Koop-Gamer - 1479 - 30. Dezember 2017 - 12:53 #

Es müsste reichen, den MeshRenderer zu deaktivieren, so dass Gegner noch herumlaufen können etc.

gamalala2017 (unregistriert) 29. Dezember 2017 - 17:41 #

Ein Artikel zum Thema Polishing wäre nicht schlecht.

Gerade in diesen Bereich kämpfen viele Einsteiger obwohl das eigtl. einfache zu erledigende Dinge sind.

Kurzfassung/Idee für ein Artikel: Polishing wäre z.B. die Integration eines kleines Hauptmenüs, Introscreen, Storyscreen (vom Hauptmenü abrufbar), Soundoption, Credits (Screen), Musikstücke und das Lizenzhandling (max. 3 stück für den Anfang (intro, menü, game)).

Wenn das Game später mehr Pepp hat, dann kann man auch die Screens aufwerten (vllt. sogar mit Animationen).

Die Sache mit den Screens klingt zunächst kindisch/albern/unwürdig, aber für VR die beste Lösung, weil Engine-Unabhängig und kann man selbst im Grafikprogramm machen. (Es gibt auch Plugins für Adobe Produkte)

LRod 15 Kenner - - 3248 - 3. Januar 2018 - 8:41 #

Danke, das ist ein Thema, das ich auf jeden Fall im Hinterkopf habe. Ein wenig habe ich in der Richtung auch schon gemacht. Ich habe z.B. ein Hauptmenü und ein Spielmenü. Allerdings beides noch mit wenig Optionen. Soundoptionen fehlen noch komplett.

Demnächst werde ich mich einmal mit Musik und Sound beschäftigen müssen, in dem Zuge werde ich sicher beides erweitern und dann auch einmal darüber schreiben.

Das mit den animierten Screenshots ist ein guter Hinweis, da habe ich noch gar nicht dran gedacht. Werde ich mir auf jeden Fall einmal anschauen!

Olipool 16 Übertalent - 4552 - 3. Januar 2018 - 23:02 #

Da möchte ich höflich widersprechen :) Polishing besteht keineswegs nur aus einfach zu erledigenden Dingen. Es ist mitunter sehr schwierig, weil man eben nicht einfach nach Kochrezept vorgehen kann, sondern vielfach Iterieren muss.

TheRaffer 18 Doppel-Voter - - 11599 - 29. Dezember 2017 - 19:01 #

Eine meiner liebsten "Serien" hier. Vermittelt mir Laien doch sehr schöne Einblicke in die Probleme auf die man so stoßen kann und was alles bedacht werden muss bei der Programmierung. Ich bewundere deinen Elan bei der Programmierung und dann auch noch die Fähigkeit das so interessant zu lesen aufzuschreiben. :)

Ich glaube einige Spieler wirst du hier schon finden und wenn es nur aus Neugier ist, wie das Projekt sich so entwickelt. ;)

LRod 15 Kenner - - 3248 - 29. Dezember 2017 - 23:57 #

Vielen Dank für das Kompliment. Macht ja auch Spaß zu schreiben. Darum hat die Reihe auch schon mehr Teile als ursprünglich gedacht und solange ich interessante Themen finde mache ich auch gerne weiter. Für 2-3 Teile reicht es auf jeden Fall noch. Danach muss ich mal schauen, wie und ob es weitergeht.

Olipool 16 Übertalent - 4552 - 30. Dezember 2017 - 19:57 #

Danke fürs Update :)
Ich würde mal probieren, ähnlich wie Brackenburg vorgeschlagen hat, nur die Räume zu rendern, die um dich herum sind. Das mit der Sichtbarkeit wäre noch eine Spur more advanced aber du kannst ganz einfach damit anfangen nur deinen und alle angrenzenden Räume zu rendern. Hm wobei...ich merke grad du hast ja auch lange Passagen über mehrere Räume drin, das geht dann natürlich schlecht :(
Naja, so hat man immer was zum puzzeln und jedes mal, wenn man was anfasst, tut sich ein langer Rattenschwanz auf :)

Wen es interessiert, wie schmerzvoll Spieleentwicklung selbst bei Profis ist, dem kann ich "Blood, Sweat and Pixels" empfehlen. Es kommen dort Einsichten zu z.B. Uncharted 4, Last of Us, Stardew Valley, Diablo 3 etc. zu Tage... Burn out, 16h Tage, fiese Stolpersteine...

Brackenburg 13 Koop-Gamer - 1479 - 30. Dezember 2017 - 20:39 #

Ich würde so etwas vorschlagen:
P: Raum, den der Spieler betritt
0: angezeigter Raum
X: nicht angezeigter Raum

XXXX0XXXX
XXXX0XXXX
XXX000XXX
0000P0000
XXX000XXX
XXXX0XXXX
XXXX0XXXX

(Ich hoffe es ist ersichtlich was ich meine. Es schien mir so besser als es zu beschreiben.^^)

Man könnte noch bei den vier Strahlen abfragen, bis wohin genau offene Türen in diese Richtung vorhanden sind, um mehr Ressourcen zu sparen.

LRod 15 Kenner - - 3248 - 3. Januar 2018 - 8:44 #

Ja, das könnte helfen, weil das ansonsten dargestellte Sichtfeld viel breiter ist. Und relativ einfach umsetzbar sollte es auch sein, weil ich ja in der Zufalls-Variante alle Räume und bei diesen jeweils alle Raumelemente in einer Liste hinterlegt habe.

Werde ich auf jeden Fall einmal ausprobieren!

gamalala2017 (unregistriert) 30. Dezember 2017 - 22:01 #

Ich gehe stark davon aus dass du keine Lust zu Polishing hast, weil du ja irgendwie nicht auf eine allgemeine Idee, geäußert von mir, reagiert hast. :/

John of Gaunt 26 Spiele-Kenner - P - 75057 - 2. Januar 2018 - 20:20 #

Das geht mehr auf unsere Kappe, den Kommentar haben wir übersehen und er war daher nicht sichtbar.

Larnak 21 Motivator - P - 27817 - 3. Januar 2018 - 0:02 #

Wie frech von euch ;D

LRod 15 Kenner - - 3248 - 3. Januar 2018 - 8:47 #

Sorry, die Benachrichtigung kam tatsächlich erst gestern abend an. Habe inhaltlich oben etwas zu dem Kommentar geschrieben. Sound und Polishing werde ich auf jeden Fall einen eigenen Abschnitt, ggf. sogar einen ganzen Teil widmen (in letztem Fall vielleicht in Kombination mit dem visuellen Polishing durch Post Processing).

Kommentar hinzufügen

Neuen Kommentar abgeben
(Antworten auf andere Comments bitte per "Antwort"-Knopf.)