Gedanken zu Spiele-Engines

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.

Gedanken zu Spiele-Engines

Beitragvon Krishty » 10.06.2015, 22:44

Mir schwebt zu viel im Kopf rum, und ich werde in absehbarer Zeit nicht dazu kommen, alles zu implementieren … darum schreibe ich es hier auf und vielleicht nützt es jemandem, vielleicht auch nicht. Ich habe auch überlegt, ob es nicht ins allgemeine Talk-Brett gehört, aber es geht wohl doch überwiegend um Algorithmen.

Kein Open World ohne LoD

Detailabstufung ist Essentiell bei großen Spielfeldern. Ich bin lange auf der Schiene gefahren, alles in einem Rutsch zu laden und dann die nahe Umgebung zu rendern – das ist einfach und elegant, weil zustandslos. Leider ist es auch eine Katastrophe, sobald viel Content reinkommt. Ich spreche nicht von der Klasse Performance-Probleme, über die ich normalerweise meckere, sondern wirklich von „katastrophal“.

Der Punkt ist, dass ich zu grafikzentriert gedacht habe. In der Grafik bestimmte ich einfach, was in der näheren Umgebung ist, und das wird gezeichnet. Ist relativ schnell, dank räumlicher Strukturen auch für große Spielfelder mit vielen Einheiten.

Das kann man auch noch machen, wenn es um Klangeffekte geht. Auch da spielt man nur jene aus direkter Nachbarschaft zum Spieler ab.

Bei Ressourcen wird es haariger. Man braucht zumindest Reference Counting, damit nicht jede Einheit ihren eigenen Vertex Buffer für Grafik und ihre eigenen Voices für Klänge anlegt, sondern mit anderen teilt. Aber der Overhead jeder einzelnen Einheit kommt dann schon zum Tragen – ein dutzend Megabyte mehr im Speicher. Auch nicht schlimm. Richtig knifflig wird es dann aber mit dem Speicher – 17.000 Einheiten freigeben (ein spärlich aufregendes weitläufiges Spielfeld) dauert gut zwanzig Sekunden. Das wird der User merken. Pooling! Bucket Allocators! Schmeißt mehr Komplexität auf’s Problem; wir schaffen das!

Alles bricht zusammen, wenn man bei Physik und KI ist. Ohne LOD – und ich meine kein grafisches, sondern richtig abstraktes Gameplay-LOD – wird die Interaktion jedes Reifens mit dem Asphalt simuliert, hundert Mal pro Sekunde, also bei 17.000 Autos schon sieben Millionen Mal pro Sekunde. Jetzt kriecht's. Und die KI macht, wenn der Spieler nicht da ist, überwiegend was? Warten. Oder gemütlich auf ein langfristiges Ziel hinlaufen. Jetzt werden hundert Mal pro Sekunde die Fußstapfen simuliert obwohl die Einheiten bloß geradeaus laufen. Nichts läuft mehr.

Jetzt braucht man also LoD. Am besten welches, das die Einheiten nicht als Einheiten simuliert, sondern ganz abstrakt „hier ist ’ne Gruppe und die bewegt sich die nächsten zehn Minuten auf den Hügel da“. Das die Einheiten nicht wirklich anlegt, sondern bloß einen Zähler führt und beim Ankommen des Spielers neue Einheiten zufällig um einen Punkt entsprechend des Fortschritts auf der Route verteilt. Eines, das nur alle zehn Sekunden oder so aufgerufen wird um sich schnell zu aktualisieren und dabei kaum messbar ist.

Und damit muss man früh anfangen, denn nachträglich einbauen ist scheiße. Bevor man irgendwas mit Open World macht, sollte man sich dessen klar sein. Dieses System sollte das *erste* sein, was man entwickelt. Bevor man überhaupt eine große Spielwelt hat. Man übt einfach, indem man den LoD-Übergang auf 100 m runterschraubt oder so.

Natürlich kann man gleich alles prozedural anlegen und on-demand erzeugen (GTA-style: Spieler kommt zu ’ner Straße, dann stellen wir da alle 10 m ein Auto hin). Aber das geht in die Hose, wenn der Spieler ein Dorf ausraubt und abbrennt, dann weggeht und wiederkommt und alles ist wieder heile Welt und alle Häuser sind wieder in Ordnung und alle Bewohner leben wieder. Oder wenn sich die NPCs untereinander bekämpfen sollen. Große Scheiße.

Also: Von Anfang an eine oder zwei Detailabstufungen in die Spiellogik einbauen, bis die Spiellogik unter 1 MB Speicherverbrauch ist. Dann erst ’ne große Welt bauen und voll Einheiten klatschen.

Und wenn ihr’s richtig macht, habt ihr dabei Multiplayer im Hinterkopf. Also nicht einen Punkt, um den herum hohes Detail ist, sondern beliebig viele, deren Bereiche sich überlappen können.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 10.06.2015, 23:10

SFX-Rendering

Ich schätze, ich bin endlich dahinter gekommen, wie man vernünftig Klangeffekte verwaltet und darstellt. Erstmal mit dem Problem anfangen:

Im Gegensatz zu 3D-Bildern, die diskret jede 60tel Sekunde aufflackern und dann wieder verschwinden, sind Klänge fortlaufend. Man kann nicht jede 60tel Sekunde die Amplitude des Lautsprechers ändern und dann hoffen, dass der Spieler einen Ton versteht. Da muss ein Puffer befüllt werden, der, übermittelt an die Klangausgabe, für die Zeit zum nächsten Frame ausreicht. Das macht man in Paketen, und deshalb wirkt nicht jede Änderung (Lautstärke, Abspielgeschwindigkeit) sofort, sondern ein paar Milisekunden verzögert.

———— Was jetzt kommt, sind die Erfahrungen, wie man es nicht machen sollte. Eigentlich das Wichtigste, aber leider auch langweilig. ————

XAudio bietet für Klänge in erster Linie Start/Stop. Ich habe also in meinem Spiel Klänge, wie das Motorengeräusch meines Autos, erstmal als Endlosschleife gestartet. Ging das Auto kaputt, oder hat der Spieler es verlassen (Beobachtermodus oder so), habe ich den Klang gestoppt.

Nun ist das schon stark vereinfacht. Praktisch hat man nämlich mehrere Darstellungen des selben Geräuschs: Das Motorengeräusch klingt von außen ganz anders als von innerhalb des Autos. Außen kerniger 3D-Klang. Innen ungerichtetes Umgebungsgeräusch mit mehr Tiefe (weil Körperschall). Innen sollte man nicht den Außenklang hören und umgekehrt.

Also anfangs gucken, ob der Spieler im Auto oder in der Verfolgerperspektive startet. Falls im Auto, den Innenklang starten. Sonst den Außenklang. Beim Wechsel von Innen- zu Verfolgerperspekte den einen Klang stoppen und den anderen starten. Ihr merkt, dass es verzwickter wird. Wie macht ihr das unterstrichene? Mit Zustand, also dass ihr ein onExteriorView()-Event auslöst, und das stoppt den einen Klang und startet den anderen? Oder zustandsfrei, so dass eure renderSound()-Methode einfach gemäß eines Flags den einen Klang auf Lautstärke 1 setzt und den anderen auf 0? Protipp: Funktioniert beides nicht.

… nämlich, wenn ihr mit eurem Freund im Splitscreen spielt. Dann sitzt ihr nämlich links in der Innenperspektive in eurem Auto und braucht den Innenklang. Rechts sieht euer Kollege euer Auto aus der Außenperspektive und erwartet den Außenklang. Egal, welche Methode ihr wählt – einer der beiden Klänge fehlt immer. Scheiße an’er Latte. Baut ihr jetzt eine extra-Methode renderSoundInAndOutTogether()? Oh und ihr habt ein Knacken zwischendurch, weil das Umschalten der Klänge verzögert passiert (ihr wisst ja – Paketgrößen auf dem Weg zum Lautsprecher). Oder baut ihr für Splitscreen überall Spezialfälle ein?

———— Meine Idee, wie man es Richtig™ macht: ————

Warum ist Split-Screen mit Grafik so einfach und mit Klang nicht? Weil Klänge nicht verschwinden, wenn man sie nicht rendert. Das ist IMHO das Problem.

Also man setzt zu Beginn des Frames in allen Klängen ein Flag, dass der Klang jetzt nicht mehr benutzt werden soll. Dann rendert man die Szene und ihren Klang. Wird ein Klang benutzt, löscht man das Flag. Am Ende des Frames rennt man durch alle Klänge. Die, die nicht benutzt wurden, werden gestoppt (sofern noch nicht gestoppt). Die, die benutzt werden, werden gestartet (sofern vorher gestoppt) oder nicht angetastet (sofern eh schon spielend). Mit dem Stoppen von Klängen hört man überall außerhalb des Sound-Managers komplett auf.

Jetzt schlängt man zwei Fliegen mit einer Klappe: Wenn man einen Klang nicht benutzt, wird er automatisch nicht mehr abgespielt. Wenn man ihn benutzt, läuft er weiter. Und der Übergang – das Starten und Stoppen – passiert in einer Serie am Ende des Frames; am besten synchronisiert mit der Audio-Hardware (wie man die Grafikanzeige ja auch mit dem Bildschirm synchronisiert). Dann gibt es keine Glitches und kein Knattern mehr, und Klang rendern ist so einfach wie Grafik rendern. Der Split-Screen-Fall funktioniert nun auch. Pause auch, sofern man den Sound-Renderer dann nicht mehr aufruft.

Da man sowieso dauernd an den Lautstärken der Klänge rumspielt, kann man das Setzen des Flags daran koppeln. Am Ende hat man sogar weniger Code. Und weil die Audio-API nur noch einmal am Ende des Frames über alle Klänge rutscht, statt dauernd zwischendurch was zu starten, zu stoppen, und zu durchzuknattern, ist es wahrscheinlich auch noch schneller. Datenorientierung ftw.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 10.06.2015, 23:27

Kein LoD ohne Zeitmaschine

(Ich spreche hier wieder von Gameplay-LoD in Open World wie oben beschrieben, nicht eurem popeligen Grafik-LoD, das jedes Kind kann.)

Als ich ein Partikelsystem implementieren wollte, gehörten zu meinem Ziel riesige Rauchschwaden über zerstörten Städten. Cooooool.

Nur habe ich ja ein LOD. Heißt: Das Partikelsystem legt erst dann einen Emitter an, wenn die zerstörte Stadt tatsächlich in Sichtweite kommt. Diese Rauchschwaden brauchen aber eine Stunde, um sich aufzubauen. Die Stadt sieht, wenn der Spieler ankommt, also überhaupt nicht zerstört aus, weil kaum Rauch da ist – erst eine Stunde später. Inakzeptabel.

Dann soll die Physik halt den Emitter emittieren lassen, auch wenn der Spieler noch weit weg ist. Kann ja die Grafik weglassen, dann kostet das nicht mehr sooo viel. Und vielleicht auch nur jeden zehnten Frame oder so. MÖÖÖÖÖP falsche Antwort. Wir haben Open World. Da sind 12.000 Emitter in eurem Level. Jeden Schornstein 100 km entfernt im Hintergrund simulieren? Moment, ich miete schnell das Rechenzentrum.

Nagut! Wenn ein Emitter in Sichtweite kommt, schmeißen wir halt eine Schleife an, die die letzte Stunde mit weniger Detail simuliert (wie der Wind vor einer Stunde exakt stand, interessiert uns nur begrenzt), dann schnell die Geometrie erzeugt, und nach 100 Mikrosekunden ist die Rauchschwade auf dem Schirm. Zufrieden? Nöö. Mir kann man’s heute nicht recht machen. Dann stehen schon Rauchschwaden über der Stadt selbst wenn sie von NPCs erst Sekunden vor dem Eintreffen des Spielers angegriffen haben.

Man muss bei sowas, wohl oder übel, die vergangene Zeit hinterhersimulieren. Per Zeitmaschine quasi. Man fängt bei der Geburt des Emitters durch irgendeinen Bombeneinschlag an (den Zeitpunkt muss der low-Detail-Emitter speichern!), und geht dann die zwei Sekunden, zehn Minuten, oder die ganze Stunde bis zur Gegenwart vorwärts, wie lang das eben auch ist. Dann erzeugt man die Geometrie und zeigt das Ding an.

Warum das so wichtig ist, sieht man spätestens bei Staubwolken von Fahrzeugen im Sand. Guckt mal auf das Foto hier. Mit dumm erzeugten Partikeln nicht, da würden automatisch erzeugte Partikel zehn Kilometer weiter zurückgehen. Eine Einheit kann beim Fahren durch die Wüste anhalten, dann sind Lücken in der Wolke. Auch Farbänderungen sind möglich. Und Rauchwolken beginnen oft mit den Überresten einer Pilzwolke.

Also zumindest bei Partikel-Emittern einplanen, wie man akkurat die vergangene Zeit simulieren kann, bevor man das LoD umschaltet. Bei anderen Einheiten natürlich nach Möglichkeit genau so – verbrauchter Sprit bei Autos. Fußspuren beim Spawnen einzelner Einheiten nach einer Gruppensimulation. Usw usf.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Alexander Kornrumpf » 11.06.2015, 11:10

Danke für die Beiträge.

Ich frage mich aber gerade ob wir das Problem tatsächlich haben. Menschen sind, im sogenannten "real life", extrem schlecht darin zu realisieren, dass die Welt sich in ihrer Abwesenheit weiterbewegt. Es gibt keinen richtigen Grund das zu simulieren, weil es eh keiner Sau auffällt. Niemand betritt einen Ort und fragt sich, welche Zustandstrajektorie der in den letzten 24h hatte. Niemand beurteilt den Zustand eines Ortes danach, ob ihm eine plausible Trajektorie einfällt, die diesen Zustand erklärt. Die Art Vertrautheit mit einem Ort, die es braucht, damit das passiert (du kommst nach Hause, ein Fenster ist eingeschlagen, was ist passiert?) erwirbst du in einem Spiel sowieso nie.

Außerdem macht es mMn kein gutes Storytelling. Der Sinn bei einer Geschichte ist, dass der Leser/Zuschauer/Spieler bei jedem verdammten Major Event dabei ist. Schlimmstenfalls in einer Rückblende oder durch Hörensagen. Dass überhaupt eine ganze Stadt in Abwesenheit des Spielers in Schutt und Asche gelegt werden kann ist schon die falsche Prämisse. Das Problem der Rauchwolke ist dabei das kleinste.

Es gibt natürlich Ausnahmen. Wenn man ein Detektivspiel machen wollte z. B. Oder die Eingangsszene von Gladiator, wenn ich die jetzt recht erinnere. Ich denke was ich sagen will ist, wenn es ein Spiel werden soll, bei dem der Spieler nicht ständig die ganze Welt sieht (also nicht sowas wie SimCity), dann muss man mehr skripten und weniger simulieren. Die Prämisse bei Gladiator ist ja nicht, dass da eine Gruppe zufällig brandschatzend durch die Gegend zieht und es zufällig igendjemand trifft und der dann tut was wir alle tun würden und zusammenbricht. Nein es trift _den Helden_ (tm). Jemand in dessen Persönlichkeit es schon angelegt ist, dass aus der Eingangsszene zwingend der Rest des Films folgen _muss_. Das kann man nicht simulieren.

Ich würde gerne damit schließen, dass emergentes Gameplay unmöglich ist und Prison Architect völlig überhyped. Würde, wäre da nicht ein paar Gegenargumente:

- Crusader Kings II. Ich bin ziemlich sicher, dass die ihre Simulation dahingehend faken, dass interessante Geschichten rauskommen. Aber ansonsten, einfach nur "wow". Keine Ahnung, wie die das hinbekommen.
- Emergenz zu unterschätzen ist prinzipiell eine dumme Idee.
- Ich hab da selbst seiteinigen Jahren eine Idee im Kopf für eine möglicherweise interessante Kombination aus Skripting und Emergenz. Und ich will mir nicht sagen müssen, dass das von vornherein zum Scheitern verurteilt wäre.
Alexander Kornrumpf
Moderator
 
Beiträge: 1639
Registriert: 25.02.2009, 14:37

Re: Gedanken zu Spiele-Engines

Beitragvon Top-OR » 11.06.2015, 13:48

Tüdelitü Nachbarn!

auch ich danke euch beiden für diese Beiträge.

Ich hatte bereits auch einen längeren Antwort zu diesem Thema vorbereitet, welches mich seit 2001 beschäftigt (damals durch "Gothic 1" und mein Studium/Kommilitonen angeregt).
Mr. Kornrumpf bring meine persönliche Meinung besser auf den Punkt, als ich es ausgedrückt hatte; daher erspare ich mir meinen original vorbereiteten Post.

Kurz also:
Am Ende ist es immer ein abwägen und die Frage: WAS WILL man mit dem Spiel ERREICHEN und wie soll es sich für den Spieler "anfühlen"?
Reicht dafür Scripting an wichtigen Stellen oder müssen wir eine kleine Kopie des Universums "simulieren" - in Echtzeit, versteht sich!
Und dann fragt man sich: Wie?

Ich bin inzwischen dazu angelangt, mein persönliches Projekt so auszulesen, dass manche elementaren Dinge, die leichter generisch zu löschen sind, auch so umgesetzt werden, andere Dinge werden einfach reingescriptet und gefaked.
Es ist, wie A.K. sagt: Es geht um den Spieler/Held[tm] .. den willste nicht langweilen, in dem du a la Call-of-KeineAhnung und Co. jeden Wimpernschlag scriptest, der Weg, alles generisch und 100% Simuliert machen zu wollen ist aber wohl auch nicht ziehlführend, oder?

Ansonsten finde ich solche Überlegungen immer sehr interessant, denn so kann man Dinge generischer/dynamischer gestalten, die vorher eben reingefaked und unflexibel waren.

Gutes Beispiel für dieses Art der Entwicklung ist, finde ich, auch Echtzeitbeleuchtung vs. Einbacken von Lightmaps:
Lightmaps reichen für den nicht allzu anspruchsvollen Old-schooler, inwzischen kann man mit Echtzeitsystemen aber auch sehr sehr gute dynamische Effekte erzeugen, indem man Echtzeitbeleuchtet und -Schattiert.
Ich glaube, der "faule Informatiker/Logiker" in uns will ne gerne ne dynamisch/generische Lösung für alles Mögliche. Manches geht inzwischen ganz gut; für anderes haben mir immernoch zu wenig Rechenpower, um es in Echtzeit zu machen.
Will man also wirklich so viel simulieren? Ist es mit der Hardware machbar, in endlicher Zeit sinnvoll verstehbar und umsetzbar, ist es für das SPIEL/den Helden/den Spieler überhaupt sinnvoll, oder dient es „nur“ unserem persönlichen „Hang zur generischen und robusten Lösung“?

Auch ich kann nicht mit Meinung A) „Lass uns emergentes Gameplay vergessen; brauchen wir eh nicht!“ oder B) „Wollt ihr die totale Emergenz?“ schliessen.

Auch ich bin hin- und her gerissen.
A or B? This is the Zwetschgen...Ne, isses nicht!

Am Ende diktiert es Zeit und Use-Case und es wird auch in naher Zukunft wolhl noch ne Weile ein Kompromiss aus beiden Welten sein - aus meiner Sicht zumindest.
--
Verallgemeinerungen sind IMMER falsch.
Benutzeravatar
Top-OR
Jens H.
Establishment
 
Beiträge: 318
Registriert: 02.03.2011, 17:32
Wohnort: Esslingen/Dessau

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 11.06.2015, 14:17

Drittes Danke für die beiden Antworten.

Ja; für klassische Storytelling-Geschichten ist es ganz sicher besser, wenn der Spieler bei Großereignissen dabei ist. Ich würde es auch bevorzugen, wenn sich vor solchen Angriffen schon Gerüchte in der virtuellen Welt herumsprechen, damit der Spieler direkt in die richtige Richtung gelenkt wird. In meinem konkreten Fall kann man einen Krieg auf einer Karte steuern und auch beobachten, und wenn man sieht, dass die eigenen Einheiten bei einem Angriff abkacken, springt man in der Perspektive so einer Einheit ins eigentliche Spiel. Die Truppenstärken sind zu groß, um alles tatsächlich zu simulieren, darum werden die eigentlichen Einheiten on-Demand erzeugt wenn man an einer Handlung teilnehmen will.

Keine Kritik an LoDs an sich oder an der Klangverarbeitung? Dann werte ich das als Einverständnis. Handhabt ihr Sounds ähnlich? Da kenne ich nämlich leider keine Implementierungen außer meiner eigenen.

Dann geht's gleich weiter. Übrigens ist jeder eingeladen, seine Gedanken ebenfalls hier festzuhalten.
Zuletzt geändert von Krishty am 11.06.2015, 14:48, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 11.06.2015, 14:45

Mods

Spiele, die sich nicht einfach modden lassen, sterben einen schnellen Tod. Nach dem dritten Durchspielen sind sie langweilig; die Fehler gehen nicht weg; das Spiel verrottet auf der Festplatte. Bieten Spiele einfache Modding-Möglichkeiten, leben sie in der Community normalerweise deutlich länger – manchmal Jahrzehnte.

Es scheint industriell gewollt zu sein, dass Spiele schwer zu modden und damit schnell „verbraucht“ sind; vielleicht, damit die Leute schneller den Nachfolger konsumieren. Konsolenspielen ist das inhärent, damit z.B. PlayStation-exklusiv-Content nicht auf dem PC landet. Für uns als Hobby-Entwickler sind Modder aber eine wichtige Chance:
  • Sie halten die Leute bei der Stange, während man selber nicht viel an dem Spiel weiterentwickelt oder in einer Flaute steckt.
  • Sie produzieren kostenlos Content. Und seien wir ehrlich: Der ist bei uns allen der Flaschenhals.
  • Sie sind Multiplikatoren für das Zielpublikum und betreiben kostenlos Werbung.
  • Sie können einem zeigen, wie man aus dem bereits Bestehenden Neues und Aufregendes herausholen kann.
  • Die Beziehung ist symbiotisch – viele Modder fühlen sich geehrt, wenn die Entwickler ihre Mods ins fertige Spiel integrieren.
Ich nehme mir deshalb vor, alles, was ich entwickle, einfach modifizierbar zu machen. Leider muss ich dafür zuweilen stark umdenken:
  • So viel wie möglich data-driven entwickeln. Davon bin ich normalerweise Feind, weil Skripte und Konfigurationsdateien schwerer zu debuggen sind als C-Quelltexte mit fester Typisierung, Syntaxprüfung durch Compiler, Haltepunkten, etc. Mal sehen, wie ich damit umgehe.
  • Programmabschnitte wie den Renderer in DLLs packen. Normalerweise möchte ich aus Leistungsgründen alles in ein Modul backen.
  • Keine selbstentwickelten Kompressionsalgorithmen benutzen; nicht den ganzen Spielinhalt in ein gigantisches Archiv packen; erst recht nicht in einem selbst erfundenen Format. (Da bin ich eh spinnefeind.) Um sowas zu knacken brauchen Modder Programmierkenntnisse und viel Motivation, und das klappt vielleicht gerade so für GTA-IMG-Dateien, aber nicht bei Hobbyprojekten.
  • So wenig selbstentwickelte Datenformate nutzen wie möglich. Weil ich großer Verfechter optimierter Datenstrukturen bin, werde ich hier passen müssen. Zwei Minuten Ladezeit weil man alle Modelle aus Collada und 3DS importiert ist für mich no-go, obwohl es jedem 14-Jährigen erlaubt, seine eigene Waffe ins Spiel zu integrieren.
  • Die API für die einzelnen Programmmodule öffentlich dokumentieren. Den Schritt gehen wenige bis keine kommerziellen Spiele. Ich weiß auch nicht ob das nicht eher dazu führt, dass aus Mods ganze Branches werden, oder dass einen die Modder eines Tages überholen.
  • Wenn man keinen Bock mehr auf das Projekt hat, alles Open Source machen. Sonst ist man Arschloch. Wie fast alle Publisher der Welt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Alexander Kornrumpf » 11.06.2015, 16:27

Krishty hat geschrieben:Keine Kritik an LoDs an sich oder an der Klangverarbeitung? Dann werte ich das als Einverständnis.


Vielleicht sollten wir nochmal grundsätzlich darüber reden, was LoD bedeutet. Doch wohl, dass man unter einer bestimmten Detailstufe nicht mehr weiter simuliert. Im Normalfall noch, dass die simulierte Detailstufe mit Entfernung vom Spieler abnimmt. Aber was bedeutet das und wie kann man das machen? Ein paar Beobachtungen, z. T. Sachen die du gesagt hast anders verpackt:


- Es braucht für jedes Simulationselement einen shortcut "simuliere viele davon gleichzeitig", der transparent zu und abgeschaltet werden kann. LoD bedeutet eigentlich das, und nicht dieses Zeitreiseding was du vorschlägst, Das ist eher lazy evaluation, was man natürlich auch (zusätzlich) machen kann.

- Es gibt Konzepte, die natürlicherweise eine ausnutzbare Mikro/Makro Beziehung haben. Einige Beispiele hast du genannt: Partike/Rauchwolke; Soldat/Truppe; Fahrzeugteile/Fahrzeug. Es gibt Konzepte bei denen das nicht so ist. Was nun?

- Es ist ein fundamentaler Unterschied, ob man die volle Detailstufe kennt und nur nicht anzeigt (wie bei klassischem Geometrie-LoD) oder ob man sie von vornherein nicht kennt (hier). Beim Wechsel von der niedrigen auf die höhere Detailstufe wird man immer Details aus dem Ärmel ziehem müssen. Beim umgekehrten Wechsel immer Details verlieren.

- Dinge die persistent sein müssen kann man (daher) nicht einfach wegaggregieren. Wenn man genauer darüber nachdenkt, will man bei ziemlich vielen Dingen, dass sie persistent sind. Genau dafür wird Witcher 3 doch gerade abgefeiert. Was nun? Die meisten Spiele lösen das eben so, dass die persistenten Dinge nicht in dem Sinne persistent sind, dass sie weiterexistieren, sondern nur in dem Sinne, dass sie ihren Zustand nicht ändern, es sei denn auf (geskripteten) Zuruf.

Ich mag in Mass Effect 2 sehr diesen Moment, wenn man Ashley wiedertrifft (oder hat jemand von euch sie ernsthaft im ersten Teil draufgehen lassen?). Sie sagt dann sowas wie "Scheiße, Shepard, ich habe dich geliebt" und erzählt von ihrem Leben seitdem. Aber das Leben ist offensichtlich geskriptet, es ist nicht so, dass sie in der Zwischenzeit weitersimuliert worden wäre und statt da zu landen, wo man sie trifft, auch einen Alienkindergarten auf der Citadel hätte aufmachen können, wenn es dem RNG gefiele. Persistent ist an ihr nur das was aus dem Spielstand geladen wurde (sie weiß noch ob es eine Affäre mit Shepard gab). Sie hat aber nicht persistent in der Simulation weiterexistiert. Versteht man wovon ich rede?


- Man verliert auch, unabhängig von obigem, auf der Meta-Ebene. Die Mikro/Makro Beziehungen der Simulation an sich werden garantiert kaputt gehen. Es ist nicht dasselbe, ob man Partikel simuliert oder eine Rauchwolke (Butterfly Effect). Man bekommt vielleicht beidesmal eine gleichermaßen plausible Rauchwolke und damit eine gleichermaßen gute player experience, aber man bekommt nicht _dieselbe_ Rauchwolke, und man isoliert sie aus dem System. Ein stabile Simulation wird unmöglich.

Ich kann das gerade nicht besser erklären. Vielleicht noch ein Beispiel: Wenn man aggregiert, dann nimmt man den Effekt, der aus einzelnen Partikeln eine Wolke macht vorweg. Damit kann man im Regelfall leben und das ist es ja was man will. Aber man verliert mehr. Man verliert auch das Rauchpartikel, das dem Scharfschützen ins Auge fliegt, weshalb er nicht trifft, etc. pp. Da kann man jetzt hergehen und das auch aggregieren, z. B. als Sichtverhältnisse. Aber das kann man nicht für jeden möglichen Effekt machen. Und vor allem wird die aggregierte Version niemals die gleichen Ergebnisse liefern, wie die aussimulierte. Die Simulation wird instabil.
.

- Man kann also weiter auf Emergenz hoffen, aber man verliert jede Kontrolle über das Eintreten von Makro-Ereignissen. Da man die normalerweise kontrollieren will, muss man wie gesagt skripten.

Handhabt ihr Sounds ähnlich? Da kenne ich nämlich leider keine Implementierungen außer meiner eigenen.


Da ich davon keine Ahnung habe, werde ich es garantiert so machen, wie du es gesagt hast. Es klingt vollkommen plausibel.

Dann geht's gleich weiter. Übrigens ist jeder eingeladen, seine Gedanken ebenfalls hier festzuhalten.

Bester Thread seit langem.
Alexander Kornrumpf
Moderator
 
Beiträge: 1639
Registriert: 25.02.2009, 14:37

Re: Gedanken zu Spiele-Engines

Beitragvon Alexander Kornrumpf » 11.06.2015, 16:40

Jetzt habe ich oben glatt den wichtigsten Punkt vergessen:

Anders als bei "optischen" Spielereien an der Geometrie, ist bei LoD an der Simulation die euklidische Entfernung ein extrem schlechter Prediktor dafür, wie "nahe" dem Spieler ein Ereignis ist, d. h. wie detailliert es simuliert werden muss. Das zu lösen ist wahrscheinlich das schwierigste Problem.

Zu Mods erstmal kein Widerspruch, nur eine Ergänzung:

Ich habe da ein bisschen Angst was Intellectual Property angeht. Wenn du beispielsweise einen Fußballmanager implementierst, hast du normalerweise keine DFB-Lizenz. Du willst aber ganz sicher, dass die Spieler das modden können, denn die wollen natürlich die Originalvereine. Das bringt dich in eine Situation, in der du nie niemals nie erlauben kannst, dass jemand Mods auf deinen Server hochläd. Du wärst sofort dran.

Das gilt auch für Autorennen (Fahrzeugdesigns sind geschützt), Werbeplakate (Markenrechte) und bestimmt noch für einen Sack voll anderer Dinge. Hab ich gesagt "ein bisschen Angst"? Das war untertrieben. "Lähmend" trifft es eher. Furchtbare Zustände sind das.
Alexander Kornrumpf
Moderator
 
Beiträge: 1639
Registriert: 25.02.2009, 14:37

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 11.06.2015, 17:58

Alexander Kornrumpf hat geschrieben:Vielleicht sollten wir nochmal grundsätzlich darüber reden, was LoD bedeutet. Doch wohl, dass man unter einer bestimmten Detailstufe nicht mehr weiter simuliert. Im Normalfall noch, dass die simulierte Detailstufe mit Entfernung vom Spieler abnimmt. Aber was bedeutet das und wie kann man das machen? Ein paar Beobachtungen, z. T. Sachen die du gesagt hast anders verpackt:

- Es braucht für jedes Simulationselement einen shortcut "simuliere viele davon gleichzeitig", der transparent zu und abgeschaltet werden kann. LoD bedeutet eigentlich das, und nicht dieses Zeitreiseding was du vorschlägst, Das ist eher lazy evaluation, was man natürlich auch (zusätzlich) machen kann.

- Es gibt Konzepte, die natürlicherweise eine ausnutzbare Mikro/Makro Beziehung haben. Einige Beispiele hast du genannt: Partike/Rauchwolke; Soldat/Truppe; Fahrzeugteile/Fahrzeug. Es gibt Konzepte bei denen das nicht so ist. Was nun?

Nun mache ich einfach weiter wie gehabt – ich hab’s aufgegeben, das perfekt in sich geschlossene Überkonzept zu finden, mit dem sich die komplette Spielwelt minimal beschreiben lässt. Mit Truppe statt Soldat, Kolonne statt Fahrzeug, und Rauchwolke statt Partikel habe ich schon 100–1000× höhere Leistung als vorher. (GANZ wichtig: Auch die zeitliche Auflösung runterdrehen! Einmal pro Minute, oder gar pro Stunde simulieren statt 60× pro Sekunde, reicht!) Den Rest können Moore's Law und mein Mikrooptimierungs-Log lösen :)

Alexander Kornrumpf hat geschrieben:- Es ist ein fundamentaler Unterschied, ob man die volle Detailstufe kennt und nur nicht anzeigt (wie bei klassischem Geometrie-LoD) oder ob man sie von vornherein nicht kennt (hier). Beim Wechsel von der niedrigen auf die höhere Detailstufe wird man immer Details aus dem Ärmel ziehem müssen. Beim umgekehrten Wechsel immer Details verlieren.

- Dinge die persistent sein müssen kann man (daher) nicht einfach wegaggregieren. Wenn man genauer darüber nachdenkt, will man bei ziemlich vielen Dingen, dass sie persistent sind. Genau dafür wird Witcher 3 doch gerade abgefeiert. Was nun? Die meisten Spiele lösen das eben so, dass die persistenten Dinge nicht in dem Sinne persistent sind, dass sie weiterexistieren, sondern nur in dem Sinne, dass sie ihren Zustand nicht ändern, es sei denn auf (geskripteten) Zuruf.

Was wie persistent ist, kommt auf's Spielprinzip an (für Command & Conquer reicht mir, wenn ich bei einer Truppe Soldaten die Anzahl und jeweilige Gesundheit speichere; bei einem Rollenspiel müssen die besessenen Gegenstände und Erfahrungspunkte mit rein; …). Ich bin mir aber sicher dass, egal wie man es macht, man immer mit einem Bruchteil der ursprünglichen Datenmenge auskommt. In der dümmsten Version simuliert man nix, sondern lässt die Truppe da einfach stehen, zippt die relevanten Daten, und kramt sie wieder heraus, wenn der Spieler zurückkommt. Dann ist es dein unveränderter Zustand.


Mir kam da übrigens noch eine andere Idee, und die betrifft
Alexander Kornrumpf hat geschrieben:Anders als bei "optischen" Spielereien an der Geometrie, ist bei LoD an der Simulation die euklidische Entfernung ein extrem schlechter Prediktor dafür, wie "nahe" dem Spieler ein Ereignis ist, d. h. wie detailliert es simuliert werden muss. Das zu lösen ist wahrscheinlich das schwierigste Problem.
Nämlich, für 99 % der Aufgaben reicht es, wenn man alle zehn Minuten ein Ziel setzt, einen Weg dahin berechnet, und die Einheit dann linear über den Weg streifen lässt. Alex steht morgens auf. Ziel setzen: In 10 Minuten in der Küche. Dann neues Ziel: In 20 Minuten in der Uni. Sobald da, neues Ziel: In acht Stunden immernoch in der Uni. Dann neues Ziel: in 10 Minuten in der Kneipe. Usw usf. Jetzt das Wichtige: Das Spiel unterbrechen wir, sobald ein Feind in Alex’ Nähe kommt. Feind näher als 100 m? Testen, ob sie einander bemerken können. Falls ja, höheren Detailgrad herstellen. Kampf simulieren – in selbem Detail wie wenn der Spieler direkt daneben steht, nur ohne Grafik und Klang. Sobald der Feind tot ist, dessen relevante Daten komprimieren und an der Stelle verwahren falls der Spieler vorbeikommt. Alex’ Detailgrad wieder runter und Hintergrundsimulation fortsetzen. Polizeitruppe spawnen und Ziel am Schauplatz in 10 Minuten setzen?

„Wie viel passiert da gerade?“ sollte, mit euklidischer Distanz kombiniert, theoretisch ein ziemlich guter Indikator sein.


- Man verliert auch, unabhängig von obigem, auf der Meta-Ebene. Die Mikro/Makro Beziehungen der Simulation an sich werden garantiert kaputt gehen. Es ist nicht dasselbe, ob man Partikel simuliert oder eine Rauchwolke (Butterfly Effect). Man bekommt vielleicht beidesmal eine gleichermaßen plausible Rauchwolke und damit eine gleichermaßen gute player experience, aber man bekommt nicht _dieselbe_ Rauchwolke, und man isoliert sie aus dem System. Ein stabile Simulation wird unmöglich.

Die Simulationen an sich bleiben aber doch deterministisch. Will ich die Rauchwolke simulieren, kommt zwar nicht das selbe Ergebnis heraus wie mit einzelnen Partikeln, aber zumindest immer das selbe Ergebnis. Einzige Unbekannte ist der Zeitpunkt, wenn der Spieler auftaucht. Ich sehe da kein Problem.

Dass die Beziehungen sich auflösen, könnte tatsächlich ein Problem werden. Greifst du eine Truppe an, tötest einen Feind, und der Rest zieht weiter – dann hast du nun ein Objekt „Gruppe“ und ein Objekt „Leiche“. So könnte die Spielwelt schlimmstenfalls immer weiter fragmentieren.


Ich kann das gerade nicht besser erklären. Vielleicht noch ein Beispiel: Wenn man aggregiert, dann nimmt man den Effekt, der aus einzelnen Partikeln eine Wolke macht vorweg. Damit kann man im Regelfall leben und das ist es ja was man will. Aber man verliert mehr. Man verliert auch das Rauchpartikel, das dem Scharfschützen ins Auge fliegt, weshalb er nicht trifft, etc. pp. Da kann man jetzt hergehen und das auch aggregieren, z. B. als Sichtverhältnisse. Aber das kann man nicht für jeden möglichen Effekt machen. Und vor allem wird die aggregierte Version niemals die gleichen Ergebnisse liefern, wie die aussimulierte. Die Simulation wird instabil.

Naja; das detaillierte Ereignis wird halt nicht das selbe wie das wenig detaillierte Ereignis. Aber so lange es plausibel aussieht – wen kümmert’s?

Ich sehe das als Chance. Wenn man ein Spiel machen will, dann soll man nicht mit Partikeleffekten und Kollisionsabfragen anfangen. Dann soll man erstmal die Spielmechanik ohne Grafik ausbalancieren. Eine Rotte Zauberer gegen eine Rotte Orks, rundenbasiert. Dann hat man ja quasi schon sein niedriges LOD. Danach kann man fünf Jahre an der Grafik des Kampfes feilen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 11.06.2015, 18:30

Alexander Kornrumpf hat geschrieben:Ich habe da ein bisschen Angst was Intellectual Property angeht. Wenn du beispielsweise einen Fußballmanager implementierst, hast du normalerweise keine DFB-Lizenz. Du willst aber ganz sicher, dass die Spieler das modden können, denn die wollen natürlich die Originalvereine. Das bringt dich in eine Situation, in der du nie niemals nie erlauben kannst, dass jemand Mods auf deinen Server hochläd. Du wärst sofort dran.

Das gilt auch für Autorennen (Fahrzeugdesigns sind geschützt), Werbeplakate (Markenrechte) und bestimmt noch für einen Sack voll anderer Dinge. Hab ich gesagt "ein bisschen Angst"? Das war untertrieben. "Lähmend" trifft es eher. Furchtbare Zustände sind das.
Ja kenne ich. Ich schraub’ auch seit Jahren an was, das ich hier gern vorstellen würde, aber mit einer dreistelligen Zahl Urheberrechtsverletzungen, für die irgendein unbeteiligter Irrer meine Mitstreiter schon abgemahnt hat, hält man lieber einfach die Klappe. Da muss ich mir unbedingt noch überlegen, wie wir damit umgehen sollen.

Ich kenne von Live for Speed, dass Leute da ihre eigenen Fahrzeugmodelle und -Skins hochladen können. Wäre das als Peer-to-Peer-Übermittlung weniger riskant? Man verteilt es ja nicht, sondern man vermittelt nur ungeprüft.

Ach scheiß drauf, in Deutschland wäre es so oder so verboten, wegen Störerhaftung und dem ganzen Müll. Pralle hier.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Chromanoid » 11.06.2015, 20:49

Echt doof, dass wir kein vernünftiges Fair Use in Deutschland haben... Wenn es frei ist, kann man sich vielleicht noch mit Kunstfreiheit rausreden...
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3757
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Gedanken zu Spiele-Engines

Beitragvon TDK » 11.06.2015, 21:08

Ein paar Hinweise:

Module / Plug-Ins / Skripte / Mods
  • Bei DLLs alle Objekte bitte nur mit Interfaces austauschen (=> Versionsunabhängig, kann erweitert werden).
  • Keine Objekte direkt teilen. Am Besten in einem Garbage Collector Interface (=> Interface -> Collector -> Interfaces).
  • Strings nur als shared_ptr<>-Objekt teilen, wenn es zwischen Programm und Plug-In ist (=> Wer deallokiert was und wie)
  • Bzgl. Detailstufe: Spezielles Interface teilen, dass wichtige Kenngrößen austauscht (=> Plug-In kann Komplexität selbst regeln)
  • Dokumentation, nicht extrem, aber das Wichtigste und die verfügbaren Interfaces teilen (Header)

Ressourcen / Community
  • Wenn eine Community zum Basteln gewünscht ist: Eigene Datenformate vollständig offenlegen
  • Keine Komplett-Asset Archive. Einzelne Dateien, oder Pakete mit mehreren Daten (-> Machbar).
  • Konfiguration ermöglichen
  • Alle Tools mitliefern. Ermöglichen, dass die Tools eigene Daten in ein nutzbares Format umwandeln (Texturen, Konfigurationen, usw.)
  • Bzgl. LOD: Nachladesystem entwickeln
Komplett-Archive sind nur für "One-Place"-Projekte sinnvoll. Soll irgendetwas regelmäßig editiert/verändert/erweitert werden, gibt das unnötig große Patches.
Nächstes Problem ist die Verfügbarkeit und der Verwaltungs/Suche-Overhead. Das Paket muss im Speicher liegen, oder aufwendig mit dem File-Handle umhergesprungen werden.
Weiter nicht vergessen: Brauche ich das Paket im Speicher? Sollten in diesem und jenen Ordner Pakete wirklich unterstützt werden (=> Systemverzeichnisse)?

LODs Allgemein
  • Zu viel des Guten ist auch nicht gut. Jede Stufe unterbricht z.B. den einheitlichen Verarbeitungs-Prozess.
  • Jedes LOD ist eine Instanz, die berechnet werden muss (Sichtbarkeit, Aktivität, angebundene Ressourcen, pi pa po).
  • Bei bestimmten Konstellationen prüfen, ob eine Nicht-LOD optimierte Implementation sinnvoll ist (einfache Objekte z.B.).
  • Beispiel: Benutzt dieses LOD ein Material, welches transluzent ist? (Auswirkung und Potential)

Markenrecht aka 'Darf ich' und Kollision
  • Informieren (z.B. hier), ggf. sichergehen und spezialisierten Anwalt fragen
  • §23 MarkgenG gibt alle Antworten.
  • Europaweit oder International sind nationale Bestimmungen zum Markenschutz zu beachten. Kollisionen mit Unternehmen klären.
  • Bin ich in deren Branche operativ tätig oder übe dort Branchengeschäfte aus? Störe ich deren operatives Geschäft? Normalfall: Nein.
  • Sicherere Idee: Nachfragen und um Freigabe bitten, ggf. werden Gebühren verlangt. Wichtig: Umsatzbeteiligungen ablehnen (Aufwand, Kosten in Summe, usw.), nur fixe Beträge, angemessen
  • Bei Ablehnung/Nichtantwort: Geschützte Eigenschaften wie Marken und Kennzeichen (unter Umständen auch patentiertes Design! Z.B. Eurostar) ändern, indirekte Zugehörigkeit kann bleiben.
  • Erfahrung (siehe ETS2): Die Freigabe kommt oft später von selbst, wenn die Firmen merken dass die Sturheit, einfach nur kontraproduktiv für das Image ist und alle merken wer es ist.
TDK
 
Beiträge: 50
Registriert: 06.04.2012, 11:15

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 30.06.2015, 17:04

Retro-Look

Dem einen oder anderen wird die Retro-Welle über den Weg geschwappt sein. Also dass man jetzt gern Spiele in Grafik und Stil der 80er entwickelt; bevorzugt als Kickstarter-Aufrufe (Far Cry 3 Blood Dragon, Power Drive 2000, Glorious Leader, …).

Warum? Einerseits ist der kultige 80er-Look eine gute Möglichkeit, aus der Masse grauer Shooter herauszustechen (aber nur, so lange es nicht jeder macht – sowas wie Kung Fury ist beim zweiten Mal einfach öde). Außerdem war früher alles besser, und da waren Spiele noch richtig schwer, und haben noch richtig Spaß gemacht, und das wollen wir zurück.

Das ist ein Punkt, bei dem man mal nachbohren sollte. Warum war früher alles besser?

  • Erstmal speichert unser Gedächtnis nur die guten Sachen. Die Musik war vor 30 Jahren definitiv beschissener als heute, aber auf den Oldie-Sendern laufen nur die guten 5 % davon. Klar, dass das besser klingt als der Durchschnitt des heutigen Lokalradios. Ihr erinnert euch auch nicht an die tausend Schrott-Games von früher, sondern nur an die drei Super-Titel, die euer Leben verändert haben.
  • Da ist noch die menschliche Sehnsucht nach dem unwiederbringlich verloreren ersten Mal. Bei jedem Kuss hofft ihr, dass wieder das Kribbeln vom ersten Kuss damals da ist. Bei jeder Folge Friends hofft ihr, dass es wieder so lustig ist wie beim ersten Gucken. Bei jedem neuen Spiel hofft ihr, dass es wieder so aufregend ist wie das eine Spiel, das 1992 euer Leben verändert hat.
  • Dieses Denken bringt einen schnell in die Falle, denn man ist geneigt anzunehmen, dass die Rahmenbedingungen für das Kitzeln des ersten Mals verantwortlich waren. Aber nein. Eure Alte knutschen wird nicht wieder so aufregend wie 1995, wenn ihr den selben Song wieder auflegt. Friends wird nicht wieder so lustig wie damals, bloß weil ihr im alten Slayer-T-Shirt auf dem selben Sofa hockt. Und euer 80er-Retro-Game wird auch ganz bestimmt nicht so toll wie damals, nur weil es nach 80ern aussieht.
  • All diese Erlebnisse waren toll, weil sie das erste Mal waren. Aus keinem anderen Grund.

Ihr wollt ein Spiel machen, das genau so begeistert wie euer erstes Lieblingsspiel damals? Dann hört gefälligst auf, Dinge nachzumachen. Inspieren ist toll; Kopieren ist Liebe; klar. Aber kopiert gefälligst was zusammen, das so noch nie dagewesen ist. Nicht wieder irgendeinen bescheuerten Shooter wie tausend andere oder das X-te Rennspiel mit Power-Ups.

Mario Kart 64 (die sozialistische Utopie) war genial weil so etwas vorher nicht da war (zumindest nicht für die breite Masse). Guitar Hero war genial weil so etwas keiner von euch vorher kannte. So etwas wie Half-Life oder einige Jahre später Portal hat damals keiner kommen sehen.

Die eigentliche Lektion, die uns die 80er lehren sollten, ist: Die Grafik kann noch so beschissen sein. Ist das Spielprinzip frisch und unterhaltsam, kann man auch in 16 Farben etwas wirklich Großartiges machen.

Nichts Neues also. Jetzt muss ich mir das bitte auch selber zu Herzen nehmen, denn ich stecke seit Jahren in der selben Falle fest.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Oprah Noodlemantra » 30.06.2015, 19:19

Der Retro-Look hat aber ganz handfeste Vorteile, zum einen ist das überhaupt erstmal ein Look. Zum anderen geht man damit gezielt der Konkurrenz aus dem Weg, die auf sehr aufwändige Grafik setzt, wobei die eigentliche Konkurrenz natürlich geschlossen auf den retro look setzt. Viel wichtiger ist aber, meiner Meinung nach, dass man mit einem kleinen Spieleprojekt eben keinen Hit landen wird, sondern einen langfristigeren Plan braucht. Man sollte also keinen Grafikstil wählen, der nach drei Jahren irgendwie seltsam aussieht.
Abgesehen davon sieht so ein Spiel im retro look auch einfach aus wie ein Spiel, von vornherein wird damit schon eine Distanz zur Realität geschaffen. Man kann sich dadurch im Game Design vielleicht mehr Dinge erlauben ohne das es albern wirkt. Der Look gibt einen auch gute Möglichkeiten, Elemente in die Spielwelt einzubauen, die eigentlich nur Usabilitygründe haben, zum Beispiel kann man auf der Weltkarte von curious expedition sehr viele Dinge direkt erfassen (Distanzen, Geländegrenzen), weil die Karte aus Sechsecken besteht.
Oprah Noodlemantra
 
Beiträge: 14
Registriert: 30.06.2015, 19:03

Re: Gedanken zu Spiele-Engines

Beitragvon Chromanoid » 30.06.2015, 23:40

Beim Lesen von Pandemonium and Parade: Japanese Monsters and the Culture of Yokai bin ich zur festen Überzeugung gelangt, dass die unerschöpflichen Unterhaltungswunder der Kindheit, denen man als erwachsener Videospielnarr so hinterhersehnt, fast unwiederbringlich mit dem Ende der Kindheit verloren gehen. Sobald das Monster unter dem Bett seine Bedrohlichkeit verliert, verliert auch das Videospiel den größten Teil seines Nervenkitzels. Während man als Kind selbst beim Demomodus am Arcade-Automaten noch Einflussmöglichkeiten zu erkennen glaubt, ist man als Erwachsener viel zu sehr damit beschäftigt das "Magische" auseinander zu nehmen, um es noch zu spüren. Aus meiner Sicht analog dazu wird in dem o.g. Buch die Auseinandersetzung der japanischen Gesellschaft mit den Yokai beschrieben. Sobald das unergründliche Pandämonium zur geordneten Parade wird, wird aus der genüsslichen Furcht unter der Bettdecke sehnsüchtige Nostalgie.

Ich glaube man kann die Gefühle, die zumindest ich bei Videospielen vermisse, nur dadurch zu kurzem Leben erwecken, indem man echten Schauder in das Spiel einbaut. Viele Survival-Spiele schaffen das durch Permadeath, Zufall und die Kreativität der Spieler selbst. DayZ ist mMn genau deshalb so beliebt geworden, weil andere Spieler, die Rolle der Zirkus-Zauberkünstler einnehmen. Kombiniert man das mit der unausweichlichen Furcht Gewonnenes für immer verlieren zu können, führt das zumindest gelegentlich zu einen Schauder, der an die viel intensivere Gefühlswelt der Kindheit erinnern lässt. Ein anderes kurzlebigeres Beispiel für solch einen Schauder ist mir mal in Black & White begegnet. Die grandiosen Macher versuchen den Vornamen des Spielers zu ermitteln, um dann gelegentlich den eigenen Namen von unbestimmten Geistern ausrufen zu lassen. Das hat mir damals einen gehörigen Schauder beschert :): https://www.youtube.com/watch?v=VSIXZJFgBFA

Am Rande: Ich glaube, dass man auch als Erwachsener beim ersten "unschuldigen" Kontakt mit Videospielen eine intensive Phase mit Videospielen verbringen kann. Aber auch dann entschlüpft einem sicher schnell der ursprüngliche Zauber und alles was bleibt ist Nostalgie... :cry: :D
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3757
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Gedanken zu Spiele-Engines

Beitragvon Zudomon » 01.07.2015, 06:50

Das mit dem B&W2 ist krass... habs wohl nicht lange genug gespielt, aber mein Name "Nick" ist auch dabei! :D
Da würde mich aber mal sehr interessieren, wie das Spiel den Namen raus bekommt!!
Benutzeravatar
Zudomon
Establishment
 
Beiträge: 2108
Registriert: 25.03.2009, 08:20

Re: Gedanken zu Spiele-Engines

Beitragvon Chromanoid » 01.07.2015, 07:16

Das gabs auch schon im ersten Teil. Ich glaube die haben den aus der Registry geklaubt, bin mir aber nicht mehr sicher. Kann auch sein, dass man bei der Installation was angeben sollte.
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3757
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 01.07.2015, 09:36

Als ich gestern nachgeschaut habe, war die Rede von
  • Profilname im Spiel
  • Windows-Profilname
  • Outlook (das Spiel lädt dein Adressbuch um Dorfbewohner wie deine Freunde zu benennen)

Aber on-topic @Oprah Noodlemantra: Willkommen! :) Einen nicht schnell alternden Look bekommt man auch anders hin – man kann die Grafik einfach grün machen statt 80er-neongrün. Irgendwie scheint das aber vielen Leuten schwer zu fallen …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Alexander Kornrumpf » 01.07.2015, 10:09

Chromanoid hat geschrieben:Beim Lesen von Pandemonium and Parade: Japanese Monsters and the Culture of Yokai bin ich zur festen Überzeugung gelangt, dass die unerschöpflichen Unterhaltungswunder der Kindheit, denen man als erwachsener Videospielnarr so hinterhersehnt, fast unwiederbringlich mit dem Ende der Kindheit verloren gehen. Sobald das Monster unter dem Bett seine Bedrohlichkeit verliert, verliert auch das Videospiel den größten Teil seines Nervenkitzels. Während man als Kind selbst beim Demomodus am Arcade-Automaten noch Einflussmöglichkeiten zu erkennen glaubt, ist man als Erwachsener viel zu sehr damit beschäftigt das "Magische" auseinander zu nehmen, um es noch zu spüren. Aus meiner Sicht analog dazu wird in dem o.g. Buch die Auseinandersetzung der japanischen Gesellschaft mit den Yokai beschrieben. Sobald das unergründliche Pandämonium zur geordneten Parade wird, wird aus der genüsslichen Furcht unter der Bettdecke sehnsüchtige Nostalgie.

Ich glaube man kann die Gefühle, die zumindest ich bei Videospielen vermisse, nur dadurch zu kurzem Leben erwecken, indem man echten Schauder in das Spiel einbaut. Viele Survival-Spiele schaffen das durch Permadeath, Zufall und die Kreativität der Spieler selbst. DayZ ist mMn genau deshalb so beliebt geworden, weil andere Spieler, die Rolle der Zirkus-Zauberkünstler einnehmen. Kombiniert man das mit der unausweichlichen Furcht Gewonnenes für immer verlieren zu können, führt das zumindest gelegentlich zu einen Schauder, der an die viel intensivere Gefühlswelt der Kindheit erinnern lässt. Ein anderes kurzlebigeres Beispiel für solch einen Schauder ist mir mal in Black & White begegnet. Die grandiosen Macher versuchen den Vornamen des Spielers zu ermitteln, um dann gelegentlich den eigenen Namen von unbestimmten Geistern ausrufen zu lassen. Das hat mir damals einen gehörigen Schauder beschert :): https://www.youtube.com/watch?v=VSIXZJFgBFA

Am Rande: Ich glaube, dass man auch als Erwachsener beim ersten "unschuldigen" Kontakt mit Videospielen eine intensive Phase mit Videospielen verbringen kann. Aber auch dann entschlüpft einem sicher schnell der ursprüngliche Zauber und alles was bleibt ist Nostalgie... :cry: :D


Ich bin da nicht so pessimistisch.

1) Im Grunde alle Medien können mich noch faszinieren. Soll ich Einzelbeispiele nennen? Speziell auf "unser" Medium bezogen hatte ich große Hoffnungen in Wasteland 2, die dann enttäuscht wurden. Aber ich habe keinen Grund anzunehmen, dass Witcher III (bisher allerdings noch nicht getestet) etwas anderes als toll ist. Und ich glaube das ist noch lange nicht das Ende. Das Bsp. Wasteland 2 zeigt wohl aber das was Krishty sagt: Das gleiche neu machen reicht halt nicht.

2) Es stimmt mMn nicht, dass die Magie raus ist. Ich hatte oben Crusader Kings II erwähnt, das macht genau das, was du andeutest, nämlich eine Illusion erzeugen. In diesem konkreten Fall: Man hat das Gefühl, es schreibt eine Story für einen, aber es _muss_ ein Trick dabei sein. Da habe ich schon Ideen, wie man sowas implementiert, aber in der Perfektion muss man das erstmal hinbekommen.

3) Ich habe da so zwei, drei Spiele aus meiner Jugend, deren "Geist" ich gerne mit heutiger Technik einfangen würde. Ist so eine Idee, die ich seit Ewigkeiten mit mir rumschleppe.
Die offensichtliche Beobachtung dabei:
Es gibt da sehr sehr viele low-hanging fruits, was man auf heutigen Maschinen ohne weiteres bessser machen könnte. Und es gibt ebensoviele Sachen, die man damals faken musste, weil die Rechenpower nicht erreicht hat, die man heute "einfach richtig" machen könnte.
Die weniger offensichtliche Beobachtung:
- Es ist gar nicht gesagt, dass die fake-Version der Spielmechanik signifikant weniger Spaß macht, als die "reale". Im Gegenteil.
- Die scheinbar einfachen Verbesserungen laufen alle darauf hinaus, dass man bessere Assets bräuchte. Also eher kein Job für einen Programmierer. Einen besseren Job als die Programmierer damals zu machen, ist schwer.
- Man glaubt immer, wie du schreibst, man könnte die Magie mit seinem Wissen dekonstruieren. Das ist ein Selbstbetrug, der auffliegt, sobald man versucht es wirklich mal nachzumachen. Ich habe da jetzt ein Beispiel im Kopf in das ich sicherlich im Laufe der Jahre 100erte Stunden an Spielzeit gesteckt habe und inzwischen auch manchen Abend starren auf die Disassembly und ganz ehrlich: ich hab keine Ahung wie sie es gemacht haben. Kann an mir liegen.

4) Zum Thema Nostalgie, lest unbedingt den Mehrteiler bei RPS von dem Typen, der Deus Ex nochmal durchgespielt hat, startend mit der Überzeugung es sei das beste Spiel aller Zeiten.

5) Eine Art Fazit: Die "drei Super-Titel, die unser Leben verändert haben" (Krishty) sind in unserem Alter (tm) halt auch von den drei Super-Programmierern einer Generation aus einer Zeit, als Game Design und implementierung noch dasselbe war. Die wussten halt was sie taten. Es ist einfach nicht zu erwarten, dass under den zehntausenden Indie-Entwicklern heute auf einmal mehr Genies sein sollten. Ich glaube, dass man mangelndes Genie schon teilweise durch großes Budget kompensieren kann. Und ab und zu macht es auch jemand. Das ist mMn die eigentliche Kluft zwischen Indie und Triple-A.
Alexander Kornrumpf
Moderator
 
Beiträge: 1639
Registriert: 25.02.2009, 14:37

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 26.08.2015, 17:13

class Kamera

Ich habe mich sehr lange gegen Kamera-Klassen gesträubt. Ich meine: Wozu eine Kamera-Klasse? Man kann doch einfach seiner draw()-Funktion Position und Rotation des Betrachters übergeben. Die Matrizen müssen eh ständig neu berechnet werden; das macht dann die Funktion. Und die ist dann auch noch zustandslos, weil sie keine Daten aus vorherigen Renderings wiederverwendet (im Gegensatz zu einer Kamera-Instanz).

Jetzt weiß ich, wofür man sie braucht: um mehrere Perspektiven parallel zu zeichnen. Also Split Screen. Oder Überwachungskameras in der Spielwelt. (Dann speichert man darin immernoch nicht Projektionsmatrix usw, denn das soll verdammt nochmal zustandslos bleiben, aber ich schweife ab.)

Der Knackpunkt ist nämlich das LOD: Rendert man aus zwei Perspektiven, die weit von einander entfernt sind, dann wird beim 2. Rendern alles Detail weggeschmissen, das beim 1. Rendern geladen wurde. Sobald dann die andere Perspektive rendert, lädt sie ihre Details zurück. Und am Ende ist die Engine nur noch mit Swapping beschäftigt: LODs laden, wegschmeißen, laden, wegschmeißen.

Klar kann man jetzt einen Cache einbauen, um das ganze zustandslos zu halten, aber das suckt doch noch übler: Hat man nur einen Betrachter (oder stehen alle Betrachter direkt neben einander), wird viel zu viel nutzloses Zeug im Cache gehalten. Hat man viele Betrachter, wird der Cache zu klein und das Swapping geht wieder los. Eeew.

Der richtige™ Weg ist, dass man die Position jedes Betrachters speichert. Alles Rendering erwartet diesen Betrachterkontext als Parameter. Nachdem die Physik am Anfang des Frames alle Betrachter bewegt hat, schießt die LOD-Verwaltung los, alle LODs auf Erreichbarkeit durch *irgendeinen* Betrachter zu prüfen. Es wird immer nach dem nächsten Betrachter entschieden. Danach wird gerendert.

So geht das auch mit 32-Spieler-Splitscreen nicht kaputt, und man kann so Sachen einbauen wie, dass da LOD auf Überwachungskameras niedriger ist als auf dem Bildschirm des Spielers.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 06.09.2015, 19:18

Levelgrenze

In einem Flugsimulator sollte man beim Erreichen der Levelgrenze nicht bloß so eine scheiß Warnung „Umkehren, sonst endet die Mission“ bekommen. Wäre viel cooler, wenn der Wind zur Grenze hin immer stärker würde, so dass das Flugzeug nahe der Grenze nicht mehr dagegen anfliegen könnte und ins Level zurückgepustet würde. Dadurch würde sich das Flugzeug auch immer automatisch von der Grenze wegdrehen, sobald es in die Nähe kommt.

Aber wahrscheinlich würde das die Partikelphysik durcheinanderbringen oder so.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon Alexander Kornrumpf » 07.09.2015, 09:57

Krishty hat geschrieben:Levelgrenze

In einem Flugsimulator sollte man beim Erreichen der Levelgrenze nicht bloß so eine scheiß Warnung „Umkehren, sonst endet die Mission“ bekommen. Wäre viel cooler, wenn der Wind zur Grenze hin immer stärker würde, so dass das Flugzeug nahe der Grenze nicht mehr dagegen anfliegen könnte und ins Level zurückgepustet würde. Dadurch würde sich das Flugzeug auch immer automatisch von der Grenze wegdrehen, sobald es in die Nähe kommt.

Aber wahrscheinlich würde das die Partikelphysik durcheinanderbringen oder so.


Ich glaube nicht, dass das die Immersion wirklich erhöht. Grundsätzlich erscheint es mir sinnvoller die vierte Wand gezielt an der Levelgrenze zu durchbrechen, als Kilometer vor der Levelgrenze schon Signposts aufzustellen "Achtung, es gibt eine vierte Wand, und wir machen sie undurchdringbar, egal zu welchem Preis".

Oder anders betrachtet: Wer die Levelgrenze erreicht, der weiß sowieso, dass er in einem Spiel ist, und ist mit Absicht losgezogen um zu schauen, wie die Entwickler das gelöst haben. Wenn ein Spieler "versehentlich" die Levelgrenze erreichen kann, ist das ein Problem des Leveldesigns. Ich glaube nicht, dass man das technisch lösen kann. (Wahrscheinlich gilt dieser Absatz nur für "Open World" Spiele).
Alexander Kornrumpf
Moderator
 
Beiträge: 1639
Registriert: 25.02.2009, 14:37

Re: Gedanken zu Spiele-Engines

Beitragvon antisteo » 07.09.2015, 10:57

Eine andere Alternative wäre, die Welt torusförmig aufzubauen. Das braucht natürlich etwas mehr Grips in der Arithmetik, um Abstände und Koordinaten etc. richtig zu händeln. Zu manchen Levels passt es auch einfach nicht, wenn man z.B. echte Karten als Grundlage nimmt und man im Osten Deutschlands plötzlich wieder in Westdeutschland rauskommt.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
antisteo
Establishment
 
Beiträge: 789
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Gedanken zu Spiele-Engines

Beitragvon Top-OR » 07.09.2015, 13:03

antisteo hat geschrieben:Eine andere Alternative wäre, die Welt torusförmig aufzubauen. Das braucht natürlich etwas mehr Grips in der Arithmetik, um Abstände und Koordinaten etc. richtig zu händeln. Zu manchen Levels passt es auch einfach nicht, wenn man z.B. echte Karten als Grundlage nimmt und man im Osten Deutschlands plötzlich wieder in Westdeutschland rauskommt.


Naja, diese kachelartigen Levels gabs schon bei Comanche von anno dazumal... Das ist jetzt keine Atomphysik. Jeder halbwegs fähige Artist kann (Höhen-)Texturen machen, die "kachelbar" sind.

Mich hat das aber eher immer verwirrt - wie du sagt: "Oh, ich fahre nach Osten und bin gerade da angekommen, wo ich vor fünf Minuten losgefahren bin, obwohl ich die Richtung nicht gewechselt habe..." :-/
Muss auch nicht helfen, die Immersion zu steigern. Du wirst halt nicht "unterbrochen" durch die Wand ... aber die Grenze mach nicht eben doch in deinem Kopf breit, weil solches Umweltverhalten der Alltagserfahrung widerspricht. Ich halte die Idee von der "sanften Wand" z.B. durch Wind auch für nicht schlecht, wobei das Leveldesign das zugegebenermaßen vorher verhindern sollte...
--
Verallgemeinerungen sind IMMER falsch.
Benutzeravatar
Top-OR
Jens H.
Establishment
 
Beiträge: 318
Registriert: 02.03.2011, 17:32
Wohnort: Esslingen/Dessau

Re: Gedanken zu Spiele-Engines

Beitragvon ponx » 09.09.2015, 16:01

Chromanoid hat geschrieben:Beim Lesen von Pandemonium and Parade: Japanese Monsters and the Culture of Yokai bin ich zur festen Überzeugung gelangt, dass die unerschöpflichen Unterhaltungswunder der Kindheit, denen man als erwachsener Videospielnarr so hinterhersehnt, fast unwiederbringlich mit dem Ende der Kindheit verloren gehen. Sobald das Monster unter dem Bett seine Bedrohlichkeit verliert, verliert auch das Videospiel den größten Teil seines Nervenkitzels.


Für mich hat das Monster unter dem Bett in Gestalt von Alien Isolation seine Bedrohlichkeit zurückbekommen. Es bleibt in weiten Teilen unberechenbar, bis zum Ende des Spiels. Man kann nur seine Chance vergrößern, zu überleben, aber man kann auch einfach Pech haben. Auf einmal steht es vor dir und atmet schwer! Und man kann nur an bestimmten Punkten speichern. Je länger man schon in Angst durch die Gänge gekrochen ist, desto mehr hat man zu verlieren.
Diese Unberechenbarkeit in Verbindung mit den harten Konsequenzen beim Ableben macht für mich auch den Reiz von DayZ aus.
Benutzeravatar
ponx
Andy Ponx
Establishment
 
Beiträge: 215
Registriert: 04.05.2008, 12:52
Wohnort: Hamburg

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 08.01.2016, 03:03

Eine Engine braucht die Möglichkeit, Hintergrundmusik in Ausschnitten zu wiederholen und an Skripte zu binden. Weil die meisten guten Tracks nicht monoton sind sondern wachsen und erblühen; und weil die normalen Sound-Einlagen viel zu kurz und starr sind um gute Tracks sein zu können.

In einem Ego-Shooter betrete ich eine Straße. Sie scheint leer zu sein … zu leer. Ich will, dass dann dieser Track von 3:10 bis 3:13 als Endlosschleife startet. Mit einem sehr langen Fade-In, aus dem Hintergrund, um Spannung aufzubauen. Und sobald der erste Gegner aus einem Hauseingang springt, läuft der Track normal ab 3:13 weiter. Ist der Kampf bis zum Ende des Tracks vorbei, langsames Fade-Out. Sonst Fade-Out passend zum Ende des Tracks (oder einen anderen, passenderen Ausschnit reinmixen und wiederholen). So was muss ich als Level-Designer ganz einfach machen können.

Das setzt dann voraus, dass man Ausschnitte nahtlos wiederholen kann (nicht bloß alle n Milisekunden, wie es MP3 & Co vorsehen). Dass Fade-Ins usw. ihren Zustand getrennt vom eigentlichen Track verwalten. Dass die Schleife nicht einfach für die Fortsetzung unterbrochen wird, sondern der Player die Fortsetzung (und den neuen Abspielmodus!) sauber in die Wiedergabeschleife einreiht. Und, natürlich, dass das alles mit KI usw. verknüpft ist.

Wahrscheinlich ist das sogar recht einfach, gemessen am Gesamtaufwand einer Sound-Engine.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon ponx » 08.01.2016, 12:16

Krishty hat geschrieben:Das setzt dann voraus, dass man Ausschnitte nahtlos wiederholen kann (nicht bloß alle n Milisekunden, wie es MP3 & Co vorsehen). Dass Fade-Ins usw. ihren Zustand getrennt vom eigentlichen Track verwalten. Dass die Schleife nicht einfach für die Fortsetzung unterbrochen wird, sondern der Player die Fortsetzung (und den neuen Abspielmodus!) sauber in die Wiedergabeschleife einreiht. Und, natürlich, dass das alles mit KI usw. verknüpft ist.
Wahrscheinlich ist das sogar recht einfach, gemessen am Gesamtaufwand einer Sound-Engine.

Ich kann versprechen, spätestens wenn man nicht nur einzelne speziellen Fälle abbilden will, sondern es flexibel (und gleichzeitig benutzbar) halten will, wird es sehr aufwändig. Wenn eure Engine multiplattform sein soll, kommt jeweils noch die Unterstützung der hardwareseitigen Audio-API dazu. OpenAL als einzige offene API ist eingeschlafen und läuft zwar noch grundsätzlich unter Windows, aber ist auf den Konsolen spätestens seit PS4 und XOne tot, soweit ich weiß. Wir hatten damals mit unserer Musikengine (http://www.homeofpsai.com) auf XACT aufgesetzt, das war immerhin eine gemeinsame Schnittstelle für Xbox360 und Windows. Die wurde dann ab Windows 8 sang und klanglos von Microsoft nicht mehr unterstützt. Ich hab Tage gebraucht, um überhaupt mal jemanden bei Microsoft ans Telefon zu kriegen, der irgendwas davon wusste. Also: Ich würde sehr dazu raten, eine der etablierten Sound-Engines (FMOD, Wwise, Miles Sound System) zu benutzen. Unsere Musik-Engine setzt mittlerweile auf XAudio2 (Windows), OpenAL und FMOD auf, und keiner unserer Kunden hat sich je für was anderes als die FMOD-Variante entschieden.
Benutzeravatar
ponx
Andy Ponx
Establishment
 
Beiträge: 215
Registriert: 04.05.2008, 12:52
Wohnort: Hamburg

Re: Gedanken zu Spiele-Engines

Beitragvon Krishty » 08.01.2016, 15:53

Ahja. Aber ist das überhaupt auf Ebene der Sound-API relevant? Ich hätte gedacht, dass ich bei allen die Möglichkeit habe, PCM-Daten zu übergeben (XAudio2, meine derzeitige Wahl, kann eh kein Echtzeit-MP3-Decoding) und so lange die API mir dabei erlaubt, frei zu seeken, könnte ich solche Playback-Spielereien auf jeder API fußend aufsetzen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6661
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Gedanken zu Spiele-Engines

Beitragvon ponx » 08.01.2016, 18:12

Krishty hat geschrieben:Ahja. Aber ist das überhaupt auf Ebene der Sound-API relevant? Ich hätte gedacht, dass ich bei allen die Möglichkeit habe, PCM-Daten zu übergeben (XAudio2, meine derzeitige Wahl, kann eh kein Echtzeit-MP3-Decoding) und so lange die API mir dabei erlaubt, frei zu seeken, könnte ich solche Playback-Spielereien auf jeder API fußend aufsetzen.

Ja, wenn man schon auf der Ebene arbeitet, die PCM-Daten direkt in nen Puffer zu schreiben, dann gibt's da letztendlich ganz bestimmt eine Möglichkeit auf jeder Plattform. Ich hätte gerne eine offene API gehabt, die sowas plattformunabhängig unterstützt. Das scheitert wohl schon daran, dass Sony und Microsoft ihre Konsolen-SDKs extrem unter Verschluss halten und jeden steinigen (Sony jedenfalls), der irgendwelche interna daraus öffentlich zugänglich macht.
Benutzeravatar
ponx
Andy Ponx
Establishment
 
Beiträge: 215
Registriert: 04.05.2008, 12:52
Wohnort: Hamburg

Nächste

Zurück zu Algorithmen und Datenstrukturen

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

cron