Ir al contenido

publicidad

Foto

Motor grafico para un simulador de futbol


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
15 respuestas en este tema

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#1

Escrito 23 diciembre 2010 - 16:22

Hola a todos

Soy un colaborador de uno de los managers de futbol que aspiran a cubrir el vacio que dejo PCFutbol: Futben (dentro de poco Unifutbol). Me atreveria incluso a decir que es el que mejor pinta tiene de todos los que he visto por internet, ya que cada beta nueva que va saliendo incorpora nuevas funcionalidades, pero manteniendo una estabilidad enorme de la que ni el propio PC Futbol podia presumir. Aqui os dejo la web, por si quereis echarle un ojo:

http://www.futben.com/

El caso es que se esta planteando la posibilidad de incluir un visualizador de partidos, en principio en 2D. He estado buscando bastante por internet y no he encontrado ningun programa en el que se pueda hacer esto. ¿Conoceis alguno que pueda servirnos?

Estoy acabando ya Ingenieria Informatica, asi que no pasa nada porque sea complejo, me las puedo apañar :)

Un saludo

EDIT: Si el enlace a la web de Futben es un problema, que un moderador me lo edite sin problemas, aunque es muy facil encontrarla en google :P

  • AiZaK

  • Ultima

  • vida restante: 100%
  • Registrado: 07 jul 2004
  • Mensajes: 3.681
#2

Escrito 23 diciembre 2010 - 17:33

ostias que buena pinta tiene, yo soy todos los años fiel comprador del FOOTBALL MANAGER, pero este 2011 veo que el juego tiene cientos de fallos/bugs... así que si vuestro juego está guay... será el que me ponga en el pc. Amos a bajarlo!!!

Ánimo y gracias

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#3

Escrito 23 diciembre 2010 - 17:41

Me alegro de que te guste la pinta, aunque antes de valorar cualquier cosa recuerda que aun no esta el juego completo, esta aun en fase beta y le faltan cosas por incorporar. Aunque por otro lado si es verdad que ya es muy jugable, y esta a punto de salir la beta 8, que incorporara competiciones europeas y copa del rey, entre muchas otras cosas.

De todas formas, sigo buscando el programa para el visualizado (si tambien permite interactividad con el jugador, o posibilidad de visionado/juego en 3D, pues mira, mejor, aunque en principio no seria necesario)

Un saludo

  • gotenx

  • Bahamut

  • vida restante: 100%
  • Registrado: 13 ene 2008
  • Mensajes: 4.253
#4

Escrito 23 diciembre 2010 - 17:42

Una preguntilla, para esto tienes que pagarle algo a los equipos por los derechos ? X-D
Tiene buena pinta,pero necesitas graficos 2D o 3D ?
EDIT: Ok,no ví tu mensaje anterior.
Creo que cualquier motor 3D tambien te puede servir para graficos 2D,pero los puede haber mas específicos.

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#5

Escrito 23 diciembre 2010 - 19:13

El tema de los derechos se esta estudiando. Como nadie se beneficia de usar los nombres reales (economicamente hablando, ya que la beta es gratis) creemos que no hay problema, pero como ya he dicho se esta mirando a ver si habria algun problema

El preguntar por motor para 2D es mas que nada por sencillez, porque supongo que la diferencia entre crear circulos que se mueven y crear modelos humanos con movimientos creibles es abismal.

Un saludo

#6

Escrito 23 diciembre 2010 - 19:31

¿En que lenguaje lo estais creando?

Si es .net imagino que habra alguna forma de integrar xna en un form, y tambien teneis el modulo gdi que os bastaria para algo taaan simple...

Aunque hablo a ciegas.

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#7

Escrito 23 diciembre 2010 - 19:47

Sinceramente no lo se, el creador del proyecto se ha reservado en exclusiva el tema de programacion y es muy celoso en cuanto a desvelar cualquier cosa relacionada, pero gracias por la sugerencia. A ver que me cuenta google de esos modulos

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#8

Escrito 24 diciembre 2010 - 11:20

Hola Shuko,

Si ya habéis creado parte del juego no te puedes meter en pensar cómo representar los gráficos sin conocer como está programado lo demás, salvo que lo planteéis como un sistema independiente que se comunique con la parte de gestión que ya tenéis hecha (lo cual tendrá sus pros y sus contras)

Si tienes curiosidad por saber cómo está programado, sólo tienes que ver qué librerías has tenido que instalar para poder ejecutarlo o pegarle un vistazo a los ficheros del directorio de instalación del juego.

PD: Por lo pronto lo que mostráis en la Web tiene muy buena pinta, ¿cuánto tiempo lleváis de desarrollo?

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#9

Escrito 24 diciembre 2010 - 13:32

Estaba buscando algo que hiciera algo asi, pero con alguna herramienta un poco decente, mas que el awt de Java que es lo primero que se me vino a la cabeza.

Este seria el pseudocodigo cutre de lo que tendria que hacer (no se tabular en el foro):
[code:1]do{
pintar Campo();
for(jugadores=1;jugadores<=22;jugadores++)
pintarCirculoQueRepresentaAlJugador(x,y);
pintarBalon(x,y);
generarSiguienteEstado();
}while (not partidoAcabado);[/code]

Que poder hacerlo en Java, puedo hacerlo, pero queria algo mas... no se como explicarme, alguna herramienta mas especifica

En cuanto al PD. yo voy a hacer un añito en el proyecto en enero, pero cuando llegue ya llevaba como poco otro año mas

Un saludo

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#10

Escrito 25 diciembre 2010 - 10:13

Bueno Shuko,

Ese pseudocódigo anda un poco cojo de información eh?? :P.

Lo que te quería decir con el otro mensaje es que sin saber cómo está programado lo demás, ¿cómo sabes que datos y propiedades tienes de los jugadores?, tampoco sabes las plantillas que salen al campo ni cómo devolver el resultado del partido o lo que es más importante, cómo están dispuestas las características de los jugadores para que según el nivel que tengan en sus habilidades el partido se desarrolle de una forma u otra.

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#11

Escrito 25 diciembre 2010 - 12:48

Ya he dicho que es cutre, aunque no le falta tanta informacion como pudiera parecer. Al fin y al cabo, este "codigo" iria en una clase dedicada a "pintar" el partido, y toda esa informacion que comentas estaria dentro de "generarSiguienteEstado()", que iria en otra clase diferente (al fin y al cabo, para pintar el estado del campo solo necesitas saber donde esta cada elemento, no como han llegado hasta ahi ni como se moveran, de eso ya se encargara la clase encargada de calcularlo)

De hecho, revisando el pseudocodigo que he puesto lo unico que estaria mal es que el pintarCampo() se puede sacar del bucle y faltarian los metodos para borrar los elementos tras cada iteracion. Piensa en los jugadores como una lista de 22 elementos, alguno de ellos quiza nulo (expulsados, por ejemplo), de los que lo unico que te interesa es donde estan, y aparte otro elemento adicional para el balon (metelo en una lista de 23 si quieres junto a los jugadores, mas simple aun). generarSiguienteEstado() actualiza la posicion de los jugadores tras cada iteracion/pintado. Al fin y al cabo, mi metodo de "pintar" no escribe en esas variables en ningun momento, solo las lee, el que las actualiza (=escribe) es el de generarSiguienteEstado(), y si hay algun problema de concurrencia entre lectura y escritura se soluciona facilmente (aparte de no ser demasiado conflictivo). El resto de elementos son estaticos, asi que no me preocuparia por ellos.

Pero mi problema sigue siendo el mismo. Pintar circulitos con awt (incluso voy a darle otra oportunidad a NetBeans, aunque no nos llevamos bien) es muy sencillo, pero con una herramienta mas especifica deberia resultar facil portarlo a 3D (aunque fuera con cilindros que se mueven, sin entrar en detalles de los jugadores), o simplemente manejarlo. Igual que existen motores especializados en Shooters en primera persona, en RPGs... buscaba alguno especializado en visualizacion de futbol.

Gracias por vuestras ideas

Un saludo

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#12

Escrito 25 diciembre 2010 - 13:36

No te lo tomes a mal Shuko,

Sólo quería decir lo que ya explicas en el siguiente mensaje, vas a tener varias clases participando en el partido (así de forma rápida me vienen a la cabeza Jugador, Árbitro, Balón, Estadio, Partido), cada una con sus propiedades y métodos, y eso es mucha información como para describirla en 10 líneas de código.

Contestando a tu pregunta, no conozco ningún motor especializado en juegos de fútbol. Aquí cada uno barrerá para su terreno, pero por lo aparentemente sencillo que lo pintas yo optaría por XNA, puedes hacerlo 2D y posteriormente no tendrás que cambiar de motor si te decides a pasarlo a 3D, y si ya sabes programar en Java no tendrás ninguna dificultad en hacerlo en C#.

Ahora desviándome hacia el diseño de clases que comentas, te diré que depende mucho de la forma de programar, por ejemplo:
[code:1]for(jugadores=1;jugadores<=22;jugadores++)
pintarCirculoQueRepresentaAlJugador(x,y);[/code]
Personalmente me gustaría más algo así:
[code:1]foreach (Jugador lobjJugador in cListaJugadores)
lobjJugador.Pintar()[/code]

De este modo está más orientado a objetos, es decir, es el jugador quien sabe dónde se tiene que pintar, y no que lo sepa por ejemplo la clase Partido a la que eso en particular no debería preocuparle.

También dices que el pseudocódigo sería un método en una clase dedicada a pintar el partido, y que el método generarSiguienteEstado() iría en otra clase distinta, a mí esto me parece una barbaridad.
Pensado en las clases que te decía antes a mí se me ocurriría que la clase Partido sería el eje del juego, por así decirlo podrías tener el método main ahí, y guardar en Partido como instancias:
- Lista de jugadores
- Balón
- Árbitro
- Estadio
Esta clase podría tener dos métodos "ActualizarEstadoPartido()" y "PintarEstadoPartido()", y en cada uno lo único que se haría sería iterar por los elementos actualizando y pintando respectivamente, y luego cada clase que sepa como se tiene que actualizar y pintar.

Pero vamos, esto seguro de que si cada uno de nosotros se planteara este juego no coincidiríamos de primeras en el diseño de clases jejeje.

Un saludo y suerte con el proyecto!

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#13

Escrito 26 diciembre 2010 - 11:46

A ver, por partes:

- En primer lugar, todos los comentarios son bien recibidos, no me tomo nada a mal. Estoy/estamos aqui para aprender, si me tomara a mal una critica constructiva no tendria sentido seguir aqui. Simplemente explico mi punto de vista. Pido perdon si ha sonado como si estuviera molesto o algo asi

- En segundo lugar, el XNA. Parece que tendre que instalar Visual Studio antes, bueno, en estas fechas tengo mucha comida navideña, a ver si saco un ratillo. Pero lo que he visto tiene buena pinta. Anda mira, me acabo de encontrar un enlace de descarga que ya incluye el Visual Studio 2010 express. No se si sera un trial o la version full, ya lo descubrire.

- En cuanto a la informacion que necesito para representar un partido y donde localizar el metodo para pintar. Bajo mi punto de vista, depende de lo que vaya a pintar. Si cada jugador tiene una representacion propia, esta claro que el metodo pintar iria dentro de la clase jugador. Si todos los jugadores son iguales, podria ir en la de pintarPartido. Aunque pensandolo bien, me gusta mas tu opcion, ya que aunque solo sea pintar un circulito con el numero, ya necesito conocer ese numero y el equipo al que pertenece (para pintarlo de un color u otro). El arbitro de momento no lo representare, asi que no lo necesito. Para crear un visor 2D, no necesito tampoco el estadio, de momento puedo suponer un campo estandar con dimensiones fijas. Todo se ira viendo

- En cuanto a donde debe ir el metodo generarSiguienteEstado(), te explico por que tiene sentido que vaya en una clase aparte. Porque ya existe la generacion de estado siguiente. Teniendo esto en cuenta, las dos opciones que hay son modificar la clase existente o agregar una nueva cuya unica funcionalidad sea pintar el partido. En el fondo, seguramente ambas opciones sean validas, pero normalmente suelo dividir mi codigo en 2 paquetes: uno dedicado a todo lo que son graficos y otro para todas las clases de codigo "puro". Por eso estoy acostumbrado a que lo que sea pintar vaya en una clase aparte. Aunque en el fondo esto es solo cuestion de estetica y poco mas, la idea es crear un metodo nuevo, y ubicarlo en una clase ya existente o en una nueva.

- Por ultimo, cuando dices lo de "se me ocurriría que la clase Partido sería el eje del juego" entiendo que no has jugado al juego o que no te has explicado bien, porque el juego es de gestion, el visualizador este es un complemento secundario.

Ale, no me enrollo mas

Salu2!!

  • deviax

  • Methuselah

  • vida restante: 100%
  • Registrado: 23 mar 2005
  • Mensajes: 182
#14

Escrito 26 diciembre 2010 - 16:13

Hola Shuko,

Nada tio, por mi parte no es necesario ni perdón ni perdonado ;), esto es lo malo de escribir en foros, que no se sabes que tono se está utilizando.

Te cuento:

En segundo lugar, el XNA...

Comprueba lo que comentas de la versión express del Visual Studio, por lo general suelen ser versiones sin límite de tiempo pero con funcionalidad reducida, tal vez para lo que quieres hacer tienes VS de sobra si al final te decidieras por XNA.

En cuanto a la informacion que necesito para representar un partido...

Árbitro y estadio te los comentaba porque a la hora de enfrentar un proyecto hay que pensar en sentar unas bases ampliables, hoy a lo mejor no los necesitas, pero si dentro de dos meses os da por representar los distintos estadios agradecerás no tener que pensar "y ahora cómo meto el estadio en lo que ya tengo", que supondrá modificar la codificación que ya tengáis con el impacto que eso suponga (en rediseño del juego y en tiempo invertido en hacer algo que ya teníais y que funcionaba).

En cuanto a donde debe ir el metodo generarSiguienteEstado()

Esto es de lo que te hablaba en el punto anterior, ahora tienes que plantearte si modificar código o hacer una programación menos "elegante" porque la idea de representar gráficamente el partido no se dejó abierta en su momento.
Es prácticamente imposible caer en todos los detalles de un problema, pero si sabes que eso está ahí y no lo controlas porque le das prioridad a la forma rápida de hacer las cosas en lugar de a representar correctamente el problema (identificar los elementos que participan en el problema y delegar en ellos la lógica que les aplica), más adelante te surgirá el problema de no saber exactamente donde codificar la nueva funcionalidad porque la anterior no contempla todo lo que debería.

Por ultimo, cuando dices...

Lo que quería decir era que el tronco sobre el que podías hacer girar toda la visualización (no la gestión, que eso ya lo tenéis programado), podría ser el partido por ser el denominador común de la parte de visualización (los jugadores, el balón, el resultado actual..., todo está ahí y tiene sentido dentro del partido), pero como dices yo no he visto el juego, y más importante aún, la programación.


Bueno Shuko, no me enrollo más tampoco, espero haberte aportado algo útil aunque sólo sea en la forma de plantear el problema, un saludo.

  • Shuko

  • Humano

  • vida restante: 100%
  • Registrado: 23 dic 2010
  • Mensajes: 9
#15

Escrito 27 diciembre 2010 - 00:05

Desde luego, de una de las cosas que me he dado cuenta a lo largo de los años que llevo en la carrera es de que uno ve las cosas que sabe y no sabe cuando habla sobre ellas. Probablemente este hilo de apenas una pagina me haya resultado mas util que estudiarme un libro de 300 paginas (para lo que quiero, claro :P)

Pues de momento probare con XNA y ya os ire mostrando los resultados que voy obteniendo. Muchas gracias, especialmente a ti, deviax ;)

Un saludo


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
publicidad