PDA

Ver la versión completa : [PROGRAMACION] flame wars al canto, Unity3D vs corona vs programacion de "machotes"



Eskema
01/11/2012, 16:37
Hoy me levantado y hablando con un amigo artista me ha tocado mucho los webos su percepcion del "yo hago juegos en 1 semana o menos y no soy programador, seguro que tu en 2-3 dias lo haces". Al preguntarle que clase de mierda hacia me enseño corona, un entorno multiplataforma en java que sirve para hacer tu juego en iOS y android via lua como lenguaje de script.

Sin entrar a valorar mucho el hecho de que en 1 semana por muy drag'n drop que sea el entorno no haces un juego de calidad ni de coña, he ido a investigar que carajo era corona y he descubierto un mierdazo del quince que necesita pasar por la web para compilar tu ejecutable y probarlo en el device real, ademas no hay acceso a codigo nativo, asi que si los de android o ios sacan un nuevo gamecenter te tienes que esperar hasta que los señores de corona decidan darle soporte y añadir una funcion tipo usar.nuevogamecenter()
Desde luego esto me parece ideal para críos o gente que quiere hacer algo, pero no para un programador de verdad.


Ahora en el otro lado yo uso Unity3D a diario y no me siento menos hombre ni menos programador por usar un sistema que hace que me olvide de opengl/directX para centrarme en programar la mecanica de mi juego, ni tengo que pegarme para incluir box2d, bullet u otra libreria de colisiones (por poner un ejemplo), sin embargo algunos programadores amantes del "juan palomo yo me lo guiso yo me lo como" esto les parece un insulto.
El sistema se programa en C# y tengo acceso a casi todas las cosas internas para dibujar los modelos o aplicarles fisicas como me de la gana, o bien acceder a codigo nativo de ios, por lo que yo veo un sistema completo que no capa al programador como si hace corona y que sin programacion de verdad no haces nada.

Asi que por tocar un poco los "cohones" y por aburrimiento y ganas de crear un flame yo preguntaria, ¿que es programar?, ¿tan malo es tener un sistema como unity3d que me abstrae del main render loop y del main update loop donde solo me dedico a la logica de mi juego?, porque los mitos de "yo lo hago todo a pelo que va mas rapido" no son mas que mitos infundados

^MiSaTo^
01/11/2012, 16:51
Sólo añadir que Unity3D usa C# si, pero no como se debe hacer sino a modo de "scripts". No se si has programado alguna vez en C# pero con Unity pierdes muchas cosas buenas de la POO y sobre todo del lenguaje en sí (aka lambda expressions no se si las puedes usar tan alegremente).
Para mi es programar igual sí, pero no deja de ser scripting que es bastante más sencillo que "programar de verdad" (no se cómo llamarlo sin que suene ofensivo de verdad).

Hay otros muchos motores 3D que no usan scripting. Es más, el unreal por ejemplo, la versión "free" es un poco como Unity3D todo drag&drop y scripts por aquí que hacen magia y tu juego funciona. Ahora bien, quieres usar Unreal en la ps3/360? pues a dejarte los codos con c++. Nada de scriptcitos y drag & drop xD (Es así porque lo he vivido de primera mano vaya).

La diferencia entre ambas cosas, es que Unity3D está pensado para diseñadores o alguien que no tiene tanta idea de programar, para que le sea fácil y rápido de hacer. Mientras que lo otro está más orientado a programadores. Con esto no digo que sea mejor o peor o más o menos macho cuidao, ahora hablo sin ganas de trolear, sino que son 2 enfoques distintos. Hace relativamente poco busqué tutoriales de Unity3D en google y la gran mayoría estaban muy enfocados a diseñadores y maquetadores web. En serio.

A mi personalmente una herramienta que no se lo que hace por dentro... no me gusta nada. Y Unity, no se lo que hace, para mi es magia.
Y bueno, una herramienta que tiene que tirar de monodevelop, pero luego tienes que abrir Xcode pa que te rule en iOS y blablabla... Me parece chapucera. Claro, si quieres algo multiplataforma también es verdad que no tienes mucha más opción... De todos modos es lo que tienen las cosas multiplataforma, que como he dicho 200 veces, no puedes pedirles más ni esperar que vaya igual de bien que algo "nativo". En el caso de Unity no puedo criticar porque hice un arkanoid 3D por probarlo, no me gustó y lo mandé al peo. Por tanto no puedo comparar con otro motor a ver si va mejor o peor (en cuestión de rendimiento) pero me imagino que irá peor que haciendolo nativo con C/C++/Obj-C y OpenGL

GameMaster
01/11/2012, 17:02
29164

-----Actualizado-----

"Unity3D está pensado para diseñadores o alguien que no tiene tanta idea de programar..."

Pero que dices ? Unity3D esta pensado para hacer juegos grandes y profesionales con menor esfuerzo porque ya te da muchas cosas, no significa que esta hecho para porgramadores novatos, pero si para facilitar crear juegos que de otro modo te llevaria un par de años más...

^MiSaTo^
01/11/2012, 17:05
29164

-----Actualizado-----

"Unity3D está pensado para diseñadores o alguien que no tiene tanta idea de programar..."

Pero que dices ? Unity3D esta pensado para hacer juegos grandes y profesionales con menor esfuerzo porque ya te da muchas cosas, no significa que esta hecho para porgramadores novatos, pero si para facilitar crear juegos que de otro modo te llevaria un par de años más...
No es cierto, con Unity no sabes qué pasa por debajo y por supuesto que no puedes cambiar nada. No tienes control sobre eso. Es todo scripting... Claro que facilita, pero obviamente tampoco puedes pretender que de el mismo rendimiento que algo hecho nativamente.
Es un poco como Bennu pero llevado un poco más "al extremo" (al menos con bennu escribes código, con Unity el drag&drop te ahorra muchísimo código y luego pones scripts para tus cosas y ya).
No he dicho que sea mejor o peor o que seas peor programador por usarlo, para nada. He dicho que son 2 conceptos distintos y que a mi, personalmente, no me gusta.

EDIT: y tampoco quito mérito a nadie que haya usado esas herramientas, que por supuesto hacer un juego con Unity lleva su tiempo y su esfuerzo. No me malinterpreteis ;)

Eskema
01/11/2012, 17:56
29164

-----Actualizado-----

"Unity3D está pensado para diseñadores o alguien que no tiene tanta idea de programar..."

Pero que dices ? Unity3D esta pensado para hacer juegos grandes y profesionales con menor esfuerzo porque ya te da muchas cosas, no significa que esta hecho para porgramadores novatos, pero si para facilitar crear juegos que de otro modo te llevaria un par de años más...


Voy a robar esa imagen para incluirla en mi proximo juego xDDDDDD


Btw, no creo que el rendimiento que da unity sea muy malo, no creo que pierdas mas de 1 fps respecto a currartelo tu todo en opengl (o lo que sea), lo que pasa es que muchos programadores os asusta el usar algo sin saber lo que hay por debajo. A mi me la pela, si algo funciona y me hace el trabajo no me importa lo que haya por debajo, precisamente si uso un motor es para no saber que hay debajo y olvidarme.

GameMaster
01/11/2012, 20:39
Esta imagen fuera de coñas no deberia haberla publicado, así que voy a confiar en vuestra discreción...

dr_bacterio
01/11/2012, 20:48
Entiendo perfectamente el miedo a no saber lo que hay entre los bastidores de una aplicación, IDE, framework o librería. Lo sé , porque lo vivo a diario con las herramientas que me imponen en el trabajo, que supuestamente mejoran mi productividad y hacen que me olvide de detalles de bajo nivel. La pega está cuando tienes problemas de los que no conoces su origen en un sistema muy complejo del que apenas tienes visibilidad de un 20% , y al no conocer lo que ocurre a bajo nivel te ves forzado a emplear la técnica de marear la perdiz para resolverlo. Esta situación se solventa si cuentas con el soporte técnico adecuado de los proveedores de las herramientas, que no se contrate ese soporte para ahorrar costes es otra historia.

Respecto al usar o no herramientas como Unity3D , creo que os formuláis las preguntas equivocadas. Desarrollar un videojuego como cualquier otro proyecto informático requiere de una inversión de tiempo de trabajadores altamente cualificados. ¿Se puede desarrollar el videojuego que se ha planificado con el Unity3D? Es decir su viabilidad técnica. ¿Porque supongo que estamos todos de acuerdo que la productividad es mayor con lenguajes de scripting que usando lenguajes más eficientes y que la forma más rápida de producir código es reutilizando el código ya escrito, es decir librerías?
El motivo por el cual es mejor utilizar código propio o un engine a medida es poder poner en práctica ideas no implementadas en otros engines o que la máquina destino no disponga de librerías decentes ( o como seguro que nos pasa a la gente que lee este foro por el gusto de aprender :D).

pakoito
01/11/2012, 21:11
No es cierto, con Unity no sabes qué pasa por debajo y por supuesto que no puedes cambiar nada. No tienes control sobre eso. Es todo scripting... Claro que facilita, pero obviamente tampoco puedes pretender que de el mismo rendimiento que algo hecho nativamente.
Es un poco como Bennu pero llevado un poco más "al extremo" (al menos con bennu escribes código, con Unity el drag&drop te ahorra muchísimo código y luego pones scripts para tus cosas y ya).
No he dicho que sea mejor o peor o que seas peor programador por usarlo, para nada. He dicho que son 2 conceptos distintos y que a mi, personalmente, no me gusta.

EDIT: y tampoco quito mérito a nadie que haya usado esas herramientas, que por supuesto hacer un juego con Unity lleva su tiempo y su esfuerzo. No me malinterpreteis ;)¿No tienes acceso al codigo y al pipeline de Unity en la versión Pro? EDIT: La web me dice que si. (https://store.unity3d.com/)

Y yo no estoy con misato en lo de reinventar la rueda para cada empresa y cada desarrollo. Como independiente, es gastar mucho tiempo y recursos para conseguir un producto marginalmente mejor que uno hecho con herramienta (más simple como Gamemaker o más completa como Unity). Casos de ejemplo los tienes que conocer tu misma, Misato, ¿qué pasó con los proyectos para la gp32/x que se quedaron en la fase de tuneo del motor?

Como empresa, licenciar un motor y pedir acceso al nivel bajo me parece más sensible y hay motores de todos los colores...no hay que reescribirlo desde OpenGL/DirectX cada vez. Unreal, Gamebyro, CryEngine, Frostbite, pick your poison.

Que por cierto, ya hay juegos calidad profesional en Unity, el primero que se me ocurre es Endless Space


http://www.youtube.com/watch?v=m2H1wK1dFXg

lemure_siz
02/11/2012, 00:53
¿No tienes acceso al codigo y al pipeline de Unity en la versión Pro? EDIT: La web me dice que si. (https://store.unity3d.com/)

Y yo no estoy con misato en lo de reinventar la rueda para cada empresa y cada desarrollo. Como independiente, es gastar mucho tiempo y recursos para conseguir un producto marginalmente mejor que uno hecho con herramienta (más simple como Gamemaker o más completa como Unity). Casos de ejemplo los tienes que conocer tu misma, Misato, ¿qué pasó con los proyectos para la gp32/x que se quedaron en la fase de tuneo del motor?

Como empresa, licenciar un motor y pedir acceso al nivel bajo me parece más sensible y hay motores de todos los colores...no hay que reescribirlo desde OpenGL/DirectX cada vez. Unreal, Gamebyro, CryEngine, Frostbite, pick your poison.

Que por cierto, ya hay juegos calidad profesional en Unity, el primero que se me ocurre es Endless Space


http://www.youtube.com/watch?v=m2H1wK1dFXg

Perdonad el offtopic pero...Ostia un Master of Orion de hoy en dia, este tengo que probarlo si o si

pakoito
02/11/2012, 01:05
Has pillado un buen año, han salido un par del mismo estilo y hay otro par en camino. Además han reparado el Sword of the Stars 2 hasta un punto en que parece que ya es jugable. La única queja del EE es el combate, y parece que van a cambiarlo en la primera expansión. Y merece la pena que mires el modelo de desarrollo "abierto" que tienen, donde los próximos parches y los cambios en el diseño los hace la comunidad, y muchos de los documentos de diseño internos están liberados y aceptados entre todos.

^MiSaTo^
02/11/2012, 01:06
Yo no digo que no se use un motor, es evidente que reinventar la rueda para cada proyecto es estúpido e inviable. Digo que a mi personalmente un motor qu eno me deja ver lo que pasa por debajo... no me gusta. Y en concreto Unity, no me gusta.

pakoito
02/11/2012, 01:19
Yo no digo que no se use un motor, es evidente que reinventar la rueda para cada proyecto es estúpido e inviable. Digo que a mi personalmente un motor qu eno me deja ver lo que pasa por debajo... no me gusta. Y en concreto Unity, no me gusta.

Pero si que puedes, o eso parece decir lo que te he linkado antes.

EDIT: Perdón, te dejan acceder al metal, pero no a su código fuente. En todo caso, muchos otros motores si, previo pago de licencia.

Drumpi
02/11/2012, 01:31
Como usuario de un lenguaje pseudointerpretado, entiendo ambos puntos de vista:

Inicialmente, tener un motor que te haga todo el "trabajo sucio" es una gran ventaja: desarrollas más rápido, no necesitas aprender el lenguaje a fondo, tampoco necesitas entender el funcionamiento físico del hardware o de la comunicación con el software.
Pero a medida que pasa el tiempo y te haces experto, empiezas a verle los bugs, fallos de rendimiento y las limitaciones. Y es cuando te planteas aguantarte, tratar de arreglarlo o emigrar.

Es bueno que existan este tipo de motores, de hecho, hasta las grandes empresas de hoy día los usan. No digo Unity en concreto, pero sí motores para la consola tal o para el chip gráfico cual. Llega un momento que los juegos son tan complejos que es imposible para una persona hacerlo, no sólo por el juego en sí, sino porque hoy día entender las capas de software que hay por debajo, o peor aun, el hardware, capaz de hacer miles de procesamientos por CICLO, es abrumador.
Yo veo la publicidad de los juegos modernos y me asusto: cientos de personajes moviéndose, millones de polígonos, briznas de hierbas moviéndose con el viento ¿Dónde quedaron los plataformas simples en 2D, aunque sean en HD? No me extraña que salgan tantos refritos hoy día, necesitas un batallón de programadores para manejar tantísimos elementos como están metiendo ahora ¡y sólo para decorarlo todo!

Pero es cierto, de vez en cuando es necesario meterle mano a esa "caja negra". A mi mismo me pasó que una librería que usaba en el trabajo no mandaba mensajes de una manera determinada. Rodear ese bache supuso cambiar la metodología para enviar ese mensaje y reescribir gran parte del código. De una hora de trabajo se pasó a una semana.

Aun así ¿scripting? ¿Ni siquiera usa un bytecode propio?

^MiSaTo^
02/11/2012, 08:29
Repito, no digo que no se use un motor ya hecho, digo que a mi no me gusta Unity. Cuando curraba en la empresa de juegos usábamos el Unreal Engine para PS3 y era un concepto completamente distinto a unity. Nada de drag & drop, nada de scripts. Y ese sí me gustó.

Eskema
02/11/2012, 09:11
Aun así ¿scripting? ¿Ni siquiera usa un bytecode propio?

Unity funciona con mono por debajo y monotouch para las plataformas moviles el codigo se compila para cada plataforma asi que perdida no hay mucha...


Aqui tambien cabria notar otro debate, aceptamos barco y decimos que queremos acceder al código y tal, ¿que motores tienes de codigo libre/acceso, potentes y baratos para los indies?


Y dandole caña a misato, a ti lo que te pasa es que eres de esos programadores de mentalidad cerrada, en cuanto os sacan del codigo normal y os cambian el paradigma os haceis cacotas encima pq no quereis probar cosas distintas del actual modelo de programacion xDDD
A mi unity me costo 1 mes en entender la forma de manejar, olvidarme que ahora ya no tengo mi mainmanager, ni controlo el mainloop, ni que ahora necesito una clase para iniciar cosas (que se sigue gastando pero de forma diferente), pero una vez superado el bache inicial en el que decia lo mismo que misato, ahora estoy en el lado oscuro de la fuerza y unity me tiene cautivado xDD

ZeNiTRaM
02/11/2012, 10:12
Pues yo digo que depende de para qué lo quieras o en qué lo uses. En el departamento de la uni en el que estoy, que se especializan en cosas de e-learning (y buzzwords como Learning Analytics o Gamificación), Unity lo usan en tres o cuatro proyectos diferentes para hacer cosillas y jueguecillos en 3D que, de haber necesitado programarlos en un lenguaje "real", con Unreal o a pelo con OpenGL, no se hubieran hecho.

sereno
02/11/2012, 12:23
Todo depende de lo que quieras hacer, no deja de ser una herramienta.
Si cumple los requisitos de tu proyecto y te ahorra trabajo pues perfecto, si no es así pues te tocará buscar otras herramientas o hacerlas tú mismo.

Estopero
02/11/2012, 12:33
Y dandole caña a misato, a ti lo que te pasa es que eres de esos programadores de mentalidad cerrada, en cuanto os sacan del codigo normal y os cambian el paradigma os haceis cacotas encima pq no quereis probar cosas distintas del actual modelo de programacion xDDD
A mi unity me costo 1 mes en entender la forma de manejar, olvidarme que ahora ya no tengo mi mainmanager, ni controlo el mainloop, ni que ahora necesito una clase para iniciar cosas (que se sigue gastando pero de forma diferente), pero una vez superado el bache inicial en el que decia lo mismo que misato, ahora estoy en el lado oscuro de la fuerza y unity me tiene cautivado xDD

En favor de Misato voy a decir que de programadora cerrada nada, creo que es una de las programadoras más polivalentes que te puedes echar a la cara, probablemente ha programado en más lenguajes y con más metodologías que la mayoría de los programadores que estamos aquí.

Ahora, se le ve el plumero que tiene debilidad por el "old school" XDD y lógicamente tiene su derecho a que le guste más tener directamente las manos en el motor.

Por otra parte Eskema, me chirría mucho que estés criticando a tu amigo diseñador por usar corona porque "no te da flexibilidad para hacer cosas más complicadas" y estés defendiendo tan a capa y espada Unity frente a desarrollos más a bajo nivel. Es bastante poco lógico tu razonamiento, pues tu amigo diseñador te da exactamente las misma razones para usar corona que tú le das a Misato para usar Unity.

Cada proyecto "debería" programarse de la forma más eficaz/eficiente, y esto depende del resultado que quieras lograr y los tipos de recursos de los que dispongas, tanto materiales como humanos, así que no veo ningún método inválido si te resuelve tu proyecto de forma eficaz (ni si quiera corona) :)

saucjedi
02/11/2012, 12:40
Voy a robar esa imagen para incluirla en mi proximo juego xDDDDDD


Btw, no creo que el rendimiento que da unity sea muy malo, no creo que pierdas mas de 1 fps respecto a currartelo tu todo en opengl (o lo que sea), lo que pasa es que muchos programadores os asusta el usar algo sin saber lo que hay por debajo. A mi me la pela, si algo funciona y me hace el trabajo no me importa lo que haya por debajo, precisamente si uso un motor es para no saber que hay debajo y olvidarme.

Unity es un compromiso entre el hacerte tu motor (o integrar otros y crearte un framework) en C/C++ y recurrir a cosas más sencillas como Corona. Se nota que Unity está muy afinado y mimado para que la pérdida de rendimiento sea la mínima y aunque es cierto que no sabes lo que hay por debajo, para un 90% o más de proyectos es una alternativa muy buena.

Lo otro es más académico. A mí me gusta saber qué hay por debajo, OpenGL, C, algoritmos de pintado, todo... pero es porque me gusta saberlo, raro es que te metas en un proyecto y tengas que desarrollar cosas tan esenciales (hablo de si te contratan en una desarrolladora fuerte), por tanto acabas usando su motor o desarrollando cosas sobre su framework... que al final es parecido a usar Unity.

dardo
02/11/2012, 12:56
Dile a un Director de una empresa grande que vas a poner en producción un chisme que se ha generado mediante drag & drop y que por arte de magia se ha generado un binario y explícale que si eso tiene un bug la única manera de resolverlo es mediante ingeniería inversa.

Para hacer un juego para móviles estas metodologías están bien. Te permiten tocar mucho sin profundizar demasiado, sobre todo para gente que no programa como ocupación principal, si no que se dedica a temas de diseño. Hacen aplicaciones bonitas y no requieren un rendimiento brutal, pero a la hora de depurar un bug seguro que están perdidas.

Mándales un coredump y mira a ver si saben hacer algo con él. Si el entorno te permite acceder al código generado es harina de otro costal. Tienes el código que puedes editar, lo cual siempre es una garantía.

^MiSaTo^
02/11/2012, 13:31
Dile a un Director de una empresa grande que vas a poner en producción un chisme que se ha generado mediante drag & drop y que por arte de magia se ha generado un binario y explícale que si eso tiene un bug la única manera de resolverlo es mediante ingeniería inversa.

Para hacer un juego para móviles estas metodologías están bien. Te permiten tocar mucho sin profundizar demasiado, sobre todo para gente que no programa como ocupación principal, si no que se dedica a temas de diseño. Hacen aplicaciones bonitas y no requieren un rendimiento brutal, pero a la hora de depurar un bug seguro que están perdidas.

Mándales un coredump y mira a ver si saben hacer algo con él. Si el entorno te permite acceder al código generado es harina de otro costal. Tienes el código que puedes editar, lo cual siempre es una garantía.
Se nota que desconoces el tema por completo. Hacer un juego para móvil no es tampoco algo ni sencillo ni que no requiera optimización a tope, a veces (normalmente) bastante más que para un programa de PC o web.
Lo mismo se aplica a las apps "normales" (aunque muchas veces en menor medida porque suelen ser más sencillas que hacer un juego).

Eskema
02/11/2012, 14:15
Por otra parte Eskema, me chirría mucho que estés criticando a tu amigo diseñador por usar corona porque "no te da flexibilidad para hacer cosas más complicadas" y estés defendiendo tan a capa y espada Unity frente a desarrollos más a bajo nivel. Es bastante poco lógico tu razonamiento, pues tu amigo diseñador te da exactamente las misma razones para usar corona que tú le das a Misato para usar Unity.

Cada proyecto "debería" programarse de la forma más eficaz/eficiente, y esto depende del resultado que quieras lograr y los tipos de recursos de los que dispongas, tanto materiales como humanos, así que no veo ningún método inválido si te resuelve tu proyecto de forma eficaz (ni si quiera corona) :)


Obviamente me he explicado como el culo, lo que queria decir con "me cago la madre del diseñador", es por esa gilichorrada de "creo un juego en 1 semana como mucho porque uso corona". A mi me da igual si usas corona, unity o lo que sea, pero no me vengas a decirme que haces un juego en 1 semana y encima de calidad pq ni de coña. Corona lo veo como un entorno para niños, y no se lo recomiendo a nadie, ¿para probar algo el codigo se envia a sus servidores donde se compila y me devuelven el binario?, ¿que clase de mierda es esta?.
Al menos en unity tengo un entorno "serio y fiable" (por eso lo vendo tan bonito pq supera con creces a TODO lo que hay en el mercado a dia de hoy a nivel indie y no tendre reparos en cambiarme a otro si me ofrece mas y mejor) y que depende de mi equipo no de terceros al necesitar un servidor online para validar mi codigo, tengo acceso a codigo nativo y si necesito integrar algo externo a unity lo puedo hacer creandome mi libreria externa, cosa que con corona no.

Unity es lo mas parecido que he visto a "programar" manteniendo un compromiso decente entre facilidad y acceso al código, de ahi que me guste, pero muchos programadores les gusta mas el "do it yourself" porque quieren aprender cosas y es algo que hacen en su tiempo libre, mientras que yo trabajo y necesito hacer un juego ya mismo, no experimentar con la tecnologia del motor para aprender a hacer bump mapping


Ahora respecto a eso de no tener el codigo, pues bien, dado que me abstrae el tenerlo todo cerrado, no tengo mareos en tocar codigo interno, pongamos el ejemplo de un motor "free" como el ogre3D, como soy un programador guay que me gusta tocarlo todo, voy a cambiar codigo y crearme mi propia version del engine, pq hay cosas mejorables y tengo que arreglar sus chapuzas pq no se ajustan a mi forma de programar ademas de incorporar cosas guays que he leido y quiero aprender. Muy bien, y ahora cuando los señores de ogre3d te saquen la version 2.0 y hayan cambiado un monton de cosas, tu tendras que perder un monton de tiempo para integrar tus cambios en su nueva estructura, porque aunque les hayas enviado el parche con tus novedades por aquello de compartir codigo, tal vez tus cambios son aplicables a tu proyecto personal y no les sirven/gustan para la rama principal. En el caso del motor cerrado, me da igual lo que cambien pq yo solo tengo codigo de mi juego, asi que sus novedades/fixes no afectan a mi proyecto. De ahí que no vea

dardo
02/11/2012, 14:23
Se nota que desconoces el tema por completo. Hacer un juego para móvil no es tampoco algo ni sencillo ni que no requiera optimización a tope, a veces (normalmente) bastante más que para un programa de PC o web.
Lo mismo se aplica a las apps "normales" (aunque muchas veces en menor medida porque suelen ser más sencillas que hacer un juego).

No digo que programar para móvil no requiera mucha optimización, y si, de móviles ando muy pez. Lo mio son plataformas mucho más grandes. En cuanto a móviles, especialmente en Android donde está el tema muy segmentado en distintos terminales con capacidades muy distintas y a versiones de Android bastante distintas, algunas de las cuales llevan grandes modificaciones hechas (o encargadas) por los fabricantes de los terminales o las operadoras o encuentras una manera de unificar el tema sin reinventar la rueda cada vez o mueres en el intento de portar la aplicación.

Y en cuanto a que programar un juego sea más complicado que una aplicación "normal" no lo tengo más claro. Hay juegos que si tienen complicación y hay juegos que no. La mecánica de casi todos los juegos es sencilla, salvo excepciones. Lo difícil es que sea bonito y distinto del otro millón de juegos con la misma mecánica.

Pero no me estás quitando la razón. Haz una aplicación, o una parte de la aplicación, ya sea un juego o otra cosa y que de pronto tenga un bug en una parte generada "por arte de magia" y tú me dirás como lo depuras.
.

^MiSaTo^
02/11/2012, 14:32
Obviamente me he explicado como el culo, lo que queria decir con "me cago la madre del diseñador", es por esa gilichorrada de "creo un juego en 1 semana como mucho porque uso corona". A mi me da igual si usas corona, unity o lo que sea, pero no me vengas a decirme que haces un juego en 1 semana y encima de calidad pq ni de coña. Corona lo veo como un entorno para niños, y no se lo recomiendo a nadie, ¿para probar algo el codigo se envia a sus servidores donde se compila y me devuelven el binario?, ¿que clase de mierda es esta?.
Al menos en unity tengo un entorno "serio y fiable" (por eso lo vendo tan bonito pq supera con creces a TODO lo que hay en el mercado a dia de hoy a nivel indie y no tendre reparos en cambiarme a otro si me ofrece mas y mejor) y que depende de mi equipo no de terceros al necesitar un servidor online para validar mi codigo, tengo acceso a codigo nativo y si necesito integrar algo externo a unity lo puedo hacer creandome mi libreria externa, cosa que con corona no.

Unity es lo mas parecido que he visto a "programar" manteniendo un compromiso decente entre facilidad y acceso al código, de ahi que me guste, pero muchos programadores les gusta mas el "do it yourself" porque quieren aprender cosas y es algo que hacen en su tiempo libre, mientras que yo trabajo y necesito hacer un juego ya mismo, no experimentar con la tecnologia del motor para aprender a hacer bump mapping


Ahora respecto a eso de no tener el codigo, pues bien, dado que me abstrae el tenerlo todo cerrado, no tengo mareos en tocar codigo interno, pongamos el ejemplo de un motor "free" como el ogre3D, como soy un programador guay que me gusta tocarlo todo, voy a cambiar codigo y crearme mi propia version del engine, pq hay cosas mejorables y tengo que arreglar sus chapuzas pq no se ajustan a mi forma de programar ademas de incorporar cosas guays que he leido y quiero aprender. Muy bien, y ahora cuando los señores de ogre3d te saquen la version 2.0 y hayan cambiado un monton de cosas, tu tendras que perder un monton de tiempo para integrar tus cambios en su nueva estructura, porque aunque les hayas enviado el parche con tus novedades por aquello de compartir codigo, tal vez tus cambios son aplicables a tu proyecto personal y no les sirven/gustan para la rama principal. En el caso del motor cerrado, me da igual lo que cambien pq yo solo tengo codigo de mi juego, asi que sus novedades/fixes no afectan a mi proyecto. De ahí que no vea

Hombre, no se trata de "voy a cambiar las cosas internas del motor porque puedo y porque quiero" sino de si tienes algún problema o algo que adaptar a tu solución, puedes cambiarlo. De tener la posibilidad, no de hacerlo porque sí.
Mira un ejemplo que me pasó el año pasado, teníamos que integrar facebook en una apli y la librería que daban menos mal que daban el código tb porque en iOS iba más o menos ok, pero en Android había una llamada en concreto que siempre nos devolvía null... Era raro porque en iOS sí devolvía lo que tenía que hacer. Me puse a mirar el código y tuve que cambiar yo cosas de su librería porque el método estaba mal implementado.
Y no es la primera librería de terceros que he tenido que "retocar" para que haga lo que yo quiero o simplemente para corregir un bug suyo. Por eso me da miedo algo cerrado sobre el que no tengo control.
Por otro lado, oye entiendo tu postura. Tú no quieres tener que calentarte la cabeza, y para ti Unity se adapta perfectamente a lo que quieres, pues me parece correcto. Cada uno que use lo que mejor le venga.

Yo prefiero tener la posibilidad de si pasa algo, no tener que cambiar de librería o lo que sea a mitad de desarrollo, porque como bien dices las apps y los juegos no se hacen en una semana.
Ambas opciones son válidas siempre que se adapten a lo que necesitas, personalmente yo soy partidaria del opensource y demás pero oye, allá cada cual ;)

bulbastre
02/11/2012, 14:32
Al menos en unity tengo un entorno "serio y fiable" (por eso lo vendo tan bonito pq supera con creces a TODO lo que hay en el mercado a dia de hoy a nivel indie y no tendre reparos en cambiarme a otro si me ofrece mas y mejor) y que depende de mi equipo no de terceros al necesitar un servidor online para validar mi codigo, tengo acceso a codigo nativo y si necesito integrar algo externo a unity lo puedo hacer creandome mi libreria externa, cosa que con corona no.

Unity es lo mas parecido que he visto a "programar" manteniendo un compromiso decente entre facilidad y acceso al código, de ahi que me guste, pero muchos programadores les gusta mas el "do it yourself" porque quieren aprender cosas y es algo que hacen en su tiempo libre, mientras que yo trabajo y necesito hacer un juego ya mismo, no experimentar con la tecnologia del motor para aprender a hacer bump mapping


Por saber, Cry Engine le haría la competencia?

^MiSaTo^
02/11/2012, 14:39
No digo que programar para móvil no requiera mucha optimización, y si, de móviles ando muy pez. Lo mio son plataformas mucho más grandes. En cuanto a móviles, especialmente en Android donde está el tema muy segmentado en distintos terminales con capacidades muy distintas y a versiones de Android bastante distintas, algunas de las cuales llevan grandes modificaciones hechas (o encargadas) por los fabricantes de los terminales o las operadoras o encuentras una manera de unificar el tema sin reinventar la rueda cada vez o mueres en el intento de portar la aplicación.

Y en cuanto a que programar un juego sea más complicado que una aplicación "normal" no lo tengo más claro. Hay juegos que si tienen complicación y hay juegos que no. La mecánica de casi todos los juegos es sencilla, salvo excepciones. Lo difícil es que sea bonito y distinto del otro millón de juegos con la misma mecánica.

Pero no me estás quitando la razón. Haz una aplicación, o una parte de la aplicación, ya sea un juego o otra cosa y que de pronto tenga un bug en una parte generada "por arte de magia" y tú me dirás como lo depuras.
.

Ea ves como sigues hablando sin saber? xD La fragmentación de Android, lo único que tiene de "malo" es todo el tema de la interfaz gráfica, que gracias a díos a día de hoy el SDK ha avanzado mucho y usando ciertos truquillos (aka RelativeLayout o Linear + weights) más o menos lo tienes "controlado". El problema es que aun así, tienes que probar bien en todos los dispositivos porque nunca puedes estar seguro de que se vea igual en todos. Pero aparte de eso, lo demás funciona "igual" (lo pongo entre comillas porque obviamente en unos irá más rápido que en otros, y similares) en todos los terminales. Es la ventaja de tener la jvm ;)

Y sobre lo de hacer un juego que sea más complicado o no.. pues mira, yo he trabajado de muchas cosas (esto tb incluye administración de sistemas unix, aunque en menor medida) y programando he hecho aplicaciones web en distintos lenguajes, aplicaciones de escritorio tb en distintos lenguajes y entornos, juegos para PC, juegos para consola, y ahora esto de los móviles.
De entre todo eso te aseguro que hasta el juego más chorra (en mi caso Autoescuela DS que es el más chorra/simple que he hecho) lleva bastante más curro que una aplicación normal. Para mi es bastante más complejo y especialmente si ya lo haces para un dispositivo casi sin potencia como es un móvil (por mucho que el Galaxy S3 tenga nosecuantos cores y nosecuantos gigahertzios de ram NO es como un PC y estás MUY limitado).

Pero vamos sí, en lo último que dices no te quito razón ninguna ;) Ahí si estamos de acuerdo

-----Actualizado-----


Por saber, Cry Engine le haría la competencia?

Of course, pero Cry Engine y Unreal juegan en otra liga, en la de los "mayores" ;) También valen infinitamente más que la licencia de Unity

Eskema
02/11/2012, 15:22
Por otro lado, oye entiendo tu postura. Tú no quieres tener que calentarte la cabeza, y para ti Unity se adapta perfectamente a lo que quieres, pues me parece correcto. Cada uno que use lo que mejor le venga.

Yo prefiero tener la posibilidad de si pasa algo, no tener que cambiar de librería o lo que sea a mitad de desarrollo, porque como bien dices las apps y los juegos no se hacen en una semana.
Ambas opciones son válidas siempre que se adapten a lo que necesitas, personalmente yo soy partidaria del opensource y demás pero oye, allá cada cual ;)


Exacto, aqui hay 2 perfiles bien diferenciados tal y como pensaba cuando puse el post:

-el do it yourself, que realmente no quieren hacer ningún juego, solo quieren cacharrear, y para cacharrear necesitas el codigo fuente. No es que tengan miedo a que el engine este cerrado, es que el juego se la pela y el juego solo es una excusa para aprender XXX tecnología, y que en un porcentaje muy elevado ese juego nunca saldra de su disco duro, eso suponiendo que llegue a terminarlo.

-los que queremos hacer un juego "de verdad", es decir empezar y terminar un juego sin pararnos a ver como pongo el bump mapping o como cargo 3 texturas a la vez, quiero hacer algo pq me motiva el juego en si, no la tecnologia que hay detras ni lo que voy a aprender haciendolo.


bulbastre, tanto cryengine como unreal son engines para grupos, no son aptos para ser usados por 1 sola persona de manera eficaz.

^MiSaTo^
02/11/2012, 15:27
Exacto, aqui hay 2 perfiles bien diferenciados tal y como pensaba cuando puse el post:

-el do it yourself, que realmente no quieren hacer ningún juego, solo quieren cacharrear, y para cacharrear necesitas el codigo fuente. No es que tengan miedo a que el engine este cerrado, es que el juego se la pela y el juego solo es una excusa para aprender XXX tecnología, y que en un porcentaje muy elevado ese juego nunca saldra de su disco duro, eso suponiendo que llegue a terminarlo.

-los que queremos hacer un juego "de verdad", es decir empezar y terminar un juego sin pararnos a ver como pongo el bump mapping o como cargo 3 texturas a la vez, quiero hacer algo pq me motiva el juego en si, no la tecnologia que hay detras ni lo que voy a aprender haciendolo.


bulbastre, tanto cryengine como unreal son engines para grupos, no son aptos para ser usados por 1 sola persona de manera eficaz.

No hombre, yo lo del do it yourself no lo describiría así (al menos yo me considero en ese grupo).
A ver si yo tengo que hacer un juego para iOS, yo miraré los engines que hay y cogeré el que más se adapte a lo que quiero. No significa que yo vaya a hacer de 0 nada ni que vaya a modificar el código ni nada del estilo. Simplemente me gusta saber que si pasa algo (como el ejemplo de lo de facebook) puedo al menos solucionarlo o saber por qué está fallando. Eso no quiere decir que según me ponga a programar vaya a remirarme el código y retocar aquí y allá.
No se si ahora se ha entendido mejor ;)

Eskema
02/11/2012, 15:32
Si el juego tiene que ser comercial no dudo en que miraras algun engine (el que sea), pero por lo que veo muchos do it yourself solo cacharrean pero nunca terminan ningun proyecto, eso si saben un monton de trucos y cosas. Solo hay que mirar en general en internet la cantidad de proyectos que iban a hacer tal o cual y nunca mas se supo.