Share
Jag tror att alla spelutvecklare borde använda alla verktyg de kan för att förbättra sina arbetsflöden, snarare än att göra allt för hand eller från början. Men vad menar jag med verktyg? Nivåredaktörer, debuggers, analytics ...? Alla dessa och mer! I den här artikeln bryter jag ner de olika typerna av verktyg som är tillgängliga för spelutvecklare och förklarar varför du vill använda var och en.
När du utvecklar ett spel kommer säkerligen tiden att komma när du måste börja lägga till innehåll till det. Det här kan vara en enkel uppgift först: bara ställa in några arrayer och objekt i din kod. Men när din utveckling fortskrider, kan jag nästan garantera att din innehållskod börjar bli rörig.
Föreställ dig att du har tio nivåer av ett plattformspelspel som anges i kod, med fiendspetspositioner, föremål, objekt, kakel och allt annat i den. När du spelar testar det märker du att du måste ändra en fjärds gymposition. Innehållet i nivån är i den stora filen med all information för alla nivåer. Det låter som huvudvärk att gå igenom hela koden och letar efter den exakta raden som ska ändras. Och det överväger inte ens förändringar som kan påverka andra förändringar - som en plattforms position som en fiende står på.
Självklart kanske du också vill visualisera din nivå och kunna ändra den på flyg. Det här är inte möjligt att titta på koden.
Skriva verktyg för att hjälpa dig med din spelutvecklingsprocess är ett mer komplicerat men mer givande tillvägagångssätt. Du kan skriva ett verktyg som skulle översätta all den innehållskoden visuellt till nivån för dig själv, och när du ändrar det, skulle verktyget ändra innehållskoden. Du kan också skriva verktyg för att skapa mer innehåll för ditt spel, hjälpa dig att felsöka ditt spel och till och med hjälpa till med distribution till flera plattformar. Eller du kan gå en nivå högre och släppa verktyget till dina spelare och låta dem skapa innehåll för ditt spel också!
Detta kan till och med öka ditt spelets framgång, som du kanske märker om du tittar på nya spel som redan har gjort det.
Låt oss ta en titt på de olika verktygen du kan göra, hur var och en kan hjälpa dig att lägga till och hantera innehåll i ditt spel och svårigheterna med att skapa dem.
Detta är den bredaste delen. Ett verktyg för skapande är allt som lägger till innehåll för ditt spel - objekt, tecken, nivåer, musik ... Dessa verktyg är de som du spenderar mest tid med, eftersom det är ett spel som kommer att rotera runt dem: skapa nivåer, objekt och fiender; sätta allt ihop polera varje bit till sina finaste detaljer. Några av dessa uppgifter kan innebära ett verktyg för skapande.
Även om nivåredigeraren endast används av dig eller ditt team, måste du göra gränssnittet intuitivt och enkelt att använda.
Låt oss anta att du har ett nivåbaserat spel. För att skapa ett bra verktyg för att redigera dina nivåer är den första uppgiften att få verktyget att visuellt representera nivån för dig. Det betyder att det måste visa dig exakt hur nivån kommer att leta efter dina spelare. Därefter måste det vara möjligt att redigera innehållet på något sätt, så att du faktiskt kan skapa nivån. Detta görs via ett gränssnitt. Läs noga nu, för det här är viktigt: även om nivitetsredaktören endast används av dig eller ditt team, måste du göra gränssnittet intuitivt och enkelt att använda. Varför? Eftersom ingen gillar att arbeta med något som kräver att du trycker på en kombination av knappar eller klickar på en massa knappar för att lägga till något så enkelt som ett objekt på skärmen. Och det inkluderar dig och ditt lag.
Även om du är den som skapade den och vet allt om redaktören, gör det lätt att använda gränssnittet att alla lägger till innehåll i spelet. Och om någon råkar glömma genvägen för hur man markerar ett objekt som "kolliderbart", till exempel, då ett intuitivt gränssnitt kommer att vara en stor hjälp.
Här är ett faktiskt exempel - en enkel nivåredigerare som jag skapade för ett Windows Phone 7-kedjereaktionsspel:
Som du kanske har märkt finns hela nivåredigeraren inuti Adobe Flash Professional-programvaran - jag skapade inte en separat app. Flash Pro var en perfekt miljö: det krävde ingen ansträngning för att skapa något för att hantera ritningsgrafik på skärmen för mig, eftersom jag tittade på ett enkelt verktyg för att hjälpa mig att skapa nivåerna för spelet. Det enda jag behövde gjorde var att skapa en mycket enkel förlängning (som du kan se på videon) för att spara all den nivåinformation någonstans för mig (jag använde en XML-fil).
Allt annat hanterades för mig av Flash Pro: jag kunde ställa in skärmstorleken exakt till min spelets skärmstorlek, jag kunde placera alla föremål i sin riktiga storlek på skärmen och infoga guider för att hjälpa mig att visualisera var bilderna skulle gå efter en objektet hade exploderat. Testprocessen var lika enkelt som att "kompilera" projektet i Flash, vilket skulle öppna ett fönster där man frågade var man skulle spara XML-filen; när jag sammanställde mitt spel igen, skulle det läsa den uppdaterade XML-filen.
Nu, låt oss föreställa er att du har ett skjutspel. Har du någonsin försökt att skapa en förut? Det är irriterande (och komplicerat) att upprätta alla dessa fiendrörelser och skjutmönster via själva koden, och det är också tråkigt att ställa in tidpunkten.
Här är en shoot-up-level editor som jag skapade som ett annat experiment:
Detta är ett exempel på vad inte att göra. Även om min redaktör hade den grundläggande funktionaliteten att låta dig skapa fiendens rörelsemönster som du tyckte om och till och med inkluderade några hjälparfunktioner (i så fall speglade fienden jag redigerade för att skapa en "spegel" -effekt när fienderna uppträdde i spelet) gränssnittet var ett fullständigt fel.
Jag hade inte ett sätt att visualisera hela nivån på samma gång: allt jag kunde göra var att visualisera våg genom våg. Har du någonsin föreställt dig hur smärtsamt det skulle vara att ändra något på nivån så? Om jag till exempel vill fördröja spridningstiden mellan dagens vågors fiender med 400 millisekunder, skulle jag behöva gå igenom alla efterföljande vågor och lägga till (400ms * antal fiender ändras) till alla de första vågtiderna för de andra vågorna. För denna mycket grundläggande anledning slutade jag att behöva återskapa verktyget från början.
Att skapa skapningsverktyg är en mycket svår uppgift. Kanske är dessa det svåraste av alla andra verktyg att skapa, eftersom du kommer att hantera dem dagligen för att göra ditt spel. Du måste göra dem så snabba och enkla att använda som möjligt, och de får inte komma i vägen för att faktiskt göra innehållet för ditt spel. Om du upptäcker att du behöver spendera några minuter eller till och med timmar att ändra saker i din redaktör eftersom du ändrade något annat som måste åtgärdas, kanske du vill ompröva om verktyget tjänar sitt syfte.
Ett utmärkt tillvägagångssätt är att skapa redaktörer i spelet. Med dessa verktyg kan du ändra innehållet medan spelet körs och för att testa vad du ändrade vid körtid.
Verktyg som dessa driver din produktivitet till gränsen, eftersom du har snabb återkoppling om de ändringar du har gjort. Vissa redaktörer tillåter dig att ändra även värdet på attribut som ditt spel körs, så att du kan köra kommandon i realtid och titta på resultaten. Du kan också "böja tid" och spela in de åtgärder du gjorde i spelet, ändra sedan attribut i ditt spel (gravitation, till exempel) och se hur rörelsen för spelaren som gör samma åtgärder skulle se ut under den nya miljön.
Ta en titt på det här exemplet av en redigerare för spelkartan för ett spel i utveckling, Bekymrad Joe:
Det här är förmodligen en programmerares bästa vänner. När något går fel med ett spel hjälper felsökningsverktyg dig att ta reda på vad det var. De kan också visa statistik om ditt spel, granska processen tid för varje funktion som kallas i din kod, ge minnesdump när något misslyckas, skapa loggar så länge programmet körs och mer.
När du programmerar ett spel använder en programmerare ofta många av dessa verktyg, särskilt utvecklingsmiljöens egen debugger, om den har en. Men många andra verktyg kan skrivas för att hjälpa till med spelutvecklingsprocessen på detta område.
För ett mycket komplext spel vill du ofta kunna återställa funktionssamtalstacken när något kraschar (så du vet exakt vilken kodlinje som orsakade kraschen) och genererar loggar så ofta du kan. Självklart måste du kunna tolka dessa loggar. Kanske kan ett verktyg som hjälper dig att analysera loggar komma till nytta ...
Titta till exempel på det här verktyget som skapats av Adobe, som heter SWF Investigator:
Det här verktyget, som skapats för att analysera SWF-filer, gör det möjligt för utvecklaren att undersöka olika saker i sitt spel, inklusive kodanalys (det går att demontera SWF för att undersöka exakt vad applikationen gör), vilket är mycket viktigt för en spelutvecklare - speciellt när man optimerar kod.
Uppgiften att skriva ett felsökningsverktyg är dock mycket svårt. Inte för att det måste ha ett "perfekt" gränssnitt som skapningsverktyg; ofta används dessa verktyg endast av programmerare och kärnutvecklingsteamet, och gränssnittet spelar ingen roll den där mycket. (Naturligtvis måste det fortfarande kunna visa allt som är viktigt för dig och låter dig manipulera saker genom det med lätthet.) Nej, det är svårt på grund av den enorma mängd tekniska detaljer som måste gå in i dem.
Dessa verktyg kan dock hjälpa dig att göra ditt spel bättre på spelarnas plattformar, vilket givetvis är mycket viktigt.
Distributionsverktyg behövs när du arbetar med olika aspekter av spelet (kanske en artist och en programmerare) och när du utvecklar för flera plattformar. När du utvecklar för flera plattformar måste du ta hänsyn till skärmens storlek på varje enhet (särskilt för mobila spel) och de tekniska begränsningarna för varje plattform.
Tänk dig att utveckla ett spel för en smartphone med en upplösning på 1280x768 och en tablett med en upplösning på 1920x1200. Du kommer antagligen vilja använda två olika uppsättningar bilder för varje enhet, eftersom du inte vill använda bilder för smarttelefonen och skala upp dem för tabletten - det skulle se fult ut. Dessutom har din smartphone förmodligen inte tillräckligt med minne och bearbetningseffekt för att hantera de stora bilderna du använder för din surfplatta. På grund av det behövs ett distribueringsverktyg som hjälper dig att hantera tillgångarna för ditt spel.
Prata om att hantera tillgångar, anta nu att du arbetar i ett lag, som består av en artist och en programmerare. Konstnären kommer definitivt att skapa en hel del konsttillgångar, men hur går det med programvaran som refererar till dessa konstfiler i spelet? Det snyggaste tillvägagångssättet är att bara ändra eller lägga till namnet på filen på alla ställen där koden använder den när konstnären ändrar eller lägger till artefiler. För stora projekt är det emellertid inte möjligt, eftersom det skulle ta bort bra utvecklingstid.
Ett bra sätt att hantera det skulle vara att skapa ett verktyg för att hantera konsttillgångar för laget: artisten anger helt enkelt vilken artfil som refererar till vad och verktyget automatiskt konverterar filernas namn till ett fördefinierat namn som själva verktyget anger . På så sätt behöver programmeraren inte oroa sig för att ändra namn i koden när konstnären ändrar något.
Dessa verktyg är lätta att förbise, men du borde definitivt använda dem i dina spel. Verktyg för utgåva hjälper dig att spåra hur ditt spel gör det ute på marknaden och hur spelarna tar emot det.
Det här är väldigt viktigt för virus- och mobilspel, men skrivbordsspel kan också dra nytta av dessa verktyg. De låter dig spåra var spelet är tillgängligt och hur många spelare som har spelat ditt spel. De kan gå ännu längre: verktyg som Playtomic, Mochi Analytics och GamesAnalytics kan spåra hur många gånger en given nivå spelades, hur många gånger en knapp klickades, hur många spelare släppte ditt spel (i första minuten, första fem minuter, andra nivå, och så vidare) och mer. Du kan då använda denna information för att utgå ifrån att en viss nivå är för svår (baserat på antalet spelare som inte slutför det) och sedan fixa det.
Det finns mer: du kan också skriva verktyg för att spåra den offentliga mottagningen av ditt spel på internet, med hjälp av robotar som samlar in information om Facebook-inlägg eller Tweets som innehåller ditt spelets namn, visar vilka översynssidor som har granskat ditt spel och så vidare. Låt oss inte heller glömma Google Alerts, ett bra verktyg som meddelar dig när en viss term visas på webben.
Även om du verkligen behöver använda sig av verktyg för att hjälpa din spelutvecklingsprocess, ibland hittar du att du inte behöver faktiskt skapa dem, eftersom spelet utvecklingssamhället har skapat många verktyg redan.
Många utmärkta spelverktyg finns där ute online, tillgängliga för dig att använda - det tar bara lite tid att hitta dem. Men använd dem med försiktighet: om du känner ett verktyg inte gör exakt vad du behöver kan det vara bättre att skriva egna än att slösa bort tiden som vrider den för att passa ditt spel. Detta är ofta fallet för spel- eller genre-specifika verktyg.
Att skapa ett verktyg är ett stort ämne som förtjänar flera artiklar på egen hand, men jag ger dig ett tips här: du måste ofta standardisera hur du hanterar ditt spelets innehåll. Det betyder att du måste komma fram till ett sätt att lagra ditt spelets information, kunna ladda det och spara det. De flesta använder XML eller JSON för att beskriva information, men du kanske vill skapa ditt eget binära format om du behöver ett mer specifikt sätt att beskriva saker.
Det är slutet på min analys av de olika verktygen som du kan använda för att hjälpa dig med din spelutveckling. Jag hoppas att du tyckte om artikeln och lärde dig det! Om du har några frågor, tveka inte att fråga.
Redaktörens anmärkning: Vi ska sammanställa en lista med bra verktyg som Ogmo Editor, Tiled, och SFXR. Om du har några förslag, låt oss veta!
Accentsconagua