Ces étapes que vous mentionnez sont probablement effectuées dans des moteurs distincts. C'est juste que les moteurs de jeu simples les ont généralement en un seul passage. Votre séquence
for each object
do physics
do game logic
draw
devient
call physics subsystem
call game logic subsystem
call drawing subsystem
Physics Engine s'occupe des positions et des tailles.
Game Logic Engine s'occupe d'interpréter ce que Physics Engine a changé (il pourrait obstruer certains points de cheminement ...), quels objectifs les personnages ont et quel comportement ils devraient faire , il exécute des scripts programmés (cette fonction de réflexion ).
Drawing Engine dessine quels objets sont visibles, et il sait quels objets sont visibles parce que les moteurs Quake trichent ici (voir la section Draw).
Je vous conseille plutôt d'étudier comment se font les simulations plutôt que les moteurs de jeux. Il existe une énorme culture pop liée au développement de jeux et les moteurs de jeux sont fabriqués dans des langues impératives (en raison de la tradition et de la vitesse); donc c'était plus instructif pour moi d'avoir de bons manuels (plutôt de la théorie) et PUIS de regarder les moteurs (s'entraîner) plutôt que de regarder les moteurs et de réfléchir pendant des heures comment ils l'ont fait.
La physique
Toute notion d'itération de toutes les entités et de {penser, dessiner} entraînera probablement des problèmes. Il y aura des conflits, etc. Je crois que Valve a Havok et je suppose que Havok s'occupe d'une physique suffisamment correcte.
Pense
Pense fonction de est exécutée lorsqu'un temps dans un jeu est égal au temps dans la pensée suivante . Il fonctionne de cette façon dans le moteur Quake, et le moteur Quake est la base des moteurs Half Life. Il n'est PAS exécuté à chaque fois.
En interne, cela devrait être une simple itération à travers une liste d'entités et vérifier si le temps a passé pour appeler la fonction think. La complexité temporelle sera O (N), où N est le nombre d'entités.
S'il y a un très grand nombre d'entités, vous devez mesurer dans quelle mesure cela améliorera les fps. Notez qu'en raison de la loi d' Amdahl, il s'agit d'une accélération potentiellement invisible. Je veux dire, vous venez de parcourir tous les articles et de diminuer et de vérifier un nombre.
Je l'accélérerais en triant les entités par nextthink (créer une liste de pointeurs vers les entités et la trier à chaque fois; pas un tableau d'entités, car les entités pourraient changer leur prochaine pensée à tout moment, donc les réorganiser dans le tableau prend O (N) au lieu de O ( 1) dans la liste).
Vous devriez également regarder le planificateur O (1) sous Linux .
Dessiner
Le moteur dessine ce qui est approximativement visible de la zone où se trouve la caméra. Le niveau du jeu est une partition en arbre, et une zone est une feuille de cet arbre. Je ne vais pas vous déranger avec des détails à ce sujet ... Donc, si une entité est visible, elle est placée dans un ensemble d'entités visibles et elles sont dessinées.
Ils stockent quelles zones sont des zones potentiellement visibles. Il est appelé "ensemble potentiellement visible", PVS pour faire court. Il y a visualisation de PVS , la capsule verte est un joueur et autour de lui est rendu ce que contient son PVS.
<some commercial engine>
-il?