Buenas, pues queria exponeros unas dudas para contrastar opiniones o pedir consejo sobre la implementacion del guion del juego.

Hasta ahora lo unico que he hecho ha sido programar demos de tecnicas o motores (excepto un proyecto entero de simulacion, aunque no era un juego). Lo que tengo en mente ahora es hacer un arcade/aventura no muy complicado, mas que nada para aprender y sobre todo para terminarlo.

Tengo el argumento del juego y una sinopsis del guion, pero a partir de ahi me surgen diversas dudas.
Voy a comenzar a diseñar el engine para ese tipo de juegos (para hacer algunas piezas reutilizables), ¿deberia tener en cuenta el guion de la historia para diseñarlo o con pensar varios escenarios y analizar diversos casos de uso me basta?
¿Como meteis el guion dentro del juego? Habia pensado en una especie de grafo de sucesos (cada suceso necesita de 1...n sucesos padre completados para ocurrir) y cada uno con un trigger asociado.
¿Cuan largo y completo suele ser el guion? Ya que si el juego debe durar un rato, deberia tener muchas cosas para hacer. ¿Como diseñais eso?

Bueno creo que nada mas por ahora. Gracias.

 Yo tambien soy un poco esceptico en cuanto a 'recetas magicas' o atajos para no ir por el camino empedrado (y con curvas, claro).
Lo de las dietas milagrosas es un claro ejemplo de como la gente se cree todo lo que le dicen porque a primera vista es la ostia. P.ej., el exceso de proteinas que propone Atkins en su dieta es muy perjudicial para el higado, pues no da a basto para eliminar esos excesos. A parte de eso, detras de las dietas y las grandes palabras Proteinas, Hidratos de Carbono y Lipidos, hay mucho mas (diferentes tipos de cada grupo, algunos 'mejores' y otros 'peores').
El tiempo es muy engañoso y relativo, y lo que parece que en 2 o 3 años no perjudica, termina pasando factura. ¿Quien nos iba a decir hace pocos años que el sol producia cancer? Aun ahora hay mucha gente que sigue sin creerlo (¿playa? ¿de 11 a 16h? ¿alguien? B) ).

Justificar el metodo del sueño polifasico con que en el reino animal se duerme de la misma manera puede ser otro grave error, puesto que los humanos tenemos el cuerpo bastante mas evolucionado que otras especies que duermen de esta manera. Lo de los bebes que nacen con este tipo de sueño, esta por ver si lo hacen porque los humanos descansan mejor asi, porque solo es mas beneficioso para los bebes o simplemente tiene otro tipo de motivo.

Con todo esto lo que quiero decir es que se suele hacer propaganda demasiado rapido sobre cosas que afectan directa y drasticamente en la salud. La gente es inculta y credula per se con los metodos milagrosos (comodidad?), asi que antes de publicitar algo de lo que no se sabe con certeza que repercusion tiene en la salud, que menos que advertir, ¿no?

 Vaya, ya era hora de que se hiciese un chapter en españa. Hace tiempo que se habia hablado por aqui (o por el IRC), pero no salio nada en claro.
A ver si hacen alguna reunion pronto, puede ser un buen punto a favor del desarrollo de la industria, aunque me quedo en mi lado esceptico por ahoa  :P  

 Nombre: tiutiu/yengamatic (Arturo)
Area: Diseño y construccion de software (es lo que mas me gusta de la informatica, y mas en infografia).
Disponibilidad: Este curso, si no encuentro trabajo, lo tengo mas holgado, asi que si hay faena a hacer y me motiva, tengo varias horas a la semana para dedicar (aunque advierto que soy un poco distraido :rolleyes: )

 Desgraciadamente, parece que todos tenemos 200 prioridades antes que 'relanzar Stratos'. Por eso siempre estamos con estos interminables threads sin llegar a nada tangible.

En el caso de que hubiese una organizacion para retomar la asociacion y promover proyectos y todo eso que se dice en el documento de TheWind, ¿cuantos de los aqui presentes estaran dispuestos a soportar lo que supone gestionar la asociacion? Con tanto trabajo, estudios y vida social, a nadie le quedan ganas ni tiempo para dedicar a un proyecto en el que no se ven mas que potenciales problemas.

¿Que opcion vamos a tomar? ¿Crear una asociacion y esperar a que uno de los cientos de 'grupos' de desarrollo saquen un proyecto para lanzarlo a una productora? O al contrario, que algun grupo termine algo presentable y entonces se retome la asociacion para, al menos, ayudar a ese o esos pocos proyectos listos.

En mi opinion, lo mejor seria tener algo para 'vender' antes de montar el chiringuito. Da seguridad para no cagarla como antaño y ganas de mojarse ya que se tiene el producto. Claro que habra desarrolladores que no les hara gracia, pero bueno, al fin y al cabo son amateurs. Stratos es un apoyo para sacar algo adelante, no es un requisito para hacer un proyecto.

 Como todos, yo tambien he tenido mis dudas sobre que sistema utilizar.
Usar punteros no es muy recomendable a la hora de exponerlos en una interfaz, ya que cualquier usuario puede hacer un delete y ya te han jodido.

La parte del motor que vayas a exponer al resto de usuarios yo la haria usando el sistema de handles. Aqui tienes un articulo sobre un sistema generico de handles para un manager de recursos, yo lo tengo implementado y va bastante bien (y rapido). Puedes implementar refcounting rapidamente.

Para usos internos de recursos en el motor, puedes usar smart pointers (o shared pointers) para compartir texturas, nodos, mallas y todo eso entre los distintos modulos. Claro que para muchas funciones internas puedes (y de hecho deberias) tirar de punteros por cuestiones de eficiencia.

Recuerda que la finalidad de estos sistemas es protegerte de los errores provocados por los usuarios. Si solo vas a usarlo tu, puedes fiarte de los punteros o usar shared pointers simples.  

 Puedes usar mixins para implementar comportamientos en tus objetos. Asi defines una interfaz para serializacion:

Código [Seleccionar] Expand


class Serializable
{
public:
 virtual bool Load ( istream inStream ) = 0;
 virtual bool Save ( ostream outStream ) = 0;
}

class MyObject : public Serializable
{
 int m_iFoo;
 string m_strName;

public:
 virtual bool Load ( istream inStream )
 {
   istream >> m_iFoo;
   istream >> m_strName;
 }

 virtual bool Save ( ostream outStream )
 {
   ostream << m_iFoo;
   ostream << m_strName;
 }

}


Creo que es una bonita forma de implementarlo. Puedes hacer lo mismo con otras interfaces como p.e. reference counting, renderable y demas.

 La cosa es simple. Cualquier desarrollador que quiera ver soporte para su producto en otros paises tiene que hacerlo, mandatoriamente (y siento decirlo asi), en ingles. Franceses, alemanes, polacos, italianos, hindues, japoneses, españoles... todos ellos escriben codigo y comentarios en ingles si quieren que el resto del mundo entienda/lea/use su codigo facilmente. Es un hecho y el que se resista, peor para el.

No hay cosa que me de mas rabia que estar mirando el codigo fuente de una demo y que no este en un idioma que entiendo. Lo bueno de la estandarizacion de algo es que todo el mundo puede conocer esas normas para entenderlo, y el ingles, pese a quien le pese, es el idioma de la informatica por antonomasia.

No se trata de encontrar traducciones perfectas con pocas palabras, sino que luego no podras enseñarle ese codigo a nadie que no hable español.


PD: Por cierto, la meta principal de documentar y nombrar correctamente las variables no es que tu lo entiendas (claro que tambien es para eso), sino para que LOS DEMAS lo entiendan. Da igual que estNombre para ti sea evidente que significa 'establecer el valor de la propiedad Nombre', el caso es que no es tan evidente para otra persona ;) Ahi esta el quid de la cuestion, amigo mio.

¿Para que fuera volumetrica del todo que habria que hacer? ¿No iluminar los vertices con normal en la misma dirección que la luz (triangulos con las caras opuestas a la luz)? Me refiero a si deberian salir esos barrotes oscuros y la luz pasando entre ellos.

Buen trabajo.  :)

Pues yo creo que si, pareceria como cuando se renderiza con HDR, aunque en ese caso la luz se correria un poquito por los barrotes. De todos modos parece sencillo el efecto, me gusta :D

 Vaya, se me olvido identificarme, argggg.

Saludos.

 Bravo por el thread, merece un sticky. Estos dias estaba por instalar linux en mi ordenata y al final creo que voy a poner Ubuntu, ¿alguien la ha probado? Hace tiempo ya proble enlightenment y me parecio genial y muy personalizable, lo cual me encanta. Ademas tampoco pesaba mucho y arrancaba rapido.

Por cierto KDevelop me parece q tiene una interfaz buenisima, muy parecida a la de Visual Studio .NET 2003, y eso es un halago. A ver cuando esta disponible para win32.

 Yo no voy a opinar sobre lo de los porros, ya tuve suficiente en el IRC, pero lo dejo en que hay demasiados topicos ;)

A veces hago lo mismo que AgeR, dejo de codear un par de dias y mientras miro el proyecto desde fuera; reviso documentacion, diagramas, ideas que tenia sobre como hacer algun modulo o clase, etc... Asi se me ocurren nuevas ideas y luego vuelvo con las pilas cargadas.
Y otras veces me imagino como quedara al final y lo mucho que he aprendido para llegar hasta el punto en el que me encuentro y me digo "vas a dejarlo ahora?" y asi sigo a saco. Pero bueno, al final siempre cojo carrerilla y me tiro a saco jejeje.

PD: sobre todo aderezo mis dias de programacion con buenas dosis de musica, parando para tocar la guitarra un poco o leer un poco una revista mientras pienso en lo siguiente a programar  :lol:  

 Pero si es que el sistema de estados no esta reñido con la disponibilidad de modulos en cada estado. Un estado simplemente es una abstraccion de tu metodo.
Si que te da mas flexibilidad tener cada modulo con su propio conjunto de estados, pero tampoco te creas que tanta (flexibilidad practica, la teorica no me sirve puesto que solo añade complejidad al final ;) ). En cambio, si quieres poder ver el menu mientras estas cargando solo tienes que habilitarlo en el susodicho estado y ya esta.

La maquina de estados 'global' por asi decirlo es un wrapper que representa un comportamiento del engine en un momento dado. Tienes una vision mas general de lo que esta pasando y no tienes que preocuparte de la maquina de estados interna de cada modulo. Reducir la complejidad, amigo!

Con respecto al sistema de eventos, tambien es independiente del estado de la aplicacion. Puedes mandar mensajes y eventos aunque solo tengas un unico estado.


PD: por supuesto que para gustos colores y todo eso...

 Joer, un peazo proyecto y nadie ha comentado nada :huh:
Lo que mas me ha gustado es que se vea como cambia el color del cielo y las nubes segun la hora del dia. Al movimiento le falta un poco pero esta genial. Desde que empece en esto de los graficos, hacer un simulador de paisajes en tiempo real es un sueño para mi: terrenos enormes, vegetacion, agua, cielo y control del tiempo y la hora.
A ver si puedo hacer algo de eso como PFC, algun dia... jejeje.

PD: ya que habreis mirado flipcode, os habeis fijado en la demo del grupo plastic? Sencillamente genial, si teneis una geforce6 bajaosla porque vais a llorar  (genial)  

 Yo prefiero mas un sistema de estados orientado a objetos.
Una clase base GameState de la que derivas los estados posibles del juego (PlayState, GameOverState, MenuState, ...). El engine tiene un apuntador al estado actual del juego, y en cada frame llama a la funcion de frame. Una version mejorada puede tener una pila de eventos.

El sistema del senior wapo no me acaba de convencer porque queda un poco confuso que es el estado del juego o de la aplicacion. En cambio una abstraccion del estado en un objeto a parte con su interface da una idea mas concreta.
Este metodo no esta reñido con el uso de subsistemas. El estado del juego es el que dice a cada subsistema que debe hacer. Siguiendo el ejemplo en el post de wapo durante la carga del juego, tenemos el estado LoadingState encima de la pila, y lo que hace es llamar a la funcion frame del GUI y del manager de recursos o de niveles.
Evidentemente cada estado tiene funciones de inicializacion, destruccion, pausa y resumen que se encargarian de 'cambiar' el estado de los subsistemas que requerimos.

Hace un tiempo vi un tutorial sobre estados de juego que da una buena idea sobre esto mismo.


PD: En los tiempos que corren, con CPUs potentes y equipos de desarrollo cada vez mas grandes y/o distribuidos, la OO y el diseño que de un concepto claro y conciso de que se esta haciendo prima sobre 'lo facil y rapido'.