Uruguay Gamer » Elaboración » ¿ Cómo programar un juego con POO? (de principio a fin)
¿ Cómo programar un juego con POO? (de principio a fin)
-
Hola a todos, primero les voy a contar de que va este post.
El objetivo es avanzar entre las etapas de Relevamiento, Analisis, Diseño, Implementación que propone el paradigma de POO, mientras trabajo con la sintaxis de UML.
Una ves que este completo, con las correcciones de los compañeros del foro, que activamente participaran en este post, voy a hacer un tutorial en pdf que recopile la creación del juego de principio a fin.
No hago el pdf directamente ya que soy un NOVATO en cuanto abordar un videojuego con POO totalmente, y me van a surgir muchas preguntas o correcciones a las distintas etapas, que se deducen de los aportes de todos.
Entonces arrancamos y vamo arriba con esto!
-
RELEVAMIENTO
Nombre del juego: Matones V0.1
Descripción( en un lenguaje mas o menos superior):Juego multiplayer ( hasta 2 jugadores) que utiliza como periferico el teclado solamente.
Cada jugador controla 1 personaje de entre 4 disponibles, los cuales difieren solamente en sus atributos de STR, AGI, DEF y HP.Los enemigos( controlador mediante IA del ordenador) pueden ser de 3 estilos distintos:
- Rápido
- Lento
- Balanceado
El juego se desarrolla en un escenario 2D con vista lateral.
Cada escena esta compuesta de un fondo fijo o background.
Existen 2 modos de juego diferentes:
1-Normal: Pasas de escena sii destruyes una cantidad N de enemigos establecidos al inicio de la escena
2-TimeAttack: Pasas de escena si sobrevives una cantidad S de segundos establecidos al inicio de la escena.La cantidad de escenas totales es 10, cada una con su fondo y música únicas.
En la parte superior de cada escena podemos apreciar los HP de cada jugador, y sobre la cabeza de cada enemigo golpeado se muestran sus HP restantes.
Los enemigos y jugadores no pueden golpearse entre sí!
El menú principal permite elegir las opciones Normal, TimeAttack y Salir, además de desplegar un fondo con el nombre del juego.
---------------------------------------
La ventaja que nos presenta esta etapa inicial, es que al ser nosotros mismos los clientes ( lo que sucede usualmente como Indies), podremos profundizar en el relevamiento con un lenguaje mas o menos técnico que el Cliente usualmente no tiene, y claro, nos complica la vida un poco!
Seguiremos con los casos de uso.
-
CASOS DE USO
Nota previa: ya de manera muy temprana, me siento como un jugador de futboll cuando le gritan: " Qué pasa papa, te cortaron las piernas?", porque bueno, me sucede eso mismo.
Voy a postear un par de casos de uso hoy, y dejar algunas dudas pendientes esperando la respuesta de algún compañero mas experto en este tema.
Nombre: Seleccionar Modo de Juego
Participantes: Usuario
Sinapsis: El usuario ejecuta la aplicación, elige de entre 3 modos de juego distintos y según el modo elegido se realiza alguna de las siguientes acciones:- Redirreciona la pantalla a la de selección del personaje del jugador
- Idem a (1)
- Se cierra la aplicación
Nombre: Seleccionar personaje del jugador
Participantes: Usuario
Sinapsis: Inicialmente se ejecuta una transición, luego el Usuario selecciona a su jugador de entre 4 disponibles e inicia el juego.Nombre: Iniciar Juego
Participantes: Usuario
Sinapsis:Aca se me genero un lio, paso a explicar el porque:
En la facultad aprendimos que a partir de los casos de uso salen los Diagramas de Secuencia del Sistema (DSS).El asunto es que según como voy a plantear este caso de Uso, va a suceder que el usuario no tendra ninguna operación o tal vez 1 sola en el DSS que se genere, porque todo lo demás va a ser controlado internamente por el sistema.
Paso a plantear la Sinapsis:
El sistema consulta ( ¿ a quién? a si mismo? creo que esta llanamente mal :D ) cuál de los 2 modos de juego fue seleccionado, y establece los parámetros de escena y condiciones o metas para pasar a la escena siguiente, donde algunos de estos parámetros incluyen la linea de tiempo de creación de items, enemigos, y diversas " cosas", como ser N o S (revisar en RELEVAMIENTO), finalmente se pasa a
"Jugar Normal" o "Jugar TimeAttack".Entonces ¿Qué es lo que esta fallando? Si no hago esta descripción en los casos de Uso, donde la voy a hacer? creo que es algo muy complejo como para " colarlo en el código" mas adelante.
Mi cuartada es que le pifie a los participantes, y no debería pensarlo como usuario sino como otras clases, al igual que Sistema. Quería que sistema fuera una especie de Façade pero a lo mejor da mas molestias que ayudas.
Casos de Uso pendientes: "Jugar Normal", "Jugar TimeAttack","Terminar Aplicación".
-
Hola. Todo bien?
Primero que todo bienvenido al foro, espero que te ayude, como a mi, a poder desarrollar videojuegos!!!Bueno, he leído como 3 veces y no entendí muy bien de que se trata el juego, como matás a los enemigos, cuales son los objetivos, etc... Talvez no entendí a que ibas con el documento...
Si es que nunca hiciste ni siquiera un prototipo impresentable (pero jugable) de un videojuego... Te recomiendo que experimentes con librerías gráficas. Después de eso, hace una aplicación gráfica con un cacho de interactividad (ej. un macaco que lo podés mover con las teclas)...
Después podrías hacer un remake de un juego muy sencillo así vas agarrando la mecánica básica de los videojuegos.Leí que programás en python... Porque no intentás hacer un Pong???
Para esto podrías usar Python con la librería Pygame, que parece limitada, pero no lo es.UML para videojuegos???????? No es demasiado complejo este "lenguaje de modelado" para hacer cosas ya muy complejas como un videojuego???
-
M.DiAngelo esta bien que intentes aplicar practicas de ing de software, pero hace la documentacion que te sirva. Tene en cuenta que los casos de uso son un modo de especificacion de los requerimientos y para juegos no se si es la mejor forma. Capas que tiene mas sentido decir es como este juego con estas modificaciones .
Si vas a trabajar solo, como documentación usaria UML para bajar las ideas a tierra antes de llevarlas a código.
Igual como dice zatarathustra, empeza con un pong o arkanoid, para eso no precisas doc.
-
Voy contestando por partes:
Zatarathustra, gracias por la bienvenida, estoy seguro que me va a ayudar mucho, ya lo estan haciendo ( por ahora tu y juako).
Es verdad, hice un relevamiento muy pobre ( soy mal cliente hasta para mi mismo), en breve incluyo los detalles para que se comprenda mejor de que va el juego.
Dije lo que quería hacer pero no para que lo quería.
Todo esto apunta a aprender y enfrentar problemas. Tengo algunos prototipos echos pero canto la justa, cuando quise hacer un RPG con muchas caracteristicas como mezcla con beat em up, puzles y demás, me volvi loco y nunca lo termine.Ahora con POO encuentro una metodología super organizada ( no por eso compleja para muchas tareas) que me sirve para avanzar descomponiendo los problemas complejos en tareas mas simples ( algo asi como D&C).
El juego después va a ser implementado en c++ o en python, pero me decanto por c++ ya que quiero prácticar un par de cositas.
En cuanto a gráficos conozco SDL y OPENGL, así que tu consejo de tocar pygame ( que creo esta basado en SDl) es muy bueno.
Juako:
Tengo todo en papel pero a medida que me rinde el tiempo lo voy pasando a la PC. En breve subo el Modelo de Dominio, correcciones a casos de uso y algunos diagramas de Secuencia de Sistema.
Seguramente algunos foreros tengan dudas sobre los conceptos teoricos así que de pasada tiro unos resúmenes de que es cada cosa y material para expandirse la mente.Toda la documentación es para ir bien ordenadito, ya de los casos de uso y los DSS quiero pasar a los Diagramas de Comunicación de Cada Operación y al final la primera iteración subir todo el código implementado.
También otra cosa que tengo ganas de hacer es probar los patrones de diseño, ¿ y qué mejor oportunidad que un juego?
Algún Patron Observer para un juego de estrategía, un Singleton para los controladores del juego, un State para gestionar al Player y si se puede un ChainOfResponsability :D.
Si...es una locura, que de paso me aporta experiencia.
PD: Entre la noche de hoy y mañana subo diagramas,casos de uso y explicaciones de que es (y porque es) cada cosa.
-
Pah, veo algunas diferencias de conocimiento entre lo que escribiste y lo que se, por lo que prefiero aclarar...
UML hasta donde sabía no era orientado a objetos... Solamente contiene elementos de la orientación a objetos.
Lo que vi de UML es un diagrama entidad-relación extendido.
Aparte la orientación a objetos es de metodología Bottom-up.... Por algo es tan poderoso! Uno crea los objetos independientes y después los vas utilizando en niveles más altos... Lo que genera esto es que cuando querés modificar el objeto, no tenés que modificar el resto del código.
Si uno diseña orientado a objetos Top-Down lo que genera es que todos los objetos sean dependientes... Esta no es la idea de este paradigma.Aparte, repito, te vas a volver loco si querés aplicar ingeniería de software cuando todavía no haz desarrollado suficientes videojuegos!!!
Yo lo intenté (no estudié ingeniería... pero igual tenía los conceptos)... Y me volví loco!!!
Y más loco te vas a quedar si empiezas con algo tan complicado!!!P.D.: Si ves que realmente tenés todo muy claro y podés hacer las cosas así... Pues, me taparás la boca!!!
Saludos!
-
No dije que UML fuera orientado a objetos, ni afirmo que este bien o mal, solamente que voy a trabajar con su sintaxis ( como apoyo en los diagramas para seguir un standart).
En cuanto a la metodología Bottom-up, opino que esta muy bien lo que planteas de crear objetos independientes, y en eso esta la potencia del paradigma.
Conosco dos maneras de favorecer ese " aislamiento" entre objetos( debe haber muchas más):1- La bruta: era la que usaba antes de enterarme que Orientación a Objetos no es solo programación, y en esta trataba de no enfiestarme con los punteros de un objetoA hacia los otros 300 objetos y viceversa y además tener miles de relaciones cruzadas.
2- La no tan bruta: En la etapa de diseño asignar responsabilidades a ciertos objetos (que en parte son los conceptos de la etapa de analisis) para aumentar la cohesión (No cargues de responsabilidades una clase!) y reducir el acoplamiento (No relaciones a una clase con tantas). Existen otros criterios, se llaman GRASP.
Otra manera de lograr independencía, es mediante interfacez que hagan de mediadoras entre clases, algo asi como adaptadores. Entonces el día de mañana si queres "arrancar" esa clase de tu sistema, y Dios programador te lo permite, para usarla en otra aplicación, a lo sumo modificarias la interfaz pero internamente dejas a la clase igual.Aparte, repito, te vas a volver loco si querés aplicar ingeniería de software cuando todavía no haz desarrollado suficientes videojuegos!!!
Yo lo intenté (no estudié ingeniería... pero igual tenía los conceptos)... Y me volví loco!!!Ya somos dos, también enloquecí :D ( y eso que recién arranque con esto hace 2 dias).
-
Hola!
Bueno, te cuento que justo ando en la misma :P
También estoy cursando programación 4 en la fing (leí en tu presentación) y estoy intentando usar UML para el diseño del juego que estoy haciendo.También por momentos me pregunté si encajaría bien las cosas que nos enseñaron de UML en el diseño de un videojuego, ya que hay cosas bastantes diferentes. Pero bueno, voy probando y por ahora me sirve, al menos para bajar las ideas a tierra.
Al igual que vos voy por la parte de análisis, ya hice el modelo de dominio y algunos casos de uso (bastante parecidos a los que posteaste vos).
Y cuando arranqué con los DSS me surgió la misma duda que a vos, y mirando por internet vi que no necesariamente debe haber sólo dos "entidades" interactuando (en este caso el jugador y el sistema), sino que pueden haber más. Te dejo esta imagen que encontré que está buena, es medio parecido a un diagrama de comunicación, no se si es del todo un DSS, pero ta, capaz que en nuestro caso nos conviene hacer algo como esto.
Saludos!
-
INFORMACIÓN PSEUDO-TEÓRICA Y AVANCES
En esta entrega voy a explicar en que consiste la estapa de Analisis e introducir algunos conceptos teóricos relevantes
También presentar el Modelo de Dominio del juego ( que aun no tiene titulo!).
Comenzamos
Hace mucho tiempo, en una tierra muy lejana...vivian programadores, diseñadores, y otros seres misticos de la mitología.
Esos seres trabajaban a modo de cascada, o sea:
1- Un cliente le decía lo que quería
2- Analizaban la situación
3- Diseñaban una posible solución
4- La implementaban, y si funcionaba la liberaban.Esta forma de trabajo, se basaba en profundizar lo mas que se pueda en cada uno de los 4 puntos, y hasta no terminar seguir estancados, y se llamaba "Cascada".
Sin embargo, un buen día, surgió la luz, y se dijo:
"Y si mejor vamos de a poco y volvemos atras?"
"Si, sería como iterar sobre el problema de resolverlo todo"Y esto señores se denomino el modelo I&I, cuyas siglas significan Iterativo-Incremental.
En lugar de profundizar fuertemente en cada etapa, es cuestión de avanzar y volver a dar otra pasada a los 4 subproblemas de forma que en cada iteración se logre algún cambio medianamente importante o funcionalidad en el sistema (la aplicación que estamos desarrollando, en este caso un juego de video).Mas info en : Modelo I&I
Descripción de cada etapa (informal):
- Analisis: Consiste en identificar los conceptos principales del modelo y establecer las relaciones entre estos.
¿Qué es un concepto?: Es una representación de un objeto del dominio o alcance del problema que usualmente se corresponde de manera biyectiva con este.Notar que si modelaramos una aplicación llamada "Mundo", tendriamos conceptos como Persona o Casa, que tienen su contrapartida en el mundo como objetos fisicos y tangibles, pero también se podrian agregar conceptos como JuegoDeFutbol( no dije cancha!) que no se corresponden mas que con la idea de personas participando del mismo.
¿Qué es una relación? Es algún tipo de interacción entre dos conceptos.
Algunas relaciones famosas son:1."Es hijo/padre de.."(Herencía)
2."Esta asociado a.. " (Asociación)
3."Es o puede ser parte de.." (Agregación)
4."Esta compuesto de.."(Composición)Ejemplos de estas relaciones se pueden ver en el siguiente diagrama:
1. La relación entre Menu y Background esta representada por una asociación. Eso significa que Background podría ser un pseudo-atributo de Menu y/o Menu pseudo-atributo de background.
Un pseudo-atributo es en terminos de implementación una referencía a otro objeto que no sea un DataType.
DataType: Objetos sin identidad, solo importa su valor, que se conoce como DataValue :D.
Ejemplos de DataType: int, bool, char, String y algunas clases marcadas con la etiqueta <<DataType>> en su parte superior.
2. La relación entre Actor y Enemy es una Generalización representada por una flecha. Normalmente se conoce como Herencía y se dice que Actor es padre de Enemy, donde Enemy además de sus propios atributos y operaciones, contiene los atributos y operaciones heredados de Actor ( OJO: Operación <> Método)
3. La relación entre Scene y Actor es una Agregación representada por una linea con un Rombo vació.
Sin entrar en detalles, las Agregaciones y Composiciones son formas fuertes de la Asociación.
Una agregación indica " A es o puede ser parte de B", donde
A = Actor
B = Scene4. La relación entre Game y Partida esta representada por una linea con un Rombo relleno
Esto significa que Game esta compuesto de Partidas, y si se destruye Game también deberían de destruirse estas partidas. - Diseño: (pendiente para próximos post)
- Implementación:( pendiente para próximos post)
El diagrama mostrado anteriormente, lo creé para esta ocasión y su nombre generico es Modelo de Dominio.
Teoricamente, un Modelo de Dominio tiene conceptos y relaciones significativas en el dominio del problema, y no esta enfocado en entidades de software, por eso no aparecen TAD´s como listas o diccionarios en esta etapa.
El MD esta compuesto de Conceptos (cajitas), Relaciones y DataTypes. Cada concepto tiene sus atributos debajo del nombre.
Lista de conceptos de este MD:
- Game: Esta compuesto de varias partidas
- Partida: Contiene información como el modo de juego actual (Normal o TimeAttack) y el estado de la partida (Iniciando, SeleccionandoPlayer, Jugando, Saliendo).
- Menu: se describe sola
- Background: en cierta forma representara el fondo de una escena ( que es único como dice el relevamiento) o también un decorado del Menú
- Scene: Tiene su fondo, algunos atributos y pseudo-atributos que se revelaran mas adelante los actores pueden ser parte de esta. Además cada Partida tiene como máximo 10 Scene relacionadas a si mismo, ya que el juego (una partida) se compone de 10 niveles (Scene)
- Actor: Agrupa objetos actualizables y sera re-analizado a posteriorí
- Object: representa objetos que el "jugador" puede recoger y útilizar por medio de su UC
- Enemy: los enemigos del Jugador o Player
- UC(Unidad Controlable): la representación conceptual del Player sin tener asociada aún una imagén, ya que en otros tiempos sería por ej un juego de texto nada mas.
- AP(Actor de Plantilla): Lo explicare mas adelante cuando presente los "Casos de Uso"
- AtributosRPG: Agrupa la descripcion de atributos que tiene tanto un jugador como un enemigo
- DAtributosRPG: Expande a su clase padre y le agrega imagenes y posición.
Por hoy es todo, tengo sueño :D.Buenas noches y que les sea útil!
- Analisis: Consiste en identificar los conceptos principales del modelo y establecer las relaciones entre estos.
-
En un videjuego típico, creo que la división de tareas de programación debe ser por funcionalidad, no por caso de uso.
Pongo como ejemplo el ReVerSerers:
o- Tablero cliqueable.
o- Generador de tableros aleatorio
o- Resolvedor de partidaso- Reloj de cuenta regresiva
o- 3, 2, 1, RVS
o- Formatos de tableroso- Ronda de Duelo
o- Duelo completo
o- Configuraciones de Dueloo- Ronda de Treversería
o- Treversería completa
o- Configuraciones de Treverseríao- Ronda de Escuela
o- Escuela completa
o- Configuraciones de Escuelao- Botones de menú
o- Fondo de menús
o- Logos
o- Presentación (acercamiento de logos)No todos los puntos son casos de uso (como el fondo de menús), y algunos puntos abarcan un ciclo de vida entero (Duelo completo).
-
Hola nuevamente.
Kam: aunque la imagen quedo un poco "pequeña", me pregunto si eso es un Diagrama de Secuencia, porque tal vez entro a razonar y no se necesitan DSS sino DS.NaBUru38: exelente, creo que voy a descartar los casos de uso que tengo hasta el momento e inclinarme por la revisión de tareas en funcionalidades.
Una duda que me surge es:
¿Ronda de Duelo y Ronda de Escuela se refieren a una partida en proceso?
y además
¿Cómo reducis el acoplamiento entre las funcionalidades, para que luego puedas testear cada parte fácilmente?Muchas gracias!
-
M.DiAngelo, lamento contarte que mis juegos los desarrollé a los tropezones, sin planificación estructurada. Tampoco testeé formalmente ni realicé modularización como se debe. Simplemente programé mis ideas de la manera más fácil.
Por eso es genial que vos intentes lo contrario. Yo estudié todo eso y lo apliqué a proyectos de gran porte de facultad, pero nunca en un juego.
Con "ronda de Duelo" y "ronda de Treversería" me refiero a este ciclo del juego:
o- El jugador cliquea en "iniciar"
o- Ocurre la cuenta regresiva.
o- Se muestra el tablero a resolver.
o- El jugador lo resuelve o falla.
o- (Los pasos se repiten para cada jugador del Duelo.)
o- Se muestran los resultados.Es más grande que simplemente crear el tablero, cliquear y ganar, pero más simple que completar un Duelo o Treversería. Es hacer el proyecto en ciclos incrementales, sólo que "cortados" de otra manera.
Reply
You must log in to post.