Pues por la simple razón de que los GPS integrados son tan malos que venderlos sería un insulto a la inteligencia y los que merecen la pena valen lo mismo que tenerlo por separado y además te tienes que comprar la antena para tener una buena recepción. EL único decente es qtek, pero la pantalla es mega pequeña.
El tema está difícil, la verdad.
ya queda poco
Bueno, se va acercando el día de la presentación y el juego avanza a buen ritmo. Ya casi está programado todo el bloque central salvo el cargador de mallas cosa de 1 hora teniendo los cargadores implementados de los pluggins de blender.
La primera de las imágenes es una de las típicas imágenes de explicación coder -> grafo. El modelo está hecho en Blender, que es lo único que sé tocar y poco, porque como puedes ver si te fijas en los bordes, cree un cubo y he copiado el resto de cubos. Supongo que Blender tendrá una herramienta maravillosa para eso, pero bueno.
La segunda imagen es una prueba de widgets, en concreto esa era una prueba para listbox. Estoy muy contento de la librería de widgets, es simple de usar, ha sido simple de implementar, funciona bien y es muy útil. Ya la publicaré
Por último una de las imágenes de croquis del diseño de una pantalla. Es una imagen muy simple creada con paint pero eso no implica que no tenga importancia. Es vital tener muy claro que se quiere hacer (en todos los aspectos del juego) para que la cosa no se prolongue.
De regalo una imagen más. No todo en el juego son gráficos, también he tenido que pegarme muchísimo con física, matemáticas, etc. La representación 3D a veces no permite comprobar todos los detalles, por ello hay que echar mano de herramientas tales como excel. En esa imagen se muestra información de un test creado para ajustar los parámetros del juego. Como estas gráficas hay unas cuantas miles más, arg !
Avanzando
Bueno, después de días intensivos de coding la cosa empieza a dar sus frutos. zwitter ya me ha empezado a dar gráficos y los he podido integrar perfectamente, no sé si gracias a su pericia entendiendo mis explicaciones, al motor que se lo come todo o a las dos.
Ya están funcionando perfectamente el sistema de rotura de sólidos (salvo un pequeño problema de centro de masas), la cámara tb funciona bastante bien aunque falta por rematar detallitos (1 hora de coding) y la AI, que aunque es simple y se basa en FSM, funciona bastante bien, sorprendentemente bien diría yo a tenor de las situaciones a las que le he sometido.
Una nota acerca del juego, el nombre es make figth y como suponeis es de lucha :)
widgets
Después de unos días replanteándome algunas cosas y haciendo una pequeña librería de widgets hay algunos frutos. EL screen es malísimo porque la textura la he pillado de no sé donde, está claro que necesita un toque de grafo :).
arg
Después de currar parte del fin de semana en el editor he estado probando a hacer algún objeto con él y es posible, pero es bastante lioso. Voy a cambiar el diseño original por completo, aunque puedo aprovechar una gran parte de lo ya programado :/. Las cosas del directo.
código del mes
En el
juego que estamos preparando para art-futura05 tenemos que hacer un editor para que el usuario se construya sus propios objetos. El juego está fuertemente orientado al 3D, con lo cual el editor tiene que dar un interface sencillo pero que permita controlar perfectamente las 3 dimensiones. Lógicamente el objeto se construye en base a otros más simples que el usuario debe colocar. Aquí es cuando viene el problema, hay que diseñar un sistema que permita que el usuario con el ratón seleccione en su pantalla (un entorno 2D) un objeto que está en un entorno 3D. Para ello OpenGL aporta un mecanismo llamado picking, que dándole las coordenadas del ratón (x,y) te retorna el objeto que se ha pinchado. Dicho así resulta simple, pero tiene algunos escollos que conviene salvar antes de hacer algo decente.
Para resolver el problema he creado una pequeña clase, que, aunque es muy simple, ayuda bastante:
class Picking:
def __init__(self):
pass;
self._buf = 1024*[1];
def Init(self, cursor):
#viewport = [0,0,0,0];
self._buf = glSelectBuffer(1024);
glRenderMode(GL_SELECT);
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
viewport = glGetInteger(GL_VIEWPORT);
gluPickMatrix(cursor[0],viewport[3]-cursor[1],
1,1,viewport);
gluPerspective(45,1.3333,0.2,200);
glMatrixMode(GL_MODELVIEW);
glInitNames();
def Push(self,i):
glPushName(i);
def Pop(self):
glPopName();
def End(self):
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glFlush();
return glRenderMode(GL_RENDER);
De esta forma le das las coordenadas del ratón, renderizas indicando los identificadores de los objetos y al terminar te retorna lo que has pinchado.
Lo paradójico del tema es que mirando después la documentación de pyopengl me doy cuenta que en GL__init__.py hay un wrapper muy parecido a este, pero que en vez de usar una clase, usa una función con un callback, que será la función de render.
En fins.. :_)
Editando
Bueno, teniendo la base (muy básica) del motor del juego, ahora empiezo a codear el editor para que el usuario cree sus propios ________. Como siempre, antes de empezar a hacer una cosa hay que pensar muy bien lo que se va hacer, y qué mejor que una imagen de coder para ver el diseño?
Además, mientras el usuario construye su ______ he decidido poner una vista en 3D, supongo que perpectiva isométrica, para ello después de hacer el render de la escena editada, haré lo siguiente:
1.- Reducción viewport a una de las esquinas de la pantalla
2.- poscionar la cámara
3.- Render del objeto
4.- Restaurar viewport
Incluso puedo hacer un render a textura, colocarlo en un quad y que el usuario pueda moverl la vista 3D por la pantalla. Esas florituras para cuando nos sobre tiempo, que no nos va a sobrar XD.
Avanzamos: Controles
Bien, después de pegarme con ODE unos días he programado el primer prototipo controlado por el usuario. De momento tiene controles muy básicos, pero creo que se quedará así, ya que quiero que el resultado final sea muy simple de manejar (como mucho 4 teclas).
ODE está funcionando a la perfección, sin utilizar el algoritmo quickstep va rápido y usándolo no hay ningún problema de estabilidad. Me queda por rematar el tema de las uniones rompibles. Tengo un pequeño prototipo, sin embargo no estoy muy contento porque, aunque es realista, no creo que aporte nada a la jugabilidad. Por eso creo que me voy a saltar a la torera la física real y voy a usar un algoritmo propio para añadirle jugabilidad y así dejarme una puerta abierta para modificar a mi gusto.
En cuanto a la parte gráfica aún no hay nada hecho, pero creo que a mediados del mes que viene tendré todo lo necesario para empezar a meter tema gráfico. Confío en la capacidad de zwitter para crear los gráficos necesarios, que creo que no serán demasiados (aunque hay que tener cuidado con los "creos").
Para terminar de rematar la planificación, creo que a partir de la fecha marcada se podrá empezar, además de meter tema gráfico, ajustar la jugabilidad que creo que será uno de los puntos fuertes del juego.
Diseño
Como siempre que se hace algo sin pensar demasiado en el diseño te encuentras problemas que no habías planteado que debes resolver. La cuestión aquí no es resolverlo, si no resolverlo o resolverlo bien.
Recuerdo uno de mis primeros días de trabajo en el que me dijeron una frase que nunca olvidaré: "lo mejor es enemigo de lo bueno". La frase es la filosofía de una gran parte de empresas españolas, en especial las PYMES, y desde luego es la filosofía que llevaban en aquella empresa ( INTRAME S.A. ). Sin embargo esta vez voy a resolverlo por el camino de lo mejor, que en este caso será amigo de lo bueno.
Al grano, necesito tener una estructura que agrupe estructuras del mismo tipo, esto es, un árbol. Esto no es complejo de implementar en cualquier lenguaje, por ejemplo, C++:
class Foo
{
typedef std::vector < Foo > Container; //std::list, Foo*, etc
Container _childs;
};
o python:
class Foo:
def __init__(self):
self._childs = [];
El problema aquí es que por debajo tengo ODE y cada objeto tiene un BODY que representa el sólido rígido del mismo, por lo tanto las agrupaciones de objetos no tendrán BODY, ya que ODE calcula sus posiciones en función de esos BODY. A su vez tengo el problema de que algunos objetos pueden dividirse en muchos otros, cada uno con su BODY y a su vez puede que cada uno de esos BODY tengan varias geometrías agrupadas.
Un jaleo, veremos como lo resuelvo.
Por cierto, decir que el juego va tomando forma, ya se empiezan a ver formas que se "verán" al final del mismo.
problemas
Como comenté el otro día tuve problemas al intentar mover toda una estructura a base de uniones fijas, debido en principio a la inestablidad y posteriormente a problemas de velocidad. La aplicación dee moverse con soltura para que el juego tenga una jugabilidad aceptable, ya que se trata de un juego que tendrá acción.
Después de leer la documentación y bucear por las listas de correo de ODE, encontré una forma que podría resolver mis problemas. Nada mas venir de sanfermines me puse a codear como un loco y después de una hora conseguí portar todo el código de la estructura la la nueva forma de definirlas. Los problemas surgieron por la visualización dummy que tengo hecha en base a cubos, esferas y cilindros, ya que no se adaptaban del todo bien a la física.
El siguiente paso es buscar unos puntos de soporte sobre el suelo, pero no puedo dar más datos. Como siempre, un screen, esta vez de una estructura creada en base a unos cuantos datos que tendré que aportar el usuario y unos cubos interaccionando con él. Una lástima que no pueda subir videos :/.
Bueno, se va acercando el día de la presentación y el juego avanza a buen ritmo. Ya casi está programado todo el bloque central salvo el cargador de mallas cosa de 1 hora teniendo los cargadores implementados de los pluggins de blender.
Por último una de las imágenes de croquis del diseño de una pantalla. Es una imagen muy simple creada con paint pero eso no implica que no tenga importancia. Es vital tener muy claro que se quiere hacer (en todos los aspectos del juego) para que la cosa no se prolongue.
Después de unos días replanteándome algunas cosas y haciendo una pequeña librería de widgets hay algunos frutos. EL screen es malísimo porque la textura la he pillado de no sé donde, está claro que necesita un toque de grafo :).
