Комментарии 67
Могу конечно ошибаться, и скорее всего ошибаюсь, но мне кажется, что малыми силами можно лишь выпустить небольшую инди игрушку и как-то попытаться зацепиться за деньги. По типу Лимбо, допустим.
А уже с аудиторией превратить малые силы — в большие!
Примерно так :)
Наш план — сделать игру с уникальной механикой (синхронная разрушаемость, командная игра с шаром) и найти свою аудиторию
Выглядит странно, что сначала делается продукт, а потом ищется аудитория, готовая его купить.
За месяц написали продакшн квалити или «просто рисует куб на Opengl 3.3 с тенями из тутроиалов»?
Как вы используете Blender: читаете Assimp'ом бинарник blend или экспортируете в какой-то свой бинарный или текстовый формат сцены?
З.Ы. Спасибо за статью :)
Очень дорого считать физику на серверах и почти невозможно построить шутер без авторитарного сервера
Поэтому большим компаниям это не интересно, и, поэтому, у нас с быстрым растом есть все шансы! :)
Но даже с такой упрощенной физикой играть по сети чертовски весело! Будет круто, если у вас получится. Игр с более-менее честной разрушаемостью очень не хватает. Готов побегать в альфе, пособирать стактрейсы)
никто в гейм индустрии не делал акцент именно на полностью разрушаемом мире.
Чем вам minecraft неугодил? Ну и dwarf fortress?
в майнркафте (более релеванты были бы шутеры типа block n load, ace of spaded) нельзя вытащить самый нижний блок и обрушить мост. Вот именно такой разрушаемости очень мало.
Проблема в том что если делать игру вокруг разрушения — она будет интересна в первую очередь пироманам и другим юным взрывникам. Не отобьет затрат на производство, которое сопряжено с нехилыми вложениями (да и железо потребуется очень неслабое).
Именно в шутерах наличие физики — это не только прикольные взрывы, это, в основном, разные тактические уловки связанные с физикой, каждый раз разные сценарии игры (можно закидать коридор мусором и локация уже полностью меняется, можно всей командой подсадить одного лазутчика на высокую стену что бы он украл шары, хех) ну и всякое такое.
Именно оттуда растут высокие цены такой разработки. Тоесть полное разрушение = высокие требования к пользовательской станции + песочница + долгая и мучительная разработка.
Ибо, если вы не в курсе, гномья крепость, несмотря на ASCII графику, на больших размерах карты весьма жестко лагает, а бывает и умирает съев всю память. И это при том что там камушки покрупнее майенкрафтовских и никаких щепочек и прочего нет. Аутентично реальному упавшая и расколовшаяся бетонная плита при попытке вычисления этого процесса в реалтайме — просто испарит i7.
Так что максимум на что вы можете рассчитывать в наше время это разрушаемые объекты (на заранее назначенные осколки, которые падают в соответствии с PhysX), и возможно чуть чуть копаемый ландшафт (как в Life is feudal, но адски лагает).
Полное разрушение всего это значит отработка хотябы текстур осколков, моделей деформации (ни в одной игре не видел согнутую физическим движком металлическую балку), моделей разрушения. В общем пока хватит и того что в предыдущем обзаце.
Сделайте бой в поясе астероидов на джетпаках. И ломать все проще и физику можно сделать натуральнее. И типа уникальная на текущий момент ниша. Особенно если отказаться от идеи вязкого космоса.
Пол нерушим!
Оптимизация для CPU — количество draw call (в дальнейшем, DC)
В процессе визуализации любого объекта на экране CPU должен немного потрудиться: выяснить, какие источники света влияют на объект, настроить шейдер и его параметры, отправить команды отрисовки графическому драйверу, который подготовит команды для отправки на видеокарту. Все эти операции могут быть не очень дешёвыми в своей сумме, если у вас есть много видимых объектов.
Для примера, если у вас есть тысяча треугольников, то будет намного дешевле разместить их в одном меше, чем использовать тысячу отдельных мешей для каждого треугольника. Стоимость обоих сценариев для GPU будет примерно одинаковой, но работа, выполняемая CPU для тысячи объектов вместо одного будет намного большей по объёму.
Чтобы снизить нагрузку на CPU, старайтесь уменьшить количество видимых объектов:
Объединяйте близко расположенные объекты: вручную или используя инструмент draw call batching в Unity.
Используйте меньше материалов, объединяйте текстуры в большие текстурные атласы.
Используйте меньше объектов, которые должны визуализироваться несколько раз.
Объединяйте объекты так, чтобы каждый меш содержал хотя бы несколько сотен треугольников и использовал только один Материал. Важно понимать, что объединение двух объектов, использующих разные материалы, не даст увеличения производительности.
Если уровень создан заранее в редакторе, то его можно оптимизировать, объединив объекты в один. Если же он создается динамически, то объекты уже не объединишь. Так же нельзя заранее рассчитать освещение для объектов снаружи, только в помещениях (если, конечно, их внутренний интерьер задан жестко, а не собирается, так же, динамически).
Конечно, готовый движок накладывает дополнительные ограничения. Если делать движок самому, пространство для маневра будет больше. Но тем не менее, неочевидных граблей, просто вагон и маленькая тележка. Это я еще физики не касался. В частности, меня в свое время неприятно удивил тот факт, что в большинстве игр, в отличие от остальных объектов, игрок — не подчиняется физике. Это просто капсула, управляемая примитивным скриптом.
Игру-песочницу намного сложней оптимизировать, просто потому, что там меньше мест, где можно схитрить, и «обмануть» пользователя, создав красивую иллюзию. Многие вещи приходится делать «честно».
Движок под песочницу — идея хороша, но движок должен быть шибко умный. Или заранее все объекты разделдять на субэлементы чтобы не было резкой просадки по производительности. Но это условный плюс. При таком подходе производительность просто изначально будет хреновой и ей падать будет некуда.
И следом пару вопросов:
Кажется на YC мелкала ссылка на результаты опросника про rust, где достаточно много респондентов сказали, что используют nightly-билды компилятора. Есть мысли на этот счет? И какую ветку сами используете?
Как часто приходится юзать unsafe-код?
Не находили memory leak-и в компиляторе/своем коде?
для разработки использую nightly. Единственное ради чего nighly — я через compiler intristics узнаю всякое для профайлера.
компилятор стабилен, на самых свежих nigtly я видел настоящие баги и падения, но — очень редко. Если хотя бы недельной давности nigtly — то всё вообще путём.
мемори лик был один раз — сервер падал с out of memory (я был удивлён, раст, безопасность, и out of memory?). Оказалось я всё в том же профайлере хранил вообще все фреймы.
Настоящий мемори лик получить практически нереально.
unsafe от безысходности я использовал один раз, и это привело к тому, что я писал мимо памяти, прямо как в c++.
я захотел обмануть раст, получить ссылки на элементы массива, да при этом еще и иметь возможность менять массив.
В результате — очевидные проблемы. С помощью unsafe можно взять отвестветнность на себя и делать такие вот вещи, но — лучше не стоит.
В общем — unsafe — опасен! не используйте unsafe :)
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 внутри.
достаточно много респондентов сказали, что используют nightly-билды компилятора. Есть мысли на этот счет?
Я тут добавлю, что с тех пор как rustup довели до ума, переключаться между разными версиями компилятора на одной машине стало дико просто. Лично мне ночная сборка бывает нужна, допустим, для локальной установки статического анализатора clippy, что бы не гонять CI-сборки тысячу раз для вычистки новых предупреждений.
И да, новый формат сообщений от компилятора очень удобный для чтения человеком, ради него сейчас ночную сборку как основную и использую.
Если вы про этот идеевский плагин, то он не использует racer. Он неплохо развивается, но пока слабоват в сравнении с racer/ycmd.
Того минимума, что есть в плагине — достаточно для сносной работы, но при этом открываются не бедные и привычные по другим IDE от IntelliJ возможности и workflow, которые окупают все недостатки пока ещё слабой поддержки 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: Polydraw
Интересно, зачем они все привязки используют свои собственные? О.о Даже инициализация контекста своя для каждой платформы, хотя давно уже есть glutin.
Рассказать планирую :)
По мне так у него хороший уровень абстракции — и от OpenGL далеко не уезжаем и некую безопасность имеем.
смотрел автогенеренные байндинги к GL — у них какой-то костыльный вызов.
А что такого костыльного gl-rs делает?
странно, почему это нельзя автоматизировать
Struct generator.
в следующем абзаце:
Static generator
The static generator generates plain old bindings. You don't need to load the functions.
С ним всё хорошо, генерируются функции которые сами всё грузят как надо, автоматизация! :)
и этот самый Static generator и используется в glium.
This generator should only be used only if the platform you are compiling for is guaranteed to support the requested API. Otherwise you will get a compilation error.
Это статический генератор. Имхо это верное решение, иначе какой смысл собирать, к примеру, поддержку OpenGL ES на Windows, если ее там нет?
Ошибки, связанные с Sized, скорее всего были вызваны именно попыткой поместить структуру неизвестного размера на стек или в массив.
Просто довольно тяжело пытаться играть в честный ооп, инкапсулируя имплементацию вообще всего и работать с трейтами, которые «не интерфейсы», и в этом случае данный факт очень хорошо чувствуется. А не в ооп играть — тяжко, глобально архитектурить без ооп я еще не умею.
А в чем разница с C++
в этой плоскости?
В C++ тоже нельзя создать объект класса с чисто виртуальными функциями,
на стеке, а потом на его место записать объект наследника. Да и вообще
с созданием объекта "класса с чисто виртуальными функциями" возникнут
некоторые проблемы. Придется как в Rust где-то (например в куче) хранить "конкретные" объекты и передавать куда нужно указатели на абстрактный класс.
И ничего живут же как-то, в ООП играют уже много лет.
Человеку понравилась идея сильной системы типов с высокими гарантиями безопасности (Хаскель), но у Хаскеля большие проблемы с реал-таймом из-за GC и высокие накладные расходы на память по сравнению с более низкоуровневыми языками, что не очень хорошо для геймдева. Раст даёт высокие гарантии безопасности при работе с памятью, имеет мощную систему типов с выводом типов (в этом похож на Хаскель), но при этом низкоуровневый и имеет нулевые накладные расходы на управление памятью (статическая проверка корректности указателей во время компиляции), что делает его интересным выбором для геймдева.
статическая проверка корректности указателей во время компиляции
Ничего себе… Круто, погуглю. Пока не представляю как это может работать — указатели ведь на то и указатели, чтобы в рантайме меняться.
Речь о том, что нельзя забыть "проверить указатель". В том смысле, что нельзя его разыменовать без проверки.
http://rurust.github.io/rust_book_ru/src/ownership.html < — вот здесь описан этот механизм защищающий указатели
Выглядит достаточно удобным. На плюсах для реализации подобного контроля кода пришлось бы статический анализатор подключать. А «время жизни» даже анализатор не смог бы контролировать. Разве что через какие-то хитрые аннотации в комментах (в комментах — так как плюсы с какого-то перепугу не поддерживают пользовательские аннотации), что не есть хорошо.
Еще эта штука с борроу-чекером классно помогает с многопоточностью (перевод) — гарантирует отсутствие data-races, а это тоже здорово :)
Показалось, что фичей одинаково не хватает как для игрового гуя(хочется какую-то внешнюю вёрстку и возможности делать красивые эффекты) так и для тулзового гуя(я в основном сравнивал картинки с imgui и не особо внимательно смотрел на внутренности conrod).
Разработка игр на Rust. Обзор экосистемы