Игровые движки: среда разработки видеоигр

Введение

Среда разработки программного обеспечения, предназначенная для создания видеоигр.

Игровой движок — это программный каркас, разработанный преимущественно для разработки видеоигр и обычно включающий соответствующие библиотеки и вспомогательные программы, такие как редактор уровней. Термин "движок" аналогичен термину "программный движок", более широко используемому в индустрии программного обеспечения. Игровой движок также может относиться к программному обеспечению для разработки, поддерживающему этот каркас, как правило, представляющему собой набор инструментов и функций для разработки игр. Разработчики могут использовать игровые движки для создания игр для видеоигровых консолей и других типов компьютеров. Основные функции, обычно предоставляемые игровым движком, могут включать в себя движок рендеринга ("рендерер") для 2D или 3D-графики, движок физики или обнаружение столкновений (и обработку столкновений), звук, скрипты, анимацию, искусственный интеллект, сетевое взаимодействие, потоковую передачу данных, управление памятью, многопоточность, поддержку локализации, сцену графов и поддержку видео для кинематографических роликов. Разработчики игровых движков часто оптимизируют процесс разработки игр, повторно используя/адаптируя в значительной степени один и тот же игровой движок для создания различных игр или для облегчения переноса игр на несколько платформ.

Цель

Во многих случаях игровые движки предоставляют набор инструментов визуальной разработки в дополнение к многократно используемым программным компонентам. Эти инструменты обычно поставляются в интегрированной среде разработки, чтобы обеспечить упрощенную и быструю разработку игр, основанную на данных. Разработчики игровых движков часто стремятся предугадать потребности разработчиков, создавая надежные программные пакеты, включающие множество элементов, которые могут потребоваться для создания игры. Большинство игровых движков предоставляют средства, облегчающие разработку, такие как графика, звук, физика и функции искусственного интеллекта (ИИ). Эти игровые движки иногда называют «промежуточным программным обеспечением» (middleware), поскольку, подобно бизнес-определению этого термина, они предоставляют гибкую и многократно используемую программную платформу, которая сразу же обеспечивает всю основную функциональность, необходимую для разработки игрового приложения, одновременно снижая затраты, сложность и время выхода на рынок — все критически важные факторы в высококонкурентной индустрии видеоигр. Как и другие типы промежуточного программного обеспечения, игровые движки обычно обеспечивают абстракцию платформы, позволяя одной и той же игре работать на различных платформах (включая игровые консоли и персональные компьютеры) с минимальными или отсутствующими изменениями в исходном коде игры. Часто программисты разрабатывают игровые движки с компонентно-ориентированной архитектурой, которая позволяет заменять или расширять определенные системы в движке более специализированными (и часто более дорогими) компонентами игрового промежуточного программного обеспечения. Некоторые игровые движки состоят из серии слабо связанных компонентов игрового промежуточного программного обеспечения, которые можно выборочно комбинировать для создания пользовательского движка, вместо более распространенного подхода расширения или настройки гибкого интегрированного продукта. Однако, расширяемость остается высоким приоритетом для игровых движков из-за широкого спектра областей их применения. Несмотря на специфичность названия «игровой движок», конечные пользователи часто используют игровые движки для других видов интерактивных приложений, требующих графики в реальном времени, таких как маркетинговые демонстрации, архитектурные визуализации, учебные симуляции и среды моделирования. Некоторые игровые движки предоставляют только возможности 3D-рендеринга в реальном времени, а не широкий спектр функциональности, необходимой для игр. Эти движки полагаются на разработчика игры для реализации остальной функциональности или сборки ее из других компонентов игрового промежуточного программного обеспечения. Такие движки обычно называют «графическим движком», «движком рендеринга» или «3D-движком», а не более общим термином «игровой движок». Эта терминология используется непоследовательно, поскольку многие полнофункциональные 3D-игровые движки называют просто «3D-движками». Примеры графических движков включают: Crystal Space, Genesis3D, Irrlicht, OGRE, RealmForge, Truevision3D и Vision Engine. Современные игровые или графические движки обычно предоставляют сцену — объектно-ориентированное представление 3D-игрового мира, которое часто упрощает дизайн игры и может быть использовано для более эффективного рендеринга обширных виртуальных миров. С устареванием технологий компоненты движка могут устаревать или оказываться недостаточными для требований проекта. Поскольку разработка совершенно нового движка может привести к нежелательным задержкам (или потребовать перезапуска проекта с самого начала), команда разработчиков движка может решить обновить существующий движок новыми функциями или компонентами.

In many cases, game engines provide a suite of visual development tools in addition to reusable software components. These tools are generally provided in an integrated development environment to enable simplified, rapid development of games in a data driven manner. Game engine developers often attempt to preempt implementer needs by developing robust software suites which include many elements a game developer may need to build a game. Most game engine suites provide facilities that ease development, such as graphics, sound, physics and artificial intelligence (AI) functions. These game engines are sometimes called "middleware" because, as with the business sense of the term, they provide a flexible and reusable software platform which provides all the core functionality needed, right out of the box, to develop a game application while reducing costs, complexities, and time to market—all critical factors in the highly competitive video game industry. Like other types of middleware, game engines usually provide platform abstraction, allowing the same game to run on various platforms (including game consoles and personal computers) with few, if any, changes made to the game source code. Often, programmers design game engines with a component based architecture that allows specific systems in the engine to be replaced or extended with more specialized (and often more expensive) game middleware components. Some game engines comprise a series of loosely connected game middleware components that can be selectively combined to create a custom engine, instead of the more common approach of extending or customizing a flexible integrated product. However achieved, extensibility remains a high priority for game engines due to the wide variety of uses for which they are applied. Despite the specificity of the name "game engine", end users often re purpose game engines for other kinds of interactive applications with real time graphical requirements—such as marketing demos, architectural visualizations, training simulations, and modeling environments. Some game engines only provide real time 3D rendering capabilities instead of the wide range of functionality needed by games. These engines rely upon the game developer to implement the rest of this functionality or to assemble it from other game middleware components. These types of engines are generally referred to as a "graphics engine", "rendering engine", or "3D engine" instead of the more encompassing term "game engine". This terminology is inconsistently used, as many full featured 3D game engines are referred to simply as "3D engines". Examples of graphics engines include: Crystal Space, Genesis3D, Irrlicht, OGRE, RealmForge, Truevision3D, and Vision Engine. Modern game or graphics engines generally provide a scene graph—an object oriented representation of the 3D game world which often simplifies game design and can be used for more efficient rendering of vast virtual worlds. As technology ages, the components of an engine may become outdated or insufficient for the requirements of a given project. Since the complexity of programming an entirely new engine may result in unwanted delays (or necessitate that a project restart from the beginning), an engine development team may elect to update their existing engine with newer functionality or components.

История

До появления игровых движков игры обычно разрабатывались как единые сущности: игра для Atari 2600, например, должна была быть спроектирована с нуля для оптимального использования аппаратного обеспечения дисплея. Этот базовый программный модуль дисплея сегодня разработчики игр для старых систем называют ядром. Другие платформы предоставляли больше свободы, но даже когда дисплей не был проблемой, ограничения памяти часто срывали попытки создать дизайн, требующий большого объема данных. Даже на более гибких платформах очень мало что можно было повторно использовать между играми. Быстрое развитие аркадного оборудования — лидера рынка в то время — означало, что большая часть кода в любом случае приходила в негодность, поскольку последующие поколения игр использовали совершенно иные игровые конструкции, использующие дополнительные ресурсы. Таким образом, большинство игровых проектов 1980-х годов создавались на основе жестко закодированного набора правил с небольшим количеством уровней и графических данных. С наступлением золотого века аркадных видеоигр, компаниям, разрабатывающим видеоигры, стало обычным делом разрабатывать собственные игровые движки для использования с программным обеспечением первого уровня. Заметным примером игрового движка для домашних консолей в середине 1980-х годов был плавный движок боковой прокрутки, разработанный командой Сигеру Миямото в Nintendo для Nintendo Entertainment System (NES). Движок, разработанный ими для гоночной игры с боковой прокруткой Excitebike (1984), позже был использован для платформера с прокруткой Super Mario Bros. (1985). Это позволило Марио плавно разгоняться от ходьбы к бегу, а не двигаться с постоянной скоростью, как в более ранних платформерах. Хотя сторонние игровые движки не были распространены до появления 3D-компьютерной графики в 1990-х годах, в 1980-х годах было создано несколько систем для создания 2D-игр для независимой разработки видеоигр. Среди них: Pinball Construction Set (1983), War Game Construction Kit от ASCII (1983), Thunder Force Construction (1984), Adventure Construction Set (1984), GameMaker от Garry Kitchen (1985), Wargame Construction Set (1986), Shoot 'Em Up Construction Kit (1987), Arcade Game Construction Kit (1988) и, наиболее популярные, движки RPG Maker от ASCII, начиная с 1998 года. Klik & Play (1994) — еще одно устаревшее предложение, которое до сих пор доступно. Термин «игровой движок» появился в середине 1990-х годов, особенно в связи с 3D-играми, такими как шутеры от первого лица с движком шутера от первого лица. Epic Games, основанная разработчиком Тимом Суини, представила Unreal Engine в 1998 году. Игры Doom и Quake от Id Software были настолько популярны, что вместо того, чтобы начинать с нуля, другие разработчики лицензировали основные части программного обеспечения и разрабатывали собственную графику, персонажей, оружие и уровни — «игровой контент» или «игровые ресурсы». Разделение игровых правил и данных от базовых концепций, таких как обнаружение столкновений и игровые объекты, позволило командам расти и специализироваться. Современные игровые движки — одни из самых сложных приложений, когда-либо написанных, часто включающие десятки тщательно настроенных систем, взаимодействующих для обеспечения точно контролируемого пользовательского опыта. Продолжающаяся эволюция игровых движков привела к четкому разделению рендеринга, скриптов, графики и дизайна уровней. Например, сейчас в типичной команде разработчиков игр художников в несколько раз больше, чем программистов. Шутеры от первого лица остаются основными пользователями сторонних игровых движков, но теперь они также используются и в других жанрах. Например, ролевая видеоигра The Elder Scrolls III: Morrowind и MMORPG Dark Age of Camelot основаны на движке Gamebryo, а MMORPG Lineage II — на движке Unreal Engine. Игровые движки используются и для игр, изначально разработанных для домашних консолей; например, движок RenderWare используется во франшизах Grand Theft Auto и Burnout. Многопоточность приобретает все большее значение благодаря современным многоядерным системам (например, Cell) и растущим требованиям к реализму. Типичные потоки включают рендеринг, потоковую передачу, звук и физику. Гонки обычно были в авангарде многопоточности, с физическим движком, работающим в отдельном потоке задолго до переноса других основных подсистем, отчасти потому, что рендеринг и связанные с ним задачи нуждаются в обновлении только с частотой 30–60 Гц. Например, на PlayStation 3 физика в Need For Speed работала на частоте 100 Гц, а в Forza Motorsport 2 — на частоте 360 Гц. Хотя этот термин впервые был использован в 1990-х годах, есть несколько более ранних систем 1980-х годов, которые также считаются игровыми движками, такие как системы Adventure Game Interpreter (AGI) и SCI от Sierra, система SCUMM от LucasArts и движок Freescape от Incentive Software (в 1986 году). В отличие от большинства современных игровых движков, эти игровые движки никогда не использовались в сторонних продуктах (за исключением системы SCUMM, которая была лицензирована и использовалась Humongous Entertainment). По мере развития и повышения удобства использования технологии игровых движков, область их применения расширяется. Теперь они используются для серьезных игр: визуализации, обучения, медицинских и военных симуляций, в качестве примера можно привести CryEngine. Чтобы облегчить эту доступность, новые аппаратные платформы теперь являются целью игровых движков, включая мобильные телефоны (например, телефоны Android, iPhone) и веб-браузеры (например, WebGL, Shockwave, Flash, Trinigy's 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, предназначенный специально для небольших разработчиков, у которых нет достаточных ресурсов для выпуска игр в розничной продаже. Разрабатывать игровые движки для платформ, поддерживающих управляемые платформы, становится все легче и дешевле.

Before game engines, games were typically written as singular entities: a game for the Atari 2600, for example, had to be designed from the bottom up to make optimal use of the display hardware—this core display routine is today called the kernel by developers of games for older systems. Other platforms had more leeway, but even when the display was not a concern, memory constraints usually sabotaged attempts to create the data heavy design that an engine needs. Even on more accommodating platforms, very little could be reused between games. The rapid advance of arcade hardware—which was the leading edge of the market at the time—meant that most of the code would have to be thrown out afterwards anyway, as later generations of games would use completely different game designs that took advantage of extra resources. Thus most game designs through the 1980s were designed through a hard coded rule set with a small number of levels and graphics data. Since the golden age of arcade video games, it became common for video game companies to develop in house game engines for use with first party software. A notable example of an in house game engine on home consoles in the mid 1980s was the smooth side scrolling engine developed by Shigeru Miyamoto's team at Nintendo for the Nintendo Entertainment System (NES). The engine they had developed for the side scrolling racing game Excitebike (1984) was later employed for the scrolling platformer Super Mario Bros. (1985). This had the effect of allowing Mario to smoothly accelerate from a walk to a run, rather than move at a constant speed like in earlier platformers. While third party game engines were not common up until the rise of 3D computer graphics in the 1990s, there were several 2D game creation systems produced in the 1980s for independent video game development. These include Pinball Construction Set (1983), ASCII's War Game Construction Kit (1983), Thunder Force Construction (1984), Adventure Construction Set (1984), Garry Kitchen's GameMaker (1985), Wargame Construction Set (1986), Shoot 'Em Up Construction Kit (1987), Arcade Game Construction Kit (1988), and most popularly ASCII's RPG Maker engines from 1998 onward. Klik & Play (1994) is another legacy offering that is still available. The term "game engine" arose in the mid 1990s, especially in connection with 3D games such as first person shooters with a first person shooter engine. Epic games, founded by developer Tim Sweeney, debuted Unreal Engine in the year 1998. Such was the popularity of Id Software's Doom and Quake games that, rather than work from scratch, other developers licensed the core portions of the software and designed their own graphics, characters, weapons and levels—the "game content" or "game assets". Separation of game specific rules and data from basic concepts like collision detection and game entity meant that teams could grow and specialize. Modern game engines are some of the most complex applications written, often featuring dozens of finely tuned systems interacting to ensure a precisely controlled user experience. The continued evolution of game engines has created a strong separation between rendering, scripting, artwork, and level design. It is now common, for example, for a typical game development team to have several times as many artists as actual programmers. First person shooter games remain the predominant users of third party game engines, but they are now also being used in other genres. For example, the role playing video game The Elder Scrolls III: Morrowind and the MMORPG Dark Age of Camelot are based on the Gamebryo engine, and the MMORPG Lineage II is based on the Unreal Engine. Game engines are used for games originally developed for home consoles as well; for example, the RenderWare engine is used in the Grand Theft Auto and Burnout franchises. Threading is taking on more importance due to modern multi core systems (e. g. Cell) and increased demands in realism. Typical threads involve rendering, streaming, audio, and physics. Racing games have typically been at the forefront of threading with the physics engine running in a separate thread long before other core subsystems were moved, partly because rendering and related tasks need updating at only 30–60 Hz. For example, on PlayStation 3, physics ran in Need For Speed at 100 Hz versus Forza Motorsport 2 at 360 Hz. Although the term was first used in the 1990s, there are a few earlier systems in the 1980s that are also considered to be game engines, such as Sierra's Adventure Game Interpreter (AGI) and SCI systems, LucasArts' SCUMM system and Incentive Software's Freescape engine (in 1986). Unlike most modern game engines, these game engines were never used in any third party products (except for the SCUMM system which was licensed to and used by Humongous Entertainment). As game engine technology matures and becomes more user friendly, the application of game engines has broadened in scope. They are now being used for serious games: visualization, training, medical, and military simulation applications, with the CryEngine being one example. To facilitate this accessibility, new hardware platforms are now being targeted by game engines, including mobile phones (e. g. Android phones, iPhone) and web browsers (e. g. WebGL, Shockwave, Flash, Trinigy's WebVision, Silverlight, Unity Web Player, O3D and pure DHTML). Additionally, more game engines are being built upon higher level languages such as Java and C#/. NET (e. g. TorqueX, and Visual3D. NET), Python (Panda3D), or Lua Script (Leadwerks). As most 3D rich games are now mostly GPU limited (i. e. limited by the power of the graphics card), the potential slowdown due to translation overheads of higher level languages becomes negligible, while the productivity gains offered by these languages work to the game engine developers' benefit. These recent trends are being propelled by companies such as Microsoft to support indie game development. Microsoft developed XNA as the SDK of choice for all video games released on Xbox and related products. This includes the Xbox Live Indie Games channel designed specifically for smaller developers who do not have the extensive resources necessary to box games for sale on retail shelves. It is becoming easier and cheaper than ever to develop game engines for platforms that support managed frameworks.

Игровые движки как отрасль

Производители игровых движков определяют, как пользователи могут использовать их продукты. Игровая индустрия – это индустрия, и сами движки, на которых она построена, тоже. Ведущие игровые движки предлагаются по разным ценам, будь то в виде подписки или лицензионных платежей. В настоящее время Unity и Unreal Engine – два самых популярных варианта для разработчиков игр. Несмотря на то, что различия между игровыми движками стираются по мере того, как они добавляют собственные инструменты, разработчики могут быть слишком привыкшими к определенной системе, чтобы переходить на другую, или же привлекаются значительными преимуществами этих движков, несмотря на необходимость оплаты.

Среднее ПО игры

В более широком смысле этого термина, игровые движки сами по себе могут быть описаны как промежуточное программное обеспечение. Однако в контексте видеоигр термин "промежуточное ПО" часто используется для обозначения подсистем функциональности внутри игрового движка. Некоторые игровые промежуточные программы выполняют только одну задачу, но делают это более убедительно или эффективнее, чем промежуточное ПО общего назначения. Четыре наиболее широко используемых пакета промежуточного ПО, предоставляющих подсистемы функциональности, включают RAD Game Tools' Bink, Firelight FMOD, Havok и Scaleform GFx. RAD Game Tools разрабатывает Bink для базовой видеорендеринга, а также Miles для работы со звуком и Granny 3D для рендеринга. Firelight FMOD – это недорогая, но надежная аудиобиблиотека и набор инструментов. Havok предоставляет надежную систему физического моделирования, а также набор приложений для анимации и поведения. Scaleform предоставляет GFx для высокопроизводительного Flash-интерфейса и высококачественного воспроизведения видео, а также редактор методов ввода (IME) для поддержки азиатского чата в игре. Другое промежуточное ПО используется для оптимизации производительности: например, Simplygon помогает оптимизировать и генерировать сетки различной детализации, а Umbra добавляет оптимизацию отсечения невидимых объектов в 3D-графике. Некоторые программы промежуточного ПО содержат полный исходный код, другие предоставляют только справочник по API для скомпилированной двоичной библиотеки. Некоторые программы промежуточного обеспечения могут быть лицензированы как в одном, так и в другом варианте, обычно за более высокую плату за полный исходный код.