Добро пожаловать в пожилой тред любви, взаимопомощи и наследия!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1051748 (OP)
Архивный: >>1048979 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1051748 (OP)
Архивный: >>1048979 (OP)
Как же я люблю годо. Я готов брать и обмазываться им, брать и обмазываться. Если б ещё в вебе пустая сборка не весила 40мб, я бы развёлся и женился на годо-тян
>>5144 (OP)
Мое почтение художнику за первый оп-пик.
Мое почтение опу за хороший подбор оппиков.
вкатился
Мое почтение художнику за первый оп-пик.
Мое почтение опу за хороший подбор оппиков.
вкатился
15 Кб, 490x408>>5144 (OP)
Тощие доски не нужны. Тян должна быть сисястой, жопастой, с хорошими бедрами, чтобы родить и вскормить потомство
Тощие доски не нужны. Тян должна быть сисястой, жопастой, с хорошими бедрами, чтобы родить и вскормить потомство
>>5160
Много 2д тянок оплодотворил?
Много 2д тянок оплодотворил?
55 Кб, 749x321>>5146
В прошлом треде постил гайд по сжатию билдов. 16мб вполне реально, смотря что твой проект использует:
https://popcar.bearblog.dev/how-to-minify-godots-build-size/
В прошлом треде постил гайд по сжатию билдов. 16мб вполне реально, смотря что твой проект использует:
https://popcar.bearblog.dev/how-to-minify-godots-build-size/
>>5170
Алсо там пересобирают годот и экспорт темплейты, выкидывая неиспользуемые в проекте модули. Этого не стоит пугаться, он пересобирается максимально просто.
Алсо там пересобирают годот и экспорт темплейты, выкидывая неиспользуемые в проекте модули. Этого не стоит пугаться, он пересобирается максимально просто.
>>5171
Если только ты не шарпист на третьей версии движка, нам положняк страдать
>он пересобирается максимально просто. *
Если только ты не шарпист на третьей версии движка, нам положняк страдать
>>5170
Это знаю, да. Но сам факт, что нужен гайд для этого...
Это знаю, да. Но сам факт, что нужен гайд для этого...
Я сейчас узнал что в 3д редакторе, при зажатой ПКМ, работает навигация не только по WASD, но и по Q и E, и это охуенно.
>>5159
У меня целое аниме по комиксу получилось.
>>5160
Шаришь. Но помни: попа + бёдра > сиськи.
>>1055141 →
У тебя взаимоисключающие параграфы.
>>1055142 →
И это тоже верно. Годетта - умница.
>>5171
Я так и не понял, как установить C++...
>>5146
Ты должен любить её такой, какая она есть...
>Мое почтение художнику за первый оп-пик.
У меня целое аниме по комиксу получилось.
>>5160
>сисястой, жопастой, с хорошими бедрами
Шаришь. Но помни: попа + бёдра > сиськи.
>>1055141 →
>Почему она жирная и совсем не секси?
У тебя взаимоисключающие параграфы.
>>1055142 →
>Потому что она отрицает синглтон
И это тоже верно. Годетта - умница.
>>5171
>пересобирается максимально просто
Я так и не понял, как установить C++...
>>5146
>Если б ещё в вебе пустая сборка не весила
Ты должен любить её такой, какая она есть...
>>1055243 →
Жироен Тел https://en.wikipedia.org/wiki/Jeroen_Tel
Автор песен и постов.
https://www.youtube.com/watch?v=HiQrUDIah4E
Жироен Тел https://en.wikipedia.org/wiki/Jeroen_Tel
Автор песен и постов.
https://www.youtube.com/watch?v=HiQrUDIah4E
>>5259
Боль и унижение, когда нихуя не получается, лезут баги в ебло и придавливает распухшим скопом.
Боль и унижение, когда нихуя не получается, лезут баги в ебло и придавливает распухшим скопом.
3,6 Мб, 1024x1536>>5316
Боль и унижения когда не можешь закончить проект.
Да и в конечном итоге твоя идея оказывается так себе.
А релизнув ты вдруг осознаешь, что всем пофиг и проект затерялся среди сотни тысяч других проектов.
А ты потратил несколько лет.
Боль и унижения когда не можешь закончить проект.
Да и в конечном итоге твоя идея оказывается так себе.
А релизнув ты вдруг осознаешь, что всем пофиг и проект затерялся среди сотни тысяч других проектов.
А ты потратил несколько лет.
31 Кб, 474x421>>5330
Но у тебя же нет релизов...
Но у тебя же нет релизов...
611 Кб, 849x786>>5338
А я и не делаю.
А я и не делаю.
98 Кб, 1447x711>>5342
Сапёр с таблетками? Чтоб принимать не забывать?
Сапёр с таблетками? Чтоб принимать не забывать?
>>5342
Хороший подход. Вместо анализа рынка и предпочтений игроков делаешь то, во что сам играл бы. Или еще проще - смотришь на игру, которая тебе в целом понравилась, но тебя не устраивают в ней какие-то моменты. Копируешь делая как надо и успех обеспечен.
Хороший подход. Вместо анализа рынка и предпочтений игроков делаешь то, во что сам играл бы. Или еще проще - смотришь на игру, которая тебе в целом понравилась, но тебя не устраивают в ней какие-то моменты. Копируешь делая как надо и успех обеспечен.
>>5335
@ Играю в игры - хочу написать свою игру.
@ Хочу написать свою игру - перестаю играть в игры, чтобы начать писать свою игру.
@ Перестаю играть в игры - больше не хочу писать игру, потому что не играю в игры.
Вот так я оказался в системном программирование и изучаю zig. А куда тебя привел геймдев?
@ Играю в игры - хочу написать свою игру.
@ Хочу написать свою игру - перестаю играть в игры, чтобы начать писать свою игру.
@ Перестаю играть в игры - больше не хочу писать игру, потому что не играю в игры.
Вот так я оказался в системном программирование и изучаю zig. А куда тебя привел геймдев?
>>5342
Делать игру, чтобы играть самому - это как делать карту в каких-нибудь героях или карту в шутере.
Ты знаешь уже всё, все места, все триггеры, все скрипты, ты даже знаешь все подводные механики и лучшие подходы - потому что ты сам создавал это все.
Это просто ноль интереса.
Делать игру, чтобы играть самому - это как делать карту в каких-нибудь героях или карту в шутере.
Ты знаешь уже всё, все места, все триггеры, все скрипты, ты даже знаешь все подводные механики и лучшие подходы - потому что ты сам создавал это все.
Это просто ноль интереса.
Мы теперь оргач? Рыгач?
Энивей, а что если делать игру за игрой за игрой, в одинаковых жанрах? Я видел пару таких челиков, один врки клепает, другой карточные. Профиты - 90% кода переиспользуется из прошлых проектов, ассеты часто тоже, остается только выверять геймплей и геймдизайн пока не взлетит, плюс ты себя зарекомендуешь как создатель в жанре Х, и любители жанра Х станут приходить именно к тебе.
Энивей, а что если делать игру за игрой за игрой, в одинаковых жанрах? Я видел пару таких челиков, один врки клепает, другой карточные. Профиты - 90% кода переиспользуется из прошлых проектов, ассеты часто тоже, остается только выверять геймплей и геймдизайн пока не взлетит, плюс ты себя зарекомендуешь как создатель в жанре Х, и любители жанра Х станут приходить именно к тебе.
>>5354
Наверно это имеет смысл. Но мне наоборот хочется сделать несколько игр в разных жанрах. Для общего развития и для себя, т.к есть игры, которые я бы хотел под себя переделать.
Наверно это имеет смысл. Но мне наоборот хочется сделать несколько игр в разных жанрах. Для общего развития и для себя, т.к есть игры, которые я бы хотел под себя переделать.
>>5348
@Играю в игрУ - хочу написать игру
@Написал игрУ - хуево написал, все пердит лагает вылетает
@Сделал тактическое отступление, обособил наработки из игры в отдельный фреймворк
@Полтора года работал над фреймворком, успел переписать его раза 2
@любимый движок обосрался с runtime fee и ты внезапно понял что движок, который стал тебе таким родным вдруг оказалася (внезапно) не твоим.
@за полгода портировал фреймворк в годот
@третий раз переписал фреймворк, доведя его до архитектурного идеала, заняло еще полгода
@в продолжающемся тактическом отступлении решил написать не то что хотел написать сначала, а что-то попроще, опробовать силы.
@начал писать, в процессе реализации ебанулся наглухо и сделал все еще сложнее чем делал в самом первом проекте чтобы добиться предельной архитектурной подвижности, настолько предельной что используешь yaml файлы для создания процесса геймплея из базовых блоков
@Наконец то доделал, оттестировал работу неткода, все проверил, все работает, идеи работают, все красиво круто
@начал настраивать игровые обьекты в годоте, колижены им прописывать и прочее
@да пошло оно все нахуй
@вишу уже две недели и не хочу даже заходить в клиентский код и редактор
бздоти, знайте, вас ждет то же самое, вы будете знать как но вы возненавидите это
@Играю в игрУ - хочу написать игру
@Написал игрУ - хуево написал, все пердит лагает вылетает
@Сделал тактическое отступление, обособил наработки из игры в отдельный фреймворк
@Полтора года работал над фреймворком, успел переписать его раза 2
@любимый движок обосрался с runtime fee и ты внезапно понял что движок, который стал тебе таким родным вдруг оказалася (внезапно) не твоим.
@за полгода портировал фреймворк в годот
@третий раз переписал фреймворк, доведя его до архитектурного идеала, заняло еще полгода
@в продолжающемся тактическом отступлении решил написать не то что хотел написать сначала, а что-то попроще, опробовать силы.
@начал писать, в процессе реализации ебанулся наглухо и сделал все еще сложнее чем делал в самом первом проекте чтобы добиться предельной архитектурной подвижности, настолько предельной что используешь yaml файлы для создания процесса геймплея из базовых блоков
@Наконец то доделал, оттестировал работу неткода, все проверил, все работает, идеи работают, все красиво круто
@начал настраивать игровые обьекты в годоте, колижены им прописывать и прочее
@да пошло оно все нахуй
@вишу уже две недели и не хочу даже заходить в клиентский код и редактор
бздоти, знайте, вас ждет то же самое, вы будете знать как но вы возненавидите это
>>5361
@а ту игру которую хотел сделать - до сих пор не доделал
@а ту игру которую хотел сделать - до сих пор не доделал
410 Кб, 1128x1050>>5361
Прост начинать надо с малого. И доводить до конца, до релиза, иначе несчитово.
Прост начинать надо с малого. И доводить до конца, до релиза, иначе несчитово.
>>5363
Малое не поможет сделать большое, а хочется чето большое, прикольное. Не гта конечно, но типа по идее посильное, просто после всех этих архитектурных изысканий ты заходишь в редактор и такой "а как какать блять", смотришь и закрываешь.
Малое не поможет сделать большое, а хочется чето большое, прикольное. Не гта конечно, но типа по идее посильное, просто после всех этих архитектурных изысканий ты заходишь в редактор и такой "а как какать блять", смотришь и закрываешь.
Можно попутно сходить по малому, делая по большому..
>>5366
Не, я не настолько ебнутый, спасибо
хотя для той самой придется либо писать плагин, либо внатуре писать редактор
Не, я не настолько ебнутый, спасибо
хотя для той самой придется либо писать плагин, либо внатуре писать редактор
>>5364
Берешь и делаешь епта. Нормальный редактор. Если что, ставишь плагины и радуешься жизни
>заходишь в редактор и такой "а как какать блять", смотришь и закрываешь.
Берешь и делаешь епта. Нормальный редактор. Если что, ставишь плагины и радуешься жизни
>>5374
Дело не в редакторе. Я уже собрал в нём всё - интерфейс, некоторые базовые игровые префабы, сессионный функционал работает. Просто вот такая какая-то хуйня - зашел - и совершенно нихуя не хочется тут делать. Может через месяц пройдет, хз. Но я скорее свой путь куда меня завел геймдев описал
Дело не в редакторе. Я уже собрал в нём всё - интерфейс, некоторые базовые игровые префабы, сессионный функционал работает. Просто вот такая какая-то хуйня - зашел - и совершенно нихуя не хочется тут делать. Может через месяц пройдет, хз. Но я скорее свой путь куда меня завел геймдев описал
1 Мб, 800x533Помните принца персии и его механику отката времени? Почему никто не бесился что надо жать и ждать пока ГГ вернется взад? Мне тут утверждают что лучше дать игроку возможность создавать произвольные точки сохранения, на которые мир будет возвращаться мгновенно, а не заставлять ждать целых ебаных 5 секунд, наблюдая эффект перемотки. Мнение?
Делаю на годоте.
Делаю на годоте.
>>5376
Так сама перемотка выглядит эффектно и создает вайб. Плюс во время перемотки больше времени на осознание как именно ты проебался во время платформинга
Так сама перемотка выглядит эффектно и создает вайб. Плюс во время перемотки больше времени на осознание как именно ты проебался во время платформинга
>>5347
Именно так, сэр.
Именно так, сэр.
27 Мб, webm,1440x1080, 2:26
>>5376
Вот бы ещё кто-то сделал адаптивную систему боя как во втором принце. Охуенная же боёвка была. Они её запатентовали штоле, что никто не воспроизводит?
Вот бы ещё кто-то сделал адаптивную систему боя как во втором принце. Охуенная же боёвка была. Они её запатентовали штоле, что никто не воспроизводит?
>>5376
Есть такая игра - timeshift, в ней движок сам, включая двигло физики, делал снапы состояния материалов обьектов, физических обьектов и даже проигрывания звука. Не представляю как это сделать на годоте, а не с помощью годота.
Есть такая игра - timeshift, в ней движок сам, включая двигло физики, делал снапы состояния материалов обьектов, физических обьектов и даже проигрывания звука. Не представляю как это сделать на годоте, а не с помощью годота.
>>5386
Частично через коллбэк _integrate_forces() частично через прямой доступ к физик-серверу синглтону, ууу.
> как это сделать на годоте
Частично через коллбэк _integrate_forces() частично через прямой доступ к физик-серверу синглтону, ууу.
>>5386
Посылаешь сигнал, пишешь состояние всего в json, потом загружаешь
Посылаешь сигнал, пишешь состояние всего в json, потом загружаешь
>>5351
Да? И как же ты объяснишь это видео?
Моделька не процедурная, лепилась 100% вручную.
>это как делать карту
>Ты знаешь уже всё, все места
Да? И как же ты объяснишь это видео?
Моделька не процедурная, лепилась 100% вручную.
>>5412
Не, анон, мне нравится твоя игра, я с интересом смотрю вебмки с прогрессом, но как можно сделать настолько уебищный графон? Или это так называемая постирония?
Не, анон, мне нравится твоя игра, я с интересом смотрю вебмки с прогрессом, но как можно сделать настолько уебищный графон? Или это так называемая постирония?
>>5419
Это так называемый девелоперский графон, который не отражает качество конечного продукта.
Это так называемый девелоперский графон, который не отражает качество конечного продукта.
Йоу, я оказывается на новом пк могу модели генерить, по картинке или сразу из текста. Это ж насколько легче становится, остается просто натянуть лоуполи сетку поверх генерации. Нахер мне тогда художник.
>>5520
С миксамо накачаю
С миксамо накачаю
>>5419
Конкретно что тебе больше всего не нравится?
В целом >>5428 правильно говорит:
Есть такой термин - "placeholder", заглушка.
Облака: тупо накинул NoiseTexture в шейдер неба. Непонятно, что делать дальше? Несколько разных вариантов облаков попробовал - всё просаживает производительность и при этом плохо выглядит. А рендеринг должен быть динамическим, по идее... Интересно было бы ориентироваться по небу... Т.е. вместо компаса - смотришь на облака и солнце.
Остров: с геометрией пока не определился, но хочу композицию из частей с вращением, так что юзаю трипланарный маппинг вместо UV. Текстуры долго использовали NoiseTexture, но я хочу сделать что-то мультяшное - накидал пару текстур на пробу. Траву дорабатывать нужно, но вот почва выглядит прям практически как нужно, только слишком бледная... Собственно, в реальности почва тоже как говно - "фотореалистично" получается, ты так не думаешь? Серьёзно, это куски грунта, как им ещё выглядеть?
Дерево: общая концепция требует баллоны с газом, поэтому шарик сверху - это важный ресурс, так что останется примерно как сейчас. Ствол же я налепил по-быстрому и текстуру натянул "лишь бы было", т.е. придётся до/переделывать. Плюс другие варианты.
Персонаж... Я всё ещё разрываюсь между "делать кастомизацию пустышки-аватарки как в ММО" и "прорабатывать уникального персонажа", так что это заглушка в любом случае, и мне было лень делать её детально. Главное, что она даёт - это связь между действиями игрока и реакцией контроллера, т.к. на примитивной капсуле многое сложно разобрать. Я изначально планировал ещё и вид от первого лица (поэтому камера убирается в голову персонажа), но, думаю, такой геймплей с ней совсем не сочетается.
Сундук и всё остальное - тоже плейсхолдеры пока.
Вообще, уже месяц как не притрагивался к этому проекту... Всё думаю, "а оно мне надо?"... Не знаю... Недавно обнаружил, что Lost Skies вывалили из EA в релиз с кучей багов и, видимо, это конец для них. Все подобные проекты набирают максимум пару тысяч отзывов и при этом там всё намного круче, чем могу сделать я. Это всё больше напоминает "сделать ГТА в одиночку", чем реалистичный инди-проект...
Если продолжать разработку, надо прекратить мою прокрастинацию микрофичами и заняться слоном в комнате: если главная идея игры "путешествовать к следующему острову", то важнее всего сделать эти острова видными издалека, плавно загружаемыми.
Я, конечно, надеялся, что если мир разбит на такие микроостровки, то опенворлд будет бесплатным. На практике каждый архипелаг - сотни нод, и многие - физические, а дерево сцен в одном потоке и всё неизбежно тормозит, если всунуть всё за один кадр.
Решение очевидно - растянуть добавление нод на несколько кадров; для этого острова нужно чётко разделить на группы нод. Для этого нужна чёткая, стандартизированная структура. А я острова уже несколько раз с нуля переделывал и сейчас они застряли в очередной переделке; текущий вид не финальный, придётся ещё что-то выдумывать.
И это только вершина айсберга...
В общем, с такими фундаментальными проблемами графические косяки - это сущий пустяк. Выглядит значительно лучше моих прежних попыток, лол.
Кстати, уже несколько лет ПЛАНИРУЮ нарисовать концептики островов, персонажей и т.п., чтоб хоть приблизительно представлять, что я делаю... Но в результате я только ковырялся в своём говнокоде, переделывая по десять раз бесполезные запчасти.
>как можно сделать настолько уебищный графон?
Конкретно что тебе больше всего не нравится?
В целом >>5428 правильно говорит:
>Это так называемый девелоперский графон
Есть такой термин - "placeholder", заглушка.
Облака: тупо накинул NoiseTexture в шейдер неба. Непонятно, что делать дальше? Несколько разных вариантов облаков попробовал - всё просаживает производительность и при этом плохо выглядит. А рендеринг должен быть динамическим, по идее... Интересно было бы ориентироваться по небу... Т.е. вместо компаса - смотришь на облака и солнце.
Остров: с геометрией пока не определился, но хочу композицию из частей с вращением, так что юзаю трипланарный маппинг вместо UV. Текстуры долго использовали NoiseTexture, но я хочу сделать что-то мультяшное - накидал пару текстур на пробу. Траву дорабатывать нужно, но вот почва выглядит прям практически как нужно, только слишком бледная... Собственно, в реальности почва тоже как говно - "фотореалистично" получается, ты так не думаешь? Серьёзно, это куски грунта, как им ещё выглядеть?
Дерево: общая концепция требует баллоны с газом, поэтому шарик сверху - это важный ресурс, так что останется примерно как сейчас. Ствол же я налепил по-быстрому и текстуру натянул "лишь бы было", т.е. придётся до/переделывать. Плюс другие варианты.
Персонаж... Я всё ещё разрываюсь между "делать кастомизацию пустышки-аватарки как в ММО" и "прорабатывать уникального персонажа", так что это заглушка в любом случае, и мне было лень делать её детально. Главное, что она даёт - это связь между действиями игрока и реакцией контроллера, т.к. на примитивной капсуле многое сложно разобрать. Я изначально планировал ещё и вид от первого лица (поэтому камера убирается в голову персонажа), но, думаю, такой геймплей с ней совсем не сочетается.
Сундук и всё остальное - тоже плейсхолдеры пока.
>с интересом смотрю вебмки с прогрессом
Вообще, уже месяц как не притрагивался к этому проекту... Всё думаю, "а оно мне надо?"... Не знаю... Недавно обнаружил, что Lost Skies вывалили из EA в релиз с кучей багов и, видимо, это конец для них. Все подобные проекты набирают максимум пару тысяч отзывов и при этом там всё намного круче, чем могу сделать я. Это всё больше напоминает "сделать ГТА в одиночку", чем реалистичный инди-проект...
Если продолжать разработку, надо прекратить мою прокрастинацию микрофичами и заняться слоном в комнате: если главная идея игры "путешествовать к следующему острову", то важнее всего сделать эти острова видными издалека, плавно загружаемыми.
Я, конечно, надеялся, что если мир разбит на такие микроостровки, то опенворлд будет бесплатным. На практике каждый архипелаг - сотни нод, и многие - физические, а дерево сцен в одном потоке и всё неизбежно тормозит, если всунуть всё за один кадр.
Решение очевидно - растянуть добавление нод на несколько кадров; для этого острова нужно чётко разделить на группы нод. Для этого нужна чёткая, стандартизированная структура. А я острова уже несколько раз с нуля переделывал и сейчас они застряли в очередной переделке; текущий вид не финальный, придётся ещё что-то выдумывать.
И это только вершина айсберга...
В общем, с такими фундаментальными проблемами графические косяки - это сущий пустяк. Выглядит значительно лучше моих прежних попыток, лол.
Кстати, уже несколько лет ПЛАНИРУЮ нарисовать концептики островов, персонажей и т.п., чтоб хоть приблизительно представлять, что я делаю... Но в результате я только ковырялся в своём говнокоде, переделывая по десять раз бесполезные запчасти.
>>5419
Конкретно что тебе больше всего не нравится?
В целом >>5428 правильно говорит:
Есть такой термин - "placeholder", заглушка.
Облака: тупо накинул NoiseTexture в шейдер неба. Непонятно, что делать дальше? Несколько разных вариантов облаков попробовал - всё просаживает производительность и при этом плохо выглядит. А рендеринг должен быть динамическим, по идее... Интересно было бы ориентироваться по небу... Т.е. вместо компаса - смотришь на облака и солнце.
Остров: с геометрией пока не определился, но хочу композицию из частей с вращением, так что юзаю трипланарный маппинг вместо UV. Текстуры долго использовали NoiseTexture, но я хочу сделать что-то мультяшное - накидал пару текстур на пробу. Траву дорабатывать нужно, но вот почва выглядит прям практически как нужно, только слишком бледная... Собственно, в реальности почва тоже как говно - "фотореалистично" получается, ты так не думаешь? Серьёзно, это куски грунта, как им ещё выглядеть?
Дерево: общая концепция требует баллоны с газом, поэтому шарик сверху - это важный ресурс, так что останется примерно как сейчас. Ствол же я налепил по-быстрому и текстуру натянул "лишь бы было", т.е. придётся до/переделывать. Плюс другие варианты.
Персонаж... Я всё ещё разрываюсь между "делать кастомизацию пустышки-аватарки как в ММО" и "прорабатывать уникального персонажа", так что это заглушка в любом случае, и мне было лень делать её детально. Главное, что она даёт - это связь между действиями игрока и реакцией контроллера, т.к. на примитивной капсуле многое сложно разобрать. Я изначально планировал ещё и вид от первого лица (поэтому камера убирается в голову персонажа), но, думаю, такой геймплей с ней совсем не сочетается.
Сундук и всё остальное - тоже плейсхолдеры пока.
Вообще, уже месяц как не притрагивался к этому проекту... Всё думаю, "а оно мне надо?"... Не знаю... Недавно обнаружил, что Lost Skies вывалили из EA в релиз с кучей багов и, видимо, это конец для них. Все подобные проекты набирают максимум пару тысяч отзывов и при этом там всё намного круче, чем могу сделать я. Это всё больше напоминает "сделать ГТА в одиночку", чем реалистичный инди-проект...
Если продолжать разработку, надо прекратить мою прокрастинацию микрофичами и заняться слоном в комнате: если главная идея игры "путешествовать к следующему острову", то важнее всего сделать эти острова видными издалека, плавно загружаемыми.
Я, конечно, надеялся, что если мир разбит на такие микроостровки, то опенворлд будет бесплатным. На практике каждый архипелаг - сотни нод, и многие - физические, а дерево сцен в одном потоке и всё неизбежно тормозит, если всунуть всё за один кадр.
Решение очевидно - растянуть добавление нод на несколько кадров; для этого острова нужно чётко разделить на группы нод. Для этого нужна чёткая, стандартизированная структура. А я острова уже несколько раз с нуля переделывал и сейчас они застряли в очередной переделке; текущий вид не финальный, придётся ещё что-то выдумывать.
И это только вершина айсберга...
В общем, с такими фундаментальными проблемами графические косяки - это сущий пустяк. Выглядит значительно лучше моих прежних попыток, лол.
Кстати, уже несколько лет ПЛАНИРУЮ нарисовать концептики островов, персонажей и т.п., чтоб хоть приблизительно представлять, что я делаю... Но в результате я только ковырялся в своём говнокоде, переделывая по десять раз бесполезные запчасти.
>как можно сделать настолько уебищный графон?
Конкретно что тебе больше всего не нравится?
В целом >>5428 правильно говорит:
>Это так называемый девелоперский графон
Есть такой термин - "placeholder", заглушка.
Облака: тупо накинул NoiseTexture в шейдер неба. Непонятно, что делать дальше? Несколько разных вариантов облаков попробовал - всё просаживает производительность и при этом плохо выглядит. А рендеринг должен быть динамическим, по идее... Интересно было бы ориентироваться по небу... Т.е. вместо компаса - смотришь на облака и солнце.
Остров: с геометрией пока не определился, но хочу композицию из частей с вращением, так что юзаю трипланарный маппинг вместо UV. Текстуры долго использовали NoiseTexture, но я хочу сделать что-то мультяшное - накидал пару текстур на пробу. Траву дорабатывать нужно, но вот почва выглядит прям практически как нужно, только слишком бледная... Собственно, в реальности почва тоже как говно - "фотореалистично" получается, ты так не думаешь? Серьёзно, это куски грунта, как им ещё выглядеть?
Дерево: общая концепция требует баллоны с газом, поэтому шарик сверху - это важный ресурс, так что останется примерно как сейчас. Ствол же я налепил по-быстрому и текстуру натянул "лишь бы было", т.е. придётся до/переделывать. Плюс другие варианты.
Персонаж... Я всё ещё разрываюсь между "делать кастомизацию пустышки-аватарки как в ММО" и "прорабатывать уникального персонажа", так что это заглушка в любом случае, и мне было лень делать её детально. Главное, что она даёт - это связь между действиями игрока и реакцией контроллера, т.к. на примитивной капсуле многое сложно разобрать. Я изначально планировал ещё и вид от первого лица (поэтому камера убирается в голову персонажа), но, думаю, такой геймплей с ней совсем не сочетается.
Сундук и всё остальное - тоже плейсхолдеры пока.
>с интересом смотрю вебмки с прогрессом
Вообще, уже месяц как не притрагивался к этому проекту... Всё думаю, "а оно мне надо?"... Не знаю... Недавно обнаружил, что Lost Skies вывалили из EA в релиз с кучей багов и, видимо, это конец для них. Все подобные проекты набирают максимум пару тысяч отзывов и при этом там всё намного круче, чем могу сделать я. Это всё больше напоминает "сделать ГТА в одиночку", чем реалистичный инди-проект...
Если продолжать разработку, надо прекратить мою прокрастинацию микрофичами и заняться слоном в комнате: если главная идея игры "путешествовать к следующему острову", то важнее всего сделать эти острова видными издалека, плавно загружаемыми.
Я, конечно, надеялся, что если мир разбит на такие микроостровки, то опенворлд будет бесплатным. На практике каждый архипелаг - сотни нод, и многие - физические, а дерево сцен в одном потоке и всё неизбежно тормозит, если всунуть всё за один кадр.
Решение очевидно - растянуть добавление нод на несколько кадров; для этого острова нужно чётко разделить на группы нод. Для этого нужна чёткая, стандартизированная структура. А я острова уже несколько раз с нуля переделывал и сейчас они застряли в очередной переделке; текущий вид не финальный, придётся ещё что-то выдумывать.
И это только вершина айсберга...
В общем, с такими фундаментальными проблемами графические косяки - это сущий пустяк. Выглядит значительно лучше моих прежних попыток, лол.
Кстати, уже несколько лет ПЛАНИРУЮ нарисовать концептики островов, персонажей и т.п., чтоб хоть приблизительно представлять, что я делаю... Но в результате я только ковырялся в своём говнокоде, переделывая по десять раз бесполезные запчасти.
>>5533
Вот старые игоры были такие проработанные, потому что все материалы по игре, все схемы и планы были на бумаге. На пе ча та ны, Карл. И разрабы чётко по графику который на стене приклеен спокойно не торопясь работу работали.
А мы 2025 году обложились фигурками аниме, и пытаемся делать игоры без плана. Держим всё в головах. Даже если диздок сделан в программах, это снова программы, которые надо открыть, а это ленивооо.
Так что прямо завтра идёшь в книжный, покупаешь блокнот, карандаш и стёрку. И начинаешь рисовать концепты в блокноте ИРЛ. А потом сканы вставляешь референсами в блендер.
Вот старые игоры были такие проработанные, потому что все материалы по игре, все схемы и планы были на бумаге. На пе ча та ны, Карл. И разрабы чётко по графику который на стене приклеен спокойно не торопясь работу работали.
А мы 2025 году обложились фигурками аниме, и пытаемся делать игоры без плана. Держим всё в головах. Даже если диздок сделан в программах, это снова программы, которые надо открыть, а это ленивооо.
Так что прямо завтра идёшь в книжный, покупаешь блокнот, карандаш и стёрку. И начинаешь рисовать концепты в блокноте ИРЛ. А потом сканы вставляешь референсами в блендер.
>>5544
Свидетель диздока, спок. Точно так же переделывали по десять раз на ходу, подпирая костылями и доедая последние пиццы из заканчивающегося бюджета.
Свидетель диздока, спок. Точно так же переделывали по десять раз на ходу, подпирая костылями и доедая последние пиццы из заканчивающегося бюджета.
>>5544
Ты забываешь, что их мотивировала зарплата.
Почитай про кранчи и почему релизы задерживают.
Я тыщу раз планы и диздоки пытался составлять. На практике часто оказывается не так, как планировал, приходится переделывать планы и диздоки, а потом забиваешь, потому что уже как-то и не хочется...
Приятно иметь план, пункты которого один за другим вычёркиваешь как сделанные. Если пункты в плане зависают неделями или приходится писать "нет - это невозможно сделать, здесь нужно что-то другое", или вообще снова добавляется ранее вычеркнутое... Сам понимаешь, такое только демотивирует ещё больше.
От руки я крайне плохо рисую + стыдно на бумаге. Я самоучка, выучил нестандартные приёмы, которыми возможно рисовать только с помощью компьютера. Собственно, от отсутствия навыков нет уверенности в практической пользе от моих "концептов"...
>разрабы чётко по графику
Ты забываешь, что их мотивировала зарплата.
>спокойно не торопясь работу работали
Почитай про кранчи и почему релизы задерживают.
>пытаемся делать игоры без плана
Я тыщу раз планы и диздоки пытался составлять. На практике часто оказывается не так, как планировал, приходится переделывать планы и диздоки, а потом забиваешь, потому что уже как-то и не хочется...
Приятно иметь план, пункты которого один за другим вычёркиваешь как сделанные. Если пункты в плане зависают неделями или приходится писать "нет - это невозможно сделать, здесь нужно что-то другое", или вообще снова добавляется ранее вычеркнутое... Сам понимаешь, такое только демотивирует ещё больше.
>начинаешь рисовать концепты в блокноте ИРЛ
От руки я крайне плохо рисую + стыдно на бумаге. Я самоучка, выучил нестандартные приёмы, которыми возможно рисовать только с помощью компьютера. Собственно, от отсутствия навыков нет уверенности в практической пользе от моих "концептов"...
>>5555
Ну, с таким пентиплом хуй поспоришь. Штош. Ты прав.
Ну, с таким пентиплом хуй поспоришь. Штош. Ты прав.
>>5555
Ебанутся, вот это кританул
Ебанутся, вот это кританул
>>5555
Это крайне полезно, такой документ называется ADR.
А потом опять убрать, потому что ты забыл, почему его убрал. Поэтому ADR на каждое важное решение будет нелишним.
>или приходится писать "нет - это невозможно сделать, здесь нужно что-то другое"
Это крайне полезно, такой документ называется ADR.
>или вообще снова добавляется ранее вычеркнутое...
А потом опять убрать, потому что ты забыл, почему его убрал. Поэтому ADR на каждое важное решение будет нелишним.
>>5565
Внезапно это тоже решает гитом. Надо просто лучше комментировать коммиты и ПРы.
>А потом опять убрать, потому что ты забыл, почему его убрал
Внезапно это тоже решает гитом. Надо просто лучше комментировать коммиты и ПРы.
>>5596
чисто технически можно конечно целый документ в коммент засунуть. даже картинку в base64. но назначение у него другое.
чисто технически можно конечно целый документ в коммент засунуть. даже картинку в base64. но назначение у него другое.
>>5609
я прочитал и не согласился - документацию гитом не заменишь
фичу ты можешь несколько недель пилить, забросить, через полгода её вообще выпилить, а ещё через полгода подумаешь "а почему у меня нет фичи X? надо сделать" и даже не вспомнишь, что нужно в каких-то коммитах что-то искать
я прочитал и не согласился - документацию гитом не заменишь
фичу ты можешь несколько недель пилить, забросить, через полгода её вообще выпилить, а ещё через полгода подумаешь "а почему у меня нет фичи X? надо сделать" и даже не вспомнишь, что нужно в каких-то коммитах что-то искать
>>5565
Ты про это? Я еле нашёл, надо сразу уточнять.
https://github.com/joelparkerhenderson/architecture-decision-record
Скажу честно - лень всё это читать. Пробежал бегло - энтерпрайзная штука какая-то. В энтерпрайзе любое действие требует сбор совета директоров, а у нас тут творческое хобби в одиночку для удовольствия... И перечитывать все свои "документы" просто скучно...
Нет, ты не так понял. Вот ты делаешь персонажа:
Если ты решишь по какой-то причине, что дизайн не подходит игре - первый пункт автоматически теряет отметку о выполнении, а вместе с ним пункт о меше, который потом заново натягивать на скелет. Т.е. 3 отдельных пункта теряют галочку выполнения. Ты, получается, сделал 4 шага вперёд и 3 шага назад...
Вот это и есть "добавление уже вычеркнутого".
>>5596
А читать это всё кто будет? ИИ-ассистент что ли?
У меня дофига своих записей, которые я не читаю...
>>5612
Это справедливо для любой формы документации.
>такой документ называется ADR
Ты про это? Я еле нашёл, надо сразу уточнять.
https://github.com/joelparkerhenderson/architecture-decision-record
Скажу честно - лень всё это читать. Пробежал бегло - энтерпрайзная штука какая-то. В энтерпрайзе любое действие требует сбор совета директоров, а у нас тут творческое хобби в одиночку для удовольствия... И перечитывать все свои "документы" просто скучно...
>убрать, потому что ты забыл, почему его убрал
Нет, ты не так понял. Вот ты делаешь персонажа:
>[ x ] Придумать дизайн персонажа (сделано)
>[ x ] Смоделировать меш персонажа (сделано)
>[ x ] Натянуть модельку на скелет (сделано)
>[ x ] Сделать анимацию ходьбы (сделано)
>[ _ ] Нарисовать текстуры одежды (в процессе)
Если ты решишь по какой-то причине, что дизайн не подходит игре - первый пункт автоматически теряет отметку о выполнении, а вместе с ним пункт о меше, который потом заново натягивать на скелет. Т.е. 3 отдельных пункта теряют галочку выполнения. Ты, получается, сделал 4 шага вперёд и 3 шага назад...
Вот это и есть "добавление уже вычеркнутого".
>>5596
>просто лучше комментировать коммиты
А читать это всё кто будет? ИИ-ассистент что ли?
У меня дофига своих записей, которые я не читаю...
>>5612
>не вспомнишь, что нужно ... что-то искать
Это справедливо для любой формы документации.
>>5515
на твг пробовал создавать модели нейронкой впервые
там вершины корявые с которыми работать не возможно
на твг пробовал создавать модели нейронкой впервые
там вершины корявые с которыми работать не возможно
Ебаный сука нейрослоп, теперь при поиске рефов в гугл-картинках бОльшая часть это кривая ИИ-мазня, с уехавшими пропорциями, перспективами и вообще дрист.
>>5618
>>5633
Стоп. Трейсить пиксель-в-пиксель хочешь?
Деревня = домики + деревья + бочки + ящики.
Домик = параллелепипеды + пирамидки.
Дерево = цилиндр + мазня сверху.
Бочка = цидиндр.
Ящик = куб.
Собери это в кучу и нарисуй. Руками. Изи!
Перспективу сам знаешь как строить - изи.
Не можешь? Тогда выбирай одно из:
0. Найти книги и учиться, учиться, учиться...
1. Найти того, кто сможет вместо тебя.
2. Генерировать помои нейронкой.
3. Делать всё в 3D, а не в 2D.
А по поиску - там есть кнопка жалобы.
>при поиске рефов
>пропорциями, перспективами
>>5633
>pixel art village
Стоп. Трейсить пиксель-в-пиксель хочешь?
Деревня = домики + деревья + бочки + ящики.
Домик = параллелепипеды + пирамидки.
Дерево = цилиндр + мазня сверху.
Бочка = цидиндр.
Ящик = куб.
Собери это в кучу и нарисуй. Руками. Изи!
Перспективу сам знаешь как строить - изи.
Не можешь? Тогда выбирай одно из:
0. Найти книги и учиться, учиться, учиться...
1. Найти того, кто сможет вместо тебя.
2. Генерировать помои нейронкой.
3. Делать всё в 3D, а не в 2D.
А по поиску - там есть кнопка жалобы.
>>5640
Во-первых этот запрос был выдачей автокомплита Утки по "pixel art", во-вторых посмотреть композицию и набор предметов в похожем арте - тоже реф.
Если каждый нейрослоп репортить времени не останется не то что на геймдев, но и на поспать.
>Трейсить пиксель-в-пиксель
Во-первых этот запрос был выдачей автокомплита Утки по "pixel art", во-вторых посмотреть композицию и набор предметов в похожем арте - тоже реф.
>А по поиску - там есть кнопка жалобы.
Если каждый нейрослоп репортить времени не останется не то что на геймдев, но и на поспать.
>>5633
Ты чёт хуйню какую-то ищешь. Естественно, с таким запросом только нейрослоп будет, потому что это самая релевантная выдача. Может, тебе нужны скрины олдовых игр, а?
Ты чёт хуйню какую-то ищешь. Естественно, с таким запросом только нейрослоп будет, потому что это самая релевантная выдача. Может, тебе нужны скрины олдовых игр, а?
760 Кб, 1168x839>>5673
У вас отрицание прост что интернет ВСЕ.
Ладно, я игры делать пошел.
>вот мой-то поисковик не показывает слоп! даже фильтр есть, настоящий!
>аррря ты просто ищешь не то, ищи менее релевантное!
У вас отрицание прост что интернет ВСЕ.
Ладно, я игры делать пошел.
>>5674
Ты совсем запутался - веб-поисковик в роли generative AI используешь?
Используй Яндекс.Картинки - там норм. Но у меня он тормозит как-то...
>pixel art godette
>литералли 3.5 картинки на весь интернет
>ожидает увидеть тонны годных результатов по этому запросу
Ты совсем запутался - веб-поисковик в роли generative AI используешь?
Используй Яндекс.Картинки - там норм. Но у меня он тормозит как-то...
>>5674
В этом есть и плюсы. Конкуренты в таких условиях не вырастут. А мы будем на вес золота, как реальные творцы.
В этом есть и плюсы. Конкуренты в таких условиях не вырастут. А мы будем на вес золота, как реальные творцы.
>>5376
Единственная игра, где мне понравилась механика отката времени, это Super Time Force Ultra. Но такое сложновато реализовать конечно. Однако это мега фаново. Я прям с удовольствием прошёл.
https://www.youtube.com/watch?v=PhJJOmJ9tiY
>Мнение?
Единственная игра, где мне понравилась механика отката времени, это Super Time Force Ultra. Но такое сложновато реализовать конечно. Однако это мега фаново. Я прям с удовольствием прошёл.
https://www.youtube.com/watch?v=PhJJOmJ9tiY
>>5703
Прикольные у них имена, мистер Годотски.
Прикольные у них имена, мистер Годотски.
>>5727
Зачем?
Зачем?
4,4 Мб, mp4,1280x704, 0:10
>>5895
Решил отдохнуть от игр и посмотреть сора-тред в б. Нашёл базированные видосы, сижу схороняю.
Решил отдохнуть от игр и посмотреть сора-тред в б. Нашёл базированные видосы, сижу схороняю.
948 Кб, webm,960x540, 0:11
>>5895
ГАТАРИ
А
Т
А
Р
И
а у тебя на пике что-то девочковое, с жирухами и бисёненами
>Нашёл базированное аниме
ГАТАРИ
А
Т
А
Р
И
а у тебя на пике что-то девочковое, с жирухами и бисёненами
Как бы вы сделали proximity объект? 3д объект, который плавно появляется когда игрок или нпс к нему приближаются. В 3д материалах есть удобные галки distanceFade и proximityFade, но первый реагирует на камеру, так что не сработает с приближающимся нпс, а второй реагирует на любой близкий объект.
>>5928 (Del)
Если моя игра мне хотябы на пару банок пива привезет - уже считай победа блять. А челу 14к не нравится.
Если моя игра мне хотябы на пару банок пива привезет - уже считай победа блять. А челу 14к не нравится.
>>5937
Че такой злой? Я лично всегда рад за успехи годот комьюнити, похуй из кого, пускай постит.
мимо другой анон
Че такой злой? Я лично всегда рад за успехи годот комьюнити, похуй из кого, пускай постит.
мимо другой анон
>>5938
У этого самого канал на 4 млн подписоты. Он мог симулятор безыгорного годачера высрать и всеравно стать успешным. Но он даже с этим обосрался. Не вижу тут никакого успеха годот комьюнити.
У этого самого канал на 4 млн подписоты. Он мог симулятор безыгорного годачера высрать и всеравно стать успешным. Но он даже с этим обосрался. Не вижу тут никакого успеха годот комьюнити.
>>5941
Видимо не все так просто.
Видимо не все так просто.
>>5936
Ну так он думал выехать на фурри пропаганде для детей и заказал производствол фигурок, а их не покупают т рекламу покупал в каких то иностранных пердях, а теперь это всё у него вышло в минус
Ну так он думал выехать на фурри пропаганде для детей и заказал производствол фигурок, а их не покупают т рекламу покупал в каких то иностранных пердях, а теперь это всё у него вышло в минус
>>5924
1. Делаешь Area3D с радиусом появления объектов.
2. При вхождении в Area3D делаешь их видимыми.
3. Сражаешься с проблемами Area3D, побеждаешь.
4. ???
5. Делаешь пулл-реквест с фиксами в движок.
Потом расскажешь, когда доделаешь, ладно?
>Как бы вы сделали proximity объект?
1. Делаешь Area3D с радиусом появления объектов.
2. При вхождении в Area3D делаешь их видимыми.
3. Сражаешься с проблемами Area3D, побеждаешь.
4. ???
5. Делаешь пулл-реквест с фиксами в движок.
Потом расскажешь, когда доделаешь, ладно?
>>5926 (Del)
Ютуб-болото заблокировано уже несколько лет.
>>5950
Не специалист, но фигурка у него неправильная.
>>5956 (Del)
4 млн - накрученные мёртвые души, очевидно...
>А вы знали, что известный ютубер...
Ютуб-болото заблокировано уже несколько лет.
>>5950
>выехать на фурри пропаганде
>заказал производствол фигурок
>Симулятор магазина с товарами для взрослых
Не специалист, но фигурка у него неправильная.
>>5956 (Del)
>Никакие выводы не напрашиваются?
4 млн - накрученные мёртвые души, очевидно...
>>5926 (Del)
Чёт он зря выбрал годот для 3Д игры.
Чёт он зря выбрал годот для 3Д игры.
>>5957
Вообще, сначала же создают популярный проект, а уже потом продают по нему мерч, а не наоборот. Как-то он всё перепутал 🤔
Вообще, сначала же создают популярный проект, а уже потом продают по нему мерч, а не наоборот. Как-то он всё перепутал 🤔
>>5959
Судя по скриншотам - он не разобрался в Environment:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html
А так в его игре нет ничего сложного. Считай, это 2D.
Судя по скриншотам - он не разобрался в Environment:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html
А так в его игре нет ничего сложного. Считай, это 2D.
>>5952
Зделол. Только при вхождении в арею запускаю скрипт, который подкручивает альбедо, учитывая дальность от центра ареи до персонажа. Вроде норм, подводных не заметил.
Зделол. Только при вхождении в арею запускаю скрипт, который подкручивает альбедо, учитывая дальность от центра ареи до персонажа. Вроде норм, подводных не заметил.
>>5910
Самое базированное аниме - это: 無人惑星サヴァイヴ, Выжить на необитаемой планете, Mujin Wakusei Survive, мультсериал
Там тебе и Звёздная месть Юрия Петухова, и Таинственный остров Жюля Верна, и Зелёный слоник Светланы Басковой.
В одном онэмэ.
Самое базированное аниме - это: 無人惑星サヴァイヴ, Выжить на необитаемой планете, Mujin Wakusei Survive, мультсериал
Там тебе и Звёздная месть Юрия Петухова, и Таинственный остров Жюля Верна, и Зелёный слоник Светланы Басковой.
В одном онэмэ.
>>5987
Выглядит как всратая нейронка.
Выглядит как всратая нейронка.
>>5971 (Del)
Всратые чёрные тени даже в дневное время, тёмные насыщенные цвета без определённой палитры...
Сделал бы картинку соответствующей мультяшным зверушкам, а не вот это вот всё мрачно-мрачное.
Просто сравни скриншоты:
1. Trailer Park Tycoon 2002 года - выглядит ЛУЧШЕ.
2. Animal Crossing 2020 года - выглядит идеально.
3. Унылое говно 2025 года - выглядит как говно.
Как с такой графикой можно надеяться на успех?
>Что натолкнуло тебя на эти мысли
Всратые чёрные тени даже в дневное время, тёмные насыщенные цвета без определённой палитры...
>что бы ты изменил
Сделал бы картинку соответствующей мультяшным зверушкам, а не вот это вот всё мрачно-мрачное.
Просто сравни скриншоты:
1. Trailer Park Tycoon 2002 года - выглядит ЛУЧШЕ.
2. Animal Crossing 2020 года - выглядит идеально.
3. Унылое говно 2025 года - выглядит как говно.
Как с такой графикой можно надеяться на успех?
Палитра и стиль решают. У блохира нет ни того, ни другого. Вот пример на годоте - вебфишинг, обладает и стилем и внятной палитрой, плюс геймплей топ, потому успех.
>>6011 (Del)
Дед, на пенсию.
Дед, на пенсию.
>>6011 (Del)
Двачую. Роблокс покорил мир ассетфлипов, теперь нужны только обьемные по механикам игры, которые в роблоксе не собрать.
Двачую. Роблокс покорил мир ассетфлипов, теперь нужны только обьемные по механикам игры, которые в роблоксе не собрать.
>>6003
Фурриебам только кость кинь, они всё купят. Игра по социальным механикам днище ебаное, но сделай фурри, добавь прикольное хрюканье - получи деньги. не понимаю, почему фурри рынок всё еще как следует не обработан
Фурриебам только кость кинь, они всё купят. Игра по социальным механикам днище ебаное, но сделай фурри, добавь прикольное хрюканье - получи деньги. не понимаю, почему фурри рынок всё еще как следует не обработан
>>6028 >>6033
Два тролля схлестнулись в эпической жирорубке...
Поясняю про игры:
1. Webfishing: эта игра - в тени Animal Crossing (милые зверушки), но для нищих детей и с мультиплеером.
2. УГ с енотом: эта хрень копирует ноунейм игру 2002, нацеливаясь на взрослую аудиторию, а не детей.
Короче, аудитория у них разная.
Поясняю про фурри... вкратце.
Во-первых, есть деление "фурри" на "фурри-фандом" и "фурри-фетишизм". Оба могут наряжаться в мохнатые костюмы и ходить на собрания. Однако, если первые заинтересованы в подобных зверушках как забавных персонажах из детства, то вторые хотят трахаться с животными - антропоморфными или не очень (да, по статистике среди фурри достаточно зоофилов). Легко догадаться - во вторую группу переходят из первой, поэтому можно считать, что большинство взрослых поклонников фурри на деле фурри-фетишисты. Нет, не каждый взрослый фурри - фетишист, т.к. фетишистом становятся обычно в маленьком возрасте (до 12-13).
Во-вторых, "фурри" - не обязательно означает "люблю пушистых животных без разбора". Там очень строгое разделение на виды и категории животных. Раньше в фандом не пускали любителей ящерообразных, типа "отсутствует мех = не фурри", поэтому драконы, птицы, ящерицы, рыбки и прочее могли смело идти на хрен. Впоследствии это изменилось и теперь "фурри" это не обязательно млекопитающее, а "разумный гуманоид". Не обязательно биологический - роботы, надувные создания, живая слизь - all are welcome. Короче, что-то вроде японского monster musume на максималках. Японцы, кстати, тоже просекли фишку: суют в новые исекай аниме побольше животноголовых, лол.
То есть, если вы делаете игру "для фурри", вы должны определиться, для каких фурри делаете? Для мелких детишек, которым просто что-то цветное на экране интересно смотреть? Или для взрослых фетишистов, которые имеют строго определённые вкусы на расы животных и их поведение? Вы не соберёте большую аудиторию, если скажете "для всех", делая фигню...
Покемоны, например, не собирают на себя всех, хотя накидали больше тысячи монстров и пиарятся уже несколько десятков лет... не признавая наличие повзрослевших фетишистов в своей аудитории (хотя изначально в лоре были браки людей с покемонами - такой-то базированный сеттинг просрали от страха).
В тоже время игру про фурри-лисичку какую-нибудь, очевидно, купят не все фурри, а только те, что дрочат лисичек в своём лисичковом подразделении фурри.
Так что Webfishing привлёк фурри-детишек, сделав правильный выбор аудитории. А та игра про енота просчиталась со вкусами своей очевидно взрослой аудитории. Взрослый фурри вряд ли будет покупать фигурку какой-то гиены, если он не дрочит на гиен; собственно игра вообще не про эту гиену, даже на обложке какой-то упоротый алкаш-енот. Может, он попытался сделать симулятор свиданий в игре?..
Запомните, дети: выбор целевой аудитории должен обусловливать остальные выборы в дизайне игры. Можете взять за ЦА себя любимых и надеяться, что некоторые люди такие же, как вы. Но если у вас нет понимания выбранной ЦА, то вы точно проиграете. В общем, делать игру "для себя" (ЦА = вы сами) инди предпочтительнее, т.к. самого себя он точно знает и бюджета на социальные исследования у него нет.
А все эти "фурри скупают всё" - это жирный троллинг. Конечно, среди фурри много богатых фетишистов. Но фетишизм - дело тонкое и без понимания аудитории производить продукт для них - пустая трата средств.
Да, я дрочу, но не на фурри. Просто натыкаюсь на них постоянно. Задолбали. Первое время пугали, а потом привык, даже начал немного разбираться в их видах. Ничего не имею против, но и не одобряю их. Лишь бы настоящих животных не насиловали...
Два тролля схлестнулись в эпической жирорубке...
Поясняю про игры:
1. Webfishing: эта игра - в тени Animal Crossing (милые зверушки), но для нищих детей и с мультиплеером.
2. УГ с енотом: эта хрень копирует ноунейм игру 2002, нацеливаясь на взрослую аудиторию, а не детей.
Короче, аудитория у них разная.
Поясняю про фурри... вкратце.
Во-первых, есть деление "фурри" на "фурри-фандом" и "фурри-фетишизм". Оба могут наряжаться в мохнатые костюмы и ходить на собрания. Однако, если первые заинтересованы в подобных зверушках как забавных персонажах из детства, то вторые хотят трахаться с животными - антропоморфными или не очень (да, по статистике среди фурри достаточно зоофилов). Легко догадаться - во вторую группу переходят из первой, поэтому можно считать, что большинство взрослых поклонников фурри на деле фурри-фетишисты. Нет, не каждый взрослый фурри - фетишист, т.к. фетишистом становятся обычно в маленьком возрасте (до 12-13).
Во-вторых, "фурри" - не обязательно означает "люблю пушистых животных без разбора". Там очень строгое разделение на виды и категории животных. Раньше в фандом не пускали любителей ящерообразных, типа "отсутствует мех = не фурри", поэтому драконы, птицы, ящерицы, рыбки и прочее могли смело идти на хрен. Впоследствии это изменилось и теперь "фурри" это не обязательно млекопитающее, а "разумный гуманоид". Не обязательно биологический - роботы, надувные создания, живая слизь - all are welcome. Короче, что-то вроде японского monster musume на максималках. Японцы, кстати, тоже просекли фишку: суют в новые исекай аниме побольше животноголовых, лол.
То есть, если вы делаете игру "для фурри", вы должны определиться, для каких фурри делаете? Для мелких детишек, которым просто что-то цветное на экране интересно смотреть? Или для взрослых фетишистов, которые имеют строго определённые вкусы на расы животных и их поведение? Вы не соберёте большую аудиторию, если скажете "для всех", делая фигню...
Покемоны, например, не собирают на себя всех, хотя накидали больше тысячи монстров и пиарятся уже несколько десятков лет... не признавая наличие повзрослевших фетишистов в своей аудитории (хотя изначально в лоре были браки людей с покемонами - такой-то базированный сеттинг просрали от страха).
В тоже время игру про фурри-лисичку какую-нибудь, очевидно, купят не все фурри, а только те, что дрочат лисичек в своём лисичковом подразделении фурри.
Так что Webfishing привлёк фурри-детишек, сделав правильный выбор аудитории. А та игра про енота просчиталась со вкусами своей очевидно взрослой аудитории. Взрослый фурри вряд ли будет покупать фигурку какой-то гиены, если он не дрочит на гиен; собственно игра вообще не про эту гиену, даже на обложке какой-то упоротый алкаш-енот. Может, он попытался сделать симулятор свиданий в игре?..
Запомните, дети: выбор целевой аудитории должен обусловливать остальные выборы в дизайне игры. Можете взять за ЦА себя любимых и надеяться, что некоторые люди такие же, как вы. Но если у вас нет понимания выбранной ЦА, то вы точно проиграете. В общем, делать игру "для себя" (ЦА = вы сами) инди предпочтительнее, т.к. самого себя он точно знает и бюджета на социальные исследования у него нет.
А все эти "фурри скупают всё" - это жирный троллинг. Конечно, среди фурри много богатых фетишистов. Но фетишизм - дело тонкое и без понимания аудитории производить продукт для них - пустая трата средств.
Да, я дрочу, но не на фурри. Просто натыкаюсь на них постоянно. Задолбали. Первое время пугали, а потом привык, даже начал немного разбираться в их видах. Ничего не имею против, но и не одобряю их. Лишь бы настоящих животных не насиловали...
>>6028 >>6033
Два тролля схлестнулись в эпической жирорубке...
Поясняю про игры:
1. Webfishing: эта игра - в тени Animal Crossing (милые зверушки), но для нищих детей и с мультиплеером.
2. УГ с енотом: эта хрень копирует ноунейм игру 2002, нацеливаясь на взрослую аудиторию, а не детей.
Короче, аудитория у них разная.
Поясняю про фурри... вкратце.
Во-первых, есть деление "фурри" на "фурри-фандом" и "фурри-фетишизм". Оба могут наряжаться в мохнатые костюмы и ходить на собрания. Однако, если первые заинтересованы в подобных зверушках как забавных персонажах из детства, то вторые хотят трахаться с животными - антропоморфными или не очень (да, по статистике среди фурри достаточно зоофилов). Легко догадаться - во вторую группу переходят из первой, поэтому можно считать, что большинство взрослых поклонников фурри на деле фурри-фетишисты. Нет, не каждый взрослый фурри - фетишист, т.к. фетишистом становятся обычно в маленьком возрасте (до 12-13).
Во-вторых, "фурри" - не обязательно означает "люблю пушистых животных без разбора". Там очень строгое разделение на виды и категории животных. Раньше в фандом не пускали любителей ящерообразных, типа "отсутствует мех = не фурри", поэтому драконы, птицы, ящерицы, рыбки и прочее могли смело идти на хрен. Впоследствии это изменилось и теперь "фурри" это не обязательно млекопитающее, а "разумный гуманоид". Не обязательно биологический - роботы, надувные создания, живая слизь - all are welcome. Короче, что-то вроде японского monster musume на максималках. Японцы, кстати, тоже просекли фишку: суют в новые исекай аниме побольше животноголовых, лол.
То есть, если вы делаете игру "для фурри", вы должны определиться, для каких фурри делаете? Для мелких детишек, которым просто что-то цветное на экране интересно смотреть? Или для взрослых фетишистов, которые имеют строго определённые вкусы на расы животных и их поведение? Вы не соберёте большую аудиторию, если скажете "для всех", делая фигню...
Покемоны, например, не собирают на себя всех, хотя накидали больше тысячи монстров и пиарятся уже несколько десятков лет... не признавая наличие повзрослевших фетишистов в своей аудитории (хотя изначально в лоре были браки людей с покемонами - такой-то базированный сеттинг просрали от страха).
В тоже время игру про фурри-лисичку какую-нибудь, очевидно, купят не все фурри, а только те, что дрочат лисичек в своём лисичковом подразделении фурри.
Так что Webfishing привлёк фурри-детишек, сделав правильный выбор аудитории. А та игра про енота просчиталась со вкусами своей очевидно взрослой аудитории. Взрослый фурри вряд ли будет покупать фигурку какой-то гиены, если он не дрочит на гиен; собственно игра вообще не про эту гиену, даже на обложке какой-то упоротый алкаш-енот. Может, он попытался сделать симулятор свиданий в игре?..
Запомните, дети: выбор целевой аудитории должен обусловливать остальные выборы в дизайне игры. Можете взять за ЦА себя любимых и надеяться, что некоторые люди такие же, как вы. Но если у вас нет понимания выбранной ЦА, то вы точно проиграете. В общем, делать игру "для себя" (ЦА = вы сами) инди предпочтительнее, т.к. самого себя он точно знает и бюджета на социальные исследования у него нет.
А все эти "фурри скупают всё" - это жирный троллинг. Конечно, среди фурри много богатых фетишистов. Но фетишизм - дело тонкое и без понимания аудитории производить продукт для них - пустая трата средств.
Да, я дрочу, но не на фурри. Просто натыкаюсь на них постоянно. Задолбали. Первое время пугали, а потом привык, даже начал немного разбираться в их видах. Ничего не имею против, но и не одобряю их. Лишь бы настоящих животных не насиловали...
Два тролля схлестнулись в эпической жирорубке...
Поясняю про игры:
1. Webfishing: эта игра - в тени Animal Crossing (милые зверушки), но для нищих детей и с мультиплеером.
2. УГ с енотом: эта хрень копирует ноунейм игру 2002, нацеливаясь на взрослую аудиторию, а не детей.
Короче, аудитория у них разная.
Поясняю про фурри... вкратце.
Во-первых, есть деление "фурри" на "фурри-фандом" и "фурри-фетишизм". Оба могут наряжаться в мохнатые костюмы и ходить на собрания. Однако, если первые заинтересованы в подобных зверушках как забавных персонажах из детства, то вторые хотят трахаться с животными - антропоморфными или не очень (да, по статистике среди фурри достаточно зоофилов). Легко догадаться - во вторую группу переходят из первой, поэтому можно считать, что большинство взрослых поклонников фурри на деле фурри-фетишисты. Нет, не каждый взрослый фурри - фетишист, т.к. фетишистом становятся обычно в маленьком возрасте (до 12-13).
Во-вторых, "фурри" - не обязательно означает "люблю пушистых животных без разбора". Там очень строгое разделение на виды и категории животных. Раньше в фандом не пускали любителей ящерообразных, типа "отсутствует мех = не фурри", поэтому драконы, птицы, ящерицы, рыбки и прочее могли смело идти на хрен. Впоследствии это изменилось и теперь "фурри" это не обязательно млекопитающее, а "разумный гуманоид". Не обязательно биологический - роботы, надувные создания, живая слизь - all are welcome. Короче, что-то вроде японского monster musume на максималках. Японцы, кстати, тоже просекли фишку: суют в новые исекай аниме побольше животноголовых, лол.
То есть, если вы делаете игру "для фурри", вы должны определиться, для каких фурри делаете? Для мелких детишек, которым просто что-то цветное на экране интересно смотреть? Или для взрослых фетишистов, которые имеют строго определённые вкусы на расы животных и их поведение? Вы не соберёте большую аудиторию, если скажете "для всех", делая фигню...
Покемоны, например, не собирают на себя всех, хотя накидали больше тысячи монстров и пиарятся уже несколько десятков лет... не признавая наличие повзрослевших фетишистов в своей аудитории (хотя изначально в лоре были браки людей с покемонами - такой-то базированный сеттинг просрали от страха).
В тоже время игру про фурри-лисичку какую-нибудь, очевидно, купят не все фурри, а только те, что дрочат лисичек в своём лисичковом подразделении фурри.
Так что Webfishing привлёк фурри-детишек, сделав правильный выбор аудитории. А та игра про енота просчиталась со вкусами своей очевидно взрослой аудитории. Взрослый фурри вряд ли будет покупать фигурку какой-то гиены, если он не дрочит на гиен; собственно игра вообще не про эту гиену, даже на обложке какой-то упоротый алкаш-енот. Может, он попытался сделать симулятор свиданий в игре?..
Запомните, дети: выбор целевой аудитории должен обусловливать остальные выборы в дизайне игры. Можете взять за ЦА себя любимых и надеяться, что некоторые люди такие же, как вы. Но если у вас нет понимания выбранной ЦА, то вы точно проиграете. В общем, делать игру "для себя" (ЦА = вы сами) инди предпочтительнее, т.к. самого себя он точно знает и бюджета на социальные исследования у него нет.
А все эти "фурри скупают всё" - это жирный троллинг. Конечно, среди фурри много богатых фетишистов. Но фетишизм - дело тонкое и без понимания аудитории производить продукт для них - пустая трата средств.
Да, я дрочу, но не на фурри. Просто натыкаюсь на них постоянно. Задолбали. Первое время пугали, а потом привык, даже начал немного разбираться в их видах. Ничего не имею против, но и не одобряю их. Лишь бы настоящих животных не насиловали...
>>6048
Ого, вы эксперт по фурри, мое почтение.
Ого, вы эксперт по фурри, мое почтение.
Кто-то пробоваь клод сонет подрубать к godot? Как чел вот с этого видео https://youtu.be/THwZYWuOdZI?si=k2ZWwwG7oucR4Mqn
Как оно работает с большими проектами, которые уже разрабатываются?
Чет глянул и тильтую теперь
Как оно работает с большими проектами, которые уже разрабатываются?
Чет глянул и тильтую теперь
>>6101
Мне неиронично больше нравится чат-формат с сохраненным контекстом. Контроль выше, спрашивать удобней.
Мне неиронично больше нравится чат-формат с сохраненным контекстом. Контроль выше, спрашивать удобней.
47 Кб, 718x462>>6101
К сожалению оно не для меня написано, и не для таких как я.
К сожалению оно не для меня написано, и не для таких как я.
305 Кб, 460x601>>6107
Давай карочи, типа я издатель, а ты девелопер, проебавший все сроки.
Давай карочи, типа я издатель, а ты девелопер, проебавший все сроки.
167 Кб, 1024x700>>6114
Будем обновлять.
Будем обновлять.
>>6107
Тяжело морально, когда видишь, как нейронки уничтожают креативный класс (т.е. нас с вами буквально)
>ПОЛОВИНА ПОБРОСАЛО
Тяжело морально, когда видишь, как нейронки уничтожают креативный класс (т.е. нас с вами буквально)
4,6 Мб, mp4,1280x704, 0:10
>>6124
Да ладно тебе. Не ври себе. Мы просто ленивые овощи. Нейронки буквально заменяют нам сотрудников, которых раньше в треде поиска сотрудников искали. Музыка? Да! Арт? Да! Бойлерплейт кода? Да! А что же мы? Продолжаем прокрастинировать.
Да ладно тебе. Не ври себе. Мы просто ленивые овощи. Нейронки буквально заменяют нам сотрудников, которых раньше в треде поиска сотрудников искали. Музыка? Да! Арт? Да! Бойлерплейт кода? Да! А что же мы? Продолжаем прокрастинировать.
Нашёл годные бесплатные 3D модели:
https://sketchfab.com/marcoslate1999
Многовато треугольников, правда...
>>6124
Никто не запрещает тебе креативить.
А заработать ты и раньше не смог бы...
>>6128
Особенно после курса таблеток...
Ну а что нам ещё делать... Игры?
Godot - это игра. И мы в неё играем.
https://sketchfab.com/marcoslate1999
Многовато треугольников, правда...
>>6124
>уничтожают креативный класс
Никто не запрещает тебе креативить.
А заработать ты и раньше не смог бы...
>>6128
>Мы просто ленивые овощи.
Особенно после курса таблеток...
>Продолжаем прокрастинировать.
Ну а что нам ещё делать... Игры?
Godot - это игра. И мы в неё играем.
4 Мб, mp4,704x1280, 0:10
Я вот думаю, как в 2Д платформере заюзать нейросети? Есть всякие билдеры, типа марио ворлд, где ты создаёшь уровни, а другие игроки их проходят. Однако многие уровни получаются уродливыми, так как у игроков нет достаточно опыта и времени сделать "красиво". Что, если игрок будет схематически показывать устройство уровня, а далее нейросетка на основе наброска сгенерирует уже на выбор 3 карты. Далее ты должен пройти карту от начала до конца, и тогда её можно будет опубликовать, либо перегенерировать. Но тут конечно вопрос откуда брать данные для обучения.
>>6149
https://poly.pizza
Я отсюда иногда беру, по лицензии все СС0 или BY.
>>6154
Тоже думал в эту сторону. Наляпать в формате скриншотов нейросеть может. Самое трудное - заставить ее собственно в игре это потом построить, и там либо куча ручной работы по интеграции, либо неюзабельная каша, когда нейронка без понимания чего-куда пытается .tscn нагенерить.
https://poly.pizza
Я отсюда иногда беру, по лицензии все СС0 или BY.
>>6154
Тоже думал в эту сторону. Наляпать в формате скриншотов нейросеть может. Самое трудное - заставить ее собственно в игре это потом построить, и там либо куча ручной работы по интеграции, либо неюзабельная каша, когда нейронка без понимания чего-куда пытается .tscn нагенерить.
>>6172
Много чего и без нейросети можно, вопрос в количестве усилий. Если подключение ИИ такое же ебучее как и делать руками, то смысла в ИИ на эту задачу ноль.
Много чего и без нейросети можно, вопрос в количестве усилий. Если подключение ИИ такое же ебучее как и делать руками, то смысла в ИИ на эту задачу ноль.
>>6174 (Del)
Не мы такие, 12.09.2023 такая. Не считая прочего.
Не мы такие, 12.09.2023 такая. Не считая прочего.
>>6154
Никак, жанр мёртв и никому не нужен.
Тебе шашечки (красиво) или ехать (интересно)?
Это можно автоматизировать без нейросетей:
https://github.com/mxgmn/WaveFunctionCollapse
Можно генерировать процедурно...
Можно через reinforcement learning...
Вопрос в том, что тебе даст нейронка?
>>6157
Хороший сайт и результаты интересные.
Речь не о больших претрейнах, а о кастомной штуке.
Анон хочет обучать свою нейронку с чистого листа.
>>6173
Без труда не вытянешь и рыбки из пруда...
>>6175
Не корми тролля - молча репорти его посты.
>как в 2Д платформере
Никак, жанр мёртв и никому не нужен.
>многие уровни получаются уродливыми
Тебе шашечки (красиво) или ехать (интересно)?
>схематически показывать устройство уровня
Это можно автоматизировать без нейросетей:
https://github.com/mxgmn/WaveFunctionCollapse
>откуда брать данные для обучения
Можно генерировать процедурно...
Можно через reinforcement learning...
Вопрос в том, что тебе даст нейронка?
>>6157
>Я отсюда иногда беру
Хороший сайт и результаты интересные.
>Наляпать в формате скриншотов нейросеть может
>заставить собственно в игре это потом построить
Речь не о больших претрейнах, а о кастомной штуке.
Анон хочет обучать свою нейронку с чистого листа.
>>6173
>вопрос в количестве усилий
Без труда не вытянешь и рыбки из пруда...
>>6175
Не корми тролля - молча репорти его посты.
>>6154
Никак, жанр мёртв и никому не нужен.
Тебе шашечки (красиво) или ехать (интересно)?
Это можно автоматизировать без нейросетей:
https://github.com/mxgmn/WaveFunctionCollapse
Можно генерировать процедурно...
Можно через reinforcement learning...
Вопрос в том, что тебе даст нейронка?
>>6157
Хороший сайт и результаты интересные.
Речь не о больших претрейнах, а о кастомной штуке.
Анон хочет обучать свою нейронку с чистого листа.
>>6173
Без труда не вытянешь и рыбки из пруда...
>>6175
Не корми тролля - молча репорти его посты.
>как в 2Д платформере
Никак, жанр мёртв и никому не нужен.
>многие уровни получаются уродливыми
Тебе шашечки (красиво) или ехать (интересно)?
>схематически показывать устройство уровня
Это можно автоматизировать без нейросетей:
https://github.com/mxgmn/WaveFunctionCollapse
>откуда брать данные для обучения
Можно генерировать процедурно...
Можно через reinforcement learning...
Вопрос в том, что тебе даст нейронка?
>>6157
>Я отсюда иногда беру
Хороший сайт и результаты интересные.
>Наляпать в формате скриншотов нейросеть может
>заставить собственно в игре это потом построить
Речь не о больших претрейнах, а о кастомной штуке.
Анон хочет обучать свою нейронку с чистого листа.
>>6173
>вопрос в количестве усилий
Без труда не вытянешь и рыбки из пруда...
>>6175
Не корми тролля - молча репорти его посты.
>>6188
Ну игра-то говно. Онлайн из-за мемов про то, что игра никогда не выйдет. Сможет ли инди разраб без большой фанбазы повторить подобный эффект? Не думаю.
Ну игра-то говно. Онлайн из-за мемов про то, что игра никогда не выйдет. Сможет ли инди разраб без большой фанбазы повторить подобный эффект? Не думаю.
>>6190
Ну то есть дело не в жанре уже. Окей.
Ender lilies. Разраб без фанбазы отбил игру, частенько переигрываю в нее. Salt and sanctuary так и вовсе мой самый любимый платформер, переигрывал бесчисленное множество раз. Есть еще пример бласпхемоус. Хотя я лично считаю первый холоунайт тупвм говном, душным и уебищным.
>Онлайн из-за мемов про то, что игра никогда не выйдет.
Ну то есть дело не в жанре уже. Окей.
>Сможет ли инди разраб без большой фанбазы
Ender lilies. Разраб без фанбазы отбил игру, частенько переигрываю в нее. Salt and sanctuary так и вовсе мой самый любимый платформер, переигрывал бесчисленное множество раз. Есть еще пример бласпхемоус. Хотя я лично считаю первый холоунайт тупвм говном, душным и уебищным.
>>6205
Берёшь и делаешь, ничего сложного. Хочешь - делаешь сегодня, хочешь - завтра, хочешь - все следующие несколько лет делаешь и делаешь
Берёшь и делаешь, ничего сложного. Хочешь - делаешь сегодня, хочешь - завтра, хочешь - все следующие несколько лет делаешь и делаешь
Гайс, не подскажите, сейчас скооперировался с одним чувачком, добавил его в гит, он скачал ту же версию что и у меня, но у него проект тупо вылетает, что в основной ветке что в той что для него сделал. Тип редактор тупо вылетает без ошибок, а у меня всё работает нормально.
Версия 4.4.1 , он попробовал открыть в 4.5 но все равно вылетает. Экспортная игра у него запускается. Может я чет не то делал?
Версия 4.4.1 , он попробовал открыть в 4.5 но все равно вылетает. Экспортная игра у него запускается. Может я чет не то делал?
>>6208
Душно, господа, несите брют в фужерах!
Душно, господа, несите брют в фужерах!
103 Кб, 800x600>>6195
Переводчик отказывается озвучивать такое длинное, а по английски я не умею.
Переводчик отказывается озвучивать такое длинное, а по английски я не умею.
>>6243
Ну логи пусть покажет. Может у него видеодрова кривые или дотнет не той версии. Попроси открыть годот через батник из папки с движком, все будет видно почему упало.
Ну логи пусть покажет. Может у него видеодрова кривые или дотнет не той версии. Попроси открыть годот через батник из папки с движком, все будет видно почему упало.
Я делаю ККИ в Godot 4+. Мне нужно, чтобы при выборе карты на экране появлялся указатель баффа. Как лучше всего реализовать этот указатель?
>>6195
Господа можете на русский язык это перевести, яндекс браузер не справляется.
Господа можете на русский язык это перевести, яндекс браузер не справляется.
>>6249
Смотря что из себя представляет этот указатель. Если это спрайт с картинкой баффа + шейдер аутлайна какой нибудь то можешь на похуях делать на спрайте/плейне. Если нужен текст, отступы и прочая юайщина - делай через ui контрол с 0;0, 0;0 якорями.
Смотря что из себя представляет этот указатель. Если это спрайт с картинкой баффа + шейдер аутлайна какой нибудь то можешь на похуях делать на спрайте/плейне. Если нужен текст, отступы и прочая юайщина - делай через ui контрол с 0;0, 0;0 якорями.
>>6252
Странно, с первым курсом в 14 часов справлялся, деградировал видимо
Странно, с первым курсом в 14 часов справлялся, деградировал видимо
Когда уже дообучают нейросетки, сброшу ей свои txt записи и пусть ебашит игры мне. Там на несколько серий полноценных хватит. Эх, осталось совсем чуток потерпеть.
>>6277
Не думаю что чуток. Именно адекватная реализация выйдет может лет через 5, если повезёт.
>совсем чуток
Не думаю что чуток. Именно адекватная реализация выйдет может лет через 5, если повезёт.
>>6277
>>6279
И то она будет бездвижковая, типа google genie, которые, по сути, галлюцинируют тебе видос и подправляют его под твой инпут. Облачный гейминг как его хотели большие дяди, ты только подписку плоти.
Лепить игры с помощью ИИ через традиционные движки на этом фоне бесполезно-комплексно. Зачем ИИ кодить сложные системы, когда их можно нарисовать. В плане производительности тоже интересно - то, о чем мы сегодня думаем как удар по фпс, например физика миллиардов объектов или качественная симуляция жидкостей, ИИ нарисует на раз-два. Все эти пастрейсинги тоже внезапно нахуй не нужны.
Интересное время крч.
>>6279
И то она будет бездвижковая, типа google genie, которые, по сути, галлюцинируют тебе видос и подправляют его под твой инпут. Облачный гейминг как его хотели большие дяди, ты только подписку плоти.
Лепить игры с помощью ИИ через традиционные движки на этом фоне бесполезно-комплексно. Зачем ИИ кодить сложные системы, когда их можно нарисовать. В плане производительности тоже интересно - то, о чем мы сегодня думаем как удар по фпс, например физика миллиардов объектов или качественная симуляция жидкостей, ИИ нарисует на раз-два. Все эти пастрейсинги тоже внезапно нахуй не нужны.
Интересное время крч.
Не люблю Годот, но обожаю годотеров. Кто сейм?
>>6331
Ошибка странная, пусть скачает последнюю версию и попробует, возможно у него майнер в системе или ебанутый антивирус
Ошибка странная, пусть скачает последнюю версию и попробует, возможно у него майнер в системе или ебанутый антивирус
>>6331
https://www.reddit.com/r/AMDHelp/comments/1aelvdm/mini_pc_ryzen_7_5800h_vulkan_suddenly_not_working/
Лиииибо
Пусть запустит годотовский экзешник через консоль с параметром --rendering-driver opengl3
Если запустится - у него какое-то говно с вулканом. Лучше даже начать с первого варианта, а затем удалять всякое
https://www.reddit.com/r/AMDHelp/comments/1aelvdm/mini_pc_ryzen_7_5800h_vulkan_suddenly_not_working/
Лиииибо
Пусть запустит годотовский экзешник через консоль с параметром --rendering-driver opengl3
Если запустится - у него какое-то говно с вулканом. Лучше даже начать с первого варианта, а затем удалять всякое
>>6331
Третий вариант в самом конце ишью
https://github.com/godotengine/godot/issues/94112
Возможно это.
Третий вариант в самом конце ишью
https://github.com/godotengine/godot/issues/94112
Возможно это.
>ишью
Лул
>Лул
Лол
Пекарня нищая сгорела сегодня, вместе со всеми проектами. У меня давно ничего не сгорало, поэтому я расслабился и не делал бэкапы. И пропустил удар.
>>6406
Все так, вместо того чтобы потратить денек, лучше ничего не делать, поныть, и начать все с начала, а то и вообще забить.
Все так, вместо того чтобы потратить денек, лучше ничего не делать, поныть, и начать все с начала, а то и вообще забить.
>>6407
Если ссд откинулся - с него даже фсб нихуя не достанет, не то что анон со своими рекува перделками
Если ссд откинулся - с него даже фсб нихуя не достанет, не то что анон со своими рекува перделками
>>6416
Мне казалось ССД наоборот проще в плане восстановления данных.
Мне казалось ССД наоборот проще в плане восстановления данных.
366 Кб, 680x459Как пизже грузить ресурсы: при запуске игры или на загрузочном экране?
Мне больше при запуске нравится
Мне больше при запуске нравится
>>6436
В игре есть уровни? На загрузочном экране уровня.
В игре один уровень и он большой? На загрузочном экране.
Игра средне-мелкая? При запуске грузи всю.
В игре есть уровни? На загрузочном экране уровня.
В игре один уровень и он большой? На загрузочном экране.
Игра средне-мелкая? При запуске грузи всю.
ШОК! Кто-то довёл до релиза свой ретро-хоррор на годоте! может и я однажды ето сделаю...
https://store.steampowered.com/app/3447260/House_of_Necrosis_Demo/
О том что игра на годоте узнал после вылета при первом запуске демки. Сначала не понял в чем дело, думал это у меня годот наебнулся, но я сегодня не запускал его же, лол. Со второго раза запустилось и все норм
https://store.steampowered.com/app/3447260/House_of_Necrosis_Demo/
О том что игра на годоте узнал после вылета при первом запуске демки. Сначала не понял в чем дело, думал это у меня годот наебнулся, но я сегодня не запускал его же, лол. Со второго раза запустилось и все норм
>>6478
Плохо-плохо. Вот если бы я релизил игры, я бы как минимум менял внутренние названия экспортного шаблона в ресурсах ресхакером (как я это делал на ТВГ когда там участвовал, занимая вторые с конца места). А возможно даже конпелировал бы собственные шаблоны.
> О том что игра на годоте узнал после вылета при первом запуске демки.
Плохо-плохо. Вот если бы я релизил игры, я бы как минимум менял внутренние названия экспортного шаблона в ресурсах ресхакером (как я это делал на ТВГ когда там участвовал, занимая вторые с конца места). А возможно даже конпелировал бы собственные шаблоны.
23 Кб, 429x520>>6499
Да, я в курсе что движок так может. Но через классические редакторы ресурсов контроля больше. А потом ещё можно хекс-редактором пройтись и все упоминания годота вырезать.
Да, я в курсе что движок так может. Но через классические редакторы ресурсов контроля больше. А потом ещё можно хекс-редактором пройтись и все упоминания годота вырезать.
97 Кб, 661x282>>6491
самокритично
самокритично
>>6504
Просто потому что могу. Лицензия MIT не запрещает. Я хочу брендированные окна критических ошибок. Вот хочу - и всё.
> А зачем?
Просто потому что могу. Лицензия MIT не запрещает. Я хочу брендированные окна критических ошибок. Вот хочу - и всё.
>>6507
Я знаю что не запрещает. Твое право, твое дело, хоть движок форкай. Просто интересна логика такой хотелки.
Я знаю что не запрещает. Твое право, твое дело, хоть движок форкай. Просто интересна логика такой хотелки.
>>6509
Контроль. Я люблю контролировать всё до мелочей. Извини, что из поста сразу это прямо не последовало.
> интересна логика
Контроль. Я люблю контролировать всё до мелочей. Извини, что из поста сразу это прямо не последовало.
107 Кб, 640x640>>6514
Пасиб)
Пасиб)
96 Кб, 480x270А что если для одноразового (OneShot) кода использовать ноды-с-кодом, которые по завершении своего кода УДОЛЯЮТ себя?
>>6536
Операции с деревом дорогие. Лучше заведи глобальную ноду с массивом, куда всовывай инстанс+имя метода, и за process проходи весь массив, и зачищай его.
Операции с деревом дорогие. Лучше заведи глобальную ноду с массивом, куда всовывай инстанс+имя метода, и за process проходи весь массив, и зачищай его.
136 Кб, mp4,640x352, 0:03
>>6588
Не надо её заводить, она уже есть - корень дерева. Просто научись с неё работать. Корень дерева уже есть. Почему бы не закинуть туда именованный скрипт и далее через простейший тайп-каст работать с ним. Это безопасно.
> Лучше заведи глобальную нод
Не надо её заводить, она уже есть - корень дерева. Просто научись с неё работать. Корень дерева уже есть. Почему бы не закинуть туда именованный скрипт и далее через простейший тайп-каст работать с ним. Это безопасно.
> if get_tree().root is MySingletonExtensionClass r: r.my_method(); r.my_array = [1,2,3]
>>6589
Очевидно, приведённый псевдокод не будет работать, потому что там синтаксис гдскрипта вперемешку с шарпом. Вот как правильно:
>>6590
Пишите игоры с синглтонами, посаны, игнорируйте посты синглтоношиза, гоните, смейтесь.
Очевидно, приведённый псевдокод не будет работать, потому что там синтаксис гдскрипта вперемешку с шарпом. Вот как правильно:
> var r = get_tree().root as MySingletonExtensionClass # если каст не пройдёт, переменная будет null
> > r: r.my_method() # всё, в этом скопе у нас подтянуты автодополнения, вызываем методы
> > r.my_array = [1,2,3] # вызываем мемберы
> > # если корень не наш, код просто не выполнится, не вызывая ошибок.
> > # если ошибка нужна, то
> else:
> > push_error("Вы не установили скрипт в корень")
>>6590
Пишите игоры с синглтонами, посаны, игнорируйте посты синглтоношиза, гоните, смейтесь.
>>6591
Ну ёп вашу. Проебал иф. Сами вставьте. Домашнее задание. Где в коде иф проебан? Подсказка в комментах к коду.
Ну ёп вашу. Проебал иф. Сами вставьте. Домашнее задание. Где в коде иф проебан? Подсказка в комментах к коду.
>>6589
Я напоминаю, в годоте нода может обладать только одним типом. Для таких сценариев и создан globalclass, нахуя велосипедить к рутовой ноде тип этой херни, когда движком предусмотрен более элегентный способ? А если я на рут захочу повесить другой скрипт, какой нибудь менеджер сцены? Который у каждой сцены свой будет.
Я напоминаю, в годоте нода может обладать только одним типом. Для таких сценариев и создан globalclass, нахуя велосипедить к рутовой ноде тип этой херни, когда движком предусмотрен более элегентный способ? А если я на рут захочу повесить другой скрипт, какой нибудь менеджер сцены? Который у каждой сцены свой будет.
>>6593
А если я захочу погоду за прошлый год? Что ж мне теперь ,весь менеджер погоды переписывать?
Хаха!
А если я захочу погоду за прошлый год? Что ж мне теперь ,весь менеджер погоды переписывать?
Хаха!
>>6590
Напади в ответ
Напади в ответ
Ребята, помогите составить тир-лист для моей карточной игры!
Способности героев (1 раз за ход, без манны):
Некромант: взять карту, −2 HP себе.
Маг: нанести 1 урона любому существу.
Оракл: дать союзному существу случайное ключевое слово.
Целитель: вылечить союзное существо на 2 HP.
Вампир: нанести своему существу 1 урона; если выживает — +1 мана.
Друид: +1 HP себе, но обязан атаковать вражеское существо.
Ключевые слова (выдаются Ораклом):
Ободрение, Воровство, Вампиризм, Вард, Яд, Иммунитет к яду.
Способности героев (1 раз за ход, без манны):
Некромант: взять карту, −2 HP себе.
Маг: нанести 1 урона любому существу.
Оракл: дать союзному существу случайное ключевое слово.
Целитель: вылечить союзное существо на 2 HP.
Вампир: нанести своему существу 1 урона; если выживает — +1 мана.
Друид: +1 HP себе, но обязан атаковать вражеское существо.
Ключевые слова (выдаются Ораклом):
Ободрение, Воровство, Вампиризм, Вард, Яд, Иммунитет к яду.
Ключевые слова (от Оракла):
Ободрение: При атаке — союзная карта в руке получает +1/+1.
Воровство: При атаке врага — +1/+0.
Вампиризм: При атаке — восстановление HP = урону.
Вард: Иммунитет к урону на 1 ход.
Яд: Уничтожает существо без иммунитета к яду.
Иммунитет к яду: Не умирает от яда.
Ободрение: При атаке — союзная карта в руке получает +1/+1.
Воровство: При атаке врага — +1/+0.
Вампиризм: При атаке — восстановление HP = урону.
Вард: Иммунитет к урону на 1 ход.
Яд: Уничтожает существо без иммунитета к яду.
Иммунитет к яду: Не умирает от яда.
>>6600
>>6601
Некромант: реанимировать заброшенную игру на пигейме, −2 HP себе.
Маг: нанести урон любому анону, раздув масштаб его игры.
Оракл: дать союзному существу случайное ключевое слово.
Целитель: подсказать решение проблемы союзному анону, +2 HP.
Вампир: делаешь игру исключительно по туториалам с ютуба, повторяя 1-в-1.
Друид: никому не показываешь свою игру 7 лет, работаешь "в стол", фидбек - твой враг.
Ключевые слова (выдаются Ораклом):
Ободрение — "делайте игры, годаны", буст морали для союзного анона.
Воровство — крадешь гениальные идеи у противников.
Вампиризм — лечишься за счет обсирания чужих игр.
Вард — "не трогай меня, я игры делаю", защита на 1 ход.
Яд — тихий баг в системе - синглтоны и прочие антипаттерны уничтожают игру.
Иммунитет к яду — анон ебет ваши антипаттерны в рот и делает игру за игрой, раз-раз, раз-раз и в релиз.
>>6601
Некромант: реанимировать заброшенную игру на пигейме, −2 HP себе.
Маг: нанести урон любому анону, раздув масштаб его игры.
Оракл: дать союзному существу случайное ключевое слово.
Целитель: подсказать решение проблемы союзному анону, +2 HP.
Вампир: делаешь игру исключительно по туториалам с ютуба, повторяя 1-в-1.
Друид: никому не показываешь свою игру 7 лет, работаешь "в стол", фидбек - твой враг.
Ключевые слова (выдаются Ораклом):
Ободрение — "делайте игры, годаны", буст морали для союзного анона.
Воровство — крадешь гениальные идеи у противников.
Вампиризм — лечишься за счет обсирания чужих игр.
Вард — "не трогай меня, я игры делаю", защита на 1 ход.
Яд — тихий баг в системе - синглтоны и прочие антипаттерны уничтожают игру.
Иммунитет к яду — анон ебет ваши антипаттерны в рот и делает игру за игрой, раз-раз, раз-раз и в релиз.
>>6536
В общем случае эта задача неразрешима.
Какой именно код тебе нужно выполнить один раз?
_init выполняется 1 раз при инициализации Object.
_enter_tree - 1 раз при 1 вхождении Node в дерево.
_ready - 1 раз после всех _ready всех дочерних Node.
_exit_tree - 1 раз при 1 выходе Node из дерева сцены.
_process - 1 раз при 1 итерации цикла рендеринга.
_input - 1 раз на каждое событие ввода InputEvent
И т.д. Всё это - "одноразовые участки кода".
По классам объектов следует опираться на это:
Любые потомки Node - если нужен их функционал.
Node - если нужно взаимодействие с деревом сцены.
Resource - если нужно сохранение/загрузка файлов.
RefCounted - если нужен просто какой-то код.
Object - если тебе мешает reference counter.
В целом, Godot часто создаёт одноразовые объекты:
Они удаляются после завершения работы.
Для наглядности, попробуйте следить за этим:
Оно постоянно колеблется даже на простой сцене...
>одноразового кода
В общем случае эта задача неразрешима.
Какой именно код тебе нужно выполнить один раз?
_init выполняется 1 раз при инициализации Object.
_enter_tree - 1 раз при 1 вхождении Node в дерево.
_ready - 1 раз после всех _ready всех дочерних Node.
_exit_tree - 1 раз при 1 выходе Node из дерева сцены.
_process - 1 раз при 1 итерации цикла рендеринга.
_input - 1 раз на каждое событие ввода InputEvent
И т.д. Всё это - "одноразовые участки кода".
По классам объектов следует опираться на это:
Любые потомки Node - если нужен их функционал.
Node - если нужно взаимодействие с деревом сцены.
Resource - если нужно сохранение/загрузка файлов.
RefCounted - если нужен просто какой-то код.
Object - если тебе мешает reference counter.
В целом, Godot часто создаёт одноразовые объекты:
>get_tree().create_timer()
>get_tree().create_tween()
Они удаляются после завершения работы.
Для наглядности, попробуйте следить за этим:
>Performance.get_monitor(Performance.OBJECT_COUNT)
Оно постоянно колеблется даже на простой сцене...
>>6536
В общем случае эта задача неразрешима.
Какой именно код тебе нужно выполнить один раз?
_init выполняется 1 раз при инициализации Object.
_enter_tree - 1 раз при 1 вхождении Node в дерево.
_ready - 1 раз после всех _ready всех дочерних Node.
_exit_tree - 1 раз при 1 выходе Node из дерева сцены.
_process - 1 раз при 1 итерации цикла рендеринга.
_input - 1 раз на каждое событие ввода InputEvent
И т.д. Всё это - "одноразовые участки кода".
По классам объектов следует опираться на это:
Любые потомки Node - если нужен их функционал.
Node - если нужно взаимодействие с деревом сцены.
Resource - если нужно сохранение/загрузка файлов.
RefCounted - если нужен просто какой-то код.
Object - если тебе мешает reference counter.
В целом, Godot часто создаёт одноразовые объекты:
Они удаляются после завершения работы.
Для наглядности, попробуйте следить за этим:
Оно постоянно колеблется даже на простой сцене...
>одноразового кода
В общем случае эта задача неразрешима.
Какой именно код тебе нужно выполнить один раз?
_init выполняется 1 раз при инициализации Object.
_enter_tree - 1 раз при 1 вхождении Node в дерево.
_ready - 1 раз после всех _ready всех дочерних Node.
_exit_tree - 1 раз при 1 выходе Node из дерева сцены.
_process - 1 раз при 1 итерации цикла рендеринга.
_input - 1 раз на каждое событие ввода InputEvent
И т.д. Всё это - "одноразовые участки кода".
По классам объектов следует опираться на это:
Любые потомки Node - если нужен их функционал.
Node - если нужно взаимодействие с деревом сцены.
Resource - если нужно сохранение/загрузка файлов.
RefCounted - если нужен просто какой-то код.
Object - если тебе мешает reference counter.
В целом, Godot часто создаёт одноразовые объекты:
>get_tree().create_timer()
>get_tree().create_tween()
Они удаляются после завершения работы.
Для наглядности, попробуйте следить за этим:
>Performance.get_monitor(Performance.OBJECT_COUNT)
Оно постоянно колеблется даже на простой сцене...
>>5144 (OP)
Ой девчушки мои йа не моху! А доску назвали в честь нашего любимого движка, или как?
Ой девчушки мои йа не моху! А доску назвали в честь нашего любимого движка, или как?
>>6478
Какой же ты молодец :3
Какой же ты молодец :3
Знали бы вы, как же я наебался с IK на шее персонажа. Думал, что конфликтует с анимацией, а оказалось я просто долбоеб и допустил маленькую ошибку в рассчётах угла. Хочу отметить, что в процессе я так и не понял, как оверрайдить положение кости поверх анимации. Вопрос не нужный, но интересный. Кто нибудь знает?
>>6758
Вкратце - создать потомок класса с этим методом:
https://docs.godotengine.org/en/stable/classes/class_skeletonmodifier3d.html#class-skeletonmodifier3d-private-method-process-modification-with-delta
Подробный туториал можно почитать тут:
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/#1-create-a-script
>оверрайдить положение кости поверх анимации
Вкратце - создать потомок класса с этим методом:
https://docs.godotengine.org/en/stable/classes/class_skeletonmodifier3d.html#class-skeletonmodifier3d-private-method-process-modification-with-delta
Подробный туториал можно почитать тут:
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/#1-create-a-script
>>6758
А я не ебусь с IK, работая с 3д персонажами - слишком большой таймсинк, как и лицевые анимации и прочий липсинк. Даже большие АААААА дяди с этим лажают.
А я не ебусь с IK, работая с 3д персонажами - слишком большой таймсинк, как и лицевые анимации и прочий липсинк. Даже большие АААААА дяди с этим лажают.
134 Кб, 328x279https://godotengine.org/article/dev-snapshot-godot-4-6-dev-2/
4.6 дев 2 - улучшения рендера и авто-лодов. В редакторе улучшения гизмо 3д поворотов и снап поворотов на 45 градусов при зажатом альте. Ну и еще LibGodot - годот как библиотека для доступа из стороннего кода например, из Юнити
4.6 дев 2 - улучшения рендера и авто-лодов. В редакторе улучшения гизмо 3д поворотов и снап поворотов на 45 градусов при зажатом альте. Ну и еще LibGodot - годот как библиотека для доступа из стороннего кода например, из Юнити
>>6793
Я заебался городить кастомные лоды для каждой поигрули. Если они сделают нормальные лоды - я буду очень рад. Даже перестану грезить о других движках
>улучшения рендера и авто-лодов
Я заебался городить кастомные лоды для каждой поигрули. Если они сделают нормальные лоды - я буду очень рад. Даже перестану грезить о других движках
>>6801
Потести. Найдешь баги, зарепортишь - успеют поправить к 4.6 релизу.
Потести. Найдешь баги, зарепортишь - успеют поправить к 4.6 релизу.
>>6801
Почему же ты не сделаешь до сих пор универсальный переносимый код, чтобы просто закинуть файл в новый проект и настроить?
> городить кастомные лоды для каждой поигрули
Почему же ты не сделаешь до сих пор универсальный переносимый код, чтобы просто закинуть файл в новый проект и настроить?
>>6874
Нет, не умею.
Нет, не умею.
Как же охуенно что все сцены в годоте это простые текстовые файлы. Зашел в каталог сцен, погрепал на нужное название ноды, и все сразу нашел. Да, на название, потому что в свое время я поленился делать сцену-компонент и просто накопипастил ноды.
>>6924
Я форсер толщеходов. Как необычно это слово звучит в 2025 году, хех, словно ботинки из Толщегусениц.
Соответственно, да, я выгорел прямо на стадии предпродакшена, не смог в инверсную гравитацию. Мне аноны даже пытались помочь, проекты скидывали с примерами. И я сам кучу материалов перекопал в интернетах, на тему гравитации и планетарной ходьбы. Пока я не смогу, пока не научусь, мне нет смысла двигаться дальше. Потому что весь остальной геймплей и фишки завязаны на инверсно-планетарную гравитацию.
Я форсер толщеходов. Как необычно это слово звучит в 2025 году, хех, словно ботинки из Толщегусениц.
Соответственно, да, я выгорел прямо на стадии предпродакшена, не смог в инверсную гравитацию. Мне аноны даже пытались помочь, проекты скидывали с примерами. И я сам кучу материалов перекопал в интернетах, на тему гравитации и планетарной ходьбы. Пока я не смогу, пока не научусь, мне нет смысла двигаться дальше. Потому что весь остальной геймплей и фишки завязаны на инверсно-планетарную гравитацию.
155 Кб, 1041x1041>>6973
Название красивое, но того что мне нужно, он не делает. Все эти формы задаются искаропки Area'ми. А потом он вручную делает то, что годот и так делает автоматически.
Название красивое, но того что мне нужно, он не делает. Все эти формы задаются искаропки Area'ми. А потом он вручную делает то, что годот и так делает автоматически.
1,1 Мб, mp4,608x480, 0:13
>>6973
Потыкался как слепой видрелейтед, и опять ничего не получилось. Ни с аддоном не получается. Ни без аддона. Тупо не понимаю как применять всю эту векторную математику. Мне надо чтобы контроллер персонажа вычислял направление к центру, выравнивался относительно этого направления, падал в противоположном направлении, вычислял правильный базис относительно центра, и корректно двигался вдоль базиса. Слова все знаю. Теоретически всё понимаю. На практике - хуй.
Потыкался как слепой видрелейтед, и опять ничего не получилось. Ни с аддоном не получается. Ни без аддона. Тупо не понимаю как применять всю эту векторную математику. Мне надо чтобы контроллер персонажа вычислял направление к центру, выравнивался относительно этого направления, падал в противоположном направлении, вычислял правильный базис относительно центра, и корректно двигался вдоль базиса. Слова все знаю. Теоретически всё понимаю. На практике - хуй.
>>6984
а не пробовал мир поворачивать, все кроме персонажа, при входе в арею планеты. через кватернион вокруг гг, затем скорость гг на -1
мимо
а не пробовал мир поворачивать, все кроме персонажа, при входе в арею планеты. через кватернион вокруг гг, затем скорость гг на -1
мимо
>>7034
Была такая идея, но тогда придётся отказаться от 90% фич движка.
Хотелось бы, чтобы весь мир работал на движке без моего участия. Ещё на трёшке в одном из тредов я показывал видос, где без единой строчки кода накидана планета-Area с точечной гравитацией и куча мячей-RigidBody летающих по баллистическим траекториям по ней. Без. Единой. Строчки. Кода.
Была такая идея, но тогда придётся отказаться от 90% фич движка.
Хотелось бы, чтобы весь мир работал на движке без моего участия. Ещё на трёшке в одном из тредов я показывал видос, где без единой строчки кода накидана планета-Area с точечной гравитацией и куча мячей-RigidBody летающих по баллистическим траекториям по ней. Без. Единой. Строчки. Кода.
https://godotengine.org/article/maintenance-release-godot-3-6-2/
Вместо 3.7 походу будет 3.6.7
Вместо 3.7 походу будет 3.6.7
>>7040
Плохо что ли?
Плохо что ли?
>>7040
3.7 скорее будет, там уже более значимые изменения накопились. 3.6.2 появился только из-за мозгоебства гугла с его новыми требованиями к гугл плею.
3.7 скорее будет, там уже более значимые изменения накопились. 3.6.2 появился только из-за мозгоебства гугла с его новыми требованиями к гугл плею.
Внимание, вопрос!
Игры на годоте я делать не могу, а что насчёт приложения? Если оно будет включено примерно 24 часа в сутки, будут ли утечки памяти? Насколько годот страдает от таких проблем.
Игры на годоте я делать не могу, а что насчёт приложения? Если оно будет включено примерно 24 часа в сутки, будут ли утечки памяти? Насколько годот страдает от таких проблем.
>>7060
Если у тебя куча рефкаунтсов ссылается на кучу рефкаунтсов и друг-на друга, то вся эта шушера впадёт в циклическую блокировку при выгрузке и не сможет выгрузиться. Для этого юзай weekref. В остальных случаях всё должно вполне себе работать. В четвёрке для приложух даже специальный режим ввели, в настройках. Низкопроцессорный оконный цикл.
Единственное, над чем я пока не задумывался, как отключить, но подмечал, что выполняющееся годот-приложение всё же как игра себя представляет, поэтому где-то внутри в потрохах она отключает системный скринсейвер. Для приложух это неприемлемо.
Если у тебя куча рефкаунтсов ссылается на кучу рефкаунтсов и друг-на друга, то вся эта шушера впадёт в циклическую блокировку при выгрузке и не сможет выгрузиться. Для этого юзай weekref. В остальных случаях всё должно вполне себе работать. В четвёрке для приложух даже специальный режим ввели, в настройках. Низкопроцессорный оконный цикл.
Единственное, над чем я пока не задумывался, как отключить, но подмечал, что выполняющееся годот-приложение всё же как игра себя представляет, поэтому где-то внутри в потрохах она отключает системный скринсейвер. Для приложух это неприемлемо.
>>7066
Это еще с тройки.
>>7060
Про 24 часа не знаю. Я делал приложуху с low process mode, о котором анон выше говорит, но вряд ли ее 24 часа кто-то держал. Лично я никаких подводных не встретил.
Из более популярного чем мое на годоте сделана пиксельная рисовалка:
https://github.com/Orama-Interactive/Pixelorama
Материал мейкер:
https://github.com/RodZill4/material-maker
Данжкрафт:
https://dungeondraft.net
Вондеркрафт:
https://www.wonderdraft.net
Звуковой редактор:
https://github.com/YuriSizov/boscaceoil-blue
И еще куча всего.
>В четвёрке для приложух даже специальный режим ввели, в настройках.
Это еще с тройки.
>>7060
Про 24 часа не знаю. Я делал приложуху с low process mode, о котором анон выше говорит, но вряд ли ее 24 часа кто-то держал. Лично я никаких подводных не встретил.
Из более популярного чем мое на годоте сделана пиксельная рисовалка:
https://github.com/Orama-Interactive/Pixelorama
Материал мейкер:
https://github.com/RodZill4/material-maker
Данжкрафт:
https://dungeondraft.net
Вондеркрафт:
https://www.wonderdraft.net
Звуковой редактор:
https://github.com/YuriSizov/boscaceoil-blue
И еще куча всего.
488 Кб, 1280x1280>>7069
Хех. Теперь и я захотел какую нибудь софтину сделать. Правда не знаю какую, но очень хочется.
Хех. Теперь и я захотел какую нибудь софтину сделать. Правда не знаю какую, но очень хочется.
627 Кб, 1643x966>>7069
https://github.com/mbrlabs/Lorien
Вот еще приложуху для записей нашел, типа Обсидиана. Пишут что "infinite canvas drawing/note-taking app that is focused on performance"
Что характерно - все что я накидал, все прямо на GDScript нахуячено. Это анону который тут периодически трясется про свой сисярп.
https://github.com/mbrlabs/Lorien
Вот еще приложуху для записей нашел, типа Обсидиана. Пишут что "infinite canvas drawing/note-taking app that is focused on performance"
Что характерно - все что я накидал, все прямо на GDScript нахуячено. Это анону который тут периодически трясется про свой сисярп.
>>7070
О, спасиб. Я предполагал, что это отключается где-то в настройках, но поскольку мои приложухи утилитарны (открыл, сделяль, сохранил, закрыл) то вы себе не представляете насколько мне было похуй, что они по дефолту держат систему с отключенным скренсейвером.
О, спасиб. Я предполагал, что это отключается где-то в настройках, но поскольку мои приложухи утилитарны (открыл, сделяль, сохранил, закрыл) то вы себе не представляете насколько мне было похуй, что они по дефолту держат систему с отключенным скренсейвером.
1,1 Мб, 1920x1080Еси шо, операционная система тоже есть! Годот ОС:
https://github.com/popcar2/GodotOS
https://www.youtube.com/watch?v=44LcozXequw
Но не Bare Metal, конечно же.
https://github.com/popcar2/GodotOS
https://www.youtube.com/watch?v=44LcozXequw
Но не Bare Metal, конечно же.
>>7072
Конечно трясусь, нахуй мне годот без моей любимой рефлексии и кодогенерации (и нормальной типизации)
Конечно трясусь, нахуй мне годот без моей любимой рефлексии и кодогенерации (и нормальной типизации)
407 Кб, 750x1000Тем временем ИТТ
>>7085
... для приложений, разумеется.
... для приложений, разумеется.
Карточная roguelike на Godot, ищу фидбэк.
Очень сырая демка, графики почти нет.
Готов делиться деталями реализации.
https://gamejolt.com/games/the-grim-cards-fate-archive/1026362
Очень сырая демка, графики почти нет.
Готов делиться деталями реализации.
https://gamejolt.com/games/the-grim-cards-fate-archive/1026362
>>7151
Ну, оно работает. Карточные игры не мое, поэтому по геймплею ничего сказать не могу, тем более без обучения для таких как я.
А почему на геймджолт?
Ну, оно работает. Карточные игры не мое, поэтому по геймплею ничего сказать не могу, тем более без обучения для таких как я.
А почему на геймджолт?
>>7173
На итче охваты больше. У меня на джолте игра за все время 6 лайков собрала и меньше 500 просмотров, тогда как на итче за один день в среднем 100 просмотров и 30 загрузок.
Но и там и там страничку надо оформлять полноценно.
На итче охваты больше. У меня на джолте игра за все время 6 лайков собрала и меньше 500 просмотров, тогда как на итче за один день в среднем 100 просмотров и 30 загрузок.
Но и там и там страничку надо оформлять полноценно.
>>7161
На итч позже залью, когда перевод карточек будет
На итч позже залью, когда перевод карточек будет
>>6874
Хочу, но работа забирает всё время
Хочу, но работа забирает всё время
Сап, гдач. Такой вопрос, кто-нибудь занимался портированием игры на Godot под XBOX и сыч? Насколько трудоёмким процесс?
>>7241
Учитывая что коробка это все та же винда - не думаю что там будут какие нибудь особенные сложности. А вот сыч...
Учитывая что коробка это все та же винда - не думаю что там будут какие нибудь особенные сложности. А вот сыч...
>>7241
И с сычом и с хуйбоксом основная проблема - их платные ключи разработчика и прочий онбоардинг, которые стоят дохуя.
И с сычом и с хуйбоксом основная проблема - их платные ключи разработчика и прочий онбоардинг, которые стоят дохуя.
>>7254
Понял, меня скорее техническая сторона вопроса интересует. С ключом и девкитом издатель по идее вопрос решать должен
Понял, меня скорее техническая сторона вопроса интересует. С ключом и девкитом издатель по идее вопрос решать должен
>>7259
Насколько понимаю сейчас все железо примерно похоже, на дворе уже не нулевые. Годот имеет полуофициальную платную поддержку всех консолей от W4Games и еще от парочки других сторонних компаний. Сыч там тоже присутствует. Значит все вполне реально. Годотовские игры тоже на сыче публиковались. Конкретней не скажу, сам не занимался, просто пересказал что видел.
Насколько понимаю сейчас все железо примерно похоже, на дворе уже не нулевые. Годот имеет полуофициальную платную поддержку всех консолей от W4Games и еще от парочки других сторонних компаний. Сыч там тоже присутствует. Значит все вполне реально. Годотовские игры тоже на сыче публиковались. Конкретней не скажу, сам не занимался, просто пересказал что видел.
Годаны, подкиньте годных туторов по генерации ландшафта.
Ну точнее, тут какая проблема. Обычно такие туторы сосредотачиваются на том, как всё технически организовать. Как террейну задать карту высот, вот это всё. Но полностью игнорируют, как сделать получаемый рельеф правдоподобным.
Вот ирл есть равнины, есть горы, есть плато. Равнины и плато плоские, горы кривые. Если генерировать при помощи шума, перлина там или симплексного, то получится всё одинаково неровное; и уж точно не получится плато.
А как добавить к этому всему реки - я вообще не представляю.
Вот по таким вещам не попадалось ли чего годного?
Ну точнее, тут какая проблема. Обычно такие туторы сосредотачиваются на том, как всё технически организовать. Как террейну задать карту высот, вот это всё. Но полностью игнорируют, как сделать получаемый рельеф правдоподобным.
Вот ирл есть равнины, есть горы, есть плато. Равнины и плато плоские, горы кривые. Если генерировать при помощи шума, перлина там или симплексного, то получится всё одинаково неровное; и уж точно не получится плато.
А как добавить к этому всему реки - я вообще не представляю.
Вот по таким вещам не попадалось ли чего годного?
>>7262
Спасибо, будем разбираться)
Спасибо, будем разбираться)
>>7269
Дважды хуйня. Годится для процедурной генерации плоских миров. Вообще не подходит для большого правдоподобного мира.
1. Результат получается очень однородный
2. Каждый следующий чанк привязан к предыдущему -> из одного и того же сида получатся разные миры в зависимости от порядка генерации.
Бонусом, бесит меня эта дама. Регулярно лезет в темы, в которых не шарит, а потом с восторженным видом рассказывает, как это круто!!1111
Дважды хуйня. Годится для процедурной генерации плоских миров. Вообще не подходит для большого правдоподобного мира.
1. Результат получается очень однородный
2. Каждый следующий чанк привязан к предыдущему -> из одного и того же сида получатся разные миры в зависимости от порядка генерации.
Бонусом, бесит меня эта дама. Регулярно лезет в темы, в которых не шарит, а потом с восторженным видом рассказывает, как это круто!!1111
>>7272
Значит в какой-то момент генерации у тебя порядок задаётся сторонним генератором, сид и степ которого ты не контролируешь.
> из одного и того же сида получатся разные миры в зависимости от порядка генерации
Значит в какой-то момент генерации у тебя порядок задаётся сторонним генератором, сид и степ которого ты не контролируешь.
>>7276
Было былобылобыло, но прошло. О о о.
Было былобылобыло, но прошло. О о о.
>>7268
Это очень сложная тема - иди учи ИРЛ географию...
Включи фантазию, лол. И возьми НАБОР шумов.
Допустим, есть три разных шума:
Чтобы сделать горы, можно просто:
Чтобы добавить шероховатости:
А чёткие плоскости можно как-то так:
Конкретные числа подбирай по вкусу.
Результат зависит от roughness_factor:
От 0.0 до 0.2: ровные плоскости.
От 0.2 до 0.5: гладкие горы и холмы.
От 0.5 до 1.0: шершавые горы и равнины.
В процедурных мирах два типа рек:
1. Грубая аппроксимация, как в Minecraft.
2. Точная, дорогая симуляция течений.
Для аппроксимации, можно:
1. FRACTAL_RIDGED или FRACTAL_PING_PONG.
2. Далее, у тебя такие варианты:
а) Реки-кольца на одном уровне (Minecraft).
б) Вдавливать их по высоте (т.е. heightmap).
в) Учитывать карты температуры, влажности...
Много разного можно придумать.
Симулирование рек может быть таким:
1. Выбираешь случайную точку на горе.
2. Двигаешь в сторону меньшей высоты.
3. Заканчиваешь, если:
- некуда спуститься (озеро);
- дошёл до уровня океана;
- пересёк другую реку.
4. Вдавливаешь ландшафт по пути движения.
Вот как-то так и всё остальное делается:
- биомы (высота, температура, влажность);
- ветренность (шум даёт направление ветра);
- расположение поселений и тому подобного.
>>7269
Для реалистичного ландшафта он не подходит.
Он больше для всяких подземелий, замков и т.п.
>>7272
Нет, тот алгоритм работает в любом измерении.
Карты шума (Перлина и т.п.) тоже однородные.
Этот вопрос решается иерархической генерацией:
1. Сначала генерируется огромная карта "зёрен".
2. Потом они дробятся на гигантские чанки.
3. Пункт 2 повторяется до нужного разрешения.
4. Детализируется конкретный ландшафт.
Это понадобится любому генератору...
Рекомендую ещё глянуть клеточные автоматы:
https://en.wikipedia.org/wiki/Cellular_automaton
Ими можно многие процессы симулировать:
- движение рек, особенно через разную почву;
- распространение или уничтожение лесов;
- миграцию животных и т.п.
Естественно, чем мельче ячейки - тем лучше.
>как сделать получаемый рельеф правдоподобным
Это очень сложная тема - иди учи ИРЛ географию...
>Равнины и плато плоские, горы кривые.
>Если генерировать... получится всё одинаково
Включи фантазию, лол. И возьми НАБОР шумов.
Допустим, есть три разных шума:
>var heightmap: Noise
>var roughness: Noise
>var roughness_factor: Noise
Чтобы сделать горы, можно просто:
>var height := heightmap.get_noise_2d(x, y)
Чтобы добавить шероховатости:
>if roughness_factor.get_noise_2d(x, y) > 0.5:
>_ height += roughness.get_noise_2d(x, y)
А чёткие плоскости можно как-то так:
>elif roughness_factor.get_noise_2d(x, y) < 0.2:
>_ height = snappedf(height, 0.1)
Конкретные числа подбирай по вкусу.
Результат зависит от roughness_factor:
От 0.0 до 0.2: ровные плоскости.
От 0.2 до 0.5: гладкие горы и холмы.
От 0.5 до 1.0: шершавые горы и равнины.
>А как добавить к этому всему реки
В процедурных мирах два типа рек:
1. Грубая аппроксимация, как в Minecraft.
2. Точная, дорогая симуляция течений.
Для аппроксимации, можно:
1. FRACTAL_RIDGED или FRACTAL_PING_PONG.
2. Далее, у тебя такие варианты:
а) Реки-кольца на одном уровне (Minecraft).
б) Вдавливать их по высоте (т.е. heightmap).
в) Учитывать карты температуры, влажности...
Много разного можно придумать.
Симулирование рек может быть таким:
1. Выбираешь случайную точку на горе.
2. Двигаешь в сторону меньшей высоты.
3. Заканчиваешь, если:
- некуда спуститься (озеро);
- дошёл до уровня океана;
- пересёк другую реку.
4. Вдавливаешь ландшафт по пути движения.
Вот как-то так и всё остальное делается:
- биомы (высота, температура, влажность);
- ветренность (шум даёт направление ветра);
- расположение поселений и тому подобного.
>>7269
>wave function collapse
Для реалистичного ландшафта он не подходит.
Он больше для всяких подземелий, замков и т.п.
>>7272
>плоских миров
Нет, тот алгоритм работает в любом измерении.
>получается очень однородный
Карты шума (Перлина и т.п.) тоже однородные.
>в зависимости от порядка генерации
Этот вопрос решается иерархической генерацией:
1. Сначала генерируется огромная карта "зёрен".
2. Потом они дробятся на гигантские чанки.
3. Пункт 2 повторяется до нужного разрешения.
4. Детализируется конкретный ландшафт.
Это понадобится любому генератору...
Рекомендую ещё глянуть клеточные автоматы:
https://en.wikipedia.org/wiki/Cellular_automaton
Ими можно многие процессы симулировать:
- движение рек, особенно через разную почву;
- распространение или уничтожение лесов;
- миграцию животных и т.п.
Естественно, чем мельче ячейки - тем лучше.
>>7268
Это очень сложная тема - иди учи ИРЛ географию...
Включи фантазию, лол. И возьми НАБОР шумов.
Допустим, есть три разных шума:
Чтобы сделать горы, можно просто:
Чтобы добавить шероховатости:
А чёткие плоскости можно как-то так:
Конкретные числа подбирай по вкусу.
Результат зависит от roughness_factor:
От 0.0 до 0.2: ровные плоскости.
От 0.2 до 0.5: гладкие горы и холмы.
От 0.5 до 1.0: шершавые горы и равнины.
В процедурных мирах два типа рек:
1. Грубая аппроксимация, как в Minecraft.
2. Точная, дорогая симуляция течений.
Для аппроксимации, можно:
1. FRACTAL_RIDGED или FRACTAL_PING_PONG.
2. Далее, у тебя такие варианты:
а) Реки-кольца на одном уровне (Minecraft).
б) Вдавливать их по высоте (т.е. heightmap).
в) Учитывать карты температуры, влажности...
Много разного можно придумать.
Симулирование рек может быть таким:
1. Выбираешь случайную точку на горе.
2. Двигаешь в сторону меньшей высоты.
3. Заканчиваешь, если:
- некуда спуститься (озеро);
- дошёл до уровня океана;
- пересёк другую реку.
4. Вдавливаешь ландшафт по пути движения.
Вот как-то так и всё остальное делается:
- биомы (высота, температура, влажность);
- ветренность (шум даёт направление ветра);
- расположение поселений и тому подобного.
>>7269
Для реалистичного ландшафта он не подходит.
Он больше для всяких подземелий, замков и т.п.
>>7272
Нет, тот алгоритм работает в любом измерении.
Карты шума (Перлина и т.п.) тоже однородные.
Этот вопрос решается иерархической генерацией:
1. Сначала генерируется огромная карта "зёрен".
2. Потом они дробятся на гигантские чанки.
3. Пункт 2 повторяется до нужного разрешения.
4. Детализируется конкретный ландшафт.
Это понадобится любому генератору...
Рекомендую ещё глянуть клеточные автоматы:
https://en.wikipedia.org/wiki/Cellular_automaton
Ими можно многие процессы симулировать:
- движение рек, особенно через разную почву;
- распространение или уничтожение лесов;
- миграцию животных и т.п.
Естественно, чем мельче ячейки - тем лучше.
>как сделать получаемый рельеф правдоподобным
Это очень сложная тема - иди учи ИРЛ географию...
>Равнины и плато плоские, горы кривые.
>Если генерировать... получится всё одинаково
Включи фантазию, лол. И возьми НАБОР шумов.
Допустим, есть три разных шума:
>var heightmap: Noise
>var roughness: Noise
>var roughness_factor: Noise
Чтобы сделать горы, можно просто:
>var height := heightmap.get_noise_2d(x, y)
Чтобы добавить шероховатости:
>if roughness_factor.get_noise_2d(x, y) > 0.5:
>_ height += roughness.get_noise_2d(x, y)
А чёткие плоскости можно как-то так:
>elif roughness_factor.get_noise_2d(x, y) < 0.2:
>_ height = snappedf(height, 0.1)
Конкретные числа подбирай по вкусу.
Результат зависит от roughness_factor:
От 0.0 до 0.2: ровные плоскости.
От 0.2 до 0.5: гладкие горы и холмы.
От 0.5 до 1.0: шершавые горы и равнины.
>А как добавить к этому всему реки
В процедурных мирах два типа рек:
1. Грубая аппроксимация, как в Minecraft.
2. Точная, дорогая симуляция течений.
Для аппроксимации, можно:
1. FRACTAL_RIDGED или FRACTAL_PING_PONG.
2. Далее, у тебя такие варианты:
а) Реки-кольца на одном уровне (Minecraft).
б) Вдавливать их по высоте (т.е. heightmap).
в) Учитывать карты температуры, влажности...
Много разного можно придумать.
Симулирование рек может быть таким:
1. Выбираешь случайную точку на горе.
2. Двигаешь в сторону меньшей высоты.
3. Заканчиваешь, если:
- некуда спуститься (озеро);
- дошёл до уровня океана;
- пересёк другую реку.
4. Вдавливаешь ландшафт по пути движения.
Вот как-то так и всё остальное делается:
- биомы (высота, температура, влажность);
- ветренность (шум даёт направление ветра);
- расположение поселений и тому подобного.
>>7269
>wave function collapse
Для реалистичного ландшафта он не подходит.
Он больше для всяких подземелий, замков и т.п.
>>7272
>плоских миров
Нет, тот алгоритм работает в любом измерении.
>получается очень однородный
Карты шума (Перлина и т.п.) тоже однородные.
>в зависимости от порядка генерации
Этот вопрос решается иерархической генерацией:
1. Сначала генерируется огромная карта "зёрен".
2. Потом они дробятся на гигантские чанки.
3. Пункт 2 повторяется до нужного разрешения.
4. Детализируется конкретный ландшафт.
Это понадобится любому генератору...
Рекомендую ещё глянуть клеточные автоматы:
https://en.wikipedia.org/wiki/Cellular_automaton
Ими можно многие процессы симулировать:
- движение рек, особенно через разную почву;
- распространение или уничтожение лесов;
- миграцию животных и т.п.
Естественно, чем мельче ячейки - тем лучше.
337 Кб, 720x1612Поясните мимокроку, насколько сложно на этом движке запилить свой пиксель данжн с блэкджеком и шлюхами?
>>7324
Твой пиксель данжн опенсорсный, бери и переписывай один в один: https://github.com/00-Evan/shattered-pixel-dungeon
Ассеты готовые с итча возьмешь. Суммарно примерно изи.
Твой пиксель данжн опенсорсный, бери и переписывай один в один: https://github.com/00-Evan/shattered-pixel-dungeon
Ассеты готовые с итча возьмешь. Суммарно примерно изи.
>>7304
Сенкс бро, ясно и по делу.
Вообще, я надеялся найти не то чтобы тутор, а скорее что-то типа девлога вида "вот так я сделал, получилось прикольно". А ты по большей части повторил мои соображения.
Пока что я рпобую сделать так:
- Шум первый: "грубая" карта высот, низкого разрешения, задаёт среднюю высоту над уровнем моря для большой области
- Шум второй: карта "холмистости", тоже низкого разрешения
- Шум третий: "локальная" карта высот высокого разрешения
Получается так: к "грубой" карте прибавляется "локальная" карта, умноженная на карту "холмистости". Причём параметры шумов, соответственно, разные: "грубая" это однооктавный симплекс низкой частоты, "локальная" - зернистый 5-октавный simplex smooth, а "холмистость" - клеточный шум без фрактала, но с искажением.
Если получится победить текстуры (с нормалями оказалась загвоздка, слишком сложно генерировать их в шейдере, придётся в скрипте, а это возня), то покажу результат.
Сенкс бро, ясно и по делу.
Вообще, я надеялся найти не то чтобы тутор, а скорее что-то типа девлога вида "вот так я сделал, получилось прикольно". А ты по большей части повторил мои соображения.
Пока что я рпобую сделать так:
- Шум первый: "грубая" карта высот, низкого разрешения, задаёт среднюю высоту над уровнем моря для большой области
- Шум второй: карта "холмистости", тоже низкого разрешения
- Шум третий: "локальная" карта высот высокого разрешения
Получается так: к "грубой" карте прибавляется "локальная" карта, умноженная на карту "холмистости". Причём параметры шумов, соответственно, разные: "грубая" это однооктавный симплекс низкой частоты, "локальная" - зернистый 5-октавный simplex smooth, а "холмистость" - клеточный шум без фрактала, но с искажением.
Если получится победить текстуры (с нормалями оказалась загвоздка, слишком сложно генерировать их в шейдере, придётся в скрипте, а это возня), то покажу результат.
3,7 Мб, 1920x1080>>7339
Ну и недо не забывать, что натуральный ландшафт состоит из ветровой эррозии, тектонических смещений, осадочных наносов, а потом ещё эрозии поверх этого, а потом на уровне будущей высоты моря сделать прибрежную эррозию. Алгоритмы для всего этого добра есть в гугле.
Ну и недо не забывать, что натуральный ландшафт состоит из ветровой эррозии, тектонических смещений, осадочных наносов, а потом ещё эрозии поверх этого, а потом на уровне будущей высоты моря сделать прибрежную эррозию. Алгоритмы для всего этого добра есть в гугле.
>>7324
невъебически сложно. потому что уже делаю около 5-ти месяцев. ахуел с того насколько тяжело сделать генератор уровней (делал около месяца), а потом ахуел с того как тяжело сделать нормально работающие сохранения которые НЕ теряют по пути уровень, объекты, врагов, предметы и т.д.
невъебически сложно. потому что уже делаю около 5-ти месяцев. ахуел с того насколько тяжело сделать генератор уровней (делал около месяца), а потом ахуел с того как тяжело сделать нормально работающие сохранения которые НЕ теряют по пути уровень, объекты, врагов, предметы и т.д.
>>7353
хотя опять таки, смотря для чего. если для себя, то тебе ничего не мешает реально спиздить код и ассеты с итча и сделать всё за неделю, но условно заработать на этом ты не сможешь просто потому что кому нахуй нужен полный клон PD с ретекстуром?
а если как раз таки пытаться сделать КАК в PD, но делать это самому чтобы в процессе появилась идентичность хоть какая-то, вот в этом случае всё сводится к первому сообщению, потому что как я понял ты не годот-синьор и близко
хотя опять таки, смотря для чего. если для себя, то тебе ничего не мешает реально спиздить код и ассеты с итча и сделать всё за неделю, но условно заработать на этом ты не сможешь просто потому что кому нахуй нужен полный клон PD с ретекстуром?
а если как раз таки пытаться сделать КАК в PD, но делать это самому чтобы в процессе появилась идентичность хоть какая-то, вот в этом случае всё сводится к первому сообщению, потому что как я понял ты не годот-синьор и близко
>>7348
Если игра с такой графикой не обладает разрушаемостью - нахуй она такая нужна когда есть майнкрафт
Если игра с такой графикой не обладает разрушаемостью - нахуй она такая нужна когда есть майнкрафт
>>7359
Он вроде аналог Вора делает, нахуй ему разрушаемость
Он вроде аналог Вора делает, нахуй ему разрушаемость
>>7350
Ну да, всё это важно и нужно, но не сейчас пока что.
Я хочу сделать генератор мира, концептуально как в Дварф Фортресс (но не настолько заморочисто). Для начала создам базовую форму, а потом просимулирую геологические процессы; не очень долго, пару десятков тысяч лет, и не очень точно. Потом туда придут цивилизации и всё засрут, устроят атомную войну, глобальное оледенение, засуху и ещё парочку каких-нибудь катаклизмов. А потом придёт игрок и будет изучать, что тут произошло и почему все сдохли.
Я, правда, не думаю, что вообще доберусь до стадии геймплея. Скорее просто пробую свои силы в генерации мира и повышаю свой уровень навыков.
>натуральный ландшафт состоит из
Ну да, всё это важно и нужно, но не сейчас пока что.
Я хочу сделать генератор мира, концептуально как в Дварф Фортресс (но не настолько заморочисто). Для начала создам базовую форму, а потом просимулирую геологические процессы; не очень долго, пару десятков тысяч лет, и не очень точно. Потом туда придут цивилизации и всё засрут, устроят атомную войну, глобальное оледенение, засуху и ещё парочку каких-нибудь катаклизмов. А потом придёт игрок и будет изучать, что тут произошло и почему все сдохли.
Я, правда, не думаю, что вообще доберусь до стадии геймплея. Скорее просто пробую свои силы в генерации мира и повышаю свой уровень навыков.
>>7369
Фан заканчивается через две недели в среднем, за это время ты ничего путного сделать не успеешь. Я это говорю не как чел который пару строчек кода написал, а макак с 10 летним стажем
Фан заканчивается через две недели в среднем, за это время ты ничего путного сделать не успеешь. Я это говорю не как чел который пару строчек кода написал, а макак с 10 летним стажем
>>7403
В оригинальных червяках (которые 2D) сделано через битовую маску текстуры уровня или что-то в этом роде. Очень давно об этом читал. Вкратце, у тебя есть гигантская текстура, изображающая весь ландшафт одного уровня со всеми деталями, и есть чёрно-белая маска, где белый пиксель - твёрдая почва, чёрный пиксель - пустота (или наоборот). Взрывы и выстрелы переключают цвет пикселей на маске, и это вызывает исчезновение кусков текстуры ландшафта на экране (скрытие). Физически червяки проверяют столкновение по пикселям этой маски, если я правильно понимаю.
Плюсы этого подхода:
- можно нарисовать что пожелаешь на текстуре уровня;
- можно делать большие взрывы простым bitblt или шейдером;
- края взрывов могут быть как круглыми, так и неровными.
Минусов, имхо, больше:
- красивую карту рисовать сложно, а тайлы не будут сочетаться;
- сложно добавить свойства почвы наподобие сыпучего песка;
- объекты легко застревают даже на единственном пикселе;
- большая карта = высокая требовательность к процессору.
Вроде возможно убрать весь код в compute шейдеры, но я не знаю, как. GDScript'ом будет очень неэффективно, поэтому лучше сразу рассматривай компилируемые языки. Самое примитивное и медленное решение можно сделать за один вечер на GDScript, но если делать такую игру всерьёз, там наверняка куча подводных камней.
Если твоя игра - это не прямой клон "червяков" или подобных им игр, то лучше задумайся, нужна ли тебе настолько точная (пиксельная) разрушаемость и физика в твоей игре. Вот в Terraria грубая тайловая физика, но это не помешало ей стать лучшей инди-игрой. А Noita несмотря на физическую симуляцию всего мира из отдельных пикселей (на видеокарте, как я понимаю) не собрала даже 10% отзывов Terraria в Steam - так что физика не главное.
Если всё же будешь делать клон "червяков", то рекомендую заранее делать стресс-тесты, то есть нагружать своё решение до неиграбельных просадок FPS, чтобы заранее знать лимит или заранее обнаружить узкое место в реализации. Одна реализация может быть хороша на маленькой карте, но совершенно неиграбельна на большой...
Кстати, в серии Worms была как минимум одна 3D игра, и разрушаемость там была почти как в Minecraft - по кубикам. Во всяком случае так мне она запомнилась - играл давно... В 3D можно сглаживать воксели, и для этого существуют готовые решения, в том числе на Godot, но у этого подхода свои ограничения на стиль графики и точность физики...
>как в червяках
В оригинальных червяках (которые 2D) сделано через битовую маску текстуры уровня или что-то в этом роде. Очень давно об этом читал. Вкратце, у тебя есть гигантская текстура, изображающая весь ландшафт одного уровня со всеми деталями, и есть чёрно-белая маска, где белый пиксель - твёрдая почва, чёрный пиксель - пустота (или наоборот). Взрывы и выстрелы переключают цвет пикселей на маске, и это вызывает исчезновение кусков текстуры ландшафта на экране (скрытие). Физически червяки проверяют столкновение по пикселям этой маски, если я правильно понимаю.
Плюсы этого подхода:
- можно нарисовать что пожелаешь на текстуре уровня;
- можно делать большие взрывы простым bitblt или шейдером;
- края взрывов могут быть как круглыми, так и неровными.
Минусов, имхо, больше:
- красивую карту рисовать сложно, а тайлы не будут сочетаться;
- сложно добавить свойства почвы наподобие сыпучего песка;
- объекты легко застревают даже на единственном пикселе;
- большая карта = высокая требовательность к процессору.
Вроде возможно убрать весь код в compute шейдеры, но я не знаю, как. GDScript'ом будет очень неэффективно, поэтому лучше сразу рассматривай компилируемые языки. Самое примитивное и медленное решение можно сделать за один вечер на GDScript, но если делать такую игру всерьёз, там наверняка куча подводных камней.
Если твоя игра - это не прямой клон "червяков" или подобных им игр, то лучше задумайся, нужна ли тебе настолько точная (пиксельная) разрушаемость и физика в твоей игре. Вот в Terraria грубая тайловая физика, но это не помешало ей стать лучшей инди-игрой. А Noita несмотря на физическую симуляцию всего мира из отдельных пикселей (на видеокарте, как я понимаю) не собрала даже 10% отзывов Terraria в Steam - так что физика не главное.
Если всё же будешь делать клон "червяков", то рекомендую заранее делать стресс-тесты, то есть нагружать своё решение до неиграбельных просадок FPS, чтобы заранее знать лимит или заранее обнаружить узкое место в реализации. Одна реализация может быть хороша на маленькой карте, но совершенно неиграбельна на большой...
Кстати, в серии Worms была как минимум одна 3D игра, и разрушаемость там была почти как в Minecraft - по кубикам. Во всяком случае так мне она запомнилась - играл давно... В 3D можно сглаживать воксели, и для этого существуют готовые решения, в том числе на Godot, но у этого подхода свои ограничения на стиль графики и точность физики...
>>7403
В оригинальных червяках (которые 2D) сделано через битовую маску текстуры уровня или что-то в этом роде. Очень давно об этом читал. Вкратце, у тебя есть гигантская текстура, изображающая весь ландшафт одного уровня со всеми деталями, и есть чёрно-белая маска, где белый пиксель - твёрдая почва, чёрный пиксель - пустота (или наоборот). Взрывы и выстрелы переключают цвет пикселей на маске, и это вызывает исчезновение кусков текстуры ландшафта на экране (скрытие). Физически червяки проверяют столкновение по пикселям этой маски, если я правильно понимаю.
Плюсы этого подхода:
- можно нарисовать что пожелаешь на текстуре уровня;
- можно делать большие взрывы простым bitblt или шейдером;
- края взрывов могут быть как круглыми, так и неровными.
Минусов, имхо, больше:
- красивую карту рисовать сложно, а тайлы не будут сочетаться;
- сложно добавить свойства почвы наподобие сыпучего песка;
- объекты легко застревают даже на единственном пикселе;
- большая карта = высокая требовательность к процессору.
Вроде возможно убрать весь код в compute шейдеры, но я не знаю, как. GDScript'ом будет очень неэффективно, поэтому лучше сразу рассматривай компилируемые языки. Самое примитивное и медленное решение можно сделать за один вечер на GDScript, но если делать такую игру всерьёз, там наверняка куча подводных камней.
Если твоя игра - это не прямой клон "червяков" или подобных им игр, то лучше задумайся, нужна ли тебе настолько точная (пиксельная) разрушаемость и физика в твоей игре. Вот в Terraria грубая тайловая физика, но это не помешало ей стать лучшей инди-игрой. А Noita несмотря на физическую симуляцию всего мира из отдельных пикселей (на видеокарте, как я понимаю) не собрала даже 10% отзывов Terraria в Steam - так что физика не главное.
Если всё же будешь делать клон "червяков", то рекомендую заранее делать стресс-тесты, то есть нагружать своё решение до неиграбельных просадок FPS, чтобы заранее знать лимит или заранее обнаружить узкое место в реализации. Одна реализация может быть хороша на маленькой карте, но совершенно неиграбельна на большой...
Кстати, в серии Worms была как минимум одна 3D игра, и разрушаемость там была почти как в Minecraft - по кубикам. Во всяком случае так мне она запомнилась - играл давно... В 3D можно сглаживать воксели, и для этого существуют готовые решения, в том числе на Godot, но у этого подхода свои ограничения на стиль графики и точность физики...
>как в червяках
В оригинальных червяках (которые 2D) сделано через битовую маску текстуры уровня или что-то в этом роде. Очень давно об этом читал. Вкратце, у тебя есть гигантская текстура, изображающая весь ландшафт одного уровня со всеми деталями, и есть чёрно-белая маска, где белый пиксель - твёрдая почва, чёрный пиксель - пустота (или наоборот). Взрывы и выстрелы переключают цвет пикселей на маске, и это вызывает исчезновение кусков текстуры ландшафта на экране (скрытие). Физически червяки проверяют столкновение по пикселям этой маски, если я правильно понимаю.
Плюсы этого подхода:
- можно нарисовать что пожелаешь на текстуре уровня;
- можно делать большие взрывы простым bitblt или шейдером;
- края взрывов могут быть как круглыми, так и неровными.
Минусов, имхо, больше:
- красивую карту рисовать сложно, а тайлы не будут сочетаться;
- сложно добавить свойства почвы наподобие сыпучего песка;
- объекты легко застревают даже на единственном пикселе;
- большая карта = высокая требовательность к процессору.
Вроде возможно убрать весь код в compute шейдеры, но я не знаю, как. GDScript'ом будет очень неэффективно, поэтому лучше сразу рассматривай компилируемые языки. Самое примитивное и медленное решение можно сделать за один вечер на GDScript, но если делать такую игру всерьёз, там наверняка куча подводных камней.
Если твоя игра - это не прямой клон "червяков" или подобных им игр, то лучше задумайся, нужна ли тебе настолько точная (пиксельная) разрушаемость и физика в твоей игре. Вот в Terraria грубая тайловая физика, но это не помешало ей стать лучшей инди-игрой. А Noita несмотря на физическую симуляцию всего мира из отдельных пикселей (на видеокарте, как я понимаю) не собрала даже 10% отзывов Terraria в Steam - так что физика не главное.
Если всё же будешь делать клон "червяков", то рекомендую заранее делать стресс-тесты, то есть нагружать своё решение до неиграбельных просадок FPS, чтобы заранее знать лимит или заранее обнаружить узкое место в реализации. Одна реализация может быть хороша на маленькой карте, но совершенно неиграбельна на большой...
Кстати, в серии Worms была как минимум одна 3D игра, и разрушаемость там была почти как в Minecraft - по кубикам. Во всяком случае так мне она запомнилась - играл давно... В 3D можно сглаживать воксели, и для этого существуют готовые решения, в том числе на Godot, но у этого подхода свои ограничения на стиль графики и точность физики...
>>7412
Ага, да, на видеокарте. нет, это самый процессоротребовательный высер в мире, я даже чет подозреваю что там даже avx не применяется
>на видеокарте, как я понимаю
Ага, да, на видеокарте. нет, это самый процессоротребовательный высер в мире, я даже чет подозреваю что там даже avx не применяется
>>7339
Для базовой генерации ландшафта тебе вообще не нужно генерировать текстуру какого-либо разрешения. В Godot "NoiseTexture2D" - это лишь контейнер/рендерер для Noise. А запрашивать из Noise ты можешь любую точку, хоть за сто тысяч километров от центра (0, 0, 0), в любой момент, в любом измерении (1D, 2D, 3D). Хотя NoiseTexture2D удобен в качестве превью в редакторе...
Ты сразу 3D меш пытаешься генерировать и текстуры на него натягивать?
Рекомендую для начала ограничиться 2D картой одним из способов:
- В Control или Node2D в обработчике _draw() можно рисовать квадратики и т.п.
- Стопка из TextureRect с NoiseTexture2D, если логика смешивания несложная.
- Через шейдер, выводящий плоскую картинку на Control или Node2D.
Так будет проще анализировать и отлаживать базовую генерацию.
А 3D можно генерировать по-разному, например, можно взять PlaneMesh.
Новые нормали можно сгенерировать через SurfaceTool.generate_normals().
Ну или используй любой из доступных плагинов типа Terrain3D, их несколько...
>>7363
Тогда текстуры и нормали должны быть в самом конце списка проблем.
Ещё раз рекомендую присмотреться к клеточным автоматам - они как раз неплохо приближаются к симуляции реальной жизни в большом масштабе. Кажется, их даже биологи для каких-то там своих научных симуляций использовали. Noise даст тебе начальные значения, которые ты затем как-то преобразуешь и потом как-то выводишь на экран - повторюсь, для начала лучше чисто 2D карта, с 3D замучаешься искать проблемы. Высоту в 2D можно отображать яркостью пикселя: чёрный - максимальная глубина, белый - максимальная высота. Поскольку ты хочешь симуляцию целого мира, то лучше сразу задуматься о "биомах" - разных экологических зонах с характерными свойствами. Шершавость гор и гладкость холмов оставь на потом, потому что это практически не влияет на результат.
Генерировать процедурные миры очень интересно. На Reddit есть даже крупные сабреддиты про это, и существовало несколько веб-сайтов/форумов чисто про процедурную генерацию... Ещё до того, как эта тема была популяризирована Minecraft и другими играми. А Godot хоть и позиционируется как игровой движок, по сути универсальный инструмент для любого графического приложения. Главное, чтоб тебе самому нравилось, что ты там делаешь...
>Шум первый: "грубая" карта высот, низкого разрешения
Для базовой генерации ландшафта тебе вообще не нужно генерировать текстуру какого-либо разрешения. В Godot "NoiseTexture2D" - это лишь контейнер/рендерер для Noise. А запрашивать из Noise ты можешь любую точку, хоть за сто тысяч километров от центра (0, 0, 0), в любой момент, в любом измерении (1D, 2D, 3D). Хотя NoiseTexture2D удобен в качестве превью в редакторе...
>Если получится победить текстуры (с нормалями оказалась загвоздка
Ты сразу 3D меш пытаешься генерировать и текстуры на него натягивать?
Рекомендую для начала ограничиться 2D картой одним из способов:
- В Control или Node2D в обработчике _draw() можно рисовать квадратики и т.п.
- Стопка из TextureRect с NoiseTexture2D, если логика смешивания несложная.
- Через шейдер, выводящий плоскую картинку на Control или Node2D.
Так будет проще анализировать и отлаживать базовую генерацию.
А 3D можно генерировать по-разному, например, можно взять PlaneMesh.
Новые нормали можно сгенерировать через SurfaceTool.generate_normals().
Ну или используй любой из доступных плагинов типа Terrain3D, их несколько...
>>7363
>просимулирую геологические процессы
>Потом туда придут цивилизации
Тогда текстуры и нормали должны быть в самом конце списка проблем.
Ещё раз рекомендую присмотреться к клеточным автоматам - они как раз неплохо приближаются к симуляции реальной жизни в большом масштабе. Кажется, их даже биологи для каких-то там своих научных симуляций использовали. Noise даст тебе начальные значения, которые ты затем как-то преобразуешь и потом как-то выводишь на экран - повторюсь, для начала лучше чисто 2D карта, с 3D замучаешься искать проблемы. Высоту в 2D можно отображать яркостью пикселя: чёрный - максимальная глубина, белый - максимальная высота. Поскольку ты хочешь симуляцию целого мира, то лучше сразу задуматься о "биомах" - разных экологических зонах с характерными свойствами. Шершавость гор и гладкость холмов оставь на потом, потому что это практически не влияет на результат.
>не думаю, что вообще доберусь до стадии геймплея
Генерировать процедурные миры очень интересно. На Reddit есть даже крупные сабреддиты про это, и существовало несколько веб-сайтов/форумов чисто про процедурную генерацию... Ещё до того, как эта тема была популяризирована Minecraft и другими играми. А Godot хоть и позиционируется как игровой движок, по сути универсальный инструмент для любого графического приложения. Главное, чтоб тебе самому нравилось, что ты там делаешь...
>>7339
Для базовой генерации ландшафта тебе вообще не нужно генерировать текстуру какого-либо разрешения. В Godot "NoiseTexture2D" - это лишь контейнер/рендерер для Noise. А запрашивать из Noise ты можешь любую точку, хоть за сто тысяч километров от центра (0, 0, 0), в любой момент, в любом измерении (1D, 2D, 3D). Хотя NoiseTexture2D удобен в качестве превью в редакторе...
Ты сразу 3D меш пытаешься генерировать и текстуры на него натягивать?
Рекомендую для начала ограничиться 2D картой одним из способов:
- В Control или Node2D в обработчике _draw() можно рисовать квадратики и т.п.
- Стопка из TextureRect с NoiseTexture2D, если логика смешивания несложная.
- Через шейдер, выводящий плоскую картинку на Control или Node2D.
Так будет проще анализировать и отлаживать базовую генерацию.
А 3D можно генерировать по-разному, например, можно взять PlaneMesh.
Новые нормали можно сгенерировать через SurfaceTool.generate_normals().
Ну или используй любой из доступных плагинов типа Terrain3D, их несколько...
>>7363
Тогда текстуры и нормали должны быть в самом конце списка проблем.
Ещё раз рекомендую присмотреться к клеточным автоматам - они как раз неплохо приближаются к симуляции реальной жизни в большом масштабе. Кажется, их даже биологи для каких-то там своих научных симуляций использовали. Noise даст тебе начальные значения, которые ты затем как-то преобразуешь и потом как-то выводишь на экран - повторюсь, для начала лучше чисто 2D карта, с 3D замучаешься искать проблемы. Высоту в 2D можно отображать яркостью пикселя: чёрный - максимальная глубина, белый - максимальная высота. Поскольку ты хочешь симуляцию целого мира, то лучше сразу задуматься о "биомах" - разных экологических зонах с характерными свойствами. Шершавость гор и гладкость холмов оставь на потом, потому что это практически не влияет на результат.
Генерировать процедурные миры очень интересно. На Reddit есть даже крупные сабреддиты про это, и существовало несколько веб-сайтов/форумов чисто про процедурную генерацию... Ещё до того, как эта тема была популяризирована Minecraft и другими играми. А Godot хоть и позиционируется как игровой движок, по сути универсальный инструмент для любого графического приложения. Главное, чтоб тебе самому нравилось, что ты там делаешь...
>Шум первый: "грубая" карта высот, низкого разрешения
Для базовой генерации ландшафта тебе вообще не нужно генерировать текстуру какого-либо разрешения. В Godot "NoiseTexture2D" - это лишь контейнер/рендерер для Noise. А запрашивать из Noise ты можешь любую точку, хоть за сто тысяч километров от центра (0, 0, 0), в любой момент, в любом измерении (1D, 2D, 3D). Хотя NoiseTexture2D удобен в качестве превью в редакторе...
>Если получится победить текстуры (с нормалями оказалась загвоздка
Ты сразу 3D меш пытаешься генерировать и текстуры на него натягивать?
Рекомендую для начала ограничиться 2D картой одним из способов:
- В Control или Node2D в обработчике _draw() можно рисовать квадратики и т.п.
- Стопка из TextureRect с NoiseTexture2D, если логика смешивания несложная.
- Через шейдер, выводящий плоскую картинку на Control или Node2D.
Так будет проще анализировать и отлаживать базовую генерацию.
А 3D можно генерировать по-разному, например, можно взять PlaneMesh.
Новые нормали можно сгенерировать через SurfaceTool.generate_normals().
Ну или используй любой из доступных плагинов типа Terrain3D, их несколько...
>>7363
>просимулирую геологические процессы
>Потом туда придут цивилизации
Тогда текстуры и нормали должны быть в самом конце списка проблем.
Ещё раз рекомендую присмотреться к клеточным автоматам - они как раз неплохо приближаются к симуляции реальной жизни в большом масштабе. Кажется, их даже биологи для каких-то там своих научных симуляций использовали. Noise даст тебе начальные значения, которые ты затем как-то преобразуешь и потом как-то выводишь на экран - повторюсь, для начала лучше чисто 2D карта, с 3D замучаешься искать проблемы. Высоту в 2D можно отображать яркостью пикселя: чёрный - максимальная глубина, белый - максимальная высота. Поскольку ты хочешь симуляцию целого мира, то лучше сразу задуматься о "биомах" - разных экологических зонах с характерными свойствами. Шершавость гор и гладкость холмов оставь на потом, потому что это практически не влияет на результат.
>не думаю, что вообще доберусь до стадии геймплея
Генерировать процедурные миры очень интересно. На Reddit есть даже крупные сабреддиты про это, и существовало несколько веб-сайтов/форумов чисто про процедурную генерацию... Ещё до того, как эта тема была популяризирована Minecraft и другими играми. А Godot хоть и позиционируется как игровой движок, по сути универсальный инструмент для любого графического приложения. Главное, чтоб тебе самому нравилось, что ты там делаешь...
>>7324
Движок тут никаких препятствий не ставит, всё интуитивно понятно.
Если ты 100% новичок в геймдеве - рогалики довольно сложный жанр.
Если уже делал игры на других движках, то проблем быть не должно.
>>7326
Там бОльшая часть кода - движок, а не сама игра. Запутаешься.
Алсо, некоторые моменты могут решаться в Godot по-другому...
>>7353
Не суди только по себе - тебе ведь даже shift нажать сложно.
Твои проблемы. Все алгоритмы давно доступны в интернете...
Опять - твои проблемы. У Godot всё ОК с файловой системой.
>>7356
Есть несколько форков PixelDungeon. И в целом рогаликов много.
Навыки геймдизайнера не связаны с навыками обращения с Godot.
Код - это реализация задумки. Если нет задумки, не будет и кода.
>насколько сложно на этом движке запилить
Движок тут никаких препятствий не ставит, всё интуитивно понятно.
>свой пиксель данжн с блэкджеком и шлюхами
Если ты 100% новичок в геймдеве - рогалики довольно сложный жанр.
Если уже делал игры на других движках, то проблем быть не должно.
>>7326
>опенсорсный, бери и переписывай один в один
Там бОльшая часть кода - движок, а не сама игра. Запутаешься.
Алсо, некоторые моменты могут решаться в Godot по-другому...
>>7353
>сложно. потому что уже делаю около 5-ти месяцев
Не суди только по себе - тебе ведь даже shift нажать сложно.
>тяжело сделать генератор уровней (делал около месяца)
Твои проблемы. Все алгоритмы давно доступны в интернете...
>тяжело сделать нормально работающие сохранения
Опять - твои проблемы. У Godot всё ОК с файловой системой.
>>7356
>нужен полный клон PD с ретекстуром?
Есть несколько форков PixelDungeon. И в целом рогаликов много.
>делать это самому чтобы в процессе появилась идентичность
>потому что как я понял ты не годот-синьор и близко
Навыки геймдизайнера не связаны с навыками обращения с Godot.
Код - это реализация задумки. Если нет задумки, не будет и кода.
>>7324
Движок тут никаких препятствий не ставит, всё интуитивно понятно.
Если ты 100% новичок в геймдеве - рогалики довольно сложный жанр.
Если уже делал игры на других движках, то проблем быть не должно.
>>7326
Там бОльшая часть кода - движок, а не сама игра. Запутаешься.
Алсо, некоторые моменты могут решаться в Godot по-другому...
>>7353
Не суди только по себе - тебе ведь даже shift нажать сложно.
Твои проблемы. Все алгоритмы давно доступны в интернете...
Опять - твои проблемы. У Godot всё ОК с файловой системой.
>>7356
Есть несколько форков PixelDungeon. И в целом рогаликов много.
Навыки геймдизайнера не связаны с навыками обращения с Godot.
Код - это реализация задумки. Если нет задумки, не будет и кода.
>насколько сложно на этом движке запилить
Движок тут никаких препятствий не ставит, всё интуитивно понятно.
>свой пиксель данжн с блэкджеком и шлюхами
Если ты 100% новичок в геймдеве - рогалики довольно сложный жанр.
Если уже делал игры на других движках, то проблем быть не должно.
>>7326
>опенсорсный, бери и переписывай один в один
Там бОльшая часть кода - движок, а не сама игра. Запутаешься.
Алсо, некоторые моменты могут решаться в Godot по-другому...
>>7353
>сложно. потому что уже делаю около 5-ти месяцев
Не суди только по себе - тебе ведь даже shift нажать сложно.
>тяжело сделать генератор уровней (делал около месяца)
Твои проблемы. Все алгоритмы давно доступны в интернете...
>тяжело сделать нормально работающие сохранения
Опять - твои проблемы. У Godot всё ОК с файловой системой.
>>7356
>нужен полный клон PD с ретекстуром?
Есть несколько форков PixelDungeon. И в целом рогаликов много.
>делать это самому чтобы в процессе появилась идентичность
>потому что как я понял ты не годот-синьор и близко
Навыки геймдизайнера не связаны с навыками обращения с Godot.
Код - это реализация задумки. Если нет задумки, не будет и кода.
260 Кб, 393x419Мужики, спасайте. Как элегантно решить вопрос с клипающейся волосней? Я пытался с помощью новенького стенсила, который мне довелось трогать впервые, и это не очень помогло, так как иногда волосы слишком сильно клипаются и выходят за пределы шляпы. Выходит что под некоторыми углами их всетаки видно.
Я придумал костыль через невидимый цилиндр над шляпой, но мне это не очень нравится.
Я придумал костыль через невидимый цилиндр над шляпой, но мне это не очень нравится.
>>7485
В одной шляпной ммо, которую я гонял, модельки шляп либо брили персонажей налысо, либо да, делали волосы частью шляпы. Помню это негативное бухчение, когда шляпа ломала прическу принцессы.
В одной шляпной ммо, которую я гонял, модельки шляп либо брили персонажей налысо, либо да, делали волосы частью шляпы. Помню это негативное бухчение, когда шляпа ломала прическу принцессы.
>>7485
С таким графонием, как у тебя, протекающая сквозь шляпу причёска - не баг, а фича. Как арты в MS Paint, сознательно искажающие объекты ради стиля.
А если серьёзно, то, полагаю, наиболее простым и эффективным способом будет сделать отдельный блендшейп на меш волос (он ведь отдельный от остального тела?), и изменять его значение, когда персонаж надевает специфические шляпы.
Общий алгоритм действий таков:
1. Делаешь меш волос персонажу.
2. Делаешь съёмную шляпу - видишь косяк волос.
3. Делаешь блендшейп, вдавливая волосы в голову.
4. На движке настраиваешь логику типа такой:
Где hat и hair - это MeshInstance3D.
Потенциальные недостатки метода:
- если уже и без того много блендшейпов у волос;
- если тебе нужны сотни таких людей на экране;
- если у тебя 100500 разных шляп и волос;
- если это нужно под старые мобилки...
Но, думаю, в большинстве случаев и так сойдёт.
Если что, блендшейпы можно "запекать" в коде.
>>7492
Вот это как раз "нужно сотни людей на экране"...
С таким графонием, как у тебя, протекающая сквозь шляпу причёска - не баг, а фича. Как арты в MS Paint, сознательно искажающие объекты ради стиля.
А если серьёзно, то, полагаю, наиболее простым и эффективным способом будет сделать отдельный блендшейп на меш волос (он ведь отдельный от остального тела?), и изменять его значение, когда персонаж надевает специфические шляпы.
Общий алгоритм действий таков:
1. Делаешь меш волос персонажу.
2. Делаешь съёмную шляпу - видишь косяк волос.
3. Делаешь блендшейп, вдавливая волосы в голову.
4. На движке настраиваешь логику типа такой:
>@export var wear_hat: bool = false:
>_ set(v):
>_ _ wear_hat = v
>_ _ hat.visible = v
>_ _ hair.mesh.set_blend_shape_value("hat", float(v))
Где hat и hair - это MeshInstance3D.
Потенциальные недостатки метода:
- если уже и без того много блендшейпов у волос;
- если тебе нужны сотни таких людей на экране;
- если у тебя 100500 разных шляп и волос;
- если это нужно под старые мобилки...
Но, думаю, в большинстве случаев и так сойдёт.
Если что, блендшейпы можно "запекать" в коде.
>>7492
>ммо
Вот это как раз "нужно сотни людей на экране"...
>>7485
С таким графонием, как у тебя, протекающая сквозь шляпу причёска - не баг, а фича. Как арты в MS Paint, сознательно искажающие объекты ради стиля.
А если серьёзно, то, полагаю, наиболее простым и эффективным способом будет сделать отдельный блендшейп на меш волос (он ведь отдельный от остального тела?), и изменять его значение, когда персонаж надевает специфические шляпы.
Общий алгоритм действий таков:
1. Делаешь меш волос персонажу.
2. Делаешь съёмную шляпу - видишь косяк волос.
3. Делаешь блендшейп, вдавливая волосы в голову.
4. На движке настраиваешь логику типа такой:
Где hat и hair - это MeshInstance3D.
Потенциальные недостатки метода:
- если уже и без того много блендшейпов у волос;
- если тебе нужны сотни таких людей на экране;
- если у тебя 100500 разных шляп и волос;
- если это нужно под старые мобилки...
Но, думаю, в большинстве случаев и так сойдёт.
Если что, блендшейпы можно "запекать" в коде.
>>7492
Вот это как раз "нужно сотни людей на экране"...
С таким графонием, как у тебя, протекающая сквозь шляпу причёска - не баг, а фича. Как арты в MS Paint, сознательно искажающие объекты ради стиля.
А если серьёзно, то, полагаю, наиболее простым и эффективным способом будет сделать отдельный блендшейп на меш волос (он ведь отдельный от остального тела?), и изменять его значение, когда персонаж надевает специфические шляпы.
Общий алгоритм действий таков:
1. Делаешь меш волос персонажу.
2. Делаешь съёмную шляпу - видишь косяк волос.
3. Делаешь блендшейп, вдавливая волосы в голову.
4. На движке настраиваешь логику типа такой:
>@export var wear_hat: bool = false:
>_ set(v):
>_ _ wear_hat = v
>_ _ hat.visible = v
>_ _ hair.mesh.set_blend_shape_value("hat", float(v))
Где hat и hair - это MeshInstance3D.
Потенциальные недостатки метода:
- если уже и без того много блендшейпов у волос;
- если тебе нужны сотни таких людей на экране;
- если у тебя 100500 разных шляп и волос;
- если это нужно под старые мобилки...
Но, думаю, в большинстве случаев и так сойдёт.
Если что, блендшейпы можно "запекать" в коде.
>>7492
>ммо
Вот это как раз "нужно сотни людей на экране"...
>>7490
Да
>>7492
Вот, к этому я склоняюсь. Подобрать нейтральную прическу с плоским верхом и свапать вместе со шляпами. Хотелось, конечно, интереснее, но видимо не выйдет
>>7493
Ты сейчас до графона доебался, или я чего-то не понял?
У меня оче много разных волос и ещё больше планируется добавить. Не мой вариант. Хотя, у меня есть система слотов одежды, которая поможет удобно всем этим оперировать. Короч, подумаю.
>Ты симулятор реальности делаешь или игру?
Да
>>7492
>модельки шляп либо брили персонажей налысо
Вот, к этому я склоняюсь. Подобрать нейтральную прическу с плоским верхом и свапать вместе со шляпами. Хотелось, конечно, интереснее, но видимо не выйдет
>>7493
>С таким графонием, как у тебя, протекающая сквозь шляпу причёска - не баг, а фича
Ты сейчас до графона доебался, или я чего-то не понял?
>А если серьёзно, то, полагаю, наиболее простым и эффективным способом будет сделать отдельный блендшейп на меш волос (он ведь отдельный от остального тела?)
У меня оче много разных волос и ещё больше планируется добавить. Не мой вариант. Хотя, у меня есть система слотов одежды, которая поможет удобно всем этим оперировать. Короч, подумаю.
>>7497
Какой смысл делать много разных волос, если они полностью перекрываются шляпой/шлемом? Всегда раздражало, что вот сидишь два часа в редакторе персонажа, а потом первая же кепка на +1 к защите умножает тщательно выбранную причёску на ноль. Хочется бегать красивым персонажем, но без брони нерационально, а с ней все персонажи одинаковы.
Я это к тому, что можешь забить на причёски, если планируются геймплейно значимые шапки, т.к. игрок наверняка не будет лишать себя шапковых бонусов...
Я тут ещё подумал: шапка больше всего влияет на длинные волосы, верно? Короткие обычно целиком скрываются под шапкой. Следовательно, можно их разделить на "макушку" - она скрывается шапкой - и "длинную часть" - то есть все эти косы, вылезающие наружу локоны и т.п. В таком случае тут не нужен блендшейп, достаточно 2-3 меша на причёску:
1. Меш макушки.
2. Меш косы/локонов и т.п.
3. Опционально: цельный меш причёски (без швов).
В некоторых редакторах персонажа можно делать комбинации из нескольких стилей: на затылок, на макушку, на чёлку, на виски и т.д. С одной стороны, количество возможных причёсок равно количеству комбинаций деталей. С другой - её можно скрывать частично, если отдельные части закрыты одеждой.
>Подобрать нейтральную прическу
>У меня оче много разных волос
Какой смысл делать много разных волос, если они полностью перекрываются шляпой/шлемом? Всегда раздражало, что вот сидишь два часа в редакторе персонажа, а потом первая же кепка на +1 к защите умножает тщательно выбранную причёску на ноль. Хочется бегать красивым персонажем, но без брони нерационально, а с ней все персонажи одинаковы.
Я это к тому, что можешь забить на причёски, если планируются геймплейно значимые шапки, т.к. игрок наверняка не будет лишать себя шапковых бонусов...
Я тут ещё подумал: шапка больше всего влияет на длинные волосы, верно? Короткие обычно целиком скрываются под шапкой. Следовательно, можно их разделить на "макушку" - она скрывается шапкой - и "длинную часть" - то есть все эти косы, вылезающие наружу локоны и т.п. В таком случае тут не нужен блендшейп, достаточно 2-3 меша на причёску:
1. Меш макушки.
2. Меш косы/локонов и т.п.
3. Опционально: цельный меш причёски (без швов).
В некоторых редакторах персонажа можно делать комбинации из нескольких стилей: на затылок, на макушку, на чёлку, на виски и т.д. С одной стороны, количество возможных причёсок равно количеству комбинаций деталей. С другой - её можно скрывать частично, если отдельные части закрыты одеждой.
>>7514
Делаем, делаем, никак не сделаем
Делаем, делаем, никак не сделаем
137 Кб, 766x737Автор GodotSteam поехал на теме, что Godot требует создавать плагины в папке addons из-за чего бывают лишние файлы в корне, всем кидает issue чтобы создали файл игнора, хотя годот и так умеет это делать при скачивании.
Кстати, он окуклил все репозитории на github позавчера и переехал на CodeBerg.
Кстати, он окуклил все репозитории на github позавчера и переехал на CodeBerg.
>>7518
Про аддоны хз, а на кодберг давно переезжают потихоньку - с момента когда МС гитхабю выкупили. Сорсхат и гитлаб еще есть.
Про аддоны хз, а на кодберг давно переезжают потихоньку - с момента когда МС гитхабю выкупили. Сорсхат и гитлаб еще есть.
>>7520
Он бы полтора года назад переехал если бы прична была в этом, тут что-то другое. Хотя я сам гитхабом пользуюсь и заливка коммитов без их клиента это пиздец, надо выдать себе токен прописать его в системе или в локальном репозитории на ПК или сгенерировать ключ короче было просто логин-пароль, сделали какую-то хуйню чтобы побольше данных воровать, надеюсь они форкнут гит, сделают несовместимое изменение и сдохнут нахуй как и их икс бокс.
Он бы полтора года назад переехал если бы прична была в этом, тут что-то другое. Хотя я сам гитхабом пользуюсь и заливка коммитов без их клиента это пиздец, надо выдать себе токен прописать его в системе или в локальном репозитории на ПК или сгенерировать ключ короче было просто логин-пароль, сделали какую-то хуйню чтобы побольше данных воровать, надеюсь они форкнут гит, сделают несовместимое изменение и сдохнут нахуй как и их икс бокс.
>>7521
Сейчас там тоже причины всплывают, типа заявлений гитхаба что они будут приоритезириовать интеграцию/переезд на МС (азура, копайлот), вместо разработки фич.
Сам я гитом пользуюсь через кли, там пофиг на платформу, будь то гитхаб или кодберг. А вот необходимость иметь кучу аккаунтов для репорта багов - ну такое. Самое жопное когда разраб поднимает свою собственную gitea и ожидает что ему туда issue придут репортить.
Сейчас там тоже причины всплывают, типа заявлений гитхаба что они будут приоритезириовать интеграцию/переезд на МС (азура, копайлот), вместо разработки фич.
Сам я гитом пользуюсь через кли, там пофиг на платформу, будь то гитхаб или кодберг. А вот необходимость иметь кучу аккаунтов для репорта багов - ну такое. Самое жопное когда разраб поднимает свою собственную gitea и ожидает что ему туда issue придут репортить.
>>7543
Никто не мешает на гитхабе пустой репозиторий держать для ишью (можно и не пустой, а зеркало), а самому разрабатывать в gitea. Если уж уходить с гитхаба, то на свой хостинг с gitea. Иначе смысл шило на мыло менять...
Никто не мешает на гитхабе пустой репозиторий держать для ишью (можно и не пустой, а зеркало), а самому разрабатывать в gitea. Если уж уходить с гитхаба, то на свой хостинг с gitea. Иначе смысл шило на мыло менять...
>>7543
Ну вот, через кли гита чтобы спушить на гитхаб у тебя конечно спросят логин/пароль, а потом напишут "извините мы выключили пуш по логину паролю с такого-то числа" и чтобы пуш прошёл надо прописывать токен. Я предпологаю что кли от гитхаба упрощает эту задачу, но это надо ставить их клиент и он хоть и опенсорсный, выполняет неизвестный пользователю JavaScript код который получает с сервера(типа для авторизации) и не видно какая информация собирается с ПК
>Сам я гитом пользуюсь через кли
Ну вот, через кли гита чтобы спушить на гитхаб у тебя конечно спросят логин/пароль, а потом напишут "извините мы выключили пуш по логину паролю с такого-то числа" и чтобы пуш прошёл надо прописывать токен. Я предпологаю что кли от гитхаба упрощает эту задачу, но это надо ставить их клиент и он хоть и опенсорсный, выполняет неизвестный пользователю JavaScript код который получает с сервера(типа для авторизации) и не видно какая информация собирается с ПК
>>7547
Не токен а ssн ключ. Это нормальная правктика для понимающих в безопасности. Пароли используют либо сликом ленивые либо тупые.
Не токен а ssн ключ. Это нормальная правктика для понимающих в безопасности. Пароли используют либо сликом ленивые либо тупые.
>>7549
Да и скорее ленивые тоже тупые. Потому что если написать .ssh/config то большинство приложений работающий через ssh будет автоматически подключаться к git+ssh
Да и скорее ленивые тоже тупые. Потому что если написать .ssh/config то большинство приложений работающий через ssh будет автоматически подключаться к git+ssh
>>7550
Опасность скорее в том что майки захотят оставить только live аккаунт для всего. Это их старый способ больбы с конкурентами. Внедряй, изменяй, убивай альтернативы
Опасность скорее в том что майки захотят оставить только live аккаунт для всего. Это их старый способ больбы с конкурентами. Внедряй, изменяй, убивай альтернативы
>>7549
Токен токен, персонал ацесс токен. Это не безопасность, а ебание мозгов, потому что я могу через браузер по логину и паролю зайти и сделать коммит через web интерфейс, где тут безопасность и от кого? Что твоё понимание в безопасности говорит по этому поводу?
>Не токен а ssн ключ
Токен токен, персонал ацесс токен. Это не безопасность, а ебание мозгов, потому что я могу через браузер по логину и паролю зайти и сделать коммит через web интерфейс, где тут безопасность и от кого? Что твоё понимание в безопасности говорит по этому поводу?
>>7552
1) А тебя кто-то заставляет ими пользоваться?
2) Это чисто для автоматизации хуйня
Асес токены безопаснее ключей, чтобы их выложиь куда то на сервер выложить для автоматизации работы с гитхабом. Потому что они имеют СКОУП прав доступа. Это тоже стандартная правктика. Я такую же хуйню на гитлабе настраивал
1) А тебя кто-то заставляет ими пользоваться?
2) Это чисто для автоматизации хуйня
>Что твоё понимание в безопасности говорит по этому поводу?
Асес токены безопаснее ключей, чтобы их выложиь куда то на сервер выложить для автоматизации работы с гитхабом. Потому что они имеют СКОУП прав доступа. Это тоже стандартная правктика. Я такую же хуйню на гитлабе настраивал
>>7553
Еще может как костыль для сторонни приложений использоваться, но для этого есть OAuth. Даже VSCode работает спокойно через git + ssh. У меня просто в .ssh/config прописано куда подключаться и какой ключи использовать
Еще может как костыль для сторонни приложений использоваться, но для этого есть OAuth. Даже VSCode работает спокойно через git + ssh. У меня просто в .ssh/config прописано куда подключаться и какой ключи использовать
>>7553
Так ну да. Большой разницы нет токен или ссш, раньше жили с паролем, затем майкрософт купила гитхаб, "произошла утечка" паролей и они решили запретить доступ из кли по паролю, причём так чтобы на виндовс это работало до 2023.
Как бы если у тебя есть доступ к веб интерфейсу ты там и токен можешь добавить и ссш ключ ещё один добавить, я не вижу в этом какой-то особой безопасности, это скорее цифровой паспорт конкретного ПК.
Ладно, тред Godot, делайте игры.
>А тебя кто-то заставляет ими пользоваться?
Так ну да. Большой разницы нет токен или ссш, раньше жили с паролем, затем майкрософт купила гитхаб, "произошла утечка" паролей и они решили запретить доступ из кли по паролю, причём так чтобы на виндовс это работало до 2023.
Как бы если у тебя есть доступ к веб интерфейсу ты там и токен можешь добавить и ссш ключ ещё один добавить, я не вижу в этом какой-то особой безопасности, это скорее цифровой паспорт конкретного ПК.
Ладно, тред Godot, делайте игры.
504 Кб, 1600x720Современные школотроны, не знающие пеку, делают игры прямо на телефонах, на годоте. До чего мы докатимся? Это плохо или хорошо?
>>7575
В моей молодости не имея денег на пеку писали программы прямо на симбиан. Ничего не поменялось...
В моей молодости не имея денег на пеку писали программы прямо на симбиан. Ничего не поменялось...
>>7595
Челу который на симбиан писал нужна помощь в годоти? Совсем куку?
Челу который на симбиан писал нужна помощь в годоти? Совсем куку?
2 Мб, 1920x1080>>7595
Извините. Вот вам годетта.
Извините. Вот вам годетта.
>>7514
>>6874
Вкратце о разработке моей игры: пикрил.
На видео: набросал радар для отладки положения. Геймплейно никакого радара не будет: предполагаю навигацию по солнцу и облакам, игроку важны лишь координаты X и Y для определения биомов. Но для разработки хочется знать "реальное" положение...
>>6969
А ты уверен, что она тебе нужна? Вот радиус Земли - мизерные 6370 км, по окружности всего-то 40000 км. Несмотря на такой малый размер, "сферичность" гравитации почувствовать на поверхности по сути невозможно. Да и изгиб горизонта не так заметен. В компьютерных играх доступный участок обычно значительно меньше, поэтому в играх они плоские. Реальная гравитация встречается только в каких-то аркадных игрушках и симуляторах выхода в космос.
Если я правильно помню, по лору у тебя все ездят на колоссальных машинах, вплоть до всяких пиратов. Возникает вопрос, где эти машины конструировать? Очевидно, что полости должны иметь настолько масштабный размер, что искривление поверхности скрывается далеко за облаками и не влияет на те физические взаимодействия, что доступны игроку. Фактически вывернутость пространства у тебя - это обоснование, почему/как игрок может с помощью землероющей машины попасть на другую планету. Симулировать реальную физику здесь не нужно.
Короче говоря, тебе будет достаточно стандартной "плоской" физики как практически во всех 3D играх. Необходимые графические эффекты можно делать конвертацией координат в то, что тебе потребуется. Большинство игроков всё равно не заметят никакой разницы на практике, т.к. будут слишком озабочены конкретным геймплеем (противостояние монстрам, нахождение и сбор ресурсов, крафт/ремонт и т.д.).
Ты всё ещё можешь делать 3D модели и текстуры, персонажей всяких и т.п. Тестировать на плоскости, поскольку разницы для графики всё равно нет. Да и базовые механики типа стрельбы никак не должны взаимодействовать с искривлением гравитации, т.к. снаряды "летят" мгновенно (рейкаст). Так ты хотя бы некоторые части игры сделаешь, и целую игру будет намного проще реализовать. Ну и в будущем может пригодится для какой-нибудь другой 3D игры...
Возможно, ты просто ищешь оправдание, чтобы не заниматься скучной рутиной? Где бы ты достал все необходимые ресурсы, будь у тебя готовая игра с "инверсной гравитацией", но без графики и прочего? Прекрасно понимаю это желание оправдать своё бездействие какими-то "особыми" препятствиями.
Но если тебя игры в целом не привлекают - не стоит заставлять себя заниматься их разработкой. Ничего хорошего от такого принуждения не получится...
>Делайте игры
>>6874
>Игры-то делаете?
Вкратце о разработке моей игры: пикрил.
На видео: набросал радар для отладки положения. Геймплейно никакого радара не будет: предполагаю навигацию по солнцу и облакам, игроку важны лишь координаты X и Y для определения биомов. Но для разработки хочется знать "реальное" положение...
>>6969
>не смог в инверсную гравитацию
А ты уверен, что она тебе нужна? Вот радиус Земли - мизерные 6370 км, по окружности всего-то 40000 км. Несмотря на такой малый размер, "сферичность" гравитации почувствовать на поверхности по сути невозможно. Да и изгиб горизонта не так заметен. В компьютерных играх доступный участок обычно значительно меньше, поэтому в играх они плоские. Реальная гравитация встречается только в каких-то аркадных игрушках и симуляторах выхода в космос.
Если я правильно помню, по лору у тебя все ездят на колоссальных машинах, вплоть до всяких пиратов. Возникает вопрос, где эти машины конструировать? Очевидно, что полости должны иметь настолько масштабный размер, что искривление поверхности скрывается далеко за облаками и не влияет на те физические взаимодействия, что доступны игроку. Фактически вывернутость пространства у тебя - это обоснование, почему/как игрок может с помощью землероющей машины попасть на другую планету. Симулировать реальную физику здесь не нужно.
Короче говоря, тебе будет достаточно стандартной "плоской" физики как практически во всех 3D играх. Необходимые графические эффекты можно делать конвертацией координат в то, что тебе потребуется. Большинство игроков всё равно не заметят никакой разницы на практике, т.к. будут слишком озабочены конкретным геймплеем (противостояние монстрам, нахождение и сбор ресурсов, крафт/ремонт и т.д.).
>мне нет смысла двигаться дальше
>геймплей и фишки завязаны
Ты всё ещё можешь делать 3D модели и текстуры, персонажей всяких и т.п. Тестировать на плоскости, поскольку разницы для графики всё равно нет. Да и базовые механики типа стрельбы никак не должны взаимодействовать с искривлением гравитации, т.к. снаряды "летят" мгновенно (рейкаст). Так ты хотя бы некоторые части игры сделаешь, и целую игру будет намного проще реализовать. Ну и в будущем может пригодится для какой-нибудь другой 3D игры...
Возможно, ты просто ищешь оправдание, чтобы не заниматься скучной рутиной? Где бы ты достал все необходимые ресурсы, будь у тебя готовая игра с "инверсной гравитацией", но без графики и прочего? Прекрасно понимаю это желание оправдать своё бездействие какими-то "особыми" препятствиями.
Но если тебя игры в целом не привлекают - не стоит заставлять себя заниматься их разработкой. Ничего хорошего от такого принуждения не получится...
>>7514
>>6874
Вкратце о разработке моей игры: пикрил.
На видео: набросал радар для отладки положения. Геймплейно никакого радара не будет: предполагаю навигацию по солнцу и облакам, игроку важны лишь координаты X и Y для определения биомов. Но для разработки хочется знать "реальное" положение...
>>6969
А ты уверен, что она тебе нужна? Вот радиус Земли - мизерные 6370 км, по окружности всего-то 40000 км. Несмотря на такой малый размер, "сферичность" гравитации почувствовать на поверхности по сути невозможно. Да и изгиб горизонта не так заметен. В компьютерных играх доступный участок обычно значительно меньше, поэтому в играх они плоские. Реальная гравитация встречается только в каких-то аркадных игрушках и симуляторах выхода в космос.
Если я правильно помню, по лору у тебя все ездят на колоссальных машинах, вплоть до всяких пиратов. Возникает вопрос, где эти машины конструировать? Очевидно, что полости должны иметь настолько масштабный размер, что искривление поверхности скрывается далеко за облаками и не влияет на те физические взаимодействия, что доступны игроку. Фактически вывернутость пространства у тебя - это обоснование, почему/как игрок может с помощью землероющей машины попасть на другую планету. Симулировать реальную физику здесь не нужно.
Короче говоря, тебе будет достаточно стандартной "плоской" физики как практически во всех 3D играх. Необходимые графические эффекты можно делать конвертацией координат в то, что тебе потребуется. Большинство игроков всё равно не заметят никакой разницы на практике, т.к. будут слишком озабочены конкретным геймплеем (противостояние монстрам, нахождение и сбор ресурсов, крафт/ремонт и т.д.).
Ты всё ещё можешь делать 3D модели и текстуры, персонажей всяких и т.п. Тестировать на плоскости, поскольку разницы для графики всё равно нет. Да и базовые механики типа стрельбы никак не должны взаимодействовать с искривлением гравитации, т.к. снаряды "летят" мгновенно (рейкаст). Так ты хотя бы некоторые части игры сделаешь, и целую игру будет намного проще реализовать. Ну и в будущем может пригодится для какой-нибудь другой 3D игры...
Возможно, ты просто ищешь оправдание, чтобы не заниматься скучной рутиной? Где бы ты достал все необходимые ресурсы, будь у тебя готовая игра с "инверсной гравитацией", но без графики и прочего? Прекрасно понимаю это желание оправдать своё бездействие какими-то "особыми" препятствиями.
Но если тебя игры в целом не привлекают - не стоит заставлять себя заниматься их разработкой. Ничего хорошего от такого принуждения не получится...
>Делайте игры
>>6874
>Игры-то делаете?
Вкратце о разработке моей игры: пикрил.
На видео: набросал радар для отладки положения. Геймплейно никакого радара не будет: предполагаю навигацию по солнцу и облакам, игроку важны лишь координаты X и Y для определения биомов. Но для разработки хочется знать "реальное" положение...
>>6969
>не смог в инверсную гравитацию
А ты уверен, что она тебе нужна? Вот радиус Земли - мизерные 6370 км, по окружности всего-то 40000 км. Несмотря на такой малый размер, "сферичность" гравитации почувствовать на поверхности по сути невозможно. Да и изгиб горизонта не так заметен. В компьютерных играх доступный участок обычно значительно меньше, поэтому в играх они плоские. Реальная гравитация встречается только в каких-то аркадных игрушках и симуляторах выхода в космос.
Если я правильно помню, по лору у тебя все ездят на колоссальных машинах, вплоть до всяких пиратов. Возникает вопрос, где эти машины конструировать? Очевидно, что полости должны иметь настолько масштабный размер, что искривление поверхности скрывается далеко за облаками и не влияет на те физические взаимодействия, что доступны игроку. Фактически вывернутость пространства у тебя - это обоснование, почему/как игрок может с помощью землероющей машины попасть на другую планету. Симулировать реальную физику здесь не нужно.
Короче говоря, тебе будет достаточно стандартной "плоской" физики как практически во всех 3D играх. Необходимые графические эффекты можно делать конвертацией координат в то, что тебе потребуется. Большинство игроков всё равно не заметят никакой разницы на практике, т.к. будут слишком озабочены конкретным геймплеем (противостояние монстрам, нахождение и сбор ресурсов, крафт/ремонт и т.д.).
>мне нет смысла двигаться дальше
>геймплей и фишки завязаны
Ты всё ещё можешь делать 3D модели и текстуры, персонажей всяких и т.п. Тестировать на плоскости, поскольку разницы для графики всё равно нет. Да и базовые механики типа стрельбы никак не должны взаимодействовать с искривлением гравитации, т.к. снаряды "летят" мгновенно (рейкаст). Так ты хотя бы некоторые части игры сделаешь, и целую игру будет намного проще реализовать. Ну и в будущем может пригодится для какой-нибудь другой 3D игры...
Возможно, ты просто ищешь оправдание, чтобы не заниматься скучной рутиной? Где бы ты достал все необходимые ресурсы, будь у тебя готовая игра с "инверсной гравитацией", но без графики и прочего? Прекрасно понимаю это желание оправдать своё бездействие какими-то "особыми" препятствиями.
Но если тебя игры в целом не привлекают - не стоит заставлять себя заниматься их разработкой. Ничего хорошего от такого принуждения не получится...
>>5375
Я сейчас на стадии добавления контента и фикса мелких багов игровых механик.
Ебать это время отжирает, хоть и не так заебно как базовые механики.
Я сейчас на стадии добавления контента и фикса мелких багов игровых механик.
Ебать это время отжирает, хоть и не так заебно как базовые механики.
60 Кб, 1161x550>>7609
Как же хочется. Эльфиечку. Маленькую, сисястую, жопастую, бегающую враскорячку.
Когда релиз?
> моей игры: пикрил
Как же хочется. Эльфиечку. Маленькую, сисястую, жопастую, бегающую враскорячку.
Когда релиз?
>>7575
Зато они делают игры, а ты нет.
Зато они делают игры, а ты нет.
>>7615
Сделай сам. Да, ты.
Сделай сам. Да, ты.
Аноны. Вопрос. Могу ли я цеплять к одному синглтон таймеру кучу всякой хуйни? Мне только что чатгопота сказал, мол await может скипнуть сигнал таймера и залипнуть
>>7631
Я ничего не хочу. Просто у меня в синглтоне несколько таймеров, которые я использую в совершенно рандомных местах. Например у меня обновление интерфейса, баффы и скорость роста растений держатся на одном этом таймере. И сегодня нейронка выдала мне, что если я буду абюзить таймер во многих await сразу то всё поломается, гроб кладбище пидор. Я не сильно понял ПОЧЕМУ. Посему прошу, чтобы мне разжевали, бредит ли нейронка.
Я ничего не хочу. Просто у меня в синглтоне несколько таймеров, которые я использую в совершенно рандомных местах. Например у меня обновление интерфейса, баффы и скорость роста растений держатся на одном этом таймере. И сегодня нейронка выдала мне, что если я буду абюзить таймер во многих await сразу то всё поломается, гроб кладбище пидор. Я не сильно понял ПОЧЕМУ. Посему прошу, чтобы мне разжевали, бредит ли нейронка.
>>7629
Если таймер умрёт (выйдет из дерева, баганет код таймера) - то может залипнуть, но это всего лишь значит что консьюмер не будет вызван, с нулевой нагрузкой на движок, что в общем-то база для продьюсер/консюмер систем. По идее в 99.99999% случаев ничего никуда с нихуя не залипает, но вот годотовские process-base таймеры это мем сам по себе.
Если таймер умрёт (выйдет из дерева, баганет код таймера) - то может залипнуть, но это всего лишь значит что консьюмер не будет вызван, с нулевой нагрузкой на движок, что в общем-то база для продьюсер/консюмер систем. По идее в 99.99999% случаев ничего никуда с нихуя не залипает, но вот годотовские process-base таймеры это мем сам по себе.
У меня таймер ломал игру когда пытался изменить значение переменной, когда я покидал сцену с данным запущенным таймером.
А мне больше нравятся таймеры из кода, чем ноды-таймеры. Удобней, наглядней.
>>7577
Для подобного м.б. планшеты полезнее.
что в целом оправданно. Пришёл дома поработал, залил в хранилище. Нашёл время, открыл планшет, скачал, поработал, залил обратно.
В юнитях и УЕ такого нет, кстати.
Для подобного м.б. планшеты полезнее.
что в целом оправданно. Пришёл дома поработал, залил в хранилище. Нашёл время, открыл планшет, скачал, поработал, залил обратно.
В юнитях и УЕ такого нет, кстати.
Вы готовы, дети? Новая дефолтная тема в 4.6 релизе.
>>7649
На андроиде из пиксельных рисовак resprite удобней всего, но он платный.
На андроиде из пиксельных рисовак resprite удобней всего, но он платный.
>>7653
Ну, сделали и сделали, чо бухтеть то.
Ну, сделали и сделали, чо бухтеть то.
>>7653
Чел сам выкладывал оригинальный aseprite под опенсорсной (GPLv2) лицензией. До определенного момента. Так что все чисто. Что упало то пропало, как грится.
>Спиздили
Чел сам выкладывал оригинальный aseprite под опенсорсной (GPLv2) лицензией. До определенного момента. Так что все чисто. Что упало то пропало, как грится.
2 Кб, 64x64>>7654
Понял, принял
Понял, принял
>>7635
Когда к одной и той же хуйне привязано одновременно много не связанных между собой вещей, со временем начинают возникать баги, описание которых выглядит как бред. Типа "Фиолетовые жабы отказываются пить пиво, если игрока зовут Олег".
И вообще:
Если каждый кадр, то для этого есть func _process прямо в скрипте интерфейса. А если реже, то лучше привяжи сигналы. В какой такой ситуации вообще может в годоте понадобиться таймер для обновления интерфейса?
Но если очень надо - заведи отдельные таймеры для каждой категории. Это не на случай, когда всё нормально работает, а на случай, когда что-то сломается. Всегда считай, что сломаться может что угодно, ведь ты никогда не знаешь, где накосячишь.
Олсо, я не синглтоношиз, но вот конкретно таймеры в синглтон не вешаю никогда. Это слишком локальная хуйня, которая никогда не бывает нужна всем сразу. Самый верхний уровень, куда можно было бы повесить таймер - это уровень (каламбурчик, хех).
Когда к одной и той же хуйне привязано одновременно много не связанных между собой вещей, со временем начинают возникать баги, описание которых выглядит как бред. Типа "Фиолетовые жабы отказываются пить пиво, если игрока зовут Олег".
И вообще:
>обновление интерфейса
Если каждый кадр, то для этого есть func _process прямо в скрипте интерфейса. А если реже, то лучше привяжи сигналы. В какой такой ситуации вообще может в годоте понадобиться таймер для обновления интерфейса?
Но если очень надо - заведи отдельные таймеры для каждой категории. Это не на случай, когда всё нормально работает, а на случай, когда что-то сломается. Всегда считай, что сломаться может что угодно, ведь ты никогда не знаешь, где накосячишь.
Олсо, я не синглтоношиз, но вот конкретно таймеры в синглтон не вешаю никогда. Это слишком локальная хуйня, которая никогда не бывает нужна всем сразу. Самый верхний уровень, куда можно было бы повесить таймер - это уровень (каламбурчик, хех).
>>7648
Выглядит как "мы теперь серьёзный инструмент для серьёзных дядек с деньгами". А трёшка выглядела как "у нас всё просто и понятно даже для школовкатунов, играй в наш движок". Четвёрка уже задала впечатление большей серьёзности, поменяв шрифт и приглушив цвета, а теперь вот совсем.
Выглядит как "мы теперь серьёзный инструмент для серьёзных дядек с деньгами". А трёшка выглядела как "у нас всё просто и понятно даже для школовкатунов, играй в наш движок". Четвёрка уже задала впечатление большей серьёзности, поменяв шрифт и приглушив цвета, а теперь вот совсем.
>>7665
При том что тема сделана одним-единственным ультранердом из соцсетей. Интересно сколько охуилиардов потратили бы на нее "серьезные дяди с деньгами".
При том что тема сделана одним-единственным ультранердом из соцсетей. Интересно сколько охуилиардов потратили бы на нее "серьезные дяди с деньгами".
>>7647
Уп.
Протестил. Я хз, но приложением на моём экране пользоваться не возможно. Вероятно, оно таки для планшетов задумано. И хоть, конечно, и можно и клаву отодвинуть и что-то еще. Но тем не менее, на обычном телефоне это хоть и работает, но работать в таком виде, пока не возможно.
Уп.
Протестил. Я хз, но приложением на моём экране пользоваться не возможно. Вероятно, оно таки для планшетов задумано. И хоть, конечно, и можно и клаву отодвинуть и что-то еще. Но тем не менее, на обычном телефоне это хоть и работает, но работать в таком виде, пока не возможно.
>>7693
Мы просто деды, пора вымирать. Зумеры-альферы на телефонах и код пишут и 3д моделят и пиксельарт рисуют.
Мы просто деды, пора вымирать. Зумеры-альферы на телефонах и код пишут и 3д моделят и пиксельарт рисуют.
>>7693
я вообще не пользуюсь годотом, но попробовал покодить на 11" планшете с беспроводной клавиатурой - приемлемо
на 6-7 дюймовом телефоне придётся масштаб выкрутить, чтоб что-либо увидеть, окно кода сожмётся в 10 символов на строку
на версии 3.5 backspace и delete посылал один и тот же keycode, с версии 3.6 исправили, в 4.х не было этой проблемы, но он работает медленнее
я вообще не пользуюсь годотом, но попробовал покодить на 11" планшете с беспроводной клавиатурой - приемлемо
на 6-7 дюймовом телефоне придётся масштаб выкрутить, чтоб что-либо увидеть, окно кода сожмётся в 10 символов на строку
на версии 3.5 backspace и delete посылал один и тот же keycode, с версии 3.6 исправили, в 4.х не было этой проблемы, но он работает медленнее
>>7635
На остальное как-нибудь потом отвечу, но вот это - бросилось в глаза... Ты там симулятор фермы или майнкрафт/террарию делаешь?.. В любом случае: множество обновляемых штук == необходимо оптимизировать разбиванием на группы или вовсе рандомными обновлениями по такому алгоритму:
По такому методу и Minecraft, и Terraria работают.
>скорость роста растений на одном таймере
На остальное как-нибудь потом отвечу, но вот это - бросилось в глаза... Ты там симулятор фермы или майнкрафт/террарию делаешь?.. В любом случае: множество обновляемых штук == необходимо оптимизировать разбиванием на группы или вовсе рандомными обновлениями по такому алгоритму:
>каждый тик таймера:
>_ ткнуть в рандомную клетку карты (x, y)
>_ это обновляемая клетка? (растение)
>_ _ бросить кубик на обновление
>_ _ выпало "пора обновить"?
>_ _ _ обновить клетку (растение растёт)
По такому методу и Minecraft, и Terraria работают.
>>7662
Да не. Я пользуюсь таймерами как средством для экономии вычислительной мощности на кадр. Точнее использую там, где что-то нужно подождать без особой точности. То есть единственное их применение это await Singleton.timer_a.timeout. Ни в чем более менее важном они не участвуют.
Это всё хуйня, анон. Я хочу понять конкретно сколько правды в словах нейросети. А сказано было, что сигнал одного таймера нельзя использовать во множестве await одновременно, потому что может случиться, что один await станет ожидать сигнал, который в этом кадре занят другим авэйтом, сигнал отработает и авейт не отследит его и залипнет в бесконечном ожидании.
>>7725
Не, у меня всего несколько растений, но они должны симпатично расти. Они разворачивают форму ростка в блендшейпе. Потому там цикл while, который подкручивает блендшейп 10 раз в секунду, пока не достигнет 1.0. Звучит может калично, но большего этим росткам и не нужно. Я не видел смысл занимать этим процессом каждый кадр.
>Когда к одной и той же хуйне привязано одновременно много не связанных между собой вещей, со временем начинают возникать баги, описание которых выглядит как бред. Типа "Фиолетовые жабы отказываются пить пиво, если игрока зовут Олег".
Да не. Я пользуюсь таймерами как средством для экономии вычислительной мощности на кадр. Точнее использую там, где что-то нужно подождать без особой точности. То есть единственное их применение это await Singleton.timer_a.timeout. Ни в чем более менее важном они не участвуют.
Это всё хуйня, анон. Я хочу понять конкретно сколько правды в словах нейросети. А сказано было, что сигнал одного таймера нельзя использовать во множестве await одновременно, потому что может случиться, что один await станет ожидать сигнал, который в этом кадре занят другим авэйтом, сигнал отработает и авейт не отследит его и залипнет в бесконечном ожидании.
>>7725
Не, у меня всего несколько растений, но они должны симпатично расти. Они разворачивают форму ростка в блендшейпе. Потому там цикл while, который подкручивает блендшейп 10 раз в секунду, пока не достигнет 1.0. Звучит может калично, но большего этим росткам и не нужно. Я не видел смысл занимать этим процессом каждый кадр.
>>7742
Это RTX + DLSS, ты не шаришь, все серьезно.
Это RTX + DLSS, ты не шаришь, все серьезно.
>>7665
Надеюсь что крупные студии и команды не набигут на наш движок креативных мечтателей
Надеюсь что крупные студии и команды не набигут на наш движок креативных мечтателей
>>7755
Может ты через лупу смотрел, хз или не прочитал как её установить и настроить. Там уменьшены иконки, уменьшены отступы и расстояния, короче всё что можно
Может ты через лупу смотрел, хз или не прочитал как её установить и настроить. Там уменьшены иконки, уменьшены отступы и расстояния, короче всё что можно
>>7696
Единственный плюс от этого - тесты, а если на ведре встроенная компиляция в апк, то это вобще найс. За остальным, в годо, смарт в этом плане не пригоден.
Единственный плюс от этого - тесты, а если на ведре встроенная компиляция в апк, то это вобще найс. За остальным, в годо, смарт в этом плане не пригоден.
>>7775
плюс в том что любой поридж из нищей семьи может делать игру прямо на уроке на нонейм китайском планшете за с озона и не покупать пека для учобы
плюс в том что любой поридж из нищей семьи может делать игру прямо на уроке на нонейм китайском планшете за с озона и не покупать пека для учобы
https://oceanofpdf.com/authors/alan-thorn/pdf-epub-game-development-with-godot-4-download/
Новую книженцию притащил
Новую книженцию притащил
>>7776
Ну, технически, да.
Ну, технически, да.
>>7728
Порядок срабатывания этих авэйтов непредсказуем. И в какой-то момент гарантированно вылезет трудноуловимый баг из-за того, что хуйнянейм1 срабатывает раньше, чем хуйнянейм2, и роняет игру. Ещё хуже - если хуйнянейм1 и хуйнянейм2 сработают одновременно в разных потоках и начнут долбиться в одну и ту же область данных. Или таких хуйней окажется больше, чем доступно потоков.
Я не могу утверждать стопроцентно, какой из вариантов верный, но в любом случае выглядит как очень плохая затея.
Предлагаю другой вариант. Храни в синглтоне массив объектов такого вида:
class QueryEntry:
. var duration: float # общее время между срабатываниями
. var estimated: float # текущее время до срабатывания
. var function: Callable # функция, которая должна срабатывать
. var repeat: int #количество повторов, -1 это повторять бесконечно, 0 удалится сразу после добавления
. # конструктор для простоты использования
. func _init(dur: int, fnc: Callable, rep: int = -1) -> void:
. . duration = dur
. . estimated = dur
. . function = fnc
. . repeat = rep
# собсно объявляем массив
var query: Array[QueryEntry]
# И соответственно там же в синглтоне что-то типа такого:
func _process(delta: float) -> void:
. # удаляем лишние элементы - те, у которых указано 0 повторений
. query = query.filter(func(entry): return entry.repeat != 0)
. # основной цикл
. for entry in query:
. . entry.estimated -= delta
. . if entry.estimated <= 0:
. . . # проверка на случай, если, например, на том конце объект удалился
. . . if not is_instance_valid(entry.function):
. . . . entry.repeat = 0
. . . . continue
. . . entry.function.call()
. . . entry.repeat -= 1
. . . entry.estimated += entry.duration # сбрасываем время (но помним, что мы всё-таки проскочили на сколько-то через ноль)
Да, это костылесипед, зато даёт полный контроль над тем, что вызывается и в каком порядке. И ты всегда можешь в дебаге посмотреть на свою очередь. Соответственно, добавлять как-то так:
MySingleton.query.append(QueryEntry.new(10.0, GrowMyTreeGrow, -1))
Хотя это считается адвенсед техникуе, да и несколько проигрывает таймерам в производительности, зато контроль.
Ну или ПРОСТО создавай по таймеру на каждый объект. Там под капотом точно такая же очередь, только на плюсах - более производительно, даже если создашь по таймеру на каждое дерево.
Но вообще, фильтруй всё выше прочитанное, потому что я после празднования хеллуина немного бухой.
>сигнал одного таймера нельзя использовать во множестве await одновременно
Порядок срабатывания этих авэйтов непредсказуем. И в какой-то момент гарантированно вылезет трудноуловимый баг из-за того, что хуйнянейм1 срабатывает раньше, чем хуйнянейм2, и роняет игру. Ещё хуже - если хуйнянейм1 и хуйнянейм2 сработают одновременно в разных потоках и начнут долбиться в одну и ту же область данных. Или таких хуйней окажется больше, чем доступно потоков.
Я не могу утверждать стопроцентно, какой из вариантов верный, но в любом случае выглядит как очень плохая затея.
Предлагаю другой вариант. Храни в синглтоне массив объектов такого вида:
class QueryEntry:
. var duration: float # общее время между срабатываниями
. var estimated: float # текущее время до срабатывания
. var function: Callable # функция, которая должна срабатывать
. var repeat: int #количество повторов, -1 это повторять бесконечно, 0 удалится сразу после добавления
. # конструктор для простоты использования
. func _init(dur: int, fnc: Callable, rep: int = -1) -> void:
. . duration = dur
. . estimated = dur
. . function = fnc
. . repeat = rep
# собсно объявляем массив
var query: Array[QueryEntry]
# И соответственно там же в синглтоне что-то типа такого:
func _process(delta: float) -> void:
. # удаляем лишние элементы - те, у которых указано 0 повторений
. query = query.filter(func(entry): return entry.repeat != 0)
. # основной цикл
. for entry in query:
. . entry.estimated -= delta
. . if entry.estimated <= 0:
. . . # проверка на случай, если, например, на том конце объект удалился
. . . if not is_instance_valid(entry.function):
. . . . entry.repeat = 0
. . . . continue
. . . entry.function.call()
. . . entry.repeat -= 1
. . . entry.estimated += entry.duration # сбрасываем время (но помним, что мы всё-таки проскочили на сколько-то через ноль)
Да, это костылесипед, зато даёт полный контроль над тем, что вызывается и в каком порядке. И ты всегда можешь в дебаге посмотреть на свою очередь. Соответственно, добавлять как-то так:
MySingleton.query.append(QueryEntry.new(10.0, GrowMyTreeGrow, -1))
Хотя это считается адвенсед техникуе, да и несколько проигрывает таймерам в производительности, зато контроль.
Ну или ПРОСТО создавай по таймеру на каждый объект. Там под капотом точно такая же очередь, только на плюсах - более производительно, даже если создашь по таймеру на каждое дерево.
Но вообще, фильтруй всё выше прочитанное, потому что я после празднования хеллуина немного бухой.
>>7728
Порядок срабатывания этих авэйтов непредсказуем. И в какой-то момент гарантированно вылезет трудноуловимый баг из-за того, что хуйнянейм1 срабатывает раньше, чем хуйнянейм2, и роняет игру. Ещё хуже - если хуйнянейм1 и хуйнянейм2 сработают одновременно в разных потоках и начнут долбиться в одну и ту же область данных. Или таких хуйней окажется больше, чем доступно потоков.
Я не могу утверждать стопроцентно, какой из вариантов верный, но в любом случае выглядит как очень плохая затея.
Предлагаю другой вариант. Храни в синглтоне массив объектов такого вида:
class QueryEntry:
. var duration: float # общее время между срабатываниями
. var estimated: float # текущее время до срабатывания
. var function: Callable # функция, которая должна срабатывать
. var repeat: int #количество повторов, -1 это повторять бесконечно, 0 удалится сразу после добавления
. # конструктор для простоты использования
. func _init(dur: int, fnc: Callable, rep: int = -1) -> void:
. . duration = dur
. . estimated = dur
. . function = fnc
. . repeat = rep
# собсно объявляем массив
var query: Array[QueryEntry]
# И соответственно там же в синглтоне что-то типа такого:
func _process(delta: float) -> void:
. # удаляем лишние элементы - те, у которых указано 0 повторений
. query = query.filter(func(entry): return entry.repeat != 0)
. # основной цикл
. for entry in query:
. . entry.estimated -= delta
. . if entry.estimated <= 0:
. . . # проверка на случай, если, например, на том конце объект удалился
. . . if not is_instance_valid(entry.function):
. . . . entry.repeat = 0
. . . . continue
. . . entry.function.call()
. . . entry.repeat -= 1
. . . entry.estimated += entry.duration # сбрасываем время (но помним, что мы всё-таки проскочили на сколько-то через ноль)
Да, это костылесипед, зато даёт полный контроль над тем, что вызывается и в каком порядке. И ты всегда можешь в дебаге посмотреть на свою очередь. Соответственно, добавлять как-то так:
MySingleton.query.append(QueryEntry.new(10.0, GrowMyTreeGrow, -1))
Хотя это считается адвенсед техникуе, да и несколько проигрывает таймерам в производительности, зато контроль.
Ну или ПРОСТО создавай по таймеру на каждый объект. Там под капотом точно такая же очередь, только на плюсах - более производительно, даже если создашь по таймеру на каждое дерево.
Но вообще, фильтруй всё выше прочитанное, потому что я после празднования хеллуина немного бухой.
>сигнал одного таймера нельзя использовать во множестве await одновременно
Порядок срабатывания этих авэйтов непредсказуем. И в какой-то момент гарантированно вылезет трудноуловимый баг из-за того, что хуйнянейм1 срабатывает раньше, чем хуйнянейм2, и роняет игру. Ещё хуже - если хуйнянейм1 и хуйнянейм2 сработают одновременно в разных потоках и начнут долбиться в одну и ту же область данных. Или таких хуйней окажется больше, чем доступно потоков.
Я не могу утверждать стопроцентно, какой из вариантов верный, но в любом случае выглядит как очень плохая затея.
Предлагаю другой вариант. Храни в синглтоне массив объектов такого вида:
class QueryEntry:
. var duration: float # общее время между срабатываниями
. var estimated: float # текущее время до срабатывания
. var function: Callable # функция, которая должна срабатывать
. var repeat: int #количество повторов, -1 это повторять бесконечно, 0 удалится сразу после добавления
. # конструктор для простоты использования
. func _init(dur: int, fnc: Callable, rep: int = -1) -> void:
. . duration = dur
. . estimated = dur
. . function = fnc
. . repeat = rep
# собсно объявляем массив
var query: Array[QueryEntry]
# И соответственно там же в синглтоне что-то типа такого:
func _process(delta: float) -> void:
. # удаляем лишние элементы - те, у которых указано 0 повторений
. query = query.filter(func(entry): return entry.repeat != 0)
. # основной цикл
. for entry in query:
. . entry.estimated -= delta
. . if entry.estimated <= 0:
. . . # проверка на случай, если, например, на том конце объект удалился
. . . if not is_instance_valid(entry.function):
. . . . entry.repeat = 0
. . . . continue
. . . entry.function.call()
. . . entry.repeat -= 1
. . . entry.estimated += entry.duration # сбрасываем время (но помним, что мы всё-таки проскочили на сколько-то через ноль)
Да, это костылесипед, зато даёт полный контроль над тем, что вызывается и в каком порядке. И ты всегда можешь в дебаге посмотреть на свою очередь. Соответственно, добавлять как-то так:
MySingleton.query.append(QueryEntry.new(10.0, GrowMyTreeGrow, -1))
Хотя это считается адвенсед техникуе, да и несколько проигрывает таймерам в производительности, зато контроль.
Ну или ПРОСТО создавай по таймеру на каждый объект. Там под капотом точно такая же очередь, только на плюсах - более производительно, даже если создашь по таймеру на каждое дерево.
Но вообще, фильтруй всё выше прочитанное, потому что я после празднования хеллуина немного бухой.
>>7728
Ты страдаешь от преждевременных оптимизаций...
Для одноразовых таймеров достаточно этого:
А для повторяющихся лучше подключать метод:
Как работает await в данном случае:
1. Выполняется весь код функции перед await.
2. Создаётся закладка "вернуться сюда, когда..."
3. Происходит немедленный выход из функции.
4. Когда происходит событие, происходит переход на следующую строчку после await и выполняется весь остаток функции (или до следующего await).
Фактически await разделяет функцию на две:
1. Именованная точка входа - начало функции.
2. Безымянный обработчик события - конец.
Если await несколько, то всё ещё запутаннее...
Главный подводный камень await - это await в цикле, особенно в _process. Если у тебя есть что-то такое:
Тогда движок будет каждый кадр создавать новый безымянный обработчик события таймера - и когда сработает событие таймера, все эти обработчики выполнятся одновременно, т.е. заблокируют тебе выполнение любого другого кода игры. Например, с минутным интервалом таймера будет 3600+ таких безымянных обработчиков, которые сработают все одновременно и, скорее всего, подвесят тебе игру.
Но бывают и более хитрые случаи, когда ты сам по неосторожности вызываешь одну функцию с await несколько раз подряд, создавая очередь из таких безымянных обработчиков, которые могут просто испортить состояние объекта, в котором работают. Следовательно, нужно каким-то образом узнавать состояние "я уже жду этот сигнал", избегая лишнего. Собственно, именнованные обработчики сигнала невозможно подключить больше одного раза.
В общем и целом await следует использовать крайне аккуратно, только по необходимости, когда можешь гарантировать, что не произойдёт ничего лишнего:
Эта строчка в ноде-предке при выполнении до _ready задержит выполнение остального кода, пока ноды в потомках этой ноды не будут готовы. Всё остальное время эта строчка никак не будет влиять на код. Это может быть необходимо для сеттеров в @export var.
>для экономии вычислительной мощности
>смысл занимать этим процессом каждый кадр
Ты страдаешь от преждевременных оптимизаций...
>await ...timeout
Для одноразовых таймеров достаточно этого:
>await get_tree().create_timer(1.0).timeout
А для повторяющихся лучше подключать метод:
>$Timer.timeout.connect(_on_timer_timeout)
Как работает await в данном случае:
1. Выполняется весь код функции перед await.
2. Создаётся закладка "вернуться сюда, когда..."
3. Происходит немедленный выход из функции.
4. Когда происходит событие, происходит переход на следующую строчку после await и выполняется весь остаток функции (или до следующего await).
Фактически await разделяет функцию на две:
1. Именованная точка входа - начало функции.
2. Безымянный обработчик события - конец.
Если await несколько, то всё ещё запутаннее...
Главный подводный камень await - это await в цикле, особенно в _process. Если у тебя есть что-то такое:
>func _process(): await $Timer.timeout
Тогда движок будет каждый кадр создавать новый безымянный обработчик события таймера - и когда сработает событие таймера, все эти обработчики выполнятся одновременно, т.е. заблокируют тебе выполнение любого другого кода игры. Например, с минутным интервалом таймера будет 3600+ таких безымянных обработчиков, которые сработают все одновременно и, скорее всего, подвесят тебе игру.
Но бывают и более хитрые случаи, когда ты сам по неосторожности вызываешь одну функцию с await несколько раз подряд, создавая очередь из таких безымянных обработчиков, которые могут просто испортить состояние объекта, в котором работают. Следовательно, нужно каким-то образом узнавать состояние "я уже жду этот сигнал", избегая лишнего. Собственно, именнованные обработчики сигнала невозможно подключить больше одного раза.
В общем и целом await следует использовать крайне аккуратно, только по необходимости, когда можешь гарантировать, что не произойдёт ничего лишнего:
>if not is_node_ready(): await ready
Эта строчка в ноде-предке при выполнении до _ready задержит выполнение остального кода, пока ноды в потомках этой ноды не будут готовы. Всё остальное время эта строчка никак не будет влиять на код. Это может быть необходимо для сеттеров в @export var.
>>7728
Ты страдаешь от преждевременных оптимизаций...
Для одноразовых таймеров достаточно этого:
А для повторяющихся лучше подключать метод:
Как работает await в данном случае:
1. Выполняется весь код функции перед await.
2. Создаётся закладка "вернуться сюда, когда..."
3. Происходит немедленный выход из функции.
4. Когда происходит событие, происходит переход на следующую строчку после await и выполняется весь остаток функции (или до следующего await).
Фактически await разделяет функцию на две:
1. Именованная точка входа - начало функции.
2. Безымянный обработчик события - конец.
Если await несколько, то всё ещё запутаннее...
Главный подводный камень await - это await в цикле, особенно в _process. Если у тебя есть что-то такое:
Тогда движок будет каждый кадр создавать новый безымянный обработчик события таймера - и когда сработает событие таймера, все эти обработчики выполнятся одновременно, т.е. заблокируют тебе выполнение любого другого кода игры. Например, с минутным интервалом таймера будет 3600+ таких безымянных обработчиков, которые сработают все одновременно и, скорее всего, подвесят тебе игру.
Но бывают и более хитрые случаи, когда ты сам по неосторожности вызываешь одну функцию с await несколько раз подряд, создавая очередь из таких безымянных обработчиков, которые могут просто испортить состояние объекта, в котором работают. Следовательно, нужно каким-то образом узнавать состояние "я уже жду этот сигнал", избегая лишнего. Собственно, именнованные обработчики сигнала невозможно подключить больше одного раза.
В общем и целом await следует использовать крайне аккуратно, только по необходимости, когда можешь гарантировать, что не произойдёт ничего лишнего:
Эта строчка в ноде-предке при выполнении до _ready задержит выполнение остального кода, пока ноды в потомках этой ноды не будут готовы. Всё остальное время эта строчка никак не будет влиять на код. Это может быть необходимо для сеттеров в @export var.
>для экономии вычислительной мощности
>смысл занимать этим процессом каждый кадр
Ты страдаешь от преждевременных оптимизаций...
>await ...timeout
Для одноразовых таймеров достаточно этого:
>await get_tree().create_timer(1.0).timeout
А для повторяющихся лучше подключать метод:
>$Timer.timeout.connect(_on_timer_timeout)
Как работает await в данном случае:
1. Выполняется весь код функции перед await.
2. Создаётся закладка "вернуться сюда, когда..."
3. Происходит немедленный выход из функции.
4. Когда происходит событие, происходит переход на следующую строчку после await и выполняется весь остаток функции (или до следующего await).
Фактически await разделяет функцию на две:
1. Именованная точка входа - начало функции.
2. Безымянный обработчик события - конец.
Если await несколько, то всё ещё запутаннее...
Главный подводный камень await - это await в цикле, особенно в _process. Если у тебя есть что-то такое:
>func _process(): await $Timer.timeout
Тогда движок будет каждый кадр создавать новый безымянный обработчик события таймера - и когда сработает событие таймера, все эти обработчики выполнятся одновременно, т.е. заблокируют тебе выполнение любого другого кода игры. Например, с минутным интервалом таймера будет 3600+ таких безымянных обработчиков, которые сработают все одновременно и, скорее всего, подвесят тебе игру.
Но бывают и более хитрые случаи, когда ты сам по неосторожности вызываешь одну функцию с await несколько раз подряд, создавая очередь из таких безымянных обработчиков, которые могут просто испортить состояние объекта, в котором работают. Следовательно, нужно каким-то образом узнавать состояние "я уже жду этот сигнал", избегая лишнего. Собственно, именнованные обработчики сигнала невозможно подключить больше одного раза.
В общем и целом await следует использовать крайне аккуратно, только по необходимости, когда можешь гарантировать, что не произойдёт ничего лишнего:
>if not is_node_ready(): await ready
Эта строчка в ноде-предке при выполнении до _ready задержит выполнение остального кода, пока ноды в потомках этой ноды не будут готовы. Всё остальное время эта строчка никак не будет влиять на код. Это может быть необходимо для сеттеров в @export var.
>>7635
Сделай тест в отдельном проекте, смоделируй свою ситуацию (чтобы не разъебать основной проект). Займет минут 10-15 от силы.
Результаты сюда напиши, интересно.
Сделай тест в отдельном проекте, смоделируй свою ситуацию (чтобы не разъебать основной проект). Займет минут 10-15 от силы.
Результаты сюда напиши, интересно.
В твоем случае с таймерами ты получаешь не то что хочешь - лишние проблемы
Ты хочешь кеширование + call_deferred если результат не в кеше (чтобы код в idle запускался)
Ты хочешь кеширование + call_deferred если результат не в кеше (чтобы код в idle запускался)
У CollisionBody2d есть атрибут disable_mode, который определяет что происходит с физикой объекта когда process_mode = ... DISABLED. По умолчанию объект просто исчезает из физики и не коллайдит ни с чем, что логично.
TileMapLayer тоже может служить физическим объектом. Но если для него поставить процесс_моде равно дизаблид, то нихуя не происходит и он все еще коллайдит. Настройки дизабле_моде у тайлмаплейера нет.
Вот и думайте горловой.
TileMapLayer тоже может служить физическим объектом. Но если для него поставить процесс_моде равно дизаблид, то нихуя не происходит и он все еще коллайдит. Настройки дизабле_моде у тайлмаплейера нет.
Вот и думайте горловой.
>>7833
Оформляем ишью.
Оформляем ишью.
>>7844
Горловой?
Горловой?
>>7797
Ты по моему перепутал. Сигнал который испускает движок всегда синхронизирован с деревом сцены, а сигнал таймера испускает движок. Если ты испустишь сигнал в потоке единолично - то да, тогда последствия непредсказуемые, потому что вызов консьюмеров происходит из другого потока и кто знаком с особенностями многопотока годота знает, почему это страшно.
>сработают одновременно в разных потоках
Ты по моему перепутал. Сигнал который испускает движок всегда синхронизирован с деревом сцены, а сигнал таймера испускает движок. Если ты испустишь сигнал в потоке единолично - то да, тогда последствия непредсказуемые, потому что вызов консьюмеров происходит из другого потока и кто знаком с особенностями многопотока годота знает, почему это страшно.
Тред синглтонов здесь? Поясните, в чем отличие синглтона от класса, в котором я тупо пометил все переменные и функции как static? Нахуя какой-то отдельный одиночный объект создавать?
>>7896
Синглтон - (анти)паттерн, имеющий ДВА свойства:
1. Уникальность объекта (нельзя создать копию).
2. Глобальный доступ (вызов по одному имени).
Если одно не соблюдается - это НЕ синглтон.
Реальные синглтоны в Godot/GDScript невозможны.
Если ты об AutoLoad, то это было в движке давно, и называлось "синглтоном" некорректно, сейчас там переименовали надпись в "make global". Т.е. данные объекты не уникальны - их можно дублировать. Их назначение - загрузить что-то ДО загрузки главной (помеченной в редакторе) сцены и сохраняться при переключении сцен через SceneTree.change_scene(). Опасная штука, ведующая к трудностям в отладке.
Статическими переменные и методы стали недавно, некоторые баги с ними долго висели и я не в курсе, исправили уже или нет (особенно Array и Dictionary). Основное назначение - дать всем экземплярам единственное хранилище данных или общий метод, работающий с этим единственным хранилищем.
Но вот с их помощью стало возможно реализовать "подобие синглтону" - общий доступ к уникальному экземпляру данных, которые нельзя дублировать. Разумеется, это не объект, но сути это не маняет... Бессмысленный выстрел в ногу, имхо. Избегайте глобальных сущностей везде, где это возможно.
Как у больших дядь синглтон по-прежнему нельзя реализовать, поскольку в Godot нет нормального конструктора у классов, _init слишком ограничен, ограничивать видимость методов тоже нельзя...
Короче, это мутная тема, но главное тут: проблемы начинаются не из-за уникальности синглтона, а от глобального доступа к нему. Поэтому глобальные автолоады ничем не лучше синглтонов. Ещё и GUI уродливый - прячет их куда-то глубоко в меню.
>>7898 (Del)
Зачем ты скопипастил ответ какой-то LLM? Если бы спрашивающий хотел ответ LLM, он бы сам лично её спросил, а не шёл на форум. Тем более что в данном случае ответ LLM про синглтоны из ЯП типа Java, не учитывающий особенностей Godot и GDScript.
Синглтон - (анти)паттерн, имеющий ДВА свойства:
1. Уникальность объекта (нельзя создать копию).
2. Глобальный доступ (вызов по одному имени).
Если одно не соблюдается - это НЕ синглтон.
Реальные синглтоны в Godot/GDScript невозможны.
Если ты об AutoLoad, то это было в движке давно, и называлось "синглтоном" некорректно, сейчас там переименовали надпись в "make global". Т.е. данные объекты не уникальны - их можно дублировать. Их назначение - загрузить что-то ДО загрузки главной (помеченной в редакторе) сцены и сохраняться при переключении сцен через SceneTree.change_scene(). Опасная штука, ведующая к трудностям в отладке.
Статическими переменные и методы стали недавно, некоторые баги с ними долго висели и я не в курсе, исправили уже или нет (особенно Array и Dictionary). Основное назначение - дать всем экземплярам единственное хранилище данных или общий метод, работающий с этим единственным хранилищем.
Но вот с их помощью стало возможно реализовать "подобие синглтону" - общий доступ к уникальному экземпляру данных, которые нельзя дублировать. Разумеется, это не объект, но сути это не маняет... Бессмысленный выстрел в ногу, имхо. Избегайте глобальных сущностей везде, где это возможно.
Как у больших дядь синглтон по-прежнему нельзя реализовать, поскольку в Godot нет нормального конструктора у классов, _init слишком ограничен, ограничивать видимость методов тоже нельзя...
Короче, это мутная тема, но главное тут: проблемы начинаются не из-за уникальности синглтона, а от глобального доступа к нему. Поэтому глобальные автолоады ничем не лучше синглтонов. Ещё и GUI уродливый - прячет их куда-то глубоко в меню.
>>7898 (Del)
Зачем ты скопипастил ответ какой-то LLM? Если бы спрашивающий хотел ответ LLM, он бы сам лично её спросил, а не шёл на форум. Тем более что в данном случае ответ LLM про синглтоны из ЯП типа Java, не учитывающий особенностей Godot и GDScript.
>>7908
...хотя не, уникальность тоже может выйти боком. В частности, Godot по умолчанию копирует ссылку на ресурсный объект, не делая его дубликат - что часто приводит к ошибкам пользователя, когда ты вроде дублировал ноду, а её ресурс не дублировался - т.е. остаётся уникальным даже без глобального имени. Приходится вручную дублировать нужные ресурсы.
>>7910
Ты про "survival game" или "vampire survivors"? В одном посте всё не распишешь, так что ищи сам туториалы. Вроде много есть на обе темы... Но тебе, наверное, сначала лучше пройтись по классическим играм - попробовать сделать Pong, Asteroids, Breakout, Tetris. С опытом разработки этих игр ты бы не задавался настолько широким вопросом "как сделать survival".
>проблемы начинаются не из-за уникальности
...хотя не, уникальность тоже может выйти боком. В частности, Godot по умолчанию копирует ссылку на ресурсный объект, не делая его дубликат - что часто приводит к ошибкам пользователя, когда ты вроде дублировал ноду, а её ресурс не дублировался - т.е. остаётся уникальным даже без глобального имени. Приходится вручную дублировать нужные ресурсы.
>>7910
>сюрвалик
Ты про "survival game" или "vampire survivors"? В одном посте всё не распишешь, так что ищи сам туториалы. Вроде много есть на обе темы... Но тебе, наверное, сначала лучше пройтись по классическим играм - попробовать сделать Pong, Asteroids, Breakout, Tetris. С опытом разработки этих игр ты бы не задавался настолько широким вопросом "как сделать survival".
>>7913
Попробуй сначала официальные туториалы:
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Как раз что-то типа "вампиров" без способностей.
>>7918
А потом переделываешь, переделываешь...
>>7912
Кому ты врёшь, мелкобуква? Я знаю сленг LLMок.
Попробуй сначала официальные туториалы:
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Как раз что-то типа "вампиров" без способностей.
>>7918
>без задней мысли. Подходишь и делаешь
А потом переделываешь, переделываешь...
>>7912
>нет, я сам написал
Кому ты врёшь, мелкобуква? Я знаю сленг LLMок.
>Я знаю сленг LLMок.
Шизы спок, хватит чатгопоту ИТТ искать, у нас своих аутистов хватает, писавших мегапортянки в гопота-стиле еще до рождения гопоты.
>>7922
По-твоему, это не стиль "ассистента"? >>7898 (Del)
Но это ведь другой аутист...
>хватит чатгопоту ИТТ искать
По-твоему, это не стиль "ассистента"? >>7898 (Del)
>Ключевые отличия и "нахуя это нужно"
>вы вы вы вы вы вы... (на дваче)
>java (в Godot-треде)
>своих аутистов хватает, писавших мегапортянки
Но это ведь другой аутист...
>>7922
Никто её не ищет, она просто детектируется естественным образом, потому что роботы еще не смогли пройти тест Тьюринга.
> Шизы спок, хватит чатгопоту ИТТ искать,
Никто её не ищет, она просто детектируется естественным образом, потому что роботы еще не смогли пройти тест Тьюринга.
>>7856
Специально уточнил, что не уверен.
Просто недавно прогу писал (клиента для одного линуксового демона), и там коллбэки от демона могут прилететь в любом потоке, не обязательно в главном. И я подзабыл, как оно в годоте.
>>7896
Годотский синглтон не обязательно должен быть объектом, это может быть нода или даже целая сцена. И в общем случае, если вот такой функционал тебе не нужен, - юзай статический класс. А если нужен - скорее всего, ты что-то делаешь не так, пересмотри архитектуру проекта.
Ну или ты точно знаешь, что делаешь, и тогда не мне тебя учить.
>>7908
Ничоси ты вежливый
>Ты по моему перепутал
Специально уточнил, что не уверен.
Просто недавно прогу писал (клиента для одного линуксового демона), и там коллбэки от демона могут прилететь в любом потоке, не обязательно в главном. И я подзабыл, как оно в годоте.
>>7896
Годотский синглтон не обязательно должен быть объектом, это может быть нода или даже целая сцена. И в общем случае, если вот такой функционал тебе не нужен, - юзай статический класс. А если нужен - скорее всего, ты что-то делаешь не так, пересмотри архитектуру проекта.
Ну или ты точно знаешь, что делаешь, и тогда не мне тебя учить.
>>7908
>Зачем
Ничоси ты вежливый
>Синглтон - антипаттерн
И это говорят люди которые не одного теста в жизни не написали..
>>7896
Есть два понятия синглтона
1) Паттерн. Класс который имеет статический метод (например getInstance) для получения уникального инстанса этого класса, всегда одного и того же. Получается что класс хранит инстанс самого себя. Считается антипаттерном, как и все статические фабрики, потому что сложно тестировать код с такой хуйней.
2) Синглтон как уникальный сервис в DI контейнере. Создается DI ситемой, которая передает один же и тот инстанс некоторого класса в конструкторы пользователей этого класса. Не считается анипаттерном, легко тестируется, широко используется в анемичной архитектуре.
Судя по твоему вопросу ты хочешь сделать не синглтон 1) а сервис локатор вместо DI
Есть два понятия синглтона
1) Паттерн. Класс который имеет статический метод (например getInstance) для получения уникального инстанса этого класса, всегда одного и того же. Получается что класс хранит инстанс самого себя. Считается антипаттерном, как и все статические фабрики, потому что сложно тестировать код с такой хуйней.
2) Синглтон как уникальный сервис в DI контейнере. Создается DI ситемой, которая передает один же и тот инстанс некоторого класса в конструкторы пользователей этого класса. Не считается анипаттерном, легко тестируется, широко используется в анемичной архитектуре.
Судя по твоему вопросу ты хочешь сделать не синглтон 1) а сервис локатор вместо DI
>>8031
ЗЫ. Еще есть годная книжка для годотодетей которые хотят думать об архитектуре
https://github.com/PacktPublishing/Game-Development-Patterns-with-Godot-4
ЗЫ. Еще есть годная книжка для годотодетей которые хотят думать об архитектуре
https://github.com/PacktPublishing/Game-Development-Patterns-with-Godot-4
>>8031
Это ты просто в /pr/ограммач не заходил, там всё считается антипаттерном, даже SOLID, даже небо, даже Аллах.
> Не считается анипаттерном
Это ты просто в /pr/ограммач не заходил, там всё считается антипаттерном, даже SOLID, даже небо, даже Аллах.
>>8059
Там поголовно ddd/компоненты головного мозга у бэков и фронтов соответственно, с этими людьми говорить не о чем, у них задача делать индемпонентные ручки и они их делают
Там поголовно ddd/компоненты головного мозга у бэков и фронтов соответственно, с этими людьми говорить не о чем, у них задача делать индемпонентные ручки и они их делают
>>8113
А чего там, по 4.6 уже книга?
А чего там, по 4.6 уже книга?
Цветное лого выглядит отстойно, коряво, непрофессионально.
Монохромное - заебись.
Когда они уже везде на монохром перейдут? Нахуй эти чОрные глаза, смотрящие в мою безыгровую душу?
Монохромное - заебись.
Когда они уже везде на монохром перейдут? Нахуй эти чОрные глаза, смотрящие в мою безыгровую душу?
Сделал кринжовый рисунок с Годеттой. Стыдно...
Как вы побеждаете стыд от своего творчества?
Как вы побеждаете стыд от своего творчества?
>>8127
дрочу на него
дрочу на него
>>8127
Заворачиваюсь в одеяло, закрываю вкладку с сайтом где опозорился и не захожу туда гдет неделю, просто сижу пью пиво и прокручиваю позорный момент слушая думерскую музыку на ютубе, плачу иногда, и думаю для чего и кого вообще это делаю, ведь это только мне нравится, а денег все равно не заработаю.
Когда отпускает продолжаю пилить.
Заворачиваюсь в одеяло, закрываю вкладку с сайтом где опозорился и не захожу туда гдет неделю, просто сижу пью пиво и прокручиваю позорный момент слушая думерскую музыку на ютубе, плачу иногда, и думаю для чего и кого вообще это делаю, ведь это только мне нравится, а денег все равно не заработаю.
Когда отпускает продолжаю пилить.
>>8136
А мог бы начать семенить и поддерживать себя.
А мог бы начать семенить и поддерживать себя.
47 Кб, 270x270>>8121
По мне так вообще лепить чью-либо мордочку на лого - не професионально. Вот стилизованный куб под углом - заебись. Предлагаю переделать лого годота на пирамидку
По мне так вообще лепить чью-либо мордочку на лого - не професионально. Вот стилизованный куб под углом - заебись. Предлагаю переделать лого годота на пирамидку
545 Кб, 8586x8165>>8139
Нихуя. Надо пятиконечную звезду. Символизирующую пять столпов, на которых стоит Годот.
1. Белые ноды.
2. Красные ноды.
3. Зелёные ноды.
4. Синие ноды.
5. ГДСкрипт.
> Предлагаю переделать лого годота на пирамидку
Нихуя. Надо пятиконечную звезду. Символизирующую пять столпов, на которых стоит Годот.
1. Белые ноды.
2. Красные ноды.
3. Зелёные ноды.
4. Синие ноды.
5. ГДСкрипт.
>>8166
Не позволено.
Не позволено.
>>8172
Тактикульно...
Но я всеравно не понел. Этого значка не было - все работало. Появился - все тоже работает.
Тактикульно...
Но я всеравно не понел. Этого значка не было - все работало. Появился - все тоже работает.
>>8173
Он тебе напиздел. Эта хуйня не дает тебе случайно заселектить чилдрены на сцене. Вообще не надейся методом тыка изучить гейдев
Он тебе напиздел. Эта хуйня не дает тебе случайно заселектить чилдрены на сцене. Вообще не надейся методом тыка изучить гейдев
>>8174
Оно не позволяет кликнуть на ноды-чилдрены в визуальном редакторе.
Оно не позволяет кликнуть на ноды-чилдрены в визуальном редакторе.
9 Кб, 389x177>>8176
Хуле напиздел-то? Вот, читай - группировка выбранных нод. Моя группировка нод уже окружила твою группировку жалких недонод.
Хуле напиздел-то? Вот, читай - группировка выбранных нод. Моя группировка нод уже окружила твою группировку жалких недонод.
>>8178
Прочитал: мейк селектед нодс чилдрен нот селектабл - сделать детей выбранной ноды невыбираемыми
Прочитал: мейк селектед нодс чилдрен нот селектабл - сделать детей выбранной ноды невыбираемыми
221 Кб, 1440x810Чуваки, а какой движоклучше для новичка нового ньюфага в геймдеве? Выбирал между годот и гейммейкером. Решил что годот.
>>8198
Бери годот
Бери годот
>>8198
В такой конфигурации выбора - разумеется годот. Если добавить к конфигурации еще варианты движков - вполне вероятно что будут варики получше. Но такой вопрос если хочешь конкретики лучше в движкосраче спрашивай, в этом треде за любую не-годот конкретику пизды дают.
В такой конфигурации выбора - разумеется годот. Если добавить к конфигурации еще варианты движков - вполне вероятно что будут варики получше. Но такой вопрос если хочешь конкретики лучше в движкосраче спрашивай, в этом треде за любую не-годот конкретику пизды дают.
162 Кб, 365x441>>8198
Тот который тебе нравится, на котором лично тебе приятно работать. Скачай несколько и попробуй все. Если этим движком окажется Годот, возвращайся, будем рады обменяться с тобой знаниями.
> а какой движоклучше для новичка нового ньюфага в геймдеве?
Тот который тебе нравится, на котором лично тебе приятно работать. Скачай несколько и попробуй все. Если этим движком окажется Годот, возвращайся, будем рады обменяться с тобой знаниями.
>>8229
А где мне их ещё делать?
А где мне их ещё делать?
>>8198
У нас тут самый живой тред, и спрашиваешь ты в годот-треде, так что очевидно годот.
У нас тут самый живой тред, и спрашиваешь ты в годот-треде, так что очевидно годот.
114 Кб, 1330x736Как много автолоадов считается слишком много?
Я тут набрал пару десятков, но в целом это всё нужные вещи. Трекеры отвечают за хранение и взаимодействие с ресурсами, Logic'и отвечают за изменения состояний вещей в игре. Например в CutsceneLogic я прописываю функции, вызываемые после отображения какой-то катсцены. Логики вызывают только либо другой логик, либо свой трекер. Так я могу из диалога запустить катсцену, из катсцены добавить предмет в инвентарь, из завершения квеста вызвать катсцену и так далее. Очень гибкая структура, очень полезна для того, что я пишу.
Я тут набрал пару десятков, но в целом это всё нужные вещи. Трекеры отвечают за хранение и взаимодействие с ресурсами, Logic'и отвечают за изменения состояний вещей в игре. Например в CutsceneLogic я прописываю функции, вызываемые после отображения какой-то катсцены. Логики вызывают только либо другой логик, либо свой трекер. Так я могу из диалога запустить катсцену, из катсцены добавить предмет в инвентарь, из завершения квеста вызвать катсцену и так далее. Очень гибкая структура, очень полезна для того, что я пишу.
>>8253
Это ты специально да, специально нашего синглтона-шиза триггеришь? Я уже скорую ему вызываю.
Это ты специально да, специально нашего синглтона-шиза триггеришь? Я уже скорую ему вызываю.
>>8256
Я не вижу ничего плохого в автолоадах годота. Если движок даёт возможность, значит ей можно пользоваться. Просто нужно это делать аккуратно.
Мы всё-таки игры делаем, а не энтерпрайз-решения для заказчиков.
Я не вижу ничего плохого в автолоадах годота. Если движок даёт возможность, значит ей можно пользоваться. Просто нужно это делать аккуратно.
Мы всё-таки игры делаем, а не энтерпрайз-решения для заказчиков.
>>8273
Если опыт программирования в целом есть - возможно, с натяжкой, успеешь. Если опыта нет - хуй. Если еще и ассеты сам рисовать планируешь - хуй в квадрате, целься на год обучения + работы.
Если опыт программирования в целом есть - возможно, с натяжкой, успеешь. Если опыта нет - хуй. Если еще и ассеты сам рисовать планируешь - хуй в квадрате, целься на год обучения + работы.
>>8274
Ладно выкупил, сяп
Ладно выкупил, сяп
>>8271
Я сам программист со стажем, но прежде чем сделать что-то более-менее вменяемое в годоте, я потратил 100 часов на разные маленькие проектики, в которых просто всякие разные ноды и скрипты как-то взаимодействовали. В геймдеве нет магической таблетки, которая делает всё за тебя. Это долгий и упорный труд, и особенно опыт.
Я сам программист со стажем, но прежде чем сделать что-то более-менее вменяемое в годоте, я потратил 100 часов на разные маленькие проектики, в которых просто всякие разные ноды и скрипты как-то взаимодействовали. В геймдеве нет магической таблетки, которая делает всё за тебя. Это долгий и упорный труд, и особенно опыт.
>>8279
Ну у меня и опыта в программировании 5 лет.
Так что гдскрипт я относительно быстро понял. За сотню часов более-менее разобрался.
И да, я разобрался только с 2Д вещами. 3Д я даже не трогал.
Ну у меня и опыта в программировании 5 лет.
Так что гдскрипт я относительно быстро понял. За сотню часов более-менее разобрался.
И да, я разобрался только с 2Д вещами. 3Д я даже не трогал.
1,6 Мб, webm,1278x720, 0:17
>>8285
Спасибо!
>>8283
Дорогу осилит идущий, анон. Как в любом хобби, 95% желающих отваливаются в самом начале. До завершения проекта доходят сотни, а качественный продукт создают лишь единицы.
Раз уж такое дело, то закину сюда вебмку с игрой. Я как раз закончил ядро игры, только что мягкие переходы сделал между локациями. Готовы основные механики: инвентарь, квесты, статусы квестов, диалоги, система динамического состояния объектов, катсцены, звуковая система, загрузка и сохранение корректные.
Будет недо-рпг, недо-имеррсив сим, где нужно играя за правительственного агента сделать так, чтобы текущий мэр города проиграл на предстоящих выборах. Делается это путем взаимодействия с фракциями города, предлагая/торгуясь/шантажируя их голосовать за других кандидатов, так как на старте почти все фракции голосуют за мэра.
Так-то это бродилка, но она очень сильно разбавлена большими возможностями выбора игрока, разными исходами ситуаций.
Я даже нашел уже начинающего художника, который пилит потихоньку графику в игре. Первая лока и спрайты главного героя - его работа. Остальное я сам рисовал на скорую руку, чисто чтобы было видно. Плохой из меня художник.
Ну и движок годот, естественно.
Спасибо!
>>8283
Дорогу осилит идущий, анон. Как в любом хобби, 95% желающих отваливаются в самом начале. До завершения проекта доходят сотни, а качественный продукт создают лишь единицы.
Раз уж такое дело, то закину сюда вебмку с игрой. Я как раз закончил ядро игры, только что мягкие переходы сделал между локациями. Готовы основные механики: инвентарь, квесты, статусы квестов, диалоги, система динамического состояния объектов, катсцены, звуковая система, загрузка и сохранение корректные.
Будет недо-рпг, недо-имеррсив сим, где нужно играя за правительственного агента сделать так, чтобы текущий мэр города проиграл на предстоящих выборах. Делается это путем взаимодействия с фракциями города, предлагая/торгуясь/шантажируя их голосовать за других кандидатов, так как на старте почти все фракции голосуют за мэра.
Так-то это бродилка, но она очень сильно разбавлена большими возможностями выбора игрока, разными исходами ситуаций.
Я даже нашел уже начинающего художника, который пилит потихоньку графику в игре. Первая лока и спрайты главного героя - его работа. Остальное я сам рисовал на скорую руку, чисто чтобы было видно. Плохой из меня художник.
Ну и движок годот, естественно.
>>8288
Судя по стиму 82,7 часов потратил на всё что сейчас есть.
Систему диалогов я не стал писать сам, взял Dialogic 2, в целом он способен в рпг-стайл диалоги, плюсом из него можно что-угодно в игре вызвать, так что они будут очень богатые в этом плане. Были тесты, я могу хоть квест обновить из диалога, хоть дать/забрать у игрока предмет, хоть катсцену запустить после диалога.
Судя по стиму 82,7 часов потратил на всё что сейчас есть.
Систему диалогов я не стал писать сам, взял Dialogic 2, в целом он способен в рпг-стайл диалоги, плюсом из него можно что-угодно в игре вызвать, так что они будут очень богатые в этом плане. Были тесты, я могу хоть квест обновить из диалога, хоть дать/забрать у игрока предмет, хоть катсцену запустить после диалога.
271 Кб, webm,1278x720, 0:09
>>8288
Да, если интересно, то вот диалог с тестовым болванчиком. Диалоджик позволяет кастомные сцены диалогов рисовать, так что я немного заморочился. На лица можешь не смотреть, это ворованное, пока художник красиво не сделает, да и сцена тестовая.
Да, если интересно, то вот диалог с тестовым болванчиком. Диалоджик позволяет кастомные сцены диалогов рисовать, так что я немного заморочился. На лица можешь не смотреть, это ворованное, пока художник красиво не сделает, да и сцена тестовая.
>>8293
Это, наверно, самый частый вопрос, который я слышал про свою игру, когда я про неё кому-то рассказываю.
От рпг-мейкера мне нужна только диалоговая система. Всё остальное там будет только мешать. Не говоря уже о том, что я хотел игру делать именно на годоте, и долго к этому шел.
Это, наверно, самый частый вопрос, который я слышал про свою игру, когда я про неё кому-то рассказываю.
От рпг-мейкера мне нужна только диалоговая система. Всё остальное там будет только мешать. Не говоря уже о том, что я хотел игру делать именно на годоте, и долго к этому шел.
>>8295
Лол, что?
У тебя какой браузер? В хроме и правда почему-то не открывается, а в файрфоксе норм работает. Странно. Но чтобы систему вешал - это вообще непонятно.
Лол, что?
У тебя какой браузер? В хроме и правда почему-то не открывается, а в файрфоксе норм работает. Странно. Но чтобы систему вешал - это вообще непонятно.
>>8253 >>8257
Ты можешь хоть весь код игры в одном _process() в MainLoop записать и это будет работать:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Беда глобального доступа к сцене в автозагрузке заключается в том, что игру становится практически невозможно тестировать по частям и изменять эти автозагрузочные компоненты радикально, а связи становится сложнее изучать из-за монолитности.
Почему невозможно тестировать по частям? Скрипт автозагрузки стартует с любой сценой даже по F6. Исключить этой скрипт можно лишь исключением из настроек проекта. Но если ты к нему по имени как-то обращаешься, то ты уже не имеешь права его просто исключать. То есть он прибит гвоздями к проекту. Становится невозможно рассматривать какую-либо отдельную зону игры отдельно от этого скрипта.
Почему сложнее изучать? Во-первых, у тебя нет нормального способа узнать, из каких мест идут все обращения к скрипту в автозагрузке. Да, ты можешь использовать поиск по имени во всех файлах, но это костыльное, неудобное решение. То есть любой файл теоретически можео дёргать за твой скрипт и это заставляет тебя долго перекапывать проект для собственного понимания его работы. Во-вторых, концентрация связей в одном месте создаёт "узел", взаимодействующий со многими сущностями, и это банально сложнее удерживать в памяти, когда ты пытаешься разобраться в каком-то компоненте. Т.е. единственный источник влияет сразу на многое.
Из этого следует сложность модификации - чтобы переработать этот скрипт, тебе нужно внести много изменений по всему проекту, которые сложно будет определить с первого взгляда и придётся сильно полагаться на ошибки компиляции/рантайма. Тут, возможно, проще игру с нуля начать, чем вносить модификации в автозагрузочные скрипты.
Из всего этого следует то, что ты не можешь просто обновить какие-то сторонние плагины, если ты уже используешь их как автозагрузочные скрипты; твои собственные решения, потенциально ошибочные, принятные в начале разработки, нельзя просто так выбросить из проекта или даже немного изменить. Разобраться в проекте через месяц отдыха тоже проблематично, а игры делаются обычно долго.
И это касается не только "автозагрузки". Слишком полагаться на статические члены классов будет аналогичной ошибкой, только вместо UI настроек в редакторе будет "наличие скрипта в папке проекта".
Суть в том, что если что-то есть и работает, не стоит вслепую полагаться на это. Многие инструменты в программировании предназначены только для одноразовых, временных костылей, т.е. чаще для ликвидации последствий старых ошибок. Или же - призраком тёмного прошлого. Типа, никто из вас не согласится писать на ассемблере и не будет менять отдельные биты в памяти через дизассемблер, хотя теоретически этого более чем достаточно для игр.
Ты можешь хоть весь код игры в одном _process() в MainLoop записать и это будет работать:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Беда глобального доступа к сцене в автозагрузке заключается в том, что игру становится практически невозможно тестировать по частям и изменять эти автозагрузочные компоненты радикально, а связи становится сложнее изучать из-за монолитности.
Почему невозможно тестировать по частям? Скрипт автозагрузки стартует с любой сценой даже по F6. Исключить этой скрипт можно лишь исключением из настроек проекта. Но если ты к нему по имени как-то обращаешься, то ты уже не имеешь права его просто исключать. То есть он прибит гвоздями к проекту. Становится невозможно рассматривать какую-либо отдельную зону игры отдельно от этого скрипта.
Почему сложнее изучать? Во-первых, у тебя нет нормального способа узнать, из каких мест идут все обращения к скрипту в автозагрузке. Да, ты можешь использовать поиск по имени во всех файлах, но это костыльное, неудобное решение. То есть любой файл теоретически можео дёргать за твой скрипт и это заставляет тебя долго перекапывать проект для собственного понимания его работы. Во-вторых, концентрация связей в одном месте создаёт "узел", взаимодействующий со многими сущностями, и это банально сложнее удерживать в памяти, когда ты пытаешься разобраться в каком-то компоненте. Т.е. единственный источник влияет сразу на многое.
Из этого следует сложность модификации - чтобы переработать этот скрипт, тебе нужно внести много изменений по всему проекту, которые сложно будет определить с первого взгляда и придётся сильно полагаться на ошибки компиляции/рантайма. Тут, возможно, проще игру с нуля начать, чем вносить модификации в автозагрузочные скрипты.
Из всего этого следует то, что ты не можешь просто обновить какие-то сторонние плагины, если ты уже используешь их как автозагрузочные скрипты; твои собственные решения, потенциально ошибочные, принятные в начале разработки, нельзя просто так выбросить из проекта или даже немного изменить. Разобраться в проекте через месяц отдыха тоже проблематично, а игры делаются обычно долго.
И это касается не только "автозагрузки". Слишком полагаться на статические члены классов будет аналогичной ошибкой, только вместо UI настроек в редакторе будет "наличие скрипта в папке проекта".
Суть в том, что если что-то есть и работает, не стоит вслепую полагаться на это. Многие инструменты в программировании предназначены только для одноразовых, временных костылей, т.е. чаще для ликвидации последствий старых ошибок. Или же - призраком тёмного прошлого. Типа, никто из вас не согласится писать на ассемблере и не будет менять отдельные биты в памяти через дизассемблер, хотя теоретически этого более чем достаточно для игр.
>>8253 >>8257
Ты можешь хоть весь код игры в одном _process() в MainLoop записать и это будет работать:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Беда глобального доступа к сцене в автозагрузке заключается в том, что игру становится практически невозможно тестировать по частям и изменять эти автозагрузочные компоненты радикально, а связи становится сложнее изучать из-за монолитности.
Почему невозможно тестировать по частям? Скрипт автозагрузки стартует с любой сценой даже по F6. Исключить этой скрипт можно лишь исключением из настроек проекта. Но если ты к нему по имени как-то обращаешься, то ты уже не имеешь права его просто исключать. То есть он прибит гвоздями к проекту. Становится невозможно рассматривать какую-либо отдельную зону игры отдельно от этого скрипта.
Почему сложнее изучать? Во-первых, у тебя нет нормального способа узнать, из каких мест идут все обращения к скрипту в автозагрузке. Да, ты можешь использовать поиск по имени во всех файлах, но это костыльное, неудобное решение. То есть любой файл теоретически можео дёргать за твой скрипт и это заставляет тебя долго перекапывать проект для собственного понимания его работы. Во-вторых, концентрация связей в одном месте создаёт "узел", взаимодействующий со многими сущностями, и это банально сложнее удерживать в памяти, когда ты пытаешься разобраться в каком-то компоненте. Т.е. единственный источник влияет сразу на многое.
Из этого следует сложность модификации - чтобы переработать этот скрипт, тебе нужно внести много изменений по всему проекту, которые сложно будет определить с первого взгляда и придётся сильно полагаться на ошибки компиляции/рантайма. Тут, возможно, проще игру с нуля начать, чем вносить модификации в автозагрузочные скрипты.
Из всего этого следует то, что ты не можешь просто обновить какие-то сторонние плагины, если ты уже используешь их как автозагрузочные скрипты; твои собственные решения, потенциально ошибочные, принятные в начале разработки, нельзя просто так выбросить из проекта или даже немного изменить. Разобраться в проекте через месяц отдыха тоже проблематично, а игры делаются обычно долго.
И это касается не только "автозагрузки". Слишком полагаться на статические члены классов будет аналогичной ошибкой, только вместо UI настроек в редакторе будет "наличие скрипта в папке проекта".
Суть в том, что если что-то есть и работает, не стоит вслепую полагаться на это. Многие инструменты в программировании предназначены только для одноразовых, временных костылей, т.е. чаще для ликвидации последствий старых ошибок. Или же - призраком тёмного прошлого. Типа, никто из вас не согласится писать на ассемблере и не будет менять отдельные биты в памяти через дизассемблер, хотя теоретически этого более чем достаточно для игр.
Ты можешь хоть весь код игры в одном _process() в MainLoop записать и это будет работать:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Беда глобального доступа к сцене в автозагрузке заключается в том, что игру становится практически невозможно тестировать по частям и изменять эти автозагрузочные компоненты радикально, а связи становится сложнее изучать из-за монолитности.
Почему невозможно тестировать по частям? Скрипт автозагрузки стартует с любой сценой даже по F6. Исключить этой скрипт можно лишь исключением из настроек проекта. Но если ты к нему по имени как-то обращаешься, то ты уже не имеешь права его просто исключать. То есть он прибит гвоздями к проекту. Становится невозможно рассматривать какую-либо отдельную зону игры отдельно от этого скрипта.
Почему сложнее изучать? Во-первых, у тебя нет нормального способа узнать, из каких мест идут все обращения к скрипту в автозагрузке. Да, ты можешь использовать поиск по имени во всех файлах, но это костыльное, неудобное решение. То есть любой файл теоретически можео дёргать за твой скрипт и это заставляет тебя долго перекапывать проект для собственного понимания его работы. Во-вторых, концентрация связей в одном месте создаёт "узел", взаимодействующий со многими сущностями, и это банально сложнее удерживать в памяти, когда ты пытаешься разобраться в каком-то компоненте. Т.е. единственный источник влияет сразу на многое.
Из этого следует сложность модификации - чтобы переработать этот скрипт, тебе нужно внести много изменений по всему проекту, которые сложно будет определить с первого взгляда и придётся сильно полагаться на ошибки компиляции/рантайма. Тут, возможно, проще игру с нуля начать, чем вносить модификации в автозагрузочные скрипты.
Из всего этого следует то, что ты не можешь просто обновить какие-то сторонние плагины, если ты уже используешь их как автозагрузочные скрипты; твои собственные решения, потенциально ошибочные, принятные в начале разработки, нельзя просто так выбросить из проекта или даже немного изменить. Разобраться в проекте через месяц отдыха тоже проблематично, а игры делаются обычно долго.
И это касается не только "автозагрузки". Слишком полагаться на статические члены классов будет аналогичной ошибкой, только вместо UI настроек в редакторе будет "наличие скрипта в папке проекта".
Суть в том, что если что-то есть и работает, не стоит вслепую полагаться на это. Многие инструменты в программировании предназначены только для одноразовых, временных костылей, т.е. чаще для ликвидации последствий старых ошибок. Или же - призраком тёмного прошлого. Типа, никто из вас не согласится писать на ассемблере и не будет менять отдельные биты в памяти через дизассемблер, хотя теоретически этого более чем достаточно для игр.
1,3 Мб, webm,1278x720, 0:17
>>8295
Вот тебе еще раз переконвертированная первая вебмка. Прости, что повесил тебе систему, не думал, что такое вообще возможно. А в хроме и правда не воспроизвелась почему-то.
Всё, хватит своей игрой пока срать. Пойду отдыхать.
>>8299
Ты демку закинул или уже полностью готовую? Бесплатная? Не планируешь её продавать?
Вот тебе еще раз переконвертированная первая вебмка. Прости, что повесил тебе систему, не думал, что такое вообще возможно. А в хроме и правда не воспроизвелась почему-то.
Всё, хватит своей игрой пока срать. Пойду отдыхать.
>>8299
Ты демку закинул или уже полностью готовую? Бесплатная? Не планируешь её продавать?
А я совершаю вот уже третью попытку собрать инверсную кинематику ног, которая корректируют высоту и положение стопы и третий раз на первой же трудности бросаю с мыслями "у меня нету времени на такие мелочи".
Дайте ассет, короч, если таков имеется. Я никогда их не доделаю
Дайте ассет, короч, если таков имеется. Я никогда их не доделаю
127 Кб, 402x431>>8304
Насколько "широкие" у тебя стены? Если ты зайдешь за стену и уткнешься в нее впритык - насколько персонаж будет виден? Прост тоже подобное делаю и пытаюсь понять как лучше.
Насколько "широкие" у тебя стены? Если ты зайдешь за стену и уткнешься в нее впритык - насколько персонаж будет виден? Прост тоже подобное делаю и пытаюсь понять как лучше.
>>8306
Блин, а ты прав, я что-то не подумал, что у нас вообще-то стены сзади нужно обходить. Блин. Надо будет просить художника стены отдельно прорисовать.
Сейчас пол со стенами - это просто статичная картинка целая. Нельзя зайти "за" стену вот эту, которую ты показываешь. Нужно будет переделать. Я напишу художнику, пусть стены от пола отделит.
Блин, а ты прав, я что-то не подумал, что у нас вообще-то стены сзади нужно обходить. Блин. Надо будет просить художника стены отдельно прорисовать.
Сейчас пол со стенами - это просто статичная картинка целая. Нельзя зайти "за" стену вот эту, которую ты показываешь. Нужно будет переделать. Я напишу художнику, пусть стены от пола отделит.
6 Кб, 226x177>>8305
Я у себя через SpringArm3D регулирую высоту. А кинематическая стопа просто падает до конца спринг арма если не касается земли
Я у себя через SpringArm3D регулирую высоту. А кинематическая стопа просто падает до конца спринг арма если не касается земли
2,6 Мб, mp4,1286x724, 0:10
>>8306
Короче вот, так я порезал комнату. У меня стены с обратной стороны начинаются на уровне плитки в ванной.
Короче вот, так я порезал комнату. У меня стены с обратной стороны начинаются на уровне плитки в ванной.
>>8319
Я пробовал, но проблема в том, что тогда персонаж "теряется" за стеной. Это не очень хорошо. Во-первых, это не имеет смысла, там как бы и не подразумевается, что там что-то есть. Во-вторых, это может путать игроков.
Тут нужно искать компромисс между реализмом и удобством, лично моё мнение. За стену можно встать, уже хорошо, но надо, чтобы героя было видно.
Я пробовал, но проблема в том, что тогда персонаж "теряется" за стеной. Это не очень хорошо. Во-первых, это не имеет смысла, там как бы и не подразумевается, что там что-то есть. Во-вторых, это может путать игроков.
Тут нужно искать компромисс между реализмом и удобством, лично моё мнение. За стену можно встать, уже хорошо, но надо, чтобы героя было видно.
>>8321
Только не вздумай делать силуэт персонажа за стеной, иначе тебя нинтендо оштрафует за нарушение патентов..
Только не вздумай делать силуэт персонажа за стеной, иначе тебя нинтендо оштрафует за нарушение патентов..
>>8322
Нинтендо ушла из РФ, не говоря уж о том, что в РФ их патенты не зарегистрированы, так что они скорее всего даже пытаться не будут.
Нинтендо ушла из РФ, не говоря уж о том, что в РФ их патенты не зарегистрированы, так что они скорее всего даже пытаться не будут.
>>8323
Как вообще они смогли вот это запатентовать https://dtf.ru/gameindustry/4019240-nintendo-patent-na-mehaniku-vyzova-personazha Судья в Скайрим не играл?
Как вообще они смогли вот это запатентовать https://dtf.ru/gameindustry/4019240-nintendo-patent-na-mehaniku-vyzova-personazha Судья в Скайрим не играл?
>>8327
Это патентный троллинг называется. Дело не в том, кто первый сделал. А в том, кто первый запатентовал. Кто первый встал, того и тапки.
С другой стороны, если они пойдут в суд с этим патентом, и сторона защита покажет игру с этой же механикой до даты регистрации патента, то иск аннулируют, как и патент. Создатели Palworld недавно же победили в суде против нинтенды именно этим способом.
Это патентный троллинг называется. Дело не в том, кто первый сделал. А в том, кто первый запатентовал. Кто первый встал, того и тапки.
С другой стороны, если они пойдут в суд с этим патентом, и сторона защита покажет игру с этой же механикой до даты регистрации патента, то иск аннулируют, как и патент. Создатели Palworld недавно же победили в суде против нинтенды именно этим способом.
>>8329
А я под юрисдикцией РФ, а не США. Вот если бы у меня было еще и гражданство или хотя бы вид на жительство США, то тогда другой разговор.
А я под юрисдикцией РФ, а не США. Вот если бы у меня было еще и гражданство или хотя бы вид на жительство США, то тогда другой разговор.
>>8329
Вообще, можно было бы доебаться до того, что деньги на счете аккаунта разработчика лежат у Valve, а они американская компания, значит у меня есть имущество под юрисдикцией США, которое можно конфисковать. Но тут как раз и загвоздка в том, что лежат-то они на банковских счетах Valve, а не моих. Это их деньги, я их еще не получил и не имею право ими свободно распоряжаться. Valve - не банк.
Вообще, можно было бы доебаться до того, что деньги на счете аккаунта разработчика лежат у Valve, а они американская компания, значит у меня есть имущество под юрисдикцией США, которое можно конфисковать. Но тут как раз и загвоздка в том, что лежат-то они на банковских счетах Valve, а не моих. Это их деньги, я их еще не получил и не имею право ими свободно распоряжаться. Valve - не банк.
>>8327
1) Там описана определённая механика - надо кинуть предмет во врага, вместо предмета появляется союзник, он появляется обязательно перед игроком.
2) Патентное бюро сша коррумпированная структура
3) Патентное бюро Японии в таком патенте, вроде как, отказало
1) Там описана определённая механика - надо кинуть предмет во врага, вместо предмета появляется союзник, он появляется обязательно перед игроком.
2) Патентное бюро сша коррумпированная структура
3) Патентное бюро Японии в таком патенте, вроде как, отказало
>>8512
Я тоже. Отдыхаю воть. Второй год.
Я тоже. Отдыхаю воть. Второй год.
>>8512
Устал или мотивация поехала? Это две большие разницы.
Устал это когда делал, делал и в сон стал валиться в 3 часа ночи, скорей бы утро и снова за работу. Вот это усталость.
Исчерпание мотивации это не усталость.
Устал или мотивация поехала? Это две большие разницы.
Устал это когда делал, делал и в сон стал валиться в 3 часа ночи, скорей бы утро и снова за работу. Вот это усталость.
Исчерпание мотивации это не усталость.
>>8516
Просто тебя другие приоритеты сбили. Возможно временно. Потому что мотивация != жизненные цели. Мотивация существует на эмоциональном уровне. Она накапливается как либидо.
Если у тебя есть жизненная цель стать инди разработчиком, то мотивация накопится со временем.
Просто тебя другие приоритеты сбили. Возможно временно. Потому что мотивация != жизненные цели. Мотивация существует на эмоциональном уровне. Она накапливается как либидо.
Если у тебя есть жизненная цель стать инди разработчиком, то мотивация накопится со временем.
>>8518
Тогда ляг поспи и снова делай.
Тогда ляг поспи и снова делай.
Подскажите плиз. Вот я хочу запилить кооп слоп. Пусть сессия будет в виде dedicated server. Как вообще это правильно делать? Сначала я хотел тупо пилить отдельный сервер на другом языке делать udp коннекшены, а игру использовать тупо как интерфейс. Собсна пришлось бы всю логику, физику переносить на этот сервер. Потом я понял, что так делают только большие компании или задроты, для вонючего индюка это сложно и затратно. Как я понял в виде сервера также используют хэдлесс билд игры, а там вся логика + такой же движок. В туторах вообще делают p2p сессии. Вопрос: как мне понять как мне организовывать мультиплеер наиболее православно. Теоретически я хочу гэйм менеджер и отдельные сервера, но я не уверен, что нужно делать так. Мне нужен не нэт код, а бэст практис кейсы как сделать мультиплеер игру на годоте. Желательно пока без использования готовых аддонов, чтобы самому разобраться. Потом перейду к ним.
ТЛДР: Как делать мультиплеер в годоте в виде сервера и гейм менеджера.
ТЛДР: Как делать мультиплеер в годоте в виде сервера и гейм менеджера.
>>8525
Добавлю, что обычно я делал простые мультиплееры и какой-то физики и прочего мне переносить было не нужно и я просто пилил сервера на Go и имел полный кастом. Как переносить в текущем случае физику и логику, которая построена на коллизиях и анимациях я понятия не имею. Допустим гейм менеджер я сделаю на го, а остальное как? Хэдлесс игра? Или как-то инстансить сервер внутри клиента?
Добавлю, что обычно я делал простые мультиплееры и какой-то физики и прочего мне переносить было не нужно и я просто пилил сервера на Go и имел полный кастом. Как переносить в текущем случае физику и логику, которая построена на коллизиях и анимациях я понятия не имею. Допустим гейм менеджер я сделаю на го, а остальное как? Хэдлесс игра? Или как-то инстансить сервер внутри клиента?
>>8526
От света - нет. От теней - возможно.
Уже неоднократно обсуждали здесь: источник света в компьютерной графике лишь немного меняет оттенок освещённых пикселей, и это дёшево, хотя старые API поддерживали мало источников. Тени же - вообще отдельная концепция, которую можно по-разному реализовать, но сейчас доминирует shadow mapping. Который, естественно, затратен, поскольку должен отрендерить кусок сцены в текстуру теней раньше финального рендера. А теперь внимание: для 360° освещения с тенями в идеале нужно 6 карт в виде кубической развёртки. Эконом-вариант может и 2 использовать, но выглядит слишком всрато. Но без рендеринга теней освещение 360° почти бесплатно.
Где может пригодиться освещение без теней? Вот, например, неоновые вывески: они излучают свет, но слишком слабый, чтобы от них падала тень. Парочку омнилайт засовываешь в вывеску и она будет чуть реалистичнее даже без отбрасывания теней.
У тебя на скриншоте омнилайты создают свечение окошек под потолком. Тени там не нужны - это типа мутные или матовые стёкла, что рассеивают свет вокруг себя, окрашивая предметы без теней.
Почему нельзя использовать блум (bloom)? Это постпроцессинг - работает поверх рендера, как бы размазывая яркие пиксели. Если ярких пикселей в непосредственной видимости нет, не будет блума. Омнилайт может освещать предметы из-за угла. Естественно, никто не мешает добавить и блум - так возможно сделать более мягкие очертания света.
От света - нет. От теней - возможно.
Уже неоднократно обсуждали здесь: источник света в компьютерной графике лишь немного меняет оттенок освещённых пикселей, и это дёшево, хотя старые API поддерживали мало источников. Тени же - вообще отдельная концепция, которую можно по-разному реализовать, но сейчас доминирует shadow mapping. Который, естественно, затратен, поскольку должен отрендерить кусок сцены в текстуру теней раньше финального рендера. А теперь внимание: для 360° освещения с тенями в идеале нужно 6 карт в виде кубической развёртки. Эконом-вариант может и 2 использовать, но выглядит слишком всрато. Но без рендеринга теней освещение 360° почти бесплатно.
Где может пригодиться освещение без теней? Вот, например, неоновые вывески: они излучают свет, но слишком слабый, чтобы от них падала тень. Парочку омнилайт засовываешь в вывеску и она будет чуть реалистичнее даже без отбрасывания теней.
У тебя на скриншоте омнилайты создают свечение окошек под потолком. Тени там не нужны - это типа мутные или матовые стёкла, что рассеивают свет вокруг себя, окрашивая предметы без теней.
Почему нельзя использовать блум (bloom)? Это постпроцессинг - работает поверх рендера, как бы размазывая яркие пиксели. Если ярких пикселей в непосредственной видимости нет, не будет блума. Омнилайт может освещать предметы из-за угла. Естественно, никто не мешает добавить и блум - так возможно сделать более мягкие очертания света.
>>8526
Смотрю на локацию, думаю "похоже на e1m1", а потом слева вижу "DoomE1M1", забавно.
Смотрю на локацию, думаю "похоже на e1m1", а потом слева вижу "DoomE1M1", забавно.
>>8525
Headless билд нужен только если тебе неиронично нужен dedicated сервер, где ты будешь симулировать физику для античита и быть мастер-хостом всех сессий. В p2p просто пилится функционал мастер-хоста внутри одного из клиентов, который проверяет обновление стейта сессии и отправляет эту информацию другим членам сессии, а организацией сессий занимается какой-нибудь сервачок на go или вообще левый p2p сервис.
Зависит от типа игры. Если это какой-нибудь 2д слоп то там можно и р2р обойтись, тем более ты индюк. Если это 3д фпс шутанчик, особенно на кучу клиентов - то ему понадобится либо очень умный р2р сервачок который помимо проксирования rpc будет еще и обеспечивать лаг-компенсацию, либо придется пилить нормальный, православный сервер.
р2р делать проще, особенно в годоте/с фотоном. Но если ты хочешь античит, хочешь по хитрому управлять геймплеем, у тебя масштабная игра и ты не хочешь чтобы пиратские сервера на базе твоей раздербаненой игры выросли моментально после успеха релиза - тебе понадобится свой сервер. В сущности писать логику мастер-хоста/дедикатед сервера в любом случае придется, потому здесь больше вопрос куда ты целишься со своей игрой.
>>8527
Ну можешь просто передавать больше данных об обьекте, что позволит обеспечивать детерминизм физики.
Это нужно только если ты захочешь полноценную симуляцию сессий а-ля врот оф танкс. Для большинства серверных игр такие изращения не нужны, хотя для улучшеного античита возможно придется часть физики считать на сервере чтобы палить стрельбу сквозь стены и заход за текстуры.
Headless билд нужен только если тебе неиронично нужен dedicated сервер, где ты будешь симулировать физику для античита и быть мастер-хостом всех сессий. В p2p просто пилится функционал мастер-хоста внутри одного из клиентов, который проверяет обновление стейта сессии и отправляет эту информацию другим членам сессии, а организацией сессий занимается какой-нибудь сервачок на go или вообще левый p2p сервис.
>Вопрос: как мне понять как мне организовывать мультиплеер наиболее православно.
Зависит от типа игры. Если это какой-нибудь 2д слоп то там можно и р2р обойтись, тем более ты индюк. Если это 3д фпс шутанчик, особенно на кучу клиентов - то ему понадобится либо очень умный р2р сервачок который помимо проксирования rpc будет еще и обеспечивать лаг-компенсацию, либо придется пилить нормальный, православный сервер.
>Теоретически я хочу гэйм менеджер и отдельные сервера, но я не уверен, что нужно делать так.
р2р делать проще, особенно в годоте/с фотоном. Но если ты хочешь античит, хочешь по хитрому управлять геймплеем, у тебя масштабная игра и ты не хочешь чтобы пиратские сервера на базе твоей раздербаненой игры выросли моментально после успеха релиза - тебе понадобится свой сервер. В сущности писать логику мастер-хоста/дедикатед сервера в любом случае придется, потому здесь больше вопрос куда ты целишься со своей игрой.
>>8527
>Как переносить в текущем случае физику и логику, которая построена на коллизиях и анимациях я понятия не имею.
Ну можешь просто передавать больше данных об обьекте, что позволит обеспечивать детерминизм физики.
>Допустим гейм менеджер я сделаю на го, а остальное как? Хэдлесс игра? Или как-то инстансить сервер внутри клиента?
Это нужно только если ты захочешь полноценную симуляцию сессий а-ля врот оф танкс. Для большинства серверных игр такие изращения не нужны, хотя для улучшеного античита возможно придется часть физики считать на сервере чтобы палить стрельбу сквозь стены и заход за текстуры.
>>8532
Да, по сути я хочу, чтобы клиент только как витрина был, все просчеты физики и анимация на клиенте. Короче мне важно, чтобы все видели одно и тоже (позицию объектов, их анимацию, и положение всяких физико говняков)
>>8532
Наверное я мало понимаю и целюсь в лишний функционал, но я хз как делать п2п. Как должен будет выглядеть второй клиент? Какая-то каша, где один будет иметь по сути полный билд с расчетом и в нем считать инпут, другие игроки как ноды в его билде. Я видел уроки, но для меня это какой-то франкенштейн. С выделенным сервером я понимаю, что будет аля унифицированный клиент. А если п2п, то типа запускать этот сервер как отдельный сервис или как сцену (тогда получится п2п почище как по мне, но я хз как тут с ресурсами).
Короче я склоняюсь прям к отдельной логике сервера и все расчеты на нем, которую если что можно высрать в отдельный билд. Где про это подробнее почитать?
>>8532
Блина звучит очень сложно. Типа подключать те же обработчики анимаций, физики уже в го, учитывая положения и силу - это ебанутся какая работа. В годоте же все само уже считается. Хотелось бы этого избежать. На го пусть будет менеджер сессий и может быть чат.
ХЗ очень мало понимания во всем этом. Хочу чистенько делать, а не каши. Я смотрел примеры мультиплееров в туторах, выглядит как-то ситуативно и васянски имхо. Как-то четкое разделение клиент сервер для меня понятнее и интуитивнее. Мне больше вкатывает самостоятельный контроль и синк параметров, чем всякие синхронизаторы и тд. Но я не откажусь от функционала движка
>неиронично нужен dedicated сервер, где ты будешь симулировать физику для античита
Да, по сути я хочу, чтобы клиент только как витрина был, все просчеты физики и анимация на клиенте. Короче мне важно, чтобы все видели одно и тоже (позицию объектов, их анимацию, и положение всяких физико говняков)
>>8532
>р2р делать проще, особенно в годоте/с фотоном.
Наверное я мало понимаю и целюсь в лишний функционал, но я хз как делать п2п. Как должен будет выглядеть второй клиент? Какая-то каша, где один будет иметь по сути полный билд с расчетом и в нем считать инпут, другие игроки как ноды в его билде. Я видел уроки, но для меня это какой-то франкенштейн. С выделенным сервером я понимаю, что будет аля унифицированный клиент. А если п2п, то типа запускать этот сервер как отдельный сервис или как сцену (тогда получится п2п почище как по мне, но я хз как тут с ресурсами).
Короче я склоняюсь прям к отдельной логике сервера и все расчеты на нем, которую если что можно высрать в отдельный билд. Где про это подробнее почитать?
>>8532
>Ну можешь просто передавать больше данных об обьекте, что позволит обеспечивать детерминизм физики.
Блина звучит очень сложно. Типа подключать те же обработчики анимаций, физики уже в го, учитывая положения и силу - это ебанутся какая работа. В годоте же все само уже считается. Хотелось бы этого избежать. На го пусть будет менеджер сессий и может быть чат.
ХЗ очень мало понимания во всем этом. Хочу чистенько делать, а не каши. Я смотрел примеры мультиплееров в туторах, выглядит как-то ситуативно и васянски имхо. Как-то четкое разделение клиент сервер для меня понятнее и интуитивнее. Мне больше вкатывает самостоятельный контроль и синк параметров, чем всякие синхронизаторы и тд. Но я не откажусь от функционала движка
>>8537
Документацию почитай для начала.
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Что у тебя за игра-то планируется?
Может, сначала стоит сделать попроще?
>>8532
Всё правильно написал...
>как делать п2п
Документацию почитай для начала.
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Что у тебя за игра-то планируется?
Может, сначала стоит сделать попроще?
>>8532
Всё правильно написал...
>>8538
Попроще я делал, мне хочется сразу хавать правильную архитектуру. Я копировал туторы по мультиплееру, оно работает, но логика сервера получается впечатана в клиент (типа в одной сцене и клиентское отображение и серверная логика), мне это очень не нравится. Я согласен даже на что-то типа запустил класс/сцену Server и сцена Client подключается к этому серваку - уже получается раздельная логика. В теории этот класс можно вынести и в хэдлесс. Такой вот decouple.
Игра пока условно ебики 3дшные ходят по зданию от первого лица. Интеракции с предметами, нпс. Супер точности не надо, но хочу, чтобы все было у всех одинаково видно, как в условной фазмофобии и прочих коопах.
>>8538
Спасибо! Я читал по верхам, когда туторы ковырял, ща увидел что там полезное.
Может есть примеры того как я написал? Сами как мультиплеер пилили? Или все таки не выебываться и хуярить как в туторах?
>Что у тебя за игра-то планируется?
>Может, сначала стоит сделать попроще?
Попроще я делал, мне хочется сразу хавать правильную архитектуру. Я копировал туторы по мультиплееру, оно работает, но логика сервера получается впечатана в клиент (типа в одной сцене и клиентское отображение и серверная логика), мне это очень не нравится. Я согласен даже на что-то типа запустил класс/сцену Server и сцена Client подключается к этому серваку - уже получается раздельная логика. В теории этот класс можно вынести и в хэдлесс. Такой вот decouple.
Игра пока условно ебики 3дшные ходят по зданию от первого лица. Интеракции с предметами, нпс. Супер точности не надо, но хочу, чтобы все было у всех одинаково видно, как в условной фазмофобии и прочих коопах.
>>8538
>Документацию почитай для начала.
Спасибо! Я читал по верхам, когда туторы ковырял, ща увидел что там полезное.
Может есть примеры того как я написал? Сами как мультиплеер пилили? Или все таки не выебываться и хуярить как в туторах?
>>8530
Хуя ты умный. Пасиб.
Хуя ты умный. Пасиб.
>>8543
И еще интересно - игрушки в стиме получаются используют стим апи для созданий лобби и проброски портов для п2п? Или они свой сервак херачат? Как ето блять, разжуйте долбаебу по братски?
И еще интересно - игрушки в стиме получаются используют стим апи для созданий лобби и проброски портов для п2п? Или они свой сервак херачат? Как ето блять, разжуйте долбаебу по братски?
>>8543
В GTA 5 Online играл? Там официальный мультиплеер именно p2p, максимум до 30 человек, но тормозить начинает в зависимости от того, кто хост. На слабом компьютере даже вдвоём будет дикий рассинхрон. Отдельного сервера нет - если возникают проблемы соединения, игра отключается от игрока-хоста и превращается в хоста с пустой сессией (один игрок). Выделенный сервер там только только для поиска игроков, сохранения данных, контроля денег и т.п.
Естественно это всё приводит к огромному числу внутриигровых проблем: лаги, зависания, глитчи на миссиях, читеры, безнаказанно абузящие каждую уязвимость. И это - одна из самых популярных игр, с колоссальным бюджетом, в огромной франшизе, от огромной компании, на написанном с нуля движке. Сравни теперь их возможности со своими. Всё ещё недоволен тем, что приходится делать "некрасиво"?
Давно наблюдаю за всеми этими онлайн-играми и полностью разочаровался в них. Это всё слишком сложно, а результат - пук и обмяк на релизе/через несколько месяцев предсмертных обновлений. Демотивирует больше всего в геймдеве...
>>8546
Читай документацию, она открыта у стима:
https://partner.steamgames.com/doc/features/multiplayer/networking
>логика сервера получается впечатана в клиент
В GTA 5 Online играл? Там официальный мультиплеер именно p2p, максимум до 30 человек, но тормозить начинает в зависимости от того, кто хост. На слабом компьютере даже вдвоём будет дикий рассинхрон. Отдельного сервера нет - если возникают проблемы соединения, игра отключается от игрока-хоста и превращается в хоста с пустой сессией (один игрок). Выделенный сервер там только только для поиска игроков, сохранения данных, контроля денег и т.п.
Естественно это всё приводит к огромному числу внутриигровых проблем: лаги, зависания, глитчи на миссиях, читеры, безнаказанно абузящие каждую уязвимость. И это - одна из самых популярных игр, с колоссальным бюджетом, в огромной франшизе, от огромной компании, на написанном с нуля движке. Сравни теперь их возможности со своими. Всё ещё недоволен тем, что приходится делать "некрасиво"?
Давно наблюдаю за всеми этими онлайн-играми и полностью разочаровался в них. Это всё слишком сложно, а результат - пук и обмяк на релизе/через несколько месяцев предсмертных обновлений. Демотивирует больше всего в геймдеве...
>>8546
>игрушки в стиме
Читай документацию, она открыта у стима:
https://partner.steamgames.com/doc/features/multiplayer/networking
>>8548
Ну игру в гта затерпят, а в мое поделие нет. Но сейчас даже не в этом дело, а дело разобраться как делать все же правильно и какие проблемы решать. Сейчас уже снял часть вопросов: дублировать сервер на другом языке - долго и бесполезно, низко уровневый неткод писать не нужно - у годота есть апи. Но вот посмотреть готовую архитектуру мультиплеера на годоте хочется. Пока в туторах и проектах, что я смотрел, абстракции сервра не было, по сути в клиентской сесии были обработчики сетевые. Хочется понять так все делают? Есть по вашему примеры хорошего нет кода в сессионых играх на годоте? Мне вот пиздец хочется это все изолировать, но при этом я сейчас стараюсь не выдумывать, а просто научиться правильному
>В GTA 5 Online играл
>Всё ещё недоволен тем, что приходится делать "некрасиво"?
Ну игру в гта затерпят, а в мое поделие нет. Но сейчас даже не в этом дело, а дело разобраться как делать все же правильно и какие проблемы решать. Сейчас уже снял часть вопросов: дублировать сервер на другом языке - долго и бесполезно, низко уровневый неткод писать не нужно - у годота есть апи. Но вот посмотреть готовую архитектуру мультиплеера на годоте хочется. Пока в туторах и проектах, что я смотрел, абстракции сервра не было, по сути в клиентской сесии были обработчики сетевые. Хочется понять так все делают? Есть по вашему примеры хорошего нет кода в сессионых играх на годоте? Мне вот пиздец хочется это все изолировать, но при этом я сейчас стараюсь не выдумывать, а просто научиться правильному
>>8549
Эээ, я, честно говоря, не разбираюсь в этом всём, но как ты себе представляешь изолирование клиента? Я вот пробовал писать простенькие TCP программки, приблизительно вся их работа выглядит как просто последовательный обмен данными туда-сюда, нет? Изолировать (абстрагировать) тут как бы нечего?
Ну, скажем, ты хочешь двигать куб на клиенте, чтоб сервер видел положение куба. Ты двигаешь куб и отправляешь на сервер. Сервер принимает данные, сохраняет их к себе. Если сервер двигает куб, тогда клиент принимает данные о кубе и сдвигает его. Не понимаю, что от чего ты тут изолировать хочешь? Движение куба от передачи данных? Или что?
Я просто не понимаю, в чём твоя проблема-то...
Эээ, я, честно говоря, не разбираюсь в этом всём, но как ты себе представляешь изолирование клиента? Я вот пробовал писать простенькие TCP программки, приблизительно вся их работа выглядит как просто последовательный обмен данными туда-сюда, нет? Изолировать (абстрагировать) тут как бы нечего?
Ну, скажем, ты хочешь двигать куб на клиенте, чтоб сервер видел положение куба. Ты двигаешь куб и отправляешь на сервер. Сервер принимает данные, сохраняет их к себе. Если сервер двигает куб, тогда клиент принимает данные о кубе и сдвигает его. Не понимаю, что от чего ты тут изолировать хочешь? Движение куба от передачи данных? Или что?
Я просто не понимаю, в чём твоя проблема-то...
>>8553
сложность зависит от PvP или PvE
PvP оче сложно даже примитивном пинг понге синхронизировать СОСТОЯНИЕ
PvE в основном просто - задача в синхронизации КАРТИНКИ. Рассинхрон не фатален, отвалившийся клиен играет в своем мирке
Вы даже в начале дискуссии не определили что будет
мимо
сложность зависит от PvP или PvE
PvP оче сложно даже примитивном пинг понге синхронизировать СОСТОЯНИЕ
PvE в основном просто - задача в синхронизации КАРТИНКИ. Рассинхрон не фатален, отвалившийся клиен играет в своем мирке
Вы даже в начале дискуссии не определили что будет
мимо
>>8553
Смотри:
Есть игра про движение кубов. В туториале чел делает сцену, где двигает куб стрелочками. Потом говорит, ща ебану мультиплеер. Добавляет какие то синк ноды в эту же сцену, срет скриптами в эти же объекты и запускает второе окно и говорит, вооо - теперь мультиплеер. Получился какой-то ебень полуклиент, полусервер где нет границы.
Мне хочется, чтобы было четкое разделение - вот эта сцена/класс/приложение клиент - вот это сервер. То есть я создал сцену где есть кубы и скрипт тупо считывает инпуты. Это абстракция клиент. И потом отправляет это в абстракцию сервер, где уже логика сессий, конекшна и игровая логика. Это абстракция может быть в виде менеджера, в виде отдельной сцены или даже в виде отдельного приложения. Вот такое есть, я правильно думаю? Или норм практика писать логику как для сингла, а потом вмазывать туда синхронизаторы и нэткод?
>>8555
Я написал что условные кооп болванчики с нпс и немного физикой. Считай фазмафобия по устройству
>Я просто не понимаю, в чём твоя проблема-то...
Смотри:
Есть игра про движение кубов. В туториале чел делает сцену, где двигает куб стрелочками. Потом говорит, ща ебану мультиплеер. Добавляет какие то синк ноды в эту же сцену, срет скриптами в эти же объекты и запускает второе окно и говорит, вооо - теперь мультиплеер. Получился какой-то ебень полуклиент, полусервер где нет границы.
Мне хочется, чтобы было четкое разделение - вот эта сцена/класс/приложение клиент - вот это сервер. То есть я создал сцену где есть кубы и скрипт тупо считывает инпуты. Это абстракция клиент. И потом отправляет это в абстракцию сервер, где уже логика сессий, конекшна и игровая логика. Это абстракция может быть в виде менеджера, в виде отдельной сцены или даже в виде отдельного приложения. Вот такое есть, я правильно думаю? Или норм практика писать логику как для сингла, а потом вмазывать туда синхронизаторы и нэткод?
>>8555
>Вы даже в начале дискуссии не определили что будет
Я написал что условные кооп болванчики с нпс и немного физикой. Считай фазмафобия по устройству
>>8549
Rpc это база сетевых игр по сей день, в годоте разве что еще есть функционал прямого зеркалирования по п2п определенных полей определенных нод. Собственно, так делают многие до сих пор, просто обмазываются типизированными rpc для сложного взаимодействия и зеркалиоованием физических свойств (ускорение, позиция, поворот, инпут) и на основе кучи событий (и их обработки) строится сетевой обмен. Это позволяет дробить обмен на dto и управлять этими dto на низком уровне как вздумается. Обратная сторона медали - событий и их обработчиков может стать неприлично много, даже если опустить вопрос маппинга и траффика без полей. Это по крайней мере единственный достаточно простой в реализации рабочий способ. Есть и другие, но они доступны только тем кто не убоится нормальных языков и компонентных систем, а еще не убоится потерять ооп твердь и ступить на жидкую почву сущностей и их максимально разнообразного содержания, которое определяет их поведение.
>Хочется понять так все делают?
Rpc это база сетевых игр по сей день, в годоте разве что еще есть функционал прямого зеркалирования по п2п определенных полей определенных нод. Собственно, так делают многие до сих пор, просто обмазываются типизированными rpc для сложного взаимодействия и зеркалиоованием физических свойств (ускорение, позиция, поворот, инпут) и на основе кучи событий (и их обработки) строится сетевой обмен. Это позволяет дробить обмен на dto и управлять этими dto на низком уровне как вздумается. Обратная сторона медали - событий и их обработчиков может стать неприлично много, даже если опустить вопрос маппинга и траффика без полей. Это по крайней мере единственный достаточно простой в реализации рабочий способ. Есть и другие, но они доступны только тем кто не убоится нормальных языков и компонентных систем, а еще не убоится потерять ооп твердь и ступить на жидкую почву сущностей и их максимально разнообразного содержания, которое определяет их поведение.
Кто-то уже мацал дев3? Как темка? Хочу перекатиться под шумок, пушто у меня диск жидко пёрнув умер.
Кстати да. Только сегодня вышел. Уже с новой темой. Осталось лого замонохромить! https://godotengine.org/article/dev-snapshot-godot-4-6-dev-3/
>>8591
Смотря чего у тебя. Если новый проект - ебашь. Старый переводишь - готовься покопаться.
>>8591
Смотря чего у тебя. Если новый проект - ебашь. Старый переводишь - готовься покопаться.
>>8595
Это как посмотреть. Я его завел на 4.4. Вот, случай подвернулся обновиться. Меня больше интересует не багованная ли весия? И почему никак блядь не пофиксят неработающий драг энд дроп в файловом менеджере если он откреплен от основного окна.
>Смотря чего у тебя. Если новый проект - ебашь. Старый переводишь - готовься покопаться.
Это как посмотреть. Я его завел на 4.4. Вот, случай подвернулся обновиться. Меня больше интересует не багованная ли весия? И почему никак блядь не пофиксят неработающий драг энд дроп в файловом менеджере если он откреплен от основного окна.
>>8700
Потянулись движкосрачеры в загон. А я взял нод красных, спелых, нашинковал в сцену, сверху положил зелёные ноды, добавил скриптов макаронистых, и ещё добавил синглтон для мягкости. А тут уже и шаблоны экспорта скачались. Добавил шаблон в проект, экспортировал, запустил и начал неистово играть! И! И! И в школу сегодня не пошёл.
Потянулись движкосрачеры в загон. А я взял нод красных, спелых, нашинковал в сцену, сверху положил зелёные ноды, добавил скриптов макаронистых, и ещё добавил синглтон для мягкости. А тут уже и шаблоны экспорта скачались. Добавил шаблон в проект, экспортировал, запустил и начал неистово играть! И! И! И в школу сегодня не пошёл.
>>8720
Я, блять, второй день играюсь с переустановленной 10 виндой. Так усрать операционку разной говной могут только мелкомягкие. При первом запуске шиндоус выглядит как те порносайты, на которых 80% экранного пространства занимает реклама разной степени шакальности
Я, блять, второй день играюсь с переустановленной 10 виндой. Так усрать операционку разной говной могут только мелкомягкие. При первом запуске шиндоус выглядит как те порносайты, на которых 80% экранного пространства занимает реклама разной степени шакальности
>>8747
Не хотелось тут разводить ОСесрач, но чел, на линухе годот работает идеально. И игорь давно не тонет, спасибо Габену.
Не хотелось тут разводить ОСесрач, но чел, на линухе годот работает идеально. И игорь давно не тонет, спасибо Габену.
>>8747
Ты еще 11 не видел. А так двачую анона выше. Половина разработчиков годота - линуксоиды
Ты еще 11 не видел. А так двачую анона выше. Половина разработчиков годота - линуксоиды
>>8747
Если твой ПК позволяет, то используй Virtual Box или VMWare и на них накати любую ОС и на неё движок
Я недавно перешёл на 11 с 10, всё устраивает
Если твой ПК позволяет, то используй Virtual Box или VMWare и на них накати любую ОС и на неё движок
Я недавно перешёл на 11 с 10, всё устраивает
>>8863
Это бессмысленно без проброса видеокарты в виртуалку. А этого я так и не научился.
> используй Virtual Box или VMWare и на них накати любую ОС и на неё движок
Это бессмысленно без проброса видеокарты в виртуалку. А этого я так и не научился.
>>8899
У VMWare проброс есть вроде и отдельной, но, по идее сам VMWare будет при помощи своего драйвера пробрасывать часть ресурсов видяхи в виртуальную машину
У VMWare проброс есть вроде и отдельной, но, по идее сам VMWare будет при помощи своего драйвера пробрасывать часть ресурсов видяхи в виртуальную машину
119 Кб, 980x600>>8747
Сделай как на пикриле и Windows сразу станет лучше.
Тогда лишние приложения можно будет удалить.
Несколько лет без обновлений - всё работает!
>второй день играюсь с переустановленной 10 виндой
Сделай как на пикриле и Windows сразу станет лучше.
Тогда лишние приложения можно будет удалить.
Несколько лет без обновлений - всё работает!
632 Кб, 680x847>>8914
@
ПОКА ДЕЛАЛ СКРИНШОТ ЧТО-ТО НАЖАЛ
@
«ОБНОВЛЕНИЯ | Б У Д У Т | УСТАНОВЛЕНЫ»
@
«ОЙ! ПРОИЗОШЁЛ 0x060СРАМС В WTF.SYS :(»
@
ПЕРЕЗАГРУЗИЛАСЬ
@
ПЕРЕЗАГРУЗИЛАСЬ
@
ПЕРЕЗАГРУЗИЛАСЬ
@
«ИДЁТ УСТАНОВКА...»
Моё лицо - на пикриле.
>Несколько лет без обновлений
@
ПОКА ДЕЛАЛ СКРИНШОТ ЧТО-ТО НАЖАЛ
@
«ОБНОВЛЕНИЯ | Б У Д У Т | УСТАНОВЛЕНЫ»
@
«ОЙ! ПРОИЗОШЁЛ 0x060СРАМС В WTF.SYS :(»
@
ПЕРЕЗАГРУЗИЛАСЬ
@
ПЕРЕЗАГРУЗИЛАСЬ
@
ПЕРЕЗАГРУЗИЛАСЬ
@
«ИДЁТ УСТАНОВКА...»
Моё лицо - на пикриле.
>>8757
Я знаю, я тестировал. Но мне немного стремно как будет с билдами игр. Я же не смогу нормально тестировать. А две оси я себе позволить не могу. Ну и иногда и в онлайн дрочильни поиграть хочется
>>8764
Я планирую принудительно укатиться на линупс когда десятка окончательно сдохнет. Но я так уже сделал после семерки, через 3 года на дебиане стиснув зубы затерпел и вернулся к десятке.
В целом, если мне кто-то нормально расскажет как там обстоят дела со сборкой игры я может и свалю на линукс. Возможно кто-то сочтет меня ебанутым, но я боюсь магического воздействия, которое сделает мои игры незапускаемыми, если я буду собирать под винду на линуксе и наоборот.
Я знаю, я тестировал. Но мне немного стремно как будет с билдами игр. Я же не смогу нормально тестировать. А две оси я себе позволить не могу. Ну и иногда и в онлайн дрочильни поиграть хочется
>>8764
Я планирую принудительно укатиться на линупс когда десятка окончательно сдохнет. Но я так уже сделал после семерки, через 3 года на дебиане стиснув зубы затерпел и вернулся к десятке.
В целом, если мне кто-то нормально расскажет как там обстоят дела со сборкой игры я может и свалю на линукс. Возможно кто-то сочтет меня ебанутым, но я боюсь магического воздействия, которое сделает мои игры незапускаемыми, если я буду собирать под винду на линуксе и наоборот.
>>8923
У тебя SSD меньше 256 ГБ под систему что ли?
Делишь диск так:
96 ГБ под шинукс для работы
4000 ГБ под пиндус для игорей
И всё норм будет. По идее.
Ты export template из исходников компилируешь?
Если нет, то вообще никаких проблем (по идее).
Если да, то, по идее, на шпиндукс будет лучше.
В смысле, шинукс. Или пиндус?.. Блин.
Просто почитай документацию.
>две оси я себе позволить не могу
У тебя SSD меньше 256 ГБ под систему что ли?
Делишь диск так:
96 ГБ под шинукс для работы
4000 ГБ под пиндус для игорей
И всё норм будет. По идее.
>дела со сборкой игры
Ты export template из исходников компилируешь?
Если нет, то вообще никаких проблем (по идее).
Если да, то, по идее, на шпиндукс будет лучше.
В смысле, шинукс. Или пиндус?.. Блин.
Просто почитай документацию.
>>8932
У меня кореш на мак уже перекатился. Без обид, конечно, но идите нахуй со своим соевым маком.
У меня кореш на мак уже перекатился. Без обид, конечно, но идите нахуй со своим соевым маком.
>>8923
Годотовые игры собирается одинаково что на линуксе что на винде, под любую платформу. У меня на итче валяются игры (и люди в них играют) которые были собраны под линукс-винду-мак-андроид НА линуксе. И если виндовую и андроидовую версию игры я мог протестировать, то билд под мак я выложил не протестировав, и написал что хуй знает работает ли он. Как мне в комментах потом написали - работает.
>Возможно кто-то сочтет меня ебанутым, но я боюсь магического воздействия, которое сделает мои игры незапускаемыми, если я буду собирать под винду на линуксе и наоборот.
Годотовые игры собирается одинаково что на линуксе что на винде, под любую платформу. У меня на итче валяются игры (и люди в них играют) которые были собраны под линукс-винду-мак-андроид НА линуксе. И если виндовую и андроидовую версию игры я мог протестировать, то билд под мак я выложил не протестировав, и написал что хуй знает работает ли он. Как мне в комментах потом написали - работает.
>>8953
Двачую. Слово в слово так же было.
Олсо, я и темплейт компилировать из исходников пробовал. Под шиндошс из-под линуха нормально компилился и потом работал; под макось и ведроид - я тогда не осилил. Но это всё в порядке эксперимента, в релизе использовал всё равно дефолтные темплейты.
Двачую. Слово в слово так же было.
Олсо, я и темплейт компилировать из исходников пробовал. Под шиндошс из-под линуха нормально компилился и потом работал; под макось и ведроид - я тогда не осилил. Но это всё в порядке эксперимента, в релизе использовал всё равно дефолтные темплейты.
2,8 Мб, 2560x1440Можете в шапку переката
https://www.youtube.com/watch?v=7ZwEmxihlw4
Ваши игры же присутствуют в видосе? Верно же? Вы их сделали, релизнули и отправили?
Ваши игры же присутствуют в видосе? Верно же? Вы их сделали, релизнули и отправили?
>>7151
Поиграл, мне понравилось, жалко нет продолжения, час примерно аутировал за разные классы. Идея понятно, играть интересно даже вот как щас есть, отсутствие графики не смутило, то что меня сырое вот это прям на подкорке мозга ебёт но понятно что демка. Механики за час показались прикольными, жду релиза короче
Поиграл, мне понравилось, жалко нет продолжения, час примерно аутировал за разные классы. Идея понятно, играть интересно даже вот как щас есть, отсутствие графики не смутило, то что меня сырое вот это прям на подкорке мозга ебёт но понятно что демка. Механики за час показались прикольными, жду релиза короче
Котаны, есть какой то темплейт для гуи настроек графики 3Д игры? Ассет какой нибудь, или что-то такое. Я чето вот всё откладываю и откладываю это дело.
20 Кб, 156x156>>9143
У Кенни на гитхабе были стартер киты для разных жанров, не знаю есть ли там именно ГУЙ для настроек. Выглядит слишком поверхностной задачей чтобы кто-то заморачивался.
У Кенни на гитхабе были стартер киты для разных жанров, не знаю есть ли там именно ГУЙ для настроек. Выглядит слишком поверхностной задачей чтобы кто-то заморачивался.
хаха тред потонул и теперь никто не узнает что я не делаю игры
Обновить тред
