Lua et C++: séparation des tâches

Question

Aidez-nous à classer les façons d'organiser le code de jeu C++/Lua et à séparer leurs tâches. Quels sont les moyens les plus pratiques, lequel utilisez-vous? Par exemple, Lua peut être utilisé pour initialiser des objets C++ uniquement ou à chaque itération de boucle de jeu. Il peut être utilisé aussi bien pour la logique de jeu que pour les graphiques. Certains moteurs de jeu offrent un contrôle total à tous les sous-systèmes des scripts! Je n'aime vraiment pas cette approche (pas de séparation du tout).

Est-ce une bonne idée d'implémenter tous les objets de jeu (npc, emplacements) comme tables Lua sans objets C++? Ou est-il préférable de les mettre en miroir (tables Lua pour contrôler les objets C++)? Ou autre chose?

Merci.

Modifier. Ma classification: Lua and C++: separation of duties.

la poursuite du sujet: Lua, game state and game loop

Answer 1

Mon approche a été de limiter autant que possible ce qui est exposé à Lua. Je n'ai jamais trouvé le besoin d'une fonction "principale" ou autre qui est appelée à chaque fois que la scène est rendue (ou plus). Certains moteurs Lua (comme LOVE) le font cependant. Je préfère définir des objets avec des fonctions de rappel optionnelles pour les événements courants auxquels vous voulez que l'objet réagisse, comme une collision, un clic de souris, entrer ou quitter le monde du jeu, etc.

Le résultat final est très déclaratif, presque un fichier de configuration pour les objets. J'ai une fonction pour créer des classes ou des types d'objets et une autre pour créer des objets basés sur ces types. Les objets ont alors une collection de méthodes qui peuvent être appelées en répondant à divers événements. Toutes ces méthodes Lua sont mappées aux méthodes C/C++ qui à leur tour modifient les propriétés privées de l'objet. Voici un exemple d'un objet seau qui peut capturer des objets à billes:

define { 
    name='ball'; 
    texture=png('images/orb.png'); 
    model='active'; 
    shape='circle'; 
    radius=16; 
    mass=1.0; 
    elastic=.7; 
    friction=.4; 
} 

define { 
    name='bucket'; 
    model='active'; 
    mass=1; 
    shape='rect'; 
    width=60; 
    height=52; 
    texture=png('images/bucket.png'); 
    elastic=.5; 
    friction=.4; 
    oncontact = function(self, data) 
     if data.subject:type() == 'ball' then 
      local a = data.subject:angleTo(self:getxy()) 
      if a < 130 and a > 50 then 
       --update score etc.. 
      end 
     end 
    end; 
} 

Je ne prendrais pas cela comme la « une façon vraie » pour mettre en œuvre votre API de script. Une des beautés de Lua est qu'il supporte de nombreux styles différents d'API. C'est juste ce que j'ai trouvé fonctionne bien pour les jeux que je fais - des jeux basés sur la physique 2D.

Answer 2

Commencez petit. Autorisez l'accès aux entités de jeu afin de pouvoir exécuter des scripts spécifiques à la carte ou au niveau. Un comportement cohérent entre les cartes/niveaux n'a probablement pas besoin de script.

De même, ne donnez accès qu'à l'interface publique de vos objets.

Answer 3

Je propose cette classification:

1. variante Extreme: les scripts Lua tout contrôle (logique de jeu, graphiques, AI, etc.). Encore plus: le script fonctionne comme un programme hôte, possède une boucle de jeu. Certains moteurs font une telle chose. Chose Ba-ad: pas de séparation des tâches du tout et pas de sécurité script. Les scripts Lua maintiennent l'état du jeu et la logique du jeu de processus. Des scripts sont probablement appelés à chaque itération de boucle de jeu.

2. Les scripts Lua sont rarement utilisés pour les initialisations, les configurations et les rappels. Un programme hôte fournit (lie) une interface très minimaliste pour les scripts. Les scripts sont construits à partir de ces blocs bien conçus et fournis.