Unitys neue Preispolitik: Ein Warnsignal für die Bedeutung von Open Source in der Spieleentwicklung
(archive.md)- Unity stellt sein Preismodell von einer Abrechnung pro Sitzplatz auf Abrechnung pro Installation (pay per install) um und berechnet nicht nur kostenpflichtige Installationen, sondern alle regulären Installationen
- In einem mobilen Umfeld, in dem der durchschnittliche Umsatz pro Werbeeinblendung 0,02 $ beträgt, verlangt Unity nach einem Jahresumsatz von 200.000 $ 0,20 $ pro Installation, sodass pro Nutzer mindestens 10 Werbeeinblendungen nötig sind
- Diese Änderung gilt rückwirkend auch für bestehende Anwendungen und belastet damit auch bereits veröffentlichte Spiele
- Spiele durchlaufen eine lange Entwicklung über Monate bis Jahre, weshalb ein Wechsel auf eine andere Engine äußerst schwierig ist; anders als der Wechsel eines Dokumenteneditors kann das existenzbedrohend sein
- Open-Source-Engines auf Basis der MIT-Lizenz garantieren Rechte, die nicht entzogen oder geändert werden können, und schützen Entwickler vor künftigen Preis- und Richtlinienänderungen
Unitys Änderung der Preispolitik und ihre Folgen
- Unity stellt sein Preismodell von Abrechnung pro Sitzplatz (pay per seat) auf Abrechnung pro Installation (pay per install) um; dies ist nicht auf kostenpflichtige Installationen oder Spielvorgänge beschränkt, sondern gilt für alle regulären Installationen
- Besonders schwerwiegende Folgen hat das im mobilen Umfeld, wo der Umsatz pro Installation stark schwankt
- Laut Unity-Tochter Ironsource liegt der durchschnittliche Umsatz pro Werbeeinblendung bei 0,02 $
- Unity beabsichtigt, 0,20 $ pro Installation zu berechnen, nachdem eine App in den vergangenen 12 Monaten 200.000 $ eingenommen hat
- In der Folge müsste jeder Nutzer nach der Installation der App mindestens 10 Werbeeinblendungen ansehen, damit keine Kostenverluste entstehen
- Das ist ein Durchschnittswert; bei Apps, die in Schwellenmärkten besonders beliebt sind, sind die Werbeerlöse niedriger, wodurch das Problem deutlich gravierender wird
- Dass diese Änderung rückwirkend auch für bestehende Anwendungen gilt, verschärft die Situation zusätzlich
Warum eine solche Politik möglich ist
- Als Vergleich: Würde Microsoft nach der Zahl der Personen abrechnen, die ein mit Word erstelltes Dokument lesen, könnten Nutzer einfach zu Google Docs wechseln
- Der Wechsel eines Dokumenteneditors ist nur unbequem, aber nicht existenzbedrohend
- Spieleentwicklung ist ein langer und komplexer Prozess, der Monate bis Jahre dauert; nach Abschluss der Arbeit ist ein Umstieg auf eine andere Engine nicht einfach
- Er kostet erhebliche Zeit und Geld
- Selbst wenn eine Migration möglich ist, könnte das Entwicklungsteam zu diesem Zeitpunkt bereits aufgelöst sein
Der Schutz durch Open Source
- Open-Source-Game-Engines wie die Godot engine gewähren ein Nutzungsrecht an der Engine, das nicht entzogen oder geändert werden kann, und schützen so die Arbeit
- Unter Godots MIT-Lizenz erhalten alle Nutzer das Recht zur freien Nutzung, Änderung und Verbreitung
- Die einzige Bedingung ist, die ursprünglichen Urheber zu nennen und die Engine nicht als eigenes Werk auszugeben
- Dies gilt nur für die Engine; das Spiel selbst gehört dem Entwickler
Warum ein Wechsel zur Unreal engine keine Lösung ist
- Die Unreal engine hat derzeit keine Unity-ähnlichen Bedingungen, doch es gibt keinen Mechanismus, der sie daran hindert, künftig ähnliche Regeln einzuführen
- Wenn Unity diese Änderung durchsetzt, besteht die Möglichkeit, dass Unreal nachzieht
Die Rolle von Ramatak
- Ramatak mobile studio ergänzt die Open-Source-Godot-engine um für Mobile Games unverzichtbare Funktionen wie Werbung, In-App-Käufe und Analytics
- Ramatak erhebt Gebühren für diesen Dienst, doch wenn die Bedingungen unbequem werden, können Nutzer ihr Spiel mitnehmen und auf die Open-Source-Version wechseln
- Sie verlieren den Zugriff auf Ramatak-spezifische Funktionen, aber das Spiel bleibt vollständig im Besitz des Entwicklers
- Der erste Beitrag der Website behandelt die Beziehung zu den Nutzern
- Weil der Wechsel zur Open-Source-Version sehr einfach ist, muss zwingend der Wert geboten werden, den Nutzer erwarten
Fazit
- Das Umfeld für Mobile Games verändert sich ständig, und es ist unmöglich vorherzusagen, was der nächste „große Trend“ sein wird
- Bei Nutzung einer Open-Source-Engine blockiert die Engine die Nutzung nicht, egal welches „nächste Ding“ kommt, und erzwingt keine Monetarisierungsstrategie
- Mit Ramatak mobile studio erhält man sowohl die Freiheit und Stabilität einer Open-Source-Engine als auch die fortgeschrittenen, maßgeschneiderten Funktionen, die moderne Mobile Games benötigen
- Vor allem können die Bedingungen nicht einseitig geändert werden
1 Kommentare
Hacker-News-Kommentare
Die Argumentation, dass Epic und die Unreal Engine etwas Ähnliches wie Unity tun würden, überzeugt mich nicht wirklich.
Epic betreibt einen eigenen Game Store und ist ein Unternehmen, das Entwickler mit einer großzügigen Umsatzbeteiligung aktiv anzieht; dafür müsste man annehmen, dass es für zweifelhafte Umsatzsteigerungen die Beziehung zu Entwicklern kappt.
Dass Unity diesen Weg gewählt hat, lag wohl daran, dass man nicht so wirken wollte, als würde man das früher gegebene Versprechen von keiner Umsatzbeteiligung/keinen Royalties öffentlich brechen; ironischerweise scheint daraus ein noch schlechteres Abrechnungsmodell entstanden zu sein.
Letztlich ist Unity nach dem Börsengang in einem Umfeld, in dem es nach Wachstum bewertet wird, zu groß geworden, und der Kern dieser Sache scheint zu sein, dass Personalbestand und Kosten überzogen sind. Dass Epic und Valve nicht börsennotiert sind, Unity aber schon, sagt viel aus.
Ganz stimmt das nicht. Unity hat mit ironSource fusioniert, einem Unternehmen für Mobile Advertising, und konkurriert direkt mit AppLovin, einem Schwergewicht in diesem Markt.
Die Konditionen und Hinterzimmerdeals, die Unity Entwicklern anbietet, laufen darauf hinaus, diese Gebühr zu erlassen, wenn sie statt AppLovin die Werbeprodukte von Unity verwenden. Das wirkt wie ein Versuch, die Stellung im Markt für Game Engines zu nutzen, um die Position im Mobile-Advertising-Markt auszubauen.
Ich sehe das nicht als Problem der Unternehmensstruktur, sondern als Managementversagen. Hätte man auf Nutzer, interne Entwickler oder irgendjemanden mit auch nur etwas Realitätssinn gehört, wäre das nicht passiert.
Aber wenn man einen früheren EA-CEO holt, der keine Low-Level-Erfahrung in der Branche hat und seinen vorherigen Job wegen schwacher finanzieller Ergebnisse verlassen hat, wirkt eine solche Katastrophe fast unvermeidlich.
Das lässt einen viel über den Unterschied zwischen privaten und börsennotierten Unternehmen nachdenken. Die meisten Produkte, die ich mag, stammen von privaten Unternehmen, und in den Anreizen börsennotierter Unternehmen steckt etwas, das schlechte Entscheidungen begünstigt.
Im Grunde gibt es zwei Einnahmequellen: den Verkauf von Produkten/Services und den Verkauf von Aktien, und diese beiden geraten oft auf eine Weise in Konflikt, die Kunden schadet. Bei privaten Unternehmen ist die Loyalität gegenüber den Kunden direkter; das Produkt muss gut sein, damit das Unternehmen bestehen kann.
Das heißt nicht, dass es keine börsennotierten Unternehmen geben sollte, aber es braucht eine Struktur, bei der die Anreize des Unternehmens nicht gegen die tatsächlich zahlenden Kunden laufen. Im Moment scheint ein stärkerer Fokus auf Revenue Sharing und Dividenden statt auf den Aktienkurs ein möglicher Weg zu sein.
Die Frage ist nicht: „Würde Epic das morgen tun?“, sondern: „Würde Epic das irgendwann in absehbarer Zukunft tun?“
Das Epic-Management könnte sich in Erwartung größerer Summen für einen IPO entscheiden, das Unternehmen könnte an einen vermögenden Milliardär wie Musk verkauft werden, oder ein neues Führungsteam könnte eine solche Entscheidung aus „ernsthaften geschäftlichen Gründen“ durchsetzen.
Wenn man ein Spiel mit Unreal entwickelt, setzt man den künftigen kommerziellen Erfolg letztlich darauf, dass ein gewinnorientiertes Unternehmen „weniger bösartig bleibt als die Alternative“. Die Wahl der Engine ist jetzt nicht mehr nur eine Frage von Features, Entwicklerzahl und aktueller Preisstruktur, sondern auch die Sorge, ob irgendwann rückwirkend die Preisstruktur geändert und das eigene Unternehmen ruiniert wird.
Baut man dagegen mit Godot oder einer eigenen Engine, muss man sich darüber keine Sorgen machen. Wenn die Spielebranche und die Öffentlichkeit Unity jetzt ein ausreichend starkes Signal senden, wird es auch für andere Unternehmen künftig deutlich unwahrscheinlicher, so etwas zu versuchen.
In der Unreal-Lizenz gibt es starke Belege für dieses Argument.
„7. The Agreement Between You and Epic
a. Amendments
If we make changes to this Agreement, you are not required to accept the amended Agreement, and this Agreement will continue to govern your use of any Licensed Technology you already have access to.
However, if we make changes to this Agreement, you will not be allowed to access certain Epic services or download the Licensed Technology unless you have accepted the amended Agreement. If we make changes, we will provide you with notice, such as by sending an email or giving you notice when you next log into an Epic service.”
Das heißt: Selbst wenn es zu einem Lockangebot mit anschließender Änderung der Bedingungen kommt, kann man bereits zugängliche ältere Engine-Versionen weiterhin unter der bisherigen Lizenz verwenden. In einer Zeit, in der fast alle Endbenutzerlizenzen ungefähr auf „wir können jederzeit alles tun und du kannst gar nichts tun“ hinauslaufen, wirkt die Aufnahme einer solchen Klausel wie ein erheblicher Vertrauensbeweis.
https://www.unrealengine.com/en-US/eula/unreal
Das sollte auch für alle, die insgesamt auf Closed-Source-Tools setzen, ein Warnsignal sein: DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle usw.
Manche davon sind erstklassige Tools, aber sie sind nur geliehene Zeit, bis der Eigentümer die Bedingungen ändert, das Angebot einstellt oder die Preise so weit erhöht, dass es dem Geschäft schadet.
Closed-Source-Softwaretools sind Schulden, und der Nutzen ist im Verhältnis zum Risiko oft gering. Ich habe in mehreren Teams Projekte gesehen, in die Dutzende Personenjahre geflossen waren und die wegen eingestelltem Support oder überzogener Preiserhöhungen verworfen wurden.
Ich bin kein Purist und nutze daher Dinge wie JetBrains. Denn wenn nötig, kann man ohne Schaden fürs Geschäft leicht auf Open-Source-Tools umsteigen. Es geht nicht darum, eigene Tools zu bauen, sondern hervorragende Open-Source-Tools wie PostgreSQL, Apache, Linux, MariaDB, Open-Source-Sprachen, Redis oder CouchDB zu verwenden.
Bei Unity sind die Kosten eines Engine-Wechsels viel höher. Für die meisten, die ihr Spiel bereits fertiggestellt haben, ist ein Wechsel zu Godot oder Unreal realistisch kaum überhaupt in Betracht zu ziehen; genau deshalb ist diese Sache besonders gravierend.
Intern entwickelte Software führt dagegen oft dazu, dass neue Teammitglieder am Ende Code neu schreiben, den frühere Mitarbeitende hinterlassen haben. Es ist seltsam, wegen einer geringen Möglichkeit, dass sich Closed Source ändert, von dessen Nutzung abzuraten, aber als Alternative interne Software zu wählen, bei der künftige Wartungsprobleme nahezu garantiert sind.
Man sollte mit vertrauenswürdigen Anbietern arbeiten, Abhängigkeiten prüfen, das akzeptable Risikoniveau festlegen und die verwendeten Lizenzen sorgfältig ansehen. Das gilt besonders, wenn es für ein Spieleunternehmen um etwas so Zentrales wie eine Game-Engine geht.
Hinter allen dreien stehen Unternehmen, es gibt Vertrieb oder Einschränkungen, und diese Einschränkungen zielen meist auf Cloud-Anbieter, nicht auf Self-Hosting. Nach aktuellem Versionsstand halte ich alle drei für offen genug, dass das Risiko von Vendor-Lock-in nicht groß ist.
Die Unity-Preispolitik ist insofern rückwirkend, als sie sogar Installationszahlen alter, bereits veröffentlichter Spiele erfassen will. Das ist ähnlich, als würde SQL Server auf eine GB-basierte Abrechnung umstellen und sagen, das gelte für alle Versionen seit 2005; eine solche rückwirkende Änderung würden selbst Regierungen ablehnen.
Die eigentliche Frage ist jetzt, ob ein vernünftiger Mensch künftig noch ein Spiel mit Unity entwickeln würde.
Kurzfristig mögen die Gewinne steigen, aber bald wird die Neuentwicklung von Unity-Spielen versiegen. Denn selbst wenn man die jetzigen Bedingungen akzeptiert, weiß man nun, dass Unity jederzeit die Regeln ändern und Kosten auf die Nutzer abwälzen kann.
Unity ist für Spielefirmen zu einem existenzbedrohenden Haftungsrisiko geworden, und ich frage mich, wer sich noch in die Nähe trauen würde. Ich erwarte, dass das Management bald von den Aktionären hinausgeworfen wird.
Ob das Management so schnell hinausgeworfen wird, ist schwer zu sagen. Auf Unity wurde zu viel aufgebaut.
Die gängigste Interpretation ist, dass Unity versucht, Geld aus Genshin Impact herauszupressen, aber es gibt auch viele erfolgreiche Spiele wie Among Us oder Untitled Goose Game, die sich nicht einfach auf eine andere Engine portieren lassen.
Mit anderen Worten: Unity will zum IBM der Game-Engines werden, zu einem Unternehmen, das mit minderwertigem Service Rent-Seeking betreibt.
https://www.sportskeeda.com/esports/will-genshin-impact-affe...
https://www.create-learn.us/blog/top-games-made-with-unity/
Es ist die Art von „nach mir und nach dir“-Denken.
Die guten Zahlen erscheinen rechtzeitig zur Bonusberechnung, und die schlechten Zahlen werden erst sichtbar, wenn die Entscheidungsträger schon zu anderen Unternehmen gewechselt sind. So oder so werden sie als diejenigen verkauft werden, die Unitys Profitabilität verdoppelt haben, also dürften sie viele Optionen haben.
Bedauerlich ist, dass Unity in den letzten zehn Jahren in gewissem Maß zum Zuwachs bei Linux-Spielen beigetragen hat.
In Unity war Linux-Support im Vergleich zu vielen anderen Engines fast kostenlos, und wenn es weniger Unity-Spiele gibt, wird es wahrscheinlich auch weniger Linux-Spiele geben.
Das wird auch für Vision Pro ein Problem werden. Es ist etwas überraschend, dass Apple nicht eingeschritten ist und gesagt hat, dass dies nicht für Vision-Pro-Apps gilt.
Zumindest in meiner begrenzten Zeit im Unternehmensleben war es sehr selten, dass das Management böser war als der Vorstand. Besonders bei börsennotierten, gewinnorientierten Unternehmen ist das so, und noch seltener ist es, dass der Vorstand vor der Ankündigung nicht mit dem Management darüber gesprochen hätte.
Unity tut mir irgendwie auch ein bisschen leid. Das Unternehmen steht finanziell schlecht da, verbrennt jährlich fast 1 Milliarde Dollar und hat keine klare Lösung
Entweder es erhöht die Preise und verärgert die Kunden, oder es senkt die Kosten – wie schon durch die massiven Entlassungen – und riskiert, von anderen Game Engines wie Unreal verdrängt zu werden
Was das Unternehmen über Jahre im Grunde getragen hat, war seine Bewertung. Solange Investoren Wachstum und künftige Gewinne finanzierten, konnte Unity die Verluste ausgleichen; aber jetzt, da das Wachstum langsamer wird und Investoren beim Thema Wachstum weniger großzügig sind, weiß ich nicht, was Unity noch tun kann
Kein Burggraben, verlangsamtes Wachstum und hoher Cash-Burn. Wenn sich das makroökonomische Umfeld nicht zu seinen Gunsten ändert, ist schwer zu sehen, wie Unity da herauskommen und an der Spitze bleiben soll
Hätte Unity seine Kernkunden, Indie-Entwickler, vor allem mit einem kleinen Team und einem einfachen Produkt unterstützt, hätte das nachhaltig und profitabel sein können. Stattdessen wirkte es, als wollten sie sich mit Gewalt in den AAA-Markt drängen
Dieser Aufruhr ist das Ergebnis eines wirklich schlecht angekündigten Modells, von Details, die nicht sauber ausgearbeitet waren und Entwickler Missbrauch aussetzen, sowie einer eng verbundenen Creator-Community, die bereits Erfahrungen mit Missbrauch durch Piraterie, Review-Bombing, Rückerstattungswellen usw. gemacht hat und beinahe wie ein einziger Körper reagierte
Die meisten Entwickler hätten eine Umsatzbeteiligung wohl akzeptiert, auch wenn sie gemurrt hätten. Auch große Studios wie Nintendo und Microsoft haben Unity genutzt; schwer zu verstehen, ob Unity wirklich dachte, sie würden Gebühren auf rückwirkende Verkaufs- und Umsatzzahlen einfach problemlos hinnehmen
Bei einem Marktanteil von etwa 30 % würde es schon reichen, weniger als 2 % des mit den Tools geschaffenen Werts abzuschöpfen, um den Break-even zu erreichen. Wenn das nicht gelingt oder man Technologie für Bereiche bereitstellt, die unterdurchschnittlich profitabel sind, muss man den Fokus ändern oder die Kosten senken
Wenn ein Unternehmen nicht mehr Wert abschöpfen kann, als es verbraucht, ist es ganz natürlich, dass es scheitert
Niemand hat Riccitiello gezwungen, aufs Gaspedal zu treten, und niemand hat ihn gezwungen, vor der katastrophalen Ankündigung Aktien zu verkaufen und sich selbst zu bereichern. Das hat er selbst getan
Viel mehr Mitleid habe ich mit den Tausenden Entwicklern, denen diese furchtbare Politik metaphorisch die Pistole an den Kopf gesetzt hat, und die jetzt über einen Engine-Wechsel nachdenken müssen
Ich mag Open Source und die Godot Engine, aber dieser Fall wirkt eher wie ein Warnsignal, dass Unternehmen Verträge nicht einseitig und rückwirkend ändern dürfen sollten, um neue Kosten aufzuerlegen und bestehende vertragliche Zusagen zu brechen
Wenn so etwas möglich ist, bietet auch Open Source praktisch keinen großen Schutz
Der HashiCorp-Fall ist ein gutes Beispiel. Terraform wurde geforkt und läuft weiter wie gewohnt, die Nutzer sind nicht betroffen
Bei Programmierplattformen wie Game Engines ist dieser Vorteil noch größer. Etwas wie Terraform ließe sich, wenn die Tests gut sind, vielleicht in ein paar Wochen neu schreiben; bei einem Spiel ist das unmöglich
Die Rechte unter der MIT-Lizenz kann einem niemand wegnehmen, und es gibt auch keinen rechtlichen Mechanismus dafür. Davor ist man vollständig geschützt
Manche Open-Source-Lizenzen sind leicht einzuhalten und geschäftsfreundlich, was helfen kann. Umgekehrt würden die Game Studios, die sich jetzt beschweren, wohl heftig reagieren, wenn sie zur Einhaltung der GPL gezwungen würden und ihren Source Code offenlegen müssten
Selbst bei permissiven Open-Source-Lizenzen bleibt das Risiko, dass künftige Releases unter eine unerwünschte Lizenz gestellt werden, wie HashiCorp es bei Terraform und anderen getan hat, und man dadurch von notwendigen Updates und Fixes abgeschnitten wird. Die Community kann einen Fork pflegen – oder auch nicht
Wenn dieser Fall legal ist, dann vermutlich wegen Endnutzer-Lizenzregeln; ob er legal ist, möchte ich nicht leichtfertig vorhersagen
Nutzungsbedingungen sind oft nicht einmal das Toilettenpapier wert, auf das man sie drucken könnte; aber ich frage mich, ob Bestandskunden, die seit 2019 abonniert haben, jetzt wegen Vertragsbruchs und Kosten für Neuentwicklung klagen könnten
Mir ist das mit Steam passiert. Auf einem alten Laptop hatte ich alte Spiele wie Half-Life; eines Tages startete ich ihn, Steam aktualisierte sich und ging kaputt, und weil das alte System nicht mehr unterstützt wurde, liefen auch die Spiele nicht mehr
Das heißt nicht, dass Open Source zwingend nötig ist, aber man muss Software besitzen, nicht nur ausleihen
Unreal hat derzeit keine Bedingungen wie Unity, aber die Behauptung, es gebe nichts, was sie daran hindern würde, Ähnliches zu tun, und dass sie es wahrscheinlich nachmachen würden, sobald Unity damit durchkommt, ist nicht ausreichend belegt.
Bei Unreal gibt es Bedingungen, nach denen man eine bestimmte Version der Engine für immer verwenden kann und Epic diese Lizenz nicht widerrufen kann. Für neue Versionen stimmt es, dass Epic die Bedingungen ändern kann.
Tim Sweeney hat das ebenfalls oft ausdrücklich klargestellt, und wenn man sich die Bestrebungen ansieht, die Monopole von Google Play/Apple aufzubrechen, wirkt das Management von Epic Games anders als solche Unternehmens-Piranhas wie Unity.
Allerdings ist es auch zu simpel, bei Godot zu sagen: „Es ist Open Source, also kein Problem.“ Was ist, wenn die Entwickler den Support einstellen? Die Aussage „Die Community wird weiter daran arbeiten“ läuft in der Realität oft darauf hinaus, dass man sich auf ein oder zwei Personen verlässt, die die eigentliche Arbeit machen.
Wenn die Godot-Entwickler aufhören, steckt man in einem Projekt ohne Support fest und muss statt sich auf das Spiel zu konzentrieren die Engine-Entwicklung fortsetzen. Dasselbe gilt auch für das eigene Produkt des Autors.
Godot hatte in der vergangenen Woche 32 Personen, die 52 Commits eingebracht haben, und im vergangenen Monat 135 Beitragende. Das ist nicht das Niveau von „ein oder zwei Personen“.
Wenn ein Closed-Source-Unternehmen die Produktentwicklung einstellt, steckt man genauso fest; dann hat man aber keinen Zugriff auf den Source Code und kann es nicht selbst reparieren, steckt also noch schlimmer fest.
Selbst wenn die Godot-Entwicklung stoppt, bleibt die Version, die man hat, weiterhin erhalten. Was ist der Unterschied zwischen Epic, das die Arbeit an einer von einem Spiel genutzten Game Engine einstellt, und einem Open-Source-Projekt, das die Arbeit an einer von einem Spiel genutzten Game Engine einstellt? Bei Godot ist der Unterschied, dass man selbst daran arbeiten kann, wenn man möchte.
Unity scheint die Lizenz in einem Git-Repository vorgehalten zu haben, damit alle Lizenzänderungen leicht nachverfolgen konnten. Kurz vor der Lizenzänderung wurde dieses Repository entfernt und später wieder online gestellt; die Klausel, dass man alte Versionen ohne neue Einschränkungen für immer nutzen kann, fehlte jedoch.
Ich habe einem Freund, der Spieleentwickler und Unity-C#-Entwickler ist, ständig erzählt, er solle sich Bevy und Rust ansehen. Der Grund ist, dass das Typsystem von Rust wirklich hervorragend ist.
Codebeispiel: https://bevyengine.org/learn/book/getting-started/ecs/
Die Lizenz ist Apache 2.0 oder MIT.
Apache 2.0: https://github.com/bevyengine/bevy/blob/main/LICENSE-APACHE
MIT: https://github.com/bevyengine/bevy/blob/main/LICENSE-MIT
In den Kommentaren zum Ars-Artikel habe ich diesen Abschnitt aus der Unity-FAQ (https://unity.com/pricing-updates) gesehen, und er geht mir nicht aus dem Kopf:
“Will developers be charged the Unity Runtime Fee for subscription-based games?
No, in this case the developer is not distributing it so we’re not going to invoice the developer on subscription-based games (e.g. Apple Arcade, Xbox Game Pass, PlayStation Plus, Netflix Games, etc.)”
Ich kann nicht glauben, dass das Unity-Management glaubt, damit durchzukommen. Microsoft, Apple usw. dürften Verträge mit den Entwicklern abgeschlossen haben, die ihnen die gesamten Vertriebsrechte am Spiel unter einer bestimmten Gebührenstruktur sichern. Will Unity jetzt ernsthaft sagen: „Dieser Vertrag gibt euch nicht das Recht, den Teil zu vertreiben, der uns gehört. Zahlt auch uns“?
Selbst wenn das funktionieren sollte, könnten Microsoft oder Apple wohl rechtliche Ansprüche gegen den Entwickler geltend machen, der zugesichert hat, die Vertriebsrechte am gesamten Spiel zu übertragen.
Das Ganze wirkt wie ein riesiger Schnellschuss, und diese Frage-und-Antwort-Passage zu Abo-Spielen zeigt das Niveau des gesamten Plans. Es ist schwer zu verstehen, ob man ohne juristische Prüfung einer Laune des CEO gefolgt ist oder ob man absichtlich auf Klagen zusteuert.
Ich bin Bevy-Sponsor geworden. Ich will versuchen, unser Studio davon zu überzeugen, einen bestimmten Prozentsatz des Gewinns an Open-Source-Projekte zu spenden.
Egal wie gering die Chance ist, dass Bevy tatsächlich eine Mainstream-Engine wird: Es ist einen Versuch wert.
Unity war ein Traum oder eine Lüge, dass man Spiele auch ohne kompetentes Softwareteam entwickeln könne.
Jetzt macht der Originaltext Hoffnung auf einen weiteren Traum oder eine weitere Lüge: dass magische Open-Source-Feen einen auch ohne kompetentes Softwareteam weiter über Wasser halten würden. Aber so wird es nicht laufen.
Man muss Programmierer finden, ein Team aufbauen, ein Unternehmen schaffen, in dem dieses Team bestehen kann, und das Geschäftsmodell so anpassen, dass man sie bezahlen kann. Mit anderen Worten: Man muss die Preise erhöhen.
Spiele zu machen vielleicht. Gute Spiele eher nicht.