Castle Defence pour NumWorks, concours Python 2024-2025

[critor]

Voici la présentation de Castle Defence, un jeu conçu pour notre concours de programmation Python 2024-2025.

Castle Defence est un jeu de type Tower Defense, conçu par HenriHenry.

Tu dois positionner des tours sur la carte le long de la route conduisant à ton château, afin de le défendre correctement contre des vagues successives d'assaillants. Les tours peuvent être de différents types et faire l'objet d'améliorations.

Pour te permettre de mieux interagir avec les différents éléments du jeu, Mathieu a même code et intégré à son jeu un véritable système de pointage contrôlé aux flèches du clavier !
En prime, précisons que la carte est raccordée horizontalement et verticalement (poursuivre après avoir atteint le bord droit de l'écran nous ramène à gauche), c'est remarquable !

Pour construire une tour, si tu as suffisamment de fonds, il te faut pointer l'emplacement libre souhaité puis taper une touche

1

à

4

afin d'en choisir le type, touches précisées en écran d'introduction. Les types de tour avec leurs prix te sont rappelés en bas d'écran.

Pour améliorer une tour, encore une fois si tu as assez d'argent, il te faut la pointer puis taper la boîte à outils ou encore

)

.
Comme c'est la seule action possible dans ce contexte, une touche

OK

ou

EXE

aurait peut-être été préférable, plus habituelle pour les joueurs.

Enfin pour lancer la prochaine vague d'ennemis, il te faut pointer le bouton démarrer en haut à droite puis taper

OK

.
Précisons que comme c'est ici la touche

OK

qui est testée et non pas

EXE

, le jeu ne sera malheureusement pas utilisable dans le lecteur Python en ligne de NumWorks.
Ici, comme c'est une action à effectuer plusieurs fois en cours de partie, il aurait peut-être été mieux de donner le choix, et lui associer une touche en plus de la possibilité de passer par le pointage.

Un jeu fort intéressant et prenant ! 😍

Niveau graphismes, on apprécie les petits sprites conçus pour l'occasion.
Les rafraîchissements provoquent de légers clignotements de certains éléments, redessinés inutilement à chaque action.

Par contre et c'est bien dommage devant un tel jeu, nous restons un petit peu sur notre faim. En effet il semble y avoir des bugs nous empêchant de profiter pleinement de la partie. Certaines actions dans le jeu déclenchent l'appel de fonctions F() ou S() qui ne sont apparemment définies nulle-part.

Téléchargement : https://my.numworks.com/python/mathieu- ... defence_v7

[HenriHenry]

Bonjour,
Est-ce bien la v7 ? le problème pourrait être que je n'ai pas assez testé le script sur Epsilon, mais F() est défini lors de l'importation de fill_rect(), alors je ne comprend pas... Pour améliorer, au dernier niveau il y a le choix entre ( ou ) pour différents types de tour, mais je préfere laisser les joueurs découvrir les options...
Je n'avais malheuresement pas la place de changer les sprites des tours lors de leur dernière amélioration, mais peut être dans une prochaine update ?
Pour ce qui est de marcher dans l'émulateur, il marche dans celui d'Upsilon, mais pour celui d'Epsilon il aurait fallut tout changer car les touches 1,2,3 et 4 ne sont pas détectées...
Le rafraichissement est optimisé par rapport à la v1, mais il est loin d'être parfait...
Je n'avais même pas penser à utiliser EXE pour démarrer une autre vague ! C'est une très bonne idée.
Pouvez vous indiquez les actions qui causent les bugs ? Ça m'aiderait beacoup.
Merci pour ce feedback très complet !

[Afyu]

Bonjour HenriHenry,

Merci pour ton jeu, qui est bien réalisé et qui est très prenant. J'ai passé quelques heures à y jouer...

Bonjour,
Est-ce bien la v7 ? le problème pourrait être que je n'ai pas assez testé le script sur Epsilon, mais F() est défini lors de l'importation de fill_rect(), alors je ne comprend pas...

C'est une bonne question, ça, mais je crois bien que toi seul peux y répondre. D'après le nom du projet qui se termine en "v7", il semblerait que oui. Mais on n'est pas à l'abri d'une erreur de copier-coller...
Je n'ai pas testé le script sur Epsilon mais seulement sur le (formidable ) Workshop Upsilon de Yaya.Cout.
Il me semble que F() n'est pas définie, dans ton script. Ni à l'importation de fill_rect() (qui est importé en tant que r), ni ailleurs dans le script).
J'ai eu une erreur concernant F() lors de mes premières parties mais je ne l'ai pas rencontrée de nouveau depuis. Je ne peux donc pas t'aider à trouver comment reproduire l'erreur.
Il semblerait que la fonction S() ne soit pas définie non plus.

Pour améliorer, au dernier niveau il y a le choix entre ( ou ) pour différents types de tour, mais je préfere laisser les joueurs découvrir les options...
Je n'avais malheuresement pas la place de changer les sprites des tours lors de leur dernière amélioration, mais peut être dans une prochaine update ?

J'espère voir ça dans une prochaine update !
Pour ce qui est du manque de place, je connais bien ce problème... J'ai quelques astuces pour gagner en place. Je te détaillerai ça.

Pour ce qui est de marcher dans l'émulateur, il marche dans celui d'Upsilon, mais pour celui d'Epsilon il aurait fallut tout changer car les touches 1,2,3 et 4 ne sont pas détectées...

Tu peux remplacer les codes 0, 1, 2 et 3 par KEY_LEFT, KEY_UP, KEY_RIGHT, KEY_DOWN pour que ça fonctionne avec Epsilon (et aussi avec Upsilon).

Le rafraichissement est optimisé par rapport à la v1, mais il est loin d'être parfait...
Je n'avais même pas penser à utiliser EXE pour démarrer une autre vague ! C'est une très bonne idée.
Pouvez vous indiquez les actions qui causent les bugs ? Ça m'aiderait beacoup.

Oui, la touche EXE pourrait être utilisée à n'importe quel moment pour lancer la vague suivante. Ce qui ferait gagner un peu de temps, aussi, sans devoir aller jusqu'au bouton en haut à droite.
De même, la touche OK pourrait être utilisée lorsqu'on est sur une tour, pour l'améliorer au niveau suivant (sauf pour le dernier niveau, qui requiert un choix), à la place ou en plus de la touche Boîte à Outils.
On pourrait même tout regrouper sur la touche OK (ou EXE ou les deux pour que ça fonctionne aussi sur le simulateur) si on n'est pas sur une tour, alors ça lance la vague suivante, si on est sur une tour et qu'on a assez de sous pour l'améliorer, alors ça l'améliore (sauf pour la dernière amélioration).
J'ai rencontré un bug à ce propos : lorsqu'une tour est au dernier niveau et que j'appuie (disons, "par erreur") sur une touche pour l'améliorer alors que ça n'est plus possible, ça renvoie une erreur.

Comme autre amélioration, je propose d'intervertir le dessin des tours et leur prix de construction, en bas de l'écran. Au passage, on pourrait également supprimer les deux points pour gagner un peu en place.

Je veux bien t'aider pour les améliorations ou pour optimiser le code et gagner en place (éventuellement dans un projet partagé sur le Workshop Upsilon).

[critor]

Bonjour,
Est-ce bien la v7 ? le problème pourrait être que je n'ai pas assez testé le script sur Epsilon, mais F() est défini lors de l'importation de fill_rect(), alors je ne comprend pas... Pour améliorer, au dernier niveau il y a le choix entre ( ou ) pour différents types de tour, mais je préfere laisser les joueurs découvrir les options...
Je n'avais malheuresement pas la place de changer les sprites des tours lors de leur dernière amélioration, mais peut être dans une prochaine update ?
Pour ce qui est de marcher dans l'émulateur, il marche dans celui d'Upsilon, mais pour celui d'Epsilon il aurait fallut tout changer car les touches 1,2,3 et 4 ne sont pas détectées...
Le rafraichissement est optimisé par rapport à la v1, mais il est loin d'être parfait...
Je n'avais même pas penser à utiliser EXE pour démarrer une autre vague ! C'est une très bonne idée.
Pouvez vous indiquez les actions qui causent les bugs ? Ça m'aiderait beacoup.
Merci pour ce feedback très complet !

Bonjour HenriHenry


Avant tout, merci pour ce très beau jeu.

Oui, c'est bien la v7, et la fonction F() entre autres n'y est pas définie.
Mais cela n'empêche pas de commencer à jouer, et j'ai modifié le code pour pouvoir tester plus profondément et donc évaluer correctement.

Pour le concours ne t'inquiète pas, cette histoire de fonction non définie n'est qu'un petit détail, en l'état ça ne risque pas de changer quelque chose au classement.


Après si tu améliores malgré tout ton superbe jeu, nous aurons grand plaisir à en reparler.
Merci encore énormément à toi pour cette remarquable création.

[Afyu]

Pour les optimisations du code (ou plutôt de la place qu'il prend en mémoire à l'exécution), je te propose :

1) de remplacer (0,)*3 par "k", pour désigner la couleur noire (on gagne 30 lignes de marge en plus)
2) de remplacer (255,)*3 par "w", pour désigner la couleur blanche (on gagne 5 lignes de marge en plus)
3) de remplacer les lignes
if key==0:map_pos[0]-=1
elif key==1:map_pos[1]-=1
elif key==2:map_pos[1]+=1
elif key==3:map_pos[0]+=1
if map_pos[0]<0:map_pos[0]=39
elif map_pos[0]>39:map_pos[0]=0
if map_pos[1]<0:map_pos[1]=24
elif map_pos[1]>24:map_pos[1]=0

par
map_pos[0]+=(key==3)-(key==0)
map_pos[1]+=(key==2)-(key==1)
map_pos[0]=map_pos[0]%40
map_pos[1]=map_pos[1]%25

voire même, directement par une forme encore plus compacte :
map_pos[0]=(map_pos[0]+(key==3)-(key==0))%40
map_pos[1]=(map_pos[1]+(key==2)-(key==1))%25

Il n'y pas plus de if et la forme la plus compacte permet de gagner encore 7 lignes de mage.

4) de remplacer les lignes

if it.type=="normal":id=0
elif it.type=="double":id=1
elif it.type=="fire":id=2
elif it.type=="ice":id=3

par
id=("normal",""double","fire","ice").index(it.type)

Cette modification attend que it.type soit forcément dans le tuple qui suit. (on gagne 2 lignes de marge)

[HenriHenry]

Merci !
Effectivement, j'aurais du relire mon code avant... J'ai du faire des modifications en utilisant F() à la place de r(), provoquant des erreurs... (S() devrait donc être set_pixel(), qui doit donc être importé)
J'avais testé le jeu, mais je n'ai pas eu les erreurs, donc ça m'étonnait (mais en même temps je m'y attendais, il est rare qu'un code soit complètement sans erreurs)
Je corrige ça bientôt, avec les améliorations proposées généreusement par Afyu, ainsi qu'un changement des sprites au niveau max et peut-être de nouvelle tours dans une v8 !
Je voudrais aussi améliorer le système de génération de vague, mais je suis un peu perdu... Si quelqu'un veut bien prendre sur son temps pour m'aider, il/elle est le/la bienvenu(e) !
Merci a tous !

P-S: Y-a t-il un script permettant de renvoyer le heap disponible/utilisé ? J'ai vu celui de critor, mais je ne comprend pas bien comment l'utiliser, car le script renvoie autour de 38000 quand utilisé sur un script au bord de la saturation de mémoire. Ça pourrait être dû à mon manque de connaissance quand à la structuration de la mémoire ?

[Afyu]

Je corrige ça bientôt, avec les améliorations proposées généreusement par Afyu, ainsi qu'un changement des sprites au niveau max et peut-être de nouvelle tours dans une v8 !
Je voudrais aussi améliorer le système de génération de vague, mais je suis un peu perdu... Si quelqu'un veut bien prendre sur son temps pour m'aider, il/elle est le/la bienvenu(e) !
Merci a tous !

Bonsoir HenriHenry,

J'ai hâte de voir ces améliorations !

Tu pourras gagner encore un peu de place dans ton script si tu simplifies la partie qui demande d'aller sur le triangle pour ensuite appuyer sur OK pour lancer une nouvelle vague. D'ailleurs, ce triangle pourrait être utilisé pour indiquer lorsqu'une vague est en cours avec un symbole en triangle (comme "play") et un symbole qui ressemble aux deux barres de "pause" (en remplacement du "-in progress").

Je veux bien t'aider.

Dans la suite des améliorations ou optimisations du code possibles, je te propose :

1) étant donné que les lignes 8 à 31 s'occupent de l'affichage du texte et en particulier des caractères " ", "\t" et "\n", avec la possibilité de choisir une couleur de fond et qu'Upsilon (et Epsilon aussi, quoiqu'un peu différemment pour le "\n") gère très bien cet affichage, par défaut, avec une couleur de fond (blanche par défaut), alors on peut les supprimer et ne garder que l'instruction s=D. On peut également importer draw_string en tant que s et remplacer tous les appels à la fonction D par des appels à la fonctions s et ainsi se passer de la ligne s=D.
Cette suppression des lignes 8 à 31 (la partie try...except) permet de gagner 39 lignes de marge.

2) Les lignes suivantes, qui gèrent l'affichage des points de vie restants, en collant cet affichage contre le bord droit de l'écran
if(HP<100)and(HP>9):s(" "+str(HP),238,203,"k","k");s("HP : "+str(HP),250,203,col,"k")
elif(HP<10):s(" "+str(HP),250,203,"k","k");s("HP : "+str(HP),260,203,col,"k")
else:s("HP : "+str(HP),238,203,col,"k")

sont simplifiables en
s(" "*((HP<100)+(HP<10))+"HP : "+str(HP),238,203,col,"k")

avec le tout petit changement : le texte "HP" sera affiché à 238 ou 248 ou 258 en abscisse contre 238, 250 ou 260 avant le changement.
Cette simplification du code fait gagner encore 7 lignes de marge.

[critor]

P-S: Y-a t-il un script permettant de renvoyer le heap disponible/utilisé ? J'ai vu celui de critor, mais je ne comprend pas bien comment l'utiliser, car le script renvoie autour de 38000 quand utilisé sur un script au bord de la saturation de mémoire. Ça pourrait être dû à mon manque de connaissance quand à la structuration de la mémoire ?

Nous n'avons malheureusement par, sur NumWorks, de bibliothèque permettant d'interroger l'état mémoire.

La seule alternative pour mesurer la mémoire libre est donc de tenter de la remplir jusqu'à obtenir une erreur.

C'est une méthode qui peut servir aux développeurs pour connaître la capacité mémoire à vide.
Elle n'est pas adaptée à interroger la mémoire libre restante en cours d'exécution d'un script.

[SlyVTT]

Dans la suite des améliorations ou optimisations du code possibles, je te propose :

...

Cette simplification du code fait gagner encore 7 lignes de marge.

Afyu, le roi de l'optimisation pour faire tenir des programmes sur une NW

(optimisation préférée de Pépère SlyVTT : virer les commentaires !! On a vu avec Afyu que la conso mémoire des commentaires est juste délirante sur NW)

[Afyu]

Afyu, le roi de l'optimisation pour faire tenir des programmes sur une NW

(optimisation préférée de Pépère SlyVTT : virer les commentaires !! On a vu avec Afyu que la conso mémoire des commentaires est juste délirante sur NW)

Héhé

La suppression des commentaires fait gagner beaucoup sur la taille du script, oui, mais ça semble utile uniquement lorsque le script fait 64 ko et qu'il faut le faire maigrir (ce qui n'est pas le cas ici).