Здравствуйте! Я занимаюсь разработкой игры на 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 — маленький, простой графический движок. Не богат на функционал, но к этому и не стремится. Позволяет создавать окна и рисовать графические примитивы. Выглядит поддерживаемым, но активной разработки не замечено. С другой стороны — оно уже полностью готово, свои функции выполняет.
Готовые графические движки:
Piston PistonDevelopers — по сути, это огромное количество проектов объединенных общей целью — стать, когда-нибудь, модульным игровым движком. "Не в каждом раст проекте есть пистон целиком, но в каждом есть немного пистона" (“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 архиватор, cжимать ресурсы.
Работа со звуком:
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-apk — дополнение к 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, использует идеевский автокомплит, который пока что работает даже хуже 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.
Комментарии (55)
k12th
27.06.2016 15:07+1Расскажите про Blender как редактор сцен и прочего, думаю, это интересно не только rust-игроделам.
JeriX
27.06.2016 15:10Поддерживаю!
Как вы используете Blender: читаете Assimp'ом бинарник blend или экспортируете в какой-то свой бинарный или текстовый формат сцены?
З.Ы. Спасибо за статью :)
FL3
27.06.2016 15:30+1в двух словах — из блендера пишем иерархию объектов, метаданные, пути до энтитей с компонентами в отдельный toml + экспортируем отдельно каждый уникальный меш.
assimp не используем, у нас свой формат, основанный на валвоском .smd.
alexshelkov
27.06.2016 15:48Мне очень нравится идея «синхронной разрушаемости». Странно что никто в гейм индустрии не делал акцент именно на полностью разрушаемом мире. Было бы очень круто и весело иметь шутер, где можно было бы разнести весь мир на куски. Или есть какие то причины, которые просто технологически не позволяют создать подобное?
FL3
27.06.2016 15:58+2Очень тяжело считать предсказания в условиях падающих стен, поэтому тяжело сделать быстрый геймплей
Очень дорого считать физику на серверах и почти невозможно построить шутер без авторитарного сервера
Поэтому большим компаниям это не интересно, и, поэтому, у нас с быстрым растом есть все шансы! :)
eugzol
27.06.2016 15:59+1Red Faction же
FL3
27.06.2016 16:00только он и есть, к сожалению :(
Rast1234
27.06.2016 18:05+3Где-то видел то ли интервью, то ли дневники разработчиков Red Faction Guerrilla, там немного рассказывали об оптимизациях физики (она же на PS3/X360 выходила еще) и проблемах с сетью. Говорили, что было очень много упрощений по сравнению с изначальными задумками, и очень много поисков «магических констант». Из-за этого, например, трехэтажное здание может спокойно стоять на одной последней недобитой подпорке, а падающая постройка в процессе падения «складывается» внутрь, исчезает в клубах пыли и оставляет относительно мало обломков. Автомобилей и роботов в сетевом режиме нет из-за непредсказуемости.
Но даже с такой упрощенной физикой играть по сети чертовски весело! Будет круто, если у вас получится. Игр с более-менее честной разрушаемостью очень не хватает. Готов побегать в альфе, пособирать стактрейсы)
evans2094
27.06.2016 16:07никто в гейм индустрии не делал акцент именно на полностью разрушаемом мире.
Чем вам minecraft неугодил? Ну и dwarf fortress?FL3
27.06.2016 16:50+3там не та разрушаемость и не тот жанр.
в майнркафте (более релеванты были бы шутеры типа block n load, ace of spaded) нельзя вытащить самый нижний блок и обрушить мост. Вот именно такой разрушаемости очень мало.evans2094
27.06.2016 17:03+1Silent storm имеет приличную графику по совместительству с внушительной разрушаемостью
Проблема в том что если делать игру вокруг разрушения — она будет интересна в первую очередь пироманам и другим юным взрывникам. Не отобьет затрат на производство, которое сопряжено с нехилыми вложениями (да и железо потребуется очень неслабое).FL3
27.06.2016 17:11Silent storm это тоже не о том.
Именно в шутерах наличие физики — это не только прикольные взрывы, это, в основном, разные тактические уловки связанные с физикой, каждый раз разные сценарии игры (можно закидать коридор мусором и локация уже полностью меняется, можно всей командой подсадить одного лазутчика на высокую стену что бы он украл шары, хех) ну и всякое такое.evans2094
27.06.2016 17:33+1Вы очень корректно описали то, что обычно называется «конкретный геморрой для левел дизайнера».
Именно оттуда растут высокие цены такой разработки. Тоесть полное разрушение = высокие требования к пользовательской станции + песочница + долгая и мучительная разработка.
Ибо, если вы не в курсе, гномья крепость, несмотря на ASCII графику, на больших размерах карты весьма жестко лагает, а бывает и умирает съев всю память. И это при том что там камушки покрупнее майенкрафтовских и никаких щепочек и прочего нет. Аутентично реальному упавшая и расколовшаяся бетонная плита при попытке вычисления этого процесса в реалтайме — просто испарит i7.
Так что максимум на что вы можете рассчитывать в наше время это разрушаемые объекты (на заранее назначенные осколки, которые падают в соответствии с PhysX), и возможно чуть чуть копаемый ландшафт (как в Life is feudal, но адски лагает).
Полное разрушение всего это значит отработка хотябы текстур осколков, моделей деформации (ни в одной игре не видел согнутую физическим движком металлическую балку), моделей разрушения. В общем пока хватит и того что в предыдущем обзаце.FL3
27.06.2016 17:38так мы пока что и не готовы крошить бетонные плиты. Для тех игровых моментов что я описал полностью хватает нашего уровня детализации — который в видео в начале поста.
evans2094
27.06.2016 17:43Очень тяжело сделать интересным уровень, который можно легко сломать весь. В лучшем случает как в red faction или Deus Ex: HR. Ломать можно, но только в специально предназначенных для этого местах.
FL3
27.06.2016 17:45+1доделаем публичную играбельную версию — прямо в эту ветку комментариев её положу и послушаю фидбек :)
evans2094
27.06.2016 18:03Матчевый бой с полным разрушением (в том числе земли) при наличии гравитации? Вы о связанных с этим проблемах думали? Это как мошонку прибить к красной площади. Дело то нехитрое, но зачем и кто будет в это страдать?
Сделайте бой в поясе астероидов на джетпаках. И ломать все проще и физику можно сделать натуральнее. И типа уникальная на текущий момент ниша. Особенно если отказаться от идеи вязкого космоса.FL3
27.06.2016 18:06почем всего то? посмотрите видео! мы ломаем мосты, стены, подпорки всякие.
Пол нерушим!evans2094
28.06.2016 12:13+1Если по честному, то в демке вы ничего не ломаете. Кубики как были отдельными объектами, так и остались. Отсутствует деформация объектов. Я даже не уверенн что есть трение как динамический процесс зависящий от площади соприкосновения (тогда бы кубики немного подругому расползались).
Rast1234
27.06.2016 20:52В том же Red Faction можно невзначай разрушить мост и остаться на маленьком островке карты, но для решения таких проблем разработчики сделали оружие — реконструктор. Оно просто восстанавливает разрушенные постройки до исходного состояния.
Cryvage
28.06.2016 08:58На практике, даже просто тот факт, что уровень в игре создается динамически, например игра предоставляет редактор карт, может дать просадку в производительности. Во всяком случае в Unity так. Из справки Unity:
Оптимизация для CPU — количество draw call (в дальнейшем, DC)
В процессе визуализации любого объекта на экране CPU должен немного потрудиться: выяснить, какие источники света влияют на объект, настроить шейдер и его параметры, отправить команды отрисовки графическому драйверу, который подготовит команды для отправки на видеокарту. Все эти операции могут быть не очень дешёвыми в своей сумме, если у вас есть много видимых объектов.
Для примера, если у вас есть тысяча треугольников, то будет намного дешевле разместить их в одном меше, чем использовать тысячу отдельных мешей для каждого треугольника. Стоимость обоих сценариев для GPU будет примерно одинаковой, но работа, выполняемая CPU для тысячи объектов вместо одного будет намного большей по объёму.
Чтобы снизить нагрузку на CPU, старайтесь уменьшить количество видимых объектов:
Объединяйте близко расположенные объекты: вручную или используя инструмент draw call batching в Unity.
Используйте меньше материалов, объединяйте текстуры в большие текстурные атласы.
Используйте меньше объектов, которые должны визуализироваться несколько раз.
Объединяйте объекты так, чтобы каждый меш содержал хотя бы несколько сотен треугольников и использовал только один Материал. Важно понимать, что объединение двух объектов, использующих разные материалы, не даст увеличения производительности.
Если уровень создан заранее в редакторе, то его можно оптимизировать, объединив объекты в один. Если же он создается динамически, то объекты уже не объединишь. Так же нельзя заранее рассчитать освещение для объектов снаружи, только в помещениях (если, конечно, их внутренний интерьер задан жестко, а не собирается, так же, динамически).
Конечно, готовый движок накладывает дополнительные ограничения. Если делать движок самому, пространство для маневра будет больше. Но тем не менее, неочевидных граблей, просто вагон и маленькая тележка. Это я еще физики не касался. В частности, меня в свое время неприятно удивил тот факт, что в большинстве игр, в отличие от остальных объектов, игрок — не подчиняется физике. Это просто капсула, управляемая примитивным скриптом.
Игру-песочницу намного сложней оптимизировать, просто потому, что там меньше мест, где можно схитрить, и «обмануть» пользователя, создав красивую иллюзию. Многие вещи приходится делать «честно».evans2094
28.06.2016 14:07Я гдето к тому и веду. Если красиво, правильно и по честному взорвать стенку — появится много новых мешей. Можно искуственно ограничить разрушения балансом (1 бомба на команду и ни каплей больше), но игроки они ведь такие. Возьмут и рванут несущую опору у моста так, что сначала сервер подвиснет считать разрушения, и потом еще в ЦПУ прилетит обсчет пары миллионов новых мешей и он перейдет в режим турбогриля.
Движок под песочницу — идея хороша, но движок должен быть шибко умный. Или заранее все объекты разделдять на субэлементы чтобы не было резкой просадки по производительности. Но это условный плюс. При таком подходе производительность просто изначально будет хреновой и ей падать будет некуда.
l4l
27.06.2016 15:59Спасибо за обзор, очень не хватало подобного списка с кратким описанием.
И следом пару вопросов:
Кажется на YC мелкала ссылка на результаты опросника про rust, где достаточно много респондентов сказали, что используют nightly-билды компилятора. Есть мысли на этот счет? И какую ветку сами используете?
Как часто приходится юзать unsafe-код?
Не находили memory leak-и в компиляторе/своем коде?FL3
27.06.2016 16:28+3на билд машине для виндового билда использую stable
для разработки использую nightly. Единственное ради чего nighly — я через compiler intristics узнаю всякое для профайлера.
компилятор стабилен, на самых свежих nigtly я видел настоящие баги и падения, но — очень редко. Если хотя бы недельной давности nigtly — то всё вообще путём.
мемори лик был один раз — сервер падал с out of memory (я был удивлён, раст, безопасность, и out of memory?). Оказалось я всё в том же профайлере хранил вообще все фреймы.
Настоящий мемори лик получить практически нереально.
unsafe от безысходности я использовал один раз, и это привело к тому, что я писал мимо памяти, прямо как в c++.
Отвратительный код!функция была примерно такая https://is.gd/PzW9O4 (без unsafe я бы мог написать только так: https://is.gd/gXIbJx).
я захотел обмануть раст, получить ссылки на элементы массива, да при этом еще и иметь возможность менять массив.
В результате — очевидные проблемы. С помощью unsafe можно взять отвестветнность на себя и делать такие вот вещи, но — лучше не стоит.l4l
27.06.2016 17:23Ээ, а вы ссылку не перепутали? Если нет то каким чудом lifetime может сделать код safe?
FL3
27.06.2016 17:31+2unsafe позволил написать функцию с такой сигнатурой:
fn get_by_ids<'a>(data : &mut Vec, ids : &HashSet) -> Vec<&'a mut Foo>
то есть я получаю массив мутабельных ссылок, не связанную лайфтаймом с исходным массивом.
и такую функцию можно написать только с unsafe. Ну и она супер не правильная, так не надо писать!
а безопасная выглядела бы так:
fn get_by_ids<'a>(data : &'a mut Vec, ids : &HashSet) -> Vec<&'a mut Foo>
с такой сигнатурой, раст запретил бы мне делать data.clear() и всё было бы хорошо. И примерно такую сигнатуру можно получить безо всяких unsafe внутри.l4l
27.06.2016 17:41Ммм, какое хитрое шаманство, ясно :)
Наверное стоило запустить код, мне почему-то показалось, что они оба валидны
kstep
27.06.2016 17:49Нет, без unsafe не валиден, будет ошибка компиляции:
<anon>:17:5: 17:9 error: cannot borrow `data` as mutable more than once at a time [E0499] <anon>:17 data.clear();
ozkriff
28.06.2016 10:28+1достаточно много респондентов сказали, что используют nightly-билды компилятора. Есть мысли на этот счет?
Я тут добавлю, что с тех пор как rustup довели до ума, переключаться между разными версиями компилятора на одной машине стало дико просто. Лично мне ночная сборка бывает нужна, допустим, для локальной установки статического анализатора clippy, что бы не гонять CI-сборки тысячу раз для вычистки новых предупреждений.ozkriff
28.06.2016 11:39+1И да, новый формат сообщений от компилятора очень удобный для чтения человеком, ради него сейчас ночную сборку как основную и использую.
grossws
27.06.2016 16:06Если вы про этот идеевский плагин, то он не использует racer. Он неплохо развивается, но пока слабоват в сравнении с racer/ycmd.
BlessMaster
27.06.2016 19:53+1Чем так хорош идеевский плагин? Тем что он даёт возможность использовать Идею.
Того минимума, что есть в плагине — достаточно для сносной работы, но при этом открываются не бедные и привычные по другим IDE от IntelliJ возможности и workflow, которые окупают все недостатки пока ещё слабой поддержки Rust.
FrozenTwilight
27.06.2016 22:34+3Приятно видеть, что Rust набирает популярность т.к. язык весьма интересный и перспективный.
Недавно наткнулся на библиотеку векторной графики, разрабатывается она тоже на Rust.
Вот описание с сайта проекта: «Polydraw is a 2D vector graphics engine written in the Rust programming language for the development of rich interactive applications and games.»
Вот ссылка на GitHub: Polydrawozkriff
28.06.2016 10:46Интересно, зачем они все привязки используют свои собственные? О.о Даже инициализация контекста своя для каждой платформы, хотя давно уже есть glutin.
snuk182
28.06.2016 00:04Одно время назад пытался написать на расте игру и уперся в «ограничение, которое так и надо» — невозможность оперировать только абстракциями в расте. С постоянно выпрыгивающей руганью на Sized я бороться устал и все забросил. Теперь читаю ваш пост, и очень интересно посмотреть на внутренности того, что вы делаете, применимо к парадигмам Раста. Вы случайно не планируете если не опенсорсить движок, то хотя бы рассказать, как там что взаимосвязано.
FL3
28.06.2016 00:47+1entity system example — примерно вот так у нас вся игра и написана.
Рассказать планирую :)
red75prim
28.06.2016 00:55+1Если понимать под абстракцией структуру неизвестного на этапе компиляции размера, реализующую определенный набор интерфейсов, то, как следует из её определения, работать с ней на стеке нельзя — только в куче. То есть, такие абстракции нужно оборачивать в Box (владеющий указатель на структуру, располагающуюся в куче).
Ошибки, связанные с Sized, скорее всего были вызваны именно попыткой поместить структуру неизвестного размера на стек или в массив.snuk182
29.06.2016 00:00Да это я знаю. Просто довольно тяжело пытаться играть в честный ооп, инкапсулируя имплементацию вообще всего и работать с трейтами, которые «не интерфейсы», и в этом случае данный факт очень хорошо чувствуется. А не в ооп играть — тяжко, глобально архитектурить без ооп я еще не умею.
semenyakinVS
29.06.2016 14:42Понимаю, что могу отхватить за этот вопрос, но всё таки… Чем не подошёл С++? Возможно, я упустил обоснование выбора в пользу Rust где-то в статье — тогда заранее извиняюсь.
kstep
29.06.2016 14:55+7Человеку понравилась идея сильной системы типов с высокими гарантиями безопасности (Хаскель), но у Хаскеля большие проблемы с реал-таймом из-за GC и высокие накладные расходы на память по сравнению с более низкоуровневыми языками, что не очень хорошо для геймдева. Раст даёт высокие гарантии безопасности при работе с памятью, имеет мощную систему типов с выводом типов (в этом похож на Хаскель), но при этом низкоуровневый и имеет нулевые накладные расходы на управление памятью (статическая проверка корректности указателей во время компиляции), что делает его интересным выбором для геймдева.
semenyakinVS
29.06.2016 17:27Ясно. Спасибо!..
статическая проверка корректности указателей во время компиляции
Ничего себе… Круто, погуглю. Пока не представляю как это может работать — указатели ведь на то и указатели, чтобы в рантайме меняться.
DarkEld3r
29.06.2016 17:51+1Речь о том, что нельзя забыть "проверить указатель". В том смысле, что нельзя его разыменовать без проверки.
FL3
29.06.2016 19:07+3в безопасном расте невозможно получить и соответственно разименовать невалидный указатель
http://rurust.github.io/rust_book_ru/src/ownership.html < — вот здесь описан этот механизм защищающий указателиsemenyakinVS
29.06.2016 20:34Спасибо. Почитал. Похоже на ссылки (и, в некотором роде, на умные указатели — однако в Rust они ещё и компайлтайм выходят) из С++ с некоторым ограничениями и синтаксическим сахаром (для понятия «время жизни»)…
Выглядит достаточно удобным. На плюсах для реализации подобного контроля кода пришлось бы статический анализатор подключать. А «время жизни» даже анализатор не смог бы контролировать. Разве что через какие-то хитрые аннотации в комментах (в комментах — так как плюсы с какого-то перепугу не поддерживают пользовательские аннотации), что не есть хорошо.FL3
29.06.2016 21:12+3Всё так! действительно чем-то похоже на умные указатели, и действительно существуют только на уровне статического анализа при компиляции.
Еще эта штука с борроу-чекером классно помогает с многопоточностью (перевод) — гарантирует отсутствие data-races, а это тоже здорово :)
Terras
А можно уточнить коммерческие прогнозы игрушки, что вы делаете?
Могу конечно ошибаться, и скорее всего ошибаюсь, но мне кажется, что малыми силами можно лишь выпустить небольшую инди игрушку и как-то попытаться зацепиться за деньги. По типу Лимбо, допустим.
FL3
Наш план — сделать игру с уникальной механикой (синхронная разрушаемость, командная игра с шаром) и найти свою аудиторию, готовую мириться с малым количеством контента ради специфичного игрового опыта.
А уже с аудиторией превратить малые силы — в большие!
Примерно так :)
Optik
Выглядит странно, что сначала делается продукт, а потом ищется аудитория, готовая его купить.
mamkaololosha
> Под впечатлением вот этого выступления
За месяц написали продакшн квалити или «просто рисует куб на Opengl 3.3 с тенями из тутроиалов»?
FL3
не очень понятно к чему вопрос, но конечно я не начал писать production quality код за полгода (или сколько там было) экспериментов с haskell.