sugerencias para divgo del pesado de hokuto

[hokuto40]

Hola amakast y gracias por este ejemplo. :D

Esta sugerencia es sobre todo para gente nueva que quiera utilizar divgo y se encuentre este problema,ya que los engines que hay hoy en dia te hacen esto automaticamente y te olvidas de limpiar recursos y ademas creo que para proyectos grandes este metodo es fundamental,porque hacerlo manualmente se te puede complicar bastante a la larga.

Comentando el ejemplo ,hay un par de cosas que no me quedan claras,la primera es que veo procesos sin un bucle y sin el frame,esto es posible,yo pensaba que esto no se podia hacer.

Otra cosa que veo es en el proceso pasar de nivel,estas llamando en dentro  un proceso que se llama nivel() y no lo veo por ninguna parte,ademas que le pasas como parametro el nombre del proceso nivel() y yo no sabia que fuera posible llamar a otro proceso como parametro de otro proceso,me acabo de perder un poco. :-\

[AmakaSt]

Hola amakast y gracias por este ejemplo. :D

Esta sugerencia es sobre todo para gente nueva que quiera utilizar divgo y se encuentre este problema,ya que los engines que hay hoy en dia te hacen esto automaticamente y te olvidas de limpiar recursos y ademas creo que para proyectos grandes este metodo es fundamental,porque hacerlo manualmente se te puede complicar bastante a la larga.

Comentando el ejemplo ,hay un par de cosas que no me quedan claras,la primera es que veo procesos sin un bucle y sin el frame,esto es posible,yo pensaba que esto no se podia hacer.

Otra cosa que veo es en el proceso pasar de nivel,estas llamando en dentro  un proceso que se llama nivel() y no lo veo por ninguna parte,ademas que le pasas como parametro el nombre del proceso nivel() y yo no sabia que fuera posible llamar a otro proceso como parametro de otro proceso,me acabo de perder un poco. :-\

De nada hokuto40.

Sobre los dos puntos:

1. Esto se debería de poder en cualquier Divlike, sin bucle solo pasa una vez (cuando el proceso es llamado) y sin frame no espera a que se dibuje nada en pantalla. El proceso hará las llamadas y gestiones que deba hacer y morirá.
2. nivel() es una variable privada del proceso pasar_nivel que recibe el nombre del proceso por parámetro, por lo que luego puedes hacer la llamada desde la variable, esto no se si lo soporta otros divlikes, aquí una explicación de lo que es, lo soporta muchos lenguajes por lo que no es tan raro: https://es.wikipedia.org/wiki/Expresi%C3%B3n_lambda

Un saludo.

[hokuto40]

Gracias por la explicacion. ;)

Dime!,hay alguna sugerencia que puedas introducir en divgo.

[Drumpi]

Mas sugerencias.

Si se quiere conseguir una buena animacion no queda mas remedio que trabajar con arrays,pero esto hace que se llene de muchos numeros y si hay muchas animaciones puede ser una locura.

Se me ha ocurrido el crear una funcion para esto.

Code Select Expand


animacion(fichero,grafico inicial,grafico final,velocidad)


Aqui tenemos la funcion con el fichero,el grafico donde quieres que comience,el grafico donde finaliza y la velocidad de animacion.

Claro esta que para hacer bien esto habria que meter cada animacion en su fpg correspondiente,es decir...Si tienes el personaje parado con sus animacion ira en un fpg y si tienes el personaje con movimiento en otro fpg.

Pues en lugar de pedirle a AmakaSt que la haga ¿Por qué no la implementas tú con las herramientas que hay? Es fácil crear un proceso como el que mencionas que se responsabilice de cambiar el gráfico del proceso padre.
Mi única sugerencia es que haya una variable local en dicho proceso padre, para que al crear un proceso "animacion", compruebe si hay algún proceso y eliminarlo, antes de asignarse a sí mismo a dicha variable, y de esta forma tener siempre un único proceso que controle la animación.

[Drumpi]

Otra sugerencia,pero esta es una flipada mia que puede no ser muy sensata pero te la digo igualmente.

Esta claro que no vas a crear un editor de escenarios para colocar mis objetos y crear un buen escenario,entonces lo tengo que crear yo y no tengo ni idea de como se hace.

Se me ha ocurrido unas funcionalidades que faciliten esta tarea.

Code Select Expand


crear_editor(proceso,guardar,camara)
activar_editor = true o false
rejilla(tamaño de cuadricula,tamaño de cuadricula)


La variable "activar_editor" es para decirle al programa que funcione como editor,la funcion rejilla(32,32) es para decirle el tamaño de cada cuadricula de la pantalla donde colocaremos los objetos,ya sea el suelo o la pared o un enemigo.

Esta rejilla sirve para que no se pongan encima un objeto de otro,y la funcion crea_editor(proceso,guardar,camara) tiene el proceso que vamos a utilizar para ir colocandolo en el nivel,luego pondremos en guardar a true para que guarde el contenido creado cuando cierres la aplicacion y el parametro camara = true es para activar la camara.

La camara estara configurada para mover con los cursores de teclado y el objeto lo moveremos con el raton y si dejamos pulsado el boton izquierdo se ira colocando continuamente mientras nos desplazamos con el raton.

Si queremos crear mas objetos y seleccionarlos utilizaremos otra variable para que se activa el boton de seleccion que sera la rueda del raton.

Code Select Expand


seleccion_objeto = true


Por lo que si tenemos muchos objetos se podran seleccionar con la rueda del raton y quedaria de esta forma.

Code Select Expand


crear_editor(proceso=type objeto,guardar=true,camara=true)
crear_editor(proceso=type objeto2,guardar=true,camara=true)
crear_editor(proceso=type objeto3,guardar=true,camara=true)
activar_editor = true
rejilla(32,32)
seleccion_objeto = true


Cuando queramos volver al modo normal para jugar a nuestro nivel creado pues desactivamos el modo editor.

Code Select Expand


activar_editor = false


Se que esto es una flipada mia pero hay esta por si sirve para dar alguna idea y facilitar el diseño del editor casero.

¡Y tan flipada! ¿No prefieres una función llamada "create_game" que haga todo el juego por ti? :D
Aquí te toca crearte tu propia herramienta: o te creas un array en memoria y lo vas llenando de números, o usas un programa externo, ya sea el tiled o uno propio, y luego lees el fichero generado para ir poniendo los elementos que quieras.
Ya sé que esto es algo básico, pero hay mil formas de hacerlo, y no todas sirven para todos los tipos de juegos.

Creo que estás confundiendo un lenguaje de programación de videojuegos, con un entorno de desarrollo de videojuegos. Conviene que te olvides de GameMaker, porque ni DivGo, ni DIV, ni Fenix, ni Gemix, ni BennuGD ni PixTudio tienen nada que ver, y empieces a pensar como un programador de verdad :D
Y no, no te estoy echando la bronca, todos hemos pasado por lo mismo, y todos necesitamos este toque de atención. Sólo quiero que pienses, antes de pedir, si lo puedes hacer tú, y cuánto tardarías en hacerlo ;)

[Drumpi]

Sigamos con esto.

Ahora una coleccion de funciones y variables para el movimiento.

Code Select Expand


Hspeed;
Vspeed;
advancePoint(x,y,velocidad,tipo,rotacion);
advanceSinCos(tipo,velocidad,angulo);


Hspeed y Vspeed es para darle al objeto un movimiento en vertical y horizontal,esto es util para cosas simples pero se puede utilizar para juegos de plataformas y cuando te hable de las sugerencias sobre plataformas estas seran muy utiles para esto.


advancePoint(x,y,velocidad,tipo,rotacion) esta te la explique pero te la explico otra vez,el objeto se desplaza a la posicion x e y, y con su velocidad,el tipo seria si quieres que sea un desplazamiento en linea recto o circular y la rotacion es para decirle si quieres que el sprite rote segun la direccion que tenga o no.

advanceSinCos(tipo,velocidad,angulo),esta funcion es como si utilizas las funciones sin() y cos() juntas,con esta dos funciones se consiguen unos movimientos interesantes pero hay que meter mucho codigo y calculos y es un rollo.El tipo es para decirle si quieres que el movimiento sea en vertical,horizontal o en circulo,luego la velocidad y el angulo es para decirle el tamaño del recorrido,como recorrer un circulo pequeño o grande. 

A ver, lo mismo en DivGo no existen porque hace tiempo que no lo toco, pero voy a suponer que sí porque son funciones básicas del primer DIV: busca GetAngle, o fGetAngle, y piensa cómo puedes usar XAdvance en tu beneficio. Tanto para perseguir a un enemigo, como para seguir una ruta.

Lo de los movimiento sinusoidales y circulares, sí, es un rollo de implementar, pero si sabes trigonometría, sólo necesitas DOS lineas:

x += 1;
dato += 1000;
y += pos_vert + 10*sin(dato);

Donde pos_vert es la posición del centro de la sinusoide, y dato es un valor que se autoincrementa en cada frame, para darnos valores equivalentes a ángulos entre 0º y 360º, que al usarlo dentro de la función sin nos devuelve valores entre -1 y 1, por eso lo multiplicamos por 10, para que el proceso se mueva arriba y abajo un máximo de 20 pixels.

[Drumpi]

Vamos con mi sugerencia favorita.

Los divlike no tienen ningun sistema para el manejo de los niveles y por lo que veo todo el mundo suele usar el switch() para manejar todos los objetos y crear multiples niveles,pero cuando se trata de un juego muy grande se complica bastante el tema.

Ademas de que se te puede quedar por hay algun procesos vivo y ya ves los problemas que te puede causar.

Yo propongo crear un proceso especial para esto,con algunas funciones que te ayuden en el manejo de los niveles.

Code Select Expand


process_scene nivel1()
begin
      graph = 1;//grafico del fondo
      x = 300; y = 200;
      jugador();
      enemigo();
      enemigo2();
      balablabla();
      loop
         if(ya no hay enemigos en pantalla)
         pasar_nivel(type nivel2);//funcion para pasar de nivel
         end
   
         if(el jugador muere)
         reiniciar_nivel();//funcion para reiniciar nivel
         end
         frame;
      end
end

process_scene nivel2()
begin
      graph = 1;//grafico del fondo
      x = 300; y = 200;
      jugador();
      enemigo();
      enemigo2();
      balablabla();
      loop
         if(ya no hay enemigos en pantalla)
         pasar_nivel(type nivel3);//funcion para pasar de nivel
         end
   
         if(el jugador muere)
         reiniciar_nivel();//funcion para reiniciar nivel
         end
         frame;
      end
end


Tenemos el proceso especial process_scene() que es para el manejo de niveles,este tiene todas la propiedades del proceso normal y ademas sirve para el manejo del nivel.

Es decir,esto es un contenedor donde meter todos los objetos del nivel y cuando pasamos de nivel con la funcion pasar_nivel(id) se elimina automaticamente todos los objetos que hay en el para que al pasar al siguiente nivel este todo limpio y solo con los objetos del nivel 2.

Ademas tambien eliminara automaticamente los textos y los recursos que haya en la memoria.La funcion reiniciar_nivel() hace lo mismo que pasar_nivel(id) pero en vez de pasar al nivel siguiente volvera a mostrar el nivel donde esta con todo limpito para mostrar lo del nivel actual.

Pongo un videotutorial de gamemaker donde se explica como se manejan los niveles en este engine y con esto podras entender mejor mi sugerencia.
https://www.youtube.com/watch?v=BaTGBtdKLBU

Hay que ver entero el video sino no sirve. :)

Como ya te ha dicho AmakaSt, cada uno implementa sus propias rutinas para los niveles.
Puedes usar un switch o no, pero creo que tener un "play_level", creado por tí, que se encargue de cargar los recursos y guardar sus ID en listas, y crear los procesos de juego, y al terminar, los libere y mate respectivamente, es la mejor solución.
Aparte, hay funciones y métodos para obtener y descargar todos los recursos, como el delete_text(all_text), Get_id(type xxx)...

Adelantándome a los siguientes tres mensajes, te recomiendo que examines el código de un juego de DIV llamado "Castle of Dr Malvado", que te dará muchas pistas sobre gravedad y rebotes. Si puedes encontrar el "manual avanzado de programación de DIV", en él se explica el código con más claridad.
Y mover hacia objeto ya te lo he dicho: GetAngle, y XAdvance.

[hokuto40]

Hola drumpi,esto son solo sugerencias para dar ideas no es algo que haya que coger como esta y introducirlo tal cual,son solo eso,ideas por si sirve.

Pero entiendo lo que dices,sin embargo creo que tu forma de ver las cosas esta obsoleta,si lo que quieres es que solo unos pocos utilicen el lenguaje div,simplemente hay que dejarlo como esta,pero si quieres que mucha gente se interese por este lenguaje no queda mas remedio que cambiar y añadir algunas cosas para que sea mas atractivo.

Si cualquiera llega aqui para aprender a crear juegos y tu le dices que se tiene que montar su propio sistema de animaciones,niveles,editor de niveles,y basicamente crear todo desde cero pues entonces esa persona pensara que es mejor aprender c++ o java y montarse su propio engine y acabara antes.

Si cada vez que quiero crear un juego tengo que crear desde cero todo el motor del juego,es reinventar la rueda continuamente y desde luego a esto no se le puede llamar engine de juegos porque no trae las herramientas necesarias para facilitarme el desarrollo de juegos.

En definitiva,que cualquiera que entre aqui y vea lo que hay se ira directamente a unity,godot,ureal etc..

Pero esto no es una critica,eso solo como esta el tema hoy en dia,y el desarrollo de juegos sigue evolucionando y cada vez las herramientas son mas sencillas y completas.

Pero hay que pensar que los desarrolladores de juegos no van a usar un lenguaje div como esta hoy en dia y los programadores tampoco lo van a usar,unos usaran un motor grafico y los otros usaran un framework para sui lenguaje de preferencia.

Entonces donde queda el lenguaje div,pues hoy en dia en tierra de nadie,por eso me parece buena idea que el lenguaje div sea un hibrido entre motor grafico y framework,si no,seguira igual.

[SplinterGU]

Drumpi, menos mal que has aclarado que no era echar broncas... ahora me quedo mas tranquilo!!! xD (???)

hokuto40, lo que drumpi dice en cuanto a que eso es un lenguaje de programacion, me temo que tiene razon, esto es un lenguaje de programacion, no porque existan otros integrados donde todo se hace con clicks nadie lo va a usar... por ejemplo, porque exista lenguajes como Visual Basic .NET (por decir alguna pavada) donde haces casi todo con clicks, no significa que yo deje de programar en C, o que lo prefiera a C... esto es un lenguaje orientado a programar... fantastico seria un IDE grafico donde no se tenga que programar o solo programar lo basico, pero eso es algo encima del motor... y no todo el mundo lo prefiere...

comparar los divlike con unity, unreal, godot, etc... es un poco injusto, detras de esos hay una compañia o algun tipo de apoyo detras, aca somos solo unos pocos compartiendo nuestros trabajos...

igual creo que con tus sugerencias has ayudado a enriquecer el proyecto de AmakaSt...

[hokuto40]

Drumpi, menos mal que has aclarado que no era echar broncas... ahora me quedo mas tranquilo!!! xD (???)

hokuto40, lo que drumpi dice en cuanto a que eso es un lenguaje de programacion, me temo que tiene razon, esto es un lenguaje de programacion, no porque existan otros integrados donde todo se hace con clicks nadie lo va a usar... por ejemplo, porque exista lenguajes como Visual Basic .NET (por decir alguna pavada) donde haces casi todo con clicks, no significa que yo deje de programar en C, o que lo prefiera a C... esto es un lenguaje orientado a programar... fantastico seria un IDE grafico donde no se tenga que programar o solo programar lo basico, pero eso es algo encima del motor... y no todo el mundo lo prefiere...

comparar los divlike con unity, unreal, godot, etc... es un poco injusto, detras de esos hay una compañia o algun tipo de apoyo detras, aca somos solo unos pocos compartiendo nuestros trabajos...

igual creo que con tus sugerencias has ayudado a enriquecer el proyecto de AmakaSt...

Hola SplinteGU.

Se perfectamente que el lenguaje div es un lenguaje de programacion y que no tiene nada que ver con entornos de desarrollo y jamas compararia este fantastico lenguaje con entornos como unity o unreal donde hay cientos de trabajadores detras.

Sin embargo creo que no es incompatible con este lenguaje el hecho de que se le puedan introducir algunas funcionalidades para facilitarte el desarrollo de los juegos,porque yo veo que trae algunas funciones como advance(),get_angle(),start_scroll(),signal() etc...

Y gracias a estas funciones me resulta mas sencillo hacer algunas cosas y no veo a nadie quejarse de estas funciones o otras que ya trae el lenguaje,ademas de que el lenguaje trae un sistema de procesos que ayuda a la creacion del juego y nadie se queja de esto.

Por eso no veo mala idea el introducir mas cosas relacionadas con los juegos y que el lenguaje sea mas atractivo para mas gente.

Hay tenemos phaser,que es un framework donde todo se hace programando y sin embargo ya trae una seria de funcionalidades para facilitarte el desarrollo del juego y trae un sistema de animaciones y niveles integrado,algo que por aqui parece una locura.

Por cierto drumpi,este tema de sugerencias lo cree porque amaka me invito a crearlo,si no,no lo hubiera hecho.Y aqui solo hay un porcentaje pequeño de sugerencias,desde luego tengo muchas mas pero de momento me las guardo para mi.

Y ya por ultimo y acabo,no os tomeis a mal mis comentarios,solo lo hago por si sirve de ayuda para mejorar este lenguaje,no hay ninguna critica a este lenguaje,todo lo contario,estoy muy agradecido por la creacion de este lenguaje.Pero hay que acordarse para quien fue creado div game studio--""para gente sin conocimentos de programacion"",creo que habria que recuperar esa filosofia.  :)

[SplinterGU]

me parece muy bien... y no quita todo lo que has veniendo recomendando... lo mio solo fue un comentario sobre 2 cosas concretas... el resto no opino como Drumpi, me parece fantastico sigas aportando sugerencias...

[Drumpi]

¿En serio parecía enfadado? :P No era mi intención, lo siento.


Antes que nada, yo me alegro de ver sugerencias, y animo a hacerlas. Es sólo que a muchos novatos les pasa (como me pasó a mi) de empezar a hacer sugerencias sin conocer el lenguaje o el objetivo del mismo, y terminan casi pidiendo que les hagan el juego :D :D :D

Pero es que he leído cosas a lo largo del hilo (aunque todo sea dicho, lo he hecho a super-velocidad, entre compilación y compilación del código) que no te lo hace ni Unity.
Por ejemplo, el sistema de "niveles", aunque Unity tiene algo llamado así... no sé si lo has utilizado, pero me parece un sistema horroroso, porque el paso de parámetros es complicadísimo para el novato, y provoca una cantidad de copy-paste entre niveles bestial... Copy-paste es el principal responsable del 70% de los bugs en los códigos, no te quiero ni contar en un entorno más orientado al desarrollo mediante ratón.

Es cierto que un scroll tileado sería imprescindible en BennuGD, y se lo comenté hace años a Splinter... y a Slainté en época de Fenix, y en ambos casos me remitieron al código fuente para que lo implementara yo, e incluso lo estuve mirando, pero claro, por falta de tiempo y conocimientos, ahí se quedó.
Por eso implementé mi propio motor en Fenix y lo trasladé a Bennu, que me daba mucha más flexibilidad que un código encerrado en una DLL (animar los tiles, darles propiedades diferentes, cambiar el FPG para cada capa...)... y el código lo publiqué para que se usara, y el editor de mapas de tiles para usarlo.

Pero otras cosas como "¿por qué no se implementa una función para...?", la mitad de las que he leído, se pueden hacer por código, y con apenas 20 líneas. Por ejemplo, segur un camino de X puntos: ya digo, un bucle, fGetAngle y XAdvance. Imagina que se implementa ¿Cómo? ¿Y si quiero que haga un giro suave? ¿Debe alterar el angle del proceso? ¿Debería ejecutar una animación? ¿Y si quiero una animación diferente en cada tramo? ¿O si quiero que avance girando sobre sí mismo? ¿Y si otro proceso lo empuja fuera? Son demasiadas cosas que puedes hacer de forma diferente.
Vale, quizás se pueda implementar la más básica para los novatos, y que los expertos usen la suya propia, pero no sé, me parece que hacer eso forma parte del aprendizaje.

Al final, cada uno termina por desarrollar sus propios trozos de código, y los va copiando de proyecto en proyecto, e incluso lo comparte con los demás para que no tengan que reescribirlo (no sé la de veces que habré pegado el código de input de texto por teclado :D ).

Por cierto, SplinterGu ¿En qué no estás de acuerdo conmigo? Me gustaría saber :)

[Drumpi]

PD: De hecho, sólo he comentado las partes que me parecían más obvias que no se iban a implementar. Del resto no he dicho nada porque, aunque si bien son fáciles de hacer mediante código DivLike, podría ser interesante para los desarrolladores de los lenguajes evaluar el implementarlo o no. Al fin y al cabo, son ellos los que deciden qué entra y qué no, y yo sólo soy un simple usuario del mismo :P

[hokuto40]

Hola drumpi,entiendo lo que dices pero llevo probando los distintos divlike desde hace unos 2 años.

Aunque tambien es cierto que no estoy todo el rato con los divlike,hay veces que utilizo un divlike,otras gamemaker,otras construct 2, otras muchos otros que he ido probando.No te digo todos porque estaria hasta mañana escribiendo.

La mayoria de sugerencias que he hecho las se programar pero lo he hecho pensando en las personas sin conocimientos de programacion.Veras,el lenguaje div o todos los divlike estan en una situacion que ya saben todos y por eso pienso necesario un cambio en el lenguaje.

Intentar hacerlo mas asequible para las personas que empiezan.Si tu quieres hacerlo todo desde cero pues me parece perfecto,pero tu ya tienes experiencia,algo que una persona que empieza no y si se encuentran con tanta dificultad se iran para otro lado.

Lo mejor es ofrecerles una ayudita al principio de su aprendizaje para motivarlos,y con el tiempo cuando tengan soltura ellos mismos sin forzarlos crearan sus propias funciones.

Sigo pensando que no es incompatible las dos cosas,tener un lenguaje que te permite programar de dos formas,una mas clasica y avanzada y otra mas moderna y sencilla.

Lo mejor es mirar las cosas que funcionan en los engines mas utilizados y tratar de trasladarlas con el tiempo al lenguaje div,hay muchos engines donde mirar con codigo abierto.Godot,pilasengine,phaser,gdevelop etc..

Creo que esto animara a mucha gente a utilizar el lenguaje div,porque ahora mismo ni tu lo estas utilizando,supongo que sera por algo,y no me digas que no tienes tiempo,cuando algo te gusta sacas tiempo de donde sea.

Y si,he probado unity y tampoco me gusta su sistema de niveles por eso es mejor mirar phaser,pilasengine,gamemaker etc...

Por cierto,el tema del editor de niveles,lo suyo seria hacer compatible el lenguaje div con tiled map editor,que ademas trae una funcionalidad para pintar con una capa de color los objetos que tu quieras que sean colisionable.

[Drumpi]

Bueno, yo llevo con los DIV-like desde el 2002, cuando aprendí a programar en C, usando aquel "vetusto" DIV2, por lo que sé lo difícil que es la curva de aprendizaje :D
Y más teniendo en cuenta que me he enfrentado a la "curva de aprendizaje" de un nuevo lenguaje ya unas cuantas veces, pues si me pongo a enumerar los que me han enseñado y los que he tenido que aprender, te puede dar algo, pero te resumo en que he visto cosas desde ensamblador a Xamarin, así que por variedad no será :D

Pero sí que entiendo el problema, y estoy de acuerdo contigo, que hay cosas que hay que mejorar, pero hay otras que no porque falta personal o porque no entiendes cómo funciona realmente.
Por ejemplo, dices que Tiled pinta con un color los objetos colisionables. Muy bien ¿Y cómo sabe Bennu que es un objeto colisionable? Eso no es más que un atributo en memoria. ¿Significa eso que Bennu debería controlar las colisiones con ese tile? Vale, y si colisiona ¿qué hace? ¿Impide al gráfico avanzar? ¿Y si quiero que el gráfico lo atraviese porque los disparos del prota sí atraviesan los campos de fuerza para activar el botón que hay detrás?

Como digo, no voy a entrar en qué debería estar o no en Bennugd, en DivGo o en X, porque eso es decisión del desarrollador/es, pero que tienes que tener muy claro qué es un entorno de creación de videojuegos, como es Unity o Construct, y qué un lenguaje orientado a videojuegos, como los Div-like, XNA Framework, o el combo C+SDL. Son dos filosofías diferentes.


Ahora, si quieres saber por qué no programo ya en Bennu, mis razones no tienen nada que ver con que me haya dejado de gustar: llego a casa de trabajar sobre las ocho de la tarde, y apenas tengo dos horas antes de cenar y acostarme, y eso incluye las tareas de casa, ducharme, etc.
Si a eso le sumas que me he tirado como 8 horas y media, como mínimo, programando en C#, VB6, XML, SQL o lo que me echen encima, como tu comprenderás, lo último que me apetece al llegar a casa es ponerme a programar. Me he visto obligado a cambiar mi hobby por el modelado 3D en Blender, para no pasarme el poco tiempo libre que tengo enganchado a la consola, y hacer algo creativo para que no me estalle la cabeza con tantas ideas como tengo sin hacer.