Reprise du message précédent :

Quand vous entendrez parler d'un jeu révolutionnaire vous penserez à moi  

 
Merci.  
Première impression : j'y comprends rien, mais c'est beau ! Et ça tourne bien avec une pauvre Geforce2 MX400 (512 Mo de RAM tout de même).

je veux bien jouer sur l'IA
ya (IA ) de quoi se marrer je pense
par contre, j'ai un peu de mal à suivre le topic ici, donc à l'avance veuillez m'excuser si je harkote, si je débarque etc.

 
Moi je suis pour le multijoueurs, mais avec un seul serveur (pas de monde persistant).
Le problème du jeu mono, c'est que si jamais on veut par la suite évoluer vers le multi, il y a de fortes chances qu'il y ait quasiment tout à réécrire.

 
votons!
 
je suis contre le multijoueur.

 
Le problème du jeu multi, c'est qu'il ne sert à rien si personne ne paie le serveur ou si presque personne ne viens jouer.

de plus ça va disperser de l'énergie au détriment du mode solo  

Ben moi je pensais aux étudiants de fac, qui ont un serveur de jeu en permanence...

ceux là jouent déjà à xpilot

ce serait bien de d'abord se focaliser sur le solo, le multi c pour + tard ( je pense )

Bon, si la majorité est pour le sqolo, je me rends à la majorité

si l'analyse est correctement faite, on peut concevoir 1 jeu solo, mais avec toutes les portes de sorties prévues vers 1 jeu multi

 
Je suis pour aussi. Sinon, pour que le code puisse facilement évoluer, il suffit de coder un serveur qui n'accepte qu'un seul client

Perso, je suis toujours d'accord sur le principe d'évolutivité, j'ai bien l'intention d'en tenir compte à tous les stades du développement comme j'essaie de le faire à chaque fois que j'implémente quelque chose.
 
Faire un jeu avec une implémentation multi nous ralentirait fortement je pense, mais aucun problème pour développer un jeu solo en tenant compte des impératifs du multijoueurs.
 
Ceci dit, si quelqu'un veut s'occuper de l'implémentation spécifique au multijoueurs, ce n'est pas moi qui l'en empêcherai

Sur base de mon premier draft (un poil amélioré niveau contenu), j'ai commencé un document d'analyse. J'attends les commentaires (et les corrections/updates d'el muchacho) pour continuer

 
Bon comme j'ai pas continué depuis le w-e, je t'envoie mes remarques.

 
Ca m'intéresserait bien de m'en occuper.

C'est noté

Cool, on aura un forum integré dans le jeu en C

Si ca vous interresse, je dois avoir dans mes cartons un petit script qui génère en ensemble d'étoiles en forme de galaxie à spirale. Le tout en 3D.
 
Voici un screen d'exemple de ce qui est généré :


Comme vous le voyez sur la vue de tranche, la couleur représente l'altitude. Chaque point blanc est une étoile.

 
COOOOOL !!! URL ?  
Vais pouvoir tester ça avec le moteur 3d !!!

Attend un peu stp, le script est un peu poussiereux. Je vais essayer de trouver le temps de nettoyer ça avant de le poster.
 
Edit : en attendant, tu peux essayer d'utiliser ça : Ficher SQL contenant les coordonées des étoiles/planetes
 

pas mal du tout

heuuuuu "poussiereux" ... mmmmmmmmh en Basic ZX Spectrum ?
 
Pour les curieux ... une démo 64k ... assez lourd mais impressionnant ... apparament, une création dynamique des textures + "nuages" et "brumes" ...
http://www.pouet.net/prod.php?which=11452

Poussiereux c'est du 2 ans d'age. Mais comme j'utilise quelques libs externes pour les trucs comme la generation d'images, je ne peux pas réutiliser le script avant d'avoir réinstaller tout ça. Et puis comme je suis au taf là, je ne peux pas trop en faire quand même

 
Oki. Je vais commencer à réfléchir à un système potable pour pouvoir faire du persistent (sauf si l'idée dérange quelqu'un). A priori, ce n'est pas si complexe que ça.

bin vous pouvez toujours réfléchir à plusieurs choses, proposer, on en rediscutera de toute façon pour voir ce qui est le mieux

 
Ben le seul problème du persistant .. c'est d'avoir un/DES serveur(s) .. et étant donné qu'on part sur l'idée de base qu'on a un budget de 18 cents ça va pas trop le faire ... à moins que certains se sacrifient pour vendre qques-uns de leurs organes ...

je suis curieux de suivre ça
de trés près
parcequ'au final, dans un premier temps, les bots peuvent être des "joueurs" à part entière
donc on fait du multijoueur en monojoueur pour commencer

 
Ca va alors
Pour l'instant, j'en ai un qui ne sert à rien (enfin, il est à un pote mais il n'en fait rien; c'est celui dont je me sers pour la démo de mon forum). Enfin, tel que je voyais ça, c'était plutôt un système qui pourrait autant à la fois servir pour faire du monojoueur que du multi.

Ce qui serait "marrant", c'est que chaque client soit aussi serveur ( à la P2P ) et que chaque client possède "son" univers dans lequel pourrait venir se balader les autres joueurs ...  
C'est clair que ça amène pas mal de problèmes genre; si le joueur se déconnecte, qu'advient-il des joueurs "connecté" sur son univers à ce moment, etc etc .. mais bon on est bien ici pour poster des idées ...

Je sais pas trop comment marche le réseau dans le cas de monde persistant, mais je soumets juste une idée :
il suffit qu'il y ai toujours une personne de connecté pour que le monde soit à peu près connu.
Est-ce qu'un système de monde persistant distribué sur l'ensemble des clients peut-être une bonne idée (outre le fait que ça doit être chaud à mettre en place ) ?
 
Un peu à la manière de Bittorrent. Ca permet d'économiser beaucoup de bande passante et de puissance je pense (pour le serveur au moins )
Le principe serait d'avoir un serveur dédié, qui tourne tout le temps, mais qui voit ça charge diminué en fonction du nombre de client connecté. Ainsi, chaque client contribue un peu au role de serveur...

'tin, grilled

dites, au sujet du langage de script, Squirrel a pas l'air mal, mais apparemment on ne peut le binder qu'à du C
je suis en train d'essayer ceci : http://felix.sourceforge.net/
qui n'a pas l'air mal non plus, et qui peut s'interfacer à du C++

Pour faire un jeu dans un monde persistant, avec le code source dispo et sans tricherie, il faut s'accrocher. Si en plus vous donnez le controle du jeu aux clients c'est même plus la peine

 
pas grâve, ça fait plaisir de voir que je ne suis pas le seul malade à avoir eu cette idée !

Un langage de script compilé, comme c'est mignon Autant écrire du C ou du C++ directement vu comme ça.

nous sommes au moins 2

 
Spa con non plus

bah, ou est le problème
au contraire, ça ne peut qu'améliorer les performances, faut il que la partie scriptée du jeu tourne obligatoirement sous VM ?

 
En fait, on a à peu près les mêmes problématiques à résoudre en mulijoueur normal et en persistent. C'est dû à la taille de l'univers. C'est-à-dire que vu le nombre d'objets, on est obligé de gérer un état où les objets sont:
- en sommeil (rien à péter de l'étoile xyz qui est à 20 années-lumière du joueur le plus proche)
- en réveil (au moins un joueur s'en approche)
- en activité (un joueur peut interagir avec)
 
Ce qui est différent, c'est que dans un multijoueur persistent, on a des shards qui correspondent à une zone logique de l'univers (la zone n'étant pas nécessairement statique). Tous les objets de cette zone sont gérés dans le shard qui lui correspond. Si un objet (comme un joueur par exemple) se trouve proche d'autres shards, on se débrouille pour que les shards communiquent (en faisant un proxy de l'objet dans les shards où l'objet ne se trouve pas).
 
Dans un multijoueur normal, on ne programme qu'un seul shard ce qui ôte toute la com inter-shards mais on est quand même obligé d'avoir un système de zonage par rapport aux joueurs. Dans les deux cas, on envoit chaque input significatif du joueur (touche, mouvement du joystick) au serveur qui valide, traite et relaie ça aux joueurs impactés avec un système de gestion pour la correction des latences du réseau.