1

Bon ben vala, j'adore Nainwak (nooon? eek ) mais je trouve que c'est lanterne.

J'aimerais bien faire un jeu genre mix de Zelda, Pokémon (pour les graphismes uniquement gni) et bien sûr NainWak, et qui se jouerait en ligne avec un programme client connecté à un serveur. La différence avec Nainwak? Ben:
- les nains se baladeraient n'importe où sur des maps beaucoup plus grandes (au moins 50x50) et plus nombreuses;
- pixel par pixel au lieu de case par case;
- le rôle des guildes serait beaucoup plus développé -> familles et lignées?
- Les nains inscrits seraient une descendance des nains créés avant (ca me fait penser au parrainage ca grin )
- les actions par contre seraient limitées par un système de points, couplés à ces caracs de fatigue et de mana
- des quêtes complètes pourraient être programmées avec des actions à faire (pas que poutrage de cible donc)
Ne dites pas que c un vaporware, je le sais
Le développement comprendrait plusieurs étapes:
- choix du langage (je veux le faire en VB mais Delphi c possible aussi, le C éventuellement ++ ca va prendre des plombes pour avoir un truc qui marche)
- développement du client et du serveur en parallèle
- tests en réseau restreints avec serveur sur hôte ADSL ou réseau PG par exemple
- recherche d'une possibilité de serveur dédié (genre nainwak.com qui pourrait héberger un chtit serveur avec la bdd associée, mais ca viendra bcp plus tard avec les premières versions publiques)

Je sais que vous avez pas beaucoup de temps, mais on n'est pas pressés. Mais je pense que ca peut être un truc bien.
Si ca vous branche, posez moi les questions que vous voulez sur ce que j'ai expliqué ou pas, et donnez vos idées à vous.

2

Moi aussi je voudrais bien.... Mais un bémol: c'est forcé d'être une histoire de nains ?
Ca fait reloo à force les nains, on pourrait dire simplement des petits bonhommes, genre Kokiri de Zelda...
Moi c'est possible en Delphi 6 mais ça m'embêterait un peu...
En revanche en VB 7 ça pourrait être bien... On aurait bien sûr les forms faciles à faire,
et les fonctions DirectPlay etc sont bien mieux intégrées, pas comme le 6 où y'a des bidouilles à faire avec les symboles,
trifouiller les .lib je crois...

J'ai VB 7.0 (.Net 2002) et le DirectX 9.0b SDK pour faire du DirectPlay etc (pas super nécessaire, DX8SDK est en qq sorte
dedans et la MSDN documente tout)

Bon ça a des bémols, certes, comme la nécessité du .net framework (mais de toute manière il devient assez répandu, un
peu comme les packages DirectX mais avec beaucoup moins d'ampleur) et le fait que ça demanderait DirectX 9 ou 8,
le 7 je pense que c'est pas possible, du moins facilement.

Les gros avantages étant la conception qui se fait très très vite, le fait qu'avec le DXSDK rien qu'au premier exemple
on peut demander la gestion de DirectPlay, ce fait que ce côté là aussi devrait être fastoche à gérer...

Maintenant je reprends tes points:

- les nains se baladeraient n'importe où sur des maps beaucoup plus grandes (au moins 50x50) et plus nombreuses;

top

- pixel par pixel au lieu de case par case;

Pas vraiment nécessaire, et puis pourrait p-ê compliquer les choses, et sera dur si on fait ça avec des
forms VB ou Delphi... On peut aussi faire des petites cases, les persos en occuppent plusieurs, le joueur
remarque beaucoup moins le système de cases et est bien plus libre, sans pour autant qu'on s'emmerde.


- le rôle des guildes serait beaucoup plus développé -> familles et lignées?

OUI happy

- Les nains inscrits seraient une descendance des nains créés avant (ca me fait penser au parrainage ca )

Oui...

- des quêtes complètes pourraient être programmées avec des actions à faire (pas que poutrage de cible donc)

Oui !

- les actions par contre seraient limitées par un système de points, couplés à ces caracs de fatigue et de mana

hum, c'est ce qui m'a toujours énervé sur Nainwak....
J'aime pô du tout ça...

Bien si c'est pour le flood, on pourrait mettre un grand nombre de points
(ou un temps de jeu, au choix) qui fait qu'un joueur peut par exemple
jouer très correctement une ou deux heures par jour.

Et si c'est pour empêcher les joueurs de clasher ceux qui jouent pas,
ben on peut faire soit que les joueurs non loggés n'ont pas leurs
personnages présents, (s'il y a assez de monde), et sinon
qu'il y a des lieux sûrs pour rester, genre dormir dans une auberge,
voir "chez soi" s'il y a des cartes assez grandes, qui permettraient
aux gens de bâtir leur maison façon Ultima Online, (grâce au système de maps)

Et par pitié, du fric et une gestion des échanges inter-joueurs...
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

3

si tu limites pas les actions, y'aura trop de monde et il va falloir un serveur de taré.

4

Ben pourquoi pas tester de façon à donner le maximum de temps de jeu au joueur,
sans que ça floode ? Ex: on commence à l'équivalent de 30 points de Nainwak. Si ça passe
bien, on augmente peu à peu les points... Et puis on peut aussi essayer des tests pour voir
ce qui fait ramer le serveur, de façon à programmer un truc qui n'a pas besoin des points (faut pas rêver mais bon...)
ou qui permet pas mal d'actions ne demandant pas de points.
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

5

déja faut avoir une idée précise de ce qu'on veut faire neutral

6

Quels trucs ça demanderait de la part du serveur ?
(Si c'est possible de faire ça avec un serveur commun genre Free, ça serait bien,
on pourrait l'avoir up 24h/24. Et si on peut pas, on pourrait peut-être s'arranger,
genre les infos sont transmises par http, soit par une bidouille soit par
page web contenant les données et que le client décode, en actualisant rapidement.
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

7

erf... ca peut marcher, mais par expérience c'est lent.

8

Sûr ? Un script PHP fait tous les traitements et met à jour un fichier (disons binaire cette fois, pas html)
très fréquemment, présentant les actions des joueurs. Ca pourrait être une sorte de log (mais sans langage compréhensible)
et chaque client a une certaine position. Il a une certaine conception du monde, imposée au départ, et tout
nouveau joueur a celle-là, qui est mise à jour immédiatement au monde actuel (son pointeur dans le log est à 0, l'objectif à chaque accès est de passer tout à la fin du log.)

Et un joueur qui se déconnecte sauvegarde sa position dans le fichier qqpart, soit sur le client, soit sur le serveur par demande à un script PHP de sauvegarde, qui tient des infos sur les joueurs (et sur le monde, d'ailleurs) dans une DB.

Un joueur qui se relog accède au log et se met à jour...

Ensuite, la synchronisation, plus les accès fréquents au log, ça va sûrement être lent, mais le serveur pourra
probablement héberger beaucoup de monde, et comme c'est un serveur Free, on faire plusieurs mondes, un
serveur Free pour chaque, et la limite du nombre de joueurs peut être très grande.
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

9

non !

ca c pas du mmorpg!

le but c que tu saches ce qui se passe quand t'es en ligne, quand t'es déconnecté tu peux pas savoir ce qui s'est passé pisque t'y étais pas! Donc pas de log. en plus à y être hein, mysql gère ca un peu mieux qu'un log binaire si il le fallait!

De toute facon je pense que si tu dois gérer plusieurs utilisateurs, soit faut un serveur CGI plus évolué que apache/php, soit faut coder un serveur en binaire qui utilise pas le http (genre cstrike, à mon avis c le mieux) et qui gère des sessions, et héberger ca chez qqn.
met à jour un fichier (disons binaire cette fois, pas html) très fréquemment
Bah c le temps d'accès au disque qui va tuer le serveur, si il doit relire le fichier complètement à chaque connection, et comment tu vas gérer tous les users? comment savoir où en est chaque utilisateur dans le log? nan, c inutilisable.

le principe c qu'il faut pas garder trace d'actions pour d'autres buts que le log pur et simple. le serveur dans ce cas servirait à gérer uniquement la mise en commun des positions de chacun.

En fait on pourrait faire ca tout connement avec un serveur IRC.
Chaque joueur connecté passe ses infos au autres sur un chan, un chan par monde, comme ca par exemple
L'avantage c que le serveur de jeu est aussi un client du système IRC, qui ne sert qu'à dispatcher les messages.

* joueur 1 has joined #riorim
<joueur1> INS 3,3 <- insertion dans le jeu, apparait sur case
* joueur 2 has joined #riorim
<joueur2> INS 5,4
<joueur1> POS 3,4 <- MAJ position, tous les clients meuvent mettre à jour leur vue
<joueur1> POS 3,3
<joueur1> MSG joueur2 Gare ta geule! <- message
<joueur1> PAN joueur2 <- poutrage
<server> RES joueur1 DEG 10 LIVE <- serveur: résultat action 10PV de moins tjs pas mort
<joueur1> MSG joueur2 Méeuh!
<joueur1> USE WEAP calculette <- utilise autre arme
<joueur1> PAN joueur2
<server> RES joueur1 DEG 53 DEAD <-ayé il est mort
* joueur3 has joined #riorim
<joueur3> INS 2,2
<joueur3> SEEN joueur4
<server> MSG joueur3 STAT joueur4 LASTSEEN 3607 sec
<joueur3> SEEN joueur1
<server> MSG joueur3 STAT joueur 1 INLINE
<joueur2> DEL
* joueur 2 has left #riorim <

10

Très intéressante, cette conception en IRC. happy
Mais ça serait bien si on pouvait mettre ça chez des hébergeurs...
A la rigueur on doit bien pouvoir trouver un moyen....
(HS: L'idée du log est pas mal quand même, on pourrait faire du coup des
voyages temporels, ou rattrapper des trucs trop graves genre un pk qui a trouvé une faille devient
invincible et casse tout le monde...)
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

11

Pas besoin d'hébergeur. Et aucun ne voudra t'héberger un serveur IRC.
La solution c'est
-demander à kewl, efnet ou un autre si on peut faire des channels pour ca, ca devrait pas leur poser de pb.
-faire un petit réseau de serveurs sur nos adsls (on est plusieurs à en avoir je pense) comme ca si yen a un qui pète les autres tiennent encore.

12

Oki
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

13

-