07-04-2008, 03:20 PM
mao : musique assisté par ordinateur (renoise + plugins vst, car je suis pas un adepte de cubase, zics sur http://allkala.free.fr/all_kala_music/)
Sinon pour un retour plus détaillé de Iuki's Land écrit un peu à l'arrache
comment l'idée a germer :
pendant mon contrat de qualif, j'avais 3 semaine entreprises et 1 semaine de cours, chaque semaine = 1 langage de prog différent.
Selon les semaines de cours, on pouvait avoir un prof très autoritaire ou très ouverts.
C'est tombé pendant la semaine de windev, le prof très ouvert nous sort un truc du genre après 2 jours de théories, "vous avez les 3 autres jours pour pondre un truc, c'est noté a la fin de la semaine", j'ai eu l'idée de faire un tamagotchi, en utilisant le sgbd proprio de windev (hyperfile). Après coup je me suis dit,
merde, je suis en train de faire un jeu basé sur une base de données, ce qui veut dire que je peux mettre le truc en ligne, puis, kit a faire un jeu, pourquoi ne pas aller au plus loin en faisant un monde virtuel complet !
j'ai donc commencé a étudier l'existant, en premier je suis tombé sur nainwak, puis tous les autres qui existaient à l'époque (mi 2002).
Problématiques et Solutions(coup de génie ? je sais pas vraiment ) :
-techniques d'abord.
.A l'époque tout le monde n'avait pas l'adsl, donc pas de pitié pour la bande passante ! le tableau html de 20 ko servant a afficher la carte s'est vite transformé en un ensemble d'appels de fonctions javascript totalisant un poids moyen de 1 ko, les images de la carte sont dispo dans un kit d'accélération, le joueur peut donc les télécharger et déclarer le dossier local dans lequel les images doivent être lus. il reste donc que les monstres et les objets (qui alimentent progressivement le cache du navigateur)
.Après il a fallu optimiser la partie sql, tout le code est orienté pour faire le moins de requêtes possibles, les tables sont indexées la ou il faut, etc. Dans tous les cas ça reste quand même lourd, car a chaque attaque/déplacement, il faut gérer les éventuels pnj et attaques potentiels qu'ils peuvent lancer + réafficher la map (1 requête par élément : carte, objets, pnj, pj)
.graphiques
.la carte est un quad texturé, rendu sous lightwave en vue aërienne d'une taille de 6144*6144. chaque batiment et arbre a été modélisé a part, rendu en spite. le rendu du quad a été chargé sous photoshop et chaque instance de sprite a été placé sur le quad rendu en pleins d'exemplaires. Cette image global est la carte.
Après quoi, l'image a été découpé en 65536 morceaux de 24*24 pour faire les cases pour le premier kit d'accélération. pour le second kit, la même image a été découpé en portion de 360*360.
.les persos mâles et femelles ont également été modélisé rendu sous lightwave en 24*48. Ils ont ensuite été découpés en plusieurs sprites de plusieurs couleurs pour la peau, les cheveux et les vêtements (d'où la possibilité de choisir homme/femme longueur de cheveux, couleur vêtement, couleur peau = race).
.les objets et les pnj (monstres) sont des gifs animés existant ramassés sur le net (j'ai du me taper 2/3 semaines de ramassage global pour dégoter le top du top en la matière). De nombreux gifs ont été retouchés avec gifsicle faute de transparence bien géré.
seul l'objet rune a été modélisé/rendu sous lightwave et assemble avec gifsicle.
-humains
.Beaucoup de de plaintes de joueurs(moyennes d'âge = 16 ans) se faisant tuer leur perso et voulant récupérer les objets perdus.
.Un forum phpbb dont l'administration a été délégué (pour me permettre d'éviter une gestion communautaire trop lourde et me concentrer sur la partie technique et innovation). Malgré cela, le forum a subi une attaque (spam message insulte) d'un script kiddies a cause d'une dispute entre joueurs, c'est en partie la raison pour laquelle j'ai laissé le jeu de côté.
.Un public un peu inattendu, c'est à dire par mal de joueurs en attente d'une immersion plus profonde laissant place à l'imaginaire, ce qui est communément appelé "role-play". J'ai du me réadapter en créant rapidement la possibilité de se guilder, d'appartenir à un royaume, et en participant à la création d'un scénario pouvant justifier certaines limitation du jeu (pas de transport type cheval, taille de carte limité, etc.)
-ergonomie / équilibre du jeu
.caractéristique des objets(arme, armure, incrémenteur, consommation, parchemin)(plusieurs centaines en tout) et des pnj(100 différents)
faire en sorte qu'il y en ai aucun d'identique, que ceux-ci soient en adéquation avec ce que le gif(animé) représente, que le joueur ai une probabilité forte d'avoir un intérêt à les utiliser en fonction du niveau de son perso.
.caractéristique des pj
trouver des courbes et des conditions d'augmentation raisonnables (ce n'était pas le cas dans la 1 ere version), (échelle logarithmique pour éviter que les anciens soient non rattrapable pour les nouveaux, et pour inciter les nouveaux a jouer au début)
-répartition des pnj
la répartition aléatoire a très vite trouvé ses limites, il a fallu définir des zones de vie sur la carte, avec des probabilités d'affectation par monstre. (genre éviter de mettre un dragon de ouf dans un village et une poule dans le désert).
.probabilité d'obtention des objets sur les pnj
il a fallu trouver des formules très équilibrés pour que les objets convoités se trouvent sur les monstres puissants et vice versa,
la problématique étant que ce sois ni trop facile, sans quoi le jeu est exploité trop rapidement, mais ni trop difficile car risque de lassitude des joueurs, il faut donc faire des calculs prévisionnels en fonction du temps de jeu et de l'évolution potentielle qu'on souhaite pour le joueur idem pour les sous.
.que faire quand le joueur est déconnecté
il a fallu mettre un mode autoréponse au cas ou le joueur est attaqué (sous nainwak, y a 30 pa, ce qui permet 2-3 attaques par jour, sous iuki c'est plusieurs dizaines)
.que faire pour éviter du multi clique quand plusieurs dizaines d'attaques a faire.
un bouton attaque tant que possible
(la fonction a été très longue a coder, puisque le pj ou pnj potentiel peut répondre à l'attaque et ceci récursivement, jusqu'à la mort d'un des 2 combatant (il a fallu faire un pseudo système de cache des données du combat pour éviter les requêtes sql, et délivrer le résultat)
.que faire pour éviter le multi perso par joueur
la, c'est le plan de galérien, j'ai tout essayé (ip, cookie, +trucs de ouf abjectes à décrire),
a part la négociation humaines, j'ai pas de soluces idéales.
mes principales erreurs (en vrac) :
.carte à taille limité, la façon dont j'ai fait la carte (orienté optimisation bp et graphisme correct) fait que celle ci n'était pas modulable (les bâtiments, arbres, chemins, etc, font partie de la carte elle même). Donc si c'était à refaire, j'aurais rendu la carte éditable par des mj pour une extension potentiellement infinie (y aurait eu le problème sql pour la gestion des cases pénétrables/non pénétrables, si carte trop grande, donc plusieurs cartes avec téléportation à la slider comme nainwak mais scrollable (la carte fait 256* 256 cases, l'écran en affiche 15*15)).
.le jeu étant médiéval fantastique, ne pas avoir fait de moyen de transport genre cheval (feature très demandé par les joueurs que je n'ai pu coder faute de graphisme mal orienté et de recherches pour rééquilibrer l'intérêt du jeu, car il y avait des classes à fort potentiel pour le déplacement genre 'explorateur')
.ne pas avoir fait de coffres inviolable (feature très demandé, car tout joueur mort perd ses objets (sauf si il est de classe/race préservateur ou qu'il les a laissés dans sa maison, mais celle-ci peut potentiellement être cambriolé, puisqu'il perd ses clés au moment de sa mort, et la classe/race détrousseur peut ouvrir n'importe quelle porte))
.Avoir subdivisé les persos en classe/race. Dans la première version du jeu (principalement joué, la seconde n'a quasiment pas été joué), après avoir ramassé pleins de parchemins, l'ensemble des sorts étaient accessible à tous les persos, soit une bonne trentaine, ce qui laissait un nombre de possibilités grandioses. En subdivisant en 6 classes, 5 races, il ne reste plus que 7 sorts communs a tous et 2/3 sorts par combinaisons. J'ai voulu cette subdivision car il y avait trop de pvp, et je voulais rendre le jeu plus 'intelligent' en obligeant les joueurs a s'allier pour regrouper leur compétence, j'ai travaillé d'arrache pied pour rééquilibrer le jeu, car une potion (très rare) permettait de doubler ses capacités et un sort(parchemin très rare) permettait de dupliquer les objets, il s'est avéré qu'au bout de quelques mois plusieurs joueurs parvenaient au level 9999 (max des tables sql), tuant ainsi les nouveaux venus (la subdivision + rééquilibrage aurait évité ce phénomène)
.ne pas avoir fait de purge automatique des objets délaissés par terre !!!
beaucoup de joueurs laissaient les objets utilisés par terre, car ils n'étaient plus d'aucune utilité,
a un moment le monde était une vrai porcherie, certains joueurs ont même fait des guildes ecolos pour régler le pb. Seul une purge auto a 48h a vraiment pu régler le pb.
.ne pas avoir défini un positionnement clair,
nainwak le positionnement est clair, c'est du 5 minutes par jour,
dans iuki, les unités de temps permettent de jouer plus longtemps, mais pas tant que ça non plus (15 minutes), du coup le joueur est obligé de s'investir un peu (plus le chat sur map, plus les guildes et le role play).
nainwak joue la carte de l'humour et du fun,
iuki pas trop, donc sérieux = le jeu doit déboiter techniquement, le web = juste une solution échappatoire pour éviter au jouer de télécharger un client lourd.
donc si pas de technique et pas drôle et que l'existant est meilleur (wow) = impossible d'avoir du monde.
.pas suffisamment d'aide non plus (y a un manuel écrit par ma copine de l'époque), j'en ai encore plus conscience à l'heure actuel quand je vois l'effort humain a fournir pour former des utilisateurs sur un projet web (compter raisonnablement 1 demi journée par formulaire codé, donc imaginer l'effort à fournir pour délivrer une aide correcte à tout nouvel arrivant dans une interface chiadé)
'si c'était à refaire ...' :
-vu le nombre de jeux existants aujourd'hui par rapport à l'époque, faudrait avoir une idée qui déboite vraiment !
.maintenant y a wow, donc en médiéval fantastique en mode web ...
donc si je limite l'énoncé à
jeu en php à faire aujourd'hui,
-trouver une thématique non exploité (stratégie spatiale = trop exploité, médiéval-fantastique = idem, élevages, trucs rigolos aussi) (je sais pas ce qui reste, j'ai pas encore lu le forum, j'espère y trouver quelque chose d'original)
-ne pas être trop ambitieux (je l'ai été pas mal avec iuki)
-avoir un positionnement super clair (le joueur doit avoir un intérêt très concret à jouer, genre plaisir, notoriété ou argent à gagner), cela sous entend avoir un moyen de promotion/marketing, un plan d'action très clair pour générer du trafic qualifié (voir mes vidéos seo (youtube kalaspace), à l'époque j'avais pas ces compétences la, d'ailleurs même avec, ça devient super difficile de faire quelque chose, le public cherchant un "jeu par navigateur" et n'étant pas des gens cherchant eux même a faire un jeu s'avère hyper limité)
-je complèterai en fonction de ce que je découvrirai ici car on peut pas vraiment dire que mes postulats ci dessus constituent des solutions.
Conclusion globale :
-Dans tous les cas faire un jeu est le meilleur moyen d'apprendre un langage de prog.
-Ce projet m'a servi de vitrine techno pour être embauché la ou je suis aujourd'hui.
Sinon pour un retour plus détaillé de Iuki's Land écrit un peu à l'arrache
comment l'idée a germer :
pendant mon contrat de qualif, j'avais 3 semaine entreprises et 1 semaine de cours, chaque semaine = 1 langage de prog différent.
Selon les semaines de cours, on pouvait avoir un prof très autoritaire ou très ouverts.
C'est tombé pendant la semaine de windev, le prof très ouvert nous sort un truc du genre après 2 jours de théories, "vous avez les 3 autres jours pour pondre un truc, c'est noté a la fin de la semaine", j'ai eu l'idée de faire un tamagotchi, en utilisant le sgbd proprio de windev (hyperfile). Après coup je me suis dit,
merde, je suis en train de faire un jeu basé sur une base de données, ce qui veut dire que je peux mettre le truc en ligne, puis, kit a faire un jeu, pourquoi ne pas aller au plus loin en faisant un monde virtuel complet !
j'ai donc commencé a étudier l'existant, en premier je suis tombé sur nainwak, puis tous les autres qui existaient à l'époque (mi 2002).
Problématiques et Solutions(coup de génie ? je sais pas vraiment
) : -techniques d'abord.
.A l'époque tout le monde n'avait pas l'adsl, donc pas de pitié pour la bande passante ! le tableau html de 20 ko servant a afficher la carte s'est vite transformé en un ensemble d'appels de fonctions javascript totalisant un poids moyen de 1 ko, les images de la carte sont dispo dans un kit d'accélération, le joueur peut donc les télécharger et déclarer le dossier local dans lequel les images doivent être lus. il reste donc que les monstres et les objets (qui alimentent progressivement le cache du navigateur)
.Après il a fallu optimiser la partie sql, tout le code est orienté pour faire le moins de requêtes possibles, les tables sont indexées la ou il faut, etc. Dans tous les cas ça reste quand même lourd, car a chaque attaque/déplacement, il faut gérer les éventuels pnj et attaques potentiels qu'ils peuvent lancer + réafficher la map (1 requête par élément : carte, objets, pnj, pj)
.graphiques
.la carte est un quad texturé, rendu sous lightwave en vue aërienne d'une taille de 6144*6144. chaque batiment et arbre a été modélisé a part, rendu en spite. le rendu du quad a été chargé sous photoshop et chaque instance de sprite a été placé sur le quad rendu en pleins d'exemplaires. Cette image global est la carte.
Après quoi, l'image a été découpé en 65536 morceaux de 24*24 pour faire les cases pour le premier kit d'accélération. pour le second kit, la même image a été découpé en portion de 360*360.
.les persos mâles et femelles ont également été modélisé rendu sous lightwave en 24*48. Ils ont ensuite été découpés en plusieurs sprites de plusieurs couleurs pour la peau, les cheveux et les vêtements (d'où la possibilité de choisir homme/femme longueur de cheveux, couleur vêtement, couleur peau = race).
.les objets et les pnj (monstres) sont des gifs animés existant ramassés sur le net (j'ai du me taper 2/3 semaines de ramassage global pour dégoter le top du top en la matière). De nombreux gifs ont été retouchés avec gifsicle faute de transparence bien géré.
seul l'objet rune a été modélisé/rendu sous lightwave et assemble avec gifsicle.
-humains
.Beaucoup de de plaintes de joueurs(moyennes d'âge = 16 ans) se faisant tuer leur perso et voulant récupérer les objets perdus.
.Un forum phpbb dont l'administration a été délégué (pour me permettre d'éviter une gestion communautaire trop lourde et me concentrer sur la partie technique et innovation). Malgré cela, le forum a subi une attaque (spam message insulte) d'un script kiddies a cause d'une dispute entre joueurs, c'est en partie la raison pour laquelle j'ai laissé le jeu de côté.
.Un public un peu inattendu, c'est à dire par mal de joueurs en attente d'une immersion plus profonde laissant place à l'imaginaire, ce qui est communément appelé "role-play". J'ai du me réadapter en créant rapidement la possibilité de se guilder, d'appartenir à un royaume, et en participant à la création d'un scénario pouvant justifier certaines limitation du jeu (pas de transport type cheval, taille de carte limité, etc.)
-ergonomie / équilibre du jeu
.caractéristique des objets(arme, armure, incrémenteur, consommation, parchemin)(plusieurs centaines en tout) et des pnj(100 différents)
faire en sorte qu'il y en ai aucun d'identique, que ceux-ci soient en adéquation avec ce que le gif(animé) représente, que le joueur ai une probabilité forte d'avoir un intérêt à les utiliser en fonction du niveau de son perso.
.caractéristique des pj
trouver des courbes et des conditions d'augmentation raisonnables (ce n'était pas le cas dans la 1 ere version), (échelle logarithmique pour éviter que les anciens soient non rattrapable pour les nouveaux, et pour inciter les nouveaux a jouer au début)
-répartition des pnj
la répartition aléatoire a très vite trouvé ses limites, il a fallu définir des zones de vie sur la carte, avec des probabilités d'affectation par monstre. (genre éviter de mettre un dragon de ouf dans un village et une poule dans le désert).
.probabilité d'obtention des objets sur les pnj
il a fallu trouver des formules très équilibrés pour que les objets convoités se trouvent sur les monstres puissants et vice versa,
la problématique étant que ce sois ni trop facile, sans quoi le jeu est exploité trop rapidement, mais ni trop difficile car risque de lassitude des joueurs, il faut donc faire des calculs prévisionnels en fonction du temps de jeu et de l'évolution potentielle qu'on souhaite pour le joueur idem pour les sous.
.que faire quand le joueur est déconnecté
il a fallu mettre un mode autoréponse au cas ou le joueur est attaqué (sous nainwak, y a 30 pa, ce qui permet 2-3 attaques par jour, sous iuki c'est plusieurs dizaines)
.que faire pour éviter du multi clique quand plusieurs dizaines d'attaques a faire.
un bouton attaque tant que possible
(la fonction a été très longue a coder, puisque le pj ou pnj potentiel peut répondre à l'attaque et ceci récursivement, jusqu'à la mort d'un des 2 combatant (il a fallu faire un pseudo système de cache des données du combat pour éviter les requêtes sql, et délivrer le résultat)
.que faire pour éviter le multi perso par joueur
la, c'est le plan de galérien, j'ai tout essayé (ip, cookie, +trucs de ouf abjectes à décrire),
a part la négociation humaines, j'ai pas de soluces idéales.
mes principales erreurs (en vrac) :
.carte à taille limité, la façon dont j'ai fait la carte (orienté optimisation bp et graphisme correct) fait que celle ci n'était pas modulable (les bâtiments, arbres, chemins, etc, font partie de la carte elle même). Donc si c'était à refaire, j'aurais rendu la carte éditable par des mj pour une extension potentiellement infinie (y aurait eu le problème sql pour la gestion des cases pénétrables/non pénétrables, si carte trop grande, donc plusieurs cartes avec téléportation à la slider comme nainwak mais scrollable (la carte fait 256* 256 cases, l'écran en affiche 15*15)).
.le jeu étant médiéval fantastique, ne pas avoir fait de moyen de transport genre cheval (feature très demandé par les joueurs que je n'ai pu coder faute de graphisme mal orienté et de recherches pour rééquilibrer l'intérêt du jeu, car il y avait des classes à fort potentiel pour le déplacement genre 'explorateur')
.ne pas avoir fait de coffres inviolable (feature très demandé, car tout joueur mort perd ses objets (sauf si il est de classe/race préservateur ou qu'il les a laissés dans sa maison, mais celle-ci peut potentiellement être cambriolé, puisqu'il perd ses clés au moment de sa mort, et la classe/race détrousseur peut ouvrir n'importe quelle porte))
.Avoir subdivisé les persos en classe/race. Dans la première version du jeu (principalement joué, la seconde n'a quasiment pas été joué), après avoir ramassé pleins de parchemins, l'ensemble des sorts étaient accessible à tous les persos, soit une bonne trentaine, ce qui laissait un nombre de possibilités grandioses. En subdivisant en 6 classes, 5 races, il ne reste plus que 7 sorts communs a tous et 2/3 sorts par combinaisons. J'ai voulu cette subdivision car il y avait trop de pvp, et je voulais rendre le jeu plus 'intelligent' en obligeant les joueurs a s'allier pour regrouper leur compétence, j'ai travaillé d'arrache pied pour rééquilibrer le jeu, car une potion (très rare) permettait de doubler ses capacités et un sort(parchemin très rare) permettait de dupliquer les objets, il s'est avéré qu'au bout de quelques mois plusieurs joueurs parvenaient au level 9999 (max des tables sql), tuant ainsi les nouveaux venus (la subdivision + rééquilibrage aurait évité ce phénomène)
.ne pas avoir fait de purge automatique des objets délaissés par terre !!!
beaucoup de joueurs laissaient les objets utilisés par terre, car ils n'étaient plus d'aucune utilité,
a un moment le monde était une vrai porcherie, certains joueurs ont même fait des guildes ecolos pour régler le pb. Seul une purge auto a 48h a vraiment pu régler le pb.
.ne pas avoir défini un positionnement clair,
nainwak le positionnement est clair, c'est du 5 minutes par jour,
dans iuki, les unités de temps permettent de jouer plus longtemps, mais pas tant que ça non plus (15 minutes), du coup le joueur est obligé de s'investir un peu (plus le chat sur map, plus les guildes et le role play).
nainwak joue la carte de l'humour et du fun,
iuki pas trop, donc sérieux = le jeu doit déboiter techniquement, le web = juste une solution échappatoire pour éviter au jouer de télécharger un client lourd.
donc si pas de technique et pas drôle et que l'existant est meilleur (wow) = impossible d'avoir du monde.
.pas suffisamment d'aide non plus (y a un manuel écrit par ma copine de l'époque), j'en ai encore plus conscience à l'heure actuel quand je vois l'effort humain a fournir pour former des utilisateurs sur un projet web (compter raisonnablement 1 demi journée par formulaire codé, donc imaginer l'effort à fournir pour délivrer une aide correcte à tout nouvel arrivant dans une interface chiadé)
'si c'était à refaire ...' :
-vu le nombre de jeux existants aujourd'hui par rapport à l'époque, faudrait avoir une idée qui déboite vraiment !
.maintenant y a wow, donc en médiéval fantastique en mode web ...
donc si je limite l'énoncé à
jeu en php à faire aujourd'hui,
-trouver une thématique non exploité (stratégie spatiale = trop exploité, médiéval-fantastique = idem, élevages, trucs rigolos aussi) (je sais pas ce qui reste, j'ai pas encore lu le forum, j'espère y trouver quelque chose d'original)
-ne pas être trop ambitieux (je l'ai été pas mal avec iuki)
-avoir un positionnement super clair (le joueur doit avoir un intérêt très concret à jouer, genre plaisir, notoriété ou argent à gagner), cela sous entend avoir un moyen de promotion/marketing, un plan d'action très clair pour générer du trafic qualifié (voir mes vidéos seo (youtube kalaspace), à l'époque j'avais pas ces compétences la, d'ailleurs même avec, ça devient super difficile de faire quelque chose, le public cherchant un "jeu par navigateur" et n'étant pas des gens cherchant eux même a faire un jeu s'avère hyper limité)
-je complèterai en fonction de ce que je découvrirai ici car on peut pas vraiment dire que mes postulats ci dessus constituent des solutions.
Conclusion globale :
-Dans tous les cas faire un jeu est le meilleur moyen d'apprendre un langage de prog.
-Ce projet m'a servi de vitrine techno pour être embauché la ou je suis aujourd'hui.