Pull to refresh

Comments 38

Статью уже видел, но аккаунт только на хабре, задам накопившиеся вопросы.
Под мобилки пробовали собирать?
OpenAl динамически линкуете?
Для воспроизведения музыки санвоксовский же рантайм используется? Всегда было интересно потыкать, но никогда руки не доходили попробовать. Особенно, собрать под мобилы.
Вопрос про опенсорс уже поднимался, выскажу мнение: чтоб поделиться, причесывать и документировать совсем не обязательно. Все равно может быть полезно: взять готовые экстерны для санвокса, поэкспериментировать с IQM…
  • На мобильные собирать пока не пробовал, но такая возможность в теории есть, так как Haxe/Lime кроссплатформенный.

  • OpenAL-Soft входит в состав Lime, который сам по себе open source и линкуется динамически.

  • Нет, музыка и все звуки — в формате ogg.

  • Спасибо, подумаю.

А исходники движка открыты?

Просто увидел что в системных требованиях только винда и немного погрустнел.

Код движка недоступен. Думаю, что движок слишком узкоспециализирован для общего потребления, а на создание полной документации и поддержку ушло бы много времени. Посчитал, что полезнее было писать такие статьи, в которых делюсь опытом самого процесса разработки.

Говорят, игра работает под Wine/Proton без проблем. Может быть в будущем сделаю нативные билды для Linux.

Категорически не согласен на этот счёт, тем более что в движке используется асинхронная архитектура. Было бы интересно увидеть саму реализацию. Может вам накидают пуллреквестов с добавлением функционала и результат будет велик. Открытие исходников подстегнёт вас к написанию документации и может быть оформлению кода под единый стиль. Если выложить под подходящей лицензией(например, gpl + коммерческая), у вас не украдут проект.

Отличный результат! Вот так и рождаются независимые игроделы, на которых сегодня вся надежда. Успехов!

Лёгкая (в плане эмоций и нагрузки на комп) игра. Здорово, что поддерживается gamepad!

А невидимые грани вы как отсекаете?

Если Вы говорите о culling, то в данной игре этого не происходит.

Уровень практически весь состоит из статичный объектов, которые при загрузке объединяются в одну модель для оптимизации, так что приходится отображать его полностью. В таком объекте не очень много полигонов, так что оптимизировать что-то дальше нет особого смысла. Если бы уровни были намного больше, то, наверное, был бы смысл в такой оптимизации, и я бы резал их на сектора, показывая только те, которые попадают в обзор камеры.

А в чем преимущество привязки логики к какому-то определенному таймеру? В универсальных движках логика завязана на дельту времени, и таким образом тоже отвязывается от кадровой частоты.

Я думаю, это зависит от ситуации. Но на мой взгляд, гораздо удобнее, когда логика работает с определённой частотой.

Главное, чтобы логика была отделена от отображения.

Удобнее, но дельту использует в играх когда определённую частоту соблюсти сложно, к примеру кадр не успел обработаться за 16мс. Если таких кадров 100 то получится слоумо. В оффлайн играх наверно пофиг, в онлайн к сожалению не подойдёт. Довольно сильное ограничение движка, если делать какие то очень нагружённые игры в 16мс на слабом в железке будет уложиться сложно

Если кадр не успевает обработаться за 16мс на целевом железе, то это значит, что пора заниматься оптимизацией или снизить требования к логике/графике. Уложиться в 16мс/32мс (60/30фпс) любыми средствами - это основное требование к производительности любой современной игры на любой платформе

Обычно в качестве аргументов приводят общий детерминизм игровой логики и стабильность физики.

Но есть и минус, если игровая логика выполняется с частотой 62.5 гц, то на экранах с частотой 60 гц будет заметен пропуск кадров, а на экранах с высокой герцовкой изображение не меняется несколько кадров, теряется плавность анимаций. Этого можно избежать, интерполируя все видимые игроку значения (положения объектов, костей в анимациях и т.д.), что влечет значительное усложнение кода движка

В моём движке применяется интерполяция, поэтому все движения остаются плавными. Возможно, стоит написать об этом отдельную статью.

То есть имеется плавающий лаг инпута до 18 мс?

Интерполяция происходит между предыдущим и текущим логическим кадром, поэтому инпут лаг в 16 мс неизбежен.

vrode ranshe osobo ne tracha resursov vsegda schutali tekushyu skorost vychesleniy zaodno ponimaya tekushuyu (obschiyu) nagruzku na ustroistvo da ot raschyota korrekturovalos to chto on nazval система временных шагов ... pro eto dazhe v knishkah iz90yh po sozdaniyu igr na pascale bylo i tam ne nazyvali timerom a imenno tekuschaya skorost vychesleniya kotoray menyala vse neobhodimye zaderzhki obespechivaya plavnost proishodyaschego

Даже если у вас нет русской клавиатуры можно использовать google translate

Прикольно) я как то тоже пытался сделать движок на c++, sdl, opengl. Сделал примитивный 3д рендеринг, чтоб модельки из блендера загружать, примитивнейшую физику в виде гравитации и прямоугольных хитбоксов для вычисления столкновений, пытался еще научиться рисовать. Вдохновлялся ютуберами Thomas Brush и The Cherno. Но чет забил в итоге)

Сам недавно занялся такимже процессом. Сейчас только в начале пути для обработки ввода от игрока выбрал GLFW, а для аудио FMOD, не смотрели в их сторону? И там и там заявляется кроссплатформенность.

Выглядит прикольно =)

Спасибо, про FMOD слышал, но не использовал из-за лицензии.

насколько я понимаю OpenAl тоже не совсем open.

OpenAL-Soft — под лицензией LGPL. Библиотека Lime, которую я использую, включает в себя OpenAL-Soft.

До чего же круто. Успехов! Завидую вам.

Несколько лет назад слышал в чём-то похожую историю от человека, который разрабатывал "убийцу Minecraft". Тоже рассказывал, как с нуля, ничего не зная про 3D, изучал OpenGL, делал свой движок, решал проблемы производительности. Название игры забыл, но работал он тогда в Кемеровском Goodline главным разработчиком интернет-тв.

Смотрится здорово!

посмотрел на сайте ролик про Phantom Path и думаю многим бы зашла такая игра.

Пару вопросов / предложений? к Phantom Path :

- есть возможность добавить GI (global illumination) для теней и источников света? Визуально игра начала бы выглядеть еще привлекательней.

-возможно ли многопользовательская игра? бегать компанией 3-4 человека

-есть вариант портировать на консоли (ps/xbox)?

Понравилась стилистика/динамика у PP, успехов!

Спасибо! Ни GI, ни multiplayer в движке пока нет. Если пригодится для будущих игр, возможно, добавлю. На консоли возможность портировать есть, так как Haxe кроссплатформенный, но пока не пытался.

Многое из того, что я перечислил, присутствует и в других движках, но в YUME есть несколько отличий. Одно из них — система временных шагов

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

Универсальные игровые движки называются так, потому что они предназначены для общего использования, и в них заложены функции, которые не всем нужны. Это неизбежно приводит к "раздуванию" кода, и к замедлению производительности игр.

Есть и обратная сторона медали. Качественные современные движки предлагают хорошие оптимизации для конкретных случаев (например в зависимости от того, какую версию OpenGL поддерживает видеокарта будут использованы разные API - на современных системах какие-то вещи будут работать быстрее). Также, если мы говорим о высоко-реалистичной графике, то туда соваться без готового движка это вообще смерть. Люди там годами только реалистичную воду или деревья создают.

Самое сложное при разработке игры было сохранять мотивацию и интерес на протяжении всех 20 месяцев

Вот за это мое уважение. Хотел бы иметь такую же способность

Потрясающая работа! Люблю игры с душой...

Игра смотрится хорошо на видео. Странно, что вы закончили разработку в 2017 и до сих пор не сделали мобильную версию игры. Зря однако. На ПК в такие казуальные игры мне кажется не играют особо.

Классная работа! Но ещё нужна кроссплатформенность и мультиплеер, хотя бы игра за одним компом вдвоём.

Чел, ты серьезно? Извини, я вряд ли вернусь сюда, Но, ты слышал про Unreal engine 5?) Он хоть и универсальный, но с новыми разработками говорят что он вообще не лагает, автоматическая оптимизация, не важно насколько большие модели будут в плане полигонов. А ты тут свой движок писал 20 месяцев. Это все равно что написать Виндоус заново, хотя он уже есть 20+ лет и у тебя не будет лучше.

Можно было бы критиковать, если бы автор бы начал писать движок и бросил на полпути, что постоянно происходит. Он же довёл работу до конца и выпустил уже 6 своих игр на нём. Если рождается что-то новое можно это только приветствовать.

а сколько весит билд со сценой без ассетов?

Когда писал свой движок, у меня только интерпретатор рантайм-скриптов весил over 20mb.

А когда взял исходник готового движка, того же acid или godot engine, выходной инарник выходил меньше и шустрее.

Как по мне, самодельный движок нужен только, и только, если задача к игре стоит специфичная.
Например воксельная механика или в рантайме очень быстро сплитить меши, или еще какая нибудь не стандартная задача, тип не эфклидовой геометрии..

Молодец автор!!! Проделана огромная работа, получен колоссальный опыт, а это бесценно. Могу лишь порекомендовать слушать музыку разных жанров. Сразу в ухо врезалось, что все мелодии в одной тональности. Учитывая то, что они однотипные и написаны в жанре а-ля 8 бит, музыка начала стучать в мозг к концу демо ролика. Хотелось бы большего разнообразия. Но стиль выбран удачно, на мой взгляд!!!

Я тоже прямо сейчас пишу свой движок, и конкретно сейчас почти его закончил, пишу на sfml с парой докинутых туда файликов)) Как вы сделали свет, как обычный openGL'евский свет или через шейдеры? Я пытаюсь через первый вариант, и почему-то на большие объекты плохо ложится...

Sign up to leave a comment.

Articles