Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Proyecto Ruina

Iniciado por LuisV, 19 de Febrero de 2010, 08:46:12 PM

« anterior - próximo »

LuisV

Hola a todos. Soy nuevo en este foro, mi nombre es Luis y me voy a embarcar en un proyecto nuevo para mi.

Estoy en la universidad y mi proyecto para una asignatura (Ingeniería del Software  :'( ) consiste en un videojuego utilizando la plataforma J2ME, o sea, un juego de móvil.

La verdad es que la asignatura está pensada para el desarrollo de software comercial prácticamente, y se les ha olvidad un poco el tema de videojuegos. Además, en mi universidad no existe ninguna asignatura en la que ofrezcan la posibilidad de iniciarse en este mundo de los videojuegos.

Por eso escribo en este foro, para solicitar consejos de cómo afrontar el proyecto.

Tengo las especificaciones del videojuego, la trama del videojuego con sus posibles escenarios, las características de los personajes, el audio que encaja en el videojuego y demás temas relacionados.

Sin embargo, no sé como debo afrontar el reto, de cómo hacer el análisis de requisistos del videojuego (diagramas de flujo de datos, diccionario de datos, diagramas de transición de estados, diagrama de flujo de sistemas...), de cómo diseñar el videojuego ( estructura de datos, representación del interfaz, etc).

A parte, no encuentro un buen manual o libro en el que se especifique el proceso de creación de un videojuego para móvil, únicamente manuales de J2ME, pero eso en realidad me da igual, ya que la tecnología Java la conozco.

Por eso me gustaría recibir vuestros consejos para poder enfrentarme al proyecto y crear algo medianamente decente. Conociendo los pasos que debo seguir, podré sacar adelante el proyecto y no tener que repetir asignatura, que el quela haya cursado y sufrido... creo que sabe de qué va la cosa :D  :-[

Muchas gracias a todos y espero vuestros consejos.  ::)

flipper83

Mi primer consejo no se si le gustará mucho a tu profe pero creo q es lo q hay q hacer en verdad. cojete una hoja y pon el tiempo que tienes para hacer el proyecto, y saca todas las funcionalidades q tiene tu juego (pintar el fondo, el movimiento, el ataque, los enemigos) y repartelo de más importante a menos importante a lo largo del tiempo. Luego indica que es lo esencial para tener el juego terminado, suele el ser el 70% del proyecto; lo demás es lo q se llama valor añadido de un proyecto. Y empieza por el principio.

Por experiencia no te recomiendo que intentes diseñar todo el modelo de datos y de flujo de tu aplicación, ya que 1) es una estupiez y 2) es imposible porq seguro q se te va a olvidar agregar un montón de cosas. Mi recomendación es q cuando te sientes con uno de esos bloques de funcionalidades que pienses antes como lo vas a hacer y ese caso si q pudes pensar los diagramas de flujo, de datos, de estados, bla bla bla.

Otro punto importante es hacer maquetas en papel para aquellas pantallas q vayas a hacer para ver que no se te olvida nada, dibujar una fase donde se vea a tu muñeco, tus indicadores de vida, de puntos o lo que sea, para poder estimar siempre mejor.

Un punto imporatante "estimar" no es una ciencia extacta, se basa en la experiencia por lo cual es muy facil equicarse, si tu profesor no entiende eso es quiere q seas consultor xD.

Alguna de las cosas que te he dicho están basadas en metodologias ágiles, asi q no se si querrán q lo hagas asi

A partir de ahi te deseo suerte y al final todo se resume en ir paso a paso empezando por lo más esencial a lo más concreto.
un cobarde forero en el tanatorio al mes sería un placentero trofeo digno de merecer

Hans

#2
El problema de la universidad es que te enseñan la teoría pero de la ahí a la práctica hay miles y miles y miles y miles y miles de horas de diferencia y es cuando te das cuenta de que la mayor parte de la carrera se la podrían haber ahorrado y que seguir un libro sirve para poquito en general. También observas cómo la mayor parte del profesorado no tiene ni zorra idea real de lo que está explicando porque lleva toda la santa vida dando clases teóricas y cero práctica, además de tener modelos bastante desfasados en general.

De mi vida universitaria sólo salvo a un par de profesores, más o menos. Los demás o eran casi de mi edad (con lo cual práctica sabías que tenían ninguna, aprox xD), o eran tan viejos que los videojuegos ni existían cuando estudiaron, o bien eran tan inútiles como un clásico pase de dispositivas.

Yo te aconsejo que empieces a hacer el juego y cuando tengas un esqueleto más o menos coherente entonces hagas todo lo que quiere tu profesor que hagas antes. Si tuvieras experiencia quizás pudieras hacerlo al revés pero en tu caso vas a pasarte el 99% del tiempo reescribiendo todo sin haber programado nada si sigues el método informático.


edit.- Curiosidad, ¿qué universidad es? :P

Sergen

#3
Flipper y Hans en mi opinión tienen parte de razón, más Flipper que Hans. Mi recomendación es que no hagas un videojuego J2ME para la asignatura de ingeniería del software si no quieres meterte en un lío de tres pares de narices ;-), realmente todo dependerá mucho de la ilusión y las ganas que tenga el profesor de sacar el tema adelante, si es una idea que has sacado tu por tu cuenta, yo me olvidaría de ello. Los videojuegos por lo menos muchas de las categorías en las que se trabaja tienen un alto componente de programación en tiempo real.

LuisV

Muchas gracias por vuestros consejos.

El problema que tengo es que para aprobar si o si tengo que hacer todo lo descrito, hombre, algunas cosas como diseño de flujos y demás se podrían omitir. Lo que pasa que al no enfrentarme nunca a un videojuego y sin tener experiencia pues ando un poco perdido la verdad.

La parte positiva es que ese videojuego entra en concurso para ser vendido, el mejor se venderá y se llevará un plus. De ahí que esté tan perdido y pidiendo vuestro consejo.

Muchas gracias a todos y espero seguir recibiendo consejos.

Un Saludo desde León.

Sergen

Por curiosidad, ¿qué metodología te piden que apliques?.

Vicente

Cita de: LuisV en 21 de Febrero de 2010, 04:45:03 PM
Muchas gracias por vuestros consejos.

El problema que tengo es que para aprobar si o si tengo que hacer todo lo descrito, hombre, algunas cosas como diseño de flujos y demás se podrían omitir. Lo que pasa que al no enfrentarme nunca a un videojuego y sin tener experiencia pues ando un poco perdido la verdad.

La parte positiva es que ese videojuego entra en concurso para ser vendido, el mejor se venderá y se llevará un plus. De ahí que esté tan perdido y pidiendo vuestro consejo.

Muchas gracias a todos y espero seguir recibiendo consejos.

Un Saludo desde León.

Cuando estuve en la uni, muchas veces estuve en una posición parecida a la tuya, y no te recomiendo hacer un juego, porque te vas a liar con el juego, y en el fondo no es lo que te están pidiendo para la práctica, con lo que vas a palmar la asignatura.

Si sigues empeñado en hacer un juego, ya que sabes Java yo no me complicaría con J2ME y haría algo como un ajedrez en Swing o algo así. Así no tienes que romperte la cabeza haciendo un diseño de juego y te centras en la documentación técnica de como hacer el juego.

Un saludo,

Vicente

urkel

Mi primera recomendación seria que le dieras una soberana patada al J2ME, ese mundillo es un puro inferno de jefes bocazas especuladores y programadores esclavizados. Si tuvieras que hacer un producto comercial, debes tener claro que NO haces UN juego para mobiles, sino DECENAS de versiones de ese juego que deberan funcionar, al menos, en la mayoria de mobiles del mercado... desde terminales tipo IPhone (480x320 res, 128 Megas Ram) hasta terminales (128x128, 200 Kbytes Ram).... Pero pongamos el mejor caso de que no llegas al caso de terminales prehistoricos aqui (aunque no en otros paises), aun tienes que asegurarte de que el juego funciona en muchos terminales y eso supone tenerlos fisicamente para testearlos, algo totalmente inviable para cualquier individual (ni pequeña empresa). Puedes olvidarte de la "fiabilidad" de los emuladores de cada casa, son pura basura, nunca simulan ni RAM, ni velocidad de procesamiento correctamente.

Quieres alternativas, si quieres orientarte a mobiles toma el IPhone (Objective-C). Si quieres orientarte a juegos guiate por XNA, Flash, OpenGL, DirectX...

Pero lo que preguntas es como empezar, y yo te recomiendo este enlace:

http://today.java.net/pub/a/today/2005/07/07/j2me3.html

Te explica el bucle principal de juego (mira en la funcion "run()"), y algunas cosas basicas mas. A partir de hay pasa un tiempo haciendo pruebas, buscando tutoriales de tilemaps, animar sprites, deteccion de colisiones, etc, etc.... Cuando tengas algunos de estos conceptos claros empezaras a distinguir las clases que definiran tu programa, clases de enemigos, del protagonista, de items, del mundo, etc... y dentro de esas clases distinguiras los estados en los que se pueden encontrar... Seguro que buscando en el Google encuentras esquematizaciones y diagramas de estados de videojuegos senzillos. Yo hize un pequeño juego clon del Arkanoid con Flash y Box2DFlash a modo de tutorial de desarrollo de juego, hice un esquema muy senzillo de diagrama de clases y sequencia de principales estados, es muy simple pero quizas te pueda dar ideas.

En fin, buena suerte con la practica, confio que no te pidan que sea comercial, desgraciadamente hay demasiada gente que se cree que por tener tu juego corriendo en el emulador se piensan que esta acabado (eso ni siquiera se cumple con el IPhone, que al principio se definia como una plataforma cerrada)... : :'( :'( :'(

LuisV

Cita de: Sergen en 21 de Febrero de 2010, 07:32:19 PM
Por curiosidad, ¿qué metodología te piden que apliques?.

No nos han dicho qué metodología debemos utilizar. A parte no hemos visto ninguna dedicada a la creación de videojuegos, solo para software comercial, que seguramente no sirva para desarrollar un videojuego. Nos piden:
1º Análisis de requisitos.
- Diagramas de Flujo de Datos.
- Diccionario de Datos y Especificaciones de Proceso.
- Diagramas Entidad-Relacion.
- Diagrama de Transición de Estados
- Diagramas de Estructuras.
- Diagramas de Flujo de Sistemas.
- Balanceo de Diagramas.

2º Diseño.
- Estructura de Datos.
- Arquitectura.
- Representacion del Interfaz.
- Diseño Procedimental.

3º Codigo.

4º Pruebas.

Eso es todo.

Vicente

Cita de: LuisV en 22 de Febrero de 2010, 06:32:55 PM
No nos han dicho qué metodología debemos utilizar. A parte no hemos visto ninguna dedicada a la creación de videojuegos, solo para software comercial, que seguramente no sirva para desarrollar un videojuego. Nos piden:

Los juegos son software, un poco raro a veces pero software al fin y al cabo. Aún recuerdo las charlas del CDV 2009 donde varios desarrolladores de videojuegos nos contaban como usaban Scrum en los proyectos de sus empresas.

LuisV

Cita de: Vicente en 22 de Febrero de 2010, 07:22:21 PM
Cita de: LuisV en 22 de Febrero de 2010, 06:32:55 PM
No nos han dicho qué metodología debemos utilizar. A parte no hemos visto ninguna dedicada a la creación de videojuegos, solo para software comercial, que seguramente no sirva para desarrollar un videojuego. Nos piden:

Los juegos son software, un poco raro a veces pero software al fin y al cabo. Aún recuerdo las charlas del CDV 2009 donde varios desarrolladores de videojuegos nos contaban como usaban Scrum en los proyectos de sus empresas.

Habia odio hablar de Scrum, ya que nos los sugirieron para otra asignatura (Sistemas expertos), tal vez heche mano de algun manual para conocer la metodología.

seryu

#11
mi experiencia con el profesorado, y la gente en general, es que valoran muy poco el trabajo que requiere hacer un videojuego. Por eso creo que vicente tiene razón en su comentario, hay que pensar que en el entorno académico importan más las formas que el resultado.

si sabes java, creo que la mejor alternativa puede ser hacer un juego de android, no te vas a encontrar los problemas y limitaciones del j2me, y es un mercado en auge.






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.