Share
Så du har bestämt dig för att du vill göra ett videospel som en hobbyist. Du har valt en utvecklingsplattform, läst några tutorials, och du har en cool spelidé i åtanke. Du är upptagen, dags att komma igång, låt oss slå på datorn, eller hur? Fel.
Videospelutvecklingsstudior är företag; pengar definierar vad de kan och kan inte göra. Men du är inte ett företag, och saker är inte så enkla för dig.
Ett antagande som många ensamstående hobbyistutvecklare gör är att deras utveckling kommer att fungera på samma sätt som en studio. Att de inte behöver betala sig en lön, och de är inte beroende av sitt spel för pengar, så de kan ta så länge de vill avsluta det. de kan göra vad de tänker på.
Tyvärr är det inte hur det verkligen fungerar. Som enmanslag är du begränsad av dina nuvarande färdigheter och färdigheter som du kommer att kunna förvärva under utveckling. Det kan tyckas uppenbart, men det är något som ambitiösa nya utvecklare ofta glänsar över. Många nya hobbyister, inklusive mig, blev tåriga ögon första gången de började göra ett spel, tänkte på den fantastiska upplevelsen de skulle skapa och helt förlorade synen på vad de kunde realistiskt åstadkomma.
Att göra ett videospel är komplicerat arbete, särskilt ensamt. Från design till programmering till konst, inte alla kan göra allt, och det är inte alltid lätt att lära sig. Du kan vara villig att lära dig hur du gör din egen kropp med fysisk fysisk fysik, men det kan vara svårt att få det gjort utan att förlora intresset för ditt projekt - och vem vet, kanske matematiken bakom fysiken inte bara håller med din hjärna.
Utsätt inte dig själv med ditt koncept, speciellt om detta är ditt första spel. Oavsett om det ser ut som det eller inte, kommer det alltid att finnas hinder som du inte hade förväntat, även i de enklaste av mönster, och du kommer att bli utmanad och lära dig något under utveckling. Även om du inte söker det, kommer det att hända själv.
En annan sak att tänka på: omfattning. Spel tar alltid längre tid att göra än du tror att de kommer att göra, så justera dina mönster i enlighet därmed. Som nittiohalvfemsregeln säger:
De första 90 procenten av koden står för de första 90 procenten av utvecklingstiden. De återstående 10 procenten av koden står för de övriga 90 procenten av utvecklingstiden. Tom Cargill av Bell Labs
Denna regel är humoristisk, men den beskriver den typiska utvecklingscykeln i ett spel. Du kommer få allt som verkar fungera perfekt och tror att du är nästan klar ... och inser plötsligt att du fortfarande har massor av arbete för att polera ditt spel. Saker som UI, ljud och sista minuten glitcher kräver mycket mer av din tid än du skulle tro.
Ju större ditt spel är desto mer av dessa små saker kommer det att vara att fixa - så håll alltid räckhåll i åtanke.
Har du ett koncept som du är säker på att du kan utföra på? Bra - men börja inte än. Du kan inte koda a begrepp; inget programmeringsspråk eller spelutvecklingsverktyg tillåter utvecklare att skapa spel i vaga, breda streck. Du behöver veta detaljerna för vad du gör.
Antag att du gör en 2D pusselplattform som äger rum under vattnet med en kulviktmekaniker. Det låter bra, men du kan inte koda en "coolweight mechanic", du måste bryta ner hur det fungerar på en mycket specifik nivå.
Du måste överväga alla dessa aspekter innan du börjar skapa innehållet. Självklart kommer många saker att förändras under utvecklingens gång - du kommer att hitta nya idéer och skrapa gamla - men det är viktigt att ha en bra bild av vad du gör innan du slår på datorn.
Jag är inte ensam i denna mentalitet. Hela kartan för Shadow Complex gjordes på grafpapper innan någon ens rörde en dator. Nu är det här definitivt en ovanlig utvecklingsstil, och jag säger inte att alla ska replikera det, men laget över på Chair Entertainment förstod definitivt värdet av att förstå ditt spel innan du byggde det.
Jag är fast vid denna punkt eftersom det är en kamp som jag kom över mig nyligen, och jag skulle vilja använda mig själv som ett exempel på vad jag inte skulle göra.
Jag var glada att börja utveckla ett spel under sommarlovet, när jag var garanterad att ha massor av ledig tid. Jag kom fram med ett koncept som jag tyckte var ganska coolt, fick lite bra feedback om en teknisk demo som jag byggt och började koda. Problemet var, allt jag hade var ett koncept. Jag hade en primärspelare förmåga som jag tyckte var intressant: du kunde skjuta någon kakel i nivån för att få den att stiga upp eller nedåt, låta dig flytta runt och knyta fiender. Bortsett från allt jag hade var en genre och en generell känsla av hur jag ville ha mitt spel att känna.
Detta var katastrofalt och dumt. Jag var så ivrig att gå på att jag inte hade aning om vad jag försökte göra. Jag hamnade i kodningsfunktioner slumpmässigt och hoppades att mitt spel skulle kristallisera till något coolt. Vad jag fick var en väldigt rörig kodbas, konst som såg ut som om mitt spel ägde rum i en djungel (och kanske gjorde det, jag ritade konst innan jag hade en inställning - gå figur) och ingen inspiration alls.
Efter allt det förlorade jag helt intresse för projektet eftersom det var så svårt att göra. Designen var inte särskilt komplicerad och det var inget jag inte gjort tidigare, men jag hittade fortfarande utveckling noggrann, svår och inte alls stimulerande.
Använd mig som ett exempel - du kan läsa mer om mitt övergivna projekt på min blogg. Vet vad du vill göra innan du börjar göra det.
Nästan varje gamedev efter släkten diskuterar prototyper. "Bara prototyp och playtest, skölj och upprepa tills du har något du gillar."
Jag har aldrig gjort ett spel som en del av ett stort lag, men jag har erfarenhet av att arbeta i små grupper och på egen hand, och jag kan säga: prototyper är inte så snabbt och enkelt som du kanske tror. När du bara är en person som arbetar på ett spel, blir det bara en liten del av det som arbetar, det kan ta en stund, och det är ganska tråkig att använda detta som en metod för att räkna ut primära spelkoncept..
Men prototyper och spelprovning har sin plats i ett enmanslags utvecklingscykel - du behöver bara ta det på ett annat sätt.
När du bestämmer dig för huruvida en spelidé är lika stor som du tror är det, ingenting är mer effektivt än att sätta sig ner och spela det. Detta förändras inte när du arbetar ensam, men eftersom prototyper kan ta så lång tid behöver det lite tweaking. Gå inte blind i prototyper, tänk på det som en tid där du ska testa en sak och komma upp med en massa coola nya idéer. Tänk snarare på prototyper som ett utrymme där du kan förfina de idéer du redan har, stryka detaljerna i din befintliga plan.
Du kan bli slagen av en våg av inspiration när du börjar få saker att springa, men räkna inte med det. När du börjar prototypning är det effektivt att göra en vertikal del av ditt spel, en kort hackad-tillsammans spelbar sektion som representerar så gott du kan vad du vill ha en del av slutprodukten att vara. Du behöver inte återanvända någon av denna kod senare, så få det bara igång så fort du kan för att få en bra mätare av vad du verkligen gör. Du kan till och med använda en annan motor för detta än du planerar att använda för det aktuella spelet.
Detta kommer att hjälpa dig att få ett mål att arbeta för, liksom en riktigt bra idé om hur din design ska fungera. Denna erfarenhet lägger till kontext för resten av din utveckling och gör det möjligt att göra arbetet mycket effektivt. Att alltid ha den slutliga produkten bakom dig själv hjälper verkligen till att minimera mängden konst och koda dig skrot senare.
Allt detta beror givetvis på din utvecklingsplattform. Om du gör ditt spel i något med mycket förankring gjort för dig, som GameMaker eller till och med LittleBigPlanet-nivåredigeraren, kan prototyper vara snabb även om du bara är en person. Bygg så många prototyper som du vill, i så fall!
När du har en design som kan uppnås har du hamrat ut detaljerna om hur sakerna ska fungera, och du vet exakt hur du ska ta itu med prototyperna, då är du redo!
Tack för att du läser. Gå vidare och få göra det spelet - jag ser fram emot att se den.
Accentsconagua