Éviter les erreurs en tant que programmeur de jeu

Vous pouvez faire environ 10 milliards erreurs générales lorsque vous écrivez un jeu et un 100 milliards d'autres erreurs techniques. Voici quelques erreurs courantes qui couvrent le spectre du développement de jeux.

Faire une mauvaise affaire

(Si vous écrivez, le financement, la distribution, le marketing, la vente, et de tester votre jeu en interne, ce conseil particulier ne vous concerne pas.)

Les chances sont bonnes que vous allez impliquer un ou plusieurs autres parties dans le développement de votre jeu. Peut-être une autre partie va financer ou de le distribuer. Quoiqu'il en soit, ne vous laissez pas être exploitées. Cela est plus facile à dire qu'à faire, mais à la fin, une mauvaise affaire rend tout le monde malheureux.

Si votre jeu va prendre 15 mois à faire, alors vous avez besoin de 15 mois- que tout y est pour elle. Si vous avez besoin de 50.000 $ ou 1,5 million $, alors que ce que vous avez besoin. Si vous faites le jeu dans un laps de temps plus ou moins pour moins d'argent, il est garanti que le jeu va être terrible, il ne se vendra pas, et tout le monde va pointer leurs doigts à vous! Alors, quand vous faites tout type d'accord financier - le marketing, les ventes, ou de la distribution - faire une bonne affaire ou vous serez désolé!

En règle générale, un jeu 2-D prend entre six et neuf mois pour terminer et coûte environ 100 000 $ pour la qualité de niveau commercial. Un jeu 3-D a une limite supérieure illimitée, mais 15 mois et 750 000 $ est la limite inférieure absolue pour tout jeu de qualité.

Oublier de sauvegarder votre travail

Vous avez 1 millions de lignes de code C de dans 50 modules, et il est tout assis sur un disque dur. Vous avez travaillé sur elle pendant 6 mois et - BANG - il ya un incendie, un vol, un fou ponctuel autre significatif, ou un crash de disque dur qui détruit tout. Bien que la probabilité de ces événements qui se déroulent est mince (sauf peut-être pour la première impliquant l'ancien significative autre fou), un sur un million est toujours trop de chance pour vous de dormir paisiblement. Donc, assurez-vous de sauvegarder votre travail quotidien sur bande, disque Iomega ZIP, CD-ROM, ou un serveur distant.

Noël manquant

Si vous allez écrire un jeu qui va être libéré tout moment au cours de la dernière partie de l'année, ne manquez pas de Noël. Votre meilleur pari est d'avoir terminé le jeu en Octobre ou Novembre au plus tard. Si le jeu est un shareware, l'heure de la libération est pas si important. Cependant, les gens semblent toujours être dans plus d'une humeur à dépenser autour des vacances, alors ne tirez pas pour Arbor Day ou un moment autre moins-que-rentable.

A défaut de tester correctement

Vous venez d'écrire un jeu de tueur, et il fonctionne très bien sur votre ordinateur. Eh bien, alors? Vous feriez mieux de le tester sur un certain nombre de machines différentes - et de laisser d'autres personnes le tester, ainsi - parce que vous êtes probablement (inconsciemment) trop facile sur votre jeu quand vous le tester.

Si vous faites un jeu qui a un seul problème, les gens vont sauter hors de proportion. Un seul pixel hors de l'endroit se transforme en "un pilote vidéo mauvais» sur Internet dans les 24 heures. Par conséquent, assurez-vous que vous beta tester votre jeu sur un certain nombre de machines avec des configurations différentes. Si vous ne disposez pas d'un accès à 20 à 30 ordinateurs (comme tout le fait), puis prenez votre jeu sur un disque ou CD au magasin le plus proche de l'ordinateur et essayer le jeu sur leurs ordinateurs. Si quelqu'un vous demande ce que vous faites, juste leur dire que vous songez à acheter des ordinateurs, et vous voulez savoir si ce jeu est compatible - à moins, bien sûr, vous voulez utiliser cette réponse: «Je suis un client du magasin. Si vous jouez vos cartes à droite, je ne vais pas vous écrire jusqu'à ".

Si vous ne voulez pas faire semblant d'être James Bond, le laboratoire d'informatique de l'école locale sera probablement vous permettre d'essayer votre jeu pendant les heures creuses. Mais faire semblant d'être James Bond - ou Jane Bond - est plus amusant.

En utilisant l'ancienne technologie

Nous ne sommes pas tous des millionnaires, mais en utilisant la vieille technologie et les anciennes façons ne paie pas. Essayez de garder à jour autant que possible. Même si vous ne pouvez pas vous permettre d'obtenir le dernier C / C ++ ou le meilleur modeleur 3-D, au moins vous savez qu'ils existent. Peut-être que vous pouvez demander à la compagnie pour une version de démonstration ou une unité d'évaluation. Cependant, toutes les excuses de côté, le développement de jeux est une entreprise high-tech, et vous devez être le plus à jour possible.

Ecrire pour DOS

DOS est ainsi date limite, il est mort depuis les âges. Programmeurs de jeu utilisé car une meilleure alternative était pas disponible. Si vous lisez cet article, vous savez que Win32 avec DirectX est mieux. Si vous faites un match professionnel, même pas la peine d'écrire pour DOS. Cependant, si vous créez un jeu de shareware et que vous voulez utiliser une conception simple, puis DOS est correct. DOS est bon pour des fins d'apprentissage, mais, si vous pouvez, écrire pour Windows. Si vous voulez faire une version DOS pour les ordinateurs plus anciens, se sentir libre - mais Windows a été mieux pour la programmation de jeux depuis DirectX est entré en scène.

Allongé au public

Le public est brutale. Une minute ils vous aiment et voir tous vos Films et la prochaine, tout le travail que vous pouvez obtenir est dans une publicité pour la gomme à mâcher. Ne mentez pas - exagérer, mais ne pas mentir. Mieux vaut retenir et de faire sauter les chaussettes au large du public et des critiques à l'exagération que votre jeu au point que les attentes de chacun sont trop élevés, et ils vont être déçus.

Négliger de publicité

Si vous êtes un ancien employé d'Atari, s'il vous plaît lire attentivement: Produits ne se vendre. Si vous voulez que votre jeu à vendre, vous devez faire de la publicité d'une certaine façon. Si vous êtes à la commercialisation du jeu vous-même, mis en place un site Web simple et obtenir un certain intérêt en cours. Lorsque vous êtes sur un à deux mois à compter de la libération, commencer à envoyer des bêtas à des sites de jeu. Lorsque vous êtes enfin prêt à libérer votre jeu, passer tout de go. Ajouter à des centaines de sites manuellement ou avec une araignée ou un robot Internet pour mettre le jeu dans tous les sens et au moins laisser les gens savent qu'il existe.

Permettre trop de cuisiniers dans la cuisine

Pour certains emplois, plus est pas mieux. Lorsque vous avez besoin d'aide des autres, ne comportent pas trop de gens. Ne pas ajouter des personnes au projet parce qu'ils sont amis, ou ils pensent que le développement du jeu est cool. Seulement amener les gens talentueux et dévoués qui vous avez confiance et qui veulent travailler sur le projet. Et les moins de gens qui travaillent sur le code du jeu, plus le jeu sera.

L'omission des commentaires dans votre code

Travailler avec le code qui est insuffisamment commenté est un cauchemar. Commentaire de votre code de jeu avec au moins un commentaire par ligne. Presque personne ne peut programmer aussi vite qu'il ou elle peut taper pour une période prolongée, ce qui signifie que vous avez toujours le temps pour ajouter des commentaires. Et si jamais vous souhaitez obtenir une licence ou de faire une nouvelle version de votre jeu, vous ne serez pas besoin d'un interprète Vulcan de comprendre ce que vous faisiez avec le code original!