Этого треда уже нет.
Это копия, сохраненная 22 июля в 04:00.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 22 июля в 04:00.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
102 Кб, 622x350Добро пожаловать в тред любви, взаимопомощи и обсессивно-копульсивного ощущения будто что-то забыл дописать в шапку!
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Новости движка: https://godotengine.org/news/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
Библиотека готовых шейдеров: https://godotshaders.com
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
Лучше кинуть ссылку на список всех языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк (в связи с появлением батчинга приглашается автор бенча для актуализации):
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>833955 (OP)
Архивный: https://arhivach.ng/thread/845965/
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Новости движка: https://godotengine.org/news/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
Библиотека готовых шейдеров: https://godotshaders.com
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
Лучше кинуть ссылку на список всех языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк (в связи с появлением батчинга приглашается автор бенча для актуализации):
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>833955 (OP)
Архивный: https://arhivach.ng/thread/845965/
>>841790 →
Не совсем подходит, но get_vector интересная штука
>>841820 →
>>841830 →
Ну мне такая схема управления больше нравится, сразу по нескольким причинам.
1) Мне она кажется более интуитивной и отзывчивой, не хочешь идти вправо - просто не нажимаешь правую клавишу, захотел пойти вправо - идёшь вправо вне зависимости от нажатых клавиш.
2) Поскольку игра survival horror и довольно быстрая (из-за малого разрешения) довольно часто от игрока будет требоваться быстрая реакция, в особенности это распространяется на перемещение и стрельбу.
У нас есть две самых популярных схемы перемещения. Допустим, игрок идёт вправо, зажимает правую клавишу, потом начал зажимать левую. Пока зажаты обе клавиши, в этих схемах происходит либо
I - игрок стоит на месте, "идёт в обе стороны" и векторы складываются в ноль.
II - игрок идёт в изначальную сторону.
В обоих случаях нажатие клавиши "влево" не даёт перемещения влево, движение влево начнётся только после того, как будет отпущена клавиша "вправо". Я понимаю, что никто не зажимает 10 клавиш подряд, однако, никто и не отпускает изначальную клавишу моментально. Т.е. вот в этот момент, когда новая клавиша уже нажата, а вторая ещё не отпущена появляется задержка. И в таких играх, как моя (survival horror, маленькое разрешение, быстрые и ваншотящие враги) такая задержка может быть критичной. Даже 50-100 миллисекунд могут спасти ситуацию и помочь убежать от ёбы, или развернуть и выстрелить в неё. Надеюсь понятно объяснил.
Что касательно кода, мне ваши решения нравится, но я сейчас посмотрел на своё, и я думаю, его можно немного переписать для чистоты, инкапсулировать в функцию и в целом будет понятно.
Я не думаю, что геймпад и стики сейчас это мои main concerns, всё же я сейчас даже не уверен, будет ли игра в стиме, или только на итче, а от этого уже будет зависеть очень и очень много (продолжительность и количество контента из самого заметного).
Не совсем подходит, но get_vector интересная штука
>>841820 →
>>841830 →
Ну мне такая схема управления больше нравится, сразу по нескольким причинам.
1) Мне она кажется более интуитивной и отзывчивой, не хочешь идти вправо - просто не нажимаешь правую клавишу, захотел пойти вправо - идёшь вправо вне зависимости от нажатых клавиш.
2) Поскольку игра survival horror и довольно быстрая (из-за малого разрешения) довольно часто от игрока будет требоваться быстрая реакция, в особенности это распространяется на перемещение и стрельбу.
У нас есть две самых популярных схемы перемещения. Допустим, игрок идёт вправо, зажимает правую клавишу, потом начал зажимать левую. Пока зажаты обе клавиши, в этих схемах происходит либо
I - игрок стоит на месте, "идёт в обе стороны" и векторы складываются в ноль.
II - игрок идёт в изначальную сторону.
В обоих случаях нажатие клавиши "влево" не даёт перемещения влево, движение влево начнётся только после того, как будет отпущена клавиша "вправо". Я понимаю, что никто не зажимает 10 клавиш подряд, однако, никто и не отпускает изначальную клавишу моментально. Т.е. вот в этот момент, когда новая клавиша уже нажата, а вторая ещё не отпущена появляется задержка. И в таких играх, как моя (survival horror, маленькое разрешение, быстрые и ваншотящие враги) такая задержка может быть критичной. Даже 50-100 миллисекунд могут спасти ситуацию и помочь убежать от ёбы, или развернуть и выстрелить в неё. Надеюсь понятно объяснил.
Что касательно кода, мне ваши решения нравится, но я сейчас посмотрел на своё, и я думаю, его можно немного переписать для чистоты, инкапсулировать в функцию и в целом будет понятно.
>будет работать только на клавишах клавиатуры, ни на стиках, ни на крестовинах геймпадов такое не заработает
Я не думаю, что геймпад и стики сейчас это мои main concerns, всё же я сейчас даже не уверен, будет ли игра в стиме, или только на итче, а от этого уже будет зависеть очень и очень много (продолжительность и количество контента из самого заметного).
>>841790 →
Не совсем подходит, но get_vector интересная штука
>>841820 →
>>841830 →
Ну мне такая схема управления больше нравится, сразу по нескольким причинам.
1) Мне она кажется более интуитивной и отзывчивой, не хочешь идти вправо - просто не нажимаешь правую клавишу, захотел пойти вправо - идёшь вправо вне зависимости от нажатых клавиш.
2) Поскольку игра survival horror и довольно быстрая (из-за малого разрешения) довольно часто от игрока будет требоваться быстрая реакция, в особенности это распространяется на перемещение и стрельбу.
У нас есть две самых популярных схемы перемещения. Допустим, игрок идёт вправо, зажимает правую клавишу, потом начал зажимать левую. Пока зажаты обе клавиши, в этих схемах происходит либо
I - игрок стоит на месте, "идёт в обе стороны" и векторы складываются в ноль.
II - игрок идёт в изначальную сторону.
В обоих случаях нажатие клавиши "влево" не даёт перемещения влево, движение влево начнётся только после того, как будет отпущена клавиша "вправо". Я понимаю, что никто не зажимает 10 клавиш подряд, однако, никто и не отпускает изначальную клавишу моментально. Т.е. вот в этот момент, когда новая клавиша уже нажата, а вторая ещё не отпущена появляется задержка. И в таких играх, как моя (survival horror, маленькое разрешение, быстрые и ваншотящие враги) такая задержка может быть критичной. Даже 50-100 миллисекунд могут спасти ситуацию и помочь убежать от ёбы, или развернуть и выстрелить в неё. Надеюсь понятно объяснил.
Что касательно кода, мне ваши решения нравится, но я сейчас посмотрел на своё, и я думаю, его можно немного переписать для чистоты, инкапсулировать в функцию и в целом будет понятно.
Я не думаю, что геймпад и стики сейчас это мои main concerns, всё же я сейчас даже не уверен, будет ли игра в стиме, или только на итче, а от этого уже будет зависеть очень и очень много (продолжительность и количество контента из самого заметного).
Не совсем подходит, но get_vector интересная штука
>>841820 →
>>841830 →
Ну мне такая схема управления больше нравится, сразу по нескольким причинам.
1) Мне она кажется более интуитивной и отзывчивой, не хочешь идти вправо - просто не нажимаешь правую клавишу, захотел пойти вправо - идёшь вправо вне зависимости от нажатых клавиш.
2) Поскольку игра survival horror и довольно быстрая (из-за малого разрешения) довольно часто от игрока будет требоваться быстрая реакция, в особенности это распространяется на перемещение и стрельбу.
У нас есть две самых популярных схемы перемещения. Допустим, игрок идёт вправо, зажимает правую клавишу, потом начал зажимать левую. Пока зажаты обе клавиши, в этих схемах происходит либо
I - игрок стоит на месте, "идёт в обе стороны" и векторы складываются в ноль.
II - игрок идёт в изначальную сторону.
В обоих случаях нажатие клавиши "влево" не даёт перемещения влево, движение влево начнётся только после того, как будет отпущена клавиша "вправо". Я понимаю, что никто не зажимает 10 клавиш подряд, однако, никто и не отпускает изначальную клавишу моментально. Т.е. вот в этот момент, когда новая клавиша уже нажата, а вторая ещё не отпущена появляется задержка. И в таких играх, как моя (survival horror, маленькое разрешение, быстрые и ваншотящие враги) такая задержка может быть критичной. Даже 50-100 миллисекунд могут спасти ситуацию и помочь убежать от ёбы, или развернуть и выстрелить в неё. Надеюсь понятно объяснил.
Что касательно кода, мне ваши решения нравится, но я сейчас посмотрел на своё, и я думаю, его можно немного переписать для чистоты, инкапсулировать в функцию и в целом будет понятно.
>будет работать только на клавишах клавиатуры, ни на стиках, ни на крестовинах геймпадов такое не заработает
Я не думаю, что геймпад и стики сейчас это мои main concerns, всё же я сейчас даже не уверен, будет ли игра в стиме, или только на итче, а от этого уже будет зависеть очень и очень много (продолжительность и количество контента из самого заметного).
2,5 Мб, 2880x1800Го в Российский Автопром кодить на Годоте?
У нас уже есть один очень клёвый годотер с вашего форума, хотелось бы как минимум ещё одного! А ещё у него очень много весёлых и замечательных видео про вас.
hh.ru/vacancy/72736381
У нас уже есть один очень клёвый годотер с вашего форума, хотелось бы как минимум ещё одного! А ещё у него очень много весёлых и замечательных видео про вас.
hh.ru/vacancy/72736381
>>41844
ничего себе ты мегомозг я бы даже не подумал о таком,что такие нюансы в управлении могут как то с гэймдизайном быть связанны лол
где научиться думать не как кодер а как гэймдизайнер чтобы такие вещи продумывать? у меня всегда код качественны й но игры пустыми получаются
ничего себе ты мегомозг я бы даже не подумал о таком,что такие нюансы в управлении могут как то с гэймдизайном быть связанны лол
где научиться думать не как кодер а как гэймдизайнер чтобы такие вещи продумывать? у меня всегда код качественны й но игры пустыми получаются
>>41846
Я вам долбоебам 1,5 недели назад резюме отправлял, вы его даже не посмотрели до сих пор.
Я вам долбоебам 1,5 недели назад резюме отправлял, вы его даже не посмотрели до сих пор.
>>41846
Забавно.
Когда я изучил шарп, а теперь учу питон, появилась таки вакансия на годоте...
Ну лан. Щас глянем, что вы там предлагаете.
Китайца в москвич переделывать?
> Го в Российский Автопром кодить на Годоте?
Забавно.
Когда я изучил шарп, а теперь учу питон, появилась таки вакансия на годоте...
Ну лан. Щас глянем, что вы там предлагаете.
Китайца в москвич переделывать?
>>41864
Ты настолько тупой, что по названию компании продукт загуглить не можешь, IT это не твоё.
>Китайца в москвич переделывать?
Ты настолько тупой, что по названию компании продукт загуглить не можешь, IT это не твоё.
>>41868
А зачем его гуглить? Очередной попильный ё-мобиль. Причём, что забавно, организатор этой хуйни будет до последнего думать, что они делом занимаются, а спонсоры будут у наго за спиной попилы откатывать.
А потом крайним останется этот гендиректор. И сядет, да.
А зачем его гуглить? Очередной попильный ё-мобиль. Причём, что забавно, организатор этой хуйни будет до последнего думать, что они делом занимаются, а спонсоры будут у наго за спиной попилы откатывать.
А потом крайним останется этот гендиректор. И сядет, да.
>>41870
Тебе не похуй? Зарплату платят, опыт нарабатываешь, строчка в резюме будет, это всё что тебя как сотрудника должно волновать.
Ну так не ты же.
>Очередной попильный ё-мобиль
Тебе не похуй? Зарплату платят, опыт нарабатываешь, строчка в резюме будет, это всё что тебя как сотрудника должно волновать.
>крайним останется этот гендиректор. И сядет, да.
Ну так не ты же.
68 Кб, 969x920>>41874
Заскриню пожалуй. Когда эта хуйня развалится, будет интересно пруфнуть мою правоту.
Заскриню пожалуй. Когда эта хуйня развалится, будет интересно пруфнуть мою правоту.
>>41899
Ты куколд? Любишь смотреть, как твой код посторонние люди скачивают на чужую машину и там во все окна его исполняют? Ничего не имею против твоего фетиша - каждый дрочит как он хочет, но не втягивай нас в эти свои дела, хорошо? Мы тут пишем свой код под себя, чтобы запускать на своей машине своими руками. Мы любим свой код, а не смотреть, как наш код любят какие-то посторонние люди с длинными, толстыми и липкими пальцами. Иди отсюда уже, оставил спам ссылку на вакансию и до свидания.
>Приятно смотреть как мой код на GDScript заканчивается в машину.
Ты куколд? Любишь смотреть, как твой код посторонние люди скачивают на чужую машину и там во все окна его исполняют? Ничего не имею против твоего фетиша - каждый дрочит как он хочет, но не втягивай нас в эти свои дела, хорошо? Мы тут пишем свой код под себя, чтобы запускать на своей машине своими руками. Мы любим свой код, а не смотреть, как наш код любят какие-то посторонние люди с длинными, толстыми и липкими пальцами. Иди отсюда уже, оставил спам ссылку на вакансию и до свидания.
>>41844
Хм, согласен с тобой. Действительно, такой подход будет более отзывчивым. Во всяком случае, он будет более толерантным к ошибкам - т.е. когда игрок случайно продолжает удерживать предыдущую клавишу, уже нажимая следующую. Очень умно ты придумал. Но, всё же, мне кажется, что те люди, кто много играет в видеоигры, не испытывают таких проблем, во всяком случае на привычной клавиатуре (у разных клавиатур разная длина хода клавиш).
>>41847
- мозговой штурм
- концепт-арты
- поиск референсов
- генераторы идей
Общий принцип: набрать максимум идей и затем отобрать среди них подходящие.
>Мне она кажется более интуитивной и отзывчивой
>Даже 50-100 миллисекунд могут спасти ситуацию и помочь убежать
Хм, согласен с тобой. Действительно, такой подход будет более отзывчивым. Во всяком случае, он будет более толерантным к ошибкам - т.е. когда игрок случайно продолжает удерживать предыдущую клавишу, уже нажимая следующую. Очень умно ты придумал. Но, всё же, мне кажется, что те люди, кто много играет в видеоигры, не испытывают таких проблем, во всяком случае на привычной клавиатуре (у разных клавиатур разная длина хода клавиш).
>>41847
>игры пустыми получаются
- мозговой штурм
- концепт-арты
- поиск референсов
- генераторы идей
Общий принцип: набрать максимум идей и затем отобрать среди них подходящие.
4 Мб, 2880x1800>>41916
Компания акредитирована минцифрой - брони для айтишников.
Годо используется в куче компонентов, как внутри - так и вне машины (всякие лабораторные установки). Не доверяешь хх - оставляй(те) телегу, дискорд, блин. Начальство сказало искать достойных годотеров, значит, ищу.
Компания акредитирована минцифрой - брони для айтишников.
Годо используется в куче компонентов, как внутри - так и вне машины (всякие лабораторные установки). Не доверяешь хх - оставляй(те) телегу, дискорд, блин. Начальство сказало искать достойных годотеров, значит, ищу.
>>41925
Искать достойных... на дваче? Серьёзно? К успеху идёте.
Ты так и не ответил на главный вопрос: чем заряжать будете? Что-то я не вижу точек быстрой зарядки и/или замены электромобильных аккумуляторов, плотно натыканных по всей России. Может быть в Москве и есть 3.5 точки, где можно зарядить Теслу, но вы же, наверное, не 3.5 машины выпустить хотите, да вам никто и не разрешит заряжаться от чужой розетки. А главный прикол Теслы - не сама Тесла, а сервис по быстрой замене аккумулятора, чтобы не ждать зарядки у розетки. У вас такое будет? Или только игрушки на встроенном мониторчике? Если нет зарядки, зачем покупать электромобиль?
>Начальство сказало искать достойных годотеров, значит, ищу.
Искать достойных... на дваче? Серьёзно? К успеху идёте.
Ты так и не ответил на главный вопрос: чем заряжать будете? Что-то я не вижу точек быстрой зарядки и/или замены электромобильных аккумуляторов, плотно натыканных по всей России. Может быть в Москве и есть 3.5 точки, где можно зарядить Теслу, но вы же, наверное, не 3.5 машины выпустить хотите, да вам никто и не разрешит заряжаться от чужой розетки. А главный прикол Теслы - не сама Тесла, а сервис по быстрой замене аккумулятора, чтобы не ждать зарядки у розетки. У вас такое будет? Или только игрушки на встроенном мониторчике? Если нет зарядки, зачем покупать электромобиль?
>>41844
А тебе нужно учитывать движение по диагоналям?
Смотри, я немного код поправил, добавив поддержку диагоналей.
А тебе нужно учитывать движение по диагоналям?
Смотри, я немного код поправил, добавив поддержку диагоналей.
>>41844
Вектор с кнопок возвращает -1, 0 или +1. Соответственно когда нажаты обе кнопки он возвращает +1-1=0, что потом отдельно обрабатывается (если 0, а кнопка все же нажата, то двигать в противоположенную сторону последнему сохраненному направлению по этой оси).
Вектор с кнопок возвращает -1, 0 или +1. Соответственно когда нажаты обе кнопки он возвращает +1-1=0, что потом отдельно обрабатывается (если 0, а кнопка все же нажата, то двигать в противоположенную сторону последнему сохраненному направлению по этой оси).
>>41899
Крайне советую переписать все на c++ и скомпилировать как модуль. Гдскрипт вскрывается на раз два, ты же не хочешь, чтобы твою машину потом хакнули через магнитолу.
Крайне советую переписать все на c++ и скомпилировать как модуль. Гдскрипт вскрывается на раз два, ты же не хочешь, чтобы твою машину потом хакнули через магнитолу.
>>42015
Там не будет никакой машины, лол. Просто кабанчики грант попилят, бурную деятельность поимитируют. Для этого очень важно понабрать анонимных омежек с двачей в разработчики, чтобы когда всё развалится, омежки засунули языки в жопы.
Там не будет никакой машины, лол. Просто кабанчики грант попилят, бурную деятельность поимитируют. Для этого очень важно понабрать анонимных омежек с двачей в разработчики, чтобы когда всё развалится, омежки засунули языки в жопы.
>>42018
А не то, видишь ли, "деанон от Серёги".
> чтобы когда всё развалится, омежки засунули языки в жопы
А не то, видишь ли, "деанон от Серёги".
>>42015
Это же фронтэнд, какая разница на чем он сделан.
>ты же не хочешь, чтобы твою машину потом хакнули через магнитолу.
Это же фронтэнд, какая разница на чем он сделан.
>>42022
Да нет никакого лучше, на чём хочешь, на том и делай, там по любому внутри будет стоять АРМ и андроид на нём, так что ситуация никак не отличается от этих ваших игрушек в гугл плей
Да нет никакого лучше, на чём хочешь, на том и делай, там по любому внутри будет стоять АРМ и андроид на нём, так что ситуация никак не отличается от этих ваших игрушек в гугл плей
>>42024
Не-а.
В случае с Авалонией не обязательно тащить за собой на портативную железку целый андроид. Формочки Авалонии могут запускаться прямо во фреймбуфере. А это значит автор такой магнитолы (сферической вакуумной) может прошить в неё минимальный линукс, который только фреймбуфер запускает. Ну и дотнет конечно. Это ещё 100 мегабайт сверху.
И ты получаешь шустрый, удобный интерфейс, да ещё и на божественном сишарпе.
Кроме того, разраб Авалонии - российский, так что, выбирая её, ты поддерживаешь отечественного разработчика.
> там по любому внутри будет стоять АРМ и андроид на нём
Не-а.
В случае с Авалонией не обязательно тащить за собой на портативную железку целый андроид. Формочки Авалонии могут запускаться прямо во фреймбуфере. А это значит автор такой магнитолы (сферической вакуумной) может прошить в неё минимальный линукс, который только фреймбуфер запускает. Ну и дотнет конечно. Это ещё 100 мегабайт сверху.
И ты получаешь шустрый, удобный интерфейс, да ещё и на божественном сишарпе.
Кроме того, разраб Авалонии - российский, так что, выбирая её, ты поддерживаешь отечественного разработчика.
>>42026
Спасибо за познавательную рекламу, но расскажи как пользователь без ебли будет устанавливать себе приложения из гугл плея?
Спасибо за познавательную рекламу, но расскажи как пользователь без ебли будет устанавливать себе приложения из гугл плея?
>>42047
Ну это уже моё дело как покупателя, какую я там навигацию хочу поставить и видеоплеер
Ну не будет гуглоплэя, будет нашстор или ещё какая ебан, главное чтоб в основе андроид решающий все проблемы
>Зачем тебе приложения гугльплея?
Ну это уже моё дело как покупателя, какую я там навигацию хочу поставить и видеоплеер
>Все равно в России с ним будут проблемы
Ну не будет гуглоплэя, будет нашстор или ещё какая ебан, главное чтоб в основе андроид решающий все проблемы
>>42050
Какую господин Илья Маскин продаёт, такой и будешь пользоваться. Ишь расслабились, зумеры. Хочешь свой навигатор - купи держатель для мобилы в торпеду.
Уууу блять, как всё запущено. Андроид у восторженного нубаса-школьника, возомнившего себя великим Ильёй Маскиным небоходцем, андроид у него решает все проблемы.
А НИЧЕГО, БЛЯТЬ, ЧТО АНДРОИД В АВТОМАГНИТОЛЕ - ЭТО И ЕСТЬ ПРОБЛЕМА, КОТОРУЮ СЛЕДУЕТ РЕШАТЬ?
> какую я там навигацию хочу поставить и видеоплеер
Какую господин Илья Маскин продаёт, такой и будешь пользоваться. Ишь расслабились, зумеры. Хочешь свой навигатор - купи держатель для мобилы в торпеду.
> андроид решающий все проблемы
Уууу блять, как всё запущено. Андроид у восторженного нубаса-школьника, возомнившего себя великим Ильёй Маскиным небоходцем, андроид у него решает все проблемы.
А НИЧЕГО, БЛЯТЬ, ЧТО АНДРОИД В АВТОМАГНИТОЛЕ - ЭТО И ЕСТЬ ПРОБЛЕМА, КОТОРУЮ СЛЕДУЕТ РЕШАТЬ?
>>42052
Если андроид вдруг почему то проблема (нет), то уж решение точно не дотнкт.
Если андроид вдруг почему то проблема (нет), то уж решение точно не дотнкт.
436 Кб, 1920x1080Вы тут уже мою магнитолу написанную на Годоте обсуждаете?
Ахаха, я был прав на счёт студенторабов:
https://nticenter.spbstu.ru/article/kama-1
Фотки каких-то довольных старпёров прилагаются.
Алсо:
Что и следовало ожидать: бесполезный прототип электромобиля сделали, а зарядных станций как не было, так и нет - одни только желания.
А вы тут всё про магнитолы, магнитолы...
https://nticenter.spbstu.ru/article/kama-1
>Впервые автомобиль был не только разработан, но и подготовлен к серийному производству не промышленным предприятием, а именно университетом: Петербургским Политехом.
Фотки каких-то довольных старпёров прилагаются.
Алсо:
>«Это интересный проект и очень современный. Полагаю, сейчас каждая страна думает о том, как сделать транспорт в городах более экологичным.
>Такие темы всегда привлекают внимание, и, действительно, очень интересно узнать о том, как будет развиваться проект, будет ли организовано серийное производство.
>Это очень важно, потому что многие проекты заканчиваются прототипами. Здесь мне бы очень хотелось, чтобы «КАМА-1» развивалась дальше. Дизайн автомобиля очень красивый, современный и, я бы сказал, стремительный. Желаю, чтобы в городе стало больше станций зарядки электромобилей!»
Что и следовало ожидать: бесполезный прототип электромобиля сделали, а зарядных станций как не было, так и нет - одни только желания.
А вы тут всё про магнитолы, магнитолы...
>>42070
Чел ты ебанутый? Да всем поебать выйдет он или нет. Выйдет - хорошо, нет - хуй с ним. Откуда у тебя такая возбужденность на ровном месте?
Чел ты ебанутый? Да всем поебать выйдет он или нет. Выйдет - хорошо, нет - хуй с ним. Откуда у тебя такая возбужденность на ровном месте?
Короче. Сам я не програмист. Знаю только иф элсы всякие. Так вот. Есть же такая вещь как "функция". Как ими пользоваться правильно? Можно с примером? Я понимаю, что функции это основа основ, но как их использовать и зачем, в силу отсутствия опыта, вообще не представляю. Типо, я же могу еë где то один раз написать, а потом вызывать постоянно меняя при этом переменные внутри... Или нет? Сорян за тупой вопрос.
>>42114
Самых частых кандидатов 3
1. Математические функции. a = sin(x).
например тебе может понадобиться функция среднего:
func average(a, b): return (a+b)/2
2. Глаголы-действия
например erase_disk("C:")
Если функция определена внутри класса (а обычные скрипты в годоте это классы)
то ее еще называют методом этого класса.
Тогда ее можно вызывать у объекта:
player.shoot()
dog.bark()
отдельно можно упомянуть "set" и "get" которые часто используются в программировании
coord = planet.get_position()
rocket.set_position(coord)
Иногда такую переменную называют свойством, а в годоте setget
В данном случае это примерно тоже что написать
coord = planet.position
rocket.position = coord
Но при этом в этих функциях-геттерах и сеттерах могут проводиться дополнительные вычисления
3. Обработчики событий
наглядный пример - _ready() и _process() которые ты пишешь
Это функции которые вызовет сам движок когда придет время
Сюда же относятся приемники сигналов
button.connect("pressed", self, "on_pressed")
...
func on_pressed(): ...
Самых частых кандидатов 3
1. Математические функции. a = sin(x).
например тебе может понадобиться функция среднего:
func average(a, b): return (a+b)/2
2. Глаголы-действия
например erase_disk("C:")
Если функция определена внутри класса (а обычные скрипты в годоте это классы)
то ее еще называют методом этого класса.
Тогда ее можно вызывать у объекта:
player.shoot()
dog.bark()
отдельно можно упомянуть "set" и "get" которые часто используются в программировании
coord = planet.get_position()
rocket.set_position(coord)
Иногда такую переменную называют свойством, а в годоте setget
В данном случае это примерно тоже что написать
coord = planet.position
rocket.position = coord
Но при этом в этих функциях-геттерах и сеттерах могут проводиться дополнительные вычисления
3. Обработчики событий
наглядный пример - _ready() и _process() которые ты пишешь
Это функции которые вызовет сам движок когда придет время
Сюда же относятся приемники сигналов
button.connect("pressed", self, "on_pressed")
...
func on_pressed(): ...
>>42114
Самых частых кандидатов 3
1. Математические функции. a = sin(x).
например тебе может понадобиться функция среднего:
func average(a, b): return (a+b)/2
2. Глаголы-действия
например erase_disk("C:")
Если функция определена внутри класса (а обычные скрипты в годоте это классы)
то ее еще называют методом этого класса.
Тогда ее можно вызывать у объекта:
player.shoot()
dog.bark()
отдельно можно упомянуть "set" и "get" которые часто используются в программировании
coord = planet.get_position()
rocket.set_position(coord)
Иногда такую переменную называют свойством, а в годоте setget
В данном случае это примерно тоже что написать
coord = planet.position
rocket.position = coord
Но при этом в этих функциях-геттерах и сеттерах могут проводиться дополнительные вычисления
3. Обработчики событий
наглядный пример - _ready() и _process() которые ты пишешь
Это функции которые вызовет сам движок когда придет время
Сюда же относятся приемники сигналов
button.connect("pressed", self, "on_pressed")
...
func on_pressed(): ...
Самых частых кандидатов 3
1. Математические функции. a = sin(x).
например тебе может понадобиться функция среднего:
func average(a, b): return (a+b)/2
2. Глаголы-действия
например erase_disk("C:")
Если функция определена внутри класса (а обычные скрипты в годоте это классы)
то ее еще называют методом этого класса.
Тогда ее можно вызывать у объекта:
player.shoot()
dog.bark()
отдельно можно упомянуть "set" и "get" которые часто используются в программировании
coord = planet.get_position()
rocket.set_position(coord)
Иногда такую переменную называют свойством, а в годоте setget
В данном случае это примерно тоже что написать
coord = planet.position
rocket.position = coord
Но при этом в этих функциях-геттерах и сеттерах могут проводиться дополнительные вычисления
3. Обработчики событий
наглядный пример - _ready() и _process() которые ты пишешь
Это функции которые вызовет сам движок когда придет время
Сюда же относятся приемники сигналов
button.connect("pressed", self, "on_pressed")
...
func on_pressed(): ...
>>42127
Ммм. Ну с математическими понятно. А вот про player.shoot() по подробнее. Это не годотовская функция, ведь так? Значит мне её где-то самому писать нужно. Где лучше это сделать? Дальше. Например у меня в ней считается и применяется дамаг по врагу. То есть, я не каждый раз как идиот формулу пишу, а просто вызываю функцию как белый человек, так? И ещё вопрос. Переменные в годоте вводить только таким образом?:
var a
var b
var c
Или можно как-то скомпоновать? А то вроде как в сишке подряд можно через запятую перечислить. На сайт заходил, документацию смотрел, примера с перечислением не нашёл.
Ммм. Ну с математическими понятно. А вот про player.shoot() по подробнее. Это не годотовская функция, ведь так? Значит мне её где-то самому писать нужно. Где лучше это сделать? Дальше. Например у меня в ней считается и применяется дамаг по врагу. То есть, я не каждый раз как идиот формулу пишу, а просто вызываю функцию как белый человек, так? И ещё вопрос. Переменные в годоте вводить только таким образом?:
var a
var b
var c
Или можно как-то скомпоновать? А то вроде как в сишке подряд можно через запятую перечислить. На сайт заходил, документацию смотрел, примера с перечислением не нашёл.
>>42113 (Del)
На хх там написано, что требуется сеньер помидор с 6 летним опытом. Ну а по факту то что требуется знать, можно пример тестового задания?
На хх там написано, что требуется сеньер помидор с 6 летним опытом. Ну а по факту то что требуется знать, можно пример тестового задания?
>>42130
Пока что только методом объявления словаря. Но ты теряешь типизацию.
> можно как-то скомпоновать?
Пока что только методом объявления словаря. Но ты теряешь типизацию.
> var my_vars = { a = 1, b = 2, c = 3 }
>>42113 (Del)
А, всё понятно, у вас даже рабочего прототипа нет, а вы уже магнитолу решили погромировать на Годо. Бизнес план из десяти, погромировать не буду.
Нет, серьёзно, проект один-в-один как у вас: "КАМА", студентота, "виртуальный двойник", электромобиль, про зарядные станции ни одного слова, 4 часа на 60 км/ч и потом 6 часов зарядки... Неплохо устроились.
Ты в курсе, что нормальные люди стараются не создавать одноимённых вещей в одной категории? Ты что-нибудь слышал про торговые марки и вообще как бизнес работает? Только мошенник будет создавать фирму-однодневку с похожим названием на другую, настоящую фирму, чтобы лохи вложили в эту фирму деньги, прежде чем она схлопнется с их деньгами. Нет уж, либо вы та студентота с прототипом КАМА-1, либо мошенники, пытающиеся нажиться на чужом имени. В любом случае работать на вас - себя не уважать. У программиста есть честь, и переступать через неё будут только кодомартышки.
Либо это Серёга нас всех тут троллить пытается. Нашёл какие-то вакансии, решил затроллить гдачеров.
>>42073
Ненавижу, когда мошенники пиарятся в том месте, где я сижу. Неизвестно, кто этот человек, но доказать свою честность он не пытается - как, обычно, и делают мошенники, потому что доказывать им нечего. Только вялые оправдания и пустые слова. И ладно бы если звал программировать слот-машины - это популярная тема у крупных пользователей Годо (неоднократно были большие пожертвования в движок от разных казино), но он нам затирает какую-то дичь про магнитолу для несуществующего электромобиля, имя которого "случайно" повторяет имя другого электромобиля... Тебе не кажется всё это слишком подозрительным? Кто его знает, что он там затеял, и кем ты в его схемах окажешься.
>Ты не думал что ты упомянул другой автомобиль?
А, всё понятно, у вас даже рабочего прототипа нет, а вы уже магнитолу решили погромировать на Годо. Бизнес план из десяти, погромировать не буду.
Нет, серьёзно, проект один-в-один как у вас: "КАМА", студентота, "виртуальный двойник", электромобиль, про зарядные станции ни одного слова, 4 часа на 60 км/ч и потом 6 часов зарядки... Неплохо устроились.
Ты в курсе, что нормальные люди стараются не создавать одноимённых вещей в одной категории? Ты что-нибудь слышал про торговые марки и вообще как бизнес работает? Только мошенник будет создавать фирму-однодневку с похожим названием на другую, настоящую фирму, чтобы лохи вложили в эту фирму деньги, прежде чем она схлопнется с их деньгами. Нет уж, либо вы та студентота с прототипом КАМА-1, либо мошенники, пытающиеся нажиться на чужом имени. В любом случае работать на вас - себя не уважать. У программиста есть честь, и переступать через неё будут только кодомартышки.
Либо это Серёга нас всех тут троллить пытается. Нашёл какие-то вакансии, решил затроллить гдачеров.
>>42073
>Откуда у тебя такая возбужденность на ровном месте?
Ненавижу, когда мошенники пиарятся в том месте, где я сижу. Неизвестно, кто этот человек, но доказать свою честность он не пытается - как, обычно, и делают мошенники, потому что доказывать им нечего. Только вялые оправдания и пустые слова. И ладно бы если звал программировать слот-машины - это популярная тема у крупных пользователей Годо (неоднократно были большие пожертвования в движок от разных казино), но он нам затирает какую-то дичь про магнитолу для несуществующего электромобиля, имя которого "случайно" повторяет имя другого электромобиля... Тебе не кажется всё это слишком подозрительным? Кто его знает, что он там затеял, и кем ты в его схемах окажешься.
>>42157
Спасибо.
Спасибо.
>>42114
У тебя в школе информатика ещё не началась?
https://ru.wikipedia.org/wiki/Подпрограмма
В программировании нет ничего "правильного" и "неправильного" относительно того, что не вызывает ошибок компиляции/выполнения. Есть только более эффективные способы и менее эффективные... Хороший программист должен уметь выбирать эффективный способ в каждой конкретной ситуации, а не использовать одно и то же для всего на свете.
Нет, в GDScript основа основ - это классы. Но тебе стоит сначала с базовым программированием разобраться, поделать простые задачки в консоли.
>>42130
Ты, похоже, вообще туториалы по Годо не читал? Там на каждом шагу создаются новые методы. Без понимания основ тебе бесполезно говорить, где "лучше".
Нет, в GDScript один var - одна переменная. Но ты можешь использовать точку с запятой для комбинации нескольких операций на одной строке:
Однако, во-первых, твои имена переменных должны иметь читаемое название - в большинстве случаев одной буквой называть переменную нерационально, кроме счётчика i и координат x, y и z. Если в физике пишут g, обозначая силу гравитации, то в коде ты должен писать gravity; если в физике пишут f для абстрактной силы, то в коде ты должен писать force, и так далее. Во-вторых, запись нескольких действий на одной строке ухудшает читаемость кода, поэтому официально разработчики Godot рекомендуют писать всё на отдельных строках.
>>42157
Это имеет смысл только когда тебе нужен словарь, то есть общее имя для набора переменных. Он же имел в виду простую экономию места, т.е. ему достаточно использовать точку с запятой.
>Есть же такая вещь как "функция".
У тебя в школе информатика ещё не началась?
https://ru.wikipedia.org/wiki/Подпрограмма
>Как ими пользоваться правильно?
В программировании нет ничего "правильного" и "неправильного" относительно того, что не вызывает ошибок компиляции/выполнения. Есть только более эффективные способы и менее эффективные... Хороший программист должен уметь выбирать эффективный способ в каждой конкретной ситуации, а не использовать одно и то же для всего на свете.
>функции это основа основ
Нет, в GDScript основа основ - это классы. Но тебе стоит сначала с базовым программированием разобраться, поделать простые задачки в консоли.
>>42130
>Где лучше это сделать?
Ты, похоже, вообще туториалы по Годо не читал? Там на каждом шагу создаются новые методы. Без понимания основ тебе бесполезно говорить, где "лучше".
>Или можно как-то скомпоновать?
Нет, в GDScript один var - одна переменная. Но ты можешь использовать точку с запятой для комбинации нескольких операций на одной строке:
>var a; var b; var c;
Однако, во-первых, твои имена переменных должны иметь читаемое название - в большинстве случаев одной буквой называть переменную нерационально, кроме счётчика i и координат x, y и z. Если в физике пишут g, обозначая силу гравитации, то в коде ты должен писать gravity; если в физике пишут f для абстрактной силы, то в коде ты должен писать force, и так далее. Во-вторых, запись нескольких действий на одной строке ухудшает читаемость кода, поэтому официально разработчики Godot рекомендуют писать всё на отдельных строках.
>>42157
Это имеет смысл только когда тебе нужен словарь, то есть общее имя для набора переменных. Он же имел в виду простую экономию места, т.е. ему достаточно использовать точку с запятой.
>>42173
Каюсь. Ответил мимоходом, а по факту дал вредный совет махровому новичку.
> Это имеет смысл только когда тебе нужен словарь, то есть общее имя для набора переменных. Он же имел в виду простую экономию места, т.е. ему достаточно использовать точку с запятой.
Каюсь. Ответил мимоходом, а по факту дал вредный совет махровому новичку.
2,7 Мб, 5124x3325>>41833 (OP)
ОП, зачем нужно было такую картинку ставить?
Поставил бы няшу Годетту - было бы больше постеров.
Алсо обидно, что никто так и не доставил новый вариант маскотов Godot от Tyson Tan, которые он вроде ещё весной нарисовал. Палитрой напоминает белку Kiki от него же для Krita, но всё же разница существенная. Моё мнение: дизайн хороший (кроме логотипа, он слишком банальный и G даже не читается), но Godot не соответствует... или я просто привык к оригиналу.
Хех, Tyson Tan вроде уже посылали с какого-то опенсурс проекта, для которого он запилил маскот, а ему ответили "у нас серьёзный софт, нам не нужны какие-то зверушки". Он обиделся и настрочил целую статью в каком-то своём блоге. Жалко его, в общем-то помочь хотел бесплатно, даже если всё это только ради его самопиара (если бы не Кики, я бы о нём вообще не узнал, лол!).
ОП, зачем нужно было такую картинку ставить?
Поставил бы няшу Годетту - было бы больше постеров.
Алсо обидно, что никто так и не доставил новый вариант маскотов Godot от Tyson Tan, которые он вроде ещё весной нарисовал. Палитрой напоминает белку Kiki от него же для Krita, но всё же разница существенная. Моё мнение: дизайн хороший (кроме логотипа, он слишком банальный и G даже не читается), но Godot не соответствует... или я просто привык к оригиналу.
Хех, Tyson Tan вроде уже посылали с какого-то опенсурс проекта, для которого он запилил маскот, а ему ответили "у нас серьёзный софт, нам не нужны какие-то зверушки". Он обиделся и настрочил целую статью в каком-то своём блоге. Жалко его, в общем-то помочь хотел бесплатно, даже если всё это только ради его самопиара (если бы не Кики, я бы о нём вообще не узнал, лол!).
>>42486
Если будешь выкладывать годный арт под конец треда ( с поста 490-го), то я конечно же подберу самый годный в следующий тред. А то обычно это происходит так:
Про то, что тайсон тян годетту рисует впервые слышу. Какого хуя нейросеть гугла мне её не подсовывала все эти годы?
Если будешь выкладывать годный арт под конец треда ( с поста 490-го), то я конечно же подберу самый годный в следующий тред. А то обычно это происходит так:
> Ой блять, бамплимит!
> Мы тонем, тонееем!
> Шапка, шапка, где блять шапка!
> Что придумать в в названии? Что? Что?
> Ебучий архивач, открывайся!
> Пикча. Пикча. Пикчаааа... Так, гуглим, годот арт, за месяц. Тааак. Эта была. Та была. Блять, ничего нового. ХЗ, ну вот эту вроде ничего.
Про то, что тайсон тян годетту рисует впервые слышу. Какого хуя нейросеть гугла мне её не подсовывала все эти годы?
>>42499
Гдачую, 30 страниц на доске (~600 тредов?), а активных тредов 3.5 штуки.
Последний тред на 30-й странице в данный момент (июнь 2021): >>747203 →
Так что паниковать не стоит. Лучше пофикси ссылку в ньюфаготреде.
>>42493
Достаточно иногда проверять r/godot и схоронять годноту.
Я и сам случайно наткнулся, когда искал "godot godette". На knowyourmeme залили какие-то картинки в низком разрешении, оригиналы что-то не нашёл:
https://knowyourmeme.com/search?context=images&q=tags%3A%28%22godot+engine%22%29
https://knowyourmeme.com/search?context=images&q=tags%3A%28%22tyson+tan%22%29
>тут тред года полтора тонуть будет
Гдачую, 30 страниц на доске (~600 тредов?), а активных тредов 3.5 штуки.
Последний тред на 30-й странице в данный момент (июнь 2021): >>747203 →
Так что паниковать не стоит. Лучше пофикси ссылку в ньюфаготреде.
>>42493
>Так, гуглим, годот арт, за месяц.
Достаточно иногда проверять r/godot и схоронять годноту.
>Про то, что тайсон тян годетту рисует впервые слышу.
Я и сам случайно наткнулся, когда искал "godot godette". На knowyourmeme залили какие-то картинки в низком разрешении, оригиналы что-то не нашёл:
https://knowyourmeme.com/search?context=images&q=tags%3A%28%22godot+engine%22%29
https://knowyourmeme.com/search?context=images&q=tags%3A%28%22tyson+tan%22%29
Неделю назад попытался нарисовать фанарт на Godot/Godette, но расстроился и забросил...
>>42618
А мне кажется вышло очень реалистично.
В этом фанарте прям весь дух Годота.
Ты очень хороший художник.
А мне кажется вышло очень реалистично.
В этом фанарте прям весь дух Годота.
Ты очень хороший художник.
>>42644
Сам ты троллинг.
Я в этех двух картинках вижу Волка на Кубе и ту выстрелившую игра про Купол.
Реально же ДУХ ГОДОТА.
Сам ты троллинг.
Я в этех двух картинках вижу Волка на Кубе и ту выстрелившую игра про Купол.
Реально же ДУХ ГОДОТА.
211 Кб, 800x450Хуан наебал. Гадкий утенок не стал лебедем. Единственное что улучшилось за 5 лет разработки - это личная жизнь Хуана. Расходимся.
Я зря потратил 5 лет на изучение годота. Верните мне мои годы.
Я зря потратил 5 лет на изучение годота. Верните мне мои годы.
>>42742 (Del)
Похоже на троллинг
>Мы команда, которая создает инновационный электромобиль, превращает авто в гаджет
>ищут ведущего разработчика по объявлению, удаленная работа
>интерфейс машины на годоте
Похоже на троллинг
160 Кб, 609x325>>42742 (Del)
У них в объявлениях все подряд, начиная от "архитекторов машины", "дизайнеров машины" и заканчивая всеми возможными фремворками, движками (flutter, unreal engine) и вплоть до бухгалтера и уборщицы.
У меня от этого пикрелейтед
У них в объявлениях все подряд, начиная от "архитекторов машины", "дизайнеров машины" и заканчивая всеми возможными фремворками, движками (flutter, unreal engine) и вплоть до бухгалтера и уборщицы.
У меня от этого пикрелейтед
168 Кб, mp4,208x162, 0:05
>>41846
Лучшее качество для ведущего разработчика на годоте, я считаю.
>умение не использовать ООП если этого не нужно;
Лучшее качество для ведущего разработчика на годоте, я считаю.
32 Кб, 500x349>>42749
Ну, типа, можно рассматривать методы класса в скрипте как простые процедуры и писать процедурно в рамках одного скрипта; можно применить функциональный подход, опять же в рамках одного скрипта, рассматривая методы как функции и лишь единожды присваивая значение каждой переменной; можно придумать свой формат декларативной записи чего-либо и парсер для этого формата, чтобы писать часть проекта вообще не на GDScript, а в отдельных файлах.
Ну, типа, можно рассматривать методы класса в скрипте как простые процедуры и писать процедурно в рамках одного скрипта; можно применить функциональный подход, опять же в рамках одного скрипта, рассматривая методы как функции и лишь единожды присваивая значение каждой переменной; можно придумать свой формат декларативной записи чего-либо и парсер для этого формата, чтобы писать часть проекта вообще не на GDScript, а в отдельных файлах.
>>42772 (Del)
Так вы "построили здание" больше года назад, но персонал так и не нашли?
TL;DR: бумеры услышали модные слова и решили подлизнуть зумерам.
ПОЧЕМУ Я ДОЛЖЕН ВСЁ ЭТО САМ ГУГЛИТЬ, ПОЧЕМУ ТЫ НЕ МОЖЕШЬ САМ ДОСТАВИТЬ? ТЕБЕ НЕ НУЖНЫ СОТРУДНИКИ? ТЫ ПРИШЁЛ ПОКИДАТЬ АНИМЕ-КАРТИНОК В НАДЕЖДЕ, ЧТО ОНИ ЗАЦЕПЯТ КАКОГО-НИБУДЬ АНИМЕШНИКА? ДА, НАС ПРИ ОЦЕНКЕ ВАКАНСИИ ИНТЕРЕСУЕТ ТОЛЬКО ТО, КИДАЮТ ЛИ В НАС АНИМЕ-КАРТИНКИ ИЛИ НЕТ, БЕЗ АНИМЕ КОД ВООБЩЕ ПИСАТЬ НЕВОЗМОЖНО, ОСОБЕННО НА GODOT.
>Ты думал что персонал как в стратежках сам появляется как здание построишь?
Так вы "построили здание" больше года назад, но персонал так и не нашли?
>АКЦИОНЕРНОЕ ОБЩЕСТВО "КАМА"
>Дата регистрации: 05.08.2021
>Юридический адрес: 423824, Республика Татарстан, г Набережные Челны, Машиностроительная ул, д. 91, этаж 9 помещ. 13
>Руководитель: Генеральный директор Поваразднюк Игорь Валериевич с 5 августа 2021 г.
>Основной вид деятельности: Разработка компьютерного программного обеспечения (62.01)
>Собственники: Варданян Рубен Карленович, КамАЗ
>Продукты (ит-системы) данного вендора:
>Кама-2 (электромобиль)
>Кама Атом (электромобиль)
>История: 2021: Привлечение инвестиций от Рубена Варданяна
>9 декабря 2021 года стало известно о вхождении Рубена Варданяна в число инвесторов проекта компактного городского электромобиля «Кама».
>Я присоединился к консорциуму инвесторов, поверил в этот проект и поддержал ребят на этапе идеи. Считаю, что его ждет большое будущее, — сказал «Ведомостям» Варданян через своего представителя.
>Отмечается, что ранее проект развивался при участии «КамАЗа», но впоследствии стал отдельным стартапом — в августе 2021 года было зарегистрировано АО «Кама» с уставным капиталом 720 млн рублей. Его главой указан бывший менеджер блока развития перспективных проектов «КамАЗа» Игорь Поваразднюк.
>По сообщению газеты, в конце ноября 2021 года в инновационном центре «Сколково» проект «Кама» презентовали для инвесторов.
>Генеральный директор «КамАЗа» Сергей Когогин уточнил, что речь идет о совершенно новом электромобиле «Кама», который не стоит путать с концептом «Кама-1».
>Во сколько оценят электрокроссовер, к декабрю 2021 года. В 2020-м предварительную цену модели «Кама-1» называли в пределах 1,2-1,4 млн рублей.
>Один из собеседников «Ведомостей» отметил, что проект «Кама» делался в расчете на то, что государство поддержит развитие собственных технологий электротранспорта. Однако, согласно принятой концепции развития электротранспорта, упор делается на локализацию в России иностранных электромобилей. По словам собеседника, необходимость в дальнейшей разработке платформы существует.
>2022: Раскрыты характеристики электромобиля
>В середине июля 2022 года стали известны характеристики российского электромобиля «Кама-2».
>Утверждается, что проект «Кама-2» не имеет ничего общего с шоу-каром «Кама-1», который спроектировали в 2020 году в центре компьютерного инжиниринга, который входит в Санкт-Петербургский политехнический университет.
>Над проектом «Кама-2» работает компания АО «Кама», аффилированная с КамАЗом и софинансируемая гендиректором челнинского производителя Сергеем Когогиным.
>Городской электромобиль может выйти на рынок в 2024-2025 годах, сообщал ранее Когогин. По его словам, основными сферами использования машины станут каршеринг и такси.
>2022: Названы сроки начала продаж электромобиля
>23 ноября 2022 года стал известны сроки начала продаж электромобиля «Атом». По словам исполнительного директора АО «Кама» Харальда Грюбеля, функциональный прототип машины будет показан в 2023 году, а приобрести новинку можно будет в 2025-м.
>Грюбель говорит, что важной задачей компании стало «изменение формата отношений между человеком и электромобилем», также при разработке машин учитываются потребности молодого поколения.
>О том, что прототипы «Атома» планируется представить в 2023 году, в ноябре 2022-го рассказывал генеральный директор ПАО «КамАЗ» Сергей Когогин, который вместе с бизнесменом Рубеном Варданяном инвестировал в развитие проекта.
>По данным RTVI, стартап планирует потратить $20 млн на приобретение простаивающего завода Ford Motor Company в Набережных Челнах.
>Также, согласно презентации, «Атом» планирует производить четыре модели электромобилей: двухдверную городскую «Дуо», семейную «Фэмили», отдельные авто для такси и доставки. Ожидается, что у всех моделей максимальный запас хода составит 500 км на одном заряде.
>Ранее газета «Ведомости» сообщала, что электромобиль «Кама» рассматривается в качестве основы для производства автомобилей «Москвич».
>До начала специальной военной операции на Украине у «Камы» были оптимистичные планы по экспансии на рынке. В презентации в феврале 2022 года компания предполагала выход на выпуск 450 000 электромобилей в год к 2030-му, часть из них предполагалось собирать в Венгрии. Российский рынок машин на электротяге к 2025 году «Кама» оценивала в 100 000 штук.
>АТОМ — именно так мы назвали свой электромобиль. Мы мечтаем о том, чтобы наши электромобили-атомы уже к 2025 году стали неотъемлемой частью технологичной жизни сообщества атомов-людей. АТОМ включает в себя создание цифровой среды мобильности и сам электромобиль. — рассказал Игорь Поваразднюк, генеральный директор АО КАМА
>По информации компании, артерии городов наполняет другая мобильность. Каршеринг, такси, доставка всего — это существенная часть обычного городского дня, наряду с социальными сетями, мессенджерами, подписками, коворкингами, метавселенными и NFT. Задача команды – сделать электромобиль, соответствующий такому образу жизни.
>При разработке проекта важно учесть не только технологические, автомобильные тренды, но и создать ментально, мировоззренчески- современный продукт. Учитывая масштаб изменений в мышлении и образе жизни людей даже за последние 10 лет, с нашей стороны было бы неправильным предлагать пользователям просто электродвигатель вместо ДВС и более продвинутые характеристики автомобиля. — прокомментировал Игорь Поваразднюк, генеральный директор АО КАМА
>Для решения задачи собрана команда продуктовых специалистов, IT-разработчиков, UX- дизайнеров из разных областей: от мобильности до гейминга, от финтеха до блокчейна. В международной инженерно-технической команде АТОМ уже на ноябрь 2022 года более 250 автомобильных конструкторов и IT-разработчиков, имеющих опыт реализации крупнейших проектов в сферах электротранспорта, мобильности и экосистем в России, Китае, Европе и США. География команды охватывает множество городов и стран. Но ее сердце, идейный центр вдохновения, расположено в одной из автомобильных столиц России — в городе Набережные Челны.
TL;DR: бумеры услышали модные слова и решили подлизнуть зумерам.
ПОЧЕМУ Я ДОЛЖЕН ВСЁ ЭТО САМ ГУГЛИТЬ, ПОЧЕМУ ТЫ НЕ МОЖЕШЬ САМ ДОСТАВИТЬ? ТЕБЕ НЕ НУЖНЫ СОТРУДНИКИ? ТЫ ПРИШЁЛ ПОКИДАТЬ АНИМЕ-КАРТИНОК В НАДЕЖДЕ, ЧТО ОНИ ЗАЦЕПЯТ КАКОГО-НИБУДЬ АНИМЕШНИКА? ДА, НАС ПРИ ОЦЕНКЕ ВАКАНСИИ ИНТЕРЕСУЕТ ТОЛЬКО ТО, КИДАЮТ ЛИ В НАС АНИМЕ-КАРТИНКИ ИЛИ НЕТ, БЕЗ АНИМЕ КОД ВООБЩЕ ПИСАТЬ НЕВОЗМОЖНО, ОСОБЕННО НА GODOT.
>>42772 (Del)
Так вы "построили здание" больше года назад, но персонал так и не нашли?
TL;DR: бумеры услышали модные слова и решили подлизнуть зумерам.
ПОЧЕМУ Я ДОЛЖЕН ВСЁ ЭТО САМ ГУГЛИТЬ, ПОЧЕМУ ТЫ НЕ МОЖЕШЬ САМ ДОСТАВИТЬ? ТЕБЕ НЕ НУЖНЫ СОТРУДНИКИ? ТЫ ПРИШЁЛ ПОКИДАТЬ АНИМЕ-КАРТИНОК В НАДЕЖДЕ, ЧТО ОНИ ЗАЦЕПЯТ КАКОГО-НИБУДЬ АНИМЕШНИКА? ДА, НАС ПРИ ОЦЕНКЕ ВАКАНСИИ ИНТЕРЕСУЕТ ТОЛЬКО ТО, КИДАЮТ ЛИ В НАС АНИМЕ-КАРТИНКИ ИЛИ НЕТ, БЕЗ АНИМЕ КОД ВООБЩЕ ПИСАТЬ НЕВОЗМОЖНО, ОСОБЕННО НА GODOT.
>Ты думал что персонал как в стратежках сам появляется как здание построишь?
Так вы "построили здание" больше года назад, но персонал так и не нашли?
>АКЦИОНЕРНОЕ ОБЩЕСТВО "КАМА"
>Дата регистрации: 05.08.2021
>Юридический адрес: 423824, Республика Татарстан, г Набережные Челны, Машиностроительная ул, д. 91, этаж 9 помещ. 13
>Руководитель: Генеральный директор Поваразднюк Игорь Валериевич с 5 августа 2021 г.
>Основной вид деятельности: Разработка компьютерного программного обеспечения (62.01)
>Собственники: Варданян Рубен Карленович, КамАЗ
>Продукты (ит-системы) данного вендора:
>Кама-2 (электромобиль)
>Кама Атом (электромобиль)
>История: 2021: Привлечение инвестиций от Рубена Варданяна
>9 декабря 2021 года стало известно о вхождении Рубена Варданяна в число инвесторов проекта компактного городского электромобиля «Кама».
>Я присоединился к консорциуму инвесторов, поверил в этот проект и поддержал ребят на этапе идеи. Считаю, что его ждет большое будущее, — сказал «Ведомостям» Варданян через своего представителя.
>Отмечается, что ранее проект развивался при участии «КамАЗа», но впоследствии стал отдельным стартапом — в августе 2021 года было зарегистрировано АО «Кама» с уставным капиталом 720 млн рублей. Его главой указан бывший менеджер блока развития перспективных проектов «КамАЗа» Игорь Поваразднюк.
>По сообщению газеты, в конце ноября 2021 года в инновационном центре «Сколково» проект «Кама» презентовали для инвесторов.
>Генеральный директор «КамАЗа» Сергей Когогин уточнил, что речь идет о совершенно новом электромобиле «Кама», который не стоит путать с концептом «Кама-1».
>Во сколько оценят электрокроссовер, к декабрю 2021 года. В 2020-м предварительную цену модели «Кама-1» называли в пределах 1,2-1,4 млн рублей.
>Один из собеседников «Ведомостей» отметил, что проект «Кама» делался в расчете на то, что государство поддержит развитие собственных технологий электротранспорта. Однако, согласно принятой концепции развития электротранспорта, упор делается на локализацию в России иностранных электромобилей. По словам собеседника, необходимость в дальнейшей разработке платформы существует.
>2022: Раскрыты характеристики электромобиля
>В середине июля 2022 года стали известны характеристики российского электромобиля «Кама-2».
>Утверждается, что проект «Кама-2» не имеет ничего общего с шоу-каром «Кама-1», который спроектировали в 2020 году в центре компьютерного инжиниринга, который входит в Санкт-Петербургский политехнический университет.
>Над проектом «Кама-2» работает компания АО «Кама», аффилированная с КамАЗом и софинансируемая гендиректором челнинского производителя Сергеем Когогиным.
>Городской электромобиль может выйти на рынок в 2024-2025 годах, сообщал ранее Когогин. По его словам, основными сферами использования машины станут каршеринг и такси.
>2022: Названы сроки начала продаж электромобиля
>23 ноября 2022 года стал известны сроки начала продаж электромобиля «Атом». По словам исполнительного директора АО «Кама» Харальда Грюбеля, функциональный прототип машины будет показан в 2023 году, а приобрести новинку можно будет в 2025-м.
>Грюбель говорит, что важной задачей компании стало «изменение формата отношений между человеком и электромобилем», также при разработке машин учитываются потребности молодого поколения.
>О том, что прототипы «Атома» планируется представить в 2023 году, в ноябре 2022-го рассказывал генеральный директор ПАО «КамАЗ» Сергей Когогин, который вместе с бизнесменом Рубеном Варданяном инвестировал в развитие проекта.
>По данным RTVI, стартап планирует потратить $20 млн на приобретение простаивающего завода Ford Motor Company в Набережных Челнах.
>Также, согласно презентации, «Атом» планирует производить четыре модели электромобилей: двухдверную городскую «Дуо», семейную «Фэмили», отдельные авто для такси и доставки. Ожидается, что у всех моделей максимальный запас хода составит 500 км на одном заряде.
>Ранее газета «Ведомости» сообщала, что электромобиль «Кама» рассматривается в качестве основы для производства автомобилей «Москвич».
>До начала специальной военной операции на Украине у «Камы» были оптимистичные планы по экспансии на рынке. В презентации в феврале 2022 года компания предполагала выход на выпуск 450 000 электромобилей в год к 2030-му, часть из них предполагалось собирать в Венгрии. Российский рынок машин на электротяге к 2025 году «Кама» оценивала в 100 000 штук.
>АТОМ — именно так мы назвали свой электромобиль. Мы мечтаем о том, чтобы наши электромобили-атомы уже к 2025 году стали неотъемлемой частью технологичной жизни сообщества атомов-людей. АТОМ включает в себя создание цифровой среды мобильности и сам электромобиль. — рассказал Игорь Поваразднюк, генеральный директор АО КАМА
>По информации компании, артерии городов наполняет другая мобильность. Каршеринг, такси, доставка всего — это существенная часть обычного городского дня, наряду с социальными сетями, мессенджерами, подписками, коворкингами, метавселенными и NFT. Задача команды – сделать электромобиль, соответствующий такому образу жизни.
>При разработке проекта важно учесть не только технологические, автомобильные тренды, но и создать ментально, мировоззренчески- современный продукт. Учитывая масштаб изменений в мышлении и образе жизни людей даже за последние 10 лет, с нашей стороны было бы неправильным предлагать пользователям просто электродвигатель вместо ДВС и более продвинутые характеристики автомобиля. — прокомментировал Игорь Поваразднюк, генеральный директор АО КАМА
>Для решения задачи собрана команда продуктовых специалистов, IT-разработчиков, UX- дизайнеров из разных областей: от мобильности до гейминга, от финтеха до блокчейна. В международной инженерно-технической команде АТОМ уже на ноябрь 2022 года более 250 автомобильных конструкторов и IT-разработчиков, имеющих опыт реализации крупнейших проектов в сферах электротранспорта, мобильности и экосистем в России, Китае, Европе и США. География команды охватывает множество городов и стран. Но ее сердце, идейный центр вдохновения, расположено в одной из автомобильных столиц России — в городе Набережные Челны.
TL;DR: бумеры услышали модные слова и решили подлизнуть зумерам.
ПОЧЕМУ Я ДОЛЖЕН ВСЁ ЭТО САМ ГУГЛИТЬ, ПОЧЕМУ ТЫ НЕ МОЖЕШЬ САМ ДОСТАВИТЬ? ТЕБЕ НЕ НУЖНЫ СОТРУДНИКИ? ТЫ ПРИШЁЛ ПОКИДАТЬ АНИМЕ-КАРТИНОК В НАДЕЖДЕ, ЧТО ОНИ ЗАЦЕПЯТ КАКОГО-НИБУДЬ АНИМЕШНИКА? ДА, НАС ПРИ ОЦЕНКЕ ВАКАНСИИ ИНТЕРЕСУЕТ ТОЛЬКО ТО, КИДАЮТ ЛИ В НАС АНИМЕ-КАРТИНКИ ИЛИ НЕТ, БЕЗ АНИМЕ КОД ВООБЩЕ ПИСАТЬ НЕВОЗМОЖНО, ОСОБЕННО НА GODOT.
я правильно понимаю, что АО КАМА ищет главного программиста движка машины на годоте на дваче в разделе ГД?
у них даже движка на годоте еще нет, они даже "архитектора машины" еще не наняли по объявлению, зато уже посчитали стоимость несуществующей машины и сколько они их выпустят
у них даже движка на годоте еще нет, они даже "архитектора машины" еще не наняли по объявлению, зато уже посчитали стоимость несуществующей машины и сколько они их выпустят
>>42774
Как я понял, на Godot будет развлекательная система для магнитолы. Ведь это именно то, что нужно современному человеку в 2025 году: сидя в огромной пробке, на заднем сидении такси, смотреть мультики и играть в игрушки на встроенном в приборную панель мониторе, а ещё покупать/продавать NFT и майнить крипту на блокчейне.
Почему всё это нельзя сделать на смартфоне, планшете или ноутбуке - неизвестно. Наверное, делать это на смартфоне и ноутбуке всё-таки можно и даже удобнее (особенно в контексте такси и каршеринга), но тогда автомобиль нельзя будет назвать прорывным, современным, ориентированным на молодёжь и прочее, и прочее.
А зарядные станции пусть государство строит. Вот политики в Думе увидят, как Кама произвела 100 тысяч компактных электрокаров, увидят, как эти электрокары проехали 500 км и разрядились, и быстро-быстро построят зарядные станции на каждом углу в каждом городе. План 10/10, уже бегу программировать игры для магнитолы, а то ведь зумеры на машину без магнитолы даже не посмотрят и тогда план провалится - ведь если никто машину не купит, аккумулятор у неё не разрядится, и политики не построят зарядные станции.
>главного программиста движка машины на годоте
Как я понял, на Godot будет развлекательная система для магнитолы. Ведь это именно то, что нужно современному человеку в 2025 году: сидя в огромной пробке, на заднем сидении такси, смотреть мультики и играть в игрушки на встроенном в приборную панель мониторе, а ещё покупать/продавать NFT и майнить крипту на блокчейне.
Почему всё это нельзя сделать на смартфоне, планшете или ноутбуке - неизвестно. Наверное, делать это на смартфоне и ноутбуке всё-таки можно и даже удобнее (особенно в контексте такси и каршеринга), но тогда автомобиль нельзя будет назвать прорывным, современным, ориентированным на молодёжь и прочее, и прочее.
А зарядные станции пусть государство строит. Вот политики в Думе увидят, как Кама произвела 100 тысяч компактных электрокаров, увидят, как эти электрокары проехали 500 км и разрядились, и быстро-быстро построят зарядные станции на каждом углу в каждом городе. План 10/10, уже бегу программировать игры для магнитолы, а то ведь зумеры на машину без магнитолы даже не посмотрят и тогда план провалится - ведь если никто машину не купит, аккумулятор у неё не разрядится, и политики не построят зарядные станции.
>>42772 (Del)
ну да. стартап это команда, идея и рабочий продукт, которому нужно финансирование
ждем стартапы по производству процессоров и видеокарт, с объявлениями "ищу архитектора современного процессора x86_64", "ищу архитектора видеокарты с поддержкой dx12 ultimate и трассировкой лучей, чтобы не меньше чем 100 фпс на ультрах в киберпанке было!"
>персонал как в стратежках сам появляется как здание построишь?
ну да. стартап это команда, идея и рабочий продукт, которому нужно финансирование
ждем стартапы по производству процессоров и видеокарт, с объявлениями "ищу архитектора современного процессора x86_64", "ищу архитектора видеокарты с поддержкой dx12 ultimate и трассировкой лучей, чтобы не меньше чем 100 фпс на ультрах в киберпанке было!"
>>42771
Да, этим ещё статические методы обычно занимаются. Только массово они в классе не нужны, иначе зачем тебе класс - типо контейнер для функций? Ну такое.
Да я в общем-то понимаю, о чём эта фраза может быть, например наследование оказалось говном в массе и чаще надо использовать композицию, древнее понимание ООП в современном программировании будет только вредным.
Просто в резюме это очень смешно выглядит, скорее всего это значит что там будет куча говнокода, ибо я уверен если бы кто-то начал нормально разговаривать за подходы в программировании - интервьювер бы просто слился. В этой теории не понимает вообще никто кроме 2.5 анонимов которые этим именно занимаются, всякие СОЛИД - это баззворды чтобы отсеивать умственно отсталых, а геймдев - это вообще сборище говноедов, которые пишут говнокод.
>методы класса в скрипте как простые процедуры и писать процедурно в рамках одного скрипта
Да, этим ещё статические методы обычно занимаются. Только массово они в классе не нужны, иначе зачем тебе класс - типо контейнер для функций? Ну такое.
Да я в общем-то понимаю, о чём эта фраза может быть, например наследование оказалось говном в массе и чаще надо использовать композицию, древнее понимание ООП в современном программировании будет только вредным.
Просто в резюме это очень смешно выглядит, скорее всего это значит что там будет куча говнокода, ибо я уверен если бы кто-то начал нормально разговаривать за подходы в программировании - интервьювер бы просто слился. В этой теории не понимает вообще никто кроме 2.5 анонимов которые этим именно занимаются, всякие СОЛИД - это баззворды чтобы отсеивать умственно отсталых, а геймдев - это вообще сборище говноедов, которые пишут говнокод.
>>42778 (Del)
С того, что у вас там никого и ничего нет, кроме мешка денег и громких слов.
>>42779 (Del)
Всё так: никого и ничего нет, зато есть мешок денег. Хороший "стартап".
>>42785
Поэтому и троллейбус из буханки хлеба: можно, но зачем?
Обидно это признавать. Вдвойне обиднее видеть, как хейтят яндередева за говнокод.
>С чего ты взял что она уже на нем не сделана, успокойся.
С того, что у вас там никого и ничего нет, кроме мешка денег и громких слов.
>>42779 (Del)
>Представь на момент что вопрос с финансированием решен.
Всё так: никого и ничего нет, зато есть мешок денег. Хороший "стартап".
>>42785
>контейнер для функций? Ну такое.
Поэтому и троллейбус из буханки хлеба: можно, но зачем?
>сборище говноедов, которые пишут говнокод
Обидно это признавать. Вдвойне обиднее видеть, как хейтят яндередева за говнокод.
4 Мб, mp4,1280x720, 0:27
>такси с играми на годоте
>>42776
Там не только про магнитолу, но и про HUD на лобовом стекле.
И для такой задачи я действительно годот бы рекомендовал. Требований к графону в таких случаях мало, там по большому счету одноцветные плоскости. но поскольку они в 3д, движок очень сильно упростит рассчеты всех этих проекций, масштабов, положения в пространстве, плюс анимации. Собственно я сам примерно такие тулзы разрабатываю на годоте, рикамендую. Да и с магнитолой норм идея, там тебе сразу и удобный layout гуя, и скинчики.
>>42774
А это вообще странная претензия. Прикинь, сначала нужно планировать производство и считать себестоимость и оценивать рынок сбыта
Там не только про магнитолу, но и про HUD на лобовом стекле.
И для такой задачи я действительно годот бы рекомендовал. Требований к графону в таких случаях мало, там по большому счету одноцветные плоскости. но поскольку они в 3д, движок очень сильно упростит рассчеты всех этих проекций, масштабов, положения в пространстве, плюс анимации. Собственно я сам примерно такие тулзы разрабатываю на годоте, рикамендую. Да и с магнитолой норм идея, там тебе сразу и удобный layout гуя, и скинчики.
>>42774
> зато уже посчитали стоимость несуществующей машины и сколько они их выпустят
А это вообще странная претензия. Прикинь, сначала нужно планировать производство и считать себестоимость и оценивать рынок сбыта
>>42792
только если ты конкурент лол
годот даже для продакшена игр сырой
есть профессиональные решения
https://www.youtube.com/watch?v=WhyUrRIKBi0
https://www.youtube.com/watch?v=hwLn_850y-Y
>я действительно годот бы рекомендовал
только если ты конкурент лол
годот даже для продакшена игр сырой
есть профессиональные решения
https://www.youtube.com/watch?v=WhyUrRIKBi0
https://www.youtube.com/watch?v=hwLn_850y-Y
>>42749
Умение неиспользовать что-то сверх меры, просто потому что ты знаешь это, вообще полезно.
А тут речь идет, очевидно, о любителях ООП обмазывать все фабриками и прочими сервис локаторами.
Умение неиспользовать что-то сверх меры, просто потому что ты знаешь это, вообще полезно.
А тут речь идет, очевидно, о любителях ООП обмазывать все фабриками и прочими сервис локаторами.
>>42798
Поменьше фантазий движкосрачеров тащи.
Вообще пох. Не говоря о том что их тебе сейчас продаст.
>годот даже для продакшена игр сырой
Поменьше фантазий движкосрачеров тащи.
>есть профессиональные решения
Вообще пох. Не говоря о том что их тебе сейчас продаст.
>>42792
По твоим картинкам:
1. Затрудняет обзор обочины, с которой пешеходы бегут под машину. Ещё и другие машины зачем-то закрашивает, как будто это цензура. Вместо нормального обзора - какие-то пятна.
2. Затрудняет обзор колдобин на дороги, которые в данный момент находятся прямо под впереди идущей машиной или впереди неё. Зачем нужен индикатор пробок на дороге, когда ты уже стоишь в этой самой пробке на этой самой дороге?
3. 1+2, только ещё жирнее и цветастее, как гирлянда на ёлке.
4. А эта хрень умудрилась закрыть собой встречную полосу.
Короч, это всё какие-то яждизайнеры рисуют.
Пока в геймдеве стремятся ИЗБАВИТЬСЯ от HUD, яждизайнеры добавляют этот HUD в ИРЛ...
>>42796 (Del)
Ты сразу название аниме пиши, чтобы не приходилось каждую картинку в Яндексе искать.
>>42798
Как и Unity с UE, которые любая солидная фирма переделывает под свои нужды.
Если ничего не путаю, они запретили пользоваться в РФ, так что не вариант.
>HUD на лобовом стекле
По твоим картинкам:
1. Затрудняет обзор обочины, с которой пешеходы бегут под машину. Ещё и другие машины зачем-то закрашивает, как будто это цензура. Вместо нормального обзора - какие-то пятна.
2. Затрудняет обзор колдобин на дороги, которые в данный момент находятся прямо под впереди идущей машиной или впереди неё. Зачем нужен индикатор пробок на дороге, когда ты уже стоишь в этой самой пробке на этой самой дороге?
3. 1+2, только ещё жирнее и цветастее, как гирлянда на ёлке.
4. А эта хрень умудрилась закрыть собой встречную полосу.
Короч, это всё какие-то яждизайнеры рисуют.
Пока в геймдеве стремятся ИЗБАВИТЬСЯ от HUD, яждизайнеры добавляют этот HUD в ИРЛ...
>>42796 (Del)
Ты сразу название аниме пиши, чтобы не приходилось каждую картинку в Яндексе искать.
>>42798
>годот даже для продакшена игр сырой
Как и Unity с UE, которые любая солидная фирма переделывает под свои нужды.
>Qt
Если ничего не путаю, они запретили пользоваться в РФ, так что не вариант.
>>42800
тащемта это официальное заявление разработчиков годота
https://godotengine.org/article/release-management-4-0-and-beyond
>Поменьше фантазий движкосрачеров тащи.
тащемта это официальное заявление разработчиков годота
https://godotengine.org/article/release-management-4-0-and-beyond
652 Кб, webm,320x240, 0:32
СОБИРАЮ КОМАНДУ ДЛЯ СОЗДАНИЯ ЭЛЕКТРОКАРА
@
ПОЛОВИНА ШТАТА - АЙТИШНИКИ
@
НА ГОДОТЕ
@
ПОЛОВИНА ШТАТА - АЙТИШНИКИ
@
НА ГОДОТЕ
>>42823
Ну чё ты ржош, это же не просто какой-то там электрокар, не просто ДВС на электродвигатель заменили - это электрокар для молодого, современного поколения, которое уткнулось в свои мониторчики и постоянно там что-то, это, как его... твитит, вот, что-то там, мемы смотрит какие-то. Вот! Нужно сделать электрокар, чтобы можно было твитить мемы прямо из него - и тогда никакой смартфон не понадобится! Пусть сидят в машине уткнувшись носом в монитор - всяко комфортнее, чем делать это пешком. А если у нас есть монитор, то и айтишники нужны... Как монитор-то без айтишников включишь? Никак. А выключенный монитор молодёжь не привлекает...
Ну чё ты ржош, это же не просто какой-то там электрокар, не просто ДВС на электродвигатель заменили - это электрокар для молодого, современного поколения, которое уткнулось в свои мониторчики и постоянно там что-то, это, как его... твитит, вот, что-то там, мемы смотрит какие-то. Вот! Нужно сделать электрокар, чтобы можно было твитить мемы прямо из него - и тогда никакой смартфон не понадобится! Пусть сидят в машине уткнувшись носом в монитор - всяко комфортнее, чем делать это пешком. А если у нас есть монитор, то и айтишники нужны... Как монитор-то без айтишников включишь? Никак. А выключенный монитор молодёжь не привлекает...
394 Кб, 449x554Как же это иронично, что именно в теме годота обсуждают попильный российский автопром.
>>42850 (Del)
На работе сколько времени можно аниме смотреть?
На работе сколько времени можно аниме смотреть?
129 Кб, 1280x720>>42862
Сколько пожелаешь! Работа не к спеху, аниме важнее.
Сколько пожелаешь! Работа не к спеху, аниме важнее.
>>42848
А для москвича не требуется ведущий разработчик на годоте? Или там уже на cocos creator все написано?
А для москвича не требуется ведущий разработчик на годоте? Или там уже на cocos creator все написано?
>>42877
Они никуда и не пропадали еще с 2 версии
https://docs.godotengine.org/en/stable/classes/class_quat.html
Они никуда и не пропадали еще с 2 версии
https://docs.godotengine.org/en/stable/classes/class_quat.html
Когда в годоте появятся кватернионы для вращения объектов вместо матриц?
На реддите выяснили что GDScript слишком медленный для создания реальных игр
Пользователи в комментариях посоветовали писать меньше кода чтобы работало быстрее
https://www.reddit.com/r/godot/comments/z9wete/isnt_gdscript_far_too_slow_to_really_compute/
Пользователи в комментариях посоветовали писать меньше кода чтобы работало быстрее
https://www.reddit.com/r/godot/comments/z9wete/isnt_gdscript_far_too_slow_to_really_compute/
>>42889
Мне нравится как чел тонко годоть поджёг.
Мне нравится как чел тонко годоть поджёг.
>>42889
В этом есть доля истины. Использовать интерпретируемый медленный скриптовый язык в движке, который позицинурется как современная лучшая опен сурс альтернатива коммерческим движкам - это дурной тон.
В этом есть доля истины. Использовать интерпретируемый медленный скриптовый язык в движке, который позицинурется как современная лучшая опен сурс альтернатива коммерческим движкам - это дурной тон.
Если gdscript не самое быстрое решение из возможных, то это плохое решение. Мне все равно насколько этот язык хорош или удобен. Если он медленный, то это ошибка архитектуры движка.
gdscript это баг годота, снижающий производительность игр, который должен быть исправлен.
gdscript это баг годота, снижающий производительность игр, который должен быть исправлен.
>>42902
Скриптам не нужна скорость. Если что-то должно работать быстро, это пишется на c++ модулем. А скрипты нужны для примитивных вещей, типа обработки нажатых кнопок (по исследованиям время реакции человека в районе 150-200мс). Те, кто пищут вообще все на гдскрипте - сами виноваты, это их баг.
Это как если бы тебе дали бензопилу и к ней в комплекте кусачки. И кусачками удобно подрезать всякие веточки, а ты бы кусачками вручную пытался перерубить все деревья по пути и жаловался что это неправильная бензопила.
А если ты считаешь, что это баг - компилятор в руки и вперед делать pull request https://github.com/godotengine/godot-proposals/issues/3069
Скриптам не нужна скорость. Если что-то должно работать быстро, это пишется на c++ модулем. А скрипты нужны для примитивных вещей, типа обработки нажатых кнопок (по исследованиям время реакции человека в районе 150-200мс). Те, кто пищут вообще все на гдскрипте - сами виноваты, это их баг.
Это как если бы тебе дали бензопилу и к ней в комплекте кусачки. И кусачками удобно подрезать всякие веточки, а ты бы кусачками вручную пытался перерубить все деревья по пути и жаловался что это неправильная бензопила.
А если ты считаешь, что это баг - компилятор в руки и вперед делать pull request https://github.com/godotengine/godot-proposals/issues/3069
>>42919
Тут скорее наоборот, GDScript - бензопила, а C++ - кусачки.
Бензопилой (высокоуровневый ЯП) можно много чего наворотить, но маленькие веточки (все эти байты и биты) резать неудобно.
А кусачками (низкоуровневый ЯП) можно вырезать маленькие веточки, но делать что-то большое (крупный проект) неудобно.
Все ведь знают, что C/C++ недалеко от ассемблера ушёл, поэтому он так неудобен и коряв, но быстр.
>>42902
Скриптовый ЯП - самое быстрое решение из возможных для разработки.
Медленность интерпретатора скриптового ЯП обычно не имеет значения для разработчика.
>дали бензопилу и к ней в комплекте кусачки
Тут скорее наоборот, GDScript - бензопила, а C++ - кусачки.
Бензопилой (высокоуровневый ЯП) можно много чего наворотить, но маленькие веточки (все эти байты и биты) резать неудобно.
А кусачками (низкоуровневый ЯП) можно вырезать маленькие веточки, но делать что-то большое (крупный проект) неудобно.
Все ведь знают, что C/C++ недалеко от ассемблера ушёл, поэтому он так неудобен и коряв, но быстр.
>>42902
>Если gdscript не самое быстрое решение из возможных
Скриптовый ЯП - самое быстрое решение из возможных для разработки.
Медленность интерпретатора скриптового ЯП обычно не имеет значения для разработчика.
2 Кб, 242x104>>42919
никто так делает. C++ нет в документации.
играм не нужны скрипты.
даже epic games это поняли и убрали UnrealScript из unreal engine.
если решение по умолчанию в движке не самый быстрое, то это плохое решение и его не должно быть, потому эта грабли, на которые будут наступать все. если язык программирования игры не быстрый, то все остальное не имеет смысла.
в играх важна каждая миллисекунда. это не научные вычисления, где скриптовые языки популярны и где нет разницы между 100 милисекунд и 5 секунд
никто так делает. C++ нет в документации.
>Скриптам не нужна скорость
играм не нужны скрипты.
даже epic games это поняли и убрали UnrealScript из unreal engine.
если решение по умолчанию в движке не самый быстрое, то это плохое решение и его не должно быть, потому эта грабли, на которые будут наступать все. если язык программирования игры не быстрый, то все остальное не имеет смысла.
в играх важна каждая миллисекунда. это не научные вычисления, где скриптовые языки популярны и где нет разницы между 100 милисекунд и 5 секунд
>>42939
я хочу программировать на C++ на годоте, а не тратить время на gdscript, чтобы в конце разработки с ужасом осознать что игра не тянет из-за пропуков гдскрипта
где можно почитать туториалы на C++?
я хочу программировать на C++ на годоте, а не тратить время на gdscript, чтобы в конце разработки с ужасом осознать что игра не тянет из-за пропуков гдскрипта
где можно почитать туториалы на C++?
>>42942
пиши на шарпе
пиши на шарпе
435 Кб, 1920x1080>>42939
Многие топовые разрабы так делают (и выкладывают свои с++ модули в опенсорс).
Для c++ не нужна какая-то особая документация. Апи будет почти 1 в 1.
Это просто демагогия, поскольку всегда есть решение более быстрое, например ассемблер. Любой вызов функции в принципе неоптимален, потому что там push bp, call, pop bp и так далее.
Не важна. А там где важна - все равно пишут свое на с++.
>>42942
Берешь и переписываешь любой туториал на с++.
>никто так делает
Многие топовые разрабы так делают (и выкладывают свои с++ модули в опенсорс).
>C++ нет в документации.
Для c++ не нужна какая-то особая документация. Апи будет почти 1 в 1.
>если решение по умолчанию в движке не самый быстрое
Это просто демагогия, поскольку всегда есть решение более быстрое, например ассемблер. Любой вызов функции в принципе неоптимален, потому что там push bp, call, pop bp и так далее.
>в играх важна каждая миллисекунда
Не важна. А там где важна - все равно пишут свое на с++.
>>42942
Берешь и переписываешь любой туториал на с++.
>>42947
это объективная реальность. на гдскрипте нельзя сделать определенные игры. три в ряд можно написать, а сложную стратегию с тысячами юнитов нельзя. это уже выкидывает годот из универсальных движков в категорию нишевых, типа defold'а.
>Это просто демагогия
это объективная реальность. на гдскрипте нельзя сделать определенные игры. три в ряд можно написать, а сложную стратегию с тысячами юнитов нельзя. это уже выкидывает годот из универсальных движков в категорию нишевых, типа defold'а.
>>42950
Можно, godot это язык на с++, вообще никаких проблем.
>это объективная реальность. на гдскрипте нельзя сделать определенные игры.
>а сложную стратегию с тысячами юнитов нельзя.
Можно, godot это язык на с++, вообще никаких проблем.
>>42919
Ну дык гдскрипт не сильнее проще плюсов так то. А если сравнивать с C# то он проигрывает просто во всём.
>А скрипты нужны для примитивных вещей
Ну дык гдскрипт не сильнее проще плюсов так то. А если сравнивать с C# то он проигрывает просто во всём.
>>42942
Шаг 1: https://github.com/godotengine/godot
Шаг 2: программируешь на C++ на Godot.
Ты сначала делаешь игру, а потом оптимизируешь. Не наоборот, понял?
В учебнике по C++. Программирование на C++ не подходит для ньюфагов.
>>42939
Умник, если ты умеешь в C++, доки тебе не нужны. Иди программировай.
В каких именно? Огласи список жанров, где "важна каждая миллисекунда".
Большинство игр бездействуют между кадрами, если включён VSync.
Т.е. буквально: 1 мс на кадр + 15 мс бездействия до следующего.
>я хочу программировать на C++ на годоте
Шаг 1: https://github.com/godotengine/godot
Шаг 2: программируешь на C++ на Godot.
>чтобы в конце разработки с ужасом осознать что игра не тянет
Ты сначала делаешь игру, а потом оптимизируешь. Не наоборот, понял?
>где можно почитать туториалы на C++?
В учебнике по C++. Программирование на C++ не подходит для ньюфагов.
>>42939
>C++ нет в документации.
Умник, если ты умеешь в C++, доки тебе не нужны. Иди программировай.
>в играх важна каждая миллисекунда
В каких именно? Огласи список жанров, где "важна каждая миллисекунда".
Большинство игр бездействуют между кадрами, если включён VSync.
Т.е. буквально: 1 мс на кадр + 15 мс бездействия до следующего.
>>42967
Очень сильно проще. В плюсах есть UB, порча стека, шаблоны, много чего короче.
Не во всем - нужен .net, запуск приложения на андроиде реально дольше.
Очень сильно проще. В плюсах есть UB, порча стека, шаблоны, много чего короче.
>сравнивать с C# то он проигрывает просто во всём.
Не во всем - нужен .net, запуск приложения на андроиде реально дольше.
>>42969
ну, удачи в конце разработки перепиливать всю архитектуру с нуля
>Ты сначала делаешь игру, а потом оптимизируешь
ну, удачи в конце разработки перепиливать всю архитектуру с нуля
>>42995
99% тормозов в играх по вине таких умников, что думают что "оптимизируют" в конце
99% тормозов в играх по вине таких умников, что думают что "оптимизируют" в конце
>>42992 (Del)
Вангую, он оба языка одинаково НИАСИЛИЛ, поэтому так говорит. А ниасилил потому, что скачет с темы на тему, пытаясь без каких-либо знаний запилить "убийцу" какого-нибудь АААА+ тайтла, который сто тысяч профессионалов на кастомном приватном ПО пилят десять лет, сжигая тонны бабла и нервов (на кранчах). Но он, конечно, убеждён, что бесплатный движок должен сделать всё за него, только скриптовый язык слишком медленный (по слухам с какого-нибудь древнего форума) для его АААА+, а пошаговых туториалов "как сделать АААА+ игру на C++ в одиночку на Godot, если ты полный ноль во всех сферах знаний" не нашёл - вот и бесится тут.
>>42995
Это называется "рефакторинг". Сначала делают программу так, чтобы она работала и работала правильно (как в ТЗ), а уже потом перекраивают так, чтобы она работала быстро и её можно было расширять (в играх - обновления, DLC, моды, следующая часть серии и т.п.).
Ты в любом случае должен сделать прототип игры, прежде чем делать игру. Прототип не обязательно где-то публиковать - он служит для того, чтобы ты мог проверить и оценить свои задумки. Поэтому прототип желательно сделать как можно быстрее, чтобы не тратить время на неудачные задумки. Производительность в прототипе тебя вообще волновать не должна, потому что ты его в любом случае будешь с нуля переделывать. Поэтому прототипы делают на быстрых для разработки языках - обычно, скриптовых, поскольку скриптовые языки избавлены от многих затягивающих цикл разработки вещей. Позже, если прототип докажет жизнеспособность твоей игры, ты берёшь более производительные инструменты и прорабатываешь более надёжную и гибкую архитектуру.
Именно поэтому Godot набирает популярность - он удобен для быстрого прототипирования игр, чего крайне не хватает другим игровым движкам. Даже те студии, которые делают игры на Unity, последние годы интересуются Godot и используют его для прототипирования. Если бы в Godot не было GDScript, он не имел бы никаких преимуществ, т.к. на нём было бы так же сложно сделать прототип, как и на других игровых движках.
>>42996
Из-за людей, которые выбрасывают ассет-флип на рынок и больше его не обновляют. Игра должна поддерживаться много лет после релиза, только тогда она принесёт максимальную прибыль. Minecraft, Terraria, GTA Online, многочисленные ММО и т.д., всё получает обновления, чтобы приносить прибыль. Тот же Minecraft радикально переписали в какой-то из 1.1X версий, а ещё сделали массу оптимизаций. Если бы Minecraft вышел в версии 1.0 и больше никак не обновлялся, он бы не принёс той сверхприбыли, которую принёс. А ты, видимо, планируешь с самого начала оптимизировать игру на C++, чтобы "к концу разработки" ничего не переделывать - выкинуть 1.0 на рынок и забыть как страшный сон.
>кто-то, кто знает оба языка
Вангую, он оба языка одинаково НИАСИЛИЛ, поэтому так говорит. А ниасилил потому, что скачет с темы на тему, пытаясь без каких-либо знаний запилить "убийцу" какого-нибудь АААА+ тайтла, который сто тысяч профессионалов на кастомном приватном ПО пилят десять лет, сжигая тонны бабла и нервов (на кранчах). Но он, конечно, убеждён, что бесплатный движок должен сделать всё за него, только скриптовый язык слишком медленный (по слухам с какого-нибудь древнего форума) для его АААА+, а пошаговых туториалов "как сделать АААА+ игру на C++ в одиночку на Godot, если ты полный ноль во всех сферах знаний" не нашёл - вот и бесится тут.
>>42995
>перепиливать всю архитектуру с нуля
Это называется "рефакторинг". Сначала делают программу так, чтобы она работала и работала правильно (как в ТЗ), а уже потом перекраивают так, чтобы она работала быстро и её можно было расширять (в играх - обновления, DLC, моды, следующая часть серии и т.п.).
>в конце разработки
Ты в любом случае должен сделать прототип игры, прежде чем делать игру. Прототип не обязательно где-то публиковать - он служит для того, чтобы ты мог проверить и оценить свои задумки. Поэтому прототип желательно сделать как можно быстрее, чтобы не тратить время на неудачные задумки. Производительность в прототипе тебя вообще волновать не должна, потому что ты его в любом случае будешь с нуля переделывать. Поэтому прототипы делают на быстрых для разработки языках - обычно, скриптовых, поскольку скриптовые языки избавлены от многих затягивающих цикл разработки вещей. Позже, если прототип докажет жизнеспособность твоей игры, ты берёшь более производительные инструменты и прорабатываешь более надёжную и гибкую архитектуру.
Именно поэтому Godot набирает популярность - он удобен для быстрого прототипирования игр, чего крайне не хватает другим игровым движкам. Даже те студии, которые делают игры на Unity, последние годы интересуются Godot и используют его для прототипирования. Если бы в Godot не было GDScript, он не имел бы никаких преимуществ, т.к. на нём было бы так же сложно сделать прототип, как и на других игровых движках.
>>42996
>99% тормозов в играх
Из-за людей, которые выбрасывают ассет-флип на рынок и больше его не обновляют. Игра должна поддерживаться много лет после релиза, только тогда она принесёт максимальную прибыль. Minecraft, Terraria, GTA Online, многочисленные ММО и т.д., всё получает обновления, чтобы приносить прибыль. Тот же Minecraft радикально переписали в какой-то из 1.1X версий, а ещё сделали массу оптимизаций. Если бы Minecraft вышел в версии 1.0 и больше никак не обновлялся, он бы не принёс той сверхприбыли, которую принёс. А ты, видимо, планируешь с самого начала оптимизировать игру на C++, чтобы "к концу разработки" ничего не переделывать - выкинуть 1.0 на рынок и забыть как страшный сон.
>>42992 (Del)
Вангую, он оба языка одинаково НИАСИЛИЛ, поэтому так говорит. А ниасилил потому, что скачет с темы на тему, пытаясь без каких-либо знаний запилить "убийцу" какого-нибудь АААА+ тайтла, который сто тысяч профессионалов на кастомном приватном ПО пилят десять лет, сжигая тонны бабла и нервов (на кранчах). Но он, конечно, убеждён, что бесплатный движок должен сделать всё за него, только скриптовый язык слишком медленный (по слухам с какого-нибудь древнего форума) для его АААА+, а пошаговых туториалов "как сделать АААА+ игру на C++ в одиночку на Godot, если ты полный ноль во всех сферах знаний" не нашёл - вот и бесится тут.
>>42995
Это называется "рефакторинг". Сначала делают программу так, чтобы она работала и работала правильно (как в ТЗ), а уже потом перекраивают так, чтобы она работала быстро и её можно было расширять (в играх - обновления, DLC, моды, следующая часть серии и т.п.).
Ты в любом случае должен сделать прототип игры, прежде чем делать игру. Прототип не обязательно где-то публиковать - он служит для того, чтобы ты мог проверить и оценить свои задумки. Поэтому прототип желательно сделать как можно быстрее, чтобы не тратить время на неудачные задумки. Производительность в прототипе тебя вообще волновать не должна, потому что ты его в любом случае будешь с нуля переделывать. Поэтому прототипы делают на быстрых для разработки языках - обычно, скриптовых, поскольку скриптовые языки избавлены от многих затягивающих цикл разработки вещей. Позже, если прототип докажет жизнеспособность твоей игры, ты берёшь более производительные инструменты и прорабатываешь более надёжную и гибкую архитектуру.
Именно поэтому Godot набирает популярность - он удобен для быстрого прототипирования игр, чего крайне не хватает другим игровым движкам. Даже те студии, которые делают игры на Unity, последние годы интересуются Godot и используют его для прототипирования. Если бы в Godot не было GDScript, он не имел бы никаких преимуществ, т.к. на нём было бы так же сложно сделать прототип, как и на других игровых движках.
>>42996
Из-за людей, которые выбрасывают ассет-флип на рынок и больше его не обновляют. Игра должна поддерживаться много лет после релиза, только тогда она принесёт максимальную прибыль. Minecraft, Terraria, GTA Online, многочисленные ММО и т.д., всё получает обновления, чтобы приносить прибыль. Тот же Minecraft радикально переписали в какой-то из 1.1X версий, а ещё сделали массу оптимизаций. Если бы Minecraft вышел в версии 1.0 и больше никак не обновлялся, он бы не принёс той сверхприбыли, которую принёс. А ты, видимо, планируешь с самого начала оптимизировать игру на C++, чтобы "к концу разработки" ничего не переделывать - выкинуть 1.0 на рынок и забыть как страшный сон.
>кто-то, кто знает оба языка
Вангую, он оба языка одинаково НИАСИЛИЛ, поэтому так говорит. А ниасилил потому, что скачет с темы на тему, пытаясь без каких-либо знаний запилить "убийцу" какого-нибудь АААА+ тайтла, который сто тысяч профессионалов на кастомном приватном ПО пилят десять лет, сжигая тонны бабла и нервов (на кранчах). Но он, конечно, убеждён, что бесплатный движок должен сделать всё за него, только скриптовый язык слишком медленный (по слухам с какого-нибудь древнего форума) для его АААА+, а пошаговых туториалов "как сделать АААА+ игру на C++ в одиночку на Godot, если ты полный ноль во всех сферах знаний" не нашёл - вот и бесится тут.
>>42995
>перепиливать всю архитектуру с нуля
Это называется "рефакторинг". Сначала делают программу так, чтобы она работала и работала правильно (как в ТЗ), а уже потом перекраивают так, чтобы она работала быстро и её можно было расширять (в играх - обновления, DLC, моды, следующая часть серии и т.п.).
>в конце разработки
Ты в любом случае должен сделать прототип игры, прежде чем делать игру. Прототип не обязательно где-то публиковать - он служит для того, чтобы ты мог проверить и оценить свои задумки. Поэтому прототип желательно сделать как можно быстрее, чтобы не тратить время на неудачные задумки. Производительность в прототипе тебя вообще волновать не должна, потому что ты его в любом случае будешь с нуля переделывать. Поэтому прототипы делают на быстрых для разработки языках - обычно, скриптовых, поскольку скриптовые языки избавлены от многих затягивающих цикл разработки вещей. Позже, если прототип докажет жизнеспособность твоей игры, ты берёшь более производительные инструменты и прорабатываешь более надёжную и гибкую архитектуру.
Именно поэтому Godot набирает популярность - он удобен для быстрого прототипирования игр, чего крайне не хватает другим игровым движкам. Даже те студии, которые делают игры на Unity, последние годы интересуются Godot и используют его для прототипирования. Если бы в Godot не было GDScript, он не имел бы никаких преимуществ, т.к. на нём было бы так же сложно сделать прототип, как и на других игровых движках.
>>42996
>99% тормозов в играх
Из-за людей, которые выбрасывают ассет-флип на рынок и больше его не обновляют. Игра должна поддерживаться много лет после релиза, только тогда она принесёт максимальную прибыль. Minecraft, Terraria, GTA Online, многочисленные ММО и т.д., всё получает обновления, чтобы приносить прибыль. Тот же Minecraft радикально переписали в какой-то из 1.1X версий, а ещё сделали массу оптимизаций. Если бы Minecraft вышел в версии 1.0 и больше никак не обновлялся, он бы не принёс той сверхприбыли, которую принёс. А ты, видимо, планируешь с самого начала оптимизировать игру на C++, чтобы "к концу разработки" ничего не переделывать - выкинуть 1.0 на рынок и забыть как страшный сон.
93 Кб, 616x700>>43019
нельзя оптимизировать почти готовую игру, потому что если что-то тронешь в 10 этажах говнокода, то поломается вообще все
"сначала сделай, оптимизируй потом" это вредный миф. надо оптимизировать с самого начала
нельзя оптимизировать почти готовую игру, потому что если что-то тронешь в 10 этажах говнокода, то поломается вообще все
"сначала сделай, оптимизируй потом" это вредный миф. надо оптимизировать с самого начала
beta 7
>>43028
Да понятно что годоти ничего массивного в своей жизни не писали. Они подрузамевают что есть какие-то издержки того, чтобы писать правильно. Их нет. Тормозной гдскрипт вообще не ускоряет разработку, хорошее решение это писать очевидно затратные вещи правильно изначально, а не говнокодить на годоте создавая себе работу в будущем.
Да понятно что годоти ничего массивного в своей жизни не писали. Они подрузамевают что есть какие-то издержки того, чтобы писать правильно. Их нет. Тормозной гдскрипт вообще не ускоряет разработку, хорошее решение это писать очевидно затратные вещи правильно изначально, а не говнокодить на годоте создавая себе работу в будущем.
>>43028
Я тебе вообще про другое пишу. Они сначала сделали, потом получили огромные продажи, а оптимизацию вообще выкинули.
Я тебе вообще про другое пишу. Они сначала сделали, потом получили огромные продажи, а оптимизацию вообще выкинули.
>>43030
Ускоряет конечно. Нет фазы компиляции, быстрее итерации разработки.
>гдскрипт вообще не ускоряет разработку
Ускоряет конечно. Нет фазы компиляции, быстрее итерации разработки.
>>43030
Писали. И прекрасно разбираются в прототипировании и паттернах. И то что вот этот >>43028 сказал чушь, не значит, что все в треде такие.
Гдскрипт же позволяет писать любой степени поддерживаемости код. Всё как и везде зависит от ручек кодера. Но у налетевших ИТТ движкосрачеров опять виноват движок. Чувствую скоро репортить массово придётся. Что-то вы тут все распустились.
> ничего массивного в своей жизни не писали
Писали. И прекрасно разбираются в прототипировании и паттернах. И то что вот этот >>43028 сказал чушь, не значит, что все в треде такие.
Гдскрипт же позволяет писать любой степени поддерживаемости код. Всё как и везде зависит от ручек кодера. Но у налетевших ИТТ движкосрачеров опять виноват движок. Чувствую скоро репортить массово придётся. Что-то вы тут все распустились.
>>43028
Ага, чтобы игру вообще никогда не закончить, ведь всегда можно выжать +1 микросекунду.
>>43030
Это ты ничего больше Hello World в жизни не писал, раз так говоришь. Чтобы написать "правильно", нужно это самое "правильно" сначала ПРИДУМАТЬ, потом только написать и протестировать, чтобы убедиться, что твоя задумка действительно даёт какой-то прирост производительности. Или ты думаешь, что это твоё "правильно" в каких-то книжках написано, и достаточно только скопипастить?
GDScript императивный, и C++ императивный. Ты считаешь "работой" трансляцию своего же кода с одного императивного языка на другой императивный язык? Может, ты просто печатаешь по одной букве в секунду, глядя на клавиатуру? Тогда можно было бы понять, почему тебе лень печатать код.
>>43036
Хорошую графику сложнее сделать, чем юзабельный код.
>надо оптимизировать с самого начала
Ага, чтобы игру вообще никогда не закончить, ведь всегда можно выжать +1 микросекунду.
>>43030
>ничего массивного в своей жизни не писали
>Они подрузамевают что есть какие-то издержки того, чтобы писать правильно. Их нет.
Это ты ничего больше Hello World в жизни не писал, раз так говоришь. Чтобы написать "правильно", нужно это самое "правильно" сначала ПРИДУМАТЬ, потом только написать и протестировать, чтобы убедиться, что твоя задумка действительно даёт какой-то прирост производительности. Или ты думаешь, что это твоё "правильно" в каких-то книжках написано, и достаточно только скопипастить?
>создавая себе работу в будущем
GDScript императивный, и C++ императивный. Ты считаешь "работой" трансляцию своего же кода с одного императивного языка на другой императивный язык? Может, ты просто печатаешь по одной букве в секунду, глядя на клавиатуру? Тогда можно было бы понять, почему тебе лень печатать код.
>>43036
Хорошую графику сложнее сделать, чем юзабельный код.
>>43053
Эта книга называется "теория алгоритмов".
>Или ты думаешь, что это твоё "правильно" в каких-то книжках написано, и достаточно только скопипастить?
Эта книга называется "теория алгоритмов".
27 Кб, 413x360>>43058
Любитель печатать код три часа подряд, нажимать кнопку "компиляция", идти заваривать чай, возвращаться к консоли с сотнями ошибок, и затем весь остаток дня пытаться разобраться, где и когда ты ошибся в своей жизни, ты?
>Любитель 30 раз менять одну строчку, ты?
Любитель печатать код три часа подряд, нажимать кнопку "компиляция", идти заваривать чай, возвращаться к консоли с сотнями ошибок, и затем весь остаток дня пытаться разобраться, где и когда ты ошибся в своей жизни, ты?
Когда из blender экспортирую модель gltf с инверсной кинематикой, оно ее будет переносить или нужно будет самому в арматуре потом в самом godot настраивать?
если будет, то мне что нужно сделать: привязать IK управляющую кость к ноде и двигать ноду?
если будет, то мне что нужно сделать: привязать IK управляющую кость к ноде и двигать ноду?
>>43130
Я не знаю. Извини.
Я не знаю. Извини.
>>43130
Инверсная кинематика - это алгоритм, а не данные. У блендера инверсная кинематика работает, когда ты кости двигаешь, а когда ты экспортируешь меш, то анимации все будут запечёнными. То есть в Godot ты сможешь использовать анимации, которые сделал в Blender с помощью инверсной кинематики, но кости скелета будут обычными. Чтобы сделать инверсную кинематику реального времени в Godot, нужно вешать скрипты на скелет или кости, пример смотри в демках Godot. Встроенной инверсной кинематики вообще нет, в демке алгоритм записан на GDScript. Но в реальном времени инверсная кинематика в играх редко используется.
Ну, это как я понял. Могу ошибаться.
>экспортирую модель с инверсной кинематикой
Инверсная кинематика - это алгоритм, а не данные. У блендера инверсная кинематика работает, когда ты кости двигаешь, а когда ты экспортируешь меш, то анимации все будут запечёнными. То есть в Godot ты сможешь использовать анимации, которые сделал в Blender с помощью инверсной кинематики, но кости скелета будут обычными. Чтобы сделать инверсную кинематику реального времени в Godot, нужно вешать скрипты на скелет или кости, пример смотри в демках Godot. Встроенной инверсной кинематики вообще нет, в демке алгоритм записан на GDScript. Но в реальном времени инверсная кинематика в играх редко используется.
Ну, это как я понял. Могу ошибаться.
>>43192
А, значит, встроенный решатель всё-таки есть. А то я когда тестил демку, увидел этот скрипт:
https://github.com/godotengine/godot-demo-projects/blob/3.4-b0d4a7c/3d/ik/addons/sade/ik_fabrik.gd
Расстроился и удалил. Нужно было внимательнее читать описание демки (там сказано про эту ноду).
А, значит, встроенный решатель всё-таки есть. А то я когда тестил демку, увидел этот скрипт:
https://github.com/godotengine/godot-demo-projects/blob/3.4-b0d4a7c/3d/ik/addons/sade/ik_fabrik.gd
Расстроился и удалил. Нужно было внимательнее читать описание демки (там сказано про эту ноду).
>>43196
Почему? Все равно годот это c++, надо на c++ игру писать как советуют в треде
>Расстроился и удалил
Почему? Все равно годот это c++, надо на c++ игру писать как советуют в треде
>>43228
Двачую.
В прошлых тредах я неоднократно писал, что у современных девелоперов есть сильное непонимание того, что именно в движке является движком. Для большинства закрепилось ошибочное мнение, будто движок это редактор движка. Но извините, редактор это редактор. Редактор это не движок. Редактор это утилита (tool, toolset). А движок - это набор классов и бойлерплейта, который уже написан до тебя, для того чтобы ты просто взял и начал делать игру, хоть в редакторе, хоть в ИДЕ, хоть вообще в блокноте - твой выбор.
Соответственно, чтобы сделать игру на годоте, можно как диды в 80х, 90х, 2000х взять исходник на с++ и дописывать свои модули на с++, пользуясь имеющимися классами в имеющихся модулях. А потом скомпилировать. Плюсом такого пайплайна будет то, что у тебя на выходе будет скомпилированный бинарник без малейших следов исходников, в отличие от гдскрипта и шарпа, где в конечном продукте остаётся уплотнённый байткод (байткод, это когда вместо слова for стоит определённый символ, и фраза for i in range(10) будет в байткоде записана примерно как c1v1r1, где c1 - команда 1, v1 - переменная 1, r1 - диапазон 1), который легко восстановить до исходника. Кресты же можно восстановить только до ассемблера, из которого существующие декомпиляторы могут воссоздать отдалённо напоминающий исходник, в общем, сишный код твоей игры будут взламывать только профи, а гдскриптовый/шарповый сможет взломать любой васян.
Двачую.
В прошлых тредах я неоднократно писал, что у современных девелоперов есть сильное непонимание того, что именно в движке является движком. Для большинства закрепилось ошибочное мнение, будто движок это редактор движка. Но извините, редактор это редактор. Редактор это не движок. Редактор это утилита (tool, toolset). А движок - это набор классов и бойлерплейта, который уже написан до тебя, для того чтобы ты просто взял и начал делать игру, хоть в редакторе, хоть в ИДЕ, хоть вообще в блокноте - твой выбор.
Соответственно, чтобы сделать игру на годоте, можно как диды в 80х, 90х, 2000х взять исходник на с++ и дописывать свои модули на с++, пользуясь имеющимися классами в имеющихся модулях. А потом скомпилировать. Плюсом такого пайплайна будет то, что у тебя на выходе будет скомпилированный бинарник без малейших следов исходников, в отличие от гдскрипта и шарпа, где в конечном продукте остаётся уплотнённый байткод (байткод, это когда вместо слова for стоит определённый символ, и фраза for i in range(10) будет в байткоде записана примерно как c1v1r1, где c1 - команда 1, v1 - переменная 1, r1 - диапазон 1), который легко восстановить до исходника. Кресты же можно восстановить только до ассемблера, из которого существующие декомпиляторы могут воссоздать отдалённо напоминающий исходник, в общем, сишный код твоей игры будут взламывать только профи, а гдскриптовый/шарповый сможет взломать любой васян.
>>43253
Ах да, самое главное, имея доступ ко внутренней кухне движка, а не только к тому, что выставили наружу через модуль гдскрипта, ты сможешь организовать в приложении и свой майнлуп и свой (как нынче модно говорить) лайфцикл, то есть, сможешь как угодно запускать приложение, и как угодно инициализировать ресурсы, используя угодный тебе формат. То есть, с бинарником может не идти пак-файл, а может идти файл другого формата, а может вообще никакого файла не идти, а все ресурсы сможешь вшить в бинарник натуральным для си образом, а не как раржпег.
Владея с++, ты вообще можешь встроить вюьпорт годота во внешнюю форму. Типа как в редакторе модов беседкиных ТЕСачей, есть оконное приложение, а в нём есть фрейм с тридэ-вьюпортом, в котором игра в режиме бога конструируется.
Ах да, самое главное, имея доступ ко внутренней кухне движка, а не только к тому, что выставили наружу через модуль гдскрипта, ты сможешь организовать в приложении и свой майнлуп и свой (как нынче модно говорить) лайфцикл, то есть, сможешь как угодно запускать приложение, и как угодно инициализировать ресурсы, используя угодный тебе формат. То есть, с бинарником может не идти пак-файл, а может идти файл другого формата, а может вообще никакого файла не идти, а все ресурсы сможешь вшить в бинарник натуральным для си образом, а не как раржпег.
Владея с++, ты вообще можешь встроить вюьпорт годота во внешнюю форму. Типа как в редакторе модов беседкиных ТЕСачей, есть оконное приложение, а в нём есть фрейм с тридэ-вьюпортом, в котором игра в режиме бога конструируется.
Привет друзья. Делаю стратежку по типу Хойки/Виктории (но более упрощенная - чисто контурные карты).
Начал с рисования карт. Самое быстрое и легкое сделал - нарисовал бэкграунд и синий фон для обозначения моря.
Сейчас готовлюсь к тому чтобы начать рисовать карты стран. Т.к у меня будут линии фронта и страны будут так же поделены на провинции хотелось бы узнать как лучше делать с технической стороны.
Я планирую просто сделать 2 карты. Общий план (в отдалении) и карта с провинциями при приближении + карта будет поделена на маленькие клетки для процесса захвата земель при войне.
Хотелось бы узнать я правильно мыслю или есть варианты лучше и проще? Я уже собираю карты стран в нужный мне период, скоро примусь за попытку нарисовать их в фш.
Начал с рисования карт. Самое быстрое и легкое сделал - нарисовал бэкграунд и синий фон для обозначения моря.
Сейчас готовлюсь к тому чтобы начать рисовать карты стран. Т.к у меня будут линии фронта и страны будут так же поделены на провинции хотелось бы узнать как лучше делать с технической стороны.
Я планирую просто сделать 2 карты. Общий план (в отдалении) и карта с провинциями при приближении + карта будет поделена на маленькие клетки для процесса захвата земель при войне.
Хотелось бы узнать я правильно мыслю или есть варианты лучше и проще? Я уже собираю карты стран в нужный мне период, скоро примусь за попытку нарисовать их в фш.
>>43260
Правильных вариантов нет. Есть только удобные для тебя.
Подкину тебе совет, который поразил меня, когда я исследовал тайлмапы в годоте: гексагональная карта получается если сдвинуть ряды прямоугольной карты наполовину.
> я правильно мыслю или есть варианты лучше и проще?
Правильных вариантов нет. Есть только удобные для тебя.
> как лучше делать с технической стороны
Подкину тебе совет, который поразил меня, когда я исследовал тайлмапы в годоте: гексагональная карта получается если сдвинуть ряды прямоугольной карты наполовину.
>>43171
я просто думал, что могу управляющие кости в блендере накидать, на которые IK привязываю, а потом в годоте просто к ним ноду приделать к скелету и на нее все вектора кидать, чтобы цепочки костей не в самом годоте прописывать, а в блендере, а там только вот алгоритмы и логику
понял, спасибо, значит только скелет и анимации делать в блендере, а кинематику и всякие смешения уже в движке буду
я просто думал, что могу управляющие кости в блендере накидать, на которые IK привязываю, а потом в годоте просто к ним ноду приделать к скелету и на нее все вектора кидать, чтобы цепочки костей не в самом годоте прописывать, а в блендере, а там только вот алгоритмы и логику
понял, спасибо, значит только скелет и анимации делать в блендере, а кинематику и всякие смешения уже в движке буду
>>43267
Воспринимай это как шейдерные ноды в блендере. Ты внутри блендера можешь на нодах сваять красивый шейдер, натурально выглядящий, но при экспорте тебе экспортируется всё равно набор текстур, но не логический скрипт.
Так и с ИК, это не битмап, не геометрия. Это - логика. Логика физической модели. Логику между приложениями неохотно передают. Почему так? ХЗ.
> управляющие кости в блендере накидать, на которые IK привязываю
Воспринимай это как шейдерные ноды в блендере. Ты внутри блендера можешь на нодах сваять красивый шейдер, натурально выглядящий, но при экспорте тебе экспортируется всё равно набор текстур, но не логический скрипт.
Так и с ИК, это не битмап, не геометрия. Это - логика. Логика физической модели. Логику между приложениями неохотно передают. Почему так? ХЗ.
>>43228
Я удалил ту демку (3D инверсная кинематика), т.к. она мне в общем-то бесполезна. Во всяком случае до тех пор, пока у меня нет полноценного 3D персонажа, которому можно было бы навешивать инверсную кинематику с какой-либо целью.
>>43253
Пока ты там байтики ковыряешь, современные разработчики выпускают игры, даже толком не разбираясь в программировании. Куда не глянь, везде игры делают дизайнеры. Даже дорогие проекты. Да, в этом есть недостатки и такие проекты редко получают хорошую поддержку. Но, тем не менее, они приносят тонны бабла и признания игроков, считаются культовыми в своём времени и жанре. Примеры я приводить, конечно, не буду.
Твой говнокод никому не нужен. А если твой говнокод всё же скопируют, ты можешь обратиться в суд за нарушение твоего авторского права. Вот только чтобы в суде признали, что твой код действительно скопирован, нужен какой-то способ увидеть код в руках того, кто его у тебя скопировал. Если твой код компилируется - удачи с попытками доказать, что кто-то компилирует твой декомпилированный код, ведь бинарники будут совершенно разными, а декомпиляция чужого бинарника - преступление, т.е. тебе для доказательства преступления нужно совершить преступление...
Совсем другое дело со скриптовыми языками, которые поставляются в исходном виде: если ты зашёл на сайт, ты сразу видишь, какие JS файлы там используются. Если JS файл с твоего сайта скопировали на другой, ты сразу это можешь увидеть и доказать, даже если его отредактировали или обфусцировали. В результате ты можешь выиграть суд и отсудить у скопировавшего твой JS код огромную сумму. В то же время твой скомпилированный код будут юзать все кому не лень и ты даже права не имеешь на то, чтобы узнать, что они действительно абузят твой код, а не какой-то там свой - при попытке узнать ты нарушаешь закон.
>>43254
Главный вопрос: зачем? Зачем вкладывать силы и время в то, что тебе нахрен не нужно? Игровые движки стали популярны именно по той простой причине, что большинству разработчиков игр нахрен не нужно писать свой собственный движок и как-то там его организовывать. Им достаточно взять готовое, изучить это и использовать в том виде, в котором поставляет это разработчик движка. А если ты такой умник, что хочешь всё по-своему организовать, то вообще иди собирать свой движок: Bullet - отдельная библиотека, для графики тоже есть библиотека, для всего что угодно есть отдельные библиотеки.
Если тебе не нужен Godot Editor и ты хочешь ковырять байтики на C++ в Блокноте, то тебе не нужен Godot Engine.
>>Расстроился и удалил
>Почему?
Я удалил ту демку (3D инверсная кинематика), т.к. она мне в общем-то бесполезна. Во всяком случае до тех пор, пока у меня нет полноценного 3D персонажа, которому можно было бы навешивать инверсную кинематику с какой-либо целью.
>>43253
>надо как диды в 80-х
Пока ты там байтики ковыряешь, современные разработчики выпускают игры, даже толком не разбираясь в программировании. Куда не глянь, везде игры делают дизайнеры. Даже дорогие проекты. Да, в этом есть недостатки и такие проекты редко получают хорошую поддержку. Но, тем не менее, они приносят тонны бабла и признания игроков, считаются культовыми в своём времени и жанре. Примеры я приводить, конечно, не буду.
>сможет взломать любой васян
Твой говнокод никому не нужен. А если твой говнокод всё же скопируют, ты можешь обратиться в суд за нарушение твоего авторского права. Вот только чтобы в суде признали, что твой код действительно скопирован, нужен какой-то способ увидеть код в руках того, кто его у тебя скопировал. Если твой код компилируется - удачи с попытками доказать, что кто-то компилирует твой декомпилированный код, ведь бинарники будут совершенно разными, а декомпиляция чужого бинарника - преступление, т.е. тебе для доказательства преступления нужно совершить преступление...
Совсем другое дело со скриптовыми языками, которые поставляются в исходном виде: если ты зашёл на сайт, ты сразу видишь, какие JS файлы там используются. Если JS файл с твоего сайта скопировали на другой, ты сразу это можешь увидеть и доказать, даже если его отредактировали или обфусцировали. В результате ты можешь выиграть суд и отсудить у скопировавшего твой JS код огромную сумму. В то же время твой скомпилированный код будут юзать все кому не лень и ты даже права не имеешь на то, чтобы узнать, что они действительно абузят твой код, а не какой-то там свой - при попытке узнать ты нарушаешь закон.
>>43254
>сможешь организовать
Главный вопрос: зачем? Зачем вкладывать силы и время в то, что тебе нахрен не нужно? Игровые движки стали популярны именно по той простой причине, что большинству разработчиков игр нахрен не нужно писать свой собственный движок и как-то там его организовывать. Им достаточно взять готовое, изучить это и использовать в том виде, в котором поставляет это разработчик движка. А если ты такой умник, что хочешь всё по-своему организовать, то вообще иди собирать свой движок: Bullet - отдельная библиотека, для графики тоже есть библиотека, для всего что угодно есть отдельные библиотеки.
Если тебе не нужен Godot Editor и ты хочешь ковырять байтики на C++ в Блокноте, то тебе не нужен Godot Engine.
>>43228
Я удалил ту демку (3D инверсная кинематика), т.к. она мне в общем-то бесполезна. Во всяком случае до тех пор, пока у меня нет полноценного 3D персонажа, которому можно было бы навешивать инверсную кинематику с какой-либо целью.
>>43253
Пока ты там байтики ковыряешь, современные разработчики выпускают игры, даже толком не разбираясь в программировании. Куда не глянь, везде игры делают дизайнеры. Даже дорогие проекты. Да, в этом есть недостатки и такие проекты редко получают хорошую поддержку. Но, тем не менее, они приносят тонны бабла и признания игроков, считаются культовыми в своём времени и жанре. Примеры я приводить, конечно, не буду.
Твой говнокод никому не нужен. А если твой говнокод всё же скопируют, ты можешь обратиться в суд за нарушение твоего авторского права. Вот только чтобы в суде признали, что твой код действительно скопирован, нужен какой-то способ увидеть код в руках того, кто его у тебя скопировал. Если твой код компилируется - удачи с попытками доказать, что кто-то компилирует твой декомпилированный код, ведь бинарники будут совершенно разными, а декомпиляция чужого бинарника - преступление, т.е. тебе для доказательства преступления нужно совершить преступление...
Совсем другое дело со скриптовыми языками, которые поставляются в исходном виде: если ты зашёл на сайт, ты сразу видишь, какие JS файлы там используются. Если JS файл с твоего сайта скопировали на другой, ты сразу это можешь увидеть и доказать, даже если его отредактировали или обфусцировали. В результате ты можешь выиграть суд и отсудить у скопировавшего твой JS код огромную сумму. В то же время твой скомпилированный код будут юзать все кому не лень и ты даже права не имеешь на то, чтобы узнать, что они действительно абузят твой код, а не какой-то там свой - при попытке узнать ты нарушаешь закон.
>>43254
Главный вопрос: зачем? Зачем вкладывать силы и время в то, что тебе нахрен не нужно? Игровые движки стали популярны именно по той простой причине, что большинству разработчиков игр нахрен не нужно писать свой собственный движок и как-то там его организовывать. Им достаточно взять готовое, изучить это и использовать в том виде, в котором поставляет это разработчик движка. А если ты такой умник, что хочешь всё по-своему организовать, то вообще иди собирать свой движок: Bullet - отдельная библиотека, для графики тоже есть библиотека, для всего что угодно есть отдельные библиотеки.
Если тебе не нужен Godot Editor и ты хочешь ковырять байтики на C++ в Блокноте, то тебе не нужен Godot Engine.
>>Расстроился и удалил
>Почему?
Я удалил ту демку (3D инверсная кинематика), т.к. она мне в общем-то бесполезна. Во всяком случае до тех пор, пока у меня нет полноценного 3D персонажа, которому можно было бы навешивать инверсную кинематику с какой-либо целью.
>>43253
>надо как диды в 80-х
Пока ты там байтики ковыряешь, современные разработчики выпускают игры, даже толком не разбираясь в программировании. Куда не глянь, везде игры делают дизайнеры. Даже дорогие проекты. Да, в этом есть недостатки и такие проекты редко получают хорошую поддержку. Но, тем не менее, они приносят тонны бабла и признания игроков, считаются культовыми в своём времени и жанре. Примеры я приводить, конечно, не буду.
>сможет взломать любой васян
Твой говнокод никому не нужен. А если твой говнокод всё же скопируют, ты можешь обратиться в суд за нарушение твоего авторского права. Вот только чтобы в суде признали, что твой код действительно скопирован, нужен какой-то способ увидеть код в руках того, кто его у тебя скопировал. Если твой код компилируется - удачи с попытками доказать, что кто-то компилирует твой декомпилированный код, ведь бинарники будут совершенно разными, а декомпиляция чужого бинарника - преступление, т.е. тебе для доказательства преступления нужно совершить преступление...
Совсем другое дело со скриптовыми языками, которые поставляются в исходном виде: если ты зашёл на сайт, ты сразу видишь, какие JS файлы там используются. Если JS файл с твоего сайта скопировали на другой, ты сразу это можешь увидеть и доказать, даже если его отредактировали или обфусцировали. В результате ты можешь выиграть суд и отсудить у скопировавшего твой JS код огромную сумму. В то же время твой скомпилированный код будут юзать все кому не лень и ты даже права не имеешь на то, чтобы узнать, что они действительно абузят твой код, а не какой-то там свой - при попытке узнать ты нарушаешь закон.
>>43254
>сможешь организовать
Главный вопрос: зачем? Зачем вкладывать силы и время в то, что тебе нахрен не нужно? Игровые движки стали популярны именно по той простой причине, что большинству разработчиков игр нахрен не нужно писать свой собственный движок и как-то там его организовывать. Им достаточно взять готовое, изучить это и использовать в том виде, в котором поставляет это разработчик движка. А если ты такой умник, что хочешь всё по-своему организовать, то вообще иди собирать свой движок: Bullet - отдельная библиотека, для графики тоже есть библиотека, для всего что угодно есть отдельные библиотеки.
Если тебе не нужен Godot Editor и ты хочешь ковырять байтики на C++ в Блокноте, то тебе не нужен Godot Engine.
>>43282
Чтобы не было пропуков. Выше же например сказали что гдскрипт не годится для нормальных игр.
>Главный вопрос: зачем?
Чтобы не было пропуков. Выше же например сказали что гдскрипт не годится для нормальных игр.
>>43285
Они будут, даже если ты игру прямо в машинных кодах напишешь.
В этом разделе настоящих разработчиков игр практически нет, не верь на слово кому попало.
Годится, ещё как годится. Он даже быстрее некоторых других скриптовых языков, которые широко используются или использовались в играх на других игровых движках.
>>43292
Ну вот сделают они всю игру на C++, увидят случайный пропук из-за драйвера в их ОС и будут верещать "годот пропукивается даже на C++", хотя это вообще не вина игрового движка. Смысл таким вообще что-то рекомендовать, если в их мирке единственное, что требуется от игры - это максимальная производительность. Это либо тролли, либо клюнувшие на маркетинг мониторов 120+ Гц. Что-то вроде аудиофилов, для которых качество звукового файла важнее, чем записанная музыка, потому что в музыке они не разбираются, а циферки в мета-информации файла сравнить могут.
Я, как тот, кто долгое время играл в игры с 15-20 фпс и до сих пор продолжаю играть в некоторые игры на 25-30 фпс, могу сказать, что у Godot всё более чем хорошо с производительностью и GDScript оптимизирован больше, чем необходимо для игр. Там, где игра на UE будет вообще зависать, а игра на Unity будет выдавать от силы 30 фпс, игра на Godot запросто выдаст сотни фпс. Конечно, в том числе потому, что большинства лишних функций в Godot просто нет, а реализовывать я их, разумеется, не буду, но, например, обмазывать супер-пупер освещением набор примитивных кубов в любом случае нет смысла... Главное - это геймплей, механики - то, что мы называем игрой. А графика - это что-то вроде украшения, макияжа, мишуры. Вот поэтому Godot лучше и ему более чем хватает производительности (RTS с миллионами юнитов пишите на ассемблере, если вам это нужно) и функционала (анимированные 3D модели выводить на экран можно, источники света и теней есть - чего вы ещё хотите?).
>Чтобы не было пропуков.
Они будут, даже если ты игру прямо в машинных кодах напишешь.
>Выше же например сказали
В этом разделе настоящих разработчиков игр практически нет, не верь на слово кому попало.
>гдскрипт не годится для нормальных игр
Годится, ещё как годится. Он даже быстрее некоторых других скриптовых языков, которые широко используются или использовались в играх на других игровых движках.
>>43292
>порядок действий для тех, кто боится пропуков
Ну вот сделают они всю игру на C++, увидят случайный пропук из-за драйвера в их ОС и будут верещать "годот пропукивается даже на C++", хотя это вообще не вина игрового движка. Смысл таким вообще что-то рекомендовать, если в их мирке единственное, что требуется от игры - это максимальная производительность. Это либо тролли, либо клюнувшие на маркетинг мониторов 120+ Гц. Что-то вроде аудиофилов, для которых качество звукового файла важнее, чем записанная музыка, потому что в музыке они не разбираются, а циферки в мета-информации файла сравнить могут.
Я, как тот, кто долгое время играл в игры с 15-20 фпс и до сих пор продолжаю играть в некоторые игры на 25-30 фпс, могу сказать, что у Godot всё более чем хорошо с производительностью и GDScript оптимизирован больше, чем необходимо для игр. Там, где игра на UE будет вообще зависать, а игра на Unity будет выдавать от силы 30 фпс, игра на Godot запросто выдаст сотни фпс. Конечно, в том числе потому, что большинства лишних функций в Godot просто нет, а реализовывать я их, разумеется, не буду, но, например, обмазывать супер-пупер освещением набор примитивных кубов в любом случае нет смысла... Главное - это геймплей, механики - то, что мы называем игрой. А графика - это что-то вроде украшения, макияжа, мишуры. Вот поэтому Godot лучше и ему более чем хватает производительности (RTS с миллионами юнитов пишите на ассемблере, если вам это нужно) и функционала (анимированные 3D модели выводить на экран можно, источники света и теней есть - чего вы ещё хотите?).
>>43305
В шутане тебе требуется обновлять не только статичную картинку, а обновлять сотни картинок в моменты, когда ты резко поворачиваешься. На 60 гц мониторе ты соснёшь у 120 герцовых богов.
> клюнувшие на маркетинг мониторов 120+ Гц
В шутане тебе требуется обновлять не только статичную картинку, а обновлять сотни картинок в моменты, когда ты резко поворачиваешься. На 60 гц мониторе ты соснёшь у 120 герцовых богов.
895 Кб, 1024x768>>43307
если в шутане тебе пришлось поворачиваться резко, ты занял неправильную позицию. да и вообще, про играют на низком разрешении со скрученными мипмапами.
если в шутане тебе пришлось поворачиваться резко, ты занял неправильную позицию. да и вообще, про играют на низком разрешении со скрученными мипмапами.
>>43308
... чтобы видеокарта выдавала 120 ФПС на 120 гц моник.
> про играют на низком разрешении со скрученными мипмапами
... чтобы видеокарта выдавала 120 ФПС на 120 гц моник.
1,4 Мб, webm,1366x768, 0:22
>>43260
Я отвечал в каком-то треде, что считаю, что карты надо делать на полигонах. Вот набросал небольшой пример, с выделениями областей и даже примитивным редактированием.
Не буду говорить что там все просто и не требует работы, надо много с чем разбираться, и с качеством рисуемых линий и их шейдерами и текстурированием, изгибы, стыки.
В этом примере оба полигона просто от руки накликаны мышкой, по ним строится еще контур, а также коллайдер который реагирует на наведение мыши. Кроме того заметен баг, при редактировании вершин в какой то момент красная территория исчезла, возможно полигон оказался "вывернутым", это все надо прорабатывать.
Но даже если ты делаешь более простую игру, ты можешь использовать эти приемы, даже если у тебя вся карта растровая будет, ты все равно можешь ее сам разрезать на спрайты отдельных провинций, и включать-выключать используя невидимые полигоны как кнопки.
Я отвечал в каком-то треде, что считаю, что карты надо делать на полигонах. Вот набросал небольшой пример, с выделениями областей и даже примитивным редактированием.
Не буду говорить что там все просто и не требует работы, надо много с чем разбираться, и с качеством рисуемых линий и их шейдерами и текстурированием, изгибы, стыки.
В этом примере оба полигона просто от руки накликаны мышкой, по ним строится еще контур, а также коллайдер который реагирует на наведение мыши. Кроме того заметен баг, при редактировании вершин в какой то момент красная территория исчезла, возможно полигон оказался "вывернутым", это все надо прорабатывать.
Но даже если ты делаешь более простую игру, ты можешь использовать эти приемы, даже если у тебя вся карта растровая будет, ты все равно можешь ее сам разрезать на спрайты отдельных провинций, и включать-выключать используя невидимые полигоны как кнопки.
>>43348
Тоже сойдёт.
Тоже сойдёт.
Рубрика вряд ли пригодится, но знать стоит
Нода может узнать свой порядковый номер в дереве родителя: get_index()
С другой стороны, родитель может двигать дочерние ноды на другую позицию: move_child(node, index)
Нода может узнать свой порядковый номер в дереве родителя: get_index()
С другой стороны, родитель может двигать дочерние ноды на другую позицию: move_child(node, index)
Ломает учить 3,5, когда уже милионная бета 4,0. Да, для 3.5 дохуя туторов+стабильность, но насколько сильно отличается 4 от 3,5? Ну т.е. концептуально-кардинально. Старые туторы + какие-нибудь доки по бете (есть ли вообще что-то?) норм тема? Мне чисто для себя кириллить говно всякое.
>>43355
Разница небольшая. Но ассеты совсем отвалятся. Если тебе некритично, то и ладно. А я сейчас одну игру с редактором уровней заказчику собирал и там не отказаться пока от 3
Разница небольшая. Но ассеты совсем отвалятся. Если тебе некритично, то и ладно. А я сейчас одну игру с редактором уровней заказчику собирал и там не отказаться пока от 3
>>43307
Ты про PUBG, который лагает на топовом железе?
Или ты про обычные шутеры, где 3.5 калеки на заднем дворе дачи?
Реакция нервной системы человека между 150 мс и 500 мс.
Это реакция на уровне рефлекса. Если нужно думать - дольше.
Смотрим, какая задержка у дисплеев между кадрами:
60 Гц - это 16 мс между кадрами.
120 Гц - это 8 мс между кадрами.
Добавляем задержки железа:
Пинг в локальной городской сети - 30 мс
Пинг в пределах своей страны (РФ) - 100 мс
Пинг до сервера где-то в США или Китае - 200+ мс
Учитываем ещё что обычно сервер не самый быстрый.
А какая задержка у клавомыши? Десяток мс как минимум.
Считаем общую задержку:
+ 100 мс на получение данных от сервера;
+ 1 мс на обновление всех данных в клиенте;
+ 16 мс на вывод актуальной картинки на монитор;
+ 350 мс на то, чтобы сигнал прошёл от сетчатки до мышц;
+ 250 мс на то, чтобы рука дёрнулась в нужном направлении;
+ 10 мс на передачу сигнала от кнопки мыши до процессора;
+ 1 мс на то, чтобы игра сформировала запрос к серверу;
+ 100 мс на то, чтобы запрос с данными дошли до сервера;
+ 1 мс на то, чтобы сервер убедился в валидности данных.
Итого: 829 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 72% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2% этого времени.
Если игра оффлайн: 627 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 95% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2.5% этого времени.
Вывод: твои оправдания покупки 120 Гц монитора ложны.
inb4 ррряяяя нет, я потратил деньги не зря, не зря!
>>43308
Верно, так легче заметить противника, меньше отвлекающих факторов.
>>43309
На низких настройках графики зачастую нет травы, бликов и т.п.
>>43312 (Del)
Попробуй быть "про", когда противник может скрыться в траве.
>В шутане
>обновлять сотни картинок
Ты про PUBG, который лагает на топовом железе?
Или ты про обычные шутеры, где 3.5 калеки на заднем дворе дачи?
>На 60 гц мониторе ты соснёшь у 120 герцовых лохов.
Реакция нервной системы человека между 150 мс и 500 мс.
Это реакция на уровне рефлекса. Если нужно думать - дольше.
Смотрим, какая задержка у дисплеев между кадрами:
60 Гц - это 16 мс между кадрами.
120 Гц - это 8 мс между кадрами.
Добавляем задержки железа:
Пинг в локальной городской сети - 30 мс
Пинг в пределах своей страны (РФ) - 100 мс
Пинг до сервера где-то в США или Китае - 200+ мс
Учитываем ещё что обычно сервер не самый быстрый.
А какая задержка у клавомыши? Десяток мс как минимум.
Считаем общую задержку:
+ 100 мс на получение данных от сервера;
+ 1 мс на обновление всех данных в клиенте;
+ 16 мс на вывод актуальной картинки на монитор;
+ 350 мс на то, чтобы сигнал прошёл от сетчатки до мышц;
+ 250 мс на то, чтобы рука дёрнулась в нужном направлении;
+ 10 мс на передачу сигнала от кнопки мыши до процессора;
+ 1 мс на то, чтобы игра сформировала запрос к серверу;
+ 100 мс на то, чтобы запрос с данными дошли до сервера;
+ 1 мс на то, чтобы сервер убедился в валидности данных.
Итого: 829 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 72% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2% этого времени.
Если игра оффлайн: 627 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 95% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2.5% этого времени.
Вывод: твои оправдания покупки 120 Гц монитора ложны.
inb4 ррряяяя нет, я потратил деньги не зря, не зря!
>>43308
>про играют на низком разрешении со скрученными мипмапами.
Верно, так легче заметить противника, меньше отвлекающих факторов.
>>43309
На низких настройках графики зачастую нет травы, бликов и т.п.
>>43312 (Del)
Попробуй быть "про", когда противник может скрыться в траве.
>>43307
Ты про PUBG, который лагает на топовом железе?
Или ты про обычные шутеры, где 3.5 калеки на заднем дворе дачи?
Реакция нервной системы человека между 150 мс и 500 мс.
Это реакция на уровне рефлекса. Если нужно думать - дольше.
Смотрим, какая задержка у дисплеев между кадрами:
60 Гц - это 16 мс между кадрами.
120 Гц - это 8 мс между кадрами.
Добавляем задержки железа:
Пинг в локальной городской сети - 30 мс
Пинг в пределах своей страны (РФ) - 100 мс
Пинг до сервера где-то в США или Китае - 200+ мс
Учитываем ещё что обычно сервер не самый быстрый.
А какая задержка у клавомыши? Десяток мс как минимум.
Считаем общую задержку:
+ 100 мс на получение данных от сервера;
+ 1 мс на обновление всех данных в клиенте;
+ 16 мс на вывод актуальной картинки на монитор;
+ 350 мс на то, чтобы сигнал прошёл от сетчатки до мышц;
+ 250 мс на то, чтобы рука дёрнулась в нужном направлении;
+ 10 мс на передачу сигнала от кнопки мыши до процессора;
+ 1 мс на то, чтобы игра сформировала запрос к серверу;
+ 100 мс на то, чтобы запрос с данными дошли до сервера;
+ 1 мс на то, чтобы сервер убедился в валидности данных.
Итого: 829 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 72% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2% этого времени.
Если игра оффлайн: 627 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 95% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2.5% этого времени.
Вывод: твои оправдания покупки 120 Гц монитора ложны.
inb4 ррряяяя нет, я потратил деньги не зря, не зря!
>>43308
Верно, так легче заметить противника, меньше отвлекающих факторов.
>>43309
На низких настройках графики зачастую нет травы, бликов и т.п.
>>43312 (Del)
Попробуй быть "про", когда противник может скрыться в траве.
>В шутане
>обновлять сотни картинок
Ты про PUBG, который лагает на топовом железе?
Или ты про обычные шутеры, где 3.5 калеки на заднем дворе дачи?
>На 60 гц мониторе ты соснёшь у 120 герцовых лохов.
Реакция нервной системы человека между 150 мс и 500 мс.
Это реакция на уровне рефлекса. Если нужно думать - дольше.
Смотрим, какая задержка у дисплеев между кадрами:
60 Гц - это 16 мс между кадрами.
120 Гц - это 8 мс между кадрами.
Добавляем задержки железа:
Пинг в локальной городской сети - 30 мс
Пинг в пределах своей страны (РФ) - 100 мс
Пинг до сервера где-то в США или Китае - 200+ мс
Учитываем ещё что обычно сервер не самый быстрый.
А какая задержка у клавомыши? Десяток мс как минимум.
Считаем общую задержку:
+ 100 мс на получение данных от сервера;
+ 1 мс на обновление всех данных в клиенте;
+ 16 мс на вывод актуальной картинки на монитор;
+ 350 мс на то, чтобы сигнал прошёл от сетчатки до мышц;
+ 250 мс на то, чтобы рука дёрнулась в нужном направлении;
+ 10 мс на передачу сигнала от кнопки мыши до процессора;
+ 1 мс на то, чтобы игра сформировала запрос к серверу;
+ 100 мс на то, чтобы запрос с данными дошли до сервера;
+ 1 мс на то, чтобы сервер убедился в валидности данных.
Итого: 829 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 72% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2% этого времени.
Если игра оффлайн: 627 мс на то, чтобы сделать один выстрел.
Человеческий фактор составляет 95% этого времени (600+ мс).
Задержка монитора 60 Гц едва дотягивает до 2.5% этого времени.
Вывод: твои оправдания покупки 120 Гц монитора ложны.
inb4 ррряяяя нет, я потратил деньги не зря, не зря!
>>43308
>про играют на низком разрешении со скрученными мипмапами.
Верно, так легче заметить противника, меньше отвлекающих факторов.
>>43309
На низких настройках графики зачастую нет травы, бликов и т.п.
>>43312 (Del)
Попробуй быть "про", когда противник может скрыться в траве.
9 Кб, 332x331>>43260
Верно мыслишь, маленькие клетки - "атомы", т.е. неделимые участки территории.
>>43314
Задолбаешься фиксить баги + сложно сделать красиво.
Лучший способ сделать такие контуры - это marching squares:
https://en.wikipedia.org/wiki/Marching_squares
>карта будет поделена на маленькие клетки для процесса захвата земель при войне
Верно мыслишь, маленькие клетки - "атомы", т.е. неделимые участки территории.
>>43314
>считаю, что карты надо делать на полигонах
Задолбаешься фиксить баги + сложно сделать красиво.
Лучший способ сделать такие контуры - это marching squares:
https://en.wikipedia.org/wiki/Marching_squares
Годотеры, у меня такая проблема. Вот узнать вошло ли тело или вышло легко с помощью сигналов, а как узнать есть ли тело в области? Не вошло оно или вышло, а именно есть в области
>>43430
Спасибо, то что нужно
Спасибо, то что нужно
>>43430
А разве не проще просто переменной менеджить? Вошло тело isOverlappped = true, вышло isOverlapped = false. Если что в годоте новичок.
А разве не проще просто переменной менеджить? Вошло тело isOverlappped = true, вышло isOverlapped = false. Если что в годоте новичок.
>>43663
Если что-то двигается динамически, есть смысл делать как ты говоришь. А если одноразово статически, так так не удобно.
Во-вторых, он возвращает список, а у тебя только один флаг.
Например, ты хочешь построить домик в каком-то месте и тебе надо узнать, что там нет препятствий в виде других домиков. Или делаешь мгновенный взрыв. Тогда достаточно просто get_overlapping_...()
Если что-то двигается динамически, есть смысл делать как ты говоришь. А если одноразово статически, так так не удобно.
Во-вторых, он возвращает список, а у тебя только один флаг.
Например, ты хочешь построить домик в каком-то месте и тебе надо узнать, что там нет препятствий в виде других домиков. Или делаешь мгновенный взрыв. Тогда достаточно просто get_overlapping_...()
>>43674
for body in get_overlapping_bodies(): if body.has_method("overlap_action"): body.overlap_action()
Рейт май код, годаны.
мимокрок
> Тогда достаточно просто get_overlapping_...()
for body in get_overlapping_bodies(): if body.has_method("overlap_action"): body.overlap_action()
Рейт май код, годаны.
мимокрок
>>43674
Area для такой задачи не подходит, потому что она не обновляет список коллизий сразу.
Тебе нужно это:
https://docs.godotengine.org/en/stable/classes/class_physics2ddirectspacestate.html#class-physics2ddirectspacestate-method-intersect-shape
- можешь теребить сколько угодно, оно будет сразу выдавать точный ответ.
А Area - это датчики для системы сигналов "вошёл" и "вышел", то есть совсем без сигналов их использовать нерационально (кроме изменения свойств физики). Ты же не будешь держать в сцене бесполезную 99% времени Area, но и не будешь создавать новую Area при необходимости проверить всего одно пресечение? Для этого как раз и предусмотрены методы по ссылке выше.
>>43663
Зависит от ситуации. Иногда лучше хранить это значение у себя в классе, иногда может быть лучше не дублировать данные, запрашивая их у ноды по необходимости.
>одноразово статически
>хочешь построить домик в каком-то месте и тебе надо узнать, что там нет препятствий в виде других домиков. Или делаешь мгновенный взрыв.
Area для такой задачи не подходит, потому что она не обновляет список коллизий сразу.
Тебе нужно это:
https://docs.godotengine.org/en/stable/classes/class_physics2ddirectspacestate.html#class-physics2ddirectspacestate-method-intersect-shape
- можешь теребить сколько угодно, оно будет сразу выдавать точный ответ.
А Area - это датчики для системы сигналов "вошёл" и "вышел", то есть совсем без сигналов их использовать нерационально (кроме изменения свойств физики). Ты же не будешь держать в сцене бесполезную 99% времени Area, но и не будешь создавать новую Area при необходимости проверить всего одно пресечение? Для этого как раз и предусмотрены методы по ссылке выше.
>>43663
Зависит от ситуации. Иногда лучше хранить это значение у себя в классе, иногда может быть лучше не дублировать данные, запрашивая их у ноды по необходимости.
>>43737
На следующий кадр вроде должно быть обновлено, для 99% геймплея этого хватит.
>Area для такой задачи не подходит, потому что она не обновляет список коллизий сразу.
На следующий кадр вроде должно быть обновлено, для 99% геймплея этого хватит.
Почему в годоте координаты в пикселях?
Пиксели сейчас даже для интерфейса не используются. Какие пиксели в 2022 ЛОЛ.
Какой смысл в пикселях, если можно на камере поменять масштаб? Все равно пиксели отыквятся и не будут ничего обозначать
Вся логика игры привязывается к размеру экрана лол. Как мне, например, сделать скорость персонажа 1 метр в секунду в игре?
Пиксели сейчас даже для интерфейса не используются. Какие пиксели в 2022 ЛОЛ.
Какой смысл в пикселях, если можно на камере поменять масштаб? Все равно пиксели отыквятся и не будут ничего обозначать
Вся логика игры привязывается к размеру экрана лол. Как мне, например, сделать скорость персонажа 1 метр в секунду в игре?
>>43802
Я хотел сделать 3д спрайты с ортографической камерой и 2д физикой. Но видимо так нельзя сделать в годоте. 2д физика намертво пришита к CanvasItem с пикселями, как я понял
Печально
Только свой 2д движок прикручивать самому
Я хотел сделать 3д спрайты с ортографической камерой и 2д физикой. Но видимо так нельзя сделать в годоте. 2д физика намертво пришита к CanvasItem с пикселями, как я понял
Печально
Только свой 2д движок прикручивать самому
>>43802
Чел...
Ну ок давай разбираться.
Во-первых, до сих пор делают пиксель-перфект игры.
Во-вторых, сам 2д арт рисуется пикселями, пока что тут мало изменений.
В-третьих, читай документацию. Эти пиксели - виртуальные, design-time пиксели. Ты можешь точно так же считать их абстрактными юнитами.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Так же как и везде - берешь и делаешь масштабирование. Если у тебя у персонажа нога 1 метр и ее спрайт это 10 пикселей, то вот и ответ.
Чел...
Ну ок давай разбираться.
Во-первых, до сих пор делают пиксель-перфект игры.
Во-вторых, сам 2д арт рисуется пикселями, пока что тут мало изменений.
В-третьих, читай документацию. Эти пиксели - виртуальные, design-time пиксели. Ты можешь точно так же считать их абстрактными юнитами.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
>Как мне, например, сделать скорость персонажа 1 метр в секунду в игре?
Так же как и везде - берешь и делаешь масштабирование. Если у тебя у персонажа нога 1 метр и ее спрайт это 10 пикселей, то вот и ответ.
Здравствуйте.
Уважаемые эксперты по движку Годо, поясните, пожалуйста, за шаблоны экспорта. Привязаны ли они к архитектуре процессора? Например, получилось скомпилить Godot под Линукс на архитектуре E2K (Эльбрус) или ARM, при этом он запускается и нормально работает (сам движок со всем что есть из коробки). А вот дальше как быть? Что ещё нужно, чтобы можно было экспортировать проект с Линукса на Эльбрусе для Линукса на x86/64, например? Достаточно будет просто загрузить темплейты с официального сайта или нужно будет пилить свои под экзотический процессор?
Уважаемые эксперты по движку Годо, поясните, пожалуйста, за шаблоны экспорта. Привязаны ли они к архитектуре процессора? Например, получилось скомпилить Godot под Линукс на архитектуре E2K (Эльбрус) или ARM, при этом он запускается и нормально работает (сам движок со всем что есть из коробки). А вот дальше как быть? Что ещё нужно, чтобы можно было экспортировать проект с Линукса на Эльбрусе для Линукса на x86/64, например? Достаточно будет просто загрузить темплейты с официального сайта или нужно будет пилить свои под экзотический процессор?
4,3 Мб, webm,1920x1080, 0:34
>>43805
Не выдумывай. У тебя одновременно 2д и 3д в годоте. Все, что надо - присваивать из одного мира в другой global_position. Вот пример, где у меня 3д физика переносится на пиксель перфект 2д.
>Но видимо так нельзя сделать в годоте.
Не выдумывай. У тебя одновременно 2д и 3д в годоте. Все, что надо - присваивать из одного мира в другой global_position. Вот пример, где у меня 3д физика переносится на пиксель перфект 2д.
>>43810
Вернее, что нужно, чтобы экспортировать проект под Линукс на Эльбрусе (уже имея Годо запущенный на Эльбрусе)?
>Что ещё нужно, чтобы можно было экспортировать проект с Линукса на Эльбрусе для Линукса на x86/64
Вернее, что нужно, чтобы экспортировать проект под Линукс на Эльбрусе (уже имея Годо запущенный на Эльбрусе)?
>>43810
Раз ты собрал движок, то и шаблон экспорта соберешь.
По сути там отличается тем что scons надо передать флаг tools=no.
https://docs.godotengine.org/en/stable/development/compiling/compiling_for_x11.html#building-export-templates
А вообще, даже сам движок с редактором может запускать экспортированную игру
godot --main-pack your_game.pck
Раз ты собрал движок, то и шаблон экспорта соберешь.
По сути там отличается тем что scons надо передать флаг tools=no.
https://docs.godotengine.org/en/stable/development/compiling/compiling_for_x11.html#building-export-templates
А вообще, даже сам движок с редактором может запускать экспортированную игру
godot --main-pack your_game.pck
>>43814
Спасибо за ответ.
Спасибо за ответ.
>>43814
P.s. но у тебя нет шаблона, чтобы экспортировать...
А не, есть - шаблоном может служить.. Тоже сам билд с редактором.
Сам себя экспортнул - сам себя запустил. Хуан - гений!
>А вообще, даже сам движок с редактором может запускать экспортированную игру
P.s. но у тебя нет шаблона, чтобы экспортировать...
А не, есть - шаблоном может служить.. Тоже сам билд с редактором.
Сам себя экспортнул - сам себя запустил. Хуан - гений!
>>43822
В данном случае у меня 1unit 3d = 32 пикселя.
В твоем случае может быть надо наоборот конвесрию делать, то есть
spatial или sprite3d.global_transform.origin = sprite.global_position / SCALE_RATIO.
В данном случае у меня 1unit 3d = 32 пикселя.
В твоем случае может быть надо наоборот конвесрию делать, то есть
spatial или sprite3d.global_transform.origin = sprite.global_position / SCALE_RATIO.
123 Кб, 820x529>>43822
ты создаешь невидимый 3д объект с симуляцией физики, и потом копируешь его координаты в 2д спрайт?
смекал очка
ты создаешь невидимый 3д объект с симуляцией физики, и потом копируешь его координаты в 2д спрайт?
смекал очка
>>43823
спрайту можно присвоить мировые 3д координаты? я думал он только пиксели переваривает
спрайту можно присвоить мировые 3д координаты? я думал он только пиксели переваривает
>>43839
Это проблема древней архитектуры движка с иерархией объектов, когда физический объект наследуется от объекта канваса. Которую на сайте годота нескромно называют "инновационной".
На этих инновациях еще деды игры писали, и прекрасно понимая все их недостатки придумали ECS и компоненты.
Это проблема древней архитектуры движка с иерархией объектов, когда физический объект наследуется от объекта канваса. Которую на сайте годота нескромно называют "инновационной".
На этих инновациях еще деды игры писали, и прекрасно понимая все их недостатки придумали ECS и компоненты.
>>43849
ECS тебе тут вообще ничем не поможет, кроме того, что тебе придется в разы больше писать этих присваиваний transform = physics_transform, ага.
ECS тебе тут вообще ничем не поможет, кроме того, что тебе придется в разы больше писать этих присваиваний transform = physics_transform, ага.
>>43812
Не совсем понимаю, зачем тебе 3D физика? Разве в Godot нет 2D физики с видом сверху?
>>43805
Не понял, в каком смысле "пришита к пикселям"?
Ты просто создаёшь физические сущности... и всё. Не обязательно вешать на них спрайты.
Если тебе нужна 2D физика с видом сверху, просто обнули гравитацию. Ты ж всё равно прыгать не можешь в 2D мире с видом сверху - все персонажи в таких играх прибиты гвоздями к полу и скользят по нему. Или у тебя какая-то особенная графика? Покажи пример того, что хочешь сделать.
Не совсем понимаю, зачем тебе 3D физика? Разве в Godot нет 2D физики с видом сверху?
>>43805
>2д физика намертво пришита к CanvasItem с пикселями
Не понял, в каком смысле "пришита к пикселям"?
Ты просто создаёшь физические сущности... и всё. Не обязательно вешать на них спрайты.
Если тебе нужна 2D физика с видом сверху, просто обнули гравитацию. Ты ж всё равно прыгать не можешь в 2D мире с видом сверху - все персонажи в таких играх прибиты гвоздями к полу и скользят по нему. Или у тебя какая-то особенная графика? Покажи пример того, что хочешь сделать.
>>43854
В 2д физике с видом сверху кубик не перекатится через ребро.
В 2д физике с видом сверху кубик не перекатится через ребро.
>>43852
Проблема в том, что поведение объекта зависит от родителя, и приходится выбирать или у тебя физический объект это элемент канваса, или еще что-то.
>>43853
В другом популярном движке поведение объекта задается не через наследование, а через добавленные на него компоненты. Любой объект с компонентом rigid body становится физическим телом.
Не верю что в 2022 до сих возникают из-за это проблемы. Мне кажется что консенсус по тому что наследование объектов плохо подходит для игровых движков был достигнут еще в нулевых.
Проблема в том, что поведение объекта зависит от родителя, и приходится выбирать или у тебя физический объект это элемент канваса, или еще что-то.
>>43853
В другом популярном движке поведение объекта задается не через наследование, а через добавленные на него компоненты. Любой объект с компонентом rigid body становится физическим телом.
Не верю что в 2022 до сих возникают из-за это проблемы. Мне кажется что консенсус по тому что наследование объектов плохо подходит для игровых движков был достигнут еще в нулевых.
8 Кб, 357x294>>43867
Это вообще ни на что не влияет.
В реальности они там и будут равноправными компонентами.
> что поведение объекта зависит от родителя, и приходится выбирать или у тебя физический объект это элемент канваса, или еще что-то.
Это вообще ни на что не влияет.
В реальности они там и будут равноправными компонентами.
>>43870
Это влияет на то, что я не могу сделать Node3D с поведением RigidBody2D, потому что они наследованы от разных родителей.
Это влияет на то, что я не могу сделать Node3D с поведением RigidBody2D, потому что они наследованы от разных родителей.
138 Кб, 735x687Есть ли вообще предпосылки что в годо откажутся от gsdcript как своё время юнити отказались от UnityScript?
Посос будет если я сейчас сижу ламповейший форк питона учу а мне потом подсунут свинью в виде всратого lua
Посос будет если я сейчас сижу ламповейший форк питона учу а мне потом подсунут свинью в виде всратого lua
>>43886
гдскрипт - это модуль (плагин) к движку. даже если его зачем-то когда-то уберут, легко будет вернуть обратно.
гдскрипт - это модуль (плагин) к движку. даже если его зачем-то когда-то уберут, легко будет вернуть обратно.
>>43886
Это было бы идеально, но зная Хуана по всем его предыдущим решениям - этого не случится никогда.
>Есть ли вообще предпосылки что в годо откажутся от gsdcript как своё время юнити отказались от UnityScript?
Это было бы идеально, но зная Хуана по всем его предыдущим решениям - этого не случится никогда.
>>43901
ну или в виде более всратого C#
ну или в виде более всратого C#
>>43810
Давайте кратко резюмируем ответы на этот пост:
1. Шаблон экспорта это движок, скомпилированный без редактора.
2. Если ты смог скомпилировать движок с редактором, то сможешь и без.
3. Если тебе удалось запустить движок с редактором на своей редкой платформе, и если на ней есть сеть, ты сможешь скачать шаблоны экспорта под другие платформы, но не под свою, потому что Хуан и его команда могут просто о твоей платформе не знать.
4. Если поместить свой шаблон экспорта в папку с шаблонами, которую создаёт себе редактор, ты сможешь делать экспорт встроенными средствами редактора.
5. Экспорт игры - это положить в одну папку шаблон экспорта переименованный в название твоей игры и пак-файл с ресурсами, переимнованный буква в букву как шаблон.
Давайте кратко резюмируем ответы на этот пост:
1. Шаблон экспорта это движок, скомпилированный без редактора.
2. Если ты смог скомпилировать движок с редактором, то сможешь и без.
3. Если тебе удалось запустить движок с редактором на своей редкой платформе, и если на ней есть сеть, ты сможешь скачать шаблоны экспорта под другие платформы, но не под свою, потому что Хуан и его команда могут просто о твоей платформе не знать.
4. Если поместить свой шаблон экспорта в папку с шаблонами, которую создаёт себе редактор, ты сможешь делать экспорт встроенными средствами редактора.
5. Экспорт игры - это положить в одну папку шаблон экспорта переименованный в название твоей игры и пак-файл с ресурсами, переимнованный буква в букву как шаблон.
>>43886
Хули там учить? Я когда узнал о годоте, выучил гдскрипт через неделю и уже через неделю начал пилить первые проекты и срать видосиками в первые годотреды.
(космические видосики с музоном из 90х)
Прекращайте говорить такие профанские фразы как "учу язык", запомни, сын, ты не язык учишь, ты учишь АПИ и арихтектуру движка. Зная архитектуру годота, ты с легкостью оттранспилишь свои наработки с гдаскрпта на шарп, на луа, на питон, на кресты. Да хоть на фортран!
> я сейчас сижу ламповейший форк питона учу
Хули там учить? Я когда узнал о годоте, выучил гдскрипт через неделю и уже через неделю начал пилить первые проекты и срать видосиками в первые годотреды.
(космические видосики с музоном из 90х)
Прекращайте говорить такие профанские фразы как "учу язык", запомни, сын, ты не язык учишь, ты учишь АПИ и арихтектуру движка. Зная архитектуру годота, ты с легкостью оттранспилишь свои наработки с гдаскрпта на шарп, на луа, на питон, на кресты. Да хоть на фортран!
>>43915
Без обид.
Без обид.
>>43913
Не всё так просто.
На Windows может потребоваться редактировать мета-информацию exe (по желанию).
На Android вообще нужен дрочь с SDK, чтобы всё правильно упаковать в APK и подписать.
С вебом точно не уверен, но наверняка что-то нужно менять в JS-файле (название pck)...
На MacOS/iOS, скорее всего, свои заморочки, т.к. это ОСи от эпла, а эпл - корпорация зла.
На Linux вообще без понятия, наверное, будет зависеть от сборки/версии ядра линуха.
Но да, чисто под Windows x86/x64 ты можешь просто закинуть exe в одну папку с pck.
>Экспорт игры - это положить в одну папку шаблон экспорта переименованный в название твоей игры и пак-файл с ресурсами, переимнованный буква в букву как шаблон.
Не всё так просто.
На Windows может потребоваться редактировать мета-информацию exe (по желанию).
На Android вообще нужен дрочь с SDK, чтобы всё правильно упаковать в APK и подписать.
С вебом точно не уверен, но наверняка что-то нужно менять в JS-файле (название pck)...
На MacOS/iOS, скорее всего, свои заморочки, т.к. это ОСи от эпла, а эпл - корпорация зла.
На Linux вообще без понятия, наверное, будет зависеть от сборки/версии ядра линуха.
Но да, чисто под Windows x86/x64 ты можешь просто закинуть exe в одну папку с pck.
>>43914
С нуля? Или был опыт программирования? С опытом-то очень легко изучить. Даже не так - там учить нечего. Я, переходя с Паскаля, просто смотрел в документации формат записи func/for/match/... и писал код "как обычно", т.е. по сути ничего для меня не изменилось. Разве что пришлось привыкать писать snake_case, мне всё-таки больше нравилось писать в PascalCase. Хотя теперь snake_case тоже нравится, привык же. Правда, у меня кроме Паскаля ещё был опыт в (приблизительно по убыванию опыта): JS/PHP/Ada/AutoIt/C#/Forth/Python/C++/ещё что-то, уже не помню имён. Вот учить GDScript с абсолютного нуля будет, наверное, не так-то просто, поэтому не рекомендую его учить первым языком, как минимум из-за значащих отступов в коде, укороченного синтаксиса (урезанных ключевых слов) и отсутствия строгой типизации - наломаешь много дров и даже не поймёшь, почему. Лучше начинать писать на строго типизированном и многословном языке, который не придаёт значения расположению команд в коде и не различает большие и маленькие буквы. Тогда ты сможешь понять Сутьтм программирования, не наступая на неочевидные грабли с типами, табами и всем остальным, по которым всегда успеешь пройти в будущем. Вообще жаль, что GDScript не навязывает строгую типизацию, я бы предпочёл явным образом объявлять Variant-типы вместо опускания типа (чтобы вместо func do(thing) писать func do(thing: Variant) -> Variant).
>Я когда узнал о годоте, выучил гдскрипт через неделю
С нуля? Или был опыт программирования? С опытом-то очень легко изучить. Даже не так - там учить нечего. Я, переходя с Паскаля, просто смотрел в документации формат записи func/for/match/... и писал код "как обычно", т.е. по сути ничего для меня не изменилось. Разве что пришлось привыкать писать snake_case, мне всё-таки больше нравилось писать в PascalCase. Хотя теперь snake_case тоже нравится, привык же. Правда, у меня кроме Паскаля ещё был опыт в (приблизительно по убыванию опыта): JS/PHP/Ada/AutoIt/C#/Forth/Python/C++/ещё что-то, уже не помню имён. Вот учить GDScript с абсолютного нуля будет, наверное, не так-то просто, поэтому не рекомендую его учить первым языком, как минимум из-за значащих отступов в коде, укороченного синтаксиса (урезанных ключевых слов) и отсутствия строгой типизации - наломаешь много дров и даже не поймёшь, почему. Лучше начинать писать на строго типизированном и многословном языке, который не придаёт значения расположению команд в коде и не различает большие и маленькие буквы. Тогда ты сможешь понять Сутьтм программирования, не наступая на неочевидные грабли с типами, табами и всем остальным, по которым всегда успеешь пройти в будущем. Вообще жаль, что GDScript не навязывает строгую типизацию, я бы предпочёл явным образом объявлять Variant-типы вместо опускания типа (чтобы вместо func do(thing) писать func do(thing: Variant) -> Variant).
>>43959
Всё верно, я имел ввиду десктопные платформы, винду и линукс. Остальные платформы я пока что не рассматриваю как интересные мне. Никак не могу побороть свой синдром утёнка по поводу того, что игры - это для мощного игрового пека с большим экраном, клавомышью или геймпадом, но никак не миниатюрный дисплей в который нужно пальцами тыкать. Экран и так мелкий, да ещё и руками половину закрываешь, да ещё и визуальные кнопки загораживают игровую область. Фублять-фунахуй. Пориджы-дегенераты, хрртьфу! Никогда не признаю! Ни за что не приму!
Всё верно, я имел ввиду десктопные платформы, винду и линукс. Остальные платформы я пока что не рассматриваю как интересные мне. Никак не могу побороть свой синдром утёнка по поводу того, что игры - это для мощного игрового пека с большим экраном, клавомышью или геймпадом, но никак не миниатюрный дисплей в который нужно пальцами тыкать. Экран и так мелкий, да ещё и руками половину закрываешь, да ещё и визуальные кнопки загораживают игровую область. Фублять-фунахуй. Пориджы-дегенераты, хрртьфу! Никогда не признаю! Ни за что не приму!
бета 8
Подскажите кто сталкивался:
Есть отдельный Bus на запись звука с микрофона, есть подключенный AudioStreamPlayer2D с выбранным Bus "record" и подключенным AudioStreamMicrophone.
Плеер включен, т.е. в игре я слышу звук с микрофона, но буквально через секунд 5 звук начинает хрипеть и с каждой секундой нарастает задержка перед воспроизведением сказанного в микрофон. Хотя изначально первые секунд 5 сказанное в микрофон мгновенно воспроизводилось в игре, и чем дольше он работает, тем больше задержка между вводом аудио и выводом.
Есть отдельный Bus на запись звука с микрофона, есть подключенный AudioStreamPlayer2D с выбранным Bus "record" и подключенным AudioStreamMicrophone.
Плеер включен, т.е. в игре я слышу звук с микрофона, но буквально через секунд 5 звук начинает хрипеть и с каждой секундой нарастает задержка перед воспроизведением сказанного в микрофон. Хотя изначально первые секунд 5 сказанное в микрофон мгновенно воспроизводилось в игре, и чем дольше он работает, тем больше задержка между вводом аудио и выводом.
>>44244
Сложная проблема, вряд ли с лету тут получится помочь. Попробуй писать в буфер и програмино его воспроизводить, может быть никто не проверял напрямую воткнутый аудиовход в аудиовыход? Алсо пробовал на разных компах, операционках?
Сложная проблема, вряд ли с лету тут получится помочь. Попробуй писать в буфер и програмино его воспроизводить, может быть никто не проверял напрямую воткнутый аудиовход в аудиовыход? Алсо пробовал на разных компах, операционках?
>>44245
Пробовал под Win только 7 и 10, разные аудио драйвера использовал.
В демках официальных с voip такая же история, больше 5 секунд если идёт запись звука, то такой же эффект.
Сижу на 3.5.1, чешу репу. Если выставить буфер секунд 10, то на подольше хватает до этого глюка, но он никуда не уходит.
Пробовал под Win только 7 и 10, разные аудио драйвера использовал.
В демках официальных с voip такая же история, больше 5 секунд если идёт запись звука, то такой же эффект.
Сижу на 3.5.1, чешу репу. Если выставить буфер секунд 10, то на подольше хватает до этого глюка, но он никуда не уходит.
4,1 Мб, webm,1920x1080, 1:08
>>44244
В общем записал видео как это выглядит, вначале звук идёт из самого приложения без задержек, как начинаются фризы подрубаю звук из OBS, чтобы было понятно, какая идёт задержка.
В общем записал видео как это выглядит, вначале звук идёт из самого приложения без задержек, как начинаются фризы подрубаю звук из OBS, чтобы было понятно, какая идёт задержка.
>>44248
Пиши issue, у меня точно в ближайшую неделю нет времени в такое низкоуровневое закапываться.
Можешь для эксперимента еще в других версиях попробовать, 3.4 какой нить
Пиши issue, у меня точно в ближайшую неделю нет времени в такое низкоуровневое закапываться.
Можешь для эксперимента еще в других версиях попробовать, 3.4 какой нить
Как узнать размер всей 2д сцены, на которой расставлены объекты? Не могу найти метода который просто бы вернул общий bounding box.
>>44435
Ладно, некоторый код не вызывающий гордости проще написать и забыть про него как страшный сон.
Ладно, некоторый код не вызывающий гордости проще написать и забыть про него как страшный сон.
254 Кб, 1920x1080>>41833 (OP)
Мужики, помогите! Уже дошел до исступления человеческих эмоций, как в этих шейдерах заменить определенный цвет? Сравнение тупо не работает! Пик релайтед - и так пробовал писать и эдак. Может винду надо переставить или видеокарту купить новую что бы заработало?
Мужики, помогите! Уже дошел до исступления человеческих эмоций, как в этих шейдерах заменить определенный цвет? Сравнение тупо не работает! Пик релайтед - и так пробовал писать и эдак. Может винду надо переставить или видеокарту купить новую что бы заработало?
>>44452
Попробуй такой подход
https://godotengine.org/qa/20926/changing-a-specific-color-in-a-sprite-using-shaders-in-godot
Проще говоря, возможно во float твой цвет не точно 0.33 а 0.330001 и надо не сравнивать, а проверять диапазон
Ну и проверь вообще что твоей шейдер реально заменяет цвет. Например без условия на красный.
Попробуй такой подход
https://godotengine.org/qa/20926/changing-a-specific-color-in-a-sprite-using-shaders-in-godot
Проще говоря, возможно во float твой цвет не точно 0.33 а 0.330001 и надо не сравнивать, а проверять диапазон
Ну и проверь вообще что твоей шейдер реально заменяет цвет. Например без условия на красный.
>>44453
Этого двачую.
Вот вам очередной пруф того, что перед вкатом в геймдев, нужно вкатываться в обычный кодинг.
Если бы у вопрошавшего анона были базовые знания по числам с плавающей точкой и об их сравнении, то вопрос бы не возник.
А = Б, если |А - Б| < Ц, где Ц - это коэффициент точности.
Если же А и Б - наборы чисел с плавающей точкой, то мы всё это выполняем для каждой пары элементов А и Б.
Этого двачую.
Вот вам очередной пруф того, что перед вкатом в геймдев, нужно вкатываться в обычный кодинг.
Если бы у вопрошавшего анона были базовые знания по числам с плавающей точкой и об их сравнении, то вопрос бы не возник.
А = Б, если |А - Б| < Ц, где Ц - это коэффициент точности.
Если же А и Б - наборы чисел с плавающей точкой, то мы всё это выполняем для каждой пары элементов А и Б.
А знаете, годаны.
Годоту остался один шаг, чтобы стать идеальным движком.
У годота модульная архитектура, у его есть модули гдскрипта и шарпскрипта, и есть модуль нативнплагинов, но он не фвляется редакторным модулем, в той мере, в которой им являются первые два.
Когда будет создан редакторный модуль си++ (редакторный - это значит поддерживающийся не только на уровне движка, но и на уровне редактора), то мы сможем делать игры прямо в редакторе годота на си++ и при нажатии кнопки запуска, будет происходить билд нативной либы подключённым компилятором и затем запуск.
Вот тогда.
Вот тогдаааа!
Годоту остался один шаг, чтобы стать идеальным движком.
У годота модульная архитектура, у его есть модули гдскрипта и шарпскрипта, и есть модуль нативнплагинов, но он не фвляется редакторным модулем, в той мере, в которой им являются первые два.
Когда будет создан редакторный модуль си++ (редакторный - это значит поддерживающийся не только на уровне движка, но и на уровне редактора), то мы сможем делать игры прямо в редакторе годота на си++ и при нажатии кнопки запуска, будет происходить билд нативной либы подключённым компилятором и затем запуск.
Вот тогда.
Вот тогдаааа!
>>44459
Это было бы здорово, но до абсолютного совершенства еще работать
Это было бы здорово, но до абсолютного совершенства еще работать
С какой стороны эффективнее подойти?
Вот есть задача: имеется скелет, на него моделим несколько тел/голов, т.е. некий аналог этого вашего скайрима анимации одни и те же, а внешний вид тел разный. Как нашей команде лучше подходить, что делать в условном блендере, а что в движке оптимальнее, чтобы потом можно было новые тела/головыв штамповать и добавлять в игру?
Вот есть задача: имеется скелет, на него моделим несколько тел/голов, т.е. некий аналог этого вашего скайрима анимации одни и те же, а внешний вид тел разный. Как нашей команде лучше подходить, что делать в условном блендере, а что в движке оптимальнее, чтобы потом можно было новые тела/головыв штамповать и добавлять в игру?
>>44456
Это шейдер, а не гдскрипт.
Хотя, наверное, забавная задачка, добавить print() в шейдер.
В принципе можно за вечер по фану сделать.
Это шейдер, а не гдскрипт.
Хотя, наверное, забавная задачка, добавить print() в шейдер.
В принципе можно за вечер по фану сделать.
222 Кб, 1623x858>>44459
Хз, нафик это надо. В смысле, альт-табнуться в IDE где уже настроена компиляция в DLL - вообще несущественная разница.
А вообще видел забавную штуку чувак пилит
https://github.com/RedMser/godot-embed-external-editor
Хз, нафик это надо. В смысле, альт-табнуться в IDE где уже настроена компиляция в DLL - вообще несущественная разница.
А вообще видел забавную штуку чувак пилит
https://github.com/RedMser/godot-embed-external-editor
>>44466
Ну это только для ультравайд господ. И так по бокам место отнимают панели, а ещё у встроенного вс-кода своя панель. Ненене. Лучше альт-табаться.
Ну это только для ультравайд господ. И так по бокам место отнимают панели, а ещё у встроенного вс-кода своя панель. Ненене. Лучше альт-табаться.
12 Кб, 506x143>>44457
Спамлист шатал
Спамлист шатал
>>44468
По большому счету vscode-панель и не нужна, если у него нормально настроен проброс, редактируемый скрипт выбирать в годоте в файл или сцен менеджере
Вообще если подумать самое важное в интеграции это дерево сцены, чтобы автодополнение названий нод работало. Хотя сейчас с %именами это может быть уже и не актуально.
По большому счету vscode-панель и не нужна, если у него нормально настроен проброс, редактируемый скрипт выбирать в годоте в файл или сцен менеджере
Вообще если подумать самое важное в интеграции это дерево сцены, чтобы автодополнение названий нод работало. Хотя сейчас с %именами это может быть уже и не актуально.
>>44452
Во, я подозревал что-то подобное, спасибо за наводку. Кто ж знал что эти шейдыры не такие очевидные.
>возможно во float твой цвет не точно 0.33 а 0.330001 и надо не сравнивать, а проверять диапазон
Во, я подозревал что-то подобное, спасибо за наводку. Кто ж знал что эти шейдыры не такие очевидные.
>>44467
судя по беглому осмотру (сейчас на работе пока и не получается целиком глянуть) нечто похожее, но в видео там вроде одежду/оружие на персонаже просто надевают разное, а у нас типа на гуманоидных персонажей там разные головы нацеплять человек/орк/оборотень, комплекция тела разная качок, худой, толстый и все это привязывать к одному скелету с одним набором анимаций
судя по беглому осмотру (сейчас на работе пока и не получается целиком глянуть) нечто похожее, но в видео там вроде одежду/оружие на персонаже просто надевают разное, а у нас типа на гуманоидных персонажей там разные головы нацеплять человек/орк/оборотень, комплекция тела разная качок, худой, толстый и все это привязывать к одному скелету с одним набором анимаций
>>44464
Наканецта кто-то пилит скайрим-лайк на годоте! Можна к вам в команду? Я умею корявые скрипты на гдскрипте писать.
Наканецта кто-то пилит скайрим-лайк на годоте! Можна к вам в команду? Я умею корявые скрипты на гдскрипте писать.
>>44521
Проиграл.
Хочу сделать реанимацию старого шутана, фирма вроде как давно пиздой накрылась, че там с авторскими правами и левами в таком случае?
Проиграл.
Хочу сделать реанимацию старого шутана, фирма вроде как давно пиздой накрылась, че там с авторскими правами и левами в таком случае?
>>44537
Делай на своих ассетах. Что может пойти не так? Вот если фирма не накрылась, то даже на своих ассетах засудила бы. Как Нинтендо. Всех по судам таскает за Марио, даже когда Марио с нуля нарисован.
Чё за игра-то?
Делай на своих ассетах. Что может пойти не так? Вот если фирма не накрылась, то даже на своих ассетах засудила бы. Как Нинтендо. Всех по судам таскает за Марио, даже когда Марио с нуля нарисован.
Чё за игра-то?
65 Кб, 1267x743Хочу написать машину тьюринга с преферансом и куртизанками
>>44537
Ее мог купить за 1 цент какой нибудь патентный тролль, который только и ждет твоего проступка.
Ее мог купить за 1 цент какой нибудь патентный тролль, который только и ждет твоего проступка.
>>44681
Прикольно, давно читал про ленту Тьюринга, там еще показывали алгоритмы вычитания чисел (записанных азбукой морзе), и сортировку букв.
У тебя есть таймер для обнаружения проблемы останова?
Лента конечная? бгг конечно конечная, в смысла только 20 позиций или несколько гигов
Недетерменированные команды детектишь/запрещаешь? (Это когда одно условие но разные команды - можно решать перебором с бэктрекингом или расщеплением вселенных)
Отображение программы в виде конечного автомата планируется?
Прикольно, давно читал про ленту Тьюринга, там еще показывали алгоритмы вычитания чисел (записанных азбукой морзе), и сортировку букв.
У тебя есть таймер для обнаружения проблемы останова?
Лента конечная? бгг конечно конечная, в смысла только 20 позиций или несколько гигов
Недетерменированные команды детектишь/запрещаешь? (Это когда одно условие но разные команды - можно решать перебором с бэктрекингом или расщеплением вселенных)
Отображение программы в виде конечного автомата планируется?
1 Мб, 1600x900>>44688
На каждый шаг надо кликать
Длинной ленты, недетерминированных команд и отображения в виде конечного графа не планирую. Мне интереснее оказуалить в стиле пикрила.
>У тебя есть таймер для обнаружения проблемы останова?
На каждый шаг надо кликать
Длинной ленты, недетерминированных команд и отображения в виде конечного графа не планирую. Мне интереснее оказуалить в стиле пикрила.
>>44700
Если команды вводит игрок, тебе надо отслеживать, что условие уже не присутствует, выходит.
Как то жестоко. Не будет кнопки плей?
А ограничения по кол-ву ходов будут? Типа челлендж выполнить цель уровня за N ходов?
>недетерминированных команд
Если команды вводит игрок, тебе надо отслеживать, что условие уже не присутствует, выходит.
>На каждый шаг надо кликать
Как то жестоко. Не будет кнопки плей?
А ограничения по кол-ву ходов будут? Типа челлендж выполнить цель уровня за N ходов?
>>44707
Пока просто ищется первое совпадение в списке, если дальше условие повторится, то оно проигнорируется.
По поводу всех остальных улучшений. Ничего не будет, пока не появятся идеи, как сделать машину доступной для широких кругов. Классическую машину тьюринга программировать дико неудобно и не интересно.
>надо отслеживать, что условие уже не присутствует
Пока просто ищется первое совпадение в списке, если дальше условие повторится, то оно проигнорируется.
По поводу всех остальных улучшений. Ничего не будет, пока не появятся идеи, как сделать машину доступной для широких кругов. Классическую машину тьюринга программировать дико неудобно и не интересно.
>>44709
Помнишь, в одном из ТВГ была игра про робота, которого надо запрограммировать? Вот поиграй в неё, может найдёшь там идеи.
> как сделать машину доступной для широких кругов
Помнишь, в одном из ТВГ была игра про робота, которого надо запрограммировать? Вот поиграй в неё, может найдёшь там идеи.
>>44712
Не могу вспомнить, на древнем ТВГ что-ли?
Не могу вспомнить, на древнем ТВГ что-ли?
Объясните зачем нужны PackedScene, ResourceLoader, ResourceSaver и вот это вот всё. Это можно использовать для организации сейв-лоада в игре? В документации про сейв-лоад написано, что, мол, делай сериализацию и сохраняй в текстовый файл. Можно просто все ноды в сцене с их текущим состоянием (значения переменных в привязанных скриптах и всё такое прочее) тупо записать в файл как есть (tscn) и потом загрузить как сейв?
>>44787
Вопрос снят. Уже разобрался.
Вопрос снят. Уже разобрался.
>>44709
Столкнулся с такой же проблемой, пытаясь геймифицировать игру "Life" Конвея. Чтобы сделать ее похожей на типичную игру (например платформер), а не редактор где просто гоняют симуляции.
Тут ничего не поделать, кроме того, чтобы вычленить а что же именно интересно, и подавать это игроку со словами ВАУ, с горящими глазами, а не говорить что это скучно и неинтересно.
Одна из мыслей которая приходит в голову - чтобы игрок решал игру как пазл. Например, уже составлена часть программы. Давать ему только определенный набор кубиков, он должен дописать программу. Или можно двигать строчки местами. Тогда он будет получать фан от успешного решения паззлов.
Другая мысль - добавить удобство и красивости программированию. Отчасти проблема ТМ в том, что все выглядит как просто стена текста из рандомных символов. Хотя явно твой алгоритм состоит из подпрограмм: 1) сдвинуть всю строку от маркера на 1 символ вправо; (которая вызывает подпрограмму "найти первый пробел после строки символов") 2) сдвинуть первый символ после пробела влево и вставить маркер. Если их выделять в какие-то блоки (как в скретче?), подсвечивать их цветом, выносить в библиотеку откуда игрок может их вставлять - наверное намного удобнее все это будет.
>. Классическую машину тьюринга программировать дико неудобно и не интересно.
Столкнулся с такой же проблемой, пытаясь геймифицировать игру "Life" Конвея. Чтобы сделать ее похожей на типичную игру (например платформер), а не редактор где просто гоняют симуляции.
Тут ничего не поделать, кроме того, чтобы вычленить а что же именно интересно, и подавать это игроку со словами ВАУ, с горящими глазами, а не говорить что это скучно и неинтересно.
Одна из мыслей которая приходит в голову - чтобы игрок решал игру как пазл. Например, уже составлена часть программы. Давать ему только определенный набор кубиков, он должен дописать программу. Или можно двигать строчки местами. Тогда он будет получать фан от успешного решения паззлов.
Другая мысль - добавить удобство и красивости программированию. Отчасти проблема ТМ в том, что все выглядит как просто стена текста из рандомных символов. Хотя явно твой алгоритм состоит из подпрограмм: 1) сдвинуть всю строку от маркера на 1 символ вправо; (которая вызывает подпрограмму "найти первый пробел после строки символов") 2) сдвинуть первый символ после пробела влево и вставить маркер. Если их выделять в какие-то блоки (как в скретче?), подсвечивать их цветом, выносить в библиотеку откуда игрок может их вставлять - наверное намного удобнее все это будет.
239 Кб, 1675x1063Вот есть куча готовых проектов, широкая документация, но есть ли какой то обучающий проект с которого можно начать чтобы понять как пошагово делать вещи? Все эти готовые проекты же они лишь показывают как это сделать можно, но не сам процес деланья. Или я не прав?
>>44923
Официально это
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Неофициально, повторять за кем нибудь тутор на ютубе.
Официально это
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
Неофициально, повторять за кем нибудь тутор на ютубе.
>>44924
Двачую этого. Причём надо не скачивать сорцы туториала "по ссылке в описании", а натурально прям ставить на паузу видос и перепечатывать код себе. Тогда начнёт работать моторная память.
> повторять за кем нибудь тутор на ютубе
Двачую этого. Причём надо не скачивать сорцы туториала "по ссылке в описании", а натурально прям ставить на паузу видос и перепечатывать код себе. Тогда начнёт работать моторная память.
>>44928
>>44924
А может подскажите какие нибудь годные туторы?
https://www.youtube.com/watch?v=QU1pPzEGrqw
Что нибудь на подобие такого, ток по годоту, или может даже лучше чем это
>>44924
А может подскажите какие нибудь годные туторы?
https://www.youtube.com/watch?v=QU1pPzEGrqw
Что нибудь на подобие такого, ток по годоту, или может даже лучше чем это
>>44931
А ты прям по этому делай, на лету заменяя питоновое на годотовое. Щас не смогу посмотреть, ближе к вечеру напомни.
Покажу тебе на примерах, как смотреть туториал для любого другого движка и переводить его на годот.
Я таким методом смотрю туториалы по УЕЧу.
Ведь главное, не встроенные объекты движка, главное подходы, паттерны, алгоритмы, а они универсальны.
Вот тебе быстропример. Когда игрок управляет персонажем с помощью 4 стрелок, то когда он одновременно нажимает скажем вперёд и вбок, то скорее всего в контроллер вернётя вектор (1, 1), длина которого будет больше единицы, таким образом, по диагонали он будет бежать быстрее, чем просто вперёд. Таким образом, тебе надо будет нормализовать вектор в контроллере перед применением операций движения. И это актуально для всех движков. Даже если в некоторых движках есть предустановленный контроллер движения, рано или поздно ты вырастешь до написания собственного.
>>44934
Этот неплох. Попробуй еще канал GameEndeavor.
А ты прям по этому делай, на лету заменяя питоновое на годотовое. Щас не смогу посмотреть, ближе к вечеру напомни.
Покажу тебе на примерах, как смотреть туториал для любого другого движка и переводить его на годот.
Я таким методом смотрю туториалы по УЕЧу.
Ведь главное, не встроенные объекты движка, главное подходы, паттерны, алгоритмы, а они универсальны.
Вот тебе быстропример. Когда игрок управляет персонажем с помощью 4 стрелок, то когда он одновременно нажимает скажем вперёд и вбок, то скорее всего в контроллер вернётя вектор (1, 1), длина которого будет больше единицы, таким образом, по диагонали он будет бежать быстрее, чем просто вперёд. Таким образом, тебе надо будет нормализовать вектор в контроллере перед применением операций движения. И это актуально для всех движков. Даже если в некоторых движках есть предустановленный контроллер движения, рано или поздно ты вырастешь до написания собственного.
>>44934
Этот неплох. Попробуй еще канал GameEndeavor.
229 Кб, 696x588>>44931
Сижу смотрю этот туториал. С годотом большую часть того, что она там делает, можно выкинуть, ибо уже есть в движке. Например в первой части туториала, он нам показывает майнлуп и плейсхолдер будущей отрисовки на канве вручную. Ни то, ни другое нинужна. Майнлуп есть. Отрисовка есть. Он показывает заготовку карты в виде текстового массива. Нинужно. Есть тайлмапы.
Смотрю дальше.
Сижу смотрю этот туториал. С годотом большую часть того, что она там делает, можно выкинуть, ибо уже есть в движке. Например в первой части туториала, он нам показывает майнлуп и плейсхолдер будущей отрисовки на канве вручную. Ни то, ни другое нинужна. Майнлуп есть. Отрисовка есть. Он показывает заготовку карты в виде текстового массива. Нинужно. Есть тайлмапы.
Смотрю дальше.
>>44966
Дропнул просмотр. Он там реально вместо игры движок с нуля пилит. Нахуй.
Дропнул просмотр. Он там реально вместо игры движок с нуля пилит. Нахуй.
>>43886
он конечно со странностями в виде вкусовщины, но пока еще самый быстрый актуальный скриптовый язык с его jit-ом
> подсунут свинью в виде всратого lua
он конечно со странностями в виде вкусовщины, но пока еще самый быстрый актуальный скриптовый язык с его jit-ом
>>44979
Хватит разглагольствовать. Покажи нам мастер класс на луа
https://github.com/gilzoide/godot-lua-pluginscript
Хватит разглагольствовать. Покажи нам мастер класс на луа
https://github.com/gilzoide/godot-lua-pluginscript
145 Кб, 1196x827>>44983
Я ебал кодить без дебага. До чего люблю луа, если бы можно было на нём годотить, было б вообще супер. Но оно в таком вот статусе уже года два.
Я ебал кодить без дебага. До чего люблю луа, если бы можно было на нём годотить, было б вообще супер. Но оно в таком вот статусе уже года два.
какими инструментами пользуетесь для встраивания SDK всяких HTML5 порталов (yandex, VK...) ?
Нашел такую штуку, но она вроде только на godot 3 пока работает
https://github.com/instant-games-bridge/instant-games-bridge-godot
Нашел такую штуку, но она вроде только на godot 3 пока работает
https://github.com/instant-games-bridge/instant-games-bridge-godot
>>45051
Никакими, славбгу.
Так 4 еще и не вышел, да там и html5 не до конца вылизан еще.
>HTML5 порталов (yandex, VK...)
Никакими, славбгу.
>она вроде только на godot 3
Так 4 еще и не вышел, да там и html5 не до конца вылизан еще.
>>42889
Сто раз уже обесняли. Гдскрипт нужен для прототипирования. Чтобы не отвлекаясь на альттаб, внутри одного редактора, в порыве вдохновения ебашить прототип игры. Для джемов хорош. Для несложных задачек по фану.
Затем, ты переписываешь код на сях, или, с версии 3 на шарпе. Только после этого игра годна в продакшен.
Пожалуй, надо это в шапку вынести.
> На реддите выяснили что GDScript слишком медленный для создания реальных игр
Сто раз уже обесняли. Гдскрипт нужен для прототипирования. Чтобы не отвлекаясь на альттаб, внутри одного редактора, в порыве вдохновения ебашить прототип игры. Для джемов хорош. Для несложных задачек по фану.
Затем, ты переписываешь код на сях, или, с версии 3 на шарпе. Только после этого игра годна в продакшен.
Пожалуй, надо это в шапку вынести.
>>45127 (Del)
Прототипирование и продакшен две разные вещи. Обычно код прототипа, когда понятно что и как должно быть, просто выкидывается. Смысл GDScript в быстрых итерациях. В УЕче точно так же принято - нафигачить лапши на блюпринтах и когда понятно что к чему - переписать на плюсах.
>>45083
Можно ещё находить критические и медленные части и переписывать только их.
Прототипирование и продакшен две разные вещи. Обычно код прототипа, когда понятно что и как должно быть, просто выкидывается. Смысл GDScript в быстрых итерациях. В УЕче точно так же принято - нафигачить лапши на блюпринтах и когда понятно что к чему - переписать на плюсах.
>>45083
Можно ещё находить критические и медленные части и переписывать только их.
>>45131
лишь в самых крупнх студиях
> Обычно код прототипа, когда понятно что и как должно быть, просто выкидывается
лишь в самых крупнх студиях
>>45158
В инди переписывается еще больше.
В инди переписывается еще больше.
2,2 Мб, mp4,1280x720, 0:32
вот, сделал простенький контроллер персонажа и механику телепортера (как в майнкрафте), не уверен, что сделал его лучшим способом, но в целом мне нравится
>>45252
Поздравляю. 1% игры сделал. Теперь остальные 99%.
Поздравляю. 1% игры сделал. Теперь остальные 99%.
659 Кб, webm,1280x720, 1:37
Пилю убийцу Vampire Survivors на Godot'е.
Понаблюдать можно на мелкоборде:
https://mboard.tk/b/thread/100855/
Пока сделал мобам выбор целей, перемещение, переключение анимации (атака, ходить, стоять, себя показать) и некоторые эффекты дебафов. Спрайты временные. Когда/если закончу с кодом, буду красивые спрайтики рисовать. Но сначала хочу геймплей запилить.
Вооот....
Понаблюдать можно на мелкоборде:
https://mboard.tk/b/thread/100855/
Пока сделал мобам выбор целей, перемещение, переключение анимации (атака, ходить, стоять, себя показать) и некоторые эффекты дебафов. Спрайты временные. Когда/если закончу с кодом, буду красивые спрайтики рисовать. Но сначала хочу геймплей запилить.
Вооот....
>>45317
ножом
ножом
Ля, какие варианты монетизации для годотанов щас актуальны на андроидомобилочках?
можно ли как-то в JavaScript.eval() впихнуть код с переносами и табами или его нужно форматировать обязательно в одну строку?
Скоро не надо будет самостоятельно код писать, достаточно будет нейронке давать текстовое описание.
https://www.youtube.com/watch?v=ntQLEdh_2hk
https://www.youtube.com/watch?v=ntQLEdh_2hk
4 Кб, 129x46>>45645
Во-первых пикрелейтед, твои дейтвия?
Во-вторых ебло с видоса даже код не попробовал, шейдер может выглядит как говно фром жопа.
Во-первых пикрелейтед, твои дейтвия?
Во-вторых ебло с видоса даже код не попробовал, шейдер может выглядит как говно фром жопа.
>>45645
Мы ИТТ ждём только релиз четвёрки. Ждём и готовимся.
А когда релизнется, будем ждать 4.1 кекек
> Скоро
> надо только подождать
Мы ИТТ ждём только релиз четвёрки. Ждём и готовимся.
А когда релизнется, будем ждать 4.1 кекек
пусть есть глобальный скрипт с именем global в аатозагрузке
в нем объявлен сигнал signal sig_name
сам этот глобальный скрипт естественно extends Node
также в нем есть функция TEST(), которая делает только emit_signal("sig_name")
создаю сцену, в ней создаю кнопку, на нажатие которой вызываю TEST() - это работает
тв ней же создаю функцию func_name(), которая просто принт делает
в _ready() этой кнопки прописываю global.connect("sig_name", self, "func_name") - имена "sig_name" и "func_name" видит и сам предлагает подставлять, но функция не отрабатывает, т.к. принта не вижу
сигнал же можно коннектить просто к скрипту-синглтону?
в нем объявлен сигнал signal sig_name
сам этот глобальный скрипт естественно extends Node
также в нем есть функция TEST(), которая делает только emit_signal("sig_name")
создаю сцену, в ней создаю кнопку, на нажатие которой вызываю TEST() - это работает
тв ней же создаю функцию func_name(), которая просто принт делает
в _ready() этой кнопки прописываю global.connect("sig_name", self, "func_name") - имена "sig_name" и "func_name" видит и сам предлагает подставлять, но функция не отрабатывает, т.к. принта не вижу
сигнал же можно коннектить просто к скрипту-синглтону?
101 Кб, 702x914>>45675
Написал по твоему описанию, все работает.
Смотри может где перепутал Названия_функций.
Проверяй что возвращает connect (там warning не просто так)
Написал по твоему описанию, все работает.
Смотри может где перепутал Названия_функций.
Проверяй что возвращает connect (там warning не просто так)
>>45675
Параметров у сигнала нет? Если есть, то должны совпадать.
Имею в виду
emit_signal("sig_name", [data])
...
func func_name()
и
emit_signal("sig_name")
...
func func_name(param1)
выдадут ошибку.
Параметров у сигнала нет? Если есть, то должны совпадать.
Имею в виду
emit_signal("sig_name", [data])
...
func func_name()
и
emit_signal("sig_name")
...
func func_name(param1)
выдадут ошибку.
там один внешний SDK требует в свой метод объект JS
я создаю в скрипте
var player_data = {
"money" : 5
}
отсылаю ему to_json(player_data) а он мне говорит, что не валидный объект, нужно хитрее отправлять?
я создаю в скрипте
var player_data = {
"money" : 5
}
отсылаю ему to_json(player_data) а он мне говорит, что не валидный объект, нужно хитрее отправлять?
>>45737
Хз по докам вроде так
a = { "a": 1, "b": 2 }
b = to_json(a)
print(b) # {"a":1, "b":2}
Сам не проверял
Хз по докам вроде так
a = { "a": 1, "b": 2 }
b = to_json(a)
print(b) # {"a":1, "b":2}
Сам не проверял
>>45737
дополняю..
вроде как я понял в godot нужно создать что-то типа такого
var player_data = JavaScript.create_object(...)
только пока не очень понял, что там в скобках нужно пихать, чтобы из этого key-value сформировалось
в примерах создают типа массив JavaScript.create_object("Array", 5)
и в него пихают
player_data[0] = 22
дополняю..
вроде как я понял в godot нужно создать что-то типа такого
var player_data = JavaScript.create_object(...)
только пока не очень понял, что там в скобках нужно пихать, чтобы из этого key-value сформировалось
в примерах создают типа массив JavaScript.create_object("Array", 5)
и в него пихают
player_data[0] = 22
>>45741
Это: https://docs.godotengine.org/en/stable/classes/class_javascriptobject.html#class-javascriptobject
Напрямую нельзя работать с объектами жс. Если хочешь красиво-объектно, сначала придется напилить классы-обёртки.
> что там в скобках нужно пихать
Это: https://docs.godotengine.org/en/stable/classes/class_javascriptobject.html#class-javascriptobject
Напрямую нельзя работать с объектами жс. Если хочешь красиво-объектно, сначала придется напилить классы-обёртки.
>>45831
этот пример тоже видел, да мне красивость и не особо нужна тут, просто принцип бы понять
у меня есть внешний SDK платформы с методами get_data() и set_data(data), data - это объект, содержащий пары ключ-значение
вот мне нужно в скрипте godot как-то это создать, менять во время работы приложения и потом передавать уже в это во внешнее api через set_data(data)
а потом получать через get_data(), а там пишут, что возвращают это не объектом, а промисом, тут тоже не очень понятно как мне это преобразовывать
этот пример тоже видел, да мне красивость и не особо нужна тут, просто принцип бы понять
у меня есть внешний SDK платформы с методами get_data() и set_data(data), data - это объект, содержащий пары ключ-значение
вот мне нужно в скрипте godot как-то это создать, менять во время работы приложения и потом передавать уже в это во внешнее api через set_data(data)
а потом получать через get_data(), а там пишут, что возвращают это не объектом, а промисом, тут тоже не очень понятно как мне это преобразовывать
>>45842
Принцип классический, как и в любой гетерогенной системе до этого.
У тебя есть две системы, никак между собой не связанные, назовём их А (жаваскрипт) и Б (гдскрипт). Ты хочешь из Б обращаться к А, совершать действия и получать данные. В системе А имеется АПИ для совершения таких действий из сторонних объектов. А вот теперь важно. Поскольку сторонняя система ничего не знает о внутренней кухне, то в АПИ введены функции для создания внутренних объектов. Возвращают эти функции исключительно указатели на созданные объекты, эти указатели ты передаёшь в другие управляющие функции.
Всегда ищи такие функции в любом АПИ. И всегда их найдёшь. Приведу пример в псевдокоде:
Функция создания объекта: создать_объект(тип, параметры_конструктора) в случае с гдскриптом, тип передаётся в виде строкового названия, тебе нужно обратиться к документации джаваскрипта и узнать, какие названия типов тебе доступны. Параметры конструктора в документации годота не указаны явно, просто написано vararg, минус документерам. Они полагали, что читатель это уже знает, что все остальные аргументы, это аргументы, предназначенные для конструктора внутри джаваскрипта.
И вот ты создал объект.
объект = А.создать_объект("ЖабаОбъект", 0, 0, 12, 17, 21, 5, 37)
А чо дальше?
А дальше ты переменную с указателем на этот объект подставляешь дальше в АПИ внешней системы:
А.залогиниться_на_сервере("логин", "пароль", объект) там происходит логин на сервере и статус операции написан у объекта типа жаба, который ты передал аргументом, но как я сказал выше, у тебя нет доступа к полям и методам объекта, но ты ищешь и находишь АПИ:
А.статус_подключения(объект) и уже тут тебе возвращается годот-строка с надписью "неверный пароль" или "подключено".
И всё это пиздец как неудобно, и для удобства пишут обёртки, где у тебя есть годот-нода "жаба", у которой есть нужные методы, у которой в инит создаётся и удерживается ссылка на внешний объект, а в методах дёргаются внешние АПИ.
> просто принцип бы понять
Принцип классический, как и в любой гетерогенной системе до этого.
У тебя есть две системы, никак между собой не связанные, назовём их А (жаваскрипт) и Б (гдскрипт). Ты хочешь из Б обращаться к А, совершать действия и получать данные. В системе А имеется АПИ для совершения таких действий из сторонних объектов. А вот теперь важно. Поскольку сторонняя система ничего не знает о внутренней кухне, то в АПИ введены функции для создания внутренних объектов. Возвращают эти функции исключительно указатели на созданные объекты, эти указатели ты передаёшь в другие управляющие функции.
Всегда ищи такие функции в любом АПИ. И всегда их найдёшь. Приведу пример в псевдокоде:
Функция создания объекта: создать_объект(тип, параметры_конструктора) в случае с гдскриптом, тип передаётся в виде строкового названия, тебе нужно обратиться к документации джаваскрипта и узнать, какие названия типов тебе доступны. Параметры конструктора в документации годота не указаны явно, просто написано vararg, минус документерам. Они полагали, что читатель это уже знает, что все остальные аргументы, это аргументы, предназначенные для конструктора внутри джаваскрипта.
И вот ты создал объект.
объект = А.создать_объект("ЖабаОбъект", 0, 0, 12, 17, 21, 5, 37)
А чо дальше?
А дальше ты переменную с указателем на этот объект подставляешь дальше в АПИ внешней системы:
А.залогиниться_на_сервере("логин", "пароль", объект) там происходит логин на сервере и статус операции написан у объекта типа жаба, который ты передал аргументом, но как я сказал выше, у тебя нет доступа к полям и методам объекта, но ты ищешь и находишь АПИ:
А.статус_подключения(объект) и уже тут тебе возвращается годот-строка с надписью "неверный пароль" или "подключено".
И всё это пиздец как неудобно, и для удобства пишут обёртки, где у тебя есть годот-нода "жаба", у которой есть нужные методы, у которой в инит создаётся и удерживается ссылка на внешний объект, а в методах дёргаются внешние АПИ.
>>45831
to_json() возвращает строковое представление "{"money": 5, "data": abc}" - это system agnostic.
to_json() возвращает строковое представление "{"money": 5, "data": abc}" - это system agnostic.
67 Кб, 670x605Хотел сделать переменные width и height, которые можно менять только в редакторе. Для этого сделал скрипт тулом и написал сеттер, в котором проверяется, в редакторе ли выполняется код, и если нет, то не менять размер. Но не проканало, так как при запуске все равно сеттер вызывается (видимо чтобы присвоить то значение, которое в инспекторе было введено), ничего не делает (потому что условие такое), и в итоге имеем размер по умолчанию 5x5 всегда, что бы ни написали в инспекторе.
Вопрос, как сделать переменные, которые можно менять только в редакторе?
Вопрос, как сделать переменные, которые можно менять только в редакторе?
>>46081
Ну, сам я додумался до второго решения (завести флаг инициализации) отсюда
https://stackoverflow.com/questions/73906909/avoid-invoking-setget-function-on-starting-up
Первое выглядит более официально - завести два поля, одно видимо только в редакторе, второе только в игре.
Ну, сам я додумался до второго решения (завести флаг инициализации) отсюда
https://stackoverflow.com/questions/73906909/avoid-invoking-setget-function-on-starting-up
Первое выглядит более официально - завести два поля, одно видимо только в редакторе, второе только в игре.
1,4 Мб, 1316x1554Как мне нормально повернуть объект на кривой поверхности юзая нормали? А-ля пикрил. Т.е. есть позиция глобальная, в которой он должен находиться, есть нормаль вылетающая из поверхности в этой точке и сопсно сам объект в каком-то относительно повернутом положении, в котором он должен оказаться с новом месте.
Я чёт заебался тупить, то объект не крутится, то углы не те, то углы те, но по другой оси.
Я чёт заебался тупить, то объект не крутится, то углы не те, то углы те, но по другой оси.
76 Кб, 281x180>>46126
Вроде то шо нуно.
Вроде то шо нуно.
>>46113
Вот бы Хуан на уровне синтаксиса ГДскрипта такое добавил
>одно видимо только в редакторе, второе только в игре
Вот бы Хуан на уровне синтаксиса ГДскрипта такое добавил
125 Кб, 1023x991Бумп новой жизни во вселенной
>>46271
Вот тебе пример на питоне, 5 сек гугла
https://ru.stackoverflow.com/questions/1111439/%D0%9D%D1%83%D0%B6%D0%BD%D0%BE-%D1%80%D0%B0%D1%81%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D0%B8%D1%82%D1%8C-%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D1%83-%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BC%D0%B0%D1%81%D1%81%D0%B8%D0%B2%D0%B0
В гдскрипт сам переведешь.
Это же так просто, как говорят, знаешь питон - сможешь и в гдскрипт.
Вот тебе пример на питоне, 5 сек гугла
https://ru.stackoverflow.com/questions/1111439/%D0%9D%D1%83%D0%B6%D0%BD%D0%BE-%D1%80%D0%B0%D1%81%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D0%B8%D1%82%D1%8C-%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D1%83-%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BC%D0%B0%D1%81%D1%81%D0%B8%D0%B2%D0%B0
В гдскрипт сам переведешь.
Это же так просто, как говорят, знаешь питон - сможешь и в гдскрипт.
114 Кб, 1023x991>>46291
Появились новые идеи и я решил поиграться с программой, которая узор делает, но вот беда, она медленная
И у меня два варианта
Шейдеры и видяха
Потоки процессора
Проблема в том, что у меня есть два массива, в первом исходные данные, а во второй пишется среднее значение цветов, которые вокруг текущего, включая его. И вот подозреваю, что выполнить параллельно это невозможно, потому всё это созависимо
Как я это вижу
Дробим массив, он одномерный, на энное количество потоков, сколько есть у процессора, и запустить такую вот операцию с кусочком второго массива на каждом потоке и читать данные из целого первого
Чего меня смущает
Доступ на чтение к первому массиву, он не может быть параллельным
Доступ на запись к кусочку второго массива, это ведь блок памяти и не факт, что тут тоже получится это распараллелить
Видеократа те же проблемы, мне тут отвечали как можно получить доступ к элементам вокруг элемента в двухмерном массиве
Как-то так
>>46292
Посмотрел, там нету разрешения вышеописанной проблемы, но я и не уточнял, так что сойдёт. Примеры по годо тоже уже поискал, но не пробовал
Хочу чтобы это всё быстрее рисовалось и в большем разрешении
Появились новые идеи и я решил поиграться с программой, которая узор делает, но вот беда, она медленная
И у меня два варианта
Шейдеры и видяха
Потоки процессора
Проблема в том, что у меня есть два массива, в первом исходные данные, а во второй пишется среднее значение цветов, которые вокруг текущего, включая его. И вот подозреваю, что выполнить параллельно это невозможно, потому всё это созависимо
Как я это вижу
Дробим массив, он одномерный, на энное количество потоков, сколько есть у процессора, и запустить такую вот операцию с кусочком второго массива на каждом потоке и читать данные из целого первого
Чего меня смущает
Доступ на чтение к первому массиву, он не может быть параллельным
Доступ на запись к кусочку второго массива, это ведь блок памяти и не факт, что тут тоже получится это распараллелить
Видеократа те же проблемы, мне тут отвечали как можно получить доступ к элементам вокруг элемента в двухмерном массиве
Как-то так
>>46292
Посмотрел, там нету разрешения вышеописанной проблемы, но я и не уточнял, так что сойдёт. Примеры по годо тоже уже поискал, но не пробовал
Хочу чтобы это всё быстрее рисовалось и в большем разрешении
813 Кб, webm,960x540, 0:24
>>46301
С плюсами знаком, похожее делал с OpenGL, но как же утомительно создавать основу в виде окна и базовых классов, да, надо один раз, но что-то у меня это глохло
До этого был второй опен и свободный глут
Вобщем я посыл понял, придётся снова туда или пробовать на шейдерах
И да, а на С++ такое провернуть легче? Из того, что использовал это потешное pragma parallel перед циклами
С плюсами знаком, похожее делал с OpenGL, но как же утомительно создавать основу в виде окна и базовых классов, да, надо один раз, но что-то у меня это глохло
До этого был второй опен и свободный глут
Вобщем я посыл понял, придётся снова туда или пробовать на шейдерах
И да, а на С++ такое провернуть легче? Из того, что использовал это потешное pragma parallel перед циклами
>>46303
Так ты просто накидываешь модуль для движка с алгоритмом и в нем распараллеливаешь любым понравившимся способом
Так ты просто накидываешь модуль для движка с алгоритмом и в нем распараллеливаешь любым понравившимся способом
>>46303
потоки, если через скрипты пробовать будешь
https://docs.godotengine.org/ru/stable/tutorials/performance/threads/using_multiple_threads.html#doc-using-multiple-threads
потоки, если через скрипты пробовать будешь
https://docs.godotengine.org/ru/stable/tutorials/performance/threads/using_multiple_threads.html#doc-using-multiple-threads
147 Кб, 920x907>>46296
Потоки процессора работают, просто передаешь разные дипазоны массива.
Алсо, можно написать модуль на с++, хехе.
Потоки процессора работают, просто передаешь разные дипазоны массива.
Алсо, можно написать модуль на с++, хехе.
123 Кб, 1023x991>>46310
Можно еще сам алгоритм ускорить, но это думать надо.
Я читал, что Game of Life ускоряют октодеревьями + хэшами позиций (примерно как битборды в шахматных программах).
Октотри тут помогает тем, что у тебя половина экрана пустая, и по идее если записи в некий квадрат не было, алгоритм сразу знает что там не надо делать апдейты
А хэши - это предпосчитанные квадратные блоки "до" и "после", это на случай, когда в байт может влезть больше одного пикселя (например если у тебя 4 цвета, то это 2 бита, 4 точки на байт.)
https://en.wikipedia.org/wiki/Hashlife
https://www.youtube.com/watch?v=l228ARRYkNE
Сам я такое правда не писал.
Можно еще сам алгоритм ускорить, но это думать надо.
Я читал, что Game of Life ускоряют октодеревьями + хэшами позиций (примерно как битборды в шахматных программах).
Октотри тут помогает тем, что у тебя половина экрана пустая, и по идее если записи в некий квадрат не было, алгоритм сразу знает что там не надо делать апдейты
А хэши - это предпосчитанные квадратные блоки "до" и "после", это на случай, когда в байт может влезть больше одного пикселя (например если у тебя 4 цвета, то это 2 бита, 4 точки на байт.)
https://en.wikipedia.org/wiki/Hashlife
https://www.youtube.com/watch?v=l228ARRYkNE
Сам я такое правда не писал.
>>46100
ну вроде веб уже норм работает, сейчас для теста катнули пару проектов, только движок пока распух с 14 до 27 мб, но это мелочи
> Бета 10
ну вроде веб уже норм работает, сейчас для теста катнули пару проектов, только движок пока распух с 14 до 27 мб, но это мелочи
1,6 Мб, webm,960x540, 0:30
По примеру кода с использованием многопотока в годо с гд скриптом переделал код, стало бодрее, но увы, даже 32 потока значительно ситуацию не улучшило
Вместо 144 на 144 стало 320 на 320 быстрой обработки
Дальше попробую уже с использованием C++
Но всё равно интересно, изначально я хотел волны сэмитировать
Вместо 144 на 144 стало 320 на 320 быстрой обработки
Дальше попробую уже с использованием C++
Но всё равно интересно, изначально я хотел волны сэмитировать
16 Кб, 820x190Поставил шарповую версию движка, поставил .NET SDK (битности совпадают)
При сборке пишет:
C:\Users\<user>\.nuget\packages\godot.net.sdk\3.3.0\Sdk\Sdk.props(29,11): не удалось найти указанный пакет SDK "Microsoft.NET.Sdk".
пакет вроде на месте
При сборке пишет:
C:\Users\<user>\.nuget\packages\godot.net.sdk\3.3.0\Sdk\Sdk.props(29,11): не удалось найти указанный пакет SDK "Microsoft.NET.Sdk".
пакет вроде на месте
>>46380
да и ладно, не в каждом проекте и требуются, тем более работать над проектом тоже не мешает
> Теней в опенжл3 пока нет
да и ладно, не в каждом проекте и требуются, тем более работать над проектом тоже не мешает
8 Кб, 352x113>>41833 (OP)
У меня тут небольшой вопросик. Я не пойму, как работает duplicate у массива? По идеи, он должен давать копию исходного массива, но почему он просто дает ссылку на него? Или я что-то не понимаю?
Вот есть такой код, он, вроде как, должен менять только массив _enemy, не трогая enemy, но он меняет массив enemy
У меня тут небольшой вопросик. Я не пойму, как работает duplicate у массива? По идеи, он должен давать копию исходного массива, но почему он просто дает ссылку на него? Или я что-то не понимаю?
Вот есть такой код, он, вроде как, должен менять только массив _enemy, не трогая enemy, но он меняет массив enemy
>>46401
Он работает так:
Если deep = false, дуплицируется только внешний слой массива, а все внутренние сылочные типы остаются ссылками на исходные данные.
Если deep = true, дуплицируется рекурсивно всё содержимое массива, включая вложенные массивы, словари, объекты, то есть все ссылочные типы.
> как работает duplicate(bool deep)
Он работает так:
Если deep = false, дуплицируется только внешний слой массива, а все внутренние сылочные типы остаются ссылками на исходные данные.
Если deep = true, дуплицируется рекурсивно всё содержимое массива, включая вложенные массивы, словари, объекты, то есть все ссылочные типы.
>>46401
Я ещё раз внимательно пересмотрел твой скрин с кодом и сдаётся мне, ты лепишь какой-то тормозной велосипед. Зачем ты хранишь списки врагов в массивах, которые потом медленно перебираешь, удаляя удалённых, если годот всё это делает автоматически внутри дерева нод? Просто заведи себе ноду Enemies, в которую добавляй каждого нового enemy и при его самоуничтожении, он сам себчя удалит из списка чайлдов этой ноды. Так же в годоте есть группы. Ты можешь каждого enemy добавлять в определённую тобой группу, а потом опрашивать эту группу, производя нужные действия со всеми членами группы, и это будет происходить не в гдскрипте, а внутри годота, в его сишных потрохах.
Если тебе нужно держать матрицу(двумерный массив) то есть великолепная формула, позволяющая выводить одномерный массив в виде матрицы и обратно, из двумерных координат получать индекс в одномерном массиве. Выписываешь себе в скрипт две функции перевода координат в индекс и обратно и не паришься.
Я ещё раз внимательно пересмотрел твой скрин с кодом и сдаётся мне, ты лепишь какой-то тормозной велосипед. Зачем ты хранишь списки врагов в массивах, которые потом медленно перебираешь, удаляя удалённых, если годот всё это делает автоматически внутри дерева нод? Просто заведи себе ноду Enemies, в которую добавляй каждого нового enemy и при его самоуничтожении, он сам себчя удалит из списка чайлдов этой ноды. Так же в годоте есть группы. Ты можешь каждого enemy добавлять в определённую тобой группу, а потом опрашивать эту группу, производя нужные действия со всеми членами группы, и это будет происходить не в гдскрипте, а внутри годота, в его сишных потрохах.
Если тебе нужно держать матрицу(двумерный массив) то есть великолепная формула, позволяющая выводить одномерный массив в виде матрицы и обратно, из двумерных координат получать индекс в одномерном массиве. Выписываешь себе в скрипт две функции перевода координат в индекс и обратно и не паришься.
>>46401
Добавлю к анону выше, что ты пишешь какой-то велосипед.
Во-первых, в гдскрипте у массива есть метод remove или erase, который наверняка быстрее удаляет элемент из середины (просто потому что там в с++ какой-нибудь memmove, а не цикл на гдскрипте).
[1,3,5,7,9].remove(1) => [1,5,7,9] добавить пустое место в конце тривиально push_back(null)
[obj3, obj1, obj2].erase(obj3) => [obj1, obj2]
Во-вторых, присмотрись к концепции object pool, когда у тебя массив фиксированного размера, скажем на 20 врагов, и ты в нем никогда не двигаешь никакие элементы, а просто выдаешь новым врагам пустые слоты.
Добавлю к анону выше, что ты пишешь какой-то велосипед.
Во-первых, в гдскрипте у массива есть метод remove или erase, который наверняка быстрее удаляет элемент из середины (просто потому что там в с++ какой-нибудь memmove, а не цикл на гдскрипте).
[1,3,5,7,9].remove(1) => [1,5,7,9] добавить пустое место в конце тривиально push_back(null)
[obj3, obj1, obj2].erase(obj3) => [obj1, obj2]
Во-вторых, присмотрись к концепции object pool, когда у тебя массив фиксированного размера, скажем на 20 врагов, и ты в нем никогда не двигаешь никакие элементы, а просто выдаешь новым врагам пустые слоты.
>>46418
Спасибо.
>>46419
>>46421
У меня там двумерный массив, который изображает игровое поле и мне просто нужно передвинуть врага вперед на клетку, если она свободна и так, пока он не упрется в другого врага или конец поля. Но у меня задача не передвинуть врага физически, а всего лишь получить данные, как будет выглядеть игровое поле, если они передвинуться. При этом мне не надо удалять элементы, мне нужно именно указывать, что ячейка пустая.
Спасибо.
>>46419
>>46421
У меня там двумерный массив, который изображает игровое поле и мне просто нужно передвинуть врага вперед на клетку, если она свободна и так, пока он не упрется в другого врага или конец поля. Но у меня задача не передвинуть врага физически, а всего лишь получить данные, как будет выглядеть игровое поле, если они передвинуться. При этом мне не надо удалять элементы, мне нужно именно указывать, что ячейка пустая.
>>46471
Ну всё равно реализовать то же самое через одномерный массив проще и эффективнее. Ты же точно знаешь размеры игрового поля, которое собираешься потестировать на следующий ход.
Кроме того, тебе в эту тестовую матрицу не нужно дуплицировать реальные объекты. Ведь тебе то от объектов на их местах нужны не они сами, а их типы и их свойства. Вот и создавай массив из данных, которые ты возьмёшь у объектов, опросив их. Таким образом, я бы на твоём месте сделал что-то типа этого:
func get_next_turn_coord(Obj: Node): if Obj.is_in_group("Enemies"): return Obj.get_next_coord_if_my_turn_else_current_coord()
func create_next_turn_positions():
____ var result = []
____ for x in GameField.Columns:
________ for y in GameField.Rows:
____________ var cell = GameField.get_cell(x,y)
____________ if cell != null:
________________ result.append(get_next_turn_coord(cell))
____________ else:
________________ result.append(Vector2.ZERO)
Вот как-то так. У тебя будет массив, легкий, шустрый, с одними векторами, к которому ты сможешь легко применить игровые правила. Если вектор нулевой, то нет объекта, либо объект не движется, если в ячейке массива есть ненулевой вектор, то вот на координаты в этом векторе из этой ячейки объект переместится.
> задача не передвинуть врага физически, а всего лишь получить данные, как будет выглядеть игровое поле, если они передвинуться
Ну всё равно реализовать то же самое через одномерный массив проще и эффективнее. Ты же точно знаешь размеры игрового поля, которое собираешься потестировать на следующий ход.
Кроме того, тебе в эту тестовую матрицу не нужно дуплицировать реальные объекты. Ведь тебе то от объектов на их местах нужны не они сами, а их типы и их свойства. Вот и создавай массив из данных, которые ты возьмёшь у объектов, опросив их. Таким образом, я бы на твоём месте сделал что-то типа этого:
func get_next_turn_coord(Obj: Node): if Obj.is_in_group("Enemies"): return Obj.get_next_coord_if_my_turn_else_current_coord()
func create_next_turn_positions():
____ var result = []
____ for x in GameField.Columns:
________ for y in GameField.Rows:
____________ var cell = GameField.get_cell(x,y)
____________ if cell != null:
________________ result.append(get_next_turn_coord(cell))
____________ else:
________________ result.append(Vector2.ZERO)
Вот как-то так. У тебя будет массив, легкий, шустрый, с одними векторами, к которому ты сможешь легко применить игровые правила. Если вектор нулевой, то нет объекта, либо объект не движется, если в ячейке массива есть ненулевой вектор, то вот на координаты в этом векторе из этой ячейки объект переместится.
>>46476
Ах ты ж блять. Пока выписывал код, мысль ушла далеко вперёд. Исправляюсь:
У объектов указанной группы нужно будет сделать метод, который возвращает значение согласно описанию: выдаёт следующие свои координаты, если сейчас его ход, иначе выдаёт нулевой вектор (а не текущие координаты, как я написал изначально).
Ах ты ж блять. Пока выписывал код, мысль ушла далеко вперёд. Исправляюсь:
> func get_next_turn_coord(Obj: Node): if Obj.is_in_group("Enemies"): return Obj.get_next_coord_if_my_turn_else_zero_vec2()
У объектов указанной группы нужно будет сделать метод, который возвращает значение согласно описанию: выдаёт следующие свои координаты, если сейчас его ход, иначе выдаёт нулевой вектор (а не текущие координаты, как я написал изначально).
>>46476
Это все, конечно, хорошо, но у меня там хранятся не ноды и игровое поле немного не такое, каким ты его представляешь. Собственно, я не буду расписывать, как там все, но твой вариант не подходит.
Это все, конечно, хорошо, но у меня там хранятся не ноды и игровое поле немного не такое, каким ты его представляешь. Собственно, я не буду расписывать, как там все, но твой вариант не подходит.
Я тут посмотрел видео от 3blue1brown https://www.youtube.com/watch?v=KuXjwB4LzSA
И так чувствую, что анону >>46296 могло бы пригодиться знание матана. FFT туда, там проделать простую операцию, FFT обратно - это быстрее и лучше, чем искать способ распараллелить операции с двумя массивами.
И так чувствую, что анону >>46296 могло бы пригодиться знание матана. FFT туда, там проделать простую операцию, FFT обратно - это быстрее и лучше, чем искать способ распараллелить операции с двумя массивами.
>>46480
Но как же мы тогда тебе поможем? Чего ты от нас-то хочешь?
> я не буду расписывать, как там все
Но как же мы тогда тебе поможем? Чего ты от нас-то хочешь?
>>46486
Я хотел спросить, почему duplicate не работает. Я ответ получил.
Остальное уже вы сами начали, я в этом помощи не просил
Я хотел спросить, почему duplicate не работает. Я ответ получил.
Остальное уже вы сами начали, я в этом помощи не просил
>>46497
Я хочу, чтобы ты сделал игру, и я в неё поиграл. Из того скриншота, что я увидел, я увидел неиллюзорную вероятность того, что твоя игра утонет в производственном аду через пару недель, и я в неё не поиграю. В моих интересах помочь тебе сразу грамотную архитектуру заложить в проект, а не изобретать велосипеды.
Я хочу, чтобы ты сделал игру, и я в неё поиграл. Из того скриншота, что я увидел, я увидел неиллюзорную вероятность того, что твоя игра утонет в производственном аду через пару недель, и я в неё не поиграю. В моих интересах помочь тебе сразу грамотную архитектуру заложить в проект, а не изобретать велосипеды.
>>46505
И как это применимо ко мне? Вы свои теорию, видимо, строите только на основе того, что у меня массивы названы "enemy". Потому что один начал говорить, что я удаляю удаленных враговхотя я это не делаю, другой предлагал удалять мне средний элемент, хотя тоже непонятно, зачем мне это, если я не удаляю средний элемент.
>>46501
Буквально, все то, что мне нужно это получить тот же массив, с теми же размерами, но сдвинутый, чтобы уже дальше, на основе него, производить действия. Всё.
И как это применимо ко мне? Вы свои теорию, видимо, строите только на основе того, что у меня массивы названы "enemy". Потому что один начал говорить, что я удаляю удаленных враговхотя я это не делаю, другой предлагал удалять мне средний элемент, хотя тоже непонятно, зачем мне это, если я не удаляю средний элемент.
>>46501
Буквально, все то, что мне нужно это получить тот же массив, с теми же размерами, но сдвинутый, чтобы уже дальше, на основе него, производить действия. Всё.
>>46465
спасибо, кэп
спасибо, кэп
сап, геймдевелоперы, подскажите по вашей дрочильне, ветка latest в доках включает изменения/дополнения в 4.0 бетах или мне надо будет все репорты перечитывать, чтобы понять, кк что изменилось с каждой альфы/беты?
>>47753
Сложно сказать. Это же в разработке, наверняка где-то и не успевают документацию обновить.
Сложно сказать. Это же в разработке, наверняка где-то и не успевают документацию обновить.
а для три-в-ряд лучше использовать просто спрайты движущиеся или есть что-то как для платформеров более удобное вроде tilemap?
>>48205
Есть в годо изначально и подобное в использовании, возможно, что есть даже видосы создания такой игры
> tilemap
Есть в годо изначально и подобное в использовании, возможно, что есть даже видосы создания такой игры
>>48220
Что не так? Ты спросил про наличие tilemap, он есть и его можно использовать для три в ряд
Что не так? Ты спросил про наличие tilemap, он есть и его можно использовать для три в ряд
>>48222
в нем есть плавное перемещение тайла с одной клетки на другую?
иначе смысла нет тащить tilemap, он хорошо когда статичный уровень формируешь для платформера, карту для какой-нибудь пошаговой стратегии, а тут большая часть объектов - это сами интерактивные объекты, где фон по сути одинаковая сетка
в нем есть плавное перемещение тайла с одной клетки на другую?
иначе смысла нет тащить tilemap, он хорошо когда статичный уровень формируешь для платформера, карту для какой-нибудь пошаговой стратегии, а тут большая часть объектов - это сами интерактивные объекты, где фон по сути одинаковая сетка
>>48205
В подобных случаях использую спрайты для плавного движения + невидимый тайлмап для вычисления координат и кликов мышкой.
Индивидуальные ячейки, вроде, нельзя было двигать, а главное для меня критично - нельзя перекрашивать (только тайл в тайлсете, то есть применяется ко всей карте, а не ячейке). Может быть в 4 это переделали получше.
Надо будет в 4 посмотреть, может там уже есть это все.
В подобных случаях использую спрайты для плавного движения + невидимый тайлмап для вычисления координат и кликов мышкой.
Индивидуальные ячейки, вроде, нельзя было двигать, а главное для меня критично - нельзя перекрашивать (только тайл в тайлсете, то есть применяется ко всей карте, а не ячейке). Может быть в 4 это переделали получше.
Надо будет в 4 посмотреть, может там уже есть это все.
>>48239
я уже думаю, что наверное лучше подойдут даже не спрайты, а TextureRect, т.к. позиционировать их удобнее будет и управлять
в гайдах там просто для новичков такие примеры, чтобы вкатиться, я же просто спросил через какие ноды оптимальнее такое сделать, чтобы самому время не тратит если есть что-то готовое
я уже думаю, что наверное лучше подойдут даже не спрайты, а TextureRect, т.к. позиционировать их удобнее будет и управлять
в гайдах там просто для новичков такие примеры, чтобы вкатиться, я же просто спросил через какие ноды оптимальнее такое сделать, чтобы самому время не тратит если есть что-то готовое
Если я создаю покадровую анимацию в AnimationPlayer, мне обязательно надо вручную рассчитать и добавить промежуток времени (1/FPS) после последнего кадра, иначе при зацикливании, последний кадр скипнется.
Мне это нужно, чтобы добавлять такую анимацию в другой AnimationPlayer как Animation Playback Track. А анимацию из AnimatedSprite я таким образом добавить не могу.
По другому никак?
Мне это нужно, чтобы добавлять такую анимацию в другой AnimationPlayer как Animation Playback Track. А анимацию из AnimatedSprite я таким образом добавить не могу.
По другому никак?
20 Кб, 899x266>>48271
Это тоже дополнительная работа.
Я не заметил сразу, что можно в кадрах отсчитывать. Это немного облегчает. Но все равно хотелось бы либо спрайты прямо на таймлайн кидать, либо проигрывать анимации прямо из AnimatedSprite. А сейчас получается, что я сперва создал анимации в AnimatedSprite (потому что у меня отдельные картинки, а не спрайтшит), потом я повторно создаю эти анимации а AnimationPlayer, и там надо целых 2 трека - один чтобы включить нужную анимацию, другой чтобы анимировать кадр.
Это тоже дополнительная работа.
Я не заметил сразу, что можно в кадрах отсчитывать. Это немного облегчает. Но все равно хотелось бы либо спрайты прямо на таймлайн кидать, либо проигрывать анимации прямо из AnimatedSprite. А сейчас получается, что я сперва создал анимации в AnimatedSprite (потому что у меня отдельные картинки, а не спрайтшит), потом я повторно создаю эти анимации а AnimationPlayer, и там надо целых 2 трека - один чтобы включить нужную анимацию, другой чтобы анимировать кадр.
>>41833 (OP)
5 раз возвращаюсь сюда... Где можно найти базу по созданию игрока? Все туториалы основаны на передвижении и управлении персонажем. Мне же нужно подробное объяснение как работают сами команды в коде.
5 раз возвращаюсь сюда... Где можно найти базу по созданию игрока? Все туториалы основаны на передвижении и управлении персонажем. Мне же нужно подробное объяснение как работают сами команды в коде.
>>48288
Кого? Контроллера?
А тебе что нужно?
Какие команды, например?
GDScript - https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
> базу по созданию игрока?
Кого? Контроллера?
> туториалы основаны на передвижении и управлении персонажем
А тебе что нужно?
>объяснение как работают сами команды в коде.
Какие команды, например?
GDScript - https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
>>48289
Контролер playr.
По сути механика как у Tower Defense.
Дополнительные к атаке, использование защиты, перезарядка. Туториал по анимированию всего этого я уже находил.
>Кого? Контроллера?
Контролер playr.
>А тебе что нужно?
По сути механика как у Tower Defense.
>Какие команды, например?
Дополнительные к атаке, использование защиты, перезарядка. Туториал по анимированию всего этого я уже находил.
>>48290
так а что нужно?
это все обычная математика уже, которая реализуется от цели игры, какие правила придумаешь, такое и будет. Естественно, что нет туториалов на все случаи и правила всех возможных игр
> Дополнительные к атаке, использование защиты, перезарядка. Туториал по анимированию всего этого я уже находил.
так а что нужно?
это все обычная математика уже, которая реализуется от цели игры, какие правила придумаешь, такое и будет. Естественно, что нет туториалов на все случаи и правила всех возможных игр
24 Кб, 776x463>>48301
Плоское 2d
Нужно за стоячий танк отстреливать появляющихся врагов. Из управление мне нужно только стрелять, использовать спец приёмы.
Плоское 2d
Нужно за стоячий танк отстреливать появляющихся врагов. Из управление мне нужно только стрелять, использовать спец приёмы.
>>48301
Хочу добавить что анимацию я планировал делать видео рядом. Но похоже годот использует только покадровый метод показывания спрайтов.
Хочу добавить что анимацию я планировал делать видео рядом. Но похоже годот использует только покадровый метод показывания спрайтов.
>>48323
Не все форматы. Только .ogg .ogx с помощью узла VideoPlayer.
Для анимации персонажа нужно создавать узел AnimatedSprite, и анимировать через него с помощью спрайтов.
Мне нужно создать тир!
>Видео годот проигрывает
Не все форматы. Только .ogg .ogx с помощью узла VideoPlayer.
Для анимации персонажа нужно создавать узел AnimatedSprite, и анимировать через него с помощью спрайтов.
>Честно говоря мы не очень понимаем что ты говоришь.
>так а что нужно?
Мне нужно создать тир!
>>48318
ну если тебе тир типа такого, то просто смотришь пересечение клика мыши и цели
спецприемы повесь на горячие клавиши и тоже кнопки
>>48327
так пережми в нужны, ffmpeg в помощь
это только в твоей голове понятно, что ты там хочешь создать, а другим людям объяснять нужно, для этого тз и пишут
ну если тебе тир типа такого, то просто смотришь пересечение клика мыши и цели
спецприемы повесь на горячие клавиши и тоже кнопки
>>48327
> Не все форматы
так пережми в нужны, ffmpeg в помощь
> Мне нужно создать тир!
это только в твоей голове понятно, что ты там хочешь создать, а другим людям объяснять нужно, для этого тз и пишут
>>48333
Я не знаю как! В программировании полный ноль, по этому и спрашивал про подходящие туториалы и матерьялы.
>ну если тебе тир типа такого, то просто смотришь пересечение клика мыши и цели
>спецприемы повесь на горячие клавиши и тоже кнопки
Я не знаю как! В программировании полный ноль, по этому и спрашивал про подходящие туториалы и матерьялы.
>>48339
по стрельбе, чтобы был тир - это клик по спрайту, тут подробно описано как
https://www.reddit.com/r/godot/comments/7xwr22/guide_how_to_click_a_sprite/
по стрельбе, чтобы был тир - это клик по спрайту, тут подробно описано как
https://www.reddit.com/r/godot/comments/7xwr22/guide_how_to_click_a_sprite/
83 Кб, 800x600>>41833 (OP)
Давно сюда не заходил, хотел забросить геймдев...
Через какое-то время после того, как я попытался переделать json с описанием блоков карты, сломал их загрузку, расстроился и забросил проект, пришла идея реализовать внутриигровой редактор блоков большего размера, который будет поддерживать ландшафт на основе карты высот (уже пробовал делать, нужно только решить вопрос с гладким текстурированием), произвольное расположение дорог (сначала попробую более простой вариант, потом добавлю изгибы), домов, растений и прочих объектов, а также "точек генерации" для автоматического создания вариаций. Каждый из четырёх рёбер блока будет хранить список совместимых блоков/категорий. Пользователь может редактировать стандартные блоки и создавать с нуля свои собственные, описание которых сохраняется в json в папке пользовательских файлов. Это избавит от ручного редактирования json, и, в идеале, от создания obj в сторонних 3D редакторах (Blender). Во время генерации новой карты эти блоки будут соединяться друг с другом краями, как раньше, но дополнительно будет производиться сшивание краёв ландшафта, чтобы пользователю не приходилось подгонять края блоков друг по друга (это была основная проблема предыдущей версии). Сшивание краёв ландшафта позволит создавать куда более произвольные комбинации, чем раньше, не заботясь о совместимости блоков - в худшем случае будет слишком высокий перепад высот.
На скриншоте можно сравнить размер старого блока (24x24 метра) с новым (пока что 256x256 метров). Решил значительно увеличить блоки по той причине, что из маленьких блоков неизбежно образуется субъективно скучная квадратная сетка (я так и не нашёл способа её избежать), к тому же, редактор имеет больше смысла, когда в блок можно запихнуть больше интересных деталей/вариаций. К примеру, большой блок позволит создать петляющий участок дороги, спускающейся с крутой горы; хотя такой блок и будет повторяться, но в композиции с другими такими же большими блоками должно получаться что-то интересное. Правда, есть сомнения о том, как это всё повлияет на производительность...
Почему именно блочная генерация, а не генерация карты сразу как единого целого? Во-первых, генерацию карты целиком, ИМХО, сложнее контролировать, даже имея доступ к исходным кодам игры (сужу по опыту и чтению описаний чужих генераторов); если собирать большую карту из небольших кусочков, форма и взаимоотношения которых заданы заранее, можно точнее контролировать свойства карты. Во-вторых, я давно уже хотел сделать игру, позволяющую игроку тонко настраивать генерацию мира игровыми средствами (т.е. доработка игры без внешних инструментов); хотя отдельный редактор блоков не совсем соответствует этим идеям (в идеале хотелось чтобы игровой персонаж каким-то образом влиял на генерацию новых чанков), он всё же куда ближе к ним, чем использование сторонних инструментов (Blender + редактор json для описания блока), потому что позволяет дополнять генератор новым контентом, меняющим результат генерации, не выходя из игры.
Также я всё-таки хотел бы иметь реально большой мир с разнообразными местами, а не мелкий островок 2x2 км, который можно объехать по периметру за пару минут... Из маленьких блоков собирать большую осмысленную территорию оказалось сложнее, чем я думал, так что надеюсь, что крупные блоки помогут увеличить масштабы, пусть и в ущерб вариациям на меньшем масштабе (кого вообще волнует форма оврагов в каком-нибудь абстрактном лесу, лол?). По идее, крупный размер блоков ускорит генерацию мира, хотя ландшафт на карте высот замедлит загрузку блоков.
Программа-минимум: вернуть игре минимальную играбельность, чтобы покататься на машинке по дорогам и холмам вокруг пустых серых коробок(( Разве я многого прошу? Я всего лишь хочу ГТА-образный геймплей с несколькими дополнительными фичами, которых в оригинальной серии ГТА никогда не сделают, ну почему это всё так сложно реализовать...
Программа-максимум: сделать редактор не только блоков мира, но ещё редакторы зданий, машин, растений, персонажей/ИИ, интерактивных предметов и даже текстур со звуками. Тогда в какой-то момент можно будет забить на редактор Godot с бесконечным F5/F8 и делать игру внутри самой игры, достраивая её контент вокруг скелетных механик встроенными редакторами. Тем более что GDScript можно выполнять из любой папки, т.е. любая игра на Godot из коробки поддерживает пользовательский скриптинг внутри самой себя, достаточно добавить редактор кода.
Готовые редакторы ландшафта под Godot знаю, но пока хочу накидать сам из любопытства и желания контроля, а уже потом посмотрим, стоит ли на что-то переходить (ничего хорошего в лишних зависимостях нет).
Давно сюда не заходил, хотел забросить геймдев...
Через какое-то время после того, как я попытался переделать json с описанием блоков карты, сломал их загрузку, расстроился и забросил проект, пришла идея реализовать внутриигровой редактор блоков большего размера, который будет поддерживать ландшафт на основе карты высот (уже пробовал делать, нужно только решить вопрос с гладким текстурированием), произвольное расположение дорог (сначала попробую более простой вариант, потом добавлю изгибы), домов, растений и прочих объектов, а также "точек генерации" для автоматического создания вариаций. Каждый из четырёх рёбер блока будет хранить список совместимых блоков/категорий. Пользователь может редактировать стандартные блоки и создавать с нуля свои собственные, описание которых сохраняется в json в папке пользовательских файлов. Это избавит от ручного редактирования json, и, в идеале, от создания obj в сторонних 3D редакторах (Blender). Во время генерации новой карты эти блоки будут соединяться друг с другом краями, как раньше, но дополнительно будет производиться сшивание краёв ландшафта, чтобы пользователю не приходилось подгонять края блоков друг по друга (это была основная проблема предыдущей версии). Сшивание краёв ландшафта позволит создавать куда более произвольные комбинации, чем раньше, не заботясь о совместимости блоков - в худшем случае будет слишком высокий перепад высот.
На скриншоте можно сравнить размер старого блока (24x24 метра) с новым (пока что 256x256 метров). Решил значительно увеличить блоки по той причине, что из маленьких блоков неизбежно образуется субъективно скучная квадратная сетка (я так и не нашёл способа её избежать), к тому же, редактор имеет больше смысла, когда в блок можно запихнуть больше интересных деталей/вариаций. К примеру, большой блок позволит создать петляющий участок дороги, спускающейся с крутой горы; хотя такой блок и будет повторяться, но в композиции с другими такими же большими блоками должно получаться что-то интересное. Правда, есть сомнения о том, как это всё повлияет на производительность...
Почему именно блочная генерация, а не генерация карты сразу как единого целого? Во-первых, генерацию карты целиком, ИМХО, сложнее контролировать, даже имея доступ к исходным кодам игры (сужу по опыту и чтению описаний чужих генераторов); если собирать большую карту из небольших кусочков, форма и взаимоотношения которых заданы заранее, можно точнее контролировать свойства карты. Во-вторых, я давно уже хотел сделать игру, позволяющую игроку тонко настраивать генерацию мира игровыми средствами (т.е. доработка игры без внешних инструментов); хотя отдельный редактор блоков не совсем соответствует этим идеям (в идеале хотелось чтобы игровой персонаж каким-то образом влиял на генерацию новых чанков), он всё же куда ближе к ним, чем использование сторонних инструментов (Blender + редактор json для описания блока), потому что позволяет дополнять генератор новым контентом, меняющим результат генерации, не выходя из игры.
Также я всё-таки хотел бы иметь реально большой мир с разнообразными местами, а не мелкий островок 2x2 км, который можно объехать по периметру за пару минут... Из маленьких блоков собирать большую осмысленную территорию оказалось сложнее, чем я думал, так что надеюсь, что крупные блоки помогут увеличить масштабы, пусть и в ущерб вариациям на меньшем масштабе (кого вообще волнует форма оврагов в каком-нибудь абстрактном лесу, лол?). По идее, крупный размер блоков ускорит генерацию мира, хотя ландшафт на карте высот замедлит загрузку блоков.
Программа-минимум: вернуть игре минимальную играбельность, чтобы покататься на машинке по дорогам и холмам вокруг пустых серых коробок(( Разве я многого прошу? Я всего лишь хочу ГТА-образный геймплей с несколькими дополнительными фичами, которых в оригинальной серии ГТА никогда не сделают, ну почему это всё так сложно реализовать...
Программа-максимум: сделать редактор не только блоков мира, но ещё редакторы зданий, машин, растений, персонажей/ИИ, интерактивных предметов и даже текстур со звуками. Тогда в какой-то момент можно будет забить на редактор Godot с бесконечным F5/F8 и делать игру внутри самой игры, достраивая её контент вокруг скелетных механик встроенными редакторами. Тем более что GDScript можно выполнять из любой папки, т.е. любая игра на Godot из коробки поддерживает пользовательский скриптинг внутри самой себя, достаточно добавить редактор кода.
Готовые редакторы ландшафта под Godot знаю, но пока хочу накидать сам из любопытства и желания контроля, а уже потом посмотрим, стоит ли на что-то переходить (ничего хорошего в лишних зависимостях нет).
83 Кб, 800x600>>41833 (OP)
Давно сюда не заходил, хотел забросить геймдев...
Через какое-то время после того, как я попытался переделать json с описанием блоков карты, сломал их загрузку, расстроился и забросил проект, пришла идея реализовать внутриигровой редактор блоков большего размера, который будет поддерживать ландшафт на основе карты высот (уже пробовал делать, нужно только решить вопрос с гладким текстурированием), произвольное расположение дорог (сначала попробую более простой вариант, потом добавлю изгибы), домов, растений и прочих объектов, а также "точек генерации" для автоматического создания вариаций. Каждый из четырёх рёбер блока будет хранить список совместимых блоков/категорий. Пользователь может редактировать стандартные блоки и создавать с нуля свои собственные, описание которых сохраняется в json в папке пользовательских файлов. Это избавит от ручного редактирования json, и, в идеале, от создания obj в сторонних 3D редакторах (Blender). Во время генерации новой карты эти блоки будут соединяться друг с другом краями, как раньше, но дополнительно будет производиться сшивание краёв ландшафта, чтобы пользователю не приходилось подгонять края блоков друг по друга (это была основная проблема предыдущей версии). Сшивание краёв ландшафта позволит создавать куда более произвольные комбинации, чем раньше, не заботясь о совместимости блоков - в худшем случае будет слишком высокий перепад высот.
На скриншоте можно сравнить размер старого блока (24x24 метра) с новым (пока что 256x256 метров). Решил значительно увеличить блоки по той причине, что из маленьких блоков неизбежно образуется субъективно скучная квадратная сетка (я так и не нашёл способа её избежать), к тому же, редактор имеет больше смысла, когда в блок можно запихнуть больше интересных деталей/вариаций. К примеру, большой блок позволит создать петляющий участок дороги, спускающейся с крутой горы; хотя такой блок и будет повторяться, но в композиции с другими такими же большими блоками должно получаться что-то интересное. Правда, есть сомнения о том, как это всё повлияет на производительность...
Почему именно блочная генерация, а не генерация карты сразу как единого целого? Во-первых, генерацию карты целиком, ИМХО, сложнее контролировать, даже имея доступ к исходным кодам игры (сужу по опыту и чтению описаний чужих генераторов); если собирать большую карту из небольших кусочков, форма и взаимоотношения которых заданы заранее, можно точнее контролировать свойства карты. Во-вторых, я давно уже хотел сделать игру, позволяющую игроку тонко настраивать генерацию мира игровыми средствами (т.е. доработка игры без внешних инструментов); хотя отдельный редактор блоков не совсем соответствует этим идеям (в идеале хотелось чтобы игровой персонаж каким-то образом влиял на генерацию новых чанков), он всё же куда ближе к ним, чем использование сторонних инструментов (Blender + редактор json для описания блока), потому что позволяет дополнять генератор новым контентом, меняющим результат генерации, не выходя из игры.
Также я всё-таки хотел бы иметь реально большой мир с разнообразными местами, а не мелкий островок 2x2 км, который можно объехать по периметру за пару минут... Из маленьких блоков собирать большую осмысленную территорию оказалось сложнее, чем я думал, так что надеюсь, что крупные блоки помогут увеличить масштабы, пусть и в ущерб вариациям на меньшем масштабе (кого вообще волнует форма оврагов в каком-нибудь абстрактном лесу, лол?). По идее, крупный размер блоков ускорит генерацию мира, хотя ландшафт на карте высот замедлит загрузку блоков.
Программа-минимум: вернуть игре минимальную играбельность, чтобы покататься на машинке по дорогам и холмам вокруг пустых серых коробок(( Разве я многого прошу? Я всего лишь хочу ГТА-образный геймплей с несколькими дополнительными фичами, которых в оригинальной серии ГТА никогда не сделают, ну почему это всё так сложно реализовать...
Программа-максимум: сделать редактор не только блоков мира, но ещё редакторы зданий, машин, растений, персонажей/ИИ, интерактивных предметов и даже текстур со звуками. Тогда в какой-то момент можно будет забить на редактор Godot с бесконечным F5/F8 и делать игру внутри самой игры, достраивая её контент вокруг скелетных механик встроенными редакторами. Тем более что GDScript можно выполнять из любой папки, т.е. любая игра на Godot из коробки поддерживает пользовательский скриптинг внутри самой себя, достаточно добавить редактор кода.
Готовые редакторы ландшафта под Godot знаю, но пока хочу накидать сам из любопытства и желания контроля, а уже потом посмотрим, стоит ли на что-то переходить (ничего хорошего в лишних зависимостях нет).
Давно сюда не заходил, хотел забросить геймдев...
Через какое-то время после того, как я попытался переделать json с описанием блоков карты, сломал их загрузку, расстроился и забросил проект, пришла идея реализовать внутриигровой редактор блоков большего размера, который будет поддерживать ландшафт на основе карты высот (уже пробовал делать, нужно только решить вопрос с гладким текстурированием), произвольное расположение дорог (сначала попробую более простой вариант, потом добавлю изгибы), домов, растений и прочих объектов, а также "точек генерации" для автоматического создания вариаций. Каждый из четырёх рёбер блока будет хранить список совместимых блоков/категорий. Пользователь может редактировать стандартные блоки и создавать с нуля свои собственные, описание которых сохраняется в json в папке пользовательских файлов. Это избавит от ручного редактирования json, и, в идеале, от создания obj в сторонних 3D редакторах (Blender). Во время генерации новой карты эти блоки будут соединяться друг с другом краями, как раньше, но дополнительно будет производиться сшивание краёв ландшафта, чтобы пользователю не приходилось подгонять края блоков друг по друга (это была основная проблема предыдущей версии). Сшивание краёв ландшафта позволит создавать куда более произвольные комбинации, чем раньше, не заботясь о совместимости блоков - в худшем случае будет слишком высокий перепад высот.
На скриншоте можно сравнить размер старого блока (24x24 метра) с новым (пока что 256x256 метров). Решил значительно увеличить блоки по той причине, что из маленьких блоков неизбежно образуется субъективно скучная квадратная сетка (я так и не нашёл способа её избежать), к тому же, редактор имеет больше смысла, когда в блок можно запихнуть больше интересных деталей/вариаций. К примеру, большой блок позволит создать петляющий участок дороги, спускающейся с крутой горы; хотя такой блок и будет повторяться, но в композиции с другими такими же большими блоками должно получаться что-то интересное. Правда, есть сомнения о том, как это всё повлияет на производительность...
Почему именно блочная генерация, а не генерация карты сразу как единого целого? Во-первых, генерацию карты целиком, ИМХО, сложнее контролировать, даже имея доступ к исходным кодам игры (сужу по опыту и чтению описаний чужих генераторов); если собирать большую карту из небольших кусочков, форма и взаимоотношения которых заданы заранее, можно точнее контролировать свойства карты. Во-вторых, я давно уже хотел сделать игру, позволяющую игроку тонко настраивать генерацию мира игровыми средствами (т.е. доработка игры без внешних инструментов); хотя отдельный редактор блоков не совсем соответствует этим идеям (в идеале хотелось чтобы игровой персонаж каким-то образом влиял на генерацию новых чанков), он всё же куда ближе к ним, чем использование сторонних инструментов (Blender + редактор json для описания блока), потому что позволяет дополнять генератор новым контентом, меняющим результат генерации, не выходя из игры.
Также я всё-таки хотел бы иметь реально большой мир с разнообразными местами, а не мелкий островок 2x2 км, который можно объехать по периметру за пару минут... Из маленьких блоков собирать большую осмысленную территорию оказалось сложнее, чем я думал, так что надеюсь, что крупные блоки помогут увеличить масштабы, пусть и в ущерб вариациям на меньшем масштабе (кого вообще волнует форма оврагов в каком-нибудь абстрактном лесу, лол?). По идее, крупный размер блоков ускорит генерацию мира, хотя ландшафт на карте высот замедлит загрузку блоков.
Программа-минимум: вернуть игре минимальную играбельность, чтобы покататься на машинке по дорогам и холмам вокруг пустых серых коробок(( Разве я многого прошу? Я всего лишь хочу ГТА-образный геймплей с несколькими дополнительными фичами, которых в оригинальной серии ГТА никогда не сделают, ну почему это всё так сложно реализовать...
Программа-максимум: сделать редактор не только блоков мира, но ещё редакторы зданий, машин, растений, персонажей/ИИ, интерактивных предметов и даже текстур со звуками. Тогда в какой-то момент можно будет забить на редактор Godot с бесконечным F5/F8 и делать игру внутри самой игры, достраивая её контент вокруг скелетных механик встроенными редакторами. Тем более что GDScript можно выполнять из любой папки, т.е. любая игра на Godot из коробки поддерживает пользовательский скриптинг внутри самой себя, достаточно добавить редактор кода.
Готовые редакторы ландшафта под Godot знаю, но пока хочу накидать сам из любопытства и желания контроля, а уже потом посмотрим, стоит ли на что-то переходить (ничего хорошего в лишних зависимостях нет).
>>48268
>>48276
1. Делаешь декомпозицию задачи на простейшие операции.
2. Пишешь скрипт, выполняющий эти простейшие операции.
3. Делаешь кнопку "сделать анимации ваще нормально да".
4. Нажимаешь кнопку...
5. ???
6. Твой скрипт сделал всю работу за тебя. Восхитительно.
>вручную рассчитать и добавить
>>48276
>дополнительная работа
1. Делаешь декомпозицию задачи на простейшие операции.
2. Пишешь скрипт, выполняющий эти простейшие операции.
3. Делаешь кнопку "сделать анимации ваще нормально да".
4. Нажимаешь кнопку...
5. ???
6. Твой скрипт сделал всю работу за тебя. Восхитительно.
>>48339
>>48288
Тебе нужны туториалы по программированию, начиная с самых основ (что такое переменные, что такое функции, как делать простые математические операции и выводить результат в консоль, и т.п.). Благо, есть туториалы для новичков в программировании прямо на GDScript, чтобы не учить другой ЯП и сразу пробовать всё в Godot. Вот с этого и начинай, а уже потом будешь думать, как сделать игру. Если делать игру сразу (даже такую простую, как 2D тир), не понимая ничего в программировании, наломаешь дров и много раз расстроишься из-за непонимания. Нужно вкатываться постепенно, а не бросаться делать игру мечты, не разбираясь в том, из чего она может быть устроена.
>В программировании полный ноль
>>48288
>Мне же нужно подробное объяснение как работают сами команды в коде.
Тебе нужны туториалы по программированию, начиная с самых основ (что такое переменные, что такое функции, как делать простые математические операции и выводить результат в консоль, и т.п.). Благо, есть туториалы для новичков в программировании прямо на GDScript, чтобы не учить другой ЯП и сразу пробовать всё в Godot. Вот с этого и начинай, а уже потом будешь думать, как сделать игру. Если делать игру сразу (даже такую простую, как 2D тир), не понимая ничего в программировании, наломаешь дров и много раз расстроишься из-за непонимания. Нужно вкатываться постепенно, а не бросаться делать игру мечты, не разбираясь в том, из чего она может быть устроена.
29 Кб, 497x278>>48344
Большое спасибо за гайд. Смог даже анимацию сделать, но... Она у меня проигрывается только от одного клика. После она перестает работать.
Большое спасибо за гайд. Смог даже анимацию сделать, но... Она у меня проигрывается только от одного клика. После она перестает работать.
26 Кб, 935x337почему сигнал посылается дважды, когда изменяю размер окна?
Это _ready так работает или сам сигнал испускается для начального/конечного состояний или что?
Это _ready так работает или сам сигнал испускается для начального/конечного состояний или что?
46 Кб, 483x435>>48365
Мало было проблем с проигрыванием анимации у врага. Не понятно как сделать анимацию по нажатию мышки у плеера. Она должна проигрываться вне зависимости куда нажал игрок, как его изменить под мои нужды понятия не имею.
Мало было проблем с проигрыванием анимации у врага. Не понятно как сделать анимацию по нажатию мышки у плеера. Она должна проигрываться вне зависимости куда нажал игрок, как его изменить под мои нужды понятия не имею.
создаю TextureRect и ему загоняю текстуру из вьюпорта
почему, когда как на первом пике является родителем, то не рисует
а когда является братом, идущим после, то рисует?
вроде же root также работать должна, она же родитель
почему, когда как на первом пике является родителем, то не рисует
а когда является братом, идущим после, то рисует?
вроде же root также работать должна, она же родитель
>>48469
Скорее всего, порядок отрисовки - сначала рисуются корни, потом их дети по порядку. Поэтому во втором случае вьюпорт рисуется раньше и его текстура готова для подачи в текстуррект. Знаю что если во втором случае переставить вьюпорт и таргет местами в списке, тоже не сработает. На root ориентироваться смысла нет, там наверняка другая логика из-за того что это идет на экран.
Скорее всего, порядок отрисовки - сначала рисуются корни, потом их дети по порядку. Поэтому во втором случае вьюпорт рисуется раньше и его текстура готова для подачи в текстуррект. Знаю что если во втором случае переставить вьюпорт и таргет местами в списке, тоже не сработает. На root ориентироваться смысла нет, там наверняка другая логика из-за того что это идет на экран.
49 Кб, 500x471>>48412
Ты ловишь клик в _input_event твоего игрока.
Если ты хочешь ловить клики "везде в сцене", то писать _input или _unhandled_input тебе надо в сцене игры, которая выше по уровню, а не игрока.
Здесь есть диаграмма которая объясняет происходящее
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html
Ты ловишь клик в _input_event твоего игрока.
Если ты хочешь ловить клики "везде в сцене", то писать _input или _unhandled_input тебе надо в сцене игры, которая выше по уровню, а не игрока.
Здесь есть диаграмма которая объясняет происходящее
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html
>>48474
да, если переставить, то там порядок обработки изменится, если вьюпорт станет последующим братом, но почему не срабатывает, если родитель-то
получается мне всегда лишний узел нужно будет делать, который их группирует
да, если переставить, то там порядок обработки изменится, если вьюпорт станет последующим братом, но почему не срабатывает, если родитель-то
получается мне всегда лишний узел нужно будет делать, который их группирует
>>48477
так он не лишний. это у тебя в голове все очевидно, а движку нужно это «обьяснять» структурой. иерархия - это и есть «обьяснение» что с чем связано вперед чего
так он не лишний. это у тебя в голове все очевидно, а движку нужно это «обьяснять» структурой. иерархия - это и есть «обьяснение» что с чем связано вперед чего
>>48481
так связь родитель-сын разве уже это не объясняет? root же так работает
так связь родитель-сын разве уже это не объясняет? root же так работает
>>48493
Раздели в уме - кто получает клик (игровое поле, спрайт игрока или кнопка), и кому потом эта информация будет передана (например может быть послан сигнал и подписчики его получат, или игровое поле вызовет функцию у сцены игрока).
Раздели в уме - кто получает клик (игровое поле, спрайт игрока или кнопка), и кому потом эта информация будет передана (например может быть послан сигнал и подписчики его получат, или игровое поле вызовет функцию у сцены игрока).
55 Кб, 959x445>>48503
Клик происходит на поле, но сама анимация на которую будет реагировать игрок прописана в сцене Player. Если я в основной сцене напишу этот код, он не будет привязан к конкретному объекту, потому что в сцене кроме него есть enemy. Сам enemy спокойно получает клик на поле, хотя скрипт прописан в его личной сцене. Единственной проблемой которой является одиночное проигрывание, не смотря на повторные нажатия.
Найдя гайд в котором вроде как показан способ сделать нужный мне клик для игрока, столкнулся с ошибкой которая хрен пойми откуда взялась! Почему программирование так жестко со мной?
Клик происходит на поле, но сама анимация на которую будет реагировать игрок прописана в сцене Player. Если я в основной сцене напишу этот код, он не будет привязан к конкретному объекту, потому что в сцене кроме него есть enemy. Сам enemy спокойно получает клик на поле, хотя скрипт прописан в его личной сцене. Единственной проблемой которой является одиночное проигрывание, не смотря на повторные нажатия.
Найдя гайд в котором вроде как показан способ сделать нужный мне клик для игрока, столкнулся с ошибкой которая хрен пойми откуда взялась! Почему программирование так жестко со мной?
3 Кб, 591x35Сама ошибка >>48508
645 Кб, 1917x1077>>48528
А что сделать для его появления? Пересмотрев видео понял что скрипт был привязан к sprite. Но все равно у него нет этой ошибки, а она у меня есть.
https://www.youtube.com/watch?v=Om7JzfU_plw&ab_channel=IsraelRuiz
А что сделать для его появления? Пересмотрев видео понял что скрипт был привязан к sprite. Но все равно у него нет этой ошибки, а она у меня есть.
https://www.youtube.com/watch?v=Om7JzfU_plw&ab_channel=IsraelRuiz
>>48508
тебе выше посоветовали начать с основ, а ты сразу в анимации полез
подвигай спрайтики, понажимай на них мышкой, вот это вот всё
> Почему программирование так жестко со мной?
тебе выше посоветовали начать с основ, а ты сразу в анимации полез
подвигай спрайтики, понажимай на них мышкой, вот это вот всё
>>48554
У меня кор-геймплей завязан на кликах по врагам. Если этого не будет, все остальное можно не начинать. Делать по гайду 3d шутер паркур от первого лица к которому я не сделаю модельки, не хочу.
Уже, первый клик работает нормально. Потом... >>48365
>тебе выше посоветовали начать с основ
У меня кор-геймплей завязан на кликах по врагам. Если этого не будет, все остальное можно не начинать. Делать по гайду 3d шутер паркур от первого лица к которому я не сделаю модельки, не хочу.
>подвигай спрайтики, понажимай на них мышкой, вот это вот всё
Уже, первый клик работает нормально. Потом... >>48365
>>48508
>>48532
В начале скрипта пишется extends ClassName, это означает что у объекта будут определенные свойства.
Так вот на этом скрине extends Sprite, поэтому и доступна функция get_rect()
В твоем же случае extends KinematicBody2D, у которого такой функции нет.
Раз ты хочешь вызвать ее у спрайта, то очевидно тебе надо писать _animated_sprite.get_rect()...
>>48532
В начале скрипта пишется extends ClassName, это означает что у объекта будут определенные свойства.
Так вот на этом скрине extends Sprite, поэтому и доступна функция get_rect()
В твоем же случае extends KinematicBody2D, у которого такой функции нет.
Раз ты хочешь вызвать ее у спрайта, то очевидно тебе надо писать _animated_sprite.get_rect()...
Надо учить с# перед разработкой своих шедевров на годоте? Или во время разработки выучится что надо?
Что такое документация?
Что такое документация?
>>48560
А у AnimatedSprite что писать? Я всё туда принёс.
А у AnimatedSprite что писать? Я всё туда принёс.
>>48365
Я посмотрел, походу это из-за того что AnimatedSprite не перематывает после анимации, а остается в последнем кадре
Не уверен что так должно быть. Но я им не пользуюсь обычно, а пользуюсь AnimationPlayer.
Помогло если написать так
func on_click():
_print("click")
_$AnimatedSprite.frame = 0
_$AnimatedSprite.play("damage")
Я посмотрел, походу это из-за того что AnimatedSprite не перематывает после анимации, а остается в последнем кадре
Не уверен что так должно быть. Но я им не пользуюсь обычно, а пользуюсь AnimationPlayer.
Помогло если написать так
func on_click():
_print("click")
_$AnimatedSprite.frame = 0
_$AnimatedSprite.play("damage")
>>48562
Это большая книга в которой всё расписано по программе.
https://docs.godotengine.org/ru/latest/
Посмотри на меня! Нормально привязать клик к игроку не могу. Лучше без знаний программирования сюда не соваться. Будет сильно болеть попа.
>Что такое документация?
Это большая книга в которой всё расписано по программе.
https://docs.godotengine.org/ru/latest/
>Надо учить с# перед разработкой своих шедевров на годоте? Или во время разработки выучится что надо?
Посмотри на меня! Нормально привязать клик к игроку не могу. Лучше без знаний программирования сюда не соваться. Будет сильно болеть попа.
>>48562
Лучше выучить. Можешь начать с питона и гдскрипта.
Хотел сказать, что это как справка к программе, но вспомнил что уже мало кто помнит что это.
>Надо учить с# перед разработкой своих шедевров на годоте?
Лучше выучить. Можешь начать с питона и гдскрипта.
>Что такое документация?
Хотел сказать, что это как справка к программе, но вспомнил что уже мало кто помнит что это.
>>48589
Так, смотри.
В гдскрипте $Название означает доступ к ноде с именем название.
Например если у тебя сцена такая
Area
-AnimatedSprite
То из скрипта Area можно обращаться к спрайту как $AnimatedSprite.
Я писал по аналогии с >>48508
до того как ты начал что-то куда то переносить.
Поэтому если у тебя называется не $AnimationSprite, а $Sprite, пиши так.
В общем по аналогии как у тебя .play("damage") написано, понимаешь?
Я просто добавил одну строчку до этого, которя делает .frame = 0
Так, смотри.
В гдскрипте $Название означает доступ к ноде с именем название.
Например если у тебя сцена такая
Area
-AnimatedSprite
То из скрипта Area можно обращаться к спрайту как $AnimatedSprite.
Я писал по аналогии с >>48508
до того как ты начал что-то куда то переносить.
Поэтому если у тебя называется не $AnimationSprite, а $Sprite, пиши так.
В общем по аналогии как у тебя .play("damage") написано, понимаешь?
Я просто добавил одну строчку до этого, которя делает .frame = 0
>>48601
Теперь я понял. Сейчас оно заработало нормально. Но всё же пугает то сколько ещё нужно сделать для своей маленькой задумки.
Теперь я понял. Сейчас оно заработало нормально. Но всё же пугает то сколько ещё нужно сделать для своей маленькой задумки.
>>48625
Потому что floating point error. Старайся выбирать такие значения scale в камере, при которых пиксели спрайтов попадают чётко в пиксели экрана.
https://en.wikipedia.org/wiki/Floating-point_error_mitigation
Потому что floating point error. Старайся выбирать такие значения scale в камере, при которых пиксели спрайтов попадают чётко в пиксели экрана.
https://en.wikipedia.org/wiki/Floating-point_error_mitigation
>>48626
Тайлмап 800x600, размер окна 800x600, scale камеры 0,5x 0,5
Тайлмап 800x600, размер окна 800x600, scale камеры 0,5x 0,5
>>48382
Скорее всего это связано с тем, как ОС меняет размер окна. Вряд ли ты можешь с этим что-то сделать.
>почему сигнал посылается дважды, когда изменяю размер окна?
Скорее всего это связано с тем, как ОС меняет размер окна. Вряд ли ты можешь с этим что-то сделать.
>>48632 (Del)
https://docs.godotengine.org/en/stable/classes/class_skeleton.html
>Для прототипа требуется пилить процедурные анимации, а это значит нужно таскать косточки при помощи функций.
https://docs.godotengine.org/en/stable/classes/class_skeleton.html
>>48633
Окей, вижу инверс кинематика имеется, в принципе если вращать косточки и направлять в сторону можно, то мне хватит. Спасибо.
Окей, вижу инверс кинематика имеется, в принципе если вращать косточки и направлять в сторону можно, то мне хватит. Спасибо.
>>48318
>>48608
Сначала хотел тебе помочь, но потом понял твою "маленькую задумку" и передумал. Прикладывай свои собственные силы, диванный воен.
Остальным предлагаю помогать только нормальным анонам, которые делают игры, а пропаганду, замаскированную в форму игр.
>пик
>Нужно за стоячий танк отстреливать появляющихся врагов.
>>48608
>сделать для своей маленькой задумки.
Сначала хотел тебе помочь, но потом понял твою "маленькую задумку" и передумал. Прикладывай свои собственные силы, диванный воен.
Остальным предлагаю помогать только нормальным анонам, которые делают игры, а пропаганду, замаскированную в форму игр.
>>48632 (Del)
Я пробовал создавать прототип на Unity и Godot, а про UE читал достаточно достоверной информации, чтобы даже не прикасаться к нему с его ворохом проблем. Из двух движков выбрал Godot, потому что он сделан как качественный цельный продукт, а не куча неподдерживаемых глючных фич. Лучше меньше фич, но качественно спроектированных, поддерживаемых и подходящих друг другу, чем какой-то фичехаос.
Впрочем, в геймдеве куда важнее иметь качественную графику, чем какой-то конкретный движок. Многие культовые игры прошлого сделаны некачественно с точки зрения кода, но цепляют своей графикой. Поэтому Unity так вкладываются в свой "ассет стор" - чем больше готовой графики для движка, тем проще слепить на нём что-то, что привлечёт внимание игроков.
>Выбираю сейчас на каком двигле работать между Юнити, Уечем и Годотом путём создания прототипа в каждом и оценки где удобнее и лучше.
Я пробовал создавать прототип на Unity и Godot, а про UE читал достаточно достоверной информации, чтобы даже не прикасаться к нему с его ворохом проблем. Из двух движков выбрал Godot, потому что он сделан как качественный цельный продукт, а не куча неподдерживаемых глючных фич. Лучше меньше фич, но качественно спроектированных, поддерживаемых и подходящих друг другу, чем какой-то фичехаос.
Впрочем, в геймдеве куда важнее иметь качественную графику, чем какой-то конкретный движок. Многие культовые игры прошлого сделаны некачественно с точки зрения кода, но цепляют своей графикой. Поэтому Unity так вкладываются в свой "ассет стор" - чем больше готовой графики для движка, тем проще слепить на нём что-то, что привлечёт внимание игроков.
>>48638
Меня вот пятый уеч завлёк тем что меньше надо будет ебаться со светом, FOV, плюс куча ассетов, на которых можно налепить годный грефениум даже одиночки, и последним убедительным аргументом был встроенный мультиплеер. Игра, которую я хочу сделать ближе к тому на что заточен уеч - экшон от первого лица. На Юнити уже попердолился, и там его тоже сделать можно, но как ты и сказал там куча фич либо сырые, либо в виде сырого плагина, и вообще ощущение что всё слеплено скотчем вместе.
Посмотрю чё там в уече, потом наверну годотю. Кстати, что там по мультиплееру в годоте?
Меня вот пятый уеч завлёк тем что меньше надо будет ебаться со светом, FOV, плюс куча ассетов, на которых можно налепить годный грефениум даже одиночки, и последним убедительным аргументом был встроенный мультиплеер. Игра, которую я хочу сделать ближе к тому на что заточен уеч - экшон от первого лица. На Юнити уже попердолился, и там его тоже сделать можно, но как ты и сказал там куча фич либо сырые, либо в виде сырого плагина, и вообще ощущение что всё слеплено скотчем вместе.
Посмотрю чё там в уече, потом наверну годотю. Кстати, что там по мультиплееру в годоте?
>>48635
Что за кавычки?
Какой ещё диванный воин блин! Я игру для себя делаю. А во влажных мечтах после того как залью её на itch.io все проникнутся моей идеей и начнут кидать донатики.
Если бы я хотел подмазать правительству, в первую очередь понёс бы проект RUSSIAN ELDEN RING в виде презентации PowerPoint. Выбил финансирование и заплатил человеку который все за меня сделает.
Но к сожалению мир жесток! Моя идея будет нужна только мне! А я мало того что не имею знаний и сил в её реализацию, ещё и бп похоже начал умирать к ебеням! Денег на замену нету, а когда они появятся окажется что весь PC умер! Что мне делать? С каждым днём все хуже и хуже. Теннис с дерьмовым мячом не смог закодить 2021. Теперь гребаный кликер мне не даётся.
Как сказал один псих с двачей, который искал свою возлюбленную...
Благодаря моим неудачам, другие люди могут обрадоваться своему везению.
>"маленькую задумку"
Что за кавычки?
>диванный воен
Какой ещё диванный воин блин! Я игру для себя делаю. А во влажных мечтах после того как залью её на itch.io все проникнутся моей идеей и начнут кидать донатики.
>которые делают игры, а пропаганду, замаскированную в форму игр.
Если бы я хотел подмазать правительству, в первую очередь понёс бы проект RUSSIAN ELDEN RING в виде презентации PowerPoint. Выбил финансирование и заплатил человеку который все за меня сделает.
Но к сожалению мир жесток! Моя идея будет нужна только мне! А я мало того что не имею знаний и сил в её реализацию, ещё и бп похоже начал умирать к ебеням! Денег на замену нету, а когда они появятся окажется что весь PC умер! Что мне делать? С каждым днём все хуже и хуже. Теннис с дерьмовым мячом не смог закодить 2021. Теперь гребаный кликер мне не даётся.
Как сказал один псих с двачей, который искал свою возлюбленную...
Благодаря моим неудачам, другие люди могут обрадоваться своему везению.
>>48639
Есть, и достаточно продуманный.
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Можно написать сервер на GDScript/C# и запускать движок в headless режиме, т.е. без графики и звука.
https://godotengine.org/download/server
Ну или сделать собственную сборку движка.
>Кстати, что там по мультиплееру в годоте?
Есть, и достаточно продуманный.
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Можно написать сервер на GDScript/C# и запускать движок в headless режиме, т.е. без графики и звука.
https://godotengine.org/download/server
Ну или сделать собственную сборку движка.
Аноны, как лучше реализовать закрашивание вручную\заливку частей изображения(как в расскрасках - загружается черно-белая картинка и юзер должен внутри каждого контура закрасить)?
>>48655
Самое простое в Godot:
1. Разрезаешь картинку на части по областям, которые могут быть закрашены.
2. Составляешь исходную картинку из отдельных спрайтов, которые получились на предыдущем шаге.
3. Каждому спрайту делаешь Area2D.
4. Когда игрок кликает по области, просто меняешь связанному с ней спрайту свойство modulate.
Если тебе лень резать картинку или нужно сэкономить вес приложения, тогда нужно реализовать трушный инструмент floodfill (ведёрко) из растровых редакторов. Хотя тогда возникает вопрос, зачем пользователю твоё приложение, когда можно просто скачать картинку и закрашивать в пейнте?
Во времена Flash раскраски были векторными, соответственно каждый закрашиваемый фрагмент был векторным объектом, у которого кроме контура есть заливка, по умолчанию белая/прозрачная. Godot вроде бы поддерживает загрузку SVG картинок, но, насколько я понимаю, он рендерит SVG в растр и дальше использует только растр, т.е. редактировать SVG не получится. Для векторной раскраски сегодня лучше всего подошёл бы HTML/JS, т.к. редактировать теги SVG на страничке сайта можно точно так же, как теги HTML. Кстати, SVG вообще-то поддерживают скриптинг, так что можно сделать игру-раскраску в одном SVG...
Если тебе нужна не детская раскраска, а что-то совершенно другое, вроде захвата территорий в стратегии - тогда опиши задачу подробнее.
>заливку частей изображения
Самое простое в Godot:
1. Разрезаешь картинку на части по областям, которые могут быть закрашены.
2. Составляешь исходную картинку из отдельных спрайтов, которые получились на предыдущем шаге.
3. Каждому спрайту делаешь Area2D.
4. Когда игрок кликает по области, просто меняешь связанному с ней спрайту свойство modulate.
Если тебе лень резать картинку или нужно сэкономить вес приложения, тогда нужно реализовать трушный инструмент floodfill (ведёрко) из растровых редакторов. Хотя тогда возникает вопрос, зачем пользователю твоё приложение, когда можно просто скачать картинку и закрашивать в пейнте?
Во времена Flash раскраски были векторными, соответственно каждый закрашиваемый фрагмент был векторным объектом, у которого кроме контура есть заливка, по умолчанию белая/прозрачная. Godot вроде бы поддерживает загрузку SVG картинок, но, насколько я понимаю, он рендерит SVG в растр и дальше использует только растр, т.е. редактировать SVG не получится. Для векторной раскраски сегодня лучше всего подошёл бы HTML/JS, т.к. редактировать теги SVG на страничке сайта можно точно так же, как теги HTML. Кстати, SVG вообще-то поддерживают скриптинг, так что можно сделать игру-раскраску в одном SVG...
Если тебе нужна не детская раскраска, а что-то совершенно другое, вроде захвата территорий в стратегии - тогда опиши задачу подробнее.
>>48657
Думал над первым твоим предложенным вариантом, но:
1. хз как потом из нарезнных элементов составить единую картинку
2. чувствую пердолинг с режимом закрашивания "игнорировать границы и красить все подряд"
Насчет веса думаю, что в теории я же могу не сохранять изображения в приложении, а хранить их на удаленном сервере и выдавать пользователю, таким образом экономить размер приложения и раздувать сетевой трафик.
Картинку резать не лень, т.к. это делать буду не руками, а скриптом левым.
Я в принципе не против реализовать ведерко и различные режимы кистей, но даже не знаю с чего начать работу. Гугл не помог.
С JSом не знаком сильно.
Мне именно нужна детская расскраска, просто с различными режимами работы самого процесса покраски, не более.
Спасибо за ответ, анон.
Думал над первым твоим предложенным вариантом, но:
1. хз как потом из нарезнных элементов составить единую картинку
2. чувствую пердолинг с режимом закрашивания "игнорировать границы и красить все подряд"
Насчет веса думаю, что в теории я же могу не сохранять изображения в приложении, а хранить их на удаленном сервере и выдавать пользователю, таким образом экономить размер приложения и раздувать сетевой трафик.
Картинку резать не лень, т.к. это делать буду не руками, а скриптом левым.
Я в принципе не против реализовать ведерко и различные режимы кистей, но даже не знаю с чего начать работу. Гугл не помог.
С JSом не знаком сильно.
Мне именно нужна детская расскраска, просто с различными режимами работы самого процесса покраски, не более.
Спасибо за ответ, анон.
>>48658
Делаешь снимок через Viewport -> сохраняешь png.
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-method-get-texture
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-save-png
Просто всем элементам задаёшь один modulate.
Пиксельное ведёрко:
https://en.wikipedia.org/wiki/Flood_fill
Доступ к пикселям в Godot:
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-get-pixel
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-set-pixel
Но, как ты понимаешь, на GDScript и с огромным количеством пикселей твой алгоритм заливки будет слишком медленным. Лучше рассмотреть создание модуля на C++, если тебе нужна пиксельная заливка.
Интересно. Кому-то из знакомых? Мне кажется, у раскрасок самая жёсткая конкуренция из-за простоты создания и наивности целевой аудитории.
>как потом из нарезнных элементов составить единую картинку
Делаешь снимок через Viewport -> сохраняешь png.
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-method-get-texture
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-save-png
>чувствую пердолинг с режимом закрашивания "игнорировать границы и красить все подряд"
Просто всем элементам задаёшь один modulate.
>func fill_ignoring_borders(fill_color: Color) -> void:
>_ for image_part in get_children():
>_ _ image_part.modulate = fill_color
>Я в принципе не против реализовать ведерко и различные режимы кистей, но даже не знаю с чего начать работу. Гугл не помог.
Пиксельное ведёрко:
https://en.wikipedia.org/wiki/Flood_fill
Доступ к пикселям в Godot:
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-get-pixel
https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-set-pixel
Но, как ты понимаешь, на GDScript и с огромным количеством пикселей твой алгоритм заливки будет слишком медленным. Лучше рассмотреть создание модуля на C++, если тебе нужна пиксельная заливка.
>Мне именно нужна детская расскраска
Интересно. Кому-то из знакомых? Мне кажется, у раскрасок самая жёсткая конкуренция из-за простоты создания и наивности целевой аудитории.
>>48628
так а если у меня на ресайз перерасчет всего гуя идет и там всякие текстуры подгоняются, он мне что два раза все это делать будет?
> Скорее всего это связано с тем, как ОС меняет размер окна. Вряд ли ты можешь с этим что-то сделать.
так а если у меня на ресайз перерасчет всего гуя идет и там всякие текстуры подгоняются, он мне что два раза все это делать будет?
>>48660
Стандартные гуевые элементы делают всё это автоматически без твоей помощи. Используй якори и ничего подгонять вручную не придётся.
Добавь такой код:
>перерасчет всего гуя идет и там всякие текстуры подгоняются
Стандартные гуевые элементы делают всё это автоматически без твоей помощи. Используй якори и ничего подгонять вручную не придётся.
>он мне что два раза все это делать будет?
Добавь такой код:
>var last_window_size: Vector2
>func on_window_resize(new_size: Vector2) -> void:
>_ if not new_size.is_equal_approx(last_window_size):
>_ _ last_window_size = new_size
>_ _ rearrange_everthing_window_related(bla_bla_bla)
1,6 Мб, mp4,800x600, 1:58
>>48643
Расслабься, я сделал его вместо тебя.
Теперь можешь мучиться чем-то другим.
>Теперь гребаный кликер мне не даётся.
Расслабься, я сделал его вместо тебя.
Теперь можешь мучиться чем-то другим.
>>48662
зачетный писюн
зачетный писюн
>>48661
ну да, тоже уже думал, чтобы сохранять вектор размера и если не поменялся, то не запускать основной код, видимо так и закостылю
ну да, тоже уже думал, чтобы сохранять вектор размера и если не поменялся, то не запускать основной код, видимо так и закостылю
>>48662
И зачем ты мне это скинул? Хочешь показать насколько ты крутой программист? Или на сколько я бездарен раз не смог сделать это за 2 дня? В любом случае уже повторяется игра с теннисом. У меня не получается сделать геймплей, и как настоящий самурай делаю харакири для своей мечты создать игру.
И зачем ты мне это скинул? Хочешь показать насколько ты крутой программист? Или на сколько я бездарен раз не смог сделать это за 2 дня? В любом случае уже повторяется игра с теннисом. У меня не получается сделать геймплей, и как настоящий самурай делаю харакири для своей мечты создать игру.
>>48630
Ту ситуацию, которая у меня была, я исправил. Был главный класс А, в нем я расположил несколько констант и статических функций. Также класс А создавал объекты класса Б, которые использовали эти константы и стат фунцкии. Ну я их вынес в отдельный класс.
Сейчас у меня конкретной нужды в циклических зависимостях нет. Но в принципе, есть же классические ООП паттерны, где разные классы должны знать друг о друге взаимно.
Ту ситуацию, которая у меня была, я исправил. Был главный класс А, в нем я расположил несколько констант и статических функций. Также класс А создавал объекты класса Б, которые использовали эти константы и стат фунцкии. Ну я их вынес в отдельный класс.
Сейчас у меня конкретной нужды в циклических зависимостях нет. Но в принципе, есть же классические ООП паттерны, где разные классы должны знать друг о друге взаимно.
>>48672
а почему ты хочешь быть человеком-оркестром, кооперируйся с другими программистами и делайте игры
а почему ты хочешь быть человеком-оркестром, кооперируйся с другими программистами и делайте игры
1 Кб, 283x223
211 Кб, 1202x745Совершенствую машину тьюринга, чтобы в каждом состоянии можно было бы проверять много условий и выполнять много команд. Плюс память из нескольких регистров.
>>48659
Спасибо за подробности, буду все пробовать.
Нет, для себя. Под "детской" имею ввиду принцип как у обычных детских расскрасок, картинки можно ведь грузить и сложные\интересные. Был опыт работы(на бэкэнде) с мобильным приложением, со схожей тематикой. В тех расскраках что сейчас есть(на ведре точно, и во многих на иОС) вижу недостатки\недоделки и варианты как их исправить, поэтому хочу попробовать реализовать задумку + есть художник, у которого можно будет оригинальный контент заказывать.
Спасибо за подробности, буду все пробовать.
> Кому-то из знакомых?
Нет, для себя. Под "детской" имею ввиду принцип как у обычных детских расскрасок, картинки можно ведь грузить и сложные\интересные. Был опыт работы(на бэкэнде) с мобильным приложением, со схожей тематикой. В тех расскраках что сейчас есть(на ведре точно, и во многих на иОС) вижу недостатки\недоделки и варианты как их исправить, поэтому хочу попробовать реализовать задумку + есть художник, у которого можно будет оригинальный контент заказывать.
>>48675
Уж разделил на класс-контейнер и класс-фабрику?
Это которые? Я поискал по запросу
Большинство ответов - "как избежать циклических зависимостей", но есть такое:
https://stackoverflow.com/questions/11598055/
Конкретно в Godot, проблема циклической зависимости возникает только если ты в коде явно указываешь что-то, что заставляет парсер пойти прочитать другой скрипт, который возвращает парсер обратно на этот скрипт. Т.е. ты не можешь явно указать это:
Потому что тогда парсер не сможет остановиться, пытаясь разобраться, что на кого указывает.
Но ничто не мешает тебе оперировать ссылками на объекты без точного указания на класс объекта. Можешь указать предка объекта или вообще опустить тип, и интерпретатор не будет иметь проблемы циклической зависимости, т.к. он не бегает по файлам туда-сюда. Если тебе важно, чтобы код не падал с ошибками, можешь делать проверку наличия конкретного метода:
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
Такой приём называется "утиная типизация":
https://en.wikipedia.org/wiki/Duck_typing
Также для нод в Godot есть концепция групп:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-is-in-group
Может пригодиться, если проверка метода не подходит.
>класс А, в нем я расположил несколько констант и статических функций. Также класс А создавал объекты
Уж разделил на класс-контейнер и класс-фабрику?
>классические ООП паттерны, где разные классы должны знать друг о друге взаимно
Это которые? Я поискал по запросу
>oop patterns with circular reference
Большинство ответов - "как избежать циклических зависимостей", но есть такое:
https://stackoverflow.com/questions/11598055/
>Two objects can operate on each other without necessarily referring to each other. In general a circular reference is a case where Class A and B both have a member variable that refers to the other. As implemented in the Wikipedia article there is no circular reference because while the Context stores a reference to the State, the Context is passed into the State as a parameter to a method, and it falls out of scope when the method finishes executing without the State having stored a reference to it.
Конкретно в Godot, проблема циклической зависимости возникает только если ты в коде явно указываешь что-то, что заставляет парсер пойти прочитать другой скрипт, который возвращает парсер обратно на этот скрипт. Т.е. ты не можешь явно указать это:
>class_name ObjA
>var obj: ObjB
>class_name ObjB
>var obj: ObjA
Потому что тогда парсер не сможет остановиться, пытаясь разобраться, что на кого указывает.
Но ничто не мешает тебе оперировать ссылками на объекты без точного указания на класс объекта. Можешь указать предка объекта или вообще опустить тип, и интерпретатор не будет иметь проблемы циклической зависимости, т.к. он не бегает по файлам туда-сюда. Если тебе важно, чтобы код не падал с ошибками, можешь делать проверку наличия конкретного метода:
>func something_a(obj: Reference) -> void:
>_ if obj.has_method("something_b"):
>_ _ obj.something_b(...)
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
Такой приём называется "утиная типизация":
https://en.wikipedia.org/wiki/Duck_typing
Также для нод в Godot есть концепция групп:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-is-in-group
Может пригодиться, если проверка метода не подходит.
>>48675
Уж разделил на класс-контейнер и класс-фабрику?
Это которые? Я поискал по запросу
Большинство ответов - "как избежать циклических зависимостей", но есть такое:
https://stackoverflow.com/questions/11598055/
Конкретно в Godot, проблема циклической зависимости возникает только если ты в коде явно указываешь что-то, что заставляет парсер пойти прочитать другой скрипт, который возвращает парсер обратно на этот скрипт. Т.е. ты не можешь явно указать это:
Потому что тогда парсер не сможет остановиться, пытаясь разобраться, что на кого указывает.
Но ничто не мешает тебе оперировать ссылками на объекты без точного указания на класс объекта. Можешь указать предка объекта или вообще опустить тип, и интерпретатор не будет иметь проблемы циклической зависимости, т.к. он не бегает по файлам туда-сюда. Если тебе важно, чтобы код не падал с ошибками, можешь делать проверку наличия конкретного метода:
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
Такой приём называется "утиная типизация":
https://en.wikipedia.org/wiki/Duck_typing
Также для нод в Godot есть концепция групп:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-is-in-group
Может пригодиться, если проверка метода не подходит.
>класс А, в нем я расположил несколько констант и статических функций. Также класс А создавал объекты
Уж разделил на класс-контейнер и класс-фабрику?
>классические ООП паттерны, где разные классы должны знать друг о друге взаимно
Это которые? Я поискал по запросу
>oop patterns with circular reference
Большинство ответов - "как избежать циклических зависимостей", но есть такое:
https://stackoverflow.com/questions/11598055/
>Two objects can operate on each other without necessarily referring to each other. In general a circular reference is a case where Class A and B both have a member variable that refers to the other. As implemented in the Wikipedia article there is no circular reference because while the Context stores a reference to the State, the Context is passed into the State as a parameter to a method, and it falls out of scope when the method finishes executing without the State having stored a reference to it.
Конкретно в Godot, проблема циклической зависимости возникает только если ты в коде явно указываешь что-то, что заставляет парсер пойти прочитать другой скрипт, который возвращает парсер обратно на этот скрипт. Т.е. ты не можешь явно указать это:
>class_name ObjA
>var obj: ObjB
>class_name ObjB
>var obj: ObjA
Потому что тогда парсер не сможет остановиться, пытаясь разобраться, что на кого указывает.
Но ничто не мешает тебе оперировать ссылками на объекты без точного указания на класс объекта. Можешь указать предка объекта или вообще опустить тип, и интерпретатор не будет иметь проблемы циклической зависимости, т.к. он не бегает по файлам туда-сюда. Если тебе важно, чтобы код не падал с ошибками, можешь делать проверку наличия конкретного метода:
>func something_a(obj: Reference) -> void:
>_ if obj.has_method("something_b"):
>_ _ obj.something_b(...)
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
Такой приём называется "утиная типизация":
https://en.wikipedia.org/wiki/Duck_typing
Также для нод в Godot есть концепция групп:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-is-in-group
Может пригодиться, если проверка метода не подходит.
>>48796
А в чём смысл, если ты взрослый и в компьютерных программах разбираешься? В рисовальном ПО есть инструменты мощнее любых раскрасок, пример:
https://docs.krita.org/en/reference_manual/layers_and_masks/fill_layers.html
Открываешь картинку в Krita и раскрашиваешь по слоям со всякими спецэффектами, можно даже в стиле манги или западных комиксов (сеточкой).
Кстати, Krita же опенсурс (GPL, но вряд ли это как-то влияет на отдельные алгоритмы), можно посмотреть, как реализованы все инструменты в ней:
https://invent.kde.org/graphics/krita
Предлагаю её, потому что... другие просто не пробовал)
Так они же для детей в первую очередь, а детям всё это либо не мешает, либо не нужно, поэтому никто особо не стремится создать идеальную раскраску - ЦА просто не оценит вложенных в разработку усилий.
>Нет, для себя.
А в чём смысл, если ты взрослый и в компьютерных программах разбираешься? В рисовальном ПО есть инструменты мощнее любых раскрасок, пример:
https://docs.krita.org/en/reference_manual/layers_and_masks/fill_layers.html
Открываешь картинку в Krita и раскрашиваешь по слоям со всякими спецэффектами, можно даже в стиле манги или западных комиксов (сеточкой).
Кстати, Krita же опенсурс (GPL, но вряд ли это как-то влияет на отдельные алгоритмы), можно посмотреть, как реализованы все инструменты в ней:
https://invent.kde.org/graphics/krita
Предлагаю её, потому что... другие просто не пробовал)
>В тех расскраках что сейчас есть
>недостатки\недоделки
Так они же для детей в первую очередь, а детям всё это либо не мешает, либо не нужно, поэтому никто особо не стремится создать идеальную раскраску - ЦА просто не оценит вложенных в разработку усилий.
>>48655
Там все довольно просто, писал когда то давно.
Самый простой алгоритм - это просто рекурсия
func floodFill(i, j):
_if i >= 0 and i < width and j >= 0 and j < height and get_pixel(i,j) == oldColor:
__set_pixel(i,j,newColor)
__floodFill(i-1,j);
__floodFill(i+1,j);
__floodFill(i,j-1);
__floodFill(i,j+1);
Но он медленный, и может закончиться память
Есть более быстрые алгоритмы, на порядок, но там надо побольше писать и заводить всякие очереди.
https://en.wikipedia.org/wiki/Flood_fill
Само попиксельное рисование в годоте можно сделать в Image
https://godotengine.org/qa/3804/how-to-edit-an-image-pixels
Вообще есть же пиксельный редактор на годоте, можешь там подсмотреть.
https://github.com/Orama-Interactive/Pixelorama/blob/eb153d11a1d41e599b497947dcd4d5caf6734f0b/src/Tools/Bucket.gd
Насчет скриншотов, кое какой код показывал тут >>44446
Там все довольно просто, писал когда то давно.
Самый простой алгоритм - это просто рекурсия
func floodFill(i, j):
_if i >= 0 and i < width and j >= 0 and j < height and get_pixel(i,j) == oldColor:
__set_pixel(i,j,newColor)
__floodFill(i-1,j);
__floodFill(i+1,j);
__floodFill(i,j-1);
__floodFill(i,j+1);
Но он медленный, и может закончиться память
Есть более быстрые алгоритмы, на порядок, но там надо побольше писать и заводить всякие очереди.
https://en.wikipedia.org/wiki/Flood_fill
Само попиксельное рисование в годоте можно сделать в Image
https://godotengine.org/qa/3804/how-to-edit-an-image-pixels
Вообще есть же пиксельный редактор на годоте, можешь там подсмотреть.
https://github.com/Orama-Interactive/Pixelorama/blob/eb153d11a1d41e599b497947dcd4d5caf6734f0b/src/Tools/Bucket.gd
Насчет скриншотов, кое какой код показывал тут >>44446
>>48672
1. Чтоб ты вдохновился и замотивировался.
2. Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
3. Я ж не знал, что ты такой депрессивный, которому обидно видеть чужой "успех". Реши психические проблемы, а потом делай игры. Я это серьёзно, ты ж себя доводишь до ещё более худшего состояния (говорю по опыту, я допускаю похожие ошибки).
Там нет ничего крутого, весь код можно написать за полчаса, куда больше времени занимает настройка сцен и рисование графики.
Ты не бездарен, ты просто азы программирования осваивать не хочешь, бросаясь реализовывать сравнительно сложные игры для своего уровня.
Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
1. Пользователь жмёт на кнопку (Button).
2. Игра делает что-то из:
2.1. Меняет текст надписи (Button.text, Label.text).
2.2. Меняет свойства кнопки.
2.3. Добавляет другие кнопки, надписи, картинки...
2.4. Перемещает элементы окна, удаляет их и т.д.
2.5. Запускает анимации и т.п.
2.6. И прочее подобное.
3. Игра в сущности состоит из нескольких этапов и заканчивается на последнем этапе или замыкается в бесконечный цикл, т.е. нажатия кнопки на последнем экране появляется экран с первой кнопкой.
Также есть популярные простые игры для практики программирования, вот примеры:
1. "Угадай число" (разные варианты).
2. Крестики-нолики (3x3 для начала).
Честно, не помню дальше, давно это было...
Никакой ты не самурай, а обычный капризный ребёнок (даже если со взрослым телом, гугли инфантилизм), который не оценивает собственные знания и силы объективно, берётся за слишком сложные для его уровня задачи, а потом расстраивается и плачет, что у него не получилось с первой попытки сделать то, для чего нужно долго читать скучные теоретические книги и решать простейшие задачки для практики. Это не оскорбление, если что, ты должен в ответ осознать свою ошибку, признать её и начать работать над её устранением: как минимум, начать изучать программирование с базы, прежде чем переходить к сложным задачам.
>>48754
Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
А навязываться с банальнейшими ошибками?
Вот здесь >>48589, например, интерпретатор говорит тебе ясно и чётко: ты обращаешься к null. Ты знаешь, что такое null? Не знаешь. А должен знать, прежде чем переходить к разработке игр на ООП языке. Это база. Если ты не знаешь, что такое null, почему они возникают и как их избегать, то ты будешь постоянно натыкаться на ошибки с ними и не знать, как эти ошибки исправить. Это будет мучительно и тебе вряд ли будут помогать каждый раз посторонние люди, т.к. эти ошибки банальны и скучны (очевидно, люди в интернете помогают в основном потому, что решать некоторые чужие проблемы интересно). Но если бы ты изучил программирование последовательно, от самых простых концепций к более сложным, то ошибки с null у тебя могли бы возникнуть только из-за невнимательности, и ты всегда бы знал способ их решения (умел искать причину и устранять её), так что тебе даже гуглить не приходилось бы, а тем более было бы стыдно спрашивать о такой тривиальной проблеме на форуме. Но ты галопом по Европам проскакал по нескольким случайным урокам от каких-то случайных чуваков с Ютуба и решил, что сможешь сделать игру, хотя понятия не имеешь, как именно. Конечно, у тебя ничего не получается, ведь ты нарушил главный принцип освоения любой специальности - последовательное получение знаний и усложнение задач, бросившись решать пока что непосильное тебе.
Это как...
...в спортзале взять самую тяжёлую гирю, порвать себе мышцы/кишки и заявить "упражнения - это не моё".
...в кондитерской попытаться изготовить большой свадебный торт, не умея даже разбивать яйца.
...пытаться сшить платье, вообще не разбираясь в шитье, материалах, дизайне одежды и т.д.
Ну ты понял.
>И зачем ты мне это скинул?
1. Чтоб ты вдохновился и замотивировался.
2. Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
3. Я ж не знал, что ты такой депрессивный, которому обидно видеть чужой "успех". Реши психические проблемы, а потом делай игры. Я это серьёзно, ты ж себя доводишь до ещё более худшего состояния (говорю по опыту, я допускаю похожие ошибки).
>показать насколько ты крутой программист
Там нет ничего крутого, весь код можно написать за полчаса, куда больше времени занимает настройка сцен и рисование графики.
>бездарен раз не смог сделать это за 2 дня
Ты не бездарен, ты просто азы программирования осваивать не хочешь, бросаясь реализовывать сравнительно сложные игры для своего уровня.
Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
1. Пользователь жмёт на кнопку (Button).
2. Игра делает что-то из:
2.1. Меняет текст надписи (Button.text, Label.text).
2.2. Меняет свойства кнопки.
2.3. Добавляет другие кнопки, надписи, картинки...
2.4. Перемещает элементы окна, удаляет их и т.д.
2.5. Запускает анимации и т.п.
2.6. И прочее подобное.
3. Игра в сущности состоит из нескольких этапов и заканчивается на последнем этапе или замыкается в бесконечный цикл, т.е. нажатия кнопки на последнем экране появляется экран с первой кнопкой.
Также есть популярные простые игры для практики программирования, вот примеры:
1. "Угадай число" (разные варианты).
2. Крестики-нолики (3x3 для начала).
Честно, не помню дальше, давно это было...
>У меня не получается сделать геймплей, и как настоящий самурай делаю харакири для своей мечты создать игру.
Никакой ты не самурай, а обычный капризный ребёнок (даже если со взрослым телом, гугли инфантилизм), который не оценивает собственные знания и силы объективно, берётся за слишком сложные для его уровня задачи, а потом расстраивается и плачет, что у него не получилось с первой попытки сделать то, для чего нужно долго читать скучные теоретические книги и решать простейшие задачки для практики. Это не оскорбление, если что, ты должен в ответ осознать свою ошибку, признать её и начать работать над её устранением: как минимум, начать изучать программирование с базы, прежде чем переходить к сложным задачам.
>>48754
>>Моя идея будет нужна только мне!
Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
>Навязывать человеку работу над своим проектом желания не имею.
А навязываться с банальнейшими ошибками?
Вот здесь >>48589, например, интерпретатор говорит тебе ясно и чётко: ты обращаешься к null. Ты знаешь, что такое null? Не знаешь. А должен знать, прежде чем переходить к разработке игр на ООП языке. Это база. Если ты не знаешь, что такое null, почему они возникают и как их избегать, то ты будешь постоянно натыкаться на ошибки с ними и не знать, как эти ошибки исправить. Это будет мучительно и тебе вряд ли будут помогать каждый раз посторонние люди, т.к. эти ошибки банальны и скучны (очевидно, люди в интернете помогают в основном потому, что решать некоторые чужие проблемы интересно). Но если бы ты изучил программирование последовательно, от самых простых концепций к более сложным, то ошибки с null у тебя могли бы возникнуть только из-за невнимательности, и ты всегда бы знал способ их решения (умел искать причину и устранять её), так что тебе даже гуглить не приходилось бы, а тем более было бы стыдно спрашивать о такой тривиальной проблеме на форуме. Но ты галопом по Европам проскакал по нескольким случайным урокам от каких-то случайных чуваков с Ютуба и решил, что сможешь сделать игру, хотя понятия не имеешь, как именно. Конечно, у тебя ничего не получается, ведь ты нарушил главный принцип освоения любой специальности - последовательное получение знаний и усложнение задач, бросившись решать пока что непосильное тебе.
Это как...
...в спортзале взять самую тяжёлую гирю, порвать себе мышцы/кишки и заявить "упражнения - это не моё".
...в кондитерской попытаться изготовить большой свадебный торт, не умея даже разбивать яйца.
...пытаться сшить платье, вообще не разбираясь в шитье, материалах, дизайне одежды и т.д.
Ну ты понял.
>>48672
1. Чтоб ты вдохновился и замотивировался.
2. Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
3. Я ж не знал, что ты такой депрессивный, которому обидно видеть чужой "успех". Реши психические проблемы, а потом делай игры. Я это серьёзно, ты ж себя доводишь до ещё более худшего состояния (говорю по опыту, я допускаю похожие ошибки).
Там нет ничего крутого, весь код можно написать за полчаса, куда больше времени занимает настройка сцен и рисование графики.
Ты не бездарен, ты просто азы программирования осваивать не хочешь, бросаясь реализовывать сравнительно сложные игры для своего уровня.
Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
1. Пользователь жмёт на кнопку (Button).
2. Игра делает что-то из:
2.1. Меняет текст надписи (Button.text, Label.text).
2.2. Меняет свойства кнопки.
2.3. Добавляет другие кнопки, надписи, картинки...
2.4. Перемещает элементы окна, удаляет их и т.д.
2.5. Запускает анимации и т.п.
2.6. И прочее подобное.
3. Игра в сущности состоит из нескольких этапов и заканчивается на последнем этапе или замыкается в бесконечный цикл, т.е. нажатия кнопки на последнем экране появляется экран с первой кнопкой.
Также есть популярные простые игры для практики программирования, вот примеры:
1. "Угадай число" (разные варианты).
2. Крестики-нолики (3x3 для начала).
Честно, не помню дальше, давно это было...
Никакой ты не самурай, а обычный капризный ребёнок (даже если со взрослым телом, гугли инфантилизм), который не оценивает собственные знания и силы объективно, берётся за слишком сложные для его уровня задачи, а потом расстраивается и плачет, что у него не получилось с первой попытки сделать то, для чего нужно долго читать скучные теоретические книги и решать простейшие задачки для практики. Это не оскорбление, если что, ты должен в ответ осознать свою ошибку, признать её и начать работать над её устранением: как минимум, начать изучать программирование с базы, прежде чем переходить к сложным задачам.
>>48754
Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
А навязываться с банальнейшими ошибками?
Вот здесь >>48589, например, интерпретатор говорит тебе ясно и чётко: ты обращаешься к null. Ты знаешь, что такое null? Не знаешь. А должен знать, прежде чем переходить к разработке игр на ООП языке. Это база. Если ты не знаешь, что такое null, почему они возникают и как их избегать, то ты будешь постоянно натыкаться на ошибки с ними и не знать, как эти ошибки исправить. Это будет мучительно и тебе вряд ли будут помогать каждый раз посторонние люди, т.к. эти ошибки банальны и скучны (очевидно, люди в интернете помогают в основном потому, что решать некоторые чужие проблемы интересно). Но если бы ты изучил программирование последовательно, от самых простых концепций к более сложным, то ошибки с null у тебя могли бы возникнуть только из-за невнимательности, и ты всегда бы знал способ их решения (умел искать причину и устранять её), так что тебе даже гуглить не приходилось бы, а тем более было бы стыдно спрашивать о такой тривиальной проблеме на форуме. Но ты галопом по Европам проскакал по нескольким случайным урокам от каких-то случайных чуваков с Ютуба и решил, что сможешь сделать игру, хотя понятия не имеешь, как именно. Конечно, у тебя ничего не получается, ведь ты нарушил главный принцип освоения любой специальности - последовательное получение знаний и усложнение задач, бросившись решать пока что непосильное тебе.
Это как...
...в спортзале взять самую тяжёлую гирю, порвать себе мышцы/кишки и заявить "упражнения - это не моё".
...в кондитерской попытаться изготовить большой свадебный торт, не умея даже разбивать яйца.
...пытаться сшить платье, вообще не разбираясь в шитье, материалах, дизайне одежды и т.д.
Ну ты понял.
>И зачем ты мне это скинул?
1. Чтоб ты вдохновился и замотивировался.
2. Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
3. Я ж не знал, что ты такой депрессивный, которому обидно видеть чужой "успех". Реши психические проблемы, а потом делай игры. Я это серьёзно, ты ж себя доводишь до ещё более худшего состояния (говорю по опыту, я допускаю похожие ошибки).
>показать насколько ты крутой программист
Там нет ничего крутого, весь код можно написать за полчаса, куда больше времени занимает настройка сцен и рисование графики.
>бездарен раз не смог сделать это за 2 дня
Ты не бездарен, ты просто азы программирования осваивать не хочешь, бросаясь реализовывать сравнительно сложные игры для своего уровня.
Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
1. Пользователь жмёт на кнопку (Button).
2. Игра делает что-то из:
2.1. Меняет текст надписи (Button.text, Label.text).
2.2. Меняет свойства кнопки.
2.3. Добавляет другие кнопки, надписи, картинки...
2.4. Перемещает элементы окна, удаляет их и т.д.
2.5. Запускает анимации и т.п.
2.6. И прочее подобное.
3. Игра в сущности состоит из нескольких этапов и заканчивается на последнем этапе или замыкается в бесконечный цикл, т.е. нажатия кнопки на последнем экране появляется экран с первой кнопкой.
Также есть популярные простые игры для практики программирования, вот примеры:
1. "Угадай число" (разные варианты).
2. Крестики-нолики (3x3 для начала).
Честно, не помню дальше, давно это было...
>У меня не получается сделать геймплей, и как настоящий самурай делаю харакири для своей мечты создать игру.
Никакой ты не самурай, а обычный капризный ребёнок (даже если со взрослым телом, гугли инфантилизм), который не оценивает собственные знания и силы объективно, берётся за слишком сложные для его уровня задачи, а потом расстраивается и плачет, что у него не получилось с первой попытки сделать то, для чего нужно долго читать скучные теоретические книги и решать простейшие задачки для практики. Это не оскорбление, если что, ты должен в ответ осознать свою ошибку, признать её и начать работать над её устранением: как минимум, начать изучать программирование с базы, прежде чем переходить к сложным задачам.
>>48754
>>Моя идея будет нужна только мне!
Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
>Навязывать человеку работу над своим проектом желания не имею.
А навязываться с банальнейшими ошибками?
Вот здесь >>48589, например, интерпретатор говорит тебе ясно и чётко: ты обращаешься к null. Ты знаешь, что такое null? Не знаешь. А должен знать, прежде чем переходить к разработке игр на ООП языке. Это база. Если ты не знаешь, что такое null, почему они возникают и как их избегать, то ты будешь постоянно натыкаться на ошибки с ними и не знать, как эти ошибки исправить. Это будет мучительно и тебе вряд ли будут помогать каждый раз посторонние люди, т.к. эти ошибки банальны и скучны (очевидно, люди в интернете помогают в основном потому, что решать некоторые чужие проблемы интересно). Но если бы ты изучил программирование последовательно, от самых простых концепций к более сложным, то ошибки с null у тебя могли бы возникнуть только из-за невнимательности, и ты всегда бы знал способ их решения (умел искать причину и устранять её), так что тебе даже гуглить не приходилось бы, а тем более было бы стыдно спрашивать о такой тривиальной проблеме на форуме. Но ты галопом по Европам проскакал по нескольким случайным урокам от каких-то случайных чуваков с Ютуба и решил, что сможешь сделать игру, хотя понятия не имеешь, как именно. Конечно, у тебя ничего не получается, ведь ты нарушил главный принцип освоения любой специальности - последовательное получение знаний и усложнение задач, бросившись решать пока что непосильное тебе.
Это как...
...в спортзале взять самую тяжёлую гирю, порвать себе мышцы/кишки и заявить "упражнения - это не моё".
...в кондитерской попытаться изготовить большой свадебный торт, не умея даже разбивать яйца.
...пытаться сшить платье, вообще не разбираясь в шитье, материалах, дизайне одежды и т.д.
Ну ты понял.
73 Кб, 1108x532>>48805
Там пишут, что это не считается за циклическую ссылку, потому что Контекст содержит ссылку на Стейт, а Стейт получает ссылку на Контекст только как параметр функции. Но в гдскрипте такое не прокатывает. Вообще получается в двух классах имен друг друга упоминать нельзя.
Ну я понял, надо это утиной типизацией обходить. Но конечно непривычно, не знаю даже в каком из популярных языков такое ограничение есть.
> Большинство ответов - "как избежать циклических зависимостей", но есть такое:
Там пишут, что это не считается за циклическую ссылку, потому что Контекст содержит ссылку на Стейт, а Стейт получает ссылку на Контекст только как параметр функции. Но в гдскрипте такое не прокатывает. Вообще получается в двух классах имен друг друга упоминать нельзя.
Ну я понял, надо это утиной типизацией обходить. Но конечно непривычно, не знаю даже в каком из популярных языков такое ограничение есть.
>>48816
Я в спортзал ходил, так у меня желудок болеть стал. Хотя я там самую тяжелую гирю не тягал, тетеньки больше меня поднимали. Я ночами заснуть не мог, были боли и отрыжка. После гастроскопии сказали, что гастрит обострился. Пропил прописанное лекарство, сделал перерыв и вернулся в зал, еще сильнее ослабив нагрузки. Но в течении года мне все равно периодически херово становилось после тренировок. Плюс еще коленка заболела. Я заявил, что "упражнения - это не моё", и бросил.
другой
Я в спортзал ходил, так у меня желудок болеть стал. Хотя я там самую тяжелую гирю не тягал, тетеньки больше меня поднимали. Я ночами заснуть не мог, были боли и отрыжка. После гастроскопии сказали, что гастрит обострился. Пропил прописанное лекарство, сделал перерыв и вернулся в зал, еще сильнее ослабив нагрузки. Но в течении года мне все равно периодически херово становилось после тренировок. Плюс еще коленка заболела. Я заявил, что "упражнения - это не моё", и бросил.
другой
23 Кб, 1116x633>>48822
Вроде бы в GDScript 2.0 можно, но я не совсем понял:
https://github.com/godotengine/godot/pull/67714
Может, мы говорим о cyclic definition?
В Object Pascal вот так можно решить: в интерфейсной части второго модуля заявить, что ожидаешь предка TObject, а в части имплементации делать проверку, что полученный TObject на самом деле TContext, потому что часть имплементации может обращаться к ContextUnit (в интерфейсной части такое обращение приведёт к ошибке компиляции). Таким образом можно точно убедиться, с кем работаешь, а не гадать по наличию методов.
Вот ещё что нашёл:
https://softwareengineering.stackexchange.com/questions/11856
>Вообще получается в двух классах имен друг друга упоминать нельзя.
Вроде бы в GDScript 2.0 можно, но я не совсем понял:
https://github.com/godotengine/godot/pull/67714
>Please note: cyclic references (RefCounted-related issue), cyclic dependencies (a bug in GDScript) and cyclic definitions/calls (a user error, not a GDScript bug) are different things.
Может, мы говорим о cyclic definition?
В Object Pascal вот так можно решить: в интерфейсной части второго модуля заявить, что ожидаешь предка TObject, а в части имплементации делать проверку, что полученный TObject на самом деле TContext, потому что часть имплементации может обращаться к ContextUnit (в интерфейсной части такое обращение приведёт к ошибке компиляции). Таким образом можно точно убедиться, с кем работаешь, а не гадать по наличию методов.
Вот ещё что нашёл:
https://softwareengineering.stackexchange.com/questions/11856
>Circular references in general are simply confusing and drastically increase the cognitive load when attempting to understand how a program functions.
>Please, think of the children; avoid circular references whenever you can.
>>48841
Порнушные картинки? Всё равно непонятно, в чём преимущество по сравнению с редактором графики.
Если только тебе доставляет сам процесс виртуального раскрашивания настолько, что ты хочешь делать это в дороге на смартфоне, не мучаясь со сложными мобильными редакторами графики, хотя, я уверен, даже у мобильных редакторов уже есть режим умной заливки (как минимум игнорировать JPG-артефакты должны уже уметь, это же самая важная фича, когда работаешь с чужой картинкой из интернета). Если не смартфон, а планшетный компьютер, то полноценные редакторы вроде Krita можно запускать на Android.
>>48842
Я с самого начала его упоминал и уже кидал ссылку на Википедию. Учитывай только, что наивная реализация (как в пейнте) игнорирует полупрозрачные пиксели, поэтому сглаженные контуры будут очень некрасиво заливаться, а JPG-артефакты вообще будут непреодолимой помехой. Следовательно, нужно не простое ведёрко, а с порогом похожести цвета, или какая-то предварительная подготовка изображения (заранее вырезать белый цвет и размещать контур поверх заливаемой области, чтобы контур не портился заливкой и выглядел красиво - так делают художники при рисовании на нескольких слоях - контуры на слое выше цветов).
>Я же смотрю в сторону другой ЦА.
Порнушные картинки? Всё равно непонятно, в чём преимущество по сравнению с редактором графики.
Если только тебе доставляет сам процесс виртуального раскрашивания настолько, что ты хочешь делать это в дороге на смартфоне, не мучаясь со сложными мобильными редакторами графики, хотя, я уверен, даже у мобильных редакторов уже есть режим умной заливки (как минимум игнорировать JPG-артефакты должны уже уметь, это же самая важная фича, когда работаешь с чужой картинкой из интернета). Если не смартфон, а планшетный компьютер, то полноценные редакторы вроде Krita можно запускать на Android.
>>48842
>Flood fill
Я с самого начала его упоминал и уже кидал ссылку на Википедию. Учитывай только, что наивная реализация (как в пейнте) игнорирует полупрозрачные пиксели, поэтому сглаженные контуры будут очень некрасиво заливаться, а JPG-артефакты вообще будут непреодолимой помехой. Следовательно, нужно не простое ведёрко, а с порогом похожести цвета, или какая-то предварительная подготовка изображения (заранее вырезать белый цвет и размещать контур поверх заливаемой области, чтобы контур не портился заливкой и выглядел красиво - так делают художники при рисовании на нескольких слоях - контуры на слое выше цветов).
>>48843
Чего вдруг порно? Расскрашивание картинок в дороге, перед сном и т.п.
Безусловно картинку буду изначально подготавливать, очищая ее от мусора.
Чего вдруг порно? Расскрашивание картинок в дороге, перед сном и т.п.
Безусловно картинку буду изначально подготавливать, очищая ее от мусора.
>>48816
Уже есть вдохновитель который заставляет меня восхищаться, завидовать, и страдать.
Ты уже с ходу записал меня в пропагандистов. Если человек предвзят к тебе благодаря своей шизофрении, у него глупо просить чего либо.
Хвастовство не успех. Стандартное избиение лежачего.
Ты можешь написать этот код за пол часа. Мне он не поддался после двух дневного поиска ответов. Где из поставленной задачи единственное что мне удалось, покраснение врага при клике. За два дня...
Как раз я осознаю насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
Наш мир жесток. Если ребенок не научился к пяти годам говорить, ему на всю жизнь ставят диагноз аутизм. Он ничего с этим уже не поделает, может попытать счастье переродившись!
Какая к чёрту база? Открывая документацию по представлению разработчиков, я уже был обязан все знать. Потому что в ней ничего не понятно! Весь код разложен на разные столбцы, которые для примера соединяются только в конце бессмысленного доклада. Вбивая в поиске про ввод мышкой знаешь что мне удалось найти? Ничего! Благо я понял что поиск на этом сайте не работает постоянно, проще вбивать в гугл, и тогда первая ссылка с ответом будет параша docs.godotengine.org
Или мне на курсы Григорина записаться? Быть очередным дебилом который лучше бы дома сидел и яйца чесал.
Это была самой легкой задачей! Костяк геймплея раскрутив который можно было создать хорошую игру. Самое простое, которое не требует по сути ничего! И то всрато криворуким тугодумом.
Что ты хочешь услышать? Молодец! Крутой прототип! Мне понравилось! Идея с шариками хоть и детская, но отдаёт Кодзимой.
Моему другу придётся заставлять себя искать причину для отказа. На борде в любой момент тебя проигнорируют и скинут в утиль.
Я не буду это перечитывать третий раз. С этим куском полностью согласен.
Аналогии говно! >>48825 Это куда больше подходить в нынешней ситуации.
Попробовал! Нашёл парочку гайдов на крестики нолики. и понял что они делают их не с помощью разных переменных или другой штуки, я не знаю ваших понятий. перебором пишут в коде что будет если так, что будет если этак. Обучаясь основам только ещё больше буду делать ошибок, и место продвижения простого концепта, у меня будет сотня крестиков ноликов.
Но несмотря на это я решил выдавить из себя хоть капельку кода. Потратив его на программирование кнопок по гайду создающему меню... Не работает! Ничего не работает! Две строчки кода! Ноль ошибок! Не могу зайти! Не могу выйти!
Мне нравится godot своим дизайном. Тем что на нём много интересных плагинов которые могут украсить любой проект, удобный интерфейс. К сожалению, мы страдаем друг от друга.
>Чтоб ты вдохновился и замотивировался.
Уже есть вдохновитель который заставляет меня восхищаться, завидовать, и страдать.
>Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
Ты уже с ходу записал меня в пропагандистов. Если человек предвзят к тебе благодаря своей шизофрении, у него глупо просить чего либо.
>которому обидно видеть чужой "успех"
Хвастовство не успех. Стандартное избиение лежачего.
>весь код можно написать за полчаса
Ты можешь написать этот код за пол часа. Мне он не поддался после двух дневного поиска ответов. Где из поставленной задачи единственное что мне удалось, покраснение врага при клике. За два дня...
>который не оценивает собственные знания и силы объективно
Как раз я осознаю насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
>берётся за слишком сложные для его уровня задачи
Наш мир жесток. Если ребенок не научился к пяти годам говорить, ему на всю жизнь ставят диагноз аутизм. Он ничего с этим уже не поделает, может попытать счастье переродившись!
>начать изучать программирование с базы, прежде чем переходить к сложным задачам.
Какая к чёрту база? Открывая документацию по представлению разработчиков, я уже был обязан все знать. Потому что в ней ничего не понятно! Весь код разложен на разные столбцы, которые для примера соединяются только в конце бессмысленного доклада. Вбивая в поиске про ввод мышкой знаешь что мне удалось найти? Ничего! Благо я понял что поиск на этом сайте не работает постоянно, проще вбивать в гугл, и тогда первая ссылка с ответом будет параша docs.godotengine.org
>программирование с базы
Или мне на курсы Григорина записаться? Быть очередным дебилом который лучше бы дома сидел и яйца чесал.
>переходить к сложным задачам
Это была самой легкой задачей! Костяк геймплея раскрутив который можно было создать хорошую игру. Самое простое, которое не требует по сути ничего! И то всрато криворуким тугодумом.
>Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
Что ты хочешь услышать? Молодец! Крутой прототип! Мне понравилось! Идея с шариками хоть и детская, но отдаёт Кодзимой.
>А навязываться с банальнейшими ошибками?
Моему другу придётся заставлять себя искать причину для отказа. На борде в любой момент тебя проигнорируют и скинут в утиль.
>Вот здесь >>48589 (You), например, интерпретатор говорит тебе ясно и чётко
Я не буду это перечитывать третий раз. С этим куском полностью согласен.
>Это как...
Аналогии говно! >>48825 Это куда больше подходить в нынешней ситуации.
>Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
Попробовал! Нашёл парочку гайдов на крестики нолики. и понял что они делают их не с помощью разных переменных или другой штуки, я не знаю ваших понятий. перебором пишут в коде что будет если так, что будет если этак. Обучаясь основам только ещё больше буду делать ошибок, и место продвижения простого концепта, у меня будет сотня крестиков ноликов.
Но несмотря на это я решил выдавить из себя хоть капельку кода. Потратив его на программирование кнопок по гайду создающему меню... Не работает! Ничего не работает! Две строчки кода! Ноль ошибок! Не могу зайти! Не могу выйти!
Мне нравится godot своим дизайном. Тем что на нём много интересных плагинов которые могут украсить любой проект, удобный интерфейс. К сожалению, мы страдаем друг от друга.
>>48816
Уже есть вдохновитель который заставляет меня восхищаться, завидовать, и страдать.
Ты уже с ходу записал меня в пропагандистов. Если человек предвзят к тебе благодаря своей шизофрении, у него глупо просить чего либо.
Хвастовство не успех. Стандартное избиение лежачего.
Ты можешь написать этот код за пол часа. Мне он не поддался после двух дневного поиска ответов. Где из поставленной задачи единственное что мне удалось, покраснение врага при клике. За два дня...
Как раз я осознаю насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
Наш мир жесток. Если ребенок не научился к пяти годам говорить, ему на всю жизнь ставят диагноз аутизм. Он ничего с этим уже не поделает, может попытать счастье переродившись!
Какая к чёрту база? Открывая документацию по представлению разработчиков, я уже был обязан все знать. Потому что в ней ничего не понятно! Весь код разложен на разные столбцы, которые для примера соединяются только в конце бессмысленного доклада. Вбивая в поиске про ввод мышкой знаешь что мне удалось найти? Ничего! Благо я понял что поиск на этом сайте не работает постоянно, проще вбивать в гугл, и тогда первая ссылка с ответом будет параша docs.godotengine.org
Или мне на курсы Григорина записаться? Быть очередным дебилом который лучше бы дома сидел и яйца чесал.
Это была самой легкой задачей! Костяк геймплея раскрутив который можно было создать хорошую игру. Самое простое, которое не требует по сути ничего! И то всрато криворуким тугодумом.
Что ты хочешь услышать? Молодец! Крутой прототип! Мне понравилось! Идея с шариками хоть и детская, но отдаёт Кодзимой.
Моему другу придётся заставлять себя искать причину для отказа. На борде в любой момент тебя проигнорируют и скинут в утиль.
Я не буду это перечитывать третий раз. С этим куском полностью согласен.
Аналогии говно! >>48825 Это куда больше подходить в нынешней ситуации.
Попробовал! Нашёл парочку гайдов на крестики нолики. и понял что они делают их не с помощью разных переменных или другой штуки, я не знаю ваших понятий. перебором пишут в коде что будет если так, что будет если этак. Обучаясь основам только ещё больше буду делать ошибок, и место продвижения простого концепта, у меня будет сотня крестиков ноликов.
Но несмотря на это я решил выдавить из себя хоть капельку кода. Потратив его на программирование кнопок по гайду создающему меню... Не работает! Ничего не работает! Две строчки кода! Ноль ошибок! Не могу зайти! Не могу выйти!
Мне нравится godot своим дизайном. Тем что на нём много интересных плагинов которые могут украсить любой проект, удобный интерфейс. К сожалению, мы страдаем друг от друга.
>Чтоб ты вдохновился и замотивировался.
Уже есть вдохновитель который заставляет меня восхищаться, завидовать, и страдать.
>Я думал, что ты начнёшь выпрашивать код или задавать какие-то вопросы по реализации.
Ты уже с ходу записал меня в пропагандистов. Если человек предвзят к тебе благодаря своей шизофрении, у него глупо просить чего либо.
>которому обидно видеть чужой "успех"
Хвастовство не успех. Стандартное избиение лежачего.
>весь код можно написать за полчаса
Ты можешь написать этот код за пол часа. Мне он не поддался после двух дневного поиска ответов. Где из поставленной задачи единственное что мне удалось, покраснение врага при клике. За два дня...
>который не оценивает собственные знания и силы объективно
Как раз я осознаю насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
>берётся за слишком сложные для его уровня задачи
Наш мир жесток. Если ребенок не научился к пяти годам говорить, ему на всю жизнь ставят диагноз аутизм. Он ничего с этим уже не поделает, может попытать счастье переродившись!
>начать изучать программирование с базы, прежде чем переходить к сложным задачам.
Какая к чёрту база? Открывая документацию по представлению разработчиков, я уже был обязан все знать. Потому что в ней ничего не понятно! Весь код разложен на разные столбцы, которые для примера соединяются только в конце бессмысленного доклада. Вбивая в поиске про ввод мышкой знаешь что мне удалось найти? Ничего! Благо я понял что поиск на этом сайте не работает постоянно, проще вбивать в гугл, и тогда первая ссылка с ответом будет параша docs.godotengine.org
>программирование с базы
Или мне на курсы Григорина записаться? Быть очередным дебилом который лучше бы дома сидел и яйца чесал.
>переходить к сложным задачам
Это была самой легкой задачей! Костяк геймплея раскрутив который можно было создать хорошую игру. Самое простое, которое не требует по сути ничего! И то всрато криворуким тугодумом.
>Ну вот видишь, твоя идея привлекла моё внимание и я на скорую руку слепил прототип, с учётом своих собственных идей (не всех).
Что ты хочешь услышать? Молодец! Крутой прототип! Мне понравилось! Идея с шариками хоть и детская, но отдаёт Кодзимой.
>А навязываться с банальнейшими ошибками?
Моему другу придётся заставлять себя искать причину для отказа. На борде в любой момент тебя проигнорируют и скинут в утиль.
>Вот здесь >>48589 (You), например, интерпретатор говорит тебе ясно и чётко
Я не буду это перечитывать третий раз. С этим куском полностью согласен.
>Это как...
Аналогии говно! >>48825 Это куда больше подходить в нынешней ситуации.
>Попробуй реализовать игру с единственной кнопкой, типа тех, что были популярны в эпоху флеша:
Попробовал! Нашёл парочку гайдов на крестики нолики. и понял что они делают их не с помощью разных переменных или другой штуки, я не знаю ваших понятий. перебором пишут в коде что будет если так, что будет если этак. Обучаясь основам только ещё больше буду делать ошибок, и место продвижения простого концепта, у меня будет сотня крестиков ноликов.
Но несмотря на это я решил выдавить из себя хоть капельку кода. Потратив его на программирование кнопок по гайду создающему меню... Не работает! Ничего не работает! Две строчки кода! Ноль ошибок! Не могу зайти! Не могу выйти!
Мне нравится godot своим дизайном. Тем что на нём много интересных плагинов которые могут украсить любой проект, удобный интерфейс. К сожалению, мы страдаем друг от друга.
Поясните за правильное, Хуаном одобренное преобразование экранных координат в геймплейные с учётом дебильной Camera2D, которая по какой-то причине не хочет преобразовывать координаты сама. Вот в 3D есть методы чтобы чётко взять и получить координаты мыши относительно 3D объектов с учётом настроек Camera, а в 2D такого что-то вообще не вижу. У меня все способы получения позиции мыши выдают, что (0;0) - это левый верхний угол, независимо от положения Camera2D. Мне что, вручную каждый раз получать размер окна, делить его на два, затем складывать со смещением игрока и т.д.? Выглядит как костыль, который будет баговать в случае, если я включу в камере плавный сдвиг. Странно, что нет одной готовой функции "получить координаты мыши относительно 2D мира (а не окна)". Или есть, а я не вижу?
>>48868
А, блин, только написал вопрос и сразу нашёл, лол.
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-get-global-mouse-position
А, блин, только написал вопрос и сразу нашёл, лол.
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-get-global-mouse-position
54 Кб, 1446x1089>>48852
Не нужно драматизировать.
Ты в курсе вообще, какой год? У нас уже почти год из всех щелей нахрюки информационной войны, да, и в этом разделе тоже регулярно всплывало, просто большую часть своевременно чистили. А ты тут со своим "танчики наступают", естественно меня триггернуло, тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня". Адекватный человек найдёт учебники по программированию и всему сам обучится, а школьники из /po/ ничего не умеют и уметь не хотят, кроме как боевыми картиночками кидаться.
Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге, прежде чем освоил все базовые темы, не считая ООП, который я осваивал много позже и по другой книге. А ты хочешь за два дня всему научиться методом слепого тыка и копипасты из интернета. Алсо, я так и не доделал ни одной полноценной игры, некоторые заготовки много месяцев ковырял и ни к чему достойному не пришёл. Так что не разочаровывайся так, два дня попыток - это сущий пустяк для ньюфага в геймдеве. Главное, что ты получил какой-то опыт за эти два дня, что-то узнал и понял.
Вылечи депрессию и всплывёшь.
Программирование не относится к таким навыкам, программированию можно и в старости научиться. Да, будет сложнее, но если иметь желание и усидчивость, то всё обязательно получится.
Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке.
Godot рассчитан на лёгкое освоение, но не заточен на детей с задержками в развитии. Если тебе нужно что-то совсем простое, попробуй конструкторы игр вроде GameMaker и ему подобных, там тебе будут пиктограммы и задачки уровня вставить кубик в квадратную дырку. А Godot - это для подросших детей, которые уже более-менее уверенно чувствуют себя за компьютером и не боятся трудностей, а также умеют читать и писать.
Конкретно по документации, она разделена на две части: туториалы (уроки) и API Reference (справка по движку). Второе доступно изнутри самого движка по кнопке F1. Туториалы разделены на несколько уровней сложности, но они, тем не менее, подразумевают, что ты кое-что уже понимаешь в программировании. Есть отдельные, сторонние туториалы для полных нулей в программировании - вот они тебе, скорее всего, и нужны, судя по твоему нытью.
Попробуй это, тут даже интерактивно всё:
https://gdquest.itch.io/learn-godot-gdscript
Не нужны, программирование легко осваивается по классическим текстовым книгам. Но если ты зумер, то, возможно, видосики тебе и правда зайдут. Можешь скачать какой-нибудь видеокурс с торрентов, их очень часто сливают и всем насрать, что ты это скачаешь.
У тебя какая такая болезнь, которая мешает тебе усидчиво осваивать программирование? Вангую, у тебя СДВГ, из-за которого ты не можешь сфокусироваться на одной задаче и скачешь, а потом удивляешься, почему ничего не понял. Плюс, судя по твоим постам, у тебя ещё и депрессия или как минимум крайне заниженная самооценка, которая рано или поздно доведёт до депрессии. Лечись давай, я не знаю, к психотерапевту сходи, а потом будешь шедевры геймдева создавать за два дня.
Вот если ты основам научишься и набьёшь шишки на всех возможных граблях, делая сотню "крестиков-ноликов", то потом сможешь без проблем продвигать любые свои концепты. А пока ты пытаешься "продвигать концепты" без системных знаний, ты тупо делаешь кучу ошибок и ничего в результате не достигаешь, разочаровываясь в себе и своих силах.
Смотри пикрил и читай статью:
https://ru.wikipedia.org/wiki/Поток_(психология)
Состояние потока - лучшее переживание в жизни любого человека, но чтобы его достичь, твои задачи должны соответствовать твоим навыкам. Если задачи слишком просты, ты заскучаешь, а если задачи слишком сложны, ты будешь беспокоиться, испытывать стресс и разочарование. Вот ты сейчас берёшь слишком сложные конкретно для тебя задачи - тебе нужно повысить навыки, даже если повышение навыков кажется тебе слишком скучным.
В первой функции у тебя опечатка:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-change-scene
Однако, судя по тому, что у тебя
Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены. Выбираешь в списке сигналов сигнал "pressed", нажимаешь connect и в открывшемся меню выбираешь свой скрипт - только тогда в появившемся методе с зелёной стрелочкой слева (на линейке) пишешь код из примера. Это не единственный способ подключения обработчиков сигнала, но в случае с GUI он чаще всего используется (другой способ - вызов connect(), чаще всего нужен для создания динамических связей при процедурной генерации части уровня, типа врагов и т.п.).
>завидовать и страдать
Не нужно драматизировать.
>предвзят к тебе благодаря своей шизофрении
Ты в курсе вообще, какой год? У нас уже почти год из всех щелей нахрюки информационной войны, да, и в этом разделе тоже регулярно всплывало, просто большую часть своевременно чистили. А ты тут со своим "танчики наступают", естественно меня триггернуло, тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня". Адекватный человек найдёт учебники по программированию и всему сам обучится, а школьники из /po/ ничего не умеют и уметь не хотят, кроме как боевыми картиночками кидаться.
>За два дня...
Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге, прежде чем освоил все базовые темы, не считая ООП, который я осваивал много позже и по другой книге. А ты хочешь за два дня всему научиться методом слепого тыка и копипасты из интернета. Алсо, я так и не доделал ни одной полноценной игры, некоторые заготовки много месяцев ковырял и ни к чему достойному не пришёл. Так что не разочаровывайся так, два дня попыток - это сущий пустяк для ньюфага в геймдеве. Главное, что ты получил какой-то опыт за эти два дня, что-то узнал и понял.
>насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
Вылечи депрессию и всплывёшь.
>не научился к пяти годам
>Он ничего с этим уже не поделает
Программирование не относится к таким навыкам, программированию можно и в старости научиться. Да, будет сложнее, но если иметь желание и усидчивость, то всё обязательно получится.
>Какая к чёрту база?
Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке.
>Открывая документацию по представлению разработчиков, я уже был обязан все знать.
Godot рассчитан на лёгкое освоение, но не заточен на детей с задержками в развитии. Если тебе нужно что-то совсем простое, попробуй конструкторы игр вроде GameMaker и ему подобных, там тебе будут пиктограммы и задачки уровня вставить кубик в квадратную дырку. А Godot - это для подросших детей, которые уже более-менее уверенно чувствуют себя за компьютером и не боятся трудностей, а также умеют читать и писать.
Конкретно по документации, она разделена на две части: туториалы (уроки) и API Reference (справка по движку). Второе доступно изнутри самого движка по кнопке F1. Туториалы разделены на несколько уровней сложности, но они, тем не менее, подразумевают, что ты кое-что уже понимаешь в программировании. Есть отдельные, сторонние туториалы для полных нулей в программировании - вот они тебе, скорее всего, и нужны, судя по твоему нытью.
Попробуй это, тут даже интерактивно всё:
https://gdquest.itch.io/learn-godot-gdscript
>курсы
Не нужны, программирование легко осваивается по классическим текстовым книгам. Но если ты зумер, то, возможно, видосики тебе и правда зайдут. Можешь скачать какой-нибудь видеокурс с торрентов, их очень часто сливают и всем насрать, что ты это скачаешь.
>Это куда больше подходить в нынешней ситуации.
У тебя какая такая болезнь, которая мешает тебе усидчиво осваивать программирование? Вангую, у тебя СДВГ, из-за которого ты не можешь сфокусироваться на одной задаче и скачешь, а потом удивляешься, почему ничего не понял. Плюс, судя по твоим постам, у тебя ещё и депрессия или как минимум крайне заниженная самооценка, которая рано или поздно доведёт до депрессии. Лечись давай, я не знаю, к психотерапевту сходи, а потом будешь шедевры геймдева создавать за два дня.
>Обучаясь основам только ещё больше буду делать ошибок, и вместо продвижения простого концепта, у меня будет сотня крестиков ноликов.
Вот если ты основам научишься и набьёшь шишки на всех возможных граблях, делая сотню "крестиков-ноликов", то потом сможешь без проблем продвигать любые свои концепты. А пока ты пытаешься "продвигать концепты" без системных знаний, ты тупо делаешь кучу ошибок и ничего в результате не достигаешь, разочаровываясь в себе и своих силах.
Смотри пикрил и читай статью:
https://ru.wikipedia.org/wiki/Поток_(психология)
Состояние потока - лучшее переживание в жизни любого человека, но чтобы его достичь, твои задачи должны соответствовать твоим навыкам. Если задачи слишком просты, ты заскучаешь, а если задачи слишком сложны, ты будешь беспокоиться, испытывать стресс и разочарование. Вот ты сейчас берёшь слишком сложные конкретно для тебя задачи - тебе нужно повысить навыки, даже если повышение навыков кажется тебе слишком скучным.
>Не могу зайти! Не могу выйти!
В первой функции у тебя опечатка:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-change-scene
Однако, судя по тому, что у тебя
>Ноль ошибок!
Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены. Выбираешь в списке сигналов сигнал "pressed", нажимаешь connect и в открывшемся меню выбираешь свой скрипт - только тогда в появившемся методе с зелёной стрелочкой слева (на линейке) пишешь код из примера. Это не единственный способ подключения обработчиков сигнала, но в случае с GUI он чаще всего используется (другой способ - вызов connect(), чаще всего нужен для создания динамических связей при процедурной генерации части уровня, типа врагов и т.п.).
54 Кб, 1446x1089>>48852
Не нужно драматизировать.
Ты в курсе вообще, какой год? У нас уже почти год из всех щелей нахрюки информационной войны, да, и в этом разделе тоже регулярно всплывало, просто большую часть своевременно чистили. А ты тут со своим "танчики наступают", естественно меня триггернуло, тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня". Адекватный человек найдёт учебники по программированию и всему сам обучится, а школьники из /po/ ничего не умеют и уметь не хотят, кроме как боевыми картиночками кидаться.
Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге, прежде чем освоил все базовые темы, не считая ООП, который я осваивал много позже и по другой книге. А ты хочешь за два дня всему научиться методом слепого тыка и копипасты из интернета. Алсо, я так и не доделал ни одной полноценной игры, некоторые заготовки много месяцев ковырял и ни к чему достойному не пришёл. Так что не разочаровывайся так, два дня попыток - это сущий пустяк для ньюфага в геймдеве. Главное, что ты получил какой-то опыт за эти два дня, что-то узнал и понял.
Вылечи депрессию и всплывёшь.
Программирование не относится к таким навыкам, программированию можно и в старости научиться. Да, будет сложнее, но если иметь желание и усидчивость, то всё обязательно получится.
Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке.
Godot рассчитан на лёгкое освоение, но не заточен на детей с задержками в развитии. Если тебе нужно что-то совсем простое, попробуй конструкторы игр вроде GameMaker и ему подобных, там тебе будут пиктограммы и задачки уровня вставить кубик в квадратную дырку. А Godot - это для подросших детей, которые уже более-менее уверенно чувствуют себя за компьютером и не боятся трудностей, а также умеют читать и писать.
Конкретно по документации, она разделена на две части: туториалы (уроки) и API Reference (справка по движку). Второе доступно изнутри самого движка по кнопке F1. Туториалы разделены на несколько уровней сложности, но они, тем не менее, подразумевают, что ты кое-что уже понимаешь в программировании. Есть отдельные, сторонние туториалы для полных нулей в программировании - вот они тебе, скорее всего, и нужны, судя по твоему нытью.
Попробуй это, тут даже интерактивно всё:
https://gdquest.itch.io/learn-godot-gdscript
Не нужны, программирование легко осваивается по классическим текстовым книгам. Но если ты зумер, то, возможно, видосики тебе и правда зайдут. Можешь скачать какой-нибудь видеокурс с торрентов, их очень часто сливают и всем насрать, что ты это скачаешь.
У тебя какая такая болезнь, которая мешает тебе усидчиво осваивать программирование? Вангую, у тебя СДВГ, из-за которого ты не можешь сфокусироваться на одной задаче и скачешь, а потом удивляешься, почему ничего не понял. Плюс, судя по твоим постам, у тебя ещё и депрессия или как минимум крайне заниженная самооценка, которая рано или поздно доведёт до депрессии. Лечись давай, я не знаю, к психотерапевту сходи, а потом будешь шедевры геймдева создавать за два дня.
Вот если ты основам научишься и набьёшь шишки на всех возможных граблях, делая сотню "крестиков-ноликов", то потом сможешь без проблем продвигать любые свои концепты. А пока ты пытаешься "продвигать концепты" без системных знаний, ты тупо делаешь кучу ошибок и ничего в результате не достигаешь, разочаровываясь в себе и своих силах.
Смотри пикрил и читай статью:
https://ru.wikipedia.org/wiki/Поток_(психология)
Состояние потока - лучшее переживание в жизни любого человека, но чтобы его достичь, твои задачи должны соответствовать твоим навыкам. Если задачи слишком просты, ты заскучаешь, а если задачи слишком сложны, ты будешь беспокоиться, испытывать стресс и разочарование. Вот ты сейчас берёшь слишком сложные конкретно для тебя задачи - тебе нужно повысить навыки, даже если повышение навыков кажется тебе слишком скучным.
В первой функции у тебя опечатка:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-change-scene
Однако, судя по тому, что у тебя
Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены. Выбираешь в списке сигналов сигнал "pressed", нажимаешь connect и в открывшемся меню выбираешь свой скрипт - только тогда в появившемся методе с зелёной стрелочкой слева (на линейке) пишешь код из примера. Это не единственный способ подключения обработчиков сигнала, но в случае с GUI он чаще всего используется (другой способ - вызов connect(), чаще всего нужен для создания динамических связей при процедурной генерации части уровня, типа врагов и т.п.).
>завидовать и страдать
Не нужно драматизировать.
>предвзят к тебе благодаря своей шизофрении
Ты в курсе вообще, какой год? У нас уже почти год из всех щелей нахрюки информационной войны, да, и в этом разделе тоже регулярно всплывало, просто большую часть своевременно чистили. А ты тут со своим "танчики наступают", естественно меня триггернуло, тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня". Адекватный человек найдёт учебники по программированию и всему сам обучится, а школьники из /po/ ничего не умеют и уметь не хотят, кроме как боевыми картиночками кидаться.
>За два дня...
Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге, прежде чем освоил все базовые темы, не считая ООП, который я осваивал много позже и по другой книге. А ты хочешь за два дня всему научиться методом слепого тыка и копипасты из интернета. Алсо, я так и не доделал ни одной полноценной игры, некоторые заготовки много месяцев ковырял и ни к чему достойному не пришёл. Так что не разочаровывайся так, два дня попыток - это сущий пустяк для ньюфага в геймдеве. Главное, что ты получил какой-то опыт за эти два дня, что-то узнал и понял.
>насколько глупо находясь на дне океана, пытаться всплыть имея на ногах тазик с бетоном.
Вылечи депрессию и всплывёшь.
>не научился к пяти годам
>Он ничего с этим уже не поделает
Программирование не относится к таким навыкам, программированию можно и в старости научиться. Да, будет сложнее, но если иметь желание и усидчивость, то всё обязательно получится.
>Какая к чёрту база?
Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке.
>Открывая документацию по представлению разработчиков, я уже был обязан все знать.
Godot рассчитан на лёгкое освоение, но не заточен на детей с задержками в развитии. Если тебе нужно что-то совсем простое, попробуй конструкторы игр вроде GameMaker и ему подобных, там тебе будут пиктограммы и задачки уровня вставить кубик в квадратную дырку. А Godot - это для подросших детей, которые уже более-менее уверенно чувствуют себя за компьютером и не боятся трудностей, а также умеют читать и писать.
Конкретно по документации, она разделена на две части: туториалы (уроки) и API Reference (справка по движку). Второе доступно изнутри самого движка по кнопке F1. Туториалы разделены на несколько уровней сложности, но они, тем не менее, подразумевают, что ты кое-что уже понимаешь в программировании. Есть отдельные, сторонние туториалы для полных нулей в программировании - вот они тебе, скорее всего, и нужны, судя по твоему нытью.
Попробуй это, тут даже интерактивно всё:
https://gdquest.itch.io/learn-godot-gdscript
>курсы
Не нужны, программирование легко осваивается по классическим текстовым книгам. Но если ты зумер, то, возможно, видосики тебе и правда зайдут. Можешь скачать какой-нибудь видеокурс с торрентов, их очень часто сливают и всем насрать, что ты это скачаешь.
>Это куда больше подходить в нынешней ситуации.
У тебя какая такая болезнь, которая мешает тебе усидчиво осваивать программирование? Вангую, у тебя СДВГ, из-за которого ты не можешь сфокусироваться на одной задаче и скачешь, а потом удивляешься, почему ничего не понял. Плюс, судя по твоим постам, у тебя ещё и депрессия или как минимум крайне заниженная самооценка, которая рано или поздно доведёт до депрессии. Лечись давай, я не знаю, к психотерапевту сходи, а потом будешь шедевры геймдева создавать за два дня.
>Обучаясь основам только ещё больше буду делать ошибок, и вместо продвижения простого концепта, у меня будет сотня крестиков ноликов.
Вот если ты основам научишься и набьёшь шишки на всех возможных граблях, делая сотню "крестиков-ноликов", то потом сможешь без проблем продвигать любые свои концепты. А пока ты пытаешься "продвигать концепты" без системных знаний, ты тупо делаешь кучу ошибок и ничего в результате не достигаешь, разочаровываясь в себе и своих силах.
Смотри пикрил и читай статью:
https://ru.wikipedia.org/wiki/Поток_(психология)
Состояние потока - лучшее переживание в жизни любого человека, но чтобы его достичь, твои задачи должны соответствовать твоим навыкам. Если задачи слишком просты, ты заскучаешь, а если задачи слишком сложны, ты будешь беспокоиться, испытывать стресс и разочарование. Вот ты сейчас берёшь слишком сложные конкретно для тебя задачи - тебе нужно повысить навыки, даже если повышение навыков кажется тебе слишком скучным.
>Не могу зайти! Не могу выйти!
В первой функции у тебя опечатка:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-change-scene
Однако, судя по тому, что у тебя
>Ноль ошибок!
Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены. Выбираешь в списке сигналов сигнал "pressed", нажимаешь connect и в открывшемся меню выбираешь свой скрипт - только тогда в появившемся методе с зелёной стрелочкой слева (на линейке) пишешь код из примера. Это не единственный способ подключения обработчиков сигнала, но в случае с GUI он чаще всего используется (другой способ - вызов connect(), чаще всего нужен для создания динамических связей при процедурной генерации части уровня, типа врагов и т.п.).
Обьясните простыми словами как разботает система попадания пулей по врагу, у пули есть скорость это не лазер
Пуля летит и проверяет с ебанутой скоростью не пересеклась ли она с хитбоксом?
Пуля летит и проверяет с ебанутой скоростью не пересеклась ли она с хитбоксом?
>>48873
если с ебанутой скоростью - то чистая математика, пересечение луча со сферой, с капсулой/цилиндром или с треугольником (кую/конвекс)
если скорость меньше чем ебанутая - бери bullet или любой физдвижок и не выебывайся, в такой задаче проблем и трейдоффов дохуя
если с ебанутой скоростью - то чистая математика, пересечение луча со сферой, с капсулой/цилиндром или с треугольником (кую/конвекс)
если скорость меньше чем ебанутая - бери bullet или любой физдвижок и не выебывайся, в такой задаче проблем и трейдоффов дохуя
>>48873
В наиболее простом способе пуля это как раз лазер, Hitscan/Raycast.
И это легко объяснимо. К примеру пуля вылетает со скоростью около 1000м/с. Это значит что она пролетаеть 16 метров в кадр, что дохуя (8 лежащих друг за другом людей, или 4 стоящих автомобиля).
Более медленные прожектайлы - делаешь просто физические столкновения Area/Body. Возможно есть смысл делать коллайдер не точечной сферой, а цилиндром чтобы учесть пролетный путь.
Наиболее продвинутый вариант - предыдущий, но с баллистической траекторией. Что-то типа https://github.com/deakcor/Godot-ballistic-trajectory/blob/master/scenes/projectile.gd
В наиболее простом способе пуля это как раз лазер, Hitscan/Raycast.
И это легко объяснимо. К примеру пуля вылетает со скоростью около 1000м/с. Это значит что она пролетаеть 16 метров в кадр, что дохуя (8 лежащих друг за другом людей, или 4 стоящих автомобиля).
Более медленные прожектайлы - делаешь просто физические столкновения Area/Body. Возможно есть смысл делать коллайдер не точечной сферой, а цилиндром чтобы учесть пролетный путь.
Наиболее продвинутый вариант - предыдущий, но с баллистической траекторией. Что-то типа https://github.com/deakcor/Godot-ballistic-trajectory/blob/master/scenes/projectile.gd
Как бы вы смотрели что убралось на поле двумерного массива и проверяли то ли это что вам нужно? Типа Т фигура на поле 12х20.
Я сейчас кропаю поле до того что убралось, хэширую это и чекаю есть ли такой хэш в словаре который я сделал для нужных фигур. Хэш общий для четырех положений 1 фигуры. Вариантов проще и быстрей думаю нет, но я и не шарю нихуя.
Я сейчас кропаю поле до того что убралось, хэширую это и чекаю есть ли такой хэш в словаре который я сделал для нужных фигур. Хэш общий для четырех положений 1 фигуры. Вариантов проще и быстрей думаю нет, но я и не шарю нихуя.
1,5 Мб, mp4,800x600, 1:40
Невероятно, простейший 2D космос в стиле "коровы на льду" делается настолько просто! Я ожидал каких-то сложностей, а тут реально всё так просто. Блин. Теперь точно нужно запилить что-то, а то все подобные игры в бесконечной альфе/бете и очень вяло развиваются.
>>48871
Тогда не нужно начинать ставить мне диагнозы, записывать меня в пропагандистов, казаться лучше других.
Как и в любой другой год говна было немерено. Тот же видео ролик который был снят два года назад. Посмотри концовку и все станет ясно. https://www.youtube.com/watch?v=4q0tg-HOYPo&ab_channel=Khlopak
Если тебя прорвало только после массовой истерии, не нужно затирать что эта ненависть появилась в инфополе только сейчас! Если же тебе всюду мерещится, иди искать оппонентов на досках для которых это в порядке нормы.
Войнушка - классическая тема для игр. Бф, тф, кс, колда, и тд. Большая часть игр крутится по круг военной тематики. Они не теряют свою популярность, и не будут! Устоявшейся жанр который сам по себе является обыденностью.
К тому же я не пытался полностью расписать свою идею. Аналогию можно взять с Айзеком. Где парень бегает из комнаты в комнату, а по описанию роется в говне и после убийства залезает в чрево своей матери. В следующий раз для описания своей идеи место танка - цветок, враги - пчёлы.
Кто за меня игру сделает? Она никому кроме меня не нужна! Мне нужно было сделать только имитацию стрельбы от клика. После чего привязать к врагам исчезновение после смерти, а к игроку выход из укрытия в виде анимации.
В прошлый раз я пытался сделать простенький теннис. Но застопорился на физике мяча. Сидел смотрел множество гайдов, в треде ответил анон как его можно сделать. Но я ничего не понял! Сейчас для провери зашёл в архивач, увидел свои посты 2021 года. Без слез смотреть не возможно, столько времени прошло, и ничего не поменялось.
Ты сам говоришь что godot для более продвинутых. При этом предлагаешь мне получать в нём базу.
Пересмотрев видео я заметил это, теперь кнопки заработали. Как до этого можно догадаться? Если анимация спрайтов спокойно вызывается через код, без дополнительных узлов. База в коде не будет предусматривать особенности программы, где кроме кода, ты будешь обязан потыкаться в 2d области для правильной настройки объектов.
Мне нужен инструмент который выполнит мои задачи. Более примитивные движке не могут это выполнить. Переходить на них не имеет смысла. Путь самурая, единственное что будет иметь смысл.
Я знаю про состояния потока. От программирования я его не испытываю, куда больше удовольствия вызывает мытьё посуды.
Ты сам создал демку по моему описанию, считаешь это шедевром? Сколько мне раз повторять что это базис игры! Кость на которую можно нарастить полноценную игру. Мне не нужно было на первом этапе сделать целую игру. Моё желание заключалась в постепенной сборке пазла. Где в начале была проработка стрельбы. После, проработка главного героя, создания меню и первого уровня. Установка плагинов и постепенное обустройство в своей игре. Оступился. Упал с лестницы, сломал шею.
>Не нужно драматизировать.
Тогда не нужно начинать ставить мне диагнозы, записывать меня в пропагандистов, казаться лучше других.
>Ты в курсе вообще, какой год?
Как и в любой другой год говна было немерено. Тот же видео ролик который был снят два года назад. Посмотри концовку и все станет ясно. https://www.youtube.com/watch?v=4q0tg-HOYPo&ab_channel=Khlopak
Если тебя прорвало только после массовой истерии, не нужно затирать что эта ненависть появилась в инфополе только сейчас! Если же тебе всюду мерещится, иди искать оппонентов на досках для которых это в порядке нормы.
>А ты тут со своим "танчики наступают", естественно меня триггернуло
Войнушка - классическая тема для игр. Бф, тф, кс, колда, и тд. Большая часть игр крутится по круг военной тематики. Они не теряют свою популярность, и не будут! Устоявшейся жанр который сам по себе является обыденностью.
К тому же я не пытался полностью расписать свою идею. Аналогию можно взять с Айзеком. Где парень бегает из комнаты в комнату, а по описанию роется в говне и после убийства залезает в чрево своей матери. В следующий раз для описания своей идеи место танка - цветок, враги - пчёлы.
>тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня".
Кто за меня игру сделает? Она никому кроме меня не нужна! Мне нужно было сделать только имитацию стрельбы от клика. После чего привязать к врагам исчезновение после смерти, а к игроку выход из укрытия в виде анимации.
В прошлый раз я пытался сделать простенький теннис. Но застопорился на физике мяча. Сидел смотрел множество гайдов, в треде ответил анон как его можно сделать. Но я ничего не понял! Сейчас для провери зашёл в архивач, увидел свои посты 2021 года. Без слез смотреть не возможно, столько времени прошло, и ничего не поменялось.
>Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге,
>Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке
Ты сам говоришь что godot для более продвинутых. При этом предлагаешь мне получать в нём базу.
>Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены.
Пересмотрев видео я заметил это, теперь кнопки заработали. Как до этого можно догадаться? Если анимация спрайтов спокойно вызывается через код, без дополнительных узлов. База в коде не будет предусматривать особенности программы, где кроме кода, ты будешь обязан потыкаться в 2d области для правильной настройки объектов.
>Если тебе нужно что-то совсем простое
Мне нужен инструмент который выполнит мои задачи. Более примитивные движке не могут это выполнить. Переходить на них не имеет смысла. Путь самурая, единственное что будет иметь смысл.
>Состояние потока
Я знаю про состояния потока. От программирования я его не испытываю, куда больше удовольствия вызывает мытьё посуды.
>будешь шедевры геймдева создавать за два дня.
Ты сам создал демку по моему описанию, считаешь это шедевром? Сколько мне раз повторять что это базис игры! Кость на которую можно нарастить полноценную игру. Мне не нужно было на первом этапе сделать целую игру. Моё желание заключалась в постепенной сборке пазла. Где в начале была проработка стрельбы. После, проработка главного героя, создания меню и первого уровня. Установка плагинов и постепенное обустройство в своей игре. Оступился. Упал с лестницы, сломал шею.
>>48871
Тогда не нужно начинать ставить мне диагнозы, записывать меня в пропагандистов, казаться лучше других.
Как и в любой другой год говна было немерено. Тот же видео ролик который был снят два года назад. Посмотри концовку и все станет ясно. https://www.youtube.com/watch?v=4q0tg-HOYPo&ab_channel=Khlopak
Если тебя прорвало только после массовой истерии, не нужно затирать что эта ненависть появилась в инфополе только сейчас! Если же тебе всюду мерещится, иди искать оппонентов на досках для которых это в порядке нормы.
Войнушка - классическая тема для игр. Бф, тф, кс, колда, и тд. Большая часть игр крутится по круг военной тематики. Они не теряют свою популярность, и не будут! Устоявшейся жанр который сам по себе является обыденностью.
К тому же я не пытался полностью расписать свою идею. Аналогию можно взять с Айзеком. Где парень бегает из комнаты в комнату, а по описанию роется в говне и после убийства залезает в чрево своей матери. В следующий раз для описания своей идеи место танка - цветок, враги - пчёлы.
Кто за меня игру сделает? Она никому кроме меня не нужна! Мне нужно было сделать только имитацию стрельбы от клика. После чего привязать к врагам исчезновение после смерти, а к игроку выход из укрытия в виде анимации.
В прошлый раз я пытался сделать простенький теннис. Но застопорился на физике мяча. Сидел смотрел множество гайдов, в треде ответил анон как его можно сделать. Но я ничего не понял! Сейчас для провери зашёл в архивач, увидел свои посты 2021 года. Без слез смотреть не возможно, столько времени прошло, и ничего не поменялось.
Ты сам говоришь что godot для более продвинутых. При этом предлагаешь мне получать в нём базу.
Пересмотрев видео я заметил это, теперь кнопки заработали. Как до этого можно догадаться? Если анимация спрайтов спокойно вызывается через код, без дополнительных узлов. База в коде не будет предусматривать особенности программы, где кроме кода, ты будешь обязан потыкаться в 2d области для правильной настройки объектов.
Мне нужен инструмент который выполнит мои задачи. Более примитивные движке не могут это выполнить. Переходить на них не имеет смысла. Путь самурая, единственное что будет иметь смысл.
Я знаю про состояния потока. От программирования я его не испытываю, куда больше удовольствия вызывает мытьё посуды.
Ты сам создал демку по моему описанию, считаешь это шедевром? Сколько мне раз повторять что это базис игры! Кость на которую можно нарастить полноценную игру. Мне не нужно было на первом этапе сделать целую игру. Моё желание заключалась в постепенной сборке пазла. Где в начале была проработка стрельбы. После, проработка главного героя, создания меню и первого уровня. Установка плагинов и постепенное обустройство в своей игре. Оступился. Упал с лестницы, сломал шею.
>Не нужно драматизировать.
Тогда не нужно начинать ставить мне диагнозы, записывать меня в пропагандистов, казаться лучше других.
>Ты в курсе вообще, какой год?
Как и в любой другой год говна было немерено. Тот же видео ролик который был снят два года назад. Посмотри концовку и все станет ясно. https://www.youtube.com/watch?v=4q0tg-HOYPo&ab_channel=Khlopak
Если тебя прорвало только после массовой истерии, не нужно затирать что эта ненависть появилась в инфополе только сейчас! Если же тебе всюду мерещится, иди искать оппонентов на досках для которых это в порядке нормы.
>А ты тут со своим "танчики наступают", естественно меня триггернуло
Войнушка - классическая тема для игр. Бф, тф, кс, колда, и тд. Большая часть игр крутится по круг военной тематики. Они не теряют свою популярность, и не будут! Устоявшейся жанр который сам по себе является обыденностью.
К тому же я не пытался полностью расписать свою идею. Аналогию можно взять с Айзеком. Где парень бегает из комнаты в комнату, а по описанию роется в говне и после убийства залезает в чрево своей матери. В следующий раз для описания своей идеи место танка - цветок, враги - пчёлы.
>тем более учитывая твои наивные вопросы уровня "я ничего не понимаю, сделайте всё вместо меня".
Кто за меня игру сделает? Она никому кроме меня не нужна! Мне нужно было сделать только имитацию стрельбы от клика. После чего привязать к врагам исчезновение после смерти, а к игроку выход из укрытия в виде анимации.
В прошлый раз я пытался сделать простенький теннис. Но застопорился на физике мяча. Сидел смотрел множество гайдов, в треде ответил анон как его можно сделать. Но я ничего не понял! Сейчас для провери зашёл в архивач, увидел свои посты 2021 года. Без слез смотреть не возможно, столько времени прошло, и ничего не поменялось.
>Опять драматизируешь. Я программирование в своё время целый месяц изучал по книге,
>Я про базу программирования, которая никак не зависит от используемого языка и других инструментов. Ты можешь освоить её с использованием Godot, а можешь получить на другом языке
Ты сам говоришь что godot для более продвинутых. При этом предлагаешь мне получать в нём базу.
>Предполагаю, что ты тупо скопипастил этот код, тогда как в туториале тебе наверняка говорили создать обработчик сигнала через окно инспектора, в котором на второй вкладке есть список всех сигналов выделенной ноды в дереве сцены.
Пересмотрев видео я заметил это, теперь кнопки заработали. Как до этого можно догадаться? Если анимация спрайтов спокойно вызывается через код, без дополнительных узлов. База в коде не будет предусматривать особенности программы, где кроме кода, ты будешь обязан потыкаться в 2d области для правильной настройки объектов.
>Если тебе нужно что-то совсем простое
Мне нужен инструмент который выполнит мои задачи. Более примитивные движке не могут это выполнить. Переходить на них не имеет смысла. Путь самурая, единственное что будет иметь смысл.
>Состояние потока
Я знаю про состояния потока. От программирования я его не испытываю, куда больше удовольствия вызывает мытьё посуды.
>будешь шедевры геймдева создавать за два дня.
Ты сам создал демку по моему описанию, считаешь это шедевром? Сколько мне раз повторять что это базис игры! Кость на которую можно нарастить полноценную игру. Мне не нужно было на первом этапе сделать целую игру. Моё желание заключалась в постепенной сборке пазла. Где в начале была проработка стрельбы. После, проработка главного героя, создания меню и первого уровня. Установка плагинов и постепенное обустройство в своей игре. Оступился. Упал с лестницы, сломал шею.
>>48915
Слышал про это, но не играл. Может, управление там и похожее, но в остальном игра совсем не про то.
Я ориентируюсь на это, давно слежу:
https://store.steampowered.com/app/416240/
По сравнению с альтернативами там цепляет сборка кораблей из тайлов, что в 2D встречается редко (чаще можно видеть 3D кубики а-ля Майнкрафт в космосе, а в 2D дают набор кораблей-спрайтов и всё).
Собственно, чрезвычайно медленная разработка и некоторые геймдизайнерские решения этой игры уже давно заставляют меня задумываться над своим собственным клоном, хотя бы чисто поиграться с возможными механиками в таком мире.
Я вообще люблю песочницы, пробовал всякое, но везде встречаю какие-то нетривиальные проблемы, которые сложно решить с наскока. Отсутствие приемлемого решения демотивирует и я забрасываю всё, только чтобы потом снова начать думать "а что, если..."
А вот такие маленькие прототипы всё же мотивируют, показывая, что задумка в целом не так уж далека, как кажется после череды неразрешимых проблем.
>Sunless Sea
Слышал про это, но не играл. Может, управление там и похожее, но в остальном игра совсем не про то.
Я ориентируюсь на это, давно слежу:
https://store.steampowered.com/app/416240/
По сравнению с альтернативами там цепляет сборка кораблей из тайлов, что в 2D встречается редко (чаще можно видеть 3D кубики а-ля Майнкрафт в космосе, а в 2D дают набор кораблей-спрайтов и всё).
Собственно, чрезвычайно медленная разработка и некоторые геймдизайнерские решения этой игры уже давно заставляют меня задумываться над своим собственным клоном, хотя бы чисто поиграться с возможными механиками в таком мире.
Я вообще люблю песочницы, пробовал всякое, но везде встречаю какие-то нетривиальные проблемы, которые сложно решить с наскока. Отсутствие приемлемого решения демотивирует и я забрасываю всё, только чтобы потом снова начать думать "а что, если..."
А вот такие маленькие прототипы всё же мотивируют, показывая, что задумка в целом не так уж далека, как кажется после череды неразрешимых проблем.
>>48900
Как-то так?
Или у тебя игрок может по одной клеточке удалять вручную и тебе нужно узнать, правильно ли он сделал?
>Как бы вы смотрели что убралось на поле двумерного массива и проверяли то ли это что вам нужно? Типа Т фигура на поле 12х20.
Как-то так?
>func remove_t_figure(pos: Vector2) -> void:
>_ # код удаления фигуры
>_ emit_signal("t_figure_removed", pos)
Или у тебя игрок может по одной клеточке удалять вручную и тебе нужно узнать, правильно ли он сделал?
Вот так теперь выглядят программы расстановки пробелов в слове и копирования слова. Много неиспользуемого пространства, а сама машина тьюринга мутирует во что близкое к обычному императивному программированию.
>>48914
Как на ней можно застопориться, лол?
Сцена:
Чтобы симулировать удар, достаточно физической ракеткой бить по этому мячу, и физический движок сделает всё остальное за тебя. Тебе же остаётся только закодить управление ракеткой и триггеры на попадание мяча в определённые игровые зоны. Если хочешь какие-то дополнительные особенности, то используй метод apply_impulse() и ему подобные в RigidBody2D. Всё просто, если внимательно читать.
Godot для более продвинутых разработчиков игр. Если тебе достаточно сравнительно примитивной игры, но важно сделать её "без программирования", то конструкторы игр могут подойти тебе лучше, т.к. там многие популярные операции ещё сильнее упрощены и многое делается совсем без кода, чисто мышкой натыкать можно. Но если ты хочешь освоить программирование и в частности Godot, то конструктор игр тебе тут слабо поможет (хотя тоже вариант, конечно), а в самом Godot возможно решать почти любые задачи по программированию, выводя результат работы программы в консоль (вот ввод с консоли вроде не предусмотрен, к сожалению, но это легко решить). Т.е. даже будучи полным нулём в программировании его можно освоить прямо в Godot, было бы желание. У тебя же, как я понял, желание сразу без обучения запилить какую-то твою идею - поэтому и предложил посмотреть в сторону конструкторов игр, которые позиционируются как инструменты для создания игр "без программирования". Хотя для освоения конструктора опять же придётся проходить туториалы, а у тебя, похоже, с этим проблемы...
А ты не должен догадываться. Ты должен знать.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Туториал буквально называется "шаг за шагом", а ты решил перепрыгнуть его и заняться какой-то фигнёй. Вот теперь получаешь то, что заслужил. А тебе говорили: изучай последовательно и проблем будет меньше.
Я уже говорил, что можно связывать сигналы через код:
Повторюсь, связывать так имеет смысл что-то, что может появляться на сцене в процессе игры (новые враги, коробки патронов и т.д.), а кнопки GUI удобнее связать через инспектор, чем через код. Долго объяснять, почему. И кстати, связывание через инспектор - это тоже код, только код этот декларативный и записан в tscn файле - ты можешь открыть tscn файл в Блокноте и убедиться, что там довольно читабельный декларативный код, описывающий игровые сцены и объекты в них. Только не забивай себе этим голову сейчас, копаться и вручную менять в tscn что-либо обычно не нужно, они текстовые по большому счёту для удобства систем контроля версий.
Ну ты же планируешь использовать эту программу (Godot Editor) в дальнейшем? Значит, должен изучить её. По-другому никак, ты любой софт должен изучать, чтобы полноценно его использовать.
Разработка чисто кодом возможна, но многолетняя практика показала, что некоторые вещи всё же лучше сделать через GUIшные редакторы, чем через код. Это быстрее, нагляднее, чище и всё такое. Поэтому игровые движки обычно снабжаются GUIшным редактором, чтобы ускорить разработку ещё сильнее. Любой GUI, конечно, нужно изучать, прежде чем использовать, но это в разы проще, чем программирование.
Самураи задрачивали свои сложные техники боя до предела, а не ныли на анонимных форумах о том, как у них нихрена не получается.
Потому что ставишь слишком сложные задачи. А слишком сложные они для тебя потому, что ты не усвоил базы и пытаешься сразу сделать то, что ты там себе придумал. Не расстраивайся, ты не один такой, многие люди совершают твою ошибку - тебе остаётся признать её и предпринять действия для её исправления.
Я и сам часто совершаю такую ошибку.
О котором ты практически ничего не знаешь.
А тебе говорили неоднократно: не прыгай через четыре ступеньки, оступишься, упадёшь и сломаешь себе шею. А ты каждый раз отвечаешь "скучно по одной ступеньке пешком подниматься, я лучше побегу, прыгая через четыре", начинаешь бежать, оступаешься и ломаешь себе шею, а потом жалуешься "ой, чой-то у меня ничего не получается", но следовать советам мудрым отказываешься. Пасту про "есть с ножа" читал? Вот у тебя сейчас точно такая же ситуация, ты ешь суп с ножа и жалуешься, что рот себе весь изрезал, а совет есть суп ложкой не слушаешь.
>застопорился на физике мяча
Как на ней можно застопориться, лол?
Сцена:
>RigidBody2D
>— CollisionShape2D (выбери круг в инспекторе)
>— Sprite
Чтобы симулировать удар, достаточно физической ракеткой бить по этому мячу, и физический движок сделает всё остальное за тебя. Тебе же остаётся только закодить управление ракеткой и триггеры на попадание мяча в определённые игровые зоны. Если хочешь какие-то дополнительные особенности, то используй метод apply_impulse() и ему подобные в RigidBody2D. Всё просто, если внимательно читать.
>godot для более продвинутых
>предлагаешь мне получать в нём базу
Godot для более продвинутых разработчиков игр. Если тебе достаточно сравнительно примитивной игры, но важно сделать её "без программирования", то конструкторы игр могут подойти тебе лучше, т.к. там многие популярные операции ещё сильнее упрощены и многое делается совсем без кода, чисто мышкой натыкать можно. Но если ты хочешь освоить программирование и в частности Godot, то конструктор игр тебе тут слабо поможет (хотя тоже вариант, конечно), а в самом Godot возможно решать почти любые задачи по программированию, выводя результат работы программы в консоль (вот ввод с консоли вроде не предусмотрен, к сожалению, но это легко решить). Т.е. даже будучи полным нулём в программировании его можно освоить прямо в Godot, было бы желание. У тебя же, как я понял, желание сразу без обучения запилить какую-то твою идею - поэтому и предложил посмотреть в сторону конструкторов игр, которые позиционируются как инструменты для создания игр "без программирования". Хотя для освоения конструктора опять же придётся проходить туториалы, а у тебя, похоже, с этим проблемы...
>Как до этого можно догадаться?
А ты не должен догадываться. Ты должен знать.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Туториал буквально называется "шаг за шагом", а ты решил перепрыгнуть его и заняться какой-то фигнёй. Вот теперь получаешь то, что заслужил. А тебе говорили: изучай последовательно и проблем будет меньше.
>вызывается через код
Я уже говорил, что можно связывать сигналы через код:
>var _e = $Button.connect("pressed", self, "_on_Button_pressed")
Повторюсь, связывать так имеет смысл что-то, что может появляться на сцене в процессе игры (новые враги, коробки патронов и т.д.), а кнопки GUI удобнее связать через инспектор, чем через код. Долго объяснять, почему. И кстати, связывание через инспектор - это тоже код, только код этот декларативный и записан в tscn файле - ты можешь открыть tscn файл в Блокноте и убедиться, что там довольно читабельный декларативный код, описывающий игровые сцены и объекты в них. Только не забивай себе этим голову сейчас, копаться и вручную менять в tscn что-либо обычно не нужно, они текстовые по большому счёту для удобства систем контроля версий.
>предусматривать особенности программы
Ну ты же планируешь использовать эту программу (Godot Editor) в дальнейшем? Значит, должен изучить её. По-другому никак, ты любой софт должен изучать, чтобы полноценно его использовать.
Разработка чисто кодом возможна, но многолетняя практика показала, что некоторые вещи всё же лучше сделать через GUIшные редакторы, чем через код. Это быстрее, нагляднее, чище и всё такое. Поэтому игровые движки обычно снабжаются GUIшным редактором, чтобы ускорить разработку ещё сильнее. Любой GUI, конечно, нужно изучать, прежде чем использовать, но это в разы проще, чем программирование.
>Путь самурая
Самураи задрачивали свои сложные техники боя до предела, а не ныли на анонимных форумах о том, как у них нихрена не получается.
>От программирования я его не испытываю
Потому что ставишь слишком сложные задачи. А слишком сложные они для тебя потому, что ты не усвоил базы и пытаешься сразу сделать то, что ты там себе придумал. Не расстраивайся, ты не один такой, многие люди совершают твою ошибку - тебе остаётся признать её и предпринять действия для её исправления.
Я и сам часто совершаю такую ошибку.
>желание заключалась в постепенной сборке пазла
О котором ты практически ничего не знаешь.
>Оступился. Упал с лестницы, сломал шею.
А тебе говорили неоднократно: не прыгай через четыре ступеньки, оступишься, упадёшь и сломаешь себе шею. А ты каждый раз отвечаешь "скучно по одной ступеньке пешком подниматься, я лучше побегу, прыгая через четыре", начинаешь бежать, оступаешься и ломаешь себе шею, а потом жалуешься "ой, чой-то у меня ничего не получается", но следовать советам мудрым отказываешься. Пасту про "есть с ножа" читал? Вот у тебя сейчас точно такая же ситуация, ты ешь суп с ножа и жалуешься, что рот себе весь изрезал, а совет есть суп ложкой не слушаешь.
>>48914
Как на ней можно застопориться, лол?
Сцена:
Чтобы симулировать удар, достаточно физической ракеткой бить по этому мячу, и физический движок сделает всё остальное за тебя. Тебе же остаётся только закодить управление ракеткой и триггеры на попадание мяча в определённые игровые зоны. Если хочешь какие-то дополнительные особенности, то используй метод apply_impulse() и ему подобные в RigidBody2D. Всё просто, если внимательно читать.
Godot для более продвинутых разработчиков игр. Если тебе достаточно сравнительно примитивной игры, но важно сделать её "без программирования", то конструкторы игр могут подойти тебе лучше, т.к. там многие популярные операции ещё сильнее упрощены и многое делается совсем без кода, чисто мышкой натыкать можно. Но если ты хочешь освоить программирование и в частности Godot, то конструктор игр тебе тут слабо поможет (хотя тоже вариант, конечно), а в самом Godot возможно решать почти любые задачи по программированию, выводя результат работы программы в консоль (вот ввод с консоли вроде не предусмотрен, к сожалению, но это легко решить). Т.е. даже будучи полным нулём в программировании его можно освоить прямо в Godot, было бы желание. У тебя же, как я понял, желание сразу без обучения запилить какую-то твою идею - поэтому и предложил посмотреть в сторону конструкторов игр, которые позиционируются как инструменты для создания игр "без программирования". Хотя для освоения конструктора опять же придётся проходить туториалы, а у тебя, похоже, с этим проблемы...
А ты не должен догадываться. Ты должен знать.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Туториал буквально называется "шаг за шагом", а ты решил перепрыгнуть его и заняться какой-то фигнёй. Вот теперь получаешь то, что заслужил. А тебе говорили: изучай последовательно и проблем будет меньше.
Я уже говорил, что можно связывать сигналы через код:
Повторюсь, связывать так имеет смысл что-то, что может появляться на сцене в процессе игры (новые враги, коробки патронов и т.д.), а кнопки GUI удобнее связать через инспектор, чем через код. Долго объяснять, почему. И кстати, связывание через инспектор - это тоже код, только код этот декларативный и записан в tscn файле - ты можешь открыть tscn файл в Блокноте и убедиться, что там довольно читабельный декларативный код, описывающий игровые сцены и объекты в них. Только не забивай себе этим голову сейчас, копаться и вручную менять в tscn что-либо обычно не нужно, они текстовые по большому счёту для удобства систем контроля версий.
Ну ты же планируешь использовать эту программу (Godot Editor) в дальнейшем? Значит, должен изучить её. По-другому никак, ты любой софт должен изучать, чтобы полноценно его использовать.
Разработка чисто кодом возможна, но многолетняя практика показала, что некоторые вещи всё же лучше сделать через GUIшные редакторы, чем через код. Это быстрее, нагляднее, чище и всё такое. Поэтому игровые движки обычно снабжаются GUIшным редактором, чтобы ускорить разработку ещё сильнее. Любой GUI, конечно, нужно изучать, прежде чем использовать, но это в разы проще, чем программирование.
Самураи задрачивали свои сложные техники боя до предела, а не ныли на анонимных форумах о том, как у них нихрена не получается.
Потому что ставишь слишком сложные задачи. А слишком сложные они для тебя потому, что ты не усвоил базы и пытаешься сразу сделать то, что ты там себе придумал. Не расстраивайся, ты не один такой, многие люди совершают твою ошибку - тебе остаётся признать её и предпринять действия для её исправления.
Я и сам часто совершаю такую ошибку.
О котором ты практически ничего не знаешь.
А тебе говорили неоднократно: не прыгай через четыре ступеньки, оступишься, упадёшь и сломаешь себе шею. А ты каждый раз отвечаешь "скучно по одной ступеньке пешком подниматься, я лучше побегу, прыгая через четыре", начинаешь бежать, оступаешься и ломаешь себе шею, а потом жалуешься "ой, чой-то у меня ничего не получается", но следовать советам мудрым отказываешься. Пасту про "есть с ножа" читал? Вот у тебя сейчас точно такая же ситуация, ты ешь суп с ножа и жалуешься, что рот себе весь изрезал, а совет есть суп ложкой не слушаешь.
>застопорился на физике мяча
Как на ней можно застопориться, лол?
Сцена:
>RigidBody2D
>— CollisionShape2D (выбери круг в инспекторе)
>— Sprite
Чтобы симулировать удар, достаточно физической ракеткой бить по этому мячу, и физический движок сделает всё остальное за тебя. Тебе же остаётся только закодить управление ракеткой и триггеры на попадание мяча в определённые игровые зоны. Если хочешь какие-то дополнительные особенности, то используй метод apply_impulse() и ему подобные в RigidBody2D. Всё просто, если внимательно читать.
>godot для более продвинутых
>предлагаешь мне получать в нём базу
Godot для более продвинутых разработчиков игр. Если тебе достаточно сравнительно примитивной игры, но важно сделать её "без программирования", то конструкторы игр могут подойти тебе лучше, т.к. там многие популярные операции ещё сильнее упрощены и многое делается совсем без кода, чисто мышкой натыкать можно. Но если ты хочешь освоить программирование и в частности Godot, то конструктор игр тебе тут слабо поможет (хотя тоже вариант, конечно), а в самом Godot возможно решать почти любые задачи по программированию, выводя результат работы программы в консоль (вот ввод с консоли вроде не предусмотрен, к сожалению, но это легко решить). Т.е. даже будучи полным нулём в программировании его можно освоить прямо в Godot, было бы желание. У тебя же, как я понял, желание сразу без обучения запилить какую-то твою идею - поэтому и предложил посмотреть в сторону конструкторов игр, которые позиционируются как инструменты для создания игр "без программирования". Хотя для освоения конструктора опять же придётся проходить туториалы, а у тебя, похоже, с этим проблемы...
>Как до этого можно догадаться?
А ты не должен догадываться. Ты должен знать.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Туториал буквально называется "шаг за шагом", а ты решил перепрыгнуть его и заняться какой-то фигнёй. Вот теперь получаешь то, что заслужил. А тебе говорили: изучай последовательно и проблем будет меньше.
>вызывается через код
Я уже говорил, что можно связывать сигналы через код:
>var _e = $Button.connect("pressed", self, "_on_Button_pressed")
Повторюсь, связывать так имеет смысл что-то, что может появляться на сцене в процессе игры (новые враги, коробки патронов и т.д.), а кнопки GUI удобнее связать через инспектор, чем через код. Долго объяснять, почему. И кстати, связывание через инспектор - это тоже код, только код этот декларативный и записан в tscn файле - ты можешь открыть tscn файл в Блокноте и убедиться, что там довольно читабельный декларативный код, описывающий игровые сцены и объекты в них. Только не забивай себе этим голову сейчас, копаться и вручную менять в tscn что-либо обычно не нужно, они текстовые по большому счёту для удобства систем контроля версий.
>предусматривать особенности программы
Ну ты же планируешь использовать эту программу (Godot Editor) в дальнейшем? Значит, должен изучить её. По-другому никак, ты любой софт должен изучать, чтобы полноценно его использовать.
Разработка чисто кодом возможна, но многолетняя практика показала, что некоторые вещи всё же лучше сделать через GUIшные редакторы, чем через код. Это быстрее, нагляднее, чище и всё такое. Поэтому игровые движки обычно снабжаются GUIшным редактором, чтобы ускорить разработку ещё сильнее. Любой GUI, конечно, нужно изучать, прежде чем использовать, но это в разы проще, чем программирование.
>Путь самурая
Самураи задрачивали свои сложные техники боя до предела, а не ныли на анонимных форумах о том, как у них нихрена не получается.
>От программирования я его не испытываю
Потому что ставишь слишком сложные задачи. А слишком сложные они для тебя потому, что ты не усвоил базы и пытаешься сразу сделать то, что ты там себе придумал. Не расстраивайся, ты не один такой, многие люди совершают твою ошибку - тебе остаётся признать её и предпринять действия для её исправления.
Я и сам часто совершаю такую ошибку.
>желание заключалась в постепенной сборке пазла
О котором ты практически ничего не знаешь.
>Оступился. Упал с лестницы, сломал шею.
А тебе говорили неоднократно: не прыгай через четыре ступеньки, оступишься, упадёшь и сломаешь себе шею. А ты каждый раз отвечаешь "скучно по одной ступеньке пешком подниматься, я лучше побегу, прыгая через четыре", начинаешь бежать, оступаешься и ломаешь себе шею, а потом жалуешься "ой, чой-то у меня ничего не получается", но следовать советам мудрым отказываешься. Пасту про "есть с ножа" читал? Вот у тебя сейчас точно такая же ситуация, ты ешь суп с ножа и жалуешься, что рот себе весь изрезал, а совет есть суп ложкой не слушаешь.
>>48940
Много чего я написал ты пропустил мимо ушей. Попробую ещё немного разобраться в движке, другого выбора у меня все равно нету.
Место нытья они делали харакири.
Много чего я написал ты пропустил мимо ушей. Попробую ещё немного разобраться в движке, другого выбора у меня все равно нету.
>Самураи задрачивали свои сложные техники боя до предела, а не ныли на анонимных форумах о том, как у них нихрена не получается.
Место нытья они делали харакири.
>>48932
Не по одной, но близко.
Игрок может сделать так, что уберется что-то на поле. Это что-то может быть в виде Т, а может и не быть. Игра удаляет все блоки у которых piece.matched = true, когда легла фигура игрока и прошел чек на матчи, и она не шарит в целом че там сложилось или нет.
Не по одной, но близко.
Игрок может сделать так, что уберется что-то на поле. Это что-то может быть в виде Т, а может и не быть. Игра удаляет все блоки у которых piece.matched = true, когда легла фигура игрока и прошел чек на матчи, и она не шарит в целом че там сложилось или нет.
105 Кб, 1450x465гододвач, чё там по поддержке моддинга? игра в экспортированном виде может загружать .tcsn файлы? ну например чтобы можно было моды к игре делать в годоте, например по официальному руководству которые я сам для моддинга своей игры написал?
челы, объясните пожалуйста, как расставлять битовые маски для автотайлов. я читал официальные доки (https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html), но нихуя не понял. Они конечно оставили шаблон для 3x3, но это блин для вида сверху, а как расставить биты, например для того же тайлшита от Кенни (который в туториале этом есть)?
>>49022
Проще поэкспериментирова самому, честно.
Но вообще там все написано. Если ты хочешь, чтобы они стыковались боковыми гранями, то соответственно биты на боковых гранях должны быть вкл.
В вариантах 3х3 центральный бит должен быть установлен.
Алсо в годот4 там понавороченей будет, так что если планируешь перекатываться то есть смысл там сразу ковыряться. Режимы там называются Касаться гранями, углами, и гранями и углами, есть поддержка разных террейнов (правда не понял как они между собой будут согласоваться) и разные режимы рисования областей и дорог.
Проще поэкспериментирова самому, честно.
Но вообще там все написано. Если ты хочешь, чтобы они стыковались боковыми гранями, то соответственно биты на боковых гранях должны быть вкл.
В вариантах 3х3 центральный бит должен быть установлен.
Алсо в годот4 там понавороченей будет, так что если планируешь перекатываться то есть смысл там сразу ковыряться. Режимы там называются Касаться гранями, углами, и гранями и углами, есть поддержка разных террейнов (правда не понял как они между собой будут согласоваться) и разные режимы рисования областей и дорог.
>>49011
Игра может загружать любые файлы в любом виде, если это поддерживается движком. Ты можешь даже не экспортировать игру, а просто положить .exe файл из папки с шаблонами экспорта в папку своего проекта и запускать таким образом игру; достаточно будет скинуть эту папку проекта и любой сможет как играть, так и моддить игру.
Если тебе нужен продвинутый инструмент моддинга без раскрытия оригинальных компонентов игры, тогда тут придётся самому изобретать Mod API.
>игра в экспортированном виде может загружать .tcsn файлы?
Игра может загружать любые файлы в любом виде, если это поддерживается движком. Ты можешь даже не экспортировать игру, а просто положить .exe файл из папки с шаблонами экспорта в папку своего проекта и запускать таким образом игру; достаточно будет скинуть эту папку проекта и любой сможет как играть, так и моддить игру.
Если тебе нужен продвинутый инструмент моддинга без раскрытия оригинальных компонентов игры, тогда тут придётся самому изобретать Mod API.
Делаю генерацию предметов по этмоу видосу https://www.youtube.com/watch?v=pQvlRRh5F_g&list=PLPPPTnV2MQy3wEg6QRQNBI5Vy13zr8u-k&index=7
Код ровно такой же, сцена запускается но никаких предметов не генерируется
Что не так?
Код ровно такой же, сцена запускается но никаких предметов не генерируется
Что не так?
6 Кб, 188x207>>49061
Разобрался, сцена карты была выше сцены с предметами
Разобрался, сцена карты была выше сцены с предметами
>>49061
А если бы читал официальную документацию вместо просмотра чужих туториалов, знал бы способ проще:
Это даже во встроенной справке (F1) есть.
>int(rand_range(0, 4))
>int(rand_range(0, 321))
А если бы читал официальную документацию вместо просмотра чужих туториалов, знал бы способ проще:
>randi() % 5
>randi() % 322
Это даже во встроенной справке (F1) есть.
>>49136
Лучше вообще не использовать магические константы.
randi() % items.size()
randi() % твоя_карта.width
Лучше вообще не использовать магические константы.
randi() % items.size()
randi() % твоя_карта.width
>>48655
Благодаря помощи анона сделал логику заливки одной области(и через "спрайт в полигон" и по пиксельно, хз что оставлю).
Возможно, мудрый анон подскажет, как лучше сделать закрашивание опеределнной области инструментом типа карандаш\кисть? Как их лучше реализовать? Сейчас пробую сделать попиксельно, пока выходит лапша из кода.
Благодаря помощи анона сделал логику заливки одной области(и через "спрайт в полигон" и по пиксельно, хз что оставлю).
Возможно, мудрый анон подскажет, как лучше сделать закрашивание опеределнной области инструментом типа карандаш\кисть? Как их лучше реализовать? Сейчас пробую сделать попиксельно, пока выходит лапша из кода.
>>49159
Ты имеешь в виду закрашивание от руки?
Вариант 1, обычный в редакторах графики:
1. Пользователь выделяет область.
2. Ты её каким-то образом отмечаешь у себя (в зависимости от реализации определения зон). Можешь заранее скопировать в отдельную картинку, сделать дырку в оригинальной картинке и показывать эту копию ниже оригинала - так лишнее отрежется.
3. Обрабатываешь все нажатия только внутри этой области, за её пределами не обрабатываешь. Если на предыдущем шаге сделал копию, то на этом шаге не нужно лишних проверок - лишнее само скроется.
4. Если делал копию, то завершающим шагом будет встраивание участка копии в оригинал, так, как это видит пользователь. Можно разными способами сделать, но, думаю, лучше всего будет через Viewport.
Вариант 2, более удобный для игрушки-рисовалки: пользователь ничего специально не выбирает, но когда он кликает куда-то и начинает вести указатель в сторону, ты отмечаешь у себя зону, в которой он начал, и перед каждым нанесением мазка/штриха проверяешь, попадает ли он точно в эту зону или нет; если не попадает, то просто его не рисуешь. Чтобы закрасить другую зону, пользователь должен просто отпустить клавишу/палец, перевести курсор в другую зону и снова зажать. В теории этот процесс тоже можно оптимизировать копированием зоны в буфер и созданием прозрачного окошка, но нужно учитывать, что пользователь может кликать много раз подряд - процессы копирования и склейки слоёв должны быть достаточно быстрыми для этого.
Если ты про автоматическое закрашивание в стиле обновленного MS Paint "типа карандашный штрих" - то это должно быть проще, можно заранее подготовить текстуру или нарисовать её процедурно, а потом вырезать из неё фрагмент по форме закрашиваемой зоны.
Чтобы минимизировать "лапшу", стоит разрабатывать строго снизу вверх. Делаешь какую-то автономную часть программы низшего уровня, а потом делаешь часть программы уровнем выше, которая командует этой низшей частью - тогда не будет лишних связей снизу вверх. В Godot для этого очень подходят сигналы - когда нужно сообщить что-то с самого низа иерархии куда-то наверх, абстрагируясь от родителей/владельцев.
>как лучше сделать закрашивание опеределнной области инструментом типа карандаш\кисть?
Ты имеешь в виду закрашивание от руки?
Вариант 1, обычный в редакторах графики:
1. Пользователь выделяет область.
2. Ты её каким-то образом отмечаешь у себя (в зависимости от реализации определения зон). Можешь заранее скопировать в отдельную картинку, сделать дырку в оригинальной картинке и показывать эту копию ниже оригинала - так лишнее отрежется.
3. Обрабатываешь все нажатия только внутри этой области, за её пределами не обрабатываешь. Если на предыдущем шаге сделал копию, то на этом шаге не нужно лишних проверок - лишнее само скроется.
4. Если делал копию, то завершающим шагом будет встраивание участка копии в оригинал, так, как это видит пользователь. Можно разными способами сделать, но, думаю, лучше всего будет через Viewport.
Вариант 2, более удобный для игрушки-рисовалки: пользователь ничего специально не выбирает, но когда он кликает куда-то и начинает вести указатель в сторону, ты отмечаешь у себя зону, в которой он начал, и перед каждым нанесением мазка/штриха проверяешь, попадает ли он точно в эту зону или нет; если не попадает, то просто его не рисуешь. Чтобы закрасить другую зону, пользователь должен просто отпустить клавишу/палец, перевести курсор в другую зону и снова зажать. В теории этот процесс тоже можно оптимизировать копированием зоны в буфер и созданием прозрачного окошка, но нужно учитывать, что пользователь может кликать много раз подряд - процессы копирования и склейки слоёв должны быть достаточно быстрыми для этого.
Если ты про автоматическое закрашивание в стиле обновленного MS Paint "типа карандашный штрих" - то это должно быть проще, можно заранее подготовить текстуру или нарисовать её процедурно, а потом вырезать из неё фрагмент по форме закрашиваемой зоны.
>пока выходит лапша из кода
Чтобы минимизировать "лапшу", стоит разрабатывать строго снизу вверх. Делаешь какую-то автономную часть программы низшего уровня, а потом делаешь часть программы уровнем выше, которая командует этой низшей частью - тогда не будет лишних связей снизу вверх. В Godot для этого очень подходят сигналы - когда нужно сообщить что-то с самого низа иерархии куда-то наверх, абстрагируясь от родителей/владельцев.
>>49159
Ты имеешь в виду закрашивание от руки?
Вариант 1, обычный в редакторах графики:
1. Пользователь выделяет область.
2. Ты её каким-то образом отмечаешь у себя (в зависимости от реализации определения зон). Можешь заранее скопировать в отдельную картинку, сделать дырку в оригинальной картинке и показывать эту копию ниже оригинала - так лишнее отрежется.
3. Обрабатываешь все нажатия только внутри этой области, за её пределами не обрабатываешь. Если на предыдущем шаге сделал копию, то на этом шаге не нужно лишних проверок - лишнее само скроется.
4. Если делал копию, то завершающим шагом будет встраивание участка копии в оригинал, так, как это видит пользователь. Можно разными способами сделать, но, думаю, лучше всего будет через Viewport.
Вариант 2, более удобный для игрушки-рисовалки: пользователь ничего специально не выбирает, но когда он кликает куда-то и начинает вести указатель в сторону, ты отмечаешь у себя зону, в которой он начал, и перед каждым нанесением мазка/штриха проверяешь, попадает ли он точно в эту зону или нет; если не попадает, то просто его не рисуешь. Чтобы закрасить другую зону, пользователь должен просто отпустить клавишу/палец, перевести курсор в другую зону и снова зажать. В теории этот процесс тоже можно оптимизировать копированием зоны в буфер и созданием прозрачного окошка, но нужно учитывать, что пользователь может кликать много раз подряд - процессы копирования и склейки слоёв должны быть достаточно быстрыми для этого.
Если ты про автоматическое закрашивание в стиле обновленного MS Paint "типа карандашный штрих" - то это должно быть проще, можно заранее подготовить текстуру или нарисовать её процедурно, а потом вырезать из неё фрагмент по форме закрашиваемой зоны.
Чтобы минимизировать "лапшу", стоит разрабатывать строго снизу вверх. Делаешь какую-то автономную часть программы низшего уровня, а потом делаешь часть программы уровнем выше, которая командует этой низшей частью - тогда не будет лишних связей снизу вверх. В Godot для этого очень подходят сигналы - когда нужно сообщить что-то с самого низа иерархии куда-то наверх, абстрагируясь от родителей/владельцев.
>как лучше сделать закрашивание опеределнной области инструментом типа карандаш\кисть?
Ты имеешь в виду закрашивание от руки?
Вариант 1, обычный в редакторах графики:
1. Пользователь выделяет область.
2. Ты её каким-то образом отмечаешь у себя (в зависимости от реализации определения зон). Можешь заранее скопировать в отдельную картинку, сделать дырку в оригинальной картинке и показывать эту копию ниже оригинала - так лишнее отрежется.
3. Обрабатываешь все нажатия только внутри этой области, за её пределами не обрабатываешь. Если на предыдущем шаге сделал копию, то на этом шаге не нужно лишних проверок - лишнее само скроется.
4. Если делал копию, то завершающим шагом будет встраивание участка копии в оригинал, так, как это видит пользователь. Можно разными способами сделать, но, думаю, лучше всего будет через Viewport.
Вариант 2, более удобный для игрушки-рисовалки: пользователь ничего специально не выбирает, но когда он кликает куда-то и начинает вести указатель в сторону, ты отмечаешь у себя зону, в которой он начал, и перед каждым нанесением мазка/штриха проверяешь, попадает ли он точно в эту зону или нет; если не попадает, то просто его не рисуешь. Чтобы закрасить другую зону, пользователь должен просто отпустить клавишу/палец, перевести курсор в другую зону и снова зажать. В теории этот процесс тоже можно оптимизировать копированием зоны в буфер и созданием прозрачного окошка, но нужно учитывать, что пользователь может кликать много раз подряд - процессы копирования и склейки слоёв должны быть достаточно быстрыми для этого.
Если ты про автоматическое закрашивание в стиле обновленного MS Paint "типа карандашный штрих" - то это должно быть проще, можно заранее подготовить текстуру или нарисовать её процедурно, а потом вырезать из неё фрагмент по форме закрашиваемой зоны.
>пока выходит лапша из кода
Чтобы минимизировать "лапшу", стоит разрабатывать строго снизу вверх. Делаешь какую-то автономную часть программы низшего уровня, а потом делаешь часть программы уровнем выше, которая командует этой низшей частью - тогда не будет лишних связей снизу вверх. В Godot для этого очень подходят сигналы - когда нужно сообщить что-то с самого низа иерархии куда-то наверх, абстрагируясь от родителей/владельцев.
1,8 Мб, mp4,800x600, 1:52
>>48910
Это один маленький Line2D для разработчика, но гигантский скачок UX для всех игроков.
Кратко об идеях:
× Весь геймплей в top-down перспективе.
× Графически хочется чего-то необычного, вроде приближения к "фоновой" планете/звезде несмотря на движение строго в плоскости экрана. Т.е. не типичный параллакс, но другой вариант псевдо-3D. Представляю это как спуск по крутому склону в колодец с огромным объектом на самом дне. Узнали? Согласны?
× Вселенная всё же плоская. Из любой точки можно прилететь в любую другую на любом двигателе. Особые сверхсветовые двигатели только чтобы не аутировать несколько месяцев в абсолютной пустоте.
× В физике и балансе прицел на интересный и бодрый геймплей, по возможности без гринда, но не банальное "пиу-пиу", которого и без меня полно.
× Игрок управляет в первую очередь человечком в скафандре, а уже тот может управлять космическим кораблём, переключая камеру и схему управления.
× Корабль нужно строить из блоков человечком, без автоматизации, но можно купить готовый или даже захватить чужой, если сможешь.
× Блоки корабля повреждаются от столкновений, так что пинать астероиды катастрофически вредно, но зато мелкие пиратские истребители легко и просто размазываются об обшивку большого корабля.
× Внутрь некоторых блоков корабля человечек может входить, т.е. корабль может иметь интерьер. Это может быть как один блок-кабина, так и большая сеть комнат.
× Интерьерные блоки могут давать бонусы и иметь дополнительные свойства, такие как восполнение кислорода в баллонах и более удобное движение.
× Заполненность интерьерного блока кислородом, думаю, несложно симулировать, к тому же это важная часть симуляции космоса. Может выбросить в космос через дыру в обшивке.
× Но важнее всего - доступ к оборудованию в блоках, чтобы не летать вокруг корабля в скафандре.
× Движение в скафандре в космосе - только вперёд и вращение, а в интерьере как обычно (WASD).
× У скафандра ограниченные ресурсы, а у персонажа потребности в кислороде, еде, отдыхе и т.п.
× Конечно, начало игры в готовой стартовой капсуле со всем необходимым для жизни, рядом с источниками ресурсов для починки и расширения.
× В случае смерти респавн новым персонажем в практически случайном месте вселенной так, что найти своё старое тело и ресурсы технически возможно, но добраться и найти всё же будет сложно.
× Космос сам по себе не имеет "уровней сложности", так что начинать развитие можно почти где угодно.
× Кроме очевидных астероидов, торговых станций и кораблей, очень привлекает идея приземления на любые найденные планеты для пеших прогулок.
× Приземление натуральное, кораблём или капсулой, а не унылая телепортация человечка "лучом".
× Размер планет небольшой и копать там нельзя, но возможно построить базу с крепким фундаментом, которая не улетит и не разобьётся об астероид (лол).
× Возможность мирных контактов, найма помощников и даже развитие социальных связей - ибо игра про реальный пустой космос слишком депрессивна.
× Монстров тоже можно сделать, но нужно подумать.
× Хочется совместить ленивую генерацию с подробным моделированием жизни так, чтобы все события во вселенной были взаимосвязаны, но игра не грузила компьютер симуляцией 100500 планет, на которых игрок никогда не бывал и не будет.
× Персонаж игрока начинает с амнезией. Большинство знаний о вселенной процедурны и добываются путём получения книг на знакомых языках.
× Незнакомый язык персонаж не способен понять, игроку не показывается даже никаких подсказок. Обучение языку не по словам, а целиком, например, после покупки словаря или вживления чипа.
× Несколько созданных вручную рас, но процедурная генерация фракций. Хотя, возможно, наверное, и расы генерировать, подумаю об этом. Основная проблема в портретах, т.к. в мире все персонажи с видом сверху - то есть видны в основном макушки.
Ну как, не слишком много кирильства? Щас ещё немного пофантазирую, а потом опять заброшу на несколько месяцев, как всегда делаю. Кому надо - можете "воровать идеи", всё равно вы не сделаете то же самое, что хотел бы сделать я, так что всё норм.
Это один маленький Line2D для разработчика, но гигантский скачок UX для всех игроков.
Кратко об идеях:
× Весь геймплей в top-down перспективе.
× Графически хочется чего-то необычного, вроде приближения к "фоновой" планете/звезде несмотря на движение строго в плоскости экрана. Т.е. не типичный параллакс, но другой вариант псевдо-3D. Представляю это как спуск по крутому склону в колодец с огромным объектом на самом дне. Узнали? Согласны?
× Вселенная всё же плоская. Из любой точки можно прилететь в любую другую на любом двигателе. Особые сверхсветовые двигатели только чтобы не аутировать несколько месяцев в абсолютной пустоте.
× В физике и балансе прицел на интересный и бодрый геймплей, по возможности без гринда, но не банальное "пиу-пиу", которого и без меня полно.
× Игрок управляет в первую очередь человечком в скафандре, а уже тот может управлять космическим кораблём, переключая камеру и схему управления.
× Корабль нужно строить из блоков человечком, без автоматизации, но можно купить готовый или даже захватить чужой, если сможешь.
× Блоки корабля повреждаются от столкновений, так что пинать астероиды катастрофически вредно, но зато мелкие пиратские истребители легко и просто размазываются об обшивку большого корабля.
× Внутрь некоторых блоков корабля человечек может входить, т.е. корабль может иметь интерьер. Это может быть как один блок-кабина, так и большая сеть комнат.
× Интерьерные блоки могут давать бонусы и иметь дополнительные свойства, такие как восполнение кислорода в баллонах и более удобное движение.
× Заполненность интерьерного блока кислородом, думаю, несложно симулировать, к тому же это важная часть симуляции космоса. Может выбросить в космос через дыру в обшивке.
× Но важнее всего - доступ к оборудованию в блоках, чтобы не летать вокруг корабля в скафандре.
× Движение в скафандре в космосе - только вперёд и вращение, а в интерьере как обычно (WASD).
× У скафандра ограниченные ресурсы, а у персонажа потребности в кислороде, еде, отдыхе и т.п.
× Конечно, начало игры в готовой стартовой капсуле со всем необходимым для жизни, рядом с источниками ресурсов для починки и расширения.
× В случае смерти респавн новым персонажем в практически случайном месте вселенной так, что найти своё старое тело и ресурсы технически возможно, но добраться и найти всё же будет сложно.
× Космос сам по себе не имеет "уровней сложности", так что начинать развитие можно почти где угодно.
× Кроме очевидных астероидов, торговых станций и кораблей, очень привлекает идея приземления на любые найденные планеты для пеших прогулок.
× Приземление натуральное, кораблём или капсулой, а не унылая телепортация человечка "лучом".
× Размер планет небольшой и копать там нельзя, но возможно построить базу с крепким фундаментом, которая не улетит и не разобьётся об астероид (лол).
× Возможность мирных контактов, найма помощников и даже развитие социальных связей - ибо игра про реальный пустой космос слишком депрессивна.
× Монстров тоже можно сделать, но нужно подумать.
× Хочется совместить ленивую генерацию с подробным моделированием жизни так, чтобы все события во вселенной были взаимосвязаны, но игра не грузила компьютер симуляцией 100500 планет, на которых игрок никогда не бывал и не будет.
× Персонаж игрока начинает с амнезией. Большинство знаний о вселенной процедурны и добываются путём получения книг на знакомых языках.
× Незнакомый язык персонаж не способен понять, игроку не показывается даже никаких подсказок. Обучение языку не по словам, а целиком, например, после покупки словаря или вживления чипа.
× Несколько созданных вручную рас, но процедурная генерация фракций. Хотя, возможно, наверное, и расы генерировать, подумаю об этом. Основная проблема в портретах, т.к. в мире все персонажи с видом сверху - то есть видны в основном макушки.
Ну как, не слишком много кирильства? Щас ещё немного пофантазирую, а потом опять заброшу на несколько месяцев, как всегда делаю. Кому надо - можете "воровать идеи", всё равно вы не сделаете то же самое, что хотел бы сделать я, так что всё норм.
1,8 Мб, mp4,800x600, 1:52
>>48910
Это один маленький Line2D для разработчика, но гигантский скачок UX для всех игроков.
Кратко об идеях:
× Весь геймплей в top-down перспективе.
× Графически хочется чего-то необычного, вроде приближения к "фоновой" планете/звезде несмотря на движение строго в плоскости экрана. Т.е. не типичный параллакс, но другой вариант псевдо-3D. Представляю это как спуск по крутому склону в колодец с огромным объектом на самом дне. Узнали? Согласны?
× Вселенная всё же плоская. Из любой точки можно прилететь в любую другую на любом двигателе. Особые сверхсветовые двигатели только чтобы не аутировать несколько месяцев в абсолютной пустоте.
× В физике и балансе прицел на интересный и бодрый геймплей, по возможности без гринда, но не банальное "пиу-пиу", которого и без меня полно.
× Игрок управляет в первую очередь человечком в скафандре, а уже тот может управлять космическим кораблём, переключая камеру и схему управления.
× Корабль нужно строить из блоков человечком, без автоматизации, но можно купить готовый или даже захватить чужой, если сможешь.
× Блоки корабля повреждаются от столкновений, так что пинать астероиды катастрофически вредно, но зато мелкие пиратские истребители легко и просто размазываются об обшивку большого корабля.
× Внутрь некоторых блоков корабля человечек может входить, т.е. корабль может иметь интерьер. Это может быть как один блок-кабина, так и большая сеть комнат.
× Интерьерные блоки могут давать бонусы и иметь дополнительные свойства, такие как восполнение кислорода в баллонах и более удобное движение.
× Заполненность интерьерного блока кислородом, думаю, несложно симулировать, к тому же это важная часть симуляции космоса. Может выбросить в космос через дыру в обшивке.
× Но важнее всего - доступ к оборудованию в блоках, чтобы не летать вокруг корабля в скафандре.
× Движение в скафандре в космосе - только вперёд и вращение, а в интерьере как обычно (WASD).
× У скафандра ограниченные ресурсы, а у персонажа потребности в кислороде, еде, отдыхе и т.п.
× Конечно, начало игры в готовой стартовой капсуле со всем необходимым для жизни, рядом с источниками ресурсов для починки и расширения.
× В случае смерти респавн новым персонажем в практически случайном месте вселенной так, что найти своё старое тело и ресурсы технически возможно, но добраться и найти всё же будет сложно.
× Космос сам по себе не имеет "уровней сложности", так что начинать развитие можно почти где угодно.
× Кроме очевидных астероидов, торговых станций и кораблей, очень привлекает идея приземления на любые найденные планеты для пеших прогулок.
× Приземление натуральное, кораблём или капсулой, а не унылая телепортация человечка "лучом".
× Размер планет небольшой и копать там нельзя, но возможно построить базу с крепким фундаментом, которая не улетит и не разобьётся об астероид (лол).
× Возможность мирных контактов, найма помощников и даже развитие социальных связей - ибо игра про реальный пустой космос слишком депрессивна.
× Монстров тоже можно сделать, но нужно подумать.
× Хочется совместить ленивую генерацию с подробным моделированием жизни так, чтобы все события во вселенной были взаимосвязаны, но игра не грузила компьютер симуляцией 100500 планет, на которых игрок никогда не бывал и не будет.
× Персонаж игрока начинает с амнезией. Большинство знаний о вселенной процедурны и добываются путём получения книг на знакомых языках.
× Незнакомый язык персонаж не способен понять, игроку не показывается даже никаких подсказок. Обучение языку не по словам, а целиком, например, после покупки словаря или вживления чипа.
× Несколько созданных вручную рас, но процедурная генерация фракций. Хотя, возможно, наверное, и расы генерировать, подумаю об этом. Основная проблема в портретах, т.к. в мире все персонажи с видом сверху - то есть видны в основном макушки.
Ну как, не слишком много кирильства? Щас ещё немного пофантазирую, а потом опять заброшу на несколько месяцев, как всегда делаю. Кому надо - можете "воровать идеи", всё равно вы не сделаете то же самое, что хотел бы сделать я, так что всё норм.
Это один маленький Line2D для разработчика, но гигантский скачок UX для всех игроков.
Кратко об идеях:
× Весь геймплей в top-down перспективе.
× Графически хочется чего-то необычного, вроде приближения к "фоновой" планете/звезде несмотря на движение строго в плоскости экрана. Т.е. не типичный параллакс, но другой вариант псевдо-3D. Представляю это как спуск по крутому склону в колодец с огромным объектом на самом дне. Узнали? Согласны?
× Вселенная всё же плоская. Из любой точки можно прилететь в любую другую на любом двигателе. Особые сверхсветовые двигатели только чтобы не аутировать несколько месяцев в абсолютной пустоте.
× В физике и балансе прицел на интересный и бодрый геймплей, по возможности без гринда, но не банальное "пиу-пиу", которого и без меня полно.
× Игрок управляет в первую очередь человечком в скафандре, а уже тот может управлять космическим кораблём, переключая камеру и схему управления.
× Корабль нужно строить из блоков человечком, без автоматизации, но можно купить готовый или даже захватить чужой, если сможешь.
× Блоки корабля повреждаются от столкновений, так что пинать астероиды катастрофически вредно, но зато мелкие пиратские истребители легко и просто размазываются об обшивку большого корабля.
× Внутрь некоторых блоков корабля человечек может входить, т.е. корабль может иметь интерьер. Это может быть как один блок-кабина, так и большая сеть комнат.
× Интерьерные блоки могут давать бонусы и иметь дополнительные свойства, такие как восполнение кислорода в баллонах и более удобное движение.
× Заполненность интерьерного блока кислородом, думаю, несложно симулировать, к тому же это важная часть симуляции космоса. Может выбросить в космос через дыру в обшивке.
× Но важнее всего - доступ к оборудованию в блоках, чтобы не летать вокруг корабля в скафандре.
× Движение в скафандре в космосе - только вперёд и вращение, а в интерьере как обычно (WASD).
× У скафандра ограниченные ресурсы, а у персонажа потребности в кислороде, еде, отдыхе и т.п.
× Конечно, начало игры в готовой стартовой капсуле со всем необходимым для жизни, рядом с источниками ресурсов для починки и расширения.
× В случае смерти респавн новым персонажем в практически случайном месте вселенной так, что найти своё старое тело и ресурсы технически возможно, но добраться и найти всё же будет сложно.
× Космос сам по себе не имеет "уровней сложности", так что начинать развитие можно почти где угодно.
× Кроме очевидных астероидов, торговых станций и кораблей, очень привлекает идея приземления на любые найденные планеты для пеших прогулок.
× Приземление натуральное, кораблём или капсулой, а не унылая телепортация человечка "лучом".
× Размер планет небольшой и копать там нельзя, но возможно построить базу с крепким фундаментом, которая не улетит и не разобьётся об астероид (лол).
× Возможность мирных контактов, найма помощников и даже развитие социальных связей - ибо игра про реальный пустой космос слишком депрессивна.
× Монстров тоже можно сделать, но нужно подумать.
× Хочется совместить ленивую генерацию с подробным моделированием жизни так, чтобы все события во вселенной были взаимосвязаны, но игра не грузила компьютер симуляцией 100500 планет, на которых игрок никогда не бывал и не будет.
× Персонаж игрока начинает с амнезией. Большинство знаний о вселенной процедурны и добываются путём получения книг на знакомых языках.
× Незнакомый язык персонаж не способен понять, игроку не показывается даже никаких подсказок. Обучение языку не по словам, а целиком, например, после покупки словаря или вживления чипа.
× Несколько созданных вручную рас, но процедурная генерация фракций. Хотя, возможно, наверное, и расы генерировать, подумаю об этом. Основная проблема в портретах, т.к. в мире все персонажи с видом сверху - то есть видны в основном макушки.
Ну как, не слишком много кирильства? Щас ещё немного пофантазирую, а потом опять заброшу на несколько месяцев, как всегда делаю. Кому надо - можете "воровать идеи", всё равно вы не сделаете то же самое, что хотел бы сделать я, так что всё норм.
>>49174
Обучение языкам делай как в кингдом каме, там годно реализовано обучение чтению ГГ.
Обучение языкам делай как в кингдом каме, там годно реализовано обучение чтению ГГ.
>>49159
Я бы подумал в сторону "маски", а сделать можно по разному, хоть отдельными слоями (типа разбиваешь свою картинку на N спрайтов и рисуешь только в одном)
Я бы подумал в сторону "маски", а сделать можно по разному, хоть отдельными слоями (типа разбиваешь свою картинку на N спрайтов и рисуешь только в одном)
728 Кб, 850x676Я не смог. Надеюсь в будущем больше не попытаюсь повторить свою неудачу.
>>49241
Рассказывай подробно, что ты хотел сделать и что ты не смог сделать. Только обещай следовать советам, а не отказываться от всего с очередным нытьём.
>Я не смог
Рассказывай подробно, что ты хотел сделать и что ты не смог сделать. Только обещай следовать советам, а не отказываться от всего с очередным нытьём.
>>49241
А у меня наоборот подъем, сейчас с новыми силами все так легко получается.
А у меня наоборот подъем, сейчас с новыми силами все так легко получается.
>>49279
Я тогда тоже не смог. Мне лень рисовать арты и пилить менюшки (не придумал как). Еще надо скорборд сделать.
Я тогда тоже не смог. Мне лень рисовать арты и пилить менюшки (не придумал как). Еще надо скорборд сделать.
Как реализовать навигацию по вкладкам как в браузере? То есть при нажатии Ctrl + Tab - перемещаемся вперед, при Ctrl + Shift + Tab - назад.
Сделал через Input map - при нажатии Ctrl + Shift + Tab помимо нужного, выполняется и скрипт для перемещения вперед.
Сделал через Input map - при нажатии Ctrl + Shift + Tab помимо нужного, выполняется и скрипт для перемещения вперед.
>>49313
О, спасибо.
О, спасибо.
>>49293
Делай мэдскиллзы, используй их как плейсхолдеры, а потом будешь заменять на норм арт.
Это самое простое в Godot, у него достаточно мощная гуишная система. Читай в документации туториалы.
Это тоже очень легко сделать.
>>49362
Вот видишь, часть арта для игры готова, молодец.
>Мне лень рисовать арты
Делай мэдскиллзы, используй их как плейсхолдеры, а потом будешь заменять на норм арт.
>пилить менюшки (не придумал как)
Это самое простое в Godot, у него достаточно мощная гуишная система. Читай в документации туториалы.
>Еще надо скорборд сделать.
Это тоже очень легко сделать.
>>49362
Вот видишь, часть арта для игры готова, молодец.
>>49439
А у меня сплошные успехи в последнее время. Я прям с новыми силами бросился доделывать игру.
А у меня сплошные успехи в последнее время. Я прям с новыми силами бросился доделывать игру.
>>49439
Отставить нытьё, салага, здесь нет твоей мамки. Упал-отжался! Доложить о возникших при выполнении боевой задачи проблемах! БЫСТР-Р-РА!
Сириусли, какая-то половая тряпка пытается сделать игру про танчики, не лучше ли было сделать какой-то симулятор фермера или танцев в клубе? Найди себе что-то, что будет тебя стимулировать...
>много неудач которые мне никак не преодолеть
Отставить нытьё, салага, здесь нет твоей мамки. Упал-отжался! Доложить о возникших при выполнении боевой задачи проблемах! БЫСТР-Р-РА!
Сириусли, какая-то половая тряпка пытается сделать игру про танчики, не лучше ли было сделать какой-то симулятор фермера или танцев в клубе? Найди себе что-то, что будет тебя стимулировать...
>>49450
Может и не надо человека заставлять делать то, что не выходит. Я вот бросил кочалку и не жалею.
Может и не надо человека заставлять делать то, что не выходит. Я вот бросил кочалку и не жалею.
>>49512 (Del)
Фух, я уже думал у вас тут тред аномальный, ни одного срачедауна, но все в порядке
Фух, я уже думал у вас тут тред аномальный, ни одного срачедауна, но все в порядке
61 Кб, 574x479>>41844
Хз, поздновато ли, но в tf2 есть популярный макрос для такого мувмента. Пикрилейтед. Заключается в том, при нажатии клавиши она не только тянет тебя в нужную сторону, но и оффает противоположное направление. Хз как это тебе переложить в годоту, это так, на заметку домохозяйкам.
Хз, поздновато ли, но в tf2 есть популярный макрос для такого мувмента. Пикрилейтед. Заключается в том, при нажатии клавиши она не только тянет тебя в нужную сторону, но и оффает противоположное направление. Хз как это тебе переложить в годоту, это так, на заметку домохозяйкам.
183 Кб, 768x1024>>49516 (Del)
Да мне пох както, я по видосам с ютуба сделал себе игру
Тайловая карта которую сам нарисовал, деревья камушки пеньки рандомные, предметы которые можно поднимать
Сегодня еще инвентарь сделаю
Это самое инетересное в моей жизни за последние два года и мне пиздато
Да мне пох както, я по видосам с ютуба сделал себе игру
Тайловая карта которую сам нарисовал, деревья камушки пеньки рандомные, предметы которые можно поднимать
Сегодня еще инвентарь сделаю
Это самое инетересное в моей жизни за последние два года и мне пиздато
>>49524
лесополоса?
>самое интересное проишествие за 2 года - копирование писклявого порриджа с ютуба
>пиздосокот
лесополоса?
114 Кб, mp4,500x204, 0:04
>>49524
Красава! Респект!
Красава! Респект!
85 Кб, 723x444Как мне овладеть движком и языком чтобы потом себе спокойно без слишком большого гугления запилить игру?
Самому с нуля без гайдов создать змейку/марио/гоночку?
Или сразу делать игру мечты гугля по пути все что непонятно?
Хотелось бы какой то интересный (мне) клон вампир сурвайвал запилить (может даже сразу на андроид) а там еще какие нибудь механики накрутить или игру другого жанра сделать
Самому с нуля без гайдов создать змейку/марио/гоночку?
Или сразу делать игру мечты гугля по пути все что непонятно?
Хотелось бы какой то интересный (мне) клон вампир сурвайвал запилить (может даже сразу на андроид) а там еще какие нибудь механики накрутить или игру другого жанра сделать
243 Кб, 1165x708Попробовал разбить состояния на отдельные блоки - в одних только выполняются команды, в других только проверяются условия. Соответственно количество переходов между блоками примерно удвоилось, стало только запутанней - goto hell.
>>49576
this. возможно не доползешь до финиша это сложно, но узнаешь все что интересно и все что не интересно тоже
>Или сразу делать игру мечты гугля по пути все что непонятно?
this. возможно не доползешь до финиша это сложно, но узнаешь все что интересно и все что не интересно тоже
>>49576
В любом деле сначала определяешься с целью, и потом под нее получаешь знания.
Тебе не нужен весь движок изучать.
Только те части, которые необходимы для твоей игры.
Создавая с 0 змейку и прочие игры, ты изучаешь что общего есть у всех игр(Гуи, менеджер сцен, сигнальная шина и т.д.) и овладеваешь редактором.
В любом деле сначала определяешься с целью, и потом под нее получаешь знания.
Тебе не нужен весь движок изучать.
Только те части, которые необходимы для твоей игры.
Создавая с 0 змейку и прочие игры, ты изучаешь что общего есть у всех игр(Гуи, менеджер сцен, сигнальная шина и т.д.) и овладеваешь редактором.
>>49576
Найти максимально похожий под то что тебе надо гайд. Я свое говно делал по гайду на матч3, хотя у меня совсем другой механ, но элементы матч3 есть.
Это мне позволило запилить с нуля игровое поле, спав/снос блоков с них и впринципе понимание что и как в годоте.
Найти максимально похожий под то что тебе надо гайд. Я свое говно делал по гайду на матч3, хотя у меня совсем другой механ, но элементы матч3 есть.
Это мне позволило запилить с нуля игровое поле, спав/снос блоков с них и впринципе понимание что и как в годоте.
>>49464
Так он сам приходит спрашивать вопросы, а потом ноет, что "ничего не получается". Значит, хочет всё-таки. А не выходит потому, что не пытается слушать советов (изучить базу, прежде чем делать что-то своё), прыгает с темы на тему (вообще скипнул все базовые туториалы и пошёл гуглить "как сделать игру"), невнимательно смотрит даже то, что сам нашёл и пытается повторить (не смог кнопку забиндить, а потом пересмотрел видео и понял свою ошибку, но перед этим успел поныть о том, что "даже такое не получается").
У тебя были медицинские противопоказания.
>>49576
Владение движком и языком не избавляет тебя от необходимости гуглить то, как какие-то игровые системы и механики могут быть реализованы (реализованы в других играх), чего хочет игрок и т.д. Сделать хорошую игру сегодня можно только исследуя существующие игры и свою ЦА, эпоха первооткрывателей давно прошла. Ты, конечно, можешь изобретать велосипеды, но потом будешь сильно демотивирован, когда обнаружишь реализацию своей идеи в древней игре из 90-х, которая лучше твоей.
Совсем без гайдов ты ничего сделать не сможешь, тем более если ты программировать в принципе не умеешь и опыта с другими игровыми движками не имел. Вот если ты умеешь программировать на каком-то другом языке, то легко освоишь GDScript, если ты раньше уже делал игры на каком-то движке, то без проблем вкатишься в Godot. Но полный ньюфаг в геймдеве должен следовать урокам и рекомендациям олдфагов, иначе разочаруешься из-за слишком высокой сложности темы.
Это плохой подход, выше по треду есть наглядный пример ньюфага, который пытается идти таким путём и у него "ничего не получается". Тебе необходимо усвоить базу геймдева, прежде чем рваться пилить свою "игру мечты".
Согласен с анонами выше, что ВЕСЬ движок изучать нет никакой необходимости, например, с системой звука можно будет разобраться позже, если ты не делаешь игру, геймплей которой сильно завязан на звук (всякие раннеры, генерирующие дорожку по загруженной в них мелодии, и, конечно, ритм-игры). Но прежде чем пилить свою игру мечты, стоит разобраться с тем, как игры в принципе устроены, что такое программирование, какие-то базовые знания получить. Иначе потом ты зароешься в говнокод своей игры, и чтобы переделать нормально, тебе придётся начинать с нуля. Это как вместо популярного маршрута в лесу переть напролом через заросли, заблудиться, выйти в неправильном месте и снова пойти напролом через заросли, отказываясь пользоваться путеводителем и всем известными дорогами.
>заставлять делать то, что не выходит
Так он сам приходит спрашивать вопросы, а потом ноет, что "ничего не получается". Значит, хочет всё-таки. А не выходит потому, что не пытается слушать советов (изучить базу, прежде чем делать что-то своё), прыгает с темы на тему (вообще скипнул все базовые туториалы и пошёл гуглить "как сделать игру"), невнимательно смотрит даже то, что сам нашёл и пытается повторить (не смог кнопку забиндить, а потом пересмотрел видео и понял свою ошибку, но перед этим успел поныть о том, что "даже такое не получается").
>Я вот бросил кочалку и не жалею.
У тебя были медицинские противопоказания.
>>49576
>овладеть движком и языком
>без слишком большого гугления
Владение движком и языком не избавляет тебя от необходимости гуглить то, как какие-то игровые системы и механики могут быть реализованы (реализованы в других играх), чего хочет игрок и т.д. Сделать хорошую игру сегодня можно только исследуя существующие игры и свою ЦА, эпоха первооткрывателей давно прошла. Ты, конечно, можешь изобретать велосипеды, но потом будешь сильно демотивирован, когда обнаружишь реализацию своей идеи в древней игре из 90-х, которая лучше твоей.
>Самому с нуля без гайдов создать змейку/марио/гоночку?
Совсем без гайдов ты ничего сделать не сможешь, тем более если ты программировать в принципе не умеешь и опыта с другими игровыми движками не имел. Вот если ты умеешь программировать на каком-то другом языке, то легко освоишь GDScript, если ты раньше уже делал игры на каком-то движке, то без проблем вкатишься в Godot. Но полный ньюфаг в геймдеве должен следовать урокам и рекомендациям олдфагов, иначе разочаруешься из-за слишком высокой сложности темы.
>Или сразу делать игру мечты гугля по пути все что непонятно?
Это плохой подход, выше по треду есть наглядный пример ньюфага, который пытается идти таким путём и у него "ничего не получается". Тебе необходимо усвоить базу геймдева, прежде чем рваться пилить свою "игру мечты".
Согласен с анонами выше, что ВЕСЬ движок изучать нет никакой необходимости, например, с системой звука можно будет разобраться позже, если ты не делаешь игру, геймплей которой сильно завязан на звук (всякие раннеры, генерирующие дорожку по загруженной в них мелодии, и, конечно, ритм-игры). Но прежде чем пилить свою игру мечты, стоит разобраться с тем, как игры в принципе устроены, что такое программирование, какие-то базовые знания получить. Иначе потом ты зароешься в говнокод своей игры, и чтобы переделать нормально, тебе придётся начинать с нуля. Это как вместо популярного маршрута в лесу переть напролом через заросли, заблудиться, выйти в неправильном месте и снова пойти напролом через заросли, отказываясь пользоваться путеводителем и всем известными дорогами.
>>49464
Так он сам приходит спрашивать вопросы, а потом ноет, что "ничего не получается". Значит, хочет всё-таки. А не выходит потому, что не пытается слушать советов (изучить базу, прежде чем делать что-то своё), прыгает с темы на тему (вообще скипнул все базовые туториалы и пошёл гуглить "как сделать игру"), невнимательно смотрит даже то, что сам нашёл и пытается повторить (не смог кнопку забиндить, а потом пересмотрел видео и понял свою ошибку, но перед этим успел поныть о том, что "даже такое не получается").
У тебя были медицинские противопоказания.
>>49576
Владение движком и языком не избавляет тебя от необходимости гуглить то, как какие-то игровые системы и механики могут быть реализованы (реализованы в других играх), чего хочет игрок и т.д. Сделать хорошую игру сегодня можно только исследуя существующие игры и свою ЦА, эпоха первооткрывателей давно прошла. Ты, конечно, можешь изобретать велосипеды, но потом будешь сильно демотивирован, когда обнаружишь реализацию своей идеи в древней игре из 90-х, которая лучше твоей.
Совсем без гайдов ты ничего сделать не сможешь, тем более если ты программировать в принципе не умеешь и опыта с другими игровыми движками не имел. Вот если ты умеешь программировать на каком-то другом языке, то легко освоишь GDScript, если ты раньше уже делал игры на каком-то движке, то без проблем вкатишься в Godot. Но полный ньюфаг в геймдеве должен следовать урокам и рекомендациям олдфагов, иначе разочаруешься из-за слишком высокой сложности темы.
Это плохой подход, выше по треду есть наглядный пример ньюфага, который пытается идти таким путём и у него "ничего не получается". Тебе необходимо усвоить базу геймдева, прежде чем рваться пилить свою "игру мечты".
Согласен с анонами выше, что ВЕСЬ движок изучать нет никакой необходимости, например, с системой звука можно будет разобраться позже, если ты не делаешь игру, геймплей которой сильно завязан на звук (всякие раннеры, генерирующие дорожку по загруженной в них мелодии, и, конечно, ритм-игры). Но прежде чем пилить свою игру мечты, стоит разобраться с тем, как игры в принципе устроены, что такое программирование, какие-то базовые знания получить. Иначе потом ты зароешься в говнокод своей игры, и чтобы переделать нормально, тебе придётся начинать с нуля. Это как вместо популярного маршрута в лесу переть напролом через заросли, заблудиться, выйти в неправильном месте и снова пойти напролом через заросли, отказываясь пользоваться путеводителем и всем известными дорогами.
>заставлять делать то, что не выходит
Так он сам приходит спрашивать вопросы, а потом ноет, что "ничего не получается". Значит, хочет всё-таки. А не выходит потому, что не пытается слушать советов (изучить базу, прежде чем делать что-то своё), прыгает с темы на тему (вообще скипнул все базовые туториалы и пошёл гуглить "как сделать игру"), невнимательно смотрит даже то, что сам нашёл и пытается повторить (не смог кнопку забиндить, а потом пересмотрел видео и понял свою ошибку, но перед этим успел поныть о том, что "даже такое не получается").
>Я вот бросил кочалку и не жалею.
У тебя были медицинские противопоказания.
>>49576
>овладеть движком и языком
>без слишком большого гугления
Владение движком и языком не избавляет тебя от необходимости гуглить то, как какие-то игровые системы и механики могут быть реализованы (реализованы в других играх), чего хочет игрок и т.д. Сделать хорошую игру сегодня можно только исследуя существующие игры и свою ЦА, эпоха первооткрывателей давно прошла. Ты, конечно, можешь изобретать велосипеды, но потом будешь сильно демотивирован, когда обнаружишь реализацию своей идеи в древней игре из 90-х, которая лучше твоей.
>Самому с нуля без гайдов создать змейку/марио/гоночку?
Совсем без гайдов ты ничего сделать не сможешь, тем более если ты программировать в принципе не умеешь и опыта с другими игровыми движками не имел. Вот если ты умеешь программировать на каком-то другом языке, то легко освоишь GDScript, если ты раньше уже делал игры на каком-то движке, то без проблем вкатишься в Godot. Но полный ньюфаг в геймдеве должен следовать урокам и рекомендациям олдфагов, иначе разочаруешься из-за слишком высокой сложности темы.
>Или сразу делать игру мечты гугля по пути все что непонятно?
Это плохой подход, выше по треду есть наглядный пример ньюфага, который пытается идти таким путём и у него "ничего не получается". Тебе необходимо усвоить базу геймдева, прежде чем рваться пилить свою "игру мечты".
Согласен с анонами выше, что ВЕСЬ движок изучать нет никакой необходимости, например, с системой звука можно будет разобраться позже, если ты не делаешь игру, геймплей которой сильно завязан на звук (всякие раннеры, генерирующие дорожку по загруженной в них мелодии, и, конечно, ритм-игры). Но прежде чем пилить свою игру мечты, стоит разобраться с тем, как игры в принципе устроены, что такое программирование, какие-то базовые знания получить. Иначе потом ты зароешься в говнокод своей игры, и чтобы переделать нормально, тебе придётся начинать с нуля. Это как вместо популярного маршрута в лесу переть напролом через заросли, заблудиться, выйти в неправильном месте и снова пойти напролом через заросли, отказываясь пользоваться путеводителем и всем известными дорогами.
926 Кб, mp4,800x600, 0:23
Тест RigidBody2D, получающего коллизии от TileMap. Почему-то казалось, что так сделать будет нельзя, а оказалось, что галочку для этого добавили ещё в 2019. Странно, а с GridMap так сделать по-прежнему нельзя?
Да, корабль можно толкать своим телом в скафандре, не вижу ошибки (если ошибаюсь, поправьте). Потом сделаю проверку на вхождение в корабль и буду переключать режим полёта на режим ходьбы. В полёте скорость человечка в режиме ходьбы будет синхронизироваться со скоростью корабля, чтобы его не сносило в сторону. Ожидаю баги и глюки физики...
Как же всё-таки круто, всего одна маленькая механика и столько удовольствия от тестирования.
Да, корабль можно толкать своим телом в скафандре, не вижу ошибки (если ошибаюсь, поправьте). Потом сделаю проверку на вхождение в корабль и буду переключать режим полёта на режим ходьбы. В полёте скорость человечка в режиме ходьбы будет синхронизироваться со скоростью корабля, чтобы его не сносило в сторону. Ожидаю баги и глюки физики...
Как же всё-таки круто, всего одна маленькая механика и столько удовольствия от тестирования.
Обьявленная внутри функции переменная видна только внутри функции и может изменятся только в ней?
>>49872
Да.
Да.
>>49669
Какой же кал, почему нельзя разрабатывать что-то нормальное?
Какой же кал, почему нельзя разрабатывать что-то нормальное?
Объясните пожалуйста, вкатываюсь в godot, несколько часов уже потратил: такое ощущение что вообще не в ту сторону иду.
Как в 3d сцене добавить свечение кубу?
Можно ли это сделать не трогая глобальный свет?
Как в 3d сцене добавить свечение кубу?
Можно ли это сделать не трогая глобальный свет?
>>49669
А нельзя сделать две физики движения, одна относительно космоса в космосе и другая относительно корабля стоя на его тайле?
Как это в space station 14 реализовано
А нельзя сделать две физики движения, одна относительно космоса в космосе и другая относительно корабля стоя на его тайле?
Как это в space station 14 реализовано
>>49669
Оригинальная идея, неплохо придумал.
Оригинальная идея, неплохо придумал.
>>41833 (OP)
Здравствуйте. Я тут хочу сделать клон Стардью Вэлли и у меня возник вопрос, как мне сделать так, чтобы некоторые вещи обновлялись каждый день. Возможность дарить подарки нпс или ракушки для сбора, например. У меня из идей сохранять в объекте день последнего использования и сравнить его с текущим и если они не совпадают обновлять. Нормальная идея или можно сделать как то лучше?
Здравствуйте. Я тут хочу сделать клон Стардью Вэлли и у меня возник вопрос, как мне сделать так, чтобы некоторые вещи обновлялись каждый день. Возможность дарить подарки нпс или ракушки для сбора, например. У меня из идей сохранять в объекте день последнего использования и сравнить его с текущим и если они не совпадают обновлять. Нормальная идея или можно сделать как то лучше?
>>49936
Если ты про то, чтобы не через HDR и WorldEnvironment, то я такого не нашел.
Знаю что можно сделать для сферы иллюзию с помощью шейдера. Обратным Френелем.
(Второй пик - как выглядит обычный Френель, просто пускаю его результат в альфу вместо цвета.)
Для куба - придется написать через Signed distance field? Надо будет попробовать.
На самом деле с этим же столкнулся для, скажем, цилиндра светового меча.
Если ты про то, чтобы не через HDR и WorldEnvironment, то я такого не нашел.
Знаю что можно сделать для сферы иллюзию с помощью шейдера. Обратным Френелем.
(Второй пик - как выглядит обычный Френель, просто пускаю его результат в альфу вместо цвета.)
Для куба - придется написать через Signed distance field? Надо будет попробовать.
На самом деле с этим же столкнулся для, скажем, цилиндра светового меча.
>>50057
Ну мое скудоумие подсказывает что есть переменная со значением = false
При заходе на локацию она становится true и выполняется скрипт спавна предметов
Как персонаж ложится спать/просыпается переменная снова становится false
Ну мое скудоумие подсказывает что есть переменная со значением = false
При заходе на локацию она становится true и выполняется скрипт спавна предметов
Как персонаж ложится спать/просыпается переменная снова становится false
>>50061
Ну и также скрипт должен очищать старые предметы
Ну и также скрипт должен очищать старые предметы
>>50061
Вроде бы хорошая идея. Спасибо
Получается, все эти переменные тогда нужно делать в отдельной сцене и её в автозагрузку, чтоб везде их можно было прочитать?
И у меня ещё вопрос, как найти ближайшую ноду к игроку в определенное группе?
Вроде бы хорошая идея. Спасибо
Получается, все эти переменные тогда нужно делать в отдельной сцене и её в автозагрузку, чтоб везде их можно было прочитать?
И у меня ещё вопрос, как найти ближайшую ноду к игроку в определенное группе?
62 Кб, 750x748>>50068
В душе неебу, я в годоте три дня только
У тебя же еще должна быть система перехода между локациями
Там наверно через функции с проверками вызывать функции скриптов
В душе неебу, я в годоте три дня только
У тебя же еще должна быть система перехода между локациями
Там наверно через функции с проверками вызывать функции скриптов
>>49450
>>49665
В треде уже нашёлся анон который делает игру по такому методу. У него все получается...
Таких ошибок очень много! В Dialogic не могу заменить шрифт формата .tres нигде нет! Как сделать пропуск текста? Как доделать механику стрельбы по клику? Есть люди которые за три дня всю программу вдоль и поперек знают... Мне сложно разобраться в этом спустя несколько лет...
>>49665
>все базовые туториалы и пошёл гуглить "как сделать игру"
В треде уже нашёлся анон который делает игру по такому методу. У него все получается...
>понял свою ошибку, но перед этим успел поныть о том, что "даже такое не получается"
Таких ошибок очень много! В Dialogic не могу заменить шрифт формата .tres нигде нет! Как сделать пропуск текста? Как доделать механику стрельбы по клику? Есть люди которые за три дня всю программу вдоль и поперек знают... Мне сложно разобраться в этом спустя несколько лет...
Сейчас на каждое состояние машины тьюринга одна табличка фиксированного размер. Каждая строка этой таблице соответствует переходу в другое состояние. Думаю, размеры надо сделать динамическими, наверно реализовать это надо на годотовском гуе, а не на спрайтах.
>>50059
В общем пока так получилось, думаю метод можно доработать.
В общем пока так получилось, думаю метод можно доработать.
Не помню и не смог найти готовой функции плавного перемещения из точки А в точку БЭ, подскажите пжлст, иначе придётся писать свой вариант, хотя ясно, что есть готовый.
>>50129
Может TileMap?
>>50129
Может TileMap?
>>50068
от нужной ноды в группе найти расстояния до каждой другой ноды в группе (pos2 - pos1), затем найти минимальное
> И у меня ещё вопрос, как найти ближайшую ноду к игроку в определенное группе?
от нужной ноды в группе найти расстояния до каждой другой ноды в группе (pos2 - pos1), затем найти минимальное
>>49959
как и у графики есть слои, так и у коллизий есть слои
использовать два слоя: корабль, космос
> А нельзя сделать две физики движения, одна относительно космоса в космосе и другая относительно корабля стоя на его тайле?
как и у графики есть слои, так и у коллизий есть слои
использовать два слоя: корабль, космос
Godot 4.0 beta 12
>>50304
Отбой, нашёл что надо
Отбой, нашёл что надо
>>50304
В vector2/vector3 есть
Vector2/3.linear_interpolate (В 4 будет переименована в lerp)
slerp если нужны повороты
https://docs.godotengine.org/en/stable/tutorials/math/interpolation.html
Tween умеет с разными easing in/out
https://docs.godotengine.org/en/stable/classes/class_tween.html
PathFollow2d/3d может двигать вдоль кривой, как на абсолютное расстояние так и на относительное в процентах (unit_offset)
В vector2/vector3 есть
Vector2/3.linear_interpolate (В 4 будет переименована в lerp)
slerp если нужны повороты
https://docs.godotengine.org/en/stable/tutorials/math/interpolation.html
Tween умеет с разными easing in/out
https://docs.godotengine.org/en/stable/classes/class_tween.html
PathFollow2d/3d может двигать вдоль кривой, как на абсолютное расстояние так и на относительное в процентах (unit_offset)
>>50316
О, благодарю
О, благодарю
>>50237
Спасибо, попробую. Пока накостылил штатными источниками света.
Еще вечер посижу, покопаюсь и пойду тот же проект в юнити пилить. Сравнивать и выбирать
Спасибо, попробую. Пока накостылил штатными источниками света.
Еще вечер посижу, покопаюсь и пойду тот же проект в юнити пилить. Сравнивать и выбирать
Стрелялку не осилил... Смотря на обучающие видео понимаю, что будет проще сделать 3d песочницу.
собрал apk, запустил на телефоне, все работало, через пару часов снова собрал, естественно ничего не менялось в настройках, теперь при попытке запуска на телефоне выдает "ошибка при синтаксическом анализе пакета"
во всякое потыкался - безрезультатно, куда копать-то
во всякое потыкался - безрезультатно, куда копать-то
>>51329
А не подскажите как сделать перекат? Это должен быть типа рывок, но с анимацией переката йобыча.
А не подскажите как сделать перекат? Это должен быть типа рывок, но с анимацией переката йобыча.
>>51301
Надо еще босса абу, копрокарлсона, жидошизика и прочих
Армию мочи
А при прыжке велетающую надписть "бамп" сделать
Стрелять говном и в ближнем бою бить огромной залупой
Надо еще босса абу, копрокарлсона, жидошизика и прочих
Армию мочи
А при прыжке велетающую надписть "бамп" сделать
Стрелять говном и в ближнем бою бить огромной залупой
>>51343
Когда проигрываешь у игрока течет подлива
Когда проигрываешь у игрока течет подлива
>>51331
>>51343
Я думал добавить червей порриджей и дробовик, и если червя пуляешь, то он разлетается на ошмётки и пачкает колобка малиновым джемом. Ещё можно было бы добавить питурда, как одну из неписей, но хотелось бы каких-нибудь вариаций сюжетных. Короче блядь много чего хотелось бы, но я нихуя не умею.
>>51343
Я думал добавить червей порриджей и дробовик, и если червя пуляешь, то он разлетается на ошмётки и пачкает колобка малиновым джемом. Ещё можно было бы добавить питурда, как одну из неписей, но хотелось бы каких-нибудь вариаций сюжетных. Короче блядь много чего хотелось бы, но я нихуя не умею.
39 Кб, 1282x752Есть ли тут гуру годо, который бы смог подсказать некую функцию SurfaceTool или у вариаций Mesh, которая бы смогла рожать из точек фигуры разной сложности?
По другому правильно разбивать на треугольники сложные фигуры.
>>50984
А что именно непонятно?
По другому правильно разбивать на треугольники сложные фигуры.
>>50984
А что именно непонятно?
Sup, 2ch!
Learn how I create 3D tiles for my auto grid map system in the Godot game engine. This video shows the process from initial modeling to implementation in a game. Perfect for game developers or anyone interested in game creation.
https://www.youtube.com/watch?v=JHF3d0M59qs
Learn how I create 3D tiles for my auto grid map system in the Godot game engine. This video shows the process from initial modeling to implementation in a game. Perfect for game developers or anyone interested in game creation.
https://www.youtube.com/watch?v=JHF3d0M59qs
>>51486
Хорошо, упрощаем задачу
Итак, нарисуй наипростейшее изображение или используй годовое изображение пушки, оружия и запрограммируй изменение его угла относительно положения мыши на экране
О большем пока не думай. Если это для тебя просто, то уточни с чем проблемы.
Хорошо, упрощаем задачу
Итак, нарисуй наипростейшее изображение или используй годовое изображение пушки, оружия и запрограммируй изменение его угла относительно положения мыши на экране
О большем пока не думай. Если это для тебя просто, то уточни с чем проблемы.
>>51524
Запусти комп с флешки с вин-пе любого мантейнера (я выбираю стрельца) и оставь на ночь. Если перезагрузится - чекай питание (блок), конденсаторы на мамке. Если нет - время переустанавливать шындовс.
Запусти комп с флешки с вин-пе любого мантейнера (я выбираю стрельца) и оставь на ночь. Если перезагрузится - чекай питание (блок), конденсаторы на мамке. Если нет - время переустанавливать шындовс.
Кто нибудь игрался с compute shaders в 4? Попался ассет (который ничего не упрощает тащемта)
А что на них делать можно? Не игру жизнь же очередную.
А что на них делать можно? Не игру жизнь же очередную.
35 Кб, 1282x752Вобщем отбой, я разобрался в чём проблема
В итоге использую MeshDataTool
Проблема была в индексах вершин
>>51651
Курочка по зёрнышку, так что ты не прав, главное подход
В итоге использую MeshDataTool
Проблема была в индексах вершин
>>51651
Курочка по зёрнышку, так что ты не прав, главное подход
>>51652
Я использовал их в унити для генерации высот вокселей, типа displace, другое в голову не приходит, ну может для лучей
Я использовал их в унити для генерации высот вокселей, типа displace, другое в голову не приходит, ну может для лучей
>>51652
Сейчас нагуглил что можно с их помощью симуляцию жидкостей сделать, хм.
Сейчас нагуглил что можно с их помощью симуляцию жидкостей сделать, хм.
29 Кб, 962x572собираю apk в последней бетке четверки
sdk все как положено стоит (на 3.5.1 все собирается прекрасно)
путь к sdk прописал, путь к хранилищу путей прописал, но все равно вылезает такая ошибка, еще что-то где-то забыл указать или что?
sdk все как положено стоит (на 3.5.1 все собирается прекрасно)
путь к sdk прописал, путь к хранилищу путей прописал, но все равно вылезает такая ошибка, еще что-то где-то забыл указать или что?
>>51740
Английский забыл выучить. А тебе неоднократно говорили: не лезь туда без знания инглиша. Она тебя сожрёт.
> путь к sdk прописал
> путь к хранилищу путей прописал
> но все равно вылезает такая ошибка
> такая ошибка
> resulting APK is unsigned
> что-то где-то забыл указать или что?
Английский забыл выучить. А тебе неоднократно говорили: не лезь туда без знания инглиша. Она тебя сожрёт.
>>51786
ну и к чему этот высер, я прочитал, что apk не подписан и не создает idsig файл
сказал же, что перешел на последнюю бетку, прошлая бетка работала, стабильная версия тоже
ну и к чему этот высер, я прочитал, что apk не подписан и не создает idsig файл
сказал же, что перешел на последнюю бетку, прошлая бетка работала, стабильная версия тоже
>>51740
Попробовал, у меня сработало. Попробуй с нуля проект сделать, заново пути вписать, хз.
Попробовал, у меня сработало. Попробуй с нуля проект сделать, заново пути вписать, хз.
>>51809
попробовал не раз, именно на бетке 13-ой это выдает, трешка норм собирает
а какие версии стоят, как по дефолту прописано в доках?
sdkmanager" --sdk_root="sdk" "platform-tools" "build-tools;30.0.3" "platforms;android-31" "cmdline-tools;latest" "cmake;3.10.2.4988404" "ndk;21.4.7075529"
попробовал не раз, именно на бетке 13-ой это выдает, трешка норм собирает
а какие версии стоят, как по дефолту прописано в доках?
sdkmanager" --sdk_root="sdk" "platform-tools" "build-tools;30.0.3" "platforms;android-31" "cmdline-tools;latest" "cmake;3.10.2.4988404" "ndk;21.4.7075529"
>>51825
обновил build-tools до последней версии 33.0.1 тоже не помогло
обновил build-tools до последней версии 33.0.1 тоже не помогло
>>51825
У меня 32.0.0 и 30.0.3, не проверял какой из них запускается.
Алсо пробовал новый дебаг.кейстор создать?
У меня 32.0.0 и 30.0.3, не проверял какой из них запускается.
Алсо пробовал новый дебаг.кейстор создать?
>>51830
да, кейстор тоже создавал, причем разными версиями keytool и 11 и последней
ну сейчас эти версии тоже проверю, где наша не пропадала, как раз рабочий день и закончится
да, кейстор тоже создавал, причем разными версиями keytool и 11 и последней
> У меня 32.0.0 и 30.0.3
ну сейчас эти версии тоже проверю, где наша не пропадала, как раз рабочий день и закончится
>>51831
Сложно так ванговать. Путь к андроид сдк без пробелов, только английские буквы? Шаблоны экспорта тоже обновил?
Сложно так ванговать. Путь к андроид сдк без пробелов, только английские буквы? Шаблоны экспорта тоже обновил?
>>51834
Шаблоны экспорта тоже обновил?
да, да (так без обновления шаблонов там экспорт был бы совсем не активен)
с этими версиями тоже не работает 32.0.0 и 30.0.3 подписал пакет ручками через apksigner, все работает
Шаблоны экспорта тоже обновил?
да, да (так без обновления шаблонов там экспорт был бы совсем не активен)
с этими версиями тоже не работает 32.0.0 и 30.0.3 подписал пакет ручками через apksigner, все работает
Godot 4.0 beta 13
Парни набрали темп разработки
Парни набрали темп разработки
>>51615
Для меня любая простая задача сложная. Две недели назад мне помогли написать код для клика мышки по врагу. За все это время я не смог привязать анимацию выстрела танка, и даже меню не осилил.
>>51651
Хотел поспорить... Сейчас делая управление персонажа по гайду он не может ходить вниз.
>упрощаем задачу
Для меня любая простая задача сложная. Две недели назад мне помогли написать код для клика мышки по врагу. За все это время я не смог привязать анимацию выстрела танка, и даже меню не осилил.
>>51651
Хотел поспорить... Сейчас делая управление персонажа по гайду он не может ходить вниз.
>>51500
по русски говори ишак
по русски говори ишак
1,2 Мб, mp4,1280x720, 0:11
Godы годота, прошу вас, помогите мне проработать физику для моего йобика. Мне нужно, чтобы он сохранял энерцию во время прыжка. То есть я разбежался, прыгнул и отпустил кнопку движения, но персонаж должен продолжать лететь по направлению в которое он прыгнул. Я пологаю мне нужно будет создать нового персонажа с RigidBody вместо Kinematic, но может я не прав и лучше остаться с кинемантикой. У меня в планах ещё было добавить дробовик, который сдвигал бы моего персонажа отдачей, а ещё режим переката, в котором йоба катался бы как сосик хех, я это просто к слову, что может это тоже влияет на выбор между ригид и кенематнтик.
>>51947
ну тебе просто нужно давать импульс не на удержание кнопки, а на ее нажатие, тогда не важно держишь ты кнопку или отпустишь, импульс будет определяться только моментом прыжка
ну тебе просто нужно давать импульс не на удержание кнопки, а на ее нажатие, тогда не важно держишь ты кнопку или отпустишь, импульс будет определяться только моментом прыжка
>>51953
А что это значит? Я просто документацию не читал ><... Это что-то из разряда Input.is_action_just_pressed?
А что это значит? Я просто документацию не читал ><... Это что-то из разряда Input.is_action_just_pressed?
>>51947
А в чём сложность просто не обнулять скорость по иксу, если нет контакта с землёй?
Имхо такое управление уже попахивает Ghosts & goblins
А в чём сложность просто не обнулять скорость по иксу, если нет контакта с землёй?
Имхо такое управление уже попахивает Ghosts & goblins
>>51954
ну у тебя же перс уже как-то прыгает, вот у тебя значит уже где-то прописано, что на прыжок делать что-то (у тебя там координаты корневого узла плеера скорее всего меняются), там у тебя скорее всего есть какая-то логическая переменная, отвечающая за то, что персонаж сейчас в прыжке находится
вот проверяешь эту переменную, когда нажимаются кнопки горизонтального движения (влево-вправо, "A" "D"), пишешь условие, что если та переменная истина, т.е. мы в прыжке, то эти кнопки на это время перестают менять горизонтальные координаты плеера и получится, что ты прыгнул, но кнопки теперь только разворачивают морду персонажа в стороны, но само движение остается каким и было на момент прыжка
выстрел из дробовика - это просто на момент выстрела добавляешь импульс в противоположную сторону от направления морды
> А что это значит? Я просто документацию не читал ><... Это что-то из разряда Input.is_action_just_pressed?
ну у тебя же перс уже как-то прыгает, вот у тебя значит уже где-то прописано, что на прыжок делать что-то (у тебя там координаты корневого узла плеера скорее всего меняются), там у тебя скорее всего есть какая-то логическая переменная, отвечающая за то, что персонаж сейчас в прыжке находится
вот проверяешь эту переменную, когда нажимаются кнопки горизонтального движения (влево-вправо, "A" "D"), пишешь условие, что если та переменная истина, т.е. мы в прыжке, то эти кнопки на это время перестают менять горизонтальные координаты плеера и получится, что ты прыгнул, но кнопки теперь только разворачивают морду персонажа в стороны, но само движение остается каким и было на момент прыжка
выстрел из дробовика - это просто на момент выстрела добавляешь импульс в противоположную сторону от направления морды
14 Кб, 423x123>>52051
Ну вот допустим у меня есть приколы которые детектят положение на земле, чтобы прыгать можно было, и в воздухе, чтобы играть анимацию полёта. Что и куда мне надо вдолбить?
Ну вот допустим у меня есть приколы которые детектят положение на земле, чтобы прыгать можно было, и в воздухе, чтобы играть анимацию полёта. Что и куда мне надо вдолбить?
>>52067
полагаю, что есть еще место, которое перемещает персонажа по X, на нажатие каких-то кнопок, вот там проверяй, чтобы velocity.x изменялось только при is_on_floor()
полагаю, что есть еще место, которое перемещает персонажа по X, на нажатие каких-то кнопок, вот там проверяй, чтобы velocity.x изменялось только при is_on_floor()
>>52080
Сделал как на пикриле. В чём не прав? Почти то что нужно, но почему-то йоба стал прыгать как говно. На видео1 он прыгает со старым управлением, а на видео2 с новым.
Сделал как на пикриле. В чём не прав? Почти то что нужно, но почему-то йоба стал прыгать как говно. На видео1 он прыгает со старым управлением, а на видео2 с новым.
>>52086
Ну не мог не обосраться. На первом новое, на втором старое.
Ну не мог не обосраться. На первом новое, на втором старое.
>>52086
ну везде прыжок по параболе, в одном более пологая, то, что ты заказывал в управлении на роликах все равно не увидеть
ну везде прыжок по параболе, в одном более пологая, то, что ты заказывал в управлении на роликах все равно не увидеть
>>52093
То что я заказывал реализовалось, спасибо, но всплыла побочка, в виде коротенького прыжка у йобы. Почему так?
То что я заказывал реализовалось, спасибо, но всплыла побочка, в виде коротенького прыжка у йобы. Почему так?
>>52094
или ставь velocity.x побольше, тогда он будет более полого прыгать, но дальше
или ставь velocity.y побольше на прыжок, тогда он будет выше прыгать, за счет чего дальше пролетать
смотри как тебе по игре нужно будет
или ставь velocity.x побольше, тогда он будет более полого прыгать, но дальше
или ставь velocity.y побольше на прыжок, тогда он будет выше прыгать, за счет чего дальше пролетать
смотри как тебе по игре нужно будет
>>52095
Бля, но это же кал. Бегает он так же как бегал, а значит он начал какого-то хуя тормозить, что не есть гуд, так как нарушается естественность физики. В первом длинна прыжка была равна скорость+высота, а теперь она равна скорость+высота-вотЭтаБагулина.
>>52096
Попробую потестить вырубив акселерацию нахуй.
Бля, но это же кал. Бегает он так же как бегал, а значит он начал какого-то хуя тормозить, что не есть гуд, так как нарушается естественность физики. В первом длинна прыжка была равна скорость+высота, а теперь она равна скорость+высота-вотЭтаБагулина.
>>52096
Попробую потестить вырубив акселерацию нахуй.
Короче кому интересна вчерашняя эпопея с бэтками и экспортом разным.
Сегодня на работе прогнали все бетки, что есть на тему экспорта android и html5
Последние версии, где стабильно выдает у нас
beta13 - html5
beta10 - android
на более поздних андрюша выдает пока что ту же самую ошибку, что apsigner не фуричит
Проверялось все на платформе:
win64-10 последняя
по SDK брали как в доках: "sdk/cmdline-tools/latest/bin/sdkmanager" --sdk_root="sdk" "platform-tools" "build-tools;30.0.3" "platforms;android-31" "cmdline-tools;latest" "cmake;3.10.2.4988404" "ndk;21.4.7075529"
но можно просто неподписанный apk собрать в beta13 и ручками пописать, тогда все работает
так что будьте осторожны, аккуратны, если сейчас что-то из четверки в прод будете выкидывать, всем удачи и добра в проектах
Сегодня на работе прогнали все бетки, что есть на тему экспорта android и html5
Последние версии, где стабильно выдает у нас
beta13 - html5
beta10 - android
на более поздних андрюша выдает пока что ту же самую ошибку, что apsigner не фуричит
Проверялось все на платформе:
win64-10 последняя
по SDK брали как в доках: "sdk/cmdline-tools/latest/bin/sdkmanager" --sdk_root="sdk" "platform-tools" "build-tools;30.0.3" "platforms;android-31" "cmdline-tools;latest" "cmake;3.10.2.4988404" "ndk;21.4.7075529"
но можно просто неподписанный apk собрать в beta13 и ручками пописать, тогда все работает
так что будьте осторожны, аккуратны, если сейчас что-то из четверки в прод будете выкидывать, всем удачи и добра в проектах
>>52097
Короче да. Проблема была в акселерации, которая была добавленна для более плавного передвижения по гайду.
Короче да. Проблема была в акселерации, которая была добавленна для более плавного передвижения по гайду.
>>52116
Да бля долго ждать придётся. Я что-то спустя 5 минут любого затупа начинаю как-то плыть. Хочется чтобы был физон интересный и реалистичный, но кажется будто придётся жопу порвать прежде чем получится хотя бы неинтересный и нереалистичный. Следующий шаг добавить дробовик, которым можно будет целиться мышкой и отдачу от него. Я видел в документации что-то похожее на это, но наверное завтра приступлю.
Да бля долго ждать придётся. Я что-то спустя 5 минут любого затупа начинаю как-то плыть. Хочется чтобы был физон интересный и реалистичный, но кажется будто придётся жопу порвать прежде чем получится хотя бы неинтересный и нереалистичный. Следующий шаг добавить дробовик, которым можно будет целиться мышкой и отдачу от него. Я видел в документации что-то похожее на это, но наверное завтра приступлю.
>>52118
вектора позиции клика мыши:
куда направлен - это спавним патрон
со знаком минус - какое velocity придать йобе для отдачи
> Следующий шаг добавить дробовик, которым можно будет целиться мышкой и отдачу от него
вектора позиции клика мыши:
куда направлен - это спавним патрон
со знаком минус - какое velocity придать йобе для отдачи
>>52024
Не помню таких, может можно плагином навасянить?
Не помню таких, может можно плагином навасянить?
>>52145
на работе на всех машинах проверили, дома на компе и ноуте тоже, правда везде винда, может на других системах
на работе на всех машинах проверили, дома на компе и ноуте тоже, правда везде винда, может на других системах
79 Кб, 640x573>>52275
Какой у нас тут смелый сыч вскудахтнул из пропёрженной конуры.
Какой у нас тут смелый сыч вскудахтнул из пропёрженной конуры.
Rороче, есть одна контрол нода, в ней два лейбла current ammo и max ammo. Так вот, если пытаюсь изменить текст на лейблах из любых нод через синглтон, то текст нормально меняется, но когда пытаюсь изменить текст через ноду заспавленого оружия, то нихрена не происходит + у оружия при спавне не срабатывает _ready(). ЧЯДНТ?
1 пик - дерево худа
2 пик - нажимаю пкм на игроке - все работает
3 пик - скрипт ui.gd из ready все вызывается
в скрипте оружия
[code]
func _ready():
print("gun ready") # не вызывается
mag_ammo = mag_size # в инспекторе все норм
G.ui.update_ammo(mag_ammo, mag_size) # не работает
1 пик - дерево худа
2 пик - нажимаю пкм на игроке - все работает
3 пик - скрипт ui.gd из ready все вызывается
в скрипте оружия
[code]
func _ready():
print("gun ready") # не вызывается
mag_ammo = mag_size # в инспекторе все норм
G.ui.update_ammo(mag_ammo, mag_size) # не работает
Тред утонул или удален.
Это копия, сохраненная 22 июля в 04:00.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 22 июля в 04:00.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.