[Pré-Projet PSP] Blob Runner

[archilolo]

Envoyé par Ayla

La question c'était comment fais-tu ces musiques ?
Tu te bases sur des samples ou des sons générés ?

Donc je reprends :
- Reaper pour le séquenceur
- un axiom 61 et un Clavinova comme entrées midi
- et la Complete Composer Collection Quantum Leap EastWest pour les VST (en gros : sampler + énorme bibliothèque de sons de plus de 200Go). Alors, oui, je me suis fait plaisir, ça ne fait aucun doute.

[jujurackham]

Envoyé par archilolo

et la Complete Composer Collection Quantum Leap EastWest

AARRRRGHHHH! Archi tu as osé!
...
Tu dois t'amuser

Spoiler

[archilolo]

Allez, une autre petite musique pour la route !

C'est ma manière à moi d'encourager les codeurs !

[Pixou]

J'aime =D

[archipel]

Moi aussi

bizarre la fin, le violon (si c'est un violon) qui reprend juste les quinzes dernières secondes

[archilolo]

C'est pour boucler. Mais, oui, on peut virer allègrement ces dernières secondes qui, pour le coup, n'apportent pas grand chose.

[Ass-Itch]

Bon bon bon... je viens de jeter un oeil à mon dossier Blob Runner
Je me dis que ça serait quand même vraiment con de laisser tout ça dans un tiroir, sans que personne ne le voit jamais.
Ça représente plusieurs mois complets de boulot, c'est le plus gros gâchis de ma courte carrière de grapheux JV, et je crois que s'il fallait m'y remettre demain, je le ferais. Sérieusement.

Si quelqu'un passe par là : un "petit" aperçu, pour la postérité

Spoiler

DTC

[Pixou]

Wahoo ! Mais c'est excellent ! Le jeu sort quand ?

[Ass-Itch]

S'il avance au même ratio temps/efficacité, je dirais Noël 2027.
Et si un codeur doué et surmotivé s'y colle, Noël 2013.

[M@cZér0]

Ca mériterait de se voir concrétisé, tu devrais pouvoir trouver un codeur PSP quand même. Ca existe toujours, hein ?!

[Dr.Vince]

désolé pour le gâchis car c'est entièrement de ma faute...

tu sais que j'y repense de temps à autre, j'ai même regardé discrètement du côté de plateforme plus récentes (bon android en fait mais bon je sais que tu es apple) si y avait pas moyen de finaliser ce projet car j'éprouve toujours un sentiment d'amertume quand j'y repense.

Mais faudrait revoir entièrement le gameplay mais ce serait possible.

Ce qui m'avait bloqué principalement c'était les différentes/tailles résolution d'écran (et la gestion des gfx qui va avec) et ça m'avait un peu stoppé dans mon élan.

[EDIT]
Bon pendant que j'écrivais ce message je suis allé faire un tour sur le site d'une lib (conseillé par t4ils à l'époque) libGDX

Le truc intéressant avec cette lib c'est qu'on peut dev sur PC (et faire tourner sur PC) ce qui augment considérablement la productivité comparé à la PSP, et ensuite on peut obtenir la version pour d'autres support très facilement.

De plus le dév serait en java, mon langage de prédilection, donc là aussi ce serait bien plus simple que sur PSP.

Et pour finir voilà un truc qui pourrait devenir très intéressant :

Libgdx is a cross-platform Java game development framework based on OpenGL (ES) that works on Windows, Linux, Mac OS X, Android, your WebGL enabled browser and soon iOS.

Bon dans tous les cas la discussion est ouverte, réellement, et on peut la continuer en MP

Et pour finir bonne année et meilleurs vœux à tous les survivants de PA

[Ass-Itch]

Bof faut pas t'accabler Vince, je sais que pour toi les circonstances étaient pas vraiment propices à ce moment là...

Sinon, moi aussi j'ai forcément pensé à une adaptation Android/iOs vu que j'ai les deux plateformes maintenant ( iPad/ZTE Blade S) mais c'est clair que je ne pige absolument pas comment les devs gèrent les différences de résolutions d'un appareil Android à un autre... tu peux m'éclairer ?
Ça serait couillon de discuter de ça en MP, ça fait revivre The Walking Dead PA

[Sheeft]

Pour les différences de résolution, Android a un système qui te permet de charger automatiquement les gfx adaptées à l'écran (tu as quelques niveaux : small medium large xlarge xxlarge). Et si les images correspondant à la taille de l'utilisateur ne sont pas présente, la taille la plus proche est choisie et redimensionnée.

Tout est fait pour qu'on se préoccupe le moins possible de ça…

Toujours est-il que les format de l'écran, ça m'a l'air d'être une autre affaire, et je vois pas comment le gérer autrement qu'en prenant en compte soi même dans son code, les dimensions de l'écran qui fait tourner l'application. Si quelqu'un s'y connait mieux à ce niveau je suis aussi preneur.

[Dr.Vince]

bon voilà ce dont je me souviens:

bah quand tu fais de l'android pure y a plusieurs "type" (dépendant de la taille, du nombre de pixels etc...) et pour chaque type (4 si je me souviens bien) tu fournis les gfx de différentes tailles/résolution.
explications complètes si tu as le courage

Par contre si on déterre nos blobs du placard on utiliserait libGDX, enfin je pense, tu m'as pas donné ton avis là-dessus.
Et libGDX fonctionne pas comme ça, tout est en taille fixe.
Par contre tu peux faire du relatif (en fonction du nombre de pixels de ton écran), derrière c'est du openGL donc les gfx sont resizés comme tu veux.
Mais du coup se pose la question de la résolution de ceux-ci car un gfx de 10x10 resizé sur du 80x80 ça doit pas faire joli (enfin je sais pas si y a des ratio aussi élevé).

Voilà, si des pro libGDX passe dans le coin et pouvait en dire plus ce serait cool.

[EDIT]

Bon on peut appliquer la méthode android pure à libGDX en fait avec un peu de code.

@Ass-Itch: t'y connais quelque chose à l'openGL ?

@Sheeft: ouais le layout c'est à toi de le gérer, mais tu peux en proposer plusieurs, et c'est fait en xml.
Mais bon pour un jeu.....

[t4ils]

Hello les gars

LibGdx, c'est de la bombe =D

Pour gérer les différentes résolutions, je ne me suis pas pris la tête au début. Je suis parti du principe que je codais sur la résolution la plus répandue : 800x480. Automatiquement, libgdx va faire un fit screen de la zone de jeu. Donc sur des résolutions au même ratio : nickel. Sur des réso plus exotiques : étirements des gfx ... Sans parler de la gestion des inputs qu'il faut adapter à l'écran ciblé. (Sur un 320x240, tu peux pas toucher l'écran en (600, 312) )

Donc c'était ma première méthode, un peu caca mais ça tourne partout.

Ensuite, je me suis tourné vers un dezoom / zoom de la zone de jeu avec conservation du ratio original. Ainsi, les gfx ne sont plus étirés mais j'ajoute des bandes noires sur les zones d'écrans non utilisées. On garde une image propre, mais on perd de l'espace écran ...

Finalement, j'en suis à une méthode un peu chiante à gérer mais qui rend bien : si l'écran est plus grand, on affiche plus de jeu.
Je fais un jeu de style jumping game en ce moment. J'ai décidé de garder la largeur de l'écran fixe (j'ai toujours 480 pixels de largeur, étiré à la taille dispo sur l'appareil) et c'est la hauteur qui s'adapte.
Le ratio est respecté, on affiche juste le niveau plus grand.
(Ça me rappelle les RTS à l'époque. Plus la résolution était grande, plus tu voyais la map )

Démonstration :



En abusant sur la résolution dispo (je change la taille de la fenêtre), on voit que mon système affiche une plus grande partie du niveau s'il en a besoin.
Les GFX ne sont pas étirés, et on profite des grandes résolutions.
On voit aussi que comme je ne gère pas la taille des GFX selon la résolution, le jeu réduit la taille des images et elles rendent un peu scintillante. Pour corriger cela, il me faudrait plusieurs tailles de texture selon la résolution. Pour ce cas là, si je charge des textures plus petites le jeu aura pas besoin de les redimensionner autant et elles paraîtront propre (= non scintillantes)

Voilà une autre situation de tous les jours : résolution 800x480 contre 854x480 :



Le screen avec une hauteur de 854 pixels affiche 54 pixels de plus que l'écran à 800 pixels.

Tout ça se fait grâce à un objet de type caméra et beaucoup d'arrachage de cheveux
J'ai un peu lu cet article pour m'aider, mais c'est surtout le bidouillage qui m'a permis de m'en sortir
http://code.google.com/p/libgdx/wiki...entalsViewport

Et ça mène vers :
http://code.google.com/p/libgdx/wiki/OrthographicCamera
http://code.google.com/p/libgdx/wiki...ViewportCamera

======================

Si vous voulez vous jeter dans l'aventure LibGdx (même pour faire des jeux pour pc !), vous pourrez trouver le wiki qui indique tout bien
http://code.google.com/p/libgdx/wiki/ProjectSetupNew

Je conseil l'utilisation de LibGdx Setup qui permet de créer un template ready to go
http://www.aurelienribon.com/blog/20...-setup-v3-0-0/

Voilou

Edit : je viens de tomber la dessus aussi, ça peut aider à démarrer
Si vous utilisez libgdx setup, vous pouvez aller directement au chapitre "Creating the Game" étant donné qu'avant, c'est la configuration du projet
http://obviam.net/index.php/getting-...torial-part-1/

[Ass-Itch]

Envoyé par Dr.Vince

@Ass-Itch: t'y connais quelque chose à l'openGL ?

Carrément que dalle C'est important ?

Sinon, merci T4ils pour les divers exemples. A mes yeux, l'option "ajout de bandes noires" serait la meilleure pour un puzzle game, parce qu'il n'y a pas vraiment de portion de la surface de jeu qui puisse supporter d'être masquée.

Je vais partir de la résolution "standard" et regarder ce que ça pourrait donner...

[Dr.Vince]

attention y a 2 choses différentes: les dimensions de l'écran et la résolution.

Donc pour le problème de dimension, ok pour des bandes noires, ou mieux le fond d'écran plus large.
Après pour la résolution, y a 4 "formats" d'images normalement, et je pense qu'en gérer deux seraient bien.
De toutes façon tu travaille pas au pixel mais en vectoriel donc ça devrait faciliter la chose nan ?

pour l'openGL j'y connais rien donc si t'avais eu des compétences ça aurait été un plus.

Bon bah le projet va peut-être repartir alors ?

[Ass-Itch]

Ok pour le fond d'écran plus large, c'est effectivement le mieux et le plus simple.
J'ai effectivement créé la plupart des éléments du jeu en vectoriel, notamment les sprites des blobs, mais toutes les tiles ont été dessinées à la mano sous Photoshop... bref, y'a un peu de taf

Je sais pas si le projet peut repartir, mais on pourrait déjà regarder si y'a moyen de faire un embryon de moteur de jeu... genre contrôler un blob, non ? Je pourrais pondre les sprites relativement rapidement je pense.

[Dr.Vince]

ouais faudrait test un peu libGDX voir ce que ça donne, déjà faut installer le truc.

Pour les tiles en plus, je sais pas trop si on doit utiliser la même philosophie que sur DS ou PSP, faut voir si libGDX gère ça d'ailleurs.

Pour le moteur par contre, ce coup-ci on va utiliser des trucs déjà existant, comme ça y aura qu'à coder les interaction de jeu.

Mais bon dans tous les cas si ça redémarre on fera l'inverse de la dernière, on code le jeu et ensuite les écrans d'intro etc...

Par contre pour effectuer les tests je pensais plus à l'écran de sélection de niveau que la gestion d'un blob car ça me paraît plus simple.

Affaire à suivre...

[Ass-Itch]

Envoyé par Dr.Vince

Mais bon dans tous les cas si ça redémarre on fera l'inverse de la dernière, on code le jeu et ensuite les écrans d'intro etc...

Je me suis dis pareil

Envoyé par Dr.Vince

Par contre pour effectuer les tests je pensais plus à l'écran de sélection de niveau que la gestion d'un blob car ça me paraît plus simple.)

Pas de soucis, je regarde ça

[Dr.Vince]

sinon le truc le plus important avant de faire quoi que ce soit c'est de revoir le gameplay pour savoir comment appliquer des inputs tactiles par rapport au concept du jeu, car c'est un peu incompatible....

[Ass-Itch]

Envoyé par Dr.Vince

sinon le truc le plus important avant de faire quoi que ce soit c'est de revoir le gameplay pour savoir comment appliquer des inputs tactiles par rapport au concept du jeu, car c'est un peu incompatible....

Hum... On sélectionne un blob en cliquant dessus, puis dans un second geste on choisit la direction en glissant le doigt de droite à gauche, de haut en bas etc. ?
Pour le reste, ça ne sera que du clic basique...

[t4ils]

Envoyé par Dr.Vince

Pour les tiles en plus, je sais pas trop si on doit utiliser la même philosophie que sur DS ou PSP, faut voir si libGDX gère ça d'ailleurs.

LibGdx peut gérer les tiles pour toi, mais j'ai jamais testé :
http://code.google.com/p/libgdx-users/wiki/Tiles

Je le fais moi même : un tabeau à deux dimensions indiquant l'index du tiles à afficher en x, y

[Dr.Vince]

Envoyé par Ass-Itch

Hum... On sélectionne un blob en cliquant dessus, puis dans un second geste on choisit la direction en glissant le doigt de droite à gauche, de haut en bas etc. ?
Pour le reste, ça ne sera que du clic basique...

lol, j'ai pas essez l'habitude de jouer sur du tactile, mais effectivement c'est une évidence.
Suivant la puissance/vitesse du geste ça déterminera la distance effectué par le blob.

Envoyé par t4ils

LibGdx peut gérer les tiles pour toi, mais j'ai jamais testé :
http://code.google.com/p/libgdx-users/wiki/Tiles

Je le fais moi même : un tabeau à deux dimensions indiquant l'index du tiles à afficher en x, y

ouais, vu le besoin qu'on a ça va finir comme ça

[Ass-Itch]

Envoyé par Dr.Vince

Suivant la puissance/vitesse du geste ça déterminera la distance effectué par le blob.

Ouais enfin ça c'est si on veut faire un enième remake d'Angry Birds A la base les blobs se déplaçaient jusqu'à butée... j'avais fais un doc texte sur tous les mécanismes de jeu, si tu veux y jeter un oeil j'ai moyen d'uploader des fichiers sur Unfuddle ?
Après on peut aussi repartir sur un tout nouveau concept, pourquoi pas