Mensajes

Confirmo.

PD: ya he terminado las implementaciones y la documentación de todos los métodos setters y getters.

Mola

Perfecto, también estoy de acuerdo en ponerlos como privados. C++ 11 mola.

A ver, si os parece, los que estemos interesados nos apuntamos en una lista. Los posibles interesados:

avesudra: CONFIRMADO
0xDani: CONFIRMADO
za.asi: CONFIRMADO
xustyx: CONFIRMADO
eferion
GeorgArming: CONFIRMADO

Vamos confirmando, si os parece.

Confirmo.

Me gustaría ver código C++ si sale un simulador potente. Sugiero que se miren las especificaciones de C++ 11  

Lo que veo es que todavía no habéis hablado del simulador en sí como objeto. Con esto quiero decir que el simulador debería poder simular batallas con soldados distintos de las clases predefinidas para ello, tal vez clases derivadas, y debería haber mucho código reusable. Todo esto para que no haya que cambiar todo el mecanismo del simulador para cambiar de ejército, o modificar funciones internas del simulador para añadir características. Incluso el mismo simulador podría ser de una clase heredable.

Es interesante lo que dices.

A ver, yo lo que había pensado para el simulador es que leyese los datos de los ejércitos a partir de una base de datos y a partir de ahí asignase los atributos. En ningún momento he dicho que en el propio código del simulador ya vayan predefinidos los valores de los atributos.

¿Sabes C++, no? ¿Te gustaría trabajar con nosotros?

Yo he estado codeando algo:

unity.hpp

Código [Seleccionar] Expandir

#include <string>

class Unity {
  public:
    std::string id;
    std::string generalType;
    std::string name;
    int numberOfSoldiers;
    int numberOfInjuredSoldiers;
    float motivation;
    float physicalState;
    std::string favourableWeather;
    std::string harmfulWeather;
    std::string favourableTerrain;
    std::string harmfulTerrain;
    float meleeAttack;
    float meleeDefense;
    float longDistanceAttack;
    float longDistanceDefense;
    float discipline;
    float speed;
    std::string generalTypeFavourable;
    std::string generalTypeHarmful;
    std::string concreteTypeFavourable;
    std::string concreteTypeHarmful;
    float nutrition;
    float resistence;
};


box.hpp (casilla)

Código [Seleccionar] Expandir

#include <string>

class Box {
  public:
    std::string id;
    std::string terrain;
    bool occupied;
    std::string unityId;
    float height;
};

mapcreator.hpp

Código [Seleccionar] Expandir

#include <iostream>
#include "box.hpp"
#include "unity.hpp"


int createMap() {
 Box box[10][10];
 for(int x = 0; x < 10; x++){
  for(int y = 0; y < 10; y++) {
  /*Asignar valores a cada casilla según parámetros leídos, por                ejemplo:box[x][y].id = ...
  box[x][y].terrain = ...
  box[x][y].occupied = ...
  box[x][y].unityId =
  box[x][y].height =
              */
  }
 }
 return 0;
}

Es muy poca cosa, porque para el codeo en sí he tenido poco tiempo... Pero esta noche avanzaré más. Los que estáis interesados en darle al código, podríamos buscar una forma de colaborar, no? Bitbucket?

Y por cierto, he comenzado con C++ pero si decidís otro lenguaje lo votamos o acordamos o algo...

Lo que me está bloqueando es qué valores asignar a las casillas, qué hacemos, creamos un mapa "de prueba"? Un .txt?

Saludos.

Yo C++ no tengo mucha idea XD, soy mas de C#, aunque no tengo mucha idea de juegos y estas cosas estaría bien hacerlo en C# y luego aplicarle XNA para el modo gráfico, simplemente por su sencillez.

Bueno elegir vosotros yo ahora toy hechando unas partidas al LOL

Yo no lo haría en C#, entre otras cosas porque no tengo Windows xD. Yo lo haría en C++, sobretodo para temas de rendimiento. Imagínate que lo que hacemos al final es un juego online web, entonces iría bien que el simulador estuviese en C++.

Claro esta que la unidad tiene todo su derecho en su turno de Huir si ve que las cosas van a ir mal

Ok, pues qué, comenzamos a escribir?

Yo ya he puesto unos atributos y algo del algoritmo, pero ahora deberíamos concretar a tope. No sé si con pseudocódigo o ya con algún lenguaje tipo C++.

Para que vayamos colaborando todos de forma fácil qué hacemos? Google Docs (al menos para el pseudocódigo? Algo tipo pastebin pero editable?

Por auqí vamos posteando comentarios, ideas, avances,... Y luego iría bien tener algún sitio donde ir escribiendo el pseudocódigo (o quizás ya el código, como veáis, a mí me mola C++).

Saludos.

[concretemos]

sobre esto quoero especiicar que me referia a distancias cortas, como por ejemplo un rio que si podria cruzar a nado una unidad de infanteria ligera, por ejemplo

Ya, pero vamos a ver, en medio de una batalla no se pondrán los legionarios a nadar.  Yo no lo complicaría tanto,.

Sobretodo, lo importante es que concretemos y la única forma de hacerlo es hablando de algoritmos, clases, pseudocódigo,...

Este metodo lo utilizaria para aplicarlo a la IA, en cuanto a los combates concretos, yo me decantaria por simular la lucha realmente y olvidarno de estadisticas XD, así aun sería mas aleatorio.

Me refiero a que si calculamos la ventaja que tiene un contrincante VS otro, se puede deducir facilmente quien ganara, por ejemplo uno tiene un 60% de ganar (se tira un dado del 1 al 10, si cae entre el 1 y el 6 gana, si no pierde), bueno, pues este metodo me parece fantastico para la IA, pero cuando una unidad decide atacar yo simularia realmente el combate en el turno.

Por otra parte tenemos que definir bastante bien los atributos principales y los secundarios...

Para mi los principales son los contables, y los secundarios son incontables, los atributos secundarios incrementan en % atributos principales, mientras que por otro lado tambien tenemos otra clase de condiciones que se aplican como auras despues de realizar los calculos anteriores.

Una vez hecho esto se simula las dos unidades golpeandose, utilizando randoms para ver si una unidad mete "Critico, esquiva, cae un trueno y despista al otro XDDDDD etc etc..." creo que es mejor aplicar un random a cada golpe así la suerte decidirá, aunque uno de primeras tenga más posibilidades de ganar, nunca se sabe, y bueno el combate acaba cuando uno de los dos se queda sin Vida.

Que os parece???

Estoy básicamente de acuerdo, pero unos apuntes:

-Me parece bien lo de principales y secundarios, pero cuando hagamos la clase tampoco es necesario realmente saber cuál es cuál.
-"Hasta que uno se quede sin vida": sería lo más simple pero yo no lo haría así. Yo haría que la lucha entre dos unidades durase unos turnos y durante ellos uno de los dos pudiese retroceder (lo he especificado en los algoritmos de arriba, míralo ).

Profundizando en las casillas, se podria especifiar
Si el terreno es monañoso:
- el sentido de la pendiente (es mas facil atacar a un enemigo que esta por debajo de ti que a la inversa

- es espeso o no sera posible atravesar un tramo semiboscoso pero practicamente imposible avanzar por una selva virgen
- el agua puede ser profunda o no, de manera que sea posible vadear un rio o sea necesario cruzar a nado (la caballeria no podria, ni la infanteria pesada)

Ademas cada casilla podria tener alimentos que se podrian explotar para alimentar las tropas durante su avance (pongamos que 5 turnos componen un dia, por ejemplo) y esto daria lugar a unidades que se queden en la retaguardia para que los ejercitos no se tengan que detener a buscar alimento. Tambien se podria integrar la opcion de eliminar el alimento de la casilla al avanzar (incendios) a coste de la velocidad.

Sí, eso es muy interesante. Lo meteríamos en la clase casilla.

-Lo del pendiente ya lo había pensado. Yo lo que haría es que un atributo fuese la altura de la casilla, entonces si están luchando dos unidades, comparamos sus respectivas casillas y bonificamos o penalizamos sus características según cuál sea relativamente más alta.

-Lo de si es una zona boscosa, lo veo un pelín complicado. Lo podríamos hacer más adelante. Sino, lo que podríamos hacer es que en zona boscosa pudiese pasar infantería ligera pero no elefantes ni caballería pesada, por ejemplo.

-Sobre lo del agua, a ver, yo no veo muy realista que una unidad cruce a nado una casilla. Si es zona pantanosa, puede pasar una unidad caminando (la caballería también puede), si es agua "profunda" nadie podría pasar (y, para más adelante, podríamos añadir el elemento naval).

-Lo de la alimentación, piensa que el simulador que estamos planeando es el de una simple batalla. Cuando lo tengamos hecho, podríamos hacer un simulador de campañas y que los dos se sincronicen, pero eso que hablas de la alimentación yo lo veo más bien un tema estratégico que táctico, y por ahora vamos a por la táctica. Cuando acabemos, añadimos simulador de campañas.

Bueno, lo que veo es que hablando así es difícil de concretar. Fijaos, por favor, en los algoritmos que he puesto y completadlos. O sino nos ponemos con el pseudocódigo y las clases ya. Debemos concretar.

Tambien se podria añadir los factores que alteran la moral:
- resultados ultimas 5 batallas
- clima + terreno +/-
- situacion relativa en el ejercito propio y enemigo
- ...

Ademas se podria ir subiendo la dificultad:
- primera batalla la IA calcula un turno de antelacion
- segund dos
- tercera tres

Se puede buscar manera de atravesar obstaculos:
- se tarda un turno en talar una casilla de bosque y otro mas en construir un balsa

Si se implementa el aumento progresivo de dificultad se puede aumentar el nivel de las unidades superviientes aumentando sus caracterusticas ( ataque, defensa, velocidad...) o la moral

Sobretodo creo que es importante agregar el factor random a los combates, teniendo en cuenta lS habilidades de las unidades.

Gracias por tus sugerencias. Estaría bien lo de la IA pero primero tenemos que crear la base.

En cuanto a la motivación, también le podría afectar si el general está en la batalla o no, cómo los trata el general, resultados como has dicho,... Lo detallaremos del todo cuando pongamos el pseudocódigo. Lo vamos poniendo ya?

Lo de tardar más o menos según el terreno está bien. Esto lo deberíamos meter en el objeto Casilla. Lo de la balsa no lo veo porque en medio de una batalla no es muy realista, pero por ejemplo atravesar zonas pantanosas reduciría la velocidad un tanto por ciento.

En cuanto al factor random, sí, es muy importante. Lo que debería hacer el simulador es calcular probabilidades teniendo en cuenta los factores que hemos dicho, y luego si por ejemplo sale un 70% que pase una cosa, el simulador randomiza y si sale 90 será que no pasará y si sale 60 sí pasará.

Creo que hay que bajar un poco el nivel que requiere tantas condicionesy ir poco a poco.

Por ejemplo lo de simular una batalla lo veo más como la lucha entre dos IA, y crear una IA no es tan complicado en este caso, simplemente puedes hacer que la máquina calcule todos los posibles movimientos con todas sus tropas y haga una estadistica de cual movimiento es el que mas le rinde, y si quieres subirle en nivel, puedes hacer que calcule uno, dos o tres turnos antes de mover, claro esta, que contra mas turnos analice, las posibilidades crecen exponencialmente pero también la IA puede realizar mejores movimientos... aunque no siempre realice el mejor ya que en sus simulaciones puede que gane pero luego cuando mueve y se vuelve a simular realmente la lucha, puede que un "RANDOM" le page mal esa vez

Por todo lo demas, lo veo bien pero yo me decantaría por atributos más usados: Vida, armadura, ataque, (velocidad de ataque)* etc...
Luego lo del clima y el terreno se podría arreglar como Auras.

Me parece bien, pero lo de la IA yo lo implementaría después de haber hecho la "base" del simulador. Por ejemplo, propongo esta clase:

Clase unidad

Código [Seleccionar] Expandir

Atributos:
-ID de la unidad.
-Tipo general de unidad (caballería, infantería,...).
-Tipo concreto de unidad (Unidad de caballería pesada,...).
-Nombre de la unidad (Unidad de caballería pesada II,...).
-Número de efectivos.
-Heridos.
-Motivación.
-Estado físico.
-Clima favorable.
-Clima perjuficial.
-Terreno favorable.
-Terreno perjudicial.
-Capacidad de ataque cuerpo a cuerpo.
-Capacidad de defensa cuerpo a cuerpo.
-Capacidad de ataque a distancia.
-Capacidad de defensa a distancia.
-Disciplina táctica (como más elevada, más probable es que una unidad cumpla las órdenes y que lo haga bien).
-Velocidad (en casillas/turno  :D).
-Tipo general de unidad que se le da bien (la caballería tiene bonificación contra la infantería en general).
-Tipo concreto de unidad que se le da bien.
-Tipo general de unidad que se le da mal.
-Tipo concreto de unidad que se la da mal.
-Nutrición.
-Capacidad de resistencia.


De momento se me ocurre esto. ¿Qué os parece? Saludos.

Realmente quieres hacer un simulador o quieres aplicarle jugabilidad, por que estaría muy chulo la verdad. Mezcla de Warcraft 3, AoE, en tablero.

Si realmente quereis ir haciendo algo podriamos definir ya con listas los atributos básicos de las unidades, y luego los secundarios. ¿Que os parece? Así ya podemos generar una classe básica de donde hereden todo los otros tipos de unidades y ponernos a trabajar xDD.

Yo hablo de él como simulador, pero sí, tenemos que aplicarle jugabilidad. La idea sería que el simulador sería el backend, y luego sería fácil añadir un frontend y podríamos hacer un buen juego online masivo (o lo que queramos).

Qué te parecen los algoritmos que he puesto?

Como dices podemos ya ir añadiendo los atributos de las unidades para tener la clase. Me parece muy bien.