Hvad er en “ Gameplay-programmør ”?

Når virksomheder taler om at ansætte en gameplay-programmør , hvad de taler om er en programmør, der vil være ansvarlig for kode, der direkte berører på spiloplevelsen. Det vil sige, at programmøren er ansvarlig for faktisk at konstruere spilene snarere end motor eller større spilsystemer. Men ud over det varierer tingene meget:

Nogle virksomheder forventer, at gameplay-programmører implementerer brugergrænsefladen . Nogle don t. Nogle virksomheder forventer, at de implementerer AI-kode, andre don t. Nogle forventer, at de implementerer lydkode, andre ikke. For at være ærlig er “gameplay” i gameplay-programmør en branchen stenografi for “alt, hvad vi ikke har hyret en specialist til at gøre”. Så disse programmører skal være meget alsidige og skal kunne lære nye discipliner hurtigt.

Jeg brugte næsten femten år på at være gameplay-programmør i den kommercielle industri på tværs af fem forskellige virksomheder.

Min erfaring var, at i nogle virksomheder anses en gameplay-programmør for at være en junior- eller entry-level position; programmører, der kun arbejder på et individuelt spil, trods alt behøver ikke at være så sofistikerede som dem, der arbejder på systemer, der har brug for at understøtte mange forskellige spil samtidigt, som motorprogrammerere har brug for. I denne form for firma, hvis en gameplay-programmør klarer sig rigtig godt, kan han blive forfremmet til motorteamet en dag, hvis han kan bevise sin værdi. Eller han kan blive specialist, hvis han viser en evne til et bestemt område.

I andre virksomheder betragtes en gameplay-programmør som en mellemniveau-position; programmører, der arbejder på et individuelt spil, skal have en vis nyttig erfaring og være pålidelig. Uerfarne programmører kan få uønskede job at skære tænderne på (datarørledninger, værktøjer osv.) og til sidst få lov til at bevæge sig op i et “gameplay-programmør” -job. I denne slags system en gameplay-programmør, der fortsætter med at gøre det ganske godt, kan komme op i et projekt lea dership-rolle, ellers på motorteamet.

I endnu andre virksomheder er en gameplay-programmør betragtes som en ledende stilling og også som en halv design-stilling; disse programmerere forventes at være fremragende, gennemprøvede programmører, men også at have stærke designfølsomheder og kvalifikationer, da de direkte berører den kode, der stærkest påvirker spillerens oplevelse med spillet. I denne slags system vil en rigtig god gameplay-programmør sandsynligvis forblive en gameplay-programmerer for evigt – dette anses for at være den mest værdifulde position, som han kan udfylde.

Som en generel tommelfingerregel, jo bedre virksomhedens spil, jo mere senior en stilling, de anser gameplay-programmør for at være (og jo vanskeligere bliver det være at faktisk lande et sådant job).

Jeg finder altid det hjælper at illustrere med et eksempel.

• En gameplay-programmør fik opgaver i retning af: implementere nærkampskampsystemet, implementere mekanismen til sundhedsregenerering eller implementere spillerens hoppekontrol.

• En motorprogrammerer (hvad du kalder en person, der ikke specifikt var en gameplay-programmør) fik opgaver i retning af: implementere udsat belysning eller et animationssystem eller et netværkslag.

Nøgledistinen ction er, hvem “kunden” er. For gameplay-programmører er det designteamet – deres opgave er at gøre designet til en realitet. For motor-programmører er det generelt andre programmører . Motorprogrammerere fremstiller teknologi og systemer, som gameplay-programmører og indholdsskabere derefter kan bruge til at realisere designet.

Motorprogrammerere skriver kode, der stort set er spilagnostisk – den samme teknologi kan ofte bruges i flere spil. Gameplay-programmører har tendens til at skrive kode, som er meget specifik for det spil, der laves. Og der overlapper altid – nogle gange for at implementere gameplayet har du brug for en ny motorkode.

Gameplay-kodning er ikke sværere eller lettere end motorkodning.Det er dog bestemt et lidt andet færdighedssæt; du har ofte brug for at være mere kreative og være i stand til bodge løsninger. Dit mål er ikke at skabe det perfekte genanvendelige system (det ideelle til motorprogrammerere), men at skabe den bedste spilimplementering. Så hvad der kan være et aktiv i motorprogrammering (opmærksomhed på detaljer og veludviklede strukturer) kan være en hindring i gameplay-programmering (hvor tilpasningsevne og iterationstid er vigtigere). En god gameplay-programmør ved, hvornår man skal gøre det rigtigt (når designet er solidt og koden vil blive brugt mange steder), og hvornår man skal gøre det hurtigt (når designet stadig udarbejdes, og din kode har en god chance at blive kasseret en gang testet).

Mest af alt skal gameplay-programmører være i stand til at samarbejde med designteamet på et niveau, som motorprogrammerere ikke gør. Bortset fra de åbenlyse kommunikationsevner betyder det, at du har brug for at være fortrolig med andre spildesign meget mere end motorprogrammerere gør, så når en designer siger “få det til at fungere som Zelda”, ved du hvad de taler om.

For at lære at være en motorprogrammerer, vil du bore ned på en teknologi og lære, hvordan den fungerer, og måske implementere din egen version af den; spillet ville bare være en arena, hvor teknologien kunne vises.

For at lære at være en gameplay-programmør, ville du tage en andens motor og bruge den på så mange forskellige måder, som du kan . Med andre ord, hvis du vil være en gameplay-programmør, laver spil, ikke teknologi .

Præcis hvad det lyder, en programmør, der implementerer og vedligeholder spilmekanik.

http://en.wikipedia.org/wiki/Game_programmer#Gameplay_programmer