Bah écoute j'aime les défi et je vais relever celui celui-là ^^ puis comme le dit ta discussion avec le confinement va il y avoir du temps a abattre ^^
Lol moi je m'y connais absolument pas en carte tu me parle de belotte contrée... euh oui ?
60K Lignes? C'est rien du tout hélas :/
Soyons clairs: le développement, c'est énormément de lignes de codes très obscur, et ensuite une fois le tout groupé ça commence à présenter un truc.
Pour les langages? Te conseiller un truc par quoi commencer serait méchant de ma part parce qu'il va te manquer énormément de fondamentaux!
Alors dans l'ordre
1° Comprendre la logique booléenne. ça n'a l'air de rien, mais si tu comprends cela tu comprendras ensuite le comportement de ton environnement.
2° Comprendre et appréhender l'algorithmie. C'est fondamental pour trois raisons
- Transformer une réflexion en code
- Rendre le code fonctionnel, rapide et compréhensible
- Savoir trouver où sont tes erreurs
3° Comprendre et maîtriser l'organisation technique d'un projet.
Ce dernier point est le plus difficile à saisir car il y a autant de cadres qu'il y a de développements!
Je vais te faire les trois points précédents en texte (attention pavés)
1° La logique booléenne
L'algèbre de Boole (pas d'humour c'était son nom), c'est de faire des mathématiques avec des éléments simples. Très grossièrement, c'est "comment traiter des choses qui disent oui/non pour obtenir un résultat final".
Les bases du booléen c'est qu'une entrées est un vrai/faux qu'on appelle "booléen" (ça tombe bien). Chaque entrée est définie par une lettre. Par exemple, prenons une lampe que tu veux allumer avec trois boutons a b et c.
Tu mets en règles littérales pour obtenir l'équation de Boole. Admettons L est ta lampe.
L=ab+c
L=abc
L=ab+bc
ça dit quoi:
* le "+" est un ou
L'absence de signe (ou le point) est un "et"
donc dans l'ordre
L= (a et b) ou C-> Si tu as C qui est vrai, alors L s'allume. Sinon, il faut que ce soit a et b ensemble pour que ça marche.
L= a et b et c.-> Tu as besoin de trois pour allumer L
L=(a et b) OU (b et c)-> Tu as forcément deux interrupteurs en simultané (ab ou bc) pour que L s'allume.
Donc de là tu peux établir des règles extrêmement complexes. Tiens, pour le "fun" ça peut donner une règle du genre
- Si a (est vrai) et que b non, ou que c est vrai et d en même temps, tout ça SAUF si f est allumé...
Tu vois le genre...
22° L'algorithmie
GROS morceau. LE morceau indispensable. LA base. LE truc qui me rend dingue quand quelqu'un ne sait pas ce qu'il fait.
Pour moi la définition la plus juste de l'algo c'est
Transcrire des règles écrites sous la forme d'un comportement logiciel
Pour te donner une idée, c'est transformer
"Tant que le perso a assez de vie, afficher sa jauge de vie"
en (pseudo code)
Code:
while (live>0)
{
live.gauge(live)
}
C'est très grossier dit comme ça, mais c'est l'idée.
En algorithmie, les bases sont
- Les conditions
- Les boucles
Les conditions sont les "tests"
-> "Si telle valeur vaut x, alors faire un truc, sinon faire autre chose"
Cela se matérialise comme ceci
JavaScript:
if(valeur=x)
{
faireUnTruc
} else {
FaireAutreChose
}
ça c'est le cas "simple.
Tu peux avoir en tests une valeur que tu veux vérifier selon plusieurs valeurs.
Par exemple un test dans un JDR selon le niveau de vie
JavaScript:
int statLive = round(life/100;2); // On a le pourcentage de vie courant arrondi à deux après la virgule fonction "round"
level=~~(statLife/25)
// Là j'explique: On fait une division du pourcentage de vie (0-100%) par 25 pour avoir quatre niveaux
// 0 <=25%
// 1 compris entre 25 et 50%
// 2 compris entre 50 et 75%
// 3 compris entre 75 et 100%
// 4 full vie
switch(level)
{
case(0):
// Perso mal barré
if(lifeStat=0)
{
// on gère la mort du personnage
proceedDeath();
} else {
// On avertit avec le niveau en rouge
blinkLifeLevel(statLife;"red")
}
break;
case(1):
// on avertir en orange le niveau de vie
blinkLifeLevel(statLife;"orange")
break;
case(2):
// On avertit le niveau moyen en mettant à jour en jaune la jauge de vie
blinkLifeLevel(statLife;"yellow")
break;
case(3):
// Vie comprise entre 75 et 100
case(4):
// Vie à 100%
default:
// On ne fait rien s'il n'y a pas de valeur conforme ou que le niveau de vie est conforme.On affiche tout de même la vie
blinkLifeLevel(statLife;"blue")
}
Là tu vois on dit
- Si la vie est inférieure à 25% on alerte en rouge
- Si la vie est comprise entre 25 et 50, alerte en orange
- Si la vie comprise entre 50 et 75, alerte en jaune
- Sinon on affiche la jauge en bleu
La méthode
blinkLifeLevel prend deux paramètres:
- Le niveau de vie en pourcentage (pour afficher une jauge)
- Le codage couleur de fond afin d'informer le joueur de son niveau et du danger.
Petites subtilités:
- J'utilise en entrée une division qui me retourne la valeur entière pour avoir un "niveau". C'est le principe du "modulo" (ou de la division euclidienne pour ceux qui se souviennent)
- Le switch case que j'utilise est préparé pour traiter les éventuelles évolutions ultérieures.
Là dans cet exemple précis:
JavaScript:
case(1):
// on avertir en orange le niveau de vie
blinkLifeLevel(statLife;"orange")
break;
Le
break fait sortir du test de valeur. En gros, si "level" vaut "1", alors j'exécute
blinkLifeLevel(statLife;"orange") .
Là où je ruse pour les évolutions c'est sur ce bout de code précis
JavaScript:
case(3):
// Vie comprise entre 75 et 100
case(4):
// Vie à 100%
default:
Je dis que 3 4 et par défaut je fais la même chose. Pourquoi? Parce que je ne mets pas de break!
L'avantage? Passons sur un autre exemple
JavaScript:
switch(level)
{
case(5):
case(8):
faireuntruc()
break;
case(99):
faireAutreChose();
default:
FaireEncoreautrechose();
}
ça dit quoi?
Si la valeur "level"
- égale à 5 ou 8 : j'exécute
faireuntruc()
- égale à 99 : j'exécute
faireAutreChose()
- Pour les autres valeurs (clé "default) j'exécute
FaireEncoreautrechose()
Voilà le premier exemple de "tests" sur des valeurs.
Je passe ensuite sur les boucles ... histoire que tu en saisisses la complexité et la subtilité selon les situations.