Voilà, je voulez pousser mon premier coup de gueule de l'année contre nos chers éditeurs (de livres) qui contribuent, très involontairement, à mon avis, à la rareté des jeux libres. En effet, je cherche à m'essayer au développement de jeu (on à quand même le droit de faire ce qu'on veut de son temps libre non!!!).
Donc après quelques recherches très infructueuses sur le net, j'ai pensé m'acheter un livre et, à mon grand désespoir, aucun livre que j'ai pu trouver ne traite de la programmation de jeu avec des API libres et sur autre chose que Windows.
Après ça, il ne faudra pas s'étonner qu'il y est si peu de jeu sous Linux, en effet je ne compte pas apprendre à faire un jeu en utilisant DirectX pour ensuite essayer de tout porter sur SDL ou je ne sais quoi d'autre tout ça pour faire un malheureux casse brique sous GPL ou autre...
Journal Programmer des jeux sous Linux...
2
jan.
2006
# a voir
Posté par B16F4RV4RD1N . Évalué à 4.
Ensuite, si tu cherches en anglais, peut être peux tu trouver plus de choses. Je viens par exemple de voir cela :
http://www.amazon.com/gp/product/1886411492/002-6374413-9876(...)
(plus de détails : http://freshmeat.net/articles/view/310/ )
j'ai vu cela aussi :http://cgi.ebay.ca/SDL-Fast-Easy-Game-Development-Programmin(...)
enfin, si tu cherches à te faire la main sur un jeu que je n'arriverais jamais moi même à coder (enfin, pas pour le moment) :
http://linuxfr.org/~farvardin/20448.html
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: a voir
Posté par Krunch (site web personnel) . Évalué à 6.
https://linuxfr.org/2002/10/25/10111.html
http://csx.calvin.edu/JSPWiki/attach?page=GameSIG%2FProgramm(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# hum...
Posté par Francois COJEAN . Évalué à 5.
La documentation de SDL par exemple est très bien fourni je trouve.
[^] # Re: hum...
Posté par mcjo . Évalué à 2.
Bien entendu, je n'ai pas dit qu'il était insurmontable de voir des aspects sur un type de bibliothèque et de l'adapter grace au doc de l'API sur laquelle on compte développer notre jeu. Mais pour moi le problème est principalement une question de temps car comme beaucoup de monde je travaille et donc je ne peux y consacrer que mon temps libre.
Mais ce coup de gueule c'était juste pour dire que la programmation de jeu avec des API entièrement libre demandait 3 fois plus d'effort pour un débutant par rapport à ce que l'on trouve dans le monde propriétaire.
[^] # Re: hum...
Posté par un_brice (site web personnel) . Évalué à 8.
Par exemple, avoir des moteurs 3D et physiques, et même des moteurs de jeux, tout faits doit aider. D'ailleurs Ogre à l'air pas mal documenté, même si j'y connais rien.
Et si tu cherche à faire un n-ième FPS/RPG/... autant participer à un qui existerait, où au moins à le forker pour pouvoir implémanter tes idées sans réinventer la roue.
# Livres sur le développement de jeu sous Linux
Posté par Bruno Ethvignot (site web personnel) . Évalué à 6.
http://linuxfr.org/2002/10/25/10111.html
Le livre est un peu ancien mais cela peut donner une idée.
Je pense qu'il faut bien distinguer deux choses.
Premiérement l'apprentissage d'une API, que ce soit SDL, Clanlib ou OpenGL. Ces accès à l'API représentent finalement qu'en faible partie du jeu.
Deuxièment les algorithmes plus général utilisés par les jeux. Par exemples les techniques décrites dans les livres « Game Programming Gems » fonctionnent aussi bien sur Fenêtre(r) que sur notre système favori Linux :
http://www.gameprogramminggems.com/
Sinon tu peux commencer à bidouiller les nombreuses sources de jeux libres existantes sous Linux. Trouve le jeu le plus proche de ce que tu veux faire et va voir comment c'est fait.
Pour les casses briques par exemple tu peux voir les sources du célèbre LBreakout2 :
http://lgames.sourceforge.net/index.php?project=LBreakout2
Ou Briquolo un casse brique en 3D :
http://briquolo.free.fr/fr/
Ou encore TecnoballZ le casse briques que j'ai développé :
http://linux.tlk.fr/games/TecnoballZ/
# Moi aussi je préfère débuter avec un livre sur les genoux.
Posté par blobmaster . Évalué à 4.
Est-ce que je dis qu'ils ont raison ? Non. Je suis sûr qu'il est mieux d'avoir un bon bouquin pour apprendre plutôt que de basculer d'une fenêtre à l'autre; car le livre on peu le feuilleter avec le code que l'on apprend sur l'écran. On a donc sous les yeux le cours ET l'exercice.
Maintenant il y a sûrement des gens qui aime apprendre avec un cours sur l'ordi et qui bascule (sans tourner la tête) d'une fenêtre à l'autre ou qui ont un écran panoramique ou 2 écrans...
Du coup peut-être que le marché n'est pas suffisant '(
# Programmer des jeux...
Posté par tene . Évalué à 0.
(à mon avis, pas grand chose, si ce n'est la priorité dans les dev, et évidemment le côté artistique, mais tu t'intéresses bien à la programmation? ou alors peut-être ton post couvre également l'absence éventuelle de bouquin sur le graphisme, le son, etc... sous linux?)
ps: je n'ai aucune idée de l'abondance ou non de livre concernant le son/graphisme/... sous linux, j'essaie juste de situer le débat!
[^] # Re: Programmer des jeux...
Posté par ahuillet (site web personnel) . Évalué à 8.
Rapidement, juste ce qui me vient à l'esprit :
- contrainte de temps (un jeu vidéo c'est du temps réel généralement)
- grand consommateur de puissance (temps CPU, carte graphique, tout ça ...)
- demandeur de beaucoup de ressources différentes (son, graphisme, entrée/sortie asynchrone, etc.)
Bref c'est très différent d'écrire un jeu et une application système :)
[^] # Re: Programmer des jeux...
Posté par Larry Cow . Évalué à 5.
Ce n'est pas ce qu'on appelle du temps réel en informatique, mais je vois l'idée.
Bref c'est très différent d'écrire un jeu et une application système :)
C'est sur qu'entre un jeu et un my_ls ou un my_malloc, il y a un monde. En même temps, il y a le même monde entre un my_ls et un serveur de messagerie, ou un erp, ou un gestionnaire de fenêtres, ou un éditeur de son, etc. (j'ai choisi volontairement des types de projets pour lesquels le libre fournit plusieurs solutions distinctes).
Je crois que seule la problématique des ressources (graphismes et sons) est réellement spécifique au jeu et problématique pour le libre. Et encore, cela ne s'applique qu'aux jeux dits "modernes". On peut tout à fait faire un jeu original et intéressant sur un concept abstrait facile à illustrer (Kiki the Nanobot, Pathological, Oxyd/Enigma, ...). C'est certain que pour faire un digne concurrent de ... (ben merde, en fait je connais aucun titre de jeu actuel), il y a du boulot.
Mais faire des jeux, c'est tout-à-fait possible avec des moyens réduits. Il faut juste trouver une bonne idée. L'ennui étant que lorsque tu demandes à quelqu'un une idée de jeu vidéo, il va (dans 99% des cas) te proposer un clone d'un type de jeu connu. Autant à l'échelle d'un éditeur de jeu qu'à celle d'un particulier, on préfère instinctivement passer du temps sur quelque-chose dont le succès a déjà été éprouvé. Sauf qu'avec ce genre de raisonnements on n'aurait jamais connu Tetris.
[^] # Re: Programmer des jeux...
Posté par tene . Évalué à 2.
Comme bcp d'application, depuis le correcteur d'orthographe de ton traitement de texte en passant par une appli de bourse, etc... Cependant, je suppose que tu parles principalement de la partie graphique, dans ce cas, c'est en partie vrai, les applis deviennent seulement de plus en plus riche et dynamique, ça ne fait que commencer. On peut voir cette tendance avec des outils tel que flex, ajax, winfx, le bureau composés (osx, vista, les dernières versions de X, etc...). Toutes les applications qui manipulent des données graphiques sont également de la partie (imagerie médicale, représentation physique/chimique, outil d'édition 3D, etc...). C'est également le cas de toutes les applications gagnant en "intelligence" (IDE avec completion syntaxique par exemple, ce n'est pas trivial de parser du code incorrect, d'en extraire une structure et de la présenter à l'utilisateur tout en restant fluide!).
- grand consommateur de puissance (temps CPU, carte graphique, tout ça ...)
Comme énormément d'outil professionnel, tu ne crois pas? Cependant je suis d'accord avec toi sur un point, l'utilisation des derniers pixel/vertex shader, c'est rare dans une appli financière ;) Mais bon, j'ai l'impression que c'est commencer à l'envers, même si c'est fun, développer un jeu demande pas mal de compétences autres, avant de se concentrer sur l'optimisation d'un ps.
- demandeur de beaucoup de ressources différentes (son, graphisme, entrée/sortie asynchrone, etc.)
D'un autre côté, côté "code" y'a pas tellement de resources différentes, en gros: mémoire, socket, fichier (en oubliant le fait que sous unix presque tout est fichier;). Les jeux sont généralement peu multithread (c'est normal, c'est compliqué;).
Sinon prends une appli que tu utilises (genre ton navigateur web) elle utilise également du son (peu) des graphismes, des I/O (asynchrone), etc...
Evidemment si tu compares à un outil en ligne de commande, le jeu impressionne plus... cependant, j'ai l'impression que ce n'est pas tellement différent (côté programmeur!!! pas artiste!), j'ai même souvent l'impression que le jeu vidéo permet parfois plus d'approximation (un algo critique de calcul de taux de change dans un jeu vidéo aura probablement moins d'impact que celui d'une banque).
Enfin reste le problème principal n°1: l'idée et le n°2: les jolis dessins/sons qui vont avec (parce qu'un jeu moche, ça marche pas souvent).
[^] # Re: Programmer des jeux...
Posté par ahuillet (site web personnel) . Évalué à 4.
Pas à la même échelle ! Un jeu vidéo est pratiquement une application temps réel "comme on l'appelle en informatique" (pour faire plaisir au monsieur au-dessus).
Les conséquences sont pas très importantes mais la bonne marche d'un jeu vidéo repose très lourdement sur la précision des timers.. Sur un bloc-notes, tu peux ne pas être schedulé pendant 100ms sans que l'utilisateur s'en rende compte. Sur un jeu vidéo ... plus dur :)
Sans compter que la plupart des jeux vidéo travaillent une couche en dessous des applications GUI graphiques (pas de gestionnaires de fenêtre parce que accès "direct" à la mémoire vidéo).
Rien à ajouter :) Mais ce n'est pas une différence négligeable ...
Concernant les ressources, je suis désolé, mon navigateur n'utilise pas de son, pour les graphismes il ne consomme pas grand chose (au hasard, pas de page flipping, pas de dessins bizarres avec des fonctions trigo ou je ne sais, etc.).
Là où je voulais en venir sur les deux derniers points est qu'un jeu vidéo utilise souvent _toute_ la machine, alors que ce n'est pas le cas de la plupart des programmes. La différence au final ? Bah peut-être pas si énorme que ça en définitive, simplement que ce qui est intense pour la machine est intense pour le programmeur dans le cas qui nous intéresse :p
[^] # Re: Programmer des jeux...
Posté par tene . Évalué à 3.
Cependant, j'ai l'impression que ce dont tu parles c'est plus l'informatique des année 80 (et début 90), peu de mémoire, petit CPU, l'assembleur était maitre, les cartes 3D n'existait pas, etc... la belle période des demo-makers, les amiga (bcp mieux que les ataris), enfin l'informatique fun... ou tu passais 4 jours sur l'optimisation de 15 opcodes parce que c'tait fun... Et ce mode de développement était valable pour les jeux, les démos mais également les applications (rien que la façon dont était pensé la mémoire de cher pc en est la preuve), un des vestiges de cette air que bcp de gens subissent tous les jours, c'est windows, certaines crasses (gestion de handles, limitation GDI, etc...) subsitent encore plus ou moins...
Aujourd'hui, on parle moins de cela (regarde quel PC il te faut pour jouer à Doom 3 ou Quake 4 ;), par contre on parle de portabilité, de qualité graphique (et pas de qualité d'effet graphique), d'utilisabilité, de communauté (vous connaissez combien de jeux commerciaux qui ne vous en parle pas?), etc... et à nouveau c'est vrai pour les jeux vidéos comme pour le reste des applications... même les performances ont tendances à devenir scalability (peu importe le temps de traitement de ta requête web faut juste en gérer bcp à la seconde, peu importe le temps d'affichage d'un polygone tant que tu sais m'en mettre des millions dans la gueule par seconde...)....
En bref "c'était mieux avant"©® Sur ce je retourne gacher de la mémoire avec un algo np-complexe codé comme un goret en J2EE tournant sur un 4 cpu à 4 chiffres...
[^] # Chipotage
Posté par Thomas Douillard . Évalué à 3.
# Mon expérience
Posté par ahuillet (site web personnel) . Évalué à 2.
En ce qui concerne Allegro que je connais bien, les débutants sont en fait assez rares et se forment plutôt via le site de la communauté, IRC et les mailing-lists qu'en lisant des articles aussi complets soient-ils.
Maintenant, pour avoir débuté, moi aussi et comme à peu près tout le monde, sans bouquin (puisqu'il n'y en a pas vraiment ...), je peux te dire que j'en suis pas mort, et l'excellente documentation des diverses API est dans la plupart des cas largement suffisante.
Un peu de google, beaucoup de volonté, et le manuel de ta lib sous le bras suffisent. Évidemment tu "réinventeras la roue" mais je crois que c'est souhaitable pour se former.
# Pygame?
Posté par Larry Cow . Évalué à 3.
[^] # Re: Pygame?
Posté par Gniarf . Évalué à 2.
http://linuxfr.org/~Gniarf/17685.html
sources sur http://sam.zoy.org/monsterz/
# Oui, mais...
Posté par Anonyme . Évalué à 4.
Néanmoins, tu te rendra vite compte que la doc ne manque pas, si tu sais où chercher.
Pour créer un système de jeu complet, il te faut au strict minimum:
- Une gestion de fenêtrage/contexte graphique (SDL, glfw, la lib X11...) ;
- Une API graphique supporté par le hardware (oublie le rendu software si tu veux faire de vrais jeux, et pas des progs expérimentaux): OpenGL ;
- Une API audio (OpenAL) ;
- Une gestion input (généralement intégrée au gestionnaire de fenêtrage) ;
Tout le reste (réseau, ia, maths...) peut-être bidouillé par toi tout seul.
Or une fois les bases apprises (tu trouveras des exemples un peu partout sur le net, comme par exemple sur NeHe pour OpenGL), il ne te faudra que les documentations de référence pour avancer.
Le reste, ce sont des méthodes de conceptions, d'architecture. Dans ce domaine, les livres `Programming Gems {1,2,3,4,5}` sont un must. J'ai pu lire le 4, et viens de commander le 5. es méthodes sont la plupart du temps applicables sous Linux comme sous Fenêtre(C).
Sinon, évidemment, si tu veux juste t'amuser et faire de petits jeux d'arcade, tu peux te rabattre sur des langages comme le python ou le perl, mais pour un jeu de haut-niveau, oublie :)
# Et faire un bon jeu...
Posté par farib . Évalué à 2.
-comment trouver un concept original
-comment faire du design level
-comment faire un bon scénario
-comment créer une ambiance
etc...
C'est un peu ça qui compte aussi.
L'exemple parfait, en ce qui me concerne, c'est GTA 3/Vice/San Andreas. Des graphismes pourris (merci la PS2), un moteur buggué, mais les meilleurs jeux du monde AMHA.
[^] # Re: Et faire un bon jeu...
Posté par _seb_ . Évalué à 2.
-comment faire du design level
-comment faire un bon scénario
-comment créer une ambiance
Sur Nekem, il y a de plus en plus d'information pour les jeux libres.
A voir:
http://planet.nekeme.net/
http://www.nekeme.net/index.php/Accueil
En ce qui concerne le concept original, le jeu Gobelins (http://gobelins.nekeme.net/) me parraissait vraiment interressant (et aussi extrêment difficile à réaliser).
Pour le design level, seule l'exprience permet de faire les choses correctement. Les developpeurs Open Source ne sont pas en manque de ce côté là, je pense.
Créer une ambiance, c'est avant tout une histoire, des graphismes, etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.