Monetizando en verso

[notbad]

Unity es un engine orientado a gente sin altos conocimientos de programación y que para cosas muy sencillas casi puedes hacerlo en drag & drop.

Bueno, entro sólo porque me chirría esto xD Es un calco de la sintaxis ya que C# viene un poco de Java. Pero C# tiene cosas muy distintas a Java tanto en sintaxis como en cómo se usan ciertas clases en concreto.
Ahora bien, en Unity C# se usa como si fueran scripts y no como POO, así que da lo mismo xD

Discreto bastante de tu respuesta. Unity es un engine que permite a gente sin conocimientos de programación usar su super editor, ciertos assets como playmaker, etc... y poder hacer cosas decentes. De ahí a que esté orientado a gente sin altos conocimientos de programación va un trecho. Es más, es usado por muchos programadores experimentados en C++, etc.... El uso de un sistema de script no siempre implica que vaya a ser usado por programadores nóveles. A parte de que se pueden añadir librerías en unmanaged, etc... para irte un poco más allá. Digamos que tiene un stack de uso donde se puede cavar para abajo un buen trozo .

No entiendo la parte de que Unity C# se usa como si fueran scripts O_o. Unity está basado en un sistema de componentes de toda la vida (bueno de toda la vida desde que la gente del Dungeon Keeper le dio un empujón al paradigma cuando salio el juego hace ya tela). Visto de una forma simplista, se basa en agregación. Vaya, si esto no es un termino usado fuertemente en POO ya me dirás. El sistema sigue siendo POO puro. Es un sistema totalmente desacoplado con sus ventajas y desventajas pero esto no influye para nada en que el lenguaje usado inste a la POO o no.

Un saludo.

-----Actualizado-----

Obviamente no he profundizado en C# aun, pero visto lo visto no he necesitado ni que me den clase para programar scripts.
Y a eso es a lo que voy: Unity es muy visual, la programación interviene muy poco (repito, visto lo visto), y yo que vengo de programación "a saco" (Bennu ayuda mucho, pero al lado de cualquier motor de este tipo es como programar en C) pues me parece hasta raro. Antes cada proceso podía tener o no un único gráfico, en Unity es al revés, cada GameObject puede tener un script (o más) o no, pero no puede haber un script sin GameObject, Y olvídate de la estructura general de un programa: carga una escena, y automáticamente se ejecutarán los scripts, no existe el concepto "main"... Y aun tengo que averiguar cómo compartir datos entre escenas.

Unity es muy visual porque tiene un editor de 10. Lo mejor que he visto hasta ahora (baso mi respuesta en features y sencillez de uso). El de UE4 está muy chulo también pero le queda una vuelta aún en la usabilidad.

Sobre lo del concepto main, realmente si existe si ese es el enfoque que quieres dar. Tan solo que si se siguiera ese concepto tiraríamos por la borda unos de los pilares del engine. Para emular un main en unity, crea un script que sea el único que implementa awake y haz todas las burradas que quieras ahí. Será este metodo pues el primero en ejecutarse y después los start de todo lo que crees. La verdad, no vale la pena. Es lo mismo que siempre se hablado de tener un Update por objeto o un solo update en la escena que refresca la lógica internamente.

Para compartir datos entre escenas puedes usar el PlayerDefs por ejemplo. O tener un objecto con Don't Destroy on load y mantenerlo tú entre carga de escenas, etc... etc... Hay varias formas.

Un saludo.

[Drumpi]

A ver, Unity es un entorno que permite crear juegos casi sin programar. De hecho, he creado un plataformas con un coche sin usar scripts, sin programar físicas ni hacer nada de lo que requiere programación. Vamos, que en un par de horas (sin contar el tiempo de crear los objetos) he hecho lo que sin Unity se haría en un mes con ámplios conocimientos de física.
Hace años me dijeron que "programar juegos con DIV no era programar" y me sentó como un tiro. Pero Unity es que no tienes que escribir siquiera una línea de código, literalmente Está muy bien para desarrollar juegos, eso seguro, pero pierde toda la gracia de escribir tu código y tus optimizaciones... a menos que quieras prescindir de partes que ya trae el propio entorno.

Dado mi perfil de desarrollador de juegos y niveles, es perfecto, pero si quiero programar y usar código y controlarlo todo (porque con Unity tienes que jugar según sus reglas) prefiero usar BennuGD.

[TRaFuGa]

Para gustos los colores, a mi unity me gusta porque me permite hacer lo que yo quiera sin tener unos conocimientos avanzados, eso tiene sus pros y sus contras, pero a mi me parece una herramienta cojonuda. Lo sigo desde 2008 antes de que saliera la primera versión para pc, aunque hasta ahora no me puesto a tocarlo seriamente. He usado div, bennugd/fenix y darkbasic, y para las 3D necesitaba algo comp Unity, un entorno en el que poner tu mapa y tus objetos de manera visual.

[Segata Sanshiro]

En Unity se podrán hacer cosas sin saber apenas usarlo, pero eso no quiere decir ni que esté orientado solo a gente con escasos conocimientos ni que esté muy limitado en cuanto a lo que puedes hacer. Si quieres hacer un juego que se acerque a la calidad de un triple A en Unity puedes, pero necesitas los mismos conocimientos avanzados que si lo hicieras con un motor en C++, especialmente en cuanto a programación de gráficos.

[Drumpi]

Estoy de acuerdo, Unity es una muy buena herramienta, especialmente si se compara con otras que son mucho más limitadas, orientadas a un estilo de juego.
Y en principio se puede hacer un juego triple A sin demasiados conocimientos, lo dicho, ya integra el motor PhysX ese de NVidia, el motor gráfico, herramientas para cambio de calidad con la distancia... 1000 motores diferentes que requerirían dos o tres equipos de programadores experimentados si hubiera que hacerlo de cero.
Pero el problema de no tener control total sobre lo que haces es que pierdes rendimiento a marchas forzadas. Hacer un Pong en Unity se puede, pero no intentes meterlo en un Pentium3 porque se muere (lo mismo exagero, aun no conozco los límites de Unity). El simple hecho de no desmarcar una casilla puede significar el usar 100MB de RAM que no necesitas, eso es aun más peligroso.

Y no lo voy a negar, me parece una herramienta excelente, de hecho, me estoy planteando hacer, por fin, mi Sonic R/Drift como TFM extra yo solo, que lleva en la pila de proyectos desde el 2001 y nunca he tenido los medios/conocimientos para ello. Ahora todo el trabajo se centraría en modelar 3D y animar (pero yo soy yo y empezaré a programar cosas innecesariamente o sólo por gusto ).

[TRaFuGa]

Podéis ir probando mi "juego" en versión web: http://adanoliva.com.es
Acepto sugerencias, criticas (constructivas xD) y valoraciones para poder mejorarlo. A falta de: Mejorar la GUI, ponerle sonido y cambiar el método de spawn de los objetos por una pool (ahora se estan creando y destruyendo), lo dejaré listo para subirlo al play store (bueno, también falta meterle algo de publi, a ver que tal va la cosa).
Quería hacer otro modo de juego, pero eso ya para más adelante, que ahora entre el curro y la niña apenas puedo dedicarle tiempo al proyecto (normalmente, de 1 a 2 horas semanales, así que va muy lenta la cosa...).
Estoy seguro que con cualquier otra herramienta, no hubiera podido hacer esto en este tiempo, ni con la facilidad que me ha supuesto...

[kiero]

mi primera crítica es que no tengo instalado el unity web player para probar el juego.
nada, si no se me olvida intentaré probarlo más adelante en otro ordenador.

[josepzin]

Yo tampoco tengo el player ese y me da bastante.pereza ponerlo... :-S

[notbad]

En Unity se podrán hacer cosas sin saber apenas usarlo, pero eso no quiere decir ni que esté orientado solo a gente con escasos conocimientos ni que esté muy limitado en cuanto a lo que puedes hacer. Si quieres hacer un juego que se acerque a la calidad de un triple A en Unity puedes, pero necesitas los mismos conocimientos avanzados que si lo hicieras con un motor en C++, especialmente en cuanto a programación de gráficos.

Hombre Drumpi. Llegados a este momento yo te ofrezco esto:

486
.MODEL FLAT
.CODE
PUBLIC _myFunc
_myFunc PROC
; Subroutine Prologue
push ebp ; Save the old base pointer value.
mov ebp, esp ; Set the new base pointer value.
sub esp, 4 ; Make room for one 4-byte local variable.
push edi ; Save the values of registers that the function
push esi ; will modify. This function uses EDI and ESI.
; (no need to save EBX, EBP, or ESP)

; Subroutine Body
mov eax, [ebp+8] ; Move value of parameter 1 into EAX
mov esi, [ebp+12] ; Move value of parameter 2 into ESI
mov edi, [ebp+16] ; Move value of parameter 3 into EDI

mov [ebp-4], edi ; Move EDI into the local variable
add [ebp-4], esi ; Add ESI into the local variable
add eax, [ebp-4] ; Add the contents of the local variable
; into EAX (final result)

; Subroutine Epilogue
pop esi ; Recover register values
pop edi
mov esp, ebp ; Deallocate local variables
pop ebp ; Restore the caller's base pointer value
ret
_myFunc ENDP
END




Empezando que para cualquier cosa que no tenga unity tienes 2 opciones:

1) Currartela en C# (Lenguaje de script que no genera código nativo....)
2) Currartela en C++ y luego integrarlo con managed code

Pues que quiers que te diga, si quieres hacer juegos para una máquina
de 15 años pues no es para eso.

Unity te da una serie de herramientas para juegos de amplio espectro en cuanto
a pontencia. Pero está claro que no es lo mismo que programar con un lenguaje
que produzca nativo (!). Por que pongo una exclamación? Por que unity está
trabajando en un cross compiler que según promenten si lo hará. Así que ya veremos.

Por otro lado discrepo contigo con la frase "se puede hacer un
triple AAA sin tener mucha idea". Tú y yo tenemos conceptos diferentes de
triple A creo. Unity facilita las cosas pero ni de coña hasta ese nivel.

Un saludete.

[Drumpi]

Bueno, voy a tener que activar mi traductor de códigos para entender lo que has puesto, pero la verdad es que no son horas ^^U

De todas formas, voy a intentar poner las cosas claras:
Unity es un motor multiplataforma, lo que indica ya de por sí es que, por mucho que se intente, y se use la plataforma que se use, el juego o aplicación generado no va a ser 100% eficiente, bien porque no use determinadas funciones avanzadas de la gráfica, porque sea incapaz de usar un chip acelerador de cálculos, o porque no tiene acceso a diversas partes de la memoria del dispositivo. Si encima usa código de script (cosa que aun tengo que averiguar, porque creo que hace compilación de algo en plan "máquina virtual"), peor, porque interpretar comandos en lenguaje humano resta eficiencia... a menos que las CPU incorporen actualmente funciones de parseo y no me haya enterado.

¿Que Unity no es para máquinas de hace 15 años? Pues estamos en un serio problema, porque salvo los de gama alta, los móviles que se venden es la potencia que tienen, especialmente si queremos que un juego se ejecute en el mayor número de plataformas posibles. Mi tablet es mononúcleo de 800MHz, mi próximo móvil va a ser de doble núcleo y hace 15 años empezábamos con los dual-cores.

Repito: sí, Unity es genial para hacer juegos, Y Bennu es mejor incluso para juegos 2D, porque funciona incluso en GP2X. Y si nos ponemos con C y SDL, OpenGL o DirectX (o XNA o como se llame ahora) el juego funcinará en cualquier máquina, pero sería una barbaridad porque nos tiraríamos 5 años para hacer lo que en Unity se hace en 10 minutos. Cada cosa para lo que es.

Y sí, creo que se puede hacer un triple A con Unity fácilmente, al menos por el lado de la programación, porque insisto, trae integradas muchísimas herramientas que hace 5 años eran ciencia ficción ¿Tienes que programar las físicas? ¿La distancia de dibujado? ¿El gestor de calidad de modelos con la distancia? ¿hacer los cálculos de la niebla volumétrica? ¿Qué tal detectar las colisiones? Tu junta a 50 aficionados a crear videojuegos, dales la centésima parte de lo que cuesta una superproducción, Unity y te dejan a muchos "triple A" a la altura del betún.
Es más, el otro día en clase, habiendo usado Unity un total de 5 horas, fui capaz de hacer que un coche diese la vuelta en un looping, algo que tras 13 años programando, aun no he sido capaz de hacer con Fenix o Bennu. Y en Unity era un espacio 3D, no 2D como todos mis juegos.

Insisto, notbad, no es un ataque a Unity, ni un menosprecio, es sólo que estoy acostumbrado a saber qué es lo que uso y que busco rendimiento por "deformación profesional". También Java permite usar módulos programados en C y aun así me parece uno de los lenguajes menos eficientes que conozco, está justo por detrás de Flash

[notbad]

Bueno, voy a tener que activar mi traductor de códigos para entender lo que has puesto, pero la verdad es que no son horas ^^U

De todas formas, voy a intentar poner las cosas claras:
Unity es un motor multiplataforma, lo que indica ya de por sí es que, por mucho que se intente, y se use la plataforma que se use, el juego o aplicación generado no va a ser 100% eficiente, bien porque no use determinadas funciones avanzadas de la gráfica, porque sea incapaz de usar un chip acelerador de cálculos, o porque no tiene acceso a diversas partes de la memoria del dispositivo. Si encima usa código de script (cosa que aun tengo que averiguar, porque creo que hace compilación de algo en plan "máquina virtual"), peor, porque interpretar comandos en lenguaje humano resta eficiencia... a menos que las CPU incorporen actualmente funciones de parseo y no me haya enterado.

¿Que Unity no es para máquinas de hace 15 años? Pues estamos en un serio problema, porque salvo los de gama alta, los móviles que se venden es la potencia que tienen, especialmente si queremos que un juego se ejecute en el mayor número de plataformas posibles. Mi tablet es mononúcleo de 800MHz, mi próximo móvil va a ser de doble núcleo y hace 15 años empezábamos con los dual-cores.

Repito: sí, Unity es genial para hacer juegos, Y Bennu es mejor incluso para juegos 2D, porque funciona incluso en GP2X. Y si nos ponemos con C y SDL, OpenGL o DirectX (o XNA o como se llame ahora) el juego funcinará en cualquier máquina, pero sería una barbaridad porque nos tiraríamos 5 años para hacer lo que en Unity se hace en 10 minutos. Cada cosa para lo que es.

Y sí, creo que se puede hacer un triple A con Unity fácilmente, al menos por el lado de la programación, porque insisto, trae integradas muchísimas herramientas que hace 5 años eran ciencia ficción ¿Tienes que programar las físicas? ¿La distancia de dibujado? ¿El gestor de calidad de modelos con la distancia? ¿hacer los cálculos de la niebla volumétrica? ¿Qué tal detectar las colisiones? Tu junta a 50 aficionados a crear videojuegos, dales la centésima parte de lo que cuesta una superproducción, Unity y te dejan a muchos "triple A" a la altura del betún.
Es más, el otro día en clase, habiendo usado Unity un total de 5 horas, fui capaz de hacer que un coche diese la vuelta en un looping, algo que tras 13 años programando, aun no he sido capaz de hacer con Fenix o Bennu. Y en Unity era un espacio 3D, no 2D como todos mis juegos.

Insisto, notbad, no es un ataque a Unity, ni un menosprecio, es sólo que estoy acostumbrado a saber qué es lo que uso y que busco rendimiento por "deformación profesional". También Java permite usar módulos programados en C y aun así me parece uno de los lenguajes menos eficientes que conozco, está justo por detrás de Flash

Te puedo asegurar drumpi que no soy un fanboy de Unity. Si es lo que parece no es por donde voy. Cada uno da su opinión sobre el tema.

A mí es que creo que a veces se confunde la rapidez de hacer algo visible con lo que cuesta de crear algo AAA. Estoy de acuerdo que puedes hacer lo que comentas del vehículo y tal rapidamente, pero ahora pasa de eso a hacer un forza motosport, gran turismo, etc... un trecho no, 2 mares.

Por otro lado, hoy día es complicado aquel que se ponga a crear su propio motor de físicas (por poner un ejemplo) por que piense que lo va a hacer correr más rápido que los que hay en casi cualquier plataforma.

El tema de la optimización es muy peliagudo. Mucha de la culpa de que algo no corra como debe es del programador que queriendo optimizar al milimetro lo que obtiene el efecto contrario o no utiliza patrones básicos en un videojuego como object pooling, etc... La optimización solo para cuando haga falta y en un juego, igual que en muchos otros tipos de aplicaciones al final solo hace falta meter mano en unos cuantos procesos que son ejecutados por frame (normalmente).

Sobre lo de los 15 años, te has cogido ahí como un clavo ardiendo . Unity y muchos engines no funcionan de la misma forma internamente para un dispositivo móvil y escritorio. Funcionan bastante relajadamente en estos primeros, así, que yo me refería a escritorio .

Bueno, espero que te le sigas dando caña y dentro de poco nos enseñes algo bueno en unity3d. Por mi parte y si te gusta trastear a mi me encanta cocos2d-x también.

Un saludo.

[Drumpi]

Tampoco eran lo mismo los Windows de las agendas electrónicas y de sobremesa, y todos sabemos cómo apestaban los primeros (y los segundos también, en según qué casos ).

Una cosa está clara: los triple A son aquellos que se gastan un pastón en que un juego parezca la realidad. Se gastan presupuestos millonarios en físicas ultra-realistas (que ya ves, tienes el PhysX por HW para los cálculos matemáticos en PC), en horas de videos prerender, semanas en crear modelos hi-poly (que luego se reducen a la tercera parte), dinerales en dobladores famosos y orquestas sinfónicas... y a todos les patea el trasero el Candy Crush que podría hacer un novato en un mes en sus ratos libres.

Y por eso me gusta Unity, como Bennu, te permite centrate en el juego, en lo divertido, y no en presumir. Un aprendiz de actor le va a poner más interés que un actor de renombre en las voces por su motivación (otra cosa es la experiencia y que lo haga bien, pero para eso están los castings), hay música en OC-Remix que le dan mil vueltas a algunos temas orquestados y lo han hecho entre una y cinco personas, y el estilo retro-pixelado tiene legiones de seguidores. Se gastan millones por presumir y darle publicidad en plan "con la voz de...". Que sí, es interesante tener una voz famosa, pero en un juego, especialmente fuera de EEUU, poca gente reconoce al famoso de turno.

Para el trabajo de fin de Máster me estoy planteando en serio hacer un juego por mi cuenta (aparte del que tengo con el grupo), y aun no tengo claro si hacer un Stunt Race FX o un Sonic R, con una calidad gráfica similar

[turco]

Pues en mi caso, por nombrar otra opción, he utilizado LibGDX para mis juegos (aprovechando que conozco Java) y la verdad es que me ha encantado. Sobre lo de monetizar... yo he probado dos juegos con publicidad en AdMob, y acabo de sacar una versión Premium (0'88€) de uno de ellos a ver si deja algo más. Lo cierto es que no gano ni 30 céntimos al día

[notbad]

Pues en mi caso, por nombrar otra opción, he utilizado LibGDX para mis juegos (aprovechando que conozco Java) y la verdad es que me ha encantado. Sobre lo de monetizar... yo he probado dos juegos con publicidad en AdMob, y acabo de sacar una versión Premium (0'88€) de uno de ellos a ver si deja algo más. Lo cierto es que no gano ni 30 céntimos al día

Yo he probado LibGDX y me ha gustado también. Aunque prefiero cocos2d-x. El problema que vea es la falta de un editor de escenas decente. Ya se que importan tmx y que puede ser vervir pero es que ves cosas como esta en unity3d:

http://forum.unity3d.com/threads/fer...n-tool.204436/

Y es que mola un montón. Y ya te dan esa tecnología hecha (Muy parecida a la que tienen en el motor de ubisoft).

También es verdad que libGDX es más un framework que un game engine pero bueno, si se lo currarn un poco más con un editor mucha gente haría el switch. Por otro lado godot promete también.

Drumpi: Esos juegos que nombras molan . Yo quiero verlos cuando los hagas .

Un saludo.

[Drumpi]

Mola la herramienta esa, voy a tener que apuntármela, aunque se me antoja "cara" y tiraría de un clásico mio (ejemejemmapasdetilesejemujum, que tos más mala).
Aunque parece que a Unity le sale competencia de la buena, porque han liberado el Unreal Engine 4, que es un nombre de los gordos, y me consta que hay muchísima gente que ha usado los anteriores, de una forma o de otra, tanto de forma profesional como amater. Y creo que incluía el código fuente, por lo que los mods y los plugins se van a disparar.

Respecto a los juegos de fin de Máster, @notbad, recuérdamelo a finales de año, que es cuando se supone que deben estar entregados Lo que aun tengo que decidir es si usar coches que saltan o animales antropomórficos sin copyright.