Buen, mientras mi juego "Marcianitos" está en fase de testeos varios, e comenzado un proyecto de estrategia en tiempo real (como ya sabréis algunos).
La idea del proyecto es:
- Hacer un juego multijugador (empleando Bennuplaynet) en el que se enfrenten hasta 8 jugadores en un mapa de 6000x6000 (igual cambio el tamaño).
- Que durante el juego puedan crear unidades de tres tipos: guerreras, constructoras y de transporte.
- Que para crearlas, tengan que construir edificios inmóviles.
- Que tengan que cojer recursos.
- Que se puedan atacar entre ellos.
- Que te puedas desplazar por el scroll con el raton, y al marcar un punto en el mapa marque las coordenadas del scroll, no de la pantalla.
Problemas que tengo:
- Desarrollar un mapa de tiles que me permita hacer campos de batalla de un tamaño aceptable.
- Que la cola de producción se inicie sin tener que seleccionar el edificio.
Si asigno al puntero la capacidad de desplazar el scroll y le pongo el ctype necesario para ir por el scroll, como coje las coordenadas del mouse, nunca se mueve del mismo cuadrado (0,0) (640,480). Pero si le asigno el ctype para que se mueva por la pantalla, las coordenadas que da todo el rato están entre (0,0) y (640,480), y por tanto las naves sólo se desplazan por ahi.
El eterno problema de obtener la facción de la nave a la que he hecho click derecho.[url] (http://server16.kproxy.com/servlet/redirect.srv/slxv/smqfzasq/sdmkia/p1/index.php?topic=1844.msg32424#msg32424)
Ahora mismo, he estado codificando la cola de producción. Tiene dos cachos. Por un lado, he declarado la estructura Colt en las globales:
global
int fpgs[3]; // Gráficos
puntero ppunt; // ID del Puntero
int puni[2]; //ID de las unidades
////Estructura de la cola de producción////////////////////////////////////////////////////////
struct colt
bool oc; // Marca si esa casilla de la cola está ocupada o libre;
int xp; // X donde aparecerá el producto;
int yp; // Y donde aparecerá el producto;
int tmpP; // Tiempo que tarda el producto en producirse;
end
///////////////////////////////////////////////////////////////////////////////////////////////
end Y por otro lado tengo la cola de producción:
process cola(lim)
public
colt produccion[lim];
end
private
int i;
colt prodaux;
end
begin
for(i=0; i<lim;i++)
produccion[i].oc=false;
end
loop
if(produccion[0].oc!=false)
prodaux=producto[0];
for(i=0;i<lim;i++)
if(producto[i+1].oc!=false)
producto[i]=producto[i+1];
end
end
produto[lim-1].oc=false;
for(i=0;i>prodaux.tmp;i++)
frame;
end
// Llamamos al gestor de llamadas;
end
frame;
end
endNo he podido probarlo, pero ¿veis algo que pueda hacer que no funcione o que no haga lo que quiero?
Gran proyecto, perseverancia++!!
Gracias por los ánimos. A ver si consigo dejar de tener errores chungos que no se resolver... xD
Salvo por los errores tipográficos, como los dos for que no se ven bien y el campo tmpP que no llamaste igual en el if, la lógica del código se ve correcta para lo que quieres realizar.
Muchas gracias por el apoyo DCelso.
Ni que decir tiene que aparecerás en los créditos xD
______________________________________________________________________________
Al final, la cola de producción se ha quedado así:
process cola(lim)
public
////Estructura de la cola de producción////////////////////////////////////////////////////////
struct producto[10]
bool oc; // Marca si esa casilla de la cola está ocupada o libre;
int xp; // X donde aparecerá el producto;
int yp; // Y donde aparecerá el producto;
int tmpP; // Tiempo que tarda el producto en producirse;
int prod; //Producto a producir;
int tipo; //Tipo de producto a producir;
end
///////////////////////////////////////////////////////////////////////////////////////////////
end
private
int i;
struct prodaux
int xp; // X donde aparecerá el producto;
int yp; // Y donde aparecerá el producto;
int tmpP; // Tiempo que tarda el producto en producirse;
int prod; //Producto a producir;
int tipo; //Tipo de producto a producir;
end
end
begin
for(i=0;i < lim ; i + + )
producto[i].oc=false;
end
loop
if(producto[0].oc!=false)
prodaux.xp=producto[0].xp;
prodaux.yp=producto[0].yp;
prodaux.tmpP=producto[0].tmpP;
prodaux.prod=producto[0].prod;
prodaux.tipo=producto[0].tipo;
for(i=0;i < lim;i++)
if(producto[i+1].oc!=false)
producto[i].oc=producto[i+1].oc;
producto[i].xp=producto[i+1].xp;
producto[i].yp=producto[i+1].yp;
producto[i].tmpP=producto[i+1].tmpP;
producto[i].prod=producto[i+1].prod;
producto[i].tipo=producto[i+1].tipo;
else
producto[i].oc=false;
end
end
producto[lim-1].oc=false;
write_var(0,320,270,3,i);
for(i=0;i<prodaux.tmpP;i++)
frame;
end
gestorllamadas(prodaux.tipo,prodaux.prod,prodaux.xp,prodaux.yp,0,faction_jug);
end
frame;
end
end
Además, he creado un gestor de llamadas, de forma que si le paso el tipo de unidad, el tipo de producto, sus coordenadas, su ángulo y su facción, puedo generar automáticamente cualquier cosa (unidades, edificios,etc...) de cualquier jugador con la misma función:
process gestorllamadas(int tipo,int prod,x,y,angle,int fact)
begin
switch(tipo)
case 1:
end
case 2:
end
case 3:
guerrero(prod,x,y,angle,fact);
end
case 4:
end
case 5:
end
end
end
Te recomiendo que cuando hagas esa función "universal", definas antes mediante constantes los números que representarán las unidades y/o edificios, para que te sea mucho más fácil saber que vas a construir con las llamadas a esa función, especialmente cuando el código crece mucho.
Está definido xD
Por un lado, tengo estas variables globales:
struct guer[]
string nombre;
int vida;
int grafini;
int veloc;
int retardo;
int daño;
end
struct edif[]
string nombre;
int vida;
int graf;
int tipo;
int cantp;
int producs[2];
int tmppr;
int limitp;
endTodavía no está definida la capacidad de la array, porque la iré aumentando a medida que haga unidades y edificios.
Y por otro lado, tengo este fichero:
Quote from: unidadesdb.prgguer[0].nombre="Crucero de batalla";
guer[0].vida=200;
guer[0].grafini=1;
guer[0].veloc=2;
guer[0].retardo=4;
guer[0].daño=10;
guer[1].nombre="Goliath";
guer[1].vida=50;
guer[1].grafini=9;
guer[1].veloc=3;
guer[1].retardo=2;
guer[1].daño=3;
edif[0].nombre="Cuartel";
edif[0].vida=2000;
edif[0].graf=100;
edif[0].tipo=3;
edif[0].cantp=2;
edif[0].producs[0]=0;
edif[0].producs[1]=1;
edif[0].tmppr=1000;
edif[0].limitp=5;
Esas cosas, las tengo muy bien pensadas.
Te recomiendo que use type en vez de una estructura,ya que con type puedes instanciarlas tantas como edificios y enemigos necesites,asi obligatoriamente tienes que asignar las dimensiones,y puede que no te haga falta dentro del juego usar todas.Me explico :
struct guer[100]
............... resto del codigo
end
asi solo puedes tener 100 guerreros pero puede que al final no de tiempo a crear mas de 60,con lo que estas despediciando memoria que la puedes reserbar para musica,efectos,graficos,ect.
Con type lo puedes instanciar como se intancia los objetos en java,te digo esto porque creo recordad que dijiste que sabias java.
_guer guerrero
- ; asi lo instanciarias, por ejemplo.
Esque... croe que no has entendido como funciona. Es algo asi como una bd. Es una array con esa estructura que guarda la información de el producto nave de batalla, goliath, etc...
de forma que, cuando instancio una unidad nueva, le paso de qué tipo es, y coje de ahí su vida, sus armas, su nombre, etc...
Ah vale no me fije en la parte de abajo,te lei que lo tenias como variables globales :P,ya veo lo que quieres hacer.
Bueno, ahora tengo un pequeño problema que no se me ocurre cómo resolver.
Por un lado, teniendo en cuenta que la resolución es de 800x600, de cuánto pondríais el mapa? 6000x6000?? Eso no ralentizará mucho un ordenador?
Por otro lado:
¿Alguna idea de cómo hacer el minimapa? Porque no se me ocurre ninguna forma.
En teoría, el mapa da igual el tamaño que tenga, ya que el blit se encarga de dibujar sólo la parte que interese. La pega puede venir por la memoria disponible, ya que un mapa de 6000x6000 ocuparía unos 6000x6000 bytes en formato 256 colores (unos 36MB), el doble si es en 16bits.
En este caso es casi mejor recurrir a un mapa de tiles, como toda la vida de dios, pero hay que trabajar el scroll de tiles.
Otra intermedia sería dividir el mapa en trozos más pequeños (no sé ¿1600x1200?) y usar las funciones de carga en background y diversos procesos para moverlos, es mucho más simple, pero hay que controlar muy bien cuándo se carga y se descarga cada mapa.
El minimapa no tienes más remedio que dibujarlo aparte y usar una región exclusivamente para él. Si lo quieres de forma redonda, tendrás que dibujar sobre un mapa y aplicarle una máscara para eliminar lo que sobra a cada frame (y eso sí que puede ralentizar el juego, aunque en un PC, lo dudo, tendría que tener sus buenos años ya).
No entiendo eso de los mapas de tiles. xD
Quote from: Drumpi on January 05, 2011, 05:48:06 PM
En teoría, el mapa da igual el tamaño que tenga, ya que el blit se encarga de dibujar sólo la parte que interese. La pega puede venir por la memoria disponible, ya que un mapa de 6000x6000 ocuparía unos 6000x6000 bytes en formato 256 colores (unos 36MB), el doble si es en 16bits.
En este caso es casi mejor recurrir a un mapa de tiles, como toda la vida de dios, pero hay que trabajar el scroll de tiles.
Otra intermedia sería dividir el mapa en trozos más pequeños (no sé ¿1600x1200?) y usar las funciones de carga en background y diversos procesos para moverlos, es mucho más simple, pero hay que controlar muy bien cuándo se carga y se descarga cada mapa.
El minimapa no tienes más remedio que dibujarlo aparte y usar una región exclusivamente para él. Si lo quieres de forma redonda, tendrás que dibujar sobre un mapa y aplicarle una máscara para eliminar lo que sobra a cada frame (y eso sí que puede ralentizar el juego, aunque en un PC, lo dudo, tendría que tener sus buenos años ya).
Cuando el fondo de scroll era un mapa de 640x3000 px Free me dijo que en las portátiles andaba el juego a menos fps que cuando lo cambié a varias imagenes de 640x480 c/u. Parece que a las pequeñas les cuesta mover un mapa muy grande, no solo en cuanto a ram.
Quote from: yawin on January 05, 2011, 07:14:30 PM
No entiendo eso de los mapas de tiles. xD
Es armar mapas en base a baldosas o tiles. Imaginate un rompecabezas de piezas cuadradas. La gracia es que permite ahorrar memoria, ya que con pocas imagenes pequeñas puedes armar grandes mapas. El punto en contra es que requiere más planeamiento y programación para hacerlo funcionar. Y en el caso de bennu, si haces cada baldosa como un proceso, entonces pedirá más poder de cpu.
No a ver, sé lo que es. Lo que no entiendo es cómo va.
Yo de buenas a primeras me lo armaría con una matriz y cada casilla representaría un tile. Pero Drumpi que tiene armado un motor de scroll tileado debe saber de sobra un funcionamiento de ese estilo.
Hay varias formas de crear un motor tileado: puedes usar un proceso por cada tile, un proceso por cada posición de la pantalla, pintar los tiles sobre un mapa, etc. Luego es sólo tener control de esos procesos/mapa en función de la posición de la cámara.
De momento he comprobado que el usar un proceso por tile en pantalla no vacío es lo más rápido en cuestión de rendimiento, frente a redibujar un mapa del tamaño de la pantalla o a tener un array de procesos que ocupen la pantalla (aunque estoy trabajando en otra versión que debería ser más rápida en movimientos pequeños).
Cuesta un poco hacer estos motores, pero no es tan difícil una vez que lo tienes todo planteado sobre el papel, lo complicado es buscar la manera de optimizarlo.
El mio está disponible si te apetece, aunque a la wiz se le atraganta un poco si cubres más de la mitad de la pantalla con tiles de 16x16 (según Splinter son tiles muy pequeños). Sólo admite formatos que he creado yo (hay un editor para ello) pero se puede arreglar para que cargue el que tu quieras.
Es una de las cosas pendientes, un módulo de scroll tileado, lo tengo en la pila de proyectos, si no se me adelanta nadie con más conocimientos que yo.
Creo que ya he entendido la idea del mapa de tiles, pero no entiendo cómo habría que hacerlo, porque si hago un proceso para cada cuadrado de mapa... son muchos procesos no??
Sí, claro que son muchos, por eso, primero, necesitas guardar en memoria un array bidimensional (tridimensional si vas a poner varios planos... o varios bidimensionales) con los datos de qué tile va en cada posición.
Después tienes que usar un proceso por cada tile que se muestre en pantalla. La parte más difícil es gestionar cuando crear y destruir los tiles, y hay diversas formas de hacerlo, pero siempre has de estar pendiente de las coordenadas de la cámara.
Otra forma más sencilla es tener un mapa del tamaño de la región y usar funciones PUT para ir pintando los tiles sobre el mismo, pero hay que optimizar mucho, porque pintar un mapa entero a cada frame pide mucha máquina (en GP2X es inviable).
De todas formas, creo que hay tres motores de scroll tileado ya publicados en el foro, por si no te ves capaz de crearlo. Ya sólo nos queda crear un módulo para ello ^^U
Quote from: Drumpi on January 12, 2011, 02:15:46 PMDe todas formas, creo que hay tres motores de scroll tileado ya publicados en el foro, por si no te ves capaz de crearlo.
Les echaré un vistazo.
Quote from: Drumpi on January 12, 2011, 02:15:46 PMYa sólo nos queda crear un módulo para ello ^^U
Esa es la mejor idea que he visto en mucho tiempo xD
Gracias por la ayuda.Creo que te mereces un karma ^__^
Ya tienes el mod_mappy que te lo permite...
:D, asias free, por la publi :D.
De todas formas mod mappy está un poco verde, se le pueden hacer bastantes mejoras para su integración con bennu :'(
Le echaré un vistazo al mod_mappy, pero aviso desde ya que lo mas probable es que os cosa a preguntas xD
Dispara a DCElso ;D
¿Mod_mappy no servía sólo para cargar en memoria los mapas de tiles en el formato propio de Mappy? ¿Tambien muestra el mapa por pantalla?
La verdad, estoy estancado en este proyecto. Me decís que necesito un mapa de tiles, pero esque no se cómo hacer eso xD
Intenté usar el mod_mappy, pero no entendí ni para qué servía . A ver si me centro y encuentro algo que me ayude.
Yo tampoco se usarlo, DCElso que te ayude.
en el bennupack hay ejemplos de tiles
Durante esta mañana. Poco después de poner el mensaje anterior, he decidido montarme yo el motor xD he diseñado este "esquema" el cual seguro que tiene fallos de planteamiento serios, pero... ¿os convence?
Por si te sirve de algo, yo tengo mi motor de scroll tileado disponible para su uso:
http://drumpi.se32.com/cosas/scrolltileado_v1.3.zip
Viene la documentación de uso en una carpeta y varios ejemplos.
El formato de los ficheros de mapas de tiles también viene, pero no el editor. Para esto:
1- Puedes crearte tu propia herramienta.
2- Te puedo empaquetar una versión funcional (pero no óptima) de mi editor.
3- Puedes crearte tu propio fichero de carga para el formato de tu elección.
4- Usar el formato TMG, que no es más que un FPG en el que cada mapa es una capa, y cada pixel es un tile.
Nota mental 1: debo crearme la web para dejar estas cosillas más a mano.
Nota mental 2: debo ponerme de una vez con el nuevo editor ^^U
Muchas gracias, le voy a echar un vistazo. Estaba pensando en que los trozos del mapa fuesen imágenes guardadas en un fpg.
Igual primero me animo a intentar hacer el mio, y luego miro el tuyo. xD
Obviamente necesitas un fichero (FPG) con las imágenes (los tiles) y otro con el mapa de tiles... a menos que estés hablando en dividir un mapa grande en trozos, entonces no encajaría con la definición de "tiles".
Ya me contarás qué método has usado ;)
Bueno, os presento una versión Alpha del motor de tiles que estoy haciendo. La verdad es que lo he hecho en 2 horas. Pero, aunque tiene muchas cosas para pulirse, estoy orgulloso de su rendimiento. Maneja un mapa con un total de 999x999 cuadraditos de 32x24 con una fluidez asombrosa.
He decidido, que voy a pulirlo lo suficiente como para conseguir que sea un motor, o al menos un "motor".
Source:
Si no lo he entendido mal, generas un mapa de tiles en memoria de 999x999, y luego un array de 25x25 procesos tile que no se mueven, sólo cambian de gráfico ¿no?
Bueno, es un sistema muy simple y funcional, ya lo irás mejorando con el tiempo ;)
Por ejemplo, podrías usar punteros en lugar de un array fijo para guardar los datos, o eliminar el scroll, ya que no lo usas (podrías haber utilizado dos variables globales nuevas en lugar de x0 e y0 del scroll).
El scroll está por el echo de que los personajes y npcs estarán pintados bajo ese scroll. A parte, calculo qué tengo que pintar en función de Scroll[0].x0
Luego pasaré a scroll[0].camera (o como sea) el id del mouse y voilá xD
La idea es que en una array cargo el mapa. Y en otra guardo el id de cada cuadrado de la pantalla. Igual podría eliminar esa array ya que no le doy mucha utilidad. Pero demomento la tengo ya que es posible que más adelante le de utilidad.
Edit: Vale, sí, la array de 25x25 la quito.
Drumpi, tu ¿scroll tileado está en fenix? Es que no me va. :'(
Me dice:
D:\Bennu Ejemplos\scrolltileado_v1.3\load_tmap.inc:28: error: Unknown identifier
, found "O_READ"
...intentando compilar los 'temp.prg'.
Obviamente, cuando lo hice, pensaba en Fenix (aun no estaba metido de lleno en Bennu), pero eso se arregla con un fichero bgdc.import.
Como de todas maneras se iba a tener que crear uno (y que sería distinto para cada juego) pues no lo metí, pero te aseguro que el motor funciona 100% en Fenix y en Bennu ;)
Pero vamos, para las pruebas, si tienes un fichero estandar con todas las librerías, te sirve.
Fale.
Gracias Drumpi. :-*
Nueva actualización. Con dos funciones nuevas:
-void savemap(string path);
-void loadmap(string path);
Una sirve para guardar el mapa y otro para cargar el mapa.
Adjunto el .rar
Interesante, se puede guardar el estado de los tiles, no lo había pensado pero así es facilísimo poder tener tiles destructibles y guardar/cargar como si nada :D
¿Qué es lo que hacíais entonces vosotros?
Edit: El echo de tener en ram una array con todos los tiles, se me ocurrió en parte porque no se me ocurrió usar ficheros hasta que implementé las funciones de log. Viendo el log se me ocurrió que como guardo el log, puedo guardar y cargar la array en un fichero.
Os presento un editor de mapas para mi motor en el que llevo trabajando estos últimos dos días. Los iré desarrollando a la vez, ya que a medida que vaya ampliando las funcionalidades de mi motor y rediseñando la estructura de los mapas necesitaré adaptar mi editor a ello.
http://www.pensarescompartir.com/lahsoft/lahsoftcorp/?direc=fenix/&id=Editor%20de%20chunks.rar
Esta es la versión preliminar. Como el diseño de interfaces se me da como el culo, lo he preparado para que cualquiera pueda cambiar tanto las fuentes como los fpg en cualquier momento. Incluso mientras se está ejecutando.
Notas:
WASD - Para desplazarse por el mapa.
F5 - Para generar un mapa en blanco.
F6 - Para generar un mapa aleatorio.
F9 - Para cargar un paquete de texturas.
F10 - Para cargar el otro paquete.
Para guardar o cargar el mapa, sólo tenéis que escribir su nombre. Sin extensión y sin path (de hecho sólo podréis escribir caracteres alfanuméricos xD).
Edit: Capturas de pantalla
(http://img862.imageshack.us/img862/9599/screen1.png)
(http://img852.imageshack.us/img852/2710/screen2x.png)
(http://img854.imageshack.us/img854/4199/screen3c.png)
(http://img849.imageshack.us/img849/8496/screen4.png)
capturas por favor
Editado el post anterior con prints
muchas gracias, karma!
Cuando lo probéis decidme eh??, que estoy ya avanzándolo xD
aunque tengo problemas con un botón que acabo de poner que activa/desactiva el modo FULLSCREEN. Luego en casa os saco un video de demostración.
Yo te doy mi karma, pero...
No me entero.
Esto es un editor de mapa de tiles, sobreentiendo que: ¿los cuadros de colores son tiles?
¿Soy yo el que tiene que cambiar esos cuadro de colores por tiles?
¿Que va a generar al final?
¿Un mapa de tiles que se deberá de tratar con tu rutinas?
¿Se podrá definir el tamaño del mapa/tiles?
Perdón por la ignorancia. :D Voy a releer el hilo otra vez.
No, a ver, tu tienes cargado un fpg con todos los gráficos necesarios. Tantos los de interfaz como los del mapa. Tienes espacio para 799 tiles diferentes.
Esos colores, es porque no se diseñar gráficos, ais que las pruebas las hago con 6 colores. En la parte de abajo, te salen los gráficos. Mira, esta es una versión preparada para unos no-iniciados que me ayudan a encontrar bugs:
http://www.pensarescompartir.com/lahsoft/lahsoftcorp/?direc=fenix/&id=Editor_de_chunks_(noobs_mode).rar
Creo que lo entenderás más. xD
edit: Cuando se me ocurra cómo, haré que puedas decidir el tamaño del mapa, pero... puf, lo que no quiero es llenar el programa de parches rancios. Quiero hacerlo sólido. Asi que eso será de lo que más tarde.
Sí, genera un fichero .yaw (xD) que guarda la información de forma que mi motor lo entiende.
Fale, ya lo voy cogiendo.
Estos tiles, se entienden mejor que los cuadraditos de colores. ;D
Ideas y sugerencias.
Zoom, plis.
Barras de scroll y minimapa, para ver por donde ando.
Posibilidad de elegir el tamaño de la ventana. (Trabajo en un portátil de 10" y se me sale).
A veces se pintan dos tiles, sobre todo si el cursor está en el filo.
Poder borrar el tile con el otro botón del ratón.
Me está picando esto de los tiles. ;D
Bueno, lo del zoom lo iré mirando.
Las barras de scroll y y el minimapa, no se ni cómo empezarlo.
Y lo de borrar los tiles, para qué, si el mapa tiene que tener gráficos en todos los chunks. xD
Quote from: yawin on March 11, 2011, 02:56:59 PM
Y lo de borrar los tiles, para qué, si el mapa tiene que tener gráficos en todos los chunks. xD
Venga hombre. Haz uno que sirva para todos. :D
Aunque este todo lleno, me gusta el cuadrado blaco como representación de que no hay.
Me está entrando una picazón en el cogote y no sé si es tanto oir últimamente el tema de tiles y de editores o porque me ha picado una araña ;D
a ver si te vas a convertir en spiderdrumpi :D.
pos te estará entrando un picazón, pero me siento orgulloso de poder decir que no estoy empleando ninguno de tus códigos ni tan siquiera tus ideas (perdí lo que me descarué y me da pereza bajarlos de nuevo xD).
Me siento orgulloso de, por fín, se capaz de hacer algo chulo yo solito (aunque con alguna ayuda xD).
Jajaja, tranqui, Yawin, te entiendo, en ese aspecto soy igual que tú: las cosas hay que hacerlas uno mismo y pedir ayuda en caso de desesperación o atasco mental ;D
Eso te lo puede contar Splinter :D :D :D