 |
Vendredi 19 avril 2024 - 02:28 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Créez votre jeu... et devenez milliardaire en dollars ! La programmation fascine toujours autant les possesseurs de micro. Pas facile cependant de se lancer dans l'aventure quand on est débutant. Tilt dévoile point par point les étapes de la création d'un jeu et répond à toutes les questions que vous pouvez vous poser.
Se lancer dans la programmation
Pour beaucoup, l'ordinateur se résume à une simple machine de jeux. Pourtant, il est en mesure de réaliser bien d'autres choses et les sphères d'application ne manquent pas. Celle qui, à l'évidence, inspire le plus de respect, est certainement la programmation ; elle laisse rêveur bien des amateurs de micros qui aimeraient en faire autant, mais... Mais quoi ? Programmer n'est pas si compliqué que ça ! C'est possible, tout simplement possible et notre but est de vous indiquer les chemins à suivre pour y parvenir.
Mais au fait, qu'est-ce que la programmation ? D'après la définition du Petit Robert, il s'agit de "l'élaboration et codification de la suite d'opérations formant un programme" et un programme est un "ensemble ordonné (et formalisé) des opérations nécessaires et suffisantes pour obtenir un résultat". Autrement dit, la programmation sur ordinateur consiste à mettre en oeuvre un certain nombre d'instructions afin de parvenir à un résultat défini auparavant. Ce dernier conditionne du reste l'ordre de déroulement des instructions, la manière séquentielle dont elles sont exécutées. Cela montre bien qu'il existe une véritable méthodologie de la programmation qui consiste à se fixer un but à essayer de l'atteindre. Dans la réalisation d'un jeu, cela se concrétise par une première étape : la création d'un scénario.
De l'évolution des jeux...
Depuis une dizaine d'années, l'explosion du marché des micro-ordinateurs a été accompagnée d'une non moins fulgurante progression : celle du logiciel. Indispensables aliments des ordinateurs, ils sont, au même titre que le matériel, sujet à une évolution qualitative. Comment ne pas être enthousiasmé par la qualité et la vitesse d'apparition de nouvelles applications professionnelles ? Néanmoins, force est de constater que le domaine du jeu semble être le laissé pour compte de cette évolution. Depuis deux ans, voire trois, nous assistons à un étrange piétinement dans l'univers du jeu. Comment expliquer l'espace grandissant entre performances des machines et conformisme anesthésiant des jeux qu'elles disposent ?
Dans le domaine des jeux d'arcade, par exemple, le prétexte d'être des jeux d'action est un alibi facile pour les flopées de jeux de tir qui ne sont en définitive que des réadaptations de Galaxian, Phoenix ou de Bruce Lee ! Avec de bien meilleurs graphismes et sons, il est vrai. Les innovations marquantes telles que Battle Zone (1982) ou Star Wars n'ont pu être vraiment dépassées, si bien qu'Il règne actuellement une étrange sensation de tourner en rond. Ce ralentissement dans la venue de concepts de jeux réellement novateurs s'explique en partie par la complexité grandissante des machines actuelles. Les huit bits disposent d'une électronique légère et accessible, comparée à celle des seize bits.
Cela a permis à de nombreux mordus de se transformer en véritables démiurges du logiciel. Les barrières entre volutes de l'imagination des programmeurs et rigidité de l'électronique étaient réduites à leur plus simple expression. Bref, chaque mordu pouvait potentiellement être à l'origine d'un nouveau genre de jeu sur micro. La complexité actuelle des machines seize bits, leur manque de transparence en termes de programmation coupent de plus en plus la micro-ludique de son seul véritable moteur : l'imagination. Par ailleurs, le renouvellement des idées bute souvent sur le relatif confinement des équipes de programmeurs généralement issus des huit bits. Et nous ne parlons pas de l'impitoyable logique commerciale dont font preuve nombre d'éditeurs, qui pensent que le développement d'un jeu classique est moins coûteux puisqu'il suffit, dans la plupart des cas, de récupérer pour l'énième fois une routine de défilement ou de tir laser.
A la lumière de cela, on comprend la nostalgie des "routiers" de la micro. Les marques de machines beaucoup plus nombreuses, l'apparition de nouveaux éditeurs tous les mois, caractérisaient le bouillonnement de la micro d'il y a quelques années. Les programmeurs parvenaient à faire de véritables miracles avec leurs ordinateurs. Les accros de l'Apple II se rappellent avec nostalgie cette époque, et les anciens possesseurs de ZX 81 restent rêveurs à l'idée que certains soient parvenus à stimuler la haute résolution par logiciel (192x256 points) sur une machine qui, en mode graphique standard, n'affichait que 44x64 points ! Cette maîtrise des machines permit l'élaboration de principes de jeux, d'algorithmes et de techniques de programmation ayant toujours cours.
C'est là tout le drame de l'histoire. Malgré une augmentation considérable des performances des machines, malgré des mémoires vives dix à vingt fois supérieures, malgré les microprocesseurs seize bits, malgré les coprocesseurs spécialisés pour la gestion des graphismes et des sons, la production de logiciels ludiques ne s'est, pour l'essentiel, améliorée que sur des points de détails. Les programmes actuels sont plus évoluées graphiquement, mieux sonorisés et disposent de défilement plus rapide, mais ils n'apportent que trop rarement d'innovation conceptuelle et n'ajoutent pas forcément un plus grand plaisir de jeu !
Tout se passe comme si tous les types de jeux, ou presque, avaient été formalisés, il y a plusieurs années, à l'apogée des huit bits et que désormais les changements ne portent que sur des aspects superficiels. L'argumentation se limite de plus en plus à un défilement plus rapide, à une fréquence de tir plus élevée, à la taille des sprites.
Le scénario
Ce que nous venons de voir ramène au problème du scénario. Point de départ de tout programme, il se doit de sortir des sentiers battus. Lorsque nous disons cela, nous ne pensons pas à l'histoire du jeu, à son prétexte en quelque sorte, mais bel et bien aux principes de base présidant à l'élaboration du programme et ce, dans un style donné (arcade, aventure, etc.) ou mieux, à la création d'un nouveau style de programmes !
Admettons que vous ayez dans l'idée de faire une sorte de Pac-Man en remplaçant le Glouton par un vaisseau spatial, les fantômes par des envahisseurs venus d'un autre monde, etc. Désolé, mais votre scénario n'a vraiment rien d'original ! Il retombe sur des principes que l'on rencontre trop souvent. Il faut se mettre dans la tête que scénario recouvre bel et bien deux notions : les principes de base (qui recouvrent style et type) et l'histoire. Celle-ci est généralement assez simple à trouver et peut, dans certains cas constituer le principe de base du programme. C'est le cas pour les jeux d'aventure, éventuellement pour certains jeux de guerre ou jeux de rôle. La force de ce type de programmes réside bel et bien dans l'histoire et non dans les principes de bases originaux.
Évidemment, on peut faire un jeu d'aventure original dans un style donné. Mais il ne sera pas original au sens du type de jeu, des principes de base utilisés. CQFD ! Ne commettez pas l'erreur, de croire qu'un scénario original offrant un principe novateur complique la réalisation du programme. Un exemple le montre parfaitement : Tetris. Voici un logiciel conçu en URSS, relativement simple à programmer, offrant un divertissement inconnu jusqu'alors et dont le succès ne fait plus de doute pour qui que ce soit ! Il en est de même pour Sentinel. Bien que ce programme mette en oeuvre des algorithmes 3D, il n'est pas d'un niveau de sophistication extrême...
Voici donc les principes de base posés. Toutefois, cela ne résout pas la question que vous êtes en train de vous poser, là, maintenant... A savoir : comment écrire un scénario ? Je suis assez tenté de vous répondre avec un stylo et du papier mais ce n'est qu'une expression limitée de ma pensée présente... Il faut comprendre qu'il n'existe pas de méthode absolue pour l'écriture d'un scénario (en dehors du stylo). Chaque programmeur utilise ses propres méthodes, ses trucs de métier. Toutefois, je vais vous présenter la mienne. Elle vaut ce qu'elle vaut mais au moins elle a le mérite de marcher...
Histoire de simplifier ce que nous allons exposer, imaginons que nous désirions créer un programme dont le principe de base est le suivant. Le joueur pilote un personnage à l'écran qui doit manger sans cesse jusqu'à éclater de rire et ce en un temps limité. Au passage, je signale que ce principe de jeu n'a pas encore été mis en oeuvre à ma connaissance. Ce qui est tout de même la preuve qu'en cherchant quelques instants... A partir de cela, explorons les diverses possibilités que nous offre cette idée. Compte tenu du facteur temps, il est nécessaire d'introduire une certaine dose de stratégie, afin d'obliger le joueur à réfléchir sur le parcours qu'il doit effectuer, sinon notre jeu serait finalement peu attrayant. On pourrait imaginer que la base que nous venons d'exposer amène un Pac-Man (la stratégie peut être amenée par des poursuivants). Mais il n'en est rien ! L'élément stratégie sera ici dépendant du tracé des tableaux. En passant par tel ou tel endroit, on se trouve bloqué pendant x temps par des trappes, etc. Je vous laisse imaginer le reste car les dérivés possibles sont nombreux.
A partir de cet instant, le mieux est de mettre sur papier les diverses idées, éventuellement de réfléchir à des tracés possibles. Il s'agit déjà d'une première approche que nous complétons en réalisant des dessins des divers écrans que l'on désire obtenir. N'oublions pas que l'aspect graphique est des plus importants en matière de jeux. Mais ne vous laissez pas non plus obnubiler par celui-ci aux dépens du reste ! Il est donc logique de retenir, dès le départ, les représentations graphiques possibles de notre héros et de son univers. Compte tenu du sérieux de l'idée de base, on est plutôt tenté par des graphismes exprimant une certaine drôlerie.
Parvenu à cette étape, il ne reste plus qu'à... penser au joueur ! Il est vrai que certains programmeurs oublient trop souvent l'agrément. N'avez-vous jamais râlé contre tel ou tel jeu qui nécessitait moults accès disque avant de continuer ? Pensez aux écrans de présentation, aux enchaînements des diverses phases de jeu et même à une possible illustration musicale. Bref, de scénario, nos pages griffonnées deviennent véritable cahier des charges...
Au fait, n'oubliez pas de penser au titre ! En ce qui nous concerne, nous avons choisi "Pince Sans Rire" pour notre jeu exemple. Bref, il ne reste donc plus qu'à mettre en pratique ce que nous avons décrit dans le cahier des charges. Notez que plus il sera précis, moins vous aurez de problèmes pour parvenir à l'étape suivante : établir un préprogramme, autrement dit un organigramme !
De la théorie à la pratique
Certains ne les utilisent pas, d'autres ne jurent que par eux, une seule chose est sûre : les organigrammes sont compréhensibles par tous. De plus, c'est le seul "langage" facilement transposable sur n'importe quel ordinateur et en n'importe quel langage. Mais au fait, un organigramme c'est quoi ? En informatique, il s'agit d'une représentation graphique normalisée décrivant le fonctionnement d'un programme. Autrement dit, on représente sous la forme d'un schéma, les diverses étapes nécessaires au programme pour atteindre son but.
Cette représentation respecte, de plus, la chronologie de l'exécution des instructions. Facile à mettre en oeuvre, ce système fait tout simplement appel au bon sens. Prenons un cas concret : Pince Sans Rire, par exemple. Étudions de manière logique ce que nous voulons faire. Le joueur pilote un personnage à l'écran. Il nous faut donc une routine de gestion des actions sur les touches de commandes, ici la manette. De la même manière, comme notre personnage bouge à l'écran, nous avons besoin d'une routine d'animation. Tout cela ne suffit pas puisque notre héros se déplace dans divers parcours marqués par des zones non franchissables sur lesquelles le personnage bute. Solution : un test de collision !
On commence à voir un schéma de base se dessiner mais une question reste entière... Comment organiser les relations entre les diverses routines ? Il est évident que l'on peut le faire de plusieurs manières mais pourquoi faire compliqué alors qu'il est si facile de faire simple ? La meilleure solution est de commencer par la gestion de la manette (on teste si le joueur actionne ou non une touche de commande), ensuite on vérifie si cette demande est autorisée (le test de collision) puis on affiche le résultat (routine d'animation ou effet sonore si le déplacement n'est pas possible). Voici donc notre trame de base définie et il ne reste plus qu'à fignoler...
Certains éléments sont, en effet, absents de ce que nous venons de décrire comme le facteur de temps, les marqueurs de parcours, les farces et attrapes qui bloquent le personnage pendant un temps x, le score, etc. L'organigramme complet de Pince Sans Rire devra, bien évidemment, les prendre en compte.
Bien, maintenant que vous connaissez la méthodologie pour établir un organigramme, nous vous proposons d'en établir un sur la base que nous venons de décrire. Prenez, éventuellement, comme exemples, ceux que nous vous proposons ci-dessous et étudiez autant que faire se peut l'encadré sur la normalisation des symboles utilisés pour ce type de représentations graphiques.
La fameuse petite balle qui rebondit vous dévoile les secrets de ses entrailles. En cas de collision sur un mur, il y a passage en valeur négative des coordonnées de la balle. Les deux cas d'arrêts sont d'une part quand il n'y a plus de briques, d'autre part quand il n'y a plus de balles.
Space Invaders est sans l'ombre d'un doute le plus connu des jeux vidéo. Avec cet organigramme, vous aurez le loisir de voir dans les grandes lignes le fonctionnement du jeu. Les Invaders sont contenus dans une chaîne de caractères. En cas de destruction d'une créature, la chaîne est reconcaténée. Le programme s'arrête s'il n'y a plus d'envahisseurs dans une chaîne ou si la formation d'Invaders se trouve à la même altitude que votre base.
Prenons un exemple précis : comment demander à l'ordinateur de tester si le joueur manipule la manette et, si c'est le cas, lui indiquer ce qu'il doit faire ? Il existe plusieurs algorithmes possibles. Le mieux est de choisir celui qui se révèle le plus rapide tout en prenant un minimum de place. Trop souvent, ces impératifs sont contradictoires et l'on doit alors choisir le moyen termes le plus efficace. D'autre part, notez que l'algo utilisé peut parfois varier en fonction du langage et/ou des instructions dont on dispose. Cela en fonction bien entendu de la complexité du problème à régler car de toute manière, lire le port manette s'effectue grosso modo toujours de la même manière...
Mais revenons plutôt au problème qui nous préoccupe. La première question à se poser pour établir l'algo qui nous intéresse est... à quoi ça sert ? La gestion des commandes est à mettre en relation avec l'affichage puisque les actions sur la manette influent sur le parcours du personnage à l'écran. A partir de ce moment, nous savons donc quelle sera la relation entre routine d'affichage et gestion des commandes : cette dernière fournira des coordonnées de déplacement en X et Y (nous sommes en 2D ne l'oublions pas) à la routine d'affichage. Nous en savons assez pour formaliser en langage naturel notre routine.
Tenez, un petit exercice : réfléchissez à ce problème quelque temps avant de lire la suite et surtout écrivez ce qui vous vient à l'esprit. Vous voici de retour ? Parfait, continuons notre exposé... Voici donc la formalisation en langage naturel de notre problème. En cas de maniement de la manette, l'ordinateur doit interrompre la routine de gestion du clavier afin de transmettre des paramètres à une autre routine. Concrètement, on peut le résumer de la manière suivante.
Début de boucle
Test si commande
Si oui alors affection de valeurs aux variables d'affichage et appel routine d'affichage
Si non aller début de boucle
Fin de boucle
Compte tenu de l'organigramme que nous avons choisi, la routine d'affichage vient à la suite de la gestion des commandes... A partir de cet exemple, vous ne devriez pas avoir de problème à effectuer une transposition en BASIC. Un conseil toutefois : ne perdez jamais patience et essayez d'être logique, un peu à la manière d'un ordinateur. Admettons que vous soyez assis et que vous désiriez allumer une lampe. Que faites-vous exactement ? Tout d'abord, vous vous levez et commencez à marcher tout en évitant les obstacles entre l'interrupteur et vous. Parvenu à ce dernier, vous le manipulez et avons allez vous rasseoir. Le fait de se lever, de faire un pas et autres gestes sont autant de routines constituant le programme "allumer lumière". Le fait de marcher peut être comparé à une boucle tant que l'interrupteur n'est pas à votre portée, vous faites un pas puis un autre jusqu'à la fin de la boucle (l'interrupteur est enfin à portée de bras).
N'oubliez jamais qu'un ordinateur fait comme vous mais qu'il n'est en mesure de faire que ce qu'on lui demande ! Cela monte bien que lorsqu'on travaille sur un algorithme, seule la logique (pas la vôtre mais celle de votre ordinateur) est à prendre en compte. On procède donc de cette manière pour l'ensemble des autres routines et l'on n'a alors plus qu'à se mettre face au clavier afin d'écrire notre jeu. Notez que ce que nous venons de voir montre bien que l'écriture en elle-même, la saisie, représente une petite partie, en termes de temps, du travail nécessaire à la création d'un programme. Certains trouveront notre méthode un peu longue. C'est vrai, mais ils réalisent inconsciemment le même travail sauf qu'ils ont tout dans la tête !
Pour un petit programme, ça ne pose pas de problème, en revanche dès que l'on désire aller un peu plus loin, mieux vaut se presser lentement et appliquer une méthodologie extrêmement précise.
Langages et utilitaires
Écrire un logiciel nécessite malgré tout une certaine maîtrise d'un langage donné. Pour un débutant, il s'agit généralement du BASIC mais lorsque l'on dispose d'une certaine expérience, on a une nette tendance à s'en détourner au profit de plus de puissance mais aussi de plus de complexité (C et assembleur principalement). Le BASIC a pour lui sa grande diffusion, sa simplicité et son accessibilité. En revanche, son manque relatif de puissance (sauf exception) ainsi que son universalité plus que limitée posent problème.
Signalons tout de même qu'il peut servir de base pour un programme commercial par le biais des compilateurs. Ce type de programme permet en effet d'obtenir, à partir d'un programme source (écrit en un langage complexe tel le BASIC), un programme dit objet qui est en fait une transcription en langage machine du source. Sur ST par exemple, il existe un compilateur pour GFA Basic, sur Amstrad CPC, on dispose notamment du compilateur ERE, sur PC, il en existe de nombreux, etc. Toutefois, ils posent problème lorsque l'on désire adapter son programme sur d'autres machines car il est nécessaire de transcrire le source d'une machine à l'autre. Et comme les BASIC sont rarement compatibles entre eux...
Cet inconvénient est aplani par le C. Langage universel par essence, le C est désormais disponible sur de nombreuses machines. Tous les 16/32, PC et autres machines similaires en possèdent. En revanche, côté huit bits, cela pose problème... Autre inconvénient du C, sa syntaxe est contestable. Il en est de même pour l'assembleur. Langage puissant mais ésotérique, l'assembleur diffère en fonction des processeurs et nécessite une très bonne connaissance des machines. C'est pourquoi les programmes 100% assembleur sort de plus en plus rares... On se borne à écrire certaines routines spécifiques en ce langage car on peut faire autrement. En dehors des langages dont nous venons de parler, reste le Pascal qui s'avère un relatif moyen terme entre BASIC et C. Les autres sont à éviter sauf, bien entendu, cas spécifique.
Il existe toutefois certains palliatifs aux langages qui permettent d'obtenir de bons résultats ce sont les programmes du genre Jade de MBC. Ces outils de développement offrent la possibilité de créer des programmes sans avoir besoin de connaître un langage. A partir d'un scénario établi, l'on indique les diverses possibilités en fonction des options définies par le programme et c'est tout ! Ces outils ont cependant nombre de limitations. Premièrement, ils sont dédiés à un type de problème donné. Tel logiciel est destiné à la création de jeux d'aventure, tel autre à la création de jeu de tir, etc. Secondo, ils ont tendance à proposer un nombre restreint de possibilités, ce oui rend les divers jeux très semblables du point de vue des principes de fonctionnement. Bref, cela amène une certaine uniformité. Mais ne tirons pas sur l'ambulance car ce type de logiciels constitue malgré tout une très bonne entrée en la matière et certains permettent même l'édition pure et simple des oeuvres que l'on a créées (c'est le cas de Jade, par exemple).
Écrire un jeu, c'est aussi se préoccuper d'éléments tels le graphisme ou les bruitages. C'est pourquoi les programmes de dessin, de création de sons s'avèrent de précieuses aides pour le programmeur. Encore faut-il pouvoir récupérer les fichiers créés par ces logiciels afin de les intégrer dans son programme. Généralement, il suffit de quelques lignes pour y parvenir mais attention aux logiciels créant des fichiers compactés ou au format bizarre compliquant sérieusement la tâche. En effet, rares sont les éditeurs communiquant les formats utilisés, ce qui oblige le programmeur à chercher par lui-même la routine de récupération des données. Comme si le fait de développer un jeu n'était pas suffisamment complexe en soi !
Second type d'utilitaires : ceux que l'on développe soit même afin de se faciliter le travail. Cela ne se fait pas en un jour et, en la matière, seule l'expérience est de bon conseil. Ainsi, on s'aperçoit que créer un utilitaire spécifique pour un programme donné, en cours de développement, n'est pas la panacée. Autant passer un peu plus de temps afin de parvenir à un logiciel utilisable dans divers cas... C'est pourquoi il ne faut pas chercher à aller trop loin lorsque l'on développe son premier programme... Autrement dit, celui-ci sera de préférence écrit dans un langage simple dont on maîtrise au minimum les concepts de base. Le BASIC est à cet égard idéal et pour l'apprendre, il suffit d'ouvrir le manuel... et de le lire !
De la même façon, lorsque l'on développe son premier jeu, il est préférable d'utiliser une machine que l'on connaît bien. De cette manière, on dispose de points de référence : les logiciels déjà existants. On peut ainsi se faire une idée précise de la valeur réelle de son jeu en fonction des autres. Cela est d'autant plus important que le développement d'un programme, quel qu'il soit, ne doit pas se faire dans l'optique "je fais un jeu pour moi". Non, un logiciel doit être étudié pour les autres et non pour soi. A moins d'être un égocentrique fini, bien évidemment !
Au fait, et la machine
Il faut bien se poser la question de savoir sur quelle machine développer son oeuvre. Pour les novices, le problème est simple : généralement, on ne dispose que d'un seul ordinateur. Le choix est donc fait ! Toutefois, parlons de la configuration nécessaire pour travailler dans de bonnes conditions. Comme pour toute application sérieuse, la programmation nécessite certains périphériques afin de pouvoir travailler efficacement. Premier élément : l'écran. Programmer c'est souvent passer des heures devant son écran à chercher la petite bête parmi des lignes et des lignes de programme. Avoir un affichage stable et de qualité raisonnable est de ce fait nécessaire. Un moniteur monochrome est fortement recommandé. Toutefois, les écrans couleurs peuvent faire l'affaire mais du fait de leur lisibilité moindre, nous vous conseillons de les équiper d'un filtre. Certains modèles donnent, en effet, de très bons résultats pour une somme relativement modique (environ 250 FF).
Autre élément d'importance : l'imprimante. N'oublions pas qu'un écran ne peut afficher qu'un nombre limité de lignes. Avoir une vue globale du programme s'avère souvent utile, c'est d'ailleurs toute la justification des listings et donc de l'imprimante. Mais celle-ci doit être en mesure d'imprimer à une vitesse raisonnable car attendre des heures la fin de l'impression est souvent frustrant. Malgré tout, la qualité d'impression peut être limitée, une imprimante à 100 CPS en qualité brouillon est largement suffisante. Bref, compter environ 2000 FF.
Pour le programmeur plus averti, la configuration de base répond exactement aux mêmes critères. La différence réside, en fait, dans la question de base qui est : sur quel ordinateur dois-je développer. Cela étant évidemment à rapprocher de ce que l'on désire faire ensuite de ce programme (le diffuser, si oui comment, etc.). Deux solutions coexistent. La première consiste à se dire "je programme car ça me plaît". Pas de motivations financières, donc inutile de chercher à travailler sur un ordinateur que l'on ne possède pas ! Dans l'autre cas, le mieux est de travailler sur un ordinateur connu et diffusé. Là, vous avez le choix. Sachez tout de même qu'en France les plus gros marchés sont les Amstrad CPC et que l'univers PC n'est pas à négliger.
Ce raisonnement peut sembler bien terre à terre mais si l'on désire créer un programme avec l'idée de le commercialiser, les retombés seront plus fortes. Donc on pourra se permettre de consumer plus de temps au développement, ce qui aura pour intérêt de renforcer les qualités du jeu... D'autre part, les machines répandues disposent d'un entourage plus important. Documentations, livres et ouvrages techniques divers, utilitaires et autres éléments similaires facilitent souvent la vie... Mais nous touchons là un aspect plus professionnel du développement. Du reste, si vous êtes novice en la matière, ne désespérez pas de parvenir à ce stade. Pour vous donner du coeur à l'ouvrage sachez que l'auteur du jeu Elite a touché l'équivalent de six millions de francs en droits d'auteur ! Il ne tient qu'à vous d'y parvenir. Mais faites-le sans précipitation !
Les derniers conseils
Trop de programmeurs ne structurent pas assez leur travail. Si vous êtes débutant, gardez-vous de tomber dans ce piège en respectant une méthodologie sûre. L'intelligentsia micro-informatique répond à ceci que ce n'est pas la faute du programmeur mais la faute des langages qui ne permettent pas de structurer suffisamment les programmes. C'est une mauvaise excuse : la méthodologie que nous vous avons présentée est certes contraignante mais fonctionne. Elle vient en droite ligne de l'informatique lourde, elle est appliquée par de nombreux programmeurs sur mini et gros systèmes. D'ailleurs, ces derniers ont un adage qui résume parfaitement cela : il n'y a pas de mauvais langage mais de mauvais programmeurs.
Prenez donc dès le début de bonnes habitudes, ne faites pas de lignes de trop grande longueur, elles sont trop souvent source de complications. Réalisez, autant que possible, des routines claires et facilement lisibles et évitez toute formulation par trop ésotérique. Ainsi, lorsque vous définissez une variable, au lieu de la nommer X ou Y, utilisez l'abrégé de sa véritable fonction. Cela n'est pas toujours possible, mais si vous le pouvez, n'hésitez pas !
D'autre part, commentez votre programme au moyen de remarques (Rem en BASIC) mais ne faites jamais directement appel (Goto ou Gosub) à ces lignes... Elles sont consommatrices de mémoire (il en est de même pour les noms complexes de variables) et si vous venez à en manquer, vous pourrez toujours vous en sortir en réduisant les commentaires ou en les supprimant avant une éventuelle compilation. En contrepartie de ces quelques règles, vous pourrez reprendre un programme et le comprendre longtemps après l'avoir écrit...
Autre élément d'importance : connaître sa machine ainsi que le langage utilisé. Pour commencer, nous vous conseillons de saisir des listings. Nombre de programmeurs vous diront qu'il s'agit d'une méthode sûre. Un bon listing et un manuel du langage utilisé permettent, en effet, de comprendre pas mal de choses. La saisie implique souvent des erreurs et c'est en les cherchant que l'on apprend à mieux maîtriser sa machine. De la même manière, sachez que l'on ne programme pas comme ça en se disant "allez zou on y va". C'est trop souvent source d'erreurs et donc de découragements...
Programmer c'est réfléchir, c'est aussi savoir chercher. Il nous arrive à Tilt de recevoir des questions du genre : comment sauvegarder un programme sur telle ou telle machine, comment formater une disquette sur telle autre. Pour le savoir, il suffit de prendre le manuel de l'ordinateur, tout est dedans. Encore faut-il avoir le courage de l'ouvrir et d'essayer de comprendre.
Le but de ce dossier est de vous aider à trouver une nouvelle application pour votre ordinateur. Considérée par beaucoup comme une voie royale, la programmation offre des plaisirs que peu de jeux proposent. N'oubliez pas qu'un ordinateur, c'est un univers restreint mais plein de mystères qui vous attendent au tournant d'un circuit intégré. Trop de gens pensent que la micro-informatique est morte. Qu'elle se résume maintenant à l'utilisation de programmes développés par des éditeurs de tous les coins du monde. Si vous êtes de ceux-là, essayez d'appliquer notre méthode. Vous n'avez rien à perdre. Si, en revanche, vous êtes de ceux qui ont envie de franchir le premier pas, n'hésitez plus ! Votre ordinateur vous en remercie.
Annexe : Diffuser son programme ?
Ça y est, vous avez terminé votre premier jeu ! Satisfait de votre travail, vous cherchez maintenant à faire reconnaître vos qualités de programmeur par le biais d'une diffusion de votre oeuvre. Mais comment s'y prendre ?
En fait, tout dépend de la qualité de votre logiciel, de son niveau de sophistication, de la machine sur laquelle il fonctionne. Première possibilité : l'édition du listing dans une revue ou dans un livre. Dans ce cas, le BASIC est accepté et votre programme peut prendre diverses formes. Signalons, de plus, que dans ce cas le langage machine imbriqué dans le BASIC est souvent apprécié. Avantage de cette formule : on vous paie ! Avec les machines actuelles et la taille des listings qui a tendance à augmenter, de plus en plus de revues sont obligées de limiter le nombre de programmes publiés. Les places sont chères et seuls les meilleurs sont sélectionnés.
Dans ce cas, que faire de son programme ? Vous avez deux possibilités : le gratuiciel ou le partagiciel. La première solution consiste à abandonner tous ses droits d'auteur sur le programme. Copiable par tout un chacun, le logiciel tombe dans le domaine public et se diffuse de manière naturelle. Notez que dans ce cas la diffusion de votre programme sera directement fonction de ses qualités Intrinsèques... Le principe du partagiciel est similaire, à ceci prêt que les droits d'utilisation sont restreints. A partir du moment où une personne utilise le programme, il se doit de vous envoyer une certaine somme. En revanche, s'il ne l'utilise pas, il lui est possible d'en effectuer des copies pour les autres... Compte tenu du faible rendement financier de ce système (les utilisateurs ne jouent pas le jeu), nous vous conseillons de distribuer de cette manière une version bridée ou de démonstration de ce programme et d'envoyer une version définitive à l'intéressé lorsqu'il a acquitté son droit d'utilisation. Ici encore, le succès de ce mode de diffusion dépend fondamentalement de la qualité de votre oeuvre.
Dernière méthode : l'édition classique. A partir d'un certain niveau de qualité, vous pouvez, en effet, prétendre à la signature d'un contrat avec un éditeur quelconque. N'hésitez pas à prendre contact avec eux, éventuellement à leur expédier une version de démonstration de votre oeuvre, à contacter plusieurs éditeurs afin d'avoir la possibilité de négocier un éventuel contrat en toute connaissance de cause... Attention, toutefois, car en pratique, cette méthode de diffusion exclut, dans la très grande majorité des cas, l'utilisation du BASIC. En contrepartie, un éditeur vous apportera de l'aide (la protection contre les copies sauvages, etc.).
Voilà, vous êtes maintenant au courant des diverses méthodes de diffusion. Il ne vous reste plus qu'à choisir celle qui vous convient le plus et celle pour laquelle votre programme est le plus adapté. La règle de base est bien entendu : plus votre programme est évolué techniquement, plus il a des chances de succès. A vous les vacances dans les Caraibes, à vous les voitures de rêve, à vous les critiques des journalistes acerbes et toujours en retard...
Annexe : Dictionnaire
Adapter : convertir sur un ordinateur un programme écrit au départ sur un autre.
Algo : abréviation d'algorithme.
Algorithme : représentation théorique d'une routine.
Assembleur : logiciel permettant de programmer dans le langage du microprocesseur présent dans une machine donnée, à l'aide d'instruction spécifiques.
BASIC : langage de programmation facile à apprendre et présent sur pratiquement tous les ordinateurs.
Bit : abréviation de Binary Digit (unité binaire) prenant la valeur de 0 ou 1.
Boucle : répétition d'une séquence d'instruction.
Bytes : octet en anglais, à ne pas confondre avec bit.
C : langage de programmation, dit évolué, disposant d'une syntaxe contestable mais facilitant l'adaptation des programmes.
Collision (test de) : vérifier de manière logicielle si un élément numérique est en contact avec un autre.
Compactage : méthode logicielle permettant de diminuer la place mémoire prise par un fichier ou un programme.
Compacté : élément codé selon la technique du compactage.
Compilateur : logiciel permettant d'obtenir un programme en langage machine à partir d'un listing écrit en C, BASIC, Pascal ou tout autre langage évolué.
Commentaires (lignes de) : lignes permettant au programmeur d'expliquer à quoi sert telle ligne de programme. Les commentaires sont inclus dans le programme mais pas exécutés.
Coprocesseurs : microprocesseurs prenants en charge certaines opérations spécifiques (graphismes, sons, etc.).
Exécution : mise en fonction, par l'ordinateur, d'un programme, d'une routine, d'une instruction.
Format : structure des données.
Fichier : ensemble ordonné de données.
Gosub : instruction BASIC permettant de sauter un certain nombre de lignes pour effectuer une routine spécifique et revenir à l'instruction située juste après le Gosub.
Goto : instruction BASIC permettant de sauter directement un certain nombre de lignes.
Instruction : opération élémentaire d'un langage de programmation.
Langage machine : langage de programmation propre à chaque type de microprocesseur.
Lutin : élément graphique utilisable de manière similaire à un caractère écran.
Octet : ensemble de 8 bits.
Organigramme : représentation graphique destinée à décrire le fonctionnement d'un programme.
Outil de développement : logiciel destiné à simplifier le travail du programmeur.
Pascal : langage de programmation situé entre BASIC et C.
Return : instruction BASIC signalant la fin d'une routine appelée par Gosub.
Rem : instruction BASIC destinée aux commentaires.
Routine : partie d'un programme effectuant une tâche précise, constituée d'un ensemble d'instructions.
Séquentiel : méthode d'exécution, ou de transmission, des données où le traitement s'effectue instruction par instruction ou donnée par donnée.
Sprite : mot anglais pour lutin.
Test : vérification logicielle d'un phénomène.
Transposer : adapter.
Variable : donnée informatique capable de prendre diverses valeurs.
|
