Undgå fejl som spilprogrammerer

Du kan lav omkring 10 milliarder generelle fejl, når du skriver et spil og en anden 100 milliarder tekniske fejl. Her er nogle almindelige fejl, der spænder spekteret af spiludvikling.

Gør en dårlig aftale

(Hvis du skriver, finansierer, distribuerer, markedsfører, sælger og tester dit spil internt, gælder dette særlige råd ikke for dig.)

Chancerne er gode at du vil involvere en eller flere andre parter i udviklingen af dit spil. Måske vil en anden part finansiere den eller distribuere den. Uanset om du ikke må udnytte dig selv. Dette er lettere sagt end gjort, men i sidste ende gør en dårlig aftale alle ulykkelige.

Hvis dit spil skal tage 15 måneder at lave, så har du brug for 15 måneder; det er alt der er til det. Hvis du har brug for $ 50, 000 eller $ 1. 5 millioner, så er det hvad du har brug for. Hvis du laver spillet i en kortere tidsramme eller for mindre penge, er det garanteret at spillet bliver forfærdeligt, det vil ikke sælge, og alle vil pege på fingrene på dig! Så når du laver nogen form for økonomisk aftale - markedsføring, salg eller distribution - gør en god handel, eller du vil være ked af det!

Som regel tager et 2-D-spil mellem seks og ni måneder at fuldføre og koster omkring $ 100.000 for kommercielt niveau kvalitet. Et 3-D spil har en ubegrænset øvre grænse, men 15 måneder og $ 750.000 er den absolutte lavere grænse for ethvert kvalitetsspil.

Glemmer at sikkerhedskopiere dit arbejde

Du har 1 million linjer af C ++-kode i 50 moduler, og det sidder alle på en harddisk. Du har arbejdet på det i 6 måneder og - bang - der er en brand, et røveri, en skør engangs signifikant anden eller et harddiskkrasj, der ødelægger alt. Selv om sandsynligheden for, at disse hændelser sker, er slank (bortset fra måske for den der involverer den skøre tidligere signifikante anden), er en i en million stadig for stor for en chance for at sove fredeligt. Så sørg for at du sikkerhedskopierer dit arbejde dagligt på bånd, Iomega ZIP-disk, cd-rom eller en fjernserver.

Manglende jul

Hvis du skal skrive et spil, der vil blive frigivet når som helst i løbet af sidste halvdel af året, gå ikke glip af julen. Din bedste chance er at få spillet færdigt senest oktober eller november. Hvis spillet er shareware, er frigivelsestidspunktet ikke så vigtigt. Men folk ser altid ud til at være mere til at bruge humør i løbet af ferien, så tag ikke for Arbor Day eller en anden mindre end rentabel tid.

Undlader at teste korrekt

Du har lige skrevet et dræberspil, og det fungerer godt på din computer.Nå, hvad så? Du havde bedre test det på en række forskellige maskiner - og lad andre også teste det - fordi du formentlig (ubevidst) er for nem på dit spil, når du tester det.

Hvis du laver et spil, der har et enkelt problem, vil folk blæse det ud af proportioner. En enkelt pixel ud af stedet bliver til "en dårlig video driver" på internettet inden for 24 timer. Derfor skal du sørge for, at du tester dit spil på en række maskiner med forskellige konfigurationer. Hvis du ikke har adgang til 20 til 30 computere (som alle gør), skal du tage dit spil på en disk eller cd til nærmeste computerforretning og prøve spillet ud på deres computere. Hvis nogen spørger dig, hvad du laver, skal du bare fortælle dem, at du tænker på at købe nogle computere, og du vil se om dette spil er kompatibelt - medmindre du selvfølgelig vil bruge dette svar: "Jeg er en butikshopper. Hvis du spiller dine kort rigtigt, vil jeg ikke skrive dig op. "

Hvis du ikke kan lide at foregive at være James Bond, vil en lokal skoles computervidenskabslaboratorium sandsynligvis give dig mulighed for at prøve dit spil i spidsbelastningstider. Men foregiver at være James Bond - eller Jane Bond - er sjovere.

Brug af gammel teknologi

Vi er ikke alle millionærer, men bruger gammel teknologi og gamle måder betaler ikke. Prøv at holde dig opdateret så meget som muligt. Selvom du ikke har råd til at få den nyeste C / C ++-kompilator eller den bedste 3-D-modeler, ved du i hvert fald, at de eksisterer. Måske kan du bede virksomheden om en demoversion eller en evalueringsenhed. Men alle undskyldninger til side er, at spiludvikling er en højteknologisk forretning, og du skal være så opdateret som muligt.

Skrivning til DOS

DOS er så død; det har været død i årevis. Spilprogrammører brugte det, fordi et bedre alternativ ikke var tilgængeligt. Hvis du læser denne artikel, ved du, at Win32 med DirectX er bedre. Hvis du laver et professionelt spil, ikke engang genere skrivning til DOS. Men hvis du opretter et shareware-spil, og du vil bruge et simpelt design, så er DOS okay. DOS er godt til læringsformål, men hvis du kan, skriv til Windows. Hvis du vil lave en DOS-version til ældre computere, er du velkommen - men Windows har været bedre til spilprogrammering, da DirectX kom ind på billedet.

Ligger for offentligheden

Offentligheden er brutal. Et minut elsker de dig og ser alle dine film; Det næste er alt det arbejde du kan få, i en annonce for tyggegummi. Må ikke lyve - overdrive, men lyv ikke. Bedre at holde tilbage og blæse sokkerne ud af offentligheden og kritikerne end at hype dit spil til det punkt, at alles forventninger er for høje, og de bliver slået ned.

Forsigtig at annoncere

Hvis du er en tidligere medarbejder hos Atari, læs venligst dette omhyggeligt: Produkter sælger ikke selv. Hvis du vil have dit spil at sælge, skal du annoncere på en eller anden måde. Hvis du selv markedsfører spillet, skal du oprette et simpelt websted og få interesse. Når du er omkring en til to måneder fra udgivelsen, skal du begynde at sende betas til spilwebsteder.Når du endelig er klar til at frigive dit spil, gå alt ud. Upload det til hundredvis af websteder manuelt eller med en internet-edderkop eller bot for at sætte spillet overalt og i det mindste lade folk vide, at det eksisterer. Tillade for mange kokke i køkkenet