ÉVitant les erreurs en tant que programmeur de jeu - les nuls

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

Faire une mauvaise affaire

(Si vous écrivez, financez, distribuez, faites du marketing, vendez et testez votre jeu en interne, ce conseil ne s'applique pas à vous.)

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

Si votre jeu prend 15 mois, alors vous avez besoin de 15 mois; c'est tout ce qu'on peut en dire. Si vous avez besoin de 50 000 $ ou 1 $. 5 millions, alors c'est ce dont vous avez besoin. Si vous faites le jeu dans un laps de temps plus court ou pour moins d'argent, il est garanti que le jeu sera horrible, il ne se vendra pas, et tout le monde vous pointera du doigt! Donc, quand vous faites une sorte de transaction financière - marketing, ventes ou distribution - faites une bonne affaire ou vous serez désolé!

En règle générale, un jeu en 2D prend entre six et neuf mois et coûte environ 100 000 $ pour la qualité au niveau commercial. Un jeu 3D 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 million de lignes de code C ++ dans 50 modules, et tout est assis sur un disque dur. Vous avez travaillé dessus pendant 6 mois et - bang - il y a un feu, un vol, un fou ou un accident grave qui détruit tout. Bien que la probabilité que ces événements se produisent est mince (sauf peut-être pour celui impliquant l'ancien et significatif autre), un sur un million est encore trop une chance pour que vous dormiez paisiblement. Assurez-vous donc de sauvegarder votre travail quotidiennement sur une bande, un disque ZIP Iomega, un CD-ROM ou un serveur distant.

Missing Christmas

Si vous allez écrire un jeu qui sortira à n'importe quel moment de la dernière partie de l'année, ne manquez pas Christmas. Votre meilleur pari est d'avoir terminé le jeu en octobre ou novembre au plus tard. Si le jeu est un shareware, le moment de la sortie n'est pas si important. Cependant, les gens semblent toujours être de plus en plus friands de vacances, alors ne tirez pas pour Arbor Day ou un autre moment moins 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, et alors? Vous feriez mieux de le tester sur un certain nombre de machines différentes - et de laisser d'autres personnes le tester, aussi - parce que vous êtes probablement (inconsciemment) trop facile sur votre jeu lorsque vous le testez.

Si vous créez un jeu qui a un seul problème, les gens vont le faire sauter hors de proportion. Un seul pixel déplacé se transforme en «mauvais pilote vidéo» sur Internet dans les 24 heures. Par conséquent, assurez-vous de tester votre jeu sur un certain nombre de machines avec des configurations différentes. Si vous n'avez pas accès à 20 à 30 ordinateurs (comme n'importe qui), apportez votre jeu sur un disque ou un CD au magasin d'ordinateurs le plus proche et essayez le jeu sur leur ordinateur. Si quelqu'un vous demande ce que vous faites, dites-leur simplement que vous envisagez d'acheter des ordinateurs, et vous voulez voir si ce jeu est compatible - à moins, bien sûr, que vous vouliez utiliser cette réponse: "Je suis un acheteur de magasin. Si vous jouez bien vos cartes, je ne vous écrirai pas. "

Si vous n'aimez pas faire semblant d'être James Bond, le laboratoire d'informatique d'une école locale vous permettra probablement d'essayer votre jeu pendant les heures creuses. Mais prétendre être James Bond - ou Jane Bond - est plus amusant.

Utilisation de l'ancienne technologie

Nous ne sommes pas tous des millionnaires, mais l'utilisation de l'ancienne technologie et des anciennes méthodes ne paie pas. Essayez de rester à jour autant que possible. Même si vous ne pouvez pas vous permettre d'obtenir le dernier compilateur C / C ++ ou le meilleur modeleur 3D, vous savez au moins qu'ils existent. Peut-être que vous pouvez demander à l'entreprise une version de démonstration ou une unité d'évaluation. Cependant, toutes les excuses mises à part, le développement de jeux est une affaire de haute technologie, et vous devez être aussi à jour que possible.

L'écriture pour DOS

DOS est donc morte; il est mort depuis longtemps. Les programmeurs de jeux l'ont utilisé parce qu'une meilleure alternative n'était pas disponible. Si vous lisez cet article, vous savez que Win32 avec DirectX est meilleur. Si vous faites un jeu professionnel, ne prenez même pas la peine d'écrire pour DOS. Cependant, si vous créez un jeu shareware et que vous voulez utiliser un design simple, DOS est OK. DOS est bon pour apprendre, mais si vous le pouvez, écrivez pour Windows. Si vous voulez faire une version DOS pour les ordinateurs plus anciens, n'hésitez pas - mais Windows a été meilleur pour la programmation de jeux depuis que DirectX est entré dans l'image.

Mentir au public

Le public est brutal. Une minute, ils vous aiment et voient tous vos films; le prochain, tout le travail que vous pouvez obtenir est dans une annonce pour le chewing-gum. Ne mens pas - exagère, mais ne mens pas. Mieux vaut se retenir du public et des critiques que d'exagérer le jeu au point que les attentes de chacun sont trop élevées et qu'ils seront déçus.

Négliger d'annoncer

Si vous êtes un ancien employé d'Atari, veuillez lire ceci attentivement: Les produits ne se vendent pas. Si vous voulez que votre jeu se vende, vous devez faire de la publicité d'une manière ou d'une autre. Si vous commercialisez le jeu vous-même, créez un site Web simple et suscitez de l'intérêt. Lorsque vous avez environ un à deux mois de publication, commencez à envoyer des bêtas aux sites de jeux.Quand vous serez enfin prêt à sortir votre jeu, allez-y. Téléchargez-le sur des centaines de sites manuellement ou avec une araignée Internet ou un bot pour mettre le jeu partout et au moins faire savoir aux gens qu'il existe.

Autoriser trop de cuisiniers dans la cuisine

Pour certains travaux, plus n'est pas mieux. Lorsque vous avez besoin de l'aide des autres, n'impliquez pas trop de gens. N'ajoutez pas de personnes au projet car ce sont des amis ou ils pensent que le développement de jeux est cool. N'apportez que des personnes talentueuses et dévouées en qui vous avez confiance et qui veulent travailler sur le projet. Et moins de personnes travaillent sur le code du jeu, meilleur sera le jeu.

Omettre les commentaires dans votre code

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