starcraft - Page 2

c'est vrai que Starcraft, intuitivement on préférerait jouer contre un adversaire sur une autre calc, mais gérer le link correctement c'est pas évident non plus.
A mon humbla avis, il faut les deux possibilité:
calc vs human
human vs human
et aussi pkoi pas
calv vs calc ( pour voir quel algo d'ia est le meilleur )
cela etant dit ca reste un très gros projet et je vous souhaite de réussir.
Bon courage

-

tu peux transférer juste les coord des unités qui ont bougé non ?
( bon je sais, elles bougent presque toutes à chaque fois mais bon... )
le plus chaud à mon avis c'est l'ia qui doit logiquement être différente pour chaque type d'unité...
et puis un bon moteur de rendue graphique en 4nvg...
à mon avis faudrait faire ca en ASM plutot qu'en C non ?

-

certes...
mais en C aussi faudrait être sacrément balaise non ?
et puis y vous faut des bon grapheurs pour que ca sorte bien
vous faites des sprites de combien ?

-

c chaud à convertir.
t'a vu la taille des sprite pc ?
si on les reduits ca va etre tout caca non ?
et puis les eclaircir c pas un probleme par contre

pour les sprites c moi qui m'en occupe et ça s'annonce bien... bien sur il va falloir tout couper et on va faire des sprites de 24*24 ou peut etre 36*36 mais ça semble faisable meme si le résultat n'est po encore superbe je compte faire ça vraiment bien. l'ia et le link, c les autres qui s'en occupent et ils ont l'air de bien se démerder. moi je graphise et c déjà po maltiens ya un screen de l'éditeur de map fait par nos soins

24*2' c grand je trouve...
meme pour les ptit bonhomme ou les gros batiments ?

ouais, 24 c'est bien grand..

-

Pas besoin de transmettre toutes les unites. Tu transmets juste la position d'une unite, et son vecteur de deplacement. Ou alors tu fais un vrai serveur parallele sur les 2 calc.

pphd tu entends koi par serveur // sur les 2 calcs ?

oui là je capte po PpHd private term

d'apres ce que j'ai vu sur leur board, c du C=>bonne chance!

quence soit du C ne fera pas ramer énormément (du moins, si c du C bien programmé).
Le plus dur à gérer sera l'IA je pense... Bon courage !

Les jeux de stratégies sont vraiment les moins difficiles à programmer en link.

Je m'explique :

- tu décides de rafraîchir ton jeu à 15 frames/sec.
- sur les deux calcs tu maintiens un compteur de frames
- dès qu'un joueur donne un ordre à une unité, tu prends le numéro de frame courant, tu y ajoutes un certain délai (disons 5 frames), tu envoies le reste à l'autre calc, tu mets l'ordre dans ton buffer interne
- dès que tu reçois un ordre, tu le places dans ton buffer interne
- tu scannes le buffer : dès qu'un ordre avec le numéro de frame courant y est placé, tu l'exécutes
- l'ordre devient effectif sur les deux calculatrices à partir du numéro de frame spécifié

tu dois veiller à ce que les deux calcs restent en synchro : par exemple, si tu as des événements aléatoire, tu dois veiller à initialiser les deux générateurs avec les ^mêmes paramètres

Résultat : le flux de données est minime, pas besoin d'avoir un link ultra-rapide (il suffit d'ajuster le délai entre l'ordre et sa réalisation)...

qq'un peut m'expliquer ce qu'est exactement un buffer ???

memoire virtuelle (de l'anglais: tampon)

merci beaucoup de ton conseil MadKeyboard
Si t'as d'autres idées du meme genre bah fait moi signe...
g laissé mon email(sinon: oestro@ifrance.com)
merci