Partie I Introduction

CHAPITRE 1 Structure, performance et jeux
1.1.
Qu'est-ce que l'architecture logicielle ?
1.2.
Combien ça coûte?
1.3.
Performances et vitesse
1.4.
Les avantages du mauvais code
1.5.
Équilibrage
1.6.
Simplicité
1.7.
En conclusion

Partie II : Retour sur les modèles de conception

CHAPITRE 2 Commandes
2.1.
Modifier la touche d'entrée
2.2.
Donner des instructions aux acteurs
2.3.
Annuler et rétablir
2.4.
Les classes sont-elles une bonne chose, mais les types fonctionnels ne le sont pas autant ?
2.5.
Documents connexes

CHAPITRE 3 Léger
3.1.
Arbres qui pénètrent dans la forêt
3.2.
Des milliers d'instances
3.3.
motif léger
3.4.
Informations topographiques
3.5.
À propos des performances
3.6.
Documents connexes

CHAPITRE 4 L'Observateur
4.1.
Réalisations
4.2.
Comment ça marche
4.3.
« Trop lent »
4.4.
« Vous faites trop d’allocation dynamique. »
4.5.
Questions en suspens
4.6.
L'Observateur d'aujourd'hui
4.7.
Observateur du futur

CHAPITRE 5 PROTOTYPE
5.1.
Modèle de conception de prototype
5.2 Paradigme du langage prototype
5.3.
Prototype pour la modélisation des données

CHAPITRE 6 Singleton
6.1.
Modèle Singleton
6.2.
Pourquoi utiliser un singleton ?
6.3.
Pourquoi le singleton pose-t-il problème ?
6.4.
plan alternatif
6.5.
Que reste-t-il de Singleton ?

CHAPITRE 7 Statut
7.1.
Créer un jeu de souvenirs
7.2. FSM nous sauvera
7.3.
Énumérations et instructions à sélection multiple
7.4.
Modèle d'état
7.5.
Où dois-je placer l'objet d'état ?
7.6.
Entrée et sortie
7.7.
Quels sont les inconvénients ?
7.8.
machine à états parallèle
7.9.
machine à états hiérarchique
7.10.
Automates à pile
7.11.
À quel point est-ce utile ?

Partie III : Modèles de séquences

CHAPITRE 8 Double tampon
8.1.
intention
8.2.
motif
8.3.
modèle
8.4.
Quand l'utiliserez-vous ?
8.5.
prudence
8.6.
Exemple de code
8.7.
décisions de conception
8.8.
Documents connexes

CHAPITRE 9 BOUCLE DE JEU
9.1.
intention
9.2.
motif
9.3.
modèle
9.4.
Quand l'utiliserez-vous ?
9,5.
prudence
9.6.
Exemple de code
9.7.
décisions de conception
9.8.
Documents connexes

CHAPITRE 10 MÉTHODE DE MISE À JOUR
10.1.
intention
10.2.
motif
10.3.
modèle
10.4.
Quand l'utiliserez-vous ?
10.5.
prudence
10.6.
Exemple de code
10.7.
décisions de conception
10.8.
Documents connexes

Partie IV Modèles comportementaux

CHAPITRE 11 Code octet
11.1.
intention
11.2.
motif
11.3.
modèle
11.4.
Quand l'utiliserez-vous ?
11.5.
prudence
11.6.
Exemple de code
11.7.
décisions de conception
11.8.
Documents connexes

CHAPITRE 12 Bac à sable de sous-classe
12.1.
intention
12.2.
motif
12.3.
modèle
12.4.
Quand l'utiliserez-vous ?
12,5.
prudence
12.6.
Exemple de code
12.7.
décisions de conception
12.8.
Documents connexes

CHAPITRE 13 Type d'objets
13.1.
intention
13.2.
motif
13.3.
modèle
13.4.
Quand l'utiliserez-vous ?
13.5.
prudence
13.6.
Exemple de code
13.7.
décisions de conception
13.8.
Documents connexes

Partie V Modèles de découplage

CHAPITRE 14 COMPOSANTS
14.1.
intention
14.2.
motif
14.3.
modèle
14.4.
Quand l'utiliserez-vous ?
14.5.
prudence
14.6.
Exemple de code
14.7.
décisions de conception
14.8.
Documents connexes

CHAPITRE 15 FILE D'ATTENTE DES ÉVÉNEMENTS
15.1.
intention
15.2.
motif
15.3.
modèle
15.4.
Quand l'utiliserez-vous ?
15,5.
prudence
15.6.
Exemple de code
15.7.
décisions de conception
15.8.
Documents connexes

CHAPITRE 16 INTERMÉDIAIRES DE SERVICE
16.1.
intention
16.2.
motif
16.3.
modèle
16.4.
Quand l'utiliserez-vous ?
16.5.
prudence
16.6.
Exemple de code
16.7.
décisions de conception
16.8.
Documents connexes

Partie VI Modèles d'optimisation

CHAPITRE 17 LOCALITÉ DES DONNÉES
17.1.
intention
17.2.
motif
17.3.
modèle
17.4.
Quand l'utiliserez-vous ?
17.5.
prudence
17.6.
Exemple de code
17.7.
décisions de conception
17.8.
Documents connexes

CHAPITRE 18 Drapeau sale
18.1.
intention
18.2.
motif
18.3.
modèle
18.4.
Quand l'utiliserez-vous ?
18.5.
prudence
18.6.
Exemple de code
18.7.
décisions de conception
18.8.
Documents connexes

CHAPITRE 19 Pool d'objets
19.1.
intention
19.2.
motif
19.3.
modèle
19.4.
Quand l'utiliserez-vous ?
19.5.
prudence
19.6.
Exemple de code
19.7.
décisions de conception
19.8.
Documents connexes

CHAPITRE 20 DIVISION SPATIALE
20.1.
intention
20.2.
motif
20.3.
modèle
20.4.
Quand l'utiliserez-vous ?
20,5.
prudence
20.6.
Exemple de code
20.7.
décisions de conception
20.8.
Documents connexes

13 modèles de conception de jeux pour une structure performante et robuste

La performance est plus importante dans les jeux que dans tout autre domaine du logiciel.
Cependant, les développeurs finissent par « bricoler » le planning, et les problèmes structurels ne sont pas résolus.
Même si une fonctionnalité est ajoutée, on se retrouve au point de départ car on ne trouve pas la réponse dans le code source existant.
Cela a conduit l'auteur à écrire un livre sur la conception de logiciels à la fois performants et structurellement robustes.
Le terme « modèle de conception » est désormais devenu une sorte de texte sacré grâce au livre du même nom publié par le GoF.
L'auteur reprend et affine cette méthodologie, établissant des modèles de conception spécifiques aux jeux et les publiant dans cet ouvrage.
Pour les développeurs locaux qui tentent désespérément de résoudre des problèmes urgents sans aucune base en architecture logicielle, ce livre est une lecture incontournable, offrant une méthodologie de conception qui permet d'obtenir simultanément de bonnes performances et une bonne maintenabilité.
La partie 1 examine la relation entre la structure et les performances dans les jeux, la partie 2 examine les modèles de conception GoF du point de vue du développement de jeux, puis les parties 3 à 6 examinent 13 modèles de conception spécifiques aux jeux, divisés en quatre catégories : ordre, comportement, découplage et optimisation.
Chaque modèle est structuré de manière cohérente en huit sections : Intention, Motivation, Modèle, Quand l’utiliser, Considérations, Exemple de code, Décisions de conception et Documents associés, ce qui permet également de l’utiliser comme référence.
Je dédie ce livre à ces développeurs.
- Avez-vous du mal à fusionner votre code dispersé en un tout cohérent ?
- À mesure que la base de code s'agrandit, devient-il plus difficile de trouver ce qui a changé ?
- Avez-vous l'impression que plus vous créez de jeux, plus ils deviennent un véritable fouillis de toutes sortes de choses ?
- Êtes-vous curieux de savoir s'il existe des modèles de conception applicables aux jeux ?
- J'ai entendu parler de « cohérence du cache » et de « pools d'objets », mais je ne sais pas comment les utiliser pour rendre les jeux plus rapides ?