Aidez-vous à classer les moyens d'organiser le code de jeu C ++ / Lua et de séparer leurs tâches. Quelles sont les moyens les plus pratiques, lequel utilisez-vous?
Par exemple, LUA peut être utilisé pour initialiser uniquement les objets C ++ ou à chaque itération de la boucle de jeu. Il peut être utilisé pour la logique de jeu uniquement ou pour les graphiques. Certains moteurs de jeu offrent un contrôle total à tous les sous-titres des scripts! Je n'aime vraiment pas cette approche (pas de séparation du tout).
Est-il une bonne idée de mettre en œuvre tous les objets de jeu (NPC, emplacements) en tant que tables Lua sans objets C ++? Ou il vaut mieux les refléter (Tables Lua pour contrôler les objets C ++)? Ou quelque chose d'autre?
merci.
Continuation du sujet:
3 Réponses :
Démarrer petit. Autoriser l'accès aux entités de jeu afin que vous puissiez effectuer des scripts spécifiques à la carte / au niveau. Comportement qui est cohérent à travers des cartes / niveaux n'a probablement pas besoin de script.
Aussi, donnez uniquement accès à l'interface publique de vos objets.
Merci pour la première réponse. Dites, est-ce une bonne idée de mettre en œuvre tous les objets de jeu (NPC, emplacements) en tant que tables Lua sans objets C ++? Ou il vaut mieux les refuser? Ou autre chose?
Je voudrais implémenter les objets de jeu en C ++, mais les instantiez avec Lua. Pendant l'instatiation, vous pouvez définir des propriétés sur ce que vous voudriez qu'ils soient pour la situation spécifique. Vous pouvez également définir des rappels sur vos scripts Lua, par exemple: si la porte47 est ouverte, appelez Lua-fonction XYZ. Je vous recommande d'utiliser Lua pour "histoire" du jeu, C ++ pour la mécanique.
Mon approche a été de limiter ce qui est exposé à Lua autant que possible. Je n'ai jamais trouvé besoin d'une "principale" ou d'une autre fonction telle appelée à chaque fois que la scène est rendue (ou plus). Certains moteurs Lua (comme l'amour) font cependant. Je préfère définir des objets avec des fonctions de rappel en option pour des événements courants que vous voudrez peut-être que l'objet réponde à une collision, clic de souris, entrant ou quittant le monde de 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 en fonction de ces types. Les objets ont alors une collection de méthodes pouvant être appelées lors de la réponse à divers événements. Toutes ces méthodes Lua Carte des méthodes C / C ++ qui modifient à leur tour les propriétés privées de l'objet. Voici un exemple d'objet de seau pouvant capturer des objets à billes: P>
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;
}
Merci, j'aime beaucoup votre réponse. Donc, vous utilisez Lua principalement comme fichier de configuration et référentiel de fonctions de rappel. Et chaque objet de jeu est implémenté comme objet C ++ et objet Lua. Est-ce exact? Comment synchronisez-vous leurs états? Comment économisez-vous jeu - Générez un nouveau fichier de configuration Lua?
Les objets Lua ne sont vraiment que des interfaces qui mappent les objets en C via un seul champ LightUserData qui résout ce que "soi" est. En ce qui concerne l'enregistrement, je ne sauvegarde généralement que le niveau d'un joueur, mais je pourrais implémenter une fonction qui recrée tout l'état du jeu entièrement en Lua en obtenant simplement l'état de chaque objet, puis en écrivant un script pour les définir tout- peut-être pas Très optimisé et je regarderais probablement la sérialisation dans ce cas.
Je propose cette classification:
Variante extrême: les scripts Lua contrôlent tout (logique de jeu, graphiques, IA, etc.). Encore plus: le script fonctionne comme un programme hôte, possède une boucle de jeu. Certains moteurs font une telle chose. Ba-ad chose: Pas de séparation des tâches du tout et pas de sécurité de script.
Les scripts Lua maintiennent la logique de jeu d'état et de processus de processus. Les scripts probablement sont appelés à chaque écoute de la boucle de jeu.
Les scripts Lua sont rarement utilisés pour les initialisations, les configurations, les rappels. Un programme hôte fournit (lie) une interface très minimaliste pour les scripts. Les scripts sont donc construits à partir de blocs aussi bien conçus et fournis.