Share
Du kan lage et dusin kamper i år. Lyd umulig? Det er ikke. Prøv denne enkle spillutviklingsmetoden fra noen som har trukket den av og se for deg selv at 12-i-12 er et rimelig mål.
Jeg skal dele med deg min personlige spillutviklingsmetode. Jeg hevder ikke å ha oppfunnet verdens eneste system for å nå målstreken - langt fra det. Dette er bare en stavebok, en verktøykasse fylt med mine egne personlige tips og teknikker som jeg bruker til å kjempe mot demonene som prøver å forhindre meg i å starte et spill. Disse demonene inkluderer funksjonskryp, alt-eller-ingenting-design og ubegrenset optimisme. Dette er triks jeg har utviklet i løpet av å lykkes der jeg hadde mislyktes i fortiden.
Du ser, i 2012 oppnådde jeg det høye målet om å skape 12 kamper på 12 måneder. Overraskende var det ikke så vanskelig: det tok ikke noe mer arbeid enn mine mange mislykkede prosjekter hadde i tidligere år.
Så hva var forskjellen? En mer moden, mer erfaren, mindre brede og mindre optimistisk tilnærming. Ikke misforstå: Det er ingenting i det hele tatt feil med optimisme. Faktisk oppfordrer jeg det! Uten det ville ingen av oss være gamedev. Uten noen optimisme vil du aldri komme hvor som helst. Jeg trengte bare å nærme meg prosjektene med litt mindre ydmykhet.
Jeg vil gjerne dele noen av mine triks og tips med deg her. Jeg ber om at du vurderer hver av dem, men vær så snill å godta eller avvise dem etter eget ønske. Ingen teknikk kan fungere for hver person, men hvis du tar bort en enkelt teknikk eller tenkemåte som hjelper deg med å trekke av målet One-Game-A-Month med 12 spill på ett år, så vil jeg være glad.
Prøv å bruke disse tipsene i ditt neste spillprosjekt. Kanskje de vil hjelpe deg også. Kanskje du kommer opp med din egen beste praksis som er annerledes eller bedre. Det er flott! Som med de fleste råd, er nøkkelen å vurdere meldingen, godta eller avvise hvert punkt som du personlig ser, og vedta (eller tilpasse) de praksiser som appellerer til deg.
90% av spillprosjektene ser aldri dagens lys. Min egen personlige erfaring bekrefter dette. Jeg har laget spill i over tjue år, og av alle spillene jeg startet - fylt med entusiasme, en detaljert plan og uendelige brainstorms verdt av ideer - bare en liten prosentandel ble utgitt. Dette forårsaket meg år med hjertesorg. Jeg var en god coder, jeg kunne produsere akseptabel kunstverk, jeg hadde nok gode ideer til å føle seg trygg på planene mine, og likevel den fantastiske staten hvor spillet er klart for publikum, var et uhyggelig mål.
Hvorfor? Fordi faktisk implementering alle disse spennende planene alltid involverte utfordringer som jeg ikke hadde spådd. I tillegg vil entusiasmen jeg hadde for hvert prosjekt, vanligvis avta når målstreken nærmet seg. Gangen ville bli tøff, pengene skulle løpe ut, forfallsdatoen ville passere meg forbi, og moroa ville ende. Alt som ville forbli var det slog skjønt den siste strekningen som mange devs ringer veggen.
Veggen er poenget i et programvareutviklingsprosjekt hvor det ikke lenger er morsomt. Alle de enkle å implementere tingene er kodet, og det som gjenstår, er bugsering, vanskelige biter av kode, gjentatte oppgaver, deler som er avhengige av ting utenfor kontrollen din, det som mangler nivå eller lydeffekt, installasjonsproblemer, bruker testing, som rapporterte feil som du ikke kan reprodusere, og app store innlegg.
Etterbehandling av et spill kan betraktes som analogt å klatre i fjellet. Med hell kan du gjøre det med ingenting annet enn joggesko og ambisjon - men dette resulterer vanligvis i katastrofale feil. I stedet for å klatre fjellene mine uten tanker eller planer, begynte jeg å ta med tau og holdt, studerte fjellveggen på forhånd, tok del av deler som ville være vanskelig og tempoet selv.
Tenk deg å måtte fullføre et helt spill uten en enkelt spillsparing. Dette er hvor mange spillutviklere som lager programvare: alt eller ingenting, ingen sikkerhetsnett, du slår enten den ut av parken eller krasjer og brenner. Ingen midtbane. Ingen regnskap for uplanlagte uforutsetninger. Dette er en sikker brann måte å utilsiktet sikte på feil.
Etter at du har gjort dette noen ganger, vil du begynne å se mønsteret: optimistiske planer uten å lagre poeng underveis er ekstremt risikabelt. Hvorfor ikke redusere risikoen og gi deg flere utgangspunkter underveis?
La oss dykke inn. Jeg skal bruke et spill jeg skrev i en helg som et eksempel for å illustrere mange av disse punktene. Dette virkelige eksemplet skal bidra til å bevise dette.
Brainstorming er det beste. Jeg elsker å skrive ned store lister over varetyper, skatter, oppdrag, tegnnavn, nivåideer eller byggeklosser. Det er gøy, og det er en fin måte å begynne å jobbe med. Men det er en skjult felle: Brainstorms er, av sin natur, om mengde, ikke kvalitet. Jeg liker å joke det et akronym for brainstorm er B.S.
Hvis du starter hvert prosjekt med en stor brainstorm, flott. Men ikke begynn å jobbe med spillet ditt før du har kastet 99% av det som gjorde det på din opprinnelige liste i "lagre det for versjon to punkt oh" ønskeliste.
En fin måte å pare ned på den massive, funksjonelle, skumle, altfor optimistiske tome som er en typisk gamedevs brainstorm, er å rangere hvert punktpunkt på noen skalaer som:
Sorter listen og kaste bort de fleste ideene dine. Lagre de fleste av dem (spesielt de vanskeligste) for senere.
For hvert element i toppvalgene dine, spør ett siste spørsmål: er dette a må ha eller a fint å ha? For den første prototypen, fokuser bare på de essensielle, ikke-muligens-arbeid-uten-det-funksjonene.
For det andre, tenk: hvor vanskelig vil hvert element være å implementere? Krever det mye kode eller innhold? Ikke skam deg med å planlegge på en lat måte akkurat nå: du må være disiplinert nok til å sette mange av dine største ideer på bakbrenneren rett og slett fordi implementering av dem vil ta et stort antall timer med arbeid. Vær lat: velg de viktigste funksjonene som er lett å lage.
Det som er rettet mot når du angriper din gigantiske brainstorm, er å parre den helt ned til de absolutte essensielle. Distill din ide til enkelt kjernemekaniker du liker mest som ville være lett å implementere. Gjør en ting bra, ikke et dusin ting halvt bakt.
Dette blir din MVP: din minimum levedyktig produkt.
Når du har beskrevet MVP for deg selv - det vil si å kunne beskrive hele grunnleggende konseptet av spillet i ett avsnitt, med en eller to funksjoner på det meste - det er på tide å avgrense det.
Tenk deg at du må overbevise en stor utgiverutøvelse av levedyktigheten av spillet ditt under et sjanse møte i en heis. Du har ti sekunder. Kan du beskrive spillet så entusiastisk, så interessant, så oppmerksomt, at i det korte øyeblikket kunne du score en enorm forhåndsgodtgjørelses- og publiseringsavtale?
Skriv denne heisen nedover. Rediger den. Gjør det kortere. Foreløpig, i stedet for ovenstående scenario, ville dette være tekstkopien av baksiden av spillets boks hvis den satt på en butikkhylle. Tenk deg en spiller som plukker opp boksen og snu den rundt. De har hundrevis av andre spill å velge mellom, men de har bestemt seg for å gi deg et dusin sekunder av sin tid til å vurdere din. Selger denne banen spillet?
Hvis du leser det til en venn (eller enda bedre, en fremmed) er de fascinert? Spent? Entusiastisk? Hvis du kan si ja til disse spørsmålene, vet du at du er på noe bra.
Bare for moro skyld, og for å illustrere alle mine poeng, skal jeg vise deg arbeidet mitt i gang for et nylig spill jeg laget. Heisbanen i begynnelsen gikk noe slikt:
Du er skurken. To elskere ønsker desperat å omfavne hverandre. Ditt oppdrag er å holde dem fra hverandre ved å bygge vegger som kjører dem lenger fra hverandre uten å gjøre det umulig. Et turbasert strategi puslespill basert på A-stjerners pathfinding.
Det neste trinnet, før du begynner å kode eller lage store biblioteker med innhold som kan eller ikke gjør det til ditt siste spill, er å gjør en grov skisse av spillet i aksjon. Du trenger ikke noen kunstneriske ferdigheter: disse kan være svarte og mens fargestiften stavfigur miniatyrbilder. Det du sikter på er en visuell representasjon av hele spillet - fra begynnelse til midten til slutt.
Tegn en haug med paneler på et stykke papir og start med en grov tilnærming til hva tittelskjermen eller hovedmenyen vil se ut. I det neste panelet tegner du hva som skjer neste. Et intro? Nivå ett? Fortsett som om du spiller en spill-av-spill av selve spillet, fra øyeblikk til øyeblikk. Jo flere paneler du må opprette for å fullt ut visualisere spillet ditt, desto mer arbeid vil du tildele deg selv. Derfor, sikte på å passe hele greia på en enkelt side. Mindre enn et dusin paneler er klokt - men himmelen er grensen.
Jeg vil vise deg mine arbeidsprosessbilder av et puslespill / strategi / taktikkspill jeg programmerte nylig kalt Pathos. For å begynne, her er den grove skissen som jeg pleide å planlegge spillmekanikeren raskt:
Som du kan se, er jeg en stor fan av puns. Jeg spilte med alle slags spilltittelvarianter som spilte av den a-stjerne banebrytningsalgoritmen, og jeg kastet inn mange Dungeons and Dragons RPG-stilbilder, siden det inspirerer meg. Jeg elsker fantasi verdenskart og skjønte at det ville være det ideelle nivå velg skjermbildet.
Grunnen til at det er viktig å lage et raskt fortegn er at det vil gi deg en mer konkret beskrivelse av hva som faktisk skjer i spillet. Moreso, det legger ting ut visuelt. Hvor mange knapper kan du passe på en skjerm? Hvor stor er avataren? Hvilken retning er bevegelsen? Hvor er poengsummen eller helsefeltet? Disse miniatyrbildene er en fantastisk måte å se spillet fra et designers perspektiv. De vil også hjelpe deg under koding på mange måter. For eksempel vil du nå vite omtrent hvor mange ikoner eller knappbilder du trenger å tegne, hvilke nivåer kunst vil kreve, og selv hvordan spillet vil se ut - fra et grunnleggende layoutperspektiv.
Hvis tegneserien din ikke ser ut som et morsomt spill nå, så har du spart deg uker eller måneder med arbeid ved å vite allerede at noen endringer må gjøres. Hvis tegneserien ser ut til å gå for alltid, så ser du de åpenbare advarselsskiltene at arbeidsbelastningen er for stor og du må redusere mengden scener eller nivåer eller spillelementer.
På samme måte som en heiskast, er dette en sidepinnefigur tegneserie storyboard et ideelt BS-filter. Vis det til venner. Vil de spille dette spillet? Tror de det ville være verdt din tid å bli en realitet?
Det neste store hendige tipset for denne utfordringen er å lage et spillbart spill i den første dagen. Ingen tittel skjerm, bare ett nivå, og bare den primære gameplay mekaniker.
Det vil ikke være bra, det blir ikke ferdig, og det vil absolutt ikke se så bra ut eller være så gøy. Når det er sagt, er dette trinnet ditt beste våpen. Utfordre deg selv til å lage en kodebase som kompilerer og kjører i de første par timene. Gjør det slik at du kan godta innganger, flytte rundt, animere noe og utløse noen lyder. Denne prototypen, elendig et spill som det kan være, kommer til å bli din beste venn.
Jo før du kan ha en fungerende tidlig spillbar prototype, jo mer sannsynlig er du å lykkes. Det blir ditt første "sparepunkt" - et hvileplateau på vei til toppen av fjellet som du kan falle tilbake på. Det representerer en visjon av arbeidsspillet. Herfra vil du kunne polere spillet ditt så lenge du vil med kunnskapen om at du har noe i hånden som "virker".
Her er hva den første prototypen så ut. Det var et enkelt eksempel på opplæring i handling, med ingen art - bare fargede rektangler.
Å komme til dette stadiet tok mye programmeringstid. Jeg anslår at halvparten av levetiden til prosjektet ble brukt med spillet som ligner bildet ovenfor. Den moderne tilnærmingen er ideell for programmering: det sparer tid, hjelper deg med å finne ut av feilene, og tvinger deg til å fokusere på "følelsen".
Ikke-kunstige prototyper har også en annen stor fordel: i tidligere spill, ville jeg lage flotte mockups i Photoshop og samle hundrevis av nydelige utseende sprites som forberedelse til spillet. Etter at utviklingen var ferdig, måtte det store flertallet erstattes, endres eller kastes ut. Jeg har kastet bort tusenvis av timer som gjør spillet klar kunstverk før koding; I dag vet jeg at teknikkens spesifikasjoner og utviklende spillmekanikk vil bety det mye av det du lager i starten, vil ikke gjøre det til det ferdige spillet.
Når spillmekanikeren du jobber med, begynner å fungere, kan du begynn å legge til polish til ditt minst levedyktige produkt. På dette stadiet bør du fortsatt ikke ha en hovedmeny eller tittelskjerm, men bevegelses- og spillreglene bør være på plass for å dekke den primære mekaniker.
Du er nå klar til å forplikte seg til en bestemt pikselstørrelse for sprites, å bestemme layouter og fargeskjemaer og hvor mange fliser du vil ha på skjermen, og å begynne å slippe spillkvalitetskunst inn i spillverdenen din. Dette er også på tide å eksperimentere med ytelse og håndtere alle tekniske begrensninger som å opprettholde en god framerate og holde seg under ønsket båndbredde eller teksturstørrelse.
Tilbake til eksempelprosjektet mitt, her er den første arbeidsprototypen, med bare et par plassholderpriter. Avstanden fra et sted til et annet blir nå målt, og vi er klar for noen faktiske nivåer:
Gode nyheter: Dette er ditt neste "sparepunkt"! Du har et spill som "fungerer" ved at det fungerer. Du kan klikke på skjermen og noe skjer. Det er ingen personlighet og bare ett nivå, men i det minste er det noe du kan sende til en venn og be dem om å spille. Du har noe som kompilerer.
Det vi satser på her, er funksjonalitet: noe, noe som du kan slutte å jobbe med og likevel ha noe å vise (og spille!). Det kan være forferdelig uhyggelig eller stygg som synd, men det er ikke i det minste litt viktig. I det minste har du et koden prosjekt som kompilerer uten feil og produserer en levererbar.
Først når du oppnår denne "tidlig spillbare", er du sikker på å slå målstreken, fordi fra nå av kan du tenkelig sende den.
Med den sentrale spillmekanikeren i hånden, åpner verden seg for deg. Mulighetene er uendelige, og den morsomme delen begynner. Kanskje du velger å legge til noen nivåer, skrive litt dialog eller utvikle noen tegn i å bo i spillverdenen din. Kanskje du tenker på et fancy partikkelsystem, kul musikk eller en high score liste er viktig for visjonen om hva spillet skal være. Flott! Dykk inn!
Bare husk en ting: ikke jobbe med litt av dette eller alt på en gang. Fokuser på en oppgave og fullfør den til minimal grunnleggende tilstand før du går videre.
Du kan bli lei av å jobbe med noe og trenger en pause. Det er greit - men forsøk å være disiplinert nok til å fortsette å jobbe med det minimale systemet til det eksisterer i en tilstand som du kan gå bort fra hvis du trenger det.
For eksempel, før du implementerer kamp eller helse eller partikkeleffekter, konsentrere deg om tegnbevegelsen og kollisjonsdeteksjonen til det punktet du trygt kan si at tegnet beveger seg, støter på vegger og reagerer på tastatur, mus eller joystick kontroller.
Bare deretter bør du gå videre til våpen, eller avansert bevegelse som å hoppe, eller oppdage hvorvidt spilleren berører lava spesielt eller trenger å få skade.
Ved å jobbe så lineært som mulig (innenfor grunn), vil du oppdage at du jonglerer færre ting samtidig. Tankene dine vil være fri til å konsentrere seg om en enkelt oppgave om gangen enn å bli overveldet av femti forskjellige bugs i femti forskjellige klasser. Dette er viktig for å holde motivasjon, konsentrasjon og entusiasme. Ingenting gjør at du vil slutte mer enn å ha så mange problemer å løse at du blir motløs.
Akkurat som med en lekkende dam, er et enkelt hull lett å plugge. Hvis i stedet viser femti forskjellige hull på en gang - hvis du hopper fra en utfordring til en annen uten å fullføre den du jobbet med tidligere - vil du snart finne deg selv i et stort rot av buggy-kode som er så komplisert og har så mange problemer spredt om at du får den fryktelige følelsen som kommer med oppfatningen at du må tutte alt for å fikse dem alle.
I livet til en gamedev, lager du et metaforisk lagringspunkt når du fullfører en MVP eller spillbar prototype eller utgitt versjon av et spill.
Husk å lagre denne spillbare versjonen av spillet et annet sted enn arbeidsmappen din. Bruk versjonskontroll. Zip opp spillet og kaste det på backupen din. Send det til en spilltester. Uansett hva du gjør, sørg for at hvis du ødelegger alt fra dette punktet på, kan du trekke tilbake en versjon og sende den.
Alltid sikte på å skape mange iterativt forbedrede og inkrementelt forbedrede arbeid, funksjonelle, kjørbare. Hvis du har gått mer enn en dag uten å ha en solid backup-versjon av spillet ditt som, om nødvendig, kunne bli offentliggjort, bør du bli nervøs.
Naturligvis vil det til tider være lange strekker der du jakter ned bugs i flere timer. Når du kommer til et punkt hvor spillet virker svakt funksjonelt og ikke helt ødelagt, lagre en sikkerhetskopi. Der - du har opprettet et annet lagringspunkt.
Av denne grunn gjelder den lineære, iterative tilnærmingen som er skissert ovenfor, også for kunstinnhold eller spillnivå. Arbeid på polering et godt nivå av gangen. På denne måten, hvis du går tom for tid, penger, tålmodighet eller entusiasme før du er ferdig med alle 99 nivåene du planlegger i designdokumentet, er de tre eller fire som du gjorde ferdig nok til at du fortsatt kan være stolt av dem.
For å si det enklere, prøv å alltid ha en versjon av spillet tilgjengelig som du kan gå vekk fra og sette deg i live. Dette er et sikkerhetsnett. Tross alt, livet kan kaste en uventet krise på deg i morgen. Sykdom, familie ting, en motgående buss - uansett årsak, vil du alltid sove bedre med et lagringspunkt på det klare.
Husk at du alltid kan komme tilbake til det og skape en forbedret og utvidet versjon 2.0.
Iterativ, lineær, trinnvis, en-ting-til-en-tid-utvikling er hemmeligheten til 12-i-12 suksess.
En du har truffet noen få lagre poeng, ditt spill kommer til å være i god form. På et tidspunkt skal du bestemme at det er på tide å ringe det. Det er viktig å innse at du aldri vil legge til halvparten av funksjonene fra ditt opprinnelige brainstorm-dokument. Det er sannsynlig at mange flere vil ha flyttet fra versjon 1.0 til versjon 2.0-ønskeliste.
La oss gå tilbake til mitt eksempel prosjektspill. På dette tidspunktet hadde jeg jobbet på og av for en helg og var klar til å sende den og gå bort. Jeg hadde endret navnet, lagt til noen fine kunstverk, kodet en parser for dataformatet som min nivåredaktør brukte, og fant noen lyder og musikk. Det var et spill. Det var spillbart. Jeg var stolt av det. Jeg ringte det "Pathos", og dette er hvordan det så ut. Du er velkommen til å klikke på bildet under for å lese mer og spille spillet.
Alle gamedev er entusiastiske, kreative mennesker. Dessverre er det denne grenseløse entusiasmen og kreativiteten som kan få oss i trøbbel. Som optimister har vi i våre forestillinger en grand vision om hva som kan være: det ultimate spillet som du bare vet vil selge som hotcakes.
Hver enkelt del av dette store drømprosjektet lyder som noe du lett kan gjøre - og dette er trolig sant! Men hvis du legger opp hver oppgave, er din gode evne ganske enkelt ikke det som vil begrense deg; det er din tid det er mangelvare.
Husk at de fleste spillene du spiller på konsollen, for eksempel har hatt hundre personer som jobber på dem, heltid, i flere år. Hvis du er en solo indie som forsøker å konkurrere med disse typer lag, er alt du trenger å gjøre, litt matematikk for å innse at menneskets arbeidstid legger til mer enn en indieutviklers levetid.
Du må bare akseptere det faktum at du må sikte lavere for å fullføre, med mindre du vil bruke år på et enkelt spill. Med tanke på at gjennomsnittlig godt indie-spill nettopp noen tusen dollar med fortjeneste, har du ikke råd til å bruke hundrevis eller tusenvis av timer på spillet ditt, med mindre du satser gården på et livs arbeid eller episk mesterverk. Du må designe spill som tar 20 til 50 timers arbeid.
For all del drøm stort - men bygge iterativt. Bygg et minimalt levedyktig produkt, og hvis spilltestere elsker det, legg til litt mer og ring den versjonen 2.0. Fortsett å jobbe på denne måten så lenge du vil!
Perfeksjon er per definisjon uoppnåelig. Du må svelge din stolthet og akseptere ufullkommenhet. Å forsømme dette er å koble deg selv til prosjektet for en evighet. Husk at du alltid kan lage en oppfølger. Å frigjøre spillet ditt, selv om du vet at du kan forbedre det for alltid, er en god ting. Ikke bare vil det løfte en stor vekt på skuldrene dine og gi deg noe å være veldig stolt av, men når det kommer inn i spillerens hender kan de komme opp med nye funksjoner du aldri hadde vurdert.
Når du går tom for tid, lanserer du energi, penger eller motivasjon. Hvis du har overholdt systemutviklingsmetoden for lagringspunkt, bør du ha noe spillbar på et hvilket som helst tidspunkt i prosjektet, selv om det er mange funksjoner igjen i din ønskeliste eller oppgaveliste. Det er ok!
"Utgivelsen tidlig, slipp ofte" mantra gjentas igjen og igjen av vellykkede gamedevs av en god grunn. Du trenger spiller tilbakemelding. Du trenger ekte verdenstester. Koding i en svart boks, gjemmer seg bort i en bunker til øyeblikket for endelig utgivelse, er en feil. For en ser du ditt eget spill gjennom ditt begrensede perspektiv. Du har sikkert lagt merke til tider når du korrekturleser dine egne e-postmeldinger, men verdens mest åpenbare typoer kommer igjennom. Dette er fordi etter en stund med å se på det samme, begynner ditt sinn å vokse følelsesløs til det kritiske øyet. Et nytt sett med øyne ser ting i et annet lys.
Det kan hende du finner ut at en bestemt mekaniker, mens det er tilsynelatende strålende på papir, er kjedelig eller frustrerende når den er implementert.
I tillegg er spill som frigjør tidlig og fortsetter å bli utviklet de som får størst eksponering. Du genererer mer "nyhetsverdig" informasjon. Du bygger buzz. Du tiltrekker etterfølgere. Du får folk til å teste spillet ditt og få verdifull kunnskap som vil påvirke designene dine.
Spillere kan tilby kritikk eller kudos som overrasker deg. Funksjoner du trodde var viktige, kunne bli møtt med uinteresse, mens de du trodde var uviktig, kan vise seg å være alles favoritt. Det er viktig å se hvordan offentligheten reagerer på spillet ditt og reagere tilsvarende. Dette sparer deg tid og hjertesorg. Det gir deg retning for fremtidige utgivelser. Viktigst av alt, vil det gi deg nye fans, følgere og et velfortjent pat på baksiden.
I tillegg er kunnskapen om at noen der ute spilte og likte spillet ditt gylden.
Nå som du har fått den ekstra lille motivasjonen og et glimt inn i min personlige gamedev-metodikk, oppfordrer jeg deg til å komme deg ut av internett og bare dykke inn. Planlegging eller undersøkelse for lenge kan være en energi- og tidsavløp. Noen ganger trenger du bare å lage en ny mappe, lage et tomt prosjekt og starte kodingen. Brann opp dine gamedev-motorer og slå etterbrennerne.
Hvis du følger denne grunnleggende filosofien om spillutvikling, er jeg sikker på at du vil høste mange belønninger. Den mest grunnleggende vil være lavere stress. Mer nytelse av prosessen, mer konkrete, spillbare bygg, og flere sjanser til å få spiller tilbakemelding er også fordelen med dette lagrepunktsystemet. Til slutt, ved å hugge prosjekter i små diskrete seksjoner, er du sikker på å kunne legge inn et nytt spill hver måned i år.
Hvis du er opptatt av denne typen utfordring, inviterer jeg deg hjertelig til å bli med OneGameAMonth, en gamedevutfordring som har blitt akseptert av over tre tusen indie gamedev akkurat som deg.
OneGameAMonth er gamedev med gamification lagt til: du tjener erfaringspoeng, levelups og prestasjonspriser for å lage spill. Du kommer til å koble med et svært engasjert og aktivt fellesskap av jevnaldrende som er støttende, hjelpsom og imøtekommende. Hundrevis av spill av alle sjangere blir lagt ut der akkurat nå. Bli med oss!
Lykke til med dine fremtidige gamedev-prosjekter. Du kan gjøre det.
Accentsconagua