Algoritmo simulador de batallas

[za.asi]

Profundizando en las casillas, se podría especificar
Si el terreno es montañoso:

Código [Seleccionar] Expandir

- el sentido de la pendiente (es mas fácil atacar a un enemigo que esta por debajo de ti que a la inversa

- es espeso o no sera posible atravesar un tramo semi-boscoso pero prácticamente imposible avanzar por una selva virgen
- el agua puede ser profunda o no, de manera que sea posible vadear un río o sea necesario cruzar a nado (la caballería no podría, ni la infantería pesada)

Ademas cada casilla podría tener alimentos que se podrían explotar para alimentar las tropas durante su avance (pongamos que 5 turnos componen un día, por ejemplo) y esto daría lugar a unidades que se queden en la retaguardia para que los ejércitos no se tengan que detener a buscar alimento. También se podría integrar la opción de eliminar el alimento de la casilla al avanzar (incendios) a coste de la velocidad.

[GeorgArming]

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.

[za.asi]

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???

Yo me refería justamente a que se utilice el random para generar el porcentaje:

Una unidad tiene un 60% de probabilidades de derrotar a otra en combate, mientras que la.otra solo tiene un 40%.
Si sale entre 0 y 60 ganara la primera, pero si sale un 0 masacrara a la unidad enemiga mientras que si sale un 59 tendrá bajas  y heridos y habrá supervivientes heridos (o no) en la otra unidad. Ademas se podría generar otro random para decidir cuantas de las unidades superviviente del combate están heridas o si su comandante ha caído en la batalla modificando los atributos secundarios como la moral o incluso atributos primarios como la cantidad de soldados efectivos en la unidad (descontando los heridos).

También se podría modificar la velocidad en función de la salud (si el 80% de la unidad esta herido no se desplazara a la misma velocidad que si todos están sanos).

[za.asi]

-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).

Sobre esto quiero especificar que me refería a distancias cortas, como por ejemplo un río que si podria cruzar a nado una unidad de infanteria ligera, por ejemplo.

[GeorgArming]

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,...

[xustyx]

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 ).

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

[GeorgArming]

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.

[xustyx]

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

[GeorgArming]

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++.

[za.asi]

Yo solo se c++, pero mi nivel es muy bajo. De todos modos me interesa ayudar para poder aprender mas, pero si os decidís por un lenguaje diferente d c++ yo no podre participar.