jueves, 5 de julio de 2007

La criatura se va a llamar:

Tras pensarmelo mucho, el engine del juego se va a llamar:

Aberrant engine


domingo, 1 de julio de 2007

Listas en c++

Las clases que voy a utilizar en el programa van a hacer un uso intensivo de listas de datos que se recorrerán para realizar alguna función.
Por ejemplo, la clase "escena" tendrá una lista de "sprites". "sprite" será a su vez otra clase que contendrá más listas.
¿Cómo implemento una lista? La opción más académica es crear un sistema de punteros con una clase que gestiona la creación de nodos, su inserción y su recorrido. Es un sistema eficiente en la gestión de memoria pero es un poco pesado de implementar. Además, no tengo claro la forma en que gestionaria los diferentes tipos de punteros. ¿Tengo que hacer una clase lista para cada tipo? ¿o hago una clase genérica y luego voy heredando y sobrecargando los metodos para cada una? Un coñazo.
La opción vaga es hacer arrays de objetos de esta forma:
    laClase *arrayClase;

arrayClase = new laClase[TAMANIO_LISTA];

[...]

delete[] arrayClase;

Así, todas las clases se instancian por que "new" llama a todos los constructores de cada elemento del array. Al principio, estos objetos tendrán la menor cantidad de datos posible e iremos "llenando" de datos cada nodo de la lista según lo vayamos necesitando. El comando "delete[]" llama a todos los destructores de las clases, que a su vez se encargarán de "deletear" sus arrays-listas. Es un sistema poco eficiente en el uso de memoria, pero seguro y fácil de implementar.
La memoria no me preocupa mucho. Todos los ordenadores modernos tienen bastante memoria.

domingo, 24 de junio de 2007

Sigo vivo...

Pronto más posts...

sábado, 16 de junio de 2007

Conclusión sobre las licencias.

Para el motor del juego y un pequeño módulo de ejemplo, utilizaré la licencia BSD, en la que permitiré la libre distribución del código y crear trabajos derivados tanto en forma de código como en binarios siempre y cuando se me nombre explícitamente en créditos y publicidad.
Para el juego completo utilizaré "Licencia Reconocimiento-No comercial-Sin obras derivadas 2.5 España License de Creative Commons" en la que no permito el uso comercial del juego ni permito modificarlo. Me reservo el derecho de cambiar de opinión más adelante :P

miércoles, 13 de junio de 2007

Más acerca de las licencias.

He seguido investigando sobre los tipos de licencias que podría aplicar al juego. En general, mis conclusiones son las siguientes:
La licencia GPLv2 y posteriores me obligan a publicar TODO el código fuente del juego. Eso incluiría las funciones que definen las escenas que van en librerías a parte. No me interesa esto, ya que no podría poner a descargar el juego sin que la parte creativa quedase expuesta.
La licencia LGPLv2 y posteriores permite que el código sea enlazado desde programas privativos si obligar a esos programas a que liberen a su vez su código. Esto esta pensado para publicar librerías de tal forma que todo el mundo pueda usarlas, incluyendo los productos privativos.
La licencia BSD original permite hacer cualquier cosa con el código siempre y cuando se nombre explícitamente al autor del programa o librería incluso en la publicidad que se haga del programa. Puede que esto me interese, ya que podría liberar sólo parte del programa bajo BSD y el resto sería cerrado. Otra versión de BSD posterior no tiene la clausula de publicidad.
La licencia X11. Quizás es la más sencilla de todas. Permite hacer lo que sea con el código mientras no se nombre en otro producto como característica. Como lo que busco es que mi nombre vaya con el juego, no creo que elija esta.

De momento, creo que BSD es lo que más me gusta. Ahora quiero saber si existe un equivalente legal español a esta licencia.

martes, 29 de mayo de 2007

Librerias y licencias

Quiero diseñar el juego de tal forma que el intérprete de escenas y los descriptores de escenas se compilen independientemente. Así, la máquina principal del juego, que controlará el refresco de pantalla, el ratón, las transiciones y demás, serán el ejecutable principal en C++. Cuando se “instancie” un objeto que contenga toda la información de una escena, el constructor llamará a funciones C que devolverán los valores adecuados para esa escena. Estas funciones estarán en una DLL a parte. Así tendré separados el juego del “engine”.
El uso de DLL es más lento (sólo un poquito más lento, vamos, inapreciable) que si integrase todo en un mismo ejecutable, pero así puedo lanzar el contenido artístico con una licencia restrictiva y el código del juego con otra más abierta.
Ya he hecho mis primeras pruebas y es relativamente sencillo. Incluir código C en C++ se hace con la instrucción:

extern “C” {
#include “cabeceraC.h”
}

Así, podremos llamar a las funciones en C desde C++.

martes, 1 de mayo de 2007

Almacenamiento y otros problemas

Tengo un mac de 24 pulgadas, un pentium 4 HT, un portatil de 12 pulgadas con un core 2 duo y otro portatil viejo que hace las veces de servidor de ficheros.


Utilizaré este último como repositorio del código y del "toolkit". Será algo sencillo, un samba para almacenar ficheros comprimidos manulamente. Pondré la versión a mano en el nombre de fichero. Sé que lo ideal sería un cvs o algo así, pero no tengo tiempo para eso.


Además, no puedo postear con el widget blogger en este blog. ¿Alguien sabe de algún programa para mac os x para postear aquí?