Püüdsin teha sama 2D-mängu prototüübi rakendustes React, Unity, Godot, Construct, Game Maker ja Phaser. Siin ma leidsin.

Olen lauamängude arendaja. Uue kaardimängu kujundamisel otsustasin ehitada digitaalse prototüübi, mis aitaks mul simulatsioone käivitada ja hõlpsasti ideed tõestada.

Mul on JavaScripti ja C # -ga teatud taust ning panin paika sama, mida paljud teevad: kulutades lõputult palju aega lõikudes "millist raamistikku peaksin kasutama" ja lugedes dokumente, ilma et midagi tegelikult teeks.

Kiiresti edasi mitu kuud ja olen nüüd veetnud rohkem aega React, Unity, Godot, Construct 3, Game Maker Studio 2 ja Phaser 3 töös (ja nendega maadlemises), püüdes mõista, mis neid tiksuma paneb.

Tõsi küll, ma arvan, et olen veetnud igas neist palju rohkem aega kui vaja, et oma väikest mängu teha, ja ilmselt oleksin võinud lihtsalt esimese juurde jääda ja prototüübist läbi peksta. Loodan, et alltoodud teave on kasulik kõigile teistele, kes ostavad mootorit või raamistikku.

Hunnik hoiatusi: Ma ei ürita müüa üht mootorit või raamistikku teiste peale ega soovita ka, et üks või mõni neist raamistikest sobiks teie mängu jaoks paremini kui teine. Ma ei võrdle ka hinnakujundust, taustaprogrammi funktsionaalsust ega platvormi juurutamist. Nii et sõltuvalt teie nõudmistest võib allpool olev teave teie jaoks erineva väärtusega olla.

Lisaks põhineb see kogemus 2D-kaardimängu arendamisel, nii et ma ei hakka arutama 3D-mootoreid, füüsikat jne.

Võite ka TL; DR jaoks alla hüpata.

Prototüüp

Minu mäng Entromancy: Hacker Battles on konkurentsivõimeline küberpungi kaardimäng TCG-kerge mehaanikaga. Sellest videost saate lugeda rohkem meie veebisaidilt või vaadata, kuidas seda mängitakse. Kuid piisab sellest, kui öelda, et kaardimänguna nõuab see potentsiaalset digitaalset raamistikku, et toetada selliseid põhilisi asju nagu osariigi haldamine, kasutajaliides, lohistatav kasutajaliides ja mitmikmängu juurutamiseks mõeldud konksud.

Arvestades neid nõudeid, uurisin ma järgmises raamistikus ja mootorid näha, millest üks oleks kõige sobivam teha oma mängu ... asemel tegelikult tegemise mäng (Mul on hea meel öelda, et nüüd, et ma olen arveldada raamistik, Ma teen palju rohkem edusamme).

Mängitavale versioonile pääseb siit ja kuigi mäng on kaugemal, kui live-prototüüp soovitab, on see versioon üsna stabiilne (vähemalt Chrome'is).

Reageeri

Olles juba välja töötanud Reactis oma loodud lauaplaadi RPG jaoks tegelasgeneraatori prototüübi, arvasin, et loomulik samm oleks anda kaardimängule raamistik. Leidsin riigi haldamine oleks imelihtne (see, mida Lasta ei ju), samas rakendades lihtne drag-and-drop funktsiooni kaarte osutunud õudusunenägu.

Seal on mõned raamatukogud, mis võivad aidata lohistada ja lohistada (nt React DnD), kuid leidsin, et kaardimängu puhul vajasin tilkade jaoks elegantsemat lahendust, kuna Hacker Battles on väga konkreetne, milliseid kaarte saab kus ja millal mängitakse.

See kogemus viis mind kontrollima boardgame.io lehte, mis võib töötada koos Reactiga. Kuid see nõudis minult lõppkokkuvõttes olemasoleva raamistiku peal veel ühe raamistiku õppimist, mis oli minu jaoks vähem kui ideaalne.

Ühtsus

Üldisest huvist lähtudes olin veetnud palju aega Unity's, tehes õpetusi ja õppides redaktori kasutamist, enne kui proovisin sellega kaardimängu prototüüpi ümber teha. Varade pood on suurepärane ressurss ning seal on nii palju ametlikke ja mitteametlikke dokumente, et olin kindel, et leian vastuse igale probleemile, mis mul tekkida võib.

Minu senine kogemus Unityga on olnud segakott. Mulle meeldib väga töötada C # -s ja kõik koodiga seotud asjad on olnud suhteliselt valuvabad kogemused. Kuid Unity on selle rakendamise osas väga spetsiifiline ja võib kohati tunda end intuitiivselt.

Toimetaja seevastu on karu, kellega koos töötada. Ühtsuse täieliku potentsiaali ärakasutamiseks peate kasutajaliidese abil maadeldes veetma palju aega, et mõista, kus kõik on ja kuidas seda kasutada. Samuti on see 2D mängude arendamisega meeleheitlikult ajast maha jäänud, püüdes selgelt 3D-mootorit 2D-tasapinnaks lamendada, vastakate tulemustega.

Aususe huvides on mulle üsna meeldiv töötada Unity toimetuses, kohmakas nagu see ka pole. Kuid kui otsite 2D-mängumootorit, on teie elukvaliteet mujal palju parem (vaadake videot Unity animatsioonisüsteemist või piksli täiuslikkuse saavutamisest ja näete, mida ma mõtlen).

Lõppkokkuvõttes on Unity 2D-ruumi käsitsemine natuke keerulisem, kui mul prototüübi jaoks vaja läheb, kuid naasen selle juurde muud tüüpi mängude puhul.

Samuti külgriba, mis võib mõnele kasulik olla: olin algselt varakauplusest äärmiselt põnevil, ideega, et võiksin osta kaardimängu malli, mis muudaks arendusprotsessi minu jaoks palju lihtsamaks. See ei õnnestunud. Enamik neist olid MTG / Hearthstone / jne. kloonid, mis vajaksid minu kaardimängu jaoks nende ümberkorraldamiseks sama palju arendusaega kui lihtsalt nullist alustamine.

Godot

Minu esimene mõte Godotiga kohtudes oli: "avatud lähtekoodiga mängumootor, mis toetab C # -d? Registreeruge mind!" Siis laadisin selle alla, töötasin läbi paar põhilist õpetust ja lasin selle ehitamisel kokku kukkuda. Hurm.

Mitu Google'i otsingut, uuesti installimist ja hiljem tõmmatud karvu sain aru, et see on midagi pistmist minu VS Buildi versiooniga (ma arvan?), Mis viis mind eraldi küülikuaugust alla. Teadsin oma kogemusest, et muud mootorid - nende seas ka Unity juht - võivad põhjustada mängu murdvaid probleeme, mis jäävad täielikult väljapoole teie enda koodi, kuid see oli tüütu tõke, mis tõenäoliselt värvis mu ülejäänud kogemusi Godotiga.

Toimetaja osas meeldis mulle üsna Godoti sõlmepõhine teostus, mille leidsin tegelikult Unity prefabidest pärineva intuitiivse intuitiivsena, kuid lõpuks soojendasin. Ma ütleksin tegelikult nii kaugele, et ütlen, et selle 2D-funktsioon on parem kui Unity oma, kuid sellel puudub kogukond, varahoidla (vt ülaltoodud külgriba) ja eriti dokumentatsioon, mis Unityl on. Kui kavatsete töötada näiteks Godot'is C # -ga, siis olge valmis otsima vastuseid mootori kohandatud GDScriptist ja seejärel tõlkima need C # -ks.

Olen siiski kuulnud inimestest, kes GDScript'i kasutamise ajal Godotiga väga edukalt hakkama saavad, nii et kui olete valmis investeerima aega selle õppimiseks, võiksite nautida seda, mida Godot pakub.

Ehitada 3

Eespool loetletud hoiatustes mainisin, et ma ei hõlma hinnakujundust arutelu punktina. Siiski tunnen, et pean selle Construct 3-ga üles tooma, kuna see osutus minu kogemuste põhjal mõjukaks.

Erinevalt teistest siin loetletud mängumootoritest, mis on enamasti tasuta kasutatavad (Game Maker Studio 2-l on 30-päevane tasuta prooviversioon), on valdav osa Construct'i funktsionaalsusest tasulise seina taga ja liitumistasu seda. Uhh.

Mulle meeldib väga- väga Construct'i lihtsate 2D-mängude noole lõik. Redaktor tunneb end natuke nagu MS Paint'i versiooniuuendus, kuid see tegeleb sprite'i ja objektide haldamisega tõesti hästi ning seda on lihtsalt lihtne kasutada. Mulle ei meeldi, et see kasutab "visuaalse skriptimise" stiili, kuid nad on hiljuti lisanud tavalise vana JavaScripti kirjutamise funktsiooni ja tundub, et see töötab enam-vähem.

Sain lühikese aja jooksul prototüübi jaoks väga algelise arhitektuuri üles ehitada, enne kui sulgesin demo Construct 3 (mis töötab brauseris) ... ja proovisin siis seda kõike hiljem uue demoga uuesti proovida. Ma tunnen, et vähemalt selle kaardimängu puhul saaksin Construct 3-ga palju ära teha, kuid ma pole lihtsalt nõus prototüübi eest maksma 99 dollarit aastas (või rohkem kui ettevõte).

Game Maker Studio 2

YoYo Games on selgelt teinud palju tööd, et muuta Game Maker Studio 2 ligipääsetavaks ja hõlpsasti navigeeritavaks ning see näitab ka seda. Kõigist mootoritest, mida olen selle projekti jaoks kasutanud, meeldib mulle kõige rohkem GMS-i toimetaja. Väikese projekti jaoks on lihtne orienteeruda ja oma asju ajada. Ma kahtlustan, et suurem projekt võib üsna kiiresti käest ära minna.

Seda võib mõjutada Game Maker Studio varaline keel GML (kuigi GMS 2 toetab visuaalset skriptimist, mida ma ei kasutanud). See töötab, kuid kui tulete selle juurde mõnest muust OOP-keelest (või tõepoolest mõnest muust laialt kasutatavast keelest), võite rakenduse juurutamisel pead krabada või nuputada, kuidas mõningaid asju teha. Kui olete algaja või soovite veeta aega, et teada saada, kuidas GMS soovib, et kasutaksite GML-i, on teil tõenäoliselt kõik korras.

Game Maker Studio pukseerimisfunktsioonide abil kogesin mõningast kummalisust - nimelt on hiirekursori tuvastamine lohistamisel veidi kohmakas ja nõuab korrektseks tööks mõningaid tellinguid.

Ma arvan - ja see on minu poolt täiesti isiklik eelistus ja laiskus -, et kui GMS pakuks võimalust kasutada mõnda muud, mitteomandit programmeerimiskeelt, veedaksin ma siin rohkem kahju. Ma olen kõik selle nimel, et töötamise ajal saaksin täiustada mitut oskust, samas kui GMS-i toimetaja ja GML-i eksperdiks saamise aja veetmine ilma nende teadmiste hõlpsaks rakendamiseks mujal ei tundu olevat kasulik.

Sellegipoolest on see üsna toimiv 2D-redaktor ja kuigi kogukonna tugi ei pruugi olla Unity omaga võrdne, on see siiski päris hea. Samuti pidage meeles, et kui teie tasuta prooviversioon on läbi, peate maksma Game Maker Studio 2 kasutamise jätkamise eest.

Phaser 3

Phaser on kerge, avatud lähtekoodiga JavaScripti mängude raamistik. Ümberringi on mõned Phaseri IDE-d, kuid kui olete selline, kes soovib töötada peamiselt koodis, võite siin lõpetada, kasutades Atomi, Sublime'i või oma lemmiktoimetajat.

Phaser 2 oli ja on laialdaselt kasutusel ning hästi dokumenteeritud, kasutades selleks palju õpetusi. Phaser 3 on vastupidine. Sellel on algajatele suhteliselt kõrge õppimiskõver, hulga näiteid ja nende ümber pole palju konteksti.

Paljud sealsed õpetused toetavad Phaser 2-d ja kuigi õppimine on teisaldatav, pole kood seda. Lisaks teatasid arendajad hiljuti, et viivad toe üle Phaser 4-le (ja pigem TypeScripti kui ES6-le), mis pole tore, kui olete veetnud aega Phaser 3-s töötades.

Kui te pole professionaalne programmeerija (ma ei ole) ja teete ES6-klasside ja JavaScripti parimate tavadega kursis (ma ei olnud), võite kiiresti pettuda Phaseri käepidemete puudumise pärast ja peate oma oma IDE ja töövoog (olin).

Olen siiski leidnud, et see on võimas ja kerge raam, mis teeb paljusid asju palju sujuvamalt kui teised mängumootorid. Kaardimängu lohistamise funktsionaalsus on olnud suhteliselt imelihtne ning võimalus eraldada kaarditüübid klassidesse (umbes nagu Unity'i prefabid) on jaotanud osa kognitiivsest koormusest, mida selline mäng nõuab.

Kui olete kasutajaliidese arendaja, võib teile meeldida või olla mugav, kui kodeerite piksli koordinaadid kõvasti, kuid see on see vaevarikas töö. Lisaks, kui te pole kogu JavaScripti kursis, otsite tõenäoliselt vastuseid mitte-Phaseri ringkondadest ja rakendate neid siis oma projektis, millel on minu arvates ka oma eelis.

Üks teine ​​märkus juhuks, kui see pole selge: Phaser 3- l on küllaltki palju ametlikke dokumente ja näiteid, kuid sellel pole kogukonna ega Stack Overflow vastuseid, mida paljud teised mängumootorid naudivad. Kui teil tekib mõni probleem või te ei suuda midagi välja mõelda, peate välja mõtlema oma lahenduse või postitama oma küsimuse Phaser Discordi serverisse, mis on minu kogemuste põhjal olnud kasulik.

Järeldus

Kõike ülaltoodut arvesse võttes on prototüüp, millega olen kokku puutunud ja mida olen jätkuvalt korranud, Phaser 3-ga loonud. Mõistan, et see võib olla kliimavastane, kuna Phaser pole oma olemuselt "parem" kui muud raamistikud ja mootorid 2D-mängude arendamisel (välja arvatud võib-olla React, mis ei püüa olla konkurent digitaalses mänguruumis).

Phaser teeb, aga tundub, et hakkama drag-and-drop ja mäng loop haldamise Hacker Battles sujuvamalt ja minu eesmärkidel, mis on oluline. Mulle meeldib ka, et Phaseri kasutamine nõuab, et investeeriksin rohkem JavaScripti ökosüsteemi (de) ja kogukondadesse, kuid olen siiski huvitatud sellest, et see oleks boonus.

Kui olete pigem tüüp, mida ma saan kasutada, et midagi kiiresti üles ehitada ja mis ei hooli mootori asukohast?

TL; DR

Reageeri: suurepärane esiotsa arendamiseks. Ei kasutaks seda mängude jaoks, eriti lohistamiseks.

Ühtsus: võite teha mis tahes tüüpi 2D-mänge, kui olete valmis maadlema redaktori ja selle aluseks olevate 3D-eripäradega. Suur kogukonna tugi ja C # on vinge. Varahoid on olemas, kuid ei pruugi teie eesmärkidel kasulik olla.

Godot: avatud lähtekoodiga ja toetab GDScript, C #, isegi C ++ ja Pythoni, kui olete nõus palju rasket tõstmist tegema. Head kahemõõtmelised tagajärjed, kuid mitte nii palju kogukonna toetust kui midagi sellist nagu Unity. Samuti oli minu kogemus lollakas.

Construct 3: tõesti hõlpsasti kasutatav, kõrge sissepääsutakistus tellimuse tasulise müüri tõttu. Visuaalne skriptimine võib närvidele käia, kui soovite koodi kasutada või seda õppida, ehkki nüüd on JavaScripti tugi olemas.

Game Maker Studio 2: kasutajasõbralik toimetaja, millel on hea kogukonna tugi. GML või visuaalne skriptimine ei pruugi olla teie tass teed, kui olete pärit mõnest muust populaarsemast programmeerimiskeelest, kuid hei, kui olete Roomas. Samuti nõuab makse pärast 30-päevast tasuta prooviperioodi.

Phaser 3: oodake kõike kodeerima ja tehke palju otsinguid, et teada saada, kuidas asjad toimima panna. See töötab minu jaoks just selle mängu ja prototüübi jaoks, kuid Phaser 4 on teel, nii et see on olemas.

Loodan, et see postitus on teie otsingu- ja eristamisprotsessis kasulik. Tahaksin kuulda ka teie enda kogemustest (kogemustest) nende raamistike / mootorite või teiste kasutamisel!

Kui teile see artikkel meeldis, kaaluge palun minu mängude ja raamatute vaatamist, minu YouTube'i kanali tellimist või ühinemist Entromancy Discordiga .

MS Farzan, Ph.D. on kirjutanud ja töötanud kõrgetasemelistes videomängufirmades ja toimetuste veebisaitidel nagu Electronic Arts, Perfect World Entertainment, Modus Games ja MMORPG.com ning olnud kogukonnadirektorina selliste mängude jaoks nagu Dungeons & Dragons Neverwinter ja Mass Effect: Andromeda . Ta on filmi Entromancy: A Cyberpunk Fantasy RPG loovjuht ja juhtmängu kujundaja ning The Nightpath Trilogy autor . Leidke MS Farzan Twitterist @sominator.