Bubble Crusher 0.9 bêta release

Posté par contra-sh le 12 mars 2012 à 19:00. Édité par Nÿco, baud123 et B16F4RV4RD1N. Modéré par claudex.

Étiquettes :

mar.

2012

Depuis quelques années, le temps passé (perdu? :D) sur nos smartphone à jouer à des jeux n'a cessé d'augmenter. C'est en pratiquant ce passe temps que j'ai découvert un jeu vraiment addictif nommé Bubble Explode qui est un dérivé du célèbre Same Game.

Le principe de ce jeu est simple, l'écran est composé de billes de couleurs et il faut faire éclater les groupes de billes de même couleur. La gravité fait ensuite descendre les billes et réorganise ainsi l'écran de jeu. Plus les groupes de billes sont grands, plus on obtient de points. De même, certaines formes multiplient le score par un coefficient. Plusieurs tailles et modes de jeu sont disponibles.

L'histoire de bubble crusher commence lorsque ma copine se met à emprunter mon smartphone pour jouer à ce jeu. D'autres personnes de mon entourage qui avaient téléchargé cette application s'amusaient à battre systématiquement ses records personnels ce qui la faisait « enrager ». Désespérée de ne pas pouvoir battre les records des autres, elle me demande alors si je suis capable de développer un solveur pour ce jeu. Bête et tout amoureux que je suis, j'accepte et me voilà lancé à développer un petit simulateur de bubble explode en pygtk (ce qui devait me permettre en fait de tester les algorithmes de résolution).

Finalement, j'ai codé le jeu avec une interface graphique mais je n'ai jamais fait le solveur :D Je vous présente donc Bubble Crusher 0.9 bêta, sous licence GPLv3.

Ce jeu est toujours en développement, il reste des choses sur ma todo list, et sûrement quelques bugs. J'attends cependant vos impressions et rapports de bug. Pour les plus courageux (= barbus), j'ai également développé une version légèrement différente pour ti83, en assembleur…

Aller plus loin

Télécharger Bubble Crusher 0.9 bêta (1053 clics)
Page Wikipédia traitant de Same Game (634 clics)
Bubble explode pour Android (554 clics)
Same game pour ti83 (214 clics)

# retour sur le dev TI83 ?

Posté par Thomas Debesse (site web personnel) le 12 mars 2012 à 21:04. Évalué à 5.

Pour le dev ti83 tu travailles sous GNU/Linux ? avec quels outils ?

J'ai vu qu'il existe un émulateur : TiLem, un assembleur : zasm, et un ide : z80asmide, c'est fonctionnel comme suite ?

ce commentaire est sous licence cc by 4 et précédentes
# Les esprits se rencontrent

Posté par Thomas Debesse (site web personnel) le 12 mars 2012 à 21:11. Évalué à 6.

Au début, en lisant ta dépêche

Depuis quelques années, le temps passé (perdu? :D) sur nos smartphone à jouer à des jeux n'a cessé d'augmenter.

Je me suis rappelé qu'avant les smartphones, j'ai passé (perdu ?) beaucoup de temps sur calculette"

Puis en lisant

C'est en pratiquant ce passe temps que j'ai découvert un jeu vraiment addictif nommé Bubble Explode qui est un dérivé du célèbre Same Game.

J'ai pensé "c'est en jouant sur ma ti83+ que j'ai découvert un autre jeu addictif : la programmation"

Alors quand à la fin de ta dépêche tu annonce une version ti83… Ça m'a fait tout drôle !

Au passage, je découvre que le développement sur ces archis n'a jamais été aussi vivant, plus que lorsque j'étais lycéen ! C'est amusant. :)

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Les esprits se rencontrent
  
  Posté par Zenitram (site web personnel) le 12 mars 2012 à 21:58. Évalué à 10.
  
  J'ai pensé "c'est en jouant sur ma ti83+ que j'ai découvert un autre jeu addictif : la programmation"
  
  Je remercie l'éducation nationale pour m'avoir permis d'apprendre à programmer, ce qui m'a permis de créer un emploi (le mien), sur cette calculatrice (presque, je me souviens plus le modèle concurrent chez Casio, la mémoire… Désolé, la TI-83 était trop chère, gosses de riches!). Vous vous étonnez que l'éducation nationale fasse des cours de programmation? Ca a un autre nom en fait : Philo (au fond de la classe).
# Jeu très sympa

Posté par JGO le 12 mars 2012 à 23:58. Évalué à 2. Dernière modification le 12 mars 2012 à 23:59.
- C'est quoi le groupe de billes qui apparait en haut à un certain moment ?
- J'ai l'impression qu'il y a des billes supplémentaires qui apparaissent dans ma grille de jeu parfois, quelle est la raison ?
# Génial

Posté par barul le 13 mars 2012 à 07:40. Évalué à 1.

Je viens de le tester rapidement, c'est super! Encore un jeu qui va faire baisser ma productivité… :-)
# Petit bug, fermeture application.

Posté par zyphos le 13 mars 2012 à 09:14. Évalué à 3.

Quand je me log sur Sourceforge, je comprend pas comment il faut faire le bug reporting, donc je poste le report ici.

ui.py:
Ligne 429:
bub.connect("destroy", bub.quit)

A remplacer par:
Ligne 429:
bub.connect("destroy", bub.quit, 'Quit')

Sinon erreur lorsqu'on clique sur la croix de fermeture de la fenêtre. Et CTRL-C obligatoire.

Ce bug est peut-être volontaire. Pour nous empêcher de travailler. :p
- [^] # Re: Petit bug, ouverture application.
  
  Posté par jihele le 13 mars 2012 à 13:38. Évalué à 2.
  Lorsqu'on lance l'application depuis un autre répertoire, ça foire parce que les chemins vers les images sont indiqués en relatifs, et python cherche dans le répertoire où il a été lancé, pas dans le répertoire du fichier ui.py.
  
  Ça peut se résoudre en créant à l'init un attribut install_path
```
class interface(gtk.Window):
  def __init__(self):
    super(interface, self).__init__()
    self.install_path = os.path.dirname(inspect.getfile(inspect.currentframe()))
```
  qu'on utilise pour préfixer les chemins :
```
blue = cairo.ImageSurface.create_from_png(self.install_path + '/pixs/blue_alpha.png') 
red = cairo.ImageSurface.create_from_png(self.install_path + '/pixs/red_alpha.png') 
green = cairo.ImageSurface.create_from_png(self.install_path + '/pixs/green_alpha.png') 
yellow = cairo.ImageSurface.create_from_png(self.install_path + '/pixs/yellow_alpha.png') 
boum = cairo.ImageSurface.create_from_png(self.install_path + '/pixs/boum_alpha_big.png')
[...]
```
  Testé chez moi, ça marche mais ce n'est peut-être pas la façon habituelle de procéder, je n'en sais rien. Une autre approche pour distribuer pourrait être de mettre les chemins en dur dans les fichiers du paquet. Ou, pour distribuer une archive, d'utiliser un makefile qui modifie les fichiers .py lors du make install pour remplacer pas exemple $INSTALL_DIR par le chemin qui va bien. Mais peut-être qu'en python, on fait encore autrement. Si qqn sait, ça m'intéresse.
  
  Avant la release, il faudrait aussi placer le fichier de config dans un répertoire adapté. J'avais posé la question ici-même. Je l'ai fait pour gbirthday et ça donne ça, mais il y a peut-être plus simple :
```
        # If XDG_CONFIG_HOME is defined, use it to store config files
        if 'XDG_CONFIG_HOME' in os.environ:
            self.base_config_path = os.environ['XDG_CONFIG_HOME'] + "/gbirthday"
            # If no config file here, check for config files in ~/.config
            if not os.path.isdir(self.base_config_path):
                if os.path.isdir(os.environ['HOME'] + "/.config/gbirthday"):
                    shutil.copytree(os.environ['HOME'] + "/.config/gbirthday",
                                    self.base_config_path)
                else:
                    os.makedirs(self.base_config_path)
        # else, use ~/.config
        else:
            self.base_config_path = os.environ['HOME'] + "/.config/gbirthday"
            if not os.path.isdir(self.base_config_path):
                os.makedirs(self.base_config_path)
```
  J'ai essayé de prévoir le cas où XDG_CONFIG_HOME est défini alors qu'avant, il ne l'était pas. (Mais le cas où il disparaît n'est pas prévu…)
  
  Pour ces deux points, je suis plutôt demandeur de "bonnes pratiques".
  - [^] # Re: Petit bug, ouverture application.
    
    Posté par contra-sh le 13 mars 2012 à 13:50. Évalué à 2.
    
    Merci pour ton aide.
    
    Tout d'abord je ne suis pas un développeur python, et tu as du t'en apercevoir en lisant mon code :)
    Mais je me soigne (ou pas).
    
    Je n'ai absolument aucune idée de comment se fait le packaging avec les applis python.
    Il y a généralement un setup.py je crois.
    Si quelqu'un peut m'expliquer en quelques mots ça serait sympa :)
    
    De plus, il faudra que j'utilise des appels python pour les path pour que ça fonctionne aussi sur d'autres plateformes.
    
    Pour ces deux points, je suis plutôt demandeur de "bonnes pratiques".
    
    Oui moi aussi, surtout pour des petites applications il n'y a aucune excuses pour ne pas le faire :)
    - [^] # Re: Petit bug, ouverture application.
      
      Posté par jihele le 13 mars 2012 à 14:07. Évalué à 1. Dernière modification le 13 mars 2012 à 14:09.
      
      De rien. Pour être honnête, je n'ai pas pris le temps de bien regarder, mais rien ne m'a choqué. De toute façon, je ne crois pas avoir plus d'expérience que toi en la matière…
      
      Concernant le packaging, je n'ai pas vraiment mis le nez dedans non plus. J'ai des liens, si tu veux :
      - http://pypi.python.org/pypi/distribute
      - http://guide.python-distribute.org/index.html
      
      Comme toi, j'apprends, donc j'essaye de mettre en oeuvre les bonnes pratiques dès le début. Je suis sûr qu'il y a ici des gens qui savent comment procéder et qui sauront te conseiller, ou corriger si j'ai dit des conneries.
      
      Tu peux aussi poser la question sur la spam^Wmailing-list python. (Mais avec les commentaires en français, tu vas te faire allumer si tu exposes ton code…)
      - [^] # Re: Petit bug, ouverture application.
        
        Posté par contra-sh le 13 mars 2012 à 15:19. Évalué à 1.
        
        Ok merci
# Reponse

Posté par contra-sh le 13 mars 2012 à 09:58. Évalué à 5.

Pour le dev ti83 tu travailles sous GNU/Linux ? avec quels outils ?
Bien sûr je travaille sous GNU/Linux :)

J'utilise spasm pour assembler.
Puis bin8x (par exemple la version qui est sur mon profil ticalc) ou bin2var (sur ticalc aussi) pour convertir le binaire au format exigé par la calculatrice.
Voici le Makefile d'un de mes projets :

all: clean BASE.83p

BASE.83p: main.bin
bin8x main.bin -o BASE.83p -n ZK
rm -f *.bin

main.bin: main.asm
spasm main.asm main.bin

clean:
rm -f *.bin
rm -f *.83p

.PHONY: all clean

J'ai vu qu'il existe un émulateur : TiLem, un assembleur : zasm, et un ide : z80asmide, c'est fonctionnel comme suite ?

C'est marrant parce que je suis l'un des 2 developpeurs de TilEm :)
Mais il faut utiliser la version 2 qui n'est pas encore releasée (mais quasi finie) :
Donc :
sv co https://tilem.svn.sourceforge.net/svnroot/tilem tilem
Puis compiler depuis les sources (y a un configure et tout)
./configure
make
sudo make install

zasm est fonctionnel mais utilise plutôt spasm
Quant à z80asmide, il contient spasm en plus d'un editeur.

J'ai pensé "c'est en jouant sur ma ti83+ que j'ai découvert un autre jeu addictif : la programmation"

Moi aussi j'ai découvert la programmation grace à ma calculatrice :)

Au passage, je découvre que le développement sur ces archis n'a jamais été aussi vivant, plus que lorsque j'étais lycéen ! C'est amusant. :)

Oui et non. Y a pas mal d'activité effectivement avec notamment des langages interprétés qui sont plus puissants que le basic mais plus faciles que l'assembleur (axe, grammer).

Y a aussi une lutte incessante pour le crack de la nspire (le dernier modèle avec processeur arm et écran couleur).
TI a changé de politique avec cette gamme (l'assembleur était executable nativement sur ti83+)

C'est quoi le groupe de billes qui apparait en haut à un certain moment ?

En fait lorsque 2 lignes sont disponibles en haut, une nouvelle ligne de bille apparait en haut puis au bout de quelques actions, elles tombent au dessus des autres billes.
Ensuite tous les 5 explosions, une nouvelle ligne tombe.
Pour faire de bons scores, il faut se servir de ce principe pour rallonger sa durée de vie.
La ligne de bille en haut est en fait un preview pour aider le joueur à s'organiser.

J'ai l'impression qu'il y a des billes supplémentaires qui apparaissent dans ma grille de jeu parfois, quelle est la raison ?
Ce sont ces billes justement.
Il faudrait que j'ajoute l'animation de chute des billes pour que cela soit plus joli et plus compréhensible…

Merci du feedback en tout cas.

Je viens de le tester rapidement, c'est super! Encore un jeu qui va faire baisser ma productivité… :-)

Merci ! :)

Sinon erreur lorsqu'on clique sur la croix de fermeture de la fenêtre. Et CTRL-C obligatoire.
Ce bug est peut-être volontaire. Pour nous empêcher de travailler. :p
Ahah oui je suis satan en personne xD

Non en fait je me doutais qu'il y aurait ce problème.
En fait j'utilise xmonad comme window manager. et il n'y a pas de croix d'ornement donc tout simplement je ne savais pas si ça marchait ou pas.

Merci pour la correction de bug et le feedback :)
- [^] # Re: Reponse
  
  Posté par Thomas Debesse (site web personnel) le 13 mars 2012 à 15:09. Évalué à 3.
  
  zasm est fonctionnel mais utilise plutôt spasm
  
  Ok. En fait j'ai pas touché à la 83 depuis… 2004 je pense ^^. À l'époque TI proposait officiellement l'IDE de chez zilog (sous windows) pour développer des Flash Apps, et les tutos que j'avais suivi utilisaient Tasm (sous windows, aussi).
  
  Oui et non. Y a pas mal d'activité effectivement avec notamment des langages interprétés qui sont plus puissants que le basic mais plus faciles que l'assembleur (axe, grammer).
  
  Ils n'existaient pas à l'époque, et je n'aurai pas eu les compétences pour les inventer, en fait j'ai peut-être eu ma 83+ pendant une période de creux (vers 2001), en effet j'ai joué à des tas de jeux beaucoup plus anciens (par exemple, le premier auquel j'ai joué, penguins, un jeu de 1997 !), puis j'ai acheté une V200 avec un job d'été et refilé ma 83+ à une sœur. À l'époque l'archi 68k était bien plus vivante, alors qu'ajourd'hui elle stagne, et que les 82/83/84 ont toujours un développement actif, avec des trucs de fous comme Axe parser, que tu as évoqué, Calcnet, voire un émulateur en js, un autre en flash (exemple), on peut faire du son… Tout ça est assez récent !
  
  TI a changé de politique avec cette gamme (l'assembleur était executable nativement sur ti83+)
  
  Oui, j'avais entendu dire que la possibilité d'exécuter de l'assembleur sur 83 avait été laissé de manière non-officielle par un développeur de chez TI, une forme d'easter egg… La commande était Send(9PROGNAME), ensuite devant, le succès, TI a officialisé la chose avec une commande documentée dans le catalog : asm(PROGNAME), ils éditaient des guides de développement comme celui-ci : http://education.ti.com/guidebooks/sdk/83p/sdk83pguide.pdf (bon dans la réalité la communauté n'a jamais complètement suivi les guidelines ;).
  
  En rayon, sur les boites c'était écrit "programmez en assembleur"… Alors que c'est grâce à ça qu'ils ont la part de marché qu'ils ont aujourd'hui, tout ça a changé, et en effet il y a un jeu de bras de fer/jailbreak entre TI et les utilisateurs digne d'un iPhone. D'ailleurs c'est un point qu'on n'a pas vraiment abordé sur DLFP : il semble qu'aux États Unis une calculette autorisée aux examens doit être DRMisée et fondamentalement incompatible avec le logiciel libre (enfin, c'est la raison invoquée par TI, ils ont surement raison pour justifier ainsi de se tirer une balle dans le pied).
  
  C'est marrant parce que je suis l'un des 2 developpeurs de TilEm :)
  
  Ah oui ? merci pour ton travail alors :) Si un jour je me remets au z80, ce sera grâce à toi (à l'époque je devais utiliser l'émulateur officiel de TI sous Windows :/)
  Sais-tu pourquoi TiLem est dans le dépôt "non-free" de CalcForge ?
  (Je reconnais ne pas avoir lu les sources ^^)
  
  Avec tout les logiciels libres qui tournent dans ces calculettes, et autour de ces calculettes, il y a beaucoup de news qui auraient eu leur place sur DLFP ! Ta dépêche m'a motivé pour écrire une dépêche sur Punix (et l'occasion de présenter l'archi et le dev autour, on touche à des supers projets et thèmes que beaucoup de DLFPiens ont à cœur : logiciel libre, hacking, unix, embarqué, gcc, forks, flamewares en tout genre ^^).
  
  ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: Reponse
    
    Posté par contra-sh le 13 mars 2012 à 15:17. Évalué à 1.
    
    Sais-tu pourquoi TiLem est dans le dépôt "non-free" de CalcForge ?
    
    Parce qu'il s'agit de la version 1 qui utilisait un coeur d'émulation non libre de "Marcel de kogel".
    Le probleme ne se pose pas pour la version 2 que je developpe avec Benjamin Moody car tout est écrit "from scratch".
    
    Si ça t'intéresse, voici le projet que je développe en ce moment (megaman) :
    http://www.dwedit.org/dwedit_board/viewtopic.php?id=571
    
    Avec tout les logiciels libres qui tournent dans ces calculettes, et autour de ces calculettes, il y a beaucoup de news qui auraient eu leur place sur DLFP ! Ta dépêche m'a motivé pour écrire une dépêche sur Punix (et l'occasion de présenter l'archi et le dev autour, on touche à des supers projets et thèmes que beaucoup de DLFPiens ont à cœur : logiciel libre, hacking, unix, embarqué, gcc, forks, flamewares en tout genre ^{^).}
    
    Tout à fait d'accord :)
    - [^] # Re: Reponse
      
      Posté par Thomas Debesse (site web personnel) le 13 mars 2012 à 15:35. Évalué à 2.
      
      Parce qu'il s'agit de la version 1 qui utilisait un coeur d'émulation non libre de "Marcel de kogel".
      Le probleme ne se pose pas pour la version 2 que je developpe avec Benjamin Moody car tout est écrit "from scratch".
      
      Ok merci de l'info :)
      Je vous souhaites moins de guerres intestines qu'il n'y a eu dans la communauté 68k (avec plusieurs forks de fork de fork pour raison politiques :/)
      
      ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: Reponse
    
    Posté par M le 13 mars 2012 à 21:41. Évalué à 2.
    
    Oui, j'avais entendu dire que la possibilité d'exécuter de l'assembleur sur 83 avait été laissé de manière non-officielle par un développeur de chez TI, une forme d'easter egg… La commande était Send(9PROGNAME), ensuite devant, le succès, TI a officialisé la chose avec une commande documentée dans le catalog
    A l'époque (vers les années 98 OO), on pouvait bien faire tourner de l'asm sur les TI83, TI89 et TI92.
    
    Par contre au niveau doc il n'y avait pas grand chose et il fallait vraiment s'accrocher pour comprendre comment ça marchait (du coup je suis resté sur le BASIC).
    Je me souviens d'un tetris muti-joueur qui fonctionnait en reliant 2 calculettes avec le cable de transfert. On pouvait même mettre des calculettes différente (ti83 et TI89). Il y avait aussi un jeu de voiture avec des super dégradé de gris.
    Mais bon tout ces jeux l'explosait la batterie (vive les piles rechargeable).
    
    Et puis a l'époque pour envoyer les programmes il fallait le cable TI vendu a prix d'or (alors qu'on pouvait le fabriquer a la main avec quelques resistance et led sur le port serie).
    
    C'est marrant cet effort de dev fait sur ces calculette TI, plus tard j'ai eu une HP-40G, et ben la communauté autour de celle-ci était pauvre…
    - [^] # Re: Reponse
      
      Posté par M le 13 mars 2012 à 21:48. Évalué à 2.
      
      c'était plutot une 49G… (et la modif des commentaire ne marche pas)
      - [^] # Re: Reponse
        
        Posté par jihele le 13 mars 2012 à 22:13. Évalué à 1.
        
        (et la modif des commentaire ne marche pas)
        
        (Je crois qu'elle marche mais qu'elle ne te laisse qu'un lapsus de temps assez court. Après, c'est trop tard.)
- [^] # Re: Reponse
  
  Posté par Thomas Debesse (site web personnel) le 13 mars 2012 à 15:27. Évalué à 2.
  
  Aussi, en reparlant de la "vivacité de l'archi", j'ai vu dans cette vidéo des jeux très intéressants, comme un clone de portal en 2d, certains jeux utilisent des concepts physiques aussi, on n'est plus dans les clones des jeux des années 80.
  
  Autre projet bluffant, TI-Boy SE, en fait à ce que j'ai compris ce ne serait pas vraiment une émulation, ce serait une moulinette qui réécrit le code machine de la GB pour la TI !
  
  Donc… pleins d'outils logiciels et matériels autour de la calculette, avec des concepts modernes (réseau…), tout ce qu'il faut pour dev sur PC et On Calc, au moins un émulateur (ou équivalent), des tas de jeux qui s'inspirent de jeux modernes, ce qui signifie que les gens qui développent sont vraiment motivés : ils ne programment pas sur 83 parce qu'ils n'ont qu'une 83, ils ont certainement ordis, smartphones etc, et ils clonent les jeux de ces archis pourtant bien plus puissantes !
  
  ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Reponse
  
  Posté par Thomas Debesse (site web personnel) le 23 mars 2012 à 23:38. Évalué à 2.
  
  sv co https://tilem.svn.sourceforge.net/svnroot/tilem tilem
  Puis compiler depuis les sources (y a un configure et tout)
  ./configure
  make
  make install
  
  ça marché comme un charme, mais question bête… il me demande un .rom, et je n'ai pas ma 83+ sous la main, donc je ne peux pas faire de dump. Sur le site de ti, les OS sont en .8xu, il y a moyen de convertir l'un vers l'autre format ?
  
  ce commentaire est sous licence cc by 4 et précédentes
# Solveur SameGame-like

Posté par Maxime (site web personnel) le 13 mars 2012 à 11:55. Évalué à 3.

J'avais dev il y a 3-4 ans un samegame dans le cadre de mes études en GtkAda et l'une des particularités c'était un mode où l'ordi encadrait le groupe de boules qu'il te conseillait de supprimer.

Alors de mémoire, l'idée c'était de faire un parcourt exhaustif en profondeur dans le graphe d'états sur genre 5 niveaux puis de finir avec une heuristique du genre : "je choisi une couleur et tant que je peux je ne joue que cette couleur, sinon j'en change". Ça me donnait donc un ensemble de scores sur les feuilles et je choisissais donc la branche qui m'avait donné le meilleur score. (l'utilisation d'une heuristique pour "finir" le jeu était bien meilleure que de pousser sur un niveau de profondeur supplémentaire et prendre en compte que le score intermédiaire pour évaluer les noeuds)

La grille de jeu était plus grande (d'où l'obligation de se limiter à 4 ou 5 en profondeur) et il n'était pas nécessaire de détruire toutes les billes pour gagner, seul le score comptait.
- [^] # Re: Solveur SameGame-like
  
  Posté par contra-sh le 13 mars 2012 à 12:48. Évalué à 3.
  J'avais dev il y a 3-4 ans un samegame dans le cadre de mes études en GtkAda et l'une des particularités c'était un mode où l'ordi encadrait le groupe de boules qu'il te conseillait de supprimer.
  
  J'avais l'idée de faire ça aussi, et également de mettre en surbrillance le groupe de billes sous le focus souris, mais j'ai un peu peur que ça fasse ramer (on verra).
  
  Alors de mémoire, l'idée c'était de faire un parcourt exhaustif en profondeur dans le graphe d'états sur genre 5 niveaux puis de finir avec une heuristique du genre : "je choisi une couleur et tant que je peux je ne joue que cette couleur, sinon j'en change". Ça me donnait donc un ensemble de scores sur les feuilles et je choisissais donc la branche qui m'avait donné le meilleur score.
  
  Ce qui pourrait me poser problème, c'est que certaines forme mutliplient le score par un coefficient (par exemple un carré, une ligne, une fourchette, un corner etc…) comme ce qui est présenté ici :http://www.spookyhousestudios.com/bubex-bonus-shapes.html
  Il est parfois plus intéressant de choisir une forme avec moins de billes.
  Même si le calcul du score (n -1 )² encourage à choisir les groupes avec le plus grand nombre de billes (sur les modes large et extra large).
  Mais sinon oui la méthode que tu utilises ressemble fortement à ce que je voulais faire.
  Sauf que pour le solveur j'avais également d'autres idées.
  - Faire jouer l'ordinateur bêtement un grand nombre de fois (au moins 10000) en gardant la combinaison d'explosions qui rapporte le plus de points (ce qui permet d'obtenir un score normalement plus élevé que un joueur humain lambda).
  - Brute force avec toutes les combinaisons : juste bon a bloquer mon ordi pendant plusieurs jours je pense.
  - Calcul d'un coup puis des k suivants. Refaire cela pour chaque coup possible. Choisir celui qui rapporte le plus. Faire le coup. Recommencer. Le choix de k borné ne permet pas d'avoir le meilleur score possible mais un bon score.
  Le probleme étant qu'un coup qui rapporte peu de points n'est pas forcement moins bien qu'un coup qui rapport beaucoup de points car ça peut amener un autre coup qui rapporte beaucoup de points (et cela le coup suvant ou 10, 20 ou 30 coups plus tard…)
  
  La grille de jeu était plus grande (d'où l'obligation de se limiter à 4 ou 5 en profondeur) et il n'était pas nécessaire de détruire toutes les billes pour gagner, seul le score comptait.
  
  Quelle taille exactement?
  Pour le mode extra large, j'ai 16 * 19 billes, ça commence à faire grand (mais je peux augmenter si besoin).
  Dans bubble crusher, seul le score compte. Je pense multiplier le score par 4 si on arrive a exploser toutes les billes, mais je ne l'ai pas encore implémenté.
  
  Merci pour ton explication d'algo.
  - [^] # Re: Solveur SameGame-like
    
    Posté par Maxime (site web personnel) le 13 mars 2012 à 13:48. Évalué à 2.
    
    Tu as en effet des règles qui ont je pense tendance à augmenter la difficulté. Cependant on retrouve des problématiques communes.
    
    Le probleme étant qu'un coup qui rapporte peu de points n'est pas forcement moins bien qu'un coup qui rapport beaucoup de points car ça peut amener un autre coup qui rapporte beaucoup de points (et cela le coup suvant ou 10, 20 ou 30 coups plus tard…)
    
    C'est typiquement pour cette raison que s'arrêter sur un graphe non fini donnait de moins bons résultats que de continuer avec un algo glouton.
    
    Sur tes autres pistes :
    - Jouer bêtement : Je ne crois pas trop à cette approche mais ça me fait penser qu'il serait intéressant de mettre en place un réseau de neurones pour qu'il apprenne à reconnaître certains patterns de jeu et voir ce qu'il arrive à en apprendre :). L'avantage c'est qu'une fois qu'il est bien entraîné, il sera rapide. J'ai aucune idée de l'efficacité d'une telle approche et encore moins du temps d'apprentissage nécessaire.
    - Brute force :) Ça va dépendre de la taille de ta grille mais si une partie fait environ 20 clics et qu'il y a à chaque clics disons 5 possibilités, ça fait déjà un bon paquet :)
    - La dernière solution : cf prob du super coup à k+1.
    
    Je ne me souviens plus de la taille de la grille, mais je dirais de l'ordre de ton mode extra large.
    
    J'ai simplifié mon algo pour les explications, c'était un peu plus compliqué que ce que j'ai annoncé mais je ne m'en souviens plus maintenant :). En tout cas, une bonne source d'inspiration à l'époque c'était un papier de recherche. Je me demande si ce n'était pas : "Single-Player Monte-Carlo Tree Search" de Maarten et al.
    - [^] # Re: Solveur SameGame-like
      
      Posté par contra-sh le 13 mars 2012 à 13:58. Évalué à 1.
      
      Jouer bêtement : Je ne crois pas trop à cette approche mais ça me fait penser qu'il serait intéressant de mettre en place un réseau de neurones pour qu'il apprenne à reconnaître certains patterns de jeu et voir ce qu'il arrive à en apprendre :). L'avantage c'est qu'une fois qu'il est bien entraîné, il sera rapide. J'ai aucune idée de l'efficacité d'une telle approche et encore moins du temps d'apprentissage nécessaire.
      
      Réseau de neurones… Là on rentre dans de l'IA pure et dure :)
      Jouer bêtement de nombreuses fois ne permet pas de donner un résultat rapide (et de conseiller le joueur pendant qu'il joue) mais permet d'avoir de bon résultats sans implémenter de stratégie de résolution (donc marche quelque soit le jeu).
      Mais c'est la solution qui n'apporte aucune estime de soi à celui qui la programme :)
      (et qui ne garantie rien)
      
      Brute force :) Ça va dépendre de la taille de ta grille mais si une partie fait environ 20 clics et qu'il y a à chaque clics disons 5 possibilités, ça fait déjà un bon paquet :)
      
      Surtout que la reconnaissance des formes est un peu gourmande.
      
      J'ai simplifié mon algo pour les explications, c'était un peu plus compliqué que ce que j'ai annoncé mais je ne m'en souviens plus maintenant :). En tout cas, une bonne source d'inspiration à l'époque c'était un papier de recherche. Je me demande si ce n'était pas : "Single-Player Monte-Carlo Tree Search" de Maarten et al.
      
      Ok merci pour la référence.
# Bien !

Posté par jihele le 13 mars 2012 à 14:00. Évalué à 1.
Félicitations, c'est pas mal !

Qqs remarques :

Je suis arrivé dans une situation de blocage. Je suppose que ça ne devrait pas.

Je pars de cette situation, avec deux bleues en haut :
```
V
R
BBV
```
Et quand je "casse" les deux bleues en bas, les deux bleues du haut tombent.

J'ai alors :
```
B 
VB
RV
```
Et je ne peux donc rien casser. Je ne peux faire d'autre que new ou undo.

Par ailleurs, plus on est en taille grand (pour la taille du tableau de jeu), plus c'est lent après chaque explosion. En taille "small" c'est quasiment instantané. J'ai d'abord pensé que le calcul de l'explosion prenait du temps mais on dirait que c'est l'animation avec les points qui montent qui est juste plus lente. Pourtant je ne vois pas pourquoi dans le code.
- [^] # Re: Bien !
  
  Posté par contra-sh le 13 mars 2012 à 14:22. Évalué à 2.
  
  Merci d'avoir testé :)
  (et le report de bug)
  
  Pour la situation de blocage, je ne sais pas d'où ça vient je vais regarder.
  
  Pour le second probleme, est-ce que le temps augmente après chaque explosion ou alors c'est juste plus lent qu'en small?
  Si c'est de plus en plus lent c'est un grave probleme. Sinon c'est "juste" parce qu'il faut que je retouche les timers.
  
  L'animation du score devrait normalement pas faire ça puisque je fais :
  
  def inc_old_score_to_score(self):
  ''' Increase slowly the score '''
  if self.f.score - self.old_score > 1040:
  self.old_score += 1000
  if self.f.score - self.old_score > 140:
  self.old_score += 100
  elif self.f.score - self.old_score > 40:
  self.old_score += 10
  elif self.f.score - self.old_score > 15:
  self.old_score += 5
  elif self.f.score - self.old_score > 50:
  self.old_score += 2
  elif self.f.score - self.old_score > 0:
  self.old_score += 1
  - [^] # Re: Bien !
    
    Posté par jihele le 13 mars 2012 à 15:18. Évalué à 1.
    Pas de quoi.
    
    C'est juste plus lent qu'en "small", ça ne s'aggrave pas avec le temps. Je suppose que ça doit faire pareil chez toi, non ?
    
    Si je comprends bien ton code,
```
glib.timeout_add(10, self.on_timer) 
```
    toutes les 10 ms, tu appelles la fonction on_timer() qui appelle inc_old_score_to_score() pour modifier le score affiché (de sorte qu'avec la fréquence importante, on a l'impression que ça monte continument) et au bout de 30 fois on arrête (car timer_counter est initialisé à 30 et décrémenté à chaque fois).
    
    Je ne comprends pas tout l'algo, mais je ne vois pas où la taille intervient. En ajoutant un print self.timer_counter, je vois bien les 30 itérations, et je vois bien que c'est plus lent en "extra large", mais je ne vois pas pourquoi, sinon pour des raisons de temps-réel, mais alors je ne vois pas ce qui se passe qui retarde.
    - [^] # Re: Bien !
      
      Posté par contra-sh le 13 mars 2012 à 15:54. Évalué à 1.
      
      C'est à cause de l'affichage en fait.
      La boucle dans print_bubbles prend plus de temps tout simplement car il y a plus de bulles à afficher.
  - [^] # Re: Bien !
    
    Posté par GuieA_7 (site web personnel) le 13 mars 2012 à 17:25. Évalué à 2.
    
    Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?
    
    PS: en tant que développeur python, j'aurai créé un alias du genre "diff = self.f.score - self.old_score", histoire de gagner en lisibilité et en performance.
    - [^] # Re: Bien !
      
      Posté par contra-sh le 13 mars 2012 à 17:43. Évalué à 1.
      
      Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?
      
      Euh non ce n'est pas normal xD
# Nostalgie

Posté par benoar le 13 mars 2012 à 15:47. Évalué à 2.

Ceux qui ont joué à la version Gnome doivent se rappeler : http://live.gnome.org/Swell%20Foop
# Portage Android

Posté par herve18 le 13 mars 2012 à 16:34. Évalué à 1.

Vivement le portage sur Android, et que l'application ne demande pas des permissions intrusives, à l'inverse de Bubble Explode qui demande à lire l'identité et l'état du téléphone.
- [^] # Re: Portage Android
  
  Posté par contra-sh le 13 mars 2012 à 16:36. Évalué à 1.
  
  Ah si les applis android étaient en python ou en C plutôt qu'en java ce serait déjà fait :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.