Posiblemente empiece con una serie de noticias sobre el mundo de los videojuegos ahora que estoy tan puesto en el tema.

A lo que iba: han publicado el editor de mapas/quests/modelos/texturas de Torchlight, un buen aliciente para comprar el juego que está disponible por 15 euros pero que no tiene modalidad online, es decir se trata de una aventura offline. El juego es de los creadores originales de diablo, ha pasado por varias manos y ha cambiado de nombre mas de una vez, sobretodo alrededor de las fechas en las que se anunució diablo 3, pero finalmente salió a la luz hace bien poquito.

Foro oficial sobre modding de Torchlight: http://forums.runicgames.com/viewforum.php?f=6

Thread de descarga del editor:  http://forums.runicgames.com/viewtopic.php?f=6&t=5940

Página oficial Torchlight:  http://www.torchlightgame.com/

También teneis el juego disponible en Steam.

Como decia el de la película Princesas  “Tu le pones pasión a lo tuyo?”, el tema está ahí, en ponerle pasión. Como ya explique tengo problemas con la inspiración y el WoW me absorbe el tiempo libre de una forma que no es natural, básicamente porqué intentando escribir este mismo post no he podido definir cual es mi objetivo claro del WoW, quizá simplemente sea ver todo lo posible de este juego, ver que nos deparan los diseñadores y desarrolladores.

Tener un objetivo, una motivación es lo que hace que te dediques realmente a algo y lo vivas, que vuelques tus esfuerzos y tu tiempo en que salga adelante. Es por eso que tras AÑOS de no hacer ningún proyecto personal en PHP hice uno en cuestión de 1 semana, porqué habia motivación, habia un objetivo. Se trata de un sistema de recuento de DKPs para la hermandad del WoW, tenia claro que tenia que hacer algo mejor que lo que estamos usando ahora y lo hice.

Por el momento posiblemente amplie esta aplicación de recuento de puntos con un AddOn para volcar la información del juego a un archivo, para parsearlo y agregar las raids de una forma mas automática. La creación de AddOns para el WoW es una assignatura que tengo pendiente y es otro paso en la programación de videojuegos, ya que te familiarizas con un lenguaje que te permite interactuar con la interfaz de usuario y los eventos del juego, en este caso utilizan LUA, lenguaje de script muy extendido y que utilizan muchos frameworks de videojuegos, y XML para “pintar” la GUI.

Y luego? Bien, luego quiero terminar mi etapa Web, siento que me estoy encasillando demasiado en este tipo de programación, se me da bien no lo voy a negar, ademas como a muchos, también me motiva destacar en algo, pero lo que realmente me gustaria estar haciendo son proyectos personales relacionados con los videojuegos, aunque sea algo como el addon que he citado para la aplicación Web, o el juego basado en Web tantas veces citado en el Blog, algo a modo de puente entre lo que ya estoy haciendo y lo que me gustaria hacer… Ojala encontrara lo que realmente me hiciera ponerme las pilas, el siguiente paso ha de ser empezar algo que pueda enseñar junto con el currículum, algo que muestre de lo que soy capaz y donde vuelque esos conocimientos que he adquirido sobre el diseño y el desarrollo de videojuegos, pero… a parte del tiempo para desarrollarlo, que quitando el WoW tengo bastante, hace falta la inspiración u_u, el objetivo, quizá sea una empresa en la que me gustaria estar, a saber.  De donde la podria sacar esa motivación?

Tras un tiempo tanteando la opción de publicarla aquí está, una pequeña herramienta que suelo utilizar en mis aplicaciones webs para hacer AJAX.

Consiste en una clase con básicamente los siguiente métodos:

- Constructor de XMLHttpRequest.
- Método para capturar errores.
- Método de callback que debe ser sobreescrito para gestionar la respuesta.
- Método para realizar una llamada AJAX.
- Método para recojer todos los campos de un tipo indicado de un formulario.
- Método que combina los anteriores para enviar todo el formulario.
- Método para realizar la llamada añadiendo un script de forma dinámica, este no tiene nada que ver con lso anteriores pero está incluido dado que con este se puede realizar cross-server AJAX, en caso de que queramos tener el web en un lugar y un servidor separado para gestionar el AJAX.

Y como propiedades:
- Datos enviados.
- Datos recibidos.

Podeis encontrar un par de ejemplos y el código aquí:

http://www.virtualcraft.net/widgets/gahsamples.php

También está publicado en archivos a prueba en php-hispano con los .php de ejemplos para descargar en un zip junto con el .js:

http://www.php-hispano.net/archivos-tmp/148

Estoy en un proyecto del que estoy hasta los cojones, se entrega en enero y llevo un mes con el, y la verdad no sabria calcular la estimación total, ni yo, ni ningún analista de este planeta. Vamos a ponernos en situación, y a filosofar un poquito sobre la programación que se practica por aquí. Hay una serie de aplicaciones web hechas con JSPs y muchisimo javascript a pelo, es decir sin frameworks ni nada, y funcionan, de hecho hasta su mantenimiento no es tan incomodo como podia parecer, pero se está migrando todo a un framework propietario super chulo de la muerte basado en struts,

La perspectiva no parece muy mala, al fin y al cabo el framework propietario tiene sus ventajas a la hora de programar, la principal que no hace falta saber programar, el problema es que precisamente quieren que pongan a monos programando con el, debe ser por eso pasa por 300 clases para poner un hola mundo, y 300 mas para ponerlo centrado y en negrita, esto es facil de ver cuando salta una excepción no controlada y el track ocupa 5 pantallas (scroll). Lo mas insoportable del framework es que para moverte de una pantalla a otra, en linea recta perfecto, como quieras hacer un salto a otro lado, prepara tu imaginación y mogollon de rato para mapearlo todo, no basta con meterlo en sesion (StrutsContext). Dado que está pensado para ir en linea recta y palante, un simple menú que permita saltar entre las pantallas es lo mas tedioso de implementar, depende de como lo plantearas, una nueva pantalla representar modificar todas las vistas, y todos los webeans (flujos).

El otro gran quebranto es la migración, los modelos aquí son comunes en muchos proyectos, pero creeis que he podido reutilizar ni una sola clase de modelo? juas, ya me gustaria a mi, vereis, struts 1, o al menos la forma en que aquí lo utilizan, es muy bonito cuando tus modelos o beans tiene todas las propiedades como Strings, o alguna clase que implemente toString y te de su valor, como fechas etc, pues bien, aquí el colega programador super purista ya divido los datos en mogollon de clases, vease por ejemplo que un Cliente, tiene propiedades de la clase Domicilio, siendo domicilio una clase con las propiedades calle, numero, pisoPuerta, ciudad, cp, las cuales si son Strings, o si no hay suerte pueden ser de otros tipos propios. Esto va fatal para trabajar aquí, la cosa es que estos modelos no son del proyecto en JSPs, son de proyectos YA MIGRADOS!!, acojonante.

Total todos los modelos y beans nuevecitos de mi puño y letra, lo mas fácil ha sido hacerlo por pantallas, al ser una serie de formularios (como todo vamos) pues un bean con todos los datos de la pantalla, que es lo que le mola para luego pintar o recojer los datos (sobretodo recojerlos), en serio no soy yo, es que al fwork le va mejor. Total, aun por la mitad estoy añadiendo nuevas propiedades a estas clases.. pq? bueno, vayamos a la información de la que dispongo.

Acceso parcial a la aplicación original: pues como no podia ser de otra manera tiene fallos, sobretodo de javascript y como solo funciona en IE y es bastante especial se complica mucho pasar de pantalla, asi que no puedo ver ni todos los pasos ni hacer pruebas.

Screenshots de las pantallas actuales: posiblemente lo mas util del proyecto, ya que yo no consigo acceder a todo que mejor que poder ver como serian esas pantallas, estas screenshots han servido para reproducir las pantallas y crear los modelos.

El analisis de requisitos: vaya, ahora es cuando muchos pensaran que seré un inutil por no saber aprovechar este documento, amigos, el que consiga aprovechar este documento que me lo diga, es el analisis de requisitos original, solo le falta estar escrito en castellano antiguo, 27 paginas en las sobra redundancia, y creo que muy mal separado, si implemento un método que valida algo, quiero cerrarlo y punto, no quiero pasar 3 paginas y tener que editarlo, y pasar 3 mas, borrar lo anterior y volverlo a editar y si me lo leyera entero primero, no serviria, demasiados detalles que no recordaria, asi que hay que seguirlo paso a paso.

Con este material estoy lidiando, siguiendo el documento que me proporcionaron y que cada vez me cansa mas, sobretodo esos requisitos concretos de cada cliente, vale son requisitos y hay que ponerlos, pero joder, seguro que habia una forma mejor de indicarlo.

Para rematarlo la base de datos es comun para TODOS los proyectos en desarrollo, una fantastica db2 que debió inventarse antes que el fuego y que no para de ser tocada por todo cristo, lo cual conlleva a que en medio del desarrollo deje de funcionar la consulta de datos… genial vamos. Desde luego tengo algunas ideas de como mejorarlo, pero a estas alturas ya es chungo, no voy a volver a empezar.

Voy a citar un texto que me explico un compañero, es de un libro de “teoria de programación”, y creo que es muy acertado:

Si en un barrio, se rompe una ventana y nadie la repara, a la larga la gente que pase por ese barrio y vea la ventana pensaran que en este barrio no se cuida nada, así que el siguiente que pase no se molestará en tirar su lata de cocacola a la papelera, la dejará por ahí, y si se rompe otra ventana tampoco la repararán, y el siguiente que pase aun le parecera que lo cuidan menos ese barrio. Con esto quiero decir que los proyectos de software son como ese barrio, si hay un pegote de mierda enorme en los requisitos, no va a er el programador el que lo limpie, y dejará también pegotes en su código, y el siguiente programador que venga detras de el, cuando vea tal spaguetti hará lo mismo, haciendo la bola de mierda mas grande, hasta que llega un dia que hay que migrar la aplicación, y si se reaprovecha la basura que habia antes, pues acabará pasando lo mismo…, mas spaguetti, ni por muchos frameworks propietarios ultraproductivos que se utilicen, la cosa no va a mejorar por que sí a no ser que se replantee bien desde sus raices.

Fin del /cry.

Bueno los entendidos en el tema ya sabrán de que hablo, Javascript, nuestro código de programación web en el lado del cliente, jeje. Pongamonos en situación, resulta que mirando una herramienta que proporciona WoWHead para consultar datos de items, quests y otros elementos del WoW, y mostrarlos en un tooltip en tu página web, me ha entrado la curiosidad por saber como hacen que desde mi página puda consultar su base de datos, claramente eso no era AJAX convencional luego explicaré por qué.

Me he puesto a mirar su código y una vez encontrados los elementos que realizan dicha consulta he buscado un poco de documentación, no ha costado mucho dar con algunos ejemplos mas claros, dado que su código está “semiencriptado”, o mas bien todas las funciones y variables han sido renombradas a cadenas de 2 caracteres, esto dificulta la comprensión del código claro, pero es lo mejor en este tipo de aplicaciones dado que ocupan mucho menos, seguramente ellos tengan una versión original, embellecida, con otros nombres y con comentarios. Con un poco de paciencia,  sin la ayuda que nos proporcionaria la semantica en este caso, se puede averiguar como funciona.

Dicho esto explico: son muchas las aplicaciones que utilizan ya la tecnologia AJAX para hacer llamadas al servidor de forma que el cliente no lo vea, pudiendo consultar o guardar datos sin actualizar la página.

Existen varias formas de hacer AJAX dado que no se considera ni un código, ni una clase, ni una serie de funciones, aunque quizá el mas usual sea el XHR (XMLHttpRequest, o el equivalente en ActiveX). Ocurre que con este objeto no podemos hacer AJAX de forma remota, es decir, solo podemos hacer request hacia nuestro propio dominio. Sin embargo hay otra forma de hacerlo contra otros dominios, aunque lo que obtendremos siempre será código javascript para ejecutar.

Como funciona? Miy simple, en html tenemos el elemento <script>, este puede ser usado o bien para escribir código javascript en nuestra página, o para llamar a un archivo .js con dicho código, este archivo puede estar en otro servidor, la técnica consiste en agregar dinamicamente con el propio javascript un elemento script a nuestro head, cuya propiedad src apuntará a un js que puede o no estar en nuestro servidor, lo bueno es que obviamente podemos apuntar o bien a un js estático, o a una página dinámica generada en el servidor, enviando así cualquier consulta que queramos, también podemos pasar parámetros por GET con esta fórmula.

Veamos el ejemplo de código:

function llamadaServidor(urlJsRemoto) {
	var head = document.getElementsByTagName('head').item(0);
	var anterior =
        document.getElementById('ultimoScriptCargado');
	if (anterior ) head.removeChild(anterior );

	script = document.createElement('script');
	script.src = urlJsRemoto;
	script.type = 'text/javascript';
	script.defer = true;
	script.id = 'ultimoScriptCargado';
	void(head.appendChild(script));
}

La funciónn agregará un script al head llamando a “urlJsRemoto”, ademas borrará siempre el anterior script cargado, para ir limpiando scripts que ya hemos utilizado.

Link de referencia en inglés: http://www.dotvoid.com/2002/08/remote-scripting-with-javascript/

No soy partidario de los títulares en  inglés, pero este sonaba bien jeje. Pues ocurre que sufro una desinspiración total respecto al tema de desarrollar videojuegos, el tema es que llegar a casa despues de estar 8 horas y media programando, le quitan a uno las ganas de programar del todo :\, no solo de programar, también de apuntar y analizar ideas, así que muchas se me están quedando en el olvido.

Hay dos opciones, o bien hacer un web based de estrategia, utilizando sobretodo php, o bien hacer un juego de escritorio (o applet), en java, con gráficos 2D en el que se maneje programación de un game loop, gráficos, física, etc…

Es posible que tire por lo del juego en java, encontré un motor para 2D muy fácil de utilizar, a ver que sale .

Donde está la musa que ha de inspirarme? .

Me ha llegado un correo de un excompi de trabajo de una traducción de un artículo que cita 10 de las cosas que mas nos fastidian a los programadores. Me ha parecido muy cierto y contado de una manera muy divertida, mi favorito es el punto 8, aquí  una copia de la traducción y abajo un enlace.

• 10. Comentarios que explican el “cómo” y no el “qué”. Tan importante es incluir comentarios en el código como hacerlo bien. Es terrible encontrar comentarios que son una simple traducción literal al español del código fuente, pues no aportan información extra, en lugar de una explicación de lo que se pretende hacer. Muy bueno el ejemplo de Kevin en el post original… ¿eres capaz de decir qué hace este código, por muy comentado que esté?

  r = n / 2; // Set r to n divided by 2
  
  // Loop while r - (n/r) is greater than t
  while ( abs( r - (n/r) ) > t ) {
      r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
  }
  

• 9. Las interrupciones. Sin duda, el trabajo de desarrollador requiere concentración y continuidad, y las interrupciones son las grandes enemigas de estos dos aspectos. Una jornada de trabajo llena de llamadas, mensajes o consultas de clientes, proveedores, jefes o compañeros puede resultar realmente frustrante, a la vez que la distracción que introduce suele ser una fuente importante de errores en las aplicaciones.
• 8. Ampliación del ámbito. Una auténtica pesadilla, sobre todo cuando se produce durante el desarrollo, consistente en el aumento desproporcionado del alcance de determinadas funcionalidades o características del software a crear. Es especialmente desmotivador si, además, no viene acompañado por el aumento del tiempo o recursos necesarios para su realización.Kevin incluye en su artículo un ejemplo, algo exagerado pero ilustrativo, de sucesivas ampliaciones de ámbito que convierten un requisito factible en un infierno para el desarrollador; seguro que os recuerda algún caso que habéis sufrido en vuestras propias carnes:
  • Versión 1: Mostrar un mapa de localización
    – Bah, fácil, sólo tengo que crear una imagen; incluso puedo basarme en algún mapa existente que encuentre por ahí
  • Versión 2: Mostrar un mapa 3D de localización
    – Uff, esto ya no es lo que hablamos; tendré que currarme bastante más el diseño, y ya no será tan fácil partir de alguno existente…
  • Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando
    – ¡!
• 7. Gestores que no entienden de programación. Otro motivo común de irritación entre los desarrolladores es la incapacidad de gestores para comprender las particularidades de la industria del software en la que trabajan. Este desconocimiento genera problemas de todo tipo en una empresa y suponen un estrés terrible para el desarrollador.
• 6. Documentar nuestras aplicaciones. Lamentablemente, en nuestro trabajo no todo es desarrollar utilizando lenguajes y tecnologías que nos divierten mucho. Una vez terminado un producto es necesario crear guías, manuales y, en general, documentación destinada al usuario final que, admitámoslo, nos fastidia bastante escribir.
• 5. Aplicaciones sin documentación. A pesar de que entendamos y compartamos el punto anterior, también nos fastidia enormemente tener que trabajar con componentes o librerías partiendo de una documentación escasa o nula. Si lo habéis sufrido, entenderéis lo desesperante que resulta ir aprendiendo el significado de las funciones de un API usando el método de prueba y error.
• 4. Hardware. Especialmente los errores de hardware que el usuario percibe como un fallo de la aplicación son normalmente muy difíciles de detectar: fallos de red, discos, problemas en la memoria… por desgracia, hay un amplio abanico de opciones. Y lo peor es que por ser desarrolladores de software se nos presupone el dominio y control absoluto en asuntos hardware, lo que no siempre es así.
• 3. Imprecisiones. Aunque Kevin lo orienta al soporte al usuario, el concepto es igualmente molesto en fases de diseño y desarrollo del software. Las descripciones vagas y confusas son una causa segura de problemas, sea en el momento que sea.Son irritantes las especificaciones imprecisas, del tipo “esta calculadora permitirá al usuario realizar sumas, restas, multiplicaciones y otras operaciones”… ¿qué operaciones? ¿divisiones? ¿resolver ecuaciones diferenciales?Tampoco es fácil encajar un mensaje de un usuario tal que “me falla el ERP, arréglalo pronto“… A ver. El ERP tiene cientos de módulos, ¿fallan todos? ¿podríamos ser más concretos?
• 2. Otros programadores. Como comenta Kevin, el malestar que provoca a veces la relación entre programadores bien merecería un post independiente, pero ha adelantado aspectos que, en su opinión, hace que a veces el trato con los compañeros sea insoportable:
  • Personalidad gruñona, hostilidad
  • Problemas para comprender que hay que dejar de debatir la arquitectura del sistema y pasar a realizar las tareas
  • Falta de habilidad para mantener una comunicación efectiva
  • Falta de empuje
  • Apatía hacia el código y el proyecto
• 1. Tu propio código, 6 meses después. Sí, es frustrante estar delante de un código aberrante y darte cuenta de que tú eres el autor de semejante desastre. Y tras ello llega la fase de flagelación: ¿en qué estaba pensando cuando hice esto? ¿cómo fui tan estúpido? uff…Este hecho, sin embargo, forma parte de la evolución tecnológica, personal y profesional; todos estos factores están en continuo cambio, lo que hace que nuestra forma de atacar los problemas sea distinta casi cada día.

Fuente: http://www.variablenotfound.com/2008/10/las-10-cosas-que-ms-fastidian-los.html