Nº178 (2/2005)
 |
|
 |
Download :
|
 
| Non, ce n'est pas encore le numéro d'avril (au fait, si vous avez une idée...) ! Et pourtant un trésor Oric à été tiré de l'oubli. Je suis confu de vous livrer une pure merveille : ‘Gif Animoric' (et quelques autres gâteries) avec un an de retard. Pardon Dominique. Autre grande nouveauté : un player Midi pour Oric. Je l'ai testé et je peux vous dire que c'est un miracle. Merci Fabrice. Enfin une consigne : attention à ne pas diffuser les adresses e-mail de la rubrique “Bonnes adressesâ€�, qui ne vous sont indiquées que pour votre usage personnel. Pour le club, sauf courrier personnalisé, adressez vos e-mails à ceo'at'oric.org. A bientôt. André.
|
|
 Découvrez un Player MIDI sur Oric !
Minigames sur Oric !
Software : Gif Animoric !
Fabriquez vos Cartouches Super-Oric !
Visu, le Samedi 12 Février 2005, de 14 à 18 H, au 1er étage du 17 rue des Petits Hôtels, Paris 10e (Métro Gare de l’Est ou Gare du Nord).
Visu, le Samedi 12 Février 2005, de 14 à 18 H, au 1er étage du 17 rue des Petits Hôtels, Paris 10e (Métro Gare de l’Est ou Gare du Nord).
|
|
|
|
|
|
sommaire
|
| Adresses CEO / Sommaire / Editorial
|
|
Page |
| Petites Annonces / Bonnes Adresses
|
|
Page |
| Les Calembours de Schizo Dino
|
|
Page |
| Revue de Presse : Cambridge News & Electonic Weekly
|
|
Page |
| Historique des Magazines Oric (2/4)
|
|
Page |
| Mise au Point Software pour Cartouche Super-Oric (5)
|
|
Page |
| From “Karaoke for Oricâ€& |
|
Page 65533; to “Midipsgâ€& |
| Réponses (48) : Sujet n°133 : Midi player on Oric
|
|
Page |
| Nostalgie : Le Catalogue Tansoft (2/2)
|
|
Page |
| Des Trucs pour Tricher (17) : Encounter
|
|
Page |
| 2005 CEO Subscription Form - Back Issue Order Form
|
|
Page |
| Abonnements 2005, Anciens Numéros, Anciennes Disquettes
|
|
Page |
|
Minigames sur oric
par Mickaël Pointier
Si vous suivez (activement ou passivement) le petit monde de l'Oric, vous aurez probablement constaté que ces deux dernières années la période automnale est régulièrement riche en arrivage de jeux sur notre plate-forme favorite. La raison en est simple, c'est la période de remise et de vote de la compétition internationale "minigames" sur machines 8 bits.
Le passé
Si l'on se réfère à l'historique, cette compétition nous a apporté un certain nombre de jeux:
Compo 2002
Il n'y avait que la catégorie 1k de présente, avec un total de 62 jeux, dont un seul sur Oric:
WallDefence - 1k - BASIC - Ventzislav Tzvetkov - 35th
Compo 2003
En 2003, il y avait 63 jeux au total dans les deux catégories dont les jeux Oric suivants:
4KKong - 4k - Assembleur - Mickael Pointier - 8ième
Rush Hour - 4k - Assembleur + BASIC - Fabrice Francès - 14ième
BreakOric - 1K - Assembleur - Ventzislav Tzvetkov - 28ième
Garden - 1k - BASIC - Ventzislav Tzvetkov - 46ième
Bowling Master - 1k - BASIC - Ventzislav Tzvetkov - 48ième
The Gigabonux - 1k - BASIC - Simon Guyart - 51ième
QWERTI - 1k - BASIC - Peter (TheSpider) - 60ième
AntiISDA Warrior - 1k - BASIC - Ventzislav Tzvetkov - 63ème
Compo 2004
Cette année il y avait 42 jeux dans la catégorie 4k, et 17 dans la catégorie 1k, dont les jeux Oric suivants:
DontPanic -1k - Assembleur - Jonathan Bristow - 4th
AntiISDA Warrior 2 - 1k - BASIC - Ventzislav Tzvetkov - 10th
Cyclotron - 4k - Assembleur- Mickaël Pointier - 6th
4KQIX - 4k - Assembleur - Stephane Geley - 14th
4KFIRE - 4k - Assembleur - Stephane Geley - 16th
4KBOX - 4k - Assembleur - Stephane Geley - 25th
Cube - 4k - Assembleur - Fabrice Frances - 30th
gridOric - 4k - (???) - Norayr Chilingaryan - 41th
Évidement les adresses de site web indiquées ne valent que ce qu'elles valent, pour l'instant elles sont valides, mais je ne garantis rien :)
Le futur
On peut donc constater qu'il y à un nombre conséquent de jeux produits par cette compétition, ceci dit, cela prend du temps, et rien ne garantit que les participants continueront, il est donc bon de penser à la relève, et c'est donc la raison qui m'a poussé à écrire cet article, car c'est à toi, lecteur talentueux et passionné, que je m'adresse: Nous avons besoin de toi, n'hésite pas à participer, quel que soit ton niveau, que ce soit en BASIC, en assembleur ou encore en C.
Qui plus est, vous serez peut-être piqué par le virus du développement, car franchement c'est très motivant de faire un petit jeu et d'avoir des retours de personnes qui y jouent. Une fois qu'on est lancé, ma foi on peut partir sur quelque chose de plus gros, le tout c'est de s'y mettre !
Ceci dit, je peux comprendre que vous hésitiez, parce que mine de rien faire quelque chose d'intéressant dans une taille aussi limitée nécessite un minimum de cogitation, mais aussi de connaissances pas forcément évidentes à acquérir sur le tas. Voilà donc de quoi vous mettre sous la dent !
Signification des termes 1k et 4k
Bon, ca peut sembler évident au premier coup d'Å“il, un "minigame 1k" est un jeu qui ne doit pas dépasser 1k… oui sauf que ca n'est que le début de la vérité.
En fait, c'est le fichier .TAP fourni qui doit faire au maximum 1024 octets (dans le cas d'un jeu en 1k) ou au maximum 4096 octets (dans le cas d'un jeu en 4k). Une fois chargé en mémoire par contre, le jeu peut parfaitement utiliser l'intégralité de la mémoire disponible dans la machine.
Quand je précise "fichier .TAP", c'est bien pour mettre en valeur que ca n'est pas le jeu qui fait 1k, mais le fichier cassette contenant le jeu… il faut donc penser à enlever du calcul la taille de l'entête du fichier qui contient les octets de synchronisation, l'adresse de chargement, le type du fichier, et son nom ! Donc au final il reste moins de place disponible pour le jeu. La taille usuelle d'un entête est de 13 octets plus la taille occupée par le nom du fichier. Il est donc conseillé de ne pas donner de nom lors de la sauvegarde, histoire de gagner un peu de place, ce qui vous donne une perte de sèche de 14 octets, un jeu 1k peut donc au maximum occuper 1010 octets, et un jeu 4k au maximum 4082 octets.
Évidement rien n'interdit de compresser les données, mais il faut donc alors que l'ensemble entête + décompresseur + données compressées tienne dans la taille imposée, mais je reviendrai sur ce point plus tard.
Choisir le langage
Eh oui, c'est une vrai problématique. Il n'est pas possible (ni souhaitable) de foncer tête baissée vers l'assembleur ou le BASIC sans s'être posé un minimum de questions. En effet si il est indéniable que l'assembleur est bien plus performant que le BASIC au niveau de la vitesse d'exécution, ça n'est pas forcément le cas au niveau de la taille du code.
Quand au C, vous pouvez oublier tout de suite, le code généré prend beaucoup plus de place que toute énormité que vous pourriez écrire en BASIC ou en assembleur !
Ce qui rend le BASIC si efficace dans le cadre des compétitions minigame, c'est principalement la présence en ROM d'un interpréteur BASIC. Au final un programme en BASIC n'est composé que de "tokens" qui correspondent à telle ou telle instruction. Un token étant stocké sur un octet, il prend beaucoup moins de place que l'équivalent texte, et vu que les instructions BASIC sont des "méta instructions" comparées à ce que l'on manipule en assembleur il est possible de faire beaucoup de choses en occupant très peu de place. Il faut par contre connaître un minimum les subtilités de l'encodage d'un programme BASIC en mémoire si l'on veut être à même de faire un maximum d'économies.
L'assembleur quant à lui a pour avantage d'être clair, il n'y a pas de subtilités au niveau de la mémoire occupée: un LDA #$23 prend toujours 2 octets en mémoire. Il est aussi possible de faire des manipulations très rapides, voire même de réutiliser du code de façon particulièrement perverse (dans Cyclotron j'utilise la routine de copie de bloc pour effacer des données en commençant par mettre la valeur d'effacement dans le premier octet du bloc à copier, et en recopiant ce bloc sur lui même un octet plus loin en mémoire) ce qui n'est pas possible en BASIC.
Après discussion sur comp.sys.oric il semblerait qu'une idée intéressante soit de faire un programme mixte, utilisant du BASIC pour générer des tables ou faire des calculs compliqués au démarrage du programme, et la suite du jeu en assembleur. Pour que cela soit rentable, il faut évidemment que le gain obtenu par cette méthode soit supérieur au coût qu'implique le passage d'un langage à l'autre.
Je reviendrai plus tard sur l'utilisation des différents langages, continuons la liste des points importants à prendre en considération.
Compatibilité, et utilisation de la ROM
Si vous décidez d'écrire votre jeu en BASIC, il n'y a quasiment pas de problème de compatibilité, Ã moins que vous usiez et abusez de PEEK et POKE dans votre code. Les programmes en BASIC sont portables, il devrait donc tourner sans problèmes sur ORIC 1 ou ATMOS, en version 16 ou 48k.
Si vous décidez de faire un jeu en assembleur, c'est loin d'être garanti car l'impératif de place oblige quasiment à faire des appels directs en ROM pour tout ce qui est du domaine sonore et visuel, et donc par conséquent plantera misérablement sur une version différente de la ROM.
Un autre point d'incompatibilité provient de l'état de la mémoire au lancement du jeu. En théorie vous ne devriez pas partir du principe que telle case mémoire faut telle valeur histoire de gagner un peu de place en ne l'initialisant pas. D'une part ces valeurs peuvent être différentes entre les machines (motif d'initialisation mémoire, présence ou non d'un lecteur de disquette ou de telle ou telle extension, …) mais aussi parce qu'il est parfaitement possible que votre jeu soit lancé depuis un petit menu qui aura affecté la mémoire.
Dans le même ordre d'idée, ne considérez pas comme un acquis le fait que le papier soit blanc et l'encre noire par défaut, ni même que le clic clavier soit actif. Le meilleur exemple vient du cas où votre jeu est mis dans une compilation sur disquette Sedoric: Au démarrage de Sedoric l'écran est blanc sur fond noir et le clic clavier est désactivé.
Choix du jeu
Le choix du thème
Bon, cela peut paraître étrange de discuter du choix du jeu que vous voulez faire, mais il y a un certain nombre de points à prendre en considération qui peuvent vous aider à choisir ce que vous allez vraiment faire au final.
Ce jeu, vous le faites pour participer à une compétition, soit. Mais ce jeu, il faut aussi le considérer comme étant un nouveau jeu sur Oric, qui pourra être apprécié et joué par la communauté Oric dans son ensemble, il serait donc bien que ce jeu apporte quelque chose par rapport à ce qui existe déjà sur Oric: est-ce vraiment indispensable de refaire un clone de Pac Man qui serait moins bien que celui de PSS et de IJK ???
Un autre point important est la taille: Peut-être que vous avez toujours rêvé de faire un jeu particulier, qui aurait été une Å“uvre magistrale sur Oric. Moi par exemple ce serait de faire un jeu de rôle aventure qui donnerait l'impression que Tyran était un jeu minable. Typiquement ça n'est pas le jeu que je choisirais de faire en sujet de minigame car le résultat serait minable, même en 4k et en compressant à fond. Il faut mieux faire un jeu modeste, mais bien réalisé, qu'un jeu se voulant ambitieux mais finalement pas intéressant à cause des concessions que vous aurez dû faire pour que ça tienne en 1 ou 4k.
Enfin, et cette fois je rentre dans une optique purement "politicienne" d'optimisation de vos chances d'avoir un bon classement dans la compétition, il est important de d'abord regarder l'historique de la compétition pour voir les genres de jeux qui ont plus, les critiques faites par les gens qui ont voté, et l'évolution d'année en année.
Ce qu'il faut éviter
Le but n'est pas de faire un jeu consensuel qui essaiera de faire plaisir à tout le monde, mais plutôt de déjà éviter les sales notes qui vont plomber votre moyenne. Pour cela il suffit de suivre quelques règles simples:
- Ne pas faire un nième clone d'un jeu déjà vu et revu sans rien apporter de nouveau.
- Utiliser des contrôles clavier simples avec une bonne réactivité.
- Faire en sorte que l'on ne soit pas obligé de lire la documentation pour pouvoir jouer.
- Avoir une gestion de scores, ou du moins un moyen de comparer sa performance pour "pouvoir faire mieux la prochaine fois".
- Eviter les longs temps de calcul ou les affichages fatigants pour les yeux.
Déjà si vous évitez ça, vous maximisez les chances pour que quelqu'un joue à votre jeu. Cette année par exemple je n'avais pas beaucoup de temps à consacrer au vote, donc chaque fois que je suis tombé sur un jeu dont le but n'était pas très clair, je l'ai zappé très rapidement.
Et évidemment n'oubliez pas que la majorité des votants de la compétition minigame n'ont jamais touché à un Oric de leur vie, et vont donc probablement utiliser un émulateur, et qui plus est qui aura peut-être un clavier qui ne sera pas Azerty ou Qwerty…
Pourquoi faire un seul jeu si je peux en faire 3 ?
Je vais me permettre de faire une parenthèse rapide sur le cas de Stéphane Geley et de Ventzislav Tzvetkov sur Oric, ainsi que Richard Bayliss sur C64, et dans une moindre mesure Thomas Jentzch sur Atari VCS 2600. Ces auteurs on chacun fait le choix de présenter plusieurs jeu aux compétitions. Je reste personnellement perplexe devant ce choix, et je pense qu'en consacrant le même montant global de temps sur un jeu unique, ils obtiendraient des scores bien supérieurs à ceux qu'ils ont actuellement. (Thomas est un cas particulier, car il fait des jeux sur VCS depuis des années, il ne participe qu'à la compétition 1k et il la connaît bien.) La raison de tout ça est simple, c'est la règle dite des 80-20:
"80% du temps de développement est généralement passé dans les 20% derniers pourcents de développement du programme"
Ce qui est difficile dans un minigame, ça n'est pas de faire le jeu lui même, c'est de donner un look "professionnel" à un minigame. En gros, il faut se mettre dans sa tête que l'on fait un jeu pour Tansoft ou Loriciels et que le jeu doit valoir les sous que l'acheteur met dedans. Cela veut dire qu'il faut essayer d'avoir une présentation, des scores, des vies, gérer le joystick si possible, faire des effets de transition, avoir des effets sonores, et surtout avoir un jeu jouable et non buggé qui soit agréable à jour, ce qui implique d'avoir des testeurs et d'écouter leur avis.
Par exemple dans Cyclotron j'avais au début une seule méthode de contrôle, dite en "mode relatif" avec seulement deux touches, une pour tourner à gauche l'autre pour tourner à droite. Après avoir fait tester par plusieurs personnes il à fallu que je me rende à l'évidence: les deux tiers des gens ont besoin de jouer en "mode absolu", avec 4 flèches permettant d'aller directement dans la direction choisie. Je me suis donc débrouillé pour avoir les deux modes disponibles avec un petit menu pour changer le mode.
Comment faire rentrer tout ça
Évidemment, tout ça prend de la place ! C'est donc là que le terme de compétition minigame prend tout son sens. Faire un Tron ou un Breakout en 4k c'est trivial, d'ailleurs les magazines et livres sont remplis de listing en BASIC avec ce genre de jeu. Toute la difficulté provient du fait que matériellement cela revient à faire rentrer dans 4k le genre de jeu qui usuellement sur Oric était vendu pour les machines 48k… Il faut donc recourir à moult astuces pour que l'ensemble prenne le moins de place possible, quitte à la fin à recourir à la compression de données.
Je rentrerai dans les détails pratiques dans un article prochain, mais j'aimerais bien que toutes les personnes m'envoient leurs trucs et astuces pour gagner de la place, histoire de faire un article le plus utile et exhaustif possible.
A suivre !
|
|
|
|
|
BROWSE
NUMEROS
 [188] - [187] - [186] - [185] - [183] - [182] - [181] - [180] - [179] - [178] - [177] 
YEAR
 2013 - 2012 - 2011 - 2010 - 2009 - 2008 - 2007 - 2006 - 2005 - 2004 - 2003 - 2002 - 2001 - 2000 - 1999 - 1998 - 1997 - 1996 - 1995 - 1994 - 1993 - 1992 - 1991 - 1990
|
Built in 0.02 Seconds