Grafik"engines", Stand der Kunst 2013

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

Hey,

Background

derzeit bin ich in der glücklichen Position hin und wieder ein bisschen Freizeit zum Programmieren abzweigen zu können und gleichzeitig nichts dabei erreichen zu müssen. Wenn ich was lerne und Spaß dabei gehabt habe bin ich zufrieden. Angenommen ich würde ein Spiel machen wollen...

Game-Engine killed the Graphics-Engine Star:
Da mag ich ein Sonderfall sein, aber ich will Unity nicht. Alles in mir wehrt sich gegen Unity. Das bitte nicht als objektive Kritik an Unity auffassen. Ich verstehe dass es viele Vorteile hat, es muss mich jetzt auch niemand davon überzeugen. Wollte nur von vornherein diese Option ausschließen. Ich will auch nicht UDK oder CrySDK. Die sind ganz bestimmt toll. Aber in dem 0,0001%igen Fall dass ich für das (oder irgendein) Spiel mal Geld sehen könnte sind die Lizenzbedingungen indiskutabel.

Aber: Die klassische OpenSource Engine hat den zuvor genannten nichts entgegen zu setzen. Ich rede jetzt nicht von Funktionsumfang, sondern von "must-haves" wie DX11 Renderer (Irrlicht) oder menschenwürdiger Dokumentation (OpenSceneGraph). Zu Crystal Space kann ich nichts sagen. Mit OGRE hatte ich auf 1.6 einige Erfahrung, seit kurzem gibt es 1.9 "stable" (!) und kein einziges Sample funktioniert mit DirectX11 (http://www.ogre3d.org/forums/viewtopic.php?f=2&t=79755) Nee Sorry Leute, wenn ich Entwickeln wollte als wäre wieder 2005, hätte ich das 2005 schon gemacht.

Also die Konkurrenz ist natürlich hart, und natürlich bremst es die Entwicklung, wenn "alle Welt" Unity/UDK/Cry benutzt, aber der Zustand scheint wirklich desolat zu sein. Für OGRE hat es mal jemand auseinandergepflückt: http://www.mediafire.com/view/?7k0q4guxgm74y2g

Was kann ich tun?

- Auf alles pfeifen und in der DirectX9 Welt weiterleben.
- Ein wenig warten. Rayne (aus den Projektvorstellungen) sah ganz gut aus. Cat arbeitet an breeze (noch aktuell?).
- Selber machen.

How hard can it be?

Eigentlich habe ich relativ schmale Anforderungen. Bei der DirectX 11 Geschichte gehts darum dass ich mal das ganze "neue" Zeugs ausprobieren will. Oder zumindest die Option haben. Nicht darum dass ich es wirklich bräuchte. Also jetzt mal Hand auf die Herdplatte, was brauchts wirklich um Output zu erzeugen, ohne ganz von 0 anfangen zu müssen?

Modelle Laden -> kann Assimp machen. Ist ja eh quasi Standard.

Bilder Laden -> Irgendwas, das nicht FreeImage ist :) Selbst libpng ohne alles könnte vielleicht reichen. Mache ich mir keinen Kopf drum.

Scenegraph -> Ich weiß nicht wieviel Sinn es hat den rendereragnostisch zu implementieren und ob das mal jemand gemacht hat (?) Vermutlich ist OpenSceneGraph tatsächlich noch am ehesten das was ich will, wäre es nicht so sperrig. Lohnt es sich vielleicht den ganzen optionalen Kram und den Renderer wegzuwerfen, aber den eigentlichen SceneGraph zu benutzen?

Materialsystem -> Ein Grund hier überhaupt rumzumoppern ist ja, dass ich Kontrolle über die Pipeline will, bzw. dass es mir halt nichts nützt, wenn die Engine "nützliche" Sachen schon vorimplementiert aber dadurch auch limitiert was überhaupt geht. Dennoch scheint es irgendwie so zu sein dass Material mehr ist als "ein paar Shader schreiben". Was ist hier nötig? Was gibt es? Was taugt das? (BTW: Dass die OGRE Samples nicht mit DX11 gehen liegt vermutlich an den auto-generierten Shadern. Soviel dazu.)

GUI -> CEGUI (OGRE Ökosystem) scheint irgendwie ein bisschen übertrieben. MyGui scheint zugänglicher. Ggf. auch librocket? Herrje, zumindest das Problem muss doch mal jemand technisch gelöst haben, oder?

Input -> Wenn ich die Horrorgeschichten hier im Forum so sehe... Und den traurigen Zustand von OIS betrachte... naja schlimmstenfalls behandel ich Windows Nachrichten und reiche sie an die GUI Bibliothek weiter. Ist nichts unheimlich Zeitkritisches was ich vor habe. Was macht "man" da heute?

Renderer ->Eigentlich *ist* Direct X doch der Renderer. Muss man da unbedingt was wrappen? Wieviel?

Mathe -> Müsste was sein dass unter Windows kompiliert und fastness as opposed to precision im Sinne hat. Was gibt es da?

Fehlt was? Gibt es bessere Alternativen? Wieviel Aufwand ist das alles?

Gebt mal bitte ein paar Empfehlungen.
Zuletzt geändert von Alexander Kornrumpf am 20.12.2013, 13:26, insgesamt 1-mal geändert.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Aber: Die klassische OpenSource Engine hat den zuvor genannten nichts entgegen zu setzen.
Das hier bringt es eigentlich auf den Punkt. Es gibt derzeit einfach keine Open Source Gameengine mehr die den Big Boys auch nur ansatzweise das Wasser reichen könnte was den Umfang, die Leistung und die Bedienfreundlichkeit angeht. Das ist zumindest meine Einschätzung. Wie denn auch? Hinter Unity stehen zum Beispiel über 100 Entwickler. Und selbst Unity kauft sich noch Lizenzen für Techniken zu. Umbrella (Lightmapping) ist keine Unity Entwicklung. Das ist lizensiert. Und das wird bei UDK und Cry auch nicht anders aussehen.

Wie soll dann also eine Open Source Gameengine mit ihren im Idealfall grade mal handvoll Entwicklern gegen anstinken? In der Regel ist das sogar meist ein Einmannprojekt. Es gibt einfach zu wenig Open Source Entwickler die wirklich das Know How und das Können haben um sowas zu entwickeln. Und sobald sie ein gewisses Level an Können erreicht haben wandern sie unweigerlich in die Industrie ab. Ich sag nur Irrlicht und Coppercube.

Das ist im Grunde das Dilemma das man hinter allen Open Source Projekten sieht. Die Industrie hat einfach den grösseren Entwicklungsdruck. Und mehr kluge Köpfe, weil die da eben für ihre Arbeit bezahlt werden. Und die Industrie ist gerade dabei die klassische Game Engine durch eine ganzheitliche Lösung ala Unity/UDK/Cry abzulösen. Die reinen Engines sterben zwar nicht aus, werden sie wohl auch nie, werden aber aus dem Mainstream raus und an den Rand gedrängt. Was ich übrigens nicht wirklich schlimm finde. Wir haben einen Punkt erreicht wo ein einzelner einfach gar nicht mehr in der Lage ist noch zu Lebzeiten was wirklich konkurenzfähiges zusammenzuzimmern. Weil es einfach viel zu viel Arbeit ist. Also überlässt man die Core Entwicklung eben Firmen die sich da drauf spezialisiert haben.

Also musst du dich schlicht entscheiden. Doch was von der Stange nehmen, oder qualitativ abgehängt werden. Kommt natürlich auch drauf an was dir wichtiger ist, ein fertiges Produkt zu entwickeln das konkurenzfähig ist, oder in Code rumstochern. Programmieren oder entwickeln. Entwickeln kann man ja inzwischen (fast) ganz ohne Code :)

Mh. Hast du dir schon Maratis angeschaut? http://www.maratis3d.org/
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

Tiles hat geschrieben: Kommt natürlich auch drauf an was dir wichtiger ist, ein fertiges Produkt zu entwickeln das konkurenzfähig ist, oder in Code rumstochern. Programmieren oder entwickeln. Entwickeln kann man ja inzwischen (fast) ganz ohne Code :)
Du tust immer so als würde sich das ausschließen. Für dich mag zutreffen, dass du so produktiver bist. Ich bin produktiver wenn ich meine Engine im Code (statt durch einen Quasi-WYSIWYG-Editor) steuern kann. Ich bin auch mit LaTex bedeutend produktiver als mit Word. Es mag auch sein dass Unity mir diese Option auch böte. Schade nur wenn das sichtbare Doku-Ökoystem darauf ausgelegt ist leuten in Form von Videos die Vorzüge des Editors nahezubringen. Ich persönlich kann so nicht arbeiten. Will ich auch nicht. Dass das von vornherein schlechtere Ergebnisse impliziert möchte ich mal bezweifeln.

Richtig ist jedoch dass es für deine Arbeitsweise zur Zeit die besseren Tools zu geben scheint als für meine.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Es geht mir da weniger um die Arbeitsweise als um die Zielsetzung. Das sind zwei unterschiedliche Ziele. Gibt ja hier genug Leute die einfach nur Spass am Programmieren haben wollen. Die macht man mit dem Non Programming Tool wie dem Playmaker Plugin für Unity eher unglücklich. Das meinte ich damit :)
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Thoran
Establishment
Beiträge: 224
Registriert: 15.05.2009, 12:51
Wohnort: Stuttgart
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Thoran »

Alexander Kornrumpf hat geschrieben: Aber: Die klassische OpenSource Engine hat den zuvor genannten nichts entgegen zu setzen. Ich rede jetzt nicht von Funktionsumfang, sondern von "must-haves" wie DX11 Renderer (Irrlicht) oder menschenwürdiger Dokumentation (OpenSceneGraph). Zu Crystal Space kann ich nichts sagen. Mit OGRE hatte ich auf 1.6 einige Erfahrung, seit kurzem gibt es 1.9 "stable" (!) und kein einziges Sample funktioniert mit DirectX11 (http://www.ogre3d.org/forums/viewtopic.php?f=2&t=79755) Nee Sorry Leute, wenn ich Entwickeln wollte als wäre wieder 2005, hätte ich das 2005 schon gemacht.

Also die Konkurrenz ist natürlich hart, und natürlich bremst es die Entwicklung, wenn "alle Welt" Unity/UDK/Cry benutzt, aber der Zustand scheint wirklich desolat zu sein. Für OGRE hat es mal jemand auseinandergepflückt: http://www.mediafire.com/view/?7k0q4guxgm74y2g
Da muss ich dir recht geben. Ich selbst habe meine Engine (die eigentlich gar keine werden sollte, sondern nur ein Spiel) auf Ogre aufgebaut. Damals noch 1.7.x zwischenzeitlich 1.8.x. Aber ich muss schon sagen, eine Grafikengine, der schon allein die Möglichkeit fehlt ordentliche Shadowmaps für omnidirektionale Lichter zu erzeugen, ist heutzutage echt schon fast ein Showstopper. Klar kann man irgendwie drumrum arbeiten und das ganze hin-faken, aber das sind dann meist nur unschöne Lösungen. Ich war auch schon kurz davor das Shadowmapping für omnidirektionale Lichter in Ogre zu implementieren, aber leider reicht mir da einfach die Zeit privat nicht. Die Folien die du verlinkt hast, haben ja im Ogre-Projekt zumindest mal dazugeführt, dass Ogre selbst grundlegend überarbeitet wird und das die DX11-Samples nicht gehen, liegt wohl eher daran, dass in dem Bereich kräftig umgebaut wird. Zurecht kann man nun fragen : "Wie, da wird umgebaut? Immer noch?".

Ich denke man hat nur drei Möglichkeiten: Entweder man nimmt eine OSS-Engine wie Ogre und bleibt technologisch zurück und gibt sich damit zufrieden, man nimmt eine der für Hobbyentwickler verfügbaren Engines wie Unity, Project Anarchy oder das UDK oder man behebt die Probleme der OSS-Engines und gibt was an die Communities zurück, damit die OSS-Engines besser werden.
Ich bin momentan schwer am Wanken auf das Project Anarchy zu wechseln.

Mal sehen was daraus wird.
Wer Rechtschreibfehler findet, darf diese gerne behalten.
Mein Entwicklertagebuch
Aktuelle Projekte: Universum: Domination (ehemalig AlphaOmega),Universum: Sternenjäger, PixelWars: Highscore-based Top-Down-Spaceshooter
Spieleengine Unreal 5
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von CodingCat »

Alexander Kornrumpf hat geschrieben:Angenommen ich würde ein Spiel machen wollen...
[...]
Fehlt was?
Ich würde sagen, in erster Linie fehlt die Content Creation. Das ist der Punkt, an dem ich vor ca. einem halben Jahr ausgestiegen bin. Ich habe eine nette Qt-basierte Editorumgebung, die vor allem daran krankt, dass (a) Qt nicht hält was es verspricht (Docking-Oberfläche funktioniert nicht, Widgets spinnen rum), (b) mir derlei klassische Widget-UIs mittlerweile vollkommen ungeeignet erscheinen, weil jeder Klick und jede Mausbewegung zum nächsten Klick nur verschwendete Zeit ist und (c) die ereignisgesteuerte Spiegelung des Content-Zustands im UI-Zustand unglaublich viel Spielraum für Zustandsdivergenz und somit ungültige Zustände lässt, und dabei massig spielirrelevante Infrastruktur für die Verteilung von Ereignissen notwendig wird.

Ich denke, Content Creation ist momentan eine der größten Herausforderungen; wie platziere und verbinde ich schnell viele Objekte in glaubhafter Weise und ohne Durchdringung; wie konstruiere und verteile ich schnell die richtigen Materialien (inkl. gute Erreichbarkeit von Shaders, Texturen etc.). Bei diesen Problemen sind automatisches Neukompilieren, Neukonvertieren, Neuladen und Neukonstruieren von Spielobjekten essenziell, was je nach Tragweite der Änderungen auch bedeutende Herausforderungen bzgl. Software-Architektur einschließt. Davon abgesehen würde ich wohl versuchen, die Bearbeitung möglichst nah beim Spiel zu halten; eine minimalistische Overlay-UI mit problemangepassten Tools (Objektplatzierung mit Kollisionserkennung, einem oder mehreren wählbaren Ankerpunkten statt generischer Translation/Rotation/Skalierung etc.) dürfte dir schon einen gehörigen Produktivitätsvorteil gegenüber vielem, was so auf dem Markt ist, verschaffen. Bei der UI nach Möglichkeit ganz auf eigenen Zustand verzichten; auch wenn das anfangs ein wenig mehr Arbeit bei der Echtzeit-Umwandlung von Daten in darstellbaren Text bedeutet, die Ersparnis bei der Aktualisierung der UI macht das vermutlich zehnmal wett. Natürlich kann bei der Bearbeitung sehr großer Datenmengen Caching mal notwendig werden, aber dann ist das immer noch ein behandelbarer Spezialfall. Bäume von Objekten und Materialien in List- und Tree-Views umzuwandeln, um diese dann permanent beidseitig aktuell zu halten, ist jedenfalls kein Spaß, und meines Erachtens nutzlos vergeudete Zeit. Ein Widget, das einfach jedes Frame das anzeigt, was da ist, dürfte ein Bruchteil der Arbeit sein.

Inspiration gibt eventuell The Witness. Am Ende geht es in fast allen Spielen um Content, und niedrige Qualität bei Assets und insbesondere Assetkomposition sind meines Erachtens die größten Mängel bei aktuellen hochkarätigen Spieleproduktionen. Deshalb wäre mein Tipp, die Bearbeitung, das Speichern und das Laden von Content ins Zentrum der Entwicklung zu stellen (nebenbei auch gleich das Speichern und Wiederherstellen von Spielzustand, wenn das Spiel unterbrechbar sein soll).
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von CodingCat »

Alexander Kornrumpf hat geschrieben:Angenommen ich würde ein Spiel machen wollen...
[...]
Scenegraph -> Ich weiß nicht wieviel Sinn es hat den rendereragnostisch zu implementieren und ob das mal jemand gemacht hat (?) Vermutlich ist OpenSceneGraph tatsächlich noch am ehesten das was ich will, wäre es nicht so sperrig. Lohnt es sich vielleicht den ganzen optionalen Kram und den Renderer wegzuwerfen, aber den eigentlichen SceneGraph zu benutzen?

Materialsystem -> Ein Grund hier überhaupt rumzumoppern ist ja, dass ich Kontrolle über die Pipeline will, bzw. dass es mir halt nichts nützt, wenn die Engine "nützliche" Sachen schon vorimplementiert aber dadurch auch limitiert was überhaupt geht. Dennoch scheint es irgendwie so zu sein dass Material mehr ist als "ein paar Shader schreiben". Was ist hier nötig? Was gibt es? Was taugt das? (BTW: Dass die OGRE Samples nicht mit DX11 gehen liegt vermutlich an den auto-generierten Shadern. Soviel dazu.)
[...]
Renderer ->Eigentlich *ist* Direct X doch der Renderer. Muss man da unbedingt was wrappen? Wieviel?
Ich würde es tatsächlich mal so direkt und einfach wie möglich versuchen. Mittlerweile arbeite ich am liebsten mit meinem 3-Header-Framework: 1 Header OpenGL-, 1 Header Cuda- und 1 Header OpenCL-Wrappers, die sich nur um die Ressourcen und ganz wenig gängige Low-Level-Funktionalität wie ein ergonomisches Interface für Kernel-Dispatch kümmern. Bau erst die Spielwelt (inkl. Rendering) für dein Spiel, und zieh dann genau das raus, was alles zusammen einfacher macht.

Bzgl. Materialsystem gilt wohl leider, dass ich bisher stets weit mehr und länger daran gearbeitet habe, keinen materialspezifischen Code schreiben zu müssen, als der materialspezifische Code letztlich an Arbeit erfordert hätte. Erschwerend hinzu kommt, dass alles das, was man gerne an potentieller Next-Gen-Technik ausprobieren würde, überhaupt kein Material in Form eines oder mehrerer isolierter Shaders mehr zulässt. Material verteilt sich mittlerweile von den Draw Calls der Objekte über das Shading eines G-Buffers (Lichter? Light Probes? Volumen-Lookups oder gar Tracing für GI? -> Einheitliches Material-Layout? Global bekannte Material-Klassen?) bis hin zu vollkommen getrennten Passes zur Vorbeleuchtung einer Szenenapproximation zum Cachen des indirekten Lichttransports, eventuell gar Ray Tracing? Je nachdem, was du ausprobieren möchtest, brauchst du in erster Linie problemlosen Datenzugriff, von überall. Damit fällt ein großer Teil gängiger Material-Abstraktionen schonmal unter den Tisch, übrig bleibt allenfalls ein moderat variables Daten-Layout.
Zuletzt geändert von CodingCat am 20.12.2013, 12:27, insgesamt 1-mal geändert.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

CodingCat hat geschrieben:
Alexander Kornrumpf hat geschrieben:Angenommen ich würde ein Spiel machen wollen...
[...]
Fehlt was?
Ich würde sagen, in erster Linie fehlt die Content Creation. Das ist der Punkt, an dem ich vor ca. einem halben Jahr ausgestiegen bin.
Danke dir! Das hilft mir zu verstehen was heute die Herausforderungen sind und weshalb z.B. Unity so ist wie es ist.

Wo ich nun drüber nachdenke ist es so dass ich mir etwas viel Sandboxigeres vorstelle als die meisten heutigen Spiele. Eher eine leere Karte mit noch gar nichts drauf, und den Rest macht der Spieler. Vielleicht ein bisschen in Richtung SimCity 2000, um einen Vergleich zu haben.

Dafür muss ich zunächst mal nur eine Karte laden und rendern können. Alles andere ist dann Teil des Spiels und eben gerade nicht der Engine. Deswegen glaube ich auch dass mir Unity quasi nichts dabei nützen würde.

In dem Kontext wäre das was du beschreibst nur eine Art God-Mode für das was an UI ohnehin da sein müsste.

Hm, hm.

(Zweiter Beitrag ploppte zwischendurch auf. Schau ich mir gleich an)
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

CodingCat hat geschrieben: Ich würde es tatsächlich mal so direkt und einfach wie möglich versuchen. Mittlerweile arbeite ich am liebsten mit meinem 3-Header-Framework: 1 Header OpenGL-, 1 Header Cuda- und 1 Header OpenCL-Wrappers, die sich nur um die Ressourcen und ganz wenig gängige Low-Level-Funktionalität wie ein ergonomisches Interface für Kernel-Dispatch kümmern. Bau erst die Spielwelt (inkl. Rendering) für dein Spiel, und zieh dann genau das raus, was alles zusammen einfacher macht.
Das ist ja dieser "Write Games, not Engines" Ansatz. In meinem jugendlichen Leichtsinn hatte ich gedacht, klar, mach ich so, indem ich eine fertige Engine nehme. Das hat mich überhaupt hierher gebracht. Unter dem Strich scheint das aber ja nicht viel zu sparen. Das einzige was ich wirklich keinesfalls selbst machen möchte ist der low level Mathe Kram. Vielleicht würde es schon reichen boost::uBLAS zu nehmen? Ich erinnere mich dass ich mit CUBLAS damals recht gut klargekommen bin.
Bzgl. Materialsystem gilt wohl leider, dass ich bisher stets weit mehr und länger daran gearbeitet habe, keinen materialspezifischen Code schreiben zu müssen, als der materialspezifische Code letztlich an Arbeit erfordert hätte. Erschwerend hinzu kommt, dass alles das, was man gerne an potentieller Next-Gen-Technik ausprobieren würde, überhaupt kein Material in Form eines oder mehrerer isolierter Shaders mehr zulässt. Material verteilt sich mittlerweile von den Draw Calls der Objekte über das Shading eines G-Buffers (Lichter? Light Probes? Volumen-Lookups oder gar Tracing für GI? -> Einheitliches Material-Layout? Global bekannte Material-Klassen?) bis hin zu vollkommen getrennten Passes zur Vorbeleuchtung einer Szenenapproximation zum Cachen des indirekten Lichttransports, eventuell gar Ray Tracing? Je nachdem, was du ausprobieren möchtest, brauchst du in erster Linie problemlosen Datenzugriff, von überall. Damit fällt ein großer Teil gängiger Material-Abstraktionen schonmal unter den Tisch, übrig bleibt allenfalls ein moderat variables Daten-Layout.
Jo, es sieht für den Außenstehenden eben so aus als wäre das irgendwie ein must-have. Ich würde auch lieber ohne auskommen.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Chromanoid »

CodingCat hat mit dem Content-Problem völlig recht. Die meisten Spiele sind doch inhaltsgetrieben. Dafür baut man die Engine ja überhaupt erst. Eine Engine ist im Grunde ein Spiel mit austauschbaren Inhalten. Ich würde immer mit dem Inhalt eines Spiels beginnen, nur dann weißt Du in was für eine Engine Dein Spiel reinpasst. Assimp reicht da ja bei weitem nicht aus. Die ganze Pipeline ist was zählt und da liefern UDK, Unity, Flash und Co. eben ganze Welten mehr.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Chromanoid »

Nachtrag weil ich Deinen Beitrag zur Content Creation nicht gesehen hatte. Denk daran, dass Dir dann immer noch ziemlich viel fehlt, wo z.B. unity weiterhelfen kann (AFAIK): Wann werden welche Animationen abgespielt, wo kommt bei dem Modell Rauch raus, wann wird welcher Ton abgespielt usw. Mit Unity könntest Du wahrscheinlich sofort mit den Spielinhalten beginnen. Schau Dir das hier mal an: The Top 6 Misconceptions I Had About Unity by Richard Fine (2011) [http://zfx.info/viewtopic.php?f=28&t=1589]
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von CodingCat »

Hauptargument für Unity wäre für mich in erster Linie, dass es praktisch überall läuft. Ich habe Unity zu wenig getestet, um zu einem abschließenden Urteil zu kommen, aber bzgl. Ergonomie/Effizienz der Tools schienen mir da viele der üblichen Defizite vorhanden zu sein. Ich denke, ein Stück weit kannst du vieles durch ad hoc-Code wettmachen, d.h. du siehst einfach die Programmiersprache und den Code als dein Tool. Gerade bzgl. Transformationstools hast du mit guten eigenen Tools vermutlich tatsächlich einen Vorteil gegenüber mittelmäßigen Standardlösungen.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von CodingCat »

Nachtrag: Auch Text wird meines Erachtens häufig unterschätzt. Automatisches Reload einer Text-Datei mit einem guten Texteditor (Block-Selektion, Block-Editing ...) kann zu einem unvergleichlich effizienteren Workflow führen als dieselben Daten in einer Eingabemaske, in dem jedes Textfeld und jeder Button einzeln angeklickt und bearbeitet werden muss, und dabei jeder Datensatz erst mit einem oder mehreren Klicks aufgerufen oder hinzugefügt werden muss.

Anektdote am Rande: Die Torsion-Levels sind genau so entstanden, durch Bearbeitung einer überwachten XML-Datei im Texteditor. Für die Platzierung von Objekten ist das eher suboptimal, für sonstige Attribute ist es unglaublich praktisch.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

Chromanoid hat geschrieben:CodingCat hat mit dem Content-Problem völlig recht. Die meisten Spiele sind doch inhaltsgetrieben. Dafür baut man die Engine ja überhaupt erst. Eine Engine ist im Grunde ein Spiel mit austauschbaren Inhalten.
Das ist ein Problem mit der Definition von Engine. Als wir beide noch jung waren hat man eine Engine gebaut um was gerendert zu bekommen ohne durchzudrehen. Müsstest du dich eigentlich auch noch dran erinnern können.

An den Teil mit den universell austauschbaren Inhalten glaube ich nicht. Ich beobachte den Spielemarkt jetzt nicht allzugenau, aber ich glaube die Strategiespiele die auf Unreal-Technologie basieren kann man schnell enumerieren, oder? Es heißt immer man könne mit den modernen Engines jedes Spiel machen, aber der Workflow ist dann doch nur auf eine Art von Spiel ausgelegt. Sieht man ja auch an der begrenzten Vielfalt der Spiele, die letztlich auf den Markt kommen.
Ich würde immer mit dem Inhalt eines Spiels beginnen, nur dann weißt Du in was für eine Engine Dein Spiel reinpasst. Assimp reicht da ja bei weitem nicht aus. Die ganze Pipeline ist was zählt und da liefern UDK, Unity, Flash und Co. eben ganze Welten mehr.
Verzeih meine Ignoranz, aber was genau liefern die mehr? Der größte Hebel ist meines Wissens die Qualität der Assets an sich. Wenn die schon so mittel ist (und sein wir mal ehrlich im Hobby Bereich ist sie das, dann kannst du nach hinter raus in der Pipeline soviel auch nicht mehr rausholen, oder? Skizziere bitte kurz für jemanden der das nicht mitbekommen hat eine moderne Content Pipeline. Was kann man mit einem Asset noch machen als es von der Platte laden und rendern? (Frage ist ernst gemeint. Das könnte hier ein unheimplich nützlicher Thread werden, wenn wir mal ein bisschen Erfahrung [leider eher von eurer als von meiner Seite] bündeln).
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Alexander Kornrumpf »

Chromanoid hat geschrieben:Nachtrag weil ich Deinen Beitrag zur Content Creation nicht gesehen hatte. Denk daran, dass Dir dann immer noch ziemlich viel fehlt, wo z.B. unity weiterhelfen kann (AFAIK): Wann werden welche Animationen abgespielt, wo kommt bei dem Modell Rauch raus, wann wird welcher Ton abgespielt usw. Mit Unity könntest Du wahrscheinlich sofort mit den Spielinhalten beginnen. Schau Dir das hier mal an: The Top 6 Misconceptions I Had About Unity by Richard Fine (2011) [http://zfx.info/viewtopic.php?f=28&t=1589]
Hatte ich damals gesehen. Überzeugt mich nicht wirklich. Meine Perspektive finde ich eher hier vertreten:

http://www.gamasutra.com/blogs/TylerGla ... _Unity.php

Ein guter Teil des Artikels scheint mir recht ausgewogen und einen Teil meiner Kritik sogar entkräftend, aber ich gewichte diesen Teil recht hoch:
And here is where my criticisms of Unity begin. I want to make a FINISHED product, not just a prototype. [...]
But I've come to realize, while Unity makes 90% of the game take 10% of the time, it also makes 10% of the game take 90% of the time. This is somewhat true for most games anyway, but it feels really pronounced in Unity, especially if you have a strong attention to details. [...]
No built in user-interface system? Yeah I know about the Asset Store and NGUI and they are awesome features, I am just annoyed that the built in user interface stuff is SO bad right now, you just CAN'T use it for a release project. After spending 1500$ on Unity Pro just to be told "go spend 100 more to get a usable user interface system" just feels kinda wrong.
Letzter Punkt ist möglicherweise historisch überholt?
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Chromanoid »

Alexander Kornrumpf hat geschrieben:Was kann man mit einem Asset noch machen als es von der Platte laden und rendern? (Frage ist ernst gemeint. Das könnte hier ein unheimplich nützlicher Thread werden, wenn wir mal ein bisschen Erfahrung [leider eher von eurer als von meiner Seite] bündeln).
Das betrifft Dein Häuserbau Spiel nur teilweise: Physikalische Repräsentation, Animationen verwalten und Trigger an bestimmte Phasen der Animation kleben, Einstellungen für IK und Ragdoll-Effekte, Einstellungen für Materialien, Einstellungen für das Andocken anderer Modelle und Partikelsysteme, LoD Einstellungen, Einstellungen für das generische Zerstören, Komposition von Szenen...

Das sind natürlich nur Beispiele, aber zwischen Rendern und von der Platte laden kommt meistens noch viel Zeug dazu. Ich sag nicht, dass man das nicht selbst bauen kann, aber man sollte es nicht unterschätzen. Ich kann nur empfehlen ein Programm wie Blender inkl. eigener Anpassungen/Skripte direkt im Workflow vorzusehen.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Letzter Punkt ist möglicherweise historisch überholt?
Sie arbeiten daran endlich eine Unity Inbuild GUI Lösung auf die Beine zu stellen. Das macht inzwischen der Programmierer der auch NGUI programmiert hat. Allerdings arbeiten sie halt schon ne ganze Weile daran ohne zu Potte zu kommen :lol:

Im Moment musst du tatsächlich noch ein GUI System zukaufen. Geht natürlich auch mit dem Krampf den sie OnGUI nennen. Aber das ist wirklich nen Krampf weil du da wirklich alles selber programmieren musst. Und sehr unperformant.

Und natürlich ist auch Unity nicht nur eitel Sonnenschein. Auch nicht UDK oder die anderen Systeme. Da hats jeweils genug zum aufregen drin. Aber es ist halt immer noch tausendmal besser als alles was ich auf die Beine stellen könnte selbst wenn ich tausend Jahre alt werden würde.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
dronus
Establishment
Beiträge: 114
Registriert: 11.01.2010, 01:53

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von dronus »

Tiles hat geschrieben:
Es gibt einfach zu wenig Open Source Entwickler die wirklich das Know How und das Können haben um sowas zu entwickeln. Und sobald sie ein gewisses Level an Können erreicht haben wandern sie unweigerlich in die Industrie ab.
Komischerweise werden mehr und mehr Softwares des täglichen Bedarfs durch OpenSource gedeckt. Firefox, und Webkit-Derivate kstellen die Mehrheit der Browser, Linux-Derivate die Mehrheit der Betriebssysteme (wenn auch gut versteckt in Handys, Tablets, Routern und Waschmaschinen :-p ). Allerdings werkelt dort tatsächlich die Industrie mit (z.B. Google und Mozilla industrialisiert sich ja auch recht gut..). So gesehen würd ich sagen dass die Game-Engine-Industrie mit ihrem Paradigma der Engine als verkaufbares Endprodukt eher hinderlich ist, da man mit dem Geschäftsmodell natürlich schlecht Open-Source gehen kann (sonst wäre das Geschäft einfach weg :-) ). Mal sehen wie sich das Ganze auflöst...

Eine etwas freisprengende Kraft könnte durch den starken Trend zur Interoperabilität kommen.. vielleicht open-source't jemand seine Engine, damit er sie ohne große Investition ein Jahr später auf allen erdenklichen Platformen anbieten kann. Es gibt kaum eine Platform auf der man heutzutage nicht Doom starten kann, und theoretisch könnte ID immer noch das WAD-File dazu verkaufen, denn der Content wurde nicht verschenkt :-) Die Unreal Engine 3 kann man nun halbwegs zu JS compilieren, vielleicht schickt Epic jetzt ein paar Entwickler zu Mozilla oder Google, um JavaScript SIMD und GGPU schmackhaft zu machen usw. so kommt alles zusammen...
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Für die generelle Softwarelandschaft stimmt der Trend natürlich. Erstaunlich wo sich inzwischen überall Open Source finden lässt. Aber der Spiele- und Grafikmarkt ist immer noch fest in Händen der proprietären Lösungen. Gimp ist immer noch kein Ersatz für Photoshop. Blender immer noch kein Ersatz für Max. Und die grossen Spieleengines sind auch fast durch die Bank closed source. Ausser man kauft sich eine entsprechende Sourcecode Lizenz natürlich :)
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
anonym
Beiträge: 79
Registriert: 15.07.2009, 07:35
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von anonym »

Wie verhält es sich denn mit der Lizenzpolitik und Zugänglichkeit des Queltextes bei den Softwarelösungen anderer Industrien, z.B. Medizintechnik, Pharma, Chemie, Produktion, Logistik, Kraftwerk, Verwaltung, usw. im Vergleich mit der Spieleindustrie?
dronus
Establishment
Beiträge: 114
Registriert: 11.01.2010, 01:53

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von dronus »

Tiles hat geschrieben: Gimp ist immer noch kein Ersatz für Photoshop. Blender immer noch kein Ersatz für Max.
Das würd ich anders sagen... die Marktanteile sind minimal. Ob sie ein Ersatz sind, hängt aber von der Aufgabenstellung ab, und bei einigen Aufgaben tun sie was sie sollen und sind ein Ersatz. Dazu kommt natürlich eine sehr große Trägheit durch die angesammelte Erfahrung. Ich hab vor 10 Jahren Maya benutzt, heute benutze ich gelegentlich Blender, und noch immer will ich alles so machen wie ich es in Maya getan hätte. Dann denkt man ok, mit Maya konnte man mehr machen schon damals.. aber dann schaue ich im Web nach, und plötzlich gehts auch in Blender, nur meist auf recht eigenartige Weise :-)
Gimp benutze ich mehr, da ist es tatsächlich so dass ich bei gelegentlicher Photoshop-Nutzung jetzt von Photoshop genervt bin.

Bei Spiele-Engines sind die "großen Geräte" von den großen Firmen. Und teilweise eignen die sich ja auch für kleine Dinge mittlerweile.. das ist natürlich gut für die Entwickler, aber irgendwie auch schade finde ich. Bei sehr einfachen Spielen nimmt ein Großteil der Engine mehr oder weniger die Medien-Abstraktionsschicht ein, auch da ist viel open source vorhanden, wie SDL, OpenGL, OpenAL usw.

Auf den ganzen Spielemarkt bezogen haben die großen Engines vermutlich stark Marktanteile eingebüsst fürchte ich, zu Gunsten selbstgemachter Engines für Smartphones und schlechtes HTML / JS / Flash... die Blase ist jetzt allerdings mehr oder weniger durch hoffe ich mal, und auch im Browser kann Qualität ja nicht schaden, und mit WebGL und anderen noch zu erschaffenden Techniken wird das wohl auch irgendwann gelingen... Eine Zeit sah es so aus, als würden Browser-Anwendungen jetzt durch netzwerknutzende 'Apps' im weitesten Sinne ersetzt, aber jetzt scheint es doch wieder in den Browser zu gehen habe ich das Gefühl. Der größte Vorteil ist wohl das Gefühl, irgendwann nur noch eine Platform für alles zu haben.

Meine großes Fragezeichen ist, ob jedes Spiel auch eine große Engine braucht oder haben kann oder sollte. Wenn man mit Unity oder so ein 2d-Puzzlespiel macht, das auf vielen Platformen läuft, und dazu mit einem Fingerschnippen nach großem Casino aussieht, ist das schon eine tolle Sache. Andererseits spielen die Leute auch immernoch Patience mit einfarbigem grünen Hintergrund... wenn man jetzt ein neues Kartenspiel erfindet, kann man es so machen, oder mit Unity... Letztlich kann man fast alles mit Unity oder Unreal Engine machen.

Ein kleiner Vorteil ist auf Unity zu verzichten ist dann vielleicht die Größe. Das Kartenspiel mit grünem Hintergrund kann man in HTML JS machen und es ist in wenigen Sekunden geladen, und das sogar wenn man es vorher überhaupt nicht hatte.

Solange die Internetverbindungen mäßig schnell sind, gibt es vielleicht noch ein paar Jahre lang eine Motivation content-arme Spiele zu machen. Solche können dann auch gut auf große Engines verzichten... Auch auf Mobiltelefonen probiert man schneller mal ein Spiel-App aus, bei dem nicht 100MB daneben steht, vor allem wenn man irgendwo unterwegs mit mäßigem Netz ist.

Als ich vor vielen Jahren mit pozedurealen Gebilden experimentiert hab, war das ein kleiner Aha-Effekt: Man startet das Spiel und hat nach eingen Sekundenbruchteilen eine Landschaft aus Millionen Polygonen auf dem Schirm. Wo kein Content ist, muss auch keiner geladen werden. Aber bis zur Weltformel, die ein GTA5 aus dem Nichts synthetisiert, wird es noch ein paar Jahre dauern vermute ich :-)
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von dot »

Nur als kleine Anmerkung: Weder OpenGL noch OpenAL sind open source, ein verbreitetes Missverständnis... ;)
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Kann man bei Android eigentlich auch noch von Open Source reden? Man kann sich zwar den Code anschauen, aber die Google Jungs bauen doch nur ein was denen genehm ist.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Tiles hat geschrieben:Gimp ist immer noch kein Ersatz für Photoshop. Blender immer noch kein Ersatz für Max.
Das würd ich anders sagen... die Marktanteile sind minimal. Ob sie ein Ersatz sind, hängt aber von der Aufgabenstellung ab, und bei einigen Aufgaben tun sie was sie sollen und sind ein Ersatz.
Ja schon, so kann man es natürlich auch sehen. Die Marktanteile sind aber deswegen so minimal weil die Dinger eben kein wirklicher Ersatz sind. Du kannst einem Studio nicht Maya wegnehmen und dafür Blender hinstellen. Die kriegen damit ihren Job damit in den meisten Fällen nicht mehr erledigt.

Ob ein Tool taugt siehst du daran wie es die Industrie einsetzt. Die sind da sehr pragmatisch. Und das sieht man ja auch daran wie sich zum Beispiel Linux Derivate in den unterschiedlichsten Anwendungsgebieten verbreiten. Wenn die Industrie einen Vorteil sieht dann wird der auch ausgenutzt. Sie nutzen in der Regel aber im Spielebereich eben doch die Industrielösungen und nicht die Open Source Lösungen. Und das trotz hoher Preise.

Natürlich ist einer der Hauptgründe dass eine Umstellung richtig Knete kostet. Die etablierten Studios haben sich ja ihre Pipelines schon alle eingerichtet, die Software ist in der Regel auch schon abgeschrieben. Und die Künstler sind auch alle auf Max, Cine, Maya und Poposhop eingelernt. Dass sich ein Tool mit den richtigen Features und der richtigen Strategie auch heutzutage noch etablieren kann hat man aber an Modo gesehen. Es hapert bei Blender und Gimp tatsächlich auch an den Features und an der Bedienbarkeit. Zeit ist Geld.

So lange Gimp keine 32 Bit per Channel und CMYK kann ist es einfach kein Ersatz für Photoshop. Druck braucht CMYK, und mit 8 Bit per Channel stösst man unweigerlich an das Treppenproblem. Das 8Bit per Channel Problem könnte nun nach gerade mal etwas mehr als 10 Jahren warten doch demnächst behoben sein. Mit demnächst meine ich ein bis zwei Jahre. Wir warten auch weiterhin auf CMYK ...

Bei Blender sieht es ein wenig anders aus. Das mausert sich immer mehr, und wird auch tatsächlich hier und da vollwertig industriell eingesetzt. Für uns Hobbyisten wie mich ist das Ding sowieso unverzichtbar. Ich habe keine 4000 Euro für Maya. Das Polygonmodeling ist allerdings sehr umständlich und dementsprechend langsam. Was symptomatisch ist. Du bekommst in Blender zwar die meisten Jobs erledigt, aber das eben recht umständlich. Der Preis für kostenlos.

Bei OSS wird traditionell weniger Wert auf die GUI gelegt. Macht ja auch viel mehr Spass ein neues Feature einzubauen als an der UI rumzuschrauben. Und Blenders GUI Entwicklung stand ja auch mal eben zwei Jahre still. Da hat es eine Fast-Revolte gebraucht um da wieder Leben reinzubringen. Wobei, Leben, hihi, der UI Bereich ist nur für das UI Team zugänglich. Ein Schelm wer böses hier vermutet ... . Aber schaun wer mal. Im neuesten Blender Blogeintrag von Ton über die Ziele des nächsten Jahres ist jedenfalls schon wieder nichts mehr von UI zu lesen :)

Da sind wir aber auch wieder beim Ressourcenproblem von OSS. Blender hat nicht wirklich viele Vollzeitentwickler.

Die grösste Hürde für den professionellen Einsatz sind allerdings die professionellen Plugins die man so braucht um mithalten zu können. Sowohl bei Gimp als auch bei Blender. Und da siehts dann ganz schnell Mau aus. Blender hat keine zeitgemässe Fluidsimulation, keine zeitgemässe IK Lösung, keine Plugins wie Forester etc. . Bei den Renderengines sieht es ein wenig erfreulicher aus. Da gibt es wenigstens ein wenig Anbindung an die Profiliga. Und auch Cycles ist relativ mächtig inzwischen. Der kann sogar hier und da gegen die Grossen mithalten, yay.

Ein sehr grosses Hindernis sind auch die Lizenzen wie die GPL Lizenz. Das ist vielen kommerziellen Entwicklern einfach zu haarig. Da fängt man sich schnell mal eine Klage ein. Und um den Bogen zum Thema Game Engines zu schlagen, versuch mal ein Game zu verkaufen das mit der Blender Game Engine gemacht ist. Haleluja sag ich nur ...

Alles in allem ist Blender bei allem Meckern schon recht mächtig. Ich möchte Blender auch nicht mehr missen. Nur ist es eben kein Branchentool. Sein Haupteinsatzgebiet sind die Hobbyisten.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
dronus
Establishment
Beiträge: 114
Registriert: 11.01.2010, 01:53

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von dronus »

dot hat geschrieben:Nur als kleine Anmerkung: Weder OpenGL noch OpenAL sind open source, ein verbreitetes Missverständnis... ;)
Ok, das sind Standards, keine Codes... allerdings gibt es von beidem Open Source Implementierungen, für alle die, die wissen wollen wie man es umsetzen kann...

Was Open-Source-Software angeht, hab ich schon einige für bezahlte Arbeit genutzt. Allerdings bin ich nicht wirklich in der klassischen Spielebranche tätig, habe aber z.B. interaktive Exponate für Museen gebaut. Meine Favoriten bei der Geldarbeit sind: Ubuntu, gcc, Python, OpenJDK, Chromium, ffmpeg, Blender, OpenSCAD, GIMP, gedit, vim, bash, VirtualBox. An bezahlter Software benutze ich fast nichts mehr, es bleiben: Die Spiele sowie Vanilla-Windows und MacOS X zum Testen.

Ich spiele auch manchmal originäre und Mittlerweile- Open-Source-Spiele. Da gibt es so viele, dass man das getrost auch "Industrie" nennen kann. Nur "Wirtschaft " nicht, weil die Macher in der Regel kein Geld sehen :-) bis auf glückliche Ausnahmen... Mich interessiert allerdings, warum nur wenige Leute (zu denen ich allerdings gehöre) alte Spiele ertragen bzw. genießen. Es gibt ja praktisch alle Klassiker entweder mittlerweile kostenlos, oder in nachgebaut. Dort ist natürlich das technisch bedingte, also die Grafik- und Soundqualität, manchmal auch die Bedienbarkeit anachronistisch. Die Spielmechanik ist aber oft akzeptabel. Sicher hat es da auch neue Ideen oder neue technische Möglichkeiten gegeben, aber einige Spielprinzipien waren schon vor Jahrzehnten umzusetzen und kaum zu verbessern. Ich spiele gerne sowas. Bzw. ärgere mich dann bei aktuellen Spielen, wenn es an neuen oder guten Prinzipien mangelt. Egoshooter, Rollenspiele und alles dazwischen (z.B. GTA) kommen immer noch würdig auf den Markt würde ich sagen... Aber z.B. 'Lemmings' oder 'Die Siedler', 'Civilization' usw. sehe ich bis Heute keine Clones, die das Prinzip in der gewohnten Qualität aufgreifen. Oft fühlt sich dass dann im Vergleich wie Schach auf einem größeren Brett mit zwei neuen Figuren an... Das schlägt sich auch m.E. in den Engines nieder. Die sind für heute typische Spiele gemacht, und solche Spiele können damit besonders gut gemacht werden. Vermutlich kann man fast jedes Nicht-Realität-Spiel (z.B. Lemmings, Skat...) auch mit Unity machen, aber es ist auch keine besonders große Hilfe dann.

Es scheint einfach sehr schwer zu sein, neue Prinzipien zu entwickeln. Was naheliegend gut ist, ist schonmal gemacht worden.

Die Industrie kann sich daher nur noch auf die mit der Technik und steigenden Umsatzen und Mitarbeiterzahlen Qualitätsteigerung verlassen. Und die finde ich nicht so schnell wie es Moores Law vermuten lassen sollte. Zwar sehen die Spiele mehr und mehr wie Film oder in Echt aus, aber nur im statischen Sinne. Die dynamische Simulation kommt nur sehr mühsam vorran. In fast jedem Ego-Shooter braucht es nur einen kurzen Moment, bis man vor einer Situation steht in der man in der echten Welt anders handeln würde. Wenn man Glück hat, kann man eine Dose Cola trinken. Ich wüsste aber nicht, wie ich sie einem Wachmann in den Nacken schütten oder auf einem Herd kochen lassen kann. In keinem Spiel kann man mit den NPCs über Klobürsten diskutieren.

Im Bereich der Realitäts-Simulationen ist also noch viel zu tun... da frage ich mich sehr, ob das Konzept "Von Menschen für Menschen" da ewig weitergeht. Natürlich kann ich mit hunderten Designern leichter eine Stadt bauen wo jedes Haus echt aussieht, verschiedene Bewohner hat und andere Poster an den Wänden hängen. Die Möglichkeit zu Explorieren ist in derzeitigen Shootern z.B. aber nur begrenzt wie gesagt, und wenn man das überwinden will, müsste man schon 100 Designer an ein einziges Haus setzen: Was ist in den Schubladen? Was läuft im Fernsehen? Über was weiß der Bewohner alles zu berichten? Ich glaube da wird man nicht drum herum kommen, Design und Verhalten von Personen und Dingen zu abstrahieren. Irgendwann muss eine mehr oder weniger alltagstaugliche AI in die Person rein. Und spätestens wenn man mehr als ein Haus macht, ist es hoffnungslos den Radiergummi jedesmal von Hand auf den Tisch zu legen. Dass sollte dann der NPC selber tun. Für eine ganze Stadt wird man dann nur noch Prinzipien designen können, die Ausgestaltung muss ein Computer übernehmen, ob nun im Studio oder in der Gameengine. Irgendwann denkt sich der dann neue Gegenstände aus, die Leute haben können und Dinge die sie tun können usw. und dann ist man bei einer Art vollprozeduralen Welt, in der die uns bekannte Welt nur noch als ein getunter Parametersatz vorhanden ist. Wenn man irgendwo etwas verstellt, sieht man eine fremde Welt voller Wunder... Die Vorstellung treibt mich bei meinen Hobby-Experimenten an.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Tiles »

Es scheint einfach sehr schwer zu sein, neue Prinzipien zu entwickeln. Was naheliegend gut ist, ist schonmal gemacht worden.
Das hier ist ein echtes Dilemma für uns Hobbyentwickler. Die Genres stehen halt seit Jahren fest. Was irgendwie umsetzbar war wurde inzwischen auch umgesetzt. Und wirklich neues gibt es kaum noch. Egal was du versuchst, ein anderer hat es schon vor dir gemacht. Meistens kommerziell und mit einem grossen Team. Und deswegen meistens auch noch viel besser als du es als Hobbyist je hinkriegen könntest, seufz :)

Ich weiss nicht wie es euch geht, aber mir gehn als Hobbyentwickler so langsam auch die Spielideen aus die mich noch reizen würden. Von den kleinen Dingern habe ich schon genug gebaut. Und bei den grossen Dingern ist eigentlich nur noch Zeug übrig das ich allein nie bewältigen könnte. Vor allem weil die Qualitätsschere zwischen Profis und Hobbyisten immer weiter aufklafft. Klar könnte man da ein Team gründen. Aber das kann im Hobbybereich ein echter Höllentrip werden. Die Hobby Teamprojekte die auch wirklich fertig werden sind dünn gesät.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Grafik"engines", Stand der Kunst 2013

Beitrag von Chromanoid »

Ich finde da ist noch viel Luft nach oben. Ich sehe das Problem eher in der nostalgischen Natur der meisten Spieleentwickler und Spieler. Wenn man nach dem Kick in den bewährten Spielkonzepten sucht, den Kick, den man in der Jugend/Kindheit vielleicht viel mehr gespürt hat, dann ist die Suche praktisch schon verloren. Ich habe auch keine schlagenden Ideen, glaube aber, dass durch authentische originäre Inhalte, künstliche Intelligenz und Mehrspielerfunktionen Spiele immer einen neuen Unterhaltungswert gewinnen können. Es muss sich ja nicht immer nur um die Weiterentwicklung der Spielmechanik drehen. Ein besser ausgearbeitetes Thema mit besonderer Harmonie zwischen Thema und Spielmechanik sollte immer drin sein. Gesellschaftsspiele machen es vor. Beim Vermitteln von Persönlichkeit (der Spielfiguren) sehe ich auch noch großes Potential. Wenn es in Spielen um Inhalte geht, dann haben die Spiele doch meist nur die Finesse von Groschenromanen, das kann doch nicht alles sein.
Antworten