Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Game Development
  2. Platform Agnostic

Як стварыць JRPG: падручнік для распрацоўшчыкаў гульняў

by
Length:LongLanguages:

Belarusian (беларуская мова) translation by Alex Grigorovich (you can also view the original English article)

Гэты артыкул уяўляе сабой агляд на складаным узроўні стварэння JRPG (японскай ролевай гульні), такі як раннія гульні серыі Final Fantasy. Мы разгледзім архітэктуру і сістэмы, якія складаюць шкілет JRPG, як кіраваць гульнявымі рэжымамі, як выкарыстоўваць tilemaps для адлюстравання свету і як праграмаваць баявую сістэму RPG.

Заўвага: Гэты артыкул напісана з выкарыстаннем мовы псевдокодирования, падобнага Java, але гэтыя канцэпцыі дастасавальныя да любой асяроддзі распрацоўкі гульняў.


Змест



Неверагоднае месца нараджэння JRPG

On of Dragon Warrior iconic enemies - the slime

Культавы вораг Вайна Цмокаў - смоўж

У 1983 году Юджы Хорий, Коичи Накамура і Юкинобу Чида вылецелі ў Амерыку і наведалі AppleFest'83, які сабраў распрацоўшчыкаў, якія дэманструюць свае апошнія тварэнні для Apple II. Яны былі ўзрушаныя апошняй версіяй RPG пад назвай Wizardry.

Пасля вяртання ў Японію яны вырашылі стварыць Dragon Warrior, RPG, якая была б падобная, але прыстасаваная для NES. Гэта быў хіт, які вызначыў жанр JRPG. Воін Цмока не развіўся таксама добра ў Амерыцы, але праз некалькі гадоў з'явілася іншая гульня.

У 1987 годзе была выпушчаная арыгінальная Final Fantasy, якая выклікала ў мяне адну з самых прадаваных франшызы відэагульняў на Зямлі, якая стала, па меншай меры на Захадзе, культавым JRPG.



Абмеркаванне жанру

Гульнявыя жанры ніколі не маюць дакладных азначэнняў - гэта хутчэй невыразная калекцыя пагадненняў. У РПГ, як правіла, ёсць сістэма павышэння узроўняў, адзін або некалькі персанажаў з навыкамі і статыстыкай, зброяй і даспехамі, баявымі і разведвальнымі рэжымамі і магутнымі апавяданнямі; прагрэс гульні часта дасягаецца шляхам прасоўвання па карце.

Японскія РПГ - гэта РПГ, створаныя ў форме Воіна Дракона; яны больш лінейна, бой часта пакрокавы, і звычайна там ёсць два тыпу карт: карта свету і лакальная карта. Архаічныя JRPG ўключаюць у сябе Воіна Дракона, Final Fantasy, Wild Arms, Phantasy Star і Chrono Trigger. Тып JRPG, пра які мы пагаворым у гэтым артыкуле, падобны на раннюю Final Fantasy.

jrpg-snes-jrpgs


Пяць прычын, па якіх вы павінны зрабіць JRPG

1. Яны вытрымалі выпрабаванне часам

Гульні, такія як Final Fantasy VI і Chrono Trigger, па-ранейшаму вельмі прыемныя ў гульні. Калі вы робіце JRPG, вы вывучаеце гульнявой фармат які па-за часам, да якога сучасныя гульцы ўсё яшчэ вельмі прыхільныя. Яны ствараюць выдатную аснову для дадання ўласнай «песні» і эксперыментаў - няхай гэта будзе ў апавяданні, падачы або механіцы. Гэта выдатна, калі вы можаце зрабіць гульню, у якую будуць гуляць і атрымліваць асалоду ад дзесяцігоддзямі пасля яе першага рэлізу!

2. Механіка гульні шырока выкарыстоўваецца

Call of Duty, адна з самых папулярных гульняў FPS ў свеце, выкарыстоўвае элементы RPG; сацыяльны гульнявой бум, навакольны FarmVille, быў клонам RPG Harvest Moon для SNES; і нават гоначныя гульні, такія як Gran Turismo, маюць падлік узроўняў і балаў вопыту.

3. Абмежаванні для творчасці

Як пісьменнік можа быць запалоханы чыстым лістом паперы, распрацоўшчык гульні можа апынуцца паралізаваным вялікай колькасцю магчымых варыянтаў пры распрацоўцы новай гульні. З JRPG ў вас ёсць шмат гатовых варыянтаў, таму ў вас не будзе такога ступару пры выбары, вы можаце прытрымлівацца рэкамендацый для большасці выпадкаў і адхіляцца ад іх у кропках, якія вам важныя.

4. Гэта можна зрабіць як сольны праект

Код для Final Fantasy быў амаль цалкам напісаны адным праграмістам Насір Гебелли, і ён зрабіў гэта пакуль быў на сходзе! Дзякуючы сучасным інструментам і родам значна прасцей стварыць такі тып гульні. Самая вялікая частка RPG - гэта не праграмаванне, гэта кантэнт, але гэта не абавязкова выпадак вашай гульні. Калі вы падправіць яго крыху і сфокусируетесь на якасці, а не колькасці, тады JRPG - выдатны сольны праект.

Наяўнасць каманды можа дапамагчы ў стварэнні любой гульні, і вы, магчыма, захочаце перадаць на аўтсорсінг стварэнне графікі і музыкі, або выкарыстоўваць некаторыя з выдатных творчых рэсурсаў такіх як opengameart.org (Заўвага рэдактара: Наш родны сайт GraphicRiver таксама прадае спрайты для гульняў.)

5. Для прыбытку!

JRPG валодаюць вялікай колькасцю прыхільнікаў, і шэраг JRPG (напрыклад, прадстаўленых на малюнку ніжэй) добра зарэкамендавалі сябе ў якасці камерцыйнага прадукту і даступныя на такіх платформах, як Steam.

jrpg-indies


Архітэктура


JRPG спалучаюць у сабе так шмат умоў і механікі, што тыповую JRPG можна разбіць на некалькі сістэм:

jrpg-architecture

У распрацоўцы праграмнага забеспячэння адзін шаблон выкарыстоўваецца зноў і зноў: шматузроўневай. Гэта ставіцца да таго, як сістэмы праграмы ставяцца адзін да аднаго, прычым часта выкарыстоўваюцца ўзроўні размяшчаюцца унізе, а ўзроўні больш цесна звязаныя з непасрэднымі задачамі, размяшчаюцца уверсе. JRPG не вельмі адрозніваюцца адзін ад аднаго і таму ўтрымліваюць некалькі узроўняў - больш нізкія ўзроўні маюць справу з асноўнымі графічнымі функцыямі, а верхнія ўзроўні - з квэстамі і персанажамі.

Савет: Пры распрацоўцы новай сістэмы лепш за ўсё пачаць ствараць ніжнія ўзроўні, а затым перамяшчацца па ўзроўні ўверх. Выкарыстанне прамежкавага праграмнага забеспячэння дазваляе прапусціць некалькі ніжніх узроўняў, агульных для многіх гульняў. На дыяграме вышэй усе ўзроўні пад пункцірнай лініяй апрацоўваюцца 2D гульнявым рухавічком.

Як бачна з дыяграмы вышэй, існуе мноства сістэм, якія дазваляюць стварыць JRPG, але большасць сістэм можна згрупаваць у выглядзе асобных рэжымаў гульні. JRPG маюць вельмі выразныя гульнявыя рэжымы; там ёсць карта свету, лакальная карта, баявой рэжым і некалькі рэжымаў меню. Гэтыя рэжымы ўяўляюць сабой амаль цалкам асобныя, самадастатковыя фрагменты кода, што робіць іх простымі ў распрацоўцы.

Рэжымы важныя, але яны не будуць дарэмныя без гульнявога кантэнту. RPG змяшчае шмат файлаў карт, вызначэння монстраў, радкоў дыялогу, скрыптоў для запуску ролікаў і кода геймплэя для кіравання тым, як гулец прасоўваецца. Распавядаючы пра тое, як пабудаваць JRPG, у дэталях, мы б запоўнілі цэлую кнігу, таму мы засяродзімся на некаторых з найбольш важных частак. Кіраваць гульнявымі рэжымамі крытычна важна для стварэння JRPG, так што гэта першая частка, якую мы вывучым.



Упраўленне гульнявым станам


На прыведзеным ніжэй малюнку паказаны цыкл гульні, які выклікае функцыю абнаўлення для кожнага кадра. Гэта «сэрцабіцце» гульні, і амаль усе гульні пабудаваны такім чынам.

jrp-gameloop

Вы калі-небудзь пачалі праект, але спыняліся, таму што вам было занадта складана дадаваць новыя функцыі або былі збітыя з панталыку таямнічымі памылкамі? Можа быць, вы спрабавалі ўціснуць увесь свой код у функцыю абнаўлення з невялікай структурай і выявілі, што код стаў непрадказальным. Выдатным рашэннем гэтай праблемы будзе падзел кода на розныя гульнявыя стану, якое дае больш дакладнае ўяўленне пра тое, што адбываецца.

Звычайны інструмент распрацоўніка гульняў - гэта механізм станаў; ён выкарыстоўваецца паўсюль, для апрацоўкі анімацыі, меню, гульнявога патоку, AI ... гэта важны інструмент для нашага набору. Для JRPG мы можам выкарыстоўваць механізм станаў для апрацоўкі розных рэжымаў гульні. Мы зірнем на звычайны механізм станаў, а затым крыху зменім яго, каб зрабіць больш прыдатным для JRPG. Але спачатку давайце разгледзім агульны гульнявы ​​працэс, намаляваны ніжэй.

jrpg-states-and-transistions

У тыповай JRPG вы, верагодна, пачнеце ў рэжыме карты мясцовасці, дзе зможаце свабодна падарожнічаць па горадзе і ўзаемадзейнічаць з яго жыхарамі. Вы можаце сысці з горада - тут вы пяройдзеце ў іншай гульнявой рэжым і ўбачыце карту свету.

Карта свету вельмі падобная на лакальную карту, але ў большым маштабе; вы можаце ўбачыць горы і горада, а не дрэвы ды платы. Калі знаходзячыся на карце свету, вы вернецеся ў горад, рэжым вернецца да карце мясцовасці.

На карце свету ці мясцовасці вы можаце адкрыць меню, каб праверыць сваіх персанажаў, а часам на мапе сьвету вы будзеце адпраўленыя ў бой. На прыведзенай вышэй дыяграме апісаны гэтыя рэжымы і пераходы; гэта асноўны паток гульнявога працэсу JRPG, і гэта тое, з чаго мы пачнем ствараць нашы гульнявыя стану.

Кіраванне складанасцю з дапамогай механізму стану

Механізм стану, для нашых мэтаў, уяўляе сабой кавалак кода, які змяшчае ўсе розныя рэжымы нашых гульняў, што дазваляе нам перамяшчацца з аднаго рэжыму ў іншы і абнаўляць і адлюстроўваць ўсе актыўныя рэжымы.

У залежнасці ад мовы рэалізацыі механізм стану звычайна складаецца з класа StateMachine і інтэрфейсу, IState, які выкарыстоўваецца ва ўсіх станах.

Савет: Інтэрфейс - гэта проста клас з азначэннямі функцый, але не рэалізацыя. Класы, спадчынай інтэрфейс, неабходныя для рэалізацыі сваіх функцый. Гэта азначае, што інтэрфейс не ўтрымлівае кода, ён проста паказвае, што іншыя класы прадастаўляюць пэўныя функцыі. Гэта дазваляе выкарыстоўваць розныя класы такім жа чынам, паколькі мы ведаем, што ў іх ёсць група функцый, вызначаных агульным інтэрфейсам.

Механізм стану лепш за ўсё апісваецца шляхам стварэння базавай сістэмы ў псевдокоде:

Код вышэй паказвае просты механізм стану без праверкі памылак.

Давайце паглядзім, як выкарыстоўваецца вышэйзгаданы механізм стану ў гульні. У пачатку гульні будзе створаны StateMachine, дададзеныя усе розныя стану гульні і зыходны стан. Кожнае стан ідэнтыфікуецца па імі String, якое выкарыстоўваецца пры выкліку функцыі змены стану. Існуе толькі адно актыўны стан, mCurrentState, і яно візуалізуецца і абнаўляецца кожны гульнявой цыкл.

Код можа выглядаць так:

У гэтым прыкладзе мы ствараем усе неабходныя стану, дадаем іх у StateMachine і ўсталёўваны зыходны стан ў галоўнае меню. Калі мы запусцім гэты код, MainMenuState будзе адлюстроўвацца і абнаўляцца ў першую чаргу. Гэта меню, якое вы бачыце ў большасці гульняў пры першай загрузцы, з такімі наладамі, як «Пачаць гульню" і "Загрузіць гульню».

Калі карыстальнік выбірае Пачаць гульню, ainMenuState выклікае нешта накшталт GameMode.Change("localmap","map_001"), а LocalMapState становіцца новым бягучым станам. Гэты стан затым абновіць і адлюструе карту, дазваляючы гульцу пачаць вывучэнне гульні.

На прыведзенай ніжэй дыяграме паказана візуалізацыя механізму стану, які перамяшчаецца паміж WorldMapState і BattleState. У гульні гэта было б эквівалентна гульцу, які перамяшчаецца па ўсім свеце, змагаецца з монстрамі, пераходзіць у баявой рэжым, а затым вяртаецца на карту.

jrpg-state-machine

Давайце хутка зірнем на інтэрфейс стану і клас EmptyState, які яго рэалізуе:

Інтэрфейс IState патрабуе, каб кожнае стан ўтрымлівала чатыры метаду, перш чым яго можна будзе выкарыстоўваць як стан у механізме: Update(), Render(), OnEnter() і OnExit().

Update() і Render() выклікаюцца кожны кадр для бягучага актыўнага стану; OnEnter() і OnExit() выклікаецца пры змене стану. Гэта ўсё даволі проста. Цяпер вы ведаеце гэта, што вы можаце ствараць усе віды станаў для ўсіх частак вашай гульні.

Гэта асноўны механізм стану. Гэта карысна для многіх сітуацый, але пры працы з гульнявымі рэжымамі мы можам палепшыць яго! З бягучай сістэмай змяненне стану можа мець шмат накладных выдаткаў - часам пры пераходзе на BattleState мы хочам пакінуць WorldState, запусціць бітву, а затым вярнуцца ў WorldState ў дакладнай наладзе, якая была да бітвы. Такая аперацыя можа быць нязграбнай, выкарыстоўваючы стандартную машыну станаў, якую мы апісалі. Лепшым рашэннем было б выкарыстоўваць стэк станаў.

Зрабіць логіку гульні прасцей з дапамогай штатнага стэка

Мы можам пераключыць стандартную машыну станаў у стэк станаў, як паказана на дыяграме ніжэй. Напрыклад, MainMenuState спачатку змяшчаецца ў стэк, у пачатку гульні. Калі мы пачынаем новую гульню, LocalMapState націскаецца па-над ёй. На дадзены момант MainMenuState больш не адлюстроўваецца або не абнаўляецца, а чакае, і мы гатовыя вярнуцца да яго.

Затым, калі мы пачнем бітву, BattleState будзе націснутая уверсе; калі бітва заканчваецца, яна саслізнула са стэка, і мы можам вярнуцца на карту менавіта там, дзе мы спыніліся. Калі мы памром ў гульні, то LocalMapState выскачыць, і мы вернемся да MainMenuState.

На прыведзенай ніжэй дыяграме даецца візуалізацыя стэка станаў, якая паказвае, што InGameMenuState змяшчаецца ў стэк, а затым выскоквае.

jrpg-state-stack

Цяпер у нас ёсць ідэя, як працуе стэк, давайце паглядзім на некаторы код для яго рэалізацыі:

Гэты вышэйзгаданы код стэка стану не мае праверкі памылак і даволі просты. Стану могуць быць перанесены ў стэк з дапамогай выкліку Push() і выведзены выклікам Pop(), а стан на самай вяршыні стэка - гэта той, які абноўлены і адлюстраваны.

Выкарыстанне падыходу на аснове стэка добры для меню, і з невялікай мадыфікацыяй яго таксама можна ыкарыстоўваць для дыялогавых вокнаў і апавяшчэнняў. Калі вы адчуваеце сябе авантурнікам, тады вы можаце камбінаваць абодва і мець канчатковы аўтамат, які таксама падтрымлівае стэкі.

Выкарыстанне StateMachine, StateStack або некаторая камбінацыя двух стварае выдатную структуру для стварэння вашай RPG.

Наступныя дзеянні:

  1. Зарубіце код канчатковага аўтамата на ваш любімы мова праграмавання.
  2. Стварыце MenuMenuState і GameState, спадчыны ад IState.   
  3. Задайце асноўны стан меню як зыходны стан.
  4. Абодва стану адлюстроўваюць розныя малюнкі.   
  5. Пры націску кнопкі зменіце стан з галоўнага меню ў стан гульні.


Карты


Карты апісваюць свет; пустыні, касмічныя караблі і джунглі могуць быць прадстаўлены з выкарыстаннем пліткі. Тканкавая карта - гэта спосаб выкарыстання абмежаванай колькасці невялікіх малюнкаў для стварэння большага. На прыведзенай ніжэй дыяграме паказана, як гэта працуе:

jrpg-tiles-to-tilemap

Вышэйпрыведзеная Дыяграма складаецца з трох частак: палітры пліткі, візуалізацыі таго, як пабудавана плітка, і канчатковай карты, якая адлюстроўваецца на экран.

Плітка пліткі - гэта сукупнасць усіх плітак, якія ыкарыстоўваюцца для стварэння карты. Кожная плітка ў палітры унікальна ідэнтыфікуецца цэлым лікам. Напрыклад, плітка нумар 1 - трава; звярніце ўвагу на месцы, дзе ён выкарыстоўваецца пры візуалізацыі ў выглядзе пліткі.

Тыповая карта - гэта ўсяго толькі масіў лікаў, кожны з якіх адносіцца да пліткі ў палітры. Калі б мы хацелі стварыць карту, поўную травы, мы маглі б проста мець вялікі масіў, запоўнены нумарам 1, і калі мы адабралі гэтыя пліткі, мы ўбачылі б карту травы, складзеную з многіх дробных травяных пліт. Палітра пліткі звычайна загружаецца як адна вялікая тэкстура, якая змяшчае шмат меншых фрагментаў, але кожная запіс у палітры можа так жа лёгка быць яе уласным графічным файлам.

Савет: Чаму б не выкарыстоўваць масіў масіваў для прадстаўлення tilemap? Першы масіў можа ўяўляць сабой масіў радкоў. Першы масіў можа ўяўляць сабой масіў радкоў.

Прычына, па якой мы гэтага не робім, - проста для прастаты і эфектыўнасці. Калі ў вас ёсць масіў цэлых лікаў, гэта адзін бесперапынны блок памяці. Калі ў вас масіў масіваў, то гэта адзін блок памяці для першага масіва, які змяшчае паказальнікі, прычым кожны паказальнік паказвае на шэраг фрагментаў. Гэты кірунак можа запаволіць працу - і паколькі мы малюем карту кожнага кадра, тым хутчэй, тым лепш!

Давайце разгледзім некаторы код для апісання карты пліткі:

Параўнайце прыведзены вышэй код з дыяграмай, і зусім ясна, як плітка пабудавана з невялікай серыі плітак. Як толькі карта апісана так, мы можам напісаць простую функцыю рэндэрынгу, каб намаляваць яе на экране. Дакладныя дэталі функцыі будуць мяняцца ў залежнасці ад параметраў налады відашукальнік і чарцяжа. Ніжэй паказаная наша функцыя рэндэрынгу.

Карта, якую мы выкарысталі да гэтага часу, з'яўляецца даволі просты; большасць JRPG будуць выкарыстоўваць некалькі слаёў tilemaps для стварэння больш цікавых сцэн. На прыведзенай ніжэй дыяграме паказана наша першая карта, у якую дададзена яшчэ тры пласта, што прыводзіць да значна больш прыемнай карце.

jrpg-using-tilemap-layers

Як мы бачылі раней, кожны tilemap - гэта ўсяго толькі масіў лікаў, і таму поўнапамерная карта можа быць зроблена з масіва гэтых масіваў. Вядома, стварэнне tilemap на самай справе з'яўляецца толькі першым крокам у даданні даследаванні ў вашу гульню; карты таксама павінны мець інфармацыю аб сутыкненні, падтрымку аб'ектаў, якія рухаюцца вакол і базавую інтэрактыўнасць з выкарыстаннем трыгераў.

Трыгер - гэта фрагмент кода, які запускаецца толькі тады, калі гулец «запускае» яго, выконваючы некаторыя дзеянні. Існуе мноства дзеянняў, якія можа распазнаць трыгер. Напрыклад, перасоўванне персанажа гульца на плітку можа выклікаць дзеянне - гэта звычайна адбываецца пры перамяшчэнні па дзвярнога праёму, тэлепорт або абзе пліткі карты. Трыгеры могуць быць змешчаны на гэтыя пліткі, каб тэлепартаваць персанажа на карту ўнутранай прасторы, карту свету ці адпаведную лакальную карту.

Іншы трыгер можа залежаць ад націску кнопкі «Выкарыстаць». Напрыклад, калі гулец падымаецца да знака і націскае «выкарыстаць», тады запускаецца трыгер і адлюстроўваецца дыялогавае акно з тэкстам знака. Трыгеры выкарыстоўваюцца паўсюль, каб дапамагчы пашыць карты разам і забяспечыць інтэрактыўнасць.

У JRPG часта ёсць шмат даволі падрабязных і складаных карт, таму я рэкамендую вам не спрабаваць іх рабіць уручную, значна лепш выкарыстоўваць рэдактар ​​tilemap. Вы можаце выкарыстоўваць адзін з выдатных бясплатных існуючых рашэнняў або згортваць свае ўласныя. Калі вы хочаце паспрабаваць існуючы інструмент, я абавязкова рэкамендую праверыць Tiled, які з'яўляецца інструментам, які я выкарыстаў для стварэння гэтых прыкладаў карт.

Наступныя дзеянні:

  1. Атрымаць пліткавы.
  2. Атрымаеце некаторыя фрагменты з opengameart.org.   
  3. Стварыце карту і загрузіце яе ў сваю гульню.   
  4. Дадайце персанаж гульца.   
  5. Перамесціце сімвал з пліткі ў плітку.   
  6. Зрабіце персанажа плыўным пераходам ад пліткі да пліткі.   
  7. Дадаць выяўленне сутыкнення (вы можаце выкарыстоўваць новы пласт для захоўвання інфармацыі аб канфліктах).   
  8. Дадайце просты трыгер для абмену картамі.  
  9. Дадайце трыгер для чытання знакаў - разгледзьце выкарыстанне стэка станаў, пра які мы казалі раней, каб адлюстраваць дыялогавае акно.   
  10. Зрабіце галоўнае меню з опцыяй «Пачаць гульню" і лакальным станам карты і злучыце іх разам.
  11. Распрацуйце некалькі карт, дадайце некалькі NPC, паспрабуйце просты квэст-квэст - няхай ваша ўяўленне бяжыць бясплатна!


Бой

Нарэшце, на бітву! Якая карысць ад JRPG без бою? Combat - гэта тое, дзе мноства гульняў аддаюць перавагу ўводзіць новаўвядзенні, укараняючы новыя сістэмы навыкаў, новую баявую структуру або розныя сістэмы загавораў - ёсць даволі шмат варыяцый.

Большасць баявых сістэм выкарыстоўваюць пакрокавую структуру, і толькі адзін баец дазваляе дзейнічаць адначасова. Самыя першыя пакрокавыя баявыя сістэмы былі простымі, і кожная сутнасць атрымлівала ход: чарга гульца, кручэнне браму, паварот гульца, кручэнне і т.д. Гэта хутка саступіла месца больш складаным сістэмам, якія прапануюць больш магчымасцяў для тактыкі і стратэгіі.

Мы ўважліва разгледзім баявыя сістэмы на аснове актыўнага часу, дзе Камбатанты не абавязкова атрымліваюць роўнае колькасць абаротаў. Больш хуткія аб'екты могуць атрымліваць больш абаротаў, а тып дзеянні таксама ўплывае на працягласць праходжання. Напрыклад, воін, які сячэ кінжалам, можа заняць 20 секунд, але чараўнік, якія заклікае монстра, можа заняць дзве хвіліны.

jrpg-combat-screen

На прыведзеным вышэй здымку паказаны баявой рэжым у тыповым JRPG. Кіраваныя гульцом персанажы справа, варожыя персанажы злева, а тэкставае поле унізе паказвае інфармацыю аб камбатантаў.

У пачатку бою на сцэну дадаюцца спрайты з монстрамі і гульцамі, а затым прымаецца рашэнне аб тым, які парадак сутнасці здзяйсняюць свае чаргі. Гэтае рашэнне можа часткова залежаць ад таго, як быў пачаты бой: калі гулец патрапіў у засаду, монстры будуць атакаваць спачатку, інакш ён будзе грунтавацца на адной з статыстычных дадзеных, такіх як хуткасць.

Усё, што робіць гулец або монстры, - гэта дзеянне: атака - гэта дзеянне, выкарыстанне магіі - гэта дзеянне, і нават прыняцце рашэння аб тым, якое дзеянне трэба распачаць, - гэта дзеянне! Парадак дзеянняў лепш за ўсё адсочваць з выкарыстаннем чарзе. Дзеянне уверсе - гэта дзеянне, якое будзе адбывацца далей, калі толькі гэта не паскорыць дзеянне. Кожнае дзеянне будзе мець зваротны адлік, які памяншаецца па меры праходжання кожнага кадра.

Баявой паток кіруецца з выкарыстаннем канчатковага аўтамата з двума станамі; адно стан, каб пазначыць дзеянні і іншы стан, каб выканаць верхняе дзеянне, калі прыйдзе час. Як заўсёды, лепшы спосаб зразумець нешта - гэта паглядзець на код. У наступным прыкладзе рэалізавана базавую стан бою з чаргой дзеянняў:

У прыведзеным вышэй кодзе паказана кіраванне патокам баявога рэжыму з выкарыстаннем простага канчатковага аўтамата і чэргі дзеянняў. Пачнем з таго, што ўсе сутнасці, якія ўдзельнічаюць у бітве, дадалі ў чаргу дзеянне прыняцця рашэння.

Прыняцце рашэння для гульца прывядзе да з'яўлення меню з устойлівымі параметрамі RPG Attack, Magic і Item; як толькі гулец прымае рашэнне аб дзеянні, дзеянне прыняцця рашэння выдаляецца з чаргі і дадаецца новае абранае дзеянне.

Прыняцце рашэння для ІІ правярае сцэну і вырашае, што рабіць далей (выкарыстоўваючы нешта накшталт дрэва паводзін, дрэва рашэнняў або аналагічнай тэхнікі), а затым яно таксама выдаліць яго дзеянне прыняцця ашэння і дадасць яго новае дзеянне ў чаргу.

Клас BattleTick кантралюе абнаўленне дзеянняў, як паказана ніжэй:

BattleTick з'яўляецца падначаленым станам стану BattleMode, і ён проста галачкі, пакуль зваротны адлік верхняга дзеянні не роўны нулю. Затым ён выдае верхняе дзеянне з чаргі і пераходзіць у стан выканання.

jrpg-action-queue

На прыведзенай вышэй дыяграме паказана чаргу дзеянняў у пачатку бітвы. Ніхто яшчэ не распачаў ніякіх дзеянняў, і да іх часу ўсё загадана прыняць рашэнне.

У гіганцкага завода ёсць зваротны адлік 0, таму на наступным ціку ён выконвае сваё дзеянне AIDecide. У гэтым выпадку дзеянне AIDecide прыводзіць да таго, што монстар вырашае атакаваць. Дзеянне атакі амаль імгненна і дадаецца назад у чаргу ў якасці другога дзеянні.

На наступным ітэрацыі BattleTick гулец зможа абраць, якое дзеянне павінен распачаць яго карлік «Марк», які зноў зменіць чаргу. Пасля наступнай ітэрацыі BattleTick пасля гэтага завод атакуе аднаго з гномаў. Дзеянне атакі будзе выдалена з чаргі і перададзена ў стан BattleExecute, і яно будзе аніміраваць атакуе прылада, а таксама выканаць усе неабходныя баявыя вылічэнні.

Як толькі атака монстра будзе скончана, у чаргу для монстра дадасца іншае дзеянне AIDecide. BattleState будзе працягваць гэты шлях да канца бою.

Калі які-небудзь аб'ект памірае падчас бою, ўсе яго дзеянні можна было б выдаліць з чаргі - мы не хочам, каб мёртвыя монстры раптам рэанімавалі і атакавалі падчас гульні (калі толькі мы не маем намеру ствараць зомбі ці нейкую нежыць!).

Чарга дзеянняў і просты канчатковы аўтамат з'яўляюцца сэрцам баявой сістэмы, і зараз вы павінны добра адчуваць, як яна спалучаецца. Гэта недастаткова поўна, каб быць аўтаномным рашэннем, але яго можна выкарыстоўваць у якасці шаблону для стварэння чагосьці больш паўнавартаснага і складанага. Дзеянні і стану - гэта добрая абстракцыя, якая дапамагае кіраваць складанасцю бою і палягчае яе пашырэнне і развіццё.

Наступныя дзеянні:

  1. Напішыце стан BattleExecute.
  2. Магчыма, дадайце больш станаў, такіх як BattleMenuState і AnimationState.
  3. Выняць фоны і ворагаў з базавымі характарыстыкамі здароўя.
  4. Напішыце простае дзеянне нападаў і выканайце простую бітву за гандлёвыя атакі.
  5. Дайце сутнасці асаблівыя навыкі або магію.
  6. Зрабіце ворага, які вылечыць сябе, калі здароўе ніжэй за 25%.
  7. Стварыце карту свету для запуску стану бітвы.
  8. Стварыце стан BattleOver, якое паказвае здабычу і прырост XP.


Агляд

У нас быў высокі ўзровень погляду на тое, як зрабіць JRPG, пагрузіўшыся ў некаторыя з больш цікавых дэталяў. Мы разгледзелі, як структураваць код з выкарыстаннем канчатковага аўтамата або стэка, як выкарыстоўваць tilemaps і слаі для адлюстравання нашага свету і як кіраваць патокам бою з дапамогай чарзе дзеянняў і канчатковага аўтамата. Функцыі, якія мы разгледзелі, ствараюць добрую аснову для развіцця і развіцця.

Але ёсць і шмат чаго, што не было ахоплена наогул. Стварэнне паўнавартаснага JRPG ўключае ў сябе сістэмы XP і выраўноўвання, захаванне і загрузку гульні, мноства графічнага інтэрфейсу для меню, асноўныя анімацыі і спецыяльныя эфекты, стану для апрацоўкі ролікаў, баявой механікі (такія як сон, пазіцыя, стыхійныя бонусы і упраціву), каб назваць некалькі рэчаў!

Аднак вам не патрэбныя ўсе гэтыя рэчы для гульні; Для Месяца ў асноўным было толькі даследаванне карт і дыялог. Вы можаце паступова дадаваць новыя функцыі, калі вы робіце сваю гульню.

Куды пайсці адсюль

Самая складаная частка стварэння любой гульні сканчаецца, таму пачынайце з малога, падумайце аб міні-RPG; выйдзіце з падзямелля, адзін квэст, і затым стварыце. Калі вы выявіце, што вы захрасае, паменшыце маштаб гульні, спросціце яе і завершыце. Вы можаце выявіць, што па меры развіцця вы атрымліваеце мноства новых і захапляльных ідэй, што добра, запісвайце іх, але супраціўляйцеся імкненню павялічыць аб'ём вашай гульні або, што яшчэ горш, пачаць новую.

Зрабіць JRPG складана; існуе мноства сістэм, і без добрай карты можа быць цяжка зразумець, з чым спачатку справіцца. Дбайнае пакрокавае кіраўніцтва па стварэнні JRPG запоўнілі б кнігу! На шчасце, я пішу гэтую кнігу, таму, калі вы хочаце атрымаць больш падрабязнае кіраўніцтва па стварэнні JRPG, калі ласка, праверце гэта.



Выкарыстоўваюцца рэсурсы

Для таго, каб дапамагчы сабраць гэты артыкул, быў ыкарыстаны шэраг рэсурсаў і актываў для калектыўнага выкарыстання:

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.