Hva er en “ Spillprogrammer ”?

Når selskaper snakker om å ansette en spillprogrammerer , er det de snakker om er en programmerer som vil være ansvarlig for koden som berører direkte på spillopplevelsen. Det vil si at programmereren vil være ansvarlig for å faktisk konstruere spillene, i stedet for motor eller større spillsystemer. Men utover det varierer ting mye:

Noen selskaper forventer at spillprogrammerere å implementere brukergrensesnittet . Noen don t. Noen selskaper forventer at de skal implementere AI-kode, noen don t. Noen forventer at de skal implementere lydkode, noen ikke. For å være ærlig, er «gameplay» i gameplay-programmerer forkortelse for «alt som vi ikke har hyret en spesialist til å gjøre». Så disse programmererne må være veldig allsidige, og må kunne lære nye fag raskt.

Jeg brukte nesten femten år på å være en spillprogrammerer i den kommersielle industrien, på tvers av fem forskjellige selskaper.

Min erfaring var at i noen selskaper anses en spillprogrammerer for å være en junior- eller entry-level stilling; programmerere som bare jobber med et enkelt spill, tross alt, trenger ikke å være så sofistikerte som de som jobber med systemer som trenger å støtte mange forskjellige spill samtidig, slik motorprogrammerere trenger. I denne typen firma, hvis en gameplay-programmerer gjør det veldig bra, kan han bli forfremmet til motorteamet en dag, hvis han kan bevise sin verdi. Eller han kan bli spesialist hvis han viser evne til et bestemt område.

I andre selskaper regnes en spillprogrammerer for å være en mellomnivåposisjon; programmerere som jobber med et individuelt spill må ha litt nyttig erfaring og være pålitelig. Uerfarne programmerere kan få uønskede jobber å kutte tennene på (datarørledninger, verktøy osv.), og til slutt få lov til å gå opp i en «gameplay programmer» -jobb. I denne typen system, en spillprogrammer som fortsetter å gjøre det ganske bra, kan komme seg opp i et prosjekt lea dership-rolle, ellers på motorteamet.

I enda andre selskaper er en spillprogrammerer ansett for å være en senior stilling, og å være en halv design stilling også; disse programmørene forventes å være gode, velprøvde programmerere, men også ha sterke designfølsomheter og kvalifikasjoner, siden de direkte berører koden som påvirker spillerens opplevelse med spillet sterkest. I denne typen system vil en veldig god spillprogrammerer sannsynligvis forbli en spillprogrammerer for alltid – dette anses å være den mest verdifulle stillingen han kan fylle.

Som en generell tommelfingerregel, jo bedre selskapets spill, jo eldre stilling de anser spillprogrammerer for å være (og jo vanskeligere blir det være å faktisk lande en slik jobb).

Jeg synes alltid det hjelper å illustrere med et eksempel.

• En gameplay-programmerer vil få oppgaver i retning av: implementere nærkampssystemet, implementere helsegenerasjonsmekanikeren eller implementere spillerhoppkontrollene.

• En motorprogrammerer (det du vil kalle noen som ikke spesifikt var en gameplay-programmerer) vil få oppgaver i retning av: implementere utsatt belysning, eller et animasjonssystem eller et nettverkslag.

Nøkkelen distin ction er den av hvem «kunden» er. For spillprogrammerere er det designteamet – deres oppgave er å gjøre designet til en realitet. For motorprogrammerere er det generelt andre programmerere . Motorprogrammerere lager teknologi og systemer, som spillprogrammerere og innholdsskapere kan bruke for å realisere designet.

Motorprogrammerere skriver kode som i stor grad er spillagnostisk – den samme teknologien kan ofte brukes i flere spill. Spillprogrammerere har en tendens til å skrive kode som er veldig spesifikk for spillet som lages. Og det overlapper alltid – noen ganger for å implementere spillingen trenger du noen ny motorkode.

Spillkoding er ikke vanskeligere eller enklere enn motorkoding.Det er imidlertid definitivt et litt annet ferdighetssett; du trenger ofte å være mer kreative, og kunne bodge løsninger. Målet ditt er ikke å lage det perfekte gjenbrukbare systemet (ideelt for motorprogrammerere), men å skape den beste spillimplementeringen. Så hva som kan være en ressurs i motorprogrammering (oppmerksomhet på detaljer og godt konstruerte strukturer) kan være en hindring i spillprogrammering (der tilpasningsevne og iterasjonstid er viktigere). En god spillprogrammer vet når du skal gjøre det riktig (når designen er solid og koden vil bli brukt mange steder), og når du skal gjøre det raskt (når designen fremdeles blir utarbeidet, og koden din har en god sjanse av å bli kastet en gang testet).

Mest av alt trenger spillprogrammerere å være i stand til å samarbeide med designteamet på et nivå som motorprogrammerere ikke gjør. Bortsett fra de åpenbare kommunikasjonsferdighetene, betyr det at du trenger å være kjent med andre spilldesign mye mer enn motorprogrammerere gjør, slik at når en designer sier «få det til å fungere som Zelda», vet du hva de snakker om.

For å lære å være motorprogrammerer, vil du bore ned på en teknologi og lære hvordan den fungerer, og kanskje implementere din egen versjon av den; spillet ville bare være en arena for å vise teknologien.

For å lære å være en spillprogrammerer, ville du ta en andres motor og bruke den på så mange forskjellige måter du kan . Med andre ord, hvis du vil være spillprogrammerer, lager spill, ikke teknologi .

Akkurat hvordan det høres ut, en programmerer som implementerer og vedlikeholder spillmekanikk.

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