Conseils de développement de jeux 3D (en particulier l'architecture de jeu)

Question

tl;dr version: Quel est le meilleur conseil (que vous avez appris par l'expérience et non pas de livres) que vous pouvez me donner, en ce qui concerne le jeu en 3D de l'architecture? (comme dans la façon de concevoir et de connecter les composants d'un jeu en 3D)

---

Quand il s'agit de la programmation, il ya seulement tellement que vous pouvez apprendre dans les livres. Il me semble, beaucoup de choses apprises sont tirées d'autres personnes, ou par l'expérience. Même l'apprentissage de quelque chose dans une salle de classe a ses avantages par rapport à d'ouvrages; le professeur peut glisser dans une petite friandise de la connaissance qu'il a appris de son expérience, et il peut faire toute la différence.

Je suis à la recherche de ces friandises ici.

Livres sur le développement du jeu n'ira pas très loin. Il y a une grande différence à propos d'un livre qui explique la logique et la syntaxe d'un langage de programmation, et un livre qui essaie de vous dire comment faire un jeu. Ce dernier ne fonctionne pas si bien (au moins pour moi); mais la première est la raison pour laquelle je suis étudiant en informatique.

Je vais dans ma deuxième année de collège, et j'ai 19 ans. Je n'ai pas d'expérience, j'ai le livre de la connaissance. Donc, je suis en train de ferroutage hors de vous et de vos connaissances que vous avez acquis de l'expérience.

Mon sujet d'actualité d'intérêt est en jeu l'architecture.

(ou "moteur de conception" si vous préférez, mais je ne cherche pas à créer un tout-mais-la-cuisine-évier moteur de jeu)

J'ai récemment posé une question, structures de Données pour la transmission de message à l'intérieur d'un programme? et il en est résulté une longue, une excellente réponse de haffax. Pour lui, il était juste débitant de son expérience et de la connaissance qu'il a acquise à partir d'elle; pour moi, il m'a donné beaucoup de nouvelles choses à penser que je n'avais jamais lu dans un livre avant, et n'ai pas vécu pour moi-même. Aller voir la réponse, et si vous le souhaitez.

À partir de cela, je pensais plus au sujet de la transmission de message à l'intérieur d'un programme. J'ai pensé à la façon dont peut-être MVC n'est pas un bon ajustement pour le jeu de l'architecture. Ses concepts de tous les objets du jeu étant égales par ailleurs et non pas une hiérarchie, où, au lieu d'ajouter "Caractéristiques" pour un objet de jeu, est quelque chose que je n'ai jamais entendu parler avant, et je l'aime vraiment. Et dès le début de la question qu'il a donné à de simples morceaux de conseils:

Avant de commencer à concevoir des packages et les classes, commencer par une analyse

...

Et pour la motivation, je parle d'expérience ici, ne pensez pas à votre tâche de rédaction d'un moteur de jeu, d'écriture d'un jeu!

Je veux plus de réponses comme ça.

Ce sont le jeu le plus important de l'architecture des concepts et des astuces que vous avez prises à partir de votre expérience en tant que développeur de jeu? Quand vous vous asseyez pour écrire un jeu, comment vous organisez-vous les choses? Ne vous séparez de votre vue et de votre modèle, ou pensez-vous, s'entrelacent et refactoriser plus tard? Que voulez-vous dire au sujet de l'efficacité de la MVC comme un jeu de l'architecture modèle? Comment voulez-vous garder une trace de beaucoup de choses (images, fichiers audio, de fichiers de chargement, de collision, de l'IA, réseau) et les faire travailler ensemble pour créer un fini le jeu? Comment utiliser les modèles de conception et de préserver l'orienté objet " de votre jeu? Comment écrire des tests automatisés pour votre jeu?

Je peux venir avec un million de questions, mais pour l'instant je veux juste entendre en général, quelle que soit la colle dans votre esprit. Quelles expériences avez-vous été à travers qui a changé votre façon de penser? Quelle est votre philosophie lors de l'écriture de vos jeux? Comment voulez-vous rester organisé dans la confusion et le massif-ness de la tâche de jeu en 3D pour la création?

Ce jeu de développement astuces avez-vous appris de l'expérience?

Je vous remercie de prendre le temps de lire et de répondre!!

Answer 1

1. Le reste de ma liste peut être de la merde, mais la chose la plus importante est de simplement le faire. Vous voulez l'expérience de faire des jeux, afin de faire un jeu. Faire votre objectif de terminer un jeu, pas seulement de travailler sur un jeu.

2. Démarrage simple et de faire progressivement de plus en plus complexe des jeux. Des jeux plus simples sont plus faciles à concevoir, mais il peut toujours être difficile. Les leçons que vous apprendrez vous aidera à concevoir des systèmes plus complexes. N'est-ce pas pas de honte à faire des jeux 2D ou des clones de jeux existants.

3. Suivez les Solides principes de la conception orientée objet. Vous semblez vouloir l'unité de test. De solides principes sont essentiels pour la conception testable objets.

4. Utilisez uniquement des modèles de conception pour résoudre des problèmes. Par exemple, vous pouvez être tenté d'utiliser un singleton pour un objet avec une seule instance. Avoir une seule instance d'un objet n'est pas un problème. Imaginons que vous voulez unité de tester votre logique de jeu sans votre logique d'affichage de faire quoi que ce soit, alors MVC permet de résoudre votre problème.

5. Faire ce qui fonctionne pour vous. - Je suivre mes progrès avec la note de cartes disposées comme une liste de choses à faire sur mon mur. Pour une personne seule de projet, listes de tâches à faire le travail très bien.

6. Devenir amis avec des étudiants en art.

7. Trouver ou de démarrer une prise de jeu du club à votre école. Travailler ensemble pour faire des jeux simples.

8. Vieille rendu sage auteurs disent aspirant auteurs qu'ils ont à écrire un million de mots avant de pouvoir écrire une valeur de lecture. Je pense que l'adage vaut aussi pour la conception de jeu. Je ne suis pas vieux, ni rendu sage, mais je dis être prêt à la conception et dix jeux avant de vous faire l'éloge de hasard étrangers.

9. Utilisation de la source de contrôle. Je suis un grand fan de Mercurial à l'aide de la TortoiseHG client.

Answer 2

Voici quelques observations que je peux faire basé sur deux mois d'étude, de conception, de codage et sur le matière de jeu, architecture du moteur seul:

• Le moteur 3D est une petite partie de l'ensemble du moteur de jeu

  • Description: Le moteur graphique crée simplement la représentation visuelle du jeu. Le moteur graphique de la fonctionnalité doit être encapsulée dans la vue de composant afin qu'il recevra seulement les événements de mise à jour de la logique de jeu à travers le gestionnaire d'événement. De cette façon, la logique du jeu ne dépend pas du moteur graphique, ce qui signifie que la logique de jeu peut être détaché et utilisé dans d'autres systèmes, par exemple. lors du portage sur différentes plates-formes.

• Le moteur de jeu est une petite partie de l'ensemble du jeu

  • Description: Le moteur de jeu est une plateforme qui permet le développement d'un jeu, mais le moteur de jeu de ne pas faire n'importe quoi. Le jeu est une construction qui vit dans la logique du jeu, qui est un composant constitué d'entités en interaction. Le jeu en lui-même nécessite sa propre conception qui n'a rien à voir avec le moteur du jeu.

• Pour faire le bon développement d'un jeu, vous devez comprendre le jeu de l'architecture

  • Description: Sans une bonne architecture de votre jeu est susceptible d'entraîner une procédure emmêlés qui pue le plus élevé de couplage. C'est ce que la plupart des jeu des exemples de programmation normalement lorsque la boucle de jeu n'a mille et une choses.
  • Solution: s'Arrêter pour une minute pour penser à la façon dont les choses devraient travailler ensemble avant de commencer à coder tout de suite.

Voici un exemple de code à partir de notre moteur de jeu (pour être publié en open source lorsque nous avons suffisamment prêts):

def tick(self, deltaTime):
  """
  Advances the game forward one tick of length deltaTime (seconds).
  """

  if self.state == K_GAME_STATE_RUNNING:
    self.processMgr.updateProcesses(deltaTime)

# end tick()

C'est la boucle de jeu (appelé tique) dans le moteur de jeu, nous sommes actuellement en développement. En cela nous nous contentons de courir à travers tous les processus actifs à la logique du jeu est. Les processus eux-mêmes une incidence sur l'état des différentes logique de jeu entités par l'envoi de différents types d'événements par le biais du gestionnaire d'événement. Nous n'utilisons pas de méthode directe pour appels dans le processus de jeu ou d'entités parce que nous voulons garder le code découplé à cet égard.

• L'objectif est de créer un jeu, pas un moteur

  • Description: Comme indiqué précédemment, vous n'avez pas beaucoup d'afficher ou de lire autour de quand vous ne disposez que d'un moteur. L'ultime but doit toujours être de créer un jeu.

• Optimiser quand il ya un problème, mais pas plus tôt.

  • Description: Quand vous vous trouvez l'optimisation de quelque chose avant il y a un problème de vous tirer une balle dans le pied en termes de productivité. Il est tellement facile de garder en surface sur une très concentré problème et d'optimiser la solution jusqu'à la perfection, mais cela ne fera que conduire à la perte de temps dans le long terme.
  • La solution: faire une remarque à propos de vos doutes et de passer à quelque chose d'autre qui a un retour sur investissement élevé.

Je suis encore un débutant dans le développement d'un jeu, cependant, mais au cours de cet été, j'ai été impliqué dans un projet où notre objectif est de créer un simple à la première personne jeu d'aventure dans le but de l'enseignement d'un cours d'initiation pratique dans le développement de jeux.

Nous avons trouvé le Jeu de Codage Complet du livre de Mike McShaffry être très utile comme un guide général et de référence pour la compréhension de la façon dont les jeux devraient être conçues pour permettre un extensible et très découplé de la conception.

Je ne peux pas recommander ce livre plus. Si le moteur de jeu de l'architecture est votre point fort, et l'un quelconque de ces points ci-dessus en résonance avec vous, je vous suggère au moins prendre un coup d'oeil. J'ai le sentiment que vous l'aimerez beaucoup et apprendre des tonnes de lui.

Voici un extrait du livre (Chapitre 19, pg. 739):

"Je suis sûr que vous le savez, le Jeu de Codage Complète est vraiment une architecture livre qui des peintures de grands traits au travers d'un vaste éventail d'outils et de technologies qui composent les professionnels des jeux d'ordinateur. L'une des observations à propos de la première édition de ce livre, et je suis sûr de cela, est que le livre ne permet pas de couvrir chaque sujet rigoureux détail, complètement exposant de chaque bit. Qui était par sa conception, pas de fiat."

"Parfois, la partie la plus difficile de l'écriture de code, c'est de savoir par où commencer. Une fois que vous obtenez commencé et construire un cadre autour d'un nouveau système, les doigts volent sur le clavier jusqu'à ce que l'engourdissement prend, et encore, vous ne vous arrêtez pas. Mon objectif avec ce livre et tous les code y était pour vous donner quelques détails intéressants, vous sauver du méchant pièges, raconter quelques histoires drôles, et couvrir plus de territoire de la programmation de jeu que je le pouvais."

"J'ai aussi donné à vous, mes chers lecteur et collègue, un endroit pour commencer."

Ma quête est de découvrir les mystères cachés derrière le moteur de jeu d'architecture et d'utiliser ces connaissances pour construire des jeux impressionnants :)

Espérons que cette réponse vous aide en quelque sorte. Je peux continuer avec plusieurs de ces points dans mon blog quand je me déplace pour l'écrire.

Answer 3

Les conseils suivants s'applique principalement aux grands jeux où vous avez des programmeurs, des artistes et des designers de tous à travailler sur un jeu. Ils ont peut-être exagéré pour une personne de faire un jeu simple sur leur propre, mais dès que vous atteignez le point d'avoir une équipe qui travaille sur le jeu, ils commencent à être importants.

• Une fonction n'est aussi complet que les outils à utiliser. C'est pas de la bonne mise en œuvre de certaines super sophistiqué technique si votre artistes ont modifier à la main un sans-papiers fichier texte pour l'utiliser. Vous obtiendrez de meilleurs résultats d'une simple fonctionnalité avec un bon outil qui permet aux artistes d'expérimenter et d'itérer rapidement que d'une fonction complexe sans le support de l'éditeur.

• Ci-dessus, l'itération temps sont essentiels pour de bons résultats. Toujours examiner comment rapidement et sans douleur les personnes qui construisent le jeu sera en mesure de faire quelques réglages et de les tester lors de la conception d'une fonction. Si il est intrinsèquement lent à faire des changements (en mode hors connexion de l'illumination globale des calculs par exemple), alors essayez de fournir de faible qualité ou localisée aperçus que de permettre à au moins une certaine quantité de rétroaction rapide itérations.

• Préfère garder de la complexité dans les outils et les pipelines et de garder le moteur d'exécution de code simple. Ceci est particulièrement important lorsque le ciblage des consoles ou plusieurs plates-formes. Si la complexité d'un morceau de code n'est nécessaire que lors de la modification d'un niveau, puis le garder hors de code du jeu. Cela signifie une plus petite empreinte de code, plus facile à porter et à moins de tests.

• La conception de votre code doit être piloté par les données. Tout ce qui peut avoir besoin d'être ajusté ou modifié doit être un paramètre qui provient de données, pas codés en dur. Cela va au-delà des choses simples, comme éviter les constantes et les mettre dans un fichier de données et s'étend à l'permettant aux concepteurs de complexes gameplay conditions dans les scripts ou à l'aide d'un visual langage de script. La conception de votre code vos données tend aussi à les aider lors de la tentative de multi-thread de systèmes et de prendre avantage de matériel de la console.

• Une légère baisse de données des moteurs est qu'ils peuvent être difficiles à déboguer. Prendre cela en considération lors de la conception de vos systèmes et de mettre en fonctionnalités supplémentaires pour vous aider à comprendre ce qui se passe lorsque des problèmes surviennent inévitablement. Vous vous remercierez plus tard.

Answer 4

Si vous êtes en train de faire quelque chose en solo, et même si vous avez un groupe, essayez d'obtenir une première itération fait dès que possible. Ce n'est pas tellement au sujet de "voir si l'idée est tout bon", ou la preuve de la notion ou de quelque chose; c'est purement de la motivation.

Si vous développez une fantastique idée parfaite, et commencer à mettre en œuvre au niveau le plus bas, il peut être des semaines/mois/années avant d'arriver à la première exécution de vos étonnamment parfait jeu. Les Unités de temps dans lequel il est facile de se laisser distraire, pour passer à d'autres projets, ou d'infiniment changer les spécifications pour le projet en cours. Avoir quelque chose en face de vous qui s'exécute permet de dire "c'est cool, mais il serait mieux si on pouvait le faire X'; et vous avez maintenant une plus forte motivation pour mettre en œuvre X.

Je dis cela pour la plupart des aquariophiles de l'expérience; donc ne pas s'appliquer intégralement à jeu en 3D de l'architecture. Bien que, comme par hasard, cette raison est pourquoi mon projet actuel (logique/backend pour un jeu en 3D) a été en attente depuis quelques mois. La malédiction de mon désir pour à la fois le sommeil et un chèque de règlement.

Answer 5

Essayez de faire de l'argent avec votre projet. Il peut sembler comme un horrible capitaliste idée, mais il est plus sage que cela. En essayant de faire de l'argent de garder votre fonction de fluage faible, il va vous pousser vers de meilleures décisions de conception, de vous forcer à garder un horaire, de vous forcer à prendre pour vous de garder une trace de vos coûts, des délais, sage, et l'argent sage. En retour, cela vous permettra de garder une meilleure vision de votre projet. Il vous fera également apprendre à "vendre" votre projet à des collaborateurs potentiels, qui sont, en un sens, les "investisseurs". Finalement, il va même jusqu'à vous le faire savoir "software assurance" (comme dans le contrôle de version, de sauvegarde, de reprise après sinistre, etc), depuis la perte du code et des ressources sur un projet que vous essayez de faire de l'argent avec est inacceptable, quand il peut être toléré sur un projet de compagnie.

Et pour faire de l'argent... vous devez le remplir.