Desarrollo de videojuego [XNA]

Buenas forer@s,

Es increíble que con todo el tiempo que llevo visitando la página web no me había fijado en esta categoría del foro.., pero me viene perfecto para mi proyecto ^^. Os cuento:

Estoy llevando a cabo el desarrollo de un videojuego usando XNA y vengo buscando gente interesada en participar. El proyecto lo podeis seguir en mi blog.

El caso es que no tengo en mente hacer un jueguecillo para aficionados, es decir, nada de Pong, Tetris o Super Mario. Lo que busco hacer en este juego lo describo en esta entrada, pero como resumen os puedo decir:

- Es un juego en 2D

- El estilo será una mezcla de juegos/géneros. Mi intención es presentar una ciudad que muestre "vida" rollo GTA, con bandas a las que unirse e incluso dar la posibilidad de crear tu propia banda. Y tanto el jugador como distintos personajes del juego contarán con alguna habilidad especial (los que conozcais la serie Heroes os hareis mejor a la idea). Y estas habilidades a través de un sistema de experiencia se podrán ir desarrollando (es decir, un poquito de rolete pero sin mucha profundidad, lo justo para que tenga gracia volver a jugar y explorar otras posibilidades)

- Como ya os contaba arriba, será para PC y usando XNA a machete. Sin uso de ninguna otra herramienta, ya que al final eso acabaria limitando las posibilidades de desarrollo.

- Una vez terminado lo que sería el funcionamiento básico del juego, entraría al desarrollo de partidas multijugador.


Y poco más... bueno, muchísimo más, no os voy a engañar , pero con esto debería bastar como carta de presentación.

Y como punto final os pongo un vídeo con lo que está hecho como prototipo v0.0, que a nivel funcional presenta los distintos menús y avance y retroceso entre pantallas, pero que a nivel de codificación tiene hecha toda la estructura necesaria para comenzar con el desarrollo del motor gráfico del juego.

Un saludo y... ¡animaros!, que podemos crear algo muy interesante entre todos.

¡Perdonar!, algo que antes no os había comentado y que puede que os pregunteis es en qué áreas se puede participar.

Principalmente vendría bien gente para programación, diseño gráfico, composición musical, guión e ideas con las que ampliar lo que ofrece el juego. Así que si os interesara podeis decirme por aquí o por privado que áreas os llaman la atención.

Yo particularmente tengo un poco de experiencia en casi todo. Diseño de clases, codificación, gestión y desarrollo de proyectos, sistemas distribuidos y redes, inteligencia artificial, diseño gráfico, composición musical..

Con eso lo que quiero hacer es animaros a los que os interese de verdad hacer un juego, ya que os puedo garantizar que esto no se va a quedar a medias por falta de experiencia, si falta gente en un determinado área tal vez vayamos más lentos, pero no voy a dejar que nos quedemos atrancados en ningún punto .

Un saludo!.

Ánimo, el proyecto tiene buena pinta.

Yo, personalmente, habría optado por intentar un diseño, análisis de requisitos, etc. desde el comienzo y luego definir las iteraciones en función de los mismos. El problema que le veo a ir pensando en cada iteración es que puede que te des cuenta de algún problema o conflicto con anteriores requisitos, y tendrás que ir cambiando sobre la marcha, con el riesgo de documentación desactualizada, etc.

Está claro que de la otra forma también pueden surgir cambios a posteriori, pero teniendo una perspectiva global del proyecto, considero que es más fácil afrontarlos.

Lo digo sobre todo si al final el grupo de desarrollo aumenta. Si eres tú solo, aunque sea sin darte cuenta, seguro que tienes una visión bastante clara de lo que el proyecto será. Pero como empiece una verdadera tormenta de ideas desde 4 ó 5 puntos de vista diferentes, te puedes encontrar reescribiendo los mismos requisitos varias veces.

Por otro lado, me llama la atención lo que comentas de XNA y el paso de 2D a 3D. ¿Seguro que es tan fácil? Puede haber muchas cosas en 2D que no tengan sentido en 3D y viceversa. Si desde el principio lo tienes en cuenta, no hay "grandes problemas", porque vas a saber dónde tienes que diferenciar, qué código puede compartirse, etc. Pero si no lo tienes en cuenta y luego quieres cambiar... prff, se puede liar un buen batiburrillo.

En cualquier caso, reitero mis ánimos.

Hola gothmog_es,

Muchas gracias por los ánimos ^^, espero poder compartir algún día este proyecto como una versión final jejeje.

Ahora respecto a lo que me comentabas de hacer primero requisitos y diseño y luego emplearme en implementación de prototipos.., ¡comencé con ello!. Pero observé que me dejaba muchas cosas en el tintero (mi mala cabeza ). Así que ahora aprovecho ese guión a lo informal, y al tener la idea del juego ya pensada y en parte escrita, formalizo y amplío los requisitos, y avanzo el diseño teniendo en cuenta lo que preveía, lo que llevo hecho y lo que haré más adelante, intentando que sea lo suficientemente abstracto como para que si más adelante se me ocurrieran más cosas, no supusiera una gran dificultad (por eso el esfuerzo en un diseño piramidal).

Luego como indicas tienes toda la razón. Al ir haciendo prototipos, muchas de las cosas que voy haciendo se irán desactualizando e incluso algunas pueden llegar a ser inútiles y eliminadas en versiones posteriores.., es a lo que me enfrento con este ciclo de vida del software . Pero bueno, como ventaja le veo que es algo más dinámico y siempre anima el ir teniendo resultados, experimentando, jugando con ellos, etc.

Ya por último lo que comentas sobre las 2D y 3D es cierto. Seguro que dar el salto plantea su dificultad respecto a los cambios que se tendrán que introducir, he ahí otro de los motivos de mi empeño en realizar un buen diseño, tanto para evitar el mayor número de cambios posibles, como para concentrarlos en unos pocos métodos y que luego no se convierta en una tarea imposible por culpa de su descentralización.

Una vez más muchas gracias por los ánimos y bueno, según vaya sacando nuevas versiones con más funcionalidad del juego las iré comentando por aquí como reclamo para que se una gente al proyecto xDD.

Un saludo!

Si el juego no es excesivamente complejo yo no me rompería el coco haciendo un diseño porque vas a tardar más en hacer el diseño que el juego.

Si el juego es excesivamente complejo yo no me rompería el coco haciendo un diseño porque vas a tardar 4 años en acabar debido a que cada dos días te saldrán 20 cosas no previstas que te obligarán a modificar cien anteriores. Es el problema que vas a tener al estar tú solo, no te vas a dar cuenta de mil cosas y menos de primeras.

Si el juego es complejo pero no demasiado el diseño puede estar bien para una sola persona pero aún así yo no lo usaría xD

Sinceramente, todo lo que aprendí en la carrera lo uso para absolutamente nada a la hora de la verdad y en mi trabajo hemos sacado 40 proyectos adelante en 2 años y medio, así que no creo que sea muy necesario para todos los casos. Los proyectos de mi trabajo los catalogo de complejidad media, para que te hagas una idea.

Es muy bonito hacer un diseño y en la facultad te comen la cabeza con ello mucho tiempo pero a la hora de la verdad acabas hasta las pelotas. Tengo un compañero que entró con las mismas intenciones que tú y se dio cuenta de que los juegos son un software demasiado cambiante y diferente al que conocen nuestros profesores.

Ahora, autómatas, buena documentación, storyboards, prototipos y demás todos los que quieras. Pero más allá me parece perder el tiempo, al menos en solitario.

En cualquier caso veo que ya tienes montado el sistema de menús y tiene muy buena pinta. Enhorabuena y suerte

Hola The_Hans,

No te voy a quitar razón, en función de la complejidad el diseño acabará haciéndome perder el tiempo. Pero he considerado interesante la idea por tres motivos:

1. Cuando llego al momento de implementar, las ideas ya las tengo bastante claras. Sé donde quiero que esté todo y con una estructura más o menos clara.

2. Preveer que si por algún motivo tuviera que detener su avance (falta de tiempo o el motivo que sea), cuando lo retome me sea más fácil recordar su estructura y funcionamiento. Llevo hechos ya un par de proyectos (de todo tipo, no sólo juegos), y alguna vez que he querido reutilizar parte de otros programas he tenido que releer código para recordar la estructura. En mi opinión el diseño ayuda mucho en ese aspecto. Igualmente si consigo que alguien más se apunte al proyecto, creo que el diseño es una buena forma de entender como funciona el sistema (si lo hago claro ).

3. Lo iba a presentar como proyecto fin de carrera. Aunque al final me parece que haré algún jueguecillo mucho más simplón para móvil, porque llevar este proyecto a un PFC me va a encadenar a la universidad más de lo que podría aguantar.

Pero aun con todo eso, estoy contigo. En el primer diseño puse mucho esfuerzo por caer en todo, y en la implementación tuve que añadir alguna variable y método. Como dices, para una sola persona es muy difícil estar en todo .

Un saludo y muchas gracias por el consejo y la ventura ^^!.

A mi me parece bien que lo hagas, sera porque aun estoy con la carrera tambien y sigo pensando que es util, tambien es cierto que llevar esta documentacion cuando trabajas solo es una perdida de tiempo, pero si esperas meter a mas gente que programe puede venirle.

Yo quizas te aconsejaria meter identificadores, un generador de claves para saber sobre que sprites u objetos trabajas y tal seguramente te vendria bien y quizas, estaria bien que te miraras algunos patrones de diseño, veo metodos en las clases que heredan de pantalla que todas las tienen en comun, quizas podrias usar un abstract pattern, así todos los objetos pantalla tendrian los metodos comunes y serian un poco más genericos y faciles de usar los hijos. Mirate tambien algun composite, por si en una misma pantalla quieres tener varios objetos pantalla, aunque quizas esto te vendria bien para los sprites. Pero todo esto es ya opinion personal, tu ya veras que necesitas o como lo piensas hacer.

Luego, yo tambien usaria UML, pero unicamente si hubiese algun modulo que pasase mi diseño a codigo y me montase el esqueleto, porque sino crear el diseño serviria unicamente para las ideas. No se si tendras algun add-on o programa que te lo haga para XNA o C# si lo tienes estaria bien que lo compartieras XD.
Porque actualmente no se cuales hay que funcionen bien y gratuitos, nosotros usabamos UML-Omondo en su version para universidades de hace siglos para eclipse (JAVA), las versiones nuevas son más caras y la universidad no se lo puede permitir.

Hola Cloud_1986,

Me parecen muy acertados los patrones que mencionas, de hecho hago uso del abstract pattern (que no lo conocía como patrón, pero por lo que cuentas entiendo que es la idea de la herencia ¿no?). He sido un poco tramposo (y poco estricto, error mío) en el modelado UML y no he indicado que las clases Sprite y Pantalla son abstractas (por tanto los métodos que luego se ven en sus subclases en su mayoría son o bien el método heredado del padre, o bien su sobreescritura). Y como híbridos, además de obligar a implementar las funciones de actualización de la lógica y dibujo en pantalla, ofrecen unas versiones genéricas de estos métodos para ayudar al desarrollo de las clases que hereden de estas (por eso que estén "duplicados" los métodos Update(...) y Draw()).

Respecto al composite, para la parte que voy a comenzar ahora seguro que me interesa incluirlo, todo depende de como trabaje las transiciones entre pantallas. Podría servirme bien por ejemplo en el caso de que cuando tenga toda la ciudad en pantalla, no tener cargada a la vez la lógica que encierran los edificios por dentro, y una vez que se entre ellos, cargarlos sobre la misma pantalla.., muy interesante ^^ gracias!.

Sobre lo de los identificadores en los Sprites, también me parece una muy buena idea. hasta ahora los había estado identificando a través de posiciones (en los personajes, 0 era el jugador y del 1 en adelante manejados por la IA, etc) por optimizar rendimiento en cuanto a consumo de memoria. Pero no voy a tener tampoco una elevadísima carga de Sprites en pantalla y ese identificador me acabará ayudando más que un mapeo por número. Otra vez más muchas gracias ^^!.

Ya por último decirte que no uso ninguna herramienta que traduzca el UML a código. El primer prototipo fue un poco más aburrido crearlo por toda la cantidad de clases, métodos, etc.., pero en los siguientes prototipos al ser incrementales y con pequeñas modificaciones (prefiero hacer muchas versiones y ver resultados que aburrirme en una implementación) no tocaré tanto como para que me preocupes el pasar UML a código, asi que sorry, no tengo nada que compartir en este aspecto .

Un saludo!.

Por no crear un tema nuevo, os dejo aquí una preguntilla que me estaba planteando.

Estoy realizando ahora el diseño que necesitaré para manejar los mapas del juego y se me presentan dos opciones que a efectos de cómputo no sé por cual tirar:

1. Crear los mapas como una única textura. Es decir, tener en una única imagen el mapa completo y por otro lado(en un fichero por ejemplo) tener guardada la lógica de donde se encuentran los edificios y muros para manejar el sistema de colisiones.

2. Crear un tileset para los mapas. Es decir, tener en una imagen todo lo que puede aparecer en la ciudad (calles, edificios, muros, mobiliario...), y adicionalmente en un fichero describir el mapa (por ejemplo, poner un 1 donde haya un edificio) y que dinamicamente el juego cargue las porciones del tileset donde se encuentra el jugador.

Las ventajas e inconvenientes que le veo principalmente son:

1. Una única textura de mayor tamaño.
PROS: Se necesita menos cómputo para realizar desplazamientos por el mapa, ya que se tiene una única textura.
CONTRAS: Es poco dinámico. Cada vez que quiera hacer un nuevo mapa tendré que montarlo practicamente desde 0. Además durante la ejecución del juego, a no ser que meta algún cálculo adicional, estará cargado el mapa completo en memoria.

2. Varias texturas de menor tamaño.
PROS: Da más juego a la hora de crear mapas facilitando esta labor. Se ahorra memoria porque no está todo el mapa cargado en memoria.
CONTRAS: Al estar dividido el mapa en pequeñas secciones, cuando se produzcan desplazamientos por él (y esto va a ser constantemente), el juego tendrá que desplazar varias texturas en lugar de una sola.


¿Cómo lo veis?. Los mapas en principio no van a ser grandes en exceso, entonces no sé si debería optar por cargar una única textura de mayor tamaño en memoria, o tener varias texturas más pequeñas en memoria.. ¿Sabeis dónde se obtendría un mejor rendimiento?

Bueno, yo te puedo hablar de la segunda experiencia, pero usando SDL en lugar de DirectX (o sea que en principio, es totalmente aplicable, incluso con más razón).

Con un pc estilo pentium 3, no hay merma ninguna de rendimiento usando tilesets (y bueno, dado que es una técnica de poco menos que el cretácico, tampoco creo que tengas problemas en ordenadores más viejos ). El mapa está en memoria, sí, pero realmente, más allá de una matriz de enteros (te sirve tanto para colisiones como para pintar), o si me apuras, objetos, no vas a tener más. El tileset en sí ocupa muy poco (también depende el nivel de detalle que vayas a necesitar, claro, pero yo no me preocuparía), y pintarse solo se pinta lo que se ve en pantalla, que donde esta el cuello de botella es precisamente en la comunicación con la gráfica.

Yo creo que ya solo por la posibilidad de crear mapas rápidamente merece la pena.

¡Entonces de cabeza a la opción 2!.

Muchas gracias gothmog_es ^^.

Buenas de nuevo forer@s,

Esta vez vengo con otro tema interesante para el proyecto. Ya sabeis que buscaba colaboradores, pero no es necesario que machaqueis código, aporteis arte gráfico o compongais música, me valen todas las ideas que podais darme (y de hecho ahora mismo es lo que mejor me vendría).

Estoy terminando la versión que me ocupaba ahora (representar el mapa del juego, el sistema de colisiones y la cámara), y he empezado a plantearme la jugabilidad (que ofrecerá el juego para enganchar al jugador).

Sin duda este factor es el más determinante. Por eso os quiero preguntar, ¿qué considerais que debe tener un juego para que os enganche?.

Recordaros que el estilo de juego es rollo GTA (una ciudad con gente que se mueve de aquí para allá, edificios en los que entrar, vehículos en los que montarse, etc). De momento las ideas que se me ocurren incluir son:

- Habrá distintas facciones a las que unirse (bandas), las cuales te darán distintos tipos de misiones en las que conseguir experiencia, reputación y dinero.

- Se podrá tener hasta 3 habilidades especiales que se mejorarán con un sistema de experiencia. Cuando el jugador empieza a jugar, escogerá una habilidad especial de entre una lista que se le ofrecen. Además según la facción a la que se una, se obtendrá una nueva habilidad exclusiva de la facción, y también tendrá la posibilidad de conseguir una tercera habilidad (capturándola o aprendiéndola).

- Como resultado de la reputación uno tendrá mejores relaciones con una facción que con otras. Esto conllevará que las facciones amigas presten servicios (armas, personajes que ayuden al jugador, vehículos, edificios) al jugador, y que las enemigas al encontrarte te ataquen o incluso te busquen por la ciudad para acabar contigo.

- Con el dinero se podrá comprar armas, edificios, vehículos y contratar personajes que te ayuden a realizar las misiones o tus objetivos personales.

- El juego permitirá dos tipos de partida multijugador. Por un lado, un enfrentamiento entre los personajes de los jugadores (un versus por grupos o individual, depende de los jugadores que participen en la partida); y por otro, jugar en una ciudad al estilo de juego individual pero sabiendo que algunos ciudadanos son otros jugadores por ahí moviéndose, permitiendo la cooperación para misiones (si son de la misma facción o facciones alidadas), o el enfrentamiento de las bandas de los personajes (en caso de que las facciones sean enemigas).

Os animo a que opineis de las ideas que tengo pensadas y propongais ampliaciones, mejoras o nuevas ideas si se os ocurren .

Un saludo!.

Yo este tipo de juegos los resumiría en una palabra: libertad.

Es muy fácil decirlo, pero difícil llevarlo a cabo, claro, porque como desarrollador vas a tener que pensar todas las vías de acción. Pero la libertad es lo que hace realmente rico a un videojuego. Que lo puedas jugar 30 veces desde cero y todas sean diferentes a la par que divertidas, que si tienes un enemigo final, lo puedas matar de varias formas, no acudiendo a una determinada arma o combo. Que puedas usar fuerza bruta, o también astucia para cumplir una misión. Etc.

Por lo menos yo es lo que más valoro, y en mi opinión es donde está el futuro.

Estoy de acuerdo contigo gothmog_es, desde luego para el juego la libertad se tiene que convertir en una premisa básica (de hecho se lo comentaba hoy a mi tutor, al final voy a hacer una parte del juego como proyecto fin de carrera, concretamente el multijugador).

Mi intención es que por la ciudad te puedas mover con la máxima libertad posible (edificios a los que entrar, puertas que traspasar.., tengo pensado incluso que se puedan romper paredes de edificios y entrar por las aberturas que crees.., a este paso no termino el juego jamás xD).

Sobre las misiones, tengo intención de meter varios tipos de misión. Por un lado misiones en función de la facción a la que te unas (modo historia), y por otro lado unas que sean más o menos genéricas (en plan proteger a no se quién, robar en no se donde, eliminar a X), y algo curioso que pretendo intentar introducir es que el propio ordenador realice misiones, y asi poder encontrarte a jugadores de la máquina intentando proteger o eliminar a alguien..., incluso eliminar o robar al propio jugador podria ser una misión a realizar por la máquina. Hay que ver hasta donde consigo llegar con esta idea.

Y lo que ahora me planteo es como encajar el multijugador con este estilo de juego. Las ideas que proponía no terminan de parecerme una solución que haga que quien la juega quiera repetir la experiencia..., pero bueno, tengo tiempo para plantear una fórmula mas llamativa.

Ya por último sobre lo que comentas de dar la posibilidad de varias formas de juego, es algo que pretendo presentar a través de las habilidades. Las habrá más directas (en plan superfuerza, lanzar rayos, tal vez se me ocurra algo más xD) y que de algún modo sean más indirectas (controlar a enemigos, crear zonas en las que el tiempo vaya más despacio, mover objetos sin tocarlos). No sé, tengo muchas ideas rondándome y habrá que ver que tal las traslado al juego.

Otra cosa, aunque de momento nadie se ha animado a unirse al proyecto, os informo que de aquí hasta que termine la parte del proyecto fin de carrera no os podreis unir. Esta parte prefiero trabajarla solo..., de todos modos iré avisando por aquí de lo nuevo que vaya haciendo, para que cuando vuelva a liberar el proyecto si a alguno ya le ha interesado se apunte .

Un saludo!

Una pregunta, el menú como lo hiciste? Hay algun tutorial?