Vaut-il la peine d'implémenter les mécanismes / règles du jeu séparément du code principal?

Je ne sais pas si cela correspond à la portée de cette communauté, ou devrait plutôt aller à Stackoverflow.

Supposons que je souhaite que mon jeu soit facilement extensible dans son cœur, c'est-à-dire que beaucoup de gens, même sans connaissances de programmation décentes, puissent non seulement modifier les règles existantes, mais même y ajouter des mécanismes de jeu totalement nouveaux. Je ne suis pas moi-même un bon programmeur, mais je suis prêt à apprendre, j'ai juste besoin de quelques instructions et de l'assurance que cela peut être fait.

Ce que j'ai pensé, c'est s'il est possible / faisable de mettre en œuvre la mécanique du jeu d'une manière ou d'une autre, séparément du code de l'utilitaire principal? Je veux dire, pour les jeux de table, nous avons ces livres de règles qui ne contiennent pas d'algorithmes réels de toutes les actions, mais décrivent plutôt certains protocoles et limites, référençant fortement le contexte de chacun de ces éléments. Est-il possible de faire quelque chose de similaire pour un jeu PC, comme décrire toutes les règles dans un très haut niveau, facilement lisible (et modifiable) par un langage de programmation humain, qui est ensuite "consommé" et analysé par le code utilitaire dans un instance de travail de la mécanique de jeu?

Cela semble vraiment avoir besoin d'écrire mon propre langage et un compilateur pour cela)) Ce que je ne pourrai pas faire, bien sûr. Mais peut-être existe-t-il une approche plus facile du problème?

Pour info: ma langue de choix pour le code utilitaire sera Python 3.x

De manière générale, la facilité avec laquelle tout système peut être étendu dépend du degré auquel ses sous-systèmes sont étroitement ou faiblement couplés . Habituellement, plus les sous-systèmes sont couplés de manière lâche, plus il est facile de les modifier car ils sont isolés et ne nécessitent pas nécessairement une compréhension complète du système dans son ensemble.

Cependant, rien n'est gratuit - un tel système nécessite généralement plus de ressources (diverses combinaisons de temps, d'argent et de compétences) pour être construit. Le degré d'extensibilité que vous avez décrit me semble être en contradiction directe avec le niveau de compétence que vous vous êtes attribué. Cela pourrait être fait, mais créer un logiciel comme vous l'avez décrit est une entreprise très difficile.

La chose la plus proche que je connaisse est Vassal (qui est beaucoup plus programmatique que vous l'avez décrit), ou la création d'un mod pour Tabletop Simulator (qui dépend principalement de l'interaction humaine pour interpréter et appliquer les règles du jeu).

Ce que j'ai pensé, c'est s'il est possible / faisable de mettre en œuvre la mécanique du jeu d'une manière ou d'une autre, séparément du code principal de l'utilitaire?

C'est absolument possible. Une façon souvent utilisée dans les jeux est le script Lua .

De l'article lié:

Lua a été initialement conçu en 1993 comme un langage pour étendre les applications logicielles afin de répondre à la demande croissante de personnalisation de l'époque.

De nombreux jeux utilisent Lua. (Je lierais mais la réputation d'un nouvel utilisateur limite mon nombre de liens.)

Les scripts Lua peuvent être compilés au moment de l'exécution. Cela signifie qu'ils peuvent (par exemple) être des fichiers texte situés dans le répertoire "scripts" de votre jeu, facilement modifiables par un modder. Votre jeu les charge et les exécute.

J'ai vu des scripts Lua définir les propriétés des unités en jeu. Voici un exemple aléatoire de TA Spring.

Mais vous voulez "décrire toutes les règles". C'est possible en théorie, car Lua est un langage complet, mais le problème est que vous devez être assez prémonitoire pour que le code du jeu de base sache rechercher des scripts pour étendre son comportement.

Par exemple, vous pourriez développer un jeu de cartes qui sait rechercher des cartes dans un répertoire "scripts / cartes". C'est idéal pour ajouter de nouvelles cartes ou modifier des cartes existantes. Mais si vous souhaitez plus tard étendre votre jeu pour inclure des miniatures sur une grille, vous devrez modifier le code principal - aucune quantité de violon Lua ne vous y amènera tout seul.

Veuillez noter: j'évoque Lua parce que je sais qu'il est couramment utilisé à la fois dans les jeux et dans les logiciels de personnalisation. Je ne dis pas que c'est la seule solution, ni la meilleure pour les besoins de celui qui l'interroge.

Il existe un continuum d'approches et la pertinence de l'une d'entre elles dépendra exactement de ce que vous essayez de faire. Plus précisément, combien de contrôle souhaitez-vous offrir au tweaker?

À l'extrême fin du contrôle, vous pouvez simplement laisser le tweaker modifier le code de l'ensemble du jeu. À ce stade, vous publieriez essentiellement le code de l'utilitaire et au moins un exemple d'utilisation. Un tweaker peut utiliser autant ou aussi peu de code qu'il le souhaite.

Une approche qui offre un peu moins de contrôle serait de "geler" votre code utilitaire (par exemple en le compilant au préalable) et de ne laisser que les tweakers remplir des fonctions spécifiques (rappels), restreignant ce qu'ils peuvent faire. Selon ce que vous voulez faire, cette approche peut prendre plusieurs formes. Une méthode courante serait de mettre toute la partie d'affichage dans le code utilitaire / principal et toutes les mécaniques dans la partie modifiable. Ou, vous voudrez peut-être garder certaines mécaniques dans la partie "gelée" parce que les joueurs ne voudront probablement pas les changer, ou les rendre modifiables est trop compliqué.

À l'extrémité basse du continuum, on laisse uniquement les tweakers changer les valeurs dans une plage fixe. Un fichier de données qui vous permet de sélectionner les couleurs des objets dans le jeu en serait un exemple. Vous pouvez cependant utiliser cette approche tout en offrant beaucoup de personnalisation. Il serait possible de définir une sélection de fonctions et de permettre aux tweakers de les composer pour créer les rappels de l'approche précédente, mais sans leur permettre d'en définir de nouvelles. Ou peut-être que vous sautez la partie de composition et offrez simplement une sélection finie.

Les détails de toutes ces approches et celle qui correspond à votre cas d'utilisation dépendent du type de jeu de base que vous souhaitez créer et du contrôle que vous souhaitez abandonner. Notez que les jeux commerciaux n'utilisent généralement que les deuxième et troisième méthodes car la première permet aux joueurs de créer des jeux entièrement séparés, ce qui introduit des problèmes de licence complexes. Notez que ces approches formant un continuum, la deuxième approche peut également introduire ces problèmes.

Il est absolument possible de séparer les règles du système du code qui applique ces règles. Je préfère structurer mon code de cette façon pour les projets complexes, car cela facilite l'ajout de nouvelles règles ou la modification des règles plus tard sans introduire de bogues dans le système sous-jacent. Et les bogues dans un moteur de règles sont détectés plus rapidement que les bogues dans un système où les règles et les autres codes sont mélangés entre eux, car le même moteur de règles est utilisé à plusieurs reprises par chaque règle.

Que cela en vaille la peine dépend de la complexité du système. Comme si je ne m'embêterais pas pour Pac-Man, mais je ne pouvais pas imaginer écrire Dwarf Fortress autrement.

C'est définitivement faisable. Si cela en vaut la peine, cela dépend de vos objectifs.

Vous n'avez pas besoin d'inventer votre propre langage ou d'écrire un compilateur pour que cela fonctionne.

Si vous voulez que votre jeu soit facilement extensible, c'est probablement une bonne idée d'y aller.

C'est probablement plus de travail pour vous, au moins à court terme, pour créer des systèmes compréhensibles et rendre les choses faciles à modifier.

Un jeu qui fait cela est Rimworld (je n'ai aucune affiliation) et vous pourriez voir et apprendre de la façon dont ils l'ont fait, en mettant essentiellement beaucoup de données de jeu et de mécanismes dans des fichiers XML qui sont dans les dossiers de jeu pour que quiconque puisse les voir et modifier. Le cœur / moteur du jeu a été créé avec Unity.

Il y a aussi la possibilité d'étendre le jeu plus loin / plus profondément par le codage réel, j'en sais moins à ce sujet mais vous pouvez en apprendre en consultant le forum des mods.

La possibilité de modding rend le jeu plus intéressant pour beaucoup de gens et je pense qu'il a beaucoup contribué à son succès. Cela permet également aux développeurs d'apporter tout le contenu de mod qu'ils souhaitent dans le jeu de base et d'une manière qui accélère le développement et améliore le jeu car ils obtiennent l'aide de beaucoup de gens, et ils peuvent décider de prendre les choses en fonction de ce qui est populaire, ce qui semble fonctionner, etc.

Et bien sûr, en particulier pour un petit studio indépendant, ils ont des centaines de personnes qui proposent des idées et les testent, ce qui représente beaucoup de travail qu'ils ne pouvaient pas faire eux-mêmes, ni probablement embaucher des gens pour le faire.

Vous voudrez peut-être examiner la conception orientée objet . Python a un bon support pour cela.

Des livres épais sont écrits à ce sujet, ce qui peut être effrayant lorsque vous êtes nouveau, mais les principes fondamentaux sont assez faciles.

L'essentiel est simplement d'identifier le type d'objets avec lesquels vous travaillez. Vous ne dites pas à quel genre de jeu vous pensez, mais des choses comme le joueur, le monstre, l'objet, l'équipement, l'arme, l'armure et ainsi de suite sont des objets typiques.

Si vous voulez différents types de jeu, vous voudrez probablement un objet de jeu qui prend en charge la condition de victoire et autres. Peut-être aussi un objet Map?

Parfois, il n'est pas clair si quelque chose mérite d'être un objet ou non, par exemple des dommages. Si vous n'endommagez pas un objet, le code sera plus simple, mais en faire un objet le rendra plus facile à personnaliser.

Sous -classement : les armes et les armures sont des équipements. Les équipements sont des articles. Il existe probablement d'autres types d'articles. Vous trouverez probablement utile de définir un combattant de classe dont les joueurs et les monstres sont des sous-classes.

L'idée est que, par exemple, les armes auront beaucoup de choses en commun avec tous les autres types d'objets, elles ont un poids, une taille et d'autres propriétés comme ça.

Ainsi, le sous-classement vous permet de dire que "les armes sont comme les autres objets, mais en plus vous pouvez les manier, elles affectent les dégâts que vous faites, etc."

Le sous-classement permet également à vos constructeurs de mod de dire "Mon nouveau type d'arme est comme les armes standard, sauf que ..."

Ensuite, vous devez décider quel objet est responsable de quoi. Ce n'est pas aussi facile qu'il y paraît et vous devriez y réfléchir. Faire les mauvais choix n'affectera pas beaucoup le jeu de base, mais il sera plus difficile à personnaliser.

Tant que vous bricolez vous-même, vous pouvez changer les choses, mais au moment où vous publiez quelque chose au public, faire des changements devient beaucoup plus difficile! Les gens feront des mods qui dépendent des choses comme elles sont maintenant. Même des bugs. Les gens écriront des mods qui dépendent des bogues restant dans le code. Si vous changez les choses, ces mods se briseront et des monstres de lynchage apparaîtront chez vous.

Par exemple:

Un joueur brandissant une arme attaque un monstre portant plusieurs armures. Cela a lieu dans un mode de jeu particulier et sur une certaine carte.

Les deux combattants peuvent avoir des compétences comme Coup critique et Esquive.

Maintenant, quel objet est responsable de quoi?

Il n'y a pas de bonne réponse à cela. Cela dépend beaucoup du type de personnalisation que vous souhaitez autoriser.

Si vous n'appelez jamais un objet (par exemple la carte), cet objet ne peut en aucun cas modifier l'attaque.

Après avoir pris toutes ces décisions, documentez-les . Écrivez un "manuel Modders" qui répertorie exactement quelles méthodes moddables chaque objet possède, quels paramètres ils prennent, ce qu'ils doivent renvoyer, et ainsi de suite et ainsi de suite ...

Bonne chance!

Un moyen simple d'obtenir un support de base pour cela serait de séparer la plupart des valeurs numériques dans un ou plusieurs fichiers texte distincts pour permettre aux personnes intéressées de les modifier dans l'oubli.

Par exemple, vous avez mentionné les jeux de table; si vous aviez un jeu basé sur D&D, vous pourriez avoir un weapon_damagefichier contenant des lignes comme Battleaxe: 1d12. Votre code utilitaire lirait ce fichier et chaque fois que des dommages étaient causés par Battleaxevotre code le ferait generate a number from 1-12, 1 time(s)et les ajouterait. Ajuster la ligne pour lire Battleaxe: 4d6serait à la place generate a number from 1-6, 4 time(s)et les ajouter. De même, vous pourriez avoir un dossier Creatureset à l'intérieur vous avez un fichier pour chaque créature, y compris des lignes comme AC: 12; puis ajouter de nouveaux fichiers dans ce dossier créerait de nouvelles créatures. Cela pourrait même être fait pour des classes de personnages, des types de terrain, une tonne de choses.

Ce style de personnalisation non-code peut toujours être très puissant et couvrir de nombreuses parties de votre jeu. Cependant, cela ne permet pas vraiment à un utilisateur d'apporter des modifications que vous n'avez pas explicitement spécifiées. Par exemple, vous pouvez permettre Sneak Attack: [damage]à n'importe quelle créature ou classe d'être ajoutée [damage]à n'importe quelle attaque qui remplit les conditions d'une attaque sournoise. Vous pouvez même proposer des moyens de modifier les conditions, telles que "chaque fois que vous attaquez furtivement" ou "chaque fois que vous flanquez" ou "chaque fois que vous avez un avantage". Cependant, si un utilisateur décide qu'il souhaite que les attaques furtives soient "Lorsque vous effectuez un jet d'attaque, vous pouvez également lancer furtivement contre la perception de la cible. Si les deux jets réussissent, ajoutez les dégâts d'attaque sournoise"

Si vous vouliez qu'un utilisateur puisse ajouter un comportement complètement nouveau au jeu sans avoir besoin de compétences de codage au même niveau que le développeur, alors comme les gens l'ont mentionné, vous envisagez de créer essentiellement un moteur de jeu ou un langage de programmation distinct. Pour les modifications qui ne nécessitent pas de connaissances en codage, les fichiers de données textuels et les structures de dossiers peuvent toujours fournir de nombreuses options. Si vous souhaitez que les utilisateurs modifient plus que cela, vous devrez leur demander d'apprendre ou de connaître un langage de programmation.

[Je suis un développeur de logiciels depuis des décennies, mais sans expérience en développement de jeux, alors peut-être que l'industrie des jeux adopte des approches différentes, peut-être pour de bonnes raisons ...]

Votre approche est absolument logique pour moi. Le noyau fournit les fonctionnalités de base sur lesquelles la mécanique et les règles s'appuient, c'est donc une API qui doit être utilisée par les composants de niveau supérieur.

Et lors de la conception d'une API, ma directive préférée est de créer le langage dans lequel vous souhaitez exprimer votre code de niveau supérieur (bien sûr, avec les limitations de syntaxe de votre langage de programmation).

Donc, une bonne approche serait d'écrire des règles et des mécanismes hypothétiques exactement comme vous aimeriez qu'ils soient exprimés (avec la syntaxe de Python, bien sûr), trouvant ainsi ce que vous voulez que l'API de base fournisse aux règles et aux mécanismes couches.

Et bien sûr, je recommanderais de jeter un œil aux fonctionnalités de script des jeux existants pour avoir une idée de ce qu'ils font.