- Unity a changé son modèle tarifaire, passant d’une facturation par siège (pay per seat) à une facturation par installation (pay per install), en appliquant des frais non seulement aux installations payantes mais aussi à toutes les installations ordinaires
- Dans l’environnement mobile, où le revenu moyen par impression publicitaire est de 0,02 $, Unity prévoit de facturer 0,20 $ par installation après 200 000 $ de chiffre d’affaires annuel, ce qui impose à chaque utilisateur de regarder au minimum 10 publicités
- Ce changement est appliqué rétroactivement aux applications existantes, créant aussi une charge pour les jeux déjà sortis
- Le développement de jeux suit un processus long, sur plusieurs mois voire plusieurs années, et il est très difficile de basculer vers un autre moteur, contrairement au remplacement d’un éditeur de documents ; c’est un problème qui peut menacer la survie d’un projet
- Les moteurs open source sous licence MIT garantissent des droits irrévocables et non modifiables, protégeant les développeurs contre de futurs changements de prix ou de politique
Le changement de politique tarifaire de Unity et ses conséquences
- Unity a fait évoluer son modèle tarifaire d’une facturation par siège (pay per seat) à une facturation par installation (pay per install), qui ne se limite pas aux installations payantes ni au jeu lui-même, mais s’applique à toutes les installations ordinaires
- Les conséquences sont particulièrement graves sur mobile, où le revenu par installation varie fortement
- Selon la filiale de Unity, Ironsource, le revenu moyen par impression publicitaire est de 0,02 $
- Unity compte facturer 0,20 $ par installation une fois qu’une application a généré 200 000 $ sur les 12 derniers mois
- En conséquence, chaque utilisateur doit regarder au minimum 10 publicités après avoir installé l’application pour éviter une perte financière
- Il s’agit d’une moyenne, et le problème est bien plus grave pour les applications populaires sur les marchés émergents, où les revenus publicitaires sont plus faibles
- Le fait que ce changement soit appliqué rétroactivement aux applications existantes aggrave encore la situation
Pourquoi une telle politique est possible
- L’auteur compare cela à une situation où Microsoft facturerait Word selon le nombre de personnes qui lisent un document créé avec Word ; dans ce cas, l’utilisateur pourrait simplement passer à Google Docs
- Changer d’éditeur de documents est gênant, mais ne menace pas la survie d’une activité
- Le développement d’un jeu est un processus long et complexe, sur plusieurs mois ou plusieurs années, et migrer vers un autre moteur une fois le travail terminé n’est pas simple
- Cela demande beaucoup de temps et d’argent
- Et même si la migration est possible, l’équipe de développement peut déjà avoir été dissoute à ce moment-là
La protection apportée par l’open source
- Les moteurs de jeu open source comme Godot engine protègent le travail réalisé en accordant un droit d’usage du moteur qu’on ne peut ni retirer ni modifier
- Sous la licence MIT de Godot, tous les utilisateurs obtiennent le droit de l’utiliser, de le modifier et de le distribuer librement
- La seule condition est de créditer les auteurs d’origine et de ne pas revendiquer le moteur comme sa propre création
- Cela ne s’applique qu’au moteur ; le jeu lui-même reste la propriété du développeur
Pourquoi il ne faut pas simplement passer à Unreal engine
- Unreal engine n’a pas aujourd’hui de clauses comparables à celles de Unity, mais rien n’empêche l’introduction d’une politique similaire à l’avenir
- Si Unity parvient à imposer ce changement, Unreal pourrait suivre
Le rôle de Ramatak
- Ramatak mobile studio ajoute au moteur open source Godot des fonctions essentielles pour les jeux mobiles, comme la publicité, les achats intégrés et l’analytics
- Ramatak facture ce service, mais si ses conditions d’utilisation deviennent problématiques, les utilisateurs peuvent conserver leur jeu et basculer vers la version open source
- Ils perdent l’accès aux fonctions propres à Ramatak, mais le jeu reste entièrement la propriété du développeur
- Le premier article publié sur le site aborde cette relation avec les utilisateurs
- Comme le passage à la version open source est très simple, il est indispensable d’apporter une vraie valeur aux utilisateurs
Conclusion
- L’écosystème du jeu mobile évolue en permanence, et il est impossible de prédire quelle sera la prochaine « grande tendance »
- Avec un moteur open source, quel que soit ce « prochain changement », le moteur ne fera pas obstacle à son adoption et n’imposera pas de stratégie de monétisation
- Avec Ramatak mobile studio, on bénéficie à la fois de la liberté et de la stabilité d’un moteur open source, ainsi que de fonctions avancées adaptées aux jeux mobiles modernes
- Et surtout, les conditions d’utilisation ne peuvent pas être modifiées unilatéralement
1 commentaires
Avis sur Hacker News
L’argument selon lequel Epic et Unreal Engine feraient quelque chose de similaire à Unity ne me convainc pas vraiment
Epic exploite sa propre boutique de jeux et attire activement les développeurs avec un partage des revenus généreux ; il faudrait donc supposer que l’entreprise couperait les ponts avec les développeurs pour une hausse de revenus douteuse
Si Unity a choisi cette voie, c’est apparemment parce qu’elle ne voulait pas donner l’impression de rompre publiquement sa promesse passée de pas de partage des revenus / pas de royalties et, ironiquement, elle semble avoir inventé un modèle de facturation encore pire
Au final, Unity est devenue trop grosse après son introduction en Bourse, dans un contexte où elle était évaluée sur sa croissance, et le cœur du problème semble être des effectifs et des coûts devenus excessifs. Le fait qu’Epic et Valve soient des sociétés non cotées, contrairement à Unity, en dit long
Pas exactement. Unity a fusionné avec ironSource, une société de publicité mobile, et concurrence directement AppLovin, un acteur fort de ce marché
Les conditions et arrangements en coulisses que Unity propose aux développeurs consistent à exonérer ces frais s’ils utilisent les produits publicitaires de Unity plutôt qu’AppLovin. Cela ressemble à une tentative d’utiliser sa position sur le marché des moteurs de jeu pour renforcer sa position sur celui de la publicité mobile
À mon avis, ce n’est pas un problème de structure d’entreprise, mais un échec de management. Si l’entreprise avait écouté ne serait-ce qu’un peu les utilisateurs, les développeurs internes ou toute personne ayant le moindre sens des réalités, cela ne serait pas arrivé
Mais quand on recrute un ex-PDG d’EA sans expérience de terrain dans l’industrie et qui a quitté son précédent poste sur de mauvais résultats financiers, ce genre de catastrophe semble presque inévitable
Cela fait beaucoup réfléchir à la différence entre sociétés cotées et non cotées. La plupart des produits que j’aime viennent de sociétés non cotées, et il y a quelque chose dans les incitations des sociétés cotées qui pousse à de mauvais choix
Il existe en pratique deux sources de revenus : vendre des produits/services et vendre des actions, et les deux entrent souvent en conflit au détriment des clients. Dans une société non cotée, la loyauté envers les clients est plus directe : le produit doit être bon pour que l’entreprise survive
Je ne veux pas dire qu’il ne devrait pas y avoir de sociétés cotées, mais il faudrait trouver une structure qui évite que les incitations de l’entreprise divergent de celles des clients qui paient réellement. Pour l’instant, se concentrer davantage sur le partage des bénéfices et les dividendes que sur le cours de l’action semble être une piste
La question n’est pas « Epic fera-t-il cela demain ? », mais « le fera-t-il à un moment quelconque dans un avenir prévisible ? »
La direction d’Epic pourrait décider d’une IPO en espérant gagner davantage, l’entreprise pourrait être vendue à un milliardaire très riche comme Musk, ou une nouvelle équipe dirigeante pourrait convaincre tout le monde de prendre ce genre de décision pour de « sérieuses raisons commerciales »
Si vous créez un jeu avec Unreal, vous misez en fin de compte l’avenir commercial de votre projet sur le fait qu’une entreprise à but lucratif « restera moins malveillante que l’autre ». Désormais, le choix d’un moteur ne se résume plus aux fonctionnalités, au nombre de développeurs ou à la structure tarifaire actuelle : il faut aussi se demander s’il pourra un jour changer rétroactivement ses tarifs et ruiner votre entreprise
À l’inverse, si vous utilisez Godot ou votre propre moteur, vous n’avez pas à vous en inquiéter. Si l’industrie du jeu et le public envoient maintenant un signal suffisamment fort à Unity, cela réduira aussi fortement la probabilité que d’autres entreprises tentent ce genre de manœuvre à l’avenir
La licence Unreal contient un argument solide à l’appui de cette thèse
« 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. »
Autrement dit, même en cas de prix d’appel suivi d’un changement des conditions, les anciennes versions du moteur auxquelles vous avez déjà accès peuvent continuer à être utilisées sous la licence existante. À une époque où presque toutes les licences utilisateur final ressemblent à « nous pouvons faire ce que nous voulons à tout moment et vous ne pouvez rien faire », inclure une telle clause ressemble à un signe de bonne foi assez notable
https://www.unrealengine.com/en-US/eula/unreal
Cela devrait aussi servir de signal d’alarme à tous ceux qui utilisent des outils fermés : DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle, etc.
Certains sont des outils de tout premier ordre, mais ce n’est que du temps emprunté jusqu’à ce que leur propriétaire change les conditions, cesse de les fournir ou augmente les prix au point de nuire à votre activité.
Les outils logiciels fermés sont une dette, et les bénéfices sont souvent dérisoires au regard du risque. J’ai vu, dans plusieurs équipes, des projets ayant englouti des dizaines d’années-homme être abandonnés à cause d’un arrêt du support ou d’une hausse de prix excessive.
Je ne suis pas puriste, donc j’utilise des choses comme JetBrains. Parce que, si nécessaire, je peux facilement basculer vers des outils open source sans perturber l’activité. Il ne s’agit pas de dire qu’il faut fabriquer ses propres outils, mais d’utiliser d’excellents outils open source comme PostgreSQL, Apache, Linux, MariaDB, des langages open source, Redis ou CouchDB.
Avec Unity, le coût de changement de moteur est bien plus élevé. Pour la plupart de ceux qui ont déjà terminé leur jeu, envisager de migrer vers Godot ou Unreal n’est même pas réaliste, et c’est ce qui rend cette affaire particulièrement grave.
Les logiciels développés en interne, eux, finissent souvent par être réécrits par les nouveaux membres de l’équipe à cause du code laissé par d’anciens employés. Il est étrange de déconseiller l’usage de logiciels fermés au motif d’une faible probabilité qu’ils changent, tout en prenant comme alternative un logiciel interne dont les problèmes de maintenance futurs sont presque garantis.
Travailler avec des fournisseurs fiables, passer en revue ses dépendances, définir le niveau de risque acceptable et examiner attentivement les licences utilisées. C’est particulièrement vrai pour un élément aussi critique qu’un moteur de jeu pour un studio.
Tous trois ont une entreprise derrière eux, avec des ventes ou des restrictions, généralement visant les fournisseurs cloud plutôt que l’auto-hébergement. Dans leurs versions actuelles, je les considère tous trois comme suffisamment ouverts pour que le risque de dépendance à un fournisseur ne soit pas très élevé.
La politique tarifaire de Unity est rétroactive en ce sens qu’elle suit même le nombre d’installations de vieux jeux déjà sortis. C’est un peu comme si SQL Server passait à une facturation au Go et annonçait que cela s’applique à toutes les versions depuis 2005 ; même les gouvernements refuseraient un changement rétroactif de ce genre.
La vraie question maintenant, c’est de savoir si une personne sensée développera encore un jeu avec Unity à l’avenir.
À court terme, les bénéfices peuvent augmenter, mais le nouveau développement de jeux Unity va bientôt se tarir. Car même si l’on accepte les conditions actuelles, on sait désormais que Unity peut changer les règles à tout moment et répercuter les coûts sur les utilisateurs.
Unity est devenu, pour les studios de jeux, un risque de responsabilité de niveau existentiel ; on se demande qui osera encore s’en approcher. Je m’attends à ce que la direction soit bientôt mise dehors par les actionnaires.
Il est difficile d’être certain que la direction sera éjectée aussi vite. Beaucoup trop de choses ont été construites sur Unity.
L’interprétation la plus courante est que Unity cherche à soutirer de l’argent à Genshin Impact, mais il existe aussi beaucoup de jeux à succès, comme Among Us ou Untitled Goose Game, qui ne peuvent pas être facilement portés vers un autre moteur.
Autrement dit, l’entreprise veut devenir l’IBM des moteurs de jeu, une société qui recherche une rente avec un service médiocre.
https://www.sportskeeda.com/esports/will-genshin-impact-affe...
https://www.create-learn.us/blog/top-games-made-with-unity/
C’est le genre de logique : « après moi, après toi, le déluge ».
Les bons chiffres tombent au moment du calcul des bonus, et les mauvais chiffres n’apparaissent qu’une fois que les décideurs sont partis dans une autre entreprise. De toute façon, ils seront présentés comme ceux qui ont doublé la rentabilité de Unity, donc ils auront beaucoup d’options.
Ce qui est dommage, c’est que Unity a contribué dans une certaine mesure à l’augmentation des jeux Linux au cours des dix dernières années.
Dans Unity, la prise en charge de Linux était presque gratuite par rapport à beaucoup d’autres moteurs, et si les jeux Unity diminuent, les jeux Linux risquent fort de diminuer aussi.
Cela va aussi poser problème pour Vision Pro. Je suis un peu surpris qu’Apple ne soit pas intervenu pour dire que cela ne s’appliquerait pas aux apps Vision Pro.
Au moins sur la période limitée où j’ai travaillé en entreprise, il est très rare que la direction soit plus malveillante que le conseil d’administration. C’est encore plus vrai dans une entreprise commerciale cotée, et il est encore plus rare que le conseil n’ait pas discuté de ce sujet avec la direction avant l’annonce.
J’ai aussi un peu de peine pour Unity. L’entreprise est dans une mauvaise situation financière, brûle près de 1 milliard de dollars par an et n’a pas de solution évidente.
Elle doit soit augmenter ses prix et mettre ses clients en colère, soit réduire ses coûts — comme elle l’a déjà fait avec des licenciements massifs — au risque de se faire distancer par d’autres moteurs de jeu comme Unreal.
Pendant des années, ce qui a réellement soutenu l’entreprise, c’était sa valorisation. Tant que les investisseurs finançaient la croissance et les profits futurs, elle pouvait combler ses pertes, mais maintenant que la croissance ralentit et que les investisseurs sont moins généreux avec elle, je ne vois pas bien ce que Unity peut faire.
Elle n’a pas de moat, sa croissance ralentit et elle brûle beaucoup de cash. Si l’environnement macroéconomique ne devient pas favorable, il est difficile de voir comment elle pourra s’en sortir tout en restant en tête.
S’ils avaient principalement soutenu leurs clients cœur de cible, les développeurs indés, avec une petite équipe et un produit simple, cela aurait pu être durable et rentable. Mais on dirait qu’ils ont voulu entrer de force sur le marché AAA.
Cette affaire est vraiment le résultat d’un dispositif très mal annoncé, de détails pas suffisamment travaillés qui exposaient les développeurs aux abus, et d’une communauté de créateurs soudée, déjà habituée à subir piratage, review bombing et vagues de remboursements, qui a réagi presque comme un seul corps.
La plupart des développeurs auraient accepté un partage des revenus, même en râlant. De grands studios comme Nintendo et Microsoft utilisaient aussi Unity ; il est difficile de comprendre s’ils pensaient vraiment qu’ils accepteraient sans problème des frais appliqués aux ventes rétroactives et aux chiffres d’affaires.
Avec environ 30 % de part de marché, il suffirait qu’elle capte moins de 2 % de la valeur créée par ses outils pour atteindre le seuil de rentabilité. Si elle n’y arrive pas, ou si elle fournit sa technologie à des segments moins rentables que la moyenne, elle doit changer de focalisation ou réduire ses coûts.
Si une entreprise ne parvient pas à capter plus de valeur qu’elle n’en consomme, il est naturel qu’elle échoue.
Personne n’a obligé Riccitiello à appuyer sur l’accélérateur, ni à vendre ses actions pour s’enrichir avant cette annonce catastrophique. Il l’a fait de lui-même.
J’ai bien plus de peine pour les milliers de développeurs sur lesquels cette politique atroce a pointé un pistolet métaphorique, et qui doivent maintenant s’inquiéter de changer de moteur.
Même si j’aime l’open source et le moteur Godot, cette affaire ressemble davantage à un signal d’alarme : il faut empêcher les entreprises de modifier unilatéralement et rétroactivement les contrats pour imposer de nouveaux frais et rompre les engagements pris dans les contrats existants.
Si cela est possible, l’open source n’offre pas non plus une grande protection concrète.
L’affaire HashiCorp en est un bon exemple. Terraform a été forké et continue comme d’habitude, sans impact pour les utilisateurs.
Pour une plateforme de programmation comme un moteur de jeu, cet avantage est encore plus important. Un outil comme Terraform pourrait peut-être être réécrit en quelques semaines si les tests sont corrects, mais pour un jeu, c’est impossible.
Personne ne peut retirer les droits accordés par la licence MIT, et il n’existe aucun mécanisme juridique pour le faire. On est totalement protégé contre ce genre de situation.
Certaines licences open source sont faciles à respecter et favorables aux entreprises, ce qui peut aider. À l’inverse, les studios de jeux qui se plaignent aujourd’hui réagiraient aussi très vivement si on leur imposait de respecter la GPL et de publier leur code source.
Même avec une licence open source permissive, il reste le risque que les futures versions passent sous une licence qui ne vous convient pas, comme HashiCorp l’a fait avec Terraform et d’autres projets, vous privant des mises à jour et correctifs nécessaires. La communauté peut maintenir un fork, ou pas.
Si cette affaire est légale, ce serait à cause des règles de licence utilisateur final, mais je ne vais pas me risquer à prédire sa légalité.
Les conditions d’utilisation valent souvent moins que du papier toilette, même imprimées sur papier, mais je me demande si les abonnés existants depuis 2019 peuvent maintenant attaquer pour rupture de contrat et coûts de redéveloppement.
Steam m’a déjà eu comme ça. J’avais de vieux jeux comme Half-Life sur un ancien portable ; un jour, en le lançant, Steam s’est mis à jour et s’est cassé, et comme l’ancien système n’était plus pris en charge, les jeux ne fonctionnaient plus non plus.
Cela ne veut pas dire que l’open source est absolument indispensable, mais qu’il faut pouvoir posséder le logiciel, pas simplement le louer.
Unreal n’a actuellement pas de conditions comme celles de Unity, mais dire que rien ne l’empêche de faire quelque chose de similaire, et qu’il est très probable qu’il l’imite si Unity s’en sort, est une affirmation insuffisamment étayée.
Unreal prévoit une condition selon laquelle on peut utiliser indéfiniment une version donnée du moteur, et Epic ne peut pas révoquer cette licence. Il est vrai, en revanche, qu’Epic peut changer les conditions pour les nouvelles versions.
Tim Sweeney l’a souvent indiqué explicitement, et au vu de ses efforts pour casser le monopole Google Play/Apple, la direction d’Epic Games semble différente de ces piranhas corporatifs à la Unity.
Cela dit, dire de Godot que « comme c’est open source, il n’y a pas de problème » est également simpliste. Que se passe-t-il si les développeurs cessent de le maintenir ? Dire que « la communauté continuera à travailler dessus » revient souvent, dans la réalité, à dépendre d’une ou deux personnes qui font vraiment le travail.
Si les développeurs de Godot s’arrêtent, on se retrouve coincé avec un projet sans support, et au lieu de se concentrer sur son jeu, il faut continuer à développer le moteur. La même remarque vaut pour le produit maison de l’auteur.
La semaine dernière, 32 personnes ont envoyé 52 commits sur Godot, et sur le dernier mois, 135 personnes ont contribué. On n’est pas au niveau d’« une ou deux personnes ».
Si une entreprise closed source arrête de développer son produit, on se retrouve tout autant coincé ; et dans ce cas, comme on n’a pas accès au code source, on ne peut même pas le corriger soi-même, donc on est encore plus bloqué.
Si le développement de Godot s’arrête, la version que tu as aujourd’hui reste disponible telle quelle. Quelle est la différence entre Epic qui arrête de travailler sur le moteur de jeu que tu utilises, et un projet open source qui arrête de travailler sur le moteur de jeu que tu utilises ? La différence avec Godot, c’est que tu peux travailler dessus toi-même si tu le souhaites.
Unity semblait conserver sa licence dans un dépôt Git afin que tout le monde puisse facilement suivre les changements de licence. Juste avant le changement de licence, ce dépôt a été supprimé, puis remis en ligne plus tard, mais la clause permettant d’utiliser indéfiniment les anciennes versions sans les nouvelles contraintes avait disparu.
Je bassinais un ami développeur de jeux, développeur Unity C#, pour qu’il regarde Bevy et Rust. Parce que le système de types de Rust est vraiment excellent.
Exemple de code : https://bevyengine.org/learn/book/getting-started/ecs/
La licence est Apache 2.0 ou MIT.
Apache 2.0 : https://github.com/bevyengine/bevy/blob/main/LICENSE-APACHE
MIT : https://github.com/bevyengine/bevy/blob/main/LICENSE-MIT
Dans les commentaires de l’article d’Ars, j’ai vu ce passage de la FAQ de Unity (https://unity.com/pricing-updates), et il continue de me trotter dans la tête :
“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.)”
J’ai du mal à croire que la direction de Unity pense que ça puisse passer. Microsoft, Apple et les autres ont probablement signé avec les développeurs des contrats leur accordant l’ensemble des droits de distribution des jeux selon une structure de frais donnée ; Unity compte-t-il maintenant arriver en disant : « ce contrat ne vous donne pas le droit de distribuer la partie qui nous appartient, payez-nous aussi » ?
Et même si cela passait, Microsoft ou Apple pourraient sans doute engager des poursuites contre les développeurs qui leur avaient garanti céder les droits de distribution de l’ensemble du jeu.
Tout cela ressemble à une énorme improvisation, et cette question-réponse sur les jeux par abonnement montre le niveau général du plan. Difficile de savoir s’ils ont suivi un caprice du CEO sans validation juridique, ou s’ils cherchent délibérément à provoquer des procès.
Je suis devenu sponsor de Bevy. Je vais essayer de convaincre notre studio de reverser un certain pourcentage de ses bénéfices à des projets open source.
Même si les chances que Bevy devienne réellement un moteur grand public sont infimes, ça vaut le coup d’essayer.
Unity était un rêve, ou un mensonge, selon lequel on pouvait créer des jeux sans équipe logicielle compétente.
Maintenant, le texte d’origine nourrit l’espoir d’un autre rêve, ou mensonge : que de magiques petites fées open source permettront de continuer à tenir sans équipe logicielle compétente. Mais ça ne se passera pas comme ça.
Il faut trouver des programmeurs, constituer une équipe, créer une entreprise où cette équipe peut s’installer, et ajuster le modèle économique pour pouvoir les payer. Autrement dit, il faut augmenter les prix.
Faire un jeu, peut-être. Un bon jeu, je ne pense pas.