- Unity cambió su modelo de precios de cobro por asiento a cobro por instalación (pay per install), aplicando tarifas no solo a las instalaciones de pago sino a todas las instalaciones normales
- En un entorno móvil donde el ingreso promedio por impresión publicitaria es de $0.02, Unity planea cobrar $0.20 por instalación después de alcanzar ingresos anuales de $200,000, lo que exige que cada usuario vea al menos 10 anuncios para no generar pérdidas
- Este cambio se aplica de forma retroactiva a aplicaciones existentes, generando una carga incluso para juegos ya lanzados
- Los videojuegos pasan por un proceso de desarrollo largo, de meses a años, por lo que cambiar de motor es extremadamente difícil, y a diferencia de cambiar de editor de documentos, puede poner en riesgo la supervivencia del proyecto
- Los motores de código abierto basados en licencia MIT garantizan derechos irrevocables e inmodificables, protegiendo a los desarrolladores frente a futuros cambios de precios o políticas
El cambio en la política de precios de Unity y su impacto
- Unity cambió su modelo de precios de cobro por asiento (pay per seat) a cobro por instalación (pay per install), y esto no se limita a instalaciones de pago ni al uso del juego, sino que se aplica a todas las instalaciones normales
- Esto provoca consecuencias especialmente graves en el entorno móvil, donde el ingreso por instalación varía mucho
- Según Ironsource, subsidiaria de Unity, el ingreso promedio por impresión publicitaria es de $0.02
- Unity pretende cobrar $0.20 por instalación una vez que la app haya generado $200,000 en los últimos 12 meses
- Como resultado, cada usuario tendría que ver al menos 10 anuncios después de instalar la app para evitar pérdidas
- Se trata de un promedio, y el problema se vuelve mucho más grave en apps populares en mercados emergentes, donde los ingresos publicitarios son menores
- El hecho de que este cambio se aplique retroactivamente a aplicaciones existentes empeora aún más la situación
Por qué este tipo de política es posible
- Se compara con una situación en la que Microsoft cobrara por cada persona que lee un documento creado con Word; en ese caso, el usuario simplemente podría cambiarse a Google Docs
- Cambiar de editor de documentos es molesto, pero no pone en riesgo la supervivencia del negocio
- El desarrollo de videojuegos es un proceso largo y complejo, que dura de meses a años, y una vez avanzado el trabajo no es fácil migrar a otro motor
- Requiere una cantidad considerable de tiempo y dinero
- Incluso si la migración fuera posible, para entonces el equipo de desarrollo podría ya haberse disuelto
La protección que ofrece el código abierto
- Los motores de videojuegos de código abierto como Godot engine protegen el trabajo al otorgar un derecho de uso del motor que no puede ser revocado ni modificado
- Bajo la licencia MIT de Godot, todos los usuarios obtienen el derecho de usar, modificar y distribuir libremente
- La única condición es dar crédito al autor original y no afirmar que el motor es una creación propia
- Esto se aplica solo al motor; el juego en sí sigue siendo propiedad del desarrollador
Por qué no basta con cambiarse a Unreal engine
- Aunque Unreal engine no tiene actualmente condiciones como las de Unity, no existe ningún mecanismo que impida que adopte una política similar en el futuro
- Si Unity logra imponer este cambio, es posible que Unreal siga el mismo camino
El papel de Ramatak
- Ramatak mobile studio añade al motor de código abierto Godot engine funciones esenciales para juegos móviles como anuncios, compras dentro de la app y analítica
- Aunque Ramatak cobra por este servicio, si sus condiciones llegan a volverse incómodas, el usuario puede llevarse su juego y cambiar a la versión de código abierto
- Se perdería el acceso a funciones exclusivas de Ramatak, pero el juego seguiría siendo completamente propiedad del desarrollador
- La primera publicación del sitio trata sobre la relación con los usuarios
- Como cambiar a la versión de código abierto es muy fácil, la empresa necesariamente tiene que ofrecer el valor que los usuarios quieren
Conclusión
- El entorno de los juegos móviles cambia constantemente y es imposible predecir cuál será la próxima “gran tendencia”
- Al usar un motor de código abierto, sin importar cuál sea esa “próxima cosa”, el motor no bloqueará su aprovechamiento ni impondrá una estrategia de monetización
- Con Ramatak mobile studio, es posible obtener tanto la libertad y estabilidad de un motor de código abierto como funciones avanzadas y especializadas necesarias para los juegos móviles modernos
- Y, sobre todo, sus condiciones no pueden cambiarse de forma unilateral
1 comentarios
Opiniones de Hacker News
No me convence mucho el argumento de que Epic y Unreal Engine harán algo parecido a Unity.
Epic opera su propia tienda de juegos y atrae activamente a desarrolladores con un reparto de ingresos generoso, así que habría que asumir que rompería su relación con los desarrolladores por un aumento de ingresos dudoso.
Parece que Unity eligió este camino porque no quería que pareciera que rompía públicamente su antigua promesa de sin reparto de ingresos/regalías, e irónicamente parece haber creado un modelo de cobro peor.
Al final, Unity creció demasiado en un entorno donde, tras salir a bolsa, se la evalúa por crecimiento, y el núcleo de este problema parece ser que su plantilla y sus costos se inflaron en exceso. Dice mucho que Epic y Valve sean privadas y Unity no.
No exactamente. Unity se fusionó con ironSource, una empresa de publicidad móvil, y compite directamente con AppLovin, un actor fuerte en este mercado.
Las condiciones y acuerdos por debajo de la mesa que Unity les plantea a los desarrolladores son del tipo: si usan los productos publicitarios de Unity en lugar de AppLovin, se les exime de esta tarifa. Parece un intento de usar su posición en el mercado de motores de juegos para fortalecer su posición en el mercado de publicidad móvil.
Creo que esto no es un problema de estructura corporativa, sino un problema de fracaso de gestión. Si hubieran escuchado a usuarios, desarrolladores internos o a cualquiera con un mínimo sentido de la realidad, esto no habría pasado.
Pero si contratas a un ex-CEO de EA que no tiene experiencia de bajo nivel en la industria y que dejó su trabajo anterior por malos resultados financieros, una catástrofe así parece casi inevitable.
Me hace pensar mucho en la diferencia entre empresas privadas y empresas que cotizan en bolsa. La mayoría de mis productos favoritos vienen de empresas privadas, y hay algo en los incentivos de las empresas públicas que empuja a tomar malas decisiones.
En la práctica existen dos fuentes de ingresos: vender productos/servicios y vender acciones, y ambas a menudo entran en conflicto de formas perjudiciales para los clientes. En una empresa privada, la lealtad hacia los clientes es más directa, así que el producto tiene que ser bueno para que la empresa se sostenga.
No quiero decir que no deban existir empresas que coticen en bolsa, pero hace falta una forma de estructurarlas para que los incentivos de la empresa no se desalineen con los de los clientes que realmente pagan. Por ahora, enfocarse más en el reparto de ganancias y los dividendos que en el precio de la acción parece una dirección posible.
El problema no es “¿Epic hará esto mañana?”, sino “¿lo hará en algún momento del futuro previsible?”.
La directiva de Epic podría decidir salir a bolsa esperando ganar más dinero, o podría venderse a un multimillonario con mucho dinero como Musk, o un nuevo equipo ejecutivo podría convencer a todos de tomar una decisión así por “razones de negocio serias”.
Si haces un juego con Unreal, al final estás apostando el éxito comercial futuro a que una empresa con fines de lucro “siga siendo menos malvada que la otra”. Ahora elegir un motor ya no es solo cuestión de funciones, cantidad de desarrolladores o estructura de precios actual, sino también de preocuparse por si algún día cambian retroactivamente la estructura de precios y hunden tu empresa.
En cambio, si lo haces con Godot o con un motor propio, no tienes que preocuparte por eso. Si ahora la industria de los videojuegos y el público le envían a Unity una señal lo suficientemente fuerte, también se reducirá mucho la probabilidad de que otras empresas intenten algo así en el futuro.
La licencia de Unreal contiene una base sólida que respalda este argumento.
“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.”
Es decir, incluso si hacen un cambio de condiciones después de atraer con una oferta gancho, las versiones anteriores del motor a las que ya tienes acceso pueden seguir usándose bajo la licencia existente. En una época en la que casi todas las licencias de usuario final se acercan a “nosotros podemos hacer lo que queramos cuando queramos y tú no puedes hacer nada”, incluir una cláusula así parece una muestra considerable de buena fe.
https://www.unrealengine.com/en-US/eula/unreal
También debería ser una señal de alarma para cualquiera que use herramientas de código cerrado en general: DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle, etc.
Algunas son herramientas de primer nivel, pero no dejan de ser tiempo prestado hasta que sus dueños cambien las condiciones, dejen de ofrecerlas o suban los precios lo suficiente como para golpear el negocio.
Las herramientas de software de código cerrado son deuda, y muchas veces sus beneficios son mínimos comparados con el riesgo. He visto proyectos en los que varios equipos invirtieron decenas de años-persona terminar descartados por fin de soporte o aumentos de precio excesivos.
No soy purista, así que uso cosas como JetBrains. Porque, si hiciera falta, podría cambiar fácilmente a herramientas de código abierto sin afectar el negocio. No estoy diciendo que haya que crear las herramientas uno mismo, sino usar excelentes herramientas de código abierto como PostgreSQL, Apache, Linux, MariaDB, lenguajes de código abierto, Redis y CouchDB.
Con Unity, el costo de cambiar de motor es muchísimo mayor. Para la mayoría de quienes ya terminaron un juego, ni siquiera es realista considerar migrarlo a Godot o Unreal, y por eso este caso es especialmente grave.
En cambio, con el software desarrollado internamente, es común que los nuevos integrantes terminen reescribiéndolo por culpa del código que dejaron empleados anteriores. Es raro decir que no se use código cerrado por la pequeña posibilidad de que cambie, y al mismo tiempo proponer como alternativa software interno, cuyos problemas de mantenimiento futuros están casi garantizados.
Hay que trabajar con proveedores confiables, revisar las dependencias, definir qué nivel de riesgo se está dispuesto a asumir y mirar con cuidado las licencias que se usan. Más aún si se trata de un componente tan importante para un estudio de juegos como el motor de juego.
Los tres tienen una empresa detrás, con ventas o restricciones, y por lo general esas restricciones apuntan a proveedores de nube, no al autohosting. Con las versiones actuales, considero que los tres son lo suficientemente abiertos como para que el riesgo de dependencia de proveedor no sea grande.
La política de precios de Unity es retroactiva en el sentido de que también pretende rastrear las instalaciones de juegos antiguos ya lanzados. Es parecido a que SQL Server cambiara a cobro por GB y dijera que aplica a todo desde la versión 2005 en adelante; incluso los gobiernos rechazarían un cambio retroactivo así.
Ahora la verdadera pregunta es si alguien en su sano juicio va a crear juegos con Unity de aquí en adelante.
A corto plazo quizá aumenten las ganancias, pero pronto se va a cortar el nuevo desarrollo de juegos en Unity. Porque, aunque aceptes las condiciones actuales, ya quedó claro que Unity puede cambiar las reglas en cualquier momento y trasladar los costos a los usuarios.
Unity se convirtió en un riesgo de responsabilidad de nivel existencial para las empresas de juegos, y cuesta imaginar quién se atrevería a acercarse. Espero que los accionistas echen pronto a la dirección.
Es difícil estar seguro de que la dirección vaya a ser expulsada tan rápido. Hay demasiadas cosas construidas sobre Unity.
La interpretación más común es que Unity está tratando de sacarle dinero a Genshin Impact, pero también hay muchos juegos exitosos que no pueden portarse fácilmente a otro motor, como Among Us o Untitled Goose Game.
Es decir, quiere convertirse en la IBM de los motores de juego: una empresa que busca rentas con un servicio de baja calidad.
https://www.sportskeeda.com/esports/will-genshin-impact-affe...
https://www.create-learn.us/blog/top-games-made-with-unity/
Es el típico “después de que yo me vaya, y después de que tú también te vayas”.
Los buenos números aparecen justo a tiempo para calcular los bonos, y los malos recién salen a la luz cuando quienes tomaron las decisiones ya se fueron a otra empresa. De todos modos, los presentarán como quienes duplicaron la rentabilidad de Unity, así que opciones no les van a faltar.
Lo lamentable es que Unity contribuyó en cierta medida al aumento de los juegos en Linux durante la última década.
En Unity, dar soporte a Linux era casi gratis en comparación con muchos otros motores, y si disminuyen los juegos hechos con Unity, probablemente también disminuyan los juegos para Linux.
Esto también será un problema para Vision Pro. Me sorprende un poco que Apple no haya salido a decir que no se aplicará a las apps de Vision Pro.
Al menos en mi limitada experiencia trabajando en empresas, es muy raro que la dirección sea más malvada que el consejo de administración. Más aún en una empresa pública con fines de lucro, y es todavía más raro que el consejo no haya hablado de esto con la dirección antes del anuncio.
También me da un poco de pena Unity. Está en una mala posición financiera, quema casi 1.000 millones de dólares al año y no tiene una solución clara
O sube los precios y enfurece a sus clientes, o reduce costos, como ya lo viene haciendo con despidos masivos, y asume el riesgo de quedar desplazada por otros motores de juego como Unreal
Durante años, lo que sostuvo a la empresa fue, en la práctica, su valuación. Mientras los inversionistas financiaban crecimiento y ganancias futuras, podía cubrir las pérdidas, pero ahora que el crecimiento se desacelera y los inversionistas son menos generosos con el crecimiento, no sé qué puede hacer Unity
No tiene foso defensivo, su crecimiento se desaceleró y quema mucho efectivo. Si el entorno macro no cambia a su favor, es difícil ver cómo puede salir de esto y seguir siendo líder
Si hubieran apoyado principalmente a su cliente central, los desarrolladores indie, con un equipo pequeño y un producto simple, quizá habría sido sostenible y rentable. Pero parece que intentaron meterse a la fuerza en el mercado AAA
Este escándalo es el resultado de un esquema anunciado pésimamente, detalles poco pulidos que dejaban a los desarrolladores expuestos a abusos, y una comunidad de creadores muy unida, con experiencia de haber sido maltratada por piratería, review bombing y oleadas de reembolsos, reaccionando casi como un solo cuerpo
La mayoría de los desarrolladores habría aceptado un reparto de ingresos, aunque se quejara. Grandes estudios como Nintendo y Microsoft también han usado Unity, y cuesta entender si de verdad pensaron que ellos aceptarían sin problemas que les cobraran sobre ventas retroactivas y cifras de ingresos
Si su participación de mercado es de alrededor del 30%, con capturar menos del 2% del valor creado con sus herramientas ya llegarían al punto de equilibrio. Si no pueden hacerlo, o si están proveyendo tecnología a áreas menos rentables que el promedio, tienen que cambiar el foco o reducir costos
Si no puedes capturar más valor del que consumes, es natural que el negocio fracase
Nadie le dijo a Riccitiello que pisara el acelerador, ni que vendiera acciones para enriquecerse antes del anuncio desastroso. Él lo hizo por su cuenta
Me dan mucha más pena los miles de desarrolladores a quienes esta política terrible les puso un arma metafórica en la cabeza, y que ahora tienen que preocuparse por cambiar de motor
Aunque me gusta el código abierto y el motor Godot, esto me parece más bien una llamada de atención sobre la necesidad de impedir que las empresas cambien contratos de forma unilateral y retroactiva para imponer nuevos costos y romper promesas contractuales existentes
Si eso es posible, el código abierto tampoco ofrece mucha protección real
El caso de HashiCorp es un buen ejemplo. Terraform fue bifurcado y sigue como siempre, y los usuarios no se ven afectados
En una plataforma de programación como un motor de juego, esta ventaja es aún mayor. Algo como Terraform quizá podría reescribirse en unas semanas si las pruebas están bien, pero con un juego eso es imposible
Nadie puede quitarte los derechos bajo la licencia MIT, y no existe un mecanismo legal para hacerlo. Estás completamente protegido contra algo así
Algunas licencias de código abierto son fáciles de cumplir y favorables para los negocios, así que pueden ayudar. Por el contrario, los estudios de videojuegos que ahora se quejan también reaccionarían con fuerza si se les obligara a cumplir la GPL y publicar su código fuente
Incluso con licencias permisivas de código abierto, queda el riesgo de que las licencias de versiones futuras cambien a algo que no te guste, como hizo HashiCorp con Terraform y otros, dejándote sin actualizaciones y correcciones necesarias. La comunidad podría mantener un fork, o no
Si esto es legal, probablemente sea por las reglas de licencia para usuarios finales, pero no voy a aventurarme a predecir si lo es o no
Los términos de servicio muchas veces no valen ni el papel higiénico si los imprimes, pero me pregunto si un suscriptor existente desde 2019 ahora podría demandar por incumplimiento de contrato y costos de redesarrollo
Me pasó con Steam. Tenía juegos viejos como Half-Life en una laptop antigua, y un día al encenderla Steam se actualizó, se rompió, y como el sistema viejo ya no era compatible, los juegos tampoco funcionaron
Eso no significa que el código abierto sea imprescindible, pero sí que necesitamos poseer el software, no alquilarlo
Unreal actualmente no tiene condiciones como las de Unity, pero decir que no hay nada que le impida hacer algo similar y que, si Unity se sale con la suya, es muy probable que la siga, es una afirmación que no está suficientemente investigada.
Unreal tiene una condición que permite usar para siempre una versión específica del motor y que Epic no puede revocar esa licencia. Es cierto que Epic puede cambiar las condiciones para versiones nuevas.
Tim Sweeney también lo ha señalado con frecuencia, y si uno mira sus movimientos para romper los monopolios de Google Play/Apple, la dirección de Epic Games parece distinta de pirañas corporativas como Unity.
Dicho eso, afirmar sobre Godot que “como es open source, no hay problema” también es simplista. ¿Qué pasa si los desarrolladores dejan de darle soporte? En la práctica, eso de que “la comunidad seguirá trabajando” muchas veces termina dependiendo de una o dos personas que hacen el trabajo real.
Si los desarrolladores de Godot se detienen, quedas atrapado en un proyecto sin soporte y tienes que seguir desarrollando el motor en vez de concentrarte en tu juego. Lo mismo aplica al producto propio del autor.
Godot tuvo 52 commits de 32 personas durante la última semana, y 135 personas contribuyeron durante el último mes. No está al nivel de “una o dos personas”.
Si una empresa de código cerrado deja de desarrollar su producto, quedas igual de atrapado; y en ese caso, como no tienes acceso al código fuente, ni siquiera puedes arreglarlo tú mismo, así que quedas todavía más atrapado.
Si el desarrollo de Godot se detiene, la versión que ya tienes sigue existiendo igual. ¿Cuál es la diferencia entre que Epic deje de trabajar en el motor de juego que estás usando y que un proyecto open source deje de trabajar en el motor de juego que estás usando? La diferencia es que con Godot puedes trabajar en él tú mismo si quieres.
Parece que Unity mantenía la licencia en un repositorio Git para que todos pudieran rastrear fácilmente los cambios. Justo antes del cambio de licencia, eliminaron ese repositorio y luego lo volvieron a subir, pero ya no estaba la cláusula que permitía usar para siempre versiones antiguas sin las nuevas restricciones.
Le estuve insistiendo a un amigo desarrollador de juegos que trabaja con Unity C# para que mirara Bevy y Rust, porque el sistema de tipos de Rust es realmente excelente.
Ejemplo de código: https://bevyengine.org/learn/book/getting-started/ecs/
La licencia es Apache 2.0 o MIT.
Apache 2.0: https://github.com/bevyengine/bevy/blob/main/LICENSE-APACHE
MIT: https://github.com/bevyengine/bevy/blob/main/LICENSE-MIT
En los comentarios del artículo de Ars vi esta parte de la FAQ de Unity (https://unity.com/pricing-updates) y no deja de darme vueltas:
“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.)”
No puedo creer que la dirección de Unity piense que esto va a funcionar. Microsoft, Apple y otros seguramente firmaron contratos con los desarrolladores para obtener todos los derechos de distribución del juego bajo una estructura de comisiones específica, y ahora Unity pretende decir: “Ese contrato no les da derecho a distribuir la parte que nos pertenece. Páguennos también a nosotros”.
Incluso si eso funcionara, Microsoft o Apple podrían presentar reclamos legales contra los desarrolladores que garantizaron que estaban cediendo los derechos de distribución de todo el juego.
Todo esto parece una improvisación gigantesca, y esta pregunta y respuesta sobre juegos por suscripción muestra el nivel de todo el plan. Cuesta entender si siguieron un capricho del CEO sin revisión legal, o si están intentando llevarlo deliberadamente a un litigio.
Me hice patrocinador de Bevy. Voy a intentar convencer a nuestro estudio de donar un porcentaje fijo de las ganancias a proyectos open source.
Aunque la probabilidad de que Bevy se convierta realmente en un motor mainstream sea muy pequeña, vale la pena intentarlo.
Unity era un sueño, o una mentira, de que se podían hacer juegos sin un equipo de software competente.
Ahora el texto original da esperanza en otro sueño, o mentira, de que unas hadas mágicas open source permitirán seguir adelante sin un equipo de software competente. Pero eso no va a pasar.
Hay que encontrar programadores, formar un equipo, crear una empresa donde ese equipo pueda asentarse y ajustar el modelo de negocio para poder pagarles. Es decir, hay que subir los precios.
Hacer un juego quizá sí. Un buen juego, no lo creo.