Ultimate Smash Friends: un smash bros like en python

tshirtman · Le 09/05/2011, à 20:22

Oui, c'est en effet, un problème, la montagne doit bien être posée sur quelque chose, je suppose qu'on pourrait gérer ça avec une graaaaande image middle, et une grooooosse marge négative en bas… à voir.

Mais oui, les textures c'est vrai que ça fait gagner du temps

doudoulolita · Le 09/05/2011, à 22:17

Nouvel essai en transformant la photo de texture grâce au filtre "peinture à l'huile" de Gimp. Voici Troglo2:

J'ai un peu simplifié les grottes pour donner un côté plus dessin, et le fond est fait "à la main" . La disposition des grottes me semble ici plus logique, non ?

Si la montagne se ballade, c'est que c'est surement un astéroïde extra-terrestre, mais dans ce cas, faudrait mettre des grottes extra-terrestres aussi.

Plus sérieusement, on peut essayer de la mettre sur des nuages, pourquoi pas ?

J'ai juste une petite erreur dans mes images: les ascenseurs ne doivent pas être sur le foreground, il faut en faire des moving blocks qui montent et descendent, je pense. mais ce n'est pas compliqué à faire pour des pros comme nous !

Dernière modification par doudoulolita (Le 24/10/2011, à 17:36)

tshirtman · Le 09/05/2011, à 22:22

On peut la poser sur des nuages oui ^^ après tout, on a pas besoin de trop justifier, c'est déjà loin d'être réaliste ^^

(tiens on pourrait même mettre des bouncing blocs dans les nuages, on tomberait alors uniquement par les cotés…)

edit; ou sinon, une image front qui descend vachement bas, et qui fait un genre de ravin qui cache les personnages qui tombent

Dernière modification par tshirtman (Le 09/05/2011, à 22:26)

doudoulolita · Le 09/05/2011, à 22:52

Avec quelques nuages bas. Faut tester en jeu pour voir si ça rend bien ou non.

Dernière modification par doudoulolita (Le 24/10/2011, à 17:37)

tshirtman · Le 09/05/2011, à 22:59

hum, oui je les voyait plus gros mais bon, c'est à tester, de toutes façons…

http://bazaar.launchpad.net/~usf-team/u … yoland.xml
tiens, un exemple de vector bloc (ce que j'appelais bounce/bouncing-bloc, trampolines… tout à l'heure) ici

j'ai mis à jours le tar.gz, j'avais vraiment pas pris le bon fichier…
http://launchpad.net/ultimate-smash-fri … 1.6.tar.gz

et bonne nuit

Dernière modification par tshirtman (Le 09/05/2011, à 23:00)

doudoulolita · Le 10/05/2011, à 06:53

install réussie sous Windows7 de la version exe de la page http://usf.tuxfamily.org/blog/?p=96 Je n'ai pas joué vraiment mais tout s'est bien ouvert.
Je pense que tu peux mettre cette version en lien ici : http://usf.tuxfamily.org/wiki/Download#Windows car là, le lien de cette page est cassé.

Pour mon niveau Troglo, je crois que je vais réduire la taille de la montagne pour laisser de la place aux nuages du bas.

Dernière modification par doudoulolita (Le 10/05/2011, à 06:56)

tshirtman · Le 10/05/2011, à 08:44

J'ai corrigé le lien, que j'avais foiré à l'édition...

doudoulolita · Le 10/05/2011, à 13:35

J'ai fait un bzr pull qui me donne ça à la fin:

Conflict adding file data/characters/pixie.  Moved existing file to data/characters/pixie.moved.
Conflict adding file data/levels/blobplanet.  Moved existing file to data/levels/blobplanet.moved.
Text conflict in data/levels/cave/level.xml
3 conflicts encountered.                                                       
Now on revision 749.

Le truc bizarre, c'est que ça s'ouvre, je peux choisir les persos mais "Awesome Possum" est écrit au-dessus de l'image de Pixie, ensuite, je choisis un décor et ça plante.
Il y a un conflit entre la nouvelle version et mes datas personnelles qui sont restées dans le dossier (je vois tous mes essais de décors).
Pour les personnages, j'ai le dossier Rohon à la fois dans les characters unfinished et dans les characters puisqu'il fait partie de mes données personnelles. J'ai aussi un dossier pixie.moved, en plus du dossier pixie, qui s'est mis dans le dossier characters. il contient une version plus ancienne de Pixie.

Je refais un test en virant Rohon et Bearsum du dossier characters et en utilisant un décor "officiel". Là ça marche avec Blob et Pixie, sur Biglevel mais il y a encore des décalages dans les noms qui s'affichent au moment du choix des persos.
Avec d'autres décors ou persos "non officiels", ça plante parfois mais je ne sais pas pourquoi exactement (xml foireux ou autre).
Je teste mon nounours Miks qui a très peu de mouvements: A priori, il est capable de marcher dans biglevel mais je ne sais pas ce qu'il fera si j'essaie des trucs plus compliqués ! A une époque, ça plantait quand il était censé s'upgrader.
Cela montre qu'il faut prévoir un truc pour les personnes qui insèrent leurs persos et leurs décors en test ou pour se créer leur version personnelle. Ne pas oublier non plus de prévoir qu'on peut vouloir tester en jeu ou incorporer un perso pas fini.

Dernière modification par doudoulolita (Le 10/05/2011, à 14:12)

tshirtman · Le 10/05/2011, à 14:51

j'ai eu des soucis avec les conflits bzr pour ça aussi... je pense pas qu'on ait ce genre de soucis en ajoutant proprement des dossiers persos, faut juste pas qu'il y ait de conflits de noms si on mets à jours le bzr

Pylades · Le 11/05/2011, à 15:59

Avec Possum contre Xeon sur biglevel, je n’ai pas réussi à toucher Xeon une seule fois dans la partie. Pas une question de maniabilité délicate, là, mais tous mes coups passaient au travers.

tshirtman · Le 11/05/2011, à 16:09

Je pense faire grossir les points de contacts de coups, là ils font un pixel, c'est vrai que c'est un problème… (et ça devrait pas couter plus cher en temps de calcul).

un petit inflate(5,5) sur les rects…

edit: un patch comme ça: ça résoud le soucis?

=== modified file 'usf/entity.py'
--- usf/entity.py    2011-05-05 21:01:51 +0000
+++ usf/entity.py    2011-05-11 15:15:45 +0000
@@ -379,9 +379,10 @@
         test entity aggressive points collisions with other entity
         """
         for point in self.agressiv_points:
-            if entity.rect.collidepoint(
-                    self.rect[0] + point[0][0],
-                    self.rect[1] + point[0][1]):
+            if entity.rect.colliderect(
+                    self.rect[0] + point[0][0] - 3,
+                    self.rect[1] + point[0][1] - 3,
+                    6, 6):
                 entity.hit(point, self.reversed)
 
     def hit(self, point, reverse):

re-edit: après, c'est vrai que ça peut aussi venir du placement des points, je suis pas repassé sur possum récemment, mais il faut équilibrer la force de leurs coups, leurs placements, leurs nombres, pour que chaque perso soit aussi apte a gagner une partie que les autres ^^.

Dernière modification par tshirtman (Le 11/05/2011, à 16:19)

tshirtman · Le 11/05/2011, à 16:46

=== modified file 'usf/main.py'
--- usf/main.py    2011-05-08 07:30:37 +0000
+++ usf/main.py    2011-05-11 15:39:42 +0000
@@ -116,8 +116,6 @@
 
             self.init_sound()
 
-            self.ai = AI()
-
             # if a level was provided and at least two players in the option
             # immediatly jump into game mode
             if len(self.players) > 1 and self.level is not None:
@@ -277,6 +275,7 @@
             self.state = 'game'
             if game_ is not self.game:
                 print "starting game"
+                self.ai = AI()
                 #if self.ai_thread:
                     #self.ai_thread.stop_AI()

fix pour l'AI qui démarre pas pour les parties suivant la première… (c'est tellement idiot comme bug >_<)

(oui je peux pas commiter ici… donc je pose les corrections ici )

Pylades · Le 14/05/2011, à 03:03

tshirtman a écrit :

[…] (c'est tellement idiot comme bug >_<)

En effet ! ^^

doudoulolita · Le 16/05/2011, à 05:34

Une version légèrement améliorée de Troglo, avec un peu plus d'espace autour de la montagne. J'ai même peaufiné l'accrochage des ficelles, avec une ombre autour des gros clous :

Je n'ose pas ajouter trop de ciel autour car j'ai peur qu'à petite résolution, le niveau ne soit plus jouable. Si ça vous va côté design, je ferai le xml dès que possible.
Merci de me donner votre avis et de m'indiquer les améliorations possibles, s'il y en a encore.

Dernière modification par doudoulolita (Le 16/05/2011, à 06:24)

tshirtman · Le 16/05/2011, à 08:12

Hum, tu n'es pas obligé de mettre du ciel dans la partie middle du niveau, on mettra des marges de toutes façons.

Sinon, c'est pas mal

Mets une partie des nuages sur la partie foreground du niveau, ce sera plus sympa quand les persos tombent.
edit: j'avais pas vu que c'était déjà le cas

Dernière modification par tshirtman (Le 16/05/2011, à 09:59)

doudoulolita · Le 19/05/2011, à 18:56

J'ai fait le xml pour troglo2, ce qui donne le dossier complet suivant: troglo2.zip.

Ca marche à peu près sous Windows, les persos sont un peu trop haut de quelques pixels, il faut peut-être corriger un peu les coordonnées des pods du fait qu'ils sont un peu obliques ou les redresser.
Tshirtman, si tu peux corriger le xml et me le renvoyer, ce serait sympa.
J'ai eu un petit plantage à un moment mais je ne sais pas pourquoi. J'ai réduit les marges par rapport au modèle que j'avais et je n'ai pas d'entry-point. A ce propos, je ne sais pas trop ce que ces entry-point déterminent.

Dernière modification par doudoulolita (Le 19/05/2011, à 21:36)

doudoulolita · Le 19/05/2011, à 21:34

Le zoom au départ est un peu trop gros au début sur Troglo 2, je pense que voir le niveau en entier au début serait mieux puis ensuite zoomer. Là, c'est le contraire.

Ca m'a fait penser qu'un truc sympa serait de pouvoir indiquer le % de zoom désiré à différents moments du jeu dans le xml, au moins au moment d'arriver sur le niveau, à temps =1
On pourrait aussi se baser sur la position des persos (persos près d'une plate-forme par exemple) ou sur des évènements pour dire quel zoom on veut à ce moment-là.

C'est plus facile à dire qu'à faire, j'imagine, mais je vous fais confiance à tous pour ce genre de truc !

tshirtman · Le 19/05/2011, à 22:00

En effet, plus facile à dire qu'a faire tu pourrais faire un exemple de comment tu verrais ça au niveau xml, avec une explication du résultat attendu dans chaque cas?

Enfin, je vais regarder troglo déjà

tshirtman · Le 19/05/2011, à 22:52

hop
http://pub.tshirtman.fr/ultimate-smash- … /level.xml

J'ai corrigé les ascenceurs, vu que les barres sont un peu obliques, j'ai fait deux rect pour chacun afin, de coller au plus prêt à la forme…

Aussi, j'ai multiplié les temps des animations par deux, par ce que c'était quand même très rapide! Bon, on peu réaccélérer un peu si tu veux, mais peut être pas autant (sauf si le but c'est de faire un niveau techniquement difficile ^^).

tshirtman · Le 20/05/2011, à 22:11

A ce propos, je ne sais pas trop ce que ces entry-point déterminent.

Oups, oublié de répondre à ça… c'est les endroits ou peuvent apparaitres les persos, si on en met pas, il en invente 4 équidistant (20%, 40%, 60% et 80% du niveau en largeur) placés vers le haut du niveau. Mais c'est mieux de les placer à la main, sinon, desfois ils sont au dessus du vide, ou pas intelligemment placés…

doudoulolita · Le 21/05/2011, à 23:07

Merci pour avoir retravaillé ce niveau, ça marche sous Windows7. Merci aussi pour l'explication des entry-points.

Pour le zoom, si on veut que le niveau soit vu pendant 500 secondes au début du jeu à la taille maximum (en entier) on pourrait mettre dans le xml :

<zoom vue="entier" time="1 500">

Pour que ça zoome ensuite sur les persos jusqu'à la fin de la partie:

<zoom vue="persos" time="501 fin">

ça oblige à déterminer où sont les persos et à calculer la partie à montrer en fonction mais on dirait qu'à l'heure actuelle, c'est comme ça que ça fonctionne.

Si on associe à un évènement, ça pourrait être une action d'un des combattants avec un zoom plus serré sur celui qui tape.

<zoom vue="action" evenement="kick">

Ou plus simple peut-être, laisser tout le temps du jeu le choix au joueur de zoomer avec la molette de la souris, et dans ce cas, ça ne se passe pas dans le xml mais dans le jeu.

Sinon, j'ai un peu de mal à attraper les items quand je joue. Mais bon, je joue toujours comme une patate !
De toute façon, je trouve que ce serait bien que les items soient associés à certains niveaux et pas à d'autres. Ils seraient appelés alors par le xml du niveau.
<item nom="fireball">

tshirtman · Le 21/05/2011, à 23:47

doudoulolita a écrit :

Merci pour avoir retravaillé ce niveau, ça marche sous Windows7. Merci aussi pour l'explication des entry-points.
Pour le zoom, si on veut que le niveau soit vu pendant 500 secondes au début du jeu à la taille maximum (en entier) on pourrait mettre dans le xml :
<zoom vue="entier" time="1 500">

Hum, maximum, avec les marges? par ce que ça veut dire un zoom très "bas" (un gros dézoom quoi) sur la plupart des niveaux, (vu que c'est la limite avant que les persos sortent du niveau) donc on verrait les persos très petit, et ça ferait ramer les petites machines, si c'est sans les marges, et que les persos sortent donc de la vue, sans sortir du niveau, il devient difficile de savoir ou ils sont, et donc de revenir sur les plateformes…

donc je ne sais pas si c'est une très bonne idée…

Pour que ça zoome ensuite sur les persos jusqu'à la fin de la partie:
<zoom vue="persos" time="501 fin">
ça oblige à déterminer où sont les persos et à calculer la partie à montrer en fonction mais on dirait qu'à l'heure actuelle, c'est comme ça que ça fonctionne.

Oui, j'essaye de déterminer le plan le plus serré qui permette de voir tous les persos, et je l'applique… bon, y'a une limite, je ne zoom pas plus que la taille des pixels quoi…

Si on associe à un évènement, ça pourrait être une action d'un des combattants avec un zoom plus serré sur celui qui tape.
<zoom vue="action" evenement="kick">

Hum, et si on est plus que 2? on ne voit pas un perso le temps que les autres se battent?

Ou plus simple peut-être, laisser tout le temps du jeu le choix au joueur de zoomer avec la molette de la souris, et dans ce cas, ça ne se passe pas dans le xml mais dans le jeu.

Hum, ça non, ça veux dire lacher le clavier pour changer le zoom, surtout si on est deux ou plus sur le même clavier, ça ne me semble clairement pas viable dans usf…

Sinon, j'ai un peu de mal à attraper les items quand je joue. Mais bon, je joue toujours comme une patate !
De toute façon, je trouve que ce serait bien que les items soient associés à certains niveaux et pas à d'autres. Ils seraient appelés alors par le xml du niveau.
<item nom="fireball">

Oui, pour l'instant, les items droppés sont via un évenement global, qui était plus à but de test des évenements à l'origine, je pense que je devrais ajouter la gestion des évenements aux niveaux… ça parait logique que certains niveaux aient leurs évenements propres.

doudoulolita · Le 22/05/2011, à 00:12

Voici la nouvelle version de level.xml pour troglo2. J'ai ajouté les entry-point mais bizarrement, ils se retrouvent presque immédiatement à plusieurs persos sur une plate-forme alors que j'ai essayé de répartir correctement les entry-point, tant en hauteur qu'en largeur.

Lors d'un des essais, il y en avait même un qui tombait alors qu'il était censé être sur une plate-forme au bord d'une grotte. Mais à ce moment là, je tenais compte du centre des persos et non du coin supérieur gauche... Je pense que mon erreur vient de là ?
L'idéal serait de pouvoir situer les entry point en fonction du centre des pieds, ça faciliterait pour les gens pas trop programmeurs.

Au final, j'obtiens encore deux persos qui se retrouvent l'un sur l'autre et en plus, j'ai un plantage au bout de quelsues instants si je ne fais pas d'action autre que de déplacer ma souris.

Pourtant, le xml est bon pour le reste, c'est bizarre, non ?

doudoulolita · Le 22/05/2011, à 00:15

Ah, pour le zoom à 100 sur un niveau, mon envie c'est qu'on voit le décor en entier pendant un petit moment sinon je trouve qu'on ne comprend pas bien le niveau ni où on peut aller.
Là, on a un petit bout du niveau seulement et on navigue un peu au pif. C'est pour ça que ce serait bien de le voir en entier au début, surtout quand les plate-formes sont éloignées les unes des autres comme dans Troglo2.

Mais il faut évidemment que les persos soient dans la vue, effectivement, s'ils ne sont pas dedans je ne vois pas l'intérêt. Ils seront un peu petits avec ce système mais ce serait juste au début de la partie, le plan large, en guise d'introduction.

Le fait qu'il y ait 4 persos en même temps ne doit pas arriver super souvent tant qu'on se bat sur un seul ordi, non ? Déjà, à 2, ce n'est pas si évident sur un seul clavier !
Tant que le jeu n'est pas en réseau, je pense que les joueurs seront 2 ou seuls contre l'AI, le plus souvent.

Dernière modification par doudoulolita (Le 22/05/2011, à 00:27)

doudoulolita · Le 22/05/2011, à 01:48

Un niveau nommé Meteor qui utilise la même technique que Troglo2 pour les roches (photo + filtre Peinture à l'huile de Gimp). J'ai encore 3 plate-formes et 2 moving-blocks.

Déjà, j'ai un admirateur pour ce niveau: mon mari !

Dernière modification par doudoulolita (Le 22/05/2011, à 01:49)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1376 Le 09/05/2011, à 20:22

Re : Ultimate Smash Friends: un smash bros like en python

#1377 Le 09/05/2011, à 22:17

Re : Ultimate Smash Friends: un smash bros like en python

#1378 Le 09/05/2011, à 22:22

Re : Ultimate Smash Friends: un smash bros like en python

#1379 Le 09/05/2011, à 22:52

Re : Ultimate Smash Friends: un smash bros like en python

#1380 Le 09/05/2011, à 22:59

Re : Ultimate Smash Friends: un smash bros like en python

#1381 Le 10/05/2011, à 06:53

Re : Ultimate Smash Friends: un smash bros like en python

#1382 Le 10/05/2011, à 08:44

Re : Ultimate Smash Friends: un smash bros like en python

#1383 Le 10/05/2011, à 13:35

Re : Ultimate Smash Friends: un smash bros like en python

#1384 Le 10/05/2011, à 14:51

Re : Ultimate Smash Friends: un smash bros like en python

#1385 Le 11/05/2011, à 15:59

Re : Ultimate Smash Friends: un smash bros like en python

#1386 Le 11/05/2011, à 16:09

Re : Ultimate Smash Friends: un smash bros like en python

#1387 Le 11/05/2011, à 16:46

Re : Ultimate Smash Friends: un smash bros like en python

#1388 Le 14/05/2011, à 03:03

Re : Ultimate Smash Friends: un smash bros like en python

#1389 Le 16/05/2011, à 05:34

Re : Ultimate Smash Friends: un smash bros like en python

#1390 Le 16/05/2011, à 08:12

Re : Ultimate Smash Friends: un smash bros like en python

#1391 Le 19/05/2011, à 18:56

Re : Ultimate Smash Friends: un smash bros like en python

#1392 Le 19/05/2011, à 21:34

Re : Ultimate Smash Friends: un smash bros like en python

#1393 Le 19/05/2011, à 22:00

Re : Ultimate Smash Friends: un smash bros like en python

#1394 Le 19/05/2011, à 22:52

Re : Ultimate Smash Friends: un smash bros like en python

#1395 Le 20/05/2011, à 22:11

Re : Ultimate Smash Friends: un smash bros like en python

#1396 Le 21/05/2011, à 23:07

Re : Ultimate Smash Friends: un smash bros like en python

#1397 Le 21/05/2011, à 23:47

Re : Ultimate Smash Friends: un smash bros like en python

#1398 Le 22/05/2011, à 00:12

Re : Ultimate Smash Friends: un smash bros like en python

#1399 Le 22/05/2011, à 00:15

Re : Ultimate Smash Friends: un smash bros like en python

#1400 Le 22/05/2011, à 01:48

Re : Ultimate Smash Friends: un smash bros like en python

Pied de page des forums