# Гульнявы рухавік

**Гульнявы́ рухавік**, **гульнёвы рухавік** — праграмная структура, створаная найперш для распрацоўкі відэагульняў і звычайна ўключае адпаведныя бібліятэкі і праграмы падтрымкі, такія як рэдактар узроўняў. Тэрміналогія «рухавік» падобная да тэрміна «праграмны механізм», які выкарыстоўваецца ў індустрыі праграмнага забеспячэння.

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

Распрацоўшчыкі могуць выкарыстоўваць гульнявыя рухавікі для стварэння гульняў для гульнявых прыставак і камп’ютараў. Асноўныя функцыянальныя магчымасці, якія звычайна прадастаўляюцца гульнявым рухавіком, могуць уключаць у сябе механізм рэндэрынгу для 2D або 3D -графікі, фізічны рухавік або выяўленне сутыкненняў (і адказ на сутыкненні), гук, сцэнарыі, анімацыю, штучны інтэлект, сеткі, струменевыя перадачы, кіраванне памяццю, работа патокаў, падтрымка лакалізацыі, графік сцэны і падтрымка відэа для кінематаграфіі. Распрацоўшчыкі гульнявога рухавіка часта эканомяць на працэсе распрацоўкі гульні, паўторна выкарыстоўваючы/адаптуючы, у значнай ступені, адзін і той жа гульнявы механізм для стварэння розных гульняў або для дапамогі ў партаванні гульняў на некалькі платформаў.

## Прызначэнне

 Стварэнне гульні-платформера ў Godot
У многіх выпадках гульнявыя рухавікі забяспечваюць набор інструментаў візуальнай распрацоўкі ў дадатак да праграмных кампанентаў шматразовага выкарыстання. Гэтыя інструменты звычайна прадастаўляюцца ў інтэграваным асяроддзі распрацоўкі, каб забяспечыць спрошчаную і хуткую распрацоўку гульняў на аснове дадзеных. Распрацоўшчыкі гульнявых механізмаў часта спрабуюць апярэдзіць патрэбы распрацоўшчыкаў, распрацоўваючы надзейныя пакеты праграмнага забеспячэння, якія ўключаюць у сябе мноства элементаў, якія могуць спатрэбіцца распрацоўшчыкам для стварэння гульні. Большасць набораў гульнявых рухавікоў забяспечваюць сродкі, якія палягчаюць распрацоўку, такія як графіка, гук, фізіка і функцыі штучнага інтэлекту (AI). Гэтыя гульнявыя рухавікі часам называюць «прамежкавым праграмным забеспячэннем», таму што яны забяспечваюць гнуткую і шматразовую праграмную платформу, якая забяспечвае ўсе асноўныя функцыі, даступныя адразу з скрынкі для распрацоўкі гульні, адначасова зніжаючы выдаткі, складанасці і час выхаду на рынак — усе важныя фактары ў высокаканкурэнтнай індустрыі відэагульняў.

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

Некаторыя гульнявыя рухавікі забяспечваюць толькі магчымасці 3D-рэндэрынгу ў рэальным часе замест шырокага дыяпазону функцый, неабходных для гульняў. Гэтыя рухавікі спадзяваюцца на распрацоўшчыкаў гульні, якія будуць рэалізоўваць астатнія функцыі або зборкі з іншых кампанентаў прамежкавага праграмнага забеспячэння гульні. Гэтыя тыпы рухавікоў звычайна называюць «графічным рухавіком», «рухавіком візуалізацыі» або «3D-рухавіком» замест больш шырокага тэрміна «гульнявы рухавік». Гэтая тэрміналогія выкарыстоўваецца непаслядоўна, таму што многія поўнафункцыянальныя 3D-гульні называюць проста «3D-рухавікамі». Прыклады графічных рухавікоў: Crystal Space, Genesis3D, Irrlicht, OGRE, RealmForge, Truevision3D і Vision Engine. Сучасныя гульнявыя або графічныя рухавікі звычайна забяспечваюць граф сцэны — аб’ектна-арыентаванае прадстаўленне трохмернага гульнявога свету, якое часта спрашчае дызайн гульні і можа выкарыстоўвацца для больш эфектыўнага рэндэрынгу велізарных віртуальных светаў.

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

## Гісторыя

 Некаторыя гульнявыя рухавікі з цягам часу развіваюцца і ствараюць генеалагічнае дрэва, як, напрыклад, рухавік Quake ад id, які прывёў да сямейства id Tech.
Да з’яўлення гульнявых рухавікоў гульні звычайна пісаліся як асобныя сутнасці: гульня для Atari 2600, напрыклад, павінна была распрацоўвацца знізу ўверх, каб аптымальна выкарыстоўваць апаратнае забеспячэнне дысплэя. Іншыя платформы мелі больш свабоды дзеянняў, але нават калі дысплэй не выклікаў клопату, абмежаванні памяці звычайна сабатавалі спробы стварыць канструкцыю з вялікай колькасцю дадзеных, якая патрэбна рухавіку. Хуткі прагрэс апаратнага забеспячэння для аркадных гульняў — якое ў той час было лідзіруючым на рынку — азначала, што большую частку кода ў любым выпадку пасля трэба будзе выкінуць, бо наступныя пакаленні гульняў будуць выкарыстоўваць зусім іншыя дызайны гульняў, якія карыстаюцца перавагамі дадатковых рэсурсаў. Такім чынам, большасць гульнявых дызайнаў да 1980-х распрацоўвалася на аснове жорстка закадзіраванага набору правіл з невялікай колькасцю ўзроўняў і графічных даных. Пачынаючы з залатога веку аркадных відэагульняў, кампаніям, якія займаюцца відэагульнямі, ⁣стала звычайнай справай распрацоўваць уласныя гульнявыя рухавікі для выкарыстання з праграмным забеспячэннем.

Яркім прыкладам унутранага гульнявога рухавіка на хатніх кансолях у сярэдзіне 1980-х гадоў быў механізм плыўнай бакавой пракруткі, распрацаваны камандай Шыгеру Міямота ў Nintendo для Nintendo Entertainment System (NES). Рухавік, які яны распрацавалі для гоначнай гульні *Excitebike* (1984) з бакавой пракруткай, пазней быў выкарыстаны для скролінг- платформера *Super Mario Bros.* (1985). Гэта дало магчымасць Марыё плаўна паскарацца ад хады да бегу, а не рухацца з пастаяннай хуткасцю, як у больш ранніх платформерах.

У той час як гульнявыя рухавікі іншых вытворцаў не былі распаўсюджаны да з’яўлення трохмернай камп’ютэрнай графікі ў 1990-х гадах, у 1980-х гадах было створана некалькі сістэм стварэння двухмерных гульняў для незалежнай распрацоўкі відэагульняў. Сюды ўваходзяць *набор канструктараў Pinball* (1983), *набор канструктараў ваеннай гульні* ASCII (1983), *канструктар Thunder Force* (1984), *набор канструктараў Adventure* (1984), GameMaker Garry Kitchen (1985), *набор канструктараў Wargame* (1986), *Shoot-'Em-Up Construction Kit* (1987), *Arcade Game Construction Kit* (1988) і найбольш папулярныя рухавікі ASCII *RPG Maker* з 1998 года. Klik & Play (1994) — яшчэ адна спадчынная прапанова, якая ўсё яшчэ даступная.

Тэрмін «гульнявы рухавік» узнік у сярэдзіне 1990-х гадоў, асабліва ў сувязі з 3D-гульнямі, такімі як шутэры ад першай асобы з рухавіком шутэраў ад першай асобы. Epic games, заснаваная распрацоўшчыкам Цімам Суіні, прадставіла Unreal Engine у 1998 годзе.

Гульні *Doom* і *Quake* ад Id Software былі настолькі папулярныя, што замест таго, каб працаваць з нуля, іншыя распрацоўшчыкі ліцэнзавалі асноўныя часткі праграмнага забеспячэння і распрацоўвалі ўласную графіку, персанажаў, зброю і ўзроўні — «кантэнт гульні» або «гульня актывы». Аддзяленне правіл і даных, характэрных для гульні, ад асноўных паняццяў, такіх як выяўленне сутыкненняў і сутнасць гульні, азначала, што каманды маглі расці і спецыялізавацца.

Пазнейшыя гульні, такія як *Quake III Arena* ад id Software і *Unreal* 1998 ад Epic Games, былі распрацаваны з улікам гэтага падыходу, і рухавік і кантэнт распрацоўваліся асобна. Практыка ліцэнзавання такой тэхналогіі аказалася карыснай дапаможнай крыніцай прыбытку для некаторых распрацоўшчыкаў гульняў, паколькі адна ліцэнзія на камерцыйны гульнявы рухавік высокага класа можа вар’іравацца ад 10 000 долараў ЗША да мільёнаў долараў, а колькасць ліцэнзіятаў можа дасягаць некалькіх дзясяткаў кампаній, як відаць з Unreal Engine. Прынамсі, механізмы шматразовага выкарыстання робяць распрацоўку сіквелаў гульняў больш хуткай і лёгкай, што з’яўляецца каштоўнай перавагай у канкурэнтнай індустрыі відэагульняў. Хаця прыкладна ў 2000 годзе паміж Epic і id існавала моцнае суперніцтва, з таго часу Unreal Engine ад Epic быў значна больш папулярным, чым id Tech 4 і яго пераемнік id Tech 5.

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

Шутэры ад першай асобы застаюцца асноўнымі карыстальнікамі старонніх гульнявых рухавікоў, але цяпер яны таксама выкарыстоўваюцца ў іншых жанрах. Напрыклад, ролевая відэагульня *The Elder Scrolls III: Morrowind* і MMORPG *Dark Age of Camelot* заснаваныя на рухавіку Gamebryo, а MMORPG *Lineage II* — на Unreal Engine. Гульнявыя рухавікі таксама выкарыстоўваюцца для гульняў, першапачаткова распрацаваных для хатніх кансоляў; напрыклад, механізм RenderWare выкарыстоўваецца ў франшызах *Grand Theft Auto* і *Burnout*.

Патокі набываюць усё большае значэнне з-за сучасных шмат’ядравых сістэм (напрыклад, Клетка) і павышаныя патрабаванні да рэалізму. Тыповыя патокі ўключаюць рэндэрынг, патокавую перадачу, аўдыя і фізіку. Гоначныя гульні, як правіла, былі ў авангардзе патокаў з фізічным рухавіком, які працаваў у асобным патоку, задоўга да таго, як іншыя асноўныя падсістэмы былі перанесены. Часткова гэта рабілі таму што рэндэрынг і звязаныя з ім задачы патрабуюць абнаўлення толькі з частатой 30-60 Гц. Напрыклад, на PlayStation 3 фізіка працавала ў *Need For Speed* на 100 Гц супраць *Forza Motorsport 2* на 360 Гц.

Нягледзячы на тое, што гэты тэрмін быў упершыню выкарыстаны ў 1990-х гадах, існуе некалькі больш ранніх сістэм 1980-х гадоў, якія таксама лічацца гульнявымі рухавікамі, напрыклад Adventure Game Interpreter (AGI) ад Sierra і сістэмы SCI, сістэма SCUMM ад LucasArts і рухавік Freescape ад Incentive Software (у 1986 ). У адрозненне ад большасці сучасных гульнявых рухавікоў, гэтыя гульнявыя рухавікі ніколі не выкарыстоўваліся ні ў якіх прадуктах іншых вытворцаў (за выключэннем сістэмы SCUMM, якая была ліцэнзавана і выкарыстоўвалася Humongous Entertainment).

Па меры таго, як тэхналогія гульнявых рухавікоў старэе і становіцца больш зручнай для карыстальнікаў, прымяненне гульнявых рухавікоў пашыраецца. Зараз яны выкарыстоўваюцца для сур’ёзных гульняў: візуалізацыі, навучання, медыцынскага і ваеннага мадэлявання, адным з прыкладаў з’яўляецца CryEngine. Каб палегчыць гэтую даступнасць, гульнявыя механізмы цяпер арыентуюцца на новыя апаратныя платформы, у тым ліку мабільныя тэлефоны (напр. тэлефоны Android, iPhone) і вэб-браўзеры (напр WebGL, Shockwave, Flash, Trinigy WebVision, Silverlight, Unity Web Player, O3D і чысты DHTML).

Акрамя таго, больш гульнявых рухавікоў будуецца на мовах больш высокага ўзроўню, такіх як Java і C#/.NET (напр. TorqueX і Visual3D.NET), Python (Panda3D) або Lua Script (Leadwerks). Паколькі большасць 3D-гульняў цяпер у асноўным абмежаваныя графічным працэсарам (г. зн. абмежаваныя магутнасцю відэакарты), патэнцыйнае запаволенне з-за накладных выдаткаў на пераклад моў больш высокага ўзроўню становіцца нязначным, у той час як павышэнне прадукцыйнасці, якое прапануе гэтыя мовы, працуе на перавагу распрацоўшчыкам гульнявых рухавікоў. Гэтыя апошнія тэндэнцыі падштурхоўваюцца такімі кампаніямі, як Microsoft, каб падтрымліваць распрацоўку індзі-гульняў. Microsoft распрацавала XNA як абраны SDK для ўсіх відэагульняў, выпушчаных на Xbox, і спадарожных прадуктаў. Яно ўключае ў сябе канал Xbox Live Indie Games, распрацаваны спецыяльна для невялікіх распрацоўшчыкаў, якія не маюць шырокіх рэсурсаў, неабходных для пастаўкі гульняў для продажу на паліцах рознічнага гандлю. Становіцца прасцей і танней, чым калі-небудзь, распрацоўваць гульнявыя рухавікі для платформаў, якія падтрымліваюць кіраваныя структуры.

## Гульнявыя рухавікі як індустрыя

Вытворцы гульнявых рухавікоў вырашаюць, як яны дазваляюць карыстальнікам выкарыстоўваць іх прадукты. Гэтак жа, як гульні — гэта індустрыя, так і рухавікі, на якіх яны створаны. Асноўныя гульнявыя рухавікі бываюць па розных коштах: гэта можа быць у выглядзе платы за падпіску або ліцэнзійных плацяжоў. Unity і Unreal Engine на дадзены момант з’яўляюцца двума найбольш папулярнымі варыянтамі для распрацоўшчыкаў гульняў. Нягледзячы на тое, што адрозненні паміж рознымі гульнявымі рухавікамі сціраюцца, калі яны ствараюць свае ўласныя інструменты на іх аснове, розныя распрацоўшчыкі гульняў могуць занадта прывыкнуць да сістэмы або быць прыцягнутымі велізарнымі перавагамі такіх рухавікоў незалежна ад аплаты працы.

## Гульнявое прамежкавае праграмнае забеспячэнне

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

Чатыры найбольш шырока выкарыстоўваюцца пакеты прамежкавага праграмнага забеспячэння , якія забяспечваюць падсістэмы функцыянальнасці, уключаюць RAD Game Tools’ Bink, Firelight FMOD, Havok і Scaleform GFx. RAD Game Tools распрацоўвае Bink для асноўнага рэндэрынгу відэа, а таксама аўдыё Miles і 3D-рэндэрынгу Granny. Firelight FMOD — гэта нізкая надзейная аўдыёбібліятэка і набор інструментаў. Havok забяспечвае надзейную сістэму мадэлявання фізікі разам з наборам дадаткаў для анімацыі і паводзін. Scaleform забяспечвае GFx для высокапрадукцыйнага карыстальніцкага інтэрфейсу Flash і высакаякаснага прайгравання відэа, а таксама дапаўненне рэдактара метадаў уводу (IME) для падтрымкі азіяцкіх чатаў у гульні.

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

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

## Гл. таксама

* Ren'Py

## Зноскі