Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Consejos para el desarrollador amateur y principiante

Iniciado por [EX3], 02 de Febrero de 2007, 01:45:10 PM

« anterior - próximo »

[EX3]

Wenas.

Estaba yo dandole vueltas ultimamente a ciertos temas personales asi como debatiendome cuestiones propias acerca de que puedo estar haciendo mal y que deberia haber hecho en su dia en cuanto al desarrollo de mi proyecto, que ya se demora 6 años (demasiado tiempo para lo poco avanzado que va y para lo que pretende ser) y se me vino la idea de crear un tema o una seccion del foro, a falta de blog propio que sea medianamente visitado o a la vista de la gente, dedicada a dar consejos en base a la experiencia de cada uno, sobre todo de los que llevamos ya un tiempo en esto aunque sea intentadolo como es mi caso o en el caso de otros que ya llevan años en esto, asi como debatir acerca de los consejos expuestos por los demas. La idea seria entre todos aportar nuestro granito de arena para los que empiezan en esto, y por que no, para los que llevamos algo de tiempo, y asi intentar que no tropiecen sobre nuestros errores mas comunes. Me gustaria tambien que si lo veis oportuno y util hablarlo para proponerle a Sync ponerle chincheta al tema en caso de merecer la pena.

En mi caso los consejos que yo daria en base a mi experiencia a la hora de plantearse llevar a cabo un proyecto o una idea serian:

    1. ¿Quieres desarrollar juegos o motores?:
            Si tienes claro que es un juego lo que quieres hacer no dediques tiempo y esfuerzo en trabajar la tecnologia para llevarlo a cabo (motores, librerias, etc...) si no busca y elije entre el inmenso catalogo de herramientas existentes que hay por internet que de seguro cumpliran las espectativas de lo que buscas o necesitas e inclusive mas aun en vez de intentar reinventar la rueda uno mismo.

    Y ahora alguno se preguntara, "¿lo dice uno que se ha tirado 4 o 5 años programandose su propia libreria?". Mi caso en concreto, en su dia hara ya 6 o 7 años casi, como programador de Visual Basic 6.0 no tenia muchos recursos a mano para poder desarrollar mi idea y no me quedo mas remedio que estudiar y aprender a hacerme mi propia herramienta a medida no si antes pasar por la experiencia de aprender y desarrollar pequeñas ideas en el legendario "Div Game Studio 2" ya obsoleto. A dia de hoy, tanto en Visual Basic 6.0 como en C++, sobre todo en este ultimo, existen un numero considerable de opciones para desarrollar juegos tales como librerias y motores tales como FMod, Bass Sound System, Gally, Crm32Pro, LooverLib, JadeEngine#, LTML, TrueVision3D, Ogre, Torque Engine, XNA Game Studio Express...  asi como nuevos lenguajes especializdos en este concepto de desarrollo: Fenix (evolucion del lenguaje Div), DarkBasicPro, Blitz3D, BlitzMax, 3DGameStudio... e incluso herramientas especializadas en ciertas materias como la fisica de objetos con Newton Game Dinamics o Tokamak Game Physics SDK por ejemplo o tareas comunes como por ejemplo LemonGT, y herramientas de creacion de contenidos como Mappy para creacion de mapas de tiles o Bitmap Font Creator para crear fuentes de texto con efectos para tus juegos. Hoy dia es dificil no encontrar una herramienta para algo concreto que se necesite.

    Sinceramente, yo en mi lugar y a dia de hoy lo tengo muy claro, si tuvisese que volver a empezar de 0 eligiria un lenguaje como Fenix o Blitz, o bien un motor, framework o SDK para desarrollar en el lenguaje como Visual Basic, C++, Java o C#.

    2. Organizacion de los recursos del juego:
            ¿Me hago un formato propio para almacenar las animaciones con toda su informacion o las organizo sueltas en directorios y utilizo un simple archivo XML para configurar las animaciones? Muchas veces se pierde el tiempo sin darse cuenta en detalles innecesarios en muchos casos como es del diseñar formatos propios para organizar la informacion y recursos de un juego, tales como archivos contenedores de texturas, archivos de secuencias de animacion, archivo de niveles, etc... Si el juego que vas a diseñar no es muy complejo, a veces merece mas la pena preparar dicha informacion de animaciones y demas datos en el propio codigo del programa que andar fabricandote formatos de archivos propios y complejos sistemas de paquetes de recursos dado que se acaba invirtiendo mas tiempo en desarrollar este tipo de tareas que en hacer el juego. Muchas veces basta con un archivo INI, XML o inclusive de texto plano para organizar los datos de secuencias de animacion o textos del juego.

    Si el caso es el de un desarrollo algo mas complejo y grande, donde la cantidad de informacion a mover es considerable, ahi si suele ser interesante dedicar un tiempo al diseño y organizacion de la informacion y como sera tratada. La ventaja a dia de hoy es que muchas de las herramientas a utilizar para el desarrollo de nuestros juegos ya incorporan tanto utilidades como formatos propios para organizar los recursos, tales como por ejemplo el formato FPG de Fenix que es un archivo contenedor de texturas que gestiona el propio lenguaje de forma transparente al programado, o los formatos resultantes de herramientas como Mappy y Bitmap Font Creator, formatos abiertos faciles de adaptar a nuestros requisitos sin mucho esfuerzo o que librerias de terceros ya implementan directamente en sus funciones ahorrando mas trabajo si cabe.

    Luego cabe incluso la posibilidad de tener mas organizado aun si cabe nuestros recursos, y tambien protegidos en ciertos casos, archivandolos en paquetes con o sin compresion, al igual que formatos como ZIP o RAR. Muchos juegos utilizan este sistema, Half-Life con su formato abierto PAK por ejemplo, y que TrueVision3D entre otros soportan en sus funciones. Algunas plataformas como Blitz3D disponen de herramientas de terceros para empaquetar los recursos de los juegos u otras incorporan su sistema propio como en el caso de LemonGT. Tambien hay disponibles librerias para trabajar con formatos tradicionales como ZIP o RAR tales como UnRARlib o MiniZIP.

    3. No te emociones y conoce tus limitaciones y posibilidades:
            Un error muy comun de la gente cuando se embarca por primera vez en un proyecto de un juego, y que seguro hemos pecado todos, es la de dejarse llevar por el flujo continuo de ideas y sueños tirando la piedra muy lejos donde luego no son capaces de llegar. Esto quiere decir que mucha gente sin los conocimientos necesarios y sin experiencia en este tipo de desarrollos se intentan embarcar precipitadamente en proyectos tales como MMORPG's (Multiplayer Masively Online Role Playing Game) tipo "World of Warcraft" en otras *inspiraciones* del mercado, o FPS's (First Person Shooter) del calibre de las sagas "Batlefield", "Quake" o "Half-Life" entre otros muchos del genero o incluso juegos mas modestos pero no por ello bocado para un novato. Reconozcamos que a todos nos encantaria llevar a la realidad grandes ideas de juegos que tenemos revoloteando por nuestra cabeza, a veces ideas muy prometedoras, no lo niego, pero que a la hora de llevarlo a la realidad sugen los problemas, en algunos casos, dificiles de atajar: como programar la IA y comportamiento de enemigos y personajes, programar el sistema de batalla, buscar gente que se encargue de realizar el trabajo de diseño y contenido del juego (texturas, modelos, animaciones, musica, efectos de sonido, diseño de niveles, etc...), como programar un sistema eficiente de red asi como buscar servidores para correr nuestro juego si fuese online, y lo mas importante, sacar tiempo para ello. Un juego medianamente grande te puede llevar perfectamente un año de desarrollo contando con que seais 3 o mas en el grupo y cada uno centrado a una materia concreta: programar, diseñar, modelar o componer. Pretender uno solo abarcar todo esto no es imposible pero si inviable dado el esfuerzo y tiempo a invertir asi como el lento avance del proyecto que en la inmensa mayoria de los casos acaba por desanimar a uno mismo y por abandonarlo.

    Para evitar esto lo mejor es tomarse tiempo en hacer una completa planificacion del proyecto, aclarando las ideas, estudiando las posibilidades asi como los puntos que nos sean verdaderamente posibles atacar y cuales no descartando estos ultimos, todo ello para ir acortando y simplicando el proceso final de lo que sera el desarrollo del juego. En resumidas palabras: tener claro que quiere hacer, que se puede hacer y con que herramientas contamos. Una buena practica de ello, y recomendable aunque luego al final no todos hacemos, es hacerse un documento de diseño.[/list]
    Con esto acabo lo que seria mi pequeña aportacion a lo que espero sirva de guia a muchos de los que empiezan en esto.

    Salu2...
    José Miguel Sánchez Fernández
    .NET Developer | Game Programmer | Unity Developer

    Blog | Game Portfolio | LinkedIn | Twitter | Itch.io | Gamejolt







    Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
    Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
    Muchísimas gracias.