J'ai une bibliothèque C ++ qui a une fonctionnalité exposée à Lua et cherche des opinions sur les meilleurs moyens d'organiser mon code LUA.
La bibliothèque est un moteur de jeu, avec un système d'objet de jeu basé sur un composant. Je veux être capable d'écrire certaines de ces composantes comme des cours de Lua. J'utilise Luabind, je peux donc le faire, mais il y a des choix de mise en œuvre que je dois faire et voudrait savoir comment d'autres l'ont fait.
Dois-je avoir juste un seul lua_state, ou un par objet, une par scène, etc.? Cela ressemble à beaucoup de souvenirs au-dessus de la mémoire, mais gardera tout ce qui est sympa et séparé.
Dois-je avoir une table globale ou un par objet, qui peut être mis en place avant un appel à un membre? Cela semblerait minimiser les chances de certaines classes de décider d'utiliser des globaux et d'une autre écrasante accidentelle, avec moins de regroupement de mémoire que de nombreux Lua_states.
ou devrais-je tout simplement faire bombarder dans la table des globaux?
Une autre question implique le code Lua. Deux stratégies se produisent ... Tout d'abord, poussant toutes les définitions de la classe au même endroit, en les chargant lorsque l'application se lance, en mettant en place une définition d'une classe par fichier et simplement en veillant à ce que le fichier soit chargé lorsque j'ai besoin de l'insérer.
J'apprécierais les pensées de quiconque à ce sujet, merci.
3 Réponses :
Une considération est de savoir comment vous envisagez de filer des choses. Si vous souhaitez exécuter le code pour deux objets de jeu en parallèle, par exemple, ils devraient vraiment avoir leur propre Lua_STates séparé afin qu'ils puissent tous les deux courir en même temps. (Bien sûr, cela signifie également qu'ils ne peuvent pas vraiment partager aucun état, sauf via le code C où vous auriez besoin d'être conscient de la sécurité du fil.)
Bon point (+1), bien que la logique du jeu ne soit pas quelque chose que je considère maintenant.
tandis que Luabind est certainement très astucieux et pratique, car votre moteur grandit, alors vos temps de compilation, radicalement.
Si vous avez déjà ou que vous prévoyez d'ajouter, un système de messagerie (que je recommande vivement, spécialement pour la mise en réseau), alors cela simplifie de manière significative. Dans ce cas, ce que vous devrez faire est simplement de lier quelques fonctions clés pour interfacer avec le système de messagerie. Cela gardera vos temps de compilation et vous donnera un système très flexible.
Puisque vous faites un moteur basé sur un composant (bon choix BTW), il est plus logique d'intégrer les scripts en tant que composant d'objet. De cette façon, il a généralement plus de sens de rendre chaque composant de script une nouvelle Coroutin qui exécute un comportement pour chaque objet particulier. Vous n'avez pas besoin de ne pas vous inquiéter de la mémoire trop, les états Lua sont très légers et peuvent être réalisés très rapidement si vous interfacez votre gestionnaire de mémoire avec Lua.
Si vous implémentez des scripts en tant que composant, il est toujours judicieux d'avoir des scripts globaux ou de niveaux chargé, (pour coordonner les déclencheurs d'événements par d'autres objets, ou peut-être des minuteries de frai ennemi).
En ce qui concerne le chargement des scripts, il ne serait pas une mauvaise pratique, de ne pas charger les scripts dont vous aurez besoin pour un niveau tout à la fois et de les conserver dans une table globale pour accéder au FAS, le chargement des scripts Lua est assez rapide. , spécialement si vous les avez pré-compilées.
sur le code Lua, je vous recommande de charger tout lorsque l'application lance (sauf si vous n'avez pas besoin de faire "paresseux" chargement de vos classes principales à la demande). Il simplifie généralement la maintenance et le débogage. Et dans le cas du code chargé qui n'est plus nécessaire, le collecteur des ordures nettoiera cela avec une rapidité. : -)