AngryBirds StarWars
Posté le 17/05/2014 21:20
Bonjour à tous,
Bienvenue sur la page du projet d'adaptation du jeu AngryBirds dans sa version
StarWars sur nos chères Casio
C'est un de mes plus vieux projets, et à ce titre il a eu droit à plusieurs reprises à zéro. Il est actuellement en cours de développement dans sa nouvelle version, codée en C++ pour les caltos 75/85/95 (SD).
Vidéo de presentation dans l'état actuel
Les nouveautés par rapport aux anciennes versions:
- J'ai ajouté un système de scroll et zoom car c'était ce qu'il me manquait le plus dans les anciennes versions pour réussir a faire des niveaux différents. C'est donc la plus grosse différence. Le seul problème est la qualité des graphismes. En effet, en zoomant ou en dezoomant on passe sur un affichage « simplifié » avec des éléments géométriques, car c'était ce qui rendait le mieux à cause de la taille des sprites ; mais ca perd un peu de charme
- Le moteur physique a été revu, notamment en ajoutant les « rebonds » des objets les uns sur les autres comme amélioration notable mais il a aussi été optimisé par rapport à l'ancien, ce qui permet d'ajouter plus d'éléments, j'espère, sans trop de perte de performances. Par contre les briques que l'on retrouve dans le jeu sur mobile et qui peuvent voler, s'abîmer, ... n'ont pas encore été ajouté car la physique est plus complexe et je ne sais pas si ça rendrait très bien, là aussi à cause de leur taille. Elles resteront donc probablement fixes dans le futur.
- Les niveaux seront dorénavant chargés depuis des fichiers pour plus de simplicité et de facilité à ajouter les niveaux futurs
- Les menus vont changer pour quelque chose de plus simple que précédemment, car les anciens ne me plaisent plus.
- Les objets peuvent tourner grâce au patch de Ninestar sur MonochromeLib, ce qui est notamment utile pour la création de niveau ou pour la rotation des oiseaux en fonction de la direction dans laquelle ils vont.
L'état actuel et ce qu'il reste à faire:
Actuellement, il est possible de jouer au jeu. Le moteur physique est utilisable dans l'état énoncé au dessus. Il reste donc surtout à ajouter les niveaux.
Faire les menus
Faire les niveaux
Implémenter les capacités des oiseaux
Régler les bugs de rotation de sprites
La compatibilité SH4
Ajouter les briques mobiles (dans le futur ?)
Les personnes à remercier:
Lephenixnoir pour Memory et le partage de sprites.
Pierrotll pour MonochromeLib
Ninestars pour son amélioration de MonochromeLib, avec les algorithmes de rotation
DarkStorm pour ses tutos sur les syscalls
Aragorn pour ses sprites d'oiseaux
Shaber, d'OpenGameArt.org pour ses sprites de planètes
J'essayerai de tenir à jour ce topic au fur et à mesure.
Ancienne description (02/06/2015 à 30/07/2017)
Cliquer pour enrouler
Salut a tous,
Voila le projet que j'ai commencé il y a un bail et qu'il faut que je termine.
Il s'agit d'
une adaptation du jeu AngryBirds mais la version
StarWars. En effet, je me base sur mon moteur physique que j'avais fait pour les CPC et le projet "Appolo".
Enfin bref, j'espere qu'il vous plaira.
A l'heure actuelle, bien qu'une premiere version soit deja sortie, je suis en train de la mettre a jour avec de nouveaux graphismes plus fideles a ceux de l'original, avec differents piafs, des obstacles, ... Enfin bref, pleins de trucs cools.
J'ai deja refait pas mal de choses, à savoir:
la plupart des graphismes
la gestion des differents oiseaux et leurs capacitées (il faut que j'en revoit certaines)
l'affichage de la trajectoire pendant le lancé
les menus que je n'ai pas touché depuis la derniere version
le systeme de fichier fonctionnel
la symetrie des sprites des objets marche
Tout ceci nous donne un jeu avec cet aspect:
Il me reste a faire:
coder tous les niveaux manquants (3 mondes avec 9 niveaux plus 2 tutos)
faire l'algo de rotation des images pour alleger le bousin et diversifier les niveaux
appliquer la physique aux morceaux de bois (dans le meilleur de mes reves)
peut-etre faire un systeme de scroll, la taille etant pour le moment tres limitée
essayer de reprendre la comatibilité SH4 (pour le moment SH4 CT obligé)
Voila, j'espere que ca vous plaira, et que vous serez nombreux pour m'aider à debugger
Ancienne description (17/05/2014 à 02/06/2015)
Cliquer pour enrouler
Bon voila je fini par créer un topic
Donc depuis quelques temps, je suis sur un nouveau projet, une adaptation de Angry Bird StarWars sur calto
Ce Angry Bird est basé sur le moteur physique de Appolo (c'est surtout pour ça que je le fait) avec un disign un peu soigné même si je suis un peu limité par la résolution de l’écran...
Tout se fait avec EXE et les flèches et tout les corps (les cochon, les étoiles noires et les vaisseaux) vous attirent.
Je pense avoir tout dit
Donc voila le principal du jeu est fait, il me reste a faire (dans l'ordre des priorités):
tout les niveaux + les tutoriels
refaire un meilleur système de lancer
les personnages spéciaux
l’intégration de plusieurs cochons
un système de plusieurs étoiles ( finir à 3 étoiles tout les niveaux)
à vous de me proposer
Je me suis organisé pour les types de mondes:
Monde 1 : Un équivalent de Appolo, seulement aller taper le cochon
Monde 2 : Ajout des objets déplaçables avec l'aide de la force
(donc ajout des piafs speciaux)
Monde 3 : Plusieurs planètes avec des champs de gravités délimitées et variables et peut être plusieurs cochons
La première version est en pièce jointe avec les menus et le niveau 1 du monde 1 pour un petit aperçu
Fichier joint
Citer : Posté le 03/06/2015 15:15 | # |
Fichier joint
Renversant
Citer : Posté le 03/06/2015 17:07 | #
Euh ... T'as essayé quoi là ?
Citer : Posté le 03/06/2015 17:09 | #
J'ai juste testé mon algo de retournement d'image qui marche plutot bien avec toutes les tailles
Citer : Posté le 03/06/2015 17:11 | #
Ah ok :P En tous cas ton projet à l'air d'avoir bien avancé par rapport à le première version (qui, je dois l'avouer, n'était pas terrible
Citer : Posté le 03/06/2015 19:29 | #
Ben en fait, la première version, c’était juste un appolo un peu plus poussé avec des beaux menus si on prend que l'aspect du jeu et le "gameplay"
La franchement je suis plutôt fier de moi
Citer : Posté le 12/06/2015 10:13 | # |
Fichier joint
J'aurai besoin d'un petit coup de main
J'ai fini une version stable avec le monde 1 (dispo en pièce jointe), j'ai ajouté quelques trucs qui manquaient mais il en manque encore pas mal avant de pouvoir sortir une version finale.
Donc si vous avez des critiques sur des points à améliorer je suis preneur
(Toujours pas de compatibilité SH4 pour le moment, mais le SH4 CT fait le taff pour ceux qui ont des nouvelles caltos)
Bon comme annoncé dans la 100e RDP je me suis remis !
Je vous laisse lire le topic si vous voulez les details de la nouvelle version, maintenant place aux questions !
Voila j'aurai besoin de votre avis sur plusieurs points. Est-ce que selon vous:
Voilà j'attend vos avis et je me bouge pour vous sortir une version test histoire que vous vous fassiez un avis
Citer : Posté le 30/07/2017 15:30 | #
Hum, un champ de force sur chaque planète ? Pourquoi pas, ça permettrai de varier un peu le style de jeu
Pour le tracé du chemin de l'oiseau, tu utilises les équations horaires ? Si oui, tu ne calcules que 1 points sur 3, enfin, je pense ue c'est mieux avec le tracé
SUr le jeu original, je crois que la trace de l'ancien lancé y est à chaque fois, donc pourquoi pas le laisser (en gris clair #Gint)
Je pense que pour la beauté du jeu, il faut faire de vrais sprites, même si la hitbox reste un cercle.
Voilà
Citer : Posté le 31/07/2017 10:19 | # |
Fichier joint
Merci pour ton avis florian
Pour l'instant j'ai donc rajouté les champs de forces et le tracé avant tir permettant de voir un peu vers où ca va partir:
Par contre il devient urgent de passer sur Gint en effet pour les niveaux de gris notamment parce qu'il commence à y avoir des traits partout
Je ne passe pas par les equations horaires ça serait trop compliqué, donc j'integre pas à pas, c'est pour ca que je perd en rapidité, mais c'est aussi qu'il faut que je revois la gestion des touches, je pense qu'il y a du temps a gagner par là.
Citer : Posté le 31/07/2017 10:27 | #
Attention hein, le gris de gint ce n'est pas de la magie ! Il peut être très bon sur des sprites bien mesurés, et extrêmement mauvais sur des grands rectangles. En tous cas ce n'est pas un 4-couleurs parfait, donc pense à bien tester chaque essai pour t'assurer que ça rend bien
Le dessin est pas mal. À quoi correspond la ligne verticale à gauche ? Pour représenter les champs de force de manière pas trop dérangeante, tu pourrais afficher par défaut juste les planètes et le décor de l'espace. Et affecter un bouton « voir les champs de force » où tu mettrais les décors en retrait (peut-être en gris, à voir) et tu pourrais afficher les champs de force en mettant plus d'informations (notamment la force du champ gravitationnel, qui peut varier même pour deux planètes de même taille), même si c'est assez « intrusif » et que ça prend beaucoup de place.
Je crois que je reconnais ce dessin de planète ! Pense à créditer Shaber, d'OpenGameArt.org
Citer : Posté le 31/07/2017 10:36 | #
Le gris de gint gère des formes géométriques simples telles que les pixels ou les cercles surtout ? Après dans l'imédiat, je pense pas refaire des sprites avant un moment, enfin en tout cas c'est pas ma priorité
La verticale a gauche correspond à la limite de l'espace dans lequel les oiseaux peuvent évoluer (là elle est un peu proche). C'est pour éviter que ca parte trop loin.
Je sais pas trop pour cacher les champs de force parce que c'est quand meme un element qu'il est important de voir comme ca passe en un pixel de pas de force à un max de force appliqué. Après afficher la force des champs et la limite du terrain avec une touche ca peut être pas mal ouais
Citer : Posté le 31/07/2017 10:50 | #
Ah mais tu peux dessiner tout ce que tu veux en gris, c'est juste que ça risque d'être moche. Vois ceci.
Citer : Posté le 31/07/2017 17:26 | # |
Fichier joint
Voilà un premier add-in (non compatible SH4) avec un niveau à mettre dans à la racine de la calculatrice
Les contrôles de la caméra:
Pour lancer un oiseau:
Pour quitter:
Pour ce qui est des améliorations, je suis sur la sauvegarde du tracé mais pour l'instant j'ai le droit à une bonne vielle erreur d'allocation
J'ai encore optimisé le moteur physique pour prendre en compte seulement ce qui était proche ce qui m'a fait gagner pas mal en performance surtout lorsqu'il y a de nombreux éléments.
Citer : Posté le 31/07/2017 19:18 | #
Quelques remarques sur ton message :
- (quelques fautes corrigées)
- Refais les sprites en plus petits, au moins pour les planètes c'est facilement faisable.
- Charger les niveaux depuis *un* fichier, quitte à y laisser des emplacements libres à la fin pour les niveaux customs, serait le mieux. On ne voudrait pas avoir un dossier complet dans la SMEM, et ce sera un facteur de performance pour toi.
Citer : Posté le 31/07/2017 19:30 | #
Pourquoi ne pas mettre les niveaux directement dans l'addin ? Ca éviterait de rajouter un fichier dans la SMEM.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/07/2017 19:43 | #
Désolé pour l'orthographe.
Oui faut que je m'y mette mais pour faire les graphismes dans tout les cas j'attend de passer sur le fxSDK.
Pourquoi est-ce que avoir plusieurs fichiers réduit les performances ? Avoir des fichiers me permet d'aller plus vite dans la création de niveaux et évite d'avoir à faire des mises à jour de l'add-in
Citer : Posté le 31/07/2017 20:37 | #
Pourquoi les problèmes de perf' ? Parce que tu peux te permettre de charger plusieurs niveaux à la fois dans la mémoire (et tu devrais le faire). Et s'ils viennent tous du même fichier, ça va (notablement) plus vite.
Citer : Posté le 31/07/2017 23:26 | #
Pour le tracé du chemin de l'oiseau, tu utilises les équations horaires ? Si oui, tu ne calcules que 1 points sur 3, enfin, je pense ue c'est mieux avec le tracé
Je ne passe pas par les equations horaires ça serait trop compliqué, donc j'integre pas à pas
Et je ne comprends pas que ce soit lourd, j'ai fait Orbital en Basic et c'est hyper fluide. Les calculs sont hyper simples !!
Je ne connais pas le code de ton moteur mais voici quelques conseils
- Tu fais tes hitbox avec des cercles, ne calcule pas les racines carrées dans tes calculs de distance, c'est ce qui bouffe le plus et mathématiquement, le résultat de sqrt(a) < sqrt(b) est le même que a < b !
Pareil pour la distance de l'oiseau à la planète, surtout que tu disvises par d^2, donc encore moins utile de faire un sqrt pour faire un ^2 après.
- Pas besoin de sprite "petits" et "grands". Tu affiches que des sprites haute résolution avec mon algo pour zoomer un sprite. Comme ça avec une simple variable tu gères le zoom de ta map. Ça évite les disjonctions de cas
- je te conseille de réduire l'échelle de tous les éléments, sinon ça va faire comme le angrybirds de LouLoux, il est injouable car tout est trop gros ! T'as pas choisis le plus avantageux à ce niveau... avec les planètes ça implique de devoir tourner autour, d'avoir une caméra plus éloignée donc d'avoir des sprites petits et avec un angle (j'ai fait aussi un algo pour ça si ça t'intéresse), le rendu risque d'être assez moyen :/
- tu pourrais utiliser des vraies hitbox de rectangle quand même
Citer : Posté le 01/08/2017 00:55 | #
Merci Ninestars
- Je me croyait obligé de faire le calcul de d parce que comme un c** je me suis mis en tête que l'expression de l'attraction gravitationelle était en d^-3
- Oui c'est une possibilité mais j'ai peur que le zoom pour des éléments déjà petit ou alors de grand vers petit rende mal (j'ai pas moyens de tester la comme le sprite-coder est HS)
- Pour l'instant je suis plutôt satisfait du rendu graphique, enfin en tout cas au niveau des dimensions. Ce qui est sur c'est que dans tous les cas, je pourrai pas afficher correctement comme sur le jeu de base, parce que si on descend à une echelle en dessous ça devient carrément un challenge visuel
- Ah oui bien sur ! J'ai déjà des hitboxs en rectangle pour les "briques" que l'on peut casser mais qui sont immobiles pour l'instant, mais dans les faits, la plupart des objets ont des formes circulaires ou très proche
Citer : Posté le 01/08/2017 11:07 | #
- Pas besoin de sprite "petits" et "grands". Tu affiches que des sprites haute résolution avec mon algo pour zoomer un sprite. [...] De plus mon algo de zoom est ultra perfromant, rien à craindre de ce coté là...
- [...] avoir des sprites petits et avec un angle [...] le rendu risque d'être assez moyen :/
Et pourquoi tu crois que je voulais faire plusieurs sprites ? Aucun rendu n'est aussi bon qu'un dessin fait à la main ! Pour ton algo de zoom, je veux bien le voir, ça m'intéresse. Après n'oublie pas que gint est un chouille plus rapide que ML... et plus ton algo est rapide, moins le rendu est fidèle, ça me semble d'une logique implacable !
L'histoire de la rotation de la map est définitivement un challenge graphique. Mais n'oublie pas que la rémanence de l'écran est à prendre en compte. Pendant la rotation proprement dite, on ne verra pas grand-chose. Chaque sprite peut donc être dessiné à uniquement deux angles : 0 et π/4. Cela permet d'afficher un sprite « parfait » pour 8 directions, auxquelles la caméra peut se fixer pendant les animations. Et lorsqu'il faut changer d'octant, un algorithme bourrin peut se charger des rotations intermédiaires... qu'on ne verra pas beaucoup de toute façon !
Réduire des sprites hautes résolution, j'ai honnêtement des doutes. Parce que si on devait caractériser un sprite d'oiseau colérique au ratio 1/2:1/2, on ne dirait « c'est le même que le 1:1 mais en plus petit ». On ne dessinerait pas la même chose. On simplifierait les proportions pour aligner les traits sur les pixels, quitte à schématiser outre mesure, on éliminerait des détails, et le résultat serait bien plus convaincant.
Surtout que, si le jeu à sa résolution maximale est trop grand, comme tu le laisses entendre Ninestars, on passera 90% du temps de gameplay devant les versions réduites. Elles ont intérêt à être béton (et un nearest-neighbour par exemple, ne peut pas faire ça).
Citer : Posté le 01/08/2017 11:30 | #
Pour ton algo de zoom, je veux bien le voir, ça m'intéresse
Dans sa signature, tu as le lien
Réduire des sprites hautes résolution, j'ai honnêtement des doutes
En effet, comme attendu en faisant des tests sur des sprites de 32x32 initialement, le sprite devient vite troué. C'est à la fois pas génant et génant, mais c'est sur qu'en faisant des sprites pour les petites tailles en tout cas me semble inévitable.
L'histoire de la rotation de la map
Je sais pas si j'ai bien compris l'idée. Le but ça serait d'avoir en gros toujours l'oiseau dans sa position normale ? Si c'est ça j'en ai pas l'intention
Citer : Posté le 01/08/2017 12:50 | #
Ah oui c'est moi qui ai mal interprété cette phrase de Ninestars !
T'as pas choisis le plus avantageux à ce niveau... avec les planètes ça implique de devoir tourner autour, [...]
C'est l'oiseau qui tourne autour, pas la caméra !
Merci pour la lib ! Alors du coup Ninestars, c'est clair que la rotation est optimisée, je vois pas de technique plus rapide à vue de nez. Je n'ai pas fait le test de comparaison de performance encore, mais je le ferai à l'occasion. Ça risque quand même d'être 25/30 fois plus lent que l'affichage normal de sprite avec gint.