[Projekt] Cyberhive

[joeydee]

Ich habe einfach mal den Beschluss gefasst, aus diesem Prototyp/Experiment ein ausführlicheres Projekt zu machen.

Die Grundlage kennt man noch aus dem allgemeinen Vorstellungsthread: Eine selbstgebastelte Minimal-Engine für einen kleinen Drohnen-Shooter aus Egoperspektive.
Eine tolle Renderengine ist dabei Nebensache, mir geht es bei dem Projekt hauptsächlich um möglichst bequeme und wiederverwendbare Wege, um Standardaufgaben wie Kollision, AI, irgendwas treffen/sammeln/schalten, Türen öffnen, Trigger, States usw. immer weiter auf einen übersichtlichen Nenner zu bringen. Sprich, mein persönliches Framework zu erweitern und aufzuräumen. Und das geht für mich besser anhand von Miniprojekten als durch pure Planung.

Irgendwann hatte ich die grauen Texturen satt, obigen Screenshot übermalt um mal eine grobe Idee für ein Thema zu bekommen, und dann erste Texturen gemacht.

Der Texture-Workflow sollte dabei auch möglichst einfach bleiben. Ich habe schon Texturen mit x Maps gemacht und weiß wie sehr das alles aufhalten kann, bis einmal ein ganzes Set zusammengestellt und mit den Shadern durchgetestet ist.
Daher: Nur 3 WYSIWYG-Kanäle, keine Effektlayer, Grundlage ist immer ein Vektor-Tiefenlayout, darüber eine Art SSAO-Filter, der Rest wird mit möglichst neutraler Lichtrichtung gemalt, Illu wird für ein paar HDR-Werte im Shader per Exponent aus den hellsten Werten der Diffuse geschätzt und am Ende auf den Fog-Pass addiert. Keine (dynamische) Beleuchtung. Einfacher gehts kaum, wenn man statt reinen DevTexes ein klein wenig Atmo haben möchte. Erinnert an die frühen Shooter, aber die Geometrie ist besser lesbar als damals.

Tatsächlich hat mich "Descent" bei dieser Idee geprägt. Entsprechend auch die obligatorische Story:

Weit unter dem Wüstensand hat sich in den vergangenen Jahrzehnten, unbemerkt von der Menschheit, eine autonome unterirdische Anlage entwickelt.
Gebaut von Maschinen, die sich selbst reproduzieren und weiterentwickeln können, zieht sich die Anlage bereits wie ein Nervennetz mit unzähligen Etagen und Knotenpunkten tief durch das Grundgestein.
Langsam aber mit stetem Fortschritt bewegen sich die Adern auf die ersten Großstädte und Kraftwerke zu ...

Oder die Kurzfassung:
Schieße auf alles was sich bewegt bevor es dich erwischt, und sammle alles ein was schön blinkt.

Was noch an Gameplay-Elementen Einzug halten wird, steht noch nicht fest. Sicher noch was mit Codes für Türen.
Auch wenn das hier jetzt der Einfachheit halber in einem Grid-Level spielt, nichts davon ist an ein Grid/Zellen/Portale oder überhaupt ein Levelprinzip gebunden. Entsprechend geht keine Optimierung flöten, wenn man mal große Räume haben will. Oder mal gar keine.

Und so sieht das aktuell aus, mit vorläufig generisch erstellten Drohnen:

[marcgfx]

Sieht schon ziemlich cool aus! Für Concept-Art scheinst du auch ein gutes Händchen zu haben. Womit hast du das gemacht? Hast du womöglich ein Tablet zum malen (ich wollte mir sowas immer mal zulegen...)?

[xq]

Schließe mich meinem Vorredner an, sieht schon sehr cool aus! Aber wofür brauchen den selbstreplizierende Würfelstrukturen eigentlich diese Bildschirme auf allen Blöcken?

[scheichs]

yummy yummy.... das hört sich alles sehr clever an, was Du Dir überlegt hast!

[joeydee]

Danke euch.
@marcgfx: Richtig geraten. Ich habe Jahre mit einem A5-Intuos verbracht (sowas würde ich dir als Einstieg empfehlen) und mir vergangenes Jahr ein Cintiq 22" zugelegt. Programm ist PSD CS2, aber das ist eher zweitrangig.

@MasterQ32, die ehrliche Antwort: Ich weiß noch nicht wofür die überall Monitore brauchen könnten, ich brauche sie aktuell für ein wenig Abwechslung, "sense of scale", sowie einen Vorwand warum der Nebel im Hintergrund grün leuchtet. Zur Zeit des Concept-Art stand noch keine Story fest, ich habe einfach mal 3-4 passende Texturideen umgesetzt und zufällig über die Wände verteilt. Sollten mir Monitore am Ende noch gefallen, wird sich dafür sicher ein Story-Hint einflechten lassen.

[Krishty]

Das gefällt mir, und wie du entwickelst, klingt so wunderbar effizient :)

[joeydee]

Nachträglich noch danke, Krishty, solche Worte aus deinem Mund in meinem Thread ... :)


Auch wenn es nicht die angepeilte Zielplattform ist - ich habe es einmal gewagt eine sehr frühe Version für Browser/Flashplugin zu compilieren. Nur aus Neugierde:
http://develop.diehlsworld.de/hive/

Steuerung:
- WASD2X zum "strafen" (2 und X für steigen/sinken),
- Maus (klicken+ziehen) oder Cursor zum Umschauen,
- Space zum Ballern.
Klick auf die halbtransparente Fläche am Anfang startet das Ganze.

Es wird ein Zufallslevel generiert; theoretisch kann man in einer kleinen Blase (Levelabschnitt ohne Verbindung zum Rest) gefangen sein, dann einfach nochmal laden.
Sterben kann man in dieser Demo nicht, ist einfach mal zum umschauen gedacht.
Kästchenreihe oben: Punkte; kann man durch Sammeln gelber Chipkarten erhöhen. Unten: Verbleibende Chipkarten und Drohnen im Level. Wenn man eine Drohne zerstört hat (3 Treffer notwendig), bleibt eine Chipkarte übrig. Kann sein dass man nicht alles findet - die Objekte können nämlich ebenso in Blasen gefangen sein.
Und wenn man alles hat, passiert ... tadaaa ... nichts. Das ist nur die Basis, auf der man evtl. ein Spielprinzip aufsetzen könnte, mehr noch nicht.

Wenn ein oder mehrere größere Kästchen links oben in der 2. Zeile blinken, heißt das, man wurde gesehen und wird verfolgt. Innerhalb eines Zeitrahmens fliegt die Drohne bis zur zuletzt gesichteten Position. Keine aktive Suche oder patrol. Das ist momentan die ganze KI.
Den Drohnen fehlen noch ein paar LEDs damit man sie besser sieht. Denen fehlt eigentlich noch alles. Die Box-Art ist nur generischer Platzhalter, mit ebenso generischen Gittertexturen. Das verschwindet noch arg im aktuellen Hintergrund.
Das Fadenkreuz fehlt, Schüsse werden noch nicht dargestellt, Einschläge passieren mit Lichtgeschwindigkeit und ergeben grundsätzlich eine kleine Explosion. Eingesteckte Treffer merkt man höchstens an einem kleinen Pusher.
Insgesamt fehlt also noch sehr viel Feedback an den Spieler.

Was bzgl. Flash zu erwarten war und ist:
- Einem unbekannten Browser mitzuteilen, dass er einem Plugin Zugriff auf Hardwarebeschleunigung geben soll scheint ein größeres Ding zu sein. Bin mir nicht sicher ob das überall reibungslos klappt.
- Der Garbage Collector im Flash-Plugin ist totaler Müll. Schon immer. Da noch einige quick'n'dirty-Aktionen drin sind, kann der öfters mal gnadenlos zuschlagen.
- In manchen Testumgebungen ruckelte das an Stellen, wo es gar nicht nachvollziehbar war.
- Manche Browser scheinen ein grundsätzliches Problem damit zu haben, wenn mehrere Tasten dauerhaft gedrückt sind und dazu noch Mausaktionen kommen. Fühlt sich wie ein Tastaturüberlauf an, sowas hatte ich auch schonmal mit JS/WebGL. Lässt sich softwareseitig leider nicht abfangen.
- Flash ist tot. Gottseidank. Die Performance ist viel zu abhängig vom verwendeten Browser bei ressourcenkritischen Projekten.
- In einer AIR-Installation läuft das alles deutlich besser. Mac & PC Desktop wäre dann auch das primäre Ziel. Dazu wirds auch mal einen Download geben, bei Gelegenheit.

[marcgfx]

Das Spiel hat auf meinem Macbook Pro einwandfrei funktioniert. Ich habe mit WASD und Pfeilen gespielt Eine Drohne ist mir nicht über den Weg gelaufen, aber ich habe einige dieser gelben Kärtchen gesammelt. Die Rotation war mir etwas zu langsam, mit der Maus wärs sicher besser gewesen. Orientierung hatte ich überhaupt keine, das Fliegen an sich hat mir aber gut gefallen :)

[joeydee]

Dank der einen und anderen Action sowie dem Beschluss, die zugrundeliegende Technik komplett auf C++ umzubauen, war die Weiterentwicklung an diesem Projekt etwas stehengeblieben. Aber noch nicht auf Eis gelegt. Hier ein kleines Zwischenupdate, da man seit ein paar Tagen auch mal wieder Farbe sieht statt nur graue Dev-Texturen und Linien.


Ob es Außenlevel geben wird bin ich mir noch gar nicht sicher. Farbiger Nebel mit etwas "Zero-Dawn"-Farbschema funktioniert aber immer, innen wie außen.


Vieles wird in Retro-Flat-Optik bleiben, aufgemalte Details und Alpha-Testing statt echte Geometrie. Der Font ist nicht final, bleibt aber monospaced.
Im Moment teste ich ausschließlich in prozedural erstellten Levels, um mir das ständige Anpassen eines Levelformats zu ersparen. Bis mal das Wesentliche enthalten ist. Bis dahin sieht es überall relativ gleich aus.
Gameplay- bzw. Missionsmäßig wird es ein einfacher Verschnitt aus allgemein Bekanntem. Von den drei hier gelisteten "Missionszielen" ist aktuell nur das mittlere keine Fake-Anzeige :D

[scheichs]

Super atmosphärisch! Vor allem die monströse Struktur im Hintergrund sieht super geil aus!

[joggel]

Sieht sehr fett aus (y)

[joeydee]

Passt jetzt noch nicht direkt zu Hive, eher zum Framework/Engine im Allgemeinen, aber die Technik wird hier dann natürlich auch Einzug halten.

Meine Entity-Verwaltung war schon immer in Richtung Data-oriented inspiriert, d.h. Komponenten in gemeinsamen Listen gesammelt welche von einem jeweils dafür spezialisierten System am Stück abgearbeitet werden können, statt jeweils einzeln in einer vererbten Entity-Klasse zu liegen mit update()-Methode, Komponenten-Aufzählungen, Typkennungen oder was einem sonst so einfällt um die typischen Probleme zu lösen.

Meine bisherige Lösung (mit Querverweisen zwischen Komponenten) war allerdings noch sehr unflexibel, je komplexer die Aufgaben wurden desto weniger wiederverwendbar in anderen Projekten.
Nun habe ich das Data-oriented noch etwas konsequenter umgesetzt, ganz weg von Klassen, Instanzen, Referenzen und Methoden für ein Entity. Hin zu reinen Daten(paket)listen und Systemverarbeitern. Nicht wegen Geschwindigkeit und möglicher Parallelisierung (dafür sind meine Lookups viel zu unoptimiert und meine Projekte viel zu klein), sondern einfach wegen der Flexibilität.

Das Handling fühlt sich jetzt praktisch wie eine riesige Partikel-Engine an: jede Komponente (Position, Bewegung, Mesh, KI, ..., MyNewHyperFancyAspectTomorrow) "ist" praktisch ein Partikel und wird per spawn(id) in seiner Liste (System) aktiviert. Ein festes Paket/Struct/Klasse welches die Komponenten bündelt in der Form "Entity{unsigned id, Vector3D position, AiComponent ai, ...}" gibts nicht mehr.
Wenn ich im Render-System dann spontan entscheide, dass ich z.B. die Lebensenergie von KI-Elementen als Balken mitrendern will, frage ich die KI-Liste, welche ihrer Elemente dieselbe id wie mein aktuelles Renderelement haben. "Entities" existieren also gar nicht mehr physikalisch in ihrer Komponenten-Zusammensetzung, sondern werden on-the-fly bei Bedarf lose "zusammengesetzt", und zwar nur das was gerade für die Aufgabe von Belang ist, und am Ende vom Scope wieder verworfen.

Da es nun jedes System/Liste nur einmal gibt, und jedes System zwecks spontaner Anfragen jedes andere kennen muss, und die einzelnen Datenpakete nicht mehr an eine Klassenstruktur gebunden sind, entfällt praktisch jeglicher OOP-Ansatz. Weswegen das dann auch Data-oriented-Design genannt wird.

Jetzt mal weiterwurschteln, bischen Aufräumen, möglichst praktische Framework-Schnittstelle überlegen und testen ob es in anderen Projekten auch tatsächlich was taugt.

Obligatorischer Screenshot. Zwei Sorten Bots die sich jagen, hab ich ja schon öfter gemacht, das ist nichts Neues. Jetzt eben kleiner Stresstest, viele Spawns, viele Kills, viele Neugeburten (jede Komponentenliste ist ein Pool für sich, d.h. das eben gestorbene Partikel stellt sein Positionsobjekt im nächsten Frame einem zu spawnenden Bot zur Verfügung usw.).

[joeydee]

Shape-Bashing - solch ein Tool wollte ich schon immer mal machen, für das Erstellen von Quick'n'Dirty-3D-Modellen aus zusammengewürfelten einfachen 2D-Polygonen.
Für Game-Platzhalter. Oder im Concept-Art-Prozess um 2D in der Tiefe zu gestalten ohne sich in einem richtigen 3D-Workflow zu verlieren. Oder hier im Hive-Projekt evtl. sogar als finale Modelle.
Jetzt endlich bin ich mal dazu gekommen das anzugehen - allerdings noch genauso quick'n'dirty programmiert wie die Meshes die erzeugt werden :lol:

Das erste Beispiel ist nicht für's Hive-Projekt :D aber hier wird deutlich was genau importiert wird und was man daraus machen kann:

Hier an einem Hive-Drohnenentwurf getestet, im Hintergrund Illustrator mit ursprünglicher Konzeptskizze und SVG-Grafik.
Im Tool der Block rechts oben - das sind aktuell die einzigen Modifier, damit bekommt man aber schon ziemlich viel hin.

Workflow:
- 2D SVG-Grafik z.B. in Illustrator zusammenbashen
- Ins Tool importieren, Flächengruppen nach ID-Namen werden herausgelesen, und mit nur wenigen Slidern kann man vor allem extrudieren und tapern.
- X/Y-Verschieben, umfärben, Shapes editieren: alles nur in Illustrator - das Tool kann einen Reload durchführen ohne dass die Extrusionseinstellungen verlorengehen. Die werden einfach den Ebenennamen zugeordnet.
- Die Tools/Modifier sind so angelegt, dass immer der Seitenris erhalten bleibt. Und entstehende Flächen immer planar sind.
- Für konvexe Ausgangspolygone sorge ich in Illustrator, war erstmal der einfachere Weg.
- Revolve ist noch nicht ausprogrammiert.
- Irgendeinen Export gibts auch noch nicht (wahrscheinlich wirds .obj)
- Natürlich gibts kein CSG, die Objekte stecken beliebig ineinander, Flickern ist an der Tagesordnung.
- Es wird nicht alles an SVG geschluckt. Habe auch nicht vor den steinigen Weg zu gehen und alle Eventualitäten durchzutesten. Wenn es in meinem Workflow funktioniert, tut es seinen Zweck.

Edit: Problem mit dem Imageserver gehabt - Dateien sind nun als Anhang eingebunden.

[marcgfx]

Coole Sache, aber ist damit dein Workflow wirklich schneller? Polygone von der Seite zeichnen und extrudieren ist nicht etwas ungewöhnliches, das sie vorher schon eingefärbt sind schon eher. Ich müsste schon ein Video sehen um den Prozess zu verstehen :)
Das Ergebnis sieht auf alle Fälle gut aus!

[joeydee]

Ja, ist für mich so ziemlich der schnellste und intuitivste Kreativ-Workflow von allem was ich bisher angetestet habe, mit früh sichtbarem Ergebnis, ohne sich Wege zu verbauen.

In 3D bin ich tatsächlich deutlich langsamer, nicht weil ich es nicht könnte, sondern weil ich mich um zu viel anderes gleichzeitig kümmern muss.
Extrudieren ist dabei auch gar nicht der Knackpunkt: Sobald ich einzelne Kanten in der Tiefe verschiebe weil ich mal einen Eindruck mit geneigten Flächen gewinnen will, erzeuge ich Geometrie, die nicht mehr trivial ist. Ich muss neue Kanten einziehen und weitere Schritte immer genauer überlegen.
Mit diesem Tool kann ich gedankenlos und vor allem non-destruktiv herumprobieren. Und kann mir die Modifier dorthin legen wo ich will, nicht im 3. Untermenü mit mittlerer Maustaste und Shift-Alt ;)

Irgendwann mache ich vielleicht mal ein Video wie ich damit arbeite, aber da will ich nichts versprechen.

[scheichs]

Ich finds super genial! Von Konzept auf 3D muss man sich ja normal ewig einen abbrechen. Ich bin immer wieder beindruckt, was Du an custom-Zeugs zusammenbastelst und dazu noch begnadeter Grafiker! Geil!

[joeydee]

Die Frage ...

... das mit den Säulen nochmal ein wenig detaillierter erklären? Der Nebel scheint im Wesentlichen einfach abhängig vom Z-Buffer wert in die Nebelfarbe überzublenden, aber was bedeutet dieser Y axis depth cue?

... beantworte ich besser hier.

Bezieht sich auf dieses Bild:


Was ich da gemacht hatte sind natürlich nur Tricks ohne physikalische Grundlage, dafür einfachste Berechnungen mit etwas Aufpepp-Wirkung zugunsten der Geometrie-Erkennbarkeit. Das wirkt natürlicher als z.B. reine N-dot-L-Beleuchtung ohne Schatten.

1. Depth-Cueing:
Welt-Y bestimmt pauschal einen Helligkeitswert. D.h. oben auf der Landschaft originaler Farbwert, je tiefer desto dunkler. Eine Art billiger AO-Abklatsch, berücksichtigt nicht enge vs. weite Aushöhlungen, kann aber manchmal ruhiger wirken als echtes AO und trennt die Geometrie oft schon ganz gut. Funktioniert vor allem bei gleichmäßigen Cavings, ansonsten muss man die Werte ggf. lokal anpassen.
Kann man hier gut ohne die anderen Effekte sehen:




2. Skydome:
Welt-Y-Richtung bestimmt einen Beleuchtungswert nach N-dot-L-Art (da L=(0,1,0) kann man sich das Punktprodukt natürlich sparen), aber deutlich weicher (genaue Formel müsste ich nochmal gucken, ich hatte vor gefühlt Jahrzehnten mal die Gedanken und Experimente dazu vorgestellt, finde aber leider nichts mehr davon). Das simuliert kein Sonnen-Punktlicht, sondern mehr einen diffusen Skydome, daher bleibt der L-Vektor auch fix. In meinem Labyrinth-Beispiel reduzierte sich das lediglich auf einen etwas helleren Wert für alle horizontalen Flächen und einen dunkleren für alle vertikalen. Die Methode funktioniert auch gut für Topdown-Ansichten:

Topdown-Ansicht, nur Depth-Cue ohne Skydome-Flächen:

Dto. mit Skydome-Flächen:


3. Atmo:
Im Prinzip wie Nebel von Kamera-Z abhängig, aber: Endfarbe einen Hauch dunkler als Himmelsfarbe, und helle Bereiche werden nochmal angehoben und leicht dazuaddiert. D.h. in der Ferne gleichen sich Schatten schneller der Himmelsfarbe an als Lichter, die Landschaft verschwindet nicht in einer dichten Nebelsuppe. Vgl. z.B. den Mond am Taghimmel oder ferne schneebedeckte Berge.


4. Color Gradient
In manchen Szenen liegt nochmal ein Farbgradient drüber. Z.B.: Lichter mehr gelb, Schatten mehr blau. Hat eher einen künstlerischen Effekt, um das Orange/Teal-Farbschema von Kinofilmen zu imitieren.

[Jonathan]

Sehr schön, vielen Dank. Ich muss zugeben, dass ich jetzt emotional verwirrt bin :D. Hier wird mit einfachen Mitteln ein schicker Effekt erzeugt (das ist super) aber alles ist irgendwie so unphysikalisch und scheint sich schlecht auf allgemeine Szenen übertragen zu lassen (das ist nicht so toll).
Aber für das Projekt scheint das eine sehr adäquate Herangehensweise zu sein. Nettes Projekt auf jeden Fall, und da das letzte Update schon einige Zeit her ist: Gibt es irgendwelche Neuigkeiten?

[joeydee]

Eigentlich seltsam, die CG'ler versuchen die Realität möglichst exakt zu imitieren, während Leute am Filmset über reale Lichtverhältnisse fluchen und wie die Weltmeister künstlich abschatten, beleuchten, spiegeln, nachfärben, ..., damit die Szene auf Leinwand nicht so langweilig wirkt ;)

Du hast natürlich recht, ich setze Farben/Beleuchtungen eher gezielt nach Design-Gesichtspunkten statt mich auf einen Relaitäts-Simulator zu verlassen.
Und da ich weiß dass ich sowieso nie eine solch allmächtige AAA-Renderengine entwickeln kann und will die das gut ausehen lässt, spezialisiere ich das lieber auf das Allernotwendigste. Im Prinzip so, als ob ich gerade ein Concept-Bild male.

Neues gibt's aktuell nicht. RL- und verletzungsbedingt musste ich das Hobby zwischenzeitlich aussetzen. Erstmal überlegen, wo ich weitermache.

[Jonathan]

Eigentlich seltsam, die CG'ler versuchen die Realität möglichst exakt zu imitieren, während Leute am Filmset über reale Lichtverhältnisse fluchen und wie die Weltmeister künstlich abschatten, beleuchten, spiegeln, nachfärben, ..., damit die Szene auf Leinwand nicht so langweilig wirkt ;)

Du hast natürlich recht, ich setze Farben/Beleuchtungen eher gezielt nach Design-Gesichtspunkten statt mich auf einen Relaitäts-Simulator zu verlassen.
Und da ich weiß dass ich sowieso nie eine solch allmächtige AAA-Renderengine entwickeln kann und will die das gut ausehen lässt, spezialisiere ich das lieber auf das Allernotwendigste. Im Prinzip so, als ob ich gerade ein Concept-Bild male.

Ja, wie interessant. Ich habe mich in letzter Zeit halt halbwegs viel mit physical-based rendering beschäftigt und in gewisser Weise fährt man sich da fest - so hat das auszusehen und nicht anders. Aber gut, in gewisser Weise versuchen sowohl CGler als auch Filmemacher nur ihre natürlichen Grenzen zu überwinden. In gewisser Hinsicht macht das wohl das Können aus.

Insbesondere für Hobbyprojekte gefällt mir aber deine Herangehensweise sehr. Statt den Gold-Standard schlecht nachzumachen lieber einen eigenen Stil suchen der ein Herausstellungsmerkmal ist und sich auch als Einzelkämpfer gut umsetzen lässt, kombiniert mit einer gewissen Kreativität in Umgang mit üblichen Formeln. Hübsch, hübsch.