[PURE DEBUTANT] Comment structurer un gros programme ?

[drfloyd]

Grace à vous, j'avance vite dans la découverte de PURE BASIC, j'ai lancé la création d'un RPG et j'ai fais une demo de shoot'em up en double scrolling horizontal... Merci les amis !

Je voudrais passer à l'étape supérieure en structurant de gros programmes... Là je n'ai fait pour l'instant qu'une boucle REPEAT/ UNTIL

En effet je compte réaliser un jeu qui risque de faire 2000ko de listing avec des parties de jeu bien disctintes, donc genre 10 boucles de jeu dans le programme. Objectif, realiser la suite de mon jeu COSMOS en PURE :
http://gamopat.over-blog.com/2018/12/co ... -v.10.html

Chaque boucle pourrait fait 30 à 50 ko... et les données de chaque boucles doivent toutes pouvoir etre utilisées dans les autres boucles (super important)

Comment faire au mieux ?

Le plus simple c'est les GOTO
partie1:
repeat
if. goto partie2:endif
until

partie2:
repar
if.. : goto partie 3:endif
until
etc...

mais c'est barbare non ? Je pense qu'il y a mieux ? Les procedures ? Comment ca fonctionne en Pure ?

Et autre question : Faut-il aussi découper le programme en plusieurs fichier ? (genre avec "include")

[MLD]

bonjour drfloyd

Dans ce que tu demande certaines choses m'intrigue

Les Goto sont juste bon pour du code spaghettis comme dans les basics préhistorique.
Des boucles de 30 a 50 Ko de quoi Parle en ligne de code ce sera plus explicite
Pour segmenté un programme cela dépend de quoi l'on parle! Les includes sont une solution. Les procédures en sont une autre, et il y a aussi les macros qui remplacent du code répétitif.
Je te conseil vivement de lire attentivement la doc sur ces sujets. De regarder sur les différents forums, des exemple de codes complexes et long, et de donner sur ce forum des exemples de ton code pour que l'on puisse t'aider efficacement.
Mais tu progresse c'est bien.

[drfloyd]

Ce n'st pas du code répétitif, mais une séries d'ecrans de jeu vraiment différents

une partie dans l'espace
une partie au sol
une partie dans des donjons
etc...

et me demande quelle structure adopter. Je vais essayer de trouver des idées dans la doc.

[Ollivier]

Euh... Petite parenthèse HS ci-dessus est le
cent-quatre-vingt-dix-millième message ! 190 000 messages. Fallait un con comme moi pour le dire!

Bon... À 200 000, on pourra rajouter du son !

Bon désolé pour la boutade.

A part ça, pour structurer un gros programme, il y a un sujet << Méthode et beauté du code >> en info/tuto, avec quelques avis contradictoires pour accumuler quelques astuces. Mais ça dépend de ce qu'on programme, comment on stocke les données, ce que l'on connait (macros, procédures, inclusions, modules, etc...).

Perso, j'ai essayé les modules à plusieurs reprises, et je n'y arrive pas, ayant goûté la syntaxe cpp alpha::beta avant la création en PB (quelques mois seulement), ça a été redhibitoire pour les modules PB. Et je ne m'y fais toujours pas... Déjà, avec macros, procédures et inclusions, ça va déjà très loin... (je souffle un peu MLD)

[Ar-S]

Salut DrFloyd
J'ai testé Cosmos 1.5 et franchement, piquage de yeux à part, je kiff. Entre un bon vieux zelda et l'arche captain blood.
Pour ta question de redondance, les procédures sont surement le plus appropriées pour les éviter. Il va effectivement aussi falloir voir la doc sur les structures.
Ensuite pour les "parties" du jeu, dans la boucle principale, moi je mets des Flags histoire de n'afficher que le nécessaire.
Ces flags sont des #Constantes que je numérote en début de code.
Je mets aussi une variable global ETATJEU.b (.b qui te laisse déjà 128 flag possibles)
Genre :
#InShip = 1
#OutShip = 2
#Menu = 3
#GameOver = 4
etc...

Et donc dans ma boucle principale 2D Repeat / Until
je mets un select / case avec ma variable ETATJEU

Code : Tout sélectionner

Select ETATJEU
Case #Menu
 ; code qui affiche le menu

Case #GameOver
; code qui affiche le gameover

Endselect

Ainsi en jeu, il te suffit lorsque ton perso clic sur "vu dans vaisseau" de lancer un simple
ETATJEU = #InShip
et paf... ça s'affiche.

Pour le reste je rejoints MLD

Note:
Attention une macro n'est qu'un alias, pratique certes, mais pour le compilo c'est N fois le même code répété.
La procédure, elle, est une seule fonction que tu crées et que tu pourras appeler autant de fois que tu veux.

Maintenant il y a des gens ici qui ont déjà créé des jeux en PB et qui pourraient surement te conseiller plus que moi.

[Micoute]

Il y a tellement de domaines sur le territoire de PureBasic, qu'il y a autant de spécialistes pour chaque genre. On ne peut pas être meilleur en tout.

[kernadec]

Bjr a tous

@drfloyd a ecrit...
En effet je compte réaliser un jeu qui risque de faire 2000ko de listing avec des parties de jeu bien distinctes.

Eh ben t est pas arrive.... si pour chaque fonction tu post un help....
Perso, je pense que tu devrais deja lire la doc et etudie tous les exemple de celle-ci et aussi le dossier sources PB...

Apres une petite recherche sur le forum pourra completer
Tout cela

Cordialement

[Zorro]

mais c'est barbare non ? Je pense qu'il y a mieux ? Les procedures ? Comment ca fonctionne en Pure ?

Et autre question : Faut-il aussi découper le programme en plusieurs fichier ? (genre avec "include")

1er pas de honte a utiliser Goto , on est en Basic, c'est aussi l'un de ses "avantages"... l'assembleur a bien le Jump
l'essentiel etant qu'a la fin , ton programme marche ...

les procedures fonctionnent comme partout,
declaration de procedure en debut de programme (pas obligatoire si tu ecris tes procedures en haut du listing.... ce que je deteste )
puis appel de la procedure ...

ex

Code : Tout sélectionner

Declare addition (a,b)  ; ici on declare la procedure


; utilisation de la procedure
debug addition(15,5)





;zone des procedures

procedure addition (a,b)		
		resultat=a+b  ;<---- note que les variables dans une procedure sont local a celle-ci
		ProcedureReturn resultat
endprocedure

quand a la question "faut il decouper son listing en plusieurs fichiers....."
c'est simplement une historoire de gout et d'habitude ....
perso je prefere les gros listing d'un bloc, car c'est plus facile a debugger ....
(mais il faut que l'editeur suive.... pas evident )

pourquoi c'est plus simple a debugger, parceque ça va t'indiquer directement le numero de la ligne qui deconne
alors qu'en multiple fichier, ça va t'indiquer une ligne qui se trouve dans un fichier...quelques part...

bref c'est mon avis ... mais faut reconnaitre que l'inclusion permet aussi de bosser sur une plus petite parti du programme

bref, c'est comme tu le sent


bon je retourne sur Euro Truck Simulator, j'ai des livraisons a terminer

[Marc56]

Faire des fichiers sources pour chaque niveaux ne servirait à rien: tu va recopier une grande partie de code identique pour chaque niveau, et si tu change un algorithme, tu devra le refaire dans chaque fichier.

On découpe en fichiers source (en utilisant Include) par fonctionnalités. Exemple un fichier pour tout ce qui concerne le son, un autre pour la gestion des fichiers de données (scores et paramètres via fichiers INI ou JSON) etc.

Ce que PureBasic appelle "procédures" sont en fait des fonctions, sauf que le retour de valeur est facultatif. Si on ne met rien, il retourne 0, et si on veut autre chose, on utilise ProcedureReturn.

Les fichiers includes sont "recollés" au moment de la compilation, à l'endroit où se trouve la commande. En cas de problème, le programme ouvre automatiquement le bon source et sur la ligne où se trouve l'erreur, pas besoin de chercher.

Pareil, quand tu double-cliques sur une de tes fonctions, l'IDE t'amène automatiquement sur la procédure même si elle est dans un autre source. (En mode projet, le source est ouvert automatiquement)

Et bien-sur, on travaille en mode projet, ce qui permet de compiler plusieurs cibles en même temps et bien d'autres avantages.

[drfloyd]

Salut DrFloyd
J'ai testé Cosmos 1.5 et franchement, piquage de yeux à part, je kiff. Entre un bon vieux zelda et l'arche captain blood.

Merci !

Ca pique ? A cause des graphismes rétro ou a cause de l'effet un peu flou ?

[Naheulf]

En effet je compte réaliser un jeu qui risque de faire 2000ko de listing avec des parties de jeu bien disctintes, donc genre 10 boucles de jeu dans le programme. Objectif, realiser la suite de mon jeu COSMOS en PURE :
http://gamopat.over-blog.com/2018/12/co ... -v.10.html

Ce n'st pas du code répétitif, mais une séries d'ecrans de jeu vraiment différents

une partie dans l'espace
une partie au sol
une partie dans des donjons
etc...

et me demande quelle structure adopter. Je vais essayer de trouver des idées dans la doc.

Je ne sais pas à quel point la "suite" ressemblera (ou non) aux version existantes. Si je me base sur les captures d'écran et la vidéo présente dans ton lien, les parties espace, sol, donjon, etc (vaisseau, habitation, eau, orbite ...) ne me paraissent pas si différentes les unes des autres.

En gros, t'as :
- les cases ou tu peut aller (espace, sol),
- celles ou tu bute (mur),
- celles avec lesquelles tu peut interagir en essayant de rentrer dessus (bibliothèque, météorite, personnage, porte, ...)
- et celles ou tu peut interagir en étant dessus (lit, feu, téléporteur, ...).
- Les informations du joueur
- les informations du monde
- les informations sur le bloc/la case

Alors bon :
- dans certains cas la carte est rectangulaire, cylindrique voir torique ou infinie (mais si tu réfléchis bien tout peut être fait avec une ou plusieurs cartes toriques et des murs/téléporteurs potentiellement invisibles)
- dans d'autres le joueur peut se déplacer tout seul dans une direction : poussée d’Archimède, vitesse orbitale, glissage sur de la glace ou dans le vide de l'espace (mais est-ce une propriété de l’environnement ou de la case ?)
- les textures utilisées ne sont pas les mêmes selon l'environnement

Mais hormis à la génération de la zone tout le reste est identique. Tu peut t'inspirer de https://fr.wikipedia.org/wiki/Strat%C3% ... onception). Un lien qui explique plus l'intérêt du truc : https://openclassrooms.com/fr/courses/2 ... id/r-21972 (ok c'est un tuto pour java donc il est question de classes et d'objets, mais il explique le principe et tu peut utiliser les structures et les pointeurs de fonctions pour faire quelque chose de similaire.)

[Ar-S]

Je parlais des graphs retro et très petit sur un écran en QHD.

[Mesa]

Et autre question : Faut-il aussi découper le programme en plusieurs fichier ? (genre avec "include")

Oui, en effet, les gros projets doivent être scindés en plusieurs fichiers, que l'on inclut avec include ou xinclude.
N'hésite pas à utiliser la fonction "Projet" de l'IDE, c'est fait pour, surtout pour la maintenance du projet à long terme, quand on le reprend plusieurs mois plus tard...

[GOTO]mais c'est barbare non ? Je pense qu'il y a mieux ? Les procedures ? Comment ca fonctionne en Pure ?

Oui, c'est barbare et totalement impossible à utiliser sur de gros projet.
N'écoute pas zorro, c'est un fou
On peut utiliser GOTO sur un programme de 10 lignes,... mais dès que tu vas utiliser les procédures, qui modifient la pile, ton GOTO va faire planter ton programme car la pile ne sera pas bonne, et gérer une pile par soi-même est une ... folie.
Les jump de l'assembleur n'ont rien à voir avec les goto même si ça y ressemble, il existe plusieurs jump en fonction de la portée mémoire ( segmentation de la mémoire), bref, oublie.
Utilise l'assembleur que quand tu maîtrisera PB. Oui, le compilateur utilise des goto, mais tu ne sera jamais un compilateur , laisse le faire.

Oui, PureBasic est un langage procedurale, le but étant d'avoir un fichier principal (main) le plus court possible qui appelle les procédures.
Dans les gros projet, il faut déclarer (avec Declare) les procedures avant de les appeler, ce qui permet de les inclure n'importe où dans le code dans ce soucier ni de leur ordre d'apparition dans le code ni de leur interdépendances (une procedure qui appelle une autre procédure).
Si ton projet est vraiment gros (100 000 lignes), les modules seront probablement necessaires.

En résumé: GROS PROJET = Projet de l'IDE + XINCLUDE (+ MODULE) + DECLARE + PROCEDURE

M.

[microdevweb]

Pour ma part, pour un gros projet je découperais mon programme en modules l'avantage étant que les modules peuvent comporter des variables et procédures qui leur sont propres.

Pour un jeu, un module pour le joueur, un pour les ennemis, un pour la gestion général des niveaux et voir un par niveau.

Le moins de code possible dans le main, et beaucoup de procédure.

Pas de goto mais des procédures récursives si nécessaires.

Un code est bien écrit si une année après ne pas y avoir toucher on le comprend encore, le nom des procédures doit être explicite et auto-commenté, idem pour le nom des variables qui cependant ne doivent pas être trop longue.

Remarque :
je n'ai jamais utilisé de goto avec Pb, je ne les utilise que pour le développement d'un Pic en assembleur ou la je n'ai pas le choix, et crois moi c'est très vite gallère de suivre un code qui pourtant fait moins de 1000 lignes

[drfloyd]

Bon, ne pigeant pas les subtilités de tout ce que vous décrivez ci dessus, pour l'instant je suis parti sur une solution simple et barbare :


fichier 1 le "main"

j'y balance plein de include (mes mini jeux)

include "partie1.pb"
include "partie2.pb"
goto partie1

Fichier xxxx.pb
PARTIE1:
repeat
si condition GOTO PARTIE2
...
UNTIL

fichier yyyy.pb
PARTIE2:
repeat
si condition GOTO PARTIE1
si condition GOTO PARTIE3
....
UNTIL

etc... ca aère mon code (qui je le repète sera assez enorme, COSMOS 1, mon jeu précédent faisait 2000ko) et je peux bien sur integrer dans chaque bloc des fonction, voire des gosub

c'est surement ridicule et basique, mais ca fonctionne bien