Hoe om 'n JRPG te bou: Primer vir Spelontwikkelaars
Hierdie artikel is 'n hoë vlakoorsig om 'n Japannese Role Playing Game (JRPG) te skep soos die oorspronklike Final Fantasy-spel. Ons sal kyk na die argitektuur en stelsels wat die JRPG-raamwerk vorm, hoe om spelmodi te bestuur, hoe om kaarte te gebruik om die wêreld te vertoon, en hoe om RPG-strydstelsels te koördineer.
Nota: Hierdie artikel is geskryf met behulp van 'n Java-agtige pseudokode taal, maar die konsepte is van toepassing op enige spelontwikkelingsomgewing.
Die onwaarskynlike geboorteplek van JRPGs
Die Genre Praatjie
Vyf Redes Waarom Jou 'n JRPG Moet Maak
Bestuur Van Spelstaat
Onverwachte JRPG Geboorteplek
Slym - een van die ikoniese vyande van Dragon Warrior.
In 1983 het Yuji Horii, Koichi Nakamura en Yukinobu Chida gevlieg na Amerika en bygewoon AppleFest '83, 'n byeenkoms van ontwikkelaars wat hul nuutste skeppings vir Apple II gewys het. Hulle is weggeblaas deur die nuutste weergawe van 'n RPG genaamd Wizardry.
By terugkeer na Japan het hulle besluit om Dragon Warrior te skep, 'n RPG wat soortgelyk was maar gestroomlyn vir die NES. Dit was 'n groot treffer, wat die JRPG-genre definieer. Dragon Warrior het ook nie in Amerika gevaar nie, maar 'n paar jaar later het 'n ander wedstryd gedoen.
In 1987, is die oorspronklike Final Fantasy vrygelaat, wat een van die bekendste video-speletjies-franchises op Aarde uitgegee het, wat ten minste in die Weste die JRPG-ikoon geword het.
Spel genres word nooit presies gedefinieer nie - hulle is meer 'n fuzzy versameling van konvensies. RPG's is geneig om 'n nivelleringsstelsel te hê, een of meer spelerskarakters met vaardighede en statistieke, wapens en wapens, bestry- en eksplorasiemetodes en sterk vertellings; spel vordering word dikwels behaal deur die hele kaart te bevorder.
Japanese RPG is 'n RPG wat in Dragon Warrior-afdrukke gemaak is; hulle is meer lineêre, dikwels beurt-gebaseerde gevegte en daar is gewoonlik twee tipes kaarte: 'n wêreldkaart en 'n plaaslike kaart. Arketypale JRPGs sluit in Dragon Warrior, Final Fantasy, Wild Arms, Phantasy Star en Chrono Trigger. Die type JRPG waaroor ons gaan praat, is een soortgelyk aan 'n vroeë Final Fantasy.
1. Hulle hou dieTydtoets
Speletjies soos Final Fantasy VI en Chrono Trigger is nog steeds baie lekker om te speel. As jou 'n JRPG maak, leer jou 'n tydlose spelformaat wat moderne spelers nog baie ontvanklik is. Hulle skep 'n goeie raamwerk om jou eie draai en eksperiment te voeg - of dit nou in vertelling, aanbieding of meganika is. Dit is 'n goeie ding as jou 'n speletjie kan maak wat nog gespeel word en geniet dekades nadat dit die eerste keer uitgereik is!
2. Meganika Spel Baie Toegepas
Call of Duty, een van die gewildste FPS-speletjies in die wêreld, gebruik RPG-elemente; bloeiende sosiale speletjies rondom Farmville is basies 'n kloon van die Harvest Moon SNS RPG; En selfs wedrenne soos Gran Turismo het vlakke en ondervinding.
3. Beperking Foster Kreatiwiteit
Net soos 'n skrywer kan geïntimideer word deur 'n lee vel papier, kan spelontwikkelaars hulself verlam deur 'n groot aantal moontlike keuses wanneer hulle 'n nuwe speletjie ontwerp. Met 'n JRPG is baie van die keuses vir jou besluit, so jou het nie die keuse verlamming nie, jou kan die konvensies vir die meeste besluite volg en afwyk van konvensie by die punte wat vir jou saak maak.
4. Dit kan gedoen word as Solo-Projek
Final Fantasy word amper heeltemal deur 'n enkele programmeerder, Nasir Gebelli, gekodeer en hy doen dit in die samestelling! Met moderne gereedskap en tale is dit baie makliker om speletjies van hierdie tipe te skep. Die grootste deel van die meeste RPG-programme is nie inhoud nie - maar dit behoort nie die geval te wees vir jou spel nie. As jou dit 'n bietjie terugkoppel op die inhoud en fokus op kwaliteit oor kwantiteit dan is 'n JRPG 'n groot solo projek.
Om 'n span te kry, kan met enige speletjie help, en jou kan kuns en musiek uitkontrakteer, of 'n paar baie goeie gesamentlike kreatiewe bates gebruik van plekke soos opengameart.org. (Redakteur se nota: Ons susterwebwerf GraphicRiver verkoop ook sprite sheets.)
5. Vir Untung!
JRPG het 'n toegewyde volgelinge en 'n aantal indie-JRPG's (soos hieronder geïllustreer) het goed kommersieel gegaan en is beskikbaar op platforms soos Steam.
JRPG deel soveel konvensies en meganika wat dit toelaat om 'n tipiese JRPG in verskeie stelsels te verdeel:
In sagteware ontwikkeling lyk een patroon herhalend: lae. Dit verwys na hoe program stelsels bo-op mekaar gebou word, met lae wat wyd toegepas kan word, en lae wat nouer met die hand van probleme naby die bokant handel. JRPG is nie anders nie en kan gesien word as 'n aantal lae - die onderste laag handel oor basiese grafiese funksies en boonste lae wat handel oor karaktersoektogte en statistieke.
Wenk: Wanneer jou 'n nuwe stelsel ontwikkel is dit die beste om eers die onderste lae te skep en dan laag vir laag na bo te skuif. Deur middel van middelware te gebruik kan jou verskeie van die laer lae wat algemeen is vir baie speletjies slaan. In die argitektoniese diagram hierbo word, al die lae onder die stippellyn hanteer deur 2D-speletjiesmasjiene.
Soos jou kan sien uit die argitektuur diagram hierbo, is daar baie stelsels wat JRPG uitmaak maar die meeste stelsels kan as afsonderlik gegroepeer word modes van die spel. JRPGs het baie verskillende spel modi; hulle het 'n wêreldkaart, plaaslike kaart, gevegsmodus en verskeie spyskaartmodusse. Hierdie modi is amper heeltemal apart, selfstandige stukkies kode, wat elkeen maklik maak om te ontwikkel.
Modes is belangrik maar hulle sal nutteloos wees sonder spelinhoud. Die RPG bevat baie kaartlêers, monsterdefinisies, dialooglyne, skrifte om snitte en spelkodes te bestuur om die vordering van spelers te beheer. Insluitende hoe om 'n JRPG in detail te bou, sal die hele boek invul, so ons sal konsentreer op sommige van die belangrikste dele Om die spelmodus skoon te hanteer, is noodsaaklik om 'n beheerbare JRPG te lewer, so dit is die eerste stelsel wat ons sal verken.
Die prent hieronder wys game loop pomp weg, roep die update funksie elke raam. Dit is die hartklop van die spel en byna alle speletjies is so gestruktureer.
Het jou al ooit 'n projek begin, maar gestop omdat jou dit te moeilik gevind het om nuwe funksies by te voeg of deur geheimsinnige foute geteister te word? Miskien probeer jou al jou kode in 'n opdateringsfunksie met 'n klein struktuur vas te maak en vind die kode as 'n kriptiese gemors. 'N Goeie oplossing vir hierdie tipe probleem is om die kode in verskillende te skei game states, gee 'n beter beeld van wat aangaan.
Die algemene gamedev-instrument is die staats masjien; Dit word oral gebruik, animasies, spyskaarte, speletjies, AI ... hanteer. Dit is 'n noodsaaklike instrument om in ons kit te hê. Vir JRPG kan ons die staatsmasjien gebruik om verskillende spelmodi te hanteer. Ons sal die normale staatsmasjien sien en dan sal ons dit 'n bietjie meng, om dit meer geskik te maak vir JRPG. Maar laat ons eers 'n rukkie neem om die algemene spelvloei hieronder te oorweeg.
In 'n tipiese JRPG kan jou begin in 'n plaaslike kaartspelmodus, vry om rond die stad rond te beweeg en met die inwoners te kommunikeer. Vanuit die dorp kan jou vertrek - hier gaan jou 'n ander spel af en sien die wêreldkaart.
Die wêreldkaart werk baie soos die plaaslike kaart, maar op 'n groter skaal; Jou kan berge en dorpe sien, in plaas van bome en heinings. Terwyl jou op 'n wêreldkaart gaan as jou na die stad terugkeer sal die modus terugkeer na die plaaslike kaart.
Of dit nou op 'n wêreldkaart of 'n plaaslike kaart is, kan jou 'n spyskaart oopmaak om jou karakter te kyk, en soms op die wêreldkaart word jou in die slagveld gegooi. Die diagram hierbo verduidelik die spelmodus en hierdie oorgang; dit is die basiese vloei van die JRPG-spel en dit is wat ons van ons wildland sal maak.
Hantering van Kompleksiteit met 'n Staatsmasjien
'N Staatsmasjien, vir ons doeleindes, is 'n kode wat al ons verskillende spelmodusse stoor, sodat ons van een modus na 'n ander kan beweeg en dit verander en verander wat ook al die huidige modus.
Afhangende van die staat masjien implementering taal bestaan ​​gewoonlik uit StateMachine klas en koppelvlak, IState, wat alle lande implementeer.
Wenk: Die koppelvlak is net 'n klas met die definisie van lidfunksie, maar geen implementering nie. Klasse wat van die koppelvlak beërf word benodig om die funksie van sy lede te implementeer. Dit beteken dat die koppelvlak geen kode het nie, dit spesifiseer net dat ander klasse sekere funksies verskaf. Dit laat verskillende klasse toe om op dieselfde manier gebruik te word want ons weet hulle het 'n klomp lidfunksies wat deur die gemeenskaplike koppelvlak gedefinieer word.
Inleiding tot Ojek Georiënteerde Pogrammering vir Selontwikkeling
Die staatsmasjien word die beste verduidelik deur die basisstelsel in pseudokode te skets:
Hierdie kode hierbo toon 'n eenvoudige staat masjien met geen fout kontrole.
Kom ons kyk hoe die bogenoemde staatsmasjienkode in 'n speletjie gebruik word. Aan die begin van die spel sal 'n StateMachine geskep word, al die verskillende toestande van die spel bygevoeg en die aanvanklike staatstel. Elke staat word uniek geïdentifiseer deur die naam van die String wat gebruik word wanneer die statusveranderingsfunksie geroep word. Daar is net een huidige toestand, mCurrentState, en dit word elke speletjie lus gelewer en opgedateer.
Die kode lyk soos volg:
In ons voorbeeld skep ons al die nodige state, voeg dit by StateMachine en stel die aanvanklike staat in die hoofkieslys. As ons hierdie kode uitvoer sal MainMenuState eers toegeken en opgedateer word. Dit verteenwoordig die spyskaart wat jou in die meeste speletjies sien wanneer jou die eerste keer opstart, met opsies soos Begin Spel en Laai Spel.
Wanneer 'n gebruiker kies Begin Game, die MainMenuState roep iets soos gGameMode.Change("localmap", "map_001") en die LocalMapState in 'n nuwe staat in hierdie tyd. Hierdie situasie sal dan opdateer en die kaart maak, sodat spelers die spel kan begin verken.
Die onderstaande diagram toon die visualisering van 'n bewegende staatsmasjien tussenin WorldMapState en BattleState. In hierdie wedstryd sal ekwivalent wees aan spelers wat dwarsoor die wêreld beweeg, gaan in die geveg af, en dan terug na die kaart.
Kom ons kyk vinnig na die staatskoppelvlak en 'n EmptyState klas wat dit implementeer:
Die koppelvlak IState vereis dat elke staat vier metodes het voordat dit as 'n staat in die staatsmasjien gebruik kan word: Update (), Render (), OnEnter () en OnExit ().
Update() en Render() word elke raam genoem vir die huidige aktiewe toestand; OnEnter() en OnExit() word genoem wanneer die staat verander word. Daarbenewens is dit redelik maklik. Nou weet jy dit, jy kan allerhande state vir al die verskillende dele van jou spel skep.
Dis die basiese staatsmasjien. Dit is nuttig vir baie situasies, maar wanneer ons met spelmodusse handel, kan ons dit verbeter! Met die huidige stelsel, kan die verandering van die staat baie bokoste hê - soms wanneer dit verander BattleState ons sal wil vertrek die WorldState, hardloop die stryd, en dan terug na die WorldState in die regte omgewing voor die geveg. Hierdie soort operasie kan lomp wees deur gebruik te maak van die standaard staatsmasjien wat ons beskryf het. 'N beter oplossing sou wees om 'n stapel state te gebruik.
Maak Spel Logika Makliker Met 'n Staatsstapel
Ons kan die standaardstaatmasjien vervang in 'n stapel state, soos in die diagram hieronder getoon. Byvoorbeeld, die MainMenuState word eers aan die begin van die spel op die stapel gedruk. Wanneer ons 'n nuwe speletjie begin, word die LocalMapState bo-op dit gestoot. Op hierdie punt word die MainMenuState nie meer gelewer of opgedateer nie maar wag dit, gereed vir ons om terug te keer.
Verder, as ons die stryd begin, word BattleState omgestoot; Wanneer die geveg eindig, spring dit uit die hopie en ons kan op die kaart bly, presies waar ons opgehou het. As ons in die spel sterf,word LocalMapState uitgehaal en ons keer terug na MainMenuState.
Die diagram hieronder bied 'n visualisering van die stapel omstandighede, wat aandui dat InGameMenuState op die stapel gedruk word en dan afgeknip word.
Nou het ons 'n idee hoe die stapel werk, kom ons kyk na 'n paar kode om dit te implementeer:
Hierdie bogenoemde staaf stapel kode het geen fout kontrole en is redelik eenvoudig. State kan op die stapel gedruk word deur die Push() oproep te gebruik en met 'n Pop() oproep af te skakel en die staat bo-aan die stapel is die een wat opgedateer en weergegee word.
Die gebruik van 'n stapelgebaseerde benadering is goed vir spyskaarte, en met 'n klein wysiging kan dit ook gebruik word vir dialoogkassies en kennisgewings. As jou avontuurlustig voel kan jou albei kombineer en 'n staatsmasjien hê wat ook stapels ondersteun.
Met behulp van StateMachine, StateStack, of 'n kombinasie van die twee skep 'n uitstekende struktuur om jou RPG op te bou.
Implementeer die staatsmasjienkode in u gunsteling programmeertaal.
Skep 'n MenuMenuState en GameState erf van IState.
Stel die hoofspystaat as die aanvanklike toestand.
Beide state lewer verskillende beelde.
As jou op 'n knoppie druk, verander die toestand van die hoofkieslys na die spelstaat.
Die kaart beeld die wêreld uit; woestyne, ruimtetuie en woude kan almal met teëls verteenwoordig word. 'N Tilemap is 'n manier om 'n beperkte aantal klein beelde te gebruik om 'n groter een op te bou. Die diagram hieronder toon hoe dit werk:
Die bostaande diagram bevat drie dele: 'n teëlpalet, visualisering van hoe omemap gebou is, en die finale kaart wat op die skerm vertoon word.
Die teëlpalet is 'n versameling van al die teëls wat gebruik word om 'n kaart te skep. Elke teël in die palet word uniek geïdentifiseer deur 'n heelgetal. Byvoorbeeld, nommer 1 is gras; let op die plekke waar dit gebruik word om te visualiseer.
Tilemap is net 'n verskeidenheid getalle, enige nommer wat verband hou met teëls in die palet. As ons 'n kaart vol gras wil maak, kan ons 'n groot skikking hê met die nommer 1, en as ons daardie teël maak, sien ons 'n grasskaart wat van baie klein grasseëls gemaak word. Die plotpalet word gewoonlik gelaai as 'n groot tekstuur wat baie kleiner teëls bevat maar elke inskrywing in die palet kan maklik sy eie grafiese lêer word.
Wenk: Hoekom gebruik nie skikkingskikking om tilemap te verteenwoordig nie? Die eerste skikking kan verteenwoordig word deur 'n reëlmatriks van teëls.
Die rede waarom ons dit nie gedoen het nie is net vir eenvoud en doeltreffendheid. As jou 'n heelgetalskikking het, is dit een kontinue geheue blok. As jou 'n verskeidenheid van skikkings het, is dit een geheue blok vir die eerste skikking wat die wyser bevat, elke wyser wys na 'n ry teëls. Hierdie hoax kan dinge af sak - en aangesien ons 'n kaart van elke raam teken, hoe gouer hoe beter!
Kom ons kyk na 'n kode vir die beskrywing van 'n teël kaart:
Vergelyk die bostaande kode met die diagram en dit is duidelik hoe 'n skerm opgebou word uit 'n klein reeks teëls. Sodra 'n kaart so beskryf word, kan ons 'n eenvoudige afleweringsfunksie skryf om dit op die skerm te teken. Die presiese funksie besonderhede sal verander afhangende van die viewport instellings en beeld funksie. Ons lewer funksie word hieronder getoon.
Die kaarte wat ons tot dusver gebruik, is redelik basies; die meeste JRPG sal baie lae van die kaarte gebruik om meer interessante tonele te skep. Die onderstaande diagram toon ons eerste kaart, met nog drie lae bygevoeg, wat 'n baie aangenamer kaart tot gevolg het.
Soos ons vroeër gesien het, is elke teël net 'n verskeidenheid getalle en daarom kan 'n volledige gelaagde kaart uit die skikking van skikkings geskep word. Natuurlik, die lewering van die skedule is eintlik net die eerste stap in die verkenning van jou spel; kaarte moet ook inligting oor botsing, ondersteuning vir bewegende entiteite rondom, en basiese interaktiwiteit met triggers hê.
'N Sneller is 'n kode wat slegs geaktiveer word wanneer die speler dit "triggers" deur 'n aksie uit te voer. Daar is baie aksies wat die sneller kan herken. Byvoorbeeld, die verskuiwing van 'n speler se karakter op 'n teël kan 'n aksie veroorsaak - dit gebeur gewoonlik wanneer jou na 'n deur, teleporter- of kaartrand-teël beweeg. Triggers kan op hierdie teëls geplaas word om die karakter na 'n binnenshuise kaart, wêreldkaart of verwante plaaslike kaart te teleporteer.
Nog 'n sneller kan afhang van die druk op die "gebruik" knoppie. Byvoorbeeld, as die speler na die punt gaan en druk "gebruik" dan word die sneller afgedank en die dialoogkassie vertoon die tekentekst. Triggers word oor die hele plek gebruik om kaarte saam te steek en interaktiwiteit te verskaf.
JRPG het dikwels baie kaarte wat redelik gedetailleerd en ingewikkeld is, dus ek stel voor dat jou dit nie met die hand probeer doen nie. Dit is 'n beter idee om 'n toeskouredakteur te gebruik. Jou kan een van die uitstekende gratis bestaande oplossings gebruik of jou eie rol. As jou 'n bestaande gereedskap wil probeer raai ek dit beslis aan om na te gaan Tiled wat is die hulpmiddel wat ek gebruik om hierdie voorbeeld kaarte te skep.
Inleiding tot Teëls
Om TMX Kaartformaat Teëls in Jou Eie Speletjie Enjin te Argiveer
Leer Ogmo Editor ken
Kry 'n paar teëls van opengameart.org.
Skep 'n kaart en laai dit in jou spel.
Voeg speler karakter by.
Beweeg die karakter van die teël na die teël.
Maak die karakters glad van teël na teël.
Voeg botsingsdeteksie by (jou kan 'n nuwe laag gebruik om die botsingsinligting te stoor).
Voeg 'n eenvoudige sneller by om die kaart te ruil.
Voeg 'n sneller by om waarskuwings te lees - oorweeg om die stapel lande wat ons vroeër bespreek het te gebruik om die dialoogkassie te vertoon.
Maak 'n hoofkiesstaat met 'n "Begin spel" opsie en 'n plaaslike kaartstaat en koppel hulle saam.
Ontwerp 'n paar kaarte, voeg 'n paar NPCs by, probeer 'n eenvoudige haal soeke - laat jou verbeelding vryloop!
Ten slotte, aan die gevegte! Hoe goed is 'n JRPG sonder geveg? Gevegte is waar baie speletjies kies om te innoveer, nuwe vaardigheidstelsels, nuwe gevegstrukture, of verskillende spelstelsels in te stel. Daar is aansienlike verskeidenheid.
Die meeste strydstelsels gebruik 'n beurt-gebaseerde struktuur met slegs een stryder wat toegelaat word om op een slag te reageer. Die eerste beurt-strydstelsel is baie eenvoudig, met elke entiteit 'n beurt in die volgorde: draai die speler, draai die vyand, draai die speler, draai die vyand, ensovoorts. Dit het vinnig plek gemaak vir meer ingewikkelde stelsels wat meer ruimte bied vir taktiek en strategie.
Ons gaan 'n vinnige kyk na Active-Time gebaseerde strydstelsels, waar vegters nie noodwendig 'n gelyke aantal beurte kry nie. Vinniger entiteite kan meer draaie kry en die tipe aksie wat geneem word beïnvloed ook hoe lank die beurt neem. Bevoorbeeld, 'n soldaat wat met 'n dolkmes sny duur 20 sekondes maar 'n towenaar wat 'n monster oproep kan twee minute neem.
Bogenoemde skermkiekie toon die gevegmodus in 'n tipiese JRPG. Die speler-beheerde karakters is aan die regterkant, vyande karakters aan die linkerkant, en die tekskassie aan die onderkant toon inligting oor die vegters.
Aan die begin van die geveg word die monster- en speler-sprites by die toneel gevoeg, en dan is daar 'n besluit oor watter volgorde die entiteite hul beurt neem. Hierdie besluit kan deels afhang van hoe die stryd van stapel gestuur is: as die speler omval word sal alle monsters eerste aangeval word, indien nie gewoonlik gebaseer op een van die entiteitstatistieke soos spoed nie.
Alles wat die speler of monsters doen, is 'n aksie: aanvalle is 'n aksie, met behulp van magie is 'n aksie, en selfs besluit watter aksie die volgende moet volg is 'n aksie! Die volgorde van aksies word die beste gevolg deur 'n tou te gebruik. Bogenoemde aksies is aksies wat volgende sal gebeur, tensy geen vinniger aksie volg nie. Elke aksie sal 'n aftelling hê wat afneem as elke raam verby is.
Die strydvloei word beheer deur 'n staatsmasjien met twee toestande te gebruik; een staat om aksies en ander state na te gaan om op te tree wanneer die tyd kom. Soos altyd, die beste manier om iets te verstaan is om na die kode te kyk. Die volgende voorbeeld implementeer 'n basiese gevegstoestand met 'n aksiewachtrij:
Die bostaande kode toon die beheer van die strydmodusvloei met behulp van 'n eenvoudige staatsmasjien en 'n tou van aksies. Om mee te begin het al die entiteite betrokke by die geveg 'n besluit-aksie wat by die tou gevoeg is.
'N Aksie-beslissende speler sal 'n spyskaart saambring met die RPG's Stick Attack, Magic en Item opsies; nadat die speler die aksie besluit het word die besluitaksie verwyder uit die tou en die nuutgekose aksie is bygevoeg.
'N Besluit-aksie vir AI sal die toneel nagaan en besluit wat om volgende te doen (met iets soos 'n behavior tree, besluit boom of soortgelyke tegniek) en dan sal dit ook die besluit aksie verwyder en sy nuwe aksie in die tou voeg.
Die BattleTick klas beheer die opdatering van die aksies, soos hieronder getoon:
BattleTick is 'n sub staat van die BattleMode-staat en dit tel net tot die top aksie se aftelling nul is. Dan verskyn die boonste aksie uit die tou en verander die status van die uitvoering.
Die diagram hierbo toon 'n aksiewachtrij aan die begin van 'n geveg. Niemand het nog aksie geneem nie en almal word volgens hulle tyd bestel om 'n besluit te neem.
Die Giant Plant het 'n aftelling van 0, dus op die volgende regmerkie voer dit sy AIDecide aksie uit. In hierdie geval lei die AIDecide aksie tot die monster wat besluit om aan te val. Die aanval aksie is amper onmiddellik en word terug in die tou as die tweede aksie.
By die volgende iterasie van BattleTick, sal die speler kies watter aksie sy dwerg "Mark" moet neem, wat die tou weer sal verander. Die volgende herhaling van BattleTick daarna sal die Plant een van die dwerge aanval. Die aanval-aksie sal van die tou verwyder word en oorgedra word na die BattleExecute staat, en dit sal die aanval van die plant aangemoedig asook al die nodige strydberekeninge doen.
Sodra die monster se aanval klaar is, sal nog 'n AIDecide aksie in die tou vir die monster gevoeg word. Die BattleState sal hierdie pad tot aan die einde van die geveg voortduur.
As enige entiteit tydens 'n geveg doodgaan, moet al sy optrede uit die tou verwyder word - ons wil nie hê dat die dooie monsters skielik herleef en aanval tydens die spel nie (tensy ons doelbewus zombies of 'n soort onsterflike maak!).
Die aksie-ry en eenvoudige staatsmasjien is die hart van die strydstelsel en jy behoort nou 'n goeie gevoel te hê vir hoe dit bymekaar pas. Dit is nie genoeg om 'n selfstandige oplossing te wees nie, maar kan as 'n sjabloon gebruik word om iets wat meer volledig en ingewikkeld werk te bou. Aksies en state is goeie abstraksie wat help om die kompleksiteit van gevegte te bestuur en dit makliker te maak om uit te brei en te ontwikkel.
Skryf neer BattleExecute lande.
Miskien voeg meer state, soos BattleMenuState en AnimationState.
Lewer agtergronde en vyande met basiese gesondheidsstatistieke.
Skryf 'n eenvoudige aanval aksie en hardloop 'n eenvoudige stryd van handel aanvalle.
Gee entiteite spesiale vaardighede of magie.
Maak 'n vyand wat homself genees as onder 25% gesondheid.
Skep 'n wêreldkaart om 'n slagveld te begin.
Skep 'n BattleOver status wat buitelandse en XP voordele toon.
Ons het 'n hoëvlak aansig van hoe om 'n JRPG te skep, wat in sommige van die meer interessante besonderhede ingaan. Ons het bespreek hoe om kode te struktureer deur gebruik te maak van 'n staatsmasjien of stapel, hoe om kaarte en lae te gebruik om ons wêreld te wys, en hoe om die stroom van die stryd te beheer deur die tou van aksies en staatsmasjiene te gebruik. Die eienskappe wat ons gedek het maak 'n goeie basis om op te bou en te ontwikkel van.
Maar daar is baie wat glad nie bespreek is nie. Skep 'n volledige JRPG insluitend XP en nivelleringsisteem, stoor en laai speletjies, baie GUI-kode vir spyskaarte, basiese animasies en spesiale effekte, verklaar om skerms, meganismes (soos slaap, posie, element bonus en weerstand) te hanteer, noem net 'n paar dinge!
Jou het nie al hierdie dinge nodig vir die spel nie; Die maan is basies net die verkenning en dialoog van kaarte. Jou kan nuwe funksies in stadiums byvoeg as jou speletjie skep.
Waarheen Moet Jou Hierheen Gaan
Die moeilikste deel van 'n spel is om dit op te los, begin dus klein, dink aan mini-rpg; ontsnap uit die kerker, een soektog haal, en bou dan. As jou vind jou vas, trek dan die omvang van die spel af, maak dit eenvoudiger en voltooi dit. Jou mag dalk vind dat terwyl jou ontwikkel, baie nuwe en opwindende idees, goedes kry, skryf neer maar hou die drang om die omvang van jou spel te verhoog, of selfs erger begin 'n nuwe een.
Die skep van 'n JRPG is moeilik; daar is baie stelsels, en sonder 'n goeie kaart sal dit moeilik wees om te weet watter een eers hanteer moet word. 'N stap-vir-stap gids vir die bou van 'n JRPG sal die boek invul! Gelukkig het ek die boek geskryf, so as jou wil a more detailed guide to making a JRPG kyk dan asseblief.
'N aantal kreatiewe commons hulpbronne en bates word gebruik om hierdie artikel te help versamel:
Town Map Art deur Zabin, Daneeklu, Jetrel, Hyptosis, Redshrike, Bertram.
Tiled vir die skepping van kaarte.
Die konsep van my How to Make an RPG boek As jou meer gedetailleerde dekking van JRPG-skepping wil hê, gaan dit dan uit.