Walkthrough: Engine Irrtümer
Forumsregeln
Datenschutzerklärung: https://www.gamespodcast.de/datenschutzerklaerung/
Impressum: https://www.gamespodcast.de/impressum/
Forenregeln und zukünftige Weltverfassung
ART 1: Behandle andere Nutzer mit Respekt.
ART 2: Do NOT piss off the Podcasters
Lies bitte weitere Hinweise hier: viewtopic.php?f=4&t=2789
Datenschutzerklärung: https://www.gamespodcast.de/datenschutzerklaerung/
Impressum: https://www.gamespodcast.de/impressum/
Forenregeln und zukünftige Weltverfassung
ART 1: Behandle andere Nutzer mit Respekt.
ART 2: Do NOT piss off the Podcasters
Lies bitte weitere Hinweise hier: viewtopic.php?f=4&t=2789
- Pan Sartre
- Beiträge: 271
- Registriert: 1. Aug 2017, 22:19
- Kontaktdaten:
Walkthrough: Engine Irrtümer
Eine Folge ganz nach meinem Geschmack. Bitte gern mehr davon!
Als Modder und Adventure-Entwickler fand ich besonders die Einlassungen von Moritz interessant, da ich natürlich keinen Einblick in den industriellen Einsatz von Game-Engines besitze. Auch die momentan übliche Aufgabenteilung bei der Games-Entwicklung blitzte an einigen Stellen durch. Bei Hobby-/Kleinprojekten muss man als einzelne Person ein breites Feld an Aufgaben abdecken (3D-Modeling, Leveldesign, Texturedesign, Sounddesign, Einbinden in die Engine etc.), was sich natürlich in der Qualität und Zeitaufwand eines Projektes widerspiegelt. Überrascht hat mich, wie viel Bedeutung Moritz Animationen und deren Integration in ein Spiel für ein glaubhaftes Erleben beimisst. Mit 3D-Animationen habe ich mich zu Letzt in Half-Life 1 beschäftigt und es seitdem nicht wieder angefasst. Aktuell trau ich mich wegen des hohen Frustationspotenzials und aus Zeitmangel (zum Glück!) nicht daran, obwohl mich schon interessieren würde, wie diese heute umgesetzt werden. In Source/SrcGold war es ja noch üblich, dass die Vertices eines Models fest Bones zugeordnet werden und letztere dann für die Animation bewegt werden. Ein sehr simples, aber sehr "holziges" Prinzip, dass im Kern sicher noch so üblich ist, aber doch bestimmt deutlich erweitert wurde.
Andererseits finde ich Jochens Unwissenheit äußerst erheiternd und seine Frage erfrischend naiv und exemplarisch für die meisten Gamer, obwohl ich ebenfalls höchsten oberflächliche Erfahrungen der Spielentwicklungen besitze. Ohne es böse zu meinen, aber ich glaube, würden sich mehr Spieler auch mit den technischen und handwerklichen Aspekten hinter ihrem Hobby "Games" beschäftigen, würde sie vieles mit anderen und vielleicht auch begeisterteren Augen sehen. Sie würden bei vielen kleinen Makel ein Auge zudrücken können und so manchen Bug mal eher verzeihen. Meist sind gerade unscheinbare Dinge, die sehr viel Aufwand und Trickserei bedurften um sie auch in aktuellen Spielen umzusetzen. Andererseits wäre so einiges was große Studios manchmal abliefern gar nicht mehr so grandios, sondern höchsten ein „Taschenspielertrick“ oder doch ein nur Flickwerk statt eines Meisterwerks.
Das Problem "Engine-Wechsel" kann ich selbst sehr gut nachvollziehen. Ich habe mich seit Jahren auf die SrcGold/Source (von Half-Life 1 zu Half-Life 2) eingeschossen und mir fehlt einfach der Mut (und natürlich auch Zeit sowie ein Grund) mich in eine neuere Engine einzurichten. Dabei hängt mir so vieles an Source zum Halse heraus. Es ist eine der Engines, die im Wesentlichen sehr leicht zu bedienen ist, aber über die Jahre durch so viele grafische Funktionen erweitert wurde, die aufgrund der simplen Engine-Architektur gar nicht voll zur Geltung kommen könnten. Es ist beispielsweise ein riesiger Aufwand, Teile einer Map/des Levels so zu bauen, dass diese nicht auf einem Raster im 90°-Winkel zu einanderstehen. Auch ist es ein Bruch im Map-Editor brauchbare Landschaften zu erstellen. Wo man bei neueren Entwicklungsumgebungen ein paar Klicks braucht, sitzt man in Source einen halben Tag. Umso mehr freut man sich dann, wenn etwas endlich „funktioniert“.
Erstaunt war ich daher, als Moritz die Source-Engine mit zu den aktuell gebräuchlichsten Engines zählte. Für den Einstieg ins (nicht kommerzielle) Gamedesign und als Modder für existierende Source-Spiele würde ich dem zustimmen, aber für kommerzielle Projekte? Mir fielen abseits der Valve eigenen Produkte (Dota2, CS:GO) auch keine ein, die noch auf Source setzen. Zumal es kein offen einsehbares Lizenz-Modell wie bei anderen Engines gibt. Da Dear Esther vor einiger Zeit zu Unity portiert wurde, gehe ich auch davon aus, dass Valve nicht unbedingt Kleinentwickler-freundliche Lizenzen aushandelt.
Als Modder und Adventure-Entwickler fand ich besonders die Einlassungen von Moritz interessant, da ich natürlich keinen Einblick in den industriellen Einsatz von Game-Engines besitze. Auch die momentan übliche Aufgabenteilung bei der Games-Entwicklung blitzte an einigen Stellen durch. Bei Hobby-/Kleinprojekten muss man als einzelne Person ein breites Feld an Aufgaben abdecken (3D-Modeling, Leveldesign, Texturedesign, Sounddesign, Einbinden in die Engine etc.), was sich natürlich in der Qualität und Zeitaufwand eines Projektes widerspiegelt. Überrascht hat mich, wie viel Bedeutung Moritz Animationen und deren Integration in ein Spiel für ein glaubhaftes Erleben beimisst. Mit 3D-Animationen habe ich mich zu Letzt in Half-Life 1 beschäftigt und es seitdem nicht wieder angefasst. Aktuell trau ich mich wegen des hohen Frustationspotenzials und aus Zeitmangel (zum Glück!) nicht daran, obwohl mich schon interessieren würde, wie diese heute umgesetzt werden. In Source/SrcGold war es ja noch üblich, dass die Vertices eines Models fest Bones zugeordnet werden und letztere dann für die Animation bewegt werden. Ein sehr simples, aber sehr "holziges" Prinzip, dass im Kern sicher noch so üblich ist, aber doch bestimmt deutlich erweitert wurde.
Andererseits finde ich Jochens Unwissenheit äußerst erheiternd und seine Frage erfrischend naiv und exemplarisch für die meisten Gamer, obwohl ich ebenfalls höchsten oberflächliche Erfahrungen der Spielentwicklungen besitze. Ohne es böse zu meinen, aber ich glaube, würden sich mehr Spieler auch mit den technischen und handwerklichen Aspekten hinter ihrem Hobby "Games" beschäftigen, würde sie vieles mit anderen und vielleicht auch begeisterteren Augen sehen. Sie würden bei vielen kleinen Makel ein Auge zudrücken können und so manchen Bug mal eher verzeihen. Meist sind gerade unscheinbare Dinge, die sehr viel Aufwand und Trickserei bedurften um sie auch in aktuellen Spielen umzusetzen. Andererseits wäre so einiges was große Studios manchmal abliefern gar nicht mehr so grandios, sondern höchsten ein „Taschenspielertrick“ oder doch ein nur Flickwerk statt eines Meisterwerks.
Das Problem "Engine-Wechsel" kann ich selbst sehr gut nachvollziehen. Ich habe mich seit Jahren auf die SrcGold/Source (von Half-Life 1 zu Half-Life 2) eingeschossen und mir fehlt einfach der Mut (und natürlich auch Zeit sowie ein Grund) mich in eine neuere Engine einzurichten. Dabei hängt mir so vieles an Source zum Halse heraus. Es ist eine der Engines, die im Wesentlichen sehr leicht zu bedienen ist, aber über die Jahre durch so viele grafische Funktionen erweitert wurde, die aufgrund der simplen Engine-Architektur gar nicht voll zur Geltung kommen könnten. Es ist beispielsweise ein riesiger Aufwand, Teile einer Map/des Levels so zu bauen, dass diese nicht auf einem Raster im 90°-Winkel zu einanderstehen. Auch ist es ein Bruch im Map-Editor brauchbare Landschaften zu erstellen. Wo man bei neueren Entwicklungsumgebungen ein paar Klicks braucht, sitzt man in Source einen halben Tag. Umso mehr freut man sich dann, wenn etwas endlich „funktioniert“.
Erstaunt war ich daher, als Moritz die Source-Engine mit zu den aktuell gebräuchlichsten Engines zählte. Für den Einstieg ins (nicht kommerzielle) Gamedesign und als Modder für existierende Source-Spiele würde ich dem zustimmen, aber für kommerzielle Projekte? Mir fielen abseits der Valve eigenen Produkte (Dota2, CS:GO) auch keine ein, die noch auf Source setzen. Zumal es kein offen einsehbares Lizenz-Modell wie bei anderen Engines gibt. Da Dear Esther vor einiger Zeit zu Unity portiert wurde, gehe ich auch davon aus, dass Valve nicht unbedingt Kleinentwickler-freundliche Lizenzen aushandelt.
Zuletzt geändert von Pan Sartre am 17. Jul 2018, 13:27, insgesamt 1-mal geändert.
Re: Walkthrough: Engine Irrtümer
Sehr schönes Thema. Nach der Folge über die Preismodelle der Engines hatte ich mir schon genau so eine Folge gewünscht, die ein bisschen hinter die Kulissen schaut, welche Alternativen es gibt, warum man eine Engine benutzt und so weiter. Bei der Frage, ob Unreal besser aussieht als Unity, kam mir noch der Gedanke, dass Epic Games den Entwicklern viel stärker dabei hilft, die Graphik zu verbessern. Allein wie viele kostenlose, qualitativ hochwertige Asset Packs Epic Games für ihre Engine bereit stellt, ist absolut bemerkenswert. Außerdem würde ich sagen, dass die Unreal Engine selbst viel besser aussieht als Unity. Damit sind jetzt gar nicht die fertigen Spiele, sondern erstmal nur der Editor gemeint. Die kostenlose Version von Unity finde ich persönlich optisch echt grenzwertig, das erinnert an Software aus dem letzten Jahrhundert. Vielleicht fühlen sich dadurch auch Leute, die sehr stark auf die Optik fixiert sind, mehr zur Unreal Engine hingezogen (reine Spekulation natürlich).
Während des Gesprächs kam auch der Aspekt auf, dass Unity ja eher die Engine für Einsteiger sei und dass Unreal besser für erfahrenere Entwickler geeignet sei. Das hört man in der Entwickler-Szene ständig und vielleicht kann mir Wolfgang erklären, warum das weiterhin so ist?
Ich habe beide Engines ausprobiert und viele Jahre Erfahrung mit der Unreal Engine 4, gerade weil ich sie als Einsteiger deutlich intuitiver und leicht zu erlernen eingeschätzt habe. An der Meinung hat sich bis heute nichts geändert. Die Unreal Engine versorgt Einsteiger direkt beim Start der Engine mit Templates für bekannte Spiele-Arten und zahlreichen Beispiel Projekten, die man sich anschauen und von denen man lernen kann. Außerdem muss man keine Programmiersprache wie c# lernen, sondern kann die visuelle Skriptsprache Blueprints in wenigen Monaten lernen. Dazu dann noch die Menge an kostenlosen Assets, die wirklich ausführliche Dokumentation und die zahlreichen Tutorials, die teilweise auch noch von Epic Mitarbeitern selbst gemacht werden.
Ich persönlich kann jedem Einsteiger die Unreal Engine nur wärmstens ans Herz legen und finde es daher immer etwas befremdlich, wenn Unity als die Einsteiger-Engine schlechthin dargestellt wird und auch an Hochschulen scheinbar alternativlos ist.
Während des Gesprächs kam auch der Aspekt auf, dass Unity ja eher die Engine für Einsteiger sei und dass Unreal besser für erfahrenere Entwickler geeignet sei. Das hört man in der Entwickler-Szene ständig und vielleicht kann mir Wolfgang erklären, warum das weiterhin so ist?
Ich habe beide Engines ausprobiert und viele Jahre Erfahrung mit der Unreal Engine 4, gerade weil ich sie als Einsteiger deutlich intuitiver und leicht zu erlernen eingeschätzt habe. An der Meinung hat sich bis heute nichts geändert. Die Unreal Engine versorgt Einsteiger direkt beim Start der Engine mit Templates für bekannte Spiele-Arten und zahlreichen Beispiel Projekten, die man sich anschauen und von denen man lernen kann. Außerdem muss man keine Programmiersprache wie c# lernen, sondern kann die visuelle Skriptsprache Blueprints in wenigen Monaten lernen. Dazu dann noch die Menge an kostenlosen Assets, die wirklich ausführliche Dokumentation und die zahlreichen Tutorials, die teilweise auch noch von Epic Mitarbeitern selbst gemacht werden.
Ich persönlich kann jedem Einsteiger die Unreal Engine nur wärmstens ans Herz legen und finde es daher immer etwas befremdlich, wenn Unity als die Einsteiger-Engine schlechthin dargestellt wird und auch an Hochschulen scheinbar alternativlos ist.
- philoponus
- Beiträge: 2550
- Registriert: 4. Apr 2017, 18:18
- Kontaktdaten:
Re: Walkthrough: Engine Irrtümer
Sehr gut. Das Thema war ja ein ganz früher Walkthrough-Wunsch von mir.
Geduld zahlt sich also aus
Geduld zahlt sich also aus
- Pan Sartre
- Beiträge: 271
- Registriert: 1. Aug 2017, 22:19
- Kontaktdaten:
Re: Walkthrough: Engine Irrtümer
Ich habe schon oft gelesen, die Bedienung von Unreal sei einfacher und gutaussehende Ergebnisse sind dank der mitgelieferten Templates schneller zu erzielen. Dennoch wird wohl oft zu bedenken gegeben, dass das Lizenz-Modell gerade für kleinere Entwickler hinten heraus nicht so vorteilhaft ist. Es ist für mich daher schon schlüssig, vorrangig in Unity zu lehren und für sein Erstlingswerk (mit unvorhersehbarem Erfolg) auch auf Unity auszulegen.
Re: Walkthrough: Engine Irrtümer
Für kleine bis mittelgroße Entwickler würde ich dir da definitv zustimmen. Das ganze Modell läuft ja nach dem Motto "Wir profitieren, wenn du Erfolg hast". Unreal selbst kostet erstmal gar nichts, bis man ein fertiges Produkt auf den Markt bringt. Nach den ersten verkauften 5000$ nimmt Epic dann circa 5% von den Bruttoeinnahmen, wenn ich es richtig im Kopf habe. Ich sehe auch definitv den Punkt, dass die 5% in der Realität viel mehr sind, als man erstmal annimmt.
Trotzdem finde ich gerade deshalb, dass sich die Engine noch besser für Einsteiger eignet. Wenn man sich gerade in die erste Engine einarbeitet ist ein fertiges Spiel extrem unwahrscheinlich, geschweige denn eins, das mehr als 5000$ einnimmt. Wenn man mit Unity anfängt und nicht gerade die optisch grausame kostenlose Version benutzen will, fängt man sofort an zu zahlen, egal ob das Spiel je auf den Markt kommen wird oder nicht. Und so traurig es auch ist, aber die meißten Spieleprojekte sehen niemals das Licht der Welt. Von daher halte ich es eigentlich für recht klug, mit Unreal erstmal ohne Bedenken und Zeitdruck Erfahrung zu sammeln. Später kann man immer noch auf Unity umsteigen. Von Unreal auf Unity umzusteigen ist um ein Vielfaches einfacher, als andersherum.
Trotzdem finde ich gerade deshalb, dass sich die Engine noch besser für Einsteiger eignet. Wenn man sich gerade in die erste Engine einarbeitet ist ein fertiges Spiel extrem unwahrscheinlich, geschweige denn eins, das mehr als 5000$ einnimmt. Wenn man mit Unity anfängt und nicht gerade die optisch grausame kostenlose Version benutzen will, fängt man sofort an zu zahlen, egal ob das Spiel je auf den Markt kommen wird oder nicht. Und so traurig es auch ist, aber die meißten Spieleprojekte sehen niemals das Licht der Welt. Von daher halte ich es eigentlich für recht klug, mit Unreal erstmal ohne Bedenken und Zeitdruck Erfahrung zu sammeln. Später kann man immer noch auf Unity umsteigen. Von Unreal auf Unity umzusteigen ist um ein Vielfaches einfacher, als andersherum.
Re: Walkthrough: Engine Irrtümer
Unity ist in der Bezahlversion aktuell auch einfach nur "Dark". Optisch aendert sich da bis auf die Farbe erstmal gar nix.
Auf der juengsten Unite wurde aber nen "komplett" ueberarbeitetes UI angekuendigt. Bin mal gespannt.
Auf der juengsten Unite wurde aber nen "komplett" ueberarbeitetes UI angekuendigt. Bin mal gespannt.
Fuck Tapatalk
Re: Walkthrough: Engine Irrtümer
Extrem interessante Folge! Danke dafür
Re: Walkthrough: Engine Irrtümer
Ich fand die Folge leider sehr schwach. Ich hatte erwartet das eine Folge die Jochen im Podcast vollmundig mit den Mythbusters vergleicht weniger oberflächlich bleibt und die Mythen und Behauptungen durch Bezug auf Belege und Fakten entkräftet. Leider blieb es über weite Strecken dabei, dass Behauptungen (die zitierten Engine-Mythen) durch alternative Behauptungen ersetzt wurden und viel zu wenig tatsächlich technisch begründet oder auf andere Weise belegt wurde.
Das beginnt leider schon bei der Vorstellung des Gastredners, Moritz Voss, dessen angebliche Expertise im Bereich Spiele-Engines nicht belegt wird. Es wäre hilfreich, wenn die Credentials eines Experten etwas mehr beleuchtet würden anstatt nur den Namen und einen seiner Arbeitgeber (King) zu nennen und dann anschließend zu behaupten er wäre "Der Experte für Spiele-Engines".
Ich habe mich zum Beispiel gefragt wie man als Mitarbeiter bei King Digital Entertainment - die ja überwiegend Match-3 Handyspiele machen - zum Experten für Unreal, Unity und Cryengine werden kann, wenn Candy Crush, Bubblewitch Saga und Co. jetzt nicht für ihre ausladenden AAA 3D Welten bekannt sind.
Da wäre es schön gewesen wenn man einige seiner Projekte als Referenz aufgeführt hätte und etwas mehr Zeit investiert hätte um zu erklären, warum er denn jetzt tatsächlich der Experte für Engines ist und womit er sich in seiner Rolle als Technical Lead so rumschlagen muss. Ich musste am Ende sein Profil auf LinkedIn studieren um ein Gefühl dafür zu bekommen was er jetzt tatsächlich kann und habe mich da während des Podcasts drauf verlassen das Wolfgang schon keinen Schlangenölverkäufer einladen wird.
Diese Oberflächlichkeit zieht sich dann leider durch die ganze Folge. Ein Beispiel aus dem Kapitel "Baut endlich ‘ne neue Engine!". Jochen stellt die einleitende Frage, Moritz stellt die These auf "beim Wechsel der Engine muss man alle Assets neu bauen, deshalb sollte man neue Engines in wenig risikoreichen und kleineren Projekten beta-testen und einführen" (sinngemäß). Eine Begründung warum dass so ist bleibt uns die folgende Diskussion dann weitestgehend schuldig.
Ein anderes Beispiel. "Bei Mass Effect: Andromeda kann man sehen, dass das Team die neue Engine noch nicht im Griff hatte". (sinng.) Warum bleibt offen. Mass Effect: Andromeda war nicht das erste Bioware Spiel das Frostbyte 3 verwendet hat, dass war Dragon Age: Inquisition. Alleine schon deshalb sollte eine solche Behauptung in irgendeiner Weise begründet werden. Wenn das so offensichtlich ist, dann sollte es ja leicht sein diese Offensichtlichkeiten im Podcast mit Belegen zu untermauern.
Besonders irritiert hat mich die Tatsache, weil Jochen das Thema "neue Engine" bei Assassins Creed: Unity noch einmal angesprochen hat und Moritz dort aber keine Aussage treffen wollte ob die technischen Probleme die AC: Unity hatte mit dem Lernprozess und der fehlenden Erfahrung bei der Arbeit mit einer neuen Engine erklärbar wären. Obwohl AC: Unity tatsächlich das erste Spiel war für das Ubisoft AnvilNext 2.0 eingesetzt hat
Mir fallen leider noch einige weitere ähnliche unbelegte/schwach belegte Behauptungen in dieser Folge ein, die ich jetzt aber nicht auch noch einzeln aufführen will.
Insgesamt hat mich die Folge sehr enttäuscht und stellenweise auch ganz schön verärgert.
Ich hatte das Gefühl ihr wollt so viele Mythen auf einmal aufklären, dass euch im angedachten Zeitrahmen keine Möglichkeit mehr geblieben ist jeden einzelnen der Punkte entsprechend ausführlich zu beleuchten. Dazu blieb Wolfgang über weite Strecken auch noch weitestgehend ohne Wortmeldung
Das beginnt leider schon bei der Vorstellung des Gastredners, Moritz Voss, dessen angebliche Expertise im Bereich Spiele-Engines nicht belegt wird. Es wäre hilfreich, wenn die Credentials eines Experten etwas mehr beleuchtet würden anstatt nur den Namen und einen seiner Arbeitgeber (King) zu nennen und dann anschließend zu behaupten er wäre "Der Experte für Spiele-Engines".
Ich habe mich zum Beispiel gefragt wie man als Mitarbeiter bei King Digital Entertainment - die ja überwiegend Match-3 Handyspiele machen - zum Experten für Unreal, Unity und Cryengine werden kann, wenn Candy Crush, Bubblewitch Saga und Co. jetzt nicht für ihre ausladenden AAA 3D Welten bekannt sind.
Da wäre es schön gewesen wenn man einige seiner Projekte als Referenz aufgeführt hätte und etwas mehr Zeit investiert hätte um zu erklären, warum er denn jetzt tatsächlich der Experte für Engines ist und womit er sich in seiner Rolle als Technical Lead so rumschlagen muss. Ich musste am Ende sein Profil auf LinkedIn studieren um ein Gefühl dafür zu bekommen was er jetzt tatsächlich kann und habe mich da während des Podcasts drauf verlassen das Wolfgang schon keinen Schlangenölverkäufer einladen wird.
Diese Oberflächlichkeit zieht sich dann leider durch die ganze Folge. Ein Beispiel aus dem Kapitel "Baut endlich ‘ne neue Engine!". Jochen stellt die einleitende Frage, Moritz stellt die These auf "beim Wechsel der Engine muss man alle Assets neu bauen, deshalb sollte man neue Engines in wenig risikoreichen und kleineren Projekten beta-testen und einführen" (sinngemäß). Eine Begründung warum dass so ist bleibt uns die folgende Diskussion dann weitestgehend schuldig.
Ein anderes Beispiel. "Bei Mass Effect: Andromeda kann man sehen, dass das Team die neue Engine noch nicht im Griff hatte". (sinng.) Warum bleibt offen. Mass Effect: Andromeda war nicht das erste Bioware Spiel das Frostbyte 3 verwendet hat, dass war Dragon Age: Inquisition. Alleine schon deshalb sollte eine solche Behauptung in irgendeiner Weise begründet werden. Wenn das so offensichtlich ist, dann sollte es ja leicht sein diese Offensichtlichkeiten im Podcast mit Belegen zu untermauern.
Besonders irritiert hat mich die Tatsache, weil Jochen das Thema "neue Engine" bei Assassins Creed: Unity noch einmal angesprochen hat und Moritz dort aber keine Aussage treffen wollte ob die technischen Probleme die AC: Unity hatte mit dem Lernprozess und der fehlenden Erfahrung bei der Arbeit mit einer neuen Engine erklärbar wären. Obwohl AC: Unity tatsächlich das erste Spiel war für das Ubisoft AnvilNext 2.0 eingesetzt hat
Mir fallen leider noch einige weitere ähnliche unbelegte/schwach belegte Behauptungen in dieser Folge ein, die ich jetzt aber nicht auch noch einzeln aufführen will.
Insgesamt hat mich die Folge sehr enttäuscht und stellenweise auch ganz schön verärgert.
Ich hatte das Gefühl ihr wollt so viele Mythen auf einmal aufklären, dass euch im angedachten Zeitrahmen keine Möglichkeit mehr geblieben ist jeden einzelnen der Punkte entsprechend ausführlich zu beleuchten. Dazu blieb Wolfgang über weite Strecken auch noch weitestgehend ohne Wortmeldung
Re: Walkthrough: Engine Irrtümer
Ich hatte das Gefühl, es ging nicht darum, Thesen und Behauptungen aufzustellen, sondern darum, dass Moritz aus seinem Erfahrungsschatz berichtet. Also über generelle strukturelle Probleme, die mit Engines und Engine-Wechsel dahergekommen, und in vielen Projekten anzutreffen sind, ob nun bei AAA oder Mobile-Titeln. Was im Detail bei ME Andromeda schiefgelaufen ist, wird nur jemand sagen können, der tatsächlich am Projekt mitgearbeitet hat.Numfuddle hat geschrieben: ↑18. Jul 2018, 22:51 Ein anderes Beispiel. "Bei Mass Effect: Andromeda kann man sehen, dass das Team die neue Engine noch nicht im Griff hatte". (sinng.) Warum bleibt offen. Mass Effect: Andromeda war nicht das erste Bioware Spiel das Frostbyte 3 verwendet hat, dass war Dragon Age: Inquisition. Alleine schon deshalb sollte eine solche Behauptung in irgendeiner Weise begründet werden. Wenn das so offensichtlich ist, dann sollte es ja leicht sein diese Offensichtlichkeiten im Podcast mit Belegen zu untermauern.
Falls es dich tiefergehend interessiert, was Animatoren aus der Industrie über ME Andromeda denken, kann ich dir diesen Artikel empfehlen:
http://www.animstate.com/round-table-ma ... andromeda/
Auch die Leute, die sich hier unterhalten, können aber nur mutmaßen, denn auch sie waren nicht dabei. Das sind halt "educated guesses", die aus langjähriger Berufserfahrung kommen, und daher, dass viele Teams den gleichen strukturellen Problemen begegnen.
- philoponus
- Beiträge: 2550
- Registriert: 4. Apr 2017, 18:18
- Kontaktdaten:
Re: Walkthrough: Engine Irrtümer
In der neuen c't ist ein zweiseitiger Artikel darüber, wie Unity durch das Auswerten von Spielerdaten sein Geld verdient.