Showing posts with label platforming. Show all posts
Showing posts with label platforming. Show all posts

Wednesday, January 31, 2018

School Touch?


My brother comes back again with the idea of School Rush on Android platform. Porting issues set aside, I guess he means "on the bare device", and not assuming one bluetooth dpad and buttons attached, Nintendo-switch-like. That implies converting touch and taps and gestures into valid SNES inputs.

Mon frangin n'en démord pas: la plate-forme qu'il faudrait attaquer pour un portage de School Rush, c'est les smartphones & tablettes. Androïd, donc. Au-delà de l'aspect purement "portage", ce qui va manquer le plus sur Androïd, ce sont bien sûr les boutons et le D-PAD. Je doute qu'il avait en tête qu'on se bricole quelque-chose avec des contrôleurs bluetooth en plus du téléphone lui-même. Bon, la bonne nouvelle c'est que la DS elle-même a un écran tactile. On pourrait donc imaginer faire une version "School Touch" pour essayer le potentiel du jeu avec cette interface-là avant de se lancer dans des longues soirée de méditation sur les interfaces Androïd.

Good news: the DS also has a touchscreen. So as a preliminary test, I could just try to use the touchscreen to see how the game feels. Imho, a specific area to emulate the d-pad on having to hold a finger on the screen as we do for the (A) button would be terrible. No one could complete the game in those conditions. I've tried that with e.g. Sonic 2 back then and it was really degrading the gameplay.

Ce qui est déjà clair, c'est que je ne ferai pas une espèce de pad virtuel à travers l'écran tactile. C'est généralement une catastrophe. Il faudra plutôt que j'aille vers une sorte de mélange entre "platform panic" de Nitrome (glisser à gauche ou à droite pour changer le sens de la course avec Bilou qui continue à courir tout seul) et Phantom Hourglass (tapper un monstre pour utiliser les mains de Bilou)

Ideally, we should be constantly running when playing School Rush. That means in the School Touch game, Bilou should start running forward as soon as we trigger RUN, keep running until we give a contradictory input. Similarly, just tapping Jump should do a max-height jump. modulating dump height on distance would be additional inputs rather than timing on the initial input.

No idea when I would do that,... though.


Là où je sèche plus, c'est pour le saut. Dommage, pour un jeu de plate-forme, j'en conviens. Dans School Rush, on dose son saut par la durée de la pression sur le bouton. Faire pareil sur un écran, c'est risquer d'avoir toujours les doigts dans le chemin quand on veut regarder la suite du niveau. Je partirais plutôt vers un système où on fait de base le saut maximum, que l'on "interrompt" si Bilou arrive plus haut que l'endroit où on a tappé  / l'endroit où est le doigt. Enfin, il faudra trouver quelque-chose pour pouvoir atterrir avec assez de précision sur des plate-formes parfois assez étroites.

I liked the idea of "tap another GOB to trigger the "punch" button: it works for picking up bladors, throwing them on baddies, grabbing spons and punching things.

Saturday, September 10, 2016

La guerre des Mascottes

Ça y est : j'ai enfin reçu mon tome 2 de l'Histoire de Mario. Chiffre de ventes à l'appui, William Audureau et Oscar Lemaire passent au tamis les années sabbatiques du plombier, à savoir la période de 1990 (lancement de Super Mario World) à Juin 1996 (fin du développement de Mario 64). Je dis "années sabbatiques" puisqu'entre les deux, les amateurs de fleurs de feu n'auront que Mario Land II à se mettre sous la dent.

C'est pourtant l'époque où tous vont tenter l'aventure de la plate-forme dans le sillage de celui qui tente de faire vaciller l'idole, à savoir Sonic (1991). Bien sûr, il y aura eu d'autres jeux de plate-forme avant et il y en aura d'autre après, mais durant cette période, ils représenteront le gros des ventes de jeu sur console.

Chose peu surprenante, c'est avec la sortie de Sonic que coïncidera l'envie de faire mon propre jeu de plate-forme avec d'abord Calimero de '91 à '93 puis avec Bilou sous Basic entre '94 et '96.

Pendant ce temps, à peu près tous les détenteurs de personnages enfantin forts vont cesser d'"ignorer" le jeu vidéo et attaquer le dangereux Mario sur son terrain : celui du jeu de plate-forme. Ce sera "castle of illusion" avec Mickey, "duck tales" puis les jeux Infogrames qui ratissent autant de personnages de bande-dessinée francophone que possible mais aussi le bestiaire de la bande à Bugs Bunny -- avec plus ou moins de succès. En réaction, les acteurs du jeu vidéo vont aussi miser gros sur les personnages d'animaux antropomorphiques ayant le potentiel de devenir des mascottes, comme le Mr. Nutz de Philippe Dessoly chez Ocean, la chauve-souris acrobatique chez Sun Soft et le controversé Bubsy chez Accolade (que je ne connaissais jusque là que sur PC pour ses simulateurs de course)... et bien d'autres encore qui n'auront atteint ni l'émission Luna Park ni les planches de Midam. Même les robots de combats spatiaux prennent des allures de braves mascottes et tentent de se faire passer pour des abeilles avec des noms comme "twinnbee".

Oh, well. There's been another book by William Audureau, joint by Oscar Lemaire, about years '91-'95 where platformer was the king of video games, and where it looked like everyone could come with a mascot-like hero that would be the next Sonic since Mario was Missing... So I've been reading and reading. And no code has progressed. More luck next week ?

De notre côtés de jeunes ados, on fait la chasse aux magazines, on rève à ce que peut bien être tel ou tel jeu avec un personnage plus ou moins probable. Il semble qu'il y ait un nouveau venu tous les trimestres. Dans quelques rares cas, on aura l'occasion de s'y essayer mais le monde du PC est tristement dépourvu de ce genre d'exotisme. Au mieux, ce sera James Pond II sur Amiga à la maxithèque, ou la surprise de découvrir Moktar reconverti en Titus the Fox. Ils ne sont pas tous des sonic-like tels que Zool, mais ils cherchent clairement à plaire au même public. Et il semble bien que le succès de Sonic décomplexe tous ceux qui hésitaient jusque là à faire des chat-tout-mignons comme personnages de jeu: il suffit de leur coller un élément vestimentaire de jeune, une attitude cool-et-frondeuse, et en avant. Sur micro, on le prendra avec une dose de dérision, et j'ajouterais bien "Super Frog" (PC, Amiga) à Jazz Jackrabbit & James Pond ... mais le plus souvent, on avait droit à un gros raté du genre "Skunny the Wild West".

Le tandem William-Oscar gratte donc derrière les couvertures de magazines et effectue un impressionnant travail pour rassembler les interviews, les mettre en contexte ... Car si l'un va titrer "la nouvelle mascotte de XXX", ce n'est pas nécessairement l'avis de la société qui l'aura publié, ni du studio qui l'aura créé. Et si les personnages humains (Commander Keen ? Duke Nukem ?) sont assez peu présent dans l'analyse, les "héros/mascottes" improbables tels que Plok ou Cool Spot eux, ne sont pas oubliés.

Il met aussi en perspective les travaux de l'équipe de Miyamoto -- qui n'est évidemment pas restée les bras croisés pendant 5 ans -- qui sans parvenir à donner un deuxième jeu où l'on saute vers des blocs-questions à la SuperNES va se frotter à toutes les technologies de pré-3D afin d'avoir le meilleur Mario 64 possible quand sera enfin prête la console 3D de nintendo.

Il y aura finalement peu de suites parmi les "héros fabriqués spécialement pour l'occasion" ... et aucun ne parviendra à survivre à l'environnement des 16-bits où il a vu le jour, que ce soit pour des raisons de fusion/acquisition/license, par incompatibilité technique entre la vue 3D et les mouvements du jeu de plate-forme, ou simplement parce que les artistes d'animations qui donnaient vie aux personnages se retrouvent privés de tout repère devant les logiciels de modélisations polygonales.

Vous l'aurez compris, même s'il y avait beaucoup moins de matière pour le game-designer-amateur que je suis, le livre m'a malgré tout tenu en haleine. Bon, évidemment, avec tout ça, le travail sur l'amélioration de SEDS et LEDS, mes éditeurs de jeu sous DS, n'ont pas beaucoup avancé ^^".

Saturday, June 04, 2016

Donkey 1&3

Donkey Kong Country... excellent jeu et également un excellent dossier dans le dernier Pix'n'Love -- et impressionnant de part sa longueur, même s'il comporte une bonne part d'"histoire de Rare" en plus de couvrir la trilogie DKC. David Wise nous dévoile des pans entiers du développement. Avec quel acharnement ils ont bataillé pour faire tenir les musiques dans les 64Ko du sound chip de la SNES. L'importance des visites au Zoo, mais jamais comme on l'attendait. Tout ça avec 18 mois pour la réalisation du jeu.

Poor non-French-speaking pals. I truly hope you have an alternate information source about how Rare worked on Donkey Kong Country. We do have Pix'n'Love and they did a great job on it. I cannot give you an overview of what's in it because it's truly a huge story they collected. But let me use the occasion to take a step back and analyse what was so special about the gameplay

DKC avait pour ambition d'être aussi génial à jouer que SMB3, mais plus fluide. Invitation au speedrun avant l'heure,  les concepteurs estiment que le joueur doit avoir la possibilité de parkourir le niveau à grande vitesse s'il le connaît suffisamment bien. De là la course inspirée d'un cheval, de là aussi, l'abandon des clés et cages (inspirées de DK Jr) esquissée dans les documents de 1993 au profit des "caisses d'animaux". De là - enfin - un positionnement méticuleux des tonneaux, cordes, ennemis et autres objets mobiles pour que le joueur n'ait jamais à s'arrêter pour attendre qu'un objet utile à sa progression arrive à sa portée. La vitesse devient le coeur du jeu et les autres décisions de gameplay se mettent à graviter autour.

At some point in the game development, Rare team decided to put the focus on how fluidly one could zoom trough the level, granted that she knows the level well enough. From then on, many of the early concept sketches got dismissed (no more keys, but K.O.N.G letters), some realism was dropped (DK runs like a horse, because gorillas you can see in a Zoo just do not run). Game was tuned in that direction so that player do not *need* to wait for things like vines or blasting barrels.

Un autre élément fort du jeu, à mon avis, ce sont les tonneaux. Ils sont partout. De même que le joueur de Mario aura entraîné son oeil à repérer les blocs-à-frapper en une partie, le joueur de DK aura repéré les tonneaux. Tonneaux à lancer, tonneaux-power-up, tonneaux-sauvegarde, tonneaux-cannon. Un mélange de diversité et d'uniformité que je peine à reproduire dans mon petit Bilou.

I'm quite seduced by how much mechanics the Rare team managed to fit within a "barrel" look. But the Pix'n'love paper on DKC shows early design documents with even more ideas. Some of them will never show up, afaik (like the conveying barrels chain). Many of them will appear later in DKC3, and in my opinion, they weren't that great. It may sound fun to have "a monster in a barrel", but it actually convey the message "we don't know what to draw". It is true that a barrel can make a platform when thrown in the water, but when it means you're forced to take your bridge's step one by one it reduce the replay-appeal of the game, because you know the game will deny you the control of what you do and instead insist that you proceed through repetitive tasks. And no, a barrel-shaped boss is not cool, no matter how interesting to understand the underlying puzzle.

Ça fait quelques temps que je me demande pourquoi j'ai aussi peu apprécié DKC3 alors que les autres étaient aussi bien. Eh bien, c'est que l'équipe de Rare qui travaillait sur DKC était alors sur un autre projet N64. J'étais arrivé à me dire que c'était dommage qu'un tonneau soit l'ennemi le plus fréquent. J'ai eu la surprise de découvrir que cette idée-là était déjà croquée sur les documents de brainstorming du premier jeu.

Et d'autres idées annulées et non retenues de DKC1 figurent aussi parmi les autres idées curieuses de DKC3. Comme le remplacement de Rambi le rhinocéros par un éléphanteau froussard qui tire des jets d'eau.
Est-ce à dire que la jeune équippe qui reprenait le flambeau n'est pas parvenue à apporter de réelles idées propres et qu'elle s'est contenté de piocher dans les idées laissées de côté par leurs ainés? J'irais pas forcément jusque là. Mais l'équipe à la tête du game design avait visiblement une moins bonne perception de ce qui est chouette et de ce qui ne l'est pas.

The there-and-back puzzle nature of so many levels in DKC3 isn't the only thing that make it feel inferior to its predecessor. I now know that DKC3 was developed by a younger team while the dev'ers of DKC and DKC2 were busy on some N64 project. They definitely had access to early design document of DKC and decided e.g. to recycle the young-elephant-who-spit-water-at-monsters. They had gameplay ideas. They had a great engine to work with, but imho, they lacked the acute and experienced eye that can see a game idea and find the little thing that make it look gorgeous when played.


J'entends par là: les idées sont généralement bonnes et variées. Mais leur habillage dénote un manque d'inventivité. Un tonneau géant qui rote comme boss ? Son comportement n'est pas inintéressant, et pour le joueur qui n'a pas lu de soluce, le puzzle proposé (oui, le combat contre le boss est essentiellement un puzzle avec un peu de précision sur les lancers). Mais quelle gloire peut-on ressentir à avoir vaincu ça ?

En plus, parce qu'il s'autorise à construire des niveaux avec des va-et-viens, des objets à transporter pour éliminer les 4 ennemis qui bloquent le passage à partir du même générateur-de-tonneaux-spontanés, le jeu perd fort de son intérêt pour un re-jeu. J'ai refait des parties de DKC à ne plus savoir les compter. Mais DKC3 ? J'avoue ne pas en ressentir l'envie depuis que j'ai fini le jeu sur émulateur.


Saturday, March 21, 2015

Titus the Fox dans Pix'n'Love #15

Parmi les excellents dossiers du magazine "Pix'n'Love" que j'aimerais voir réunis en un ouvrage dédié au game design, il y a une interview très intéressante d'Eric Zmiro sur le développement de "Titus the Fox / Moktar". Moktar est un des premiers jeux de plate-formes auquel j'ai pu vraiment m'essayer ... comprenez avec autant de tentative que je ne le voulais parce qu'il n'y avait pas de fin de vacances, de fin de courses au GB ou de fin de pièce de 500 Lires pour m'obliger à passer la manette de manière définitive.

Il y avait beaucoup de bonnes choses dans ce jeu -- notamment la possibilité d'emporter plein d'objet et de construire le gameplay sur leur manipulation -- et c'est toujours un peu triste pour moi d'entendre les joueurs console cracher sur la société qui a produit les premiers jeux sympas pour PC que j'aie rencontrés. Il y a aussi beaucoup de choses discutables que l'article me permet de comprendre mieux. Le scrolling, par exemple, fonctionnant par à-coup, qui se révèle être un hybride entre le scrolling continu d'un Mario/Keen et le screen-flipping qu'on trouvait déjà dans le premier opus de Prehistorik. Bien sûr, il était techniquement possible en 1991 de faire mieux, mais pour un éditeur qui n'agit qu'en France, il est important que les titres PC tournent sur tous les PC. Pas seulement sur le 286 équippé d'une carte VGA de mon voisin Alain, mais aussi sur un 8086 CGA.

L'écart de fluidité entre les version Amiga et PC, le choix de jeux à licence laissait imaginer une équipe encleinte à la facilité. L'interview révèle une équipe extrêmement réduite (un graphiste et un programmeur pour le jeu "Moktar") qui n'hésite pas à reprendre la partie la plus technique du moteur de jeu pour pouvoir supporter des sprites plus gros et des niveaux plus vastes quand la direction déclare juste "on va faire un jeu avec Lagaf'. Changez juste le personnage de Blues Brothers et ça ira comme ça" (citation officielle). Et la description de l'environnement de création habituel, très "bride sur le coup", de Titus Interactive donne aussi un autre éclairage sur cette déclaration. "On a un contrat pour un jeu, les gars. Et cette fois on a une date limite. Alors pas question de démo techniques qui n'aboutissent à rien cette fois-ci." (interprétation personnelle, ce qui n'a de toutes façon pas beaucoup d'importance puisque de toutes façons, pendant les mois passés à attendre les graphismes, Eric Zmiro a eu l'occasion de faire un tout nouveau moteur de jeu). Quand aux versions Amiga, elles ne sont pas développées en interne, mais confiées à des spécialistes free-lance de cette machine, sans doute une fois que le jeu a fait ses preuves et que les rentrées permettent d'envisager des frais supplémentaires.

Merci à Eric pour cette interview officielle, mais aussi aux longues discussion en privé depuis son premier commentaire sur ce blog en 2007.

Tuesday, December 09, 2014

Leçon de tuning: la théorie


 
Tune it well ...
Animating a running pendat within restricted pixel space turned out better than I initially expected. Now, I have to tune that additional move to ensure it improves the gameplay. The speed at which it moves, the distance from which Bilou is detected and the acceleration were all arbitrarily picked while writing the script. They work rather well, but they can surely be tuned for maximal results.

Bien. J'ai rajouté une animation pour que le crayon-soldat puisse charger Bilou quand il l'aperçoit. Reste du coup les questions de tuning à régler:
  • à quelle vitesse doit-il courir ?
  • à quelle distance peut-il "sentir" Bilou ?
  • combien de temps doit-il mettre pour atteindre sa vitesse maximale ?
L'enjeu de ces règlages ? faire en sorte que les réflexes puissent continuer à tirer le joueur d'affaire et éviter de se retrouver dans une situation à la Rick Dangerous où le joueur doit mémoriser tout le parcours pour pouvoir jouer.
Bilou and Pendat positions over time
The issue with arbitrary values is that they can twist the gameplay towards a state where players can no longer react to what happens and have to memorize the level just to complete them. I have been convinced by Kirby Kid's blog that this is not the way platformers should be built and that they should instead allow to be "played while reading" once we mastered core skills (estimate trajectories, press buttons, read timings) and learnt game's physics. As our player has reaction time to the walk/rush transition of the pendat (a) and that Bilou needs some time e.g. to reach a height where collision no longer occurs (b) -- and possibly only keeps that height for some time (c), values exists where player cannot possibly escape. These must be avoided.

Je me suis donc donné deux cas d'étude: "Bilou tombe devant le pendat et doit s'échapper en courant" et "Bilou doit passer par-dessus le crayon en sautant". A partir de là, on peut représenter la distance Bilou-crayon au cours du temps et voir s'il y a ou non risque d'avoir une collision.

T_player_reacts + T_Bilou_reaches_speed < T_pendat_clears_distance
T_player + T_Bilou < Pendat_Detection_Distance / Pendat_max_speed

A sa vitesse actuelle, le pendat met 81 frames (1" 36 centièmes) pour aller de sa position actuelle à celle de Bilou. Bilou, lui, met 30 frames (1/2 seconde) à atteindre sa hauteur maximale (b) et on peut compter qu'il y reste 20 frames (c), pendant lesquelles le Pendat aura avancé de 30 pixels ... Assez pour se croiser sans accroc. J'ai vu la plus jeune testeuse de la S-team réussir ce saut d'instinct. Celà signifie qu'elle a un temps de réaction d'au plus 600ms ... Hmm ... Oui, le pendat actuel est loin de demander des efforts de réactivité puisqu'on estime à 200ms un bon temps de réaction à un stimulus, pouvant descendre près des 100ms pour un sportif entrainé. Et puisque Bilou est quasiment au centre de l'écran, celà signifie que si on voit le pendat quand il fait demi-tour, il nous attaque sitôt qu'il se retourne. Rétrécir la distance de détection et la compenser par un "sursaut" du crayon pourrait améliorer la situation

While my testing-nephews were giving it a try, I went through to "escape case" -- run away or jump over -- to map where would time go. Not even the youngest player had issues with the original timings, which left a generous 600ms to the player to dodge the rush. That's about 3 times the delay usually presented for fast reaction. It "turned" out that direct rush of the pendat is not the most dangerous -- so I can easily shorten the detection distance and have pendat entering the screen walking and only start chasing Bilou when at a distance close to 1/3 of the screen width. What is truly dangerous is that bounce when he enters a wall, and then quickly turns back. It means if you're waiting for him at the top of that wall, your window to sneak behind is small. In fact, the thing that may prove more stressful is to shoot him down with a blador. But that should simply tease you to get the straight-throw power-up ;)

En fait, le rebond contre le mur est beaucoup plus piégeux. J'imagine que c'est dû à la cassure du mouvement, plus difficile à estimer. Et l'atteindre avec un taille-crayon affecté par la gravité sera plus délicat, mais pas trop quand-même puisque le crayon a le bon goût de rester dans la zone active du taille-crayon pendant sa courbe. Ouf.

Avec tout ça, le "croco-désagrafeur" retombe dans l'oubli ...

Saturday, December 07, 2013

3D: X Why Z ?

On me demande sans doute à raison pourquoi m'attaquer à la 3D maintenant (alors que j'ai un premier niveau qui est entre alpha et beta) ... "des effets d'éclairage?" ajoute mon frère ... Plus que ça, en fait.

Wihin 8 hours after publishing my last post, I've got two person wondering why I need 3D now and how I'd use it. Well, there's much more than "lightning effects", as far as I'm concerned:

SpongeBop's thread: a single 3D polygon, extremely thin and flat, can be used to display SpongeBop's link with its pin, helping the user to visualize the sponge's trajectory.
Mon premier test, c'est le "fil" de Bop L'éponge, histoire qu'on visualise mieux sa trajectoire et qu'on cesse de la prendre pour "un nuage jaune". Il est construit tout simplement avec deux polygônes plats et non-texturés, mis "en sablier". Je n'ai pas résisté à la tentation de l'implémenter avant de finir de traduire ce post. Ça n'est pas encore propre (un avocat des model-view-controller s'étranglerait en voyant le code) mais ça prouve le concept.

Large smashing books come later in the level for which I have design on papers. I also have "large books" that can be pushed and dropped to create platforms. This involve a level of rotations and deformation that stem for 3D objects. Without them, their respective levels are as meaningless as a Badman episode.
J'ai dans mes carton un niveau qui repose essentiellement sur des livres-écrabouilleurs qu'il va falloir éviter comme des thwomp. En fait, j'avais construit pas mal de scénarios autour des livres pendant la phase où je réfléchissais à un niveau complètement 3D sur PC en 2004. Ils sont sans doute réalisables sans utiliser le hardware 3D, mais ce serait se chatouiller pour se faire rire.

In both the Bilou's Book and design documents, pendats feature a rich set of poses. Right now, they merely step forward, and the animation when they turn back is essentially cheating. I want them charging Bilou, laying on the ground when stunned and pausing to check left and right locations. Not only that involves rotations, but also twisting that affine sprites cannot offer.
Plus déterminant encore: les crayons-soldats. Je ne saurais pas faire beaucoup mieux avec l'approche actuelle intégralement par sprites dessinés à moins de changer fondamentalement le moteur d'animation des sprites pour passer à quelque-chose qui ressemble davantage à Donkey Kong Country. En 3D, je n'ai plus qu'à prendre 6 polygônes non-texturés et laisser la console gérer les rotations et les effets d'éclairage, le reste étant gardé sous forme de sprites affichés par-dessus les polygônes.

Rotating Rulers  -- acting as stretch-and-squish platforms for more challenging climbing action. That level element is possibly what best defines the design for future Bilou's Adventure game, so I really want to have them done. Granted, I could emulate them with flat, smaller platforms that move back and forth synchronously.
Un autre niveau que j'aimerais beaucoup réaliser et dont j'ai déjà parlé fait intervenir des "règles qui tournent" et qu'il faut escalader bien qu'elles s'escamotent dans les recoins du niveau. Ici, on pourrait imaginer un hack à base de sprites qui bougent en coordination, mais ça rendrait nettement moins bien pour 4 polygones (texturés sans doute, cette fois).

Bookmarks that move like vines in Pharaoh's Return. It's not clear that such giggles would bring significant gameplay enhancement, but they would make the School Zone more credible than if cloth-made bookmark where simply standing stiff while you grab them.
Il y a aussi les signets des livres, que je souhaite transformer en corde. Après avoir vu le prototype de Lazycow, mon frère était d'accord avec moi: ça en jette et ce serait quand même largement un plus d'avoir ça dans Bilou, même si au niveau "fonctionnalité du niveau", ça ne change pas fondamentalement la donne.

BangBash's swinging move involves rotation around the Y axis. This will probably be the most demanding item, asking for a complete update of AnimEDS to look more like that old "sketchup compo entry".
Enfin, il y a BangBash, le personnage qui frappait les trois coups pour l'ouverture de ce blog. ll a normalement deux attaques prévues, l'une frontale qui pourrait être réalisée (pas joliment du tout) avec des rotations de sprites et l'autre, tournoyante et latérale (un petit côté double-balayage de Guile) qui impose la 3D d'une façon ou d'une autre.

Voilà. Ça m'aura couté quelques heures de sommeil, mais c'est (fait) et dit.