1. UltraLeetJ ,
bgt fue un lenguaje de programación desarrollado por philip benefall (Blastbay Studios) cuya última versión nos data más o menos en el año 2010. Su propósito era ser un lenguaje simple y versátil que se junta con una poderosa plataforma para poder hacer audio juegos.
Suena noble y todo, pero cuál fue el grave error?
Precisamente ese.
BGT es bastante fácil para iniciar a programar, y el manual está escrito de tal manera que a cualquier persona se le facilita el proceso. Tiendo a pensar que es demasiado fácil, y les diré por qué. A veces, la curva de aprendizaje para una cosa puede ser una barrera natural para algunas personas que realmente no deberían estar haciendo esa actividad en cuestión. Consideren a una persona que es extremadamente torpe con un mal rendimiento físico, y por ende es más propensa a accidentes, que se mete en trabajos de construcción. Esta probablemente no es la mejor idea, ya que hacer trabajos de construcción implica, al menos el manejo de herramientas pesadas y afiladas, y dependiendo de lo que uno esté haciendo, herramientas eléctricas. ¿Debería alguien torpe y propenso a accidentes trabajar con sierras, martillos, etc.? Veo esto como una analogía perfecta para describir que la gente siente que puede hacer esto de la programación, y claro que pueden, en un nivel muy básico, porque el manual está bien escrito. Si la persona no tiene el talento suficiente, no tiene ese impulso para tener éxito, y no tiene una sed de conocimiento y aprendizaje, muy probablemente no será un buen programador. Así es, la programación es mucho más que tan solo escribir líneas de código, se trata de conceptualizar lo que uno desea hacer y hacer que suceda. Se trata de ver relaciones donde otros nunca ven nada, y es algo totalmente milimétrico, preciso y exigente; porque una computadora sólo puede hacer lo que se le dice, exactamente lo que se le dice que haga, y nada más. Las computadoras en realidad son máquinas muy, muy tontas, los buenos programadores les harán pensar que son inteligentes.
Pero volviendo al caso, con cualquiera que sea capaz de alcanzar algunos conocimientos básicos de cómo programar en bgt, sienten que deben estar progresando. Llegan a un punto en el que pueden hacer algunas cosas, y no otras, por lo que buscan ampliar sus conocimientos mediante el uso de cosas llamadas clases, que van sacando de otro lugar. Las clases en términos de programación son herramientas muy poderosas, porque están a tan solo una instrucción de include. Esto significa que se pueden colocar dentro de algún proyecto, agregar una línea en la parte superior del script y ahora toda la funcionalidad de esa clase está disponible para ser usada por el script u otros scripts en el proyecto. Hay clases para generar menús, para manejar inventarios, para crear armas, crear enemigos y así (no les suena familiar con muchos juegos que existen por ahí?). Las clases son poderosas, porque se puede implementar el uso de una clase sin mucho esfuerzo, pero ¿qué aprende la persona al hacer esto? la verdad, casi que nada, ya que el código no es realmente suyo. No voy a entrar en el robo de código en esta sección, pero tengan en cuenta que asumo que las clases que se están utilizando en muchos juegos están disponibles libremente por el bien de este post, y no el código fuente filtrado que ha sido apropiado indebidamente por otros desarrolladores.
Ahora bien, tenemos un juego que utiliza muchas clases diferentes, ninguna de las cuales realmente le pertenecen a nuestro pseudo programador. Así que lo que él hace es modificar los parámetros que toma algo llamado el constructor de la clase, o se modifica el propio constructor y la persona que hace el juego ingenuamente cree que ha codificado su propio juego. Nota bene – Un constructor es aquello que toma la información que tiene algún nuevo objeto, que fue creado por una instancia de la clase a la cuál esta se inicializará cuando se crea el objeto, por ejemplo, cuánta salud tendrá un enemigo, y así.
Me pregunto entonces, cómo es posible que alguien que usa clases externas y así , pueda decir que logra conocer y entender el código. La respuesta es que, a menos que se tomen el tiempo para familiarizarse íntimamente con su funcionamiento interno y estudiarlo a profundidad, jamás lo lograrán. Sólo obtendrán un resultado final, algo que simplemente funciona, y eso es suficiente para ellos. Sin embargo, eso no es lo suficientemente bueno, porque modificar el código sin saber realmente lo que está pasando conduce a lo que nos irrita a todos a la hora de jugar... cosas llamadas errores, fallos, bugs. Errores que el usuario final espera que el desarrollador pueda corregir, pero quién sabe si realmente pueda hacerlo.
BGT también es limitado en cuanto a que no puede imprimir texto, o mostrar gráficos de cualquier tipo en la pantalla. Con la excepción de una pequeña ventana que todos los juegos de BGT muestran en la parte superior izquierda de la pantalla, que es un requisito para que el juego pueda tomar el foco, y aceptar la escritura de números o letras del teclado, eso es todo lo que se puede hacer. Por lo tanto, mientras que otras comunidades se esfuerzan por la inclusividad, BGT es algo también totalmente excluyente, y probablemente seguirá siendo exclusivo para los ciegos, o al menos, los ciegos que utilizen lectores de pantalla, los que no usen lectores de pantalla, o usen otras ayudas tales como magnificadores no podrán jugar o hacer nada. BGT también tiene un soporte de librerías muy limitado, por lo que, si alguien desea utilizar una biblioteca que ofrece espacialización, algo que es casi una funcionalidad principal en audiojuegos, puede o no ser capaz de cargarlo (por eso hay tanto juego nuevo que es 2d). Así que, si se necesita hacer algo externo a BGT, buena suerte para que funcione.
NO todos, pero sí muchos de los que usan bgt nunca van a otros lados en sus vidas de programadores. No usan otros lenguajes, se sienten muy cómodos en bgt. Lo que significa que están totalmente atrapados y limitados a las restricciones que tiene bgt, el cual es muy bueno para juegos simples, pero rápidamente se acaba esa libertad cuando se quiere crear algo más grande.
He sido bastante duro para que la gente se aleje de BGT -y lo seguiré siendo- porque es perjudicial para todos. Es antiguo, es inseguro, ha sido abandonado, y no puede enseñarte las verdaderas habilidades que necesitas para desarrollar cosas. Te detiene y te hace pensar que puedes hacer cualquier cosa cuando la realidad es que simplemente no puedes. También es sólo 32 bits (cuando hoy en día casi todo tiene un potencial enorme al ser 64 bits) y además está en la mira de muchos software de antivirus, que sólo hace que el problema empeore; ahora la gente tiene que hacer todo tipo de maromas sólo para jugar tu juego. No puedo pensar en un juego convencional, comercial, mainstream en existencia que requiera que agregues una excepción a tu software de antivirus sólo para poder jugarlo.
Pero en fin, mi conclusión? es que los nuevos desarrolladores , sobretodo los más jóvenes deberían adquirir buenos fundamentos de programación y bases sólidas para escribir código antes de ponerse a subir proyectos inconclusos, bien sea por alimentar su ego, por querer llamar la atención, o por mostrar su trabajo prematuramente. Si quieren saber algún aspecto de cómo es que funciona una clase, sería bueno que se contacten con el desarrollador original y pregunten, la estudien y la aprendan y que no solo la usen y ya. El autoaprendizaje es clave, y también el posponer los lanzamientos. El probar el juego una y otra vez, ojalá con grupos de personas de confianza y con diversos computadores (viejos y nuevos). Pensar si existe algún otro lenguaje más rbusto y más capaz (python por ejemplo) que brinde una solución a algún problema.
La verdad es que la programación de juegos es de lo más difícil que hay, sin importar cómo se rebaje, o se mire. SI fuera tan fácil de hacer, esa industria hubiera caído hace mucho tiempo ya, sobretodo por falta de calidad. Así que por favor no dejen que le pase esto a los audiojuegos, está en sus manos.
Resultado: +0