• Braulio Madrid

La controversia del código de Yandere Simulator



En el blog pasado había hablado acerca de la polémica que se generó al salirle competidor al juego #YandereSimulator y como el desarrollador cometía un montón de errores debido a su personalidad, pero también se mencionó como el código se habría filtrado, dejando al desarrollador al nivel de ser un noob en la programación, a lo que había opinado que no creía que fuera así.


Como dije en el anterior blog, he seguido el desarrollo de yandere simulator casi desde el inicio y les puedo asegurar que el desarrollador no es para nada un noob, pero tampoco digo que sea un genio excepcional, tan solo digo que es un desarrollador del montón como muchos.


Desde que se filtró el código han surgido un montón de debates de varios programadores youtubers, hablando desde lo mal hecho que está un código, hasta como arreglarlo, hasta pasar por justificarlo o simplemente burlarse de él.


Resulta que cuando se publicó la filtración, #YandereDev dijo que el código filtrado no era el código de su juego, pues el filtrador lo único que hizo fue usar un decompilador que reconstruía el archivo dll del juego a lenguaje C#, pero los decompiladores no son perfectos, pues en el fondo después de ser transformado en binario, muchas cosas decorativas desaparecen y lo que se obtiene es una reconstrucción burda, pero igualmente funcional.


Pues #YandereDev tenía razón y no al mismo tiempo; resulta ser su código pero no exactamente como lo había programado, así que aquellos youtubers que lo justificaron tenían cierta razón, pues el uso de controles de flujo if else if no dista mucho del uso de switch y por alguna razón el compilador de unity convierte todos los switches en else if.


Por otra parte las funciones quedaban al principio y las variables al final, pues para los que no saben, unity en el fondo corre C++ y C, nada raro que el compilador tome la misma lógica con el código C# aunque no sea necesario, pues en los lenguajes en los que puedes estructurar las funciones en el orden que quiera, igualmente son las clases y las funciones las que se cargan en la memoria ram primero y considero una buena practica crear las funciones primero antes que la implementación.


#YandereSimulator abusa mucho de #EfectosDeImagen, que ya he explicado en varios blogs de como construirlos y sus implicaciones en el rendimiento, unity en las versiones anteriores obligaba a usar script que toma datos de la cámara y los envía a un material que a su vez envía la textura de lo que ve en pantalla para hacer con esta textura lo que uno quiera, pero al estar construido de esta forma, envía una y otra vez una textura nueva, esto es poco eficiente y se requiere planeación para elegir los efectos de imagen que más convengan a la estética del juego.


En mi opinión, al tratarse de un juego cartoon, no vale la pena usar #SSAO (Screen space ambient occlusion), en ese caso es mejor pintar las texturas pensando en este efecto, desenfoques de movimiento, efectos glow muy exagerados, en ese caso sería mejor hacer una lista de efectos comunes en los animes, como el desenfoque de profundidad de campo y algunos que alteren el color o que agreguen texturas a la pantalla, pero hacerlas en un solo pase, pero no todo programador tiene que saber de shaders, así que le perdono parte, pero igualmente debe aprender aunque sea un poco del tema.


Al parecer el juego tenía la opción de elegir un shader que pintaba a los personajes con el estilo cartoon, con o sin contorno, de una extraña manera duplicando el mismo modelo 2 veces, en este punto se me hace ilógico que eso ocurra o que un desarrollador lo piense así, es lógico pensar que se está dando un tiro en el pie si se hacen las cosas de esta forma, lo que muchos youtubers se aprovecharon de esto para motivo de burla.


Un contador de frames mal programado, mmm no sé, yo también he sido víctima de eso y es que es lógico que falle, pues lo único que hacen los contadores de frames es contar cuantos frames o time.deltaTime pasan por un segundo, y el valor del deltaTime no es que sea preciso, lo más adecuado seria en este caso usar algún programa externo como msi afterburner que lo haga, esto también fue motivo de burla.


Los frames caían al parecer porque se usaba muchas instrucciones en el método update, tal vez si y quizás si es cierto que faltó planeación, pero a los programadores quien los entiende, ¿acaso no dicen que optimizar prematuramente es el demonio?, precisamente yo soy de aquellos que pre optimiza y no he tenido problemas en hacerlo, salvo el retraso que supone preparar los assets para llevarlo a cabo, pero cada día mejoro mis herramientas para hacerlo, así que no sabría si culparlo o no.


De aquellos YouTubers que hablaban de como mejorar el código, está bien opinar para tomarlo como ejemplo y ver otras formas de abordar el problema, creo que eso enriquece el debate, pero creo que hablar desde las gradas es muy fácil y quizás no tuvieron en cuenta la situación del desarrollador, no siempre es fácil aplicar en patrones de diseño, creo que cada desarrollador trata de hacer lo mejor que pueda con su proyecto, pero en muchas ocasiones no se puede seguir la teoría a rajatabla.


En conclusión y con todo respeto los programadores son unos estúpidos, yo soy distinto así que me saco de esa colada, todos hablan y teorizan sobre como hacer mejor las cosas, pero para empezar nunca se han puesto de acuerdo en solo usar unos pocos lenguajes, en tratar de sintetizar las cosas en lugar de complicarlas y volver la tecnología obsoleta, los juegos son cada vez más y más pesados, lo que demuestra que cada día que pasa son menos óptimos, en lugar de buscar hacer lo mejor para plataformas más modestas.


Este episodio demostró que muchos programadores son hipócritas, aparentemente se ven como personas solladas, amigables y serviciales, pero das la espalda y se burlan de ti.


Me consta que muchos son miserables con el dinero son muy desconfiados con el trabajo de otros, pero quieren que confíen en el trabajo de ellos, pagan malos salarios y son ególatras, que repiten como loros la teoría de los libros, porque hablar es fácil pero codificar es difícil-


Lo que le ocurrió a yandere dev, es lo que le ocurre a muchos, sentirse que puede hacerlo todo solo, querer abordar mucho y no saber hasta donde llega su propio alcance, son problemas comunes que seguramente les ocurre a aquellos que se burlan de él.


Ya me quedé a gusto esta vez, creo que mi postura es clara, si eres programador espero que seas consciente que no todo en esta vida sale como uno se lo espera, me gustaría que cualquiera que se siente un experto codificando, reflexione y piense si quisieran que los trataran como a Yandere Dev y le bajen un poquito a ese síndrome dunning kruger para que vean las cosas en su justa medida.


Si no eres programador y por alguna razón eres un espectador, entiende que desde afuera todos los gremios parecen chéveres, pero todos somos humanos y como en todo, hay de todo y lo común es encontrar gente que se burla de la desgracia ajena.


Espero que se haya entendido esta reflexión. No siendo más nos vemos en el siguiente blog.



© 2023 por Darkcom. Proudly created with Wix.com | Peñol, Antioquia, Colombia| +57 3113389725 | Politica de privacidad

  • GitHub
  • BMadrid
  • DarkcomDev
  • Darkcom.dev
  • Braulio-Madrid
  • YouTube Darkcom Tech
This site was designed with the
.com
website builder. Create your website today.
Start Now