Alpha ops con spritebatch para conseguir luces en 2D

[MrK]

Toda la IA de Los Sims 3 esta hecha en C#, corre bajo mono, durante el desarrolllo tenia todas las opciones de seguridad y chequeo activadas, y una vez libre de fallos, le desactivaron la comprobación de rango en arrays y otros temas para obtener mas rendimiento.

Lo que decían es que el tiempo de desarrollo se redujo bastante... y el impacto en rendimiento fue muy bajo.


Buscando el post donde leí eso, para contrastarlo me he topado con un post reciente de miguel de icaza sobre la gdc, bastante extenso por cierto, que arroja mucha luz sobre el devenir de C# y el desarrollo de videojuegos.

http://tirania.org/blog/archive/2011/Mar-07.html

ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.

2. En una clase que vaya a ser muy usada no definir referencias a otros objetos directamente, sino a través de un indice entero... para que el GC no se pierda comprobando vinculos cuando liberas

Yo tambien estoy haciendo esto, pero me da la impresion de haber vuelto al 1990 cuando usaba C puro y duro y no sabia usar punteros. Si esto es evolucion...

[Hans]

El GC no se puede deshabilitar, ¿verdad?

[blau]

ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.

Nadie ha dicho lo contrario.  Enfrentarse en una guerra que lenguaje es mejor no tiene sentido.

A mi me encanta c# porque es productivo, y para mi que tengo pocas horas, me viene de vicio no estar peleandome con punteros ni haciendo un monton de codigo para hacer cosas que C# y .Net te las dan hechas.

Una de las ventajas que tiene c# es esta, pero es que ademas, pocos lenguajes interpretados te dan las herramientas que te da Microsoft y visual Studio...

para las quejas sobre el rendimiento en xna, yo me pregunto, ¿que otra consola de sobremesa te permite por 99$ publicar juegos, te da unas herramientas similares, esta en constante desarrollo, hay tutoriales, codigo, desarrolladores del producto en los foros dando soporte de forma gratuita?

me direis que el iphone o moviles, yo dire y ¿programar para iphone/moviles no tiene ninguna pega?

que cada uno evalue lo que le dan y lo que puede dar, y elija lo que mas le convenga, todos sabemos lo que hay, cuando programamos con c#, simplemente hay que ser consecuentes.

[Vicente]

El GC no se puede deshabilitar, ¿verdad?

Si coges tu código y lo metes en un bloque gigantesco de "unsafe" el GC no hará nada. Pero a parte de eso no se puede desactivar.

[[EX3]]

me direis que el iphone o moviles, yo dire y ¿programar para iphone/moviles no tiene ninguna pega?

Objective-C?  >:D

Si coges tu código y lo metes en un bloque gigantesco de "unsafe" el GC no hará nada. Pero a parte de eso no se puede desactivar.

Pero el unsafe no funcionaba en la XBox me suena que habeis comentado alguno, no?

Salu2...

[Vicente]

Al menos me alegro de ser de la minoria que se apaña mejor sin el GC, porque me ha dado mas problemas el GC el ultimo mes que todas las aplicaciones que he desarrollado en el trabajo y juegos a horas libres en 5 años. :)

Pero ya hemos hablado porque el GC da problemas en la Xbox/WP7 (no?), es como si en C++ usaras para alocar memoria algo de hace unos cuantos años, te ibas a morir de la manera porque según avanza la cosa cada vez es más lento hacer un new...

Por que no para juegos? Pues porque en el 99% de las aplicaciones desarrolladas te da igual que una cosa te tarde 100 milis mas pues quizas te estas tirando 3 minutos en una query, pero si tienes que generar un frame cada 16 milis eso requiere un control estricto de la maquina que hay debajo. Personalmente no aguanto juegos con tirones o bajones de framerate (pero bueno, este tipo de juegos desde que las consolas se parecen a un PC esta desapareciendo)

Que en un futuro el GC sea mejor para 360/360 next/WP7? Eso no te lo discuto. Pero ahora como ahora, no.

Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...

[Vicente]

ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.

La cosa es que en C# enterito cada vez hay más y más juegos :) Si no despega más en mi opinión es por otros motivos que no son técnicos: no es multiplataforma (este es mortal), hay mucho dinero, formación y tecnología invertidos en C++,...

Yo tambien estoy haciendo esto, pero me da la impresion de haber vuelto al 1990 cuando usaba C puro y duro y no sabia usar punteros. Si esto es evolucion...

Pero es que el GC te evite tener que manejar la memoria no te libra completamente de tener que intentar entender como funciona el asunto en .NET... Pero es como todo, haces vas haciendo tu app, profileas y si ves que lo que te mata es el GC pues optimizas (igual que si te mata un algoritmo o cualquier otra decisión que hayas tomado).

[Vicente]

Pero el unsafe no funcionaba en la XBox me suena que habeis comentado alguno, no?

Salu2...

Nope, en la Xbox no funciona. En PC .NET tiene varias palabras reservadas para ciertas situaciones expeciales: unsafe, fixed, unchecked, stackalloc, volatile,...

[MrK]

Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...

Que yo sepa, eso no se puede hacer. Cuando corre el GC no corre nada mas (en la 360).

[Vicente]

Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...

Que yo sepa, eso no se puede hacer. Cuando corre el GC no corre nada mas (en la 360).

Claro,  porque ya he dicho unas 1000 veces que la implementación del GC de la Xbox ES UNA MIERDA. A ver si con las mayúsculas se entiende mejor :p

[fjfnaranjo]

Para Vicente:

- No es que quiera mover el tema de la discusión a que la mayoría de los programadores sepan o no gestionar memoria. Es que te digo que no es relevante. Estamos discutiendo sobre la memoria autogestionada y no sobre las capacidades del ser humano. Obviamente, si el ser humano estuviese supercapacitado, no harían falta ni lenguajes de programación, y si estuviese infracapacitado, habría que gestionarle hasta la hora del almuerzo. Pero estamos hablando de la tecnología, no de la calidad de las personas de la profesión.

- No puedes comparar el GC con el proceso de compilación, ambos son parte de la misma cadena de abstracción que da lugar a su propia existencia. Como ya he dicho arriba, esta comparación tiene que ver más con las personas que con la tecnología, que es en lo que yo me centro para dar mi opinión.

- Hay muchas cosas más en el mundo aparte del Crysis que necesitan estar microgestionadas, y precisamente el que lo cites me da la razón en el hecho de que si quieres el máximo rendimiento, no puedes depender del GC. Y bueno, como el GC no es más que una abstracción, el propio .NET tiene que estar programado en un lenguaje microgestionado, que probablemente es C++. Así que no hablamos de casos raritos, si no de un buen número de casos. A parte, la implementación del GC de la XBox obliga hoy por hoy a los AAA a olvidarse del C#, por lo que podemos decir libremente, que si quieres hacer un AAA multiplataforma, te olvides de C#, a no ser que quieras soportar una implementación de mierda del GC en esa plataforma (son tus palabras).

Para todos:

Al final, esta discusión está sacando a relucir unas cuantas cosas: la primera, es que existe un grado de abstracción sobre la tecnología íntimamente relacionado con la capacidad del programador, pongo un gráfico...

0s y 1s  ->  ASM  ->  C/C++,Ada,Basic,etc  -> .NET,Java

Si todos los programadores fuésemos ultra épicos, trabajaríamos directamente con 0s y 1s. Pero como no lo somos, dependiendo de dos factores, nos movemos hacia arriba en el gráfico anterior. Estos factores, aunque habrá otros, serían:

- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.

La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.

Y ahora la pregunta épica: Si solo es elegir entre avanzar o no por el gráfico, y cuanto más se avanza más sencilla se vuelve la tarea, ¿por qué los partidarios de no avanzar cuando no se da el factor segundo no avanzan sin más?

Y la respuesta es, que cuanto más avanzas por ese gráfico, más trabajo tiene que absorver el sistema sobre el que estás desarrollado. Y menos tiempo de ese sistema tienes para conseguir tus objetivos, porque tienes que entregarlo a la máquina para que esta resuelva el poblema por ti.

Dicho esto, y para evitar extenderme mucho más, opino que el GC es del todo innecesario y que no merece su uso el coste de tiempo de proceso que necesita el sistema. Y esta opinión, está fundamentada en años de desarrollo con dos tecnologías, por un lado C++, y por el otro Java. Se que no es .NET, pero por norma general, las cosas el Java se arrastran mucho más que en C++, y el motivo por el cual yo sigo usando C++ a menudo, es porque no me supone ningún esfuerzo hacer el trabajo que .NET o Java me prometen que van a hacer por mi. El tema de la productividad es para mi un mito, que limita al ser humano en sus capacidades vendiéndole una forma fácil de resolver un problema, cuando el coste real intelectualmente hablando creo que debería ser nimio, considerando lo evolucionados que estamos como seres humanos, y lo que hemos conseguido que la tecnología evolucione. Para mi es dar un paso atrás...

Y como último apunte, quiero remarcar que lo anterior es una opinión y que no quiero que nadie cambie la suya. Cada uno verá como adapta sus factores a los problemas que se encuentre, y seguro que el camino que todos escojan es correcto observado desde su punto de vista, pues surge de su propio proceso de juicio de la situación.

[Vicente]

- No es que quiera mover el tema de la discusión a que la mayoría de los programadores sepan o no gestionar memoria. Es que te digo que no es relevante. Estamos discutiendo sobre la memoria autogestionada y no sobre las capacidades del ser humano. Obviamente, si el ser humano estuviese supercapacitado, no harían falta ni lenguajes de programación, y si estuviese infracapacitado, habría que gestionarle hasta la hora del almuerzo. Pero estamos hablando de la tecnología, no de la calidad de las personas de la profesión.

Para mi sí es relevante. Si la memoria autogestionada es mejor la mayoría de las veces que las capacidades de los seres humanos que hacen juegos AAA, entonces el GC no es un problema para hacer juegos AAA.

- No puedes comparar el GC con el proceso de compilación, ambos son parte de la misma cadena de abstracción que da lugar a su propia existencia. Como ya he dicho arriba, esta comparación tiene que ver más con las personas que con la tecnología, que es en lo que yo me centro para dar mi opinión.

Como me voy a fiar del código que genera una herramienta que yo no puedo controlar y blablablablabla. Y hoy en día ya a casi nadie le preocupa ya ese tema.

- Hay muchas cosas más en el mundo aparte del Crysis que necesitan estar microgestionadas, y precisamente el que lo cites me da la razón en el hecho de que si quieres el máximo rendimiento, no puedes depender del GC. Y bueno, como el GC no es más que una abstracción, el propio .NET tiene que estar programado en un lenguaje microgestionado, que probablemente es C++. Así que no hablamos de casos raritos, si no de un buen número de casos. A parte, la implementación del GC de la XBox obliga hoy por hoy a los AAA a olvidarse del C#, por lo que podemos decir libremente, que si quieres hacer un AAA multiplataforma, te olvides de C#, a no ser que quieras soportar una implementación de mierda del GC en esa plataforma (son tus palabras).

Hacer juegos AAA != necesitar el maximo rendimiento.

Y sobre lo de correr C# en la Xbox, a ver si entendemos el contexto "histórico". La implementación del GC es una mierda, y en general XNA es un gran hack sobre la Xbox (por eso hace falta el XNA Game Studio instalado en la Xbox, es básicamente un loader). Esa consola no sé pensó para estas cosas y el correr C# fue más una prueba de ingeniería al principio que otra cosa (luego lo que pasa que iba "tan bien" que siguieron adelante).

Y sobre la mutiplataformidad con consolas, desgraciadamente no se puede. Pero AAA no implica que un juego corra en una consola. No podrás hacer un juego para PC, Xbox, PS3 y Wii, pero nada te lo impide hacer para PC (o incluso Mac usando Mono y tan felices).

Para todos:

Al final, esta discusión está sacando a relucir unas cuantas cosas: la primera, es que existe un grado de abstracción sobre la tecnología íntimamente relacionado con la capacidad del programador, pongo un gráfico...

0s y 1s  ->  ASM  ->  C/C++,Ada,Basic,etc  -> .NET,Java

Si todos los programadores fuésemos ultra épicos, trabajaríamos directamente con 0s y 1s. Pero como no lo somos, dependiendo de dos factores, nos movemos hacia arriba en el gráfico anterior.

Ves, yo lo veo como si los programadores fueramos ultra-subnormales (e inmortales todo sea dicho), entonces usaríamos 0s y 1s. Moverse hacia arriba o hacia abajo en esa escala no indica gran cosa sobre la capacidad del programador (ni para bien ni para mal).

Estos factores, aunque habrá otros, serían:

- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.

La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.

Y ahora la pregunta épica: Si solo es elegir entre avanzar o no por el gráfico, y cuanto más se avanza más sencilla se vuelve la tarea, ¿por qué los partidarios de no avanzar cuando no se da el factor segundo no avanzan sin más?

Y la respuesta es, que cuanto más avanzas por ese gráfico, más trabajo tiene que absorver el sistema sobre el que estás desarrollado. Y menos tiempo de ese sistema tienes para conseguir tus objetivos, porque tienes que entregarlo a la máquina para que esta resuelva el poblema por ti.

Dicho esto, y para evitar extenderme mucho más, opino que el GC es del todo innecesario y que no merece su uso el coste de tiempo de proceso que necesita el sistema. Y esta opinión, está fundamentada en años de desarrollo con dos tecnologías, por un lado C++, y por el otro Java. Se que no es .NET, pero por norma general, las cosas el Java se arrastran mucho más que en C++, y el motivo por el cual yo sigo usando C++ a menudo, es porque no me supone ningún esfuerzo hacer el trabajo que .NET o Java me prometen que van a hacer por mi. El tema de la productividad es para mi un mito, que limita al ser humano en sus capacidades vendiéndole una forma fácil de resolver un problema, cuando el coste real intelectualmente hablando creo que debería ser nimio, considerando lo evolucionados que estamos como seres humanos, y lo que hemos conseguido que la tecnología evolucione. Para mi es dar un paso atrás...

Y como último apunte, quiero remarcar que lo anterior es una opinión y que no quiero que nadie cambie la suya. Cada uno verá como adapta sus factores a los problemas que se encuentre, y seguro que el camino que todos escojan es correcto observado desde su punto de vista, pues surge de su propio proceso de juicio de la situación.

En el fondo esto es un diferente punto de vista sobre lo que creemos que se puede conseguir con C#. Hay veces que las limitaciones las impone el entorno y hay que joderse: es decir, si para programar los frenos del AVE necesito usar C porque es que solo se puede programar en C, pues no hay otra. Si para hacer un juego multiplataforma en Xbox y PS3 necesito C++ pues que remedio. Si puedo usar las dos cosas pero mi empresa tiene a 100 tios formados en C++, herramientas internas en C++ y tal, pues C++. Es de sentido común. Pero que C# no es técnicamente capaz de hacer un AAA? Nope.

Y ya para terminar y la productividad y esas cosas. Para mi no es un mito. Cuanto más de alto nivel es el lenguaje, más fácil es expresar ideas complejas. Ideas complejas de verdad. Un ejemplo es la TPL (y el nuevo async de C# 5). Es decir, poder hacer esto:

collection.AsParallel().AsOrdered().ApplyOp();

Que coge una colección y aplica una operación sobre la misma usando todos los cores de la máquina pero al mismo tiempo garantizando que obtengo las operaciones en el orden correcto es la leche. Y no es algo nimio de resolver si lo tengo que resolver a mano (y es muy propenso a cagadas).

Pero es que el código de antes es la leche a varios niveles, no solo es que sea muy fácil de hacer (que está de pm), es que me incita a pensar así. Me invita a pensar en threads, como sincronizar cosas, como particionar los datos, como diseñar mis estructuras y aplicaciones para aprovechar esa potencia que tengo en la punta de los dedos. No creo que las APIs tradicionales multihilo y sincronizancion de casi ningún lenguaje (incluido C# originalmente) inciten a nadie a otra cosa excepto a pegarse un tiro.

Está de pm micro optimizar el new y cosas así, igual que he visto optimizar C# usando atributos y no propiedades, pero para mi en un proyecto grande, con problemas jodidos de verdad, las optimizaciones importantes no están en esos sitios. Están en el diseño a gran escala, en los algoritmos. Y si un lenguaje permite hacer esas cosas más sencillas, ahí es donde tengo las ganancias de verdad, y esa es la potencia de los lenguajes de alto nivel.

Que luego en otro lenguaje si te pones con el doble de esfuerzo consigues un poco más, gracias por participar, yo ya tendré dos terminados.

Por cierto porque hay gente que implementa GCs para C++? :p

[fjfnaranjo]

Vale, como me quoteas pues te respondo (quotear para mi es ponerse personal...).

Primera quote que me pones (me da la sensación de que ni te la has leído): no es relevante pa mi, pero pa ti si lo es. Si nos vamos a tirar 10 días con este debate porque no te lees los hilos de los demás al completo esto se llama debate ad nauseam.

Segunda quote: ¿se puede saber que tiene que ver el texto que pones con lo que has quoteado?

Tercera: el contexto histórico lo entendemos, precisamente por eso no vale C# ni para la consola de la propia gente que lo ha diseñado. Y yo no se lo que tu consideras un AAA, pero me da que íbamos a tener para otro hilo con eso...

Cuarta: negar que las capacidades de una persona no tienen nada que ver con esa escala que he puesto, de nuevo, arroja que no has reflexionado absolutamente nada sobre lo que he dicho y que te lo estás tomando de forma personal, cuando no es mi intención.

Quinta: aquí tengo pa dar por todas partes.

Que tu y yo vemos diferente C# es el origen del debate, eso ya lo sabemos.

Pero es que en lugar de debatir analizando el mensaje de los demás y construyendo contra-argumentos, te estas limitando a decir que el mundo debe andar a ciegas hacia la abstracción total confiando en que la tecnología y los sistemas pueden soportarlo, y parece que te crees que algún día alguien inventará algún tipo de mecanismo en algún lenguaje de manera que pondrás new Juego().getMechanicFromStratos(threadId).

En algún sitio tenemos que parar Vicente, y probablemente dentro de 10 años lo que estamos poniendo aquí no valdrá para nada, porque habrá salido la computación quántica-chusta-aleatoria y la memoria sea algo infinito e inabarcable, pero ahora mismo, C# se arrastra. Y te guste o no, se arrastra. En la xbox por la implementación, en el pc porque la gente no lo usa bien, y en linux porque los de mono tienen la culpa, pero C# se arrastra.

Y no tiene nada que ver con que haya inversión en C++. Si se pudiese usar C# para todo yo sería el primero que se quitaría la complejidad de los lenguajes antiguos o de más bajo nivel y te daría la razón. Pero es que hoy por hoy, a no ser que le den completamente la vuelta a C#, no tiene cara de que en el futuro vaya a ser el Grial de los lenguajes.

Y no soy un tradicionalista programador, ahora mismo estoy programando con Python y estoy más feliz que to con el lenguaje, y se pasa por el forro decenas de años de creencias en el fuerte tipado y temas varios...

[blau]

. Estos factores, aunque habrá otros, serían:

- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.

La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.

Por la parte que me toca, te advierto de que soy muy capaz de comprender el sistema con el trabajo y abstraer el problema real...  y por eso mismo uso C# y no me quejo, por eso mismo no hago triple AAA ni me paso a C++ para obtener el maximo rendimiento que no necesito.

He programado desde siempre en variedad de maquinas y lenguajes, ensamblador, c, basic, pascal, delphi. modula 2 y c++, aparte de que la ingenieria tecnica de sistemas me tuvo que servir de algo, aunque me quede el algebra y el calculo de primero, reconozco que estuve 4 o 5 años inactivo, hasta que tuve tiempo para volver a programar, y cuando probe c# con.Net me quede simplemente flipado.

No habia que buscar ni linkar librerias raras para hacer cosas normales como trabajar con cadenas de forma sencilla, habia una class File que te daba toda la funcionalidad que necesitabas, pero es que habia una clase Path con todas las funciones para trabajar con cadenas de rutas,... y asi para todo.

Pero cuando me corri fue cuando probe a cambiar codigo durante la ejecucion y me lo permitio... dioooosssss....aaahhhh

Y despues he descubierto linq y delegados anonimos.... podeis cantarme una misa, pero linq para hacer consultas sobre colecciones de datos es un lujo, por mucha basura que genere para el garbage collector...

De verdad, entiendo que os sea dificil cambiar porque estais acostumbrados a c++, a mi me pasara lo mismo con C#, y otros les paso con cobol, pero creo que es necesario ampliar la vision y no obcecarse.

[fjfnaranjo]

De verdad, entiendo que os sea dificil cambiar porque estais acostumbrados a c++, a mi me pasara lo mismo con C#, y otros les paso con cobol, pero creo que es necesario ampliar la vision y no obcecarse.

Ay Dios... mejor lo dejo ya porque no veo que sea sólo Vicente...

En cualquier caso, me voy del hilo diciendo dos cosas:

- En ningún momento he querido poner en duda la capacidad, desde el punto de vista intelectual, de ningún individual del foro, y toda posible interpretación que deje a ver lo contrario es una coincidencia de caracter accidental. En ningún momento he puesto tampoco en duda la capacidad de un tercero, o del conjunto de personas que toman una u otra decisión en cuanto al tema de este debate (si he puesto en duda la capacidad de un colectivo, el de los programadores, pero sin relacionar ninguna parte del mismo con ninguna de las decisiones tomadas al respecto de este debate).

- Yo uso muchos lenguajes, no solo C++. Un proyecto que co-hice en C# para un GameJam * dio buenos resultados, y los dió gracias a que usamos ese lenguaje y al grado de abstracción que nos otorgaba sobre el problema de la codificación de la idea que teníamos en mente. Mi opinión en ningún momento ha ido en el camino de atacar unilateralmente el lenguaje C#, al que respeto como respeto cualquier otro lenguaje.

* He participado dos veces en el Globla GameJam. El proyecto al que me refiero fue el de la primera que vez que participé. No digo que diese buenos resultados porque ganásemos ningún premio, si no porque cumplió con las espectativas que teníamos y pudimos reflejar una parte considerable de la mecánica que en un principio queríamos implementar.