Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - GeorgArming

#21
Cita de: eferion en 11 Agosto 2013, 13:34 PM
Las casillas van a ser cuadradas, triangulares, pentagonales, hexagonales, ... cada tipo de casilla tendrá sus implicaciones en el algoritmo. Lo más sencillo es que las casillas sean cuadradas, así se pueden encajar en una matriz sin aplicar transformaciones.

Suponiendo que las casillas sean cuadradas... vas a permitir ataques en diagonal o solo en vertical y horizontal ?? si solo permites en vertical y horizontal el código se podría simplificar.

En el caso de que se enfrenten dos unidades aquí tienes varias opciones:

* En general podrías empezar comparando la fuerza de uno con la defensa del otro... lanzar una tirada aleatoria y comprobar quien gana... el que gana o pierde vida o directamente desaparece.

* Hay unidades especializadas en acabar con otras ? esto le tendría que reportar un bonus a su fuerza o a su defensa ( las posibilidades son amplias ) antes de realizar la tirada del combate. Esto también podría ser aplicable a bonus negativos.

* Vas a tener en cuenta la moral de las tropas ?? o algún efecto beneficioso si atacan con unidades aliadas a su lado ?? Al final esto se puede traducir en modificar los bonus de ataque y defensa.

* El terreno va a influir en el combate ?? más bonus y malus para la defensa, el ataque e incluso el movimiento... algunas unidades podrían llegar a quedar atrapadas por el terreno o incluso no podrían traspasarlo... depende de ti.

* Se van a permitir ataques a distancia ?? estos ataques normalmente deberían ser especiales ya que la unidad que ataca no puede recibir daños.

Al final el combate se puede simplificar en calcular un modificador ( bonus/malus ) para la fuerza / defensa, aplicarlos a las unidades implicadas y realizar una tirada que determine quien gane... lo que pase después ya es otra cosa.

El movimiento de tropas puede ser algo tan sencillo como que las unidades avancen hacia el enemigo que tengan más cerca primero hacia adelante ( casilllas cuadradas ) y luego, si se puede, hacia los lados o puedes intentar currarte un poco la IA para que intente atacar a los puntos debiles del enemigo.

El algoritmo de general de la batalla podría ser algo así:

* Mover tropas equipo 1
* Atacar equipo 1
* Mover tropas equipo 2
* Atacar equipo 2

Posteriormente si te ves con ganas podrías mejorarlo y que sea continuo... con tropas moviéndose mientras son atacadas y cosas así. ( Nota: esto no es tiempo real por mucho que algunos se empeñen )

Y finalmente te puedes plantear si alguno de los bandos puede rendirse en un momento dado en base al desarrollo de la batalla o si por contra se exige la destrucción total del enemigo.

La verdad es que dicho parecen cuatro tonterías que se programan en un par de horas... pero al final tiene bastante más curro.

Gracias por tus sugerencias. Hay cosas que dices en las que ya había pensado, si te fijas en el post original (por ejemplo, lo del terreno). Otras no las había tenido en cuenta y están bien.

Hoy he estado todo el día dándole vueltas al tema del algoritmo. Las casillas, como dices, deben ser cuadradas, y lo del ataque en diagonal quizás sería mejor que sí pero entonces es más complejo. El tema es que quiero que haya ataque a distancia, y no tiene sentido que éste no puede hacerse en diagonal.

El juego está formado por casillas 10x10.

Lo mejor sería que todo el código fuese modular y que el runtime funcionase por turnos. He pensado eso:

Programa general

Leer datos (llamando a una función externa).
Iniciar el simulador general pasándole los datos leídos.
Devolver datos, guardándolos (llamando a una función externa).
Fin del programa.


Simulador general

Determinar los valores de las variables globales (clima, tipo de terreno, cuál de los dos ejércitos tiene la iniciativa, tácticas elegidas por cada ejército,...) según los datos leídos.
Crear las 100 casillas de la siguiente forma: se determina el tipo de terreno según los datos leídos con un 0% de azar O según el tipo de terreno general se generan aleatoriamente las diferentes casillas (por ejemplo, si es en una zona alemana, debería haber 75% de terreno de bosque, 5% de agua,...).
Crear instancias unidades partiendo de la clase Unidad y completando los atributos según los datos leídos (velocidad, motivación, estado físico, número total de efectivos de la unidad, defensa cuerpo a cuerpo, ataque cuerpo a cuerpo, defensa a distancia, unidades que se le dan bien para luchar, unidades que se le dan mal, terrenos que se le dan bien, climas que se le dan bien,...).
Ubicar las unidades en los sitios especificados por los datos leídos (aquí puede devolver error si se han puesto las unidades en sitios inválidos: fuera del "campo propio", encima de otra unidad ya colocada o en casillas ocupadas por agua,...).
Iniciar bucle de combate (con un máximo de 100 turnos) {
  Si estamos en el primer turno {
    Se avanzan una a una las unidades del ejército con iniciativa (obviamente, la caballería avanza más casillas por turno que la infantería pesada).
    Según la táctica elegida por el ejército sin iniciativa, las unidades avanzan o no.
  }
  Si no estamos en el primer turno {
  Las unidades del ejército con iniciativa avanzan según la táctica, disciplina, estado físico, situación de combate y del terreno y motivación que tengan.
  Si en alguna casilla se produce situación de choque (se encuentran en casillas contiguas unidades enemigas entre si o alguna unidad con ataque a distancia está a dos casillas de una unidad enemiga) {
  Se inicia el simulador concreto pasándole como datos las casillas de lucha y las unidades que participan.
  }
  Las unidades del ejército sin iniciativa avanzan según la táctica, disciplina, estado físico, situación de combate (si una unidad no está en combate y ha pasado de la mitad del campo, se dirigirá hacia unidades enemigas, preferentemente hacia las más cercanas) y del terreno y motivación que tengan.
  Si en alguna casilla se produce situación de choque (se encuentran en casillas contiguas unidades enemigas entre si o alguna unidad con ataque a distancia está a dos casillas de una unidad enemiga) {
  Se inicia el simulador concreto pasándole como datos las casillas de lucha y las unidades que participan.
  }
}


Simulador concreto


Si uno de los dos bandos está solamente formado por una unidad con ataque a distancia y el otro no está solamente formado por unidades de ataque a distancia {
  Las unidades dentro del combate sin ataque a distancia atacadas por unidades con ataque a distancia se dirigen hacia la unidad que les está atacando a distancia o deciden ponerse a salvo, según circunstancias de la partida (táctica, motivación,...).
}
Se cuentan los turnos de combate.
Atacan las unidades con iniciativa y ataque a distancia.
Se efectúan los daños: según capacidad de ataque, defensa, clima,...
Atacan las unidades sin iniciativa pero con ataque a distancia.
Se efectúan los daños: según capacidad de ataque, defensa, clima,...
Atacan las unidades con iniciativa cuerpo a cuerpo.
Se efectúan los daños: según capacidad de ataque, defensa, clima,...
Atacan las unidades sin iniciativa cuerpo a cuerpo.
Se efectúan los daños: según capacidad de ataque, defensa, clima,...
Si se llevan 3 turnos consecutivos en los que un equipo de los dos consigue más bajas {
  La unidad que está perdiendo se ve forzada a retroceder.
  Si no puede retroceder (porque está acorralada, dificultades del terreno,...) {
    Desbonificación (le baja mucho más el estado físico, motivación,...).
  Se pone el contador de turnos a 0.
}
Sino {
  Según táctica, moral y motivación, una unidad puede decidir (o no) retroceder.
}


¿Qué os parece? ¿Está bien? ¿No? ¿Le falta algo (general)? Si está bien, podríamos pasar a concretar más el algoritmo, poniéndolo ya con pseudocódigo y pasando argumentos, con funciones y variables,...
#22
Hola foreros. Quiero crear un simulador de batallas antiguas (rollo romanos, cartagineses,...) en modo texto. Es decir, quiero hacer un programa que lea unos datos, simula la batalla y dé otros datos.

Los datos que leería serían básicamente unidades de uno y otro ejército (así como su forma física, motivación, estado de salud, munición, adaptabilidad a los diferentes terrenos, a qué tipo de unidades hacen más daño y a qué tipo de unidades son más vulnerables,...), la disposición de los ejércitos en el terreno, el terreno mismo, las condiciones climatológicas y la táctica elegida por cada bando (defensiva, ofensiva, atacar por los flancos,...).

El usuario debería poder organizar las tropas (en grupos de "unidades", por ejemplo, 1 unidad de caballería serían 50 soldados) por el terreno y decidir las posibles tácticas, si se debería contemplar la rendición, rotaciones,...

La batalla en sí misma había pensado en organizarla por casillas (por ejemplo,e l campo de batalla es un campo de 10x10 casillas) y "turnos", aunque el usuario sólo podría escoger la táctica al principio.

Al final, el programa devolvería el nuevo estado de los ejércitos, número de bajas, heridos, si huyó alguno de los equipos, si se ha tomado el terreno,...

Sinceramente, tengo muchas dudas. Lo he puesto aquí porque mis dudas son básicamente de programación general. He estado pensando en algún algoritmo, pero el tema de las casillas no lo domino. Y otro tema que me es muy difícil es el de las luchas en sí. Si se enfrentan dos unidades, se me ocurre evaluar las diferentes características y eso. El problema es generar estas luchas, porque se deberían dar en el caso que unidades enemigas se encuentren en casillas contiguas. Y ahí el problema es que podría haber más de dos.

La intención de este post es que entre todos escribamos un algoritmo para este simulador. Yo, que soy el autor del post y el mayor interesado, voy a trabajar mucho, pero seguro que aquí hay muchos cracks que saben hacerlo y les interesa o gente que simplemente está interesada en aprender.

Lo dicho, a ver si vamos posteando el algoritmo. Voy a mirar código de simuladores de ajedrez porque podría ser de ayuda. Yo iré poniendo mi algoritmo, entre todos vamos corrigiendo si os parece y añadiendo cosas.

Muchas gracias.

Saludos.
#23
Dudas Generales / Dominios .com y trademarks
10 Febrero 2013, 22:38 PM
Hola, no sé si hay algún experto en dominios por aquí, pero estoy seguro de que todos entendéis más o menos del tema.

Resulta que quiero sí o sí un dominio .com. Es un buen dominio, pero no aloja ninguna web y su trademark correspondiente no está registrada. Si yo registrase la marca, ¿tendría derecho a que se me cediera el dominio? ¿Incluso si sólo la registrara en España? Si no sabéis eso, ¿sabéis de alguien que me podría ayudar?

Saludos.
#24
Sin duda lo mejor es que te bases en Ubuntu y que lo adaptes al máximo. Es cierto que de minimalista no tiene nada pero es la que más soporte touch tiene y es posible adaptarla a lo que quieres. Por ejemplo, piensa en proyectos "importantes" que hayan hecho algo similar: Chrome OS. Google lo eligió. ¿Por qué? Pues porque es la mejor opción.

De todas formas, yo estoy trabajando en una distro similar a lo que propones... Si te interesa, podemos hablar.
#25
Cita de: jdc en 30 Diciembre 2012, 11:15 AM
Demasiada responsabilidad para Google, si lo hicieran así seguramente debería dejar de ser gratis

Depende de cómo se hiciese. ¿Sabes que cuando un fabricante quiere incluir Android (y poder llamarle Android, y tener Google Play,...) en su dispositivo, tiene que conseguir la licencia de Android de Google no? Pues imagínate que Google pidese las siguientes condiciones para dar la licencia:

-Que el fabricante se comprometa a desarrollar los drivers y a hacerlos open-source y/o incluirlo en el repositorio central de Android.
-Que el fabricante se comprometa a instalar la imagen de Android que les da Google sin ninguna modificación.
-Que el equipo de trabajadores del fabricante, además de darle los drivers, se comprometa a participar en los ports de Android a su dispositivo y, si es posible, al desarrollo general de Android.

Es exigente, pero sería muy bueno para el fabricante porque un dispositivo así se vendería muy bien.
#26
Cita de: jdc en 29 Diciembre 2012, 17:12 PM
Y lo que menciona Aberroncho como lo solucionas?

lo mencionado por aberroncho es precisamente lo que no ocurriría si se hiciese. estoy hablando de que google lo controle todo.
#27
Pues entonces que el télefono no te deje actualizar si detecta que no lo soporta  :D
#28
Si os habéis fijado, en todos los OS de escritorio, las actualizaciones dependen 100% del responsable del OS y 0% de los fabricantes, porque el OS es el mismo para todos los ordenadores. Yo me pregunto, ¿no podría aplicarse esto a Android?

No sé si me explico. Por ejemplo, Canonical libera la versión 12.10 de Ubuntu. Entonces, todos los Ubuntu de mundo (siempre y cuando dispongan de conexión a internet y tengan activada la opción de avisar si hay nuevas versiones disponibles) lo detectan y se pueden actualizar. En cambio, Google libera la versión 4.2 de Android. Entonces, a los fabricantes que les da la gana (a muchos no) se les pasa por la cabeza bajarse el código de Android 4.2, portarlo a su dispositivo y añadir aplicaciones y capas innecesarias. Ah, y luego las operadoras también meten mano.

Sé que las arquitecturas de Android y de un OS de sobremsa son diferentes, pero se podría cambiar la de Android para que se permitiera eso. La complicación básica es que hay una gran variedad de drivers diferentes para cada móvil, y el OS tendría que contar con todos pero... a los OS de escritorio les pasa exactamente lo mismo. Además, en muchos casos se pueden meter drivers genéricos que en principio pueden funcionar más o menos bien con todos los dispositivos.

¿Qué pensáis? ¿Estáis de acuerdo? ¿Lo veis viable?
#29
Hardware / Re: Tablet o eBook???
27 Diciembre 2012, 00:08 AM
Cómprale o un Kindle o un Nexus 7.
#30
En cuanto al posible éxito de una nueva empresa, está muy de moda decir que lo importante es hacer el producto y no la idea pero yo creo que la idea es muy importante. ¿A alguien se le ocurre algo?  :D