Jeg forsøgte at lave den samme 2D-spilprototype i React, Unity, Godot, Construct, Game Maker og Phaser. Her er hvad jeg fandt.

Jeg er en spiludvikler på bordpladen. Da jeg designede et nyt kortspil, besluttede jeg at bygge en digital prototype til at hjælpe mig med at køre simuleringer og nemt dele et bevis på konceptet med samarbejdspartnere.

Jeg har en vis baggrund i JavaScript og C #, og jeg angiver, som mange gør: ved at bruge uforholdsmæssig lang tid i "hvilke rammer skal jeg bruge" tråde og læse dokumentation uden faktisk at lave noget.

Blitz fremad i mange måneder, og jeg har nu brugt mere tid på at arbejde i (og bryde med) React, Unity, Godot, Construct 3, Game Maker Studio 2 og Phaser 3 i et forsøg på at forstå, hvad der får dem til at kryds.

Ganske vist tror jeg, at jeg har brugt meget mere tid på hver af dem end nødvendigt for at lave mit lille spil, og jeg kunne sandsynligvis bare have holdt fast i det første og tabt mig gennem prototypen. Jeg håber nedenstående information vil være nyttigt for alle andre, der handler efter en motor eller ramme.

En masse advarsler: Jeg forsøger ikke at sælge en motor eller en ramme over de andre, og jeg antyder heller ikke, at en eller nogen af ​​disse rammer fungerer bedre for dit spil end en anden. Jeg sammenligner heller ikke priser, backend-funktionalitet eller platforminstallation. Så afhængigt af dine krav kan nedenstående oplysninger have forskellige værdier for dig.

Derudover er denne oplevelse baseret på udvikling af et 2D-kortspil, så jeg vil ikke diskutere 3D-motorer, fysik osv.

Du kan også springe til bunden for TL; DR.

Prototypen

Mit spil, Entromancy: Hacker Battles , er et konkurrencedygtigt cyberpunk-kortspil med TCG- lysmekanik . Du kan læse mere på vores hjemmeside eller se, hvordan det er meningen at blive spillet i denne video. Men det er tilstrækkeligt at sige, at det som et kortspil kræver en potentiel digital ramme for at understøtte grundlæggende ting som statsstyring, UI, træk-og-slip UX og back end-kroge til implementering af multiplayer.

I betragtning af disse krav udforskede jeg følgende rammer og motorer for at se, hvilken der ville være bedst til at lave mit spil ... i stedet for faktisk at lave spillet (jeg er glad for at sige, at nu hvor jeg har slået mig ned på en ramme, Jeg gør meget mere fremskridt).

Du kan få adgang til en spilbar version her, og selvom spillet er længere, end den levende prototype antyder, er denne version ret stabil (i det mindste i Chrome).

Reagere

Efter at have allerede bygget en karaktergeneratorprototype i React til en bordplade, RPG, jeg designede, troede jeg, at et naturligt skridt ville være at give rammen et spin til kortspillet. Jeg fandt statsadministration som en leg (det er jo, hvad React gør ), mens implementering af simpel træk-og-slip-funktionalitet til kort viste sig at være et mareridt.

Der er nogle biblioteker derude, der kan hjælpe med grundlæggende træk-og-slip (f.eks. React DnD), men jeg fandt ud af, at jeg med et kortspil havde brug for en mere elegant løsning til dropzones, da Hacker Battles er meget specifikke for hvilke kort der kan spilles hvor og hvornår.

Denne oplevelse fik mig til at tjekke boardgame.io, som kan arbejde sammen med React. Men dette krævede i sidste ende, at jeg lærte en anden ramme oven på en eksisterende ramme, som ikke var ideel til mine formål.

Enhed

Af generel interesse havde jeg brugt meget tid på Unity på at lave tutorials og lære at bruge redaktøren, før jeg forsøgte at genskabe kortspilprototypen med den. Aktivbutikken er en stor ressource, og der er så meget dokumentation, officiel og uofficiel, derude, at jeg var overbevist om, at jeg kunne finde et svar på ethvert problem, jeg måtte støde på.

Min erfaring med Unity hidtil har været en blandet taske. Jeg nyder virkelig at arbejde i C #, og alt kode-relateret har været en relativt smertefri oplevelse. Enhed er dog meget specifik for dens implementering og kan til tider føles kontraintuitiv.

Redaktøren er derimod en bjørn at arbejde med. For at udnytte Unitys fulde potentiale skal du bruge en god lang tid, mens du kæmper med brugergrænsefladen for at forstå, hvor alt er, og hvordan man bruger det. Det er også desperat bag tiden med 2D-spiludvikling og forsøger tydeligt at flade en primært 3D-motor ind i et 2D-plan med blandede resultater.

For at være retfærdig kan jeg godt lide at arbejde i Unity-editoren, klodset som det er. Men hvis du leder efter en 2D-spilmotor, vil din livskvalitet være meget højere andre steder (se en video på Unitys animationssystem eller opnå pixelperfektion, og du vil se, hvad jeg mener).

I sidste ende er Unitys håndtering af 2D-rummet lidt mere kompleks, end jeg har brug for til min prototype, men jeg vender tilbage til det for andre typer spil.

Også et sidebjælke, der kan være nyttigt for nogle: Jeg var oprindeligt meget begejstret for aktivbutikken med ideen om, at jeg kunne købe en kortspilskabelon, der ville gøre udviklingsprocessen meget lettere for mig. Det fungerede ikke. De fleste af dem var MTG / Hearthstone / osv. kloner, der ville kræve lige så meget udviklingstid fra min side for at omstrukturere dem til mit kortspil, som det bare ville starte fra bunden.

Godot

Min første tanke ved at møde Godot var: "open source-spilmotor, der understøtter C #? Tilmeld mig!" Derefter downloadede jeg det, arbejdede igennem et par grundlæggende vejledninger og fik det til at gå ned. Hurm.

Flere Google-søgninger, geninstallationer og hår trukket senere, jeg regnede med, at det havde noget at gøre med min version af VS Build (tror jeg?), Hvilket førte mig ned ad et separat kaninhul. Jeg vidste af erfaring, at andre motorer - enhedschef blandt dem - kunne forårsage spilbrudsproblemer helt uden for din egen kode, men dette var en irriterende forhindring, der sandsynligvis farvede resten af ​​min oplevelse med Godot.

Med hensyn til redaktøren kunne jeg godt lide Godots node-baserede implementering, som jeg faktisk fandt kontraintuitiv fra Unity's præfabrikker, men til sidst blev varm til. Jeg vil faktisk gå så langt som at sige, at dens 2D-funktionalitet er bedre end Unity, men den mangler samfundet, aktivbutikken (se sidebjælke ovenfor) og især den dokumentation, som Unity har. Hvis du f.eks. Har til hensigt at arbejde i C # med Godot, skal du være parat til at kigge efter svar i motorens brugerdefinerede GDScript og derefter oversætte dem til C #.

Jeg har dog hørt om folk, der oplever stor succes med Godot, mens de bruger GDScript, så hvis du er villig til at investere tid til at lære det, kan du nyde det, Godot har at tilbyde.

Konstruktion 3

I de forbehold, som jeg nævnte ovenfor, nævnte jeg, at jeg ikke inkluderer prissætning som et diskussionspunkt. Alligevel føler jeg, at jeg har brug for at bringe det op med Construct 3, da det viste sig at være indflydelsesrig i min oplevelse.

I modsætning til de andre spilmotorer, der er anført her, og som for det meste er gratis at bruge (Game Maker Studio 2 har en 30-dages gratis prøveperiode), er langt størstedelen af ​​Construct's funktionalitet bag en betalingsmur og et abonnementsgebyr på at. Ugh.

Jeg kan virkelig godt lide udskæringen af ​​Construct's fok til enkle 2D-spil. Editoren føles lidt som en opgradering fra MS Paint, men den håndterer sprite og objektadministration rigtig godt og er simpelthen nem at bruge. Jeg elsker ikke, at det bruger en "visual scripting" -stil, men de har for nylig tilføjet funktionen til at skrive almindelig gammel JavaScript, og det ser ud til at virke mere eller mindre.

Jeg var i stand til at spinde en meget rudimentær arkitektur op for prototypen på kort tid, før jeg lukkede Construct 3-demoen (som kører i en browser) ... og derefter prøvede det hele igen senere med en ny demo. Jeg har lyst til, i det mindste for dette kortspil, kunne jeg gøre meget med Construct 3, men jeg er bare ikke villig til at betale $ 99 / år (eller mere, som en virksomhed) for en prototype.

Game Maker Studio 2

YoYo Games har tydeligvis gjort en masse arbejde for at gøre Game Maker Studio 2 tilgængelig og let navigerbar, og det viser. Af alle de motorer, jeg har brugt til dette projekt, kan jeg godt lide GMS-editoren. For et lille projekt er det let at finde rundt og gå rundt i din virksomhed. Jeg formoder dog, at et større projekt måske går ud af hånden ret hurtigt.

Dette kan være påvirket af Game Maker Studios proprietære sprog, GML (selvom GMS 2 understøtter visuel scripting, som jeg ikke brugte). Det fungerer, men hvis du kommer til det fra et andet OOP-sprog (eller i sandhed ethvert andet almindeligt anvendt sprog), kan du muligvis ridse dit hoved ved implementeringen eller finde ud af, hvordan du gør nogle ting. Hvis du er nybegynder eller er villig til at bruge tid på at finde ud af, hvordan GMS vil have dig til at bruge GML, vil du sandsynligvis have det godt.

Jeg oplevede en del quirkiness med Game Maker Studios træk-og-slip-funktionalitet - nemlig detektering af musemarkøren ved trækning er lidt uhyggelig og kræver noget stillads for at få arbejdet korrekt.

Jeg tror - og dette er helt personlig præference og dovenskab fra min side - at hvis GMS tilbød muligheden for at bruge et andet, ikke-proprietært programmeringssprog, ville jeg bruge tiden på at gøre mere skade her. Jeg er alt sammen for at udjævne flere færdigheder, mens jeg arbejder, mens det at bruge tid på at blive ekspert i GMS-editoren og GML uden at være i stand til let at anvende den viden andetsteds ikke ser ud til at være værd.

Alligevel er det en smuk brugbar 2D-editor, og selvom samfundsstøtten muligvis ikke er på niveau med Unity, er den stadig ret god. Pas også på, at når din gratis prøveperiode er slut, skal du betale for at fortsætte med at bruge Game Maker Studio 2.

Phaser 3

Phaser er en letvægts JavaScript-spilramme med open source. Der er nogle Phaser IDE'er, men hvis du er af den slags, der primært vil arbejde i kode, kan du komme til at ende her ved hjælp af Atom, Sublime eller din foretrukne editor.

Phaser 2 var og er meget brugt og veldokumenteret med masser af selvstudier at trække på. Phaser 3 er det modsatte. Det har en forholdsvis høj indlæringskurve for begyndere med en masse eksempler og ikke meget sammenhæng omkring dem.

Mange tutorials derude understøtter Phaser 2, og mens læringen kan overføres, er koden ikke. Derudover meddelte devs for nylig, at de flytter support til Phaser 4 (og TypeScript snarere end ES6), hvilket ikke er godt, hvis du har brugt tid på at arbejde i Phaser 3.

Hvis du ikke er en professionel programmør (jeg er ikke) og er opdateret med ES6-klasser og JavaScript-bedste fremgangsmåder (det var jeg ikke), bliver du måske hurtigt frustreret over Phasers manglende håndtering og at skulle konfigurere din egen IDE og arbejdsgang (jeg var).

Imidlertid har jeg fundet det at være en stærk, let ramme, der gør en masse ting på en meget mere strømlinet måde end andre spilmotorer. Træk-og-slip-funktionalitet til kortspillet har været en relativ brise, og evnen til at adskille korttyper i klasser (som f.eks. Unity's præfabrikker) har opdelt noget af den kognitive belastning, som denne slags spil kræver.

Hvis du er en frontend-udvikler, kan du måske lide eller være fortrolig med hårde kodende pixelkoordinater til alt, men sheesh, er dette omhyggelige arbejde. Derudover, hvis du ikke er opdateret med alt JavaScript, vil du sandsynligvis søge efter svar i ikke-Phaser-cirkler og derefter anvende dem på dit projekt, hvilket har sin egen fordel, formoder jeg.

En anden tone i tilfælde det er ikke klart: Phaser 3 gør har en hel del af officiel dokumentation og eksempler, men det har ikke har fællesskabet eller Stack Overflow svarer, at en masse andre spil motorer nyde. Hvis du løber ind i et problem eller ikke kan finde ud af noget, skal du finde ud af din egen løsning eller placere dit spørgsmål på Phaser Discord-serveren, hvilket har været nyttigt i min erfaring.

Konklusion

I betragtning af alt det ovenstående er den prototype, jeg har holdt fast i og fortsætter med at gentage, den, jeg har bygget med Phaser 3. Jeg er klar over, at dette kan være anti-climactic, da Phaser ikke i sagens natur er "bedre" end andre rammer og motorer ved 2D-spiludvikling (undtagen måske React, som ikke forsøger at være en konkurrent i det digitale spilrum).

Phaser ser dog ud til at håndtere træk-og-slip-styring af spilsløjfe til Hacker Battles mere jævnt, og til mine formål er det vigtigt. Jeg nyder også at bruge Phaser kræver, at jeg investerer mere i JavaScript-økosystemet (-erne) og samfund, men jeg er interesseret i at gøre det alligevel, så det føles som en bonus.

Hvis du er mere af typen "hvad kan jeg bruge til at opbygge noget hurtigt og ikke være ligeglad med den sammenhæng, hvor motoren er placeret", YMMV.

TL; DR

Reager: fantastisk til frontend-udvikling. Ville ikke bruge det til spil, især træk og slip.

Enhed: Du kan lave enhver type 2D-spil, hvis du er villig til at kæmpe med redaktøren og de underliggende 3D-idiosynkrasier. Stor community support, og C # er fantastisk. Aktivbutik findes, men er muligvis ikke nyttig til dine formål.

Godot: open source og understøtter GDScript, C #, endda C ++ og Python, hvis du er villig til at gøre meget af det tunge løft. Gode ​​2D-implikationer, men ikke nær så meget samfundsstøtte som noget som Enhed. Min erfaring var også buggy.

Construct 3: virkelig nem at bruge, høj adgangsbarriere på grund af abonnementets betalingsvæg. Visuel scripting kan gå på dine nerver, hvis du ønsker at bruge eller lære kode, selvom der nu er en vis JavaScript-understøttelse.

Game Maker Studio 2: brugervenlig editor med god community support. GML eller visuel scripting er måske ikke din kop te, hvis du kommer fra et andet mere populært programmeringssprog, men hej, når du er i Rom. Kræver også betaling efter en 30-dages gratis prøveperiode.

Phaser 3: forvent at kode alt, og gør en masse søgning for at finde ud af, hvordan man får tingene til at fungere. Det fungerer for mig til netop dette spil og prototype, men Phaser 4 er på vej, så der er det.

Jeg håber, at dette indlæg er nyttigt i din egen søgning og skelneproces. Jeg vil meget gerne høre om dine egne oplevelser med nogen af ​​disse rammer / motorer eller andre!

Hvis du kunne lide denne artikel, kan du overveje at tjekke mine spil og bøger, abonnere på min YouTube-kanal eller deltage i Entromancy Discord.

MS Farzan, Ph.D. har skrevet og arbejdet for højt profilerede videospilvirksomheder og redaktionelle websteder som Electronic Arts, Perfect World Entertainment, Modus Games og MMORPG.com og har fungeret som Community Manager for spil som Dungeons & Dragons Neverwinter og Mass Effect: Andromeda . Han er Creative Director og Lead Game Designer af Entromancy: A Cyberpunk Fantasy RPG og forfatter af The Nightpath Trilogy . Find MS Farzan på Twitter @sominator.