Share
Som en del av feiringen av vårt ettårs jubileum trodde vi at vi ville se på hvilke artikler vi planlegger å kommisjonere i de neste 12 månedene. Internt har vi diskutert fordelene ved en slags artikkel over en annen, hvem våre lesere er og hvem vi ofte skal målrette, og hva er det egentlig om Gamedevtuts + som vi elsker så mye.
Å publisere fremtidssikre artikler som hjelper nybegynner til mellomliggende spillutviklere finpusser deres håndverk. Hver tidligere opplæring du kan lese på Gamedevtuts +, skulle være noe vi gjerne vil publisere i dag.
Dette er holdningen vi har brukt til å kjøre Gamedevtuts + siden vi lanserte den (selv om vi har tweaked dem kontinuerlig i mellomtiden).
Den avgjørende rolle - ikke nødvendigvis viktigst, men viktig - i spillutvikling er gjennomføring. Stor kunst og lyd uten interaktivitet er ikke et spill, men et spill kan gjøres uten kunst eller lyd.
Så vi definerer "gamedev" for våre formål som (a) å komme opp med regler, tema, mekanikk, estetikk, etc. og (b) implementere dem, legge til interaktivitet.
Det innebærer ikke faktisk å skape kunst og lyd, så vi vil ikke gjøre opplæringsprogrammer om tegning av tegn i Illustrator eller lage musikk i Logic Pro - vår søster Tuts + -steder dekker allerede det bra, uansett.
Samtidig involverer det ikke å komme i dyp detalj om programmering eller bruk av bestemte språk; det er ikke vårt fokus.
Det kan dekke virksomhet (PR, markedsføring, lovlig, etc.) og finne folk som kan skape kunst og lyd.
Dette er en flott artikkel som gir en innledende oversikt over stort sett alt: Hvordan å være en Indie Game Developer, ved Mode 7 Games.
Dette bidrar fremfor alt til å definere vår publikum, for eksempel er vi ikke rettet mot dem som lager sprites i Illustrator eller musikk i Logic Pro.
Tuts + og Envato er generelt rettet mot frilansere, entreprenører, småbedriftsarbeidere og lignende; vi gjør det samme på Gamedevtuts +. Våre innlegg er rettet mot freelance spillutviklere, indies, entreprenører og små studioer. Vi skriver ikke spesielt for AAA konsoll spillutviklere - selvfølgelig kan de også nyte innholdet vårt, og de er velkomne til å skrive for oss!
Vi delte publikum i tre brede grupper, basert på deres erfaring:
nybegynnere har aldri laget et spill. Vi kan imidlertid ikke anta noe annet om dem - for eksempel kan noen være strålende programmerere som har jobbet i programvare i ti år, mens andre kanskje ikke har noen programmeringserfaring i det hele tatt.
mellom har gjort et helt spill før, eller kanskje jobbet på flere. Det er trygt å anta at de har en grunnleggende kompetanse i ett eller flere programmeringsverktøy eller språk - kan være avansert Game Maker-skripting, kunne være Enhet, kunne være XNA ... alt annet enn å bare dra og slippe - og så trenger ikke å ha deres hendene holdt når diskuteres kode. De vet hvor de skal finne informasjon om deres valgfrie verktøy: docs, forum, Stack Overflow, referansebøker og så videre.
Avansert Leserne har laget eller jobbet med en rekke spill, i hvert fall noen av dem var vellykkede og har derfor mye erfaring. Når en nybegynner eller mellomliggende spillutvikler spør, "Hvordan lager jeg en MMORPG?" svaret er, "det gjør du ikke." - men det er ikke tilfelle for avanserte lesere.
Nylig har vi lagt merke til at det er et klart gap mellom Beginner og Intermediate, og dette kan være stort nok til å la noen gamedevs gå gjennom sprekkene - de som har hull i deres ferdigheter, og representerer den største demografiske av gamedev, men ville ikke t betrakter seg selv nybegynnere. Siden vi ikke har en tendens til å publisere mange avanserte opplæringsprogrammer, er det kanskje på tide å omdefinere disse gruppene: Intermediate tutorials blir kategorisert som Advanced, noe som gir oss plass til å tilpasse nye Intermediate tutorials i det gapet.
Vi har tatt en kontroversiell tilnærming til nettstedet: våre artikler er plattform-agnostic. Dette har til tider forårsaket at leserne stiller spørsmålstegn ved hvorfor vi har forsømt verktøyet, motoren eller valgt språk.
Personlig har jeg også noen ganger presset mot mer gammeldags (raskt forældede) plattform- eller språkspesifikke artikler, men jeg er helt enig i at de er et dårlig valg når de tenker på langsiktige fordeler.
Det er praktisk å gjøre et tankeeksperiment: Hvis vi hadde lansert Gamedevtuts + for et tiår siden, uten en plattform-agnostisk tilnærming, hvilken situasjon ville vi være i nå?
… og så videre. Vi vil også ha mange artikler om temaer som forretninger og estetikk, som ville holde seg i dato, men vi ville oppdage at mange av våre plattformsspesifikke opplæringsprogrammer enten ville være mindre relevante for leserne, eller ville til og med være å lære utdatert praksis.
Det er faren for at vi ville bli for nært knyttet til noen spesielle plattformer, som potensielt alienerer leserne våre hvis vi forsøkte å forgrene seg.
Hvis alle våre opplæringsprogrammer var plattformsspesifikke, vi ville risikere å kutte leserne ut unødvendig. Det er ingen grunn til at en Java-utvikler ikke kan forstå en A * -opplæringsoppgave skrevet i AS3, med mindre det er for AS3-spesifikk.
Plattformspesifikke opplæringsprogrammer kan ofte være veldig "paint-by-numbers", hvis forfatteren og redaktøren ikke er forsiktig. Dette kan skje publikum av nettstedet mot mindre dyktige (eller mindre dedikerte).
Vi kan grovt dele opp gjennomføringsveiledningene våre i disse brede kategoriene:
Dette er en stor investering: For en virkelig imponerende demo, de trenger god kunst, god lyd og solid kode allround. Og når opplæringen er skrevet, kan det være en stor smerte å oppdatere den - tenk å prøve å oppdatere en blitsbasert AS3-opplæring for å bruke Stage3D.
Og likevel ... dette er sannsynligvis det som leserne forventer av en gamedev opplæring, og har store fordeler for å lære (da det er så mange finesser når du legger sammen et helt spill som går tapt når du bare lærer om de enkelte komponentene).
Vi har gjort dette med våre nybegynnere "From Scratch" opplæringsprogrammer - som alle bruker point-and-klikk, kodefrie gamedev-plattformer - men aldri med en mellomliggende gamedev-plattform som krever koding, som Unity eller HTML5.
Det er i ferd med å endres. Vi skal begynne å publisere kryssplattform opplæringsprogrammer, starter med Michael Hoffmans Geometry Wars-basert spill. Vi publiserer en XNA-spesifikk versjon av opplæringen, og deretter en Flash-spesifikk versjon, og deretter en DirectX-spesifikk versjon, og så videre. Hver vil bli utformet for å være modulær, slik at de kan oppdateres ettersom de underliggende plattformene endres i fremtiden.
Vi skal holde disse plattformen agnostiker - men de kan fremdeles skrives på et bestemt språk, med demoer og kildekoden kompilert for en bestemt plattform, så lenge de er plattform-agnostiske nok til at devs kjent med andre plattformer kan forstå dem. For eksempel: En veiledning om A * -oppdaging bør ikke fortelle deg at "Åpne FlashDevelop og klikk Fil> Ny å skape et nytt prosjekt ".
Vi vil imidlertid begynne å publisere opplæringsprogrammer som forklarer hvordan du implementerer noen av disse konseptene med en bestemt plattform. For eksempel, kanskje vi kommisjonerer et innlegg basert på Jamie Fristroms utmerkede svingende fysikkopplæring, og forklarer nøyaktig hvordan du kodes den i Unity eller UDK, eller en annen passende plattform.
Noen ganger kan de utrolig kraftige verktøyene og programvaren vi bruker til å lage spill, være litt komplisert. Hvem ville ha gjettet?
Vi ønsker å hjelpe gamedevs ut ved å gi opplæringsprogrammer som forklarer hvordan du fikser bestemte smertepunkter i disse verktøyene, eller hvordan du bruker dialoger som kanskje ikke er like brukervennlige som de kan være. Tingen er, disse aspektene har en tendens til å bli løst ganske raskt, noe som betyr at de tilknyttede opplæringsprogrammene blir utdaterte, og vi ønsker ikke utdatert informasjon på dette nettstedet.
Vi skal eksperimentere med slike opplæringsformer, men bare for problemer som er sanne smertepunkter, og det har ikke blitt forklart andre steder allerede. Vi må finne ut hvordan du holder innholdet skilt fra alt annet når det blir foreldet!
Fremtiden ser lys ut for Gamedevtuts +. Selv om jeg forventer at vi hele tiden skal skifte prioriteter for å passe til våre lesere, så vel som den konstante innovasjonen i bransjen, er mitt håp at det på lang sikt vil være vårt oppdragssagn som hjelper oss med å holde oss relevante og umiddelbart nyttige for din nåværende og fremtidige spillprosjekter.
Ved å fokusere på det høyere nivået av gamedevs behov, konseptene som holder seg på tvers av sjangere og plattformer, og de fremvoksende trender innen spillprogramvareutvikling, forretning og produksjon, planlegger vi å lage opplæringsprogrammer og artikler som står tidstesten.
Det blir tider vi må ta på dagens teknologi - for å se på trender og verktøy i dette året. Imidlertid håper vi generelt å levere innhold som er fremtidssikret til en eller annen grad.
Tross alt, en grundig analyse av nivå design pacing eller bevegelse fysikk bak Super Mario Bros er fortsatt aktuelt i dag og er umiddelbart anvendelig for mange gamedevs akkurat nå. Omvendt vil en veiledning om minnehåndtering i monteringsspråk på 6502 CPU som brukes til å drive NES-versjonen av spillet, kun være av interesse bare for historiske formål.
Oppsummert: Fremtidssikker, Begynner-til-Mellom-nivå-opplæringsprogrammer og artikler som dekker design, implementering og virksomhet av spill.
Hva synes du om disse retningslinjene? Hvordan føler du deg om vår nåværende retning? Jeg vil gjerne høre dine tanker om saken. Tross alt er det ikke noe riktig eller feil svar her. Jeg vil sette stor pris på dine meninger, selv om vi er uenige. Vennligst vær hjertelig velkommen til å legge igjen en kommentar.
Accentsconagua