Proyecto de simulador entrenamiento.

Started by Danielo515, September 29, 2010, 07:39:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Danielo515

Hola chicos, mucho tiempo sin postear nada sí, y encima, como no para pedir ayuda.

Hace poco me vino la inspiración y me ha apetecido hacer un juego de esos marginales raros y que probablemente solo yo disfrutaré (para eso programa uno juegos no?)

El caso es que ahora está en fase de diseño porque no quiero llegar y en la mitad de proyecto quedarme trabado así que lo quiero tener todo bien atado antes de ponerme a picar código.
Y aquí es donde entran las almas caritativas, a ver si me ayudais con el diseño.

Básicamente se trata de un simulador de entrenar un athleta.

Lo que yo me había había planteado  era lo siguiente:

Cada parte del cuerpo tiene:
- puntos de progreso
- nivel
- daño

Por cada 100 puntos de progreso una parte del cuerpo sube de nivel, y si alcanza un límite máximo de daño, esa parte se lesiona.

El problema viene cuando intento definir cada ejercicio.

Lo que se debe tener en cuenta de cada ejercicio es:
- Que parte del cuerpo ejercita
- Cuantos puntos de progreso aporta
- Cuanto daño hace
- Cuanta energía consume.

Había pensado crear un array con todas las partes del cuerpo, y que en cada fila contenga sus valores.
Lo que no se es como definir los ejercicios. ¿Hago una función por cada ejercicio? ¿o hago una función que reciba un array que contenga los datos del ejercicio?

Yo había pensado lo segundo. ¿Alguna idea? ¿Alguien piensa que esto sería mejor con herencia?

Venga chicos, muchas gracias!

Noivern

crea un proceso que sea una ParteDelCuerpo y dale los atributos que quieras (nivel, daño, etc) y otro que sea el personaje, con N partes de cuerpo como  atributos. Si tanto los atributos del personaje como de las PartesDelCuerpo los haces publicos, entonces los ejercicios pueden tener a cualquier parte del personaje pasandole como parámetro el personaje como tipo de dato. Recuerda que para hacer variables públicas debes declarar los procesos/funciones primero y a partir de ahi puedes usar como tipo de dato un proceso declarado.
Los ejercicios los haría como una función, recibiendo como parámetro el tipo de ejercicio y a quién afecta.

Si a veces pienso que bennu sería aún mejor como POO, pero con las variables publicas funciona muy bien :P

PD: que raro tu juego xD

Danielo515

#2
Eso que dices sólo sería necesario se cada parte del cuerpo hiciera algo y hubiera más de un personaje en pantalla, pero no es así.
El juego se centra en UN único personaje, por lo que no necesito un proceso comiendo memoria y ciclos de CPU por cada parte del cuerpo cuando todas las variables que tengan que ver con el personaje (y por tanto con el juego) van a ser públicas.

A mi lo que me cuesta es la lógica de cómo relacionar unas cosas con otras. De momento se me ha ocurrido esto, pero es algo complicado. No está escrito en bennu, sino en un lenguaje que me invento cuando programo (pseudocódigo más tirando a código que otra cosa). A ver si me explico.


Cómo se define cada ejercicio:
Cada ejercicio es un array que contiene una serie de enteros que corresponden a qué músculo/os afecta, cuanto progreso aporta a cada músculo, cuanto daño hace y cuánta proteína, hidratos de carbono y grasas consume.
ejercicio[X][3]{
{Músculo, progreso, daño}
...
...
{proteína, hidratos, grasas}
}

Ejemplo
Press_Banca[3][3]{
{PECHO, 10, 5}
{HOMBRO, 3, 3}
{10, 2, 1}
};

Cómo se realiza cada ejercicio
La realización de un ejercicio es una función que recibe como parámetro un array del ejercicio a hacer (veáse como se define cada ejercicio) y el número de repeticiones de cada ejercicio. Esta función se encarga de ir leyendo los datos del array y sumando o restando de donde corresponda. Primero averigüa cuantos músculos implica el ejercicio mirando la longitud del array y restándole uno ya que la última fila de cada ejercicio corresponde a lo que gasta. Esto lo podemos plantear como -1 o -2 según si luego vamos a ir de "0 a max-1" o de "0 a max".
function ejercitar ( ejercicio[][], repeticiones){
PRIVATE
Int musculos_implicados = fin = ejercicio.lengt()-1 ;
BEGIN
for  j = 1 to repeticiones
{
for i=0 to musculos_implicados-1{
Cuerpo[ ejercicio[i][MÚSCULO] ] [0] + = ejercicio[i][PROGRESO];
Cuerpo[ ejercicio[i][MÚSCULO] ] [1] + = ejercicio[i][DAÑO];
}
Proteina - = ejercicio[fin][PROTES];
hidratos - = ejercicio[fin][HIDRATOS];
grasas - = ejercicio[fin][GRASAS];
}
END

Noivern

uh, los procesos los trato como objetos para simplificarme la vida además de que queda más escalable.
onda quedaria como

funcion ejercicio(tipoejercicio, personaje)
begin
   switch(tipoejercicio)
      case UN_EJERCICIO:
          //logica
          personaje.partedelcuerpo.atributo = modificar el atributo como quieras;
     end
     case N:
     //logica
     end
  end
end

Tienes razón en que usa más ram y cpu, pero es infinitamente más facil

Danielo515

Según tu lógica habría un personaje, que contendría una variable pública que "apunta" a un proceso "parte del cuerpo" cuyas variables son tambíen públicas

Algo como

personaje
public

       partedelcuerto pecho;
       partedelcuerto espalda;
etc.
END

partedelcuerto
public
       atributo a
       atributo b;
end

¿No? Muchas gracias por lo que me has aportado hasta ahora. Tal vez merezca la pena teniendo en cuenta que hay un solo proceso personaje y solo 6 procesos partedelcuerpo.

Noivern

Exactamente, a eso me refería en mi primer post :)

Danielo515

Muchas gracias por aportarme otro punto de vista y simplificarme la vida. Sabía que no perdía nada por hablarlo aquí.


Karma up.

Drumpi

Tal como yo lo veo, se supone que tiene un único personaje que entrenar, por lo que lo suyo sería usar una estructura global. Luego, cada parte del cuerpo sería un campo, o si tiene varios campos, lo ideal sería crear un array de structs, una por cada parte (puedes identificar cada número usando una constante, tipo:

tronco=0;
brazo_i=1;
brazo_d=2;

datos_cuerpo[brazo_i].fuerza=3...

Luego otra estructura global con los datos de cada entrenamiento, y luego ya creas los distintos entrenamientos como procesos/funciones (minijuego_pesas, minijuego_abdominales...) y que se le pase coo parámetro los datos de ese ejercicio.

Tampoco tengo yo muy claro qué es exactamente lo que quieres hacer, pero una buena organización es fundamental en este tipo de juegos.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Danielo515

Por supuesto la organización es esencial. Lo que tu has puesto es lo que yo había pensado / diseñado en un principio, pero la propuesta del compañero me ha parecido mucho mas intuitiva. De hecho hoy me he dado cuenta de se simplificaría aún mas con poo, ya que cada parte del cuerpo seria una clase con una serie de metodos que serian los ejercicios. Asi cuando escribes parte.ejercicio incluso el editor de código te diría que ejercicios hay disponibles para esa parte. Como dices tu ( y pensaba yo) solo lo haré si hay una bajada del rendimiento importante, si no no merece la pena. Pero gracias a todos de todos modos

Noivern

Danielo, sabes no me había percatado pero se puede hacer una mezcla que no implique agregar procesos.
En vez de que parteDelCuerpo sea un proceso, que sea un type de dato y se usa igual, haciendolas publicas, una variable de tipo parteDelCuerpo publica por cada parte de cuerpo. Aún me cuesta asimilar todas las posibilidades de bennu xD

Danielo515

MMM, noirvem por un segundo he tenido la tentación de cargarme el proceso del músculo y convertirlo en un tipo de dato, que seguramente consume muchos menos recursos, y tal vez tenga que hacerlo algún día, pero creo que me viene mejor dejarlo como proceso ya que más adelante, cuando prepare los gráficos, cada parte del cuerpo tendrá un gráfico y una evolución independientes del resto del cuerpo. Es decir, si entrena mucha pierna, la pierna crecerá, si entrena mucho hombro, el hombro crecerá más, y todos serán independientes. A no ser que se me ocurra una forma mejor de tratar los gráficos, se queda así.

Pero de todos modos, tu propuesta es muuy buena, y queda en mi memoria para futuros proyectos en los que sin duda me hará falta, la verdad es que tampocos e me había ocurrido.