Como licenciar un motor

[Vicente]

Hola!

algunos por aqui sabeis que en la empresa donde estoy trabajando ahora (http://plainconcepts.es/) estamos haciendo un motor multiplataforma para desarrollar videojuegos. El lenguaje que se utiliza es C#, y el mismo codigo funciona directamente en PC, Xbox, WP7, iOS, y Android (y en breve en Windows 8 Metro).

Teniendo en cuenta la competencia que ya existe en este campo (Unity, Corona, Moai,...), que haria que la gente de este foro se interesara por este motor en cuestion de funcionalidades? Y en el tema de precios, cual es la forma que preferis a la hora de licenciar un software?

Estamos dandole muchas vueltas al tema, y todavia queda para que salga, pero por ir escuchando algunas opiniones Un saludo!

Vicente

[blau]

para poder contestarte tendrias que hacer una pequeña introducción del engine...

habrá que licenciar monotouch o monodroid ?
pensáis distribuir vosotros las apps o lo harán directamente los desarrolladores?

[TrOnTxU]

Para mi lo mejor de Unity3D es:

- Multiplataforma  (ya veo que estais en ello )

- Sistema de Game Object Components (en C# es muy fácil de hacer con herencia).

- Poder "editar de manera visual" los componentes de los GameObject.

- Crear nuevos componentes, es tan facil como derivar un objeto. Las "miembros" públicos se serializan siempre, lo que sirve para cargar/guardar automaticamente y se muestran en el inspector para su edición. (Esto también es fácil y sencillo, solo hay que tirar de reflexion al cargar/salvar y al "seleccionar" un gameObject, lo que muestra en el "inspector" su "contenido en componentes").
Como contrapartida se puede hacer con "Propiedades" en vez de con "Miembros Públicos" que es lo "típico" que inspecciona el "PropertyGrid".

- Scripts para modifcar la "Pipeline de Importación" de manera "relativamente sencilla" (bastante más que los importadores de XNA).

- Ampliación del "Editor". Crear nuevos menus, poder interaccionar con la mayoria de las interfaces de acceso del editor, etc.

- Provee "Abstracción de plataforma", para la mayoria de "requerimientos" de TRC/Lotcheck, y "classes especificas" para las "features" especificas de plataforma ("Acelerometro", "Wii Balance Board", etc).

- La "pro" ya tiene muchas cosas integradas: Umbra, el nuevo "Beast", Physix, ...



Y lo peor:

- Mono en consolas NO MOLA. El gc es una *****, he visto un artículo interesante sobre hacer un gc incremental para Mono http://static.usenix.org/event/vm04/wips/goh.pdf, pero tampoco me lo he mirado mucho, y no sé si te puede valer de algo, pero en fin ...

- La implementación del "Dynamic Game Object Component System" es "extradamente" OOP, cosa "reforzada" por el echo de los compoenetes MonoBehaivour, que "exportan" una interfaz puramente OOP.  Esto no seria malo, si no fuese por dos razones: dispositivos con caches pequeñas, y/o con PowerPC. Las cache misses van a ser un problema en todos los dispositivos con cache pequeñas, pero el "polimorfismo" da mayores signos de "ineficiencia" en PowerPCs, que en x86 o ARM.
Hay una implementación "muy curiosa", que utiliza Insomniac a partir para el "Resistance 1" y que se "establece" en el "Resistance 2". Es tremendamente más efectivo, DOD (aunque la interfaz puede parefcer OOP), cache friendly, multi-processor scalable, y permite offloads a SPUs.  http://www.insomniacgames.com/wp-content/uploads/2011/06/6-1-2010.pdf
Està en C++, y yo he probado implementar alguna cosa, aunque ahora tengo un sistema de GameObjects "light monolithic / static defined components" como el de Uncharted 2.
De todas formas, una de las cosas más interesantes, es el uso de las "Roster Pool", que yo he incluido en varios sistemas de nuestro engine (aunque en nuestro está en C++, la idea es muy parecida en C#).

- Dificil integración en algunos casos de un Sistema de Control de versiones para el manejo del "Content". El suyo propio no está mal, pero no es la panacea.



No sé si añadiria algo más, de todas formas es solo mi opinión.

Un saludo, y suerte!


PS: En cuanto a precios, no sé que decirte, pero varia bastante dependiendo de lo "cerrado" que puedas entregar el SDK o engine, cuando más código fuente tengas que pasar, más deberia de valer la licencia (por obvias razones).

[Vicente]

para poder contestarte tendrias que hacer una pequeña introducción del engine...

habrá que licenciar monotouch o monodroid ?
pensáis distribuir vosotros las apps o lo harán directamente los desarrolladores?

Usamos Monotouch y Monodroid para iOS y Android asi que si haria falta que el desarrollador tenga licencias de esto (si quiere distribuir en esas plataformas). En PC/Xbox/WP7 usamos XNA, y en W8 Metro un wrapper propio.

Y las aplicaciones las distribuirian los desarrolladores.

[Vicente]

Para mi lo mejor de Unity3D es:

- Multiplataforma  (ya veo que estais en ello )

Sip Hay mas cosas en mente (que si Vita, que si dispositivos Experia,...), pero son para un futuro lejano.

- Sistema de Game Object Components (en C# es muy fácil de hacer con herencia).

Sip, el motor esta basado en componentes totalmente. Una entidad es simplemente un contenedor de componentes.

- Poder "editar de manera visual" los componentes de los GameObject.

Estamos haciendo un editor visual, pero esta parte es un curro del quince

- Crear nuevos componentes, es tan facil como derivar un objeto. Las "miembros" públicos se serializan siempre, lo que sirve para cargar/guardar automaticamente y se muestran en el inspector para su edición. (Esto también es fácil y sencillo, solo hay que tirar de reflexion al cargar/salvar y al "seleccionar" un gameObject, lo que muestra en el "inspector" su "contenido en componentes").
Como contrapartida se puede hacer con "Propiedades" en vez de con "Miembros Públicos" que es lo "típico" que inspecciona el "PropertyGrid".

Sip, esto es igual que en Unity. Aunque guardar/salvar por serializacion asi a lo bruto hay veces que no vale (nos ha pasado en ByeByeBrain).

- Scripts para modifcar la "Pipeline de Importación" de manera "relativamente sencilla" (bastante más que los importadores de XNA).

Apuntado

- Ampliación del "Editor". Crear nuevos menus, poder interaccionar con la mayoria de las interfaces de acceso del editor, etc.

Esto es algo que nos ha dicho muchisima gente que usa Unity y lo tenemos en mente.

- Provee "Abstracción de plataforma", para la mayoria de "requerimientos" de TRC/Lotcheck, y "classes especificas" para las "features" especificas de plataforma ("Acelerometro", "Wii Balance Board", etc).

Esto lo hacemos un poco diferente. Queremos que en general todo funcione en cualquier sitio sin tocar ni una linea, asi que las clases especificas no existen por lo general. Excepto en el caso de sensores de moviles o touch, que no lo vamos a quitar porque no existan en la Xbox ya que es demasiado basico para los telefonos :S

- Mono en consolas NO MOLA. El gc es una *****, he visto un artículo interesante sobre hacer un gc incremental para Mono http://static.usenix.org/event/vm04/wips/goh.pdf, pero tampoco me lo he mirado mucho, y no sé si te puede valer de algo, pero en fin ...

Para soportar Wii/PS3 aun nos queda un huevo creo yo :S Le dare un vistazo al link

- La implementación del "Dynamic Game Object Component System" es "extradamente" OOP, cosa "reforzada" por el echo de los compoenetes MonoBehaivour, que "exportan" una interfaz puramente OOP.  Esto no seria malo, si no fuese por dos razones: dispositivos con caches pequeñas, y/o con PowerPC. Las cache misses van a ser un problema en todos los dispositivos con cache pequeñas, pero el "polimorfismo" da mayores signos de "ineficiencia" en PowerPCs, que en x86 o ARM.

Hay una implementación "muy curiosa", que utiliza Insomniac a partir para el "Resistance 1" y que se "establece" en el "Resistance 2". Es tremendamente más efectivo, DOD (aunque la interfaz puede parefcer OOP), cache friendly, multi-processor scalable, y permite offloads a SPUs.  http://www.insomniacgames.com/wp-content/uploads/2011/06/6-1-2010.pdf
Està en C++, y yo he probado implementar alguna cosa, aunque ahora tengo un sistema de GameObjects "light monolithic / static defined components" como el de Uncharted 2.
De todas formas, una de las cosas más interesantes, es el uso de las "Roster Pool", que yo he incluido en varios sistemas de nuestro engine (aunque en nuestro está en C++, la idea es muy parecida en C#).

Interesante esto de los fallos de cache. Desgraciadamente es cierto que nuestra jerarquia de componentes es puro OOP.

- Dificil integración en algunos casos de un Sistema de Control de versiones para el manejo del "Content". El suyo propio no está mal, pero no es la panacea.

Este problema no intentamos ni resolverlo, nosotros usamos TFS, tambien hemos cotilleado Plastic,... No tenemos tanta gente como para intentar resolver este problema :S

No sé si añadiria algo más, de todas formas es solo mi opinión.

Un saludo, y suerte!

Se agradece y gracias

PS: En cuanto a precios, no sé que decirte, pero varia bastante dependiendo de lo "cerrado" que puedas entregar el SDK o engine, cuando más código fuente tengas que pasar, más deberia de valer la licencia (por obvias razones).

La idea es dar un instalador, instalas y a currar. El instalador se deberia pegar con todas las configuraciones que hagan falta. Sobre los fuentes, es un punto polemico :p

Un saludo!

Vicente

[TrOnTxU]

Pues la verdad es que tiene muy buena pinta

Siento no poder ayudarte con lo de los precios

Ya contarás como va!

Un saludo.

[YaW]

¿Va a ser enfocado a 2D o 3D (supongo)?

La verdad es que si es 3D tenéis una competencia bastante feroz, teniendo Unity bastante barato y también UDK y demás es muy complicado destacar. Si es 2D si que sería más interesante porque lo único "grande" es Corona y a mi personalmente no me agrada mucho...

[Vicente]

¿Va a ser enfocado a 2D o 3D (supongo)?

La verdad es que si es 3D tenéis una competencia bastante feroz, teniendo Unity bastante barato y también UDK y demás es muy complicado destacar. Si es 2D si que sería más interesante porque lo único "grande" es Corona y a mi personalmente no me agrada mucho...

Esta enfocado a 3D principalmente porque nuestro primer juego interno que hicimos con el motor era 3D. Ahora estamos metiendole mano al 2D, pero esta mucho mas verde por lo general (aunque el tema de la animacion esta muy bien).

Por cierto que el motor esta enfocado a estudios pequenos, y para ese tipo de estudios la version Free de Unity3D si me parece que tiene un precio barato (800$), pero la Pro no (4500$ por desarrollador me parece mucho dinero).

Un saludo!

Vicente

[Eskema]

Es dificil decir que tendria que tener para ser interesante. Si lo enfocas a los indies el precio es un punto importante. Pero sobre todo la imagen de marca, si voy a comprar algo con codigo cerrado como el unity. ¿Que me garantiza que el año que viene no chapais el negocio?, ¿si se chapa el negocio liberais los fuentes para que la gente no se quede colgada?. Yo empeze usando el motor SIO2 para IOS, cuando salio la version de pago decidi dar el salto a unity, pues prefiero pagar la pasta en algo mas "profesional" y serio de lo que era SIO2.
Lo malo de cualquier engine cerrado es el hecho de tener que aprender a manejarlo, como de rapido los autores arreglen los bugs que puedan salir, como de facil es acceder a cosas nativas del device en cuestion, por ejemplo en mi caso como podria acceder al acelerometro, iads, icloud,gamecenter,etc,etc.

Una de las cosas buenas de unity es la cantidad de middleware que existe que a la hora de hacer un juego, te ahorra mucho curro el comprar una solucion de IA, o pathfinding o alguna otra cosa del estilo.
En el lado malo esta el precio, 4500$ (mas aparte IVA) no son moco de pavo, yo en mi caso no tengo la licencia pro y me las apaño con la basica, lo cual es una mierda porque no tengo acceso al profiler y otros goodies de la version pro.

[XÑA]

Mira, yo estoy más o menos en tu situación. MonoGame es 100% 2D, aunque están pegando el salto a 3D y es gratis.
Pero piensa que la gente ya ha tenido que pagar el monotouch, así que tienes que enfocarlo a profesionales. Pero eso sí, yo quiero que funcione y tener soporte. Si es así...¡bienvenido!

[Vicente]

Es dificil decir que tendria que tener para ser interesante. Si lo enfocas a los indies el precio es un punto importante. Pero sobre todo la imagen de marca, si voy a comprar algo con codigo cerrado como el unity. ¿Que me garantiza que el año que viene no chapais el negocio?, ¿si se chapa el negocio liberais los fuentes para que la gente no se quede colgada?. Yo empeze usando el motor SIO2 para IOS, cuando salio la version de pago decidi dar el salto a unity, pues prefiero pagar la pasta en algo mas "profesional" y serio de lo que era SIO2.

Totalmente de acuerdo con esto la verdad. En el trabajo donde estaba anteriormente sufri ambas cosas (un proyecto de pago que murio y no teniamos los fuentes y nos quedamos colgados, y un proyecto open source donde nadie daba soporte ni respondia dudas) y es algo por lo que no quiero volver a pasar. Dar los fuentes si todo se cierra es un compromiso razonable, dar los fuentes con las licencias es algo que esta en el aire porque siempre cuesta (que si me van a copiar, etc etc).

El tema de "profesional" me interesa, porque es la imagen que queremos dar. Tenemos ideas sobre como dar esa imagen (un buen instalador, una buena documentacion, buenos samples,...) pero que mas ayuda a dar esa imagen (y seguridad) de profesionalidad?

Lo malo de cualquier engine cerrado es el hecho de tener que aprender a manejarlo, como de rapido los autores arreglen los bugs que puedan salir, como de facil es acceder a cosas nativas del device en cuestion, por ejemplo en mi caso como podria acceder al acelerometro, iads, icloud,gamecenter,etc,etc.

Aqui esta un poco lo que comente antes sobre que intentamos que todo funcione sobre todas las plataformas (en particular las moviles). Asi que cosas genericas (mostrar publicidad, todas las plataformas tienen publicidad) pues esta soportado, y cosas mas especificas de cada plataforma de momento es algo que el usuario tendria que resolver por si mismo.

Una de las cosas buenas de unity es la cantidad de middleware que existe que a la hora de hacer un juego, te ahorra mucho curro el comprar una solucion de IA, o pathfinding o alguna otra cosa del estilo.
En el lado malo esta el precio, 4500$ (mas aparte IVA) no son moco de pavo, yo en mi caso no tengo la licencia pro y me las apaño con la basica, lo cual es una mierda porque no tengo acceso al profiler y otros goodies de la version pro.

Lo del middleware de Unity es una triunfada. El conseguir montar una comunidad de gente que viva no de usar tu motor, sino de crear contenido para los usuarios de tu motor es la leche. El objetivo seria llegar a ese punto, pero obviamente es algo a muuuy largo plazo

Un saludo!

Vicente

[Vicente]

Mira, yo estoy más o menos en tu situación. MonoGame es 100% 2D, aunque están pegando el salto a 3D y es gratis.
Pero piensa que la gente ya ha tenido que pagar el monotouch, así que tienes que enfocarlo a profesionales. Pero eso sí, yo quiero que funcione y tener soporte. Si es así...¡bienvenido!

Sip, esta claro que tenemos que ofrecer algo mas que MonoGame porque sino vaya desastre de producto :p El soporte es algo que esta claro que es imprescindible, todo el mundo prefiere evitar si puede el pegarse con una herramienta y que cuando tenga dudas o problemas que no haya manera de que se las resuelvan.

Tambien es cierto que la gente para usarnos ya tendria que haber pagado algo para las licencias de Xamarin, asi que asumimos que es gente que tiene un interes serio por desarrollar un producto y ponerlo en un market, no alguien que nos usa por casualidad. Tambien asumimos que es alguien que si nos usa se ha informado un poco del mercado, alternativas,...

Un saludo!

Vicente

[XÑA]

Soporte directo!!!! Eso es lo que más valoro. Porqué yo me estoy pegando con monotouch y aunque tiene un  buen soporte, no es una persona que está al otro lado del teléfono.
¿Porqué no lo enfocas así? Producto gratis, lo que cuesta es el soporte. Software as a service!!!

Eso sí...¿Cómo das a conocer tu producto? Sólo se me ocurre a base de muchos productos que estén en el mercado.

También está lo que hacen los de Corona y los de Delta Engine. Me enfocaré en los de Delta. Ellos te compilan el código!! Eso es, sencillamente lo mejor con diferencia. Porqué tu te olvidas completamente de configuraciones y rollos raros. Sin embargo...¿y el debug en el device? 

Ya te digo que los que están dispuestos a pagar SABEN que el tiempo es dinero. Si tu producto FUNCIONA sin rollos raros, pagarán!! 

[AgeR]

Si la gente ha de pagar otra licencia (MonoTouch, etc...) además de la de vuestro motor... no le veo futuro, la verdad. Pensad que a la gente ya le cuesta pagar por una cosa, pagar por dos para obtener una lo veo una locura.

Precio, lo ideal sería una licencia gratuita para PC, para poder evaluar y trastear con el invento, y luego licencia de pago para dispositivos (si entrara iOS y Android en una misma licencia, tendríais puntos extra...).

De todos modos, los estudios pequeños van a optar por algo más asentado, a ser posible gratuito o con un coste ridículo.

[Vicente]

Soporte directo!!!! Eso es lo que más valoro. Porqué yo me estoy pegando con monotouch y aunque tiene un  buen soporte, no es una persona que está al otro lado del teléfono.
¿Porqué no lo enfocas así? Producto gratis, lo que cuesta es el soporte. Software as a service!!!

Es una de las ideas que esta sobre la mesa y es bastante interesante, pero hay que tener en cuenta que el soporte directo y personalizado es MUY caro. Por ejemplo la gente de Corona vende horas de soporte al precio de 750$ por 5 horas (ademas del coste de la licencia, que tambien es de pago).

Eso sí...¿Cómo das a conocer tu producto? Sólo se me ocurre a base de muchos productos que estén en el mercado.

El tener muchos productos en el mercado realizados con tu tecnologia ayuda a que se considere seria y fiable, y al principio lo que tendremos que hacer es mostrar nuestros propios proyectos in-house hasta que consigamos que otra gente nos utilice. Vamos, usar nuestros proyectos como escaparate del motor. La gente de Moai ha hecho esto un poco (y los de Delta intentaban lo mismo).

También está lo que hacen los de Corona y los de Delta Engine. Me enfocaré en los de Delta. Ellos te compilan el código!! Eso es, sencillamente lo mejor con diferencia. Porqué tu te olvidas completamente de configuraciones y rollos raros. Sin embargo...¿y el debug en el device? 

Sobre lo de compilar en la nube que hacia Delta, es un cumulo de cosas creo yo. Por ejemplo, para usar Delta en Android necesitarias una licencia de Monodroid para poder compilar, pero... Y si lo compilan ellos y te devuelven el ejecutable? Entonces el usuario ya no necesita pagar la licencia de Monodroid para nada, y puedes hacer tu producto mas barato (habria que revisar las licencias de Xamarin para saber si esto es viable o no).

Eso si, montar y mantener la infraestructura para compilar en la nube tiene bastante trabajo.

Ya te digo que los que están dispuestos a pagar SABEN que el tiempo es dinero. Si tu producto FUNCIONA sin rollos raros, pagarán!! 

Jejeje, totalmente de acuerdo. Pero tambien la gente que va a pagar por un producto investiga todas sus opciones antes de gastarselo, asi que es interesante saber que busca la gente cuando busca algo de pago. Hay cosas que no vamos a ofrecer (yo quiero usar C++!) y otras que si ofrecemos pero que lo mismo no hemos evaluado correctamente y las estamos prestando demasiada mucha o demasiada poca atencion.

Un saludo!

Vicente