Вот небольшой видос, на котором видно текущий прогресс
Мир, очевидно, бесконечный, процедурный и все такое. Есть несколько (три) тулзы для модификации террейна - сферическая тулза, кубическая (которая работает супер хуево, наверное я ее поменяю) и flatter тулза, которая делает ровную поверхность (спиздил идею из Astroneer)
Ни противников, ни чего-либо похожего, сейчас нет
Мир, очевидно, бесконечный, процедурный и все такое. Есть несколько (три) тулзы для модификации террейна - сферическая тулза, кубическая (которая работает супер хуево, наверное я ее поменяю) и flatter тулза, которая делает ровную поверхность (спиздил идею из Astroneer)
Ни противников, ни чего-либо похожего, сейчас нет
Бля, круто, хочу игру с вот такой вот пустынней и такими вот туннелями. Типа субнаутики, только в пустыне с туннелями.
Space engineers, только играть в неё скучно и оч непонятно
Видос не запускается. Делай webm
Надеюсь, что не слишком шакально вышло
Чет пиздец какой-то, нет, так не пойдет. Не думал, что самой сложной задачей за три месяца окажется нормальная конвертация в webm
Сегодня было не очень много времени на работу, к сожалению
Немного обновил систему настроек - теперь при обновлении настройки "цвет тумана" будет одновременно обновлен backgroundColor у камеры (да, сейчас у меня не используется скайбокс) и fogColor у RenderSettings
Ну и большую часть времени пытался разобраться с шейдером для террейна
Тут стоит сказать, что я вчера написал генератор этого самого шейдера, который создает все требуемые мне файлы. Смысл этого действия состоит в том, что для поддержки различных террейн материалов (dirt и stone на данный момент, но в перспективе их будет больше) требуется много копипасты в коде шейдера. Поэтому я решил заранее избавить себя от этих проблем. За основу взял темплейт URP-шейдера, найденный на гитхабе
И вроде этот генератор работает, создает файлы, все такое, но normal map и прочие map нормально не сэмплируются (насколько я вижу), а diffuse map сэмплируется корректно. И вот я не знаю, с чем связана данная проблема
На первом скрине можно видеть тестовый шейдер, который я правил вручную, и у которого только один набор карт используется. С ним все работает корректно (normal map сэмплируется). А на втором скрине (и на всех скринах в этом треде) можно видеть сгенерированный шейдер. Я специально сейчас выкрутил все параметры, чтобы было максимально заметно некорректное поведение
Немного обновил систему настроек - теперь при обновлении настройки "цвет тумана" будет одновременно обновлен backgroundColor у камеры (да, сейчас у меня не используется скайбокс) и fogColor у RenderSettings
Ну и большую часть времени пытался разобраться с шейдером для террейна
Тут стоит сказать, что я вчера написал генератор этого самого шейдера, который создает все требуемые мне файлы. Смысл этого действия состоит в том, что для поддержки различных террейн материалов (dirt и stone на данный момент, но в перспективе их будет больше) требуется много копипасты в коде шейдера. Поэтому я решил заранее избавить себя от этих проблем. За основу взял темплейт URP-шейдера, найденный на гитхабе
И вроде этот генератор работает, создает файлы, все такое, но normal map и прочие map нормально не сэмплируются (насколько я вижу), а diffuse map сэмплируется корректно. И вот я не знаю, с чем связана данная проблема
На первом скрине можно видеть тестовый шейдер, который я правил вручную, и у которого только один набор карт используется. С ним все работает корректно (normal map сэмплируется). А на втором скрине (и на всех скринах в этом треде) можно видеть сгенерированный шейдер. Я специально сейчас выкрутил все параметры, чтобы было максимально заметно некорректное поведение
Плюс попытка номер два залить видос
Пробуй через эту программу Movavi Screen Recorder 11 делать видео с экрана.
А здесь https://convert-video-online.com/ru/ конвертируй в меньший размер.
А здесь https://convert-video-online.com/ru/ конвертируй в меньший размер.
Записывай через OBS и будет тебе счастье
Короче, сегодня после работы пытался разобраться с шейдером. На данный момент я только понял, что скорее всего превысил максимальное количество texture sampler'ов. Больше у меня особо идей нет. Но оно в целом выглядит реалистично, т.к. в своем генераторе я втупую скопировал структуру template-шейдера, а там для каждой из карт материала используется отдельный шейдер. В моем случае же получается, что количество этих карт умножается на количество материалов * 2, что даже при двух только материалах дает просто огромное количество этих самых sampler'ов.
Посему я решил избрать другой подход - я убрал из шейдера всё, кроме diffuse map. Все остальные значения либо вовсе выпилил, либо заменил на константы. А теперь, когда он работает в таком минимальном состоянии, буду добавлять всякие плюшки, если посчитаю это нужным. Ну и еще там видимо нужно будет как-то вместо одного shader pass использовать несколько, если все-же количество sampler'ов будет слишком большим (по крайней мере я прочитал, что так советую решать эту проблему). Буду смотреть, в общем.
И сделал небольшую таску - добавил фонарик для игрока. Мелочь, а приятно.
Думаю, что дальше так и буду стараться делать - часть большой таски + небольшие задачи, на которые не должно уходить много времени.
Спасибо большое за советы. Попробую эти варианты, как будет время
Посему я решил избрать другой подход - я убрал из шейдера всё, кроме diffuse map. Все остальные значения либо вовсе выпилил, либо заменил на константы. А теперь, когда он работает в таком минимальном состоянии, буду добавлять всякие плюшки, если посчитаю это нужным. Ну и еще там видимо нужно будет как-то вместо одного shader pass использовать несколько, если все-же количество sampler'ов будет слишком большим (по крайней мере я прочитал, что так советую решать эту проблему). Буду смотреть, в общем.
И сделал небольшую таску - добавил фонарик для игрока. Мелочь, а приятно.
Думаю, что дальше так и буду стараться делать - часть большой таски + небольшие задачи, на которые не должно уходить много времени.
Спасибо большое за советы. Попробую эти варианты, как будет время
Только сейчас понял, что возникла путаница в использовании слова "материал". Чтобы было более понятно опишу лучше так : на каждый "игровой материал" (или "террейн материал", как удобней) требуется два "материала" (в стандартном смысле слова, который используется в контексте компьютерной графики). Надеюсь, что так понятней стало, хз
Оп, это marching cubes?
Планируешь физику к висящим блокам прикручивать?
Как хранишь данные?
Планируешь физику к висящим блокам прикручивать?
Как хранишь данные?
Да, они самые
Если получится в достаточной степени это все дело оптимизировать, то попробую. А так физика этих блоков это не самый критичный момент, на мой взгляд
Сейчас это наверное сделано несколько ебануто, но на данный момент это лучший вариант из тех, что я пробовал (а попробовал я относительно много). Выглядит это примерно следующим образом
На хай левеле у меня есть TerrainController, в котором хранится пул чанков
Каждый чанк имеет массив float + int значений, который хранится на GPU, т.к. все эти модификации происходят через compute shader'ы. Это те самые значения, по которым и прогоняется marching cubes. Еще имеет выделенную на GPU память под вершины меша. Так же он имеет заранее выделенную память для вертексов, индексов вершин и индексов материала на заднной вершине (dirt, stone и т.п.). Это значения уже хранятся в оперативной памяти и нужны для построения самого unity-меша. Количество выделяемой памяти, понятное дело, прямо пропорционально размеру чанка
Но каждый чанк хранится внутри так называемого ChunkColumn, т.к. они сами по себе кубические, то я объединяю из в "колонны", чтобы террейн имел настраиваемую высоту. По-сути это просто набор указателей на несколько чанков, которые расположенны на одинаковых X и Z координатах. Это облегчает их динамическую подгрузку и вообще все операции, которые требуется производить над чанками, которые находятся в одной "колонне"
В целом, если кратко, то получается как-то так. Но я тут много деталей упустил. Если будет интересно, могу и про них написать
Этот вариант конечно очень много места в памяти занимает (и в видео-памяти и в оперативной тоже), но у меня есть некоторые идеи, как это можно будет зафиксить. В to-do листе задача есть, так что в скором времени, надеюсь, руки до этого дойдут
Кстати, хочу отметить, что Unity не особо помогал с этим всем делом, а скорее даже мешал. Наверное под такое дело лучше другой движок юзать. Atroneer тот же, вроде бы, сначала на Unity пилили, а потом на Анрил перебрались
>Анрил перебрались
Может тебе тоже на анрил перебраться, пока разработка далеко не ушла.
Сегодня сделал небольшую задачу - основу системы цветовых пресетов. Сейчас объясню, нафиг она вообще нужна
У меня в проекте уже есть несколько мест, в которых требуется настраивать цвет, как, например, туман и сам террейн. И вот выставлять где-то в рандомных местах проекта эти цвета не очень здорово, как мне кажется. Ведь когда таких объектов, требующих окраски, будет становиться больше, их тяжело будет менеджить. Поэтому я решил сделать централизованную систему, в которой у меня существует заданная цветовая палитра, а в остальных местах проекта выставляется не конкретное значение цвета, а цвет, заданный в палитре. Таким образом мне не надо будет беспокоиться о том, что я где-то могу забыть поменять цвет какой-нибудь срани или еще что-то в таком духе. И вообще так проще будет добиться художественно привлекательной картинки, наверное
Да и к тому же, это может оказаться полезным, если я буду добавлять различные биомы в игру, т.к. каждому из них я смогу задать свой пресет
Так же есть функционал смены пересетов, где можно задать новый пресет и время, за которое должна произойти смена. На видосе, вот, пример есть. На нем происходит смена с Dbg Another Preset на Preset
Я хочу попробовать до конца доделать проект на Unity. Просто ради интереса. А там уже посмотрю, может потом на Анриле попробую что-нибудь сделать
У меня в проекте уже есть несколько мест, в которых требуется настраивать цвет, как, например, туман и сам террейн. И вот выставлять где-то в рандомных местах проекта эти цвета не очень здорово, как мне кажется. Ведь когда таких объектов, требующих окраски, будет становиться больше, их тяжело будет менеджить. Поэтому я решил сделать централизованную систему, в которой у меня существует заданная цветовая палитра, а в остальных местах проекта выставляется не конкретное значение цвета, а цвет, заданный в палитре. Таким образом мне не надо будет беспокоиться о том, что я где-то могу забыть поменять цвет какой-нибудь срани или еще что-то в таком духе. И вообще так проще будет добиться художественно привлекательной картинки, наверное
Да и к тому же, это может оказаться полезным, если я буду добавлять различные биомы в игру, т.к. каждому из них я смогу задать свой пресет
Так же есть функционал смены пересетов, где можно задать новый пресет и время, за которое должна произойти смена. На видосе, вот, пример есть. На нем происходит смена с Dbg Another Preset на Preset
Я хочу попробовать до конца доделать проект на Unity. Просто ради интереса. А там уже посмотрю, может потом на Анриле попробую что-нибудь сделать
Пиздец. Сегодня начал делать LOD систему для террейна. И какая же это боль, конечно. По-сути, надо перелопатить всю логику подгрузки чанков, а она написана, эм, хуево и запутанно, так сказать. У меня прям жопа сгорела, если честно. Но зато это хотя бы возможность ее переписать. Ну и если я сделаю, как задумано, то, по-идее, террейн будет занимать меньше места в памяти и рисоваться на бОльшие дистанции.
Лучше, конечно, такие вещи решать заранее.
Лучше, конечно, такие вещи решать заранее.
Получилось неплохо оптимизировать всю эту террейн систему. В результате радиус видимости удалось увеличить в разы, при том, что памяти теперь все это дело стало занимать гораздо меньше. Я прям удивился тому, насколько сильной вышла разница. Конечно, еще есть определенные проблемы со всем этим, но уже этот подход выглядит более перспективно, чем тот, что я до этого использовал.
На картинке, вот, пример террейна, запущенного на моем, далеко не самом мощном, ноуте из unity редактора, с таким радиусом видимости, какой раньше тянулся только на мощных компах (и то они начинали дико пердеть).
А все, что я сделал, по-сути - это отделил представление (условно) от данных. Теперь каждый чанк хранит в себе только game object с мешем и прочей сранью (т.е. просто отображение скалярного поля данных, по которому прогоняется marching cubes), а нужные GPU и RAM буферы гетает через специальный ChunkDataController, который "распределяет" данные между чанками. И теперь нам не требуется для каждого чанка отдельный набор буферов, что и дало такое сильно уменьшение затрачиваемой памяти.
Теперь еще видно, насколько плоский и "трипофобный" террейн сейчас генерируется.
На картинке, вот, пример террейна, запущенного на моем, далеко не самом мощном, ноуте из unity редактора, с таким радиусом видимости, какой раньше тянулся только на мощных компах (и то они начинали дико пердеть).
А все, что я сделал, по-сути - это отделил представление (условно) от данных. Теперь каждый чанк хранит в себе только game object с мешем и прочей сранью (т.е. просто отображение скалярного поля данных, по которому прогоняется marching cubes), а нужные GPU и RAM буферы гетает через специальный ChunkDataController, который "распределяет" данные между чанками. И теперь нам не требуется для каждого чанка отдельный набор буферов, что и дало такое сильно уменьшение затрачиваемой памяти.
Теперь еще видно, насколько плоский и "трипофобный" террейн сейчас генерируется.
> плоский и "трипофобный" террейн сейчас генерируется
А мне ЗБС. Я сразу же представил, как люди живут там, строят дома по краям карстовых пещер. Сотни лестниц ведут из полости в полость. Откуда-то тянется костра дымок. Где-то фырчит двухтактный движок. Жизнь кипит.
Сегодня в спокойном темпе начал переделывать генерацию террейна. Ну и еще немного фиксил систему подгрузки чанков. В эту систему надо добавить еще одну фичу (ну или пару), чтобы все это дело стало работать норм.
На первом пике можно видеть результат сегодняшней работы. На втором пике рофло-вариант с совмещением предыдущего и нового варианта генерации. Мне кажется, что вышла неплохая основа для дальнейшей работы. Хотелось бы добавить пещеры еще и все такое. Ну и надо будет причесать шейдер, который все это дело генерирует, ибо сейчас он не особо хорошо оформлен.
Хм, ну тут такое дело, что это все не вписывается в лор игры (который я пока умышленно не раскрываю). Ну и еще мне несколько неприятно смотреть на подобный террейн. И, думаю, такое может быть у достаточно многих людей.
На первом пике можно видеть результат сегодняшней работы. На втором пике рофло-вариант с совмещением предыдущего и нового варианта генерации. Мне кажется, что вышла неплохая основа для дальнейшей работы. Хотелось бы добавить пещеры еще и все такое. Ну и надо будет причесать шейдер, который все это дело генерирует, ибо сейчас он не особо хорошо оформлен.
Хм, ну тут такое дело, что это все не вписывается в лор игры (который я пока умышленно не раскрываю). Ну и еще мне несколько неприятно смотреть на подобный террейн. И, думаю, такое может быть у достаточно многих людей.
> лор игры (который я пока умышленно не раскрываю)
Ммм... Интрига! Неужто лор будет круче вселенной наоборот с толщеходами? Будем посмотреть!
Почему выбрал юнити?
Не срачер, просто интересно почему выбор был сделан в пользу юнити, а не уе или годо
Не срачер, просто интересно почему выбор был сделан в пользу юнити, а не уе или годо
Ответил в срачетреде
И ты так делай.
Сегодня продолжал работать над системой подгрузки. Надеюсь, что завтра уже доведу ее до нормального вида. А пока, вот, скриншоты дома, который я сегодня сделал ради интереса. Уже не только пенисы в игре получается строить. Ну и плюс тут можно посмотреть на бОльшую дистанцию отрисовки.
Если кратко, то можно сказать, что "просто так" выбрал. Но можно это интерпретировать так, как другой анон тебе ответил, наверное. Как удобней будет.
Если кратко, то можно сказать, что "просто так" выбрал. Но можно это интерпретировать так, как другой анон тебе ответил, наверное. Как удобней будет.
Ничего более депрессового чем этот дом в пустыне я не видел в играх.
Даже напомнило Sothc.
Внезапно возникло желание пожелать тебе удачи. Желаю.
Визуально игра выглядит очень меланхолично, не просри стиль! Это выглядит как пустыня на какой-то далёкой плнете, пещеры напомнили первый фильм про Риддика, а дом посреди этой пустоты это что-то!
Если эта выживалка будет иметь хорор составляющую то цены ей не будет. Надеюсь у тебя всё выйдет.
Вот видос случайно попался может тебе поможет https://youtu.be/-VgtSL5ZpYc
И пик монстра, может пригодится
Слушай, я особо тред не читал, но имею пару вопросов:
На каком движке делаешь игру и имел ли ты какие-то навыки, например в программировании, до того, как приступил к разработке?
Первый вопрос отпадает.
Вчера довел до удовлетворительного состояния систему подгрузки. На всякий случай снабдил ее код комментариями сверху донизу, чтобы через месяц не вспоминать, как она вообще работает. В общем, более или менее норм вышло, я думаю.
Так же начал работать над инвентарной системой. Пока не могу придти к архитектуре, которая меня удовлетворяет, хотя движение в этом направлении и идет, вроде бы. Хочется не только добиться достаточной гибкости использования но и удобства.
Параллельно заложил небольшую основу для систему локализации. Решил сделать это сейчас, чтобы потом не ходить по всему проекту для того, чтобы "string" заменить на условный "LocalizibleString". В целом система должна быть не очень сложной, если, конечно, я не вижу сейчас каких-то "подводных камней".
Новых интересных скриншотов у меня нет, так что прикреплю к посту небольшую фракталоподобную штуку, которую некоторое время назад сделал. Чтобы пост выглядел поинтереснее. Вообще это sort of процедурная генерация на основании заданного меша. Для этой конкретной картинки просто я подобрал удачный ракурс и базовую геометрию.
Благодарю. Рад, что вам понравилось. И, кстати, судя по вашим комментариям, я попадаю в то настроение, которое хочу получить в итоге.
За видос спасибо. В релейтеде мне все вылезал, но что-то не доходили руки его посмотреть. Позже попробую решить проблему слишком заметного тайлинга текстур.
Ну, я в шараге отучился на программиста и по специальности около года сейчас работаю. А вот всех остальных навыков у меня толком нет, я думаю. Не полный ноль, но и ничего хорошего тоже.
Так же начал работать над инвентарной системой. Пока не могу придти к архитектуре, которая меня удовлетворяет, хотя движение в этом направлении и идет, вроде бы. Хочется не только добиться достаточной гибкости использования но и удобства.
Параллельно заложил небольшую основу для систему локализации. Решил сделать это сейчас, чтобы потом не ходить по всему проекту для того, чтобы "string" заменить на условный "LocalizibleString". В целом система должна быть не очень сложной, если, конечно, я не вижу сейчас каких-то "подводных камней".
Новых интересных скриншотов у меня нет, так что прикреплю к посту небольшую фракталоподобную штуку, которую некоторое время назад сделал. Чтобы пост выглядел поинтереснее. Вообще это sort of процедурная генерация на основании заданного меша. Для этой конкретной картинки просто я подобрал удачный ракурс и базовую геометрию.
Благодарю. Рад, что вам понравилось. И, кстати, судя по вашим комментариям, я попадаю в то настроение, которое хочу получить в итоге.
За видос спасибо. В релейтеде мне все вылезал, но что-то не доходили руки его посмотреть. Позже попробую решить проблему слишком заметного тайлинга текстур.
Ну, я в шараге отучился на программиста и по специальности около года сейчас работаю. А вот всех остальных навыков у меня толком нет, я думаю. Не полный ноль, но и ничего хорошего тоже.
> начал работать над инвентарной системой. Пока не могу придти к архитектуре, которая меня удовлетворяет
Рекомендую методику "от результата".
Если речь о коде, то пишешь строчки, типа:
> Kak.ya.hochu(Zdelat.interfeis);
> Inventar.peredat(otKogo, Inventar.elementy(index), komu);
> SladkiRulet.peremestit(Igrok.inventar);
> Inventar.elementy(index).vykinut(nahui);
Затем последовательно реализуешь необходимые сущности, чтобы твой код не вызывал ошибок.
Если речь о графике, сначала накидываешь на форму каркас из элементов, добиваешься, чтобы всё нравилось, затем привязываешь к каркасу функционал из кода выше.
Сегодня продолжал работу над инвентарной системой. В целом получилось может слишком сложно, но вроде более или менее гибко. Разделить все это можно на следующие "компоненты" (к ecs никакого отношения не имеет, если что) :
1. Есть базовый класс Inventory, который является обычной оберткой над массивом заданного размера, в каждой ячейке которого хранится InventoryItem (надо будет заренеймить в InventorySlot, наверное). В свою очередь InventoryItem хранит два поля - id и количество предметов. Id для самого айтема не имеет никакого значения - интерпретировать и сетапить его должны другие системы, которые используют инвентарь. Таким образом, получается, что класс Inventory является супер базовой штукой, которая может быть использована во множестве разных контекстов. Ну, я надеюсь на это, по крайней мере
2. У инвентаря есть интерфейс. Тут идея в том, что, например, в случае инвентаря игрока нам нужно уметь постепенно свитчится между элементами, последовательно переходя от одного к другому, но в случае какого-нибудь условного ящика нам такой функционал не нужен, там другая логика взаимодействия. Посему я отделил интерфейс инвентаря в отдельный класс. На этом уровне все Id предметов - тоже просто абстрактные числа, не имеющие никакого смысла.
3. Есть PlayerInventory класс, который в себе хранит инвентарь игрока и интерфейс для него. Так же имеет возможность задавать изначальный сетап инвентаря в инспекторе Unity. Тут уже появляются впервые Item'ы, а не простые рандомные int'ы.
4. Собственно Item. Точнее сказать, ItemDescription. Каждый предмет, который игрок может взять в руки, использовать, выбросить, описывается с помощью специального ScriptableObject, в котором хранится набор некоторый набор полей, который описывает все необходимые свойства предмета - uid (в виде строки), название (в виде локализуемой строки), внешний вид в руках (префаб), внешний вид на земле (тоже префаб), максимальное количество в одном слоте инвентаря. Но это для базовых предметов, у которых нет какой-либо логики использования - их можно только подобрать и выбросить. Для предметов с логикой использования есть специальный ScriptableObject - ItemWithLogicDescription, который хранит в себе все те-же поля, но дополнительно имеет место для еще одного ScriptableObject'а, в котором описывается логика. У объекта логики есть методы Activate и Deactivate, которые, очевидно, включают и выключают эту логику. Логика, в прнципе, может делать все, что захочет.
4.5. Таким образом все необходимые свойства объектов описываются в одном месте и не зависят от других систем. Связанность образуется только в объектах, которые описывают логику, т.к. они могут тесно взаимодействовать с другими системами.
5. Есть специальный синглтон, через который по uid ItemDescription'а можно получить интовый id (и наоборот). Это используется как раз для того, чтобы предметы с заданным ItemDescription'ом можно было положить в инвентарь. Что важно - на данный момент в разные игровые сессии эти id могут оказываться разными для одного и того же Item'а. Это немного странно, но более удобно, чем вручную int проставлять во всех дескрипшенах (это выглядит очень багоопасным).
6. Ну и теперь все готово, чтобы на основе этого строить остальную игровую логику. На данный момент есть возможность сменять заселекченый предмет в инвентаре (через класс интерфеса, см. пункт 2). Заселекченый предмет отображается "в руке" с помощью получения ItemPreview префаба из ItemDescription'a. Заселекченный предмет можно выбросить. После того, как он выброшен, будет заспавнен GameObject на основании префаба, который, опять же, описан в ItemDescription. Так же можно эти объекты подбирать. Они будут возвращены в инвентарь, а GameObject будет удален.
И, кстати, таким образом, чтобы добавить новый, полностью рабочий Item достаточно создать корректный ItemDescription. И его можно брать в ручки будет, кидать и подбирать. Никаких мерзких enum'ов говна и прочих списков нигде не надо делать. Наверное это никого не удивит, да. Но я очень боялся, что какое-то такое говно всплывет.
Если кто-то дочитает эту простыню, то буду рад услышать ваши предложения и замечания. Я накидал это все дело за пару дней, вышло немного сумбурно, и наверняка я что-то упустил. Видос с примером прилагаю. Там без UI нифига не понятно, конечно, но по-сути я просто выкидываю и подбираю различные предметы.
Согласен, это хороший подход, я примерно такой способ и выбрал изначально. Только еще помимо кода старался представить желаемый пайплайн добавления новых объектов. Ну и пайплайн удаления объектов тоже.
1. Есть базовый класс Inventory, который является обычной оберткой над массивом заданного размера, в каждой ячейке которого хранится InventoryItem (надо будет заренеймить в InventorySlot, наверное). В свою очередь InventoryItem хранит два поля - id и количество предметов. Id для самого айтема не имеет никакого значения - интерпретировать и сетапить его должны другие системы, которые используют инвентарь. Таким образом, получается, что класс Inventory является супер базовой штукой, которая может быть использована во множестве разных контекстов. Ну, я надеюсь на это, по крайней мере
2. У инвентаря есть интерфейс. Тут идея в том, что, например, в случае инвентаря игрока нам нужно уметь постепенно свитчится между элементами, последовательно переходя от одного к другому, но в случае какого-нибудь условного ящика нам такой функционал не нужен, там другая логика взаимодействия. Посему я отделил интерфейс инвентаря в отдельный класс. На этом уровне все Id предметов - тоже просто абстрактные числа, не имеющие никакого смысла.
3. Есть PlayerInventory класс, который в себе хранит инвентарь игрока и интерфейс для него. Так же имеет возможность задавать изначальный сетап инвентаря в инспекторе Unity. Тут уже появляются впервые Item'ы, а не простые рандомные int'ы.
4. Собственно Item. Точнее сказать, ItemDescription. Каждый предмет, который игрок может взять в руки, использовать, выбросить, описывается с помощью специального ScriptableObject, в котором хранится набор некоторый набор полей, который описывает все необходимые свойства предмета - uid (в виде строки), название (в виде локализуемой строки), внешний вид в руках (префаб), внешний вид на земле (тоже префаб), максимальное количество в одном слоте инвентаря. Но это для базовых предметов, у которых нет какой-либо логики использования - их можно только подобрать и выбросить. Для предметов с логикой использования есть специальный ScriptableObject - ItemWithLogicDescription, который хранит в себе все те-же поля, но дополнительно имеет место для еще одного ScriptableObject'а, в котором описывается логика. У объекта логики есть методы Activate и Deactivate, которые, очевидно, включают и выключают эту логику. Логика, в прнципе, может делать все, что захочет.
4.5. Таким образом все необходимые свойства объектов описываются в одном месте и не зависят от других систем. Связанность образуется только в объектах, которые описывают логику, т.к. они могут тесно взаимодействовать с другими системами.
5. Есть специальный синглтон, через который по uid ItemDescription'а можно получить интовый id (и наоборот). Это используется как раз для того, чтобы предметы с заданным ItemDescription'ом можно было положить в инвентарь. Что важно - на данный момент в разные игровые сессии эти id могут оказываться разными для одного и того же Item'а. Это немного странно, но более удобно, чем вручную int проставлять во всех дескрипшенах (это выглядит очень багоопасным).
6. Ну и теперь все готово, чтобы на основе этого строить остальную игровую логику. На данный момент есть возможность сменять заселекченый предмет в инвентаре (через класс интерфеса, см. пункт 2). Заселекченый предмет отображается "в руке" с помощью получения ItemPreview префаба из ItemDescription'a. Заселекченный предмет можно выбросить. После того, как он выброшен, будет заспавнен GameObject на основании префаба, который, опять же, описан в ItemDescription. Так же можно эти объекты подбирать. Они будут возвращены в инвентарь, а GameObject будет удален.
И, кстати, таким образом, чтобы добавить новый, полностью рабочий Item достаточно создать корректный ItemDescription. И его можно брать в ручки будет, кидать и подбирать. Никаких мерзких enum'ов говна и прочих списков нигде не надо делать. Наверное это никого не удивит, да. Но я очень боялся, что какое-то такое говно всплывет.
Если кто-то дочитает эту простыню, то буду рад услышать ваши предложения и замечания. Я накидал это все дело за пару дней, вышло немного сумбурно, и наверняка я что-то упустил. Видос с примером прилагаю. Там без UI нифига не понятно, конечно, но по-сути я просто выкидываю и подбираю различные предметы.
Согласен, это хороший подход, я примерно такой способ и выбрал изначально. Только еще помимо кода старался представить желаемый пайплайн добавления новых объектов. Ну и пайплайн удаления объектов тоже.
Короче, недавно я решил, что весь этот террейн работает слишком медленно, и надо что-то с этим делать. Я попытался исправить это добавлением новых структур данных, которые хранят дополнительную информацию о чанках, чтобы уменьшить количество "перегенерируемых" чанков, да и в целом постарался оптимизировать C# код. Это помогло. Но все-равно результат оказался слишком плохим, из-за чего у меня сгорела ass.
Посему я решил сделать одну из двух вещей - либо сделать систему генерации в виде NativePlugin'а для Unity, либо перейти на Unreal. Основная идея состоит в том, чтобы получить возможность писать эту логику на языке, в котором можно будет более четко менеджить память, а также который будет работать без виртуальной машины и GC. C#, хоть и хороший язык, но для моих целей он не совсем подходит, да и работать мне с ним не очень комфортно.
Так что эти выходные я посвятил изучению этих двух вариантов. NativePlugin'ы мне показались не очень удобными, т.к. мне придется весь интерфейс для связи моей системы с C# реализовывать в виде функций (поправьте, если я не прав, пожалуйста). Я имею ввиду что-то в духе функций TerrainController CreateTerrainController() . А затем, чтобы вызывать какие-то методы у этого объекта, надо будет делать дополнительную функцию, которая принимает указатель в качестве аргумента : void TerrainContoller_Update(TerrainController obj) { obj -> Update(); }. Это выглядит супер-неудобным, если честно.
Т.к. вариант с нативными плагины мне не зашел, я решил попробовать второй вариант. Большую часть времени потратил на чтение документации к Анрилу. В целом за эти полтора дня вышло сделать черновую генерацию из говна и палок, совершенно не оптимизированную. Скрин прилагаю. Пока буду дальше смотреть в этом направлении, т.к. оно мне кажется наиболее предпочтительным
Посему я решил сделать одну из двух вещей - либо сделать систему генерации в виде NativePlugin'а для Unity, либо перейти на Unreal. Основная идея состоит в том, чтобы получить возможность писать эту логику на языке, в котором можно будет более четко менеджить память, а также который будет работать без виртуальной машины и GC. C#, хоть и хороший язык, но для моих целей он не совсем подходит, да и работать мне с ним не очень комфортно.
Так что эти выходные я посвятил изучению этих двух вариантов. NativePlugin'ы мне показались не очень удобными, т.к. мне придется весь интерфейс для связи моей системы с C# реализовывать в виде функций (поправьте, если я не прав, пожалуйста). Я имею ввиду что-то в духе функций TerrainController CreateTerrainController() . А затем, чтобы вызывать какие-то методы у этого объекта, надо будет делать дополнительную функцию, которая принимает указатель в качестве аргумента : void TerrainContoller_Update(TerrainController obj) { obj -> Update(); }. Это выглядит супер-неудобным, если честно.
Т.к. вариант с нативными плагины мне не зашел, я решил попробовать второй вариант. Большую часть времени потратил на чтение документации к Анрилу. В целом за эти полтора дня вышло сделать черновую генерацию из говна и палок, совершенно не оптимизированную. Скрин прилагаю. Пока буду дальше смотреть в этом направлении, т.к. оно мне кажется наиболее предпочтительным
Странно, вроде бы я ставил звездочки у указателей. Но, надеюсь, идея понятна.
Test Test * Test
>за эти полтора дня
блять ты чо сука какой-то вундеркинд что ли
хули у меня всё так медленно
>GC
Ним можно управлять вроде как.
Алсо, яннп, разве террейн не генерится однократно при создании?
тред не читал
Это магия сиплюсплюс. Не тот язык мы учили в школах, анон.
Текстура твоя?
Бамп. Я не умер.
Пытаюсь потихоньку сделать террейн опять, который мне бы нравился. Попробовал несколько вариантов, и, может, нашел неплохой.
Не охуевайте сильно от моего 999icq, но я только сейчас додумался использовать qtree для чанков, чтобы реализовать lod'ы и вообще более эффективно использовать память.
В текущем варианте разные инстансы qtree представляют из себя некое подобие "супер-чанков", которые имеют очень большие размеры. Ну а строятся эти деревья на основании позиции плеера. Максимальная глубина дерева это количество lod'ов, которые предусмотрены системой. Каждому листу дерева соответствует chunk column.
На прикриле я цветом визуализировал lod'ы террейна. Чем светлее цвет, тем более детализированный там террейн.
Так же немного изменил подход к настройкам террейна. Теперь они более гибкие (вроде бы).
Не для срача, а просто на заметку : для данной задачи Анрил действительно подходит гораздо лучше, чем Unity. Например, генерация одного чанка 32x32x32 самым тупым способом на Unity занимает просто дохуищу времени (точных замеров нет, сорян), но аналогичная генерация на Анриле происходит практически моментально. Он настолько быстро справляется с этой задачей, что всякие compute shader'ы даже не понадобятся, наверное. Я даже смог каждый кадр заново генерировать несколько чанков 64x64x64 с небольшим оффсетом, чтобы получить эффект движения, и, даже на моем не самом сильном ноуте, фреймрейт был в районе 30 кадров (повторюсь - это самый тупой и неоптимизированный вариант реализции).
Да забей, я просто с# на плюсы переписал код, который и так уже раз десять писал. Ничего такого не сделал, поэтому и вышло быстро.
Вот насчет возможности управлять им я не знал, если честно. Но все-равно это все выглядит скорее как борьба с языком и попытка писать на шарпе так, будто это плюсы. Наверное это не очень хорошо.
А насчет террейна - он должен быть условно бесконечным и подгружаться вместе с передвижением игрока. Майнкрафт, наверное, самый близкий пример.
Все текстуры качал с textures.com
Пытаюсь потихоньку сделать террейн опять, который мне бы нравился. Попробовал несколько вариантов, и, может, нашел неплохой.
Не охуевайте сильно от моего 999icq, но я только сейчас додумался использовать qtree для чанков, чтобы реализовать lod'ы и вообще более эффективно использовать память.
В текущем варианте разные инстансы qtree представляют из себя некое подобие "супер-чанков", которые имеют очень большие размеры. Ну а строятся эти деревья на основании позиции плеера. Максимальная глубина дерева это количество lod'ов, которые предусмотрены системой. Каждому листу дерева соответствует chunk column.
На прикриле я цветом визуализировал lod'ы террейна. Чем светлее цвет, тем более детализированный там террейн.
Так же немного изменил подход к настройкам террейна. Теперь они более гибкие (вроде бы).
Не для срача, а просто на заметку : для данной задачи Анрил действительно подходит гораздо лучше, чем Unity. Например, генерация одного чанка 32x32x32 самым тупым способом на Unity занимает просто дохуищу времени (точных замеров нет, сорян), но аналогичная генерация на Анриле происходит практически моментально. Он настолько быстро справляется с этой задачей, что всякие compute shader'ы даже не понадобятся, наверное. Я даже смог каждый кадр заново генерировать несколько чанков 64x64x64 с небольшим оффсетом, чтобы получить эффект движения, и, даже на моем не самом сильном ноуте, фреймрейт был в районе 30 кадров (повторюсь - это самый тупой и неоптимизированный вариант реализции).
Да забей, я просто с# на плюсы переписал код, который и так уже раз десять писал. Ничего такого не сделал, поэтому и вышло быстро.
Вот насчет возможности управлять им я не знал, если честно. Но все-равно это все выглядит скорее как борьба с языком и попытка писать на шарпе так, будто это плюсы. Наверное это не очень хорошо.
А насчет террейна - он должен быть условно бесконечным и подгружаться вместе с передвижением игрока. Майнкрафт, наверное, самый близкий пример.
Все текстуры качал с textures.com
> А насчет террейна - он должен быть условно бесконечным и подгружаться вместе с передвижением игрока. Майнкрафт, наверное, самый близкий пример.
В майнкампфе на сколько я знаю ограниченный мир (n х n блоков) генерится при ините и просто подгружается при передвижении игрока (и его настроек).
Алсо, задам наверное тупой вопрос, я конечно с дивана и не совсем понимаю как ты собрался реализовать эту бесконечность. Вот допустим я сделал какое-то действие с миром (выкопал яму/построил дом) в точке 0/0/0 (ну или где там будет спаун)(понятно что действие будет от и до какой-то точки) и решил попиздовать в далекое путешествие на 0+n/0/0+m условных координат попутно ставя какие-то метки чтобы вернуться домой. Получается все эти изменения мира нужно будет держать в памяти и через t времени подобного путешествия она рано или поздно закончится.
У тебя по идее мир должен будет прогружаться в оперативку на n/n/n координат вокруг игрока, а весь уже сгенеренный мир должен сохраняться уже на жесткий диск, я правильно понимаю?
>генерится при ините
Это неверно. Он бы просто не поместился на диск тогда. Он генерится на лету.
>нужно будет держать в памяти
В том же MC так и сделано (изменённые, но далёкие чанки сбрасываются на диск и выгружаются из ОЗУ до очередного посещения). И, да, память заканчивается, если ты решишь миллионы квадратных километров пометить.
Я немного проебался - нужно по сути "сохранять" весь мир где уже просто был игрок, а не изменения.
Не ясно что за хуйню ты удумал и что это вообще будет из себя представлять новый майнкрафт?, но с чем я могу поздравить тебя точно, так это с тем, что манипуляции с ландшафтом у тебя сделаны лучше, чем в No Man's Sky ебаном и это нихуя не комплимент на самом деле, просто примечание
>Делаю на unity.
Используешь ecs?
Небольшой апдейт. Все еще продолжаю свои попытки блять сука нахуй найти нормальную архитектуру для террейна. На данный момент сделано следующее. Как писал выше, есть quad tree, которое строится на основании позиции игрока. Потом я на основании этого дерева строю террейн. Чем глубже находится нода дерева, тем более детальный террейн там будет, таким образом получается некоторое подобие lod'ов.
Я отделил непосредственно генерацию чанков в отдельный тред. Из мейн-треда я могу просто "заказать" у него генерацию значений для какого-то чанка, передав указатель на объект и коллбек, который будет вызван по завершении генерации.
Так же теперь загрузка происходит постепенно. Т.е. сначала полностью грузится самый низкополигональный террейн, затем более детальный и так далее, пока загружать останется нечего.
Зачем я это делаю вообще, почему мне не подошло то, что было до этого? Потому что оно лагает, когда за один кадр необходимо сгенерировать много чанков. Или просто сделать их видимыми (что необходимо делать из мейн-треда), или, наоборот, невидимыми. То, что я сделал сейчас, помогает частично избавиться от этой проблемы, но я уверен, что можно сделать лучше. Не должно все так лагать, иначе это просто хуевая игра будет с технической точки зрения.
У меня есть идеи, как это можно исправить. Постараюсь на выходных сделать.
Короче, из-за смены движка, я откинулся в прогрессе практически в самое начало. Но оно к лучшему, наверное.
Т.к. мне нечего показать сейчас, то скину еще скринов с другими "экспериментами" с процедурной генерацией. Только теперь я пытался сворачивать плоскую геометрию в шары. Делал я это с помощью преобразования обычных координат в полярные. Вышло очень просто и забавно. Может потом использую где-нибудь, хз.
Там в принципе другой анон верно ответил. Добавлю только что изначально, если не ошибаюсь, ограничений на размер карты там не было, но из-за багов ("далекие земли") они были введены.
Мне сложно сказать, что именно из себя это будет представлять. Вряд ли это будет что-то масштабное, точно не "новый майнкрафт". Если не смогу техническую основу нормальную сделать, то и вовсе будет просто тред на дваче.
Рад, что модификации террейна выглядят не super huevo. Я вообще хочу их сделать максимально гибкими и удобными. Если выйдет, конечно же.
Нет, не использую. Пока на Юнити делал, я пытался сделать это через ecs, но не смог всю эту систему в нее вписать. Одна из проблем в том, что мне не особо требуется итерироваться через большое число каких-то объектов, чтобы получить большой буст перформанса. Ну или я не смог придумать, как свести проблему генерации террейна к форме, которая была бы подходящей для ecs. Другая проблема состоит в том, что у Юнитевского ecs есть ряд разумных ограничений, которые, к сожалению, не позволяют использовать классы. Из-за этого, например, я не могу использовать ComputeShader'ы и подобные штуки, а у меня на шейдерах весь террейн работает. Ну и прочие такие подводные камни я встретил.
В итоге, когда я все-же попытался сделать через ecs, то я просто итерировался через индексы чанков, а потом по индексу получал доступ к чанку и проводил нужные действия. Но это какая-то херня вышла, как мне кажется. Никакой пользы при такой реализации от ecs я не получил. Но, если что, я не пытаюсь заговнить ecs. Просто данную конкретную задачу я не смог нормально решить с ее помощью.
Я отделил непосредственно генерацию чанков в отдельный тред. Из мейн-треда я могу просто "заказать" у него генерацию значений для какого-то чанка, передав указатель на объект и коллбек, который будет вызван по завершении генерации.
Так же теперь загрузка происходит постепенно. Т.е. сначала полностью грузится самый низкополигональный террейн, затем более детальный и так далее, пока загружать останется нечего.
Зачем я это делаю вообще, почему мне не подошло то, что было до этого? Потому что оно лагает, когда за один кадр необходимо сгенерировать много чанков. Или просто сделать их видимыми (что необходимо делать из мейн-треда), или, наоборот, невидимыми. То, что я сделал сейчас, помогает частично избавиться от этой проблемы, но я уверен, что можно сделать лучше. Не должно все так лагать, иначе это просто хуевая игра будет с технической точки зрения.
У меня есть идеи, как это можно исправить. Постараюсь на выходных сделать.
Короче, из-за смены движка, я откинулся в прогрессе практически в самое начало. Но оно к лучшему, наверное.
Т.к. мне нечего показать сейчас, то скину еще скринов с другими "экспериментами" с процедурной генерацией. Только теперь я пытался сворачивать плоскую геометрию в шары. Делал я это с помощью преобразования обычных координат в полярные. Вышло очень просто и забавно. Может потом использую где-нибудь, хз.
Там в принципе другой анон верно ответил. Добавлю только что изначально, если не ошибаюсь, ограничений на размер карты там не было, но из-за багов ("далекие земли") они были введены.
Мне сложно сказать, что именно из себя это будет представлять. Вряд ли это будет что-то масштабное, точно не "новый майнкрафт". Если не смогу техническую основу нормальную сделать, то и вовсе будет просто тред на дваче.
Рад, что модификации террейна выглядят не super huevo. Я вообще хочу их сделать максимально гибкими и удобными. Если выйдет, конечно же.
Нет, не использую. Пока на Юнити делал, я пытался сделать это через ecs, но не смог всю эту систему в нее вписать. Одна из проблем в том, что мне не особо требуется итерироваться через большое число каких-то объектов, чтобы получить большой буст перформанса. Ну или я не смог придумать, как свести проблему генерации террейна к форме, которая была бы подходящей для ecs. Другая проблема состоит в том, что у Юнитевского ecs есть ряд разумных ограничений, которые, к сожалению, не позволяют использовать классы. Из-за этого, например, я не могу использовать ComputeShader'ы и подобные штуки, а у меня на шейдерах весь террейн работает. Ну и прочие такие подводные камни я встретил.
В итоге, когда я все-же попытался сделать через ecs, то я просто итерировался через индексы чанков, а потом по индексу получал доступ к чанку и проводил нужные действия. Но это какая-то херня вышла, как мне кажется. Никакой пользы при такой реализации от ecs я не получил. Но, если что, я не пытаюсь заговнить ecs. Просто данную конкретную задачу я не смог нормально решить с ее помощью.
Посмотри в сторону того, как хранится террейн в вов (в старых версиях).
https://github.com/cmangos/issues/wiki/ADT-Files
https://wowdev.wiki/ADT
https://www.youtube.com/watch?v=mQTJMy0ebjU
Оп, ты использовал в unity какой-то встроенный инструмент для создания таких дырок в террайне?
И это реклама твоей гениальной игры? Кадр c 21:03: https://youtu.be/eV-B1LSy6wM
Небольшой апдейт.
Решил недавно взять перерыв в пару недель. Занялся другим проектом, который напрямую не связан с игорями, ибо немного выгорел. Сейчас, вот, вернулся.
Так же я немного переосмыслил свой подход к разработке. Теперь буду стараться придерживаться более простой архитектуры и более простых подходов к процедурной генерации, чтобы суметь потянуть все это в одно рыло и не растягивать это все дело на миллионы лет. Посему теперь я делаю очень просто - есть чанки, они всегда одинаковые (нет разделения на lod'ы и т.д.), я просто буду выставлять их в нужные позиции и заново генерировать, когда это потребуется. Никаких qtree и подобных вещей. Может потом, когда я заставлю простой вариант работать нормально, я начну усложнять архитектуру системы, но это уже другой вопрос.
Если смотреть на текущий прогресс, то я откинулся где-то на вторую половину февраля, когда у меня на Unity был небольшой кусок террейна, который можно было разрушать и строить. Только теперь это сделано на Анриле, а так же все расчеты полностью происходят на cpu вместо видеокарты. В целом получается обновлять чанки достаточно быстро, несмотря на то, что я не пользуюсь "массовым параллелизмом", а просто разбиваю расчеты на пару потоков на процессоре. Думаю, что с Unity вариантом реализации главным боттлнеком оказалась необходимость пересылать данные с видеокарты в оперативную память каждый раз, когда нужно было обновить меши. Получается, что везде есть свои недостатки. Но все-же мне кажется, что новый вариант более перспективный.
Вот вам мерзкий говеный отвратительный скриншот, как доказательство того, что работа действительно идет.
Спасибо большое за ссылки. Я сейчас немного глазами пробежался по статье из wiki, но потом уделю больше внимания.
Нет, ничего не использовал. Не уверен, что сейчас для Unity есть какой-то ассет для подобных террейнов. Я найти не смог, по крайней мере. Есть некоторые примеры на github (и туториалы на youtube), но они все достаточно небольшие (хоть и очень полезные, на мой взгляд), т.к. сделаны просто для того, чтобы показать принцип работы.
Ну да, в целом. Но скорее это реклама паблика и просто небольшая пасхалка, которую было решено засунуть в игру.
Решил недавно взять перерыв в пару недель. Занялся другим проектом, который напрямую не связан с игорями, ибо немного выгорел. Сейчас, вот, вернулся.
Так же я немного переосмыслил свой подход к разработке. Теперь буду стараться придерживаться более простой архитектуры и более простых подходов к процедурной генерации, чтобы суметь потянуть все это в одно рыло и не растягивать это все дело на миллионы лет. Посему теперь я делаю очень просто - есть чанки, они всегда одинаковые (нет разделения на lod'ы и т.д.), я просто буду выставлять их в нужные позиции и заново генерировать, когда это потребуется. Никаких qtree и подобных вещей. Может потом, когда я заставлю простой вариант работать нормально, я начну усложнять архитектуру системы, но это уже другой вопрос.
Если смотреть на текущий прогресс, то я откинулся где-то на вторую половину февраля, когда у меня на Unity был небольшой кусок террейна, который можно было разрушать и строить. Только теперь это сделано на Анриле, а так же все расчеты полностью происходят на cpu вместо видеокарты. В целом получается обновлять чанки достаточно быстро, несмотря на то, что я не пользуюсь "массовым параллелизмом", а просто разбиваю расчеты на пару потоков на процессоре. Думаю, что с Unity вариантом реализации главным боттлнеком оказалась необходимость пересылать данные с видеокарты в оперативную память каждый раз, когда нужно было обновить меши. Получается, что везде есть свои недостатки. Но все-же мне кажется, что новый вариант более перспективный.
Вот вам мерзкий говеный отвратительный скриншот, как доказательство того, что работа действительно идет.
Спасибо большое за ссылки. Я сейчас немного глазами пробежался по статье из wiki, но потом уделю больше внимания.
Нет, ничего не использовал. Не уверен, что сейчас для Unity есть какой-то ассет для подобных террейнов. Я найти не смог, по крайней мере. Есть некоторые примеры на github (и туториалы на youtube), но они все достаточно небольшие (хоть и очень полезные, на мой взгляд), т.к. сделаны просто для того, чтобы показать принцип работы.
Ну да, в целом. Но скорее это реклама паблика и просто небольшая пасхалка, которую было решено засунуть в игру.
Тонкая пост-ирония
Понял, что не помешает вести что-то вроде дневника. Пусть он будет здесь