T'as qu'à prendre la VM rails de Sephi 
tu ouvrirais une patisserie où on ne vendrait que des croissants ?
tu ouvrirais une patisserie où on ne vendrait que des croissants ?
JeuWeb - Crée ton jeu par navigateur
Discussions, Aide, Ressources...
Programmation, infrastructure
Liste de questions
Liste de questions
|
25-02-2013, 07:17 PM
(Modification du message : 25-02-2013, 09:34 PM par Sephi-Chan.)
(25-02-2013, 07:00 PM)Malya a écrit : Rhaa.. Non mais désolée je ne peux pas m'avouer vaincue. Le truc (et pas turc), c'est que le développement informatique est une science à tiroir. Pour apprendre certaines choses, tu as besoin d'en connaître d'autres, qui eux-mêmes en requièrent d'autres, etc. Déjà, si tu veux faire un site Web, tu vas devoir apprendre un peu à utiliser un serveur Web (les débutants utilisent souvent Apache), à apprendre la syntaxe, à utiliser une base de données ? Après, outre le fait de savoir utiliser les outils, tu vas devoir apprendre à modéliser des problèmes d'un point de vue informatique. Comment représenter une carte, comment gérer un paquet de carte ? Est-ce qu'une carte peut être utilisée dans un ou plusieurs paquets ? Comment stocker ça en base de données et récupérer les données de la base ? Comment organiser une phase de jeu robuste qui peut être résolue automatiquement ? Si tu as déjà joué à Magic, tu peux voir que la pile de résolution des effets peut vite devenir complexe. Tu dois aussi avoir de bonnes connaissances en Javascript si tu veux un site un peu moderne, et interactif, qui ne se manipule pas qu'avec des formulaires, par exemple le plateau de ton jeu de carte. Maintenant, en admettant que tu vas faire ce site avec Symfony : tu as besoin de savoir manier une ligne de commande (que ce soit sur Windows, Linux ou OS X), de connaître un peu le protocole HTTP (les méthodes GET, POST, PUT, DELETE), de bouffer pas mal de documentation sur l'ORM qui fait le lien entre la base de données et des objets, du coup tu as besoin d'avoir des connaissances suffisantes en programmation orientée objet. Bien sûr, tout ça s'apprend, mais pas en 3 mois. 
Commence a faire ton jeu de cartes avec des caractéristiques , sans plus : pas d augmentation, pas de quête
Juste un jeu de confrontations entre deux séries de carte Te prends pas trop la tête avec un tas de truc : Y a pas besoin de grosses formules mathématiques Y a pas besoin de changer les images par le code C est avec l expérience, avec ce que tu auras développé que tu jugeras s il est pertinent ou pas de rajouter des fonctionnalités
@Malya:
Je pense que tu aurais du ouvrir 1 topic par sujet (ou "question"), plutôt que de les rassembler ainsi (cela aurait permis une meilleure indexation des questions pour en retrouver les réponses plus tard et aurait éviter les débats croisés que de multiples questions en un sujet peuvent faire survenir). -------------------------------------------------------------------- "Comment avez-vous pu choisir le système le plus optimale pour votre jeu du coup?" J'ai déjà touché à tous les langages cités, "touché" au sens "j'ai réalisé un projet avec". C++: mon stage ingénieur (simplification d'une maquette 3D) Pourquoi? Car le C++ est assez bas niveau, et m'a permis de contourner des problématiques de mémoire (réduire au max la mémoire occupée par le soft, pour que cela tiennent dans les 2Go allouables par Windows) et de temps de calculs ("bas" niveau, donc souvent proche du matériel qui est le fondement de la rapidité d'exécution) Atouts: Rapide, portable (suffit de ne pas utiliser des codes spécifiques à une seule plateforme), dérivé du C (donc on "connait" deux langages en un, et le C est souvent utilisé pour des systèmes embarqués), ultra-controlable (on peut "tout" faire avec) Inconvénients: ultra-rigoureux, pas forcément le plus aisé pour démarrer (ca dépend si t'es plutôt matheux ou plutôt "artiste", les artistes auront du mal, les matheux adoreront le coté ultra-rigoureux et déterministe), bas-niveau (donc, faut souvent aller ras les paquerettes) + Adapté pour la performance, la rapidité, et la rigueure - Délicat si on veut traiter du multimédia (vidéos/audios/images: on recours souvent à des bibliothèques déjà codées dont on ne sait pas toujours tout) ou si on a besoin d'interfaces graphiques (on recourt là encore à des biblios) Java: projet-TP de jeu de mille-bornes Pourquoi? Imposé. Atouts: très aisé d'en faire des interfaces, souple, assez performant (ne vaut pas C/C++ mais s'en rapproche pas mal), portable (très dur de faire des programmes java qui ne soient pas multi-plateformes), riche en bibliothèques déjà codées (pas besoin de "tout" refaire soit-même; tous les langages ont des biblios déjà codés, mais java est très riche de ce coté-là) Inconvénient: coté "boite noire" que j'aime moyen, technologie probablement propriétaire (Sun puis Oracle) + Adapté aux interfaces graphiques et aux réseaux, rapide à prendre en main pour des "petits" projets (entendre par là "si tu veux pas faire un jeu type Quake III ou IV, java sera surement bien, pour les 2D, ca passe, sauf sur-abondance d'unités type Supreme Commander et désolé pour la pub), cross-plateforme - Pas le plus performant Javascript/AJAX: ECLERD Pourquoi? Pour faire des pages webs réactives et laisser la machine du client travailler un peu (1.000 machines-clients qui travaillent 1 minute au total peut être équivalent à 1.000 minutes, soient 15heures, de travail du serveur si ton serveur a la même puissance que le client moyen, généralement, y'a un ratio x10 je dirai) Atouts: Compatible sur des tas de navigateurs, pas propriétaire, coté "script" qui permet d'avoir une bonne transparence dans ces codes (les utilisateurs peuvent lire ton code source et donc, savoir que tu ne les arnaques pas) Inconvénient: Non-orienté objet (pas forcément un handicap mais si on a l'habitude de ce genre de langage OO, c'est embêtant), pas performant + Adapté pour les pages webs dynamiques - Mauvaises performances et quelques petites différences d'un navigateur à l'autre qui peuvent être ennuyeuses quand on démarre PHP:ECLERD / Reinom Pourquoi? Pour générer le contenu, coté serveur, des pages webs et documents webs à envoyer aux clients Atouts: aisé à prendre en main, bonne documentation ( http://php.net ), OO, s'interface facilement avec un tas de trucs comme les bases de données (mysql, sql, postgres...), les bibliothèques de calcul d'images/maths/XML... supporté sur tous les hébergeurs webs (enfin, presque tous, mais même les gratuits proposent PHP, souvent restreint) Inconvénient: un peu poussif + Adapté pour générer des pages webs, simple quand on débute avec pas mal d'aide - Un peu poussif, pas de typage des données (autrement dit, PHP offre l'orienté-objet, mais de façon très "lâche") --------------------------------------------------------------- Critères utiles de choix du serveur: - Combien de clients connectés en même-temps penses-tu avoir? Il faut que le serveur ET la base de données puissent suivre. Si tu considère "bof, allez, y'aura 10 joueurs connectés en même temps", tu peux diviser ce nombre par 2 au moins, car un "joueur qui joue" n'est pas forcément "un serveur qui calcule". En d'autres mots, le joueur peut "jouer" alors que la connection est inactive; le meilleur exemple est le suivant: va sur un topic de jeu web, lis un message assez long et coupe ta connection au milieu: tu peux encore lire le message, donc la connexion est inactive, mais tu "joues" car tu peux "lire". - Quel niveau de liberté? si tu veux pouvoir tout piloter dans les moindres détails, choisis un VPS/dédié. Si tu préfères laisser "par défaut", ne serait-ce qu'au début, un "mutualisé" suffit. Mutualisé? Dédié? VPS? * Mutualisé: le serveur est partagé avec d'autres utilisateurs Atouts: pas cher, car le coût du serveur est partagé par les utilisateurs Inconvénients: si un utilsiateur occupe trop le serveur, les autres en pâtissent, de plus, on ne contrôle pas tous les paramètres * Dédié: un serveur pour toi tout(e) seul(e) Atouts: totalement contrôlable, tu es le seul maître à bord Inconvénient: oh, c'est cher! * VPS: Virtual Private Server, mix des deux précédents; c'est une sorte de mutualisé où tu peux tout piloter Atouts: totalement contrôlable, moins cher que le dédié Inconvénients: plus cher que le mutualisé A titre d'exemple, ECLERD tourne sur un ovh "perso" à 3€/mois + 4€/an pour le nom de domaine, soit un total de ~40€/an. Pour une beta de test et pour un projet qui n'a aucune vocation commerciale, c'est suffisant. Les lenteurs de certaines pages sont dues à mes mauvais algorithmes de simulation. Niveau limites (poids/puissance), normalement tu as soit un panneau de contrôle fournis par l'hébergeur et qui t'informe de la charge de ta machine (dédiée, VPS ou mutualisée), soit, ben, t'inquiète pas, si tu approches la limite, l'hébergeur se fera une joie de te contacter pour de proposer une offre "mieux adaptée", donc plus chère :p Tout le monde y gagne en un sens, car toi, tu n'as pas à stalker tes stats pour vérifier que tu ne dépasse pas, et l'hébergeur te vendra un truc plus cher (car tu as besoin de plus de puissance), et il gagnera plus. ------------------------------------------------------------ Non. Pas besoin d'être balèze, pour des tas de raisons: - Il en existe déjà des balèzes, tu peux leur demander - Il n'est pas besoin de faire des maths avancées pour un jeu: c'est le concepteur qui choisit ce qu'il veut faire et mettre dans son jeu; le niveau de maths requis découle de cela. C'est donc le concepteur qui choisit le niveau de maths qu'il veut atteindre Après, il te faut forcément les bases: savoir compter, savoir simplifier des calculs (pour alléger la charge du PC), savoir quels sont les choses interdites en maths (typiquement, diviser par 0, simplifier par une valeur nulle, ou demander le logarithme d'un nombre négatif), et connaitre le calcul élémentaire sur les fonctions (comprendre ce qu'est un polynôme, quelles sont ses limites, connaitre les fonctions log et exp pour savoir ce qu'elles représentent et comment les manipuler). Connaître les histoires de continuité/dérivabilité/intégration pourront te servir, mais ne sont pas requises (c'est utile de savoir, par exemple, que si tu ajoutes un "plafonnement" à une fonction, par exemple une vitesse, alors si l'utilisateur accélère, il sentira une "brisure" car d'un seul coup, sa vitesse ne pourra plus augmenter; c'est de la "logique", mais cela peut se mettre en maths aussi). Note que dans le cas d'un jeu de plateau, la manipulation de vecteurs 2D/3D et la géométrie te seront utiles (savoir l'aire d'une surface simple, savoir ce qu'un un produit scalaire et à quoi ca sert, etc), ainsi que les calculs d'angle. Ca semble faire beaucoup, mais la plupart des connaissances ne sont requises que dans des cas précis. SI besoin, demande sur des forums de maths (ou ici :p) ------------------------------------------------------- Les graphistes codent peu, même pas du tout. Il y a plusieurs tâches à distinguer: - Le graphiste, ou dessinateur: il fait le dessin avec quelques contraintes pré-étabies et un descriptif de ce qu'il doit dessiner ("un cheval qui court dans la plaine, en niveaux de gris"). Souvent, il n'a "aucune" idée de ce pour quoi il dessine (c'est le "dessinateur" du site). - Le designer, qui définit ce que représente l'image, et où elle se placera dans le site; il peut également définir la couleur/teinte/luminosité d'image. Il a une vue très globale du projet, mais parfois aucune capacité de dessin (c'est le "scénariste" du site) - Le codeur, qui combine les directives du designer et les dessins du graphiste. Il peut appliquer des traitements mathématiques à une image, pour en changer la teinte, la luminosité, ou d'autres paramètres comme la torsion/angle de vue, et ce en temps réel. Il est un peu "l'imprimeur" du site. ------------------------------------------------------------ Je préconise de coder l'IA après le jeu, plutôt que "pendant" ou "en continuité". L'IA est une sorte de programme qui simule l'utilisateur, mais pour le jeu, c'est toujours un "utilisateur" (humain ou IA, c'est pareil). Avec cette approche, on a d'ailleurs un jeu bien plus équitable: dans certains jeux, l'IA est "mélangée" avec le code du jeu, et elle obtient ainsi des informations complémentaires totalement innaccessibles aux joueurs humains,. Elle connait, par exemple, la vitesse de déplacement exact de l'unitée ennemie, ou encore, la destination et l'ordre que cette unité a reçue. Le langage est au choix. Souvent, c'est le même que celui du jeu, histoire de ne pas devoir se re-farcir un langage à apprendre, mais cela n'est en rien une obligation. Enfin, il faut différencier trois types d'IA: - L'IA simulant le joueur. Dans le cas d'ECLERD, il s'agirai d'une IA qui simule le président du pays. Elle est souvent complexe à réalisée, et nécessite de bien comprendre comment les joueurs jouent. Elle peut se faire totalement à part du jeu. - L'IA in-game, n'existe pas sur ECLERD mais peut être le cas d'une unitée de n'importe quelle jeu de stratégie. Cette IA est aussi appelée "agent". Elle est souvent bête comme choux, et on ne peut pas vraiment parler "d'intelligence" artificielle: c'est plutôt un robot qui, quand il voit un ennemi par exemple, tire dessus. Ce genre d'IA est souvent codé in-game, c'est à dire en même temps que le jeu, car c'est une composante même du jeu. Elle ne remplace par un joueur. Souvent, le joueur l'utilise sans le savoir (cf l'exemple des unités d'un RTS) - L'IA émergente, involontaire sur ECLERD. Elle est souvent issue d'une conception du jeu, et n'est pas codée à proprement parler (au sens où il n'existe pas de ligne de code type "$mon_IA.doit_faire_ca($a_une_autre_IA);"). Elle représente souvent des comportements de jeu (exemple d'ECLERD: si la population n'a pas de travail, elle a tendance à quitter le pays). C'est une sorte d'IA-agent représentative du comportement d'un groupe d'IA-agents. Elle peut également émerger d'un code (dans ECLERD, les algorithmes utilisés font émerger des comportements épatant, dont celui de ne plus faire d'enfants, je ne sais pas du tout pourquoi). L'IA, la vraie (celle qui joue le joueur) n'est donc pas ta priorité et se codera une fois le jeu finit, quand tu sauras comment tes joueurs jouent. L'IA-agent se code pendant le jeu. L'IA-émergente se code durant la conception du jeu. -------------------------------------------------------------------- La sécurité peut faire l'objet d'un pan entier de forum. Le top 10 d'OWASP peut t'aider à trouver les failles de sécurité potentielle. J'en distingue deux grandes catégories: - Des failles de codage, typiquement, les injections de code. Ces failles sont dues à un mauvaise codage du jeu, elles sont généralement très graves (exécution de code arbitraire par l'attaquant) mais se corrigent facilement (ligne à recoder). Par exemple, j'ai une page web "www.machin.fr/?action=acheter&produit=pain&quantite=100": si je mets une quantité négative, est-ce que cela revient à vendre du pain au lieu de l'acheter? Ce comportement est-il pris en charge? - Des failles de conception, typiquement, le multi-compte: si mon jeu est conçut selon le dicton "l'union des comptes de jeu fait la force", que se passe-t-il si un joueur crée 100 comptes, alors que je croyais que 1 compte de jeu = 1 joueur? Les premières se corrigent avec une phrase très simple: ne jamais croire ce que l'utilisateur dit, ou si le serveur peut recevoir un paramètre de l'extérieur (autre site web, utilisateur, etc) alors le serveur DOIT vérifier la validité de ce paramètre. Les secondes sont bien plus dur à résoudre car elles requierent souvent de re-concevoir une partie du jeu. Le fait d'ajouter des lignes de codes pour éviter le multi-compte revient à mettre un morceau de scotch sur un tuyau de caoutchouc qui s'est mis à fuir: ca coule toujours, moins, mais ca coule. ------------------------------------------------------ Pour ma part, je code en PHP et ne voit aucune raison à ce qu'il deviennent "obsolète" pour la suite. De très nombreux sites utilisent PHP (exemple: http://www.rankspirit.com/langage.php ) Ne te focalise pas trop sur le langage quand même: une conception bien faite est une conception indépendante du langage, qui n'est que la traduction de la conception pour la machine. L'IA peut également être un système d'attaque aléatoire, qui choisit au pif qui attaquer, et qui envoie des troupes à peu près à force égale avec ce que l'IA attaque (pour pas dégouter l'attaqué: c'est un joueur, il peut être suiceptible, alors que l'IA s'en fiche). Exact, Malya, c'est un bon système pour apprendre: fais des projets à la taille de ce que tu connais déjà. Tu ne connais rien? Et bien, lances-toi dans un tout petit projet: faire une calculatrice en ligne par exemple. Après, tu monteras peu à peu. Là, j'attaque Reinom, mais avant, y'a eu ECLERD, avant, y'avait des sites classiques, avant, y'avait des bouts de codes comme un convertisseur franc-euros, etc. @niahoo: en quoi trouves-tu PHP limité? @Sephi: le Turc? quel Turc? Je ne suis pas pleinement d'accord avec toi d'ailleurs: on peut faire des projets webs sans aucune BDD, ou sans aucun outil extérieur. Certains projets requiereront des tiroirs, mais d'autres n'auront besoin que du grand carton de base qu'est le langage. Il faut commencer par réaliser un projet comme cela, sans aucun tiroir, puis ajouter les tiroirs un à un dans des nouveaux projets. C'est, je pense, le plus fiable aussi bien sur le court que sur le long terme. @Malya: UML peut être une bonne méthode de représentation (c'est d'ailleurs une norme) pour ta conception informatique. Inutile d'apprendre toute la norme: simplement connaître les principes des différents schémas (ce "langage" de conception est surtout fait de dessins et schémas) suffit (au début en tous cas). Après, quand tu voudras modéliser un truc plus complexe, tu te diras "zut, je sais pas faire ca en UML... je fais comment? Zouh, j'vais approfondir mes connaissances sur UML". @Sephi+Malya: Commence sans javascript. Ok, ca sera pas réactif, mais tant pis! Tu ajouteras ça plus tard. A mon avis, la bonne méthode est la suivante, s'il y en a une "bonne" (y'en a plein, légèrement différentes et toutes aussi valides, mais j'aime bien celle-ci): - UML => pour faire des bases de conception. Tu mettras alors par écrit des tas de projets, peut-être jamais réalisés, mais osef! - XML => Ca structure la méthode de pensée de HTML/DOM/SVG... tu trouveras plein de tutos sur w3schools - HTML => pour faire de la page web (html5 permet, de base, plein de trucs) - CSS => D'autres le mettent plus loin, je le met ici, car cela permet d'avoir un truc joli: c'est toujours motivant pour continuer ses projets - PHP => pour ajouter du dynamisme coté serveur, autre dit, pour ne plus envoyer continuellement le même contenu ("fond") au navigateur - Javascript => pour ajouter de la réactivité et améliorer l'xp utilisateur - Flash => Si on veut... au choix. Pour chaque langage, tu te fais quelques projets (de complexité progressive), et une fois que tu comprends et maîtrise un langage, tu passes au suivant. @Ter Rowan: Je rejoins ton principe de complexification progressive. C'est une excellente méthode d'apprentissage, mais aussi de développement. ------------------------------------------------ J'aime les pavés de texte !
PHP est limité parce que tu ne peux pas avoir l'état de ton jeu qui tourne tout seul. Tu es dépendant des requêtes des joueurs. Quand il n'y a pas de joueurs, le jeu ne bouge pas.
Et tu as 50 000 frameworks, c'est chiant. Ils font tous la même chose mais pas pareil, c'est pas forcément compatible. Et puis la syntaxe me soule a force parce qu'elle n'apporte pas d'innovations sympathiques. Mais pour faire un site web ça reste un outil que je maîtrise et que j'utilise avec plaisir quand même.
26-02-2013, 12:41 AM
C'est vrai, il faut des jeux dont la conception soit adaptée. D'un autre coté, le protocole HTTP est lui aussi basé sur les transactions ponctuelles... Et le principe quantique peut s'appliquer pour dire "tant qu'on ne s'est pas connecté sur un compte/tant qu'on n'a pas consulté un compte de jeu, on ignore son avancement", autrement dit, tant que personne ne "regarde" le pays/la ville/le n'importe-quoi d'un joueur, inutile de simuler son évolution.
26-02-2013, 04:57 PM
Et bien merci Xenos pour ce magnifique pavé (et les liens que je viens d'ouvrir). J'avais fait un post unique pensant justement que ce serait plus pratique, mais c'est aussi une erreur de ma part car je ne pensais pas à autant de solutions et de façons de faire (non mais j'ai beau vous lire, je pars toujours du "ça va être simple").
Au-delà de ce qui est de l'apprentissage, il me faut me poser des questions plus fondamentales et personnelles. Pour beaucoup, votre passion et aussi liée à votre métier, c'est loin d'être mon cas malheureusement. Si je me suis lancée dans la conception de jeu web, c'était justement pour pouvoir présenter quelque chose à une boîte de jeux vidéos, à défaut de diplôme. Après, j'ai en horreur de rester sur un échec (de toute façon c'est pas possible), donc je vais m'y lancer et apprendre de façon évolutive (c'est comme ça que je fonctionne de toute façon et je n'ai jamais eu à rougir de mes acquis, sortis finalement de nul part). Il y a de fortes chances que je "laisse tomber" mon jeu, ou que je garde la version papier pour des soirées entres amis et, dans plusieurs années si tout va bien, je pourrais faire des petits jeux. Ou, tout comme les forums rp, en créer que pour moi (ou mes amis), car je ne pourrais rien présenter d'exceptionnel. Il y a tellement de jeux sur le web, qui se ressemblent plus ou moins, que je n'ai pas envie d'en rajouter d'autres s'ils n'ont rien pour sortir du lot. Donc, parce que c'est vraiment une passion et que ça m'intéresse, je vais commencer comme tu le dis Xenos, et rajouter des tiroirs à mon petit meuble, et ne plus penser à un jour travailler dans ce domaine. En tout cas, merci pour votre patience ='D J'espère que, d'ici quelques années, vous serez fiers d'avoir mit au monde la bébé Malya ( XD)
26-02-2013, 06:37 PM
Commencer par un jeu, bon courage, à ta place je commencerais par un tout petit projet
Un gestionnaire de note, ou un jeu de morpion, etc
26-02-2013, 06:53 PM
Un jeu peut être petit (le morpion que tu cites est un petit jeu).
|
|
|
