Pardon double-post mais quel est le type de jeu qui est le plus simple a faire je ne parle pas de la 2 D ou 3 D mais quel type :
Exemple : FPS, action/aventure, RPG, beat´em all...
Merci d´avance
mon CPC 464 avait 64Ko de ram (mais ca devient serieusement HS comme post)
Itachiman: je penses que les jeux qui ne sont pas "temps réel" font plus simple a faire. En outre, faire un jeu reste un exercice difficile. Et je penses que pour un débutant, il ne faut pas chercher a faire entierement un jeu des le debut. Des petits programmes qui "ne servent a rien" seront plus pédagogique et te permeteront de progresser.
Si tu désire faire du C ou du C++ regarde du coté de NGCK de lapintade et du tutoriel de C++ (?) de Fvirtman (trouvable sur leur carte de visite respectif je penses ou alors dans la faq)
Je penses qu´un exercice interessant a moyen terme serait de faire en mode console un systeme de combat simplifier de type RPGmaker etc...
Je pense pas qu´il y ait de type de jeu plus ou moins simple a réaliser.
Mais certain qui s´oriente différement.
Par exemple pour un rpg, ca va etre très facile a programmer (pratiquement rien, combat tour par tour très peu de mouvement différent etc..) , mais ca va êtr très long.
Dans un rts il va falloir que tu apprenne a coder une I.A a faire un système de click souris. Mais le devellopement seras plus court.
Dans un fps, ce sera beaucoup de collisions (gestion des dégats explosion) avec de l´IA
dans un jeu d´aventure, ca va un peu tout regrouper (IA basique, collision basique, plus grand nombre d´action : saut, roulade etc....)
etc...
A toi de regarder ce qui t´intéresse et de faire une liste de tout ce que tu auras besoin de programmé. Et de choisir ce que tu préfère apprendre (3d, IA, collision, gestion d´une interface avancée etc...)
Je ne te conseil pas le traditionnel pac-man, parcque je pars du principe qu´on apprend très peu avec un jeu de ce type. Et si il faut en faire 50 pour maîtriser le language l´interêt est minime. Il vaut mieux choisir un type de jeux en ayant conscience du travail que cela implique et galérer sans doute plus pour le réaliser mais a chaque pas en avant c´est une joie immense ^^
voilà ^^
"Je ne te conseil pas le traditionnel pac-man, parcque je pars du principe qu´on apprend très peu avec un jeu de ce type."
Et pourtant ce sont sur des exemples simples qu´on apprend le plus (et mieux) ! Car le but n´est pas de réaliser le jeu en lui même mais d´apprendre les bases et les différents concepts qui entrent en jeu.
Si une personne débute, faire un jeu "normal" sera d´autant plus décourageant pour lui car il n´y arrivera de toute façon pas...
Quand on apprend la maçonnerie on commence pas par faire un immeuble, ni même une maison ... En général on t´apprend à te servir des outils et quelques travaux appliqués d´une échelle raisonnable. Idem en architecture on va pas te faire dessiner les plans d´une cathédrale (et encore moins la faire construire juste après).
Rien qu´avec pacman, puisque tu prends cet exemple, il y a déjà beaucoup à apprendre. Et même je dirai rien ne t´empêche d´y apporter ta touche personnelle et d´améliorer le concept, pacman ok c´est vu et revu mais un pacman revisité ? J´ai vu il y a pas très longtemps un "pong plasma machin", ben sincèrement toute la théorie des fluides qu´il y a derrière n´est pas à la portée des débutants bien que le jeu initial l´est entièrement.
Je ne suis aps de cet avis, car je part d emon exemple, je devellope un mmorpg en python , c´est mon premier projet python même si je possède des connaissances plus ou moins importantes dans d´autres language. Pourquoi je devellope cela? pour apprendre a maîtriser ce language, et develloper certain aspect qu´il m´interesse d´apprendre.
Je suis d´accord avec toi que c´est une galère de tout les instant sur certain point, par exemple la gestion des heightmaps, je suis resté un certain nombre d´heure a m´arracher les cheveux devant le problème, mais une fois ce problème résolu, la joie est tellement immense que la motivation est * par 100.
Je dit qu´il ne faut pas develloper un jeu style pac-man car si la personne ne trouve pas dans le concept du jeu ce qui l´interesse , il ne sera pas motivé pour le dévelloper.
Comme tu le dit si bien on peut revisté un jeu et c´est ce que je disais. Il faut savoir quel domaine de la programmation on désire apprendre (IA, 3d etc..) et après on peut décider de créer un jeu comportant ce que l´on veut apprendre. Ca peut être un pac-man ou autre chose.
On apprend bien plus en ne menant pas au bout un projet ambitieux qu´en réussissant un pac-man.
Et la maconnerie n´a aucun rapport avec la programmation, ici le futur programmeur est autodidacte sous succes ou echec n´aura de répercution que sur son expérience , contrairement au maçon.
Et il est parfaitement possible de réaliser un projet ambitieux si celui ci nous procure la motivation qu´il nécessite, et que la personne est désireuse d´apprendre tout les domaines qui aboutiront a la réalisation de son projet.
"je possède des connaissances plus ou moins importantes dans d´autres language"
on est bien d´accord ...
que j´ai eu de la même façon pour les languages que je maîtrise le plus (basic , darkbasic). Pour les autres cela n´a constitué qu´a bouquinner.
Pour l´allusion à la maconnerie c´est plus dans la manière d´aborder un projet que je faisais la comparaison. Car je considère la conception d´un jeu ou d´un logiciel de la même manière que l´on peut construire ou faire les plans du maison. De plus le nombre de personnes entrant en jeu par la suite est tout à fait comparable jeux vidéo/maison. Tu fais les plans de ta maison (entendre analyse du logiciel/jeu), tu commences à construire les fondations etc jusqu´aux finitions, interviendront les électriciens, les décorateurs, etc... Et puis c´est pas pour rien qu´on parle d´architecte logiciel ;)
Bon je peux prendre un autre exemple, si tu veux faire de l´escalade, ou de l´ascension en montagne tu vas t´attaquer à l´Everest tout de suite ? Pourtant le défi est sympa non ?
Non mais plaisanterie à part, c´est pas sur des projets énormes qu´il faut commencer. Quand quelqu´un commence à te poser la question "comment apprendre à programmer ? je veux faire un jeu ..." vaut mieux pas commencer à lui parler d´heightmap, IA, 3D ou je ne sais quoi.
La moindre des choses est de lui faire comprendre ce qu´est un langage, un compilateur (si ya besoin), etc... et s´il veut avoir des résultats rapides car la motivation s´entretient par des résultats CONCRETS !! j´insiste sur concret car avoir réussi à "passer" une routine, un bug ou comme dans ton cas le coup des heightmaps, ce genre de satisfaction n´est pas concevable pour un débutant. Alors s´il doit passer quelques heures pour réaliser quelquechose ou quelques mois je crois que le choix est vite fait
Surtout que l´on suppose que s´agissant d´un souhait fraîchement formulé, tu ne peux pas être sûr que la motivation sera toujours là dans 6 mois. Ca peut être très bien être un caprice du moment, histoire de passer le temps ou je ne sais quoi.
Je ne rejoins pas du tout ton avis slade991.
Tu te découragera de faire ton MMORPG au bout de quelques semaines (jours). Tout simplement parceque c´est TROP dur. Ca demande des connaissances en informatique qui dépasse la simple connaissance d´un langue de programmation.
Ecrire un pacman n´est déjà pas un exercice facil.
Je m´appuie (pour dire cela) sur NGCK. Une armada de débutant est venu nous demandé des conseil sur comment faire pour colorer seulement une case sur deux.
C´est déjà irréaliste de demander a un débutant de faire pac-man en premier projet. C´est déjà un projet extremement difficile.
En fin de premiere année universitaire (non info) on demande aux etudiants de faire un puissance 4. Sachant qu´on leur fournit tous les outils graphiques pour qu´ils ne travaillent que sur le probleme de fond. Ce n´est déjà pas un problème simple pour eux.
Faire un FPS est bien audela des capacités d´un débutant.
c´ets pour ca que la personne doit etre consciente de ce qu´elle veut faire. tout d´abord il est necessaire qu´elle se document (j´ai lu 370 pages avant d´attaquer le python) mais je pense qu´après il faut que la personne fasse quelque chose qui la motive vraiment peut importe ce que c´est.
Ensuite je suis d´accord que la conception d´une maison et d´un jeu sont similaire. Mais tu apprendras plus en concevant une maison qu´en construisant une niche. Et pour tes allusion sur l´escalade ce que je rappel c´est que quand le programmeur est autodidacte les seuls retombé de sons succès/echec seront sur son expérience personnel, ce n´est donc aps comparable. Tu n´as pas de risque réel a vouloir refaire un jeu-de-la-mort-qui-tue, contrairement au risque que tu as d´escalader l´Everest sans connaissance. Après libre au programmeur de faire un pac-man. Ce que je dit c´est que le projet doit motiver le programmeur. Si il faut un pac-man aprcque tout le monde lui a conseillé et que ca le fait chier il laisserait tomber beaucoup plus facilement que si il attaque un projet démesuré qui lui tient a coeur. Tout réside dans la manière de faire la chose.
Il doit se documenter apprendre des autres. Et une fois toutes les conseil en mains il pourra commencer son dévellopement.
On parle ici de pac man pour replacer le niveau technologique qu´on lui conseil de viser.
C´est a dire un jeu a un joueur (qui peu donc se jouer sans reseau) bi-dimentionel avec un monde coupé clairement en carré. En bref, un jeu simple.
Et peut être que son apprentissage passera par la réalisation d´un pacman lol
Tu ne peux pas avoir conscience du travail requis quand tu ne connais pas le domaine lui même.
C´est simple :
MMORPG : on va faire "simple". Soit une équipe de développeurs qualifiées on va dire 20 personnes (tout domaine confondu pour faire simple toujours) sur 2 ans de développement. Ca nous fait déjà du 40 années pour 1 seul homme en supposant qu´il maîtrise tous les concepts de la création : programmation, infographie, etc...
A raison de 35h par semaine dont 5 semaines de congès payés (je compte pas les maladies, les RTT et jours fériés) ca nous fait du 65800 heures de boulot. Si tu dois apprendre en plus on peut facilement multiplier par 3, 4 ou 5. Allez voyant large on multiplie par 5! Donc 329.000 heures de boulot ^^´ aie
Je ne rejoins pas du tout ton avis slade991.
Tu te découragera de faire ton MMORPG au bout de quelques semaines (jours). Tout simplement parceque c´est TROP dur. Ca demande des connaissances en informatique qui dépasse la simple connaissance d´un langue de programmation.
Ca ca m´étonnerais, ca fait d"jà un an que le projet existe (création du game design document)
et plus de 2 mois que je code. Et je me connais ne t´inquiète pas ;)
En ce qui concerne ton puissance 4. Je pense de toute manière qu´il faut posséder une "logique du programmeur". qui fait que quand on te dit un type de jeu la personne est capable d´avoir une approche au niveau du code et d´avoir une idée de comment le réaliser. Je ne pense pas qu´on puisse être codeur sans posséder cela. C´est la petite chose qui fait que a chaque fois que tu voit une appli tu as une théorie sur la manière dont elle a été conçut. Et tu n´acquiert pas cette logique sur un projet bateau.
MMORPG : on va faire "simple". Soit une équipe de développeurs qualifiées on va dire 20 personnes (tout domaine confondu pour faire simple toujours) sur 2 ans de développement. Ca nous fait déjà du 40 années pour 1 seul homme en supposant qu´il maîtrise tous les concepts de la création : programmation, infographie, etc...
A raison de 35h par semaine dont 5 semaines de congès payés (je compte pas les maladies, les RTT et jours fériés) ca nous fait du 65800 heures de boulot. Si tu dois apprendre en plus on peut facilement multiplier par 3, 4 ou 5. Allez voyant large on multiplie par 5! Donc 329.000 heures de boulot ^^´ aie
Alors ça totu d´abord c´ets le genre de raisonnement que je trouve nul au possible. Tu ne peut pas prévoir cela pour la bonne et simple raison que tu n´as pas idée de ce que comporte le jeu ni de la manière de le réaliser. Il se trouve que j´ai appris en dévellopant herdelia que la programmation propre d´un client de mmorpg n´est pas si longue que ça. Je m´explique.
En quoi ca consiste?
Une archi-client serveur : envoie, reception de donnée et stockage SQL. Tu va pas me dire que c´est long a faire. Envoie c´est une commande send(), receptuon c´est une commande receive() tu fait un algo pourri pour savoir ce qui est envoyé et recu et c´ets fait.
programmation 3D : Avec un moteur déjà fait, collision : elle se trouve directement sur le modèle (uniquement a les activer)
création d´un éditeur de map (ca prend pas longtemps non plus) tu sauvegarde ca dans un .txt qu´il retranscrit en position des divers objets sur la map. tu fait un algo qui active les sphère de collision sur chaque modèle chargé. On a fait le tour de la 3d.
Ia: système de respawn a points fixe ou random (ca change rien sur la longueur du code), tu gèère ca par le sql ca prend pas longtemps non plus. Chaque perso possède sa vie et divers carac enregistreé sous SQL et que tu send() quand le client en as besoin
Système de click sur objet: ca se fait en 10 ligne (je l´ai fait)
interface: tu n´en as pas pour bien longtemps non plus afficher des fenetre et activer des boutons c´ets aps la fin du monde.
Dit moi si j´ai oublier des choses.
"Dit moi si j´ai oublier des choses."
oui tu oublies de préciser le temps qu´il faut pour cerner les concepts de programmation SQL, de base de données, archi client serveur ? Je rappelle que l´on parle d´une personne souhaitant apprendre à programmer (enfin je sais plus en fait :S)
"Avec un moteur déjà fait, collision"
C´était supposé certes, mais faut il savoir utiliser le code de quelqu´un d´autre et là aussi quand tu débutes ce n´est pas du tout évident. C´est un très bon exercice en soi mais loin d´être évident.
"création d´un éditeur de map (ca prend pas longtemps non plus)"
Ca également ca se discute grandement ! Je doute fort que tu saches ce que ca nécessite comme boulot, dis plutôt que tu en utilises un déjà tout fait. Pour avoir quelquechose d´efficace et qui ne fasse pas perdre trop de temps. Je me demande bien pourquoi certain métier sont dédiés aux développement d´outils de ce genre (? peut être une lubie des équipes de dév?)
"Système de click sur objet: ca se fait en 10 ligne"
Même "seulement" 10 lignes c´est parfois très difficile pour un débutant et oui ... Un clic sur objet (en 3D qui plus est) ce n´est pas donné à n´importequi faut avoir des notions en 3D et déjà savoir comment intercepter les événéments souris.
Et j´en passe la liste est trop longue
pour goldrik un petit lien qui te prouve que ca fait un peut plus que quelques semaine(jours) que je travail dessus.
http://www.wizardsprgs.com/herdelia/forum/viewtopic.php?t=23&PHPSESSID=4be13bd695408893994f3e0b5c41bbdd#23
Et afin d´étayer ce que je dit je te propose de regarde le projet woveland. dévellopé par un seul homme depuis a peu près 2 ans. Qui est totalement opérationnel dans ce qu´on peut appeler la base d´un mmorpg.
Quète,magie, pnj,interface,combat, 3d, IA etc...
Une archi-client serveur : envoie, reception de donnée et
stockage SQL. Tu va pas me dire que c´est long a faire.
Envoie c´est une commande send(), receptuon c´est une
commande receive() tu fait un algo pourri pour savoir ce
qui est envoyé et recu et c´ets fait.
une architecture client serveur...
Et comment tu fais pour gerer cent mille joueur en meme temps ?
un serveur ne te suffira pas pour plusieurs raisons dont la plus importante sera un probleme de débit sur cable.
Il va donc te falloir gérer la cohérence de ton monde a travers les différents serveurs.
Il faut aussi ne pas envoyer toutes les informations a tous les clients.
parceque sinon, tu aurait besoin d´un debit collossal par client (et je ne te parle meme pas cote serveurs)
Il va donc te falloir gerer cela.
et lorsque tu as une rupture de ton debit reseau, tu ne peux pas vraiment te permettre de ne rien pouvoir afficher cote cleint, il te faut donc lui envoyer un peu plus de donnée qu´il n´a besoin. Mais pas trop, il ne faudrait pas surchargé le réseau.
Quand a la sauvegarde sur une base SQL...
C´est lent un access SQL
et ca risque en plus de poser des problemes de cohérence.
Tu va me dire tous les SGBD modernes proposent de bonne option de synchronisation, mais tu risque d´avoir besoin de plusieurs serveurs SQL (ne serait ce que pour backuper). Il faudra donc les synchroniser eux aussi...
Faire un ORPG c´est une chose. Faire un MMORPG en est une autre.
oui tu oublies de préciser le temps qu´il faut pour cerner les concepts de programmation SQL, de base de données, archi client serveur ? Je rappelle que l´on parle d´une personne souhaitant apprendre à programmer (enfin je sais plus en fait :S)
Je partant bien entendu du fait que la personne connaissait cela. Mais ca ne va pas rajouter 20 ans au devellopement
C´était supposé certes, mais faut il savoir utiliser le code de quelqu´un d´autre et là aussi quand tu débutes ce n´est pas du tout évident. C´est un très bon exercice en soi mais loin d´être évident.
Cela rajoute uniquement des librairies a utiliser et de nouvelles fonction bien souvent expliqué sur le site du moteur.(apprentissage couplé a celui du language)
Ca également ca se discute grandement ! Je doute fort que tu saches ce que ca nécessite comme boulot, dis plutôt que tu en utilises un déjà tout fait. Pour avoir quelquechose d´efficace et qui ne fasse pas perdre trop de temps. Je me demande bien pourquoi certain métier sont dédiés aux développement d´outils de ce genre (? peut être une lubie des équipes de dév?)
Non je n´utilise pas d´éditeur, pour l´instant je place par le code. Mais je vais dévelloper cela d´ici peut. ET pour la lubie des equipe de dev, parcque tout simplement dans une équipe proffesionnel chaque domaine est géré par une personne différente, afin que les choses soit le plus parfait possible, ce qui n´est pas necessaire dans un dévellopement amateur.
Même "seulement" 10 lignes c´est parfois très difficile pour un débutant et oui ... Un clic sur objet (en 3D qui plus est) ce n´est pas donné à n´importequi faut avoir des notions en 3D et déjà savoir comment intercepter les événéments souris.
Tout s´apprend je ne savais pas le faire il y a deux semaines.
Bref de toute manière, je conclurais en disant que une fois que l´on possède une certaine logique on peut dévelloper ce que l´on veut.
Et je te signale que le plus long dans le devellopement d´un mmorpg ce n´est aps le code. Mais la multitude de document a fournir/Ecrire ,quètes npc etc...
Ainsi que la foule d´objet 3d a concevoir.
une architecture client serveur...
Et comment tu fais pour gerer cent mille joueur en meme temps ?
un serveur ne te suffira pas pour plusieurs raisons dont la plus importante sera un probleme de débit sur cable.
Il va donc te falloir gérer la cohérence de ton monde a travers les différents serveurs.
Il faut aussi ne pas envoyer toutes les informations a tous les clients.
parceque sinon, tu aurait besoin d´un debit collossal par client (et je ne te parle meme pas cote serveurs)
Il va donc te falloir gerer cela.
et lorsque tu as une rupture de ton debit reseau, tu ne peux pas vraiment te permettre de ne rien pouvoir afficher cote cleint, il te faut donc lui envoyer un peu plus de donnée qu´il n´a besoin. Mais pas trop, il ne faudrait pas surchargé le réseau.
Quand a la sauvegarde sur une base SQL...
C´est lent un access SQL
et ca risque en plus de poser des problemes de cohérence.
Tu va me dire tous les SGBD modernes proposent de bonne option de synchronisation, mais tu risque d´avoir besoin de plusieurs serveurs SQL (ne serait ce que pour backuper). Il faudra donc les synchroniser eux aussi...
Faire un ORPG c´est une chose. Faire un MMORPG en est une autre.
Je tiens a préciser qu´on parlait uniquement de programmation et non de matériel.
LA programmation est une chose les ressources physique a mettre a disposition en sont une autre.
Et il va de soi qu´un jeu permettant la connexion de 100 ou 200 client est pour moi un mmorpg. 100 ou 200 connexion sont toutes a fait gérable sur une bonne machine avec une bonne connection. Si on arrive a bien optimiser les envoies client-serveur.
Bref de toute manière, je conclurais en disant que une
fois que l´on possède une certaine logique on peut
dévelloper ce que l´on veut.
Dans un premier temps, je dirais que cette logique il faut l´acquérir. Et que ce temps d´apprentissage varie d´une personne a l´autre. Pour certain c´est inné. Pour d´autre C´est 6 mois de travail a plein temps.
Ensuite, cette logique ne suffit pas. Pour la simple et bonne raison qu´il y a des problemes extrement compliqué. Il faut des notions de maths pour certaines choses. De physiques pour d´autre. D´algorithmie dans certain cas.
Il y a bien des choses que tu ne peux pas inventer en quelques minutes. Ce genre de projet est extrement consomateur en ressources: de calcul, mémoire, réseau, disque. Ce sont des contraintes avec lesquels il faut apprendre a travailler.