Dictionnaire des noms communs pour les objets de code [fermé]

16

Je recherche un dictionnaire commun de termes (tout comme les modèles de conception ont un langage commun pour la façon dont les choses interagissent) qui sont spécifiques aux jeux.

Par exemple, si je fais un jeu de pong avec un haut niveau de complexité, je veux nommer les choses en conséquence.

J'ai vu des objets visuels avec lesquels un utilisateur peut interagir appelés widgets , d'autres non interactifs appelés doodad (quand je jouais avec l'éditeur de cartes Starcraft de toute façon). Y a-t-il un nom propre pour l'horloge de fréquence d'images? Y a-t-il un nom propre pour l'horloge de jeu (l'horloge qui concerne le mouvement des objets dans le monde mais pas le dessin visuel)?

Je veux juste un dictionnaire pour pouvoir parler la même langue et ne pas inventer les choses au fur et à mesure. Je crains de créer des choses appelées doodads, whosits, whatsists et flim-flams ... et je ne veux pas faire ça.

Incognito
la source

Réponses:

17

Ces noms varient selon la région, l'entreprise et le développeur. La plupart d'entre eux sont constitués et ne sont souvent que des synonymes de «chose».

Créez des noms qui décrivent le but du code. Une horloge de fréquence d'images est appelée horloge de fréquence d'images. Il n'y a pas de dictionnaire pour ces choses. Vous ne pouvez pas avoir de dictionnaire si les objets que vous décrivez n'ont pas de définition ferme. Les objets utilisés dans le développement de jeux changent d'un jeu à l'autre. Cela dépend du jeu en cours de développement pour savoir quelles fonctionnalités doivent être implémentées. Les objets créés sont souvent spécifiques à ce jeu. Appelez-les simplement ce qui a du sens.

MichaelHouse
la source
4

Je suppose que ce que vous demandez est un glossaire pour le côté programmation du développement de jeux. Je ne pense pas qu'il existe, ce qui est certainement dommage.

Soit dit en passant, un widget est un terme issu du développement de l'interface graphique. Je n'ai jamais entendu le terme doodad auparavant dans un contexte technique.

Kylotan
la source
2

La littérature peut être votre meilleure source d'informations si vous voulez trouver les termes généralement acceptés pour les choses de développement de jeux. Une bonne référence pour cela pourrait être IntroGameDev.com , ce n'est pas un dictionnaire mais il devrait vous donner un point de départ.

Laurent Couvidou
la source
1

À des fins strictement d'interface utilisateur (éléments interactifs), le contrôle et le widget sont très courants. Les composants deviennent également populaires, bien que cela soit source de confusion pour les systèmes d'objets de jeu fréquemment basés sur les composants d'aujourd'hui. L'utilisation de classes comme UIControl ou l'utilisation d'espaces de noms est une bonne idée pour identifier clairement ce que vous voulez dire.

Pour les objets du jeu, le terme le plus général est Objet de jeu. Ce sont souvent toutes des entités dans le code, mais GameObject ou même GO ne sont pas rares. Les moteurs de jeu strictement 2D appellent parfois tous les objets du jeu Sprite, ce qui est un peu inexact, mais fonctionne.

Dans la mesure du possible, nommez les objets en fonction de ce qu'ils sont ou de ce que vous faites, et non d'un synonyme court intelligent. Dans le pire des cas, si vous choisissez un mauvais nom et utilisez un langage adapté aux grands projets, il est trivial de renommer simplement vos classes et vos instances si vous décidez qu'un nom est trop déroutant.

Vraiment, la cohérence interne de votre propre projet est plus importante. Tant que vous utilisez des styles et des conventions de dénomination de manière cohérente et que vous documentez le but de tout, tout ira bien. Peu importe si vous appelez chaque objet de jeu un PeaPod (évidemment un nom idiot) tant que vous documentez clairement dans votre manuel de démarrage et les références de support ce qu'est un PeaPod. Tant que le nom n'est pas tout à fait trompeur (n'appelez pas votre objet maillage rendu un PhysicalBody par exemple car cela implique de la physique plutôt que des graphiques).

Sean Middleditch
la source