Buenas, se me encargo un presupuesto para un juego de autos en 3D para el usuario casual.
La idea es un juego de "paseo en auto" a travez de un recorrido, no hay carrera, cuidado con chocar otros autos, cuidado con chocar gente, no cruzar en rojo.
Y quiero hacer un recuento de la tecnologia a implementar, aun que no estoy seguro de ello, por eso pido una mano.
Supongo:
MD2 / MD3 para autos, gente y vacas creo que estaria bien.
Fisica: Newton o algo artesanal bastará?
No tengo idea:
BSP, octrees o que? Tuneles guiados?
Casi seguro:
Sombras proyectadas como mucho.
Lightmaps.
Que harían ustedes?
Tendria que ser algo que se pueda hacer en 1 mes con 4 horas por dia.
Sin shaders ni mucha menos.
Saludos y muchas gracias.
PD: No, no abandono el DA, el beta final estará listo la semana que viene ;) ... tan solo faltan algunos graficos! que emoción!
Para el mercado casual y con sólo un mes a tiempo parcial, has de tirar a lo más rápido y fácil de implementar, así que ahí va mi (poco autorizada) opinión:
- Modelos MD2, para lo que quieres tienes suficiente y son fáciles de implementar, si has de hacerte tú el motor.
- Física, si quieres un juego tirando a arcade puedes tirar de físicas "made in home", si quieres algo más realista (y complejo) usa newton por ejemplo.
- Para visualización, octrees (o quadtrees).
Por cierto, cómo van a ser los niveles?
Si son pregenerados, puedes usar lightmaps sin problemas, pero si no, tendrías que calcularlos al generarse el mapa. Para los objetos móviles, opción para stencils o directamente proyectarlas sobre el plano, según el equipo del jugador, por ejemplo.
Sobre los niveles, si no los haces pregenerados, una forma fácil de hacerlos es "por cuadrícula", rollo array de toda la vida y arreando. Primero generas las calles, luego vas poniendo distintos edificios donde no haya calle, árboles, etc... Lo más difícil se me antoja los semáforos y controlar a los peatones :ph34r: .
Vas a usar algún motor o vas a hacerlo completamente tú (te aconsejo lo primero si tienes tan poco tiempo).
De hecho me parece muy poco tiempo disponible para un proyecto así.
Depende del nivel de realismo físico que te pidan, puede ser muy complejo.
Yo utilizaría Bounding boxes y octrees y listo. Y respecto a las animaciones, MD2..
Suerte! (ole)
En realidad serán 3 meses, pero siempre te lleva mas ... y seria mientras marketineo al dylo.
Lo de usar un motor que no sea mio seria un inconveniente, creo desde mi ignorancia, pues tendria que aprender a usarlo ... y si me aparece un bug tendria que revisar codigo ajeno (asco) .
La verdad es que me parece que física sera hecha in Home y md2 es mucho mas rapido de implementar también.
Octrees nunca he trabajado ... no se cuanto cueste implementarlo, lo que me iria mas rapido sería un propio mapa del quake 3 ... y tan solo lo cargo :) pero no se si servira para hacer 5 minutos de juego.
Saludos y sigo escuchando opiniones.
Con un mes yo no pensaría demasiado en las cosas que pones, cogería un motor que te permita funcionar rápido ya sea del tipo blitz, fenix o similar o del lado de ogre, soya o similar. Está claro que en 3 meses con 4 horas/día no te da tiempo ni a empezar un motor.
Resulta curioso que lo primero que pienses sea el formato de fichero de los modelos 3D, la forma de particionar el espacio y el modo de iluminar. Yo sería en lo último que pensaría.
Creo recordar que hay un motor open source exclusivo para juegos de coches, con IA, fisica, modelos 3ds. Ahora no recuerdo el nombre. A ver si cuando llegue a casa te lo puedo poner para que le eches un vistazo.
Con el tiempo que tienes centrate en el juego, lo de usar un motor externo, si no lo conoces te va a consumir tiempo el saber como exportar modelos, acostumbrarte a trabajar con él...
Yo veo dos posibilidades:
-Utilizar tu motor y meter lo que te falte, siempre buscando el sistema que sea mas rapido de implementar.
-Utilizar un motor de terceros que sea muy sencillo de utilizar. Por ejemplo el irrlicht en una tarde sabes utilizarlo y tiene todo lo que necesitas. Torque encima tiene fisicas de vehiculos y podrias meter terrenos y editar los niveles con su editor ingame, pero su curva de aprendizaje es mucho mayor. Los blitz3d y similares los descarto por que obligan a utilizar otros lenguajes. El game studio esta bien, pero lo mismo, necesitas echarle un rato para enterarte de cada cosa, y es algo caro en comparacion.
En cuanto a tus dudas:
-Cualquier formato de modelos que soporte lo que vaya a usar el grafista esta bien.
-El sistema de oclusion lo elegiria segun el tipo de escenario, si por ejemplo es una pista lineal (no literalmente, si no que son tramos que recorres de forma lineal, como cualquier juego de carreras), puedes dividir el decorado en trozos (imagina las partes de un scalextric) y pintar el actual y adyacentes. Ejemplos de BSP, quadtree, octree.. los hay a patadas, en cualquier caso.
Pero si dices que tienes un cargador de BSPs del quake 3, vete de cabeza a eso. Puedes modelar perfectamente un escenario con eso. El unico problema que veo es que por lo que se, el compilador de bsp de quake3 requiere una licencia para utilizarlo con fines comerciales.
-Usar un engine de fisicas suena bastante bien, pero lleva su tiempo ajustar los parametros para que funcionen de la forma que esperas, y no causen bugs. Yo te recomiendo newton o tokamak, que son los mas sencillos que recuerde de implementar. Si tuvieses tiempo, ODE, pero mejor olvidate esta vez. Por lo que cuentas, si el coche no va a derrapar ni caerse por sitios, igual con hacerte la fisica y colisiones por tu cuenta acabas antes.
Suerte. (ole)
pd. el motor al que se refiere Marci creo que es el
http://www.3impact.com/ aunque este es de pago.
Descarta ODE, te lo recomiendo. Es muy difícil ajustar los parámetros, varía muchas cosas en función de muchas cosas, a veces es tedioso de programar, si no andas con cuidado se producen inestabilidades, etc, etc.
Ya encontre el motor:
http://rars.sourceforge.net/Como te decia es open source, está programado en C++ y los modelos son 3ds. Está orientado para carreras pero como pudes programar individualmente la inteligencia y el comportamiento de cada coche supongo que podras solucionarlo facilmente. Si puedes conseguir la revista software 2.0 nº2 del 2005 "Programacion de juegos" te viene un buen articulo
Cita de: "ethernet"Resulta curioso que lo primero que pienses sea el formato de fichero de los modelos 3D, la forma de particionar el espacio y el modo de iluminar. Yo sería en lo último que pensaría.
Ethy: Y en que deberia pensar? Tal vez me estoy perdiendo de algo ...
Saludos.
Edit: no es que quiero ser irrespetuoso, sino que es la primera vez que hago un presupuesto y no tengo idea.
Cita de: "Pogacha"Cita de: "ethernet"Resulta curioso que lo primero que pienses sea el formato de fichero de los modelos 3D, la forma de particionar el espacio y el modo de iluminar. Yo sería en lo último que pensaría.
Ethy: Y en que deberia pensar? Tal vez me estoy perdiendo de algo ...
Saludos.
Edit: no es que quiero ser irrespetuoso, sino que es la primera vez que hago un presupuesto y no tengo idea.
Me refiero que la forma en la que pienso yo es al revés: comienzo con el juego y si necesito un octree o similar lo incluyo. Por ejemplo en makefight no hay nada que calcule lo que es visible y lo que no porque realmente no es necesario, cualquier tarjeta es capaz de mover todo el escenario. Es posible que programando un sistema de visbilidad el juego mejorara en rendimiento, pero desde luego no es rentable en cuanto a tiempo.
De todas es una opinón personal y seguro que no es ni de lejos la mejor. En general yo no soy partidario de la tecnología por la tecnología, cuando el juego lo requiera ya aprenderás, usarás y programarás un octree/quadtree/colisiones/físicas/etc, en pocas palabras, soy partidario de hacer un motor para un juego y no un motor para un supuesto juego, con todo el respeto a quienes hacen motores.
OK ... entiendo lo que dices.
Mas que nada en este caso, la logica del juego es muy sencilla, muy muy sencilla y por eso el problema radicaba en ver que implementasiones habria que hacer para tener un producto.
Me entreviste ayer a la noche ... bueno, cuento el resultado para que quede como anecdotico:
La verdad es que no sabian lo que querian, tampoco tenian idea de nada sobre juegos, eran gente de cine. Pasé un presupuesto y les gusto el numero pero no querían ver un detalle de todas las cosas que habia que hacer. Obviamente no sabian nada del desarrollo de juegos, podian distinguir entre artistas y programadores pero tan solo eso.
No sabian a quien iban a venderselo ( lo cual no es mi problema, pero me extraño por demas y les di orientación ).
Habian ideado un gameplay terriblemente malo, el cual se los correjí sugerencialmente ( siempre teniendo la delicadeza y suavidad para no resultar pedante ni nada por el estilo ).
Como muestras de trabajo les mostre el Dylo, el cual no supieron apreciar, les mostre luego el engine2 y les tampoco lo pudieron apreciar aun que los hiso acercarce al monitor. ERROR, La proxima vez tener un juego 3d para mostrar que sea corto y muestre muchas cosas.
Al final terminaron pidiendome que les muestre como se vería el juego terminado :blink:, o que se los muestre la semana que viene, no pudieron entender de que por mas que programe todo, haría falta el trabajo de los artistas también para hacer una simulación del juego.
Se fueron igual que como vinieron, así que no se que impresion tuvieron.
En definitiva no creo que me convenga trabajar con esta gente, no sé en este rubro, pero en otros me ha pasado demasiado que cuando no saben lo que quieren nunca quedan conformes con nada y o no te pagan o terminan hablando mal de uno.
Yo no estoy como para elejir mucho tampoco :P , la verdad es que me gustaria que quien tenga experiencia me comentara que tipos de clientes se han encontrado y que resultados ha tenido.
Saludos y muchas gracias a todos.
Puf... clientes que no saben lo que quieren y experimentan con uno.. hag!
Lo mejor es que les muestres algun juego que haya dando vueltas por ahi y les digas que va a quedar algo "parecido" a eso. Y luego presupuestar todo AL DETALLE...
sigue con tu Dyldo :)
y si quieres presentar cosas a la gente olvidate de programar, ellos quieren una imagen visual, nunca apreciaran la calidad de tus algoritmos de oclusion, ni la finura con la que carga los modelos.
Si te pasa otra vez mete todo a saco, con los mejores graficos que puedas, y cuando se cuaje les dice que el codigo esta en pruebas.
mi opinion de persona impresentable :P
Efectivamente la gente ajena al mundillo se cree que hacer juegos es practicamente como jugarlos, todo diversion y por supuesto en una tarde te haces un juego enterito.
Si pagan bien hazlo, pero si ves que piensan pagar poco o te ratean, es mejor que lo dejes, no hay nada peor que un cliente que piensa que le "estafas" y encima no sabe ni lo que quiere, te tendra rehaciendo trabajo hasta el fin de los dias.
Todo lo que acordeis por escrito, incluidas fechas, es mejor no pillarse y que haya un papel que demuestre quien tiene razon cuando las cosas se pongan feas. El cliente no busca la logica, busca un juego de los que venden en las tiendas pagando practicamente lo que cuesta comprarlo. No se paran a pensar que un juego lo hacen 50 personas, o que los 50 euros que le cuesta a él no paga ni los sueldos de esa gente :P
En mi experiencia, dedica todo tu tiempo a hacer las partes visuales, lo que pueda entender el cliente. Como dice er willy no tiene sentido hacer codigo limpio, con algoritmos super currados, etc etc, si esta gente no lo aprecia. El esfuerzo debe ir con cuentagotas, reutiliza todo lo que puedas y tira de librerias modelos etc de terceros siempre que sea posible porque con el presupuesto, ¡te saldras de tiempos!
Un ultimo consejo, cuando hables con ellos, ponles ejemplos utilizando el cine. Seguro que entienden mejor que una pelicula no se hace en un dia, que el presupuesto no da ni para hacer un corto, y que la pelicula no es solo los dos actores que salen, que detras de la camara hay un equipo y un trabajo grande.
Suerte. (ole)
Muy buenos consejos, no me di cuenta que cometeria tantos errores.
La verdad es que debí pedir consejo sobre esto, pero ya es sonar desesperante decir ¡¿QUE HAGO?!
Bueno al menos acumulo experiencia.
Voy a tratar de aprender a usar el Irrlich y hacer algo para tener de muestra en otros casos.
Muchas gracias y saludos.
Citary si quieres presentar cosas a la gente olvidate de programar, ellos quieren una imagen visual, nunca apreciaran la calidad de tus algoritmos de oclusion, ni la finura con la que carga los modelos
Cuando estuve desarrollando wic messenger eso es lo que pasaba exactamente, les importaba un carajo que el codigo fuera lento, que estuviera guarro, etc. lo que les importaba era una aplicacion lista para venderse, asi estuvo en sus primeras versiones que eran todo bugs, hasta que tuve tiempo para limpiar y remodelar.
Hmmmm viendo el percal yo pasaría bastante de esa gente. Si no tienen claro que un juego no se hace en 2 tardes todo van a ser presiones, cambios y malentendidos.
De todos modos, puede ser una buena idea que mientras das los últimos retoques al DA ( (ole) ) vayas aprendiendo a usar algún motor sencillo (como el Irrlicht que has dicho ya) y te prepares algunas demos sencillas pero vistosas para poder mostrar en el futuro.
Por cierto, échale un ojo al Torque (aunque es de pago). Viene con un Starter Kit para juegos de coches, puedes bajarte una TechDemo donde hay un mini-ejemplo.
Hola Gente,
Estoy usando el torque para hacer un juego de bicicletas y la verdad que estoy un poco harto de pensar en soluciones para hacer unos simples adelantamientos de un rival con otro sin chocarse.
¿Me podeis ayudar?
Gracias de antemano.
chonli: bienvenido a los foros!
Pues de primeras se me ocurre que compruebes si el que va detrás va a chocarse con el que quiere adelantar. Si es así, varíale el vector de movimiento para que avance en diagonal al que quiere adelantar, de ese modo pasara por su lado. Otra opción es que cuando aún esté detrás se ponga un poco a algún lado del otro corredor, y luego adelantar en línea recta.
Seguro que todo esto ya lo habías pensado, pero ahí queda. Por cierto para estas cosas es mejor crear un nuevo hilo explicando el problema, aunque puede que la información le sirva tb a pogacha para los coches.
Saludos!
Gracias por los consejos ;) ... ya me doy un panorama.
@chonli:
Una solucion muy buena puede usar un elipsoide orientado de colision entonces cuando se acerquen automaticamente se separaran de la forma mas adecuada siempre manteniendo la distancia ...
Saludos.