Evitar el Hardcoding
El Hard-code es un término en el mundo de la programación que se refiere a una mala costumbre de poner los datos directamente en el código de nuestro programa o juego.
Ahora que estoy empezando con Unity he visto que resulta muy útil usar variables públicas, a las que se puede acceder desde el propio inspector del motor, para modificar datos y hacer pruebas de juegos con distintos valores establecidos. De esta forma, por fin me estoy dando cuenta que hay que huir del ya comentado Hard-code para facilitarse las cosas a medio-largo plazo.
Me explico
Imaginemos que estamos haciendo un juego de estrategia y pensamos que podría tener 12 casillas de alto por 16 de largo. El hardcoding sería escribir ese 12 y ese 16, así como suenan, directamente en alguna parte del código cuando necesitemos especificar el tamaño de nuestro escenario. Si más adelante decidimos que era más óptimo tener casillas más grandes y que haya solo 8 x12 tendremos que “bucear” entre todo lo escrito y cambiar esos números estén donde estén. ¡Por eso es una mala práctica!
En su lugar lo ideal suele ser irse a la zona de declaración de variables de nuestro código y escribir una constante (o una variable pública en el caso de Unity, para poder modificarla desde fuera) y usarla después en lugar de los datos en bruto. En el ejemplo anterior podríamos, por ejemplo, tener anchoTablero = 16 y largoTablero = 12, con lo que si hubiese que cambiarlo tenemos las variables localizadas al principio del código y resulta mucho más fácil actualizar.
A nivel de diseño podemos probar, por ejemplo, en un juego de coches con una velocidad determinada y cambiarla si vemos que parece exagerada y hace la conducción imposible o si nos ha quedado un vehículo demasiado lento. Para lograrlo ¿Qué tal una variable pública llamada velocidad, a la que podemos acceder sin meternos en nuestro archivo fuente y con la que podemos jugar para hacer testeos? (En este caso vuelvo a hablar del motor Unity, pero también se pueden tener variables fácilmente localizables en todo el código que escribamos sin importar el lenguaje)
Gracias a esta forma de trabajo tendremos mayor facilidad para hacer test y ajustar todas las variables importantes de nuestro juego hasta situarlas en su punto óptimo, como pueden ser la gravedad de un juego de plataformas, el número de balas o magias en juegos de acción, etc.
Ahora que estoy empezando con Unity he visto que resulta muy útil usar variables públicas, a las que se puede acceder desde el propio inspector del motor, para modificar datos y hacer pruebas de juegos con distintos valores establecidos. De esta forma, por fin me estoy dando cuenta que hay que huir del ya comentado Hard-code para facilitarse las cosas a medio-largo plazo.
Me explico
Imaginemos que estamos haciendo un juego de estrategia y pensamos que podría tener 12 casillas de alto por 16 de largo. El hardcoding sería escribir ese 12 y ese 16, así como suenan, directamente en alguna parte del código cuando necesitemos especificar el tamaño de nuestro escenario. Si más adelante decidimos que era más óptimo tener casillas más grandes y que haya solo 8 x12 tendremos que “bucear” entre todo lo escrito y cambiar esos números estén donde estén. ¡Por eso es una mala práctica!
En su lugar lo ideal suele ser irse a la zona de declaración de variables de nuestro código y escribir una constante (o una variable pública en el caso de Unity, para poder modificarla desde fuera) y usarla después en lugar de los datos en bruto. En el ejemplo anterior podríamos, por ejemplo, tener anchoTablero = 16 y largoTablero = 12, con lo que si hubiese que cambiarlo tenemos las variables localizadas al principio del código y resulta mucho más fácil actualizar.
A nivel de diseño podemos probar, por ejemplo, en un juego de coches con una velocidad determinada y cambiarla si vemos que parece exagerada y hace la conducción imposible o si nos ha quedado un vehículo demasiado lento. Para lograrlo ¿Qué tal una variable pública llamada velocidad, a la que podemos acceder sin meternos en nuestro archivo fuente y con la que podemos jugar para hacer testeos? (En este caso vuelvo a hablar del motor Unity, pero también se pueden tener variables fácilmente localizables en todo el código que escribamos sin importar el lenguaje)
Gracias a esta forma de trabajo tendremos mayor facilidad para hacer test y ajustar todas las variables importantes de nuestro juego hasta situarlas en su punto óptimo, como pueden ser la gravedad de un juego de plataformas, el número de balas o magias en juegos de acción, etc.
Hola, muy bueno el post y con gran razón el tema de lasvariables.
ResponderEliminarNormalmente no suelo hacer comentarios en blogs pero este es diferente. Debo hacerlo porque casi me he leido todo tu blog y a cada post me reconocía una parte de mi por la pasión por el diseño de juegos jejej Curiosamente tenemos los mismos libros de diseño de juegos(la colección de dibujo y pintura que citas en un post también :), también tengo todas las divmania, game over y me acuerdo mucho de tu juego cuando tenia el pentium 2. Empecé con esta pasión a mediados 80 con un Amstrad 6128 a los doce años con las revistas microhoby, Amstrad personal etc.. Pero me pasaba que tenia más vocación artística que de programación (tengo bachillerato artístico y cursos varios de diseño de pags webs etc pero hace años trabajo en otro ramo aunque sigo dibujando y me apasiona la historia del arte y la pintura, al final no hice Bellas Artes) y siempre ha sido una dificultad para mi programar. Es así que siempre he encontrado una herramienta o framework en cada ordenador que me permita olvidarme un poco de programación y centrarme más en la parte creativa. En resumen, en el Amstrad mis inicios programando Aventuras graficas que no llegué a terminar tanto en basic como en un parser. Más tarde a principios 90 me compre un Atari 1040 ste y con el un programa buenisimo el Stos Basic, como una especie de Div Games Studio de la época. Y ya despues con los Pentium vino el Div Div2 y mas tarde todos los engines game maker habidos y por haber. .. En todos he realizado cositas pero ninguna acabada.
Actualmente tengo una idea interesante y me compre hace poco el engine de html5 llamado Impact no se si te suena y el Construct2 para despues compilarlo con el Phonegap o el Cocoonjs. He mirado engines para moviles como el Corona sdk o el Gamesalad pero los veo demasiado caros, hay uno que no está mal y es gratuito que se llama gamechest pero no me convencía con mi situación actual de tiempo. Ya he formado una familia y no dispongo de tanto tiempo como hace años pero la pasión sigue intacta, y me he planteado con estos engines acabar un juego para móviles. Creo que hoy en dia la cuestión (si es que no vas en serio a programar en java o en c++) estriba en que engine vas a meter tu tiempo, ya que hay un montón hoy en dia... Mi selección de estos engines ha ido enfocada en la idea de crear un juego que pueda acometer con el tiempo que dispongo. Hay un montón gratuitos muy muy buenos para html5 aunque lo más parecido a mi actual nivel de programación serian estos dos que he apuntado. Unity es una genialidad he probado cosas y me he quedado sorprendido pero no podría sacarle todo el jugo yo solo.
Nada decirte que me encanta tu blog y darte ánimos para que sigas en serio con el C y Java aprendiendo mucho, y ya perdona si me he extendido mucho contando 'batallitas' 1 abrazo
Siempre es un placer leer a gente apasionada por los videojuegos. Supongo que todos tenemos nuestra historia de intentarlo una y mil veces y la tuya es muy interesante.
EliminarPersonalmente lo que siempre me asustó de los motores es "¿Que pasa si dejan de desarrollarlo y me encuentro con que he desperdiciado mi tiempo aprendiendolo?" Por eso tampoco he querido dejar de lado la programación "a pelo" pero me falta muuuucho por aprender.
Muy interesante tu historia. A ver si salen bien muchos proyectos. Y muchas gracias por los comentarios. Un saludo!
Tienes razón en eso a mi me pasó con los cambios de ordenador y de sistema operativo(un ejemplo el Div mismo que era msdos), o cuando empezaba a dominar el Stos Basic, que me gustaba mucho, el Atari y poco despues el Amiga dejaron de ser un ordenador competitivo en el comienzo de la era pc... te comprendo y haces muy bien de seguir formandote. Creo que pueden tener futuro engines en html5 a largo plazo (opinión personal eh?) por ejemplo, tanto móviles como tablets y más recientemente televisiones (seguro que aumenta un montón el mercado) tienen en común navegar en internet y aceptar una buena mayoría apps. En principio hay compiladores que permiten publicar en Android y iOS, eso si, quizas proyectos por ahora de mucha envergadura no se pueden hacer (con Unity si puedes crear juegos en 3d fabulosos y encima se exportan sin problemas a móvil es consolas...aunque hay que tener un equipo y dominar un lenguaje como el c) ,pero en plan indie en mi opinión es perfecto, es como volver al 'romántico' pasado de los 8 bits: Una, dos o tres personas haciéndolo todo y sin muchos costes porque lo publicas en las tiendas respectivas y directamente desde movil/consola/tele se lo descarga el usuario y en poco ya tienes hasta la crítica y opiniones diversas. No se, en general veo un mercado dinámico en este sector, mira los Angry birds, este juego sale al mercado en los 80 y seguro que de tan simple que es no lo compra nadie pero ahora el abanico de público es muy amplio(quien no tiene un móvil hoy en dia), no solo de jugones que les gusten juegos difíciles.
EliminarCon todo esto no quiero decir que en la parte económica sea un filón y te vayas a forrar al primer juego medianente adictivo que realices (no hay muchos que hayan conseguido tanto éxito como los Angry birds) pero si te pones a pensar en hacerlo por diversión sin pensar si va a tener éxito o no tu éxito propio como persona ya lo tienes asegurado: Antes, incluso en la epoca de Div necesitabas un medio para que te jugaran tus juegos revistas, distribuidoras que encima pasabas por un proceso de selección, pero ahora... dicho muy resumido tu lo subes a la tienda si a la gente le gusta ya verás como a poco a poco tu juego llega muy lejos.
Uy otra vez me vuelvo a enrollar mucho jejej Saludos
Buff, si, ya vamos aprendiendo todos que no es nada facil triunfar. Algunos tienen suerte o las habilidades necesarias. Otros, o no sabemos donde esta el secreto, o la suerte no nos persigue. Aun así trabajando y con paciencia se puede dar con la fórmula.
EliminarEstoy de acuerdo contigo en que los moviles ahora mismo son una oportunidad única para los que queremos meternos en el desarrollo de videojuegos. Pero es facil perderse en el inmenso mar de productos que salen cada día y no ganar nada. Cada época tiene sus pros y sus contras. Antes al menos sabías que si tu juego salía publicado algo de pasta te iba a dar y un buen número de usuarios lo jugaría. Hoy en día es más dificil destacar.