Une critique est demandé

**Pifpafboum** · 16/03/2018, 21h57

Oyez, oyez, braves gens

Pour apprendre le javascript, je me suis lancé dans le jeu vidéo. Je me demande d'ailleurs si c'est une bonne idée ? Quand je parle de jeu, c'est casse-brique, jeu du pendu...rien de bien folichon. La création d'un fps attendra l'an 2040, peut-être repoussé en 2045. Vous pouvez trouver ces jeux à dutempsaperdre.fr;
Attention j'ai bien écrit que ce n'était pas folichon.
Les jeux fonctionnent, des erreurs de programmation sans que cela soit des bugs, mais, au final, cela ne me dit pas si le code est bon ou pas. C'est quand même le but premier, apprendre le javascript. Un programme peut bien se dérouler et avoir un code dès plus bancal.
Il est vrai aussi que je voudrais améliorer mes jeux; Et c'est là que vous entrez en jeu. Si quelqu'un a du temps devant lui et une bonne connaissance du langage qui nous occupe et s'il pouvait jeter un œil voir les deux sur mon code pour le critiquer, cela m'arrangerait.
J'ai simplifier le code, mis au propre, repassé mes chemises, écrit des explications, que j'espère explicatif et pris un café. Le code se trouve en pièce jointe ou disponible sur le site (voir en pied de page)
Pour ceux et celles qui n'auraient pas le temps ni l'envie, j'ai une question bonus : Selon le navigateur utilisé, la vitesse des personnages, du jeu en général, ne sera pas la même. Opéra étant le meilleur pour ma part et firefox le plus lent. J'ai décidé d'en attribuer le problème aux navigateurs mais ai-je raison ou cela est du à ma programmation ?
Sinon si vous avez les numéros gagnants du prochain tirage du loto et que la richesse ne vous tente pas, n'hésitez pas à me les transmettre. Ce serait gentil de votre part.
Sur ce, bon week-end.

**Marco46** · 16/03/2018, 22h34

Crées toi un repo git sur github, gitlab ou mieux framagit et publie ton code.

Le zip opaque c'est au mieux sooooo 1990, au pire un attrape couillon.

**Loralina** · 18/03/2018, 12h08

Bonjour,

Selon le navigateur utilisé, la vitesse des personnages, du jeu en général, ne sera pas la même. Opéra étant le meilleur pour ma part et firefox le plus lent. J'ai décidé d'en attribuer le problème aux navigateurs mais ai-je raison ou cela est du à ma programmation ?

C'est ce qui arrive si vous ne tenez pas compte de la durée réellement écoulée entre deux rafraîchissements.
Mais en tenir compte peut impliquer diverses problématiques très délicates à gérer selon le jeu : gestion des collisions, équations de mouvements difficiles à adapter, etc.

**eleydet** · 18/03/2018, 21h06

Bonsoir,

Selon le navigateur utilisé, la vitesse des personnages, du jeu en général, ne sera pas la même...

Le bout de code ci-dessous corrige, enfin je crois, la valeur de la variable delai pour qu'elle représente une seconde.

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
<head>
...
<script>
function test() {
                debut = new Date();
                test_delai=setTimeout("fin_test()", 1000);
        }
        function fin_test() {
                clearTimeout(test_delai);
                fin = new Date();
                delai = delai*1000/(fin.getTime()-debut.getTime());
                tourne();
        }
</script>
</head>
 
<body onload="test();">
...
</body>

**Pifpafboum** · 20/03/2018, 21h44

Zut et flûte
Va falloir que je change mon code si le ralentissement n'est pas dû aux navigateurs. D'un autre côté je trouvais suspect cette fonction window.setTimeout.
Merci bien pour les réponses, je m'en vais étudier la chose.

Sinon les années 90 ont vu le groupe Nirvana, dans les années 2000 vous avez Jul, comme quoi tout n'était pas si mauvais avant, même les dossiers zippés, jeune padawan.
Pas envie de m'inscrire sur un énième site pour mettre du code. Si j'ai le temps je le mettrais tout beau sur mon site. Pour l'instant vous l'avez en zip.

**NoSmoking** · 21/03/2018, 10h33

Bonjour,
pas regardé mais pour les animations je te conseilles d'utiliser requestAnimationFrame.

**Loralina** · 24/03/2018, 10h05

Bonjour,

Envoyé par Pifpafboum

D'un autre côté je trouvais suspect cette fonction window.setTimeout.

J'ai fait un exemple qui montre l'importance, d'une part, de l'emplacement de setTimeout dans le script, et, d'autre part, de la durée d'exécution du script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<script>
(function(nb_duree_setTimeout,nb_duree_while)
	{
	var nb_;
 
	//deux points de départ presque égaux
	console.time("A");
	console.time("B");
 
	//setTimeout A
	console.time("setTimeout A");
	setTimeout(function() //sera exécutée au bout d'une seconde, soit une demi-seconde de plus que le délai souhaité par rapport au point A
		{
		console.timeEnd("A");
		console.timeEnd("setTimeout A");
		},nb_duree_setTimeout);
 
	//boucle
	nb_=performance.now();
	console.time("boucle");
	while(performance.now()-nb_<nb_duree_while) {}
	console.timeEnd("boucle");
 
	//setTimeout B
	console.time("setTimeout B");
	setTimeout(function() //sera exécutée au bout d'une seconde et demi, soit une seconde de plus que le délai souhaité par rapport au point B
		{
		console.timeEnd("B");
		console.timeEnd("setTimeout B");
		},nb_duree_setTimeout);
	})(500,1000);
</script>

Pour minimiser l'impact du script, il faut mettre setTimeout au début.
S'il est à la fin, la durée d'attente sera celle du script ajoutée au délai de setTimeout.
S'il est au début, la durée d'attente sera le maximum entre la durée du script et le délai de setTimeout, mais dans ce cas, autant utiliser setInterval :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<script>
console.time("setInterval");
setInterval(function()
	{
	var nb_;
 
	console.timeEnd("setInterval"); //une demi-seconde la première fois, une seconde ensuite
	console.time("setInterval");
 
	//boucle
	nb_=performance.now();
	while(performance.now()-nb_<1000) {}
	},500);
</script>

Un avantage éventuel à utiliser setTimeout, c'est de le placer à la fin et de retirer du délai, la durée du script tout en fixant un délai minimal de quelques millisecondes pour permettre au navigateur de respirer un minimum (à voir l'intérêt réel).

Si vous utilisez requestAnimationFrame, la cadence sera rapide, donc, si votre script est complexe, vous aurez des ralentissements.
De plus, le traitement graphique doit prendre aussi pas mal de ressources.

Peu importe ce que vous utilisez, il faut considérer qu'entre deux exécutions, la durée ne sera pas toujours fixe.
Le navigateur peut jouer aussi.
Vous pouvez alors adapter les vitesses.

Le mieux n'est pas d'avoir une vitesse constante par rapport au temps écoulé, mais une jouabilité/difficulté constante.
Tant que c'est fluide (par exemple : 24 images par seconde, voire un peu moins), on peut chercher à obtenir une vitesse constante visuellement.
Quand le jeu devient saccadé, la difficulté augmente : si vous avez une certaine vitesse pour une cadence de 24, alors, si le jeu tourne à une cadence de 12, il peut être plus ergonomique de multiplier par 1.5 que par 2, c'est en fonction du jeu.

Par ailleurs, quand la cadence ralentit considérablement et que vous augmentez les vitesses, cela peut devenir compliqué pour les tests de collision.
La solution simple, mais gourmande, est de faire plusieurs étapes en décomposant le mouvement en plusieurs déplacements et en testant les collisions à chaque fois.
Autrement, on peut essayer de faire des calculs d'intersection, mais ce n'est pas toujours envisageable, notamment par exemple dans le cas où vous avez des trajectoires curvilignes de plusieurs objets.

A noter aussi que si vous avez des ralentissements très ponctuels, il n'est pas forcément indispensable, ni même mieux, d'adapter les vitesses.
De même, si vous partez sur une cadence pas trop élevée, vous pouvez vous contenter d'une légère adaptation pour garder un niveau de difficulté constant (par exemple, accélérer légèrement les vitesses des projectiles ennemis quand la cadence baisse).

**Watilin** · 25/03/2018, 17h43

À propos des timers, si tu es à l’aise avec l’anglais @Pifpafboum, John Resig a écrit un très bon article qui explique les petits détails qui nous piègent.

Cet article a au moins dix ans, mais le fonctionnement de JavaScript n’a pas changé sur ce point. Par contre, l’article ne parle pas de requestAnimationFrame, qui n’existait pas à l’époque (ou n’était pas suffisamment répandu pour mériter qu’on en parle). Pour simplifier, on peut voir requestAnimationFrame comme un setTimeout dont le délai est choisi par le moteur d’exécution. Ce délai sera d’un 60^e de seconde dans les meilleures conditions, mais plus long si le processeur a trop de charge ou si l’application est en arrière-plan.

Les différences de timing ne dépendent pas uniquement du navigateur, il y a aussi le système d’exploitation et le matériel en lui-même. Tu ne peux tout simplement pas supposer que les durées seront les mêmes sur ta machine de développement et les machines de tes joueurs et joueuses.

À propos de ton code, j’ai commencé à jeter un œil. Vu la quantité de fichiers (j’en ai compté 28 pour le jeu « Vol »), il vaut mieux adopter des pratiques qui te permettent de réduire autant que possible les obstacles à l’évolution du code, autrement dit faciliter la maintenance.

Pour ça j’ai déjà une remarque : les fonctions ont beaucoup trop de paramètres. À partir de 3 ou 4, difficile de se rappeler quoi passer en argument sans avoir la définition de la fonction sous les yeux.

Une pratique courante en JavaScript est de passer des objets de paramètres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// Définition :
function f_creation_du_jeu( params = {} )
{
  var tab_immobile = params["tab_immobile"];
  var tab_mobile   = params["tab_mobile"];
  // etc.
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
// Appel :
f_creation_du_jeu ({
  "tab_immobile"    : tab_immobile,
  "tab_mobile"      : tab_mobile,
  "tab_declencheur" : tab_declencheur,
  "tab_donnee_jeu"  : tab_donnee_jeu,
  "tab_des_images"  : tab_des_images,
  "tab_des_sons"    : tab_des_sons
});

Ça a l’air redondant comme ça, mais ça a l’avantage de te permettre de passer les arguments dans l’ordre que tu veux, et de ne pas tous les passer si tu prévois des valeurs par défaut, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function f_creation_du_jeu( params = {} )
{
  var tab_immobile = params["tab_immobile"] || new Array();
  ...

Ou bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function f_creation_du_jeu( params = {} )
{
  var tab_immobile = params["tab_immobile"];
  if (!tab_immobile) {
    ...
  }
  ...

Cette histoire d’objets m’amène au problème suivant : les tableaux de JS ne sont pas associatifs. C’est une confusion qu’on fait fréquemment, peut-être à cause de la ressemblance avec PHP…
JS nous permet d’attacher des propriétés sur n’importe quoi qui hérite de Object, par exemple un objet Date ou Error.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
var d = new Date();
d["nimportequoi"] = 42;
console.log(d["nimportequoi"]);

Les tableaux héritent également de Object et donc n’échappent pas à la règle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
var tab = new Array();
tab["nimportequoi"] = 42;
console.log(tab["nimportequoi"]);

Cependant, les tableaux ont certains comportement spéciaux, qui font que ce sont des tableaux, et qui ne fonctionnent pas bien avec les propriétés rajoutées. Quand tu commences à avoir envie d’utiliser des fonctionnalités de tableaux telles que les méthodes map, forEach ou encore la boucle for (... of ...), ça ne marche plus.

Comme souvent quand on parle de maintenance de code, la notion d’intention est importante. Plus tu exprimes clairement ton intention au moment de l’écriture, plus tu réduis les risques de mauvaise interprétation à la relecture. Si tu veux utiliser une variable JS pour contenir des propriétés quelconques, n’utilise pas un tableau, utilise directement un objet.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var objet = {};

Cette notation est parfois appelée « objet littéral ». Les anglophones parlent aussi de « plain object », en particulier dans les docs de jQuery.

Tu peux aussi utiliser new Object() pour rester cohérent avec tes déclarations de tableaux qui utilisent new Array().

À la manipulation, la syntaxe reste la même :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var obj_donnee_jeu = {};
 
...
 
obj_donnee_jeu['largeur_fond'] = document.body.clientWidth;
obj_donnee_jeu['hauteur_fond'] = document.body.clientHeight;

Des infos complémentaires mais qui présentent un petit risque de t’embrouiller, je les mets en spoiler :

Voilà, c’est tout pour l’instant, je vais attendre la prochaine mise à jour de ton code avant de faire d’autres remarques

Une critique est demandé

JavaScript

Vue hybride

Discussions similaires

Partager

Partager