Fouten vermijden als spelprogrammeur - dummies

U kunt maak ongeveer 10 miljard algemene fouten wanneer je een spel schrijft en nog eens 100 miljard technische fouten. Hier zijn enkele veelvoorkomende fouten die het spectrum van game-ontwikkeling overspannen.

Een slechte deal maken

(Als u intern schrijft, financiert, distribueert, marketing, verkoopt en test, is dit specifieke advies niet op u van toepassing.)

De kans is groot dat je een of meer andere partijen gaat betrekken bij de ontwikkeling van je spel. Misschien gaat een andere partij het financieren of distribueren. Hoe dan ook, laat je niet uitbuiten. Dit is makkelijker gezegd dan gedaan, maar uiteindelijk maakt een slechte deal iedereen ongelukkig.

Als je spel 15 maanden nodig heeft om te maken, dan heb je 15 maanden nodig; dat is alles wat er is. Als je $ 50, 000 of $ 1 nodig hebt. 5 miljoen, dan is dat wat je nodig hebt. Als je het spel in een korter tijdsbestek of voor minder geld maakt, is het gegarandeerd dat het spel vreselijk is, het niet zal verkopen en iedereen met zijn vingers naar je wijst! Dus als je een financiële deal maakt - marketing, verkoop of distributie - verdien je een goede deal of heb je er spijt van!

In de regel duurt een 2-D-game tussen zes en negen maanden om te voltooien en kost het ongeveer $ 100.000 voor commerciële kwaliteit. Een 3D-spel heeft een onbeperkte bovengrens, maar 15 maanden en $ 750.000 is de absolute ondergrens voor elk kwaliteitsspel.

Vergeten om een ​​back-up van uw werk te maken

U hebt 1 miljoen regels C ++ -code in 50 modules en het zit allemaal op één harde schijf. Je hebt er 6 maanden aan gewerkt en - knal - er is een brand, een overval, een gekke eenmalige significante andere, of een crash met een harde schijf die alles vernietigt. Hoewel de kans dat deze gebeurtenissen plaatsvinden klein is (behalve misschien voor die met de gekke voormalige significante andere), is een op de miljoen nog steeds een te grote kans om rustig te slapen. Zorg er dus voor dat u dagelijks een back-up van uw werk maakt op tape, Iomega ZIP-diskette, CD-ROM of een externe server.

Ontbrekende kerst

Mis geen kerst als je een spel gaat schrijven dat op enig moment tijdens het laatste deel van het jaar wordt uitgebracht. De beste gok is om de game uiterlijk in oktober of november af te hebben. Als het spel shareware is, is de tijd van uitgave niet zo belangrijk. Mensen lijken echter altijd meer in een bestedende bui rond de feestdagen te zijn, dus schiet niet op Arbor Day of een andere minder-dan-winstgevende tijd.

Niet goed testen

U hebt zojuist een geweldig spel geschreven en het werkt geweldig op uw computer.Wel, wat dan? Je kunt het maar beter testen op een aantal verschillende machines - en laat andere mensen het ook testen - omdat je waarschijnlijk (onbewust) te gemakkelijk bent in je spel wanneer je het test.

Als je een spel maakt met één probleem, zullen mensen het uit de proportie blazen. Een enkele pixel op zijn plaats verandert binnen 24 uur in "een slechte videostuurprogramma" op internet. Zorg er daarom voor dat je je game bètatest op een aantal machines met verschillende configuraties. Als u geen toegang hebt tot 20 tot 30 computers (zoals iedereen), neemt u uw spel op een schijf of CD naar de dichtstbijzijnde computerwinkel en probeert u de game uit op hun computer. Als iemand je vraagt ​​wat je doet, vertel hem dan gewoon dat je erover denkt om een ​​paar computers te kopen, en je wilt zien of deze game compatibel is - tenzij je natuurlijk deze reactie wilt gebruiken: "Ik ben een winkelklant. Als u uw kaarten goed speelt, zal ik u niet opschrijven. "

Als je het niet leuk vindt om te doen alsof je James Bond bent, kun je in een computerlaboratorium van een lokale school waarschijnlijk je spel uitproberen tijdens de daluren. Maar doen alsof ze James Bond - of Jane Bond - is, is leuker.

Gebruik van oude technologie

We zijn niet allemaal miljonairs, maar het gebruik van oude technologie en oude manieren loont niet. Probeer zoveel mogelijk up-to-date te blijven. Zelfs als je het je niet kunt veroorloven om de nieuwste C / C ++ -compiler of de beste 3D-modeler te downloaden, weet je tenminste dat ze bestaan. Misschien kunt u het bedrijf vragen om een ​​demoversie of evaluatie-eenheid. Excuses echter, gameontwikkeling is een hightech bedrijf en je moet zo actueel mogelijk zijn.

Schrijven voor DOS

DOS is dus dood; het is al eeuwen dood. Spelprogrammeurs gebruikten het omdat een beter alternatief niet beschikbaar was. Als u dit artikel leest, weet u dat Win32 met DirectX beter is. Als je een professioneel spel maakt, schrijf dan niet eens voor DOS. Als u echter een shareware-game maakt en u een eenvoudig ontwerp wilt gebruiken, is DOS in orde. DOS is goed voor leerdoeleinden, maar als je kunt schrijven voor Windows. Als je een DOS-versie voor oudere computers wilt maken, voel je dan vrij - maar Windows was beter voor spelprogrammering sinds DirectX in beeld kwam.

Liegen voor het publiek

Het publiek is brutaal. Het ene moment houden ze van je en zien al je films; het volgende is al het werk dat je kunt krijgen in een advertentie voor kauwgom. Lieg niet - overdrijf, maar lieg niet. Je kunt het publiek en de critici beter tegenhouden en de sokken uitblazen dan je spel zodanig te hypeen dat de verwachtingen van iedereen te hoog zijn en ze in de steek zullen worden gelaten.

Advertenties negeren

Als u een voormalig medewerker van Atari bent, leest u dit aandachtig: Producten verkopen zichzelf niet. Als u wilt dat uw game wordt verkocht, moet u op de een of andere manier adverteren. Als u de game zelf aan het vermarkten bent, maakt u een eenvoudige website en krijgt u wat interesse. Wanneer je ongeveer een tot twee maanden na de release bent, begin je met het verzenden van bèta's naar gamesites.Wanneer je eindelijk klaar bent om je game te lanceren, ga dan helemaal uit. Upload het handmatig naar honderden sites of met een internetspider of -bot om het spel helemaal op zijn plek te zetten en laat mensen tenminste weten dat het bestaat. Te veel koks toestaan ​​in de keuken

Voor sommige klussen is meer niet beter. Wanneer u hulp van anderen nodig heeft, betrek er dan niet te veel mensen bij. Voeg geen mensen toe aan het project omdat ze vrienden zijn of als ze denken dat de ontwikkeling van games cool is. Breng alleen getalenteerde, toegewijde mensen aan die u vertrouwt en die aan het project willen werken. En hoe minder mensen aan spelcode werken, hoe beter de game zal zijn.

Reacties in uw code weglaten

Werken met code die onvoldoende wordt becommentarieerd, is een nachtmerrie. Reageer je spelcode met minimaal één commentaar per regel. Bijna niemand kan zo snel programmeren als hij of zij kan typen voor een langere periode, wat betekent dat je altijd tijd hebt om opmerkingen toe te voegen. En als je ooit een licentie wilt of een nieuwe versie van je spel wilt maken, heb je geen Vulcan-tolk nodig om erachter te komen wat je aan het doen was met de originele code!