Розробка ігор на Rust. Огляд екосистеми

Привіт! Я займаюся розробкою гри на Rust і хочу розповісти про це.
Моя перша стаття буде корисна тим, хто хоче почати робити гру на Rust, але не впевнений, які з пакетів (крейтов) варто використовувати і що взагалі відбувається в екосистемі Rust для ігрового розробника.
Невеликий відступ — навіщо все це? Є ж готовий X?
Під враженням ось цього виступу, я почав писати свій ігровий движок на Haskell. Далеко справа не пішла, але я написав рендер модельок, просте освітлення, трохи мережі.
Haskell дав можливість винести контракти з перевірок у рантайме на рівень системи типів. Ну і інші речі, про які розповідає Кармак — бути впевненим, що функція робить саме те, про що декларує у своєму типі. Бути трохи ближче до цієї формальної верифікації нашого ігрового коду — тобто, в теорії, мати гарантію коректної роботи взагалі без тестів.
Але, з Haskell було кілька проблем — для виведення 3д в реальному часі він досить повільний. Не було співтовариства займається на ньому іграми. Не вистачало потрібних для ігор бібліотек.
З Rust ж все пішло куди веселіше.
На мій погляд, Rust поєднує всі властивості, потрібні ігровим розробникам, в дуже правильному співвідношенні:
  • потужна, але при цьому проста система типів;
  • абстракції безкоштовні по перфомансу — не треба платити за ті абстракції, які не використовуєш у явному вигляді;
  • проста і безпечна багатопоточність;
І при цьому на ньому дуже просто писати код, мова маленький і простий.
Повернуся до екосистемі:
Робота з вікнами:
Glutin — раст-альтернатива GLFW, використовується в Servo, активно розвивається. Створює вікна на win/osx/linux/android. На ios ще не працює, хтось хотів зробити, але з 2015 про це прагнення не чути.
І є биндинги до не-растовым бібліотек: glfw-rs rust-sdl2 rust-sfml сайт). Всі три живі і підтримуються.
Графічні API:
Є можливість використовувати безпосередньо OpenGL/DirectX/Vulkan, до того ж вже створені растоспецифичные графічні бібліотеки.
Glium — безпечна обгортка над OpenGL, за фактом — в основному над OpenGL 3, добре підтримуються OpenGL < 4 і OpenGL ES. Підтримкою всіх хитрощів четвертої версії OpenGL автор займатися не планує, він вважає, що тоді краще відразу братися за Vulkan. Розвивається в даний момент досить неспішно — автор в основному займається своєю грою на вулкані.
Тим не менш на PC glium зі своїми функціями справляється — на ньому дійсно зручно писати код OpenGL.
Є учебник. Він не повний, але по початку дуже корисний.
Vulkano — аналог glium, але для Vulkan. Саме їм зайнятий автор glium, розробка йде дуже активно. З презентацією vulkano можна ознайомитися тут.
Gfx — універсальне API без прив'язки до графічного бэкэнду. Зараз працює поверх OpenGL і DirectX, незабаром планується Metal і Vulkan. Розробляється активніше glium. З gl es і мобільними пристроями в даний момент всі трохи гірше, ніж в glium, але прямо зараз ведуться дуже активні роботи в цю сторону.
Gfx і Glium відрізняються за поставленим завданням — glium просто надає api до стабільного opengl, gfx ж сконцентрований на своєму універсальному і типобезопасном api до найбільш сучасним графічним бэкендам.
Kiss-3d — маленький, простий графічний движок. Не багатий функціонал, але до цього і не прагне. Дозволяє створювати вікна і малювати графічні примітиви. Виглядає підтримуваним, але активної розробки не помічено. З іншого боку — воно вже повністю готове, свої функції виконує.
Готові графічні движки:
PistonPistonDevelopers — по суті, це величезна кількість проектів, об'єднаних загальною метою — стати, коли-небудь, модульним ігровим движком. "Не в кожному раст проекті є пістон цілком, але в кожному є трохи пістона" («No Rust game project uses most of Piston, but most uses some of it!»).
Основний розробник останні місяці займається виключно своїм скриптовою мовою Dyon і демо іграми на ньому (asteroids).
В купі репозиторіїв PistonDevelopers є щось майже готове, але, здебільшого, воно все дуже розрізнений і далеко від якогось практичного використання.
Amethyst — набагато молодше Piston, ще далекий від використання за призначенням, проте активно розвивається. Дизайн натхненний BitSquid/Stingray (від Autodesk). Вже є графічний пайплайн, forward/deffered rendering, asset pipeline, конфігурація через yaml. Основний розробник пропав, але спільнота дуже активно пиляє далі.
Математичні бібліотеки:
Cgmath — використовується в прикладах і gfx, і glium. Хоче стати основною математичною бібліотекою для ігор на Rust.
Nalgebra — використовується в ncollide і nphysics. Здебільшого використовується там, де потрібен ncollide/nphysics.
І то і то працює, всі основні операції є.
Glm-rs — наскільки я знаю, використовувалась до cgmath з nalgebra, просто биндинги до досить відомого GLM.
Пошук колізій:
Collision-rs — система пошуку колізій, використовує cgmath. Створювалася як частина cgmath. На відміну від решти cgmath так собі супроводжувалася і була винесена в окремий крейт. Реалізована далеко не вся потрібна функціональність, тестове покриття так собі, але, зате, побудоване на cgmath, не треба тягнути дві різні математичні бібліотеки.
ncollide — система колізій від nphsysics, використовує nalgebra. Розвивається активно, має красивий сайт. Тестується і розвивається всіма користувачами nphysics.
Entity-component-system:
https://shaneenishry.com/blog/2014/12/27/misconceptions-of-component-based-entity-systems/
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
Досить популярна ідея для проектування ігор, вже є готові растові реалізації:
Specs (https://github.com/slide-rs/specs) — єдина дійсно багатопотокова ecs. Досить активно розвивається, використовується в amethyst.
https://crates.io/keywords/ecs — ціла купа систем, які існували до specs, кожна зі своїми нюансами, описувати кожну — тема для окремої статті.
Коли я починав specs ще не було, і я написав свій велосипед.
Робота з ресурсами:
obj — растовая реалізація .obj, працює :)
Assimp — биндинги до assimp — бібліотеці працює з купою 3д форматів
image — растовая реалізація популярних форматів 2д. Працює, але є нюанс — в cargo немає можливості підключити бінарну/релізну версію залежності до налагоджувальної збірці. З-за чого налагоджувальний Image ну дуже довго відкриває картинки в налагоджувальних збірках. З релизными збірками проблем немає. Чекаємо поки cargo навчиться використовувати залежності з іншими параметрами.
stb-image — биндинги до сишной бібліотеці по роботі з картинками. По функціоналу — аналог image, але вирішує проблему налагоджувальних залежностей — навіть у налагоджувальних збірках працює швидко, тому що сишный код збирається зі своїми власними прапорами.
zip-rs — просто zip архіватор, стискати ресурси.
Робота зі звуком:
ears — просто биндинги до OpenAl. Я користуюся саме їм, для звуків — все відмінно.
vorbis — биндинги до vorbis.
rodio — більш високорівнева робота з vorbis.
GUI:
З гуі справи йдуть не дуже. Ідеальною ігровий гуі бібліотеки поки що не існує. Однак, є:
Imgui — биндинги до imgui. Відмінно працюють разом з glium. Але заточений для інструментарію розробника, не підтримує скіни, незручно верстати нестандартні вікна.
Awesomium awesomium-rs — дорого для інді, C API є тільки у давньої версії. Але працює досить швидко, api — зручне.
Скелетна анімація:
skeletal_animation — є у Piston, але вже покинутий. В json описується граф анімацій, трохи схожий на Mecanim з Unity. Підтримує gpu-скиннинг. Але, на жаль, є залежності і на piston, і на gfx — не так просто інтегрувати в проект на glium.
Фізика:
Оскільки я роблю гру про фізику — для мене це важливе питання. Для раста є тількиgithub.com/sebcrozet/nphysics.
Nphysics складається з nphysics2d і nphysics3d. Для 2д, кажуть, вистачає, а от в 3д справи не дуже — до того ж Bullet по можливості ще далеко, доводилося досить багато дописувати. Однак, роботи йдуть і йдуть досить активно.
Хочеться використовувати Bullet, але до актуальної версії C API ще немає, чекаємо.
Інструментарій:
cargo-апк — додаток до cargo, що дозволяє створювати android apk файл + бібліотека по роботі з оточенням Android з коду.
cargo-profiler — використання valgrind через cargo.
hprof — кадр профайлер, не знайшовши hprof я написав свій такий же, але гірше — tinyprof. Дуже зручно дивитися що відбувається в кожному кадрі.
Як редактор сцен, матеріалів та ігрових сутностей я використовую Blender. Про це, якщо це буде цікаво, я розповім в наступній частині. В цілому я задоволений, зручно.
З IDE ж справи йдуть так:
racer, окремий проект, що надає редакторам дані для автодоповнення і простої навігації. По функціоналу він ще не дотягує навіть до ghc-mod. Існують плагіни для всіх популярних редакторів (Vim, Emacs, Atom, VS Code тощо).
Вже заплановано повноцінний ide-backend 'Oracle'. Це той же racer, але з підтримкою в компіляторі і більше працює.
Плагіни eclipse і visual studio можуть повноцінну налагодження — ходьбу по кроках і т.д.
Можна подивитися результати опитування популярним IDE. Результати дивні — идеевский плагін (наскільки я знаю) один з найбідніших по функціоналу — просто обв'язка над racer.
Детальніше про стан справ можна прочитати тут.
Відкриті гри в розробці:
https://github.com/bfops/playform
https://github.com/ozkriff/zoc
https://github.com/kvark/vange-rs
https://github.com/PistonDevelopers/hematite
https://github.com/kvark/claymore
https://github.com/PistonDevelopers/piston/wiki/Games-Made-With-Piston
Наша гра:
На початку статті відео геймплея нашої гри — це мережевий шутер з синхронної разрушаемостью. Ми поки що у пре-альфі, готуємося до публічної альфі, плейтестам. Шукаємо людей ;)
Співтовариство:
Доброзичливе раст-геймдев спільнота завжди рада відповісти на питання в irc (#rust-gamedev) або в російськомовному гиттере:gitter.im/ruRust/gamedev.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.