Этого треда уже нет.
Это копия, сохраненная 19 апреля в 06:36.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 19 апреля в 06:36.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
513 Кб, 700x535Добро пожаловать в тред любви, взаимопомощи и опенсорца!
Краткий гайд по вкату в движок:
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/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
Предыдущий: >>826340 (OP)
Архивный: https://arhivach.ng/thread/830006/
Краткий гайд по вкату в движок:
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/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
Предыдущий: >>826340 (OP)
Архивный: https://arhivach.ng/thread/830006/
зачем перекат, оп?
48 Кб, 477x621>перекат без Годетты
Нелегетимный перекат.
Шутка, это шутка, ясно?
Алсо мне не нравится, когда Godot-робота рисуют полностью без век. На логотипе он стилизованный, поэтому век не видно, но они должны быть, если он предназначен для коммуникации с людьми (иначе зачем вообще лицо). Ибо веки передают часть эмоций и человек/существо без век выглядит жутким. А Godot вроде как должен быть дружелюбным, а не жутким...
>>833946 →
Да пофиг на эти мелочи, это всё терпимо, была бы причина терпеть. Тут нужна некая киллер-фича, которая могла бы сделать VisualScript привлекательнее, чем GDScript, даже с неудобным интерфейсом а.к.а. мышкодрочем. Лёгкость нахождения и сцепления блоков не является такой киллер-фичей, потому что набирать текст в любом случае в разы быстрее и проще, ведь текст ты набираешь вслепую на клавиатуре, хоть даже с закрытыми глазами (если опыта достаточно), а визуальные блоки нужно сначала глазами искать (даже если они в палитре), потом мышкой дрочить - много суеты ради ничего. И если на клавиатуре у тебя навык нарабатывается, то мышкодрочь как в самом начале был утомительным, так всегда и будет оставаться утомительным - навык не развивается, т.к. блоки могут быть в разных местах (нет одного уникального жеста для получения конкретного результата), а кнопки клавиатуры неподвижны (есть один жест на каждую клавишу, даже если клавиатура виртуальная - я много набираю на смартфоне вслепую двумя пальцами и мне норм, навык реально возможен даже без тактильной отдачи).
Так ведь вроде бы GDNative расширили до GDExtension специально чтобы не приходилось пересобирать редактор и шаблоны экспорта из исходников. Т.е., как я понимаю, можно будет просто закинуть .dll в папку с редактором или с игрой и всё заработает так же гладко, как если бы было встроено из коробки. По этой же причине решили выкинуть Bullet Physics из ядра движка - мол, чтобы тем, кому он не нужен (2D игры, игры целиком на GUI), не приходилось делать собственную сборку движка.
Вообще, не понимаю, почему нельзя ВСЕ модули движка сделать внешними библиотеками (кроме GUI нод, т.к. без них запускать нечего). Это же было бы намного удобнее одного массивного исполняемого файла, который нужно пересобирать. Да, конечно, это могло бы сказаться на производительности, но у нас вроде как она вообще не в приоритете, не так ли? Зато такая сильная модульность позволила бы, во-первых, легко делать собственную сборку движка простым перемещением файлов (без установки компилятора и нескольких часов ожидания ошибки компиляции гигабайта исходников), во-вторых, позволила бы обновлять отдельные модули независимо друг от друга - если в новой версии движка пофиксили баг физики, не нужно качать все модули, достаточно скачать новую версию модуля физики. В том числе это упростило бы обновления игры в Стиме, чтобы не приходилось создавать патчи (на счёт этого не уверен, Стим ведь не создаёт патчи самостоятельно?).
>>833948 →
Эммм... Что? Крайне редко сталкиваюсь со сниппетами или необходимостью в них. Высокоуровневые блоки в классических языках - это модули. Обычно модуль оформляется как отдельный файл и доступен по уникальному имени (в GDScript - class_name). В ООП модуль может быть оформлен как один класс, но это не обязательно. Беда GDScript в том, что он не позволяет подтягивать модули из произвольных папок, нужно все модули копипастить в папку проекта. Если проект всего один, проблемы нет, но если ты хочешь использовать один код в параллельных проектах - придётся копипастить. Ещё хуже, если ты в рамках одного проекта внёс изменения в свой модуль и теперь не помнишь, в каком из проектов у тебя актуальная версия модуля...
Про симлинки знаю, мне они кажутся неудобными из-за того, что сложно понять, какая из ссылок на файл является последней ссылкой. Т.е. в теории можно случайно удалить файл, не зная о том, что это последняя ссылка. Какую из ссылок считать "оригиналом", чтобы случайно его не удалить? Так сложно уложить это в голове... Или есть какие-то расширения Проводника, чтобы видеть число ссылок на файл, например, в свойствах файла? Сторонним файловым менеджером пользоваться не хочу, линуксом тоже - опыт неприятный (а ещё там игорь-то нет, и других любимых мной программ).
>>833964 →
Я первыми "играми" делал что-то через консоль в стиле DOS на Turbo Pascal 7.0. Были попытки в графику и даже 3D (смог сам придумать способ рисования куба, но только в виде решётки, без заливки), но больше меня привлекало создание текстовой игры. Тетрис тоже делал, но намного позже и уже на Delphi 7. Вообще, было много разных идей игр, некоторые я даже записывал в текстовые файлы, но на реализацию кодом мотивации не хватало. Меня больше всего привлекает осмысленный диалог с компьютером, а не какие-то игрушки. Игрушек и без меня десятки тысяч, что толку от очередной бесполезной игрушки? А с мыслящей подобно человеку программой можно было бы общаться (не как с тупыми нейрочатботами, они не мыслят вообще, во всяком случае те, что я видел). Кстати, программирование как таковое привлекает по той же причине - это диалог с машиной, пусть и на упрощённом языке по сравнению с русским/английским, зато компьютер понимает тебя куда лучше, чем тупые нейрочатботы без задач.
Согласен, но нужно заметить важный момент: только успешное решение даёт мотивацию, а если ты пробуешь и не можешь решить интересную задачу - ловишь очень сильную демотивацию и потом не можешь заставить себя решать что-либо другое. Это намного хуже, чем когда тебе говорят "у тебя ничего не получится", потому что ты реально на практике видишь, что у тебя действительно ничего не получается. А у новичка такая ситуация намного вероятнее, потому что нужных знаний ещё нет. Так что лучше тщательно подготовиться, прежде чем бросаться в ту область, которая тебе интересна, но для которой недостаточно знаний.
>это всё тысяча мелочей из которых складывается удобный интерфейс
Да пофиг на эти мелочи, это всё терпимо, была бы причина терпеть. Тут нужна некая киллер-фича, которая могла бы сделать VisualScript привлекательнее, чем GDScript, даже с неудобным интерфейсом а.к.а. мышкодрочем. Лёгкость нахождения и сцепления блоков не является такой киллер-фичей, потому что набирать текст в любом случае в разы быстрее и проще, ведь текст ты набираешь вслепую на клавиатуре, хоть даже с закрытыми глазами (если опыта достаточно), а визуальные блоки нужно сначала глазами искать (даже если они в палитре), потом мышкой дрочить - много суеты ради ничего. И если на клавиатуре у тебя навык нарабатывается, то мышкодрочь как в самом начале был утомительным, так всегда и будет оставаться утомительным - навык не развивается, т.к. блоки могут быть в разных местах (нет одного уникального жеста для получения конкретного результата), а кнопки клавиатуры неподвижны (есть один жест на каждую клавишу, даже если клавиатура виртуальная - я много набираю на смартфоне вслепую двумя пальцами и мне норм, навык реально возможен даже без тактильной отдачи).
>собирай движок самостоятельно
Так ведь вроде бы GDNative расширили до GDExtension специально чтобы не приходилось пересобирать редактор и шаблоны экспорта из исходников. Т.е., как я понимаю, можно будет просто закинуть .dll в папку с редактором или с игрой и всё заработает так же гладко, как если бы было встроено из коробки. По этой же причине решили выкинуть Bullet Physics из ядра движка - мол, чтобы тем, кому он не нужен (2D игры, игры целиком на GUI), не приходилось делать собственную сборку движка.
Вообще, не понимаю, почему нельзя ВСЕ модули движка сделать внешними библиотеками (кроме GUI нод, т.к. без них запускать нечего). Это же было бы намного удобнее одного массивного исполняемого файла, который нужно пересобирать. Да, конечно, это могло бы сказаться на производительности, но у нас вроде как она вообще не в приоритете, не так ли? Зато такая сильная модульность позволила бы, во-первых, легко делать собственную сборку движка простым перемещением файлов (без установки компилятора и нескольких часов ожидания ошибки компиляции гигабайта исходников), во-вторых, позволила бы обновлять отдельные модули независимо друг от друга - если в новой версии движка пофиксили баг физики, не нужно качать все модули, достаточно скачать новую версию модуля физики. В том числе это упростило бы обновления игры в Стиме, чтобы не приходилось создавать патчи (на счёт этого не уверен, Стим ведь не создаёт патчи самостоятельно?).
>>833948 →
>что является аналогом "высокоуровневых блоков" в текстовых языках? Сниппеты!
Эммм... Что? Крайне редко сталкиваюсь со сниппетами или необходимостью в них. Высокоуровневые блоки в классических языках - это модули. Обычно модуль оформляется как отдельный файл и доступен по уникальному имени (в GDScript - class_name). В ООП модуль может быть оформлен как один класс, но это не обязательно. Беда GDScript в том, что он не позволяет подтягивать модули из произвольных папок, нужно все модули копипастить в папку проекта. Если проект всего один, проблемы нет, но если ты хочешь использовать один код в параллельных проектах - придётся копипастить. Ещё хуже, если ты в рамках одного проекта внёс изменения в свой модуль и теперь не помнишь, в каком из проектов у тебя актуальная версия модуля...
Про симлинки знаю, мне они кажутся неудобными из-за того, что сложно понять, какая из ссылок на файл является последней ссылкой. Т.е. в теории можно случайно удалить файл, не зная о том, что это последняя ссылка. Какую из ссылок считать "оригиналом", чтобы случайно его не удалить? Так сложно уложить это в голове... Или есть какие-то расширения Проводника, чтобы видеть число ссылок на файл, например, в свойствах файла? Сторонним файловым менеджером пользоваться не хочу, линуксом тоже - опыт неприятный (а ещё там игорь-то нет, и других любимых мной программ).
>>833964 →
>моя первая игра
Я первыми "играми" делал что-то через консоль в стиле DOS на Turbo Pascal 7.0. Были попытки в графику и даже 3D (смог сам придумать способ рисования куба, но только в виде решётки, без заливки), но больше меня привлекало создание текстовой игры. Тетрис тоже делал, но намного позже и уже на Delphi 7. Вообще, было много разных идей игр, некоторые я даже записывал в текстовые файлы, но на реализацию кодом мотивации не хватало. Меня больше всего привлекает осмысленный диалог с компьютером, а не какие-то игрушки. Игрушек и без меня десятки тысяч, что толку от очередной бесполезной игрушки? А с мыслящей подобно человеку программой можно было бы общаться (не как с тупыми нейрочатботами, они не мыслят вообще, во всяком случае те, что я видел). Кстати, программирование как таковое привлекает по той же причине - это диалог с машиной, пусть и на упрощённом языке по сравнению с русским/английским, зато компьютер понимает тебя куда лучше, чем тупые нейрочатботы без задач.
>решение интересных задач подогревает мотивацию
Согласен, но нужно заметить важный момент: только успешное решение даёт мотивацию, а если ты пробуешь и не можешь решить интересную задачу - ловишь очень сильную демотивацию и потом не можешь заставить себя решать что-либо другое. Это намного хуже, чем когда тебе говорят "у тебя ничего не получится", потому что ты реально на практике видишь, что у тебя действительно ничего не получается. А у новичка такая ситуация намного вероятнее, потому что нужных знаний ещё нет. Так что лучше тщательно подготовиться, прежде чем бросаться в ту область, которая тебе интересна, но для которой недостаточно знаний.
>>833946 →
Да пофиг на эти мелочи, это всё терпимо, была бы причина терпеть. Тут нужна некая киллер-фича, которая могла бы сделать VisualScript привлекательнее, чем GDScript, даже с неудобным интерфейсом а.к.а. мышкодрочем. Лёгкость нахождения и сцепления блоков не является такой киллер-фичей, потому что набирать текст в любом случае в разы быстрее и проще, ведь текст ты набираешь вслепую на клавиатуре, хоть даже с закрытыми глазами (если опыта достаточно), а визуальные блоки нужно сначала глазами искать (даже если они в палитре), потом мышкой дрочить - много суеты ради ничего. И если на клавиатуре у тебя навык нарабатывается, то мышкодрочь как в самом начале был утомительным, так всегда и будет оставаться утомительным - навык не развивается, т.к. блоки могут быть в разных местах (нет одного уникального жеста для получения конкретного результата), а кнопки клавиатуры неподвижны (есть один жест на каждую клавишу, даже если клавиатура виртуальная - я много набираю на смартфоне вслепую двумя пальцами и мне норм, навык реально возможен даже без тактильной отдачи).
Так ведь вроде бы GDNative расширили до GDExtension специально чтобы не приходилось пересобирать редактор и шаблоны экспорта из исходников. Т.е., как я понимаю, можно будет просто закинуть .dll в папку с редактором или с игрой и всё заработает так же гладко, как если бы было встроено из коробки. По этой же причине решили выкинуть Bullet Physics из ядра движка - мол, чтобы тем, кому он не нужен (2D игры, игры целиком на GUI), не приходилось делать собственную сборку движка.
Вообще, не понимаю, почему нельзя ВСЕ модули движка сделать внешними библиотеками (кроме GUI нод, т.к. без них запускать нечего). Это же было бы намного удобнее одного массивного исполняемого файла, который нужно пересобирать. Да, конечно, это могло бы сказаться на производительности, но у нас вроде как она вообще не в приоритете, не так ли? Зато такая сильная модульность позволила бы, во-первых, легко делать собственную сборку движка простым перемещением файлов (без установки компилятора и нескольких часов ожидания ошибки компиляции гигабайта исходников), во-вторых, позволила бы обновлять отдельные модули независимо друг от друга - если в новой версии движка пофиксили баг физики, не нужно качать все модули, достаточно скачать новую версию модуля физики. В том числе это упростило бы обновления игры в Стиме, чтобы не приходилось создавать патчи (на счёт этого не уверен, Стим ведь не создаёт патчи самостоятельно?).
>>833948 →
Эммм... Что? Крайне редко сталкиваюсь со сниппетами или необходимостью в них. Высокоуровневые блоки в классических языках - это модули. Обычно модуль оформляется как отдельный файл и доступен по уникальному имени (в GDScript - class_name). В ООП модуль может быть оформлен как один класс, но это не обязательно. Беда GDScript в том, что он не позволяет подтягивать модули из произвольных папок, нужно все модули копипастить в папку проекта. Если проект всего один, проблемы нет, но если ты хочешь использовать один код в параллельных проектах - придётся копипастить. Ещё хуже, если ты в рамках одного проекта внёс изменения в свой модуль и теперь не помнишь, в каком из проектов у тебя актуальная версия модуля...
Про симлинки знаю, мне они кажутся неудобными из-за того, что сложно понять, какая из ссылок на файл является последней ссылкой. Т.е. в теории можно случайно удалить файл, не зная о том, что это последняя ссылка. Какую из ссылок считать "оригиналом", чтобы случайно его не удалить? Так сложно уложить это в голове... Или есть какие-то расширения Проводника, чтобы видеть число ссылок на файл, например, в свойствах файла? Сторонним файловым менеджером пользоваться не хочу, линуксом тоже - опыт неприятный (а ещё там игорь-то нет, и других любимых мной программ).
>>833964 →
Я первыми "играми" делал что-то через консоль в стиле DOS на Turbo Pascal 7.0. Были попытки в графику и даже 3D (смог сам придумать способ рисования куба, но только в виде решётки, без заливки), но больше меня привлекало создание текстовой игры. Тетрис тоже делал, но намного позже и уже на Delphi 7. Вообще, было много разных идей игр, некоторые я даже записывал в текстовые файлы, но на реализацию кодом мотивации не хватало. Меня больше всего привлекает осмысленный диалог с компьютером, а не какие-то игрушки. Игрушек и без меня десятки тысяч, что толку от очередной бесполезной игрушки? А с мыслящей подобно человеку программой можно было бы общаться (не как с тупыми нейрочатботами, они не мыслят вообще, во всяком случае те, что я видел). Кстати, программирование как таковое привлекает по той же причине - это диалог с машиной, пусть и на упрощённом языке по сравнению с русским/английским, зато компьютер понимает тебя куда лучше, чем тупые нейрочатботы без задач.
Согласен, но нужно заметить важный момент: только успешное решение даёт мотивацию, а если ты пробуешь и не можешь решить интересную задачу - ловишь очень сильную демотивацию и потом не можешь заставить себя решать что-либо другое. Это намного хуже, чем когда тебе говорят "у тебя ничего не получится", потому что ты реально на практике видишь, что у тебя действительно ничего не получается. А у новичка такая ситуация намного вероятнее, потому что нужных знаний ещё нет. Так что лучше тщательно подготовиться, прежде чем бросаться в ту область, которая тебе интересна, но для которой недостаточно знаний.
>это всё тысяча мелочей из которых складывается удобный интерфейс
Да пофиг на эти мелочи, это всё терпимо, была бы причина терпеть. Тут нужна некая киллер-фича, которая могла бы сделать VisualScript привлекательнее, чем GDScript, даже с неудобным интерфейсом а.к.а. мышкодрочем. Лёгкость нахождения и сцепления блоков не является такой киллер-фичей, потому что набирать текст в любом случае в разы быстрее и проще, ведь текст ты набираешь вслепую на клавиатуре, хоть даже с закрытыми глазами (если опыта достаточно), а визуальные блоки нужно сначала глазами искать (даже если они в палитре), потом мышкой дрочить - много суеты ради ничего. И если на клавиатуре у тебя навык нарабатывается, то мышкодрочь как в самом начале был утомительным, так всегда и будет оставаться утомительным - навык не развивается, т.к. блоки могут быть в разных местах (нет одного уникального жеста для получения конкретного результата), а кнопки клавиатуры неподвижны (есть один жест на каждую клавишу, даже если клавиатура виртуальная - я много набираю на смартфоне вслепую двумя пальцами и мне норм, навык реально возможен даже без тактильной отдачи).
>собирай движок самостоятельно
Так ведь вроде бы GDNative расширили до GDExtension специально чтобы не приходилось пересобирать редактор и шаблоны экспорта из исходников. Т.е., как я понимаю, можно будет просто закинуть .dll в папку с редактором или с игрой и всё заработает так же гладко, как если бы было встроено из коробки. По этой же причине решили выкинуть Bullet Physics из ядра движка - мол, чтобы тем, кому он не нужен (2D игры, игры целиком на GUI), не приходилось делать собственную сборку движка.
Вообще, не понимаю, почему нельзя ВСЕ модули движка сделать внешними библиотеками (кроме GUI нод, т.к. без них запускать нечего). Это же было бы намного удобнее одного массивного исполняемого файла, который нужно пересобирать. Да, конечно, это могло бы сказаться на производительности, но у нас вроде как она вообще не в приоритете, не так ли? Зато такая сильная модульность позволила бы, во-первых, легко делать собственную сборку движка простым перемещением файлов (без установки компилятора и нескольких часов ожидания ошибки компиляции гигабайта исходников), во-вторых, позволила бы обновлять отдельные модули независимо друг от друга - если в новой версии движка пофиксили баг физики, не нужно качать все модули, достаточно скачать новую версию модуля физики. В том числе это упростило бы обновления игры в Стиме, чтобы не приходилось создавать патчи (на счёт этого не уверен, Стим ведь не создаёт патчи самостоятельно?).
>>833948 →
>что является аналогом "высокоуровневых блоков" в текстовых языках? Сниппеты!
Эммм... Что? Крайне редко сталкиваюсь со сниппетами или необходимостью в них. Высокоуровневые блоки в классических языках - это модули. Обычно модуль оформляется как отдельный файл и доступен по уникальному имени (в GDScript - class_name). В ООП модуль может быть оформлен как один класс, но это не обязательно. Беда GDScript в том, что он не позволяет подтягивать модули из произвольных папок, нужно все модули копипастить в папку проекта. Если проект всего один, проблемы нет, но если ты хочешь использовать один код в параллельных проектах - придётся копипастить. Ещё хуже, если ты в рамках одного проекта внёс изменения в свой модуль и теперь не помнишь, в каком из проектов у тебя актуальная версия модуля...
Про симлинки знаю, мне они кажутся неудобными из-за того, что сложно понять, какая из ссылок на файл является последней ссылкой. Т.е. в теории можно случайно удалить файл, не зная о том, что это последняя ссылка. Какую из ссылок считать "оригиналом", чтобы случайно его не удалить? Так сложно уложить это в голове... Или есть какие-то расширения Проводника, чтобы видеть число ссылок на файл, например, в свойствах файла? Сторонним файловым менеджером пользоваться не хочу, линуксом тоже - опыт неприятный (а ещё там игорь-то нет, и других любимых мной программ).
>>833964 →
>моя первая игра
Я первыми "играми" делал что-то через консоль в стиле DOS на Turbo Pascal 7.0. Были попытки в графику и даже 3D (смог сам придумать способ рисования куба, но только в виде решётки, без заливки), но больше меня привлекало создание текстовой игры. Тетрис тоже делал, но намного позже и уже на Delphi 7. Вообще, было много разных идей игр, некоторые я даже записывал в текстовые файлы, но на реализацию кодом мотивации не хватало. Меня больше всего привлекает осмысленный диалог с компьютером, а не какие-то игрушки. Игрушек и без меня десятки тысяч, что толку от очередной бесполезной игрушки? А с мыслящей подобно человеку программой можно было бы общаться (не как с тупыми нейрочатботами, они не мыслят вообще, во всяком случае те, что я видел). Кстати, программирование как таковое привлекает по той же причине - это диалог с машиной, пусть и на упрощённом языке по сравнению с русским/английским, зато компьютер понимает тебя куда лучше, чем тупые нейрочатботы без задач.
>решение интересных задач подогревает мотивацию
Согласен, но нужно заметить важный момент: только успешное решение даёт мотивацию, а если ты пробуешь и не можешь решить интересную задачу - ловишь очень сильную демотивацию и потом не можешь заставить себя решать что-либо другое. Это намного хуже, чем когда тебе говорят "у тебя ничего не получится", потому что ты реально на практике видишь, что у тебя действительно ничего не получается. А у новичка такая ситуация намного вероятнее, потому что нужных знаний ещё нет. Так что лучше тщательно подготовиться, прежде чем бросаться в ту область, которая тебе интересна, но для которой недостаточно знаний.
>>34071
Вот это люто двачую! Я вообще несколько раз пытался понять хуановый гднатив, притом, что в прежние времена у меня не возникало трудностей запихнуть в длл формочки, связать длл с приложением, передать из приложение в длл ссылку на майнлуп и вызывать формочки из либы в контексте приложения. А здесь же просто нужно вызвать хотя бы одну функцию из либы не получается! Кошмар! Я наверное постарел и отупел.
> Вообще, не понимаю, почему нельзя ВСЕ модули движка сделать внешними библиотеками
Вот это люто двачую! Я вообще несколько раз пытался понять хуановый гднатив, притом, что в прежние времена у меня не возникало трудностей запихнуть в длл формочки, связать длл с приложением, передать из приложение в длл ссылку на майнлуп и вызывать формочки из либы в контексте приложения. А здесь же просто нужно вызвать хотя бы одну функцию из либы не получается! Кошмар! Я наверное постарел и отупел.
129 Кб, 322x281>>34071
Hard Link Shell.
И не делай в нём линки на файлы, делай junction-линки на папки. Так ты всегда будешь видеть, что папка не является оригиналом.
> Или есть какие-то расширения Проводника, чтобы видеть число ссылок на файл, например, в свойствах файла?
Hard Link Shell.
И не делай в нём линки на файлы, делай junction-линки на папки. Так ты всегда будешь видеть, что папка не является оригиналом.
63 Кб, 789x642>>34075
Файловые ссылки тоже есть, причём со счётчиком ссылок, как заказывали. А вот символические ссылки - шляпа. Без счётчика, так ещё и права админа затребовала при создании.
А жёсткие ссылки я пожалуй тоже теперь попробую. При удалении всех кроме одной, последний оставшийся файл автоматически перестаёт быть ссылкой.
Файловые ссылки тоже есть, причём со счётчиком ссылок, как заказывали. А вот символические ссылки - шляпа. Без счётчика, так ещё и права админа затребовала при создании.
А жёсткие ссылки я пожалуй тоже теперь попробую. При удалении всех кроме одной, последний оставшийся файл автоматически перестаёт быть ссылкой.
>>34071
Это не минус, это плюс... Все относящееся к проекту должно находиться в папке проекта. Примеры того, как нарушение этого принципа портило жизнь:
-девушка присылает .blend не проведя External File -> Pack All. В результате ничего не открывается, так как ссылается на ее C:\Users\Humanitarii\Documents\Textures
-скачанный из интернета "опенсорс" проект на C/C++ не собирается... Потому что инклюдится "../someLib", которую автор не выложил, связаться невозможно, ни на что не отвечает.
-присланный .doc ссылается на E:\Network\Share который ссылается на локальную сеть приславшего
В любой вменяемой разработке нужно фиксировать версии модулей/пакетов. Для годота я видел минимум 3 пакетных менеджера, сам пользуюсь для поднятия нового проекта https://github.com/imjp94/gd-plug
Если же у тебя молодой, динамично развивающийся модуль, то это решается git. Создаем репозиторий библиотеки, разрешаем принимать локальные изменения
git config receive.denyCurrentBranch updateInstead
Клонируем репу локально в проекте.
git clone file:///C:/Work/modules/my_module project/my_module
Потом изменения пушим, создаем ветки по необходимости.
git add .
git commit -m "added my wonderful feature"
git push
Инфа https://stackoverflow.com/questions/2519933/git-clone-repo-across-local-file-system-in-windows
https://stackoverflow.com/questions/11117823/git-push-error-refusing-to-update-checked-out-branch
> Беда GDScript в том, что он не позволяет подтягивать модули из произвольных папок, нужно все модули копипастить в папку проекта.
Это не минус, это плюс... Все относящееся к проекту должно находиться в папке проекта. Примеры того, как нарушение этого принципа портило жизнь:
-девушка присылает .blend не проведя External File -> Pack All. В результате ничего не открывается, так как ссылается на ее C:\Users\Humanitarii\Documents\Textures
-скачанный из интернета "опенсорс" проект на C/C++ не собирается... Потому что инклюдится "../someLib", которую автор не выложил, связаться невозможно, ни на что не отвечает.
-присланный .doc ссылается на E:\Network\Share который ссылается на локальную сеть приславшего
В любой вменяемой разработке нужно фиксировать версии модулей/пакетов. Для годота я видел минимум 3 пакетных менеджера, сам пользуюсь для поднятия нового проекта https://github.com/imjp94/gd-plug
Если же у тебя молодой, динамично развивающийся модуль, то это решается git. Создаем репозиторий библиотеки, разрешаем принимать локальные изменения
git config receive.denyCurrentBranch updateInstead
Клонируем репу локально в проекте.
git clone file:///C:/Work/modules/my_module project/my_module
Потом изменения пушим, создаем ветки по необходимости.
git add .
git commit -m "added my wonderful feature"
git push
Инфа https://stackoverflow.com/questions/2519933/git-clone-repo-across-local-file-system-in-windows
https://stackoverflow.com/questions/11117823/git-push-error-refusing-to-update-checked-out-branch
>>34084
Я это ему два треда назад объяснял, всё равно ноет.
Я это ему два треда назад объяснял, всё равно ноет.
>>34084
1. Присылать должна была не .blend, а .zip-папку со всеми зависимыми файлами. Да, можно упаковать файлы в .blend, но так будет сложнее ими управлять вне Blender (особенно если рисуешь текстуры в сторонней программе).
2. Вроде бы в Blender есть опция для использования только относительных путей. Понятия не имею, зачем в .blend хранить абсолютные пути... Из моего опыта, пути там обычно относительные, а не абсолютные - т.е. достаточно упаковать в .zip папку со всеми файлами.
Так и проект на Godot можно выложить так, что ничего работать не будет, если забыть какие-то файлы, в частности, какой-нибудь аддон. Это уже вопрос к разработчику проекта, а не к движку.
Опять, тут как с .blend, может быть относительный путь, а может быть абсолютный. Нужно использовать относительные пути и хранить всё необходимое поблизости, а не на разных дисках.
Пример того, что я хочу:
...\MyGodotProjects\Addons\addon1234\...
...\MyGodotProjects\AwesomeGame\game\...
Путь из игры к аддону в настройках проекта project.godot, не влияет на код в .gd скриптах игры:
..\Addons\addon1234\...
Если у пользователя нет такого аддона или путь неправильный, он просто меняет одну строчку в настройках на тот путь, который ему нужен. Если у пользователя уже есть этот аддон по этому пути, ему не придётся скачивать его лишний раз и иметь лишнюю копию в папке проекта. Если версия не совпадает... ну тут уже вопрос к разработчику аддона, почему он выпустил несовместимую версию, т.к. в идеале должна быть совместимость между всеми выпусками под одной мажорной версией.
Эх... Ну да, ты прав. Если, допустим, какую-то игру давно не обновлял, а используемый ею модуль обновил недавно, то эта игра может не смочь заработать без обновлений, учитывающих новую версию модуля. Но это только если ты реально несовместимые изменения вносишь, которые влияют на использование модуля игрой. В остальных случаях тебе придётся делать копипаст новой версии поверх устаревшей...
Ой, ещё и это настраивать, разбираться, бороться с ошибками в случае отключения питания и т.п. Я делаю проекты для себя и ни с кем не взаимодействую, так что вести длинную историю изменений каждого файла мне пока что не нужно. А ещё мне стыдно... вдруг кто-то увидит, какие изменения я вношу в свой код...
>девушка присылает .blend не проведя External File -> Pack All. В результате ничего не открывается, так как ссылается на ее C:\Users\Humanitarii\Documents
1. Присылать должна была не .blend, а .zip-папку со всеми зависимыми файлами. Да, можно упаковать файлы в .blend, но так будет сложнее ими управлять вне Blender (особенно если рисуешь текстуры в сторонней программе).
2. Вроде бы в Blender есть опция для использования только относительных путей. Понятия не имею, зачем в .blend хранить абсолютные пути... Из моего опыта, пути там обычно относительные, а не абсолютные - т.е. достаточно упаковать в .zip папку со всеми файлами.
>инклюдится "../someLib", которую автор не выложил, связаться невозможно, ни на что не отвечает.
Так и проект на Godot можно выложить так, что ничего работать не будет, если забыть какие-то файлы, в частности, какой-нибудь аддон. Это уже вопрос к разработчику проекта, а не к движку.
>присланный .doc ссылается на E:\Network\Share который ссылается на локальную сеть приславшего
Опять, тут как с .blend, может быть относительный путь, а может быть абсолютный. Нужно использовать относительные пути и хранить всё необходимое поблизости, а не на разных дисках.
Пример того, что я хочу:
...\MyGodotProjects\Addons\addon1234\...
...\MyGodotProjects\AwesomeGame\game\...
Путь из игры к аддону в настройках проекта project.godot, не влияет на код в .gd скриптах игры:
..\Addons\addon1234\...
Если у пользователя нет такого аддона или путь неправильный, он просто меняет одну строчку в настройках на тот путь, который ему нужен. Если у пользователя уже есть этот аддон по этому пути, ему не придётся скачивать его лишний раз и иметь лишнюю копию в папке проекта. Если версия не совпадает... ну тут уже вопрос к разработчику аддона, почему он выпустил несовместимую версию, т.к. в идеале должна быть совместимость между всеми выпусками под одной мажорной версией.
>нужно фиксировать версии модулей/пакетов
Эх... Ну да, ты прав. Если, допустим, какую-то игру давно не обновлял, а используемый ею модуль обновил недавно, то эта игра может не смочь заработать без обновлений, учитывающих новую версию модуля. Но это только если ты реально несовместимые изменения вносишь, которые влияют на использование модуля игрой. В остальных случаях тебе придётся делать копипаст новой версии поверх устаревшей...
>git
Ой, ещё и это настраивать, разбираться, бороться с ошибками в случае отключения питания и т.п. Я делаю проекты для себя и ни с кем не взаимодействую, так что вести длинную историю изменений каждого файла мне пока что не нужно. А ещё мне стыдно... вдруг кто-то увидит, какие изменения я вношу в свой код...
>>34084
1. Присылать должна была не .blend, а .zip-папку со всеми зависимыми файлами. Да, можно упаковать файлы в .blend, но так будет сложнее ими управлять вне Blender (особенно если рисуешь текстуры в сторонней программе).
2. Вроде бы в Blender есть опция для использования только относительных путей. Понятия не имею, зачем в .blend хранить абсолютные пути... Из моего опыта, пути там обычно относительные, а не абсолютные - т.е. достаточно упаковать в .zip папку со всеми файлами.
Так и проект на Godot можно выложить так, что ничего работать не будет, если забыть какие-то файлы, в частности, какой-нибудь аддон. Это уже вопрос к разработчику проекта, а не к движку.
Опять, тут как с .blend, может быть относительный путь, а может быть абсолютный. Нужно использовать относительные пути и хранить всё необходимое поблизости, а не на разных дисках.
Пример того, что я хочу:
...\MyGodotProjects\Addons\addon1234\...
...\MyGodotProjects\AwesomeGame\game\...
Путь из игры к аддону в настройках проекта project.godot, не влияет на код в .gd скриптах игры:
..\Addons\addon1234\...
Если у пользователя нет такого аддона или путь неправильный, он просто меняет одну строчку в настройках на тот путь, который ему нужен. Если у пользователя уже есть этот аддон по этому пути, ему не придётся скачивать его лишний раз и иметь лишнюю копию в папке проекта. Если версия не совпадает... ну тут уже вопрос к разработчику аддона, почему он выпустил несовместимую версию, т.к. в идеале должна быть совместимость между всеми выпусками под одной мажорной версией.
Эх... Ну да, ты прав. Если, допустим, какую-то игру давно не обновлял, а используемый ею модуль обновил недавно, то эта игра может не смочь заработать без обновлений, учитывающих новую версию модуля. Но это только если ты реально несовместимые изменения вносишь, которые влияют на использование модуля игрой. В остальных случаях тебе придётся делать копипаст новой версии поверх устаревшей...
Ой, ещё и это настраивать, разбираться, бороться с ошибками в случае отключения питания и т.п. Я делаю проекты для себя и ни с кем не взаимодействую, так что вести длинную историю изменений каждого файла мне пока что не нужно. А ещё мне стыдно... вдруг кто-то увидит, какие изменения я вношу в свой код...
>девушка присылает .blend не проведя External File -> Pack All. В результате ничего не открывается, так как ссылается на ее C:\Users\Humanitarii\Documents
1. Присылать должна была не .blend, а .zip-папку со всеми зависимыми файлами. Да, можно упаковать файлы в .blend, но так будет сложнее ими управлять вне Blender (особенно если рисуешь текстуры в сторонней программе).
2. Вроде бы в Blender есть опция для использования только относительных путей. Понятия не имею, зачем в .blend хранить абсолютные пути... Из моего опыта, пути там обычно относительные, а не абсолютные - т.е. достаточно упаковать в .zip папку со всеми файлами.
>инклюдится "../someLib", которую автор не выложил, связаться невозможно, ни на что не отвечает.
Так и проект на Godot можно выложить так, что ничего работать не будет, если забыть какие-то файлы, в частности, какой-нибудь аддон. Это уже вопрос к разработчику проекта, а не к движку.
>присланный .doc ссылается на E:\Network\Share который ссылается на локальную сеть приславшего
Опять, тут как с .blend, может быть относительный путь, а может быть абсолютный. Нужно использовать относительные пути и хранить всё необходимое поблизости, а не на разных дисках.
Пример того, что я хочу:
...\MyGodotProjects\Addons\addon1234\...
...\MyGodotProjects\AwesomeGame\game\...
Путь из игры к аддону в настройках проекта project.godot, не влияет на код в .gd скриптах игры:
..\Addons\addon1234\...
Если у пользователя нет такого аддона или путь неправильный, он просто меняет одну строчку в настройках на тот путь, который ему нужен. Если у пользователя уже есть этот аддон по этому пути, ему не придётся скачивать его лишний раз и иметь лишнюю копию в папке проекта. Если версия не совпадает... ну тут уже вопрос к разработчику аддона, почему он выпустил несовместимую версию, т.к. в идеале должна быть совместимость между всеми выпусками под одной мажорной версией.
>нужно фиксировать версии модулей/пакетов
Эх... Ну да, ты прав. Если, допустим, какую-то игру давно не обновлял, а используемый ею модуль обновил недавно, то эта игра может не смочь заработать без обновлений, учитывающих новую версию модуля. Но это только если ты реально несовместимые изменения вносишь, которые влияют на использование модуля игрой. В остальных случаях тебе придётся делать копипаст новой версии поверх устаревшей...
>git
Ой, ещё и это настраивать, разбираться, бороться с ошибками в случае отключения питания и т.п. Я делаю проекты для себя и ни с кем не взаимодействую, так что вести длинную историю изменений каждого файла мне пока что не нужно. А ещё мне стыдно... вдруг кто-то увидит, какие изменения я вношу в свой код...
>>34090
Все папки документов винды? Еще раз - там могли быть ссылки на десятки папок в разных местах, каждая на свой объект.
Забыть "выложить аддон" можно только сделав активное действие - удалив аддон перед выкладыванием. Забыть выложить либу, которая несколько лет назад подключена из внешней папки - намного легче, сам подход это провоцирует.
Я вообще не уверен что doc спрашивает какой путь пользователь хочет использовать. Скорее всего он просто перетаскивает объекты на файл.
Перед выкладыванием историю можно почистить.
Здесь фишка не в истории, а в автосинхронизации всех изменений.
У тебя в любом случае должен быть бэкап 3-2-1, потому что в случае отключения питания и обычная файловая система может посыпаться.
Должно быть 3 копии, на 2х разных носителях (например, диск, облако, сдром), причем 1 должна быть физически в другом месте (вне одного помещения, на случай пожара/воровства)
>т.е. достаточно упаковать в .zip папку со всеми файлами.
Все папки документов винды? Еще раз - там могли быть ссылки на десятки папок в разных местах, каждая на свой объект.
>Так и проект на Godot можно выложить так, что ничего работать не будет, если забыть какие-то файлы, в частности, какой-нибудь аддон.
Забыть "выложить аддон" можно только сделав активное действие - удалив аддон перед выкладыванием. Забыть выложить либу, которая несколько лет назад подключена из внешней папки - намного легче, сам подход это провоцирует.
>Опять, тут как с .blend, может быть относительный путь, а может быть абсолютный.
Я вообще не уверен что doc спрашивает какой путь пользователь хочет использовать. Скорее всего он просто перетаскивает объекты на файл.
>А ещё мне стыдно... вдруг кто-то увидит, какие изменения я вношу в свой код...
Перед выкладыванием историю можно почистить.
>Я делаю проекты для себя и ни с кем не взаимодействую, так что вести длинную историю изменений каждого файла
Здесь фишка не в истории, а в автосинхронизации всех изменений.
> бороться с ошибками в случае отключения питания
У тебя в любом случае должен быть бэкап 3-2-1, потому что в случае отключения питания и обычная файловая система может посыпаться.
Должно быть 3 копии, на 2х разных носителях (например, диск, облако, сдром), причем 1 должна быть физически в другом месте (вне одного помещения, на случай пожара/воровства)
>>34096
З.ы. и гит тут опять же все упрощает, поскольку можно автоматически заливать в облако или на другой комп.
>Должно быть 3 копии, на 2х разных носителях (например, диск, облако, сдром), причем 1 должна быть физически в другом месте (вне одного помещения, на случай пожара/воровства)
З.ы. и гит тут опять же все упрощает, поскольку можно автоматически заливать в облако или на другой комп.
>>34096
Ну еще можно на флешку закинуть, ее в целлофановый пакет и прямо в пакете в попу засунуть. Так всяко надежней будет.
Ну а для нормальных людей хватит гитхаба без мозгоебли где можно откатить проект на любой шаг назад. Лень гитские консоли учить - скачай GitHub Desktop и делай то же самое в два клика.
>Должно быть 3 копии, на 2х разных носителях (например, диск, облако, сдром), причем 1 должна быть физически в другом месте (вне одного помещения, на случай пожара/воровства)
Ну еще можно на флешку закинуть, ее в целлофановый пакет и прямо в пакете в попу засунуть. Так всяко надежней будет.
Ну а для нормальных людей хватит гитхаба без мозгоебли где можно откатить проект на любой шаг назад. Лень гитские консоли учить - скачай GitHub Desktop и делай то же самое в два клика.
>>34127
Можно и на флешку, но флешки по моему опыту часто дохнут, так что они довольно слабы для бэкапов.
Не хватит. Облако - всегда высокий риск. Могут быть технические проблемы. У всех крупных облаков были истории, что навернулась база данных, из бэкапа кластер именно с твоими данными не поднялся, вот тебе 10 е-баллов на счет в компенсацию, все
Могут быть административные проблемы. Не понравится чем то твой аккаунт, удалят. Причем решение в наши дни может принимать бот. Теоретически, вдруг в репозиторий попадет картинка или музыка, которую бот посчитает нарушением копирайта. Были случаи, когда репы и их форки удалялись автоматически по жалобе.
Политические проблемы, очевидно, владелец гитхаба - майкрософт, западная компания, может быть обязаны выполнить санкции. (Сейчас какие то приняли по ограничению айти услуг)
Маркетологовые проблемы - в какой то момент облако может поменять тарифы, убрать бесплатный план, сделать ограничение на количество приватных реп. Вот у меня был аккаунт Heroku, к примеру, там вертелось пара серверов. Они объявили, что в конце Ноября бесплатные аккаунты будут остановлены. Но мой аккаунт был удален в начале Октября, сразу после анонса. Я даже не могу посмотреть, какие именно сервера у меня там оставались.
Секьюрные проблемы - аккаунт могут хакнуть, приватный репозиторий может украсть индус из техподдержки, из за глюка приватный репо может стать на время публичный, за это время китайцы склонируют твою игру, и прочее. Еще гитхаб обучает ИИ копилота, и не факт, что они утерпят и не возьмут для этого приватные репы - а куски кода из публичных реп в копилоте уже вылезали, причем с нарушением лицензий MIT/GPL.
Я бы на гитхабе вообще ничего кроме опен сорс не держал. Игры на LD Compo, где обязательно раскрывать исходники, демки для портфолио, аддоны и прочее, что контрибьютишь обратно в годот и прочий опенсорс.
Можно и на флешку, но флешки по моему опыту часто дохнут, так что они довольно слабы для бэкапов.
>для нормальных людей хватит гитхаба
Не хватит. Облако - всегда высокий риск. Могут быть технические проблемы. У всех крупных облаков были истории, что навернулась база данных, из бэкапа кластер именно с твоими данными не поднялся, вот тебе 10 е-баллов на счет в компенсацию, все
Могут быть административные проблемы. Не понравится чем то твой аккаунт, удалят. Причем решение в наши дни может принимать бот. Теоретически, вдруг в репозиторий попадет картинка или музыка, которую бот посчитает нарушением копирайта. Были случаи, когда репы и их форки удалялись автоматически по жалобе.
Политические проблемы, очевидно, владелец гитхаба - майкрософт, западная компания, может быть обязаны выполнить санкции. (Сейчас какие то приняли по ограничению айти услуг)
Маркетологовые проблемы - в какой то момент облако может поменять тарифы, убрать бесплатный план, сделать ограничение на количество приватных реп. Вот у меня был аккаунт Heroku, к примеру, там вертелось пара серверов. Они объявили, что в конце Ноября бесплатные аккаунты будут остановлены. Но мой аккаунт был удален в начале Октября, сразу после анонса. Я даже не могу посмотреть, какие именно сервера у меня там оставались.
Секьюрные проблемы - аккаунт могут хакнуть, приватный репозиторий может украсть индус из техподдержки, из за глюка приватный репо может стать на время публичный, за это время китайцы склонируют твою игру, и прочее. Еще гитхаб обучает ИИ копилота, и не факт, что они утерпят и не возьмут для этого приватные репы - а куски кода из публичных реп в копилоте уже вылезали, причем с нарушением лицензий MIT/GPL.
Я бы на гитхабе вообще ничего кроме опен сорс не держал. Игры на LD Compo, где обязательно раскрывать исходники, демки для портфолио, аддоны и прочее, что контрибьютишь обратно в годот и прочий опенсорс.
70 Кб, 394x522>>34127
Распечатать на принтере, опечатать, прошить, заверить подписями и положить на хранение в сейф.
> в попу засунуть
Распечатать на принтере, опечатать, прошить, заверить подписями и положить на хранение в сейф.
>>34213
И можно проебать все упомянутые 3-2-1 копии проекта. Хоть в попу суй хоть под кожу в чип закладывай. Всегда есть шанс.
Так что это уже шиза. Если ты не корпорация гитхабу на тебя похуй, тебя даже свою страну указывать не заставляют.
>Не хватит.
И можно проебать все упомянутые 3-2-1 копии проекта. Хоть в попу суй хоть под кожу в чип закладывай. Всегда есть шанс.
Так что это уже шиза. Если ты не корпорация гитхабу на тебя похуй, тебя даже свою страну указывать не заставляют.
>>34218
Нельзя, точнее маловероятно. Шансы перемножаются, грубо говоря, если у тебя нет бэкапа и шанс фейла жесткого диска 1/100, то скопировав на другой диск, шанс улучшится до 1/10000, а если в трех местах, то уже 1/1000000. Но если они у тебя все в одной комнате, то шанс потерять при пожаре одинаковый, скажем 1/2000.
Переходить улицу на красный тоже кто-то назовет шизой. Не, если у тебя проект просто учебный, то невелика потеря, еще раз перепишешь. А если это дело всей жизни, то уже стоит озаботиться.
Есть сбор данных, таких как IP, с которого заходишь, язык выставленный в операционной системе и прочее.
Лет 20 назад это было параноей, а сейчас это стало реальностью. Буквально на днях кто-то рассказывал, что оплачивал зарубежный сервер через зарубежный впн, но один раз случайно зашел без впн напрямую, и с тех пор не может продлить даже через впн - очевидно автоматика пометила аккаунт, выставила флаг.
>И можно проебать все упомянутые 3-2-1 копии проекта.
Нельзя, точнее маловероятно. Шансы перемножаются, грубо говоря, если у тебя нет бэкапа и шанс фейла жесткого диска 1/100, то скопировав на другой диск, шанс улучшится до 1/10000, а если в трех местах, то уже 1/1000000. Но если они у тебя все в одной комнате, то шанс потерять при пожаре одинаковый, скажем 1/2000.
>Так что это уже шиза.
Переходить улицу на красный тоже кто-то назовет шизой. Не, если у тебя проект просто учебный, то невелика потеря, еще раз перепишешь. А если это дело всей жизни, то уже стоит озаботиться.
>Если ты не корпорация гитхабу на тебя похуй, тебя даже свою страну указывать не заставляют.
Есть сбор данных, таких как IP, с которого заходишь, язык выставленный в операционной системе и прочее.
Лет 20 назад это было параноей, а сейчас это стало реальностью. Буквально на днях кто-то рассказывал, что оплачивал зарубежный сервер через зарубежный впн, но один раз случайно зашел без впн напрямую, и с тех пор не может продлить даже через впн - очевидно автоматика пометила аккаунт, выставила флаг.
>>33955 (OP)
чуваки, есть же в платформерах такая фича, когда перс совершает прыжок с края какой-то платформы. так вот, там дается небольшой по продолжительности форс, когда гг может прыгнуть как-бэ в "полете", тоесть чтобы игрок точно успел прыгнуть, а не упал вниз перед тем, как нажал на кнопку прыжка.
ну дак вот
оцените мою реализацию этой хуйни:
https://pastebin.com/pJqXyw5Q
код представляет собой модифицированную версию кода отсюда: https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
чуваки, есть же в платформерах такая фича, когда перс совершает прыжок с края какой-то платформы. так вот, там дается небольшой по продолжительности форс, когда гг может прыгнуть как-бэ в "полете", тоесть чтобы игрок точно успел прыгнуть, а не упал вниз перед тем, как нажал на кнопку прыжка.
ну дак вот
оцените мою реализацию этой хуйни:
https://pastebin.com/pJqXyw5Q
код представляет собой модифицированную версию кода отсюда: https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
>>34253
Coyot time & coyot timer
Хуйня как хуйня. Работает? Ну и ладно.
> есть же в платформерах такая фича
Coyot time & coyot timer
> оцените мою реализацию этой хуйни:
Хуйня как хуйня. Работает? Ну и ладно.
>>34096
Зачем тебе ссылки на десятки папок? Храни всё близко, но без копипаста файлов в каждый проект.
Ты недооцениваешь выкладывающих...
Кстати, Inkscape на такое действие по умолчанию всегда спрашивает, как соединить файлы - по ссылке на файл или встраиванием в svg (base64 скорее всего). И это правильно, потому что всё зависит от ситуации, маленькую иконку для портативности в svg можно встроить, а 4К обоина пусть лучше будет покоиться в отдельном файле в более подходящем формате. А не так, что паковать всё в один файл из-за каких-то дураков, которые могут скинуть файл со ссылками на внешние файлы без самих этих внешних файлов. Если бы все под дураков подстраивались, мы бы так и жили на деревьях, а то дурак может случайно заблудиться в пещере или сгореть в костре, порезаться острым камнем или задавиться колесом. Нет, пусть дураки сами как-нибудь справляются.
Стоимость защиты не должна превышать стоимость защищаемого объекта.
Это маловероятно, NTFS хорошо защищена от этого, проблема у меня была только когда сам диск начал выходить из строя и уже не мог прочитать данные из отдельных секторов диска. С FAT тоже проблем не было, если и есть ошибки, файлы не утрачиваются. А вот какая там защита у конкретной реализации git мне лень разбираться...
>>34127
Если у тебя очень ценные данные, не стоит так сильно полагаться на гитхаб. У него может произойти авария на серверах или сама корпорация может обанкротиться. Т.е. они могут физически не иметь возможности восстановить твои данные, не говоря уж о том, что ты, скорее всего, пользуешься их услугами бесплатно, то есть они тебе вообще ничего не обязаны (лол).
>>34215
Недостаточно надёжно, бумага может сгореть прямо в сейфе, если будет пожар. А вот все слышали, что рукописи не горят? Нужно переписать все данные от руки! Так им точно ничего не повредит.
>>34213
У них просто низкий ресурс перезаписи ячеек. Но в остальном это достаточно надёжное хранилище (на 10+ лет), если ты бережно к нему относишься (а то обычно люди слишком небрежны с флешками). Из всех флешек у меня "умерла" всего одна MicroSD, но она позволяет считать все файлы, нельзя только записывать.
Лол, разве китайцам нужен доступ к исходным кодам игры, чтобы её склонировать? Им достаточно тизера на 10 секунд, чтобы создать твою игру быстрее тебя.
А я бы ничего кроме опенсорса бы не делал, если бы не было стыдно за мой код (бросил рисование из-за стыда за рисунки, а рисовать для себя скучно).
Хороший сервис "хероку" не назовут)))
>>34218
Это не шиза, это минимизация рисков. Конечно, может вот прям сейчас случиться апокалипсис и Землю порвёт на мелкий щебень, и что теперь? Сидеть в бункере, упаковавшись в бронированный скафандр, чтобы в случае чего пожить ещё полчаса в облаке щебня? Шиза - это считать себя неуязвимым, а нормальные люди хотя бы минимально заботятся о безопасности того, что им дорого, чтобы оно пережило хотя бы наиболее вероятные сценарии (отключение электричества, пожар в дата-центре и т.п.). От всего не защититься, но можно снизить риск пострадать от наиболее вероятного.
>>34220
Ну тогда любого чистокровного американца можно взломать паяльником, если зайти в его аккаунт со своего СНГшного айпи. Пометят как "русский хакер" и больше не будут обслуживать, даже если он лично заявится с паспортом в главный офис? Бред же. Такая "защита" скорее всего плохо продумана и самим сервисом, соответственно, пользоваться не стоит - мало ли что они там ещё плохо продумали.
>там могли быть ссылки на десятки папок
Зачем тебе ссылки на десятки папок? Храни всё близко, но без копипаста файлов в каждый проект.
>Забыть "выложить аддон" можно только сделав активное действие - удалив аддон перед выкладыванием.
Ты недооцениваешь выкладывающих...
>Скорее всего он просто перетаскивает объекты на файл.
Кстати, Inkscape на такое действие по умолчанию всегда спрашивает, как соединить файлы - по ссылке на файл или встраиванием в svg (base64 скорее всего). И это правильно, потому что всё зависит от ситуации, маленькую иконку для портативности в svg можно встроить, а 4К обоина пусть лучше будет покоиться в отдельном файле в более подходящем формате. А не так, что паковать всё в один файл из-за каких-то дураков, которые могут скинуть файл со ссылками на внешние файлы без самих этих внешних файлов. Если бы все под дураков подстраивались, мы бы так и жили на деревьях, а то дурак может случайно заблудиться в пещере или сгореть в костре, порезаться острым камнем или задавиться колесом. Нет, пусть дураки сами как-нибудь справляются.
>бэкап 3-2-1
Стоимость защиты не должна превышать стоимость защищаемого объекта.
>обычная файловая система может посыпаться
Это маловероятно, NTFS хорошо защищена от этого, проблема у меня была только когда сам диск начал выходить из строя и уже не мог прочитать данные из отдельных секторов диска. С FAT тоже проблем не было, если и есть ошибки, файлы не утрачиваются. А вот какая там защита у конкретной реализации git мне лень разбираться...
>>34127
>хватит гитхаба
Если у тебя очень ценные данные, не стоит так сильно полагаться на гитхаб. У него может произойти авария на серверах или сама корпорация может обанкротиться. Т.е. они могут физически не иметь возможности восстановить твои данные, не говоря уж о том, что ты, скорее всего, пользуешься их услугами бесплатно, то есть они тебе вообще ничего не обязаны (лол).
>>34215
>Распечатать на принтере, опечатать, прошить, заверить подписями и положить на хранение в сейф.
Недостаточно надёжно, бумага может сгореть прямо в сейфе, если будет пожар. А вот все слышали, что рукописи не горят? Нужно переписать все данные от руки! Так им точно ничего не повредит.
>>34213
>флешки по моему опыту часто дохнут
У них просто низкий ресурс перезаписи ячеек. Но в остальном это достаточно надёжное хранилище (на 10+ лет), если ты бережно к нему относишься (а то обычно люди слишком небрежны с флешками). Из всех флешек у меня "умерла" всего одна MicroSD, но она позволяет считать все файлы, нельзя только записывать.
>китайцы склонируют твою игру
Лол, разве китайцам нужен доступ к исходным кодам игры, чтобы её склонировать? Им достаточно тизера на 10 секунд, чтобы создать твою игру быстрее тебя.
>Я бы на гитхабе вообще ничего кроме опен сорс не держал.
А я бы ничего кроме опенсорса бы не делал, если бы не было стыдно за мой код (бросил рисование из-за стыда за рисунки, а рисовать для себя скучно).
>Heroku
Хороший сервис "хероку" не назовут)))
>>34218
>Всегда есть шанс.
>Так что это уже шиза.
Это не шиза, это минимизация рисков. Конечно, может вот прям сейчас случиться апокалипсис и Землю порвёт на мелкий щебень, и что теперь? Сидеть в бункере, упаковавшись в бронированный скафандр, чтобы в случае чего пожить ещё полчаса в облаке щебня? Шиза - это считать себя неуязвимым, а нормальные люди хотя бы минимально заботятся о безопасности того, что им дорого, чтобы оно пережило хотя бы наиболее вероятные сценарии (отключение электричества, пожар в дата-центре и т.п.). От всего не защититься, но можно снизить риск пострадать от наиболее вероятного.
>>34220
>случайно зашел без впн напрямую
>пометила аккаунт, выставила флаг
Ну тогда любого чистокровного американца можно взломать паяльником, если зайти в его аккаунт со своего СНГшного айпи. Пометят как "русский хакер" и больше не будут обслуживать, даже если он лично заявится с паспортом в главный офис? Бред же. Такая "защита" скорее всего плохо продумана и самим сервисом, соответственно, пользоваться не стоит - мало ли что они там ещё плохо продумали.
>>34096
Зачем тебе ссылки на десятки папок? Храни всё близко, но без копипаста файлов в каждый проект.
Ты недооцениваешь выкладывающих...
Кстати, Inkscape на такое действие по умолчанию всегда спрашивает, как соединить файлы - по ссылке на файл или встраиванием в svg (base64 скорее всего). И это правильно, потому что всё зависит от ситуации, маленькую иконку для портативности в svg можно встроить, а 4К обоина пусть лучше будет покоиться в отдельном файле в более подходящем формате. А не так, что паковать всё в один файл из-за каких-то дураков, которые могут скинуть файл со ссылками на внешние файлы без самих этих внешних файлов. Если бы все под дураков подстраивались, мы бы так и жили на деревьях, а то дурак может случайно заблудиться в пещере или сгореть в костре, порезаться острым камнем или задавиться колесом. Нет, пусть дураки сами как-нибудь справляются.
Стоимость защиты не должна превышать стоимость защищаемого объекта.
Это маловероятно, NTFS хорошо защищена от этого, проблема у меня была только когда сам диск начал выходить из строя и уже не мог прочитать данные из отдельных секторов диска. С FAT тоже проблем не было, если и есть ошибки, файлы не утрачиваются. А вот какая там защита у конкретной реализации git мне лень разбираться...
>>34127
Если у тебя очень ценные данные, не стоит так сильно полагаться на гитхаб. У него может произойти авария на серверах или сама корпорация может обанкротиться. Т.е. они могут физически не иметь возможности восстановить твои данные, не говоря уж о том, что ты, скорее всего, пользуешься их услугами бесплатно, то есть они тебе вообще ничего не обязаны (лол).
>>34215
Недостаточно надёжно, бумага может сгореть прямо в сейфе, если будет пожар. А вот все слышали, что рукописи не горят? Нужно переписать все данные от руки! Так им точно ничего не повредит.
>>34213
У них просто низкий ресурс перезаписи ячеек. Но в остальном это достаточно надёжное хранилище (на 10+ лет), если ты бережно к нему относишься (а то обычно люди слишком небрежны с флешками). Из всех флешек у меня "умерла" всего одна MicroSD, но она позволяет считать все файлы, нельзя только записывать.
Лол, разве китайцам нужен доступ к исходным кодам игры, чтобы её склонировать? Им достаточно тизера на 10 секунд, чтобы создать твою игру быстрее тебя.
А я бы ничего кроме опенсорса бы не делал, если бы не было стыдно за мой код (бросил рисование из-за стыда за рисунки, а рисовать для себя скучно).
Хороший сервис "хероку" не назовут)))
>>34218
Это не шиза, это минимизация рисков. Конечно, может вот прям сейчас случиться апокалипсис и Землю порвёт на мелкий щебень, и что теперь? Сидеть в бункере, упаковавшись в бронированный скафандр, чтобы в случае чего пожить ещё полчаса в облаке щебня? Шиза - это считать себя неуязвимым, а нормальные люди хотя бы минимально заботятся о безопасности того, что им дорого, чтобы оно пережило хотя бы наиболее вероятные сценарии (отключение электричества, пожар в дата-центре и т.п.). От всего не защититься, но можно снизить риск пострадать от наиболее вероятного.
>>34220
Ну тогда любого чистокровного американца можно взломать паяльником, если зайти в его аккаунт со своего СНГшного айпи. Пометят как "русский хакер" и больше не будут обслуживать, даже если он лично заявится с паспортом в главный офис? Бред же. Такая "защита" скорее всего плохо продумана и самим сервисом, соответственно, пользоваться не стоит - мало ли что они там ещё плохо продумали.
>там могли быть ссылки на десятки папок
Зачем тебе ссылки на десятки папок? Храни всё близко, но без копипаста файлов в каждый проект.
>Забыть "выложить аддон" можно только сделав активное действие - удалив аддон перед выкладыванием.
Ты недооцениваешь выкладывающих...
>Скорее всего он просто перетаскивает объекты на файл.
Кстати, Inkscape на такое действие по умолчанию всегда спрашивает, как соединить файлы - по ссылке на файл или встраиванием в svg (base64 скорее всего). И это правильно, потому что всё зависит от ситуации, маленькую иконку для портативности в svg можно встроить, а 4К обоина пусть лучше будет покоиться в отдельном файле в более подходящем формате. А не так, что паковать всё в один файл из-за каких-то дураков, которые могут скинуть файл со ссылками на внешние файлы без самих этих внешних файлов. Если бы все под дураков подстраивались, мы бы так и жили на деревьях, а то дурак может случайно заблудиться в пещере или сгореть в костре, порезаться острым камнем или задавиться колесом. Нет, пусть дураки сами как-нибудь справляются.
>бэкап 3-2-1
Стоимость защиты не должна превышать стоимость защищаемого объекта.
>обычная файловая система может посыпаться
Это маловероятно, NTFS хорошо защищена от этого, проблема у меня была только когда сам диск начал выходить из строя и уже не мог прочитать данные из отдельных секторов диска. С FAT тоже проблем не было, если и есть ошибки, файлы не утрачиваются. А вот какая там защита у конкретной реализации git мне лень разбираться...
>>34127
>хватит гитхаба
Если у тебя очень ценные данные, не стоит так сильно полагаться на гитхаб. У него может произойти авария на серверах или сама корпорация может обанкротиться. Т.е. они могут физически не иметь возможности восстановить твои данные, не говоря уж о том, что ты, скорее всего, пользуешься их услугами бесплатно, то есть они тебе вообще ничего не обязаны (лол).
>>34215
>Распечатать на принтере, опечатать, прошить, заверить подписями и положить на хранение в сейф.
Недостаточно надёжно, бумага может сгореть прямо в сейфе, если будет пожар. А вот все слышали, что рукописи не горят? Нужно переписать все данные от руки! Так им точно ничего не повредит.
>>34213
>флешки по моему опыту часто дохнут
У них просто низкий ресурс перезаписи ячеек. Но в остальном это достаточно надёжное хранилище (на 10+ лет), если ты бережно к нему относишься (а то обычно люди слишком небрежны с флешками). Из всех флешек у меня "умерла" всего одна MicroSD, но она позволяет считать все файлы, нельзя только записывать.
>китайцы склонируют твою игру
Лол, разве китайцам нужен доступ к исходным кодам игры, чтобы её склонировать? Им достаточно тизера на 10 секунд, чтобы создать твою игру быстрее тебя.
>Я бы на гитхабе вообще ничего кроме опен сорс не держал.
А я бы ничего кроме опенсорса бы не делал, если бы не было стыдно за мой код (бросил рисование из-за стыда за рисунки, а рисовать для себя скучно).
>Heroku
Хороший сервис "хероку" не назовут)))
>>34218
>Всегда есть шанс.
>Так что это уже шиза.
Это не шиза, это минимизация рисков. Конечно, может вот прям сейчас случиться апокалипсис и Землю порвёт на мелкий щебень, и что теперь? Сидеть в бункере, упаковавшись в бронированный скафандр, чтобы в случае чего пожить ещё полчаса в облаке щебня? Шиза - это считать себя неуязвимым, а нормальные люди хотя бы минимально заботятся о безопасности того, что им дорого, чтобы оно пережило хотя бы наиболее вероятные сценарии (отключение электричества, пожар в дата-центре и т.п.). От всего не защититься, но можно снизить риск пострадать от наиболее вероятного.
>>34220
>случайно зашел без впн напрямую
>пометила аккаунт, выставила флаг
Ну тогда любого чистокровного американца можно взломать паяльником, если зайти в его аккаунт со своего СНГшного айпи. Пометят как "русский хакер" и больше не будут обслуживать, даже если он лично заявится с паспортом в главный офис? Бред же. Такая "защита" скорее всего плохо продумана и самим сервисом, соответственно, пользоваться не стоит - мало ли что они там ещё плохо продумали.
>>34253
Не люблю таймеры для такого. Лень расписывать, но может произойти рассинхрон, когда таймер сначала запущен, потом выставится флаг что прыгать можно, а тут таймер закончится и тут же сбросит флаг, или наоборот. Так что я просто завожу переменную и увеличиваю ее на delta, и сравниваю с предыдущим таймстампом.
Не люблю таймеры для такого. Лень расписывать, но может произойти рассинхрон, когда таймер сначала запущен, потом выставится флаг что прыгать можно, а тут таймер закончится и тут же сбросит флаг, или наоборот. Так что я просто завожу переменную и увеличиваю ее на delta, и сравниваю с предыдущим таймстампом.
>>34262
Ты чего такой грубый? Хочешь, чтобы вообще ничего полезного в тред не постили?
>>34253
Зачем тебе нода Timer? Тем более если ты 60 раз в секунду сбрасываешь её состояние (логичнее включать таймер только когда он действительно нужен). Для простых задач есть встроенные в дерево сцены таймеры.
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-create-timer
Но их здесь, конечно, нерационально использовать, т.к. будет создание лишнего ООП объекта.
Но в данном случае я бы сделал так:
Здесь всё необходимое есть в коде, не зависит от какой-то отдельной ноды и не создаёт лишних объектов. При этом по-прежнему можно настраивать через инспектор, если экспортировать coyote_time_max - это даже удобнее с точки зрения настройки сцен, т.к. параметр будет у KinematicBody, а не у одной из дочерних нод. С точки зрения производительности это должно быть оптимальнее, т.к. нет обращений к API движка и вызовов функций. К тому же такой код проще для понимания - ведь всё необходимое в одном месте, а не в отдельных методах и тем более файлах (таймер у тебя описывается в tscn).
>Хуйня как хуйня. Работает? Ну и ладно.
Ты чего такой грубый? Хочешь, чтобы вообще ничего полезного в тред не постили?
>>34253
>оцените мою реализацию
Зачем тебе нода Timer? Тем более если ты 60 раз в секунду сбрасываешь её состояние (логичнее включать таймер только когда он действительно нужен). Для простых задач есть встроенные в дерево сцены таймеры.
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-create-timer
Но их здесь, конечно, нерационально использовать, т.к. будет создание лишнего ООП объекта.
Но в данном случае я бы сделал так:
>if coyote_time > 0: coyote_time -= delta
>else: can_jump = false
>if is_on_floor():
>_ coyote_time = coyote_time_max
>_ can_jump = true
>else: velocity.y += gravity x delta
Здесь всё необходимое есть в коде, не зависит от какой-то отдельной ноды и не создаёт лишних объектов. При этом по-прежнему можно настраивать через инспектор, если экспортировать coyote_time_max - это даже удобнее с точки зрения настройки сцен, т.к. параметр будет у KinematicBody, а не у одной из дочерних нод. С точки зрения производительности это должно быть оптимальнее, т.к. нет обращений к API движка и вызовов функций. К тому же такой код проще для понимания - ведь всё необходимое в одном месте, а не в отдельных методах и тем более файлах (таймер у тебя описывается в tscn).
>>34273
Да не грубо вроде. В чём грубость-то? Ты сказал, что у тебя хуйня, я ответил, что твоя хуйня обычная хуйня (по Эскобару). Такшта грубости никакой нет.
> Ты чего такой грубый?
Да не грубо вроде. В чём грубость-то? Ты сказал, что у тебя хуйня, я ответил, что твоя хуйня обычная хуйня (по Эскобару). Такшта грубости никакой нет.
>>34274
Он просил оценить его реализацию малоинтересной геймдизайнерской фичи, а ты обзываешь уже саму реализацию, а не фичу.
Алсо, раз уж затронул эту тему: в творческой среде новички часто заранее обесценивают свою работу из-за заниженной самооценки или в качестве компенсации страха перед критикой, и такого новичка лучше похвалить за его работу, а не соглашаться с ним, что его работа - бесполезная трата времени. Т.е. даже если человек сам обесценивает свою работу, он всё же ожидает поддержки со стороны, а не согласие с тем, что он занимается пустой тратой времени. Если б ему не нужна была поддержка, он бы не постил свою работу, т.к. это бессмысленно.
>>34272
Не уверен, но в теории такой рассинхрон возможен только если таймер и твой код работают в параллельных потоках. Если весь код в одном потоке, обработчик сигнала таймера не сработает, пока не выполнится твой код, в котором ты отменяешь срабатывание таймера. Возможно, ты писал параллельный код или использовал таймеры из дерева сцены - их нужно явным образом останавливать перед созданием нового, иначе ты просто потеряешь ссылку на предыдущий таймер и он вызовет свой обработчик как и положено (но он тебе уже не нужен).
Почему увеличиваешь? В данном случае логичнее использовать обратный отчёт от заданной величины и сравнивать с нулём.
>сказал, что у тебя хуйня
Он просил оценить его реализацию малоинтересной геймдизайнерской фичи, а ты обзываешь уже саму реализацию, а не фичу.
Алсо, раз уж затронул эту тему: в творческой среде новички часто заранее обесценивают свою работу из-за заниженной самооценки или в качестве компенсации страха перед критикой, и такого новичка лучше похвалить за его работу, а не соглашаться с ним, что его работа - бесполезная трата времени. Т.е. даже если человек сам обесценивает свою работу, он всё же ожидает поддержки со стороны, а не согласие с тем, что он занимается пустой тратой времени. Если б ему не нужна была поддержка, он бы не постил свою работу, т.к. это бессмысленно.
>>34272
>может произойти рассинхрон
Не уверен, но в теории такой рассинхрон возможен только если таймер и твой код работают в параллельных потоках. Если весь код в одном потоке, обработчик сигнала таймера не сработает, пока не выполнится твой код, в котором ты отменяешь срабатывание таймера. Возможно, ты писал параллельный код или использовал таймеры из дерева сцены - их нужно явным образом останавливать перед созданием нового, иначе ты просто потеряешь ссылку на предыдущий таймер и он вызовет свой обработчик как и положено (но он тебе уже не нужен).
>увеличиваю ее на delta, и сравниваю с предыдущим таймстампом.
Почему увеличиваешь? В данном случае логичнее использовать обратный отчёт от заданной величины и сравнивать с нулём.
>>34276
Сорян, я фанат Артемия Лебедева (был им до эпохи ютуба, ру.ководство наизусть читал, например), так шта от меня только критика и оскорбления. Бойтесь новички! Ехехех!
> похвалить за его работу
Сорян, я фанат Артемия Лебедева (был им до эпохи ютуба, ру.ководство наизусть читал, например), так шта от меня только критика и оскорбления. Бойтесь новички! Ехехех!
>>34273
спасибо, братишка. теперь догадался, что дельту можно использовать как величину прошедшего времени, вместо таймера
спасибо, братишка. теперь догадался, что дельту можно использовать как величину прошедшего времени, вместо таймера
>>34284
Невероятно! Правда штоле? Дельта - это оказывается Δt из уроков матана? Охуеть! Вот это новости! Ебануться!
> догадался, что дельту можно использовать как величину прошедшего времени
Невероятно! Правда штоле? Дельта - это оказывается Δt из уроков матана? Охуеть! Вот это новости! Ебануться!
Здравствуйте. Объясните пожалуйста для не-программиста что всё-таки за магия там под капотом происходит и правильно ли я ее интерпретирую... Как я понял очень много если не большую часть игровой логики можно описать простейшим синтаксисом типа if/else/then var/const и логическими операциями..
Ну вот например мне нужно чтобы был предмет, у которого есть определенное количество использований, после истечения которых предмет исчезает. Это значит, что я добавляю сам предмет, затем привязываю числовое значение y, которое убавляется после нажатия кнопки x, после того как значение y достигнет 0, предмет удаляется. Все правильно? Я просто не уверен что это самый лаконичный способ решения проблемы.. Ну или вот ещё пример - значение y убавляется только в случае, если кнопка x нажата когда курсор мыши указывает на тайл z.
Извините если вопрос прям тупой или платина, я просто совсем-совсем нубас и хочу понять как свои маняфантазии превратить в какое-то подобие ТЗ, после которого уже будет проще писать код.
Ну вот например мне нужно чтобы был предмет, у которого есть определенное количество использований, после истечения которых предмет исчезает. Это значит, что я добавляю сам предмет, затем привязываю числовое значение y, которое убавляется после нажатия кнопки x, после того как значение y достигнет 0, предмет удаляется. Все правильно? Я просто не уверен что это самый лаконичный способ решения проблемы.. Ну или вот ещё пример - значение y убавляется только в случае, если кнопка x нажата когда курсор мыши указывает на тайл z.
Извините если вопрос прям тупой или платина, я просто совсем-совсем нубас и хочу понять как свои маняфантазии превратить в какое-то подобие ТЗ, после которого уже будет проще писать код.
>>34288
в первом вопросе можешь использовать кастомный сигнал (см отдельный гайд по сигналам)
второй вопрос я не понял, в чем он
в первом вопросе можешь использовать кастомный сигнал (см отдельный гайд по сигналам)
второй вопрос я не понял, в чем он
>>34290
а стоп не, сигнал не надо, лучше используй сеттер для значения y (см ключевое слово "setget")
а стоп не, сигнал не надо, лучше используй сеттер для значения y (см ключевое слово "setget")
>>34293
Всё я прекрасно понял.
Всё я прекрасно понял.
всем привет вот вам обновленная версия скрипта без ноды таймера + теперь перс во время койот тайма не падает вниз, а продолжает идти горизонтально по воздуху, причем только если он не останавливался перед обрывом
https://pastebin.com/t5BmzyQ5
https://pastebin.com/t5BmzyQ5
>>34300
за фпс на видосе не ручаюсь - записывал через kazam на линуксе, особо не лазя в настройках этого скринкастера
за фпс на видосе не ручаюсь - записывал через kazam на линуксе, особо не лазя в настройках этого скринкастера
>>34302
да я тут даже не игру пилю, а учу движок. перса где-то месяц назад на досуге нашакалил
да я тут даже не игру пилю, а учу движок. перса где-то месяц назад на досуге нашакалил
>>33955 (OP)
Есть реализации повреждений основанная на soft body у годота из коробки? Не нашел чета. Как безигорные гта будут создавать?
Есть реализации повреждений основанная на soft body у годота из коробки? Не нашел чета. Как безигорные гта будут создавать?
>>34326
Проблема создания ГТА не в инструментах, а в количестве разрабов. Безыгорный в одно рыло ГТА не запилит. Сколько ни усирайся в срачетреде.
Проблема создания ГТА не в инструментах, а в количестве разрабов. Безыгорный в одно рыло ГТА не запилит. Сколько ни усирайся в срачетреде.
>>34326
А в чем именно у тебя трудность возникла?
А в чем именно у тебя трудность возникла?
>>34285
С каких пор математики озаботились измерением времени?
Дельта времени - это из физики. В физике есть формулы, но физика - не математика.
А поскольку физика у нас необязательный предмет, результат сам понимаешь...
>Дельта - это оказывается Δt из уроков матана?
С каких пор математики озаботились измерением времени?
Дельта времени - это из физики. В физике есть формулы, но физика - не математика.
А поскольку физика у нас необязательный предмет, результат сам понимаешь...
>>833915 →
Попробовал их CLI инструмент с сайта, работает, но все ключи в словарях (которые фигурные скобки, которые Dictionary) после "компиляции" в JSON сортируются по алфавиту. Очень раздражает этот момент. Смотрел их гитхаб, там вроде сказано, что добавили какую-то функцию для вывода без сортировки, но в CLI эта функция вроде как недоступна. При этом на их сайте онлайн утилита конвертирует без сортировки. Такое огорчение, блин... Хоть сам теперь пиши собственную утилиту. Или забить и не обращать внимание на сортировку? Я понимаю, что для Dictionary в Godot порядок безразличен, просто хотелось чтобы файлы были лучше организованы...
>https://hjson.github.io/ - значительно упрощает запись в JSON.
Попробовал их CLI инструмент с сайта, работает, но все ключи в словарях (которые фигурные скобки, которые Dictionary) после "компиляции" в JSON сортируются по алфавиту. Очень раздражает этот момент. Смотрел их гитхаб, там вроде сказано, что добавили какую-то функцию для вывода без сортировки, но в CLI эта функция вроде как недоступна. При этом на их сайте онлайн утилита конвертирует без сортировки. Такое огорчение, блин... Хоть сам теперь пиши собственную утилиту. Или забить и не обращать внимание на сортировку? Я понимаю, что для Dictionary в Godot порядок безразличен, просто хотелось чтобы файлы были лучше организованы...
>>34408
Понимаю, умом, но сердце требует прописать с ноги в еблину тупым зумерам с клиповым мышлением за их тупые вопросы! Так, где мои таблетки?
> результат сам понимаешь
Понимаю, умом, но сердце требует прописать с ноги в еблину тупым зумерам с клиповым мышлением за их тупые вопросы! Так, где мои таблетки?
>>34298
В таких местах лучше использовать константы: Vector2.UP
https://docs.godotengine.org/en/stable/classes/class_vector2.html#constants
>>34300
В Firefox видео не воспроизводится, пришлось скачивать. Рекомендую прогонять через ffmpeg, тогда точно будет поддерживаться браузером (во всяком случае из моего опыта так):
>>34303
Советую привыкать к типизированному подходу - по возможности везде явно выставляй типы переменных, аргументов функций и т.д. Это избавит от множества проблем.
>Vector2(0, -1)
В таких местах лучше использовать константы: Vector2.UP
https://docs.godotengine.org/en/stable/classes/class_vector2.html#constants
>>34300
В Firefox видео не воспроизводится, пришлось скачивать. Рекомендую прогонять через ffmpeg, тогда точно будет поддерживаться браузером (во всяком случае из моего опыта так):
>ffmpeg -i файл.mp4 результат.mp4
>>34303
>учу движок
Советую привыкать к типизированному подходу - по возможности везде явно выставляй типы переменных, аргументов функций и т.д. Это избавит от множества проблем.
>>34413
Я не зумер, но тоже какое-то время не понимал, что эта "дельта" значит.
Конечно, я слышал, что "дельта" - это
Но само по себе слово "дельта" не говорит о том, что это за параметр.
Я думаю, было бы лучше назвать это frame_time или tick_time в зависимости от контекста (_process или _physics_process). Так было бы сразу понятно: "время кадра" - время, прошедшее от отрисовки предыдущего кадра; "время тика" - время, прошедшее с предыдущего тика.
А то "дельт" в коде может быть много, не обязательно только дельта времени кадра/тика.
>тупым зумерам
Я не зумер, но тоже какое-то время не понимал, что эта "дельта" значит.
Конечно, я слышал, что "дельта" - это
>матем. конечная разность при изменении какого-либо параметра
Но само по себе слово "дельта" не говорит о том, что это за параметр.
Я думаю, было бы лучше назвать это frame_time или tick_time в зависимости от контекста (_process или _physics_process). Так было бы сразу понятно: "время кадра" - время, прошедшее от отрисовки предыдущего кадра; "время тика" - время, прошедшее с предыдущего тика.
А то "дельт" в коде может быть много, не обязательно только дельта времени кадра/тика.
>>34326
Нет и никогда не будет. Потому что такая система имеет очень узкоспециальное применение и требует сложной настройки для каждой конкретной ситуации. Следовательно, при создании серьёзной игры будет лучше написать свою систему с нуля, чем использовать какое-либо встроенное решение.
Но я видел минимум один платный аддон, реализующий физику повреждений машин.
Годо - универсальный движок для любых игр, поэтому у него нет и не будет узкоспециальных инструментов, которые сложно адаптировать для множества разных игр. Если хочешь по-быстрому сделать что-то вроде ГТА, тогда ищи конструктор игр типа ГТА или готовый набор ассетов для игр типа ГТА на какой-либо универсальный движок; сам по себе универсальный движок тут не поможет, он слишком низкоуровневый по определению (конструкторы - высокоуровневые, движки - низкоуровневые, но всё это очень относительно, конечно).
Ты же в курсе, что даже в рамках серии ГТА физика машин значительно изменялась? Пусть GTA SA была логичным развитием движка GTA 3 и VS, но вот разница между GTA SA, IV и V очень большая.
1. В GTA SA простая физика, только имитирующая повреждения путём замены мешей неповреждённых деталей на меши, выглядящие повреждёнными.
2. В GTA IV попытались реализовать честную симуляцию, которая позволяет сминать машины всмятку по любому направлению, если приложить достаточно усилий или времени (лично экспериментировал).
3. Но в GTA V от этой системы отказались, вернувшись к весьма примитивным повреждениям, а в GTA Online новые машины из регулярно выходящих DLC вообще никак не мнутся, у них только отваливаются некоторые части и всё.
Всё это разнообразие невозможно упаковать в один маленький игровой движок... да и некому этим заниматься - у Годо малое количество разработчиков и инвестиции идут в основном в 2D и рендер, а не в 3D физику.
Также рекомендую не замахиваться на реалистичную физику повреждений для ГТА-подобной игры. До сих пор большую популярность имеет GTA SA и моды на неё, а также сервера как оригинальной игры, так и сборок с модами. Естественно, модами невозможно добавить реалистичную физику на древний движок, но это никого и не волнует. Также, насколько я понимаю, пиратские сервера GTA 5 имеют большую популярность по сравнению с пиратскими серверами GTA IV; фактически, люди постепенно перекатываются с GTA SA на GTA 5, а не на GTA IV. Кроме того, я неоднократно читал критику физики автомобилей GTA IV как избыточную фичу, которая только мешает геймплею.
Из всего этого делаем вывод: ГТА ценят не за физику машин, а за свободу в большом городе. Игры типа BeamNG.drive могут иметь сверхреалистичную физику машин, которая будет лагать до неиграбельности на среднестатистическом компьютере, но даже на достаточно мощном компьютере игре типа BeamNG.drive как до луны до уровня даже ванильной GTA SA по геймплейным возможностям. Поэтому люди и пытаются создать клон GTA, а не клон серии FlatOut, в которой кроме гонок и физики повреждений ничего нет.
>>34328
Сколько нужно программистов, чтобы поменять одну лампочку в люстре?
Всё зависит от постановки задачи. Клоны GTA 2 делали в одиночку и получалось неплохо. Клон GTA 3 тоже можно сделать в одиночку, только не будет многоголосой озвучки по понятным причинам (хотя сегодня уже можно выкрутиться нейронками). Геймплейный клон ГТА вообще очень легко сделать, потому что там ничего сложного нет, так что если тебе не нужны графика и сюжет - можешь сделать свою ГТА за несколько месяцев максимум, это если по вечерам растягивать, а так за пару дней можно (без анимаций персонажей и всей остальной мишуры, только геймплей). Другое дело, если ты пытаешься внедрить в ГТА какие-то сложные с программной точки зрения механики - тогда да, сложно будет. Более того, для простой ГТА-подобной игры есть наборы ассетов, т.е. многое даже не нужно с нуля делать, если тебя устраивает визуальный стиль ассетов.
А вот когда говорят "хочу сделать убийцу ГТА 6", подразумевая при этом уровень графики, сюжета, озвучки и прочего контента - тут ты прав, в одиночку такое будешь делать десятки лет и не успеешь доделать до смерти от старости, если не использовать готовые ассеты. Но на практике всё это не нужно для хорошей ГТА-подобной игры, даже выходить из машины не нужно (серия игр Driver тому пример - ГТА-лайк без возможности выйти из машины).
>Есть реализации повреждений основанная на soft body у годота из коробки?
Нет и никогда не будет. Потому что такая система имеет очень узкоспециальное применение и требует сложной настройки для каждой конкретной ситуации. Следовательно, при создании серьёзной игры будет лучше написать свою систему с нуля, чем использовать какое-либо встроенное решение.
Но я видел минимум один платный аддон, реализующий физику повреждений машин.
>Как безигорные гта будут создавать?
Годо - универсальный движок для любых игр, поэтому у него нет и не будет узкоспециальных инструментов, которые сложно адаптировать для множества разных игр. Если хочешь по-быстрому сделать что-то вроде ГТА, тогда ищи конструктор игр типа ГТА или готовый набор ассетов для игр типа ГТА на какой-либо универсальный движок; сам по себе универсальный движок тут не поможет, он слишком низкоуровневый по определению (конструкторы - высокоуровневые, движки - низкоуровневые, но всё это очень относительно, конечно).
Ты же в курсе, что даже в рамках серии ГТА физика машин значительно изменялась? Пусть GTA SA была логичным развитием движка GTA 3 и VS, но вот разница между GTA SA, IV и V очень большая.
1. В GTA SA простая физика, только имитирующая повреждения путём замены мешей неповреждённых деталей на меши, выглядящие повреждёнными.
2. В GTA IV попытались реализовать честную симуляцию, которая позволяет сминать машины всмятку по любому направлению, если приложить достаточно усилий или времени (лично экспериментировал).
3. Но в GTA V от этой системы отказались, вернувшись к весьма примитивным повреждениям, а в GTA Online новые машины из регулярно выходящих DLC вообще никак не мнутся, у них только отваливаются некоторые части и всё.
Всё это разнообразие невозможно упаковать в один маленький игровой движок... да и некому этим заниматься - у Годо малое количество разработчиков и инвестиции идут в основном в 2D и рендер, а не в 3D физику.
Также рекомендую не замахиваться на реалистичную физику повреждений для ГТА-подобной игры. До сих пор большую популярность имеет GTA SA и моды на неё, а также сервера как оригинальной игры, так и сборок с модами. Естественно, модами невозможно добавить реалистичную физику на древний движок, но это никого и не волнует. Также, насколько я понимаю, пиратские сервера GTA 5 имеют большую популярность по сравнению с пиратскими серверами GTA IV; фактически, люди постепенно перекатываются с GTA SA на GTA 5, а не на GTA IV. Кроме того, я неоднократно читал критику физики автомобилей GTA IV как избыточную фичу, которая только мешает геймплею.
Из всего этого делаем вывод: ГТА ценят не за физику машин, а за свободу в большом городе. Игры типа BeamNG.drive могут иметь сверхреалистичную физику машин, которая будет лагать до неиграбельности на среднестатистическом компьютере, но даже на достаточно мощном компьютере игре типа BeamNG.drive как до луны до уровня даже ванильной GTA SA по геймплейным возможностям. Поэтому люди и пытаются создать клон GTA, а не клон серии FlatOut, в которой кроме гонок и физики повреждений ничего нет.
>>34328
>Проблема создания ГТА не в инструментах, а в количестве разрабов.
Сколько нужно программистов, чтобы поменять одну лампочку в люстре?
>Безыгорный в одно рыло ГТА не запилит.
Всё зависит от постановки задачи. Клоны GTA 2 делали в одиночку и получалось неплохо. Клон GTA 3 тоже можно сделать в одиночку, только не будет многоголосой озвучки по понятным причинам (хотя сегодня уже можно выкрутиться нейронками). Геймплейный клон ГТА вообще очень легко сделать, потому что там ничего сложного нет, так что если тебе не нужны графика и сюжет - можешь сделать свою ГТА за несколько месяцев максимум, это если по вечерам растягивать, а так за пару дней можно (без анимаций персонажей и всей остальной мишуры, только геймплей). Другое дело, если ты пытаешься внедрить в ГТА какие-то сложные с программной точки зрения механики - тогда да, сложно будет. Более того, для простой ГТА-подобной игры есть наборы ассетов, т.е. многое даже не нужно с нуля делать, если тебя устраивает визуальный стиль ассетов.
А вот когда говорят "хочу сделать убийцу ГТА 6", подразумевая при этом уровень графики, сюжета, озвучки и прочего контента - тут ты прав, в одиночку такое будешь делать десятки лет и не успеешь доделать до смерти от старости, если не использовать готовые ассеты. Но на практике всё это не нужно для хорошей ГТА-подобной игры, даже выходить из машины не нужно (серия игр Driver тому пример - ГТА-лайк без возможности выйти из машины).
>>34326
Нет и никогда не будет. Потому что такая система имеет очень узкоспециальное применение и требует сложной настройки для каждой конкретной ситуации. Следовательно, при создании серьёзной игры будет лучше написать свою систему с нуля, чем использовать какое-либо встроенное решение.
Но я видел минимум один платный аддон, реализующий физику повреждений машин.
Годо - универсальный движок для любых игр, поэтому у него нет и не будет узкоспециальных инструментов, которые сложно адаптировать для множества разных игр. Если хочешь по-быстрому сделать что-то вроде ГТА, тогда ищи конструктор игр типа ГТА или готовый набор ассетов для игр типа ГТА на какой-либо универсальный движок; сам по себе универсальный движок тут не поможет, он слишком низкоуровневый по определению (конструкторы - высокоуровневые, движки - низкоуровневые, но всё это очень относительно, конечно).
Ты же в курсе, что даже в рамках серии ГТА физика машин значительно изменялась? Пусть GTA SA была логичным развитием движка GTA 3 и VS, но вот разница между GTA SA, IV и V очень большая.
1. В GTA SA простая физика, только имитирующая повреждения путём замены мешей неповреждённых деталей на меши, выглядящие повреждёнными.
2. В GTA IV попытались реализовать честную симуляцию, которая позволяет сминать машины всмятку по любому направлению, если приложить достаточно усилий или времени (лично экспериментировал).
3. Но в GTA V от этой системы отказались, вернувшись к весьма примитивным повреждениям, а в GTA Online новые машины из регулярно выходящих DLC вообще никак не мнутся, у них только отваливаются некоторые части и всё.
Всё это разнообразие невозможно упаковать в один маленький игровой движок... да и некому этим заниматься - у Годо малое количество разработчиков и инвестиции идут в основном в 2D и рендер, а не в 3D физику.
Также рекомендую не замахиваться на реалистичную физику повреждений для ГТА-подобной игры. До сих пор большую популярность имеет GTA SA и моды на неё, а также сервера как оригинальной игры, так и сборок с модами. Естественно, модами невозможно добавить реалистичную физику на древний движок, но это никого и не волнует. Также, насколько я понимаю, пиратские сервера GTA 5 имеют большую популярность по сравнению с пиратскими серверами GTA IV; фактически, люди постепенно перекатываются с GTA SA на GTA 5, а не на GTA IV. Кроме того, я неоднократно читал критику физики автомобилей GTA IV как избыточную фичу, которая только мешает геймплею.
Из всего этого делаем вывод: ГТА ценят не за физику машин, а за свободу в большом городе. Игры типа BeamNG.drive могут иметь сверхреалистичную физику машин, которая будет лагать до неиграбельности на среднестатистическом компьютере, но даже на достаточно мощном компьютере игре типа BeamNG.drive как до луны до уровня даже ванильной GTA SA по геймплейным возможностям. Поэтому люди и пытаются создать клон GTA, а не клон серии FlatOut, в которой кроме гонок и физики повреждений ничего нет.
>>34328
Сколько нужно программистов, чтобы поменять одну лампочку в люстре?
Всё зависит от постановки задачи. Клоны GTA 2 делали в одиночку и получалось неплохо. Клон GTA 3 тоже можно сделать в одиночку, только не будет многоголосой озвучки по понятным причинам (хотя сегодня уже можно выкрутиться нейронками). Геймплейный клон ГТА вообще очень легко сделать, потому что там ничего сложного нет, так что если тебе не нужны графика и сюжет - можешь сделать свою ГТА за несколько месяцев максимум, это если по вечерам растягивать, а так за пару дней можно (без анимаций персонажей и всей остальной мишуры, только геймплей). Другое дело, если ты пытаешься внедрить в ГТА какие-то сложные с программной точки зрения механики - тогда да, сложно будет. Более того, для простой ГТА-подобной игры есть наборы ассетов, т.е. многое даже не нужно с нуля делать, если тебя устраивает визуальный стиль ассетов.
А вот когда говорят "хочу сделать убийцу ГТА 6", подразумевая при этом уровень графики, сюжета, озвучки и прочего контента - тут ты прав, в одиночку такое будешь делать десятки лет и не успеешь доделать до смерти от старости, если не использовать готовые ассеты. Но на практике всё это не нужно для хорошей ГТА-подобной игры, даже выходить из машины не нужно (серия игр Driver тому пример - ГТА-лайк без возможности выйти из машины).
>Есть реализации повреждений основанная на soft body у годота из коробки?
Нет и никогда не будет. Потому что такая система имеет очень узкоспециальное применение и требует сложной настройки для каждой конкретной ситуации. Следовательно, при создании серьёзной игры будет лучше написать свою систему с нуля, чем использовать какое-либо встроенное решение.
Но я видел минимум один платный аддон, реализующий физику повреждений машин.
>Как безигорные гта будут создавать?
Годо - универсальный движок для любых игр, поэтому у него нет и не будет узкоспециальных инструментов, которые сложно адаптировать для множества разных игр. Если хочешь по-быстрому сделать что-то вроде ГТА, тогда ищи конструктор игр типа ГТА или готовый набор ассетов для игр типа ГТА на какой-либо универсальный движок; сам по себе универсальный движок тут не поможет, он слишком низкоуровневый по определению (конструкторы - высокоуровневые, движки - низкоуровневые, но всё это очень относительно, конечно).
Ты же в курсе, что даже в рамках серии ГТА физика машин значительно изменялась? Пусть GTA SA была логичным развитием движка GTA 3 и VS, но вот разница между GTA SA, IV и V очень большая.
1. В GTA SA простая физика, только имитирующая повреждения путём замены мешей неповреждённых деталей на меши, выглядящие повреждёнными.
2. В GTA IV попытались реализовать честную симуляцию, которая позволяет сминать машины всмятку по любому направлению, если приложить достаточно усилий или времени (лично экспериментировал).
3. Но в GTA V от этой системы отказались, вернувшись к весьма примитивным повреждениям, а в GTA Online новые машины из регулярно выходящих DLC вообще никак не мнутся, у них только отваливаются некоторые части и всё.
Всё это разнообразие невозможно упаковать в один маленький игровой движок... да и некому этим заниматься - у Годо малое количество разработчиков и инвестиции идут в основном в 2D и рендер, а не в 3D физику.
Также рекомендую не замахиваться на реалистичную физику повреждений для ГТА-подобной игры. До сих пор большую популярность имеет GTA SA и моды на неё, а также сервера как оригинальной игры, так и сборок с модами. Естественно, модами невозможно добавить реалистичную физику на древний движок, но это никого и не волнует. Также, насколько я понимаю, пиратские сервера GTA 5 имеют большую популярность по сравнению с пиратскими серверами GTA IV; фактически, люди постепенно перекатываются с GTA SA на GTA 5, а не на GTA IV. Кроме того, я неоднократно читал критику физики автомобилей GTA IV как избыточную фичу, которая только мешает геймплею.
Из всего этого делаем вывод: ГТА ценят не за физику машин, а за свободу в большом городе. Игры типа BeamNG.drive могут иметь сверхреалистичную физику машин, которая будет лагать до неиграбельности на среднестатистическом компьютере, но даже на достаточно мощном компьютере игре типа BeamNG.drive как до луны до уровня даже ванильной GTA SA по геймплейным возможностям. Поэтому люди и пытаются создать клон GTA, а не клон серии FlatOut, в которой кроме гонок и физики повреждений ничего нет.
>>34328
>Проблема создания ГТА не в инструментах, а в количестве разрабов.
Сколько нужно программистов, чтобы поменять одну лампочку в люстре?
>Безыгорный в одно рыло ГТА не запилит.
Всё зависит от постановки задачи. Клоны GTA 2 делали в одиночку и получалось неплохо. Клон GTA 3 тоже можно сделать в одиночку, только не будет многоголосой озвучки по понятным причинам (хотя сегодня уже можно выкрутиться нейронками). Геймплейный клон ГТА вообще очень легко сделать, потому что там ничего сложного нет, так что если тебе не нужны графика и сюжет - можешь сделать свою ГТА за несколько месяцев максимум, это если по вечерам растягивать, а так за пару дней можно (без анимаций персонажей и всей остальной мишуры, только геймплей). Другое дело, если ты пытаешься внедрить в ГТА какие-то сложные с программной точки зрения механики - тогда да, сложно будет. Более того, для простой ГТА-подобной игры есть наборы ассетов, т.е. многое даже не нужно с нуля делать, если тебя устраивает визуальный стиль ассетов.
А вот когда говорят "хочу сделать убийцу ГТА 6", подразумевая при этом уровень графики, сюжета, озвучки и прочего контента - тут ты прав, в одиночку такое будешь делать десятки лет и не успеешь доделать до смерти от старости, если не использовать готовые ассеты. Но на практике всё это не нужно для хорошей ГТА-подобной игры, даже выходить из машины не нужно (серия игр Driver тому пример - ГТА-лайк без возможности выйти из машины).
>>34420
Мда, начал с того, что в ГТА богатый геймплей, а закончил тем, что геймплей ГТА простой...
Ну, у жанра ГТА-лайк нет чётких рамок, так что какая разница...
Мда, начал с того, что в ГТА богатый геймплей, а закончил тем, что геймплей ГТА простой...
Ну, у жанра ГТА-лайк нет чётких рамок, так что какая разница...
Готодотеры, привет.
Интересно, как вообще годот подходит для разработки 2д(пока что ожидаемо) пес очницы.
Игра разрабатывается для себя ради развлечения, без прицела на бабло(хотя если окажется, что можно заработать, я не буду сидеть и жопу чесать).
В данный момент, это происходит на ренпае, т.к. я со стажем в питоне, ренпай привичен, я уже видел проекты внутри него и потому что он в целом отвечает моим запросам.
Но я рассматриваю альтернативы, не исключая возможность свитча. Годот в первую очередь. Было бы неплохо узнать ещё, как быстро осваивается блендер для соотв целей + моделлинга персонажей(пока что пейпердоллов генерю в качестве заглушек) с учётом того, что я работаю, а не имею круглые сутки свободного времени.
감사합니다.
Интересно, как вообще годот подходит для разработки 2д(пока что ожидаемо) пес очницы.
Игра разрабатывается для себя ради развлечения, без прицела на бабло(хотя если окажется, что можно заработать, я не буду сидеть и жопу чесать).
В данный момент, это происходит на ренпае, т.к. я со стажем в питоне, ренпай привичен, я уже видел проекты внутри него и потому что он в целом отвечает моим запросам.
Но я рассматриваю альтернативы, не исключая возможность свитча. Годот в первую очередь. Было бы неплохо узнать ещё, как быстро осваивается блендер для соотв целей + моделлинга персонажей(пока что пейпердоллов генерю в качестве заглушек) с учётом того, что я работаю, а не имею круглые сутки свободного времени.
감사합니다.
>>34422
Подходит.
Подходит. Код открыт интегрируй что хочешь. Стим уже интегрирован (не из коробки, но модулем).
Знание питона может помочь вкату в скрепты, заменил def на func - и ты уже знаешь гдскрипт. Теоретически.
Знание ренпу, как я слышал - вредное, развращает криэйторов своим обилием кнопок "сделоть зоебись". Переход с высокоуровневого конструктора на низкоуровневый движок - крутое пике.
По этому вопросу лучше в /тд/ обратиться. Лично у меня проблем с блендером нет. Хуле там осваивать? Экструдь, скейль, экструдь, скейль. А вот художественный вкус мануалы по командам приложения никому еще не привили.
> как вообще годот подходит для разработки 2д(пока что ожидаемо) пес очницы.
Подходит.
> без прицела на бабло(хотя если окажется, что можно заработать, я не буду сидеть и жопу чесать)
Подходит. Код открыт интегрируй что хочешь. Стим уже интегрирован (не из коробки, но модулем).
> это происходит на ренпае, т.к. я со стажем в питоне
Знание питона может помочь вкату в скрепты, заменил def на func - и ты уже знаешь гдскрипт. Теоретически.
Знание ренпу, как я слышал - вредное, развращает криэйторов своим обилием кнопок "сделоть зоебись". Переход с высокоуровневого конструктора на низкоуровневый движок - крутое пике.
> как быстро осваивается блендер для соотв целей
По этому вопросу лучше в /тд/ обратиться. Лично у меня проблем с блендером нет. Хуле там осваивать? Экструдь, скейль, экструдь, скейль. А вот художественный вкус мануалы по командам приложения никому еще не привили.
>>34423
спасибо.
меня визуал очень сильно беспокоит потому что рисовать в классическом смысле -- у меня руки из жопы, никогда кроме чертежей ничего хорошо не рисовал.
насчёт моделей -- тёмный лес, пока не пробовал, потому хотелось бы знать подводные камни. в тд к блендероблядям заглядывал, почитал, понял что они поголовно дрочат на гиперреалистичность и потому будут говорить исходя из этого в качестве конечной цели, а мне очевидно не нужно это, меня практическое приложение интересует, потому мне кажется разумнее о подводных приложения блендера к годоту спрашивать в годот-треде. думаю так ясно почему я не пошёл в тд сразу.
ренпай знаю в очень общих чертах, тк осваиваю когда есть понимание что инструмент мне норм может подойти.
Есть ли какие-либо способы ревёрс-инжиниринга годотовых проектов в годоте? Это затем чтобы находит подсказки в уже мне известных проектах, т.к. мне яснее что да как из "боевого" кода.
БД, ооп, прочее?
спасибо.
меня визуал очень сильно беспокоит потому что рисовать в классическом смысле -- у меня руки из жопы, никогда кроме чертежей ничего хорошо не рисовал.
насчёт моделей -- тёмный лес, пока не пробовал, потому хотелось бы знать подводные камни. в тд к блендероблядям заглядывал, почитал, понял что они поголовно дрочат на гиперреалистичность и потому будут говорить исходя из этого в качестве конечной цели, а мне очевидно не нужно это, меня практическое приложение интересует, потому мне кажется разумнее о подводных приложения блендера к годоту спрашивать в годот-треде. думаю так ясно почему я не пошёл в тд сразу.
ренпай знаю в очень общих чертах, тк осваиваю когда есть понимание что инструмент мне норм может подойти.
Есть ли какие-либо способы ревёрс-инжиниринга годотовых проектов в годоте? Это затем чтобы находит подсказки в уже мне известных проектах, т.к. мне яснее что да как из "боевого" кода.
БД, ооп, прочее?
>>34425
Полностью открыто всё и в текстовых форматах. Хоть обизучайся. Проекты-шаблоны как гласит шапка, доступны прямо из главного окна, скачиваешь и копаешься в ресурсах без задней мысли.
БД - внешними модулями.
ООП - да, есть. Но тебе нужно поймать волну авторов годота, понять их стиль и двигаться вместе с волной. Тогда всё заебись будет. Если волну не поймаешь - будешь изобретать множество тормозных велосипедов.
> Есть ли какие-либо способы ревёрс-инжиниринга годотовых проектов в годоте?
Полностью открыто всё и в текстовых форматах. Хоть обизучайся. Проекты-шаблоны как гласит шапка, доступны прямо из главного окна, скачиваешь и копаешься в ресурсах без задней мысли.
> БД, ооп, прочее?
БД - внешними модулями.
ООП - да, есть. Но тебе нужно поймать волну авторов годота, понять их стиль и двигаться вместе с волной. Тогда всё заебись будет. Если волну не поймаешь - будешь изобретать множество тормозных велосипедов.
>>34426
окей, спасибо. буду курить понемногу маны.
начну с программной части, как пойму что пошло нормально, начну добавлять визуал по плану. как в действительности будет увижу потом.
окей, спасибо. буду курить понемногу маны.
начну с программной части, как пойму что пошло нормально, начну добавлять визуал по плану. как в действительности будет увижу потом.
32 Кб, 740x800>>34427
Давай! Жги!
Давай! Жги!
Сап, двач. Мимо погромист. Хочу вкатиться в говногейдев. Дайте советов.
Есть идея сделать игру в которую бы сам хотел играть и мне писец как хочется не могу себя унять.
Насколько вообще движок подходит для изометрической хуйни?
Есть идея сделать игру в которую бы сам хотел играть и мне писец как хочется не могу себя унять.
Насколько вообще движок подходит для изометрической хуйни?
Контент, годаны! https://www.youtube.com/watch?v=ueUMr92GQJc
>>34442
Подходит.
>>34442
> Насколько вообще движок подходит для изометрической хуйни?
Подходит.
Вопрос: а стоит ли месный тредик держать плотно в курсе процесса освоения годота? Будет очень много субъективщины и тупления.
>>34453
В душе не ебу кто это. Пару дней сижу в гд и вчера только на связь вышел.
В душе не ебу кто это. Пару дней сижу в гд и вчера только на связь вышел.
>>34450
Держи. Анонимус не возражает.
Держи. Анонимус не возражает.
Поясните за сеттеры, геттеры. Не понятен последний случай. Я ожидал, что self.test_var.x = 888 вызовет геттер, который вернет копию значения test_var, и у этой копии изменит x, а сама test_var останется неизменной. Но там что-то непонятное, сперва геттер вызывается, потом сеттер, что происходит?
>>34422
Если ты подразумеваешь нечто вроде Terraria, то в геймдеве принято советовать делать такие игры "без движка" или на минимальном фреймворке (SDL2). Таким играм мало что требуется для работы, но нужно работать с большим количеством сущностей (миллионы квадратиков ландшафта), а универсальный движок обычно всё же накладывает некоторые ограничения (если использовать его "как обычно"). Тем не менее, на Godot, кстати, читается "гОдо" без "т", в принципе, возможно сделать Terraria-подобную игру, но нужно понимать, что разработка такой игры отличается от разработки обычного платформера - потребуются специфические оптимизации - нельзя просто сесть и сделать по туториалам. Ты можешь воспользоваться встроенным TileMap для изменяемого ландшафта, но всё остальное придётся делать и оптимизировать самостоятельно, и есть вероятность, что ты столкнёшься с ограничениями TileMap.
Для песочниц типа The Powder Toy универсальный игровой движок вообще не нужен - такой игре Godot почти ничем не сможет помочь - разве что GUI кнопочки расставить и всё, остальное придётся писать и оптимизировать на C/C++, ибо там реалистичная симуляция физики на уровне отдельных пикселей, игровые физические движки и тайлмапы тут никаким образом не подходят.
Не представляю себе песочницу на Ren'Py, но если у тебя там просто визуальная новелла с возможностью свободно переходить по комнатам - вообще не ясно, с чего у тебя такой вопрос мог возникнуть, т.к. такую игру на любом инструменте можно сделать, хоть набором статичных HTML страничек (если содержимое комнат статично). Однако, зачем тебе для такой игры Godot? Чем он может тебе помочь, если у тебя по сути набор картинок с надписями и ссылками-переходами между ними? Тем более что придётся реализовывать функционал Ren'Py, как верно подметил другой анон. Впрочем, уже есть аддон, реализующий функционал Ren'Py на базе Godot: https://rakugoteam.github.io/
База там простая. Проблема в том, что тебе нужно иметь художественные навыки, чтобы слепить что-то хорошее. Блендер - всего лишь инструмент, а лепить-то тебе. Если ты не можешь вылепить красивую голову с лицом из пластилина или глины, то Блендер тут ничем не поможет. А если не умеешь рисовать в 2D, Блендер не поможет с текстурами (хотя сейчас нейронки развивают и даже есть аддон с нейронкой для Блендера, но там как всегда бредогенерация, которую сложно контролировать - т.е. не для всех задач подойдёт). Можешь попробовать генераторы персонажей типа https://github.com/animate1978/MB-Lab
>годот подходит для разработки 2д песочницы
Если ты подразумеваешь нечто вроде Terraria, то в геймдеве принято советовать делать такие игры "без движка" или на минимальном фреймворке (SDL2). Таким играм мало что требуется для работы, но нужно работать с большим количеством сущностей (миллионы квадратиков ландшафта), а универсальный движок обычно всё же накладывает некоторые ограничения (если использовать его "как обычно"). Тем не менее, на Godot, кстати, читается "гОдо" без "т", в принципе, возможно сделать Terraria-подобную игру, но нужно понимать, что разработка такой игры отличается от разработки обычного платформера - потребуются специфические оптимизации - нельзя просто сесть и сделать по туториалам. Ты можешь воспользоваться встроенным TileMap для изменяемого ландшафта, но всё остальное придётся делать и оптимизировать самостоятельно, и есть вероятность, что ты столкнёшься с ограничениями TileMap.
Для песочниц типа The Powder Toy универсальный игровой движок вообще не нужен - такой игре Godot почти ничем не сможет помочь - разве что GUI кнопочки расставить и всё, остальное придётся писать и оптимизировать на C/C++, ибо там реалистичная симуляция физики на уровне отдельных пикселей, игровые физические движки и тайлмапы тут никаким образом не подходят.
>В данный момент, это происходит на ренпае, т.к. я со стажем в питоне
Не представляю себе песочницу на Ren'Py, но если у тебя там просто визуальная новелла с возможностью свободно переходить по комнатам - вообще не ясно, с чего у тебя такой вопрос мог возникнуть, т.к. такую игру на любом инструменте можно сделать, хоть набором статичных HTML страничек (если содержимое комнат статично). Однако, зачем тебе для такой игры Godot? Чем он может тебе помочь, если у тебя по сути набор картинок с надписями и ссылками-переходами между ними? Тем более что придётся реализовывать функционал Ren'Py, как верно подметил другой анон. Впрочем, уже есть аддон, реализующий функционал Ren'Py на базе Godot: https://rakugoteam.github.io/
>как быстро осваивается блендер для соотв целей + моделлинга персонажей
База там простая. Проблема в том, что тебе нужно иметь художественные навыки, чтобы слепить что-то хорошее. Блендер - всего лишь инструмент, а лепить-то тебе. Если ты не можешь вылепить красивую голову с лицом из пластилина или глины, то Блендер тут ничем не поможет. А если не умеешь рисовать в 2D, Блендер не поможет с текстурами (хотя сейчас нейронки развивают и даже есть аддон с нейронкой для Блендера, но там как всегда бредогенерация, которую сложно контролировать - т.е. не для всех задач подойдёт). Можешь попробовать генераторы персонажей типа https://github.com/animate1978/MB-Lab
>>34422
Если ты подразумеваешь нечто вроде Terraria, то в геймдеве принято советовать делать такие игры "без движка" или на минимальном фреймворке (SDL2). Таким играм мало что требуется для работы, но нужно работать с большим количеством сущностей (миллионы квадратиков ландшафта), а универсальный движок обычно всё же накладывает некоторые ограничения (если использовать его "как обычно"). Тем не менее, на Godot, кстати, читается "гОдо" без "т", в принципе, возможно сделать Terraria-подобную игру, но нужно понимать, что разработка такой игры отличается от разработки обычного платформера - потребуются специфические оптимизации - нельзя просто сесть и сделать по туториалам. Ты можешь воспользоваться встроенным TileMap для изменяемого ландшафта, но всё остальное придётся делать и оптимизировать самостоятельно, и есть вероятность, что ты столкнёшься с ограничениями TileMap.
Для песочниц типа The Powder Toy универсальный игровой движок вообще не нужен - такой игре Godot почти ничем не сможет помочь - разве что GUI кнопочки расставить и всё, остальное придётся писать и оптимизировать на C/C++, ибо там реалистичная симуляция физики на уровне отдельных пикселей, игровые физические движки и тайлмапы тут никаким образом не подходят.
Не представляю себе песочницу на Ren'Py, но если у тебя там просто визуальная новелла с возможностью свободно переходить по комнатам - вообще не ясно, с чего у тебя такой вопрос мог возникнуть, т.к. такую игру на любом инструменте можно сделать, хоть набором статичных HTML страничек (если содержимое комнат статично). Однако, зачем тебе для такой игры Godot? Чем он может тебе помочь, если у тебя по сути набор картинок с надписями и ссылками-переходами между ними? Тем более что придётся реализовывать функционал Ren'Py, как верно подметил другой анон. Впрочем, уже есть аддон, реализующий функционал Ren'Py на базе Godot: https://rakugoteam.github.io/
База там простая. Проблема в том, что тебе нужно иметь художественные навыки, чтобы слепить что-то хорошее. Блендер - всего лишь инструмент, а лепить-то тебе. Если ты не можешь вылепить красивую голову с лицом из пластилина или глины, то Блендер тут ничем не поможет. А если не умеешь рисовать в 2D, Блендер не поможет с текстурами (хотя сейчас нейронки развивают и даже есть аддон с нейронкой для Блендера, но там как всегда бредогенерация, которую сложно контролировать - т.е. не для всех задач подойдёт). Можешь попробовать генераторы персонажей типа https://github.com/animate1978/MB-Lab
>годот подходит для разработки 2д песочницы
Если ты подразумеваешь нечто вроде Terraria, то в геймдеве принято советовать делать такие игры "без движка" или на минимальном фреймворке (SDL2). Таким играм мало что требуется для работы, но нужно работать с большим количеством сущностей (миллионы квадратиков ландшафта), а универсальный движок обычно всё же накладывает некоторые ограничения (если использовать его "как обычно"). Тем не менее, на Godot, кстати, читается "гОдо" без "т", в принципе, возможно сделать Terraria-подобную игру, но нужно понимать, что разработка такой игры отличается от разработки обычного платформера - потребуются специфические оптимизации - нельзя просто сесть и сделать по туториалам. Ты можешь воспользоваться встроенным TileMap для изменяемого ландшафта, но всё остальное придётся делать и оптимизировать самостоятельно, и есть вероятность, что ты столкнёшься с ограничениями TileMap.
Для песочниц типа The Powder Toy универсальный игровой движок вообще не нужен - такой игре Godot почти ничем не сможет помочь - разве что GUI кнопочки расставить и всё, остальное придётся писать и оптимизировать на C/C++, ибо там реалистичная симуляция физики на уровне отдельных пикселей, игровые физические движки и тайлмапы тут никаким образом не подходят.
>В данный момент, это происходит на ренпае, т.к. я со стажем в питоне
Не представляю себе песочницу на Ren'Py, но если у тебя там просто визуальная новелла с возможностью свободно переходить по комнатам - вообще не ясно, с чего у тебя такой вопрос мог возникнуть, т.к. такую игру на любом инструменте можно сделать, хоть набором статичных HTML страничек (если содержимое комнат статично). Однако, зачем тебе для такой игры Godot? Чем он может тебе помочь, если у тебя по сути набор картинок с надписями и ссылками-переходами между ними? Тем более что придётся реализовывать функционал Ren'Py, как верно подметил другой анон. Впрочем, уже есть аддон, реализующий функционал Ren'Py на базе Godot: https://rakugoteam.github.io/
>как быстро осваивается блендер для соотв целей + моделлинга персонажей
База там простая. Проблема в том, что тебе нужно иметь художественные навыки, чтобы слепить что-то хорошее. Блендер - всего лишь инструмент, а лепить-то тебе. Если ты не можешь вылепить красивую голову с лицом из пластилина или глины, то Блендер тут ничем не поможет. А если не умеешь рисовать в 2D, Блендер не поможет с текстурами (хотя сейчас нейронки развивают и даже есть аддон с нейронкой для Блендера, но там как всегда бредогенерация, которую сложно контролировать - т.е. не для всех задач подойдёт). Можешь попробовать генераторы персонажей типа https://github.com/animate1978/MB-Lab
62 Кб, 720x437>>34423
Тем не менее, это намного лучше, чем осваивать низкоуровневый движок с нуля или писать свой собственный движок без опыта в геймдеве. Так что я бы советовал начинать погружение в геймдев с любого простого конструктора игр -> потом перейти на готовый движок для расширения своих возможностей -> после понимания движка при необходимости собрать себе движок из низкоуровневых библиотек -> при необходимости переписать эти библиотеки с нуля под свои задачи. Начинать что-то делать без общих знаний сложно, а умение обращаться с низкоуровневыми инструментами не даёт тебе общих знаний. Грубо говоря, ты не построишь дом, научившись только стучать молотком по гвоздям, а архитектору не обязательно уметь самому забивать гвозди; так вот от инди требуется в первую очередь быть архитектором, а уже во вторую - владеть какими-то инструментами.
>Переход с высокоуровневого конструктора на низкоуровневый движок - крутое пике.
Тем не менее, это намного лучше, чем осваивать низкоуровневый движок с нуля или писать свой собственный движок без опыта в геймдеве. Так что я бы советовал начинать погружение в геймдев с любого простого конструктора игр -> потом перейти на готовый движок для расширения своих возможностей -> после понимания движка при необходимости собрать себе движок из низкоуровневых библиотек -> при необходимости переписать эти библиотеки с нуля под свои задачи. Начинать что-то делать без общих знаний сложно, а умение обращаться с низкоуровневыми инструментами не даёт тебе общих знаний. Грубо говоря, ты не построишь дом, научившись только стучать молотком по гвоздям, а архитектору не обязательно уметь самому забивать гвозди; так вот от инди требуется в первую очередь быть архитектором, а уже во вторую - владеть какими-то инструментами.
>>34472
Лол, почему? С чего ей оставаться неизменной-то?
Если бы происходило то, что ты описываешь, то выражение self.test_var.x = 888 не имело бы никакого смысла - присвоив значение полю x некоего вектора ты теряешь этот новый вектор, потому что он у тебя нигде не сохраняется. Так что эта часть сделана логично - не нужно писать лишний код по типу такого:
Т.е. GDScript в данной ситуации сильно упрощает типичную операцию, избавляя от необходимости создавать промежуточную переменную. А если тебе нужно зачем-то сделать то, что ты описываешь - заведи отдельную переменную. Только я не вижу в этом смысла, зачем менять что-то и затем выбрасывать это, никак не использовав?
А меня вот в этом контексте в GDScript бесит то, что нужно писать self.поле для реального использования сеттеров и геттеров в рамках скрипта, в котором они объявлены. Если просто обратиться к полю, произойдёт прямая запись/чтение, и я считаю это некорректным поведением. Прямые обращения к полю с объявленными сеттером и геттером должны происходить только в его сеттере и геттере... Алсо очень не хватает свойств, имеющих массивообразный интерфейс как в Delphi/FPC:
Чтобы можно было создавать "фейковый" массив произвольной размерности, который внутри сеттеров и геттеров преобразуется в более оптимальную структуру. Пример - вместо массива массивов один массив, а в сеттере и геттере вычисление индекса. Конечно, можно сделать то же самое прямым обращением к сеттеру и геттеру, но это не так красиво выглядит, как специальное поле с прямоугольными скобками...
>Я ожидал, что self.test_var.x = 888 вызовет геттер, который вернет копию значения test_var, и у этой копии изменит x, а сама test_var останется неизменной.
>останется неизменной
Лол, почему? С чего ей оставаться неизменной-то?
Если бы происходило то, что ты описываешь, то выражение self.test_var.x = 888 не имело бы никакого смысла - присвоив значение полю x некоего вектора ты теряешь этот новый вектор, потому что он у тебя нигде не сохраняется. Так что эта часть сделана логично - не нужно писать лишний код по типу такого:
>var buffer := self.test_var
>buffer.x = 888
>self.test_var = buffer
Т.е. GDScript в данной ситуации сильно упрощает типичную операцию, избавляя от необходимости создавать промежуточную переменную. А если тебе нужно зачем-то сделать то, что ты описываешь - заведи отдельную переменную. Только я не вижу в этом смысла, зачем менять что-то и затем выбрасывать это, никак не использовав?
А меня вот в этом контексте в GDScript бесит то, что нужно писать self.поле для реального использования сеттеров и геттеров в рамках скрипта, в котором они объявлены. Если просто обратиться к полю, произойдёт прямая запись/чтение, и я считаю это некорректным поведением. Прямые обращения к полю с объявленными сеттером и геттером должны происходить только в его сеттере и геттере... Алсо очень не хватает свойств, имеющих массивообразный интерфейс как в Delphi/FPC:
>property Items [i: Integer]: Integer read GetItem write SetItem;
Чтобы можно было создавать "фейковый" массив произвольной размерности, который внутри сеттеров и геттеров преобразуется в более оптимальную структуру. Пример - вместо массива массивов один массив, а в сеттере и геттере вычисление индекса. Конечно, можно сделать то же самое прямым обращением к сеттеру и геттеру, но это не так красиво выглядит, как специальное поле с прямоугольными скобками...
>>34479
Золотые слова!
Золотые слова!
82 Кб, 1888x956>>34477
1. Нет. Хоть люблю и уважаю игру эту.
2. Песочница -- слишком общее название жанра, потому гадать особо смысла нет.
У меня больше симуляция повседневной жизни изменёнными условиями мира. Чисто для своего развлечения. Я очень много чего напланировал и слабо представляю, как всё реализую.
Песочница очень напоминает внешними аттрибутами интерфейса вн и потому ренпай вполне подходит.
Очевидно же. Я не имея опыта игродела, предполагаю, что ренпай может быть не таким хорошим вариантом как кажется.
>>34479
О, спасибо. Ну, как бы я готов если что, к тому что придётся много ебаться. Это неминуемо. Сравнение с архитектором отлично работает для меня, я инженер практикующий. Проблема однако в другом: нужно понимать, как делается что-то и на уровне петровича, чтобы выполнять хорошо свою работу. В твоём описании ренпай и есть инструмент архитектора, хотя в этом случае скорее наоборот: тот, кто использует годот, должен понимать, как пишется на ренпае.
> Если ты подразумеваешь нечто вроде Terraria
1. Нет. Хоть люблю и уважаю игру эту.
2. Песочница -- слишком общее название жанра, потому гадать особо смысла нет.
У меня больше симуляция повседневной жизни изменёнными условиями мира. Чисто для своего развлечения. Я очень много чего напланировал и слабо представляю, как всё реализую.
Песочница очень напоминает внешними аттрибутами интерфейса вн и потому ренпай вполне подходит.
> не ясно, с чего у тебя такой вопрос мог возникнуть
Очевидно же. Я не имея опыта игродела, предполагаю, что ренпай может быть не таким хорошим вариантом как кажется.
>>34479
> Тем не менее, это намного лучше, чем осваивать низкоуровневый движок с нуля или писать свой собственный движок без опыта в геймдеве. Так что я бы советовал начинать погружение в геймдев с любого простого конструктора игр -> потом перейти на готовый движок для расширения своих возможностей -> после понимания движка при необходимости собрать себе движок из низкоуровневых библиотек -> при необходимости переписать эти библиотеки с нуля под свои задачи. Начинать что-то делать без общих знаний сложно, а умение обращаться с низкоуровневыми инструментами не даёт тебе общих знаний. Грубо говоря, ты не построишь дом, научившись только стучать молотком по гвоздям, а архитектору не обязательно уметь самому забивать гвозди; так вот от инди требуется в первую очередь быть архитектором, а уже во вторую - владеть какими-то инструментами.
О, спасибо. Ну, как бы я готов если что, к тому что придётся много ебаться. Это неминуемо. Сравнение с архитектором отлично работает для меня, я инженер практикующий. Проблема однако в другом: нужно понимать, как делается что-то и на уровне петровича, чтобы выполнять хорошо свою работу. В твоём описании ренпай и есть инструмент архитектора, хотя в этом случае скорее наоборот: тот, кто использует годот, должен понимать, как пишется на ренпае.
9 Кб, 377x99>>34482
В юнити именно так и делается.
Значит self.test_var.x = 111 это типа сахар для такого set_test_var(Vector2(111, get_test_var().y)
>var buffer := self.test_var
>buffer.x = 888
>self.test_var = buffer
В юнити именно так и делается.
Значит self.test_var.x = 111 это типа сахар для такого set_test_var(Vector2(111, get_test_var().y)
>>34482
Вполне красиво. Если не нравится get_cell(x,y) set_cell(x, y, value) то тут только пилить специальный объект, у которого будут поля x и y с сеттерами и геттерами, и поле cells типа массива, но всё равно квадратных скобочек не будет. Так что да, для любителей квадратных скобочек всё печально.
> очень не хватает свойств, имеющих массивообразный интерфейс
> Чтобы можно было создавать "фейковый" массив произвольной размерности, который внутри сеттеров и геттеров
> Пример - вместо массива массивов один массив, а в сеттере и геттере вычисление индекса. Конечно, можно сделать то же самое прямым обращением к сеттеру и геттеру, но это не так красиво выглядит, как специальное поле с прямоугольными скобками...
Вполне красиво. Если не нравится get_cell(x,y) set_cell(x, y, value) то тут только пилить специальный объект, у которого будут поля x и y с сеттерами и геттерами, и поле cells типа массива, но всё равно квадратных скобочек не будет. Так что да, для любителей квадратных скобочек всё печально.
>>34493
Вот накидал по быстрому, что я имел ввиду, на примере встроенного класса, но его можно и в отдельном файле сделать, дать ему класснейм и юзать везде. Да, получается совсем не то пальто, не дедовское. Две строки вместо одной. Первая - выставить "курсор", вторая - поработать со значением. Ну и в примере я проверки на границы массива не делал, очевидно, что их сделать надо.
Вот накидал по быстрому, что я имел ввиду, на примере встроенного класса, но его можно и в отдельном файле сделать, дать ему класснейм и юзать везде. Да, получается совсем не то пальто, не дедовское. Две строки вместо одной. Первая - выставить "курсор", вторая - поработать со значением. Ну и в примере я проверки на границы массива не делал, очевидно, что их сделать надо.
>>34492
Пойди изучи матчасть по объектам, и мутабельности. А то так и будут у тебя на экране какая-то магия твориться.
Пойди изучи матчасть по объектам, и мутабельности. А то так и будут у тебя на экране какая-то магия твориться.
>>34492
Так у тебя тут другое написано. Таким кодом ты явно создаешь копию значения, а не обращаешься по ссылке.
Так у тебя тут другое написано. Таким кодом ты явно создаешь копию значения, а не обращаешься по ссылке.
>>34509
Я даже ХЗ как на это ответить. Давай начнём сначала. Вектор это одномерный массив, так он назывался в старом си.
[0, 1, 2, 3, 4, 5] - это вектор.
[0,0] - это тоже вектор.
Но у такого короткого вектора, для удобства, нулевой элемент доступен через геттер X, а первый элемент доступен через геттер Y
На этом этапе всё ясно?
Ты создаёшь новый геттер, который принимает уже не число, а массив (вектор!), и внутри геттера ты должен написать соответствующий код.
Я даже ХЗ как на это ответить. Давай начнём сначала. Вектор это одномерный массив, так он назывался в старом си.
[0, 1, 2, 3, 4, 5] - это вектор.
[0,0] - это тоже вектор.
Но у такого короткого вектора, для удобства, нулевой элемент доступен через геттер X, а первый элемент доступен через геттер Y
На этом этапе всё ясно?
Ты создаёшь новый геттер, который принимает уже не число, а массив (вектор!), и внутри геттера ты должен написать соответствующий код.
>>34510
Ля кокая магия!
Ля кокая магия!
>>34510
При чем здесь сишные массивы? В gdscript вектор это же встроенный тип данных, который передается и возвращается по значению, то есть копируется. Массивы вроде в gdscript по ссылке передаются.
При чем здесь сишные массивы? В gdscript вектор это же встроенный тип данных, который передается и возвращается по значению, то есть копируется. Массивы вроде в gdscript по ссылке передаются.
Вот, перепроверил, C# подобную конструкцию даже не компилирует, требует использовать временную переменную. Ну а gdscript видимо в нечто такое эту строчку и разворачивает по капотом.
Играю в Dome Keeper
В игре серьёзные косяки с переключением окно/фулскрин.
В остальном всё отлично.
Игры на годоте теперь есть.
В игре серьёзные косяки с переключением окно/фулскрин.
В остальном всё отлично.
Игры на годоте теперь есть.
>>34565
Ещё раз.
Вектор - это массив. Ты объявил его как структ, это означает, что ты даже не попытался понять предыдущий пост. Вектор это массив. Сколько ещё раз тебе повторить? Вектор это массив. Вектор это массив. Массив. Массив. Массив. Пойми уже наконец.
Ещё раз.
Вектор - это массив. Ты объявил его как структ, это означает, что ты даже не попытался понять предыдущий пост. Вектор это массив. Сколько ещё раз тебе повторить? Вектор это массив. Вектор это массив. Массив. Массив. Массив. Пойми уже наконец.
>>34486
Так это вообще не жанр. Игра-песочница может быть в самых разных жанрах. Отличие песочниц в большой свободе действий игрока, отсутствии принудительных "коридоров" в левел-дизайне и сюжете, или даже полное отсутствие сюжета как такового: вот тебе песок, совок, ведёрко и другие игрушки, а дальше делай что хочешь. Но когда сегодня говорят "2D песочница", обычно подразумевают что-то вроде Террарии - огромный, зачастую бесшовный мир из тайлов с видом сбоку (платформер) или сверху (топ-даун), на который можно по-разному воздействовать, контролируя одного или более персонажей, которые по этому миру физически перемещаются, обычно в реальном времени, т.е. вместе с мобами. Иногда персонажа нет совсем, игрок управляет абстрактной "рукой бога" и меняет мир под свои желания, как в The Powder Toy, но суть игры остаётся плюс-минус похожей.
Визуальные новеллы, по-моему, не относят к 2D играм, потому что их прямые предки были чисто текстовыми, а предки их предков были бумажными книгами. Чисто технически, визуальная новелла может иметь только 3D графику реального времени, оставаясь при этом прямым наследником классических интерактивных книг из бумаги. Под "2D играми" обычно подразумевают игры, суть которых заключается конкретно в графике, а не в интерактивном тексте. Из визуальной новеллы обычно можно выкинуть все иллюстрации и она мало что потеряет, т.к. её основа - в тексте, а из 2D игры графику не выкинуть (ASCII-графика всё ещё графика). Так что не стоит называть игру "2D песочницей", если она по сути является визуальной новеллой (интерактивной книгой или текстовой игрой с большим количеством иллюстраций) с расширенной свободой действий игрока. А то игрок может сформировать ложные ожидания и разочароваться. Или могут дать неправильные советы по разработке...
Понятно. Что-то последнее время очень много желающих сделать свой симулятор жизни. За последнее время здесь кроме тебя было ещё двое или трое, кто собирался сделать симулятор жизни с иллюстрациями в стиле визуальных новелл или пойнт-н-клик квестов, некоторые из них вроде на Godot пытались это делать, но все куда-то делись без прощаний. Я тоже хочу сделать симулятор жизни, но в 3D и реальном времени; хотя были мысли и о текстовой игре, но меня слабо привлекают текстовые игры (хотя я понимаю, что основа симуляции может быть почти такой же). Тоже делаю "для себя", но мотивации не хватает и задумки все слишком абстрактные, не знаю, как и что реализовать, бросаюсь от одного к другому и забрасываю на долгое время... Хочется сделать виртуального человечка, чтоб не чувствовать себя одиноким, чтоб в моей собственной жизни появился смысл...
Увы, не могу оценить ренпай, т.к. очень поверхностно с ним знаком. Но у него однозначно узкая специализация. Там вроде можно писать код на питоне, поэтому технических ограничений нет, но проблема в том, что для чего-то сложного придётся много писать с нуля на питоне. Т.е. если вдруг решишь сделать бесшовную тайловую визуализацию мира как в обычных 2D играх, то ренпай вряд ли даст тебе готовый инструмент для этого, в отличие от Годо. Также не ясно что там по интерфейсу - шаблон для новелл там точно есть, судя по одинаковости многих визуальных новелл, но непонятны возможности расширения. У Годо интерфейс широкого назначения, хотя у него нет готовых заготовок для новелл "из коробки" (только в ассетах), но возможности неограниченные и есть все удобства для формошлёпства окошечных приложений без написания кода (код только для логики и динамических изменений). Так что если у тебя сильная зависимость от кастомизации сложного ГУИ, Годо - хороший выбор (в движках-конкурентах с гуи какие-то проблемы, сколько игр вижу - везде велосипеды на костылях и без единого зайчатка адаптивности, как будто в движке нет нормального гуи фреймворка; возможно, конечно, что проблема не в движках, а в самих разрабах, которые забили болт на юзабилити гуя, но я не верю - игра в целом хорошо выглядит, а гуй ужасный).
Ээээ, с чего вдруг? Я не знаю синтаксис питона и тем более синтаксис внутреннего языка ренпи, и не знаю, какой там графический редактор сцен (если он есть), но я достаточно хорошо разбираюсь в Годо, чтобы сделать на нём простую визуальную новеллу без каких-либо сторонних аддонов - чисто на базовых функциях. Чтобы освоить ренпи и сделать то же самое на нём, мне потребуется достаточно много времени на освоение его базы, и вполне возможно, что времени на это уйдёт даже больше, чем на написание своего велосипеда на основе Годо (что там писать-то, картинки с текстом да менюшка с выбором ответов, а весь текст с развилками и иллюстрациями можно в JSON/Hjson загнать - не нужно создавать собственный парсер; аналогично с системой сохранения/загрузки, JSONа достаточно).
>>34487
Я видел подобное в разных играх, т.к. это типичный интерфейс текстовых игр с иллюстрациями, инвентарём и другими побочными менюшками. Кроме ренпи существует ещё куча других движков для таких игр, но все они узкоспециализированные - владея Годо, разбираться в них нет никакой мотивации (а вот слепить что-то похожее на Годо чисто по фану иногда хочется, что я и делаю).
Прости за многословность, да, я графоман.
Художественную литературу и интерактивные книги пробовал писать, но это не так интересно, как на форумах.
>Песочница -- слишком общее название жанра
Так это вообще не жанр. Игра-песочница может быть в самых разных жанрах. Отличие песочниц в большой свободе действий игрока, отсутствии принудительных "коридоров" в левел-дизайне и сюжете, или даже полное отсутствие сюжета как такового: вот тебе песок, совок, ведёрко и другие игрушки, а дальше делай что хочешь. Но когда сегодня говорят "2D песочница", обычно подразумевают что-то вроде Террарии - огромный, зачастую бесшовный мир из тайлов с видом сбоку (платформер) или сверху (топ-даун), на который можно по-разному воздействовать, контролируя одного или более персонажей, которые по этому миру физически перемещаются, обычно в реальном времени, т.е. вместе с мобами. Иногда персонажа нет совсем, игрок управляет абстрактной "рукой бога" и меняет мир под свои желания, как в The Powder Toy, но суть игры остаётся плюс-минус похожей.
Визуальные новеллы, по-моему, не относят к 2D играм, потому что их прямые предки были чисто текстовыми, а предки их предков были бумажными книгами. Чисто технически, визуальная новелла может иметь только 3D графику реального времени, оставаясь при этом прямым наследником классических интерактивных книг из бумаги. Под "2D играми" обычно подразумевают игры, суть которых заключается конкретно в графике, а не в интерактивном тексте. Из визуальной новеллы обычно можно выкинуть все иллюстрации и она мало что потеряет, т.к. её основа - в тексте, а из 2D игры графику не выкинуть (ASCII-графика всё ещё графика). Так что не стоит называть игру "2D песочницей", если она по сути является визуальной новеллой (интерактивной книгой или текстовой игрой с большим количеством иллюстраций) с расширенной свободой действий игрока. А то игрок может сформировать ложные ожидания и разочароваться. Или могут дать неправильные советы по разработке...
>У меня больше симуляция повседневной жизни изменёнными условиями мира.
Понятно. Что-то последнее время очень много желающих сделать свой симулятор жизни. За последнее время здесь кроме тебя было ещё двое или трое, кто собирался сделать симулятор жизни с иллюстрациями в стиле визуальных новелл или пойнт-н-клик квестов, некоторые из них вроде на Godot пытались это делать, но все куда-то делись без прощаний. Я тоже хочу сделать симулятор жизни, но в 3D и реальном времени; хотя были мысли и о текстовой игре, но меня слабо привлекают текстовые игры (хотя я понимаю, что основа симуляции может быть почти такой же). Тоже делаю "для себя", но мотивации не хватает и задумки все слишком абстрактные, не знаю, как и что реализовать, бросаюсь от одного к другому и забрасываю на долгое время... Хочется сделать виртуального человечка, чтоб не чувствовать себя одиноким, чтоб в моей собственной жизни появился смысл...
>ренпай может быть не таким хорошим вариантом как кажется.
Увы, не могу оценить ренпай, т.к. очень поверхностно с ним знаком. Но у него однозначно узкая специализация. Там вроде можно писать код на питоне, поэтому технических ограничений нет, но проблема в том, что для чего-то сложного придётся много писать с нуля на питоне. Т.е. если вдруг решишь сделать бесшовную тайловую визуализацию мира как в обычных 2D играх, то ренпай вряд ли даст тебе готовый инструмент для этого, в отличие от Годо. Также не ясно что там по интерфейсу - шаблон для новелл там точно есть, судя по одинаковости многих визуальных новелл, но непонятны возможности расширения. У Годо интерфейс широкого назначения, хотя у него нет готовых заготовок для новелл "из коробки" (только в ассетах), но возможности неограниченные и есть все удобства для формошлёпства окошечных приложений без написания кода (код только для логики и динамических изменений). Так что если у тебя сильная зависимость от кастомизации сложного ГУИ, Годо - хороший выбор (в движках-конкурентах с гуи какие-то проблемы, сколько игр вижу - везде велосипеды на костылях и без единого зайчатка адаптивности, как будто в движке нет нормального гуи фреймворка; возможно, конечно, что проблема не в движках, а в самих разрабах, которые забили болт на юзабилити гуя, но я не верю - игра в целом хорошо выглядит, а гуй ужасный).
>тот, кто использует годот, должен понимать, как пишется на ренпае.
Ээээ, с чего вдруг? Я не знаю синтаксис питона и тем более синтаксис внутреннего языка ренпи, и не знаю, какой там графический редактор сцен (если он есть), но я достаточно хорошо разбираюсь в Годо, чтобы сделать на нём простую визуальную новеллу без каких-либо сторонних аддонов - чисто на базовых функциях. Чтобы освоить ренпи и сделать то же самое на нём, мне потребуется достаточно много времени на освоение его базы, и вполне возможно, что времени на это уйдёт даже больше, чем на написание своего велосипеда на основе Годо (что там писать-то, картинки с текстом да менюшка с выбором ответов, а весь текст с развилками и иллюстрациями можно в JSON/Hjson загнать - не нужно создавать собственный парсер; аналогично с системой сохранения/загрузки, JSONа достаточно).
>>34487
>кто опознал игру по мэдскиллзу
Я видел подобное в разных играх, т.к. это типичный интерфейс текстовых игр с иллюстрациями, инвентарём и другими побочными менюшками. Кроме ренпи существует ещё куча других движков для таких игр, но все они узкоспециализированные - владея Годо, разбираться в них нет никакой мотивации (а вот слепить что-то похожее на Годо чисто по фану иногда хочется, что я и делаю).
Прости за многословность, да, я графоман.
Художественную литературу и интерактивные книги пробовал писать, но это не так интересно, как на форумах.
>>34486
Так это вообще не жанр. Игра-песочница может быть в самых разных жанрах. Отличие песочниц в большой свободе действий игрока, отсутствии принудительных "коридоров" в левел-дизайне и сюжете, или даже полное отсутствие сюжета как такового: вот тебе песок, совок, ведёрко и другие игрушки, а дальше делай что хочешь. Но когда сегодня говорят "2D песочница", обычно подразумевают что-то вроде Террарии - огромный, зачастую бесшовный мир из тайлов с видом сбоку (платформер) или сверху (топ-даун), на который можно по-разному воздействовать, контролируя одного или более персонажей, которые по этому миру физически перемещаются, обычно в реальном времени, т.е. вместе с мобами. Иногда персонажа нет совсем, игрок управляет абстрактной "рукой бога" и меняет мир под свои желания, как в The Powder Toy, но суть игры остаётся плюс-минус похожей.
Визуальные новеллы, по-моему, не относят к 2D играм, потому что их прямые предки были чисто текстовыми, а предки их предков были бумажными книгами. Чисто технически, визуальная новелла может иметь только 3D графику реального времени, оставаясь при этом прямым наследником классических интерактивных книг из бумаги. Под "2D играми" обычно подразумевают игры, суть которых заключается конкретно в графике, а не в интерактивном тексте. Из визуальной новеллы обычно можно выкинуть все иллюстрации и она мало что потеряет, т.к. её основа - в тексте, а из 2D игры графику не выкинуть (ASCII-графика всё ещё графика). Так что не стоит называть игру "2D песочницей", если она по сути является визуальной новеллой (интерактивной книгой или текстовой игрой с большим количеством иллюстраций) с расширенной свободой действий игрока. А то игрок может сформировать ложные ожидания и разочароваться. Или могут дать неправильные советы по разработке...
Понятно. Что-то последнее время очень много желающих сделать свой симулятор жизни. За последнее время здесь кроме тебя было ещё двое или трое, кто собирался сделать симулятор жизни с иллюстрациями в стиле визуальных новелл или пойнт-н-клик квестов, некоторые из них вроде на Godot пытались это делать, но все куда-то делись без прощаний. Я тоже хочу сделать симулятор жизни, но в 3D и реальном времени; хотя были мысли и о текстовой игре, но меня слабо привлекают текстовые игры (хотя я понимаю, что основа симуляции может быть почти такой же). Тоже делаю "для себя", но мотивации не хватает и задумки все слишком абстрактные, не знаю, как и что реализовать, бросаюсь от одного к другому и забрасываю на долгое время... Хочется сделать виртуального человечка, чтоб не чувствовать себя одиноким, чтоб в моей собственной жизни появился смысл...
Увы, не могу оценить ренпай, т.к. очень поверхностно с ним знаком. Но у него однозначно узкая специализация. Там вроде можно писать код на питоне, поэтому технических ограничений нет, но проблема в том, что для чего-то сложного придётся много писать с нуля на питоне. Т.е. если вдруг решишь сделать бесшовную тайловую визуализацию мира как в обычных 2D играх, то ренпай вряд ли даст тебе готовый инструмент для этого, в отличие от Годо. Также не ясно что там по интерфейсу - шаблон для новелл там точно есть, судя по одинаковости многих визуальных новелл, но непонятны возможности расширения. У Годо интерфейс широкого назначения, хотя у него нет готовых заготовок для новелл "из коробки" (только в ассетах), но возможности неограниченные и есть все удобства для формошлёпства окошечных приложений без написания кода (код только для логики и динамических изменений). Так что если у тебя сильная зависимость от кастомизации сложного ГУИ, Годо - хороший выбор (в движках-конкурентах с гуи какие-то проблемы, сколько игр вижу - везде велосипеды на костылях и без единого зайчатка адаптивности, как будто в движке нет нормального гуи фреймворка; возможно, конечно, что проблема не в движках, а в самих разрабах, которые забили болт на юзабилити гуя, но я не верю - игра в целом хорошо выглядит, а гуй ужасный).
Ээээ, с чего вдруг? Я не знаю синтаксис питона и тем более синтаксис внутреннего языка ренпи, и не знаю, какой там графический редактор сцен (если он есть), но я достаточно хорошо разбираюсь в Годо, чтобы сделать на нём простую визуальную новеллу без каких-либо сторонних аддонов - чисто на базовых функциях. Чтобы освоить ренпи и сделать то же самое на нём, мне потребуется достаточно много времени на освоение его базы, и вполне возможно, что времени на это уйдёт даже больше, чем на написание своего велосипеда на основе Годо (что там писать-то, картинки с текстом да менюшка с выбором ответов, а весь текст с развилками и иллюстрациями можно в JSON/Hjson загнать - не нужно создавать собственный парсер; аналогично с системой сохранения/загрузки, JSONа достаточно).
>>34487
Я видел подобное в разных играх, т.к. это типичный интерфейс текстовых игр с иллюстрациями, инвентарём и другими побочными менюшками. Кроме ренпи существует ещё куча других движков для таких игр, но все они узкоспециализированные - владея Годо, разбираться в них нет никакой мотивации (а вот слепить что-то похожее на Годо чисто по фану иногда хочется, что я и делаю).
Прости за многословность, да, я графоман.
Художественную литературу и интерактивные книги пробовал писать, но это не так интересно, как на форумах.
>Песочница -- слишком общее название жанра
Так это вообще не жанр. Игра-песочница может быть в самых разных жанрах. Отличие песочниц в большой свободе действий игрока, отсутствии принудительных "коридоров" в левел-дизайне и сюжете, или даже полное отсутствие сюжета как такового: вот тебе песок, совок, ведёрко и другие игрушки, а дальше делай что хочешь. Но когда сегодня говорят "2D песочница", обычно подразумевают что-то вроде Террарии - огромный, зачастую бесшовный мир из тайлов с видом сбоку (платформер) или сверху (топ-даун), на который можно по-разному воздействовать, контролируя одного или более персонажей, которые по этому миру физически перемещаются, обычно в реальном времени, т.е. вместе с мобами. Иногда персонажа нет совсем, игрок управляет абстрактной "рукой бога" и меняет мир под свои желания, как в The Powder Toy, но суть игры остаётся плюс-минус похожей.
Визуальные новеллы, по-моему, не относят к 2D играм, потому что их прямые предки были чисто текстовыми, а предки их предков были бумажными книгами. Чисто технически, визуальная новелла может иметь только 3D графику реального времени, оставаясь при этом прямым наследником классических интерактивных книг из бумаги. Под "2D играми" обычно подразумевают игры, суть которых заключается конкретно в графике, а не в интерактивном тексте. Из визуальной новеллы обычно можно выкинуть все иллюстрации и она мало что потеряет, т.к. её основа - в тексте, а из 2D игры графику не выкинуть (ASCII-графика всё ещё графика). Так что не стоит называть игру "2D песочницей", если она по сути является визуальной новеллой (интерактивной книгой или текстовой игрой с большим количеством иллюстраций) с расширенной свободой действий игрока. А то игрок может сформировать ложные ожидания и разочароваться. Или могут дать неправильные советы по разработке...
>У меня больше симуляция повседневной жизни изменёнными условиями мира.
Понятно. Что-то последнее время очень много желающих сделать свой симулятор жизни. За последнее время здесь кроме тебя было ещё двое или трое, кто собирался сделать симулятор жизни с иллюстрациями в стиле визуальных новелл или пойнт-н-клик квестов, некоторые из них вроде на Godot пытались это делать, но все куда-то делись без прощаний. Я тоже хочу сделать симулятор жизни, но в 3D и реальном времени; хотя были мысли и о текстовой игре, но меня слабо привлекают текстовые игры (хотя я понимаю, что основа симуляции может быть почти такой же). Тоже делаю "для себя", но мотивации не хватает и задумки все слишком абстрактные, не знаю, как и что реализовать, бросаюсь от одного к другому и забрасываю на долгое время... Хочется сделать виртуального человечка, чтоб не чувствовать себя одиноким, чтоб в моей собственной жизни появился смысл...
>ренпай может быть не таким хорошим вариантом как кажется.
Увы, не могу оценить ренпай, т.к. очень поверхностно с ним знаком. Но у него однозначно узкая специализация. Там вроде можно писать код на питоне, поэтому технических ограничений нет, но проблема в том, что для чего-то сложного придётся много писать с нуля на питоне. Т.е. если вдруг решишь сделать бесшовную тайловую визуализацию мира как в обычных 2D играх, то ренпай вряд ли даст тебе готовый инструмент для этого, в отличие от Годо. Также не ясно что там по интерфейсу - шаблон для новелл там точно есть, судя по одинаковости многих визуальных новелл, но непонятны возможности расширения. У Годо интерфейс широкого назначения, хотя у него нет готовых заготовок для новелл "из коробки" (только в ассетах), но возможности неограниченные и есть все удобства для формошлёпства окошечных приложений без написания кода (код только для логики и динамических изменений). Так что если у тебя сильная зависимость от кастомизации сложного ГУИ, Годо - хороший выбор (в движках-конкурентах с гуи какие-то проблемы, сколько игр вижу - везде велосипеды на костылях и без единого зайчатка адаптивности, как будто в движке нет нормального гуи фреймворка; возможно, конечно, что проблема не в движках, а в самих разрабах, которые забили болт на юзабилити гуя, но я не верю - игра в целом хорошо выглядит, а гуй ужасный).
>тот, кто использует годот, должен понимать, как пишется на ренпае.
Ээээ, с чего вдруг? Я не знаю синтаксис питона и тем более синтаксис внутреннего языка ренпи, и не знаю, какой там графический редактор сцен (если он есть), но я достаточно хорошо разбираюсь в Годо, чтобы сделать на нём простую визуальную новеллу без каких-либо сторонних аддонов - чисто на базовых функциях. Чтобы освоить ренпи и сделать то же самое на нём, мне потребуется достаточно много времени на освоение его базы, и вполне возможно, что времени на это уйдёт даже больше, чем на написание своего велосипеда на основе Годо (что там писать-то, картинки с текстом да менюшка с выбором ответов, а весь текст с развилками и иллюстрациями можно в JSON/Hjson загнать - не нужно создавать собственный парсер; аналогично с системой сохранения/загрузки, JSONа достаточно).
>>34487
>кто опознал игру по мэдскиллзу
Я видел подобное в разных играх, т.к. это типичный интерфейс текстовых игр с иллюстрациями, инвентарём и другими побочными менюшками. Кроме ренпи существует ещё куча других движков для таких игр, но все они узкоспециализированные - владея Годо, разбираться в них нет никакой мотивации (а вот слепить что-то похожее на Годо чисто по фану иногда хочется, что я и делаю).
Прости за многословность, да, я графоман.
Художественную литературу и интерактивные книги пробовал писать, но это не так интересно, как на форумах.
10 Кб, 636x75>>34605
Не успеваю скринить, +1 игра
Не успеваю скринить, +1 игра
>>34510
>>34589
>>34590
Пускай ты и пишешь анонимно, но твой стиль сообщений узнаваем. Ты уже много месяцев тут периодически пытаешься дезинформировать новичков, либо упорно не хочешь признавать свои ошибки, и это каждый раз растягивается на множество сообщений... Либо ты тролль, который пытается сбить честных годят с верного пути, либо просто упёртый баран. Прекращай троллить и проверяй свою информацию, которую с таким упорством пытаешься всем тут доказать.
В частности, в Годо векторы объявлены как структуры и поэтому передаются по значению (т.е. через стек, если я правильно понимаю), а не по ссылке:
https://github.com/godotengine/godot/blob/3.x/core/math/vector2.h#L47
Кроме того, там нет никаких "геттер X" и "геттер Y", потому что структура объявлена как union - т.е. разные имена ссылаются на одну и ту же область памяти (стека). Другими словами, эти три фразы - синонимы:
И эти три фразы - тоже синонимы:
Если всё ещё не веришь, я проверил на практике, такая структура передаётся по значению, а не по ссылке, даже если у неё есть свои методы:
https://onecompiler.com/cpp/3yk2jyyny
А Godot написан на C++, а не на C. Это разные языки, даже если первый возник как расширение второго.
Сам я лучше всего знаю Паскаль, поэтому мне пришлось гуглить, как работает C++, но в целом суть там такая же, как в Паскале, у которого есть аналог union в записях и аналог struct с методами, передающийся через стек, т.е. по значению, а не по ссылке. Так что если ты тот, кто здесь ноет об отсутствии нормальных биндингов под Паскаль - стыдно должно быть, что вводишь в заблуждение новичков такими глупыми ошибками. Мог бы как я зайти в исходники на гитхабе и прочитать, как устроен Vector2 - каких-то сложных знаний для этого не нужно.
Всем остальным рекомендую не верить на слово анонам, которые тут иногда усираются в попытке доказать свою точку зрения, но ничего кроме своих эмоций не предоставляют. Движок опенсурсный, то есть все исходники доступны бесплатно и без регистрации - идёте на гитхаб и проверяете лично, что там и как работает. Я и сам иногда заблуждаюсь, но я хотя бы явно выражаю свою неуверенность и предлагаю проверить лично, а не пытаюсь действовать на эмоции.
>Вектор это одномерный массив
>нулевой элемент доступен через геттер X, а первый элемент доступен через геттер Y
>массив (вектор!)
>>34589
>годот написан на си
>>34590
>Вектор - это массив. Вектор это массив. Вектор это массив. Вектор это массив. Массив. Массив. Массив.
Пускай ты и пишешь анонимно, но твой стиль сообщений узнаваем. Ты уже много месяцев тут периодически пытаешься дезинформировать новичков, либо упорно не хочешь признавать свои ошибки, и это каждый раз растягивается на множество сообщений... Либо ты тролль, который пытается сбить честных годят с верного пути, либо просто упёртый баран. Прекращай троллить и проверяй свою информацию, которую с таким упорством пытаешься всем тут доказать.
В частности, в Годо векторы объявлены как структуры и поэтому передаются по значению (т.е. через стек, если я правильно понимаю), а не по ссылке:
https://github.com/godotengine/godot/blob/3.x/core/math/vector2.h#L47
Кроме того, там нет никаких "геттер X" и "геттер Y", потому что структура объявлена как union - т.е. разные имена ссылаются на одну и ту же область памяти (стека). Другими словами, эти три фразы - синонимы:
>Vector2.x
>Vector2.width
>Vector2.coord[0]
И эти три фразы - тоже синонимы:
>Vector2.y
>Vector2.height
>Vector2.coord[1]
Если всё ещё не веришь, я проверил на практике, такая структура передаётся по значению, а не по ссылке, даже если у неё есть свои методы:
https://onecompiler.com/cpp/3yk2jyyny
А Godot написан на C++, а не на C. Это разные языки, даже если первый возник как расширение второго.
Сам я лучше всего знаю Паскаль, поэтому мне пришлось гуглить, как работает C++, но в целом суть там такая же, как в Паскале, у которого есть аналог union в записях и аналог struct с методами, передающийся через стек, т.е. по значению, а не по ссылке. Так что если ты тот, кто здесь ноет об отсутствии нормальных биндингов под Паскаль - стыдно должно быть, что вводишь в заблуждение новичков такими глупыми ошибками. Мог бы как я зайти в исходники на гитхабе и прочитать, как устроен Vector2 - каких-то сложных знаний для этого не нужно.
Всем остальным рекомендую не верить на слово анонам, которые тут иногда усираются в попытке доказать свою точку зрения, но ничего кроме своих эмоций не предоставляют. Движок опенсурсный, то есть все исходники доступны бесплатно и без регистрации - идёте на гитхаб и проверяете лично, что там и как работает. Я и сам иногда заблуждаюсь, но я хотя бы явно выражаю свою неуверенность и предлагаю проверить лично, а не пытаюсь действовать на эмоции.
>>34510
>>34589
>>34590
Пускай ты и пишешь анонимно, но твой стиль сообщений узнаваем. Ты уже много месяцев тут периодически пытаешься дезинформировать новичков, либо упорно не хочешь признавать свои ошибки, и это каждый раз растягивается на множество сообщений... Либо ты тролль, который пытается сбить честных годят с верного пути, либо просто упёртый баран. Прекращай троллить и проверяй свою информацию, которую с таким упорством пытаешься всем тут доказать.
В частности, в Годо векторы объявлены как структуры и поэтому передаются по значению (т.е. через стек, если я правильно понимаю), а не по ссылке:
https://github.com/godotengine/godot/blob/3.x/core/math/vector2.h#L47
Кроме того, там нет никаких "геттер X" и "геттер Y", потому что структура объявлена как union - т.е. разные имена ссылаются на одну и ту же область памяти (стека). Другими словами, эти три фразы - синонимы:
И эти три фразы - тоже синонимы:
Если всё ещё не веришь, я проверил на практике, такая структура передаётся по значению, а не по ссылке, даже если у неё есть свои методы:
https://onecompiler.com/cpp/3yk2jyyny
А Godot написан на C++, а не на C. Это разные языки, даже если первый возник как расширение второго.
Сам я лучше всего знаю Паскаль, поэтому мне пришлось гуглить, как работает C++, но в целом суть там такая же, как в Паскале, у которого есть аналог union в записях и аналог struct с методами, передающийся через стек, т.е. по значению, а не по ссылке. Так что если ты тот, кто здесь ноет об отсутствии нормальных биндингов под Паскаль - стыдно должно быть, что вводишь в заблуждение новичков такими глупыми ошибками. Мог бы как я зайти в исходники на гитхабе и прочитать, как устроен Vector2 - каких-то сложных знаний для этого не нужно.
Всем остальным рекомендую не верить на слово анонам, которые тут иногда усираются в попытке доказать свою точку зрения, но ничего кроме своих эмоций не предоставляют. Движок опенсурсный, то есть все исходники доступны бесплатно и без регистрации - идёте на гитхаб и проверяете лично, что там и как работает. Я и сам иногда заблуждаюсь, но я хотя бы явно выражаю свою неуверенность и предлагаю проверить лично, а не пытаюсь действовать на эмоции.
>Вектор это одномерный массив
>нулевой элемент доступен через геттер X, а первый элемент доступен через геттер Y
>массив (вектор!)
>>34589
>годот написан на си
>>34590
>Вектор - это массив. Вектор это массив. Вектор это массив. Вектор это массив. Массив. Массив. Массив.
Пускай ты и пишешь анонимно, но твой стиль сообщений узнаваем. Ты уже много месяцев тут периодически пытаешься дезинформировать новичков, либо упорно не хочешь признавать свои ошибки, и это каждый раз растягивается на множество сообщений... Либо ты тролль, который пытается сбить честных годят с верного пути, либо просто упёртый баран. Прекращай троллить и проверяй свою информацию, которую с таким упорством пытаешься всем тут доказать.
В частности, в Годо векторы объявлены как структуры и поэтому передаются по значению (т.е. через стек, если я правильно понимаю), а не по ссылке:
https://github.com/godotengine/godot/blob/3.x/core/math/vector2.h#L47
Кроме того, там нет никаких "геттер X" и "геттер Y", потому что структура объявлена как union - т.е. разные имена ссылаются на одну и ту же область памяти (стека). Другими словами, эти три фразы - синонимы:
>Vector2.x
>Vector2.width
>Vector2.coord[0]
И эти три фразы - тоже синонимы:
>Vector2.y
>Vector2.height
>Vector2.coord[1]
Если всё ещё не веришь, я проверил на практике, такая структура передаётся по значению, а не по ссылке, даже если у неё есть свои методы:
https://onecompiler.com/cpp/3yk2jyyny
А Godot написан на C++, а не на C. Это разные языки, даже если первый возник как расширение второго.
Сам я лучше всего знаю Паскаль, поэтому мне пришлось гуглить, как работает C++, но в целом суть там такая же, как в Паскале, у которого есть аналог union в записях и аналог struct с методами, передающийся через стек, т.е. по значению, а не по ссылке. Так что если ты тот, кто здесь ноет об отсутствии нормальных биндингов под Паскаль - стыдно должно быть, что вводишь в заблуждение новичков такими глупыми ошибками. Мог бы как я зайти в исходники на гитхабе и прочитать, как устроен Vector2 - каких-то сложных знаний для этого не нужно.
Всем остальным рекомендую не верить на слово анонам, которые тут иногда усираются в попытке доказать свою точку зрения, но ничего кроме своих эмоций не предоставляют. Движок опенсурсный, то есть все исходники доступны бесплатно и без регистрации - идёте на гитхаб и проверяете лично, что там и как работает. Я и сам иногда заблуждаюсь, но я хотя бы явно выражаю свою неуверенность и предлагаю проверить лично, а не пытаюсь действовать на эмоции.
443 Кб, 1280x720>>34628
У меня другое. Как говорил, в геймдеве не был, залуп больших не видел. И мотивация у меня не в сделать человечка под себя, хотя, я думал запилить с архетипом яндере что-то себе, такое было, но решил что нахер-нахер. У меня скорее мотивация стать Борисом Гребенщиковым этого мира. Мне очень вкатывает мысль запилить свой виртуальный мирок, где всё будет, как ЯСКОЗАЛ.
Но есть вероятность дропнуть, да, из-за того, что ирл душит, плюс ещё и к турниру сейчас готовлюсь в игре, тоже нельзя пинать хуй.
Я навиганцию задумал почти копирующую конкретную игру, хотя, мало кто в неё играет, я не исключаю, что кто-то может догадаться. В мэдскиллзе чисто пример как целом устроено, предварительно правая колонка -- имена неписей кликабельные на локации.
И у меня есть достаточно подробное представление о том, что я хочу видеть, чтобы у меня начали мысли вертеться в голове "не лезь блядь дебил сука ебаный".
Я сначала хотел в твайне запилить, но начал и понял, что это максимум изврат будет.
> Тоже делаю "для себя", но мотивации не хватает и задумки все слишком абстрактные, не знаю, как и что реализовать, бросаюсь от одного к другому и забрасываю на долгое время...
У меня другое. Как говорил, в геймдеве не был, залуп больших не видел. И мотивация у меня не в сделать человечка под себя, хотя, я думал запилить с архетипом яндере что-то себе, такое было, но решил что нахер-нахер. У меня скорее мотивация стать Борисом Гребенщиковым этого мира. Мне очень вкатывает мысль запилить свой виртуальный мирок, где всё будет, как ЯСКОЗАЛ.
Но есть вероятность дропнуть, да, из-за того, что ирл душит, плюс ещё и к турниру сейчас готовлюсь в игре, тоже нельзя пинать хуй.
> Я видел подобное в разных играх
Я навиганцию задумал почти копирующую конкретную игру, хотя, мало кто в неё играет, я не исключаю, что кто-то может догадаться. В мэдскиллзе чисто пример как целом устроено, предварительно правая колонка -- имена неписей кликабельные на локации.
И у меня есть достаточно подробное представление о том, что я хочу видеть, чтобы у меня начали мысли вертеться в голове "не лезь блядь дебил сука ебаный".
Я сначала хотел в твайне запилить, но начал и понял, что это максимум изврат будет.
>>34637
Не видел больших игр, движков или разработчиков?
А мне больше всего генки нравятся...
Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит.
Ну-у-у, это неинтересно, ведь многие игры дают игроку способности, сравнимые с богом мира, даже если режим игры называется "выживание", так что почувствовать себя богом виртуального мирка легко можно с помощью готовой игры. Даже если игра не называет игрока "богом" (а ведь есть игры, в которых игрок играет роль бога), геймплейные возможности к эндгейму становятся колоссальными - и игра становится скучной. Более того, даже если игра якобы оказывает сопротивление в эндгейме (насылает мобов, боссов, катастрофы и т.п.), большинство игр построены вокруг игрока - всё, что игра делает, она делает ради игрока, даже если заявлена симуляция жизни.
Поэтому мне хотелось бы сделать виртуальный мир, который живёт сам по себе и для самого себя, а я бы, как игрок, мог бы наблюдать за процессами, изучать их свойства (ибо эмерджентность - обычно ты не знаешь всех свойств сложной системы, даже если создал её своими руками; т.е. ты, конечно, творец мира, но вовсе не всезнающий и не всемогущий), и взаимодействовать так, как может обычный житель мира (с минимальными допущениями, например, вместо анализа картинки - рейкасты, поиск по спискам объектов, сверка ID и т.п.). Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир. Проблема в том, что человек без окружающей среды не человек, а перемалывать данные из реальной среды (видеопоток) компьютерам пока слишком сложно.
Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки? Также, как я понимаю, твоя игра ближе к пойнт-н-клик квестам, чем к визуальным новеллам, если предполагается точно отображать содержимое комнат и предлагать взаимодействие с любым из расположенных в комнате предметов. В квестах обычно картинка занимает весь экран, а необходимые меню отображаются только при необходимости (не считая очень старых игр - там большую часть экрана занимали меню в целях оптимизации рендеринга).
В чём ты видишь основную сложность? Графики слишком много вручную рисовать? Или текста для диалогов? Или ты хочешь какие-то сложные алгоритмы поведения? Модель мира как набор "комнат" и интерактивные предметы в них несложно сделать, а вот неигровые персонажи могут представлять большую сложность, если требуется реалистичное поведение в симуляции, а не рельсовый сюжет с минимальными развилками. Но если начинать с простого и если конечная цель в принципе достижима, а по времени ограничений нет, то всё можно сделать...
Кстати, ты уже пробовал Godot запускать? Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать. И оно будет адаптивным и в какой-то степени интерактивным без единой строчки кода. Новичку, наверное, много времени понадобится, но зато потом сможешь уже приготовленный образец использовать в игре.
Сначала начни с туториалов из раздела "Getting started" в боковом меню, а потом вот здесь продвинутая информация о работе с интерфейсом:
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода. Т.е. всё намного проще, чем может показаться при первом взгляде на список доступных нод (я изучал Годо по большому счёту методом тыка, туториалы почти не читал; но у меня сравнительно долгий опыт с Delphi/Lazarus, так что все концепции мне давно уже были хорошо знакомы).
>залуп больших не видел
Не видел больших игр, движков или разработчиков?
>думал запилить с архетипом яндере что-то себе
А мне больше всего генки нравятся...
>но решил что нахер-нахер
Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит.
>запилить свой виртуальный мирок, где всё будет, как ЯСКОЗАЛ.
Ну-у-у, это неинтересно, ведь многие игры дают игроку способности, сравнимые с богом мира, даже если режим игры называется "выживание", так что почувствовать себя богом виртуального мирка легко можно с помощью готовой игры. Даже если игра не называет игрока "богом" (а ведь есть игры, в которых игрок играет роль бога), геймплейные возможности к эндгейму становятся колоссальными - и игра становится скучной. Более того, даже если игра якобы оказывает сопротивление в эндгейме (насылает мобов, боссов, катастрофы и т.п.), большинство игр построены вокруг игрока - всё, что игра делает, она делает ради игрока, даже если заявлена симуляция жизни.
Поэтому мне хотелось бы сделать виртуальный мир, который живёт сам по себе и для самого себя, а я бы, как игрок, мог бы наблюдать за процессами, изучать их свойства (ибо эмерджентность - обычно ты не знаешь всех свойств сложной системы, даже если создал её своими руками; т.е. ты, конечно, творец мира, но вовсе не всезнающий и не всемогущий), и взаимодействовать так, как может обычный житель мира (с минимальными допущениями, например, вместо анализа картинки - рейкасты, поиск по спискам объектов, сверка ID и т.п.). Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир. Проблема в том, что человек без окружающей среды не человек, а перемалывать данные из реальной среды (видеопоток) компьютерам пока слишком сложно.
>правая колонка -- имена неписей кликабельные на локации.
Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки? Также, как я понимаю, твоя игра ближе к пойнт-н-клик квестам, чем к визуальным новеллам, если предполагается точно отображать содержимое комнат и предлагать взаимодействие с любым из расположенных в комнате предметов. В квестах обычно картинка занимает весь экран, а необходимые меню отображаются только при необходимости (не считая очень старых игр - там большую часть экрана занимали меню в целях оптимизации рендеринга).
>начали мысли вертеться в голове "не лезь блядь дебил сука ебаный".
В чём ты видишь основную сложность? Графики слишком много вручную рисовать? Или текста для диалогов? Или ты хочешь какие-то сложные алгоритмы поведения? Модель мира как набор "комнат" и интерактивные предметы в них несложно сделать, а вот неигровые персонажи могут представлять большую сложность, если требуется реалистичное поведение в симуляции, а не рельсовый сюжет с минимальными развилками. Но если начинать с простого и если конечная цель в принципе достижима, а по времени ограничений нет, то всё можно сделать...
>В мэдскиллзе чисто пример как целом устроено
Кстати, ты уже пробовал Godot запускать? Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать. И оно будет адаптивным и в какой-то степени интерактивным без единой строчки кода. Новичку, наверное, много времени понадобится, но зато потом сможешь уже приготовленный образец использовать в игре.
Сначала начни с туториалов из раздела "Getting started" в боковом меню, а потом вот здесь продвинутая информация о работе с интерфейсом:
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода. Т.е. всё намного проще, чем может показаться при первом взгляде на список доступных нод (я изучал Годо по большому счёту методом тыка, туториалы почти не читал; но у меня сравнительно долгий опыт с Delphi/Lazarus, так что все концепции мне давно уже были хорошо знакомы).
>>34637
Не видел больших игр, движков или разработчиков?
А мне больше всего генки нравятся...
Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит.
Ну-у-у, это неинтересно, ведь многие игры дают игроку способности, сравнимые с богом мира, даже если режим игры называется "выживание", так что почувствовать себя богом виртуального мирка легко можно с помощью готовой игры. Даже если игра не называет игрока "богом" (а ведь есть игры, в которых игрок играет роль бога), геймплейные возможности к эндгейму становятся колоссальными - и игра становится скучной. Более того, даже если игра якобы оказывает сопротивление в эндгейме (насылает мобов, боссов, катастрофы и т.п.), большинство игр построены вокруг игрока - всё, что игра делает, она делает ради игрока, даже если заявлена симуляция жизни.
Поэтому мне хотелось бы сделать виртуальный мир, который живёт сам по себе и для самого себя, а я бы, как игрок, мог бы наблюдать за процессами, изучать их свойства (ибо эмерджентность - обычно ты не знаешь всех свойств сложной системы, даже если создал её своими руками; т.е. ты, конечно, творец мира, но вовсе не всезнающий и не всемогущий), и взаимодействовать так, как может обычный житель мира (с минимальными допущениями, например, вместо анализа картинки - рейкасты, поиск по спискам объектов, сверка ID и т.п.). Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир. Проблема в том, что человек без окружающей среды не человек, а перемалывать данные из реальной среды (видеопоток) компьютерам пока слишком сложно.
Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки? Также, как я понимаю, твоя игра ближе к пойнт-н-клик квестам, чем к визуальным новеллам, если предполагается точно отображать содержимое комнат и предлагать взаимодействие с любым из расположенных в комнате предметов. В квестах обычно картинка занимает весь экран, а необходимые меню отображаются только при необходимости (не считая очень старых игр - там большую часть экрана занимали меню в целях оптимизации рендеринга).
В чём ты видишь основную сложность? Графики слишком много вручную рисовать? Или текста для диалогов? Или ты хочешь какие-то сложные алгоритмы поведения? Модель мира как набор "комнат" и интерактивные предметы в них несложно сделать, а вот неигровые персонажи могут представлять большую сложность, если требуется реалистичное поведение в симуляции, а не рельсовый сюжет с минимальными развилками. Но если начинать с простого и если конечная цель в принципе достижима, а по времени ограничений нет, то всё можно сделать...
Кстати, ты уже пробовал Godot запускать? Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать. И оно будет адаптивным и в какой-то степени интерактивным без единой строчки кода. Новичку, наверное, много времени понадобится, но зато потом сможешь уже приготовленный образец использовать в игре.
Сначала начни с туториалов из раздела "Getting started" в боковом меню, а потом вот здесь продвинутая информация о работе с интерфейсом:
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода. Т.е. всё намного проще, чем может показаться при первом взгляде на список доступных нод (я изучал Годо по большому счёту методом тыка, туториалы почти не читал; но у меня сравнительно долгий опыт с Delphi/Lazarus, так что все концепции мне давно уже были хорошо знакомы).
>залуп больших не видел
Не видел больших игр, движков или разработчиков?
>думал запилить с архетипом яндере что-то себе
А мне больше всего генки нравятся...
>но решил что нахер-нахер
Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит.
>запилить свой виртуальный мирок, где всё будет, как ЯСКОЗАЛ.
Ну-у-у, это неинтересно, ведь многие игры дают игроку способности, сравнимые с богом мира, даже если режим игры называется "выживание", так что почувствовать себя богом виртуального мирка легко можно с помощью готовой игры. Даже если игра не называет игрока "богом" (а ведь есть игры, в которых игрок играет роль бога), геймплейные возможности к эндгейму становятся колоссальными - и игра становится скучной. Более того, даже если игра якобы оказывает сопротивление в эндгейме (насылает мобов, боссов, катастрофы и т.п.), большинство игр построены вокруг игрока - всё, что игра делает, она делает ради игрока, даже если заявлена симуляция жизни.
Поэтому мне хотелось бы сделать виртуальный мир, который живёт сам по себе и для самого себя, а я бы, как игрок, мог бы наблюдать за процессами, изучать их свойства (ибо эмерджентность - обычно ты не знаешь всех свойств сложной системы, даже если создал её своими руками; т.е. ты, конечно, творец мира, но вовсе не всезнающий и не всемогущий), и взаимодействовать так, как может обычный житель мира (с минимальными допущениями, например, вместо анализа картинки - рейкасты, поиск по спискам объектов, сверка ID и т.п.). Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир. Проблема в том, что человек без окружающей среды не человек, а перемалывать данные из реальной среды (видеопоток) компьютерам пока слишком сложно.
>правая колонка -- имена неписей кликабельные на локации.
Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки? Также, как я понимаю, твоя игра ближе к пойнт-н-клик квестам, чем к визуальным новеллам, если предполагается точно отображать содержимое комнат и предлагать взаимодействие с любым из расположенных в комнате предметов. В квестах обычно картинка занимает весь экран, а необходимые меню отображаются только при необходимости (не считая очень старых игр - там большую часть экрана занимали меню в целях оптимизации рендеринга).
>начали мысли вертеться в голове "не лезь блядь дебил сука ебаный".
В чём ты видишь основную сложность? Графики слишком много вручную рисовать? Или текста для диалогов? Или ты хочешь какие-то сложные алгоритмы поведения? Модель мира как набор "комнат" и интерактивные предметы в них несложно сделать, а вот неигровые персонажи могут представлять большую сложность, если требуется реалистичное поведение в симуляции, а не рельсовый сюжет с минимальными развилками. Но если начинать с простого и если конечная цель в принципе достижима, а по времени ограничений нет, то всё можно сделать...
>В мэдскиллзе чисто пример как целом устроено
Кстати, ты уже пробовал Godot запускать? Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать. И оно будет адаптивным и в какой-то степени интерактивным без единой строчки кода. Новичку, наверное, много времени понадобится, но зато потом сможешь уже приготовленный образец использовать в игре.
Сначала начни с туториалов из раздела "Getting started" в боковом меню, а потом вот здесь продвинутая информация о работе с интерфейсом:
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода. Т.е. всё намного проще, чем может показаться при первом взгляде на список доступных нод (я изучал Годо по большому счёту методом тыка, туториалы почти не читал; но у меня сравнительно долгий опыт с Delphi/Lazarus, так что все концепции мне давно уже были хорошо знакомы).
>>34634
Да, облажался, там правильно нужно было написать геттер свойства X.
В остальном же я вёл речь не о том, по значению или по ссылке передаётся структура данных, а о другом, о том, что вектор (массив) это комбинированная структура данных. Новичок выкатывал скрины, где он накинул поверх комбинированной структуры сетгет, и искренне удивлялся, почему при перезаписи структуры целиком, у него пропадают значения. И я и ещё один анон уже два дня пытаемся ему объяснить, что если структуру перезаписывать целиком, то предыдущие значения очевидно не сохранятся.
Чтобы сохранять предыдущие значения, следует использовать сеттеры-геттеры примитивных типов, либо вообще не использовать сеттеры-геттеры, а использовать методы с несколькими параметрами для задания всех или нескольких свойств комбинированных структур.
Ля, надо стиль менять, а то уже диванон показался на горизонте. Открою тайну: да, я не люблю проигрывать и в этом смысле я упёрт как баран.
Да, облажался, там правильно нужно было написать геттер свойства X.
В остальном же я вёл речь не о том, по значению или по ссылке передаётся структура данных, а о другом, о том, что вектор (массив) это комбинированная структура данных. Новичок выкатывал скрины, где он накинул поверх комбинированной структуры сетгет, и искренне удивлялся, почему при перезаписи структуры целиком, у него пропадают значения. И я и ещё один анон уже два дня пытаемся ему объяснить, что если структуру перезаписывать целиком, то предыдущие значения очевидно не сохранятся.
Чтобы сохранять предыдущие значения, следует использовать сеттеры-геттеры примитивных типов, либо вообще не использовать сеттеры-геттеры, а использовать методы с несколькими параметрами для задания всех или нескольких свойств комбинированных структур.
> Пускай ты и пишешь анонимно, но твой стиль сообщений узнаваем. Ты уже много месяцев тут периодически пытаешься дезинформировать новичков, либо упорно не хочешь признавать свои ошибки, и это каждый раз растягивается на множество сообщений... Либо ты тролль, который пытается сбить честных годят с верного пути, либо просто упёртый баран.
Ля, надо стиль менять, а то уже диванон показался на горизонте. Открою тайну: да, я не люблю проигрывать и в этом смысле я упёрт как баран.
>>34637
Ой, да хорош интригу нагнетать. Что за игра? Колись давай.
Вот я фанатею по навигации и в целом по раскладке скайрима (при этом интерфейс чтобы как из мода SkyUI) и не скрываю, что хочу сделать игру, с управлением и интерфейсом как в скайриме с модами.
> навиганцию задумал почти копирующую конкретную игру, хотя, мало кто в неё играет, я не исключаю, что кто-то может догадаться
Ой, да хорош интригу нагнетать. Что за игра? Колись давай.
Вот я фанатею по навигации и в целом по раскладке скайрима (при этом интерфейс чтобы как из мода SkyUI) и не скрываю, что хочу сделать игру, с управлением и интерфейсом как в скайриме с модами.
>>34673
Шиза
Шиза
>>34651
Никаким боком не касался геймдева, исключая то, что я декомпилял ддлк ради интереса. Так в ренпае и разобрался.
Вкусовщина. Мне, конечно, яндере нравятся, но я прекрасно понимаю насколько это очко жить с поехавшей настолько. Вот, кстати, я бы это и на ренпае делал бы думаю. Если бы делал.
Не совсем. Начнём с того, что мир должен быть радикально изменяемым(какой смысл быть богом, если ты не можешь влиять на мир?), второе мир... это мультивселенная со всеми вытекающими подводными.
ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Взаимодействие разных состояний гг, неписей (ну, например, по плану гг может вполне слечь с жизой в жёлтом доме ещё и творожником стать (я намерен разные псих расстройства всунуть в список возможных состояний, привет, Project Zomboid)), потребности и прочее.
Как ЯСКОЗАЛ разраб, а не я-игрок. Так-то, гг по плану будет начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной -- должно же быть что-то за счёт чего он начнёт вылезать со дна, пока предварительно, я правда хочу попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод в голове вываливается.
JUST GODETTA
Да, хорошая идея.
В уровне проработке состояний, ИИ, сложности и изменяемости мира.
Я вообще 0 в рисовании.
Не проблема.
Увидим. Пока что нет.
Да. Потыкал немного по гаедлайну в шапке, подумал что неплохо, сегодня хочу ещё потыкать.
Вот только я не знаю.
Ага, спасибо. Я от паскаля кстати плююсь.
>>34674
Я бы назвал уже если бы планировал. Спок, там не скуримовская навигация. Чел-графоман прав, к пойнт-энд-клику моя задумка тяготеет, потому скурим тут мимокрокодил.
> Не видел больших игр, движков или разработчиков?
Никаким боком не касался геймдева, исключая то, что я декомпилял ддлк ради интереса. Так в ренпае и разобрался.
> А мне больше всего генки нравятся...
Вкусовщина. Мне, конечно, яндере нравятся, но я прекрасно понимаю насколько это очко жить с поехавшей настолько. Вот, кстати, я бы это и на ренпае делал бы думаю. Если бы делал.
> Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит
Не совсем. Начнём с того, что мир должен быть радикально изменяемым(какой смысл быть богом, если ты не можешь влиять на мир?), второе мир... это мультивселенная со всеми вытекающими подводными.
ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Взаимодействие разных состояний гг, неписей (ну, например, по плану гг может вполне слечь с жизой в жёлтом доме ещё и творожником стать (я намерен разные псих расстройства всунуть в список возможных состояний, привет, Project Zomboid)), потребности и прочее.
> Ну-у-у, это неинтересно, ведь многие игры дают игроку способности
Как ЯСКОЗАЛ разраб, а не я-игрок. Так-то, гг по плану будет начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной -- должно же быть что-то за счёт чего он начнёт вылезать со дна, пока предварительно, я правда хочу попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод в голове вываливается.
> Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир
JUST GODETTA
> Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки?
Да, хорошая идея.
> В чём ты видишь основную сложность?
В уровне проработке состояний, ИИ, сложности и изменяемости мира.
> Графики слишком много вручную рисовать?
Я вообще 0 в рисовании.
> Или текста для диалогов?
Не проблема.
> Или ты хочешь какие-то сложные алгоритмы поведения?
Увидим. Пока что нет.
> Кстати, ты уже пробовал Godot запускать?
Да. Потыкал немного по гаедлайну в шапке, подумал что неплохо, сегодня хочу ещё потыкать.
> Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать.
Вот только я не знаю.
> Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода.
Ага, спасибо. Я от паскаля кстати плююсь.
>>34674
Я бы назвал уже если бы планировал. Спок, там не скуримовская навигация. Чел-графоман прав, к пойнт-энд-клику моя задумка тяготеет, потому скурим тут мимокрокодил.
>>34651
Никаким боком не касался геймдева, исключая то, что я декомпилял ддлк ради интереса. Так в ренпае и разобрался.
Вкусовщина. Мне, конечно, яндере нравятся, но я прекрасно понимаю насколько это очко жить с поехавшей настолько. Вот, кстати, я бы это и на ренпае делал бы думаю. Если бы делал.
Не совсем. Начнём с того, что мир должен быть радикально изменяемым(какой смысл быть богом, если ты не можешь влиять на мир?), второе мир... это мультивселенная со всеми вытекающими подводными.
ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Взаимодействие разных состояний гг, неписей (ну, например, по плану гг может вполне слечь с жизой в жёлтом доме ещё и творожником стать (я намерен разные псих расстройства всунуть в список возможных состояний, привет, Project Zomboid)), потребности и прочее.
Как ЯСКОЗАЛ разраб, а не я-игрок. Так-то, гг по плану будет начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной -- должно же быть что-то за счёт чего он начнёт вылезать со дна, пока предварительно, я правда хочу попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод в голове вываливается.
JUST GODETTA
Да, хорошая идея.
В уровне проработке состояний, ИИ, сложности и изменяемости мира.
Я вообще 0 в рисовании.
Не проблема.
Увидим. Пока что нет.
Да. Потыкал немного по гаедлайну в шапке, подумал что неплохо, сегодня хочу ещё потыкать.
Вот только я не знаю.
Ага, спасибо. Я от паскаля кстати плююсь.
>>34674
Я бы назвал уже если бы планировал. Спок, там не скуримовская навигация. Чел-графоман прав, к пойнт-энд-клику моя задумка тяготеет, потому скурим тут мимокрокодил.
> Не видел больших игр, движков или разработчиков?
Никаким боком не касался геймдева, исключая то, что я декомпилял ддлк ради интереса. Так в ренпае и разобрался.
> А мне больше всего генки нравятся...
Вкусовщина. Мне, конечно, яндере нравятся, но я прекрасно понимаю насколько это очко жить с поехавшей настолько. Вот, кстати, я бы это и на ренпае делал бы думаю. Если бы делал.
> Если ты про персонажа в игре - почему нет? Интересно было бы попробовать. А вот если ты хочешь когда-нибудь перенести такого персонажа в физического робота, тогда да, лучше не стоит
Не совсем. Начнём с того, что мир должен быть радикально изменяемым(какой смысл быть богом, если ты не можешь влиять на мир?), второе мир... это мультивселенная со всеми вытекающими подводными.
ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Взаимодействие разных состояний гг, неписей (ну, например, по плану гг может вполне слечь с жизой в жёлтом доме ещё и творожником стать (я намерен разные псих расстройства всунуть в список возможных состояний, привет, Project Zomboid)), потребности и прочее.
> Ну-у-у, это неинтересно, ведь многие игры дают игроку способности
Как ЯСКОЗАЛ разраб, а не я-игрок. Так-то, гг по плану будет начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной -- должно же быть что-то за счёт чего он начнёт вылезать со дна, пока предварительно, я правда хочу попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод в голове вываливается.
> Но это всё не так уж важно, на самом деле, т.к. если бы я мог создать себе виртуальную генки, мне не нужен был бы целый мир
JUST GODETTA
> Если я правильно понял задумку, то можно сделать кликабельными спрайты персонажей, при необходимости добавить всплывающие подсказки и выпадающее меню по клику правой кнопкой мыши. Это удобнее с точки зрения юзабилити и даст более глубокое погружение, а иначе зачем вообще нужны картинки?
Да, хорошая идея.
> В чём ты видишь основную сложность?
В уровне проработке состояний, ИИ, сложности и изменяемости мира.
> Графики слишком много вручную рисовать?
Я вообще 0 в рисовании.
> Или текста для диалогов?
Не проблема.
> Или ты хочешь какие-то сложные алгоритмы поведения?
Увидим. Пока что нет.
> Кстати, ты уже пробовал Godot запускать?
Да. Потыкал немного по гаедлайну в шапке, подумал что неплохо, сегодня хочу ещё потыкать.
> Накидать образец интерфейса можно за считанные минуты, если знать, какие ноды использовать.
Вот только я не знаю.
> Потом просто читаешь API конкретных компонентов, можно прямо внутри движка (F1+поиск, кнопка в правом верхнем углу инспектора ноды или ctrl+клик по названию класса ноды в редакторе кода). Компонентов много, легко растеряться и запутаться, но основные - это контейнеры разных видов да кнопки с надписями. По моему опыту, большую часть любого интерфейса составляет дерево из множества контейнеров, чтобы всё было красиво и адаптивно, а листья этого дерева - несколько кнопок, надписей и, иногда, полей ввода.
Ага, спасибо. Я от паскаля кстати плююсь.
>>34674
Я бы назвал уже если бы планировал. Спок, там не скуримовская навигация. Чел-графоман прав, к пойнт-энд-клику моя задумка тяготеет, потому скурим тут мимокрокодил.
>>34689
Скурим я привёл в пример того, что я не стесняюсь назвать игру с которой хочу потянуть механики.
> скурим тут мимокрокодил
Скурим я привёл в пример того, что я не стесняюсь назвать игру с которой хочу потянуть механики.
>>34673
Да нет там никакого "геттера свойства икс". В C++ коде я их не нашёл, если ты их где-то видел - дай ссылку (выше был пример ссылки на гитхаб). В GDScript эти x и y хотя и называются "свойствами" (property), но не подразумевают никаких get_x() и get_y() - нет там никаких геттеров. GDScript вообще не имеет отношения к C/C++, потому что он интерпретируется. Поэтому нужно смотреть на реализацию структуры Vector2 в исходниках движка, а не на описание Vector2 в документации на GDScript.
Нет, речь именно об этом. Array передаётся по ссылке. Vector2 передаётся по значению. В GDScript доступны массивы, которые передаются по значению, их имена начинаются с "pool" - так вот с ними работа особенная.
Допустим, у нас есть массив массивов arr. Если вложенный массив - Array, мы можем сделать так:
Это значение сохранится, потому что Array передаётся по ссылке. Мы буквально пишем "достань объект из нулевой ячейки arr и затем запиши в первую ячейку этого объекта двойку". Поскольку в нулевой ячейке лежит ссылка на массив, мы получаем не независимую копию массива, а прямой доступ к содержимому единственного экземпляра массива.
Но если вложенный в arr массив имеет тип PoolIntArray, тогда этот код не сохранит значение:
Смысл выражения тут тот же, что и в предыдущем случае, но мы получаем не ссылку на уникальный экземпляр массива, а независимую копию массива. Мы записываем данные в эту независимую копию, но саму эту копию никуда не записываем - поэтому данные теряются. Чтобы данные не терялись, придётся сделать так:
Теперь мы не просто меняем данные в массиве pool, но сохраняем эти данные обратно в arr.
Лол, ты всё перепутал. Новичок >>34472 спросил, почему вызывается сеттер и сохраняет изменённое значение вектора, если по его мнению это изменённое значение должно быть утрачено (и оно действительно будет утрачено в других языках программирования типа C# и Delphi, но речь идёт о поведении GDScript). Я >>34482 объяснил ему, почему происходит именно так, а не иначе:
Он правильно меня понял: >>34492
Но тут зачем-то влез ты с ошибкой: >>34506
А дальше ты вообще бредить начал: >>34510
В результате ты и сам запутался, и всех тут запутать пытаешься (а кого-то может и запутал). Или это я запутался? Не понимаю...
Так ведь Vector2.x и есть примитивный тип. Если ты обращаешься к свойству position, ты получаешь структуру из двух чисел, а если обращаешься к position.x, ты получаешь одно число. В большинстве языков ты не сохранишь значение, если сделаешь position.x = 2, т.е. обычно тебе нужно делать position = Vector2(2, position.y), чтобы действительно сохранить значение. Но интерпретатор GDScript упрощает эту операцию, неявно вызывая сеттер position с новым вектором, который сформирован из предыдущего значения и твоего нового значения для одного из компонент.
В результате, движок использует куда более эффективные в плане производительности struct, размещаемые на стеке, вместо дорогих объектов в куче, но при этом скриптовый язык упрощает типичную операцию для конечного пользователя (скриптописи).
А ты начал приплетать какие-то массивы и прочий бред, хотя массивами здесь и не пахнет (структура Vector2 имеет два поля с числами, но не является массивом с точки зрения компилятора исходников Godot).
Ты меня запутал, если честно.
Я уже не уверен, прав ли я...
Но у тебя аргументов нормальных нет вообще))
>геттер свойства X
Да нет там никакого "геттера свойства икс". В C++ коде я их не нашёл, если ты их где-то видел - дай ссылку (выше был пример ссылки на гитхаб). В GDScript эти x и y хотя и называются "свойствами" (property), но не подразумевают никаких get_x() и get_y() - нет там никаких геттеров. GDScript вообще не имеет отношения к C/C++, потому что он интерпретируется. Поэтому нужно смотреть на реализацию структуры Vector2 в исходниках движка, а не на описание Vector2 в документации на GDScript.
>речь не о том, по значению или по ссылке передаётся структура данных
Нет, речь именно об этом. Array передаётся по ссылке. Vector2 передаётся по значению. В GDScript доступны массивы, которые передаются по значению, их имена начинаются с "pool" - так вот с ними работа особенная.
Допустим, у нас есть массив массивов arr. Если вложенный массив - Array, мы можем сделать так:
>arr[0][1] = 2
Это значение сохранится, потому что Array передаётся по ссылке. Мы буквально пишем "достань объект из нулевой ячейки arr и затем запиши в первую ячейку этого объекта двойку". Поскольку в нулевой ячейке лежит ссылка на массив, мы получаем не независимую копию массива, а прямой доступ к содержимому единственного экземпляра массива.
Но если вложенный в arr массив имеет тип PoolIntArray, тогда этот код не сохранит значение:
>arr[0][1] = 2
Смысл выражения тут тот же, что и в предыдущем случае, но мы получаем не ссылку на уникальный экземпляр массива, а независимую копию массива. Мы записываем данные в эту независимую копию, но саму эту копию никуда не записываем - поэтому данные теряются. Чтобы данные не терялись, придётся сделать так:
>var pool: PoolIntArray = arr[0]
>pool[1] = 2
>arr[0] = pool
Теперь мы не просто меняем данные в массиве pool, но сохраняем эти данные обратно в arr.
>Новичок выкатывал скрины, где он накинул поверх комбинированной структуры сетгет, и искренне удивлялся, почему при перезаписи структуры целиком, у него пропадают значения. И я и ещё один анон уже два дня пытаемся ему объяснить, что если структуру перезаписывать целиком, то предыдущие значения очевидно не сохранятся.
Лол, ты всё перепутал. Новичок >>34472 спросил, почему вызывается сеттер и сохраняет изменённое значение вектора, если по его мнению это изменённое значение должно быть утрачено (и оно действительно будет утрачено в других языках программирования типа C# и Delphi, но речь идёт о поведении GDScript). Я >>34482 объяснил ему, почему происходит именно так, а не иначе:
>GDScript в данной ситуации сильно упрощает типичную операцию, избавляя от необходимости создавать промежуточную переменную.
Он правильно меня понял: >>34492
>Значит self.test_var.x = 111 это типа сахар для такого set_test_var(Vector2(111, get_test_var().y)
Но тут зачем-то влез ты с ошибкой: >>34506
>Так у тебя тут другое написано. Таким кодом ты явно создаешь копию значения, а не обращаешься по ссылке.
А дальше ты вообще бредить начал: >>34510
>Я даже ХЗ как на это ответить. Давай начнём сначала. Вектор это одномерный массив, так он назывался в старом си.
В результате ты и сам запутался, и всех тут запутать пытаешься (а кого-то может и запутал). Или это я запутался? Не понимаю...
>Чтобы сохранять предыдущие значения, следует использовать сеттеры-геттеры примитивных типов
Так ведь Vector2.x и есть примитивный тип. Если ты обращаешься к свойству position, ты получаешь структуру из двух чисел, а если обращаешься к position.x, ты получаешь одно число. В большинстве языков ты не сохранишь значение, если сделаешь position.x = 2, т.е. обычно тебе нужно делать position = Vector2(2, position.y), чтобы действительно сохранить значение. Но интерпретатор GDScript упрощает эту операцию, неявно вызывая сеттер position с новым вектором, который сформирован из предыдущего значения и твоего нового значения для одного из компонент.
В результате, движок использует куда более эффективные в плане производительности struct, размещаемые на стеке, вместо дорогих объектов в куче, но при этом скриптовый язык упрощает типичную операцию для конечного пользователя (скриптописи).
А ты начал приплетать какие-то массивы и прочий бред, хотя массивами здесь и не пахнет (структура Vector2 имеет два поля с числами, но не является массивом с точки зрения компилятора исходников Godot).
Ты меня запутал, если честно.
Я уже не уверен, прав ли я...
Но у тебя аргументов нормальных нет вообще))
>>34673
Да нет там никакого "геттера свойства икс". В C++ коде я их не нашёл, если ты их где-то видел - дай ссылку (выше был пример ссылки на гитхаб). В GDScript эти x и y хотя и называются "свойствами" (property), но не подразумевают никаких get_x() и get_y() - нет там никаких геттеров. GDScript вообще не имеет отношения к C/C++, потому что он интерпретируется. Поэтому нужно смотреть на реализацию структуры Vector2 в исходниках движка, а не на описание Vector2 в документации на GDScript.
Нет, речь именно об этом. Array передаётся по ссылке. Vector2 передаётся по значению. В GDScript доступны массивы, которые передаются по значению, их имена начинаются с "pool" - так вот с ними работа особенная.
Допустим, у нас есть массив массивов arr. Если вложенный массив - Array, мы можем сделать так:
Это значение сохранится, потому что Array передаётся по ссылке. Мы буквально пишем "достань объект из нулевой ячейки arr и затем запиши в первую ячейку этого объекта двойку". Поскольку в нулевой ячейке лежит ссылка на массив, мы получаем не независимую копию массива, а прямой доступ к содержимому единственного экземпляра массива.
Но если вложенный в arr массив имеет тип PoolIntArray, тогда этот код не сохранит значение:
Смысл выражения тут тот же, что и в предыдущем случае, но мы получаем не ссылку на уникальный экземпляр массива, а независимую копию массива. Мы записываем данные в эту независимую копию, но саму эту копию никуда не записываем - поэтому данные теряются. Чтобы данные не терялись, придётся сделать так:
Теперь мы не просто меняем данные в массиве pool, но сохраняем эти данные обратно в arr.
Лол, ты всё перепутал. Новичок >>34472 спросил, почему вызывается сеттер и сохраняет изменённое значение вектора, если по его мнению это изменённое значение должно быть утрачено (и оно действительно будет утрачено в других языках программирования типа C# и Delphi, но речь идёт о поведении GDScript). Я >>34482 объяснил ему, почему происходит именно так, а не иначе:
Он правильно меня понял: >>34492
Но тут зачем-то влез ты с ошибкой: >>34506
А дальше ты вообще бредить начал: >>34510
В результате ты и сам запутался, и всех тут запутать пытаешься (а кого-то может и запутал). Или это я запутался? Не понимаю...
Так ведь Vector2.x и есть примитивный тип. Если ты обращаешься к свойству position, ты получаешь структуру из двух чисел, а если обращаешься к position.x, ты получаешь одно число. В большинстве языков ты не сохранишь значение, если сделаешь position.x = 2, т.е. обычно тебе нужно делать position = Vector2(2, position.y), чтобы действительно сохранить значение. Но интерпретатор GDScript упрощает эту операцию, неявно вызывая сеттер position с новым вектором, который сформирован из предыдущего значения и твоего нового значения для одного из компонент.
В результате, движок использует куда более эффективные в плане производительности struct, размещаемые на стеке, вместо дорогих объектов в куче, но при этом скриптовый язык упрощает типичную операцию для конечного пользователя (скриптописи).
А ты начал приплетать какие-то массивы и прочий бред, хотя массивами здесь и не пахнет (структура Vector2 имеет два поля с числами, но не является массивом с точки зрения компилятора исходников Godot).
Ты меня запутал, если честно.
Я уже не уверен, прав ли я...
Но у тебя аргументов нормальных нет вообще))
>геттер свойства X
Да нет там никакого "геттера свойства икс". В C++ коде я их не нашёл, если ты их где-то видел - дай ссылку (выше был пример ссылки на гитхаб). В GDScript эти x и y хотя и называются "свойствами" (property), но не подразумевают никаких get_x() и get_y() - нет там никаких геттеров. GDScript вообще не имеет отношения к C/C++, потому что он интерпретируется. Поэтому нужно смотреть на реализацию структуры Vector2 в исходниках движка, а не на описание Vector2 в документации на GDScript.
>речь не о том, по значению или по ссылке передаётся структура данных
Нет, речь именно об этом. Array передаётся по ссылке. Vector2 передаётся по значению. В GDScript доступны массивы, которые передаются по значению, их имена начинаются с "pool" - так вот с ними работа особенная.
Допустим, у нас есть массив массивов arr. Если вложенный массив - Array, мы можем сделать так:
>arr[0][1] = 2
Это значение сохранится, потому что Array передаётся по ссылке. Мы буквально пишем "достань объект из нулевой ячейки arr и затем запиши в первую ячейку этого объекта двойку". Поскольку в нулевой ячейке лежит ссылка на массив, мы получаем не независимую копию массива, а прямой доступ к содержимому единственного экземпляра массива.
Но если вложенный в arr массив имеет тип PoolIntArray, тогда этот код не сохранит значение:
>arr[0][1] = 2
Смысл выражения тут тот же, что и в предыдущем случае, но мы получаем не ссылку на уникальный экземпляр массива, а независимую копию массива. Мы записываем данные в эту независимую копию, но саму эту копию никуда не записываем - поэтому данные теряются. Чтобы данные не терялись, придётся сделать так:
>var pool: PoolIntArray = arr[0]
>pool[1] = 2
>arr[0] = pool
Теперь мы не просто меняем данные в массиве pool, но сохраняем эти данные обратно в arr.
>Новичок выкатывал скрины, где он накинул поверх комбинированной структуры сетгет, и искренне удивлялся, почему при перезаписи структуры целиком, у него пропадают значения. И я и ещё один анон уже два дня пытаемся ему объяснить, что если структуру перезаписывать целиком, то предыдущие значения очевидно не сохранятся.
Лол, ты всё перепутал. Новичок >>34472 спросил, почему вызывается сеттер и сохраняет изменённое значение вектора, если по его мнению это изменённое значение должно быть утрачено (и оно действительно будет утрачено в других языках программирования типа C# и Delphi, но речь идёт о поведении GDScript). Я >>34482 объяснил ему, почему происходит именно так, а не иначе:
>GDScript в данной ситуации сильно упрощает типичную операцию, избавляя от необходимости создавать промежуточную переменную.
Он правильно меня понял: >>34492
>Значит self.test_var.x = 111 это типа сахар для такого set_test_var(Vector2(111, get_test_var().y)
Но тут зачем-то влез ты с ошибкой: >>34506
>Так у тебя тут другое написано. Таким кодом ты явно создаешь копию значения, а не обращаешься по ссылке.
А дальше ты вообще бредить начал: >>34510
>Я даже ХЗ как на это ответить. Давай начнём сначала. Вектор это одномерный массив, так он назывался в старом си.
В результате ты и сам запутался, и всех тут запутать пытаешься (а кого-то может и запутал). Или это я запутался? Не понимаю...
>Чтобы сохранять предыдущие значения, следует использовать сеттеры-геттеры примитивных типов
Так ведь Vector2.x и есть примитивный тип. Если ты обращаешься к свойству position, ты получаешь структуру из двух чисел, а если обращаешься к position.x, ты получаешь одно число. В большинстве языков ты не сохранишь значение, если сделаешь position.x = 2, т.е. обычно тебе нужно делать position = Vector2(2, position.y), чтобы действительно сохранить значение. Но интерпретатор GDScript упрощает эту операцию, неявно вызывая сеттер position с новым вектором, который сформирован из предыдущего значения и твоего нового значения для одного из компонент.
В результате, движок использует куда более эффективные в плане производительности struct, размещаемые на стеке, вместо дорогих объектов в куче, но при этом скриптовый язык упрощает типичную операцию для конечного пользователя (скриптописи).
А ты начал приплетать какие-то массивы и прочий бред, хотя массивами здесь и не пахнет (структура Vector2 имеет два поля с числами, но не является массивом с точки зрения компилятора исходников Godot).
Ты меня запутал, если честно.
Я уже не уверен, прав ли я...
Но у тебя аргументов нормальных нет вообще))
>>34850
Да, сеттеров-геттеров там нет, но зато, я щас залез в исходники и охуел! Велик и могуч си++! Буду его учить. Что делает оператор union на скринах? Кто без гугла догадается? Там ничего сложного, но насколько эта конструкция элегантна!
Да, сеттеров-геттеров там нет, но зато, я щас залез в исходники и охуел! Велик и могуч си++! Буду его учить. Что делает оператор union на скринах? Кто без гугла догадается? Там ничего сложного, но насколько эта конструкция элегантна!
>>34853
Есть подозрение, что это undefined behavior (впрочем, скорее всего, работающее корректно везде)
https://stackoverflow.com/questions/53931021/c-i-think-my-union-may-be-producing-undefined-behaviour
Есть подозрение, что это undefined behavior (впрочем, скорее всего, работающее корректно везде)
https://stackoverflow.com/questions/53931021/c-i-think-my-union-may-be-producing-undefined-behaviour
>>34857
Я уже лет 30 знаю что такое union. Нашел эту ссылку, чтобы не писать самому длинное объяснение, почему это UB, а сразу сослаться на людей, разжвавших это по стандарту.
C/C++ - опасный нож, им можно заточить копья и пойти на охоту, а можно просто случайно напороться брюхом, неудачно встав со стула.
>А эта ссылка откуда взялась? Ты таки полез гуглить union, нашёл эту ссылку и прибежал хвастаться?
Я уже лет 30 знаю что такое union. Нашел эту ссылку, чтобы не писать самому длинное объяснение, почему это UB, а сразу сослаться на людей, разжвавших это по стандарту.
C/C++ - опасный нож, им можно заточить копья и пойти на охоту, а можно просто случайно напороться брюхом, неудачно встав со стула.
>>34689
Как это относится к тому, что ты передумал сделать яндере-тян в своей игре? Тем более, если ты хочешь полноценную симуляцию, архетип яндере в ней может спонтанно сформироваться (другое дело, что её быстро менты повяжут и будет сохнуть по сенпаю в тюрьме, если вообще сможет выжить).
Если некто или нечто создало целый новый мир (т.е. является богом для этого нового мира), разве оно обязано влиять на этот новый мир? Если мир имеет сложные свойства, за ним может быть интересно наблюдать даже без вмешательства.
Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
Не вижу никаких противоречий. В старые времена большинство школьников, наверное, были такими нищими, тупыми и слабыми (попробуй быть сильным, когда твоей семье жрать нечего). Да и сейчас они преобладают в странах третьего мира, наверное. Т.е. быть школьником не значит быть богатым, умным и сильным красавчиком. Особенно если у тебя что-то вроде средневековья по сеттингу (симулировать современный мир сложнее).
Это, на самом деле, несложно, особенно в твоём случае (2D). Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия. Большинство игр просто не нуждаются в изменениях мира, т.к. завязаны на сюжет. Но вот научить ИИ правильно реагировать на любую конфигурацию мира действительно очень сложно...
Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG (плюс - карту можно менять по тайтлам). Либо полностью текстовую, без иллюстраций. Нарисовать качественные иллюстрации для визуальной новеллы или пойнт-н-клик квеста с нуля не получится...
Это какая-то порнушная игра и тебе стыдно?)
>Начнём с того, что мир должен быть радикально изменяемым, второе мир... это мультивселенная со всеми вытекающими подводными.
Как это относится к тому, что ты передумал сделать яндере-тян в своей игре? Тем более, если ты хочешь полноценную симуляцию, архетип яндере в ней может спонтанно сформироваться (другое дело, что её быстро менты повяжут и будет сохнуть по сенпаю в тюрьме, если вообще сможет выжить).
>какой смысл быть богом, если ты не можешь влиять на мир?
Если некто или нечто создало целый новый мир (т.е. является богом для этого нового мира), разве оно обязано влиять на этот новый мир? Если мир имеет сложные свойства, за ним может быть интересно наблюдать даже без вмешательства.
>ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
>начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной
>попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод
Не вижу никаких противоречий. В старые времена большинство школьников, наверное, были такими нищими, тупыми и слабыми (попробуй быть сильным, когда твоей семье жрать нечего). Да и сейчас они преобладают в странах третьего мира, наверное. Т.е. быть школьником не значит быть богатым, умным и сильным красавчиком. Особенно если у тебя что-то вроде средневековья по сеттингу (симулировать современный мир сложнее).
>изменяемость мира
Это, на самом деле, несложно, особенно в твоём случае (2D). Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия. Большинство игр просто не нуждаются в изменениях мира, т.к. завязаны на сюжет. Но вот научить ИИ правильно реагировать на любую конфигурацию мира действительно очень сложно...
>Я вообще 0 в рисовании.
Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG (плюс - карту можно менять по тайтлам). Либо полностью текстовую, без иллюстраций. Нарисовать качественные иллюстрации для визуальной новеллы или пойнт-н-клик квеста с нуля не получится...
>Я бы назвал уже если бы планировал.
Это какая-то порнушная игра и тебе стыдно?)
>>34689
Как это относится к тому, что ты передумал сделать яндере-тян в своей игре? Тем более, если ты хочешь полноценную симуляцию, архетип яндере в ней может спонтанно сформироваться (другое дело, что её быстро менты повяжут и будет сохнуть по сенпаю в тюрьме, если вообще сможет выжить).
Если некто или нечто создало целый новый мир (т.е. является богом для этого нового мира), разве оно обязано влиять на этот новый мир? Если мир имеет сложные свойства, за ним может быть интересно наблюдать даже без вмешательства.
Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
Не вижу никаких противоречий. В старые времена большинство школьников, наверное, были такими нищими, тупыми и слабыми (попробуй быть сильным, когда твоей семье жрать нечего). Да и сейчас они преобладают в странах третьего мира, наверное. Т.е. быть школьником не значит быть богатым, умным и сильным красавчиком. Особенно если у тебя что-то вроде средневековья по сеттингу (симулировать современный мир сложнее).
Это, на самом деле, несложно, особенно в твоём случае (2D). Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия. Большинство игр просто не нуждаются в изменениях мира, т.к. завязаны на сюжет. Но вот научить ИИ правильно реагировать на любую конфигурацию мира действительно очень сложно...
Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG (плюс - карту можно менять по тайтлам). Либо полностью текстовую, без иллюстраций. Нарисовать качественные иллюстрации для визуальной новеллы или пойнт-н-клик квеста с нуля не получится...
Это какая-то порнушная игра и тебе стыдно?)
>Начнём с того, что мир должен быть радикально изменяемым, второе мир... это мультивселенная со всеми вытекающими подводными.
Как это относится к тому, что ты передумал сделать яндере-тян в своей игре? Тем более, если ты хочешь полноценную симуляцию, архетип яндере в ней может спонтанно сформироваться (другое дело, что её быстро менты повяжут и будет сохнуть по сенпаю в тюрьме, если вообще сможет выжить).
>какой смысл быть богом, если ты не можешь влиять на мир?
Если некто или нечто создало целый новый мир (т.е. является богом для этого нового мира), разве оно обязано влиять на этот новый мир? Если мир имеет сложные свойства, за ним может быть интересно наблюдать даже без вмешательства.
>ИИ неписей... надо думать, я предварительно знаю, что сделал бы, но едва ли у меня конечная идея.
Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
>начинать на самом социальном дне, бомжом тупым, слабым, без спец перков или способностей, наверное, только воля будет нормальной
>попробовать сделать его школьником, но при попытке скрестить оба статуса у меня бсод
Не вижу никаких противоречий. В старые времена большинство школьников, наверное, были такими нищими, тупыми и слабыми (попробуй быть сильным, когда твоей семье жрать нечего). Да и сейчас они преобладают в странах третьего мира, наверное. Т.е. быть школьником не значит быть богатым, умным и сильным красавчиком. Особенно если у тебя что-то вроде средневековья по сеттингу (симулировать современный мир сложнее).
>изменяемость мира
Это, на самом деле, несложно, особенно в твоём случае (2D). Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия. Большинство игр просто не нуждаются в изменениях мира, т.к. завязаны на сюжет. Но вот научить ИИ правильно реагировать на любую конфигурацию мира действительно очень сложно...
>Я вообще 0 в рисовании.
Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG (плюс - карту можно менять по тайтлам). Либо полностью текстовую, без иллюстраций. Нарисовать качественные иллюстрации для визуальной новеллы или пойнт-н-клик квеста с нуля не получится...
>Я бы назвал уже если бы планировал.
Это какая-то порнушная игра и тебе стыдно?)
бамп
>>34853
Я тебе ссылку позавчера давал...
Это вариативная часть структуры.
https://wiki.freepascal.org/Record#Variable_structure
>>34856
Код внешне отличается, а делает то же.
С этой:
Ты не можешь обращаться к вектору по ссылке, потому что векторы передаются по значению. Если бы векторы передавались по ссылке, то эта операция:
Изменяла бы содержимое position, а не buf.
>>34858
Нужно было выбирать второй стул.
>я щас залез в исходники и охуел!
Я тебе ссылку позавчера давал...
>Что делает оператор union на скринах?
Это вариативная часть структуры.
https://wiki.freepascal.org/Record#Variable_structure
>>34856
>Этот код отличается от изначального
Код внешне отличается, а делает то же.
>С какой ошибкой?
С этой:
>... а не обращаешься по ссылке.
Ты не можешь обращаться к вектору по ссылке, потому что векторы передаются по значению. Если бы векторы передавались по ссылке, то эта операция:
>var buf: Vector2 = position
>buf.x = 2
Изменяла бы содержимое position, а не buf.
>>34858
>C/C++ - опасный нож, им можно заточить копья и пойти на охоту, а можно просто случайно напороться брюхом, неудачно встав со стула.
Нужно было выбирать второй стул.
>>34863
Я писал больше про то, что self.test_var.x = 888 не то же самое, что pos = test_var; pos.x = 888. В том смысле, что меняется временный объект, а не test_var. Чел написал разный код с разным смыслом, а ожидал, что в обоих случаях будет работать одинаково.
Я писал больше про то, что self.test_var.x = 888 не то же самое, что pos = test_var; pos.x = 888. В том смысле, что меняется временный объект, а не test_var. Чел написал разный код с разным смыслом, а ожидал, что в обоих случаях будет работать одинаково.
Кто-нибудь разбирался, как включить OpenGL в Godot 4? Написано, что opengl добавлен уже в Beta 1 месяц назад.
Да, я знаю, что там пока даже теней в 3д нет, но я хотел пощупать новые 2д тайлмапы и экспорт в html5.
Из того, что нарыл - надо запускать редактор с параметром --single-window, в настройках проекта вписать rendering_device/driver строку "opengl3" буквами (не выпадающим списком) и выбрать renderer/rendering_method="gl_compatibility"
Вроде бы все, но может еще что-то упустил? Напишу если что-то сам нарою еще.
Да, я знаю, что там пока даже теней в 3д нет, но я хотел пощупать новые 2д тайлмапы и экспорт в html5.
Из того, что нарыл - надо запускать редактор с параметром --single-window, в настройках проекта вписать rendering_device/driver строку "opengl3" буквами (не выпадающим списком) и выбрать renderer/rendering_method="gl_compatibility"
Вроде бы все, но может еще что-то упустил? Напишу если что-то сам нарою еще.
179 Кб, 640x360>>34861
Никак, потому что ты жопой прочитал этот момент, если читал.
Я не намерен специально вводить архетип этот.
"Бог" -- слишком размытое понятие в культуре. У Лавкрафта боги есть, какой-нибудь Аполлон тоже бог, но не создавал мир, например. Так что твоё утверждение неверно, это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью. Аиду передаю привет.
Возможность должна быть, а так ты можешь косплеить Юкитеру Амано(пикрелейтед) после становления богом.
Есть такое, ожидаемо, буду думать.
А я вижу. Ты же знаешь, как БОМЖ расшифровывается? Без Определённого Места Жительства, я буквально назвал бомжом, а не фигурально
И это охренеть как плохо сочетается с необходимостью учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть в таком случае.
Я так и вижу сейчас.
Блядь, только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
Твайн. Он у меня есть, я могу писать на sugarcube2, но когда я понял что кучу вещей мне буквально для каждой локации придётся прописывать ручками, а просто взять и подтянуть из бд что нужно мне в узел, в котором хранится инфа о текущем состоянии мира, неписей и гг и раскидать где надо, хуй там пел, я решил, что он идёт в пизду, я питона душить пойду.
> Как это относится к тому, что ты передумал сделать яндере-тян в своей игре?
Никак, потому что ты жопой прочитал этот момент, если читал.
> я думал запилить с архетипом яндере что-то себе, такое было
> но решил что нахер-нахер
Я не намерен специально вводить архетип этот.
> т.е. является богом для этого нового мира
"Бог" -- слишком размытое понятие в культуре. У Лавкрафта боги есть, какой-нибудь Аполлон тоже бог, но не создавал мир, например. Так что твоё утверждение неверно, это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью. Аиду передаю привет.
> разве оно обязано влиять на этот новый мир
> какой смысл быть богом, если ты не можешь влиять на мир
Возможность должна быть, а так ты можешь косплеить Юкитеру Амано(пикрелейтед) после становления богом.
> Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
Есть такое, ожидаемо, буду думать.
> Не вижу никаких противоречий.
А я вижу. Ты же знаешь, как БОМЖ расшифровывается? Без Определённого Места Жительства, я буквально назвал бомжом, а не фигурально
И это охренеть как плохо сочетается с необходимостью учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть в таком случае.
> Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия
Я так и вижу сейчас.
> Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG
Блядь, только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
> Либо полностью текстовую, без иллюстраций.
Твайн. Он у меня есть, я могу писать на sugarcube2, но когда я понял что кучу вещей мне буквально для каждой локации придётся прописывать ручками, а просто взять и подтянуть из бд что нужно мне в узел, в котором хранится инфа о текущем состоянии мира, неписей и гг и раскидать где надо, хуй там пел, я решил, что он идёт в пизду, я питона душить пойду.
179 Кб, 640x360>>34861
Никак, потому что ты жопой прочитал этот момент, если читал.
Я не намерен специально вводить архетип этот.
"Бог" -- слишком размытое понятие в культуре. У Лавкрафта боги есть, какой-нибудь Аполлон тоже бог, но не создавал мир, например. Так что твоё утверждение неверно, это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью. Аиду передаю привет.
Возможность должна быть, а так ты можешь косплеить Юкитеру Амано(пикрелейтед) после становления богом.
Есть такое, ожидаемо, буду думать.
А я вижу. Ты же знаешь, как БОМЖ расшифровывается? Без Определённого Места Жительства, я буквально назвал бомжом, а не фигурально
И это охренеть как плохо сочетается с необходимостью учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть в таком случае.
Я так и вижу сейчас.
Блядь, только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
Твайн. Он у меня есть, я могу писать на sugarcube2, но когда я понял что кучу вещей мне буквально для каждой локации придётся прописывать ручками, а просто взять и подтянуть из бд что нужно мне в узел, в котором хранится инфа о текущем состоянии мира, неписей и гг и раскидать где надо, хуй там пел, я решил, что он идёт в пизду, я питона душить пойду.
> Как это относится к тому, что ты передумал сделать яндере-тян в своей игре?
Никак, потому что ты жопой прочитал этот момент, если читал.
> я думал запилить с архетипом яндере что-то себе, такое было
> но решил что нахер-нахер
Я не намерен специально вводить архетип этот.
> т.е. является богом для этого нового мира
"Бог" -- слишком размытое понятие в культуре. У Лавкрафта боги есть, какой-нибудь Аполлон тоже бог, но не создавал мир, например. Так что твоё утверждение неверно, это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью. Аиду передаю привет.
> разве оно обязано влиять на этот новый мир
> какой смысл быть богом, если ты не можешь влиять на мир
Возможность должна быть, а так ты можешь косплеить Юкитеру Амано(пикрелейтед) после становления богом.
> Это очень сложная тема. Скорее всего ты обнаружишь, что твои идеи не работают на практике, и нужно что-то другое. Если бы ИИ был бы простым, у нас бы давно были равные человеку роботы (хотя бы в играх типа ММО, вместо тупых болванчиков). А без ИИ быть "богом мира" очень скучно, это всё равно что быть "богом музыкальной шкатулки".
Есть такое, ожидаемо, буду думать.
> Не вижу никаких противоречий.
А я вижу. Ты же знаешь, как БОМЖ расшифровывается? Без Определённого Места Жительства, я буквально назвал бомжом, а не фигурально
И это охренеть как плохо сочетается с необходимостью учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть в таком случае.
> Мир - набор данных. Меняешь эти данные - меняется отображение на экране и доступные игроку опции/действия
Я так и вижу сейчас.
> Тогда тебе было бы проще сделать тайловую игру по типу 2D jRPG
Блядь, только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
> Либо полностью текстовую, без иллюстраций.
Твайн. Он у меня есть, я могу писать на sugarcube2, но когда я понял что кучу вещей мне буквально для каждой локации придётся прописывать ручками, а просто взять и подтянуть из бд что нужно мне в узел, в котором хранится инфа о текущем состоянии мира, неписей и гг и раскидать где надо, хуй там пел, я решил, что он идёт в пизду, я питона душить пойду.
>>34879
Для тайловой 2д игры подойдет любой движок, и даже без движка. Это же просто вывод плиток... Ну может еще z-sort для хитрой изометрии. Такие "движки" можно на завтрак писать...
Для тайловой 2д игры подойдет любой движок, и даже без движка. Это же просто вывод плиток... Ну может еще z-sort для хитрой изометрии. Такие "движки" можно на завтрак писать...
>>34868
В первом случае у тебя test_var меняется только благодаря тому, что интерпретатор Годо великодушно вызывает сеттер, который ты поленился вызывать.
Ещё раз, векторы передаются по значению, а не по ссылке, и по этой причине, в теории, ты не можешь присваить значения выражением self.test_var.x = , потому что они будут утрачены; но на практике ты всё-таки можешь так делать благодаря неявной помощи интерпретатора GDScript, который избавляет тебя от написания лишнего кода. Это не означает, что вектор передаётся по ссылке - нет, он не передаётся по ссылке, в этом легко убедиться. Если бы векторы передавались по ссылке, движок был бы в несколько раз медленнее, чем сейчас, и многие операции в коде требовали дополнительного кода (position.duplicate()).
>self.test_var.x = 888 не то же самое, что pos = test_var; pos.x = 888. В том смысле, что меняется временный объект, а не test_var
В первом случае у тебя test_var меняется только благодаря тому, что интерпретатор Годо великодушно вызывает сеттер, который ты поленился вызывать.
Ещё раз, векторы передаются по значению, а не по ссылке, и по этой причине, в теории, ты не можешь присваить значения выражением self.test_var.x = , потому что они будут утрачены; но на практике ты всё-таки можешь так делать благодаря неявной помощи интерпретатора GDScript, который избавляет тебя от написания лишнего кода. Это не означает, что вектор передаётся по ссылке - нет, он не передаётся по ссылке, в этом легко убедиться. Если бы векторы передавались по ссылке, движок был бы в несколько раз медленнее, чем сейчас, и многие операции в коде требовали дополнительного кода (position.duplicate()).
50 Кб, 584x394>>34890
У тебя путаница в терминах. Я не писал про "передается" ни слова. Под "передается" в программировании подразумевается передача аргументов в функцию. В годоте, конечно, нельзя передать вектор по ссылке напрямую, но можно, обернув в массив или объект.
Как видишь, значение вектору, хоть и присваивается по значению, обращается к вектору-элементу массива по ссылке, что отличается от того, как если бы было написано var pos = a[0]; pos.x = 42
У тебя путаница в терминах. Я не писал про "передается" ни слова. Под "передается" в программировании подразумевается передача аргументов в функцию. В годоте, конечно, нельзя передать вектор по ссылке напрямую, но можно, обернув в массив или объект.
Как видишь, значение вектору, хоть и присваивается по значению, обращается к вектору-элементу массива по ссылке, что отличается от того, как если бы было написано var pos = a[0]; pos.x = 42
13 Кб, 524x432>>34894
Не только это. Принципиальная разница в том, где выделяется память под переменную. Есть два места: стек вызовов и куча. Переменные на стеке существуют до тех пор, пока не произойдёт возврат из функции. Данные в куче доступны только по ссылке, которая хранится на стеке. Если у тебя переменная на стеке, ты должен явным образом вернуть её значение, если хочешь его сохранить. Если в куче - можешь не волноваться, пока сохраняешь ссылку.
Это имеет критическое значение в алгоритмах, которые, например, перебирают элементы массива. Если ты запишешь for element in array - компьютер будет последовательно копировать значение из каждой ячейки массива в переменную element, и если это значение - не ссылка на кучу, а ты вдруг записал в element какие-то данные, ты просто-напросто теряешь эти данные. Вот в динамический массив ты можешь писать данные через element, а в Vector... и Pool... - не можешь.
Изначально мы обсуждали проблему сеттеров и геттеров в классе. Геттер возвращает Vector2, и если ты в него что-то запишешь, это значение не вернётся в класс... но оно всё-таки вернётся через сеттер, потому что Godot сделан для ньюфагов в программировании и избавляет их от головной боли "почему я записал position.x = 100, а персонаж никуда с места не сдвинулся". Впрочем, это только моё предположение, возможно, причина в другом (нужно смотреть исходники интерпретатора).
>Под "передается" в программировании подразумевается передача аргументов в функцию.
Не только это. Принципиальная разница в том, где выделяется память под переменную. Есть два места: стек вызовов и куча. Переменные на стеке существуют до тех пор, пока не произойдёт возврат из функции. Данные в куче доступны только по ссылке, которая хранится на стеке. Если у тебя переменная на стеке, ты должен явным образом вернуть её значение, если хочешь его сохранить. Если в куче - можешь не волноваться, пока сохраняешь ссылку.
Это имеет критическое значение в алгоритмах, которые, например, перебирают элементы массива. Если ты запишешь for element in array - компьютер будет последовательно копировать значение из каждой ячейки массива в переменную element, и если это значение - не ссылка на кучу, а ты вдруг записал в element какие-то данные, ты просто-напросто теряешь эти данные. Вот в динамический массив ты можешь писать данные через element, а в Vector... и Pool... - не можешь.
>var pos = a[0]; pos.x = 42
Изначально мы обсуждали проблему сеттеров и геттеров в классе. Геттер возвращает Vector2, и если ты в него что-то запишешь, это значение не вернётся в класс... но оно всё-таки вернётся через сеттер, потому что Godot сделан для ньюфагов в программировании и избавляет их от головной боли "почему я записал position.x = 100, а персонаж никуда с места не сдвинулся". Впрочем, это только моё предположение, возможно, причина в другом (нужно смотреть исходники интерпретатора).
>>34901
Я тебе говорю про терминологическую путаницу. "передача" означает, буквально, передавать (отдавать из одной функции в другую).
Геттеры и сеттеры тут тоже не в тему. Геттеры и сеттеры - это функции, которые вызываются при изменении или чтении переменной.
Я тебе говорю про терминологическую путаницу. "передача" означает, буквально, передавать (отдавать из одной функции в другую).
Геттеры и сеттеры тут тоже не в тему. Геттеры и сеттеры - это функции, которые вызываются при изменении или чтении переменной.
>>34901
Короче.
Предлагаю компромиссное решение для всех: Если нужен вектор по ссылке, юзаем массив из двух значений, для удобства добавим куда-нибудь в общий скрипт такие хелперы:
Короче.
Предлагаю компромиссное решение для всех: Если нужен вектор по ссылке, юзаем массив из двух значений, для удобства добавим куда-нибудь в общий скрипт такие хелперы:
> static func Vector2Array(v: Vector2) -> Array: return [v.x, v.y]
> static func Array2Vector(a: Array) -> Vector2: return Vector2.ZERO if ((not a) and (a.size() != 2) and ((typeof(a[0]) != TYPE_REAL) or (typeof(a[0]) != TYPE_INT)) and ((typeof(a[1]) != TYPE_REAL) or (typeof(a[1]) != TYPE_INT))) else Vector2(a[0], a[1])
>>34879
Ты просто непонятно пишешь.
С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями. Подумай сам:
1. Игрок видит графику и слышит звуки, тогда как неписи в лучшем случае шарятся рейкастами, а в худшем - вообще слепы, глухи и неподвижны.
2. Игрок обладает потусторонними знаниями и навыками, которые для неписей непостижимы и недоступны.
3. Игрок, в большинстве случаев, обладает бОльшими способностями, наносит больше и получает меньше урона, способен создавать новые предметы, обладает бездонным или невероятно глубоким "инвентарём", способен видеть врагов сквозь стены и т.д.
4. Игрок может даже остановить время, обратить время вспять, поменять ход событий произвольным образом, знать события заранее, даже если впервые играет, и в некоторых случаях способен нарушить правила мира путём потусторонних махинаций с материей мира, даже не запуская игру.
5. В большинстве игр мир вращается вокруг игрока и многие существа исчезают, когда игрок уходит от них на достаточное расстояние, или становятся медленнее и тупее в его отсутствие. Неписи дают задания только игроку, как будто зная, что только столь могущественное потустороннее существо способно решить их проблемы.
Короче, если бы мы переместили какого-нибудь древнего человека из прошлого в наше время, и объяснили бы ему суть и устройство видеоигр - он бы считал, что мы играем в богов, и игрок в любой игре играет роль бога. Так что ли получается? Все эти "ты играешь за бомжа" - фальшивка, красивый фантик, скрывающий истину.
В твоей формулировке для становления богом достаточно запустить любую игру и потешаться над немощными мобами/нпц, оргазмируя от своей сверхъестественной сути высшего существа из потустороннего мира.
Ты как будто БОМЖей не видел. У них нет легального места жительства, но где-то они всё-таки обитают и могут получать образование и даже работать. Особенно если посмотреть на опыт западных стран, в которых некоторые самые натуральные БОМЖи взаправду работают в IT с какого-нибудь обшарпанного ноутбука, сидя на трубе горячего водоснабжения и заряжаясь неизвестно где. Киберпанк, который мы не ожидали, но заслужили. Алсо, БОМЖ вполне может владеть автомобилем или автодомом, т.к. это не является местом жительства. А что с семьёй не так? Почему у БОМЖа не может быть семьи-то? Живут всей семьёй под мостом в ржавой копейке и подрабатывают кто чем может, мечтая об отапливаемой однушке на краю мира.
С точки зрения геймдизайна, я не вижу проблемы в том, что игрок начинает, скажем, 16-летним выходцем из трущоб, который учится в местной убитой в хлам школе и живёт со своей быдловатой семьёй в картонной коробке, палатке, отработавшей ракетной ступени, списанном вагоне или ржавой машине, опасаясь выселения властями. Денег нет, вещей, кроме найденных на свалке и полученных в дар от организации помощи бедным, нет, в школе бардак вместо занятий из-за того, что все школьники такое же быдло, как и вся его родня, и лишь мечта выбраться из этой гнилой дыры в большой город с его манящими огнями и тёплыми домами удерживает его от суицида или преступлений. Что не так-то? Это куда более реалистичная история, чем хотелось бы.
Что? Ты про RPG Maker? А я не про него, я про жанр игр. На Godot сделать игру такого жанра несложно, есть хорошая поддержка тайловых карт и туториалы. Вопрос в том, хочешь ли ты видеть свою игру в таком виде. Хотя, ничто не мешает отрендерить модель мира в разных вариантах, например, тайловый рендер подойдёт для создания карты мира или миникарты в меню.
>>34881
Некоторые функции всё же сложно писать. Тот же автотайлинг, например, если хочешь красивые переходы между тайлами разных видов. Или физика и освещение, если у тебя не jRPG, а топ-даун бродилка с наворотами. В целом, лучше взять Godot и попробовать сделать на нём, чем писать что-то с нуля и убедиться, что ты кучу времени тратишь на базовые функции.
>жопой прочитал этот момент
Ты просто непонятно пишешь.
>это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью.
С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями. Подумай сам:
1. Игрок видит графику и слышит звуки, тогда как неписи в лучшем случае шарятся рейкастами, а в худшем - вообще слепы, глухи и неподвижны.
2. Игрок обладает потусторонними знаниями и навыками, которые для неписей непостижимы и недоступны.
3. Игрок, в большинстве случаев, обладает бОльшими способностями, наносит больше и получает меньше урона, способен создавать новые предметы, обладает бездонным или невероятно глубоким "инвентарём", способен видеть врагов сквозь стены и т.д.
4. Игрок может даже остановить время, обратить время вспять, поменять ход событий произвольным образом, знать события заранее, даже если впервые играет, и в некоторых случаях способен нарушить правила мира путём потусторонних махинаций с материей мира, даже не запуская игру.
5. В большинстве игр мир вращается вокруг игрока и многие существа исчезают, когда игрок уходит от них на достаточное расстояние, или становятся медленнее и тупее в его отсутствие. Неписи дают задания только игроку, как будто зная, что только столь могущественное потустороннее существо способно решить их проблемы.
Короче, если бы мы переместили какого-нибудь древнего человека из прошлого в наше время, и объяснили бы ему суть и устройство видеоигр - он бы считал, что мы играем в богов, и игрок в любой игре играет роль бога. Так что ли получается? Все эти "ты играешь за бомжа" - фальшивка, красивый фантик, скрывающий истину.
>после становления богом
В твоей формулировке для становления богом достаточно запустить любую игру и потешаться над немощными мобами/нпц, оргазмируя от своей сверхъестественной сути высшего существа из потустороннего мира.
>Без Определённого Места Жительства
>учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть
Ты как будто БОМЖей не видел. У них нет легального места жительства, но где-то они всё-таки обитают и могут получать образование и даже работать. Особенно если посмотреть на опыт западных стран, в которых некоторые самые натуральные БОМЖи взаправду работают в IT с какого-нибудь обшарпанного ноутбука, сидя на трубе горячего водоснабжения и заряжаясь неизвестно где. Киберпанк, который мы не ожидали, но заслужили. Алсо, БОМЖ вполне может владеть автомобилем или автодомом, т.к. это не является местом жительства. А что с семьёй не так? Почему у БОМЖа не может быть семьи-то? Живут всей семьёй под мостом в ржавой копейке и подрабатывают кто чем может, мечтая об отапливаемой однушке на краю мира.
С точки зрения геймдизайна, я не вижу проблемы в том, что игрок начинает, скажем, 16-летним выходцем из трущоб, который учится в местной убитой в хлам школе и живёт со своей быдловатой семьёй в картонной коробке, палатке, отработавшей ракетной ступени, списанном вагоне или ржавой машине, опасаясь выселения властями. Денег нет, вещей, кроме найденных на свалке и полученных в дар от организации помощи бедным, нет, в школе бардак вместо занятий из-за того, что все школьники такое же быдло, как и вся его родня, и лишь мечта выбраться из этой гнилой дыры в большой город с его манящими огнями и тёплыми домами удерживает его от суицида или преступлений. Что не так-то? Это куда более реалистичная история, чем хотелось бы.
>2D jRPG
>только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
Что? Ты про RPG Maker? А я не про него, я про жанр игр. На Godot сделать игру такого жанра несложно, есть хорошая поддержка тайловых карт и туториалы. Вопрос в том, хочешь ли ты видеть свою игру в таком виде. Хотя, ничто не мешает отрендерить модель мира в разных вариантах, например, тайловый рендер подойдёт для создания карты мира или миникарты в меню.
>>34881
>Для тайловой 2д игры подойдет любой движок, и даже без движка. Это же просто вывод плиток...
Некоторые функции всё же сложно писать. Тот же автотайлинг, например, если хочешь красивые переходы между тайлами разных видов. Или физика и освещение, если у тебя не jRPG, а топ-даун бродилка с наворотами. В целом, лучше взять Godot и попробовать сделать на нём, чем писать что-то с нуля и убедиться, что ты кучу времени тратишь на базовые функции.
>>34879
Ты просто непонятно пишешь.
С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями. Подумай сам:
1. Игрок видит графику и слышит звуки, тогда как неписи в лучшем случае шарятся рейкастами, а в худшем - вообще слепы, глухи и неподвижны.
2. Игрок обладает потусторонними знаниями и навыками, которые для неписей непостижимы и недоступны.
3. Игрок, в большинстве случаев, обладает бОльшими способностями, наносит больше и получает меньше урона, способен создавать новые предметы, обладает бездонным или невероятно глубоким "инвентарём", способен видеть врагов сквозь стены и т.д.
4. Игрок может даже остановить время, обратить время вспять, поменять ход событий произвольным образом, знать события заранее, даже если впервые играет, и в некоторых случаях способен нарушить правила мира путём потусторонних махинаций с материей мира, даже не запуская игру.
5. В большинстве игр мир вращается вокруг игрока и многие существа исчезают, когда игрок уходит от них на достаточное расстояние, или становятся медленнее и тупее в его отсутствие. Неписи дают задания только игроку, как будто зная, что только столь могущественное потустороннее существо способно решить их проблемы.
Короче, если бы мы переместили какого-нибудь древнего человека из прошлого в наше время, и объяснили бы ему суть и устройство видеоигр - он бы считал, что мы играем в богов, и игрок в любой игре играет роль бога. Так что ли получается? Все эти "ты играешь за бомжа" - фальшивка, красивый фантик, скрывающий истину.
В твоей формулировке для становления богом достаточно запустить любую игру и потешаться над немощными мобами/нпц, оргазмируя от своей сверхъестественной сути высшего существа из потустороннего мира.
Ты как будто БОМЖей не видел. У них нет легального места жительства, но где-то они всё-таки обитают и могут получать образование и даже работать. Особенно если посмотреть на опыт западных стран, в которых некоторые самые натуральные БОМЖи взаправду работают в IT с какого-нибудь обшарпанного ноутбука, сидя на трубе горячего водоснабжения и заряжаясь неизвестно где. Киберпанк, который мы не ожидали, но заслужили. Алсо, БОМЖ вполне может владеть автомобилем или автодомом, т.к. это не является местом жительства. А что с семьёй не так? Почему у БОМЖа не может быть семьи-то? Живут всей семьёй под мостом в ржавой копейке и подрабатывают кто чем может, мечтая об отапливаемой однушке на краю мира.
С точки зрения геймдизайна, я не вижу проблемы в том, что игрок начинает, скажем, 16-летним выходцем из трущоб, который учится в местной убитой в хлам школе и живёт со своей быдловатой семьёй в картонной коробке, палатке, отработавшей ракетной ступени, списанном вагоне или ржавой машине, опасаясь выселения властями. Денег нет, вещей, кроме найденных на свалке и полученных в дар от организации помощи бедным, нет, в школе бардак вместо занятий из-за того, что все школьники такое же быдло, как и вся его родня, и лишь мечта выбраться из этой гнилой дыры в большой город с его манящими огнями и тёплыми домами удерживает его от суицида или преступлений. Что не так-то? Это куда более реалистичная история, чем хотелось бы.
Что? Ты про RPG Maker? А я не про него, я про жанр игр. На Godot сделать игру такого жанра несложно, есть хорошая поддержка тайловых карт и туториалы. Вопрос в том, хочешь ли ты видеть свою игру в таком виде. Хотя, ничто не мешает отрендерить модель мира в разных вариантах, например, тайловый рендер подойдёт для создания карты мира или миникарты в меню.
>>34881
Некоторые функции всё же сложно писать. Тот же автотайлинг, например, если хочешь красивые переходы между тайлами разных видов. Или физика и освещение, если у тебя не jRPG, а топ-даун бродилка с наворотами. В целом, лучше взять Godot и попробовать сделать на нём, чем писать что-то с нуля и убедиться, что ты кучу времени тратишь на базовые функции.
>жопой прочитал этот момент
Ты просто непонятно пишешь.
>это скорее сверхъестественная сущность способная, но не обязаная созидать, но обязательно имеющая сверхъестественные способности и являющаяся высшей сущностью.
С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями. Подумай сам:
1. Игрок видит графику и слышит звуки, тогда как неписи в лучшем случае шарятся рейкастами, а в худшем - вообще слепы, глухи и неподвижны.
2. Игрок обладает потусторонними знаниями и навыками, которые для неписей непостижимы и недоступны.
3. Игрок, в большинстве случаев, обладает бОльшими способностями, наносит больше и получает меньше урона, способен создавать новые предметы, обладает бездонным или невероятно глубоким "инвентарём", способен видеть врагов сквозь стены и т.д.
4. Игрок может даже остановить время, обратить время вспять, поменять ход событий произвольным образом, знать события заранее, даже если впервые играет, и в некоторых случаях способен нарушить правила мира путём потусторонних махинаций с материей мира, даже не запуская игру.
5. В большинстве игр мир вращается вокруг игрока и многие существа исчезают, когда игрок уходит от них на достаточное расстояние, или становятся медленнее и тупее в его отсутствие. Неписи дают задания только игроку, как будто зная, что только столь могущественное потустороннее существо способно решить их проблемы.
Короче, если бы мы переместили какого-нибудь древнего человека из прошлого в наше время, и объяснили бы ему суть и устройство видеоигр - он бы считал, что мы играем в богов, и игрок в любой игре играет роль бога. Так что ли получается? Все эти "ты играешь за бомжа" - фальшивка, красивый фантик, скрывающий истину.
>после становления богом
В твоей формулировке для становления богом достаточно запустить любую игру и потешаться над немощными мобами/нпц, оргазмируя от своей сверхъестественной сути высшего существа из потустороннего мира.
>Без Определённого Места Жительства
>учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть
Ты как будто БОМЖей не видел. У них нет легального места жительства, но где-то они всё-таки обитают и могут получать образование и даже работать. Особенно если посмотреть на опыт западных стран, в которых некоторые самые натуральные БОМЖи взаправду работают в IT с какого-нибудь обшарпанного ноутбука, сидя на трубе горячего водоснабжения и заряжаясь неизвестно где. Киберпанк, который мы не ожидали, но заслужили. Алсо, БОМЖ вполне может владеть автомобилем или автодомом, т.к. это не является местом жительства. А что с семьёй не так? Почему у БОМЖа не может быть семьи-то? Живут всей семьёй под мостом в ржавой копейке и подрабатывают кто чем может, мечтая об отапливаемой однушке на краю мира.
С точки зрения геймдизайна, я не вижу проблемы в том, что игрок начинает, скажем, 16-летним выходцем из трущоб, который учится в местной убитой в хлам школе и живёт со своей быдловатой семьёй в картонной коробке, палатке, отработавшей ракетной ступени, списанном вагоне или ржавой машине, опасаясь выселения властями. Денег нет, вещей, кроме найденных на свалке и полученных в дар от организации помощи бедным, нет, в школе бардак вместо занятий из-за того, что все школьники такое же быдло, как и вся его родня, и лишь мечта выбраться из этой гнилой дыры в большой город с его манящими огнями и тёплыми домами удерживает его от суицида или преступлений. Что не так-то? Это куда более реалистичная история, чем хотелось бы.
>2D jRPG
>только не это. Я знаю, что это за двиг и я не хочу с ним взаимодействовать.
Что? Ты про RPG Maker? А я не про него, я про жанр игр. На Godot сделать игру такого жанра несложно, есть хорошая поддержка тайловых карт и туториалы. Вопрос в том, хочешь ли ты видеть свою игру в таком виде. Хотя, ничто не мешает отрендерить модель мира в разных вариантах, например, тайловый рендер подойдёт для создания карты мира или миникарты в меню.
>>34881
>Для тайловой 2д игры подойдет любой движок, и даже без движка. Это же просто вывод плиток...
Некоторые функции всё же сложно писать. Тот же автотайлинг, например, если хочешь красивые переходы между тайлами разных видов. Или физика и освещение, если у тебя не jRPG, а топ-даун бродилка с наворотами. В целом, лучше взять Godot и попробовать сделать на нём, чем писать что-то с нуля и убедиться, что ты кучу времени тратишь на базовые функции.
>>34472
>>34903
Да, вообще не в тему...
Вот именно! Если ты напрямую обращаешься к полю класса, то ты обращаешься напрямую по ссылке в кучу, а если ты через геттер запрашиваешь у класса какое-то его свойство, то ты получаешь КОПИЮ содержимого этого свойства, и если эта копия содержит ЗНАЧЕНИЕ, А НЕ ССЫЛКУ на другое место в куче, то ты его должен вернуть через сеттер, чтобы сохранить изменения. Но как минимум для векторов Godot решает эту проблему автоматически, чтобы тебе не пришлось писать слишком много буковок.
Ещё раз: если ты запрашиваешь у класса через геттер вектор, то ты получаешь копию вектора, которую нужно записать через сеттер обратно в класс, иначе ты потеряешь свои изменения. Это верно для многих ЯП и движков на их основе, но не для GDScript в Godot.
>>34905
Да не нужен никому вектор по ссылке, успокойся.
>Поясните за сеттеры, геттеры.
>>34903
>Геттеры и сеттеры тут тоже не в тему.
Да, вообще не в тему...
>Геттеры и сеттеры - это функции, которые вызываются при изменении или чтении переменной.
Вот именно! Если ты напрямую обращаешься к полю класса, то ты обращаешься напрямую по ссылке в кучу, а если ты через геттер запрашиваешь у класса какое-то его свойство, то ты получаешь КОПИЮ содержимого этого свойства, и если эта копия содержит ЗНАЧЕНИЕ, А НЕ ССЫЛКУ на другое место в куче, то ты его должен вернуть через сеттер, чтобы сохранить изменения. Но как минимум для векторов Godot решает эту проблему автоматически, чтобы тебе не пришлось писать слишком много буковок.
Ещё раз: если ты запрашиваешь у класса через геттер вектор, то ты получаешь копию вектора, которую нужно записать через сеттер обратно в класс, иначе ты потеряешь свои изменения. Это верно для многих ЯП и движков на их основе, но не для GDScript в Godot.
>>34905
>Если нужен вектор по ссылке, юзаем массив
Да не нужен никому вектор по ссылке, успокойся.
>>34879
Напомнил мне одну кулстори, короче когда я был студентом, я ушел из дома и целые ночи проводил в компьютерных клубах, и подружился там с веселыми пацанами, их называли у нас "аскерами" потому что они клянчили мелочь, и "помо(е)шниками", потому что помогали админу прибираться в клубе, отскребать мусор со столов и выковыривать травку из под клавиатур, за это им давали минут 15 игровремени, и конечно они все время пытались сесть за комп, если кто-то раньше оплаченного времени ушел или вышел покурить. И вот так шло полгода, и вдруг один из этих пацанов вместо обычно замызаного, грязного вида, после ночевки в подъезде, входит в клуб в идеальном костюмчике, с уложенной прической, и прощается с нами со всеми - объясняет, что родители решили заняться его воспитанием, и они переезжают в Англию, где его уже устроили в школу. Конечно многие позавидовали. Потом как-то админ тоже уволился, сказал ну это все, я ухожу в семейный бизнес, торговать оливковым маслом. Вот такие сюжеты иногда жизнь подкидывает, круче чем в некоторых аниме
>И это охренеть как плохо сочетается с необходимостью учиться в школе, делать домашку и при этом как-то работать и саморазвиваться. Про семью тоже можно забыть в таком случае.
Напомнил мне одну кулстори, короче когда я был студентом, я ушел из дома и целые ночи проводил в компьютерных клубах, и подружился там с веселыми пацанами, их называли у нас "аскерами" потому что они клянчили мелочь, и "помо(е)шниками", потому что помогали админу прибираться в клубе, отскребать мусор со столов и выковыривать травку из под клавиатур, за это им давали минут 15 игровремени, и конечно они все время пытались сесть за комп, если кто-то раньше оплаченного времени ушел или вышел покурить. И вот так шло полгода, и вдруг один из этих пацанов вместо обычно замызаного, грязного вида, после ночевки в подъезде, входит в клуб в идеальном костюмчике, с уложенной прической, и прощается с нами со всеми - объясняет, что родители решили заняться его воспитанием, и они переезжают в Англию, где его уже устроили в школу. Конечно многие позавидовали. Потом как-то админ тоже уволился, сказал ну это все, я ухожу в семейный бизнес, торговать оливковым маслом. Вот такие сюжеты иногда жизнь подкидывает, круче чем в некоторых аниме
>>34918
Сеттер и геттер в годоте - это setget, то, что в других языках называется property. Это функции, которые могут изменить значение, например в целях валидации (если какое-то значение может быть от 0 до 10, то можно все вне диапазона сначала привести к нему.)
Не надо говорить за всех.
Сеттер и геттер в годоте - это setget, то, что в других языках называется property. Это функции, которые могут изменить значение, например в целях валидации (если какое-то значение может быть от 0 до 10, то можно все вне диапазона сначала привести к нему.)
>Да не нужен никому вектор по ссылке
Не надо говорить за всех.
>>34925
Штош, тем лучше.
Штош, тем лучше.
>>34922
Кому ты это объясняешь? Я это и так знаю. Тот анон выше, с которого началось это затянувшееся обсуждение, тоже знает, что такое setget и зачем.
А не надо давать вредные советы. Кому ОЧЕНЬ надо - сами догадаются, что и как. Остальные пусть пользуются встроенными функциями как задумано, а не делают велосипед с квадратными колёсами непонятно зачем.
>Сеттер и геттер в годоте - это setget
Кому ты это объясняешь? Я это и так знаю. Тот анон выше, с которого началось это затянувшееся обсуждение, тоже знает, что такое setget и зачем.
>Не надо говорить за всех.
А не надо давать вредные советы. Кому ОЧЕНЬ надо - сами догадаются, что и как. Остальные пусть пользуются встроенными функциями как задумано, а не делают велосипед с квадратными колёсами непонятно зачем.
>>34931
Тебе. Потому что зачем-то упорно продолжаешь писать про сеттеры и геттеры у полей вектора, у которого никакого setget не объявлено.
Ну такой себе подход. Умышленно обманывать новичков, скрывая от них конструкции языка?
>Кому ты это объясняешь?
Тебе. Потому что зачем-то упорно продолжаешь писать про сеттеры и геттеры у полей вектора, у которого никакого setget не объявлено.
>А не надо давать вредные советы. Кому ОЧЕНЬ надо - сами догадаются, что и как
Ну такой себе подход. Умышленно обманывать новичков, скрывая от них конструкции языка?
>>34939
Это ты про них начал писать, а не я. Я же сразу сказал, что таких геттеров у вектора в исходниках нет.
Так это ты начал про "вектор это массив", а я быстро, решительно кинул ссылку на исходники Годо на гитхабе, где чётко сказано, что вектор - это struct.
По-моему, у нас завелась крыса - разжигает срачи.
>сеттеры и геттеры у полей вектора
Это ты про них начал писать, а не я. Я же сразу сказал, что таких геттеров у вектора в исходниках нет.
>скрывая от них конструкции языка
Так это ты начал про "вектор это массив", а я быстро, решительно кинул ссылку на исходники Годо на гитхабе, где чётко сказано, что вектор - это struct.
По-моему, у нас завелась крыса - разжигает срачи.
>>34944
Но при этом зачем-то продолжаешь называть геттерами что-то другое, а не то, что называют ими в годоте, хотя сам говоришь, что геттеров нет.
Это уже просто дезинформация, я ни разу такого не писал - а привел пример, где к вектору идет обращение через массив, переданный по ссылке.
Это вообще не причем, в gdscript нет struct, это разные языки (язык интерпретатора может обеспечиваться совсем другими конструкциями). К примеру, в c++ нет типа Variant.
Так ты вроде тут давно этим занимаешься.
>Это ты про них начал писать, а не я. Я же сразу сказал, что таких геттеров у вектора в исходниках нет.
Но при этом зачем-то продолжаешь называть геттерами что-то другое, а не то, что называют ими в годоте, хотя сам говоришь, что геттеров нет.
>ак это ты начал про "вектор это массив"
Это уже просто дезинформация, я ни разу такого не писал - а привел пример, где к вектору идет обращение через массив, переданный по ссылке.
>исходники Годо на гитхабе, где чётко сказано, что вектор - это struct.
Это вообще не причем, в gdscript нет struct, это разные языки (язык интерпретатора может обеспечиваться совсем другими конструкциями). К примеру, в c++ нет типа Variant.
>По-моему, у нас завелась крыса - разжигает срачи.
Так ты вроде тут давно этим занимаешься.
>>34931
Очень даже понятно зачем. Сагрить на себя тред, наделать скринов и хвастаться в срачетреде.
> непонятно зачем
Очень даже понятно зачем. Сагрить на себя тред, наделать скринов и хвастаться в срачетреде.
>>34948
А это кто писал >>34510 >>34590 ?
Не надо дурака валять, тут 3.5 анона на всей борде и 1.5 из них пишут в этот тред. Если это был не ты, то зачем вообще было встревать с какими-то массивами?
Ты не знаешь, как работают интерпретаторы?
Интерпретатор видит команду в тексте. Ищет команду в своей таблице команд. Если находит, вызывает связанную с ней функцию того языка, на котором он написан. В данном случае мы имеем дело с движком на C++, следовательно, весь код на GDScript транслируется в C++. Это база, это знать надо. Хотя, тебе простительно это не знать, если ты новичок в программировании и не пытался писать собственный интерпретатор или компилятор.
>дезинформация, я ни разу такого не писал
А это кто писал >>34510 >>34590 ?
Не надо дурака валять, тут 3.5 анона на всей борде и 1.5 из них пишут в этот тред. Если это был не ты, то зачем вообще было встревать с какими-то массивами?
>язык интерпретатора может обеспечиваться совсем другими конструкциями
Ты не знаешь, как работают интерпретаторы?
Интерпретатор видит команду в тексте. Ищет команду в своей таблице команд. Если находит, вызывает связанную с ней функцию того языка, на котором он написан. В данном случае мы имеем дело с движком на C++, следовательно, весь код на GDScript транслируется в C++. Это база, это знать надо. Хотя, тебе простительно это не знать, если ты новичок в программировании и не пытался писать собственный интерпретатор или компилятор.
4 Кб, 353x75>>34953
Думаю, тот кто задавал изначальный вопрос (но это не точно)
Тут минимум 3 годотера в треде. На самом деле, такое общение наиболее интересно, чем двое, когда один всегда прав, а другой всегда неправ, тут есть перекрывающиеся пересечения знаний и можно продолжать обмениваться инфой.
Я лишь иллюстрировал передачу по ссылке.
Компиляторы и интерпретаторы - подмножества трансляторов, так что это определение тут тоже не причем.
Речь шла о том, что пофиг, что у хоста struct. Это разные языки, описываемые разным BNF.
Аналогия к твоему заблуждению - транслятор переводит с одного языка на другого (с русского на английский или немецкий), в целевом языке есть артикли (a/the, die/das/der), ты утверждаешь что они есть и в русском (по аналогии с struct в c++)
Можно объяснить по другому - передача по значению в гдскрипте могла бы быть реализована и без структур в c++, на каких-нибудь указателях, и наоборот, передача по ссылке могла бы под капотом обрабатываться какой-либо структурой (которая эмулировала бы указатель через int id.)
>А это кто писал
Думаю, тот кто задавал изначальный вопрос (но это не точно)
>тут 3.5 анона на всей борде и 1.5 из них пишут в этот тред.
Тут минимум 3 годотера в треде. На самом деле, такое общение наиболее интересно, чем двое, когда один всегда прав, а другой всегда неправ, тут есть перекрывающиеся пересечения знаний и можно продолжать обмениваться инфой.
>зачем вообще было встревать с какими-то массивами?
Я лишь иллюстрировал передачу по ссылке.
> код на GDScript транслируется в C++
Компиляторы и интерпретаторы - подмножества трансляторов, так что это определение тут тоже не причем.
Речь шла о том, что пофиг, что у хоста struct. Это разные языки, описываемые разным BNF.
Аналогия к твоему заблуждению - транслятор переводит с одного языка на другого (с русского на английский или немецкий), в целевом языке есть артикли (a/the, die/das/der), ты утверждаешь что они есть и в русском (по аналогии с struct в c++)
Можно объяснить по другому - передача по значению в гдскрипте могла бы быть реализована и без структур в c++, на каких-нибудь указателях, и наоборот, передача по ссылке могла бы под капотом обрабатываться какой-либо структурой (которая эмулировала бы указатель через int id.)
>>34914
Это вроде не трудно... Что там, берем wang tiles, накидываем рандом для вариаций тайлов из одной группы.
https://www.reddit.com/r/roguelikedev/comments/b13zxk/algorithms_for_determining_which_tile_graphic_to/
Но, конечно, сейчас хочу пощупать тайловые террейны в четверке, по описанию круто, но все таки надо попробовать на практике, а то мало ли.
>Тот же автотайлинг, например, если хочешь красивые переходы между тайлами разных видов.
Это вроде не трудно... Что там, берем wang tiles, накидываем рандом для вариаций тайлов из одной группы.
https://www.reddit.com/r/roguelikedev/comments/b13zxk/algorithms_for_determining_which_tile_graphic_to/
Но, конечно, сейчас хочу пощупать тайловые террейны в четверке, по описанию круто, но все таки надо попробовать на практике, а то мало ли.
>>34914
Разрешите вклиниться в ваш диалог. Я когда-то даже хотел запилить игру об этом. С разрушением четвёртой стены. Но идея слишком амбициозная, нужна целая студия для реализации задумки, тогда я думал, что запилю в одиночку, но практика больно стукнула по рукам.
В общем, суть токова: игрок играет ангелом хранителем персонажа. Всё почти так же, как в типичных тридэ эрпогэ. Перед стартом долго настраиваешь внешность персонажа. Смотришь вступительный синематик с эпичной музыкой. И начинается игра. Но есть кардинальные отличия. Ты свободной камерой перемещаешься вокруг персонажа. Ты не можешь им прямо управлять (хотя после прокачки такая возможность может появиться). На действия персонажа ты влияешь поначалу очень слабо. Пример: У тебя в интерфейсе есть курсор-прицел, наведя его на сундук ты можешь нажать кнопку Е. В обычных играх что происходит? Жёстко прибитый гвоздями к игроку персонаж от лица игрока открывает сундук. И на этом разработчики пытаются создать вживляемость игрока в мир, отыгрыш. В моей же концепции, мы отыгрываем не самого персонажа, а бестелесный дух, помогающий (а может и вредящий) герою/героине. Гемплей поначалу фактический пойнт и клик. Ты навёлся на обьект, кликнул на него и тем самым ты передал персонажу желание интерактировать с объектом. Будет ли он интерактировать зависит от его текущего состояния, может он в данный момент с кем-то беседует и не может прерваться беседу. Он бросает взгляды на объект, возвращается к беседе, ты понимаешь что он понял твой сигнал. Насчёт диалогов тоже интересные задумки и подходы были. Игрок, как бестелесная сущность фактически не может ни с кем беседовать в мире игры. Он может только передавать персонажу некоторую мысль (сложность и разветвлённость передаваемой мысли - тоже предмет прокачки), а уже персонаж сам решает, высказать ли эту мысль вслух или промолчать. Но сделать выводы.
Пробитие 4 стены здесь в том, что в мифологии игрового мира есть некие всесильные и всеведущие духи и таковым считают - тебя, игрока.
Фактически я хочу принцип изометрических РПГ реализовать в тридэ от первого лица, ведь по сути, в эпоху изометрических РПГ так и было: игрок был сторонней сущностью, расположенной сверху над игровым полем и отдавал существам-марионеткам в мире-диораме команды: иди туда, делай то, бей того, говори с этим.
> С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями.
Разрешите вклиниться в ваш диалог. Я когда-то даже хотел запилить игру об этом. С разрушением четвёртой стены. Но идея слишком амбициозная, нужна целая студия для реализации задумки, тогда я думал, что запилю в одиночку, но практика больно стукнула по рукам.
В общем, суть токова: игрок играет ангелом хранителем персонажа. Всё почти так же, как в типичных тридэ эрпогэ. Перед стартом долго настраиваешь внешность персонажа. Смотришь вступительный синематик с эпичной музыкой. И начинается игра. Но есть кардинальные отличия. Ты свободной камерой перемещаешься вокруг персонажа. Ты не можешь им прямо управлять (хотя после прокачки такая возможность может появиться). На действия персонажа ты влияешь поначалу очень слабо. Пример: У тебя в интерфейсе есть курсор-прицел, наведя его на сундук ты можешь нажать кнопку Е. В обычных играх что происходит? Жёстко прибитый гвоздями к игроку персонаж от лица игрока открывает сундук. И на этом разработчики пытаются создать вживляемость игрока в мир, отыгрыш. В моей же концепции, мы отыгрываем не самого персонажа, а бестелесный дух, помогающий (а может и вредящий) герою/героине. Гемплей поначалу фактический пойнт и клик. Ты навёлся на обьект, кликнул на него и тем самым ты передал персонажу желание интерактировать с объектом. Будет ли он интерактировать зависит от его текущего состояния, может он в данный момент с кем-то беседует и не может прерваться беседу. Он бросает взгляды на объект, возвращается к беседе, ты понимаешь что он понял твой сигнал. Насчёт диалогов тоже интересные задумки и подходы были. Игрок, как бестелесная сущность фактически не может ни с кем беседовать в мире игры. Он может только передавать персонажу некоторую мысль (сложность и разветвлённость передаваемой мысли - тоже предмет прокачки), а уже персонаж сам решает, высказать ли эту мысль вслух или промолчать. Но сделать выводы.
Пробитие 4 стены здесь в том, что в мифологии игрового мира есть некие всесильные и всеведущие духи и таковым считают - тебя, игрока.
Фактически я хочу принцип изометрических РПГ реализовать в тридэ от первого лица, ведь по сути, в эпоху изометрических РПГ так и было: игрок был сторонней сущностью, расположенной сверху над игровым полем и отдавал существам-марионеткам в мире-диораме команды: иди туда, делай то, бей того, говори с этим.
>>34914
Разрешите вклиниться в ваш диалог. Я когда-то даже хотел запилить игру об этом. С разрушением четвёртой стены. Но идея слишком амбициозная, нужна целая студия для реализации задумки, тогда я думал, что запилю в одиночку, но практика больно стукнула по рукам.
В общем, суть токова: игрок играет ангелом хранителем персонажа. Всё почти так же, как в типичных тридэ эрпогэ. Перед стартом долго настраиваешь внешность персонажа. Смотришь вступительный синематик с эпичной музыкой. И начинается игра. Но есть кардинальные отличия. Ты свободной камерой перемещаешься вокруг персонажа. Ты не можешь им прямо управлять (хотя после прокачки такая возможность может появиться). На действия персонажа ты влияешь поначалу очень слабо. Пример: У тебя в интерфейсе есть курсор-прицел, наведя его на сундук ты можешь нажать кнопку Е. В обычных играх что происходит? Жёстко прибитый гвоздями к игроку персонаж от лица игрока открывает сундук. И на этом разработчики пытаются создать вживляемость игрока в мир, отыгрыш. В моей же концепции, мы отыгрываем не самого персонажа, а бестелесный дух, помогающий (а может и вредящий) герою/героине. Гемплей поначалу фактический пойнт и клик. Ты навёлся на обьект, кликнул на него и тем самым ты передал персонажу желание интерактировать с объектом. Будет ли он интерактировать зависит от его текущего состояния, может он в данный момент с кем-то беседует и не может прерваться беседу. Он бросает взгляды на объект, возвращается к беседе, ты понимаешь что он понял твой сигнал. Насчёт диалогов тоже интересные задумки и подходы были. Игрок, как бестелесная сущность фактически не может ни с кем беседовать в мире игры. Он может только передавать персонажу некоторую мысль (сложность и разветвлённость передаваемой мысли - тоже предмет прокачки), а уже персонаж сам решает, высказать ли эту мысль вслух или промолчать. Но сделать выводы.
Пробитие 4 стены здесь в том, что в мифологии игрового мира есть некие всесильные и всеведущие духи и таковым считают - тебя, игрока.
Фактически я хочу принцип изометрических РПГ реализовать в тридэ от первого лица, ведь по сути, в эпоху изометрических РПГ так и было: игрок был сторонней сущностью, расположенной сверху над игровым полем и отдавал существам-марионеткам в мире-диораме команды: иди туда, делай то, бей того, говори с этим.
> С таким определением любой игрок в любой игре является сверхъестественной высшей сущностью со сверхъестественными способностями.
Разрешите вклиниться в ваш диалог. Я когда-то даже хотел запилить игру об этом. С разрушением четвёртой стены. Но идея слишком амбициозная, нужна целая студия для реализации задумки, тогда я думал, что запилю в одиночку, но практика больно стукнула по рукам.
В общем, суть токова: игрок играет ангелом хранителем персонажа. Всё почти так же, как в типичных тридэ эрпогэ. Перед стартом долго настраиваешь внешность персонажа. Смотришь вступительный синематик с эпичной музыкой. И начинается игра. Но есть кардинальные отличия. Ты свободной камерой перемещаешься вокруг персонажа. Ты не можешь им прямо управлять (хотя после прокачки такая возможность может появиться). На действия персонажа ты влияешь поначалу очень слабо. Пример: У тебя в интерфейсе есть курсор-прицел, наведя его на сундук ты можешь нажать кнопку Е. В обычных играх что происходит? Жёстко прибитый гвоздями к игроку персонаж от лица игрока открывает сундук. И на этом разработчики пытаются создать вживляемость игрока в мир, отыгрыш. В моей же концепции, мы отыгрываем не самого персонажа, а бестелесный дух, помогающий (а может и вредящий) герою/героине. Гемплей поначалу фактический пойнт и клик. Ты навёлся на обьект, кликнул на него и тем самым ты передал персонажу желание интерактировать с объектом. Будет ли он интерактировать зависит от его текущего состояния, может он в данный момент с кем-то беседует и не может прерваться беседу. Он бросает взгляды на объект, возвращается к беседе, ты понимаешь что он понял твой сигнал. Насчёт диалогов тоже интересные задумки и подходы были. Игрок, как бестелесная сущность фактически не может ни с кем беседовать в мире игры. Он может только передавать персонажу некоторую мысль (сложность и разветвлённость передаваемой мысли - тоже предмет прокачки), а уже персонаж сам решает, высказать ли эту мысль вслух или промолчать. Но сделать выводы.
Пробитие 4 стены здесь в том, что в мифологии игрового мира есть некие всесильные и всеведущие духи и таковым считают - тебя, игрока.
Фактически я хочу принцип изометрических РПГ реализовать в тридэ от первого лица, ведь по сути, в эпоху изометрических РПГ так и было: игрок был сторонней сущностью, расположенной сверху над игровым полем и отдавал существам-марионеткам в мире-диораме команды: иди туда, делай то, бей того, говори с этим.
10 Кб, 1174x92>>34953
Защищу анончика. Он этого не писал. Я это писал. Но дискутировать перестал. Игры делаю, а не дискутирую.
Защищу анончика. Он этого не писал. Я это писал. Но дискутировать перестал. Игры делаю, а не дискутирую.
Далею туториал по шейдерам. И в редакторе объект при приближении чернеет, а на отдалении выглядит нормально. При запуске этого эффекта нет. Еще была аналогичная проблема с 3д спрайтом, только он при приблежении не чернел, а становился прозрачным. В чем может быть проблема?
>>35094
Переключился с GLES3 на GLES2, стало все нормально и с шейдером и со спрайтами.
Переключился с GLES3 на GLES2, стало все нормально и с шейдером и со спрайтами.
>>35137
Дальше по туториалу оказалось, что GLES2 не поддерживает нужные фичи, переключился обратно на GLES3, этого эффекта уже не наблюдалось.
Дальше по туториалу оказалось, что GLES2 не поддерживает нужные фичи, переключился обратно на GLES3, этого эффекта уже не наблюдалось.
>>35072
Молодец. А я депрессирую.
>>34958
Формально ты прав, но на практике, с точки зрения производительности, эмулировать невыгодно. Функция должна быть очень нужна, чтобы её реализовали в ущерб общей производительности... Нужны ли нам векторы, которые передаются по ссылке? Нет, не нужны. Тогда зачем реализовывать их через динамические массивы, когда есть возможность использовать struct?
>Игры делаю, а не дискутирую.
Молодец. А я депрессирую.
>>34958
>Речь шла о том, что пофиг, что у хоста struct. Это разные языки, описываемые разным BNF.
Формально ты прав, но на практике, с точки зрения производительности, эмулировать невыгодно. Функция должна быть очень нужна, чтобы её реализовали в ущерб общей производительности... Нужны ли нам векторы, которые передаются по ссылке? Нет, не нужны. Тогда зачем реализовывать их через динамические массивы, когда есть возможность использовать struct?
В этом шейдерном туториале, чтобы нарисовать белую кромку воды, надо из буфера глубины взять глубину объекта, который под водой и сравнить его с глубиной воды. Но ведь чтобы в буфере глубины этот задний объект след оставил, надо ведь, чтобы он был уже отрисован до нашего объекта с шейдером. А что если задний объект будет отрисован позже объекта с моим шейдером?
>>35351
Официально в 3 годоте описано так
1. Сначала заполняется depth буффер непрозрачными объектами
2. Потом рисуются непрозрачные объекты, отсортированные в неизвестном порядке. Как минимум, движок пытается рисовать вместе все объекты с одинаковым материалом.
3. После этого рисуются прозрачные объекты. Они уже сортируются по глубине, потому что имеет значение порядок отрисовки. Кроме того, только для прозрачных объектов, работает параметр render_priority, который позволяет менять порядок.
(Единственное, что я не знаю, как движок определяет прозрачный или непрозрачный шейдерный материал. Возможно, по обращению к переменной ALPHA? Надо проверить)
Так что на первый взгляд, все должно работать правильно. Конечно там дальше еще будут подводные камни, например я пока не смог сделать одновременно пену и антиалиасинг (MSAA)
Официально в 3 годоте описано так
1. Сначала заполняется depth буффер непрозрачными объектами
2. Потом рисуются непрозрачные объекты, отсортированные в неизвестном порядке. Как минимум, движок пытается рисовать вместе все объекты с одинаковым материалом.
3. После этого рисуются прозрачные объекты. Они уже сортируются по глубине, потому что имеет значение порядок отрисовки. Кроме того, только для прозрачных объектов, работает параметр render_priority, который позволяет менять порядок.
(Единственное, что я не знаю, как движок определяет прозрачный или непрозрачный шейдерный материал. Возможно, по обращению к переменной ALPHA? Надо проверить)
Так что на первый взгляд, все должно работать правильно. Конечно там дальше еще будут подводные камни, например я пока не смог сделать одновременно пену и антиалиасинг (MSAA)
Всё, пиздец.
Отказал жёсткий диск. Жёстко отказал, даже данные с него забрать не удаётся с лайв-флешки. Пизда проектам. Пизда профилям. Пизда настройкам.
КАКОГО ХУЯ Я НИЧЕГО НЕ БЭКАПИЛ???
Отказал жёсткий диск. Жёстко отказал, даже данные с него забрать не удаётся с лайв-флешки. Пизда проектам. Пизда профилям. Пизда настройкам.
КАКОГО ХУЯ Я НИЧЕГО НЕ БЭКАПИЛ???
>>35362
Это тебе в /hw какой нибудь. Если у тебя HDD, а не SDD, и сгорел контроллер, можно пересадить контроллер с такого же диска. Или отнести восстановителям данных, они чуть ли не с блинов магнитную запись снимают.
А так, конечно, надо бэкапиться. Ну это, конечно, если большой проект. Маленький, возможно, проще с нуля переписать. Были и такие истории, в той же Toy Story 3. Ведь у тебя в памяти есть архитектура и как что работало + какие-то вещи ты даже лучше напишешь, так как стал опытней.
Это тебе в /hw какой нибудь. Если у тебя HDD, а не SDD, и сгорел контроллер, можно пересадить контроллер с такого же диска. Или отнести восстановителям данных, они чуть ли не с блинов магнитную запись снимают.
А так, конечно, надо бэкапиться. Ну это, конечно, если большой проект. Маленький, возможно, проще с нуля переписать. Были и такие истории, в той же Toy Story 3. Ведь у тебя в памяти есть архитектура и как что работало + какие-то вещи ты даже лучше напишешь, так как стал опытней.
Сел пилить первую игру своей мечты и как на зло это 2д космосим с симуляцией ньютоновой физики. Бэкграунд просто нулевой, как по школьной физике, так и по геймдеву. За два дня разобрался с притяжением и получил первые орбиты. Теперь у меня есть скорость(пиксели/с?), время(с) и расстояние(пиксели блядь) и я сижу и думаю как это всё привести к единому масштабу и рисовать траектории на экране. Короче лучше делайте платформеры или рогалики.
>>35387
Могу дать пару советов. Первый - программисту интуитивно делать симуляцию с притяжением, N-body (даже ассет такой есть). Но на самом деле в играх, той же KSP, симуляция не используется, а объекты управляются орбитами (заданных эллипсом), а не рисуют орбиту по симуляции. Не знаю точно причины, но предположу, что 1) плохая сходимость из-за погрешностей, т.е. хрен ты добьешься стабильных орбит даже с реальными массами земли и луны 2) алгоритм влоб O(N^2), т.е. квадратично зависит от тел в рассчете, или требует сложных оптимизаций. так что ты выполнил хорошее упражнение, и довольно быстро, но возможно он не ведет к полной игре, если только твоя игра мечты это не именно честный сим, но тогда тебе придется закопаться в физике.
Что же касается рисования орбит, там разные варианты могут быть. Тот, которым пользовался я - просто Line2D, там задается список точек, можно и в твоем варианте использовать, когда тело летит, удаляй самую старую точку и добавляй новую. У Line2D изкоробки задается градиент, и переменная толщина. Еще в голову приходит расбрасывать за собой частицы, или рисовать на канвасе draw линии, или вообще писать шейдер, который двигает по UV, по типу круговых лайф баров. https://godotshaders.com/shader/circular-life-bar/
Если же тебя заинтересует вариант с орбитами, то в годоте есть Path и PathFollow который позволяет двигать объект по кривой в "процентах" (unit offset) Ну и вообще можешь порыться на Ludum Dare наверняка были игры на годоте про орбиты с исходниками.
Могу дать пару советов. Первый - программисту интуитивно делать симуляцию с притяжением, N-body (даже ассет такой есть). Но на самом деле в играх, той же KSP, симуляция не используется, а объекты управляются орбитами (заданных эллипсом), а не рисуют орбиту по симуляции. Не знаю точно причины, но предположу, что 1) плохая сходимость из-за погрешностей, т.е. хрен ты добьешься стабильных орбит даже с реальными массами земли и луны 2) алгоритм влоб O(N^2), т.е. квадратично зависит от тел в рассчете, или требует сложных оптимизаций. так что ты выполнил хорошее упражнение, и довольно быстро, но возможно он не ведет к полной игре, если только твоя игра мечты это не именно честный сим, но тогда тебе придется закопаться в физике.
Что же касается рисования орбит, там разные варианты могут быть. Тот, которым пользовался я - просто Line2D, там задается список точек, можно и в твоем варианте использовать, когда тело летит, удаляй самую старую точку и добавляй новую. У Line2D изкоробки задается градиент, и переменная толщина. Еще в голову приходит расбрасывать за собой частицы, или рисовать на канвасе draw линии, или вообще писать шейдер, который двигает по UV, по типу круговых лайф баров. https://godotshaders.com/shader/circular-life-bar/
Если же тебя заинтересует вариант с орбитами, то в годоте есть Path и PathFollow который позволяет двигать объект по кривой в "процентах" (unit offset) Ну и вообще можешь порыться на Ludum Dare наверняка были игры на годоте про орбиты с исходниками.
>>35405
ну так...
>>35407
Игры находил, но там всё делали строго по симуляции. Для моих задач этого достаточно думаю. Про ксп не знал - там и влияния двух тел на корабль нет. Чувствую что тошнить эту игру до состояния большинства рабочих механик придётся несколько лет. Я ещё автопилот и процген запланировал. Благо это как хобби в свободное время.
ну так...
>>35407
Игры находил, но там всё делали строго по симуляции. Для моих задач этого достаточно думаю. Про ксп не знал - там и влияния двух тел на корабль нет. Чувствую что тошнить эту игру до состояния большинства рабочих механик придётся несколько лет. Я ещё автопилот и процген запланировал. Благо это как хобби в свободное время.
217 Кб, 800x420>>35408
Понятно. Я думал, там будут и более "аркадные" варианты как на схемах которые рисуют для научпопа.
Понятно. Я думал, там будут и более "аркадные" варианты как на схемах которые рисуют для научпопа.
>>35363
На это и уповаю.
Разумеется, у меня SSD. Сгорело всё до тла! И мыши греются в золе!
Мне не нужна помощь, я поныл-пожаловался на судьбу (и свою беспечность) среди котанов-годанов.
Держу в курсе: заказал новый диск, сижу с лайв-флешки
> какие-то вещи ты даже лучше напишешь, так как стал опытней.
На это и уповаю.
> Если у тебя HDD, а не SDD
Разумеется, у меня SSD. Сгорело всё до тла! И мыши греются в золе!
> Это тебе в /hw какой нибудь.
Мне не нужна помощь, я поныл-пожаловался на судьбу (и свою беспечность) среди котанов-годанов.
Держу в курсе: заказал новый диск, сижу с лайв-флешки
>>35362
Судьба Годот-куна.
Судьба Годот-куна.
>>35387
Вот этот посмотри в качестве примера, в свое время очень доставил:
https://www.youtube.com/watch?v=g3FigBwiHH0
>2д космосим с симуляцией ньютоновой физики
Вот этот посмотри в качестве примера, в свое время очень доставил:
https://www.youtube.com/watch?v=g3FigBwiHH0
Анончики, подскажите, а вот экзешники в шаблонах экспорта - это просто релизная сборка движка без редактора?
Во время экспорта без собственной перекомпиляции (например, выкинуть 3D) уменьшить размер не получится, кроме как сжатием ресурсов уже самой игры?
Во время экспорта без собственной перекомпиляции (например, выкинуть 3D) уменьшить размер не получится, кроме как сжатием ресурсов уже самой игры?
>>35658
Получится.
Например вот мой батник для сборки 2д под андроид
call scons p=android tools=no target=release android_arch=armv7 optimize=size lto=thin disable_3d=yes module_bmp_enabled=no module_bullet_enabled=no module_camera_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_denoise_enabled=no module_enet_enabled=no module_etc_enabled=yes module_fbx_enabled=no module_freetype_enabled=yes module_gdnative_enabled=yes module_gdscript_enabled=yes module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_jsonrpc_enabled=yes module_lightmapper_cpu_enabled=no module_mbedtls_enabled=yes module_minimp3_enabled=no module_mobile_vr_enabled=no module_mono_enabled=no module_ogg_enabled=yes module_opensimplex_enabled=yes module_opus_enabled=yes module_pvr_enabled=no module_raycast_enabled=no module_recast_enabled=no module_regex_enabled=yes module_squish_enabled=no module_stb_vorbis_enabled=yes module_svg_enabled=no module_tga_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_vhacd_enabled=no module_visual_script_enabled=no module_vorbis_enabled=yes module_webm_enabled=no module_webp_enabled=no module_webrtc_enabled=no module_websocket_enabled=no module_webxr_enabled=no module_xatlas_unwrap_enabled=no
Это где-то в 2 раза сжимает APK.
На десктопе же с этим возиться смысла нет. 40Мб это и так микросборка, которая обычным играм и не снилась.
Получится.
Например вот мой батник для сборки 2д под андроид
call scons p=android tools=no target=release android_arch=armv7 optimize=size lto=thin disable_3d=yes module_bmp_enabled=no module_bullet_enabled=no module_camera_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_denoise_enabled=no module_enet_enabled=no module_etc_enabled=yes module_fbx_enabled=no module_freetype_enabled=yes module_gdnative_enabled=yes module_gdscript_enabled=yes module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_jsonrpc_enabled=yes module_lightmapper_cpu_enabled=no module_mbedtls_enabled=yes module_minimp3_enabled=no module_mobile_vr_enabled=no module_mono_enabled=no module_ogg_enabled=yes module_opensimplex_enabled=yes module_opus_enabled=yes module_pvr_enabled=no module_raycast_enabled=no module_recast_enabled=no module_regex_enabled=yes module_squish_enabled=no module_stb_vorbis_enabled=yes module_svg_enabled=no module_tga_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_vhacd_enabled=no module_visual_script_enabled=no module_vorbis_enabled=yes module_webm_enabled=no module_webp_enabled=no module_webrtc_enabled=no module_websocket_enabled=no module_webxr_enabled=no module_xatlas_unwrap_enabled=no
Это где-то в 2 раза сжимает APK.
На десктопе же с этим возиться смысла нет. 40Мб это и так микросборка, которая обычным играм и не снилась.
>>35663
для android я уже - да, делал
ну для основного функционала тех игр, что требуется по моему тз, я бы сказал, что в 2-10мб можно было бы, ладно, значит там только через ключи сборки в mingw типа отключения 3D и прочего, что в доках описаны
спасибо
для android я уже - да, делал
> На десктопе же с этим возиться смысла нет. 40Мб это и так микросборка, которая обычным играм и не снилась.
ну для основного функционала тех игр, что требуется по моему тз, я бы сказал, что в 2-10мб можно было бы, ладно, значит там только через ключи сборки в mingw типа отключения 3D и прочего, что в доках описаны
спасибо
Разобрался с тем, как удобнее всего закинуть данные об освещении в материал спрайта и даже накидал набросок чарактер контроллера для такого типа игры.
Теперь самое главное... Как задизайнить красивое освещение? Я раньше пробовал какой-то алгоритм, который разливает свет как жидкость с помощью клеточного автомата, но я так не смог справиться с двумя очень неприятными эффектами: источники света светят в форме крестов и после удаления источника света свет медленно "вытекает" вместо мгновенного исчезновения. Если медленное протекание света ещё можно пофиксить, то как избавиться от крестов я не понял.
Самое интересное, что в Террарии есть мелкие искорки от различных эффектов, которые тоже освещают вокруг себя часть ландшафта, падая в бездну. А ещё я видел в таких играх анимированные факела, свет от которых неравномерно распространяется, как бы мерцая. Очень хочется что-то красивое сделать, чтоб прям достойно выглядело, а не просто обмазанные чернотой кубики. Но как это сделать с учётом производительности - непонятно. На данный момент обновление текстуры света вызывает ощутимый лаг, учитывая что нужно пересчитать все окружающие клетки, так что я сомневаюсь, что будет разумно обновлять всё это каждый кадр...
Ну, я ещё раз попробую реализовать конечный автомат, теперь-то я опытнее и всё такое; но всё же, может есть какие-то другие варианты, чтоб не было "волн света" и крестообразных лучей?
На втором скриншоте делал движок с нуля, алгоритм освещения в интернете подглядел.
Решил попробовать сделать такую игру на Годо чисто из любопытства, что получится.
Теперь самое главное... Как задизайнить красивое освещение? Я раньше пробовал какой-то алгоритм, который разливает свет как жидкость с помощью клеточного автомата, но я так не смог справиться с двумя очень неприятными эффектами: источники света светят в форме крестов и после удаления источника света свет медленно "вытекает" вместо мгновенного исчезновения. Если медленное протекание света ещё можно пофиксить, то как избавиться от крестов я не понял.
Самое интересное, что в Террарии есть мелкие искорки от различных эффектов, которые тоже освещают вокруг себя часть ландшафта, падая в бездну. А ещё я видел в таких играх анимированные факела, свет от которых неравномерно распространяется, как бы мерцая. Очень хочется что-то красивое сделать, чтоб прям достойно выглядело, а не просто обмазанные чернотой кубики. Но как это сделать с учётом производительности - непонятно. На данный момент обновление текстуры света вызывает ощутимый лаг, учитывая что нужно пересчитать все окружающие клетки, так что я сомневаюсь, что будет разумно обновлять всё это каждый кадр...
Ну, я ещё раз попробую реализовать конечный автомат, теперь-то я опытнее и всё такое; но всё же, может есть какие-то другие варианты, чтоб не было "волн света" и крестообразных лучей?
На втором скриншоте делал движок с нуля, алгоритм освещения в интернете подглядел.
Решил попробовать сделать такую игру на Годо чисто из любопытства, что получится.
>>35774
gdscript
gdscript
>>35773
ну если 3D, то там
ну если 3D, то там
У меня тысячи сущностей гуляют, ищут путь, толкаются и ловят ебалом пули. На удивление они всё это делают с успехом на физике в 60 фпс, если не сбиваются в толпу и блочат друг друга. Я отлавливаю то, что они блочат друг друга и замораживаю. А далее начинаются трудности, я знаю как их разогнать, но для этого нужно много вычислений, поиск пути, тонны рэйкастов. И вот это делать вообще не обязательно каждый фрейм.
Вот что я пока решил:
Записываю таких проблемных в очередь.
В отдельной ноде буду разгребать эту очередь, но разгребать в каждый фрейм буду ровно столько, сколько успеется за 1/10 от 60/120 (десятую часть от среднего фрейма из фреймрейта в 120 фпс). Тогда ниче тормозить не будет даже на мобилках каких-нибудь.
В чем я проебался?
Может есть какие то готовые решения? Никак не смог нагуглить.
Вот что я пока решил:
Записываю таких проблемных в очередь.
В отдельной ноде буду разгребать эту очередь, но разгребать в каждый фрейм буду ровно столько, сколько успеется за 1/10 от 60/120 (десятую часть от среднего фрейма из фреймрейта в 120 фпс). Тогда ниче тормозить не будет даже на мобилках каких-нибудь.
В чем я проебался?
Может есть какие то готовые решения? Никак не смог нагуглить.
>>35782
Готовых решений в движках общего назначения не будет. Ты либо рассчитываешь все точно, либо симулируешь, что их объединяешь в кластеры, где есть свои простые вычисления, либо откладываешь вычисления, но у тебя возникает кривость синхронизации игровых тактов.
Поэтому если ты хочешь, чтобы было куча персонажей как в стратегиях, чтобы они взаимодействовали как угодно физика/логика, то ты забрасыавешь их на ядра видюхи или на крутые процы, а если хочешь такое на мобилках, то либо упрощаешь до каких-то кластеров/отрядов и т.д. со своей логикой, либо все быстро упираешься в потолок целевого железа
Готовых решений в движках общего назначения не будет. Ты либо рассчитываешь все точно, либо симулируешь, что их объединяешь в кластеры, где есть свои простые вычисления, либо откладываешь вычисления, но у тебя возникает кривость синхронизации игровых тактов.
Поэтому если ты хочешь, чтобы было куча персонажей как в стратегиях, чтобы они взаимодействовали как угодно физика/логика, то ты забрасыавешь их на ядра видюхи или на крутые процы, а если хочешь такое на мобилках, то либо упрощаешь до каких-то кластеров/отрядов и т.д. со своей логикой, либо все быстро упираешься в потолок целевого железа
>>35360
Именно так.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/spatial_shader.html#fragment-built-ins
>>35351
Лол, если это вдруг произойдёт, то "задний" объект окажется спереди твоего, т.е. перекроет его.
>по обращению к переменной ALPHA?
Именно так.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/spatial_shader.html#fragment-built-ins
>out float ALPHA - Alpha (0..1); if written to, the material will go to the transparent pipeline.
>>35351
>Но ведь чтобы в буфере глубины этот задний объект след оставил, надо ведь, чтобы он был уже отрисован до нашего объекта с шейдером. А что если задний объект будет отрисован позже объекта с моим шейдером?
Лол, если это вдруг произойдёт, то "задний" объект окажется спереди твоего, т.е. перекроет его.
>>35658
>>35663
Ты опять отвечаешь, не прочитав вопрос? Тебя ясно спросили, можно ли как-то уменьшить размер .exe файла без скачивания исходников движка, компилятора и скунса для последующей пересборки движка. А ты отвечаешь, "да, можно без пересборки, вот мой скрипт для пересборки". Где логика? Нет логики.
>без собственной перекомпиляции
>уменьшить размер не получится
>>35663
>Получится.
>мой батник для сборки
>call scons
Ты опять отвечаешь, не прочитав вопрос? Тебя ясно спросили, можно ли как-то уменьшить размер .exe файла без скачивания исходников движка, компилятора и скунса для последующей пересборки движка. А ты отвечаешь, "да, можно без пересборки, вот мой скрипт для пересборки". Где логика? Нет логики.
>>35782
Убедись для начала, что тебе действительно нужно перемещать физические сущности (RigidBody или KinematicBody, не важно). Если у тебя классическая стратегия с видом сверху, то никакие физические сущности тебе не нужны. Другое дело, если ты хочешь что-то вроде Totally Accurate Battle Simulator.
Если отказываешься от физики, тогда тебе нужно всего лишь разделить игровой мир на квадраты или кубы, расставив точки в доступных для перемещения зонах и загнав эти точки в AStar. Всё остальное - это только анимации перемещения, анимации боя и т.д., которые отображаются только тогда, когда игрок на них смотрит.
Также, если у тебя огромный по площади мир, но всё-таки нужны физические сущности, с которыми игрок сможет физически взаимодействовать, будет достаточно выключать физику и переводить на AStar те сущности, которые слишком далеко от игрока, чтобы он с ними мог как-то взаимодействовать.
>гуляют, ищут путь, толкаются
>на физике
>тонны рэйкастов
Убедись для начала, что тебе действительно нужно перемещать физические сущности (RigidBody или KinematicBody, не важно). Если у тебя классическая стратегия с видом сверху, то никакие физические сущности тебе не нужны. Другое дело, если ты хочешь что-то вроде Totally Accurate Battle Simulator.
Если отказываешься от физики, тогда тебе нужно всего лишь разделить игровой мир на квадраты или кубы, расставив точки в доступных для перемещения зонах и загнав эти точки в AStar. Всё остальное - это только анимации перемещения, анимации боя и т.д., которые отображаются только тогда, когда игрок на них смотрит.
Также, если у тебя огромный по площади мир, но всё-таки нужны физические сущности, с которыми игрок сможет физически взаимодействовать, будет достаточно выключать физику и переводить на AStar те сущности, которые слишком далеко от игрока, чтобы он с ними мог как-то взаимодействовать.
>>35782
>>35785
Я бы попробовал так: Поскольку игрок всё равно не уследит за движениями тысяч сущностей, то нужно отключить коллизии между ними, тогда они не будут сталкиваться и беспокоить физический движок. Но тогда они будут клипаться! Чтобы они не клипались, я бы попробовал на них навесить Area которые бы уже регистрировали пересечения друг с другом, но только сигнализировали об этом, а в логике движения я бы обсчитывал уход из пересечений. Они бы всё равно клипались, но стремились бы выходить из зоны пересечения. А в четвёрке вообще завезут динамический оклюдер навигации искаропки, так что все эти танцы с бубном станут не нужны. Ты просто навештваешь шейп на объект и он своим перемещением создаёт дырку в навмеше. Главное, своевременно пересчитывать навмеш.
>>35785
Я бы попробовал так: Поскольку игрок всё равно не уследит за движениями тысяч сущностей, то нужно отключить коллизии между ними, тогда они не будут сталкиваться и беспокоить физический движок. Но тогда они будут клипаться! Чтобы они не клипались, я бы попробовал на них навесить Area которые бы уже регистрировали пересечения друг с другом, но только сигнализировали об этом, а в логике движения я бы обсчитывал уход из пересечений. Они бы всё равно клипались, но стремились бы выходить из зоны пересечения. А в четвёрке вообще завезут динамический оклюдер навигации искаропки, так что все эти танцы с бубном станут не нужны. Ты просто навештваешь шейп на объект и он своим перемещением создаёт дырку в навмеше. Главное, своевременно пересчитывать навмеш.
>>35796
также еще для перемещения в больших мирах используется такая штука как граф перемещений:
для большой карты строим граф, по которому по известным дорожкам будут переходить персонажи
если движение по дорожке заблокировано, то выбираем точку на удалении от персонажа, лежащую на этой дорожке и запускаем a-star или аналог для поиска и идем по нему
возвращаемся на дорожку и снова идем по графу до цели
было бы время у кого новичкам пример накидать рабочий этого дела
также еще для перемещения в больших мирах используется такая штука как граф перемещений:
для большой карты строим граф, по которому по известным дорожкам будут переходить персонажи
если движение по дорожке заблокировано, то выбираем точку на удалении от персонажа, лежащую на этой дорожке и запускаем a-star или аналог для поиска и идем по нему
возвращаемся на дорожку и снова идем по графу до цели
> в четвёрке вообще завезут динамический оклюдер навигации искаропки, так что все эти танцы с бубном станут не нужны. Ты просто навештваешь шейп на объект и он своим перемещением создаёт дырку в навмеше. Главное, своевременно пересчитывать навмеш.
было бы время у кого новичкам пример накидать рабочий этого дела
>>35811
Ты про симулятор скейтборда? Там вроде в ранних играх город совершенно пустой, катаешься по статичным декорациям. Следовательно, тебе нужно только контроллер персонажа нормально сделать. Можешь взять за основу RigidBody - это будет скейтборд; на него крепишь модельку персонажа. Движение и всякие трюки осуществляешь импульсами в скейтборд. Модельке персонажа нужны как минимум триггеры фейла, типа если она ударилась головой в асфальт, нужно отключить управление, включить регдолл и через пару секунд отреспавнить. Если хочешь анимации персонажу, я бы сделал их в Блендере, т.к. регдолл будет слишком хаотичные действия делать.
Сам я такого не делал, так что конкретнее не скажу.
Ты про симулятор скейтборда? Там вроде в ранних играх город совершенно пустой, катаешься по статичным декорациям. Следовательно, тебе нужно только контроллер персонажа нормально сделать. Можешь взять за основу RigidBody - это будет скейтборд; на него крепишь модельку персонажа. Движение и всякие трюки осуществляешь импульсами в скейтборд. Модельке персонажа нужны как минимум триггеры фейла, типа если она ударилась головой в асфальт, нужно отключить управление, включить регдолл и через пару секунд отреспавнить. Если хочешь анимации персонажу, я бы сделал их в Блендере, т.к. регдолл будет слишком хаотичные действия делать.
Сам я такого не делал, так что конкретнее не скажу.
>>35808
1000 Area, пытающихся регистрировать друг друга, потенциально затратнее 1000 кинематикбоди. Кинематикбоди просто пытается сместить себя на заданный вектор, а область постоянно составляет списки того, кто в неё вошёл и кто вышел. Кинематикбоди будет тормозить только если встречает препятствие, тогда он делает несколько дополнительных шагов.
Вообще не понимаю, как у того анона вышло больше 1000 кинематикбоди, у меня уже 150 кинематикбоди в одной плотной толпе просаживают фпс до нуля.
Вывод: убрать всю физику, разделить мир на клетки и двигать персонажей по клеткам как фигурки на доске.
>>35810
Я не понял, что ты пытаешься описать. Если дорога заблокирована, то как персонаж найдёт путь, она же ведь заблокирована? Или ты имеешь в виду один граф для основных дорог и дополнительный граф для обходных путей, если дороги переполнены?
>навесить Area
1000 Area, пытающихся регистрировать друг друга, потенциально затратнее 1000 кинематикбоди. Кинематикбоди просто пытается сместить себя на заданный вектор, а область постоянно составляет списки того, кто в неё вошёл и кто вышел. Кинематикбоди будет тормозить только если встречает препятствие, тогда он делает несколько дополнительных шагов.
Вообще не понимаю, как у того анона вышло больше 1000 кинематикбоди, у меня уже 150 кинематикбоди в одной плотной толпе просаживают фпс до нуля.
Вывод: убрать всю физику, разделить мир на клетки и двигать персонажей по клеткам как фигурки на доске.
>>35810
Я не понял, что ты пытаешься описать. Если дорога заблокирована, то как персонаж найдёт путь, она же ведь заблокирована? Или ты имеешь в виду один граф для основных дорог и дополнительный граф для обходных путей, если дороги переполнены?
>>35820
спасибо
спасибо
>>35822
Думаю не все так просто, кинематик ты двиграть будешь скорее всего move_and_slide или move_and_collide, думаю это операция потяжелее чем проверка Area
>Кинематикбоди просто пытается сместить себя на заданный вектор
Думаю не все так просто, кинематик ты двиграть будешь скорее всего move_and_slide или move_and_collide, думаю это операция потяжелее чем проверка Area
Годотаны, вопрос мало связанный с годотом:
это нормально, что в системе взаимодействия персонажей, перс, с которым происходит взаимодействие, ощущается, как жсон, а не перс?
это нормально, что в системе взаимодействия персонажей, перс, с которым происходит взаимодействие, ощущается, как жсон, а не перс?
>>35900
В каком смысле? У него нет методов, только данные?
Это ненормально в том смысле, что прямое обращение к данным объекта нарушает инкапсуляцию, а это в свою очередь может приводить к неожиданным ошибкам, когда состояние объекта меняется извне без ведома этого объекта. В идеале, все данные объекта должны изменяться через методы с понятыми именами.
К примеру, вместо
Лучше будет
Так целевой персонаж будет знать, кого он слушает, сможет осмысленно переключаться между собственниками, сохранять важные сообщения и игнорировать неважные и т.д. Также, если персонаж внезапно оглох, метод listen() ничего делать не будет, тогда как присваивание hears подразумевает, что персонаж уже услышал что-то.
Но вообще, это всё советы по архитектуре и тому, как управляться со сложной системой, не запутываясь в её деталях. Компьютеру без разницы, как и что ты называешь, и если ты можешь справиться с тем кодом, который пишешь, то проблемы нет. Другое дело, что через месяц/год ты можешь запутаться в собственном коде.
>в системе взаимодействия персонажей, перс, с которым происходит взаимодействие, ощущается, как жсон, а не перс?
В каком смысле? У него нет методов, только данные?
Это ненормально в том смысле, что прямое обращение к данным объекта нарушает инкапсуляцию, а это в свою очередь может приводить к неожиданным ошибкам, когда состояние объекта меняется извне без ведома этого объекта. В идеале, все данные объекта должны изменяться через методы с понятыми именами.
К примеру, вместо
>target.hears = "text"
Лучше будет
>target.listen(self, "text")
Так целевой персонаж будет знать, кого он слушает, сможет осмысленно переключаться между собственниками, сохранять важные сообщения и игнорировать неважные и т.д. Также, если персонаж внезапно оглох, метод listen() ничего делать не будет, тогда как присваивание hears подразумевает, что персонаж уже услышал что-то.
Но вообще, это всё советы по архитектуре и тому, как управляться со сложной системой, не запутываясь в её деталях. Компьютеру без разницы, как и что ты называешь, и если ты можешь справиться с тем кодом, который пишешь, то проблемы нет. Другое дело, что через месяц/год ты можешь запутаться в собственном коде.
>>35751
Ну чего никто ничего не пишет(
Сегодня мысль такая возникла, что я могу сделать систему по типу 3D: сначала вычислять карту "глубины" блоков, чтобы определять потенциал проникновения света внутрь любой структуры, а затем простейшими бинарными операциями накладывать на эту карту источники света любой формы. Не уверен, какой эффект будет в итоге, но по идее он будет сильно зависеть от карты глубины.
Набросок правил карты глубины:
0. Отсутствие блока, пустые блоки, прозрачные блоки, блоки декораций и т.п. пропускают максимум света и поэтому обозначаются белым цветом.
1. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 0, также обозначается белым цветом, чтобы игрок мог при идеальном освещении рассмотреть исходную текстуру блока.
2. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 1, но не с блоками из пункта 0, обозначается серым цветом, т.е. поглощает часть света.
3. Процесс повторяется до самых глубоких блоков, которые обозначаются чёрным цветом, поглощая весь свет.
...эээ, пока записывал, вспомнил один важный недостаток такого подхода: не происходит симуляции лучей, поэтому источник света будет одинаково освещать пространство прямо перед собой и пространство за тонкой стеной. Изначально я планировал симуляцию затухания, чтобы свет за стеной был тусклее.
Тем не менее, стоит попробовать сделать так, потому что я понятия не имею, какая именно система используется в таких играх, как Террария и Старбоунд. Не факт, что там честная симуляция, потому что я никогда не делал строгих измерений ни в одной игре... Тем более что честная симуляция, которую я сделал по примеру из интернета весной 2021, оказалась "странно выглядящей"...
Алсо, не совсем ясно, что делать "фоновым светом", который излучается "фоном" в местах отсутствия фоновых стен. Я читал предложения создавать источник света в каждой такой пустой клетке, но, учитывая динамическую смену дня и ночи, это будет слишком тяжёлой нагрузкой, как мне кажется. Предполагаю, придётся сделать две отдельных карты глубины - для динамических источников света и фонового "солнечного" освещения.
Потом делаем примерно такой бутерброд:
1. Цвет всех блоков, спрайтов и т.д.
2. Карта глубины для фонового света.
3. Фоновый свет (солнце или звёзды).
4. Карта глубины для динамического света.
5. Динамический свет (яркость).
6. Динамический свет (цвет).
Порядок вряд ли правильный, нужно подумать.
Алсо, что думаете о рендеринге текстуры максимального размера (16к на 16к), с последующим частичным рендерингом отдельных участков? Вроде такое возможно? Думаете, будет слишком большая нагрузка? По размеру вроде должно хватить, 16 тысяч блоков в длину - это как раз чуть меньше максимальной ширины карты в Террарии, а по ощущениям это чрезмерно большое пространство. В крайнем случае можно нарезать на куски...
Ну чего никто ничего не пишет(
Сегодня мысль такая возникла, что я могу сделать систему по типу 3D: сначала вычислять карту "глубины" блоков, чтобы определять потенциал проникновения света внутрь любой структуры, а затем простейшими бинарными операциями накладывать на эту карту источники света любой формы. Не уверен, какой эффект будет в итоге, но по идее он будет сильно зависеть от карты глубины.
Набросок правил карты глубины:
0. Отсутствие блока, пустые блоки, прозрачные блоки, блоки декораций и т.п. пропускают максимум света и поэтому обозначаются белым цветом.
1. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 0, также обозначается белым цветом, чтобы игрок мог при идеальном освещении рассмотреть исходную текстуру блока.
2. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 1, но не с блоками из пункта 0, обозначается серым цветом, т.е. поглощает часть света.
3. Процесс повторяется до самых глубоких блоков, которые обозначаются чёрным цветом, поглощая весь свет.
...эээ, пока записывал, вспомнил один важный недостаток такого подхода: не происходит симуляции лучей, поэтому источник света будет одинаково освещать пространство прямо перед собой и пространство за тонкой стеной. Изначально я планировал симуляцию затухания, чтобы свет за стеной был тусклее.
Тем не менее, стоит попробовать сделать так, потому что я понятия не имею, какая именно система используется в таких играх, как Террария и Старбоунд. Не факт, что там честная симуляция, потому что я никогда не делал строгих измерений ни в одной игре... Тем более что честная симуляция, которую я сделал по примеру из интернета весной 2021, оказалась "странно выглядящей"...
Алсо, не совсем ясно, что делать "фоновым светом", который излучается "фоном" в местах отсутствия фоновых стен. Я читал предложения создавать источник света в каждой такой пустой клетке, но, учитывая динамическую смену дня и ночи, это будет слишком тяжёлой нагрузкой, как мне кажется. Предполагаю, придётся сделать две отдельных карты глубины - для динамических источников света и фонового "солнечного" освещения.
Потом делаем примерно такой бутерброд:
1. Цвет всех блоков, спрайтов и т.д.
2. Карта глубины для фонового света.
3. Фоновый свет (солнце или звёзды).
4. Карта глубины для динамического света.
5. Динамический свет (яркость).
6. Динамический свет (цвет).
Порядок вряд ли правильный, нужно подумать.
Алсо, что думаете о рендеринге текстуры максимального размера (16к на 16к), с последующим частичным рендерингом отдельных участков? Вроде такое возможно? Думаете, будет слишком большая нагрузка? По размеру вроде должно хватить, 16 тысяч блоков в длину - это как раз чуть меньше максимальной ширины карты в Террарии, а по ощущениям это чрезмерно большое пространство. В крайнем случае можно нарезать на куски...
>>35751
Ну чего никто ничего не пишет(
Сегодня мысль такая возникла, что я могу сделать систему по типу 3D: сначала вычислять карту "глубины" блоков, чтобы определять потенциал проникновения света внутрь любой структуры, а затем простейшими бинарными операциями накладывать на эту карту источники света любой формы. Не уверен, какой эффект будет в итоге, но по идее он будет сильно зависеть от карты глубины.
Набросок правил карты глубины:
0. Отсутствие блока, пустые блоки, прозрачные блоки, блоки декораций и т.п. пропускают максимум света и поэтому обозначаются белым цветом.
1. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 0, также обозначается белым цветом, чтобы игрок мог при идеальном освещении рассмотреть исходную текстуру блока.
2. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 1, но не с блоками из пункта 0, обозначается серым цветом, т.е. поглощает часть света.
3. Процесс повторяется до самых глубоких блоков, которые обозначаются чёрным цветом, поглощая весь свет.
...эээ, пока записывал, вспомнил один важный недостаток такого подхода: не происходит симуляции лучей, поэтому источник света будет одинаково освещать пространство прямо перед собой и пространство за тонкой стеной. Изначально я планировал симуляцию затухания, чтобы свет за стеной был тусклее.
Тем не менее, стоит попробовать сделать так, потому что я понятия не имею, какая именно система используется в таких играх, как Террария и Старбоунд. Не факт, что там честная симуляция, потому что я никогда не делал строгих измерений ни в одной игре... Тем более что честная симуляция, которую я сделал по примеру из интернета весной 2021, оказалась "странно выглядящей"...
Алсо, не совсем ясно, что делать "фоновым светом", который излучается "фоном" в местах отсутствия фоновых стен. Я читал предложения создавать источник света в каждой такой пустой клетке, но, учитывая динамическую смену дня и ночи, это будет слишком тяжёлой нагрузкой, как мне кажется. Предполагаю, придётся сделать две отдельных карты глубины - для динамических источников света и фонового "солнечного" освещения.
Потом делаем примерно такой бутерброд:
1. Цвет всех блоков, спрайтов и т.д.
2. Карта глубины для фонового света.
3. Фоновый свет (солнце или звёзды).
4. Карта глубины для динамического света.
5. Динамический свет (яркость).
6. Динамический свет (цвет).
Порядок вряд ли правильный, нужно подумать.
Алсо, что думаете о рендеринге текстуры максимального размера (16к на 16к), с последующим частичным рендерингом отдельных участков? Вроде такое возможно? Думаете, будет слишком большая нагрузка? По размеру вроде должно хватить, 16 тысяч блоков в длину - это как раз чуть меньше максимальной ширины карты в Террарии, а по ощущениям это чрезмерно большое пространство. В крайнем случае можно нарезать на куски...
Ну чего никто ничего не пишет(
Сегодня мысль такая возникла, что я могу сделать систему по типу 3D: сначала вычислять карту "глубины" блоков, чтобы определять потенциал проникновения света внутрь любой структуры, а затем простейшими бинарными операциями накладывать на эту карту источники света любой формы. Не уверен, какой эффект будет в итоге, но по идее он будет сильно зависеть от карты глубины.
Набросок правил карты глубины:
0. Отсутствие блока, пустые блоки, прозрачные блоки, блоки декораций и т.п. пропускают максимум света и поэтому обозначаются белым цветом.
1. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 0, также обозначается белым цветом, чтобы игрок мог при идеальном освещении рассмотреть исходную текстуру блока.
2. Блок, напрямую или по диагонали контактирующий минимум с одним блоком из пункта 1, но не с блоками из пункта 0, обозначается серым цветом, т.е. поглощает часть света.
3. Процесс повторяется до самых глубоких блоков, которые обозначаются чёрным цветом, поглощая весь свет.
...эээ, пока записывал, вспомнил один важный недостаток такого подхода: не происходит симуляции лучей, поэтому источник света будет одинаково освещать пространство прямо перед собой и пространство за тонкой стеной. Изначально я планировал симуляцию затухания, чтобы свет за стеной был тусклее.
Тем не менее, стоит попробовать сделать так, потому что я понятия не имею, какая именно система используется в таких играх, как Террария и Старбоунд. Не факт, что там честная симуляция, потому что я никогда не делал строгих измерений ни в одной игре... Тем более что честная симуляция, которую я сделал по примеру из интернета весной 2021, оказалась "странно выглядящей"...
Алсо, не совсем ясно, что делать "фоновым светом", который излучается "фоном" в местах отсутствия фоновых стен. Я читал предложения создавать источник света в каждой такой пустой клетке, но, учитывая динамическую смену дня и ночи, это будет слишком тяжёлой нагрузкой, как мне кажется. Предполагаю, придётся сделать две отдельных карты глубины - для динамических источников света и фонового "солнечного" освещения.
Потом делаем примерно такой бутерброд:
1. Цвет всех блоков, спрайтов и т.д.
2. Карта глубины для фонового света.
3. Фоновый свет (солнце или звёзды).
4. Карта глубины для динамического света.
5. Динамический свет (яркость).
6. Динамический свет (цвет).
Порядок вряд ли правильный, нужно подумать.
Алсо, что думаете о рендеринге текстуры максимального размера (16к на 16к), с последующим частичным рендерингом отдельных участков? Вроде такое возможно? Думаете, будет слишком большая нагрузка? По размеру вроде должно хватить, 16 тысяч блоков в длину - это как раз чуть меньше максимальной ширины карты в Террарии, а по ощущениям это чрезмерно большое пространство. В крайнем случае можно нарезать на куски...
>>35784
Группировать никого не пришлось, получилось все так как я описал, каждый по отдельности вычисляет свое движение
>>35785
не ртс, да и больше нескольких сотен сущностей одновременно будет вряд-ли, просто пытаюсь делать оптимально, так, чтобы был максимальный запас для производительности
>>35796
вообще недопонимание между нами произошло. По клеткам двигать это же отстой. Если я не хочу движения по клеткам астар вообще не подходит (у меня тайловый мир разрушаемыми клеточками), да и для производительности астар неоч в моей ситуации, а типо как поле потенциалов сделать, рассчитав все заранее тоже не подойдет, т.к. у меня все полностью разрушаемое. Без коллизий тоже не выйдет, потому что они тогда все постакаются в одну текстуру, но я и не говорил что юзаю body, оказалось на raycast'ах можно одновременно тысячи пацанчиков водить так, чтобы они обходили друг друга, при чем вычисляя для каждого движение каждый фрейм.
>>35810
пробовал сначала как то типа так. Каждый челик себе "бронировал" клетку на которой находится, и другие пытались обходить его. Но тут опять же, унылое движение по клеточкам + даже до 1000 сущностей без просадок не дошло, т.к. пересчитывать путь очень затратно.
>>35808
бро, я с годотом только вторую неделю вожусь (и вообще это мой первый движок), но разве это не прямой велосипед? Просто это ведь именно как коллизии и звучит, только костыльные, при том, что в движке есть готовое решение и оно по идее должно работать оптимально. Или я не так понял мб, но короче я скачал одну демку с boids, вот там точно так же это пытаются хэндлить, у каждой сущности есть шейп и каждая сущность высчитывает движение исходя из позиций других сущностей, попавших в этот шейп, но эта хуйня уже на сотне боидов мне просадки в <30 фпс дала.
>>35822
Да я же нигде не писал, что юзаю именно кинематикбади. У меня на рейкастах и ареях всё.
Я наверное очень тупо вопрос описал. Проблема не в том, что я не знаю, как управлять тысячами сущностей как я хочу, проблема была в том, что они могут сбиваться в толпу, и разгон их, с пересчетом цели движения - вот эта хуйня затратная. Я решил это так, как описал, замораживаю их и аккумулирую в очереди, которая разбирается потихоньку. Разбираю очередь циклом, каждый фрейм, но каждую итерацию я чекаю сколько прошло времени с начала обработки очереди в этом кадре и если это время больше, скажем, половины миллисекунды - прекращаю этот процесс.
И мне почему то кажется, что это велосипед и должно быть готовое решение, это ж движок. А вот такие работы на фоне же вряд ли должны быть редкостью, ну реально, разные вещи имеют разный приоритет, что то нужно каждый кадр делать, а что то нужно просто сделать, похуй когда. При этом в другом потоке это делать, как я понял, не выйдет, потому что мне нужно что бы данные были с одного фрейма. Ничего просто не смог нагуглить нормального типа godot worker, godot tasks, godot jobs
Группировать никого не пришлось, получилось все так как я описал, каждый по отдельности вычисляет свое движение
>>35785
не ртс, да и больше нескольких сотен сущностей одновременно будет вряд-ли, просто пытаюсь делать оптимально, так, чтобы был максимальный запас для производительности
>>35796
вообще недопонимание между нами произошло. По клеткам двигать это же отстой. Если я не хочу движения по клеткам астар вообще не подходит (у меня тайловый мир разрушаемыми клеточками), да и для производительности астар неоч в моей ситуации, а типо как поле потенциалов сделать, рассчитав все заранее тоже не подойдет, т.к. у меня все полностью разрушаемое. Без коллизий тоже не выйдет, потому что они тогда все постакаются в одну текстуру, но я и не говорил что юзаю body, оказалось на raycast'ах можно одновременно тысячи пацанчиков водить так, чтобы они обходили друг друга, при чем вычисляя для каждого движение каждый фрейм.
>>35810
пробовал сначала как то типа так. Каждый челик себе "бронировал" клетку на которой находится, и другие пытались обходить его. Но тут опять же, унылое движение по клеточкам + даже до 1000 сущностей без просадок не дошло, т.к. пересчитывать путь очень затратно.
>>35808
бро, я с годотом только вторую неделю вожусь (и вообще это мой первый движок), но разве это не прямой велосипед? Просто это ведь именно как коллизии и звучит, только костыльные, при том, что в движке есть готовое решение и оно по идее должно работать оптимально. Или я не так понял мб, но короче я скачал одну демку с boids, вот там точно так же это пытаются хэндлить, у каждой сущности есть шейп и каждая сущность высчитывает движение исходя из позиций других сущностей, попавших в этот шейп, но эта хуйня уже на сотне боидов мне просадки в <30 фпс дала.
>>35822
Да я же нигде не писал, что юзаю именно кинематикбади. У меня на рейкастах и ареях всё.
Я наверное очень тупо вопрос описал. Проблема не в том, что я не знаю, как управлять тысячами сущностей как я хочу, проблема была в том, что они могут сбиваться в толпу, и разгон их, с пересчетом цели движения - вот эта хуйня затратная. Я решил это так, как описал, замораживаю их и аккумулирую в очереди, которая разбирается потихоньку. Разбираю очередь циклом, каждый фрейм, но каждую итерацию я чекаю сколько прошло времени с начала обработки очереди в этом кадре и если это время больше, скажем, половины миллисекунды - прекращаю этот процесс.
И мне почему то кажется, что это велосипед и должно быть готовое решение, это ж движок. А вот такие работы на фоне же вряд ли должны быть редкостью, ну реально, разные вещи имеют разный приоритет, что то нужно каждый кадр делать, а что то нужно просто сделать, похуй когда. При этом в другом потоке это делать, как я понял, не выйдет, потому что мне нужно что бы данные были с одного фрейма. Ничего просто не смог нагуглить нормального типа godot worker, godot tasks, godot jobs
>>35784
Группировать никого не пришлось, получилось все так как я описал, каждый по отдельности вычисляет свое движение
>>35785
не ртс, да и больше нескольких сотен сущностей одновременно будет вряд-ли, просто пытаюсь делать оптимально, так, чтобы был максимальный запас для производительности
>>35796
вообще недопонимание между нами произошло. По клеткам двигать это же отстой. Если я не хочу движения по клеткам астар вообще не подходит (у меня тайловый мир разрушаемыми клеточками), да и для производительности астар неоч в моей ситуации, а типо как поле потенциалов сделать, рассчитав все заранее тоже не подойдет, т.к. у меня все полностью разрушаемое. Без коллизий тоже не выйдет, потому что они тогда все постакаются в одну текстуру, но я и не говорил что юзаю body, оказалось на raycast'ах можно одновременно тысячи пацанчиков водить так, чтобы они обходили друг друга, при чем вычисляя для каждого движение каждый фрейм.
>>35810
пробовал сначала как то типа так. Каждый челик себе "бронировал" клетку на которой находится, и другие пытались обходить его. Но тут опять же, унылое движение по клеточкам + даже до 1000 сущностей без просадок не дошло, т.к. пересчитывать путь очень затратно.
>>35808
бро, я с годотом только вторую неделю вожусь (и вообще это мой первый движок), но разве это не прямой велосипед? Просто это ведь именно как коллизии и звучит, только костыльные, при том, что в движке есть готовое решение и оно по идее должно работать оптимально. Или я не так понял мб, но короче я скачал одну демку с boids, вот там точно так же это пытаются хэндлить, у каждой сущности есть шейп и каждая сущность высчитывает движение исходя из позиций других сущностей, попавших в этот шейп, но эта хуйня уже на сотне боидов мне просадки в <30 фпс дала.
>>35822
Да я же нигде не писал, что юзаю именно кинематикбади. У меня на рейкастах и ареях всё.
Я наверное очень тупо вопрос описал. Проблема не в том, что я не знаю, как управлять тысячами сущностей как я хочу, проблема была в том, что они могут сбиваться в толпу, и разгон их, с пересчетом цели движения - вот эта хуйня затратная. Я решил это так, как описал, замораживаю их и аккумулирую в очереди, которая разбирается потихоньку. Разбираю очередь циклом, каждый фрейм, но каждую итерацию я чекаю сколько прошло времени с начала обработки очереди в этом кадре и если это время больше, скажем, половины миллисекунды - прекращаю этот процесс.
И мне почему то кажется, что это велосипед и должно быть готовое решение, это ж движок. А вот такие работы на фоне же вряд ли должны быть редкостью, ну реально, разные вещи имеют разный приоритет, что то нужно каждый кадр делать, а что то нужно просто сделать, похуй когда. При этом в другом потоке это делать, как я понял, не выйдет, потому что мне нужно что бы данные были с одного фрейма. Ничего просто не смог нагуглить нормального типа godot worker, godot tasks, godot jobs
Группировать никого не пришлось, получилось все так как я описал, каждый по отдельности вычисляет свое движение
>>35785
не ртс, да и больше нескольких сотен сущностей одновременно будет вряд-ли, просто пытаюсь делать оптимально, так, чтобы был максимальный запас для производительности
>>35796
вообще недопонимание между нами произошло. По клеткам двигать это же отстой. Если я не хочу движения по клеткам астар вообще не подходит (у меня тайловый мир разрушаемыми клеточками), да и для производительности астар неоч в моей ситуации, а типо как поле потенциалов сделать, рассчитав все заранее тоже не подойдет, т.к. у меня все полностью разрушаемое. Без коллизий тоже не выйдет, потому что они тогда все постакаются в одну текстуру, но я и не говорил что юзаю body, оказалось на raycast'ах можно одновременно тысячи пацанчиков водить так, чтобы они обходили друг друга, при чем вычисляя для каждого движение каждый фрейм.
>>35810
пробовал сначала как то типа так. Каждый челик себе "бронировал" клетку на которой находится, и другие пытались обходить его. Но тут опять же, унылое движение по клеточкам + даже до 1000 сущностей без просадок не дошло, т.к. пересчитывать путь очень затратно.
>>35808
бро, я с годотом только вторую неделю вожусь (и вообще это мой первый движок), но разве это не прямой велосипед? Просто это ведь именно как коллизии и звучит, только костыльные, при том, что в движке есть готовое решение и оно по идее должно работать оптимально. Или я не так понял мб, но короче я скачал одну демку с boids, вот там точно так же это пытаются хэндлить, у каждой сущности есть шейп и каждая сущность высчитывает движение исходя из позиций других сущностей, попавших в этот шейп, но эта хуйня уже на сотне боидов мне просадки в <30 фпс дала.
>>35822
Да я же нигде не писал, что юзаю именно кинематикбади. У меня на рейкастах и ареях всё.
Я наверное очень тупо вопрос описал. Проблема не в том, что я не знаю, как управлять тысячами сущностей как я хочу, проблема была в том, что они могут сбиваться в толпу, и разгон их, с пересчетом цели движения - вот эта хуйня затратная. Я решил это так, как описал, замораживаю их и аккумулирую в очереди, которая разбирается потихоньку. Разбираю очередь циклом, каждый фрейм, но каждую итерацию я чекаю сколько прошло времени с начала обработки очереди в этом кадре и если это время больше, скажем, половины миллисекунды - прекращаю этот процесс.
И мне почему то кажется, что это велосипед и должно быть готовое решение, это ж движок. А вот такие работы на фоне же вряд ли должны быть редкостью, ну реально, разные вещи имеют разный приоритет, что то нужно каждый кадр делать, а что то нужно просто сделать, похуй когда. При этом в другом потоке это делать, как я понял, не выйдет, потому что мне нужно что бы данные были с одного фрейма. Ничего просто не смог нагуглить нормального типа godot worker, godot tasks, godot jobs
1,9 Мб, 600x338>>35947
Астар это не клеточки, это вообще граф узлов.
Ну и вообще то была демка навигейшн сервера. Там же динамические уровни.
Астар это не клеточки, это вообще граф узлов.
Ну и вообще то была демка навигейшн сервера. Там же динамические уровни.
>>35947
Как у тебя сочетается клеточный мир из разрушаемых блоков с тем, что движение не по клеткам и а-стар по какой-то причине не подходит? А-стар лучше всего подходит именно для таких клеточных миров и сочетается с разрушаемостью блоков. Тебе просто не нужно перемещать фигурки строго по клеткам. Используй результат поиска пути а-старом только как приблизительный маршрут, которому боты должны следовать по возможности, но могут отклоняться по необходимости. А-старом можно построить маршрут даже для физически двигающихся автомобилей (VehicleBody).
В чём проблема обновлять а-стар динамически? Встроенный класс позволяет произвольно добавлять и удалять узлы с любыми ID, а также временно блокировать отдельные узлы без удаления (примеры использования: двери с замком, большие коробки и т.п.).
Так в чём проблема договориться между двумя ботами, кто первым из них уступит дорогу другому? Как я понимаю проблему, боты сталкиваются лоб в лоб и не могут уступить дорогу, следовательно, один из них должен обойти другого первым, а этот другой пусть подождёт. Прямо как ИРЛ (несколько раз у меня было такое, что я и другой человек пытаемся обойти друг друга с одной и той же стороны, лишь чтобы столкнуться повторно - пока один не уступит дорогу, так что это на самом деле очень реалистичная проблема).
>Если я не хочу движения по клеткам астар вообще не подходит (у меня тайловый мир разрушаемыми клеточками)
Как у тебя сочетается клеточный мир из разрушаемых блоков с тем, что движение не по клеткам и а-стар по какой-то причине не подходит? А-стар лучше всего подходит именно для таких клеточных миров и сочетается с разрушаемостью блоков. Тебе просто не нужно перемещать фигурки строго по клеткам. Используй результат поиска пути а-старом только как приблизительный маршрут, которому боты должны следовать по возможности, но могут отклоняться по необходимости. А-старом можно построить маршрут даже для физически двигающихся автомобилей (VehicleBody).
>рассчитав все заранее тоже не подойдет, т.к. у меня все полностью разрушаемое.
В чём проблема обновлять а-стар динамически? Встроенный класс позволяет произвольно добавлять и удалять узлы с любыми ID, а также временно блокировать отдельные узлы без удаления (примеры использования: двери с замком, большие коробки и т.п.).
>проблема была в том, что они могут сбиваться в толпу, и разгон их, с пересчетом цели движения
Так в чём проблема договориться между двумя ботами, кто первым из них уступит дорогу другому? Как я понимаю проблему, боты сталкиваются лоб в лоб и не могут уступить дорогу, следовательно, один из них должен обойти другого первым, а этот другой пусть подождёт. Прямо как ИРЛ (несколько раз у меня было такое, что я и другой человек пытаемся обойти друг друга с одной и той же стороны, лишь чтобы столкнуться повторно - пока один не уступит дорогу, так что это на самом деле очень реалистичная проблема).
>>35950
У меня мир клеточный сам и каждая клетка разрушаемая, в т.ч. самими ботами. Я в таком случае могу видеть астар только как клеточки с разным weight. Конечно, ничего невозможного нет, но я предполагаю, что обойтись в таком случае без клеточек будет очень тяжело.
Навигейшн2д, насколько я понял, в моём случае, где каждый из 1к ботов должен обходить других 999, так это ещё и при том, что мир очень динамично изменяется, потому что вся эта туса может ломать клеточки если захочет, вообще ничем не поможет.
У меня мир клеточный сам и каждая клетка разрушаемая, в т.ч. самими ботами. Я в таком случае могу видеть астар только как клеточки с разным weight. Конечно, ничего невозможного нет, но я предполагаю, что обойтись в таком случае без клеточек будет очень тяжело.
Навигейшн2д, насколько я понял, в моём случае, где каждый из 1к ботов должен обходить других 999, так это ещё и при том, что мир очень динамично изменяется, потому что вся эта туса может ломать клеточки если захочет, вообще ничем не поможет.
>>35951
Я имел ввиду, что не хочу, чтобы сущности двигалались как по шахматной доске. Вообще я астар на самом деле использую, но только для длинных путешествий, да.
А это я не про астар, другой алгоритм есть похожий, не помню как называется, но там суть в том, что изначально просто рассчитывается для каждой клетки карты направление, в которое нужно двигаться, чтобы добраться до цели и получается градиент такой. Работает очень быстро, но пересчитывать всё поле на каждое изменение - очень затратно.
2 бота это хуйня, они все стараются друг друга избегать, итак обойдут. Даже толпа на толпу обойдут друг друга. Я о других кейсах. Что если есть туннель, и в одну сторону шагает одна группа, а в другую - другая? Как тут договорится? На самом деле договорится между всеми ими можно, но это слишком долго для одного фрейма. Поэтому я их замораживаю и договариваю на фоне, так, как я описал в последних абзацах.
>Как у тебя сочетается клеточный мир из разрушаемых блоков с тем, что движение не по клеткам и а-стар по какой-то причине не подходит?
Я имел ввиду, что не хочу, чтобы сущности двигалались как по шахматной доске. Вообще я астар на самом деле использую, но только для длинных путешествий, да.
> чём проблема обновлять а-стар динамически? Встроенный класс позволяет произвольно добавлять и удалять узлы с любыми ID, а также временно блокировать отдельные узлы без удаления (примеры использования: двери с замком, большие коробки и т.п.).
А это я не про астар, другой алгоритм есть похожий, не помню как называется, но там суть в том, что изначально просто рассчитывается для каждой клетки карты направление, в которое нужно двигаться, чтобы добраться до цели и получается градиент такой. Работает очень быстро, но пересчитывать всё поле на каждое изменение - очень затратно.
>Так в чём проблема договориться между двумя ботами, кто первым из них уступит дорогу другому? Как я понимаю проблему, боты сталкиваются лоб в лоб и не могут уступить дорогу, следовательно, один из них должен обойти другого первым, а этот другой пусть подождёт. Прямо как ИРЛ (несколько раз у меня было такое, что я и другой человек пытаемся обойти друг друга с одной и той же стороны, лишь чтобы столкнуться повторно - пока один не уступит дорогу, так что это на самом деле очень реалистичная проблема).
2 бота это хуйня, они все стараются друг друга избегать, итак обойдут. Даже толпа на толпу обойдут друг друга. Я о других кейсах. Что если есть туннель, и в одну сторону шагает одна группа, а в другую - другая? Как тут договорится? На самом деле договорится между всеми ими можно, но это слишком долго для одного фрейма. Поэтому я их замораживаю и договариваю на фоне, так, как я описал в последних абзацах.
>>35952
Астар это не клеточки, это граф, который на этапе инициализации ты сам заполняешь клеточками.
Там даже метод для удаления клеточек есть.
Чувак у которого самый известный туториал по астару, даже специально как-то переписал туториал с клеточек на произвольную карту, чтобы все были в курсе.
>астар только как клеточки
Астар это не клеточки, это граф, который на этапе инициализации ты сам заполняешь клеточками.
Там даже метод для удаления клеточек есть.
Чувак у которого самый известный туториал по астару, даже специально как-то переписал туториал с клеточек на произвольную карту, чтобы все были в курсе.
>>35952
Либо я очень хуёво выражаю свои мысли, либо ты нихуя не понимаешь меня. Я знаю что такое астар, но я не понимаю, как мне строить астар, кроме как клеточным полем для именно моей карты. Потому что моя карта клеточная, клетка может быть либо проходимой либо не проходимой, но разрушаемой (как игроком, так и ботами). Если бы боты вычисляли свой путь только по проходимым тайлам, то я может и попробовал бы как то изъебнуться, но они вычисляют путь с учётом того, что им можно ломать непроходимые клетки.
Либо я очень хуёво выражаю свои мысли, либо ты нихуя не понимаешь меня. Я знаю что такое астар, но я не понимаю, как мне строить астар, кроме как клеточным полем для именно моей карты. Потому что моя карта клеточная, клетка может быть либо проходимой либо не проходимой, но разрушаемой (как игроком, так и ботами). Если бы боты вычисляли свой путь только по проходимым тайлам, то я может и попробовал бы как то изъебнуться, но они вычисляют путь с учётом того, что им можно ломать непроходимые клетки.
>>35953
Так ты же сам говорил, что они могут прокапывать новые ходы. Почему бы им не расширить туннель до двух клеток, чтобы группы могли разойтись?
>>35955
Клеточным и строй. Чтобы движения не выглядели "шахматными", можно удалять промежуточные точки маршрута и сглаживать углы. А если твои клетки карты дофига огромные в сравнении с персонажем, то можно отмечать эти клетки несколькими точками. Весь вопрос в том, насколько большая у тебя карта.
Вот с этого и нужно было начинать. Это не проблема для а-стар, во всяком случае в реализации Godot. Тебе нужно просто присвоить "непроходимым" клеткам более высокий вес, чтобы а-стар по возможности их обходил, а в отсутствии такой возможности - копал.
Пример:
1+1+1+1+1+1 = 6
1+5+1 = 7
=> обойти лучше, чем пробивать стену.
1+1+1+1+1+1+1+1 = 8
1+5+1 = 7
=> лучше пробить стену, чем идти в обход.
>Что если есть туннель, и в одну сторону шагает одна группа, а в другую - другая?
Так ты же сам говорил, что они могут прокапывать новые ходы. Почему бы им не расширить туннель до двух клеток, чтобы группы могли разойтись?
>>35955
>как мне строить астар, кроме как клеточным полем для именно моей карты
Клеточным и строй. Чтобы движения не выглядели "шахматными", можно удалять промежуточные точки маршрута и сглаживать углы. А если твои клетки карты дофига огромные в сравнении с персонажем, то можно отмечать эти клетки несколькими точками. Весь вопрос в том, насколько большая у тебя карта.
>они вычисляют путь с учётом того, что им можно ломать непроходимые клетки
Вот с этого и нужно было начинать. Это не проблема для а-стар, во всяком случае в реализации Godot. Тебе нужно просто присвоить "непроходимым" клеткам более высокий вес, чтобы а-стар по возможности их обходил, а в отсутствии такой возможности - копал.
Пример:
1+1+1+1+1+1 = 6
1+5+1 = 7
=> обойти лучше, чем пробивать стену.
1+1+1+1+1+1+1+1 = 8
1+5+1 = 7
=> лучше пробить стену, чем идти в обход.
>>36170
Я не троллю. Видимо, тебя снова никто не понял. Не можешь просто показать скриншоты/видео геймплея игры или хотя бы описать подробно суть геймплея? Потому что любые решения зависят от конкретной задумки. Мы тебе дали самые общие советы, т.к. ты ничего толком не описал, даже про то, что боты могут ломать непроходимые блоки не сразу написал (обычно даже если ландшафт разрушаемый, мобы не ломают блоки, или ломают неосознанно).
Я не троллю. Видимо, тебя снова никто не понял. Не можешь просто показать скриншоты/видео геймплея игры или хотя бы описать подробно суть геймплея? Потому что любые решения зависят от конкретной задумки. Мы тебе дали самые общие советы, т.к. ты ничего толком не описал, даже про то, что боты могут ломать непроходимые блоки не сразу написал (обычно даже если ландшафт разрушаемый, мобы не ломают блоки, или ломают неосознанно).
>>36196
Но я затроллился, жесточайше
Дело в том, что я вообще не спрашивал про то, как мне навигаци/коллизии делать ни разу, это я уже сделал и написал в первом >>35782
посте:
Вопрос был вот в этом:
Вот что я пока решил:
Записываю таких проблемных в очередь.
В отдельной ноде буду разгребать эту очередь, но разгребать в каждый фрейм буду ровно столько, сколько успеется за 1/10 от 60/120 (десятую часть от среднего фрейма из фреймрейта в 120 фпс). Тогда ниче тормозить не будет даже на мобилках каких-нибудь.
В чем я проебался?
Может есть какие то готовые решения? Никак не смог нагуглить.
Я хочу аккумулировать затратные вычисления и по чуть-чуть их разгребать, так, что бы в конце концов все обработолось, но при этом это 0 влияния на производительность давало, вместо того, чтобы вычислять всё каждый фрейм. Вопрос был есть ли готовые решения или best practices
Но я затроллился, жесточайше
Дело в том, что я вообще не спрашивал про то, как мне навигаци/коллизии делать ни разу, это я уже сделал и написал в первом >>35782
посте:
>У меня тысячи сущностей гуляют, ищут путь, толкаются и ловят ебалом пули. На удивление они всё это делают с успехом на физике в 60 фпс, если не сбиваются в толпу и блочат друг друга. Я отлавливаю то, что они блочат друг друга и замораживаю
Вопрос был вот в этом:
>А далее начинаются трудности, я знаю как их разогнать, но для этого нужно много вычислений, поиск пути, тонны рэйкастов. И вот это делать вообще не обязательно каждый фрейм.
Вот что я пока решил:
Записываю таких проблемных в очередь.
В отдельной ноде буду разгребать эту очередь, но разгребать в каждый фрейм буду ровно столько, сколько успеется за 1/10 от 60/120 (десятую часть от среднего фрейма из фреймрейта в 120 фпс). Тогда ниче тормозить не будет даже на мобилках каких-нибудь.
В чем я проебался?
Может есть какие то готовые решения? Никак не смог нагуглить.
Я хочу аккумулировать затратные вычисления и по чуть-чуть их разгребать, так, что бы в конце концов все обработолось, но при этом это 0 влияния на производительность давало, вместо того, чтобы вычислять всё каждый фрейм. Вопрос был есть ли готовые решения или best practices
>>36224
Вопрос был вот в этом:
Я хочу аккумулировать затратные вычисления и по чуть-чуть их разгребать, так, что бы в конце концов все обработолось, но при этом это 0 влияния на производительность давало, вместо того, чтобы вычислять всё каждый фрейм. Вопрос был есть ли готовые решения или best practices
Вопрос был вот в этом:
>А далее начинаются трудности, я знаю как их разогнать, но для этого нужно много вычислений, поиск пути, тонны рэйкастов. И вот это делать вообще не обязательно каждый фрейм.
>Вот что я пока решил:
>
>Записываю таких проблемных в очередь.
>В отдельной ноде буду разгребать эту очередь, но разгребать в каждый фрейм буду ровно столько, сколько успеется за 1/10 от 60/120 (десятую часть от среднего фрейма из фреймрейта в 120 фпс). Тогда ниче тормозить не будет даже на мобилках каких-нибудь.
>В чем я проебался?
>Может есть какие то готовые решения? Никак не смог нагуглить.
Я хочу аккумулировать затратные вычисления и по чуть-чуть их разгребать, так, что бы в конце концов все обработолось, но при этом это 0 влияния на производительность давало, вместо того, чтобы вычислять всё каждый фрейм. Вопрос был есть ли готовые решения или best practices
Суп, годоны, пилю свой columns с отклонениями и изобрел там фигуры-комбухи. Но не могу придумать как отображать их когда ты собрал то что нужно. Нашел кучу гайдов с инвентарь системой через GridContainer, но может как то проще можно?
>>36224
Если ты всё уже решил и сделал, и работает нормально на тестовых машинах, то зачем было спрашивать, лол, вопроса по сути и нет. Ты правильно сделал, что разделяешь долгую работу на несколько кадров, хотя непонятно как ты определяешь сложность работы. Каких-то готовых решений тут быть не может, т.к. решение зависит от задачи, а задачу ты упорно не хочешь описывать. Единственное готовое решение - это многопоточность, но, как ты понимаешь, её эффективность зависит от алгоритма и количества ядер целевой машины. Также многопоточность вносит свои проблемы, так что лучше с ней без надобности не связываться.
>>36228
Ты тоже непонятно объясняешь, приложил бы хотя бы скриншоты. Я погуглил, знаю эту игру, но не могу понять, о каких "комбухах" ты говоришь. Ну, замени их спрайты? Обвели рамочкой? Перекрась в особый цвет? У тебя своего видения игры нет что ли или что?
Это потомок Control, предназначен для построения графического интерфейса и поэтому плохо подходит для геймплея. Лучше делай на спрайтах. Тебе же всего лишь массив целых чисел вывести на экран нужно, зачем мудрить. Спрайтами ты что угодно нарисовать можешь, без ограничений интерфейса.
Если ты всё уже решил и сделал, и работает нормально на тестовых машинах, то зачем было спрашивать, лол, вопроса по сути и нет. Ты правильно сделал, что разделяешь долгую работу на несколько кадров, хотя непонятно как ты определяешь сложность работы. Каких-то готовых решений тут быть не может, т.к. решение зависит от задачи, а задачу ты упорно не хочешь описывать. Единственное готовое решение - это многопоточность, но, как ты понимаешь, её эффективность зависит от алгоритма и количества ядер целевой машины. Также многопоточность вносит свои проблемы, так что лучше с ней без надобности не связываться.
>>36228
Ты тоже непонятно объясняешь, приложил бы хотя бы скриншоты. Я погуглил, знаю эту игру, но не могу понять, о каких "комбухах" ты говоришь. Ну, замени их спрайты? Обвели рамочкой? Перекрась в особый цвет? У тебя своего видения игры нет что ли или что?
>GridContainer
Это потомок Control, предназначен для построения графического интерфейса и поэтому плохо подходит для геймплея. Лучше делай на спрайтах. Тебе же всего лишь массив целых чисел вывести на экран нужно, зачем мудрить. Спрайтами ты что угодно нарисовать можешь, без ограничений интерфейса.
>>36271
Да я ебан немного, вот и не объяснил. Собственно спрайт мне и нужно показать. Для геймплея оно не нужно, это просто отображение того что ты что-то сделал, как ачивка в рамках сессии.
Собираешь на поле фигуру вида
010
111
010
и лутаешь с этого мультиплер к очкам. Вот мне надо как то это отобразить. Пилю потихоньку UI где буду просто справйты включать через show/hide.
сейчас другое голову ебет, если растягивать окно, то все снапится к левой строне.
Да я ебан немного, вот и не объяснил. Собственно спрайт мне и нужно показать. Для геймплея оно не нужно, это просто отображение того что ты что-то сделал, как ачивка в рамках сессии.
>о каких "комбухах" ты говоришь
Собираешь на поле фигуру вида
010
111
010
и лутаешь с этого мультиплер к очкам. Вот мне надо как то это отобразить. Пилю потихоньку UI где буду просто справйты включать через show/hide.
сейчас другое голову ебет, если растягивать окно, то все снапится к левой строне.
35 Кб, 430x600>>36271
И насчет видения игры, у меня она готова, я просто допиливаю всякое говно чтобы было поинтересней.
На скрине полупрозрачная одна из фигур которые можно собрать чтобы полутать иксы. Вот справа дохуя места и там я планировал отображать собранные. Если туда что-то влезет вообще, лол.
И насчет видения игры, у меня она готова, я просто допиливаю всякое говно чтобы было поинтересней.
На скрине полупрозрачная одна из фигур которые можно собрать чтобы полутать иксы. Вот справа дохуя места и там я планировал отображать собранные. Если туда что-то влезет вообще, лол.
87 Кб, 225x225Сап, годач! Я вернулся ( >>35437 >>35362 )
Ну в общем, немного освоился в свежей винде. Почти оправился от шока. Но работать пока не могу, занимаюсь различными мелкими настройками свистоперделок.
В связи с чем хочу посоветовать всем вам (ВО ПЕРВЫХ КОНЕЧНО ЖЕ БЭКАПИТЬСЯ БЛЯТЬ И ХРАНИТЬ ВСЕ ПРОЕКТЫ В РЕПАХ)
А, так вот, хочу посоветовать вам scoop. Крутая утила. Почти пакетный менеджер для венды. Давно хотел их попробовать и вот предоставилась возможность.
Вообще их много разных уже для венды есть, chocolatey, npackd, но я изучив их, остановился на скупе. Основная фишка, которую я сначала не понял, а потом кааак пооонял - это установка всех приложух в профиль юзера. В портативном режиме. Без привилегий админа. Зачем это нужно? Представь. У тебя встройка, на которой еле еле годот в глес2 тянет. А тебе надо проверить, как твоя игора запустится на совершенно чистой посторонней системе? Какие пререквизиты нужно упаковать в комплект? Виртуалку завести? Оперативки не хватит. Второго компа нет. Друзей нет. Так вот, девелопинг через локальные портативные приложения даёт тебе возможность без задней мысли завести второго пользователя в котором ничего этого установленного не будет. Чистая система, в которой есть только твой установщик.
А чего там можно установить-то?
Через скуп можно даже дотнет-кор поставить, и он реально будет локальным. Не говоря уже о вещах попроще. Годот - без проблем, включая моноверсию.
Хехе, понел, да? Инсталь годот!
Ну в общем, немного освоился в свежей винде. Почти оправился от шока. Но работать пока не могу, занимаюсь различными мелкими настройками свистоперделок.
В связи с чем хочу посоветовать всем вам (ВО ПЕРВЫХ КОНЕЧНО ЖЕ БЭКАПИТЬСЯ БЛЯТЬ И ХРАНИТЬ ВСЕ ПРОЕКТЫ В РЕПАХ)
А, так вот, хочу посоветовать вам scoop. Крутая утила. Почти пакетный менеджер для венды. Давно хотел их попробовать и вот предоставилась возможность.
Вообще их много разных уже для венды есть, chocolatey, npackd, но я изучив их, остановился на скупе. Основная фишка, которую я сначала не понял, а потом кааак пооонял - это установка всех приложух в профиль юзера. В портативном режиме. Без привилегий админа. Зачем это нужно? Представь. У тебя встройка, на которой еле еле годот в глес2 тянет. А тебе надо проверить, как твоя игора запустится на совершенно чистой посторонней системе? Какие пререквизиты нужно упаковать в комплект? Виртуалку завести? Оперативки не хватит. Второго компа нет. Друзей нет. Так вот, девелопинг через локальные портативные приложения даёт тебе возможность без задней мысли завести второго пользователя в котором ничего этого установленного не будет. Чистая система, в которой есть только твой установщик.
А чего там можно установить-то?
Через скуп можно даже дотнет-кор поставить, и он реально будет локальным. Не говоря уже о вещах попроще. Годот - без проблем, включая моноверсию.
> scoop bucket add extras
> scoop install godot
Хехе, понел, да? Инсталь годот!
90 Кб, 822x606>>35946
Попытался переписать код с GDScript на шейдеры - на экране ничего нет, игра падает спустя несколько секунд ощутимо нагрузив видеокарту, аж экран мигает. Но никаких ошибок или какой-либо информации о происходящем нет...
Всё, нафиг, не буду этим больше заниматься, мне уже не интересно, какая такая магия рисует свет и тени в террария-подобных играх, это в любом случае за гранью моего понимания.
Попытался переписать код с GDScript на шейдеры - на экране ничего нет, игра падает спустя несколько секунд ощутимо нагрузив видеокарту, аж экран мигает. Но никаких ошибок или какой-либо информации о происходящем нет...
Всё, нафиг, не буду этим больше заниматься, мне уже не интересно, какая такая магия рисует свет и тени в террария-подобных играх, это в любом случае за гранью моего понимания.
>>36493
Думаю у тебя ошибка в for. Шейдерный язык, вроде, похож на c++, поэтому там должно быть написано в третьем выражении x = x + pixel_size.x,
ты же написать просто x + pixel_size.x, что попросту отбрасывается, x новое значение не присваивается, x никогда не увеличивается, условие всегда истинно, и у тебя бесконечный цикл.
Думаю у тебя ошибка в for. Шейдерный язык, вроде, похож на c++, поэтому там должно быть написано в третьем выражении x = x + pixel_size.x,
ты же написать просто x + pixel_size.x, что попросту отбрасывается, x новое значение не присваивается, x никогда не увеличивается, условие всегда истинно, и у тебя бесконечный цикл.
Где рисовать красочные 2д картинки?
Как делают элементы интерфейса-списки там,менюшки?
Как делают элементы интерфейса-списки там,менюшки?
>>36683
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#flow-control
Возможно, проблема в том, что там float вместо int, но компилятор ничего на этот счёт не пишет.
>>36692
Потому что GDScript намного проще, подходит для решения большинства типовых задач и достаточно быстрый для большинства игр. Будешь переписывать код на C# или C++ только если столкнёшься с необходимостью написать код на более быстром языке.
>>36690
Krita, Inkscape, Blender и т.д.
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
>там должно быть написано в третьем выражении x = x + pixel_size.x,
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#flow-control
>// for loops
>for (int i = 0; i < 10; i++) {
>}
Возможно, проблема в том, что там float вместо int, но компилятор ничего на этот счёт не пишет.
>>36692
Потому что GDScript намного проще, подходит для решения большинства типовых задач и достаточно быстрый для большинства игр. Будешь переписывать код на C# или C++ только если столкнёшься с необходимостью написать код на более быстром языке.
>>36690
>Где рисовать красочные 2д картинки?
Krita, Inkscape, Blender и т.д.
>Как делают элементы интерфейса
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
>>36683
А, точно, я перепутал, спасибо. Тупо скопипастил свой код на GDScript и исправлял ошибки, которые указывал компилятор, а на это место компилятор не ругался. Вот поэтому си-подобные языки такое говно - позволяют делать совершенно бессмысленные вещи максимально нечитабельным способом...
Исправил, заработало - по крайней мере не падает.
>в третьем выражении x = x + pixel_size.x,
А, точно, я перепутал, спасибо. Тупо скопипастил свой код на GDScript и исправлял ошибки, которые указывал компилятор, а на это место компилятор не ругался. Вот поэтому си-подобные языки такое говно - позволяют делать совершенно бессмысленные вещи максимально нечитабельным способом...
Исправил, заработало - по крайней мере не падает.
>>35774
Шарп, он пригодится ещё много где.
Шарп, он пригодится ещё много где.
56 Кб, 800x600>>36683
Ещё раз спасибо, шейдер заработал. Теперь нет ощутимого лага при изменении блока, зато есть огромная стабильная просадка производительности по видеокарте. Наверное, это можно как-то (через вьюпорт) кэшировать, вызывая этот шейдер только один раз на каждое изменение блоков...
...но я уже потерял интерес к проекту и решил его забросить до следующего раза. Не мой тип игр - в такое играть куда интереснее, чем делать самому.
Ещё раз спасибо, шейдер заработал. Теперь нет ощутимого лага при изменении блока, зато есть огромная стабильная просадка производительности по видеокарте. Наверное, это можно как-то (через вьюпорт) кэшировать, вызывая этот шейдер только один раз на каждое изменение блоков...
...но я уже потерял интерес к проекту и решил его забросить до следующего раза. Не мой тип игр - в такое играть куда интереснее, чем делать самому.
10 Кб, 352x127Сижу разбираюсь в 4-ке
Теперь фильтрация текстур не в импорте, а в самих нодах, причем с наследованием. наверное это логично, это же не свойство картинки, а свойство использования.
Теперь фильтрация текстур не в импорте, а в самих нодах, причем с наследованием. наверное это логично, это же не свойство картинки, а свойство использования.
3 Кб, 241x33>>37111
А, у вектора можно проще округление писать.
А, у вектора можно проще округление писать.
36 Кб, 396x285>>37113
Доучивай, там процентов 80-90 никуда не денется же.
---
AnimationTree возвращает не строки, а StringName, они же хешированые кешированные строки. Матч с обычными строками не сработало, надо писать &"yourtext". При этом в обычном сравнении есть неявный каст и все ок ("aaa" == &"aaa")
Доучивай, там процентов 80-90 никуда не денется же.
---
AnimationTree возвращает не строки, а StringName, они же хешированые кешированные строки. Матч с обычными строками не сработало, надо писать &"yourtext". При этом в обычном сравнении есть неявный каст и все ок ("aaa" == &"aaa")
14 Кб, 395x107Читал ща доки и теперь не пойму почему некоторые строки не считаются Safe Line, теперь у меня из-за этого багет, лучше бы дальше не знал.
Как он хочет чтобы было написано, чтобы прокнул Safe Line?
Как он хочет чтобы было написано, чтобы прокнул Safe Line?
>>37123
Что нибудь из серии
var next_piece : PieceClass = ...
или
next_piece = find_node(...) as PieceClass
Или
next_piece = get_next_piece()
...
get_next_piece() -> PieceClass: return piece
Что нибудь из серии
var next_piece : PieceClass = ...
или
next_piece = find_node(...) as PieceClass
Или
next_piece = get_next_piece()
...
get_next_piece() -> PieceClass: return piece
Как поменять локаль по кнопке? Если в func _ready() прописать TranslationServer.set_locale("en") то локаль меняется.. Но если в func _on_Button_toggled(button_pressed) добавить TranslationServer.set_locale("en"), то ничего не меняется. Как быть?
>>37111
Геттеры и сеттеры очень часто являются плохой практикой. (Да почти любой размен очевидности кода на его краткость является плохой практикой.) Вот забудешь ты про какой-то геттер/сеттер, начнёшь обращаться с типом так, как будто он без них, в итоге полезут странные баги.
мимо js-ник с 11-летним стажем
Геттеры и сеттеры очень часто являются плохой практикой. (Да почти любой размен очевидности кода на его краткость является плохой практикой.) Вот забудешь ты про какой-то геттер/сеттер, начнёшь обращаться с типом так, как будто он без них, в итоге полезут странные баги.
мимо js-ник с 11-летним стажем
Всем привет!
Как сделать прогрессбар, как в Байонетте? Чтобы несколько полосок разных цветов уменьшались по очереди, пока пиздишь босса.
Несколько прогрессбаров в кучке не предлагать.
Как сделать прогрессбар, как в Байонетте? Чтобы несколько полосок разных цветов уменьшались по очереди, пока пиздишь босса.
Несколько прогрессбаров в кучке не предлагать.
>>37234
1. Возьми боксконтейнер.
2. Напихай в него текстур ректов.
3. Всем ректам выстави экспанд флаг.
4. Последним добавь контрол-пустышку.
5. С помощью минимального сайза уменьшай размер текущего ректа в цепочке.
6. Когда он достигает 0 переходи к следующему.
7. Когда до нуля дошёл последний - это значит закончилась последняя из "жизней" и весь бокс занимает пустышка, показывая подложку под прогрессбаром.
8. ПРОФИТ!
Плюсы - элементарная реализация.
Минусы - нет возможности легко организовать анимацию урона.
Чтобы реализовать анимацию урона, нужно между каждой парой ректов-баров в цепочке вставить дополнительный рект-урон и затем рассчитывать минимум-сайзы для текущего ректа-бара и ректа-урона. Нанесение урона = мгновенное увеличение ректа-урона на N и мгновенное же уменьшение ректа-бара, затем по твину ты постепенно уменьшаешь рект-урон. Визуально это будет выглядеть так же, как в популярных игорах: нанесённый урон сразу отображается фрагментом другого цвета/текстуры, затем этот другой цвет уменьшается пока не исчезнет, оставляя владельца прогресс-бара с тем количеством жизней, какое у него осталось.
1. Возьми боксконтейнер.
2. Напихай в него текстур ректов.
3. Всем ректам выстави экспанд флаг.
4. Последним добавь контрол-пустышку.
5. С помощью минимального сайза уменьшай размер текущего ректа в цепочке.
6. Когда он достигает 0 переходи к следующему.
7. Когда до нуля дошёл последний - это значит закончилась последняя из "жизней" и весь бокс занимает пустышка, показывая подложку под прогрессбаром.
8. ПРОФИТ!
Плюсы - элементарная реализация.
Минусы - нет возможности легко организовать анимацию урона.
Чтобы реализовать анимацию урона, нужно между каждой парой ректов-баров в цепочке вставить дополнительный рект-урон и затем рассчитывать минимум-сайзы для текущего ректа-бара и ректа-урона. Нанесение урона = мгновенное увеличение ректа-урона на N и мгновенное же уменьшение ректа-бара, затем по твину ты постепенно уменьшаешь рект-урон. Визуально это будет выглядеть так же, как в популярных игорах: нанесённый урон сразу отображается фрагментом другого цвета/текстуры, затем этот другой цвет уменьшается пока не исчезнет, оставляя владельца прогресс-бара с тем количеством жизней, какое у него осталось.
66 Кб, 778x651>>37252
Конкретно в этом случае все не сложнее, чем просто рисовать на канвасе. И занимает десяток строчек.
https://godotshaders.com/shader/sprite-progress-bar/
>Я не могу в шейдеры. Я их не понимаю.
Конкретно в этом случае все не сложнее, чем просто рисовать на канвасе. И занимает десяток строчек.
https://godotshaders.com/shader/sprite-progress-bar/
>>37257
Имею в виду, что доделать его не сложно. То есть сделать так, что от 0 до progress1 рисуется одна текстура, от progress1 до progress2 вторая, и до конца третья. Или перекрашивать одну текстуру по тем же границам.
Имею в виду, что доделать его не сложно. То есть сделать так, что от 0 до progress1 рисуется одна текстура, от progress1 до progress2 вторая, и до конца третья. Или перекрашивать одну текстуру по тем же границам.
>>37258
Ну я туда ставлю буквку. И сразу всё красным светится. Я это имею виду, когда говорю, что не понимаю шейдеров.
> доделать его не сложно
Ну я туда ставлю буквку. И сразу всё красным светится. Я это имею виду, когда говорю, что не понимаю шейдеров.
>>37202
Звучит невероятно. Для начала добавь в on_button_toggled print("debug") чтобы убедиться что ты вообще туда попадаешь.
Звучит невероятно. Для начала добавь в on_button_toggled print("debug") чтобы убедиться что ты вообще туда попадаешь.
>>37265
Проблема была в том, что я менял текст через скрипт. То есть, запихивал в func _ready() метод set_text. В итоге, просто в самом UI поменял текст на ID локализации. Все заработало. Непонятно объяснил в общем, но проблема решена.
Проблема была в том, что я менял текст через скрипт. То есть, запихивал в func _ready() метод set_text. В итоге, просто в самом UI поменял текст на ID локализации. Все заработало. Непонятно объяснил в общем, но проблема решена.
>>37204
Я, залетевший в годо случайно чтобы сделать себе игру со старого плеера, вообще не понял нахуй они (сетгет) нужны. Все вроде делается и без них, оставаясь читабельным.
Я, залетевший в годо случайно чтобы сделать себе игру со старого плеера, вообще не понял нахуй они (сетгет) нужны. Все вроде делается и без них, оставаясь читабельным.
>>37285
Для валидации передаваемых значений. Для синхронизации с другими элементами. Например, ты записываешь в переменную (HP) значение, а у тебя автоматически, через сеттер, обновляется ярлык на экране, если значение меньше минимального, излучается сигнал (ивент). Конечно же, это всё можно сделать и без сет-геттеров, но для тех, кто привык к ним в других языках, они сделаны и здесь.
> нахуй они (сетгет) нужны
Для валидации передаваемых значений. Для синхронизации с другими элементами. Например, ты записываешь в переменную (HP) значение, а у тебя автоматически, через сеттер, обновляется ярлык на экране, если значение меньше минимального, излучается сигнал (ивент). Конечно же, это всё можно сделать и без сет-геттеров, но для тех, кто привык к ним в других языках, они сделаны и здесь.
>>37246
Велосипед Велосипедович, ты?
Твой велосипед ничем не лучше бутерброда из прогресс-баров, зато имеет кучу недостатков и возможных подводных камней. Не надо так делать.
>>37234
Почему нет? Это именно то, что ты ищешь. Делаешь несколько прогресс-баров с текстурой друг на друге, и управляешь ими по очереди. Пустой прогресс-бар будет просвечивать, отображая нижележащие.
>>37259
Так это и в GDScript так. Только в редакторе GDScript можно увеличить задержку статического анализатора кода, а в редакторе шейдеров я что-то не нашёл такой опции. В любом случае, просто игнорируй сообщение об ошибке, пока не допечатаешь то, что хочешь. Алсо учись слепому вводу, чтобы печатать быстрее.
Велосипед Велосипедович, ты?
Твой велосипед ничем не лучше бутерброда из прогресс-баров, зато имеет кучу недостатков и возможных подводных камней. Не надо так делать.
>>37234
>Несколько прогрессбаров в кучке не предлагать
Почему нет? Это именно то, что ты ищешь. Делаешь несколько прогресс-баров с текстурой друг на друге, и управляешь ими по очереди. Пустой прогресс-бар будет просвечивать, отображая нижележащие.
>>37259
>ставлю буквку. И сразу всё красным светится
Так это и в GDScript так. Только в редакторе GDScript можно увеличить задержку статического анализатора кода, а в редакторе шейдеров я что-то не нашёл такой опции. В любом случае, просто игнорируй сообщение об ошибке, пока не допечатаешь то, что хочешь. Алсо учись слепому вводу, чтобы печатать быстрее.
>>37326
Все варианты не подходят. Надо свой собственный прогрессбар делать. Надо как-то по хитрому изъебнуться.
Годаны!
Пилите ИТТ свои варианты изъёбистых прогрессбаров. Я начну: Прогрессбар-рулетка. У него полоса и спираль слева от полосы. Пока спираль намотана, она как бы визуально разматывается по мере нанесения урона, и только когда спираль опустела - прогрессбар начинает уменьшаться.
Все варианты не подходят. Надо свой собственный прогрессбар делать. Надо как-то по хитрому изъебнуться.
Годаны!
Пилите ИТТ свои варианты изъёбистых прогрессбаров. Я начну: Прогрессбар-рулетка. У него полоса и спираль слева от полосы. Пока спираль намотана, она как бы визуально разматывается по мере нанесения урона, и только когда спираль опустела - прогрессбар начинает уменьшаться.
>>37111
А мне не нравится, что теперь код будет обмазан "@". Я понимаю, они пытаются отделить теги от ключевых слов и освободить слова для идентификаторов, но кому в своём уме может понадобиться идентификатор "export"? Превращают язык в частокол спецсимволов...
Также мне не нравится, что теперь код методов смешивается с блоком данных. Мало им var в рандомных местах кода - теперь код будет прямо в блоке свойств. Зачем? Чтобы подлизнуть ленивым? ООП придуман чтобы рационально разделить данные и методы, а не смешивать их в одну нечитабельную кучу.
>>37204
Ты не понимаешь? Суть свойства - изображать обычное поле класса так, чтобы пользователи этого класса могли обращаться с ним как с обычным полем. Это называется инкапсуляция, если я ничего не путаю. Если твой код вызывает странные баги, то ты просто неправильно используешь этот инструмент. В идеале, однажды написав класс, ты должен мочь без проблем пользоваться им, ничего не помня об его внутренней реализации. Если ты вынужден лезть внутрь и выяснять, что у тебя является полем, а что свойством - ты создал плохой класс: скорее всего, дал неправильные имена членам класса.
>>37285
Возникновение свойств с сеттерами и геттерами связано с правилами именования членов класса и необходимостью инкапсуляции. Поля класса должны отвечать на вопрос "что хранится", а методы класса должны отвечать на вопрос "что делается", пример:
1. animal - это хранилище животного.
2.1. get_animal - извлечь животное из хранилища.
2.2. pet_animal - ласкать животное в хранилище.
2.3. set_animal - вернуть животное в хранилище.
Конечно, ты можешь сделать так:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Но тебе может потребоваться сделать дополнительную работу перед получением или сохранением данных, например, проверить состояние здоровья животного перед его извлечением и покормить животное перед помещением его обратно в клетку. Тогда тебе потребуется написать так:
if pet_shop.animal.is_healthy(): my_animal = pet_shop.animal
var new_animal := Animal.new()
new_animal.feed(food)
pet_shop.animal = new_animal
Но зачем делать снаружи зоомагазина то, что должен делать сам зоомагазин? Логичнее создать методы зоомагазина и обращаться к ним:
my_animal = zoo.get_animal()
zoo.set_animal(Animal.new())
А уже в самих этих методах делать с животным то, что нужно. Но возникает вопрос, а что, если этот зоомагазин работает уже много лет и пользователи привыкли просто брать животное из клетки и пихать животных прямо в клетки без каких-либо особых процедур? Проще говоря, необходимость вызывать методы get_animal() и set_animal() ломает уже написанный ранее код:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Вот тут и пригождаются свойства. Ты объявляешь внутри класса, что animal - это не поле, а свойство, при обращении к которому вызываются get_animal() или set_animal(), которые работают с секретным _animal и совершают какую-то дополнительную работу, о которой посетителю зоомагазина совершенно не нужно знать (тебе важно только забрать здоровое животное или доставить новое животное, а всё остальное не входит в твою ответственность). Теперь пользователи (старый код) могут работать по-прежнему, а ты можешь добавить любые действия в сеттер и геттер, которые никак не касаются пользователей класса.
Ну вот как-то так я это понимаю.
>>37298
Офигенное объяснение, которое ничего не объясняет. Почему в других языках сделаны свойства? Как люди дошли до того, что "привыкли" к ним?
А мне не нравится, что теперь код будет обмазан "@". Я понимаю, они пытаются отделить теги от ключевых слов и освободить слова для идентификаторов, но кому в своём уме может понадобиться идентификатор "export"? Превращают язык в частокол спецсимволов...
Также мне не нравится, что теперь код методов смешивается с блоком данных. Мало им var в рандомных местах кода - теперь код будет прямо в блоке свойств. Зачем? Чтобы подлизнуть ленивым? ООП придуман чтобы рационально разделить данные и методы, а не смешивать их в одну нечитабельную кучу.
>>37204
>Вот забудешь ты про какой-то геттер/сеттер, начнёшь обращаться с типом так, как будто он без них, в итоге полезут странные баги.
Ты не понимаешь? Суть свойства - изображать обычное поле класса так, чтобы пользователи этого класса могли обращаться с ним как с обычным полем. Это называется инкапсуляция, если я ничего не путаю. Если твой код вызывает странные баги, то ты просто неправильно используешь этот инструмент. В идеале, однажды написав класс, ты должен мочь без проблем пользоваться им, ничего не помня об его внутренней реализации. Если ты вынужден лезть внутрь и выяснять, что у тебя является полем, а что свойством - ты создал плохой класс: скорее всего, дал неправильные имена членам класса.
>>37285
>зачем
Возникновение свойств с сеттерами и геттерами связано с правилами именования членов класса и необходимостью инкапсуляции. Поля класса должны отвечать на вопрос "что хранится", а методы класса должны отвечать на вопрос "что делается", пример:
1. animal - это хранилище животного.
2.1. get_animal - извлечь животное из хранилища.
2.2. pet_animal - ласкать животное в хранилище.
2.3. set_animal - вернуть животное в хранилище.
Конечно, ты можешь сделать так:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Но тебе может потребоваться сделать дополнительную работу перед получением или сохранением данных, например, проверить состояние здоровья животного перед его извлечением и покормить животное перед помещением его обратно в клетку. Тогда тебе потребуется написать так:
if pet_shop.animal.is_healthy(): my_animal = pet_shop.animal
var new_animal := Animal.new()
new_animal.feed(food)
pet_shop.animal = new_animal
Но зачем делать снаружи зоомагазина то, что должен делать сам зоомагазин? Логичнее создать методы зоомагазина и обращаться к ним:
my_animal = zoo.get_animal()
zoo.set_animal(Animal.new())
А уже в самих этих методах делать с животным то, что нужно. Но возникает вопрос, а что, если этот зоомагазин работает уже много лет и пользователи привыкли просто брать животное из клетки и пихать животных прямо в клетки без каких-либо особых процедур? Проще говоря, необходимость вызывать методы get_animal() и set_animal() ломает уже написанный ранее код:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Вот тут и пригождаются свойства. Ты объявляешь внутри класса, что animal - это не поле, а свойство, при обращении к которому вызываются get_animal() или set_animal(), которые работают с секретным _animal и совершают какую-то дополнительную работу, о которой посетителю зоомагазина совершенно не нужно знать (тебе важно только забрать здоровое животное или доставить новое животное, а всё остальное не входит в твою ответственность). Теперь пользователи (старый код) могут работать по-прежнему, а ты можешь добавить любые действия в сеттер и геттер, которые никак не касаются пользователей класса.
Ну вот как-то так я это понимаю.
>>37298
>для тех, кто привык к ним в других языках, они сделаны и здесь
Офигенное объяснение, которое ничего не объясняет. Почему в других языках сделаны свойства? Как люди дошли до того, что "привыкли" к ним?
>>37111
А мне не нравится, что теперь код будет обмазан "@". Я понимаю, они пытаются отделить теги от ключевых слов и освободить слова для идентификаторов, но кому в своём уме может понадобиться идентификатор "export"? Превращают язык в частокол спецсимволов...
Также мне не нравится, что теперь код методов смешивается с блоком данных. Мало им var в рандомных местах кода - теперь код будет прямо в блоке свойств. Зачем? Чтобы подлизнуть ленивым? ООП придуман чтобы рационально разделить данные и методы, а не смешивать их в одну нечитабельную кучу.
>>37204
Ты не понимаешь? Суть свойства - изображать обычное поле класса так, чтобы пользователи этого класса могли обращаться с ним как с обычным полем. Это называется инкапсуляция, если я ничего не путаю. Если твой код вызывает странные баги, то ты просто неправильно используешь этот инструмент. В идеале, однажды написав класс, ты должен мочь без проблем пользоваться им, ничего не помня об его внутренней реализации. Если ты вынужден лезть внутрь и выяснять, что у тебя является полем, а что свойством - ты создал плохой класс: скорее всего, дал неправильные имена членам класса.
>>37285
Возникновение свойств с сеттерами и геттерами связано с правилами именования членов класса и необходимостью инкапсуляции. Поля класса должны отвечать на вопрос "что хранится", а методы класса должны отвечать на вопрос "что делается", пример:
1. animal - это хранилище животного.
2.1. get_animal - извлечь животное из хранилища.
2.2. pet_animal - ласкать животное в хранилище.
2.3. set_animal - вернуть животное в хранилище.
Конечно, ты можешь сделать так:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Но тебе может потребоваться сделать дополнительную работу перед получением или сохранением данных, например, проверить состояние здоровья животного перед его извлечением и покормить животное перед помещением его обратно в клетку. Тогда тебе потребуется написать так:
if pet_shop.animal.is_healthy(): my_animal = pet_shop.animal
var new_animal := Animal.new()
new_animal.feed(food)
pet_shop.animal = new_animal
Но зачем делать снаружи зоомагазина то, что должен делать сам зоомагазин? Логичнее создать методы зоомагазина и обращаться к ним:
my_animal = zoo.get_animal()
zoo.set_animal(Animal.new())
А уже в самих этих методах делать с животным то, что нужно. Но возникает вопрос, а что, если этот зоомагазин работает уже много лет и пользователи привыкли просто брать животное из клетки и пихать животных прямо в клетки без каких-либо особых процедур? Проще говоря, необходимость вызывать методы get_animal() и set_animal() ломает уже написанный ранее код:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Вот тут и пригождаются свойства. Ты объявляешь внутри класса, что animal - это не поле, а свойство, при обращении к которому вызываются get_animal() или set_animal(), которые работают с секретным _animal и совершают какую-то дополнительную работу, о которой посетителю зоомагазина совершенно не нужно знать (тебе важно только забрать здоровое животное или доставить новое животное, а всё остальное не входит в твою ответственность). Теперь пользователи (старый код) могут работать по-прежнему, а ты можешь добавить любые действия в сеттер и геттер, которые никак не касаются пользователей класса.
Ну вот как-то так я это понимаю.
>>37298
Офигенное объяснение, которое ничего не объясняет. Почему в других языках сделаны свойства? Как люди дошли до того, что "привыкли" к ним?
А мне не нравится, что теперь код будет обмазан "@". Я понимаю, они пытаются отделить теги от ключевых слов и освободить слова для идентификаторов, но кому в своём уме может понадобиться идентификатор "export"? Превращают язык в частокол спецсимволов...
Также мне не нравится, что теперь код методов смешивается с блоком данных. Мало им var в рандомных местах кода - теперь код будет прямо в блоке свойств. Зачем? Чтобы подлизнуть ленивым? ООП придуман чтобы рационально разделить данные и методы, а не смешивать их в одну нечитабельную кучу.
>>37204
>Вот забудешь ты про какой-то геттер/сеттер, начнёшь обращаться с типом так, как будто он без них, в итоге полезут странные баги.
Ты не понимаешь? Суть свойства - изображать обычное поле класса так, чтобы пользователи этого класса могли обращаться с ним как с обычным полем. Это называется инкапсуляция, если я ничего не путаю. Если твой код вызывает странные баги, то ты просто неправильно используешь этот инструмент. В идеале, однажды написав класс, ты должен мочь без проблем пользоваться им, ничего не помня об его внутренней реализации. Если ты вынужден лезть внутрь и выяснять, что у тебя является полем, а что свойством - ты создал плохой класс: скорее всего, дал неправильные имена членам класса.
>>37285
>зачем
Возникновение свойств с сеттерами и геттерами связано с правилами именования членов класса и необходимостью инкапсуляции. Поля класса должны отвечать на вопрос "что хранится", а методы класса должны отвечать на вопрос "что делается", пример:
1. animal - это хранилище животного.
2.1. get_animal - извлечь животное из хранилища.
2.2. pet_animal - ласкать животное в хранилище.
2.3. set_animal - вернуть животное в хранилище.
Конечно, ты можешь сделать так:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Но тебе может потребоваться сделать дополнительную работу перед получением или сохранением данных, например, проверить состояние здоровья животного перед его извлечением и покормить животное перед помещением его обратно в клетку. Тогда тебе потребуется написать так:
if pet_shop.animal.is_healthy(): my_animal = pet_shop.animal
var new_animal := Animal.new()
new_animal.feed(food)
pet_shop.animal = new_animal
Но зачем делать снаружи зоомагазина то, что должен делать сам зоомагазин? Логичнее создать методы зоомагазина и обращаться к ним:
my_animal = zoo.get_animal()
zoo.set_animal(Animal.new())
А уже в самих этих методах делать с животным то, что нужно. Но возникает вопрос, а что, если этот зоомагазин работает уже много лет и пользователи привыкли просто брать животное из клетки и пихать животных прямо в клетки без каких-либо особых процедур? Проще говоря, необходимость вызывать методы get_animal() и set_animal() ломает уже написанный ранее код:
my_animal = pet_shop.animal
pet_shop.animal = Animal.new()
Вот тут и пригождаются свойства. Ты объявляешь внутри класса, что animal - это не поле, а свойство, при обращении к которому вызываются get_animal() или set_animal(), которые работают с секретным _animal и совершают какую-то дополнительную работу, о которой посетителю зоомагазина совершенно не нужно знать (тебе важно только забрать здоровое животное или доставить новое животное, а всё остальное не входит в твою ответственность). Теперь пользователи (старый код) могут работать по-прежнему, а ты можешь добавить любые действия в сеттер и геттер, которые никак не касаются пользователей класса.
Ну вот как-то так я это понимаю.
>>37298
>для тех, кто привык к ним в других языках, они сделаны и здесь
Офигенное объяснение, которое ничего не объясняет. Почему в других языках сделаны свойства? Как люди дошли до того, что "привыкли" к ним?
1,2 Мб, 500x319>>37337
1987, Last Ninja
>Пока спираль намотана, она как бы визуально разматывается по мере нанесения урона
1987, Last Ninja
>>37338
Спасибо, я старался!
Ты уже описал. Мы все ждали тебя.
Двачую! Лижут-сосут майкрософту. ГДскрипт фактически превращается в шарп. Объявление сет-гет прямо на месте лямбдами - это же из шарпа.
>>37339
Спасибо! Я уже давно перестал страдать от того, что не могу придумать ничего нового, что уже даже наслаждаюсь тем, что перепридумал что-то из восьмидесятых.
> Офигенное объяснение, которое ничего не объясняет.
Спасибо, я старался!
> Почему в других языках сделаны свойства? Как люди дошли до того, что "привыкли" к ним?
Ты уже описал. Мы все ждали тебя.
> Превращают язык в частокол спецсимволов...
Двачую! Лижут-сосут майкрософту. ГДскрипт фактически превращается в шарп. Объявление сет-гет прямо на месте лямбдами - это же из шарпа.
>>37339
Спасибо! Я уже давно перестал страдать от того, что не могу придумать ничего нового, что уже даже наслаждаюсь тем, что перепридумал что-то из восьмидесятых.
>>37384
Я и сам тоже. Удивляюсь как много уже придумали в первые годы видеоигр, что до сих пор можно что-то переоткрывать (и продавать миллеиналам как новое)
>Я уже давно перестал страдать от того, что не могу придумать ничего нового, что уже даже наслаждаюсь тем, что перепридумал что-то из восьмидесятых.
Я и сам тоже. Удивляюсь как много уже придумали в первые годы видеоигр, что до сих пор можно что-то переоткрывать (и продавать миллеиналам как новое)
>>37338
Я в своё время обмазывался гет-сетами, казалось круто. Но на деле может возникнуть потребность в отделении чистого изъятия животного от изъятия животного с дополнительным действием. Да и в целом, когда свой код конкретно так подзабудешь, становится очень неуютно от смутного знания, что когда ты просто чекаешь какие-то поля, под капотом происходит что-то дополнительное.
Поэтому в своём проекте я от гета и сета отказался почти везде. Оставил только автоматическую отправку с сервера характеристик героя игроку при их изменении.
> Но возникает вопрос, а что, если этот зоомагазин работает уже много лет и пользователи привыкли просто брать животное из клетки и пихать животных прямо в клетки без каких-либо особых процедур?
Я в своё время обмазывался гет-сетами, казалось круто. Но на деле может возникнуть потребность в отделении чистого изъятия животного от изъятия животного с дополнительным действием. Да и в целом, когда свой код конкретно так подзабудешь, становится очень неуютно от смутного знания, что когда ты просто чекаешь какие-то поля, под капотом происходит что-то дополнительное.
Поэтому в своём проекте я от гета и сета отказался почти везде. Оставил только автоматическую отправку с сервера характеристик героя игроку при их изменении.
>>37337
Делаешь несколько сцен с прогрессбарами разных цветов. Потом при прогрессбар1 = 0 лоадишь другой просто и все.
Делаешь несколько сцен с прогрессбарами разных цветов. Потом при прогрессбар1 = 0 лоадишь другой просто и все.
>>37450
В таком случае нужны дополнительные методы:
my_animal = pet_shop.animal # приобрести здоровое животное, если оно всё ещё имеется - способ извлечения животного по умолчанию
stolen_animal = pet_shop.steal_animal() # своровать в любом состоянии, даже если это труп - способ извлечения для особых извращённых ситуаций
Суть в том, что ты не должен иметь прямого доступа к полю _animal, потому что его реализация должна быть скрыта от пользователей, это один из принципов ООП. У pet_shop может вообще не быть никакого _animal: новые животные выдаются пользователям после мгновенной сборки из атомов, а полученные от доставщика животные немедленно утилизируются в мясорубке. Пользователь не должен разбираться в таких деталях, иначе он слишком много знает об устройстве pet_shop. И если ты слишком много знаешь об его устройстве, ты соблазняешься залезть в него грязными руками и что-нибудь подкрутить, внести какую-то лишнюю зависимость. В нормальных ООП языках все поля класса должны быть приватными по умолчанию, то есть быть недоступны извне - это просто GDScript слишком мягкий, делая публичным вообще всё.
Это твоя психологическая проблема. Ты же не изучаешь в подробностях код каждой библиотеки, интерпретатора и компилятора, которые используешь? А в них на каждую единицу твоего кода что-то выполняется. Вот выше упоминали JS - один и тот же JS код может выполняться по-разному в разных браузерах, ты хочешь все браузеры расковырять и изучить, прежде чем писать свой код?
Вот так и с твоим собственным кодом. Ты должен писать код так, чтобы мог его использовать даже полностью забыв его содержимое. В этом суть ООП - тебе не обязательно знать реализацию и копаться в ней.
По-моему, GDScript вносит путаницу. Сеттеры и геттеры образуют свойство класса, а записывают данные они в поле класса, если оно вообще есть. В GDScript поле и свойство объединены в одну сущность, и я считаю, что это плохое решение, хотя и удобное для новичков. В других языках приватное поле и доступ к нему через свойство - отдельные сущности, и ты реально не должен "просто чекать какие-то поля", потому что к приватным полям доступ извне класса запрещён. Жаль, что GDScript не позволяет так делать, у него даже приватных полей нет.
Это твоё дело. Я их вообще почти не использую, потому что они реально не нужны до тех пор, пока не потребуются. Если мне нужно получить что-то, обращаюсь к полю, а если потом потребуется сделать обработчик обращения к полю - повешу на него сеттер/геттер (в других ЯП объявил бы одноимённое свойство, переименовав поле и перенеся его в приватную область класса).
>Но на деле может возникнуть потребность в отделении чистого изъятия животного от изъятия животного с дополнительным действием.
В таком случае нужны дополнительные методы:
my_animal = pet_shop.animal # приобрести здоровое животное, если оно всё ещё имеется - способ извлечения животного по умолчанию
stolen_animal = pet_shop.steal_animal() # своровать в любом состоянии, даже если это труп - способ извлечения для особых извращённых ситуаций
Суть в том, что ты не должен иметь прямого доступа к полю _animal, потому что его реализация должна быть скрыта от пользователей, это один из принципов ООП. У pet_shop может вообще не быть никакого _animal: новые животные выдаются пользователям после мгновенной сборки из атомов, а полученные от доставщика животные немедленно утилизируются в мясорубке. Пользователь не должен разбираться в таких деталях, иначе он слишком много знает об устройстве pet_shop. И если ты слишком много знаешь об его устройстве, ты соблазняешься залезть в него грязными руками и что-нибудь подкрутить, внести какую-то лишнюю зависимость. В нормальных ООП языках все поля класса должны быть приватными по умолчанию, то есть быть недоступны извне - это просто GDScript слишком мягкий, делая публичным вообще всё.
>Да и в целом, когда свой код конкретно так подзабудешь, становится очень неуютно от смутного знания, что когда ты просто чекаешь какие-то поля, под капотом происходит что-то дополнительное.
Это твоя психологическая проблема. Ты же не изучаешь в подробностях код каждой библиотеки, интерпретатора и компилятора, которые используешь? А в них на каждую единицу твоего кода что-то выполняется. Вот выше упоминали JS - один и тот же JS код может выполняться по-разному в разных браузерах, ты хочешь все браузеры расковырять и изучить, прежде чем писать свой код?
Вот так и с твоим собственным кодом. Ты должен писать код так, чтобы мог его использовать даже полностью забыв его содержимое. В этом суть ООП - тебе не обязательно знать реализацию и копаться в ней.
>просто чекаешь какие-то поля
По-моему, GDScript вносит путаницу. Сеттеры и геттеры образуют свойство класса, а записывают данные они в поле класса, если оно вообще есть. В GDScript поле и свойство объединены в одну сущность, и я считаю, что это плохое решение, хотя и удобное для новичков. В других языках приватное поле и доступ к нему через свойство - отдельные сущности, и ты реально не должен "просто чекать какие-то поля", потому что к приватным полям доступ извне класса запрещён. Жаль, что GDScript не позволяет так делать, у него даже приватных полей нет.
>Поэтому в своём проекте я от гета и сета отказался почти везде.
Это твоё дело. Я их вообще почти не использую, потому что они реально не нужны до тех пор, пока не потребуются. Если мне нужно получить что-то, обращаюсь к полю, а если потом потребуется сделать обработчик обращения к полю - повешу на него сеттер/геттер (в других ЯП объявил бы одноимённое свойство, переименовав поле и перенеся его в приватную область класса).
>>37450
В таком случае нужны дополнительные методы:
my_animal = pet_shop.animal # приобрести здоровое животное, если оно всё ещё имеется - способ извлечения животного по умолчанию
stolen_animal = pet_shop.steal_animal() # своровать в любом состоянии, даже если это труп - способ извлечения для особых извращённых ситуаций
Суть в том, что ты не должен иметь прямого доступа к полю _animal, потому что его реализация должна быть скрыта от пользователей, это один из принципов ООП. У pet_shop может вообще не быть никакого _animal: новые животные выдаются пользователям после мгновенной сборки из атомов, а полученные от доставщика животные немедленно утилизируются в мясорубке. Пользователь не должен разбираться в таких деталях, иначе он слишком много знает об устройстве pet_shop. И если ты слишком много знаешь об его устройстве, ты соблазняешься залезть в него грязными руками и что-нибудь подкрутить, внести какую-то лишнюю зависимость. В нормальных ООП языках все поля класса должны быть приватными по умолчанию, то есть быть недоступны извне - это просто GDScript слишком мягкий, делая публичным вообще всё.
Это твоя психологическая проблема. Ты же не изучаешь в подробностях код каждой библиотеки, интерпретатора и компилятора, которые используешь? А в них на каждую единицу твоего кода что-то выполняется. Вот выше упоминали JS - один и тот же JS код может выполняться по-разному в разных браузерах, ты хочешь все браузеры расковырять и изучить, прежде чем писать свой код?
Вот так и с твоим собственным кодом. Ты должен писать код так, чтобы мог его использовать даже полностью забыв его содержимое. В этом суть ООП - тебе не обязательно знать реализацию и копаться в ней.
По-моему, GDScript вносит путаницу. Сеттеры и геттеры образуют свойство класса, а записывают данные они в поле класса, если оно вообще есть. В GDScript поле и свойство объединены в одну сущность, и я считаю, что это плохое решение, хотя и удобное для новичков. В других языках приватное поле и доступ к нему через свойство - отдельные сущности, и ты реально не должен "просто чекать какие-то поля", потому что к приватным полям доступ извне класса запрещён. Жаль, что GDScript не позволяет так делать, у него даже приватных полей нет.
Это твоё дело. Я их вообще почти не использую, потому что они реально не нужны до тех пор, пока не потребуются. Если мне нужно получить что-то, обращаюсь к полю, а если потом потребуется сделать обработчик обращения к полю - повешу на него сеттер/геттер (в других ЯП объявил бы одноимённое свойство, переименовав поле и перенеся его в приватную область класса).
>Но на деле может возникнуть потребность в отделении чистого изъятия животного от изъятия животного с дополнительным действием.
В таком случае нужны дополнительные методы:
my_animal = pet_shop.animal # приобрести здоровое животное, если оно всё ещё имеется - способ извлечения животного по умолчанию
stolen_animal = pet_shop.steal_animal() # своровать в любом состоянии, даже если это труп - способ извлечения для особых извращённых ситуаций
Суть в том, что ты не должен иметь прямого доступа к полю _animal, потому что его реализация должна быть скрыта от пользователей, это один из принципов ООП. У pet_shop может вообще не быть никакого _animal: новые животные выдаются пользователям после мгновенной сборки из атомов, а полученные от доставщика животные немедленно утилизируются в мясорубке. Пользователь не должен разбираться в таких деталях, иначе он слишком много знает об устройстве pet_shop. И если ты слишком много знаешь об его устройстве, ты соблазняешься залезть в него грязными руками и что-нибудь подкрутить, внести какую-то лишнюю зависимость. В нормальных ООП языках все поля класса должны быть приватными по умолчанию, то есть быть недоступны извне - это просто GDScript слишком мягкий, делая публичным вообще всё.
>Да и в целом, когда свой код конкретно так подзабудешь, становится очень неуютно от смутного знания, что когда ты просто чекаешь какие-то поля, под капотом происходит что-то дополнительное.
Это твоя психологическая проблема. Ты же не изучаешь в подробностях код каждой библиотеки, интерпретатора и компилятора, которые используешь? А в них на каждую единицу твоего кода что-то выполняется. Вот выше упоминали JS - один и тот же JS код может выполняться по-разному в разных браузерах, ты хочешь все браузеры расковырять и изучить, прежде чем писать свой код?
Вот так и с твоим собственным кодом. Ты должен писать код так, чтобы мог его использовать даже полностью забыв его содержимое. В этом суть ООП - тебе не обязательно знать реализацию и копаться в ней.
>просто чекаешь какие-то поля
По-моему, GDScript вносит путаницу. Сеттеры и геттеры образуют свойство класса, а записывают данные они в поле класса, если оно вообще есть. В GDScript поле и свойство объединены в одну сущность, и я считаю, что это плохое решение, хотя и удобное для новичков. В других языках приватное поле и доступ к нему через свойство - отдельные сущности, и ты реально не должен "просто чекать какие-то поля", потому что к приватным полям доступ извне класса запрещён. Жаль, что GDScript не позволяет так делать, у него даже приватных полей нет.
>Поэтому в своём проекте я от гета и сета отказался почти везде.
Это твоё дело. Я их вообще почти не использую, потому что они реально не нужны до тех пор, пока не потребуются. Если мне нужно получить что-то, обращаюсь к полю, а если потом потребуется сделать обработчик обращения к полю - повешу на него сеттер/геттер (в других ЯП объявил бы одноимённое свойство, переименовав поле и перенеся его в приватную область класса).
3 Кб, 175x60>>37338
Дело не только в этом. Теперь это аннотация, как в других языках, и может писаться выше строкой. (Да, это работает).
Ну это очень большая натяжка, тогда и любая инициализация типа var center = width / 2 это смешивание кода и данных ))
> код будет обмазан "@". Я понимаю, они пытаются отделить теги от ключевых слов и освободить слова для идентификаторов
Дело не только в этом. Теперь это аннотация, как в других языках, и может писаться выше строкой. (Да, это работает).
>разделить данные и методы, а не смешивать их в одну нечитабельную кучу.
Ну это очень большая натяжка, тогда и любая инициализация типа var center = width / 2 это смешивание кода и данных ))
8,2 Мб, mp4,1920x1080, 0:15
>>37285
Самый распространенный кейс который пригождается ежедневно при разработке игр
Есть юнит с настройками
Настройки export-ом пробрасываются в окно свойств в редакторе
Изменение, как писал анон выше, сначала проходит валидацию, или проще, приводится к диапазону разрешенных значений/дефолтному
Во-вторых, tool-скрипт применяет настройки и результат сразу отображается в сцене.
Самый распространенный кейс который пригождается ежедневно при разработке игр
Есть юнит с настройками
Настройки export-ом пробрасываются в окно свойств в редакторе
Изменение, как писал анон выше, сначала проходит валидацию, или проще, приводится к диапазону разрешенных значений/дефолтному
Во-вторых, tool-скрипт применяет настройки и результат сразу отображается в сцене.
>>828397 →
как прогресс?
как прогресс?
>>37505
Ок, здесь удобно действительно.
Ок, здесь удобно действительно.
>>37608
Не рисуй мышкой, тебя кто-то заставляет? Рисуй пером на планшете, или рисуй на бумаге и скань. Это если говорить про традиционный арт.
Если говорить про пиксельарт, то да, мышкой пиксели расставляются, например в Aseprite (есть платный или можно бесплатно собирать из исходников)
>>36690
Вообще это вопрос не совсем по теме, а к художникам. И напрашивается ответ - рисуй цветастыми красками, и будет красочно.
Есть много разных стилей. От плоских до вычурных.
Я бы сказал, что есть рамка, она имитирует реальный материал - раму картины, или лист бумаги, или стеклянные трубочки;
с какой-то определенной стороны падает свет, что создает подсветы, блики, затенения, что дает выпуклость или наоборот вогнутость;
есть "придание живости" - украшения на углах; сколы, порезы, порванности на гранях; опять же блики.
Есть определенные приемы, которые призваны давать "фидбек" игроку, такие как разворачивание/свертывание менюшек и рамок, деформация пунктов которые выбрали/потеряли фокус, анимация и мерцание текушего выделенного пункта, отклик на выполнение действия.
Контрастность активных пунктов против ненасыщенного фона.
Изучай, как рисуют другие, изучай как сделано в играх, которые тебе нравятся.
На втором пике коллаж примеров под лицензией CC0
https://itch.io/game-assets/tag-gui/tag-pixel-art
Если говорить про техническую сторону именно годота, то в нем много инструментов, помогающих делать гуй.
Есть 9-patch rect. Контейнеры. Поддержка тем, скинов (нажатые/отжатые кнопки, вот это все)
Сейчас некогда все расписывать, думаю можешь сам поискать туториалы. Вроде у GDQuest неплохие:
https://www.youtube.com/watch?v=sKuM5AzK-uA
https://www.youtube.com/watch?v=pVK_QzQPv4o
https://www.youtube.com/watch?v=YL8apqN6IJM
Есть официальные туториалы
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
https://docs.godotengine.org/en/3.3/getting_started/step_by_step/ui_introduction_to_the_ui_system.html
(хз этот почему то убрали из последних версий, может что-то устарело)
Также не надо забывать про шейдеры, это подходящий инструмент для всяких эффектов переходов между сценами, анимации тех же элементов гуи - прогресс баров, кнопок, для эффектов растворения/сгорания/исчезания и прочее.
банальностей псто
Не рисуй мышкой, тебя кто-то заставляет? Рисуй пером на планшете, или рисуй на бумаге и скань. Это если говорить про традиционный арт.
Если говорить про пиксельарт, то да, мышкой пиксели расставляются, например в Aseprite (есть платный или можно бесплатно собирать из исходников)
>>36690
Вообще это вопрос не совсем по теме, а к художникам. И напрашивается ответ - рисуй цветастыми красками, и будет красочно.
Есть много разных стилей. От плоских до вычурных.
Я бы сказал, что есть рамка, она имитирует реальный материал - раму картины, или лист бумаги, или стеклянные трубочки;
с какой-то определенной стороны падает свет, что создает подсветы, блики, затенения, что дает выпуклость или наоборот вогнутость;
есть "придание живости" - украшения на углах; сколы, порезы, порванности на гранях; опять же блики.
Есть определенные приемы, которые призваны давать "фидбек" игроку, такие как разворачивание/свертывание менюшек и рамок, деформация пунктов которые выбрали/потеряли фокус, анимация и мерцание текушего выделенного пункта, отклик на выполнение действия.
Контрастность активных пунктов против ненасыщенного фона.
Изучай, как рисуют другие, изучай как сделано в играх, которые тебе нравятся.
На втором пике коллаж примеров под лицензией CC0
https://itch.io/game-assets/tag-gui/tag-pixel-art
Если говорить про техническую сторону именно годота, то в нем много инструментов, помогающих делать гуй.
Есть 9-patch rect. Контейнеры. Поддержка тем, скинов (нажатые/отжатые кнопки, вот это все)
Сейчас некогда все расписывать, думаю можешь сам поискать туториалы. Вроде у GDQuest неплохие:
https://www.youtube.com/watch?v=sKuM5AzK-uA
https://www.youtube.com/watch?v=pVK_QzQPv4o
https://www.youtube.com/watch?v=YL8apqN6IJM
Есть официальные туториалы
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
https://docs.godotengine.org/en/3.3/getting_started/step_by_step/ui_introduction_to_the_ui_system.html
(хз этот почему то убрали из последних версий, может что-то устарело)
Также не надо забывать про шейдеры, это подходящий инструмент для всяких эффектов переходов между сценами, анимации тех же элементов гуи - прогресс баров, кнопок, для эффектов растворения/сгорания/исчезания и прочее.
банальностей псто
>>37608
Не рисуй мышкой, тебя кто-то заставляет? Рисуй пером на планшете, или рисуй на бумаге и скань. Это если говорить про традиционный арт.
Если говорить про пиксельарт, то да, мышкой пиксели расставляются, например в Aseprite (есть платный или можно бесплатно собирать из исходников)
>>36690
Вообще это вопрос не совсем по теме, а к художникам. И напрашивается ответ - рисуй цветастыми красками, и будет красочно.
Есть много разных стилей. От плоских до вычурных.
Я бы сказал, что есть рамка, она имитирует реальный материал - раму картины, или лист бумаги, или стеклянные трубочки;
с какой-то определенной стороны падает свет, что создает подсветы, блики, затенения, что дает выпуклость или наоборот вогнутость;
есть "придание живости" - украшения на углах; сколы, порезы, порванности на гранях; опять же блики.
Есть определенные приемы, которые призваны давать "фидбек" игроку, такие как разворачивание/свертывание менюшек и рамок, деформация пунктов которые выбрали/потеряли фокус, анимация и мерцание текушего выделенного пункта, отклик на выполнение действия.
Контрастность активных пунктов против ненасыщенного фона.
Изучай, как рисуют другие, изучай как сделано в играх, которые тебе нравятся.
На втором пике коллаж примеров под лицензией CC0
https://itch.io/game-assets/tag-gui/tag-pixel-art
Если говорить про техническую сторону именно годота, то в нем много инструментов, помогающих делать гуй.
Есть 9-patch rect. Контейнеры. Поддержка тем, скинов (нажатые/отжатые кнопки, вот это все)
Сейчас некогда все расписывать, думаю можешь сам поискать туториалы. Вроде у GDQuest неплохие:
https://www.youtube.com/watch?v=sKuM5AzK-uA
https://www.youtube.com/watch?v=pVK_QzQPv4o
https://www.youtube.com/watch?v=YL8apqN6IJM
Есть официальные туториалы
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
https://docs.godotengine.org/en/3.3/getting_started/step_by_step/ui_introduction_to_the_ui_system.html
(хз этот почему то убрали из последних версий, может что-то устарело)
Также не надо забывать про шейдеры, это подходящий инструмент для всяких эффектов переходов между сценами, анимации тех же элементов гуи - прогресс баров, кнопок, для эффектов растворения/сгорания/исчезания и прочее.
банальностей псто
Не рисуй мышкой, тебя кто-то заставляет? Рисуй пером на планшете, или рисуй на бумаге и скань. Это если говорить про традиционный арт.
Если говорить про пиксельарт, то да, мышкой пиксели расставляются, например в Aseprite (есть платный или можно бесплатно собирать из исходников)
>>36690
Вообще это вопрос не совсем по теме, а к художникам. И напрашивается ответ - рисуй цветастыми красками, и будет красочно.
Есть много разных стилей. От плоских до вычурных.
Я бы сказал, что есть рамка, она имитирует реальный материал - раму картины, или лист бумаги, или стеклянные трубочки;
с какой-то определенной стороны падает свет, что создает подсветы, блики, затенения, что дает выпуклость или наоборот вогнутость;
есть "придание живости" - украшения на углах; сколы, порезы, порванности на гранях; опять же блики.
Есть определенные приемы, которые призваны давать "фидбек" игроку, такие как разворачивание/свертывание менюшек и рамок, деформация пунктов которые выбрали/потеряли фокус, анимация и мерцание текушего выделенного пункта, отклик на выполнение действия.
Контрастность активных пунктов против ненасыщенного фона.
Изучай, как рисуют другие, изучай как сделано в играх, которые тебе нравятся.
На втором пике коллаж примеров под лицензией CC0
https://itch.io/game-assets/tag-gui/tag-pixel-art
Если говорить про техническую сторону именно годота, то в нем много инструментов, помогающих делать гуй.
Есть 9-patch rect. Контейнеры. Поддержка тем, скинов (нажатые/отжатые кнопки, вот это все)
Сейчас некогда все расписывать, думаю можешь сам поискать туториалы. Вроде у GDQuest неплохие:
https://www.youtube.com/watch?v=sKuM5AzK-uA
https://www.youtube.com/watch?v=pVK_QzQPv4o
https://www.youtube.com/watch?v=YL8apqN6IJM
Есть официальные туториалы
https://docs.godotengine.org/en/stable/tutorials/ui/index.html
https://docs.godotengine.org/en/3.3/getting_started/step_by_step/ui_introduction_to_the_ui_system.html
(хз этот почему то убрали из последних версий, может что-то устарело)
Также не надо забывать про шейдеры, это подходящий инструмент для всяких эффектов переходов между сценами, анимации тех же элементов гуи - прогресс баров, кнопок, для эффектов растворения/сгорания/исчезания и прочее.
банальностей псто
49 Кб, 548x370Интересно в годоте сделано. Вроде скрипт - атрибут объекта. Но с другой стороны объект можно кастануть к типу нового скрипта.
>>37499
А в чём принципиальная разница?
1. Почему нельзя сделать это с ключевым словом?
2. В чём практическая польза? Мне лично очень не понравилось, что в Unity ты вынужден писать экспорт на строке выше, иначе получается нечитабельная каша. Хотя каша всё равно получается, но в два раза более длинная по высоте, и это вдвойне раздражает. Вижу смысл только в том, чтобы разбить на две строки длинный экспорт, но это вроде и раньше можно было делать через "\".
Здесь ты используешь константы, действия тривиальны и выполняются строго на этапе инициализации. В геттере/сеттере может быть много кода на много строк, который вызывается неизвестно когда и может делать сложные вещи. Ты просто разрываешь список свойств длинной портянкой геттеров и сеттеров.
Я не понял, можно ли будет писать в старом стиле, через отдельные методы? Или только через костыль вроде "get: return get_property()”? Если старый стиль полностью выкинули, печаль-беда...
>Теперь это аннотация, как в других языках
А в чём принципиальная разница?
>и может писаться выше строкой.
1. Почему нельзя сделать это с ключевым словом?
2. В чём практическая польза? Мне лично очень не понравилось, что в Unity ты вынужден писать экспорт на строке выше, иначе получается нечитабельная каша. Хотя каша всё равно получается, но в два раза более длинная по высоте, и это вдвойне раздражает. Вижу смысл только в том, чтобы разбить на две строки длинный экспорт, но это вроде и раньше можно было делать через "\".
>любая инициализация типа var center = width / 2 это смешивание кода и данных
Здесь ты используешь константы, действия тривиальны и выполняются строго на этапе инициализации. В геттере/сеттере может быть много кода на много строк, который вызывается неизвестно когда и может делать сложные вещи. Ты просто разрываешь список свойств длинной портянкой геттеров и сеттеров.
Я не понял, можно ли будет писать в старом стиле, через отдельные методы? Или только через костыль вроде "get: return get_property()”? Если старый стиль полностью выкинули, печаль-беда...
>>37670
Ты путаешь "скрипт" и "объект". Скрипт - это текст в .gd, который можно считать из файла и выполнить, а объект - это экземпляр одного из классов, которые ты описываешь в своих скриптах или которые доступны тебе из набора стандартных в движке. MyTimer в твоём коде - класс, экземпляр которого создаётся во время set_script() и возвращается во время my_timer := timer as MyTimer. Т.е. ты не со скриптом работаешь, а с объектом - экземпляром описанного тобой класса.
>объект можно кастануть к типу нового скрипта
Ты путаешь "скрипт" и "объект". Скрипт - это текст в .gd, который можно считать из файла и выполнить, а объект - это экземпляр одного из классов, которые ты описываешь в своих скриптах или которые доступны тебе из набора стандартных в движке. MyTimer в твоём коде - класс, экземпляр которого создаётся во время set_script() и возвращается во время my_timer := timer as MyTimer. Т.е. ты не со скриптом работаешь, а с объектом - экземпляром описанного тобой класса.
>>37713
На самом деле все проще и есть в документации.
Object.set_script extends an existing object, if that object's class matches one of the script's base classes.
Без такой логики этот пример бы не работал, ты сам скопипастил timer as MyTimer, Но у timer тип был (системный) Timer.
На самом деле все проще и есть в документации.
Object.set_script extends an existing object, if that object's class matches one of the script's base classes.
Без такой логики этот пример бы не работал, ты сам скопипастил timer as MyTimer, Но у timer тип был (системный) Timer.
>>37608
Есть способы:
1. Если вектор, то всё очень просто - Inkscape адаптирован под мышь и ты можешь нарисовать что угодно одной только мышью без проблем. Учитывай ограничения вектора: некоторые вещи проще сделать в растре.
2. Если растр:
2.1. Пиксель-арт подразумевает изменение отдельных пикселей в очень крупном приближении, так что мышкой это делается даже проще, чем пером. Krita имеет базовые инструменты для пиксель-арта.
2.2. Обычный цифровой арт тоже возможно рисовать мышкой. Для этого поможет создать очень большой холст и включить сильное сглаживание движений, тогда плавные линии будет легче делать, а косяки после сжатия картинки станут менее заметны. Но, конечно, это потребует больше усидчивости, чем рисование пером.
Жить вообще сложно, а что-то осознанно творить - тем более. Чего ты вообще ожидал, заходя в этот раздел? Что тебе дадут здесь волшебную кнопку "сделать круто"? К сожалению, до такой кнопки ещё минимум несколько лет ждать. Если не хочешь сам заниматься, готовь бабки - платишь специалистам и они делают всю работу за тебя, а ты только публикуешь готовый продукт.
>>Krita, Inkscape
>И как это мышкой рисовать
Есть способы:
1. Если вектор, то всё очень просто - Inkscape адаптирован под мышь и ты можешь нарисовать что угодно одной только мышью без проблем. Учитывай ограничения вектора: некоторые вещи проще сделать в растре.
2. Если растр:
2.1. Пиксель-арт подразумевает изменение отдельных пикселей в очень крупном приближении, так что мышкой это делается даже проще, чем пером. Krita имеет базовые инструменты для пиксель-арта.
2.2. Обычный цифровой арт тоже возможно рисовать мышкой. Для этого поможет создать очень большой холст и включить сильное сглаживание движений, тогда плавные линии будет легче делать, а косяки после сжатия картинки станут менее заметны. Но, конечно, это потребует больше усидчивости, чем рисование пером.
>это же гемморойно?
Жить вообще сложно, а что-то осознанно творить - тем более. Чего ты вообще ожидал, заходя в этот раздел? Что тебе дадут здесь волшебную кнопку "сделать круто"? К сожалению, до такой кнопки ещё минимум несколько лет ждать. Если не хочешь сам заниматься, готовь бабки - платишь специалистам и они делают всю работу за тебя, а ты только публикуешь готовый продукт.
>>37550
Вообще никак, забросил. Возможно, насовсем. Играться с физическим движком и конструктором из физических блоков прикольно, но чтобы сделать из этого полноценную игру, нужно много работать над кучей систем и, к тому же, подгонять достойный арт. А у меня мотивации нет всем этим заниматься. Изначальная мотивация была из-за того, что мне понравился базовый геймплей Worlds Adrift и других физических песочниц, но, видимо, я просто наигрался, а делать контент совсем не так интересно, как играть в физическую песочницу.
В общем, в очередной раз наступил на самые популярные грабли инди геймдева: "играть в игру" не равно "делать игру", т.е. даже если тебе нравится играть во что-то, вряд ли тебе понравится делать это. А играя в прототип игры, игру ты не делаешь - только играешь...
>как прогресс?
Вообще никак, забросил. Возможно, насовсем. Играться с физическим движком и конструктором из физических блоков прикольно, но чтобы сделать из этого полноценную игру, нужно много работать над кучей систем и, к тому же, подгонять достойный арт. А у меня мотивации нет всем этим заниматься. Изначальная мотивация была из-за того, что мне понравился базовый геймплей Worlds Adrift и других физических песочниц, но, видимо, я просто наигрался, а делать контент совсем не так интересно, как играть в физическую песочницу.
В общем, в очередной раз наступил на самые популярные грабли инди геймдева: "играть в игру" не равно "делать игру", т.е. даже если тебе нравится играть во что-то, вряд ли тебе понравится делать это. А играя в прототип игры, игру ты не делаешь - только играешь...
15 Кб, 447x447Разобрался в общих чертах с новым террейном в 4-ке. Будет время через недельку напишу гайд.
>>37757
Если вулкан не тянет, надо разбираться
Можешь попробовать запустить в режиме OpenGL, но там еще много фич не доделано (например в 3д теней нет)
Создай в пустой папке вот такой файл проекта project.godot
config_version=5
[application]
config/name="OpenGL Godot4"
config/features=PackedStringArray("4.0", "Mobile")
config/icon="res://icon.svg"
[rendering]
rendering_device/driver="opengl3"
renderer/rendering_method="gl_compatibility"
Запускать вот так из папки проекта
путь к годоту\Godot_v4.0-beta4_win64.exe --single-window --editor
Если вулкан не тянет, надо разбираться
Можешь попробовать запустить в режиме OpenGL, но там еще много фич не доделано (например в 3д теней нет)
Создай в пустой папке вот такой файл проекта project.godot
config_version=5
[application]
config/name="OpenGL Godot4"
config/features=PackedStringArray("4.0", "Mobile")
config/icon="res://icon.svg"
[rendering]
rendering_device/driver="opengl3"
renderer/rendering_method="gl_compatibility"
Запускать вот так из папки проекта
путь к годоту\Godot_v4.0-beta4_win64.exe --single-window --editor
>>37735
Не совсем так, там история немного сложнее
Движок можно собрать с float=32 или float=64. По умолчанию движок собран с 32, но решили что вскоре будут выкладывать и float=64 сборки.
В самом C#, конечно, есть dobule и float, но в годоте следует использовать тип real_t (дефайн есть в С# и С++)
В GDScript по докам float всегда 64-битный... Но и в C#, и в GDScript поля Vector2/Vector3 real_t.
Т.е. если движок собран float=32, то при записи твоего double внутрь движка он обрежется до float.
Кроме того есть статья про трудности с шейдерами
https://godotengine.org/article/emulating-double-precision-gpu-render-large-worlds
Если пересказать, то проблема будет, если тебе надо изобразить сантиметровое движение на расстоянии в десятки тысяч километров (потому что условно говоря в переменную влезает или 1.0001, или 1000.1, но не 1000.0001). И в версии движка float=64 в шейдере обрабатывается только одна ситуация - точная, плавная позиция объекта перед камерой.
Но там сказано, что рисованию экстра огромных объектов это не поможет. Например, планета размером с десятки тысяч километров, но чтобы вершины гор и ям с точностью до 1 см. Это надо делать самому.
Еще там написаны страшилки, что на Apple float=64 бита не работают, на Intel встройках падают (а в игровых видеокартах тормозят, чтобы покупали майнерские).
И, наверное, в физике тоже проблемы могут быть, но сходу не нашел.
Не совсем так, там история немного сложнее
Движок можно собрать с float=32 или float=64. По умолчанию движок собран с 32, но решили что вскоре будут выкладывать и float=64 сборки.
В самом C#, конечно, есть dobule и float, но в годоте следует использовать тип real_t (дефайн есть в С# и С++)
В GDScript по докам float всегда 64-битный... Но и в C#, и в GDScript поля Vector2/Vector3 real_t.
Т.е. если движок собран float=32, то при записи твоего double внутрь движка он обрежется до float.
Кроме того есть статья про трудности с шейдерами
https://godotengine.org/article/emulating-double-precision-gpu-render-large-worlds
Если пересказать, то проблема будет, если тебе надо изобразить сантиметровое движение на расстоянии в десятки тысяч километров (потому что условно говоря в переменную влезает или 1.0001, или 1000.1, но не 1000.0001). И в версии движка float=64 в шейдере обрабатывается только одна ситуация - точная, плавная позиция объекта перед камерой.
Но там сказано, что рисованию экстра огромных объектов это не поможет. Например, планета размером с десятки тысяч километров, но чтобы вершины гор и ям с точностью до 1 см. Это надо делать самому.
Еще там написаны страшилки, что на Apple float=64 бита не работают, на Intel встройках падают (а в игровых видеокартах тормозят, чтобы покупали майнерские).
И, наверное, в физике тоже проблемы могут быть, но сходу не нашел.
244 Кб, 833x617Знаю я вас достал! Но как пользоваться этим ебаным Visual Novel rakudo? Не могу найти видео туториал, ссылка на документацию выдаётся ошибка! 5 раз бросаю делать игру по причине убогости и непонимании движка. Хочу сделать физику меча, иду нахуй! Хочу сделать секторы геймплея диалогов в виде визуальных новелл, иду нахуй! Хочу сделать простое перемещение персонажа по пиксельному полю сука как в ебучем рпг мейкере! Но нихуя не получается! Ненавижу этот движок блять пусть разрабы rakudo горят в аду!
>>37484
Вопрос уже неактуален. Афторы Байонеты слились-сдулись и в трёшке сделали дженерик-прогрессбар с точками внизу, каждая точка - восстановление жизней до 100%. Таким образом игрок сразу видит, какой босс перед ним (трёхточечный, например). Так что в данном смысле я теперь ХЗ ваще, стоит ли пилить изъёбистый прогрессбар или спиздить у титанов игростроя? Всё равно сами титаны пиздят друг у друга интерфейсы, как будто в одну и ту же игру играешь. Мод на мод на мод.
> несколько сцен с прогрессбарами разных цветов
Вопрос уже неактуален. Афторы Байонеты слились-сдулись и в трёшке сделали дженерик-прогрессбар с точками внизу, каждая точка - восстановление жизней до 100%. Таким образом игрок сразу видит, какой босс перед ним (трёхточечный, например). Так что в данном смысле я теперь ХЗ ваще, стоит ли пилить изъёбистый прогрессбар или спиздить у титанов игростроя? Всё равно сами титаны пиздят друг у друга интерфейсы, как будто в одну и ту же игру играешь. Мод на мод на мод.
>>37490
В гдскрипт нет в принципе приватного доступа к членам класса, что автоматически даёт нам ответ на давний вопрос: "На каком языке пилить сложную логику в годоте?" Разумеется, на шарпе. А ещё лучше сразу пилить либу со сложной логикой, чтобы она висела отдельно и подключалась к годоту по паттерну MVP (Model-View-Presenter) где эта наша сложная логика - модель, и она в отдельной либе. Вьюшка и презентёр - годот. И у тебя всегда будет возможность сменить движок и закатиться на другой движок с готовой игровой логикой в виде готовой, работающей модели.
Никого ни к чему не призываю. Всем добра!
В гдскрипт нет в принципе приватного доступа к членам класса, что автоматически даёт нам ответ на давний вопрос: "На каком языке пилить сложную логику в годоте?" Разумеется, на шарпе. А ещё лучше сразу пилить либу со сложной логикой, чтобы она висела отдельно и подключалась к годоту по паттерну MVP (Model-View-Presenter) где эта наша сложная логика - модель, и она в отдельной либе. Вьюшка и презентёр - годот. И у тебя всегда будет возможность сменить движок и закатиться на другой движок с готовой игровой логикой в виде готовой, работающей модели.
Никого ни к чему не призываю. Всем добра!
>>37499
Забавно в этом то, что в современном продакшоне на шарпогалерах уже переиграли и хуярят атрибуты в одну строку:
> Теперь это аннотация, как в других языках, и может писаться выше строкой.
Забавно в этом то, что в современном продакшоне на шарпогалерах уже переиграли и хуярят атрибуты в одну строку:
> [HurrDurrable] private void Derp(Foo bar) {}
>>37916
Ну Сан Саныч, ты чего. На C++ конечно.
>"На каком языке пилить сложную логику в годоте?"
>Разумеется, на шарпе.
Ну Сан Саныч, ты чего. На C++ конечно.
>>37624
Пасиб, изучим.
Пасиб, изучим.
>>37919
На шарпе пишешь, а потом при необходимости оптимизируешь, переписывая на кресты. Но только когда игра будет готова. Оптимизировать надо после того как игра будет готова. Когда будет игра, будет и что оптимизировать. Ещё раз повторить?
На шарпе пишешь, а потом при необходимости оптимизируешь, переписывая на кресты. Но только когда игра будет готова. Оптимизировать надо после того как игра будет готова. Когда будет игра, будет и что оптимизировать. Ещё раз повторить?
>>37921
Шарп тут лишний шаг. Я тоже сначала так думал, но пришел к тому, что пишу на гдскрипте, а оптимизирую на с++.
Это тоже не совсем так, некоторые вещи проще сразу нормально написать (грубо говоря, нет смысла делать Нойту на тайлмапе в надежде что потом заставишь его работать быстрее - лучше сразу разрабатывать систему конкретно под игру).
Шарп тут лишний шаг. Я тоже сначала так думал, но пришел к тому, что пишу на гдскрипте, а оптимизирую на с++.
>Оптимизировать надо после того как игра будет готова. Когда будет игра, будет и что оптимизировать.
Это тоже не совсем так, некоторые вещи проще сразу нормально написать (грубо говоря, нет смысла делать Нойту на тайлмапе в надежде что потом заставишь его работать быстрее - лучше сразу разрабатывать систему конкретно под игру).
>>37924
Аналогично не получится просто накидывать ассеты, надеясь что в какой то момент получится опенворлд - надо сразу пилить системы под опенворлд.
Аналогично не получится просто накидывать ассеты, надеясь что в какой то момент получится опенворлд - надо сразу пилить системы под опенворлд.
>>37908
Ты чего такой дерзкий, пуся?
Ракуго я не использовал, но это не движок, а фреймворк, т.е. набор компонентов для типичных визуальных новелл. Всё остальное ты должен делать сам с помощью базового функционала Годо, т.к. Ракуго тут вообще ни при чём.
Опиши подробнее возникающие проблемы и что именно ты хочешь сделать, попробую помочь.
>пусть разрабы rakudo горят в аду!
Ты чего такой дерзкий, пуся?
Ракуго я не использовал, но это не движок, а фреймворк, т.е. набор компонентов для типичных визуальных новелл. Всё остальное ты должен делать сам с помощью базового функционала Годо, т.к. Ракуго тут вообще ни при чём.
Опиши подробнее возникающие проблемы и что именно ты хочешь сделать, попробую помочь.
>>37916
В документации рекомендуется все приватные поля и приватные методы начинать с "_", чтобы точно знать, к чему можно обращаться извне. Я стараюсь следовать этой рекомендации и поэтому всё начинаю с "_", если не планирую обращаться извне.
C# уродлив, как и все си-подобные языки.
Лучше на Паскале писать, транспилируя в C.
Тут возникает вопрос: как ты планируешь тестировать модель в отдельной либе? Ты ведь не можешь запустить либу на выполнение, и не можешь подключить к движку недоделанную либу. Ты должен быть гением программной архитектуры, чтобы с первой попытки создать рабочую модель, без итеративных тестов. Godot + GDScript позволяет тебе работать в стиле "написал строчку кода - запустил на выполнение", чего не позволяют такие движки как Юнити (потому что компиляция C# у Юнити занимает 10 минут, а строчку кода ты писал 10 секунд). Пытаясь написать всю логику игры в отдельной либе, ты отбрасываешь все преимущества Годо и возвращаешься в доисторические времена, когда программу от начала до конца писали на бумаге, перебивали на перфоленты и ждали несколько дней результата от вычислительного центра.
Крайне сомнительна. В большинстве игр очень мало логики, и основной код состоит из обращений к API движка/ОС. Какую логику ты планируешь переносить с движка на движок? Логику "если нажали new game, нужно начать новую игру"? Или что? Движки слишком разные, чтобы можно было перенести логику типичной игры без изменений. А неизменная логика настолько мизерная, что смысла выносить её в либу нет.
Ну, вот, простой пример. Чанковая система для большого мира. Что эта система будет делать? Дёргать API движка каждый кадр, выясняя положение игрока, и затем снова дёргать API движка, переключая видимость каких-либо объектов, свойства физических тел и т.д. Неизменная логика в этой системе - это малюсенькая формула, вычисляющая положение игрока в сети чанков, а всё остальное завязано на API движка. Да, ты можешь вынести эту малюсенькую логику во внешнюю библиотеку, а затем прокидывать в неё API движка, но стоит ли оно таких задрат? Тем более что для другого движка тебе снова потребуется прокидывать API, но уже совершенно другое. Да и будешь ли ты менять движок? А если и будешь, такую мелкую формулу несложно переписать на другой язык.
>>37921
Некоторые вещи можно оптимизировать, только полностью переделав геймдизайн игры. Т.е. экономия ресурсов должна быть заложена в фундамент игры. Простой пример: Кирилл захотел ММО-экшон в галактике, где каждая планета и каждый предмет состоит из атомов, движущихся по реальным физическим законам. Кирилл сделал игру, но она рендерит 1 кадр в 1000 лет. Кирилл начал оптимизировать игру, и в результате дооптимизировал до того, что теперь у него планеты - это просто статичные спрайты на фоне, и вообще игра для одного пользователя, и не в галактике, а на орбите одной планеты-спрайта, и не экшон, а головоломка. Т.е. он должен был заранее отбросить нереалистичные задумки, чтобы не делать лишнюю работу. Многие задумки на данный момент или принципиально невозможно оптимизировать, не отказавшись от них полностью.
>>37924 >>37925
На самом деле, можно делать игру, используя в качестве временных заглушек встроенные инструменты. В хорошей архитектуре все системы сильно абстрагированы друг от друга, соответственно можно заменить одну систему без влияния на другие. Т.о. можно использовать тайлмап/гридмап, пока работаешь над другими механиками игры, а затем заменить тайлмап/гридмап на более сложную кастомную систему, когда до неё дойдёт время. Но это не "оптимизация", это полное переделывание реализации системы без изменения внешнего интерфейса. Т.е. не нужно пытаться сделать всю игру на этой заглушке, но она может помочь протестировать некоторые фичи, которые сложно протестировать в полной пустоте (без почвы под ногами).
>нет в принципе приватного доступа к членам класса, что автоматически
В документации рекомендуется все приватные поля и приватные методы начинать с "_", чтобы точно знать, к чему можно обращаться извне. Я стараюсь следовать этой рекомендации и поэтому всё начинаю с "_", если не планирую обращаться извне.
>Разумеется, на шарпе
C# уродлив, как и все си-подобные языки.
Лучше на Паскале писать, транспилируя в C.
>сразу пилить либу со сложной логикой
>модель, и она в отдельной либе
Тут возникает вопрос: как ты планируешь тестировать модель в отдельной либе? Ты ведь не можешь запустить либу на выполнение, и не можешь подключить к движку недоделанную либу. Ты должен быть гением программной архитектуры, чтобы с первой попытки создать рабочую модель, без итеративных тестов. Godot + GDScript позволяет тебе работать в стиле "написал строчку кода - запустил на выполнение", чего не позволяют такие движки как Юнити (потому что компиляция C# у Юнити занимает 10 минут, а строчку кода ты писал 10 секунд). Пытаясь написать всю логику игры в отдельной либе, ты отбрасываешь все преимущества Годо и возвращаешься в доисторические времена, когда программу от начала до конца писали на бумаге, перебивали на перфоленты и ждали несколько дней результата от вычислительного центра.
>возможность сменить движок
Крайне сомнительна. В большинстве игр очень мало логики, и основной код состоит из обращений к API движка/ОС. Какую логику ты планируешь переносить с движка на движок? Логику "если нажали new game, нужно начать новую игру"? Или что? Движки слишком разные, чтобы можно было перенести логику типичной игры без изменений. А неизменная логика настолько мизерная, что смысла выносить её в либу нет.
Ну, вот, простой пример. Чанковая система для большого мира. Что эта система будет делать? Дёргать API движка каждый кадр, выясняя положение игрока, и затем снова дёргать API движка, переключая видимость каких-либо объектов, свойства физических тел и т.д. Неизменная логика в этой системе - это малюсенькая формула, вычисляющая положение игрока в сети чанков, а всё остальное завязано на API движка. Да, ты можешь вынести эту малюсенькую логику во внешнюю библиотеку, а затем прокидывать в неё API движка, но стоит ли оно таких задрат? Тем более что для другого движка тебе снова потребуется прокидывать API, но уже совершенно другое. Да и будешь ли ты менять движок? А если и будешь, такую мелкую формулу несложно переписать на другой язык.
>>37921
>Оптимизировать надо после того как игра будет готова. Когда будет игра, будет и что оптимизировать.
Некоторые вещи можно оптимизировать, только полностью переделав геймдизайн игры. Т.е. экономия ресурсов должна быть заложена в фундамент игры. Простой пример: Кирилл захотел ММО-экшон в галактике, где каждая планета и каждый предмет состоит из атомов, движущихся по реальным физическим законам. Кирилл сделал игру, но она рендерит 1 кадр в 1000 лет. Кирилл начал оптимизировать игру, и в результате дооптимизировал до того, что теперь у него планеты - это просто статичные спрайты на фоне, и вообще игра для одного пользователя, и не в галактике, а на орбите одной планеты-спрайта, и не экшон, а головоломка. Т.е. он должен был заранее отбросить нереалистичные задумки, чтобы не делать лишнюю работу. Многие задумки на данный момент или принципиально невозможно оптимизировать, не отказавшись от них полностью.
>>37924 >>37925
На самом деле, можно делать игру, используя в качестве временных заглушек встроенные инструменты. В хорошей архитектуре все системы сильно абстрагированы друг от друга, соответственно можно заменить одну систему без влияния на другие. Т.о. можно использовать тайлмап/гридмап, пока работаешь над другими механиками игры, а затем заменить тайлмап/гридмап на более сложную кастомную систему, когда до неё дойдёт время. Но это не "оптимизация", это полное переделывание реализации системы без изменения внешнего интерфейса. Т.е. не нужно пытаться сделать всю игру на этой заглушке, но она может помочь протестировать некоторые фичи, которые сложно протестировать в полной пустоте (без почвы под ногами).
>>37916
В документации рекомендуется все приватные поля и приватные методы начинать с "_", чтобы точно знать, к чему можно обращаться извне. Я стараюсь следовать этой рекомендации и поэтому всё начинаю с "_", если не планирую обращаться извне.
C# уродлив, как и все си-подобные языки.
Лучше на Паскале писать, транспилируя в C.
Тут возникает вопрос: как ты планируешь тестировать модель в отдельной либе? Ты ведь не можешь запустить либу на выполнение, и не можешь подключить к движку недоделанную либу. Ты должен быть гением программной архитектуры, чтобы с первой попытки создать рабочую модель, без итеративных тестов. Godot + GDScript позволяет тебе работать в стиле "написал строчку кода - запустил на выполнение", чего не позволяют такие движки как Юнити (потому что компиляция C# у Юнити занимает 10 минут, а строчку кода ты писал 10 секунд). Пытаясь написать всю логику игры в отдельной либе, ты отбрасываешь все преимущества Годо и возвращаешься в доисторические времена, когда программу от начала до конца писали на бумаге, перебивали на перфоленты и ждали несколько дней результата от вычислительного центра.
Крайне сомнительна. В большинстве игр очень мало логики, и основной код состоит из обращений к API движка/ОС. Какую логику ты планируешь переносить с движка на движок? Логику "если нажали new game, нужно начать новую игру"? Или что? Движки слишком разные, чтобы можно было перенести логику типичной игры без изменений. А неизменная логика настолько мизерная, что смысла выносить её в либу нет.
Ну, вот, простой пример. Чанковая система для большого мира. Что эта система будет делать? Дёргать API движка каждый кадр, выясняя положение игрока, и затем снова дёргать API движка, переключая видимость каких-либо объектов, свойства физических тел и т.д. Неизменная логика в этой системе - это малюсенькая формула, вычисляющая положение игрока в сети чанков, а всё остальное завязано на API движка. Да, ты можешь вынести эту малюсенькую логику во внешнюю библиотеку, а затем прокидывать в неё API движка, но стоит ли оно таких задрат? Тем более что для другого движка тебе снова потребуется прокидывать API, но уже совершенно другое. Да и будешь ли ты менять движок? А если и будешь, такую мелкую формулу несложно переписать на другой язык.
>>37921
Некоторые вещи можно оптимизировать, только полностью переделав геймдизайн игры. Т.е. экономия ресурсов должна быть заложена в фундамент игры. Простой пример: Кирилл захотел ММО-экшон в галактике, где каждая планета и каждый предмет состоит из атомов, движущихся по реальным физическим законам. Кирилл сделал игру, но она рендерит 1 кадр в 1000 лет. Кирилл начал оптимизировать игру, и в результате дооптимизировал до того, что теперь у него планеты - это просто статичные спрайты на фоне, и вообще игра для одного пользователя, и не в галактике, а на орбите одной планеты-спрайта, и не экшон, а головоломка. Т.е. он должен был заранее отбросить нереалистичные задумки, чтобы не делать лишнюю работу. Многие задумки на данный момент или принципиально невозможно оптимизировать, не отказавшись от них полностью.
>>37924 >>37925
На самом деле, можно делать игру, используя в качестве временных заглушек встроенные инструменты. В хорошей архитектуре все системы сильно абстрагированы друг от друга, соответственно можно заменить одну систему без влияния на другие. Т.о. можно использовать тайлмап/гридмап, пока работаешь над другими механиками игры, а затем заменить тайлмап/гридмап на более сложную кастомную систему, когда до неё дойдёт время. Но это не "оптимизация", это полное переделывание реализации системы без изменения внешнего интерфейса. Т.е. не нужно пытаться сделать всю игру на этой заглушке, но она может помочь протестировать некоторые фичи, которые сложно протестировать в полной пустоте (без почвы под ногами).
>нет в принципе приватного доступа к членам класса, что автоматически
В документации рекомендуется все приватные поля и приватные методы начинать с "_", чтобы точно знать, к чему можно обращаться извне. Я стараюсь следовать этой рекомендации и поэтому всё начинаю с "_", если не планирую обращаться извне.
>Разумеется, на шарпе
C# уродлив, как и все си-подобные языки.
Лучше на Паскале писать, транспилируя в C.
>сразу пилить либу со сложной логикой
>модель, и она в отдельной либе
Тут возникает вопрос: как ты планируешь тестировать модель в отдельной либе? Ты ведь не можешь запустить либу на выполнение, и не можешь подключить к движку недоделанную либу. Ты должен быть гением программной архитектуры, чтобы с первой попытки создать рабочую модель, без итеративных тестов. Godot + GDScript позволяет тебе работать в стиле "написал строчку кода - запустил на выполнение", чего не позволяют такие движки как Юнити (потому что компиляция C# у Юнити занимает 10 минут, а строчку кода ты писал 10 секунд). Пытаясь написать всю логику игры в отдельной либе, ты отбрасываешь все преимущества Годо и возвращаешься в доисторические времена, когда программу от начала до конца писали на бумаге, перебивали на перфоленты и ждали несколько дней результата от вычислительного центра.
>возможность сменить движок
Крайне сомнительна. В большинстве игр очень мало логики, и основной код состоит из обращений к API движка/ОС. Какую логику ты планируешь переносить с движка на движок? Логику "если нажали new game, нужно начать новую игру"? Или что? Движки слишком разные, чтобы можно было перенести логику типичной игры без изменений. А неизменная логика настолько мизерная, что смысла выносить её в либу нет.
Ну, вот, простой пример. Чанковая система для большого мира. Что эта система будет делать? Дёргать API движка каждый кадр, выясняя положение игрока, и затем снова дёргать API движка, переключая видимость каких-либо объектов, свойства физических тел и т.д. Неизменная логика в этой системе - это малюсенькая формула, вычисляющая положение игрока в сети чанков, а всё остальное завязано на API движка. Да, ты можешь вынести эту малюсенькую логику во внешнюю библиотеку, а затем прокидывать в неё API движка, но стоит ли оно таких задрат? Тем более что для другого движка тебе снова потребуется прокидывать API, но уже совершенно другое. Да и будешь ли ты менять движок? А если и будешь, такую мелкую формулу несложно переписать на другой язык.
>>37921
>Оптимизировать надо после того как игра будет готова. Когда будет игра, будет и что оптимизировать.
Некоторые вещи можно оптимизировать, только полностью переделав геймдизайн игры. Т.е. экономия ресурсов должна быть заложена в фундамент игры. Простой пример: Кирилл захотел ММО-экшон в галактике, где каждая планета и каждый предмет состоит из атомов, движущихся по реальным физическим законам. Кирилл сделал игру, но она рендерит 1 кадр в 1000 лет. Кирилл начал оптимизировать игру, и в результате дооптимизировал до того, что теперь у него планеты - это просто статичные спрайты на фоне, и вообще игра для одного пользователя, и не в галактике, а на орбите одной планеты-спрайта, и не экшон, а головоломка. Т.е. он должен был заранее отбросить нереалистичные задумки, чтобы не делать лишнюю работу. Многие задумки на данный момент или принципиально невозможно оптимизировать, не отказавшись от них полностью.
>>37924 >>37925
На самом деле, можно делать игру, используя в качестве временных заглушек встроенные инструменты. В хорошей архитектуре все системы сильно абстрагированы друг от друга, соответственно можно заменить одну систему без влияния на другие. Т.о. можно использовать тайлмап/гридмап, пока работаешь над другими механиками игры, а затем заменить тайлмап/гридмап на более сложную кастомную систему, когда до неё дойдёт время. Но это не "оптимизация", это полное переделывание реализации системы без изменения внешнего интерфейса. Т.е. не нужно пытаться сделать всю игру на этой заглушке, но она может помочь протестировать некоторые фичи, которые сложно протестировать в полной пустоте (без почвы под ногами).
>>37942
Лол, легко, если как раз абстрагировать логику от движка. О чём челик и говорит. А вообще это проблема имено движков, которые должны давать инструменты выполнения сложных тестов.
Если у тебя комп 15 летней давности. Тебе необязательно компилировать всё, держку в курсе, разделение на библиотеки в том числе и нужно, чтобы не перекомпилировать каждую строчку от каждого пука.
Не, это значит что он получит ядро игры, которое с малой болью портирует на юнити, когда поймёт что все игровые движки это глючное говно, но на юнити хотя бы можно что-то сделать.
Ты вообще понимаешь смысл своей же фразы:
Вообще лет 5 прошло, а проблемы у анонов с pr и gd всё та же - они безработные шизики. У меня на работе уже контейнеры в контейнерах запускают, которые поднимают и отдельные базы, и шины сообщений, и всё что угодно. Такие тесты буквально имитируют реальную работу приложения. И все эти тесты это всего пару сотен строк в C#, да. То что у вас в геймдеве бардак для макак это не проблема языков, а проблема геймдева в целом. Ну и шизики которые живут в манямирке явно не помогают.
>Тут возникает вопрос: как ты планируешь тестировать модель в отдельной либе?
Лол, легко, если как раз абстрагировать логику от движка. О чём челик и говорит. А вообще это проблема имено движков, которые должны давать инструменты выполнения сложных тестов.
>потому что компиляция C# у Юнити занимает 10 минут
Если у тебя комп 15 летней давности. Тебе необязательно компилировать всё, держку в курсе, разделение на библиотеки в том числе и нужно, чтобы не перекомпилировать каждую строчку от каждого пука.
>Пытаясь написать всю логику игры в отдельной либе, ты отбрасываешь все преимущества Годо и возвращаешься в доисторические времена, когда программу от начала до конца писали на бумаге, перебивали на перфоленты и ждали несколько дней результата от вычислительного центра.
Не, это значит что он получит ядро игры, которое с малой болью портирует на юнити, когда поймёт что все игровые движки это глючное говно, но на юнити хотя бы можно что-то сделать.
Ты вообще понимаешь смысл своей же фразы:
>В хорошей архитектуре все системы сильно абстрагированы друг от друга, соответственно можно заменить одну систему без влияния на другие
Вообще лет 5 прошло, а проблемы у анонов с pr и gd всё та же - они безработные шизики. У меня на работе уже контейнеры в контейнерах запускают, которые поднимают и отдельные базы, и шины сообщений, и всё что угодно. Такие тесты буквально имитируют реальную работу приложения. И все эти тесты это всего пару сотен строк в C#, да. То что у вас в геймдеве бардак для макак это не проблема языков, а проблема геймдева в целом. Ну и шизики которые живут в манямирке явно не помогают.
>>37967
Юзай Dialogic.
Диалоги пишутся без туториалов на чистом интуитиве. Ракуго это ваше не смотрел, но уверен, диалоджик круче. А ещё он есть в шапке. А ракуги нет.
Юзай Dialogic.
Диалоги пишутся без туториалов на чистом интуитиве. Ракуго это ваше не смотрел, но уверен, диалоджик круче. А ещё он есть в шапке. А ракуги нет.
523 Кб, 848x477>>38036
Там hud нужно самому с нуля подгонять. И как я понял под каждый диалог делается hud по новой.
Там hud нужно самому с нуля подгонять. И как я понял под каждый диалог делается hud по новой.
>>37967
UI или в скриптах?
С официального сайта:
Качаешь кит & делаешь игру.
>>38036
Прикольно, у него свой визуальный язык...
>>38061
И что? В Godot очень удобная GUI-система. Шлёпать формы даже проще, чем в Delphi. Ты не ленись давай, напряги мозги и один раз нормально изучи, потом благодарен и счастлив будешь, вот увидишь.
Лол что? Ты что-то перепутал, очевидно.
UI или в скриптах?
С официального сайта:
>Kits are template for your game project. They are Rakugo plus addons, and UI template that combines those together for given game genre.
Качаешь кит & делаешь игру.
>>38036
>Dialogic
Прикольно, у него свой визуальный язык...
>>38061
>hud нужно самому с нуля подгонять
И что? В Godot очень удобная GUI-система. Шлёпать формы даже проще, чем в Delphi. Ты не ленись давай, напряги мозги и один раз нормально изучи, потом благодарен и счастлив будешь, вот увидишь.
>под каждый диалог делается hud по новой.
Лол что? Ты что-то перепутал, очевидно.
>>37968
Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП? Но ведь это совсем не весело. Тебе реально доставляет писать тесты, которые игрой даже с большой натяжкой не являются? Ладно ещё игра, которая играет сама в себя, но тесты не играют в игру, они только сравнивают вывод каких-то объектов с эталонным/ожидаемым выводом. Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
Конечно, но в Unity ты альт-табаешься и она сама начинает что-то там компилировать, не говоря толком что и сколько времени это займёт - может, 15 секунд, а может, 15 минут, заранее неизвестно в этом клубке багов. В любом случае, нужен нормальный язык с нормальным компилятором, а не клон Java от Microsoft. Вот почему от Java все плюются, а C# суют куда попало? Потому что майки распиарили очень хорошо. С Юнити ситуация абсолютно та же - бешенный, агрессивный пиар через все каналы. Без пиара отток пользователей с Юнити был бы катастрофическим для её владельцев, учитывая все альтернативы.
Лол, сделай не глючное говно. Зачем плакать и колоться об глючную юнити, если у тебя уже готово "ядро игры" и достаточно только прикрутить рендерер и физический движок? Тебе не нужен игровой движок типа юнити, если у тебя уже есть игра; тебе нужны только компоненты движка, чтобы игра могла выводить картинку на экран.
Ты ж по сути предлагаешь сделать игру без движка и каких-либо редакторов сцен, чисто в редакторе кода библиотеки, а потом подключить эту библиотеку к движку, чтобы выводить картинку и принимать ввод пользователя. То есть, например, ты предлагаешь отказаться от встроенного в игровой движок менеджера сцен (в Годо - дерево сцены с нодами), иначе твоя библиотека будет недостаточно абстрактна и её будет невозможно протестировать независимо от конкретного игрового движка. Зачем тогда вообще движок, если всё велосипедировать?
Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется. Не понравилось делать игры - не делаем, а ты вынужден крутиться, чтобы не вылететь с насиженного места. Так что не понимаю твоего возмущения - если нам не хочется писать автотесты на сотню строк C# и переходить на Юнити, то мы не пишем и не переходим, и не имеем с этим абсолютно никаких проблем, кроме завистливого шипения таких как ты. У одного тебя жопа воспламеняется от осознания, что "шизики" с форума свободнее тебя в своих решениях.
Лично я очень люблю программировать. Люблю видеть, как моя программа "встаёт на ноги" и "делает первые шаги", а потом развивается, учится новым вещам. Но это не получится увидеть сквозь безликие автотесты, которые как будто держат отдельные органы программы в банках, тестируя их свойства. Какое-то бездушное отношение к разработке. Совсем не то, что запустить программу на исполнение и взаимодействовать с ней, как с ребёнком, который ещё мало что умеет, но активно учится. В общем, мне не понять радости наёмных программистов на галерах, выполняющих строгие инструкции начальства ради проекта, который им даже не принадлежит...
Да, кстати, я даже в депрессию впадаю, когда ломаю что-нибудь в коде и программа не запускается или сильно деградирует. Как будто убил или изуродовал живое существо. Тяжело с этим жить, конечно...
>легко, если как раз абстрагировать логику
Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП? Но ведь это совсем не весело. Тебе реально доставляет писать тесты, которые игрой даже с большой натяжкой не являются? Ладно ещё игра, которая играет сама в себя, но тесты не играют в игру, они только сравнивают вывод каких-то объектов с эталонным/ожидаемым выводом. Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
>необязательно компилировать всё
Конечно, но в Unity ты альт-табаешься и она сама начинает что-то там компилировать, не говоря толком что и сколько времени это займёт - может, 15 секунд, а может, 15 минут, заранее неизвестно в этом клубке багов. В любом случае, нужен нормальный язык с нормальным компилятором, а не клон Java от Microsoft. Вот почему от Java все плюются, а C# суют куда попало? Потому что майки распиарили очень хорошо. С Юнити ситуация абсолютно та же - бешенный, агрессивный пиар через все каналы. Без пиара отток пользователей с Юнити был бы катастрофическим для её владельцев, учитывая все альтернативы.
>все игровые движки это глючное говно, но на юнити хотя бы можно что-то сделать.
Лол, сделай не глючное говно. Зачем плакать и колоться об глючную юнити, если у тебя уже готово "ядро игры" и достаточно только прикрутить рендерер и физический движок? Тебе не нужен игровой движок типа юнити, если у тебя уже есть игра; тебе нужны только компоненты движка, чтобы игра могла выводить картинку на экран.
Ты ж по сути предлагаешь сделать игру без движка и каких-либо редакторов сцен, чисто в редакторе кода библиотеки, а потом подключить эту библиотеку к движку, чтобы выводить картинку и принимать ввод пользователя. То есть, например, ты предлагаешь отказаться от встроенного в игровой движок менеджера сцен (в Годо - дерево сцены с нодами), иначе твоя библиотека будет недостаточно абстрактна и её будет невозможно протестировать независимо от конкретного игрового движка. Зачем тогда вообще движок, если всё велосипедировать?
>У меня на работе
Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется. Не понравилось делать игры - не делаем, а ты вынужден крутиться, чтобы не вылететь с насиженного места. Так что не понимаю твоего возмущения - если нам не хочется писать автотесты на сотню строк C# и переходить на Юнити, то мы не пишем и не переходим, и не имеем с этим абсолютно никаких проблем, кроме завистливого шипения таких как ты. У одного тебя жопа воспламеняется от осознания, что "шизики" с форума свободнее тебя в своих решениях.
Лично я очень люблю программировать. Люблю видеть, как моя программа "встаёт на ноги" и "делает первые шаги", а потом развивается, учится новым вещам. Но это не получится увидеть сквозь безликие автотесты, которые как будто держат отдельные органы программы в банках, тестируя их свойства. Какое-то бездушное отношение к разработке. Совсем не то, что запустить программу на исполнение и взаимодействовать с ней, как с ребёнком, который ещё мало что умеет, но активно учится. В общем, мне не понять радости наёмных программистов на галерах, выполняющих строгие инструкции начальства ради проекта, который им даже не принадлежит...
Да, кстати, я даже в депрессию впадаю, когда ломаю что-нибудь в коде и программа не запускается или сильно деградирует. Как будто убил или изуродовал живое существо. Тяжело с этим жить, конечно...
>>37968
Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП? Но ведь это совсем не весело. Тебе реально доставляет писать тесты, которые игрой даже с большой натяжкой не являются? Ладно ещё игра, которая играет сама в себя, но тесты не играют в игру, они только сравнивают вывод каких-то объектов с эталонным/ожидаемым выводом. Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
Конечно, но в Unity ты альт-табаешься и она сама начинает что-то там компилировать, не говоря толком что и сколько времени это займёт - может, 15 секунд, а может, 15 минут, заранее неизвестно в этом клубке багов. В любом случае, нужен нормальный язык с нормальным компилятором, а не клон Java от Microsoft. Вот почему от Java все плюются, а C# суют куда попало? Потому что майки распиарили очень хорошо. С Юнити ситуация абсолютно та же - бешенный, агрессивный пиар через все каналы. Без пиара отток пользователей с Юнити был бы катастрофическим для её владельцев, учитывая все альтернативы.
Лол, сделай не глючное говно. Зачем плакать и колоться об глючную юнити, если у тебя уже готово "ядро игры" и достаточно только прикрутить рендерер и физический движок? Тебе не нужен игровой движок типа юнити, если у тебя уже есть игра; тебе нужны только компоненты движка, чтобы игра могла выводить картинку на экран.
Ты ж по сути предлагаешь сделать игру без движка и каких-либо редакторов сцен, чисто в редакторе кода библиотеки, а потом подключить эту библиотеку к движку, чтобы выводить картинку и принимать ввод пользователя. То есть, например, ты предлагаешь отказаться от встроенного в игровой движок менеджера сцен (в Годо - дерево сцены с нодами), иначе твоя библиотека будет недостаточно абстрактна и её будет невозможно протестировать независимо от конкретного игрового движка. Зачем тогда вообще движок, если всё велосипедировать?
Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется. Не понравилось делать игры - не делаем, а ты вынужден крутиться, чтобы не вылететь с насиженного места. Так что не понимаю твоего возмущения - если нам не хочется писать автотесты на сотню строк C# и переходить на Юнити, то мы не пишем и не переходим, и не имеем с этим абсолютно никаких проблем, кроме завистливого шипения таких как ты. У одного тебя жопа воспламеняется от осознания, что "шизики" с форума свободнее тебя в своих решениях.
Лично я очень люблю программировать. Люблю видеть, как моя программа "встаёт на ноги" и "делает первые шаги", а потом развивается, учится новым вещам. Но это не получится увидеть сквозь безликие автотесты, которые как будто держат отдельные органы программы в банках, тестируя их свойства. Какое-то бездушное отношение к разработке. Совсем не то, что запустить программу на исполнение и взаимодействовать с ней, как с ребёнком, который ещё мало что умеет, но активно учится. В общем, мне не понять радости наёмных программистов на галерах, выполняющих строгие инструкции начальства ради проекта, который им даже не принадлежит...
Да, кстати, я даже в депрессию впадаю, когда ломаю что-нибудь в коде и программа не запускается или сильно деградирует. Как будто убил или изуродовал живое существо. Тяжело с этим жить, конечно...
>легко, если как раз абстрагировать логику
Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП? Но ведь это совсем не весело. Тебе реально доставляет писать тесты, которые игрой даже с большой натяжкой не являются? Ладно ещё игра, которая играет сама в себя, но тесты не играют в игру, они только сравнивают вывод каких-то объектов с эталонным/ожидаемым выводом. Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
>необязательно компилировать всё
Конечно, но в Unity ты альт-табаешься и она сама начинает что-то там компилировать, не говоря толком что и сколько времени это займёт - может, 15 секунд, а может, 15 минут, заранее неизвестно в этом клубке багов. В любом случае, нужен нормальный язык с нормальным компилятором, а не клон Java от Microsoft. Вот почему от Java все плюются, а C# суют куда попало? Потому что майки распиарили очень хорошо. С Юнити ситуация абсолютно та же - бешенный, агрессивный пиар через все каналы. Без пиара отток пользователей с Юнити был бы катастрофическим для её владельцев, учитывая все альтернативы.
>все игровые движки это глючное говно, но на юнити хотя бы можно что-то сделать.
Лол, сделай не глючное говно. Зачем плакать и колоться об глючную юнити, если у тебя уже готово "ядро игры" и достаточно только прикрутить рендерер и физический движок? Тебе не нужен игровой движок типа юнити, если у тебя уже есть игра; тебе нужны только компоненты движка, чтобы игра могла выводить картинку на экран.
Ты ж по сути предлагаешь сделать игру без движка и каких-либо редакторов сцен, чисто в редакторе кода библиотеки, а потом подключить эту библиотеку к движку, чтобы выводить картинку и принимать ввод пользователя. То есть, например, ты предлагаешь отказаться от встроенного в игровой движок менеджера сцен (в Годо - дерево сцены с нодами), иначе твоя библиотека будет недостаточно абстрактна и её будет невозможно протестировать независимо от конкретного игрового движка. Зачем тогда вообще движок, если всё велосипедировать?
>У меня на работе
Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется. Не понравилось делать игры - не делаем, а ты вынужден крутиться, чтобы не вылететь с насиженного места. Так что не понимаю твоего возмущения - если нам не хочется писать автотесты на сотню строк C# и переходить на Юнити, то мы не пишем и не переходим, и не имеем с этим абсолютно никаких проблем, кроме завистливого шипения таких как ты. У одного тебя жопа воспламеняется от осознания, что "шизики" с форума свободнее тебя в своих решениях.
Лично я очень люблю программировать. Люблю видеть, как моя программа "встаёт на ноги" и "делает первые шаги", а потом развивается, учится новым вещам. Но это не получится увидеть сквозь безликие автотесты, которые как будто держат отдельные органы программы в банках, тестируя их свойства. Какое-то бездушное отношение к разработке. Совсем не то, что запустить программу на исполнение и взаимодействовать с ней, как с ребёнком, который ещё мало что умеет, но активно учится. В общем, мне не понять радости наёмных программистов на галерах, выполняющих строгие инструкции начальства ради проекта, который им даже не принадлежит...
Да, кстати, я даже в депрессию впадаю, когда ломаю что-нибудь в коде и программа не запускается или сильно деградирует. Как будто убил или изуродовал живое существо. Тяжело с этим жить, конечно...
23 Кб, 1108x735>>38103
Возможно. Сейчас перед установкой решил посмотреть как зарание сделать там функцию перемотке текста как в renpy. Но нашёл только гайд как переплеснуть диалог назад. Боюсь такой фунции в нем всё же нету.
>Лол что? Ты что-то перепутал, очевидно.
Возможно. Сейчас перед установкой решил посмотреть как зарание сделать там функцию перемотке текста как в renpy. Но нашёл только гайд как переплеснуть диалог назад. Боюсь такой фунции в нем всё же нету.
>>38137
Если будет мульт, то нет. Куча игр полусингловых хостит себе сервер локальный.
Если будет мульт, то нет. Куча игр полусингловых хостит себе сервер локальный.
>>38105
Тест-раннеры это обычно одна программа. Как C# код в той же студии тестируется в отрыве от юнити очевидно.
Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры. И если ты не заботишься от качестве - этим людям неприятно. Понятно что в инди слишком бюджеты и время урезаны, претензий нет. Претензии в том, что ты походу вообще считаешь всё это бесполезным, а потом сидишь в треде движка, у которого несколько тысяч открытых issue на гитхабе. Ты не думаешь что можно было сделать немного иначе?
Если ты пилишь небольшую сетевую игру и юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает - это тоже похуй, главное же разработка? Ты понимаешь откуда идёт профит с продаж?
Потому что C# тупо лучше, он рано адаптировал фишки функционального программирования и кучу удобного синтаксического сахара.
Видимо это сложно.
Это недостаток, да. В реальной жизни придётся идти на компромисс. Но тебе обычно очень много механик всё равно придётся пилить, которые к движку не относятся напрямую, вроде того же инвенторя, системы статов, или вот системы диалогов. Как бы ты написал хорошую систему диалогов для пользователей годота? Ядро бы я 100% абстрагировал и тестировал отдельно.
У меня нет никакого техлида, я в какой-то степени сам техлид, наверху меня только бизнес. Маняфантазии короче, а свобода делать совсем что хочешь - есть только у тех, у кого нет обязательств. У тебя нет обязательств перед людьми, для которых ты делаешь игры, и последствия у этого будут соответствующие. Я могу завтра уволиться например, чо у меня, денег мало что ли или я работу не найду? Просто работа это такие же добровольные обязательства за вознаграждение.
Да я тоже, только ирл чтобы сделать продукт тебе надо быть решателем реальных проблем. Можешь глянуть на соседний тред где челик таки делает игры, нанимает каких-то людей, делает отзывы, демки, чтобы максимизировать добавления его игры в вишлист.
Короче ладно я понял что ты шизик просто. Это вообще проблема гд - тут слишком много шизиков. А я моду ещё 10 лет назад говорил что надо было всех шизиков с вебмками забанить просто. Теперь гд похож на говно.
>Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП?
Тест-раннеры это обычно одна программа. Как C# код в той же студии тестируется в отрыве от юнити очевидно.
>Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры. И если ты не заботишься от качестве - этим людям неприятно. Понятно что в инди слишком бюджеты и время урезаны, претензий нет. Претензии в том, что ты походу вообще считаешь всё это бесполезным, а потом сидишь в треде движка, у которого несколько тысяч открытых issue на гитхабе. Ты не думаешь что можно было сделать немного иначе?
Если ты пилишь небольшую сетевую игру и юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает - это тоже похуй, главное же разработка? Ты понимаешь откуда идёт профит с продаж?
>Вот почему от Java все плюются, а C# суют куда попало?
Потому что C# тупо лучше, он рано адаптировал фишки функционального программирования и кучу удобного синтаксического сахара.
>Лол, сделай не глючное говно.
Видимо это сложно.
>Зачем тогда вообще движок, если всё велосипедировать?
Это недостаток, да. В реальной жизни придётся идти на компромисс. Но тебе обычно очень много механик всё равно придётся пилить, которые к движку не относятся напрямую, вроде того же инвенторя, системы статов, или вот системы диалогов. Как бы ты написал хорошую систему диалогов для пользователей годота? Ядро бы я 100% абстрагировал и тестировал отдельно.
>Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется.
У меня нет никакого техлида, я в какой-то степени сам техлид, наверху меня только бизнес. Маняфантазии короче, а свобода делать совсем что хочешь - есть только у тех, у кого нет обязательств. У тебя нет обязательств перед людьми, для которых ты делаешь игры, и последствия у этого будут соответствующие. Я могу завтра уволиться например, чо у меня, денег мало что ли или я работу не найду? Просто работа это такие же добровольные обязательства за вознаграждение.
>Лично я очень люблю программировать
Да я тоже, только ирл чтобы сделать продукт тебе надо быть решателем реальных проблем. Можешь глянуть на соседний тред где челик таки делает игры, нанимает каких-то людей, делает отзывы, демки, чтобы максимизировать добавления его игры в вишлист.
Короче ладно я понял что ты шизик просто. Это вообще проблема гд - тут слишком много шизиков. А я моду ещё 10 лет назад говорил что надо было всех шизиков с вебмками забанить просто. Теперь гд похож на говно.
>>38105
Тест-раннеры это обычно одна программа. Как C# код в той же студии тестируется в отрыве от юнити очевидно.
Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры. И если ты не заботишься от качестве - этим людям неприятно. Понятно что в инди слишком бюджеты и время урезаны, претензий нет. Претензии в том, что ты походу вообще считаешь всё это бесполезным, а потом сидишь в треде движка, у которого несколько тысяч открытых issue на гитхабе. Ты не думаешь что можно было сделать немного иначе?
Если ты пилишь небольшую сетевую игру и юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает - это тоже похуй, главное же разработка? Ты понимаешь откуда идёт профит с продаж?
Потому что C# тупо лучше, он рано адаптировал фишки функционального программирования и кучу удобного синтаксического сахара.
Видимо это сложно.
Это недостаток, да. В реальной жизни придётся идти на компромисс. Но тебе обычно очень много механик всё равно придётся пилить, которые к движку не относятся напрямую, вроде того же инвенторя, системы статов, или вот системы диалогов. Как бы ты написал хорошую систему диалогов для пользователей годота? Ядро бы я 100% абстрагировал и тестировал отдельно.
У меня нет никакого техлида, я в какой-то степени сам техлид, наверху меня только бизнес. Маняфантазии короче, а свобода делать совсем что хочешь - есть только у тех, у кого нет обязательств. У тебя нет обязательств перед людьми, для которых ты делаешь игры, и последствия у этого будут соответствующие. Я могу завтра уволиться например, чо у меня, денег мало что ли или я работу не найду? Просто работа это такие же добровольные обязательства за вознаграждение.
Да я тоже, только ирл чтобы сделать продукт тебе надо быть решателем реальных проблем. Можешь глянуть на соседний тред где челик таки делает игры, нанимает каких-то людей, делает отзывы, демки, чтобы максимизировать добавления его игры в вишлист.
Короче ладно я понял что ты шизик просто. Это вообще проблема гд - тут слишком много шизиков. А я моду ещё 10 лет назад говорил что надо было всех шизиков с вебмками забанить просто. Теперь гд похож на говно.
>Технически-то как? Напишешь кучу консольных программ для тестирования классов ООП?
Тест-раннеры это обычно одна программа. Как C# код в той же студии тестируется в отрыве от юнити очевидно.
>Это максимальная рутина, и поэтому мало кто ей добровольно занимается, тем более в инди-геймдеве, куда приходят ради игр, а не профита с продаж прикладного ПО.
Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры. И если ты не заботишься от качестве - этим людям неприятно. Понятно что в инди слишком бюджеты и время урезаны, претензий нет. Претензии в том, что ты походу вообще считаешь всё это бесполезным, а потом сидишь в треде движка, у которого несколько тысяч открытых issue на гитхабе. Ты не думаешь что можно было сделать немного иначе?
Если ты пилишь небольшую сетевую игру и юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает - это тоже похуй, главное же разработка? Ты понимаешь откуда идёт профит с продаж?
>Вот почему от Java все плюются, а C# суют куда попало?
Потому что C# тупо лучше, он рано адаптировал фишки функционального программирования и кучу удобного синтаксического сахара.
>Лол, сделай не глючное говно.
Видимо это сложно.
>Зачем тогда вообще движок, если всё велосипедировать?
Это недостаток, да. В реальной жизни придётся идти на компромисс. Но тебе обычно очень много механик всё равно придётся пилить, которые к движку не относятся напрямую, вроде того же инвенторя, системы статов, или вот системы диалогов. Как бы ты написал хорошую систему диалогов для пользователей годота? Ядро бы я 100% абстрагировал и тестировал отдельно.
>Ты на работе делаешь так, как начальник скажет, а мы делаем так, как нам нравится и хочется.
У меня нет никакого техлида, я в какой-то степени сам техлид, наверху меня только бизнес. Маняфантазии короче, а свобода делать совсем что хочешь - есть только у тех, у кого нет обязательств. У тебя нет обязательств перед людьми, для которых ты делаешь игры, и последствия у этого будут соответствующие. Я могу завтра уволиться например, чо у меня, денег мало что ли или я работу не найду? Просто работа это такие же добровольные обязательства за вознаграждение.
>Лично я очень люблю программировать
Да я тоже, только ирл чтобы сделать продукт тебе надо быть решателем реальных проблем. Можешь глянуть на соседний тред где челик таки делает игры, нанимает каких-то людей, делает отзывы, демки, чтобы максимизировать добавления его игры в вишлист.
Короче ладно я понял что ты шизик просто. Это вообще проблема гд - тут слишком много шизиков. А я моду ещё 10 лет назад говорил что надо было всех шизиков с вебмками забанить просто. Теперь гд похож на говно.
>>38152
Такой момент тоже есть...
Такой момент тоже есть...
>>38180
В визуальных новеллах есть система перемотки текста. Мне нужно такое сделать.
В визуальных новеллах есть система перемотки текста. Мне нужно такое сделать.
>>38183
Нет, но в мою систему это интегрировать не сложно. Просто добавить буффер диалоговых ветвей, которые игрок прошел и переключаться между ними. Дело пяти минут
Нет, но в мою систему это интегрировать не сложно. Просто добавить буффер диалоговых ветвей, которые игрок прошел и переключаться между ними. Дело пяти минут
>>38183
История диалога? Как предположил анон выше? В диалоджике есть.
Перемотка большого абзаца текста в контейнере? В диалоджике есть.
Темы, стили, сохранения - всё что нужно есть в диалоджике. Если анон хочет делать игры, а не страдать хуйнёй, изобретая велосипеды - нужно брать готовое.
https://youtu.be/sYjgDIgD7AY
> система перемотки текста
История диалога? Как предположил анон выше? В диалоджике есть.
Перемотка большого абзаца текста в контейнере? В диалоджике есть.
Темы, стили, сохранения - всё что нужно есть в диалоджике. Если анон хочет делать игры, а не страдать хуйнёй, изобретая велосипеды - нужно брать готовое.
https://youtu.be/sYjgDIgD7AY
24 Кб, mp4,666x284, 0:05
>>38183
В годоте из коробки в Label есть параметр visible_characters, который можно анимировать, поэтому скорее всего все эти диалоговые системы строятся вокруг него.
В годоте из коробки в Label есть параметр visible_characters, который можно анимировать, поэтому скорее всего все эти диалоговые системы строятся вокруг него.
>>38229
Мой проект на этапе: Сложно! Что куда жать?!
Мой проект на этапе: Сложно! Что куда жать?!
95 Кб, 300x380>>38202
Если ты смог это с нуля сделать, то добавить кнопку пролистывания текста на x2 тебе будет легко создать.
>>38215
Это не история диалога, а быстрое его перелистывание. По сути пропуск. По другому это можно объяснить когда ты на youtube ставишь видео на скорость x2
>>38230
Не про анимацию идёт речь, это все кастомизация текста. Я про его скип!
Если ты смог это с нуля сделать, то добавить кнопку пролистывания текста на x2 тебе будет легко создать.
>>38215
>История диалога? Как предположил анон выше? В диалоджике есть.
Это не история диалога, а быстрое его перелистывание. По сути пропуск. По другому это можно объяснить когда ты на youtube ставишь видео на скорость x2
>>38230
Не про анимацию идёт речь, это все кастомизация текста. Я про его скип!
>>38305
Ну 4ку даже после релиза еще года 2 полировать будут
Ну 4ку даже после релиза еще года 2 полировать будут
>>38348
Зион с али.
Зион с али.
Посмотрел я этот ваш диалоджик. Писец он перегружен. Как же я рад, что не знал про него и написал свою систему.
>>38258
Ты мне, что, предлагаешь тебе диалоговую систему написать, что ли?
>Если ты смог это с нуля сделать, то добавить кнопку пролистывания текста на x2 тебе будет легко создать.
Ты мне, что, предлагаешь тебе диалоговую систему написать, что ли?
>>38367
Говорю если захочешь добавить к себе эту функцию.
Говорю если захочешь добавить к себе эту функцию.
Пытаюсь подключить кириллицу, не получается.
Вроде все делаю, как в видосе
https://www.youtube.com/watch?v=jbJp84jHei0&t=86s
Ни фига.
Знаки препинания показываются, как и латиница
Вроде все делаю, как в видосе
https://www.youtube.com/watch?v=jbJp84jHei0&t=86s
Ни фига.
Знаки препинания показываются, как и латиница
13 Кб, 544x158>>38402
Еще твоя проблема может быть в том, что в годоте нет темы по умолчанию.
Т.е. ты должен указать всем своим контролам тему.
Хорошая новость в том, что тема распространяется каскадно.
На пике тема задана контролу, поэтому распространяется на Label3 и 4.
Еще твоя проблема может быть в том, что в годоте нет темы по умолчанию.
Т.е. ты должен указать всем своим контролам тему.
Хорошая новость в том, что тема распространяется каскадно.
На пике тема задана контролу, поэтому распространяется на Label3 и 4.
>>38402
Не смотри уроки на русском лучше. В англоязычных туторов то дрянь частенько, а в таких...
Не смотри уроки на русском лучше. В англоязычных туторов то дрянь частенько, а в таких...
2,7 Мб, 1920x1080>>38271
К декабрю 25-го
К декабрю 25-го
Сделал систему перемещения, как в этом ролике.
https://www.youtube.com/watch?v=-4jEXTwTsVI
10:03 и далее. У чувака ход персонажа плавный, он нажимает на кнопку и не отпускает, персонаж движется. У меня нужно нажимать каждый раз на кнопку, чтобы персонаж сдвинулся на шаг. ВТФ?
Код абсолютно такой же, делал все так же.
https://www.youtube.com/watch?v=-4jEXTwTsVI
10:03 и далее. У чувака ход персонажа плавный, он нажимает на кнопку и не отпускает, персонаж движется. У меня нужно нажимать каждый раз на кнопку, чтобы персонаж сдвинулся на шаг. ВТФ?
Код абсолютно такой же, делал все так же.
Оказывается писать код проще чем рисовать спрайты.
>>38472
Вместо read_input() еще попробуй _input() и сотри _physical_process. Должно работать.
Вместо read_input() еще попробуй _input() и сотри _physical_process. Должно работать.
Годаны!
Подсмотрел сейчас на ютубе любопытную игровую механику. Как считаете, как она реализована? Короче игра в тридэ от третьего лица, персонаж перемещается по движущимся платформам, с края платформы персонаж не может упасть, упирается в невидимую стену, если следующая платформа улетела слишком далеко - возникает эта невидимая стена, и персонаж не может просто так взять и свалиться. Нужно ждать, пока платформа прилетит поближе.
Под спойлером мой вариант реализации:
Перс движется только в рамках навигационного шейпа, платформы содержат чанки этого шейпа и когда они близко - движение разрешено. Иначе - навигации просто нет, перс просто упирается в пустоту.
Подсмотрел сейчас на ютубе любопытную игровую механику. Как считаете, как она реализована? Короче игра в тридэ от третьего лица, персонаж перемещается по движущимся платформам, с края платформы персонаж не может упасть, упирается в невидимую стену, если следующая платформа улетела слишком далеко - возникает эта невидимая стена, и персонаж не может просто так взять и свалиться. Нужно ждать, пока платформа прилетит поближе.
Под спойлером мой вариант реализации:
Перс движется только в рамках навигационного шейпа, платформы содержат чанки этого шейпа и когда они близко - движение разрешено. Иначе - навигации просто нет, перс просто упирается в пустоту.
948 Кб, 600x338>>38559
Ну например коллайдер, который включается, если платформы далеко, это если прямое управление.
Можно еще делать рейкаст (в том числе в невидимый барьер), и если там препятствие - игнорировать управление, тогда персонаж не будет упираться шагая в невидимую стенку.
Еще у move_and_collide есть флаг test_only, не придумал как точно использовать, но смысл в том, что сначала делаешь попытку движения, и потом делаешь по настоящему только, если условия соблюдены.
Навигация это скорее если ты кликаешь и персонаж как в РТС туда идет.
Емнип там из коробки так и будет, если они не рядом (пик из статьи про 4-ку, но в 3.5 тоже этот навсервер https://godotengine.org/article/navigation-server-godot-4-0 )
Ну например коллайдер, который включается, если платформы далеко, это если прямое управление.
Можно еще делать рейкаст (в том числе в невидимый барьер), и если там препятствие - игнорировать управление, тогда персонаж не будет упираться шагая в невидимую стенку.
Еще у move_and_collide есть флаг test_only, не придумал как точно использовать, но смысл в том, что сначала делаешь попытку движения, и потом делаешь по настоящему только, если условия соблюдены.
Навигация это скорее если ты кликаешь и персонаж как в РТС туда идет.
Емнип там из коробки так и будет, если они не рядом (пик из статьи про 4-ку, но в 3.5 тоже этот навсервер https://godotengine.org/article/navigation-server-godot-4-0 )
>>38143
Ха-ха, ещё чего! Обойдутся, никому свою игру не дам, буду играть сам. Шучу.
99.(9)% игр на той же юнити НЕПРИЯТНЫ из-за низкого качества и багов.
Нет, свои проекты я всегда тестирую и исправляю все баги, которые найду, если успею раньше, чем потеряю силы и/или интерес из-за очередного навалившегося депрессивного эпизода (с суицидальными мыслями и т.д., я не симулирую). Правда, большинство проектов я забрасываю из-за этой депрессии и ни до чего не довожу. Единственная моя программа, которой я ежедневно пользуюсь, написана на Pascal в 2019, а последняя её версия - весной 2021, т.е. мне даже её нет сил/мотивации обновлять - работает и ладно. Но если бы у меня были силы и мотивация сделать и релизнуть игру, я бы постарался сделать её очень надёжной (насколько это возможно на чужом движке, пусть даже опенсурсном, и с таким-то зоопарком железа на ПК).
У юнити тоже есть баг-трекер, открытых иссуев на котором намного больше, чем у Годо. Разница в том, что траекторию развития Юнити определяет Юнити Технолоджис, а траекторию развития Годо во многом определяет обсуждение пользователей на гитхабе, пусть даже финальное слово остаётся за ключевыми разработчиками (ой, ладно тебе, они вложили много сил и времени = имеют право, если не согласен - делай форк, никто не запрещает). Кроме того, ты и сам можешь помочь пофиксить баги в Годо, если захочешь, а в Юнити ты ничего не пофиксишь, даже если очень захочешь (устроившись на работу в Юнити, ты будешь фиксить то, что тебе скажут, это очевидно).
Более того, большую роль играет то, от каких именно багов страдает тот или иной движок. По моему опыту взаимодействия с Юнити и чтению постов на её официальном форуме у меня сложилось впечатление, что Юнити страдает от критических для разработки игр багов, падая и ломая проекты на ровном месте. Конечно, Годо тоже страдает от некоторых багов, но, опять же по моему опыту и чтению отзывов, большинство его стабильных версий реально стабильны и не страдают от критических багов, т.е. их можно спокойно использовать и в большинстве случаев не испытывать проблем.
Понимаешь, когда движок ломается при попытке сделать тривиальное действие, и ты вынужден искать помощи в интернете или качать другую версию, никакие тысячи туториалов и бесплатных ассетов не удержат тебя на этом движке, если тебя не заставляют работать на нём на галере. С Годо тоже бывают проблемы, но они другого плана - чаще всего просто нет встроенного высокоуровневого функционала для какой-то моей специфической задумки, приходится искать аддоны или делать самому, используя низкоуровневые АПИ. Но я ж движкопися изначально, мне не страшно пилить всё с нуля, наоборот, я долго сопротивлялся брать готовый движок (не важно, какой), ибо это "не труъ" и ты не чувствуешь, что реально что-то создаёшь сам, а не тупо жмёшь кнопку "сделать хорошо". Серьёзно, готовый движок выглядит так, будто за тебя всё уже сделали и ты как бы и не нужен вообще...
Лол, забил на все свои идеи, связанные с сетью, много лет назад. Не из-за необходимости поддерживать сервер и работать техподдержкой, а из-за того, что набрать аудиторию до играбельной массы (сотни, а то и тысячи тел 24/7, а суммарно десятки тысяч регулярно играющих, не считая тех, кто поиграл и бросил) крайне тяжело, а потом ещё тяжелее сделать игру честной и справедливой (по-моему, это невозможно, если в игре больше одного игрока)... Нет уж, лучше одиночные игры.
Это возможно только в ситуации, когда мастер-сервер упал или по какой-то сетевой причине стал недоступен. В первом случае достаточно его перезапустить, во второй ничего не поделать, особенно в нынешнее время (РКН ломает интернет). Думаю, первую ситуацию можно автоматизировать, т.е. чтобы сервер поднимался автоматически в случае ошибки со стороны хостинг-провайдера. А во второй и любой другой ситуации просто закрепить в чате объявление о проблемах, которые от меня не зависят. Кроме того, раз уж ты говоришь, что у меня есть дискорд игры, то у меня есть и модераторы, которые по очереди дежурят в чате и успокаивают игроков.
В любом случае, это всё не относится к поиску багов в коде автотестами. Ты не можешь протестировать машину провайдера и качество сети, которое, к тому же, может меняться со временем совершенно без твоего ведома. Даже если у тебя сервер стоит прямо под столом в спальне, ты не имеешь полной власти над сетевым каналом, и никакой код на твоём сервере эту проблему не решит.
Что-то не вижу в C# begin и end (end if, end for, end while, end function, end class, end program, end unit и прочее подобное для максимального удобства чтения кода). Видимо, эта твоя "куча сахара" недостаточно полна.
Существуют языки, которые ты можешь адаптировать под себя, добавив абсолютно любые фишки из любых языков, при этом не вмешиваясь в компилятор (внезапно, да?)... Но куда тебе до такого, ты предпочитаешь использовать то, что любезно предложили навязали корпорации.
Ага, движок без багов сделать сложно, но ты требуешь делать игру без багов... На движке с багами! Да ещё критическими, так что тривиальные вещи сделать нельзя. Ну протестируешь ты свой код вдоль и поперёк, а потом узнаешь, что в юнити есть баг, ломающий твою игру, и который не могут пофиксить вот уже много лет, или фикс есть в версии, которая имеет другой баг, ломающий твою игру. Вот веселье-то, вылизывать код, который не заработает как тебе хочется из-за движка от третьих лиц.
Класс, инкапсулирующий персонажей и их действия.
Класс, инкапсулирующий реплики персонажей (вид действия).
Класс, инкапсулирующий сцены и различные эффекты сцен.
Класс, управляющий ходом сюжета - действиями и репликами персонажей на сценах.
Класс, загружающий все данные и создающий все необходимые экземпляры этих классов.
Дальше обмазать всё это нодами, которые позволят увидеть на экране результат работы класса, управляющего ходом сюжета. Ну или как-то так. Я не так давно снова собирался запилить такую систему с нуля, но, как обычно, потерял интерес и забил, ведь игру на этой системе я всё равно не буду делать. Меня почти не интересуют заскриптованные сюжеты, даже с развилками...
Конечно, это всё можно абстрагировать от движка и написать на любом ЯП. Но в своей основе это очень минималистичная система, которая не займёт так уж много места. При необходимости её будет несложно переписать на любой другой ЯП. Тем более что в программировании самое сложное - создать систему, а транслировать на другой ЯП уже имеющуюся систему обычно не так уж сложно. Я переписывал код с языка на язык, как чужой, так и личный, так что прекрасно знаю, что говорю: вся сложность программирования лежит в разработке архитектуры в уме, а не в написании кода. Готовую систему можно вообще автоматически с языка на язык транслировать, даже без нейронок (этим занимаются транспиляторы, как вид компилятора).
Я согласен, что можно абстрагировать "ядро" и тестировать отдельно, но всё же это сложно (в контексте игр, где большая часть вещей визуальна и ожидает непредсказуемый ввод пользователя), и потом может оказаться, что твои слои абстракций толще самого "ядра", да так, что вся система страдает из-за количества абстракций. Я несколько раз пробовал писать движок с нуля, в частности, обмазываясь абстракциями со всех сторон, так что знаю, что говорю.
Вообще, любая модульная система страдает из-за необходимости тратить ресурсы на соединительные узлы. Нагляднее всего это видно на ИРЛ конструкторах, которые вынуждены тратить избыточное количество материала и/или пространства на соединительные узлы. Да, модульность очень удобна, но она никогда не обходится без жертв. Особенно если ты вынужден делать отдельный соединительный узел под разные платформы (движки). И чем универсальнее модули, тем выше расходы на узлы.
>Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры.
Ха-ха, ещё чего! Обойдутся, никому свою игру не дам, буду играть сам. Шучу.
>И если ты не заботишься от качестве - этим людям неприятно.
99.(9)% игр на той же юнити НЕПРИЯТНЫ из-за низкого качества и багов.
>ты походу вообще считаешь всё это бесполезным
Нет, свои проекты я всегда тестирую и исправляю все баги, которые найду, если успею раньше, чем потеряю силы и/или интерес из-за очередного навалившегося депрессивного эпизода (с суицидальными мыслями и т.д., я не симулирую). Правда, большинство проектов я забрасываю из-за этой депрессии и ни до чего не довожу. Единственная моя программа, которой я ежедневно пользуюсь, написана на Pascal в 2019, а последняя её версия - весной 2021, т.е. мне даже её нет сил/мотивации обновлять - работает и ладно. Но если бы у меня были силы и мотивация сделать и релизнуть игру, я бы постарался сделать её очень надёжной (насколько это возможно на чужом движке, пусть даже опенсурсном, и с таким-то зоопарком железа на ПК).
>движка, у которого несколько тысяч открытых issue на гитхабе
У юнити тоже есть баг-трекер, открытых иссуев на котором намного больше, чем у Годо. Разница в том, что траекторию развития Юнити определяет Юнити Технолоджис, а траекторию развития Годо во многом определяет обсуждение пользователей на гитхабе, пусть даже финальное слово остаётся за ключевыми разработчиками (ой, ладно тебе, они вложили много сил и времени = имеют право, если не согласен - делай форк, никто не запрещает). Кроме того, ты и сам можешь помочь пофиксить баги в Годо, если захочешь, а в Юнити ты ничего не пофиксишь, даже если очень захочешь (устроившись на работу в Юнити, ты будешь фиксить то, что тебе скажут, это очевидно).
Более того, большую роль играет то, от каких именно багов страдает тот или иной движок. По моему опыту взаимодействия с Юнити и чтению постов на её официальном форуме у меня сложилось впечатление, что Юнити страдает от критических для разработки игр багов, падая и ломая проекты на ровном месте. Конечно, Годо тоже страдает от некоторых багов, но, опять же по моему опыту и чтению отзывов, большинство его стабильных версий реально стабильны и не страдают от критических багов, т.е. их можно спокойно использовать и в большинстве случаев не испытывать проблем.
Понимаешь, когда движок ломается при попытке сделать тривиальное действие, и ты вынужден искать помощи в интернете или качать другую версию, никакие тысячи туториалов и бесплатных ассетов не удержат тебя на этом движке, если тебя не заставляют работать на нём на галере. С Годо тоже бывают проблемы, но они другого плана - чаще всего просто нет встроенного высокоуровневого функционала для какой-то моей специфической задумки, приходится искать аддоны или делать самому, используя низкоуровневые АПИ. Но я ж движкопися изначально, мне не страшно пилить всё с нуля, наоборот, я долго сопротивлялся брать готовый движок (не важно, какой), ибо это "не труъ" и ты не чувствуешь, что реально что-то создаёшь сам, а не тупо жмёшь кнопку "сделать хорошо". Серьёзно, готовый движок выглядит так, будто за тебя всё уже сделали и ты как бы и не нужен вообще...
>Если ты пилишь небольшую сетевую игру
Лол, забил на все свои идеи, связанные с сетью, много лет назад. Не из-за необходимости поддерживать сервер и работать техподдержкой, а из-за того, что набрать аудиторию до играбельной массы (сотни, а то и тысячи тел 24/7, а суммарно десятки тысяч регулярно играющих, не считая тех, кто поиграл и бросил) крайне тяжело, а потом ещё тяжелее сделать игру честной и справедливой (по-моему, это невозможно, если в игре больше одного игрока)... Нет уж, лучше одиночные игры.
>юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает
Это возможно только в ситуации, когда мастер-сервер упал или по какой-то сетевой причине стал недоступен. В первом случае достаточно его перезапустить, во второй ничего не поделать, особенно в нынешнее время (РКН ломает интернет). Думаю, первую ситуацию можно автоматизировать, т.е. чтобы сервер поднимался автоматически в случае ошибки со стороны хостинг-провайдера. А во второй и любой другой ситуации просто закрепить в чате объявление о проблемах, которые от меня не зависят. Кроме того, раз уж ты говоришь, что у меня есть дискорд игры, то у меня есть и модераторы, которые по очереди дежурят в чате и успокаивают игроков.
В любом случае, это всё не относится к поиску багов в коде автотестами. Ты не можешь протестировать машину провайдера и качество сети, которое, к тому же, может меняться со временем совершенно без твоего ведома. Даже если у тебя сервер стоит прямо под столом в спальне, ты не имеешь полной власти над сетевым каналом, и никакой код на твоём сервере эту проблему не решит.
>кучу удобного синтаксического сахара
Что-то не вижу в C# begin и end (end if, end for, end while, end function, end class, end program, end unit и прочее подобное для максимального удобства чтения кода). Видимо, эта твоя "куча сахара" недостаточно полна.
>адаптировал фишки
Существуют языки, которые ты можешь адаптировать под себя, добавив абсолютно любые фишки из любых языков, при этом не вмешиваясь в компилятор (внезапно, да?)... Но куда тебе до такого, ты предпочитаешь использовать то, что любезно предложили навязали корпорации.
>Видимо это сложно.
Ага, движок без багов сделать сложно, но ты требуешь делать игру без багов... На движке с багами! Да ещё критическими, так что тривиальные вещи сделать нельзя. Ну протестируешь ты свой код вдоль и поперёк, а потом узнаешь, что в юнити есть баг, ломающий твою игру, и который не могут пофиксить вот уже много лет, или фикс есть в версии, которая имеет другой баг, ломающий твою игру. Вот веселье-то, вылизывать код, который не заработает как тебе хочется из-за движка от третьих лиц.
>Как бы ты написал хорошую систему диалогов для пользователей годота?
Класс, инкапсулирующий персонажей и их действия.
Класс, инкапсулирующий реплики персонажей (вид действия).
Класс, инкапсулирующий сцены и различные эффекты сцен.
Класс, управляющий ходом сюжета - действиями и репликами персонажей на сценах.
Класс, загружающий все данные и создающий все необходимые экземпляры этих классов.
Дальше обмазать всё это нодами, которые позволят увидеть на экране результат работы класса, управляющего ходом сюжета. Ну или как-то так. Я не так давно снова собирался запилить такую систему с нуля, но, как обычно, потерял интерес и забил, ведь игру на этой системе я всё равно не буду делать. Меня почти не интересуют заскриптованные сюжеты, даже с развилками...
Конечно, это всё можно абстрагировать от движка и написать на любом ЯП. Но в своей основе это очень минималистичная система, которая не займёт так уж много места. При необходимости её будет несложно переписать на любой другой ЯП. Тем более что в программировании самое сложное - создать систему, а транслировать на другой ЯП уже имеющуюся систему обычно не так уж сложно. Я переписывал код с языка на язык, как чужой, так и личный, так что прекрасно знаю, что говорю: вся сложность программирования лежит в разработке архитектуры в уме, а не в написании кода. Готовую систему можно вообще автоматически с языка на язык транслировать, даже без нейронок (этим занимаются транспиляторы, как вид компилятора).
>Ядро бы я 100% абстрагировал и тестировал отдельно.
Я согласен, что можно абстрагировать "ядро" и тестировать отдельно, но всё же это сложно (в контексте игр, где большая часть вещей визуальна и ожидает непредсказуемый ввод пользователя), и потом может оказаться, что твои слои абстракций толще самого "ядра", да так, что вся система страдает из-за количества абстракций. Я несколько раз пробовал писать движок с нуля, в частности, обмазываясь абстракциями со всех сторон, так что знаю, что говорю.
Вообще, любая модульная система страдает из-за необходимости тратить ресурсы на соединительные узлы. Нагляднее всего это видно на ИРЛ конструкторах, которые вынуждены тратить избыточное количество материала и/или пространства на соединительные узлы. Да, модульность очень удобна, но она никогда не обходится без жертв. Особенно если ты вынужден делать отдельный соединительный узел под разные платформы (движки). И чем универсальнее модули, тем выше расходы на узлы.
>>38143
Ха-ха, ещё чего! Обойдутся, никому свою игру не дам, буду играть сам. Шучу.
99.(9)% игр на той же юнити НЕПРИЯТНЫ из-за низкого качества и багов.
Нет, свои проекты я всегда тестирую и исправляю все баги, которые найду, если успею раньше, чем потеряю силы и/или интерес из-за очередного навалившегося депрессивного эпизода (с суицидальными мыслями и т.д., я не симулирую). Правда, большинство проектов я забрасываю из-за этой депрессии и ни до чего не довожу. Единственная моя программа, которой я ежедневно пользуюсь, написана на Pascal в 2019, а последняя её версия - весной 2021, т.е. мне даже её нет сил/мотивации обновлять - работает и ладно. Но если бы у меня были силы и мотивация сделать и релизнуть игру, я бы постарался сделать её очень надёжной (насколько это возможно на чужом движке, пусть даже опенсурсном, и с таким-то зоопарком железа на ПК).
У юнити тоже есть баг-трекер, открытых иссуев на котором намного больше, чем у Годо. Разница в том, что траекторию развития Юнити определяет Юнити Технолоджис, а траекторию развития Годо во многом определяет обсуждение пользователей на гитхабе, пусть даже финальное слово остаётся за ключевыми разработчиками (ой, ладно тебе, они вложили много сил и времени = имеют право, если не согласен - делай форк, никто не запрещает). Кроме того, ты и сам можешь помочь пофиксить баги в Годо, если захочешь, а в Юнити ты ничего не пофиксишь, даже если очень захочешь (устроившись на работу в Юнити, ты будешь фиксить то, что тебе скажут, это очевидно).
Более того, большую роль играет то, от каких именно багов страдает тот или иной движок. По моему опыту взаимодействия с Юнити и чтению постов на её официальном форуме у меня сложилось впечатление, что Юнити страдает от критических для разработки игр багов, падая и ломая проекты на ровном месте. Конечно, Годо тоже страдает от некоторых багов, но, опять же по моему опыту и чтению отзывов, большинство его стабильных версий реально стабильны и не страдают от критических багов, т.е. их можно спокойно использовать и в большинстве случаев не испытывать проблем.
Понимаешь, когда движок ломается при попытке сделать тривиальное действие, и ты вынужден искать помощи в интернете или качать другую версию, никакие тысячи туториалов и бесплатных ассетов не удержат тебя на этом движке, если тебя не заставляют работать на нём на галере. С Годо тоже бывают проблемы, но они другого плана - чаще всего просто нет встроенного высокоуровневого функционала для какой-то моей специфической задумки, приходится искать аддоны или делать самому, используя низкоуровневые АПИ. Но я ж движкопися изначально, мне не страшно пилить всё с нуля, наоборот, я долго сопротивлялся брать готовый движок (не важно, какой), ибо это "не труъ" и ты не чувствуешь, что реально что-то создаёшь сам, а не тупо жмёшь кнопку "сделать хорошо". Серьёзно, готовый движок выглядит так, будто за тебя всё уже сделали и ты как бы и не нужен вообще...
Лол, забил на все свои идеи, связанные с сетью, много лет назад. Не из-за необходимости поддерживать сервер и работать техподдержкой, а из-за того, что набрать аудиторию до играбельной массы (сотни, а то и тысячи тел 24/7, а суммарно десятки тысяч регулярно играющих, не считая тех, кто поиграл и бросил) крайне тяжело, а потом ещё тяжелее сделать игру честной и справедливой (по-моему, это невозможно, если в игре больше одного игрока)... Нет уж, лучше одиночные игры.
Это возможно только в ситуации, когда мастер-сервер упал или по какой-то сетевой причине стал недоступен. В первом случае достаточно его перезапустить, во второй ничего не поделать, особенно в нынешнее время (РКН ломает интернет). Думаю, первую ситуацию можно автоматизировать, т.е. чтобы сервер поднимался автоматически в случае ошибки со стороны хостинг-провайдера. А во второй и любой другой ситуации просто закрепить в чате объявление о проблемах, которые от меня не зависят. Кроме того, раз уж ты говоришь, что у меня есть дискорд игры, то у меня есть и модераторы, которые по очереди дежурят в чате и успокаивают игроков.
В любом случае, это всё не относится к поиску багов в коде автотестами. Ты не можешь протестировать машину провайдера и качество сети, которое, к тому же, может меняться со временем совершенно без твоего ведома. Даже если у тебя сервер стоит прямо под столом в спальне, ты не имеешь полной власти над сетевым каналом, и никакой код на твоём сервере эту проблему не решит.
Что-то не вижу в C# begin и end (end if, end for, end while, end function, end class, end program, end unit и прочее подобное для максимального удобства чтения кода). Видимо, эта твоя "куча сахара" недостаточно полна.
Существуют языки, которые ты можешь адаптировать под себя, добавив абсолютно любые фишки из любых языков, при этом не вмешиваясь в компилятор (внезапно, да?)... Но куда тебе до такого, ты предпочитаешь использовать то, что любезно предложили навязали корпорации.
Ага, движок без багов сделать сложно, но ты требуешь делать игру без багов... На движке с багами! Да ещё критическими, так что тривиальные вещи сделать нельзя. Ну протестируешь ты свой код вдоль и поперёк, а потом узнаешь, что в юнити есть баг, ломающий твою игру, и который не могут пофиксить вот уже много лет, или фикс есть в версии, которая имеет другой баг, ломающий твою игру. Вот веселье-то, вылизывать код, который не заработает как тебе хочется из-за движка от третьих лиц.
Класс, инкапсулирующий персонажей и их действия.
Класс, инкапсулирующий реплики персонажей (вид действия).
Класс, инкапсулирующий сцены и различные эффекты сцен.
Класс, управляющий ходом сюжета - действиями и репликами персонажей на сценах.
Класс, загружающий все данные и создающий все необходимые экземпляры этих классов.
Дальше обмазать всё это нодами, которые позволят увидеть на экране результат работы класса, управляющего ходом сюжета. Ну или как-то так. Я не так давно снова собирался запилить такую систему с нуля, но, как обычно, потерял интерес и забил, ведь игру на этой системе я всё равно не буду делать. Меня почти не интересуют заскриптованные сюжеты, даже с развилками...
Конечно, это всё можно абстрагировать от движка и написать на любом ЯП. Но в своей основе это очень минималистичная система, которая не займёт так уж много места. При необходимости её будет несложно переписать на любой другой ЯП. Тем более что в программировании самое сложное - создать систему, а транслировать на другой ЯП уже имеющуюся систему обычно не так уж сложно. Я переписывал код с языка на язык, как чужой, так и личный, так что прекрасно знаю, что говорю: вся сложность программирования лежит в разработке архитектуры в уме, а не в написании кода. Готовую систему можно вообще автоматически с языка на язык транслировать, даже без нейронок (этим занимаются транспиляторы, как вид компилятора).
Я согласен, что можно абстрагировать "ядро" и тестировать отдельно, но всё же это сложно (в контексте игр, где большая часть вещей визуальна и ожидает непредсказуемый ввод пользователя), и потом может оказаться, что твои слои абстракций толще самого "ядра", да так, что вся система страдает из-за количества абстракций. Я несколько раз пробовал писать движок с нуля, в частности, обмазываясь абстракциями со всех сторон, так что знаю, что говорю.
Вообще, любая модульная система страдает из-за необходимости тратить ресурсы на соединительные узлы. Нагляднее всего это видно на ИРЛ конструкторах, которые вынуждены тратить избыточное количество материала и/или пространства на соединительные узлы. Да, модульность очень удобна, но она никогда не обходится без жертв. Особенно если ты вынужден делать отдельный соединительный узел под разные платформы (движки). И чем универсальнее модули, тем выше расходы на узлы.
>Кроме разработки игр у тебя ещё есть люди, которые играют в эти игры.
Ха-ха, ещё чего! Обойдутся, никому свою игру не дам, буду играть сам. Шучу.
>И если ты не заботишься от качестве - этим людям неприятно.
99.(9)% игр на той же юнити НЕПРИЯТНЫ из-за низкого качества и багов.
>ты походу вообще считаешь всё это бесполезным
Нет, свои проекты я всегда тестирую и исправляю все баги, которые найду, если успею раньше, чем потеряю силы и/или интерес из-за очередного навалившегося депрессивного эпизода (с суицидальными мыслями и т.д., я не симулирую). Правда, большинство проектов я забрасываю из-за этой депрессии и ни до чего не довожу. Единственная моя программа, которой я ежедневно пользуюсь, написана на Pascal в 2019, а последняя её версия - весной 2021, т.е. мне даже её нет сил/мотивации обновлять - работает и ладно. Но если бы у меня были силы и мотивация сделать и релизнуть игру, я бы постарался сделать её очень надёжной (насколько это возможно на чужом движке, пусть даже опенсурсном, и с таким-то зоопарком железа на ПК).
>движка, у которого несколько тысяч открытых issue на гитхабе
У юнити тоже есть баг-трекер, открытых иссуев на котором намного больше, чем у Годо. Разница в том, что траекторию развития Юнити определяет Юнити Технолоджис, а траекторию развития Годо во многом определяет обсуждение пользователей на гитхабе, пусть даже финальное слово остаётся за ключевыми разработчиками (ой, ладно тебе, они вложили много сил и времени = имеют право, если не согласен - делай форк, никто не запрещает). Кроме того, ты и сам можешь помочь пофиксить баги в Годо, если захочешь, а в Юнити ты ничего не пофиксишь, даже если очень захочешь (устроившись на работу в Юнити, ты будешь фиксить то, что тебе скажут, это очевидно).
Более того, большую роль играет то, от каких именно багов страдает тот или иной движок. По моему опыту взаимодействия с Юнити и чтению постов на её официальном форуме у меня сложилось впечатление, что Юнити страдает от критических для разработки игр багов, падая и ломая проекты на ровном месте. Конечно, Годо тоже страдает от некоторых багов, но, опять же по моему опыту и чтению отзывов, большинство его стабильных версий реально стабильны и не страдают от критических багов, т.е. их можно спокойно использовать и в большинстве случаев не испытывать проблем.
Понимаешь, когда движок ломается при попытке сделать тривиальное действие, и ты вынужден искать помощи в интернете или качать другую версию, никакие тысячи туториалов и бесплатных ассетов не удержат тебя на этом движке, если тебя не заставляют работать на нём на галере. С Годо тоже бывают проблемы, но они другого плана - чаще всего просто нет встроенного высокоуровневого функционала для какой-то моей специфической задумки, приходится искать аддоны или делать самому, используя низкоуровневые АПИ. Но я ж движкопися изначально, мне не страшно пилить всё с нуля, наоборот, я долго сопротивлялся брать готовый движок (не важно, какой), ибо это "не труъ" и ты не чувствуешь, что реально что-то создаёшь сам, а не тупо жмёшь кнопку "сделать хорошо". Серьёзно, готовый движок выглядит так, будто за тебя всё уже сделали и ты как бы и не нужен вообще...
>Если ты пилишь небольшую сетевую игру
Лол, забил на все свои идеи, связанные с сетью, много лет назад. Не из-за необходимости поддерживать сервер и работать техподдержкой, а из-за того, что набрать аудиторию до играбельной массы (сотни, а то и тысячи тел 24/7, а суммарно десятки тысяч регулярно играющих, не считая тех, кто поиграл и бросил) крайне тяжело, а потом ещё тяжелее сделать игру честной и справедливой (по-моему, это невозможно, если в игре больше одного игрока)... Нет уж, лучше одиночные игры.
>юзеры тебе в дискорд начинают спамить в 12 ночи что у тебя лобби не работает
Это возможно только в ситуации, когда мастер-сервер упал или по какой-то сетевой причине стал недоступен. В первом случае достаточно его перезапустить, во второй ничего не поделать, особенно в нынешнее время (РКН ломает интернет). Думаю, первую ситуацию можно автоматизировать, т.е. чтобы сервер поднимался автоматически в случае ошибки со стороны хостинг-провайдера. А во второй и любой другой ситуации просто закрепить в чате объявление о проблемах, которые от меня не зависят. Кроме того, раз уж ты говоришь, что у меня есть дискорд игры, то у меня есть и модераторы, которые по очереди дежурят в чате и успокаивают игроков.
В любом случае, это всё не относится к поиску багов в коде автотестами. Ты не можешь протестировать машину провайдера и качество сети, которое, к тому же, может меняться со временем совершенно без твоего ведома. Даже если у тебя сервер стоит прямо под столом в спальне, ты не имеешь полной власти над сетевым каналом, и никакой код на твоём сервере эту проблему не решит.
>кучу удобного синтаксического сахара
Что-то не вижу в C# begin и end (end if, end for, end while, end function, end class, end program, end unit и прочее подобное для максимального удобства чтения кода). Видимо, эта твоя "куча сахара" недостаточно полна.
>адаптировал фишки
Существуют языки, которые ты можешь адаптировать под себя, добавив абсолютно любые фишки из любых языков, при этом не вмешиваясь в компилятор (внезапно, да?)... Но куда тебе до такого, ты предпочитаешь использовать то, что любезно предложили навязали корпорации.
>Видимо это сложно.
Ага, движок без багов сделать сложно, но ты требуешь делать игру без багов... На движке с багами! Да ещё критическими, так что тривиальные вещи сделать нельзя. Ну протестируешь ты свой код вдоль и поперёк, а потом узнаешь, что в юнити есть баг, ломающий твою игру, и который не могут пофиксить вот уже много лет, или фикс есть в версии, которая имеет другой баг, ломающий твою игру. Вот веселье-то, вылизывать код, который не заработает как тебе хочется из-за движка от третьих лиц.
>Как бы ты написал хорошую систему диалогов для пользователей годота?
Класс, инкапсулирующий персонажей и их действия.
Класс, инкапсулирующий реплики персонажей (вид действия).
Класс, инкапсулирующий сцены и различные эффекты сцен.
Класс, управляющий ходом сюжета - действиями и репликами персонажей на сценах.
Класс, загружающий все данные и создающий все необходимые экземпляры этих классов.
Дальше обмазать всё это нодами, которые позволят увидеть на экране результат работы класса, управляющего ходом сюжета. Ну или как-то так. Я не так давно снова собирался запилить такую систему с нуля, но, как обычно, потерял интерес и забил, ведь игру на этой системе я всё равно не буду делать. Меня почти не интересуют заскриптованные сюжеты, даже с развилками...
Конечно, это всё можно абстрагировать от движка и написать на любом ЯП. Но в своей основе это очень минималистичная система, которая не займёт так уж много места. При необходимости её будет несложно переписать на любой другой ЯП. Тем более что в программировании самое сложное - создать систему, а транслировать на другой ЯП уже имеющуюся систему обычно не так уж сложно. Я переписывал код с языка на язык, как чужой, так и личный, так что прекрасно знаю, что говорю: вся сложность программирования лежит в разработке архитектуры в уме, а не в написании кода. Готовую систему можно вообще автоматически с языка на язык транслировать, даже без нейронок (этим занимаются транспиляторы, как вид компилятора).
>Ядро бы я 100% абстрагировал и тестировал отдельно.
Я согласен, что можно абстрагировать "ядро" и тестировать отдельно, но всё же это сложно (в контексте игр, где большая часть вещей визуальна и ожидает непредсказуемый ввод пользователя), и потом может оказаться, что твои слои абстракций толще самого "ядра", да так, что вся система страдает из-за количества абстракций. Я несколько раз пробовал писать движок с нуля, в частности, обмазываясь абстракциями со всех сторон, так что знаю, что говорю.
Вообще, любая модульная система страдает из-за необходимости тратить ресурсы на соединительные узлы. Нагляднее всего это видно на ИРЛ конструкторах, которые вынуждены тратить избыточное количество материала и/или пространства на соединительные узлы. Да, модульность очень удобна, но она никогда не обходится без жертв. Особенно если ты вынужден делать отдельный соединительный узел под разные платформы (движки). И чем универсальнее модули, тем выше расходы на узлы.
9 Кб, 694x222>>38407
Вообще-то есть. Её можно перезаписать (пикрил), но она есть. По-моему, можно даже создать копию этой стандартной темы через редактор тем, т.е. чтобы использовать стандартную тему за основу своей.
Не должен, если тебе достаточно одной темы. Ты можешь создать тему и присвоить её параметру настроек проекта. Если же тебе кастомная тема не нужна, а только кастомный шрифт, то достаточно указать параметр шрифта по умолчанию - там же, где и кастомная тема.
>что в годоте нет темы по умолчанию
Вообще-то есть. Её можно перезаписать (пикрил), но она есть. По-моему, можно даже создать копию этой стандартной темы через редактор тем, т.е. чтобы использовать стандартную тему за основу своей.
>ты должен указать всем своим контролам тему
Не должен, если тебе достаточно одной темы. Ты можешь создать тему и присвоить её параметру настроек проекта. Если же тебе кастомная тема не нужна, а только кастомный шрифт, то достаточно указать параметр шрифта по умолчанию - там же, где и кастомная тема.
27 Кб, 525x350>>38559
>>38564
Нет никакой "невидимой стены", всё обман!
Вот как вы думаете, как маленький настольный робот может аккуратно объезжать край стола, не сваливаясь с него? А он может! И нет, не с помощью сложных нейронок на суперкомпьютере, а простым алгоритмом на микроконтроллере из Lego Mindstorm.
Это ведь элементарно. Тестируете рейкастом (а.к.а. датчик глубины, ИРЛ он испускает невидимый человеческому глазу инфракрасный луч, т.е. принцип тот же, что и у рейкаста), есть ли опора перед персонажем - если есть, делаем шаг, если нет - значит, там обрыв и туда идти нельзя. Никакие невидимые стены не нужны и ничего переключать не нужно, подъехавшая мобильная платформа будет достаточной опорой для ног, чтобы рейкаст сообщил "можно идти".
>с края платформы персонаж не может упасть, упирается в невидимую стену
>>38564
>Можно еще делать рейкаст (в том числе в невидимый барьер), и если там препятствие - игнорировать управление, тогда персонаж не будет упираться шагая в невидимую стенку.
Нет никакой "невидимой стены", всё обман!
Вот как вы думаете, как маленький настольный робот может аккуратно объезжать край стола, не сваливаясь с него? А он может! И нет, не с помощью сложных нейронок на суперкомпьютере, а простым алгоритмом на микроконтроллере из Lego Mindstorm.
Это ведь элементарно. Тестируете рейкастом (а.к.а. датчик глубины, ИРЛ он испускает невидимый человеческому глазу инфракрасный луч, т.е. принцип тот же, что и у рейкаста), есть ли опора перед персонажем - если есть, делаем шаг, если нет - значит, там обрыв и туда идти нельзя. Никакие невидимые стены не нужны и ничего переключать не нужно, подъехавшая мобильная платформа будет достаточной опорой для ног, чтобы рейкаст сообщил "можно идти".
>>38580
Да, ты прав, я что-то перепутал и думал это только для редактора тема.
Да, ты прав, я что-то перепутал и думал это только для редактора тема.
>>38582
Мне невидимая стена видится надежнее, так как она имеет определенный объем и луч не промахнется, в случае же с террейном могут быть ложные показания, из-за кочек или расщелин.
Мне невидимая стена видится надежнее, так как она имеет определенный объем и луч не промахнется, в случае же с террейном могут быть ложные показания, из-за кочек или расщелин.
>>38585
Какие кочки и расщелины в платформере от третьего лица, лол? Пол плоский, точка.
Но если тебе нужно прям универсальное решение, тогда потребуются несколько лучей, либо "луч" в форме цилиндра, и достаточной длины, чтобы точно проверить высоту до дна (если оно есть).
В любом случае это лучше, чем обставлять всё вокруг невидимыми стенами и потом ещё их переключать по какой-то схеме, которая зависит от положения игрока и кучи подвижных платформ...
>в случае же с террейном могут быть ложные показания, из-за кочек или расщелин
Какие кочки и расщелины в платформере от третьего лица, лол? Пол плоский, точка.
Но если тебе нужно прям универсальное решение, тогда потребуются несколько лучей, либо "луч" в форме цилиндра, и достаточной длины, чтобы точно проверить высоту до дна (если оно есть).
В любом случае это лучше, чем обставлять всё вокруг невидимыми стенами и потом ещё их переключать по какой-то схеме, которая зависит от положения игрока и кучи подвижных платформ...
Можете подсказать какой-нибудь нормальный туториал по поиску пути с помощью навигационного сервера? По узлу Navigation2D уроков много, но он считается устаревшим, а по серверу только какие-то странные вещи, которые сами используют Navigation2D вместе с сервером У GDQuest, например
>>38630
Дверь - это затычка для дырки в стене, которую игрок видит.
А невидимые стены, которые тут обсуждались, придётся расставить вокруг всех краёв всех платформ, по которым двигается игрок, иначе он будет падать. Какие-то стены будут статичными, какие-то как двери - открываться и закрываться. Но проблема в том, что их будет МНОГО, они НЕВИДИМЫЕ, и их нужно ВРУЧНУЮ РАССТАВЛЯТЬ, а потом ещё проверять, действительно ли ты заткнул все невидимые дырки в невидимых стенах или нет. Можно, конечно, сделать эти невидимые стены видимыми на этапе планирования сцены, но это всё равно много возни впустую над каждой сценой. А универсальный алгоритм с рейкастом будет работать на любой, даже неподготовленной сцене.
>>38704
Это который в 4.0 добавили? Я думаю, лучше подождать релиза четвёрки. Какой смысл делать туториал на версию движка, которая может измениться к релизу? Даже несмотря на то, что она уже в бете и "feature freeze", это не гарантирует, что вот прям абсолютно точно ничего не изменится.
>Это ничем не хуже "двери" которая вкл или выкл.
Дверь - это затычка для дырки в стене, которую игрок видит.
А невидимые стены, которые тут обсуждались, придётся расставить вокруг всех краёв всех платформ, по которым двигается игрок, иначе он будет падать. Какие-то стены будут статичными, какие-то как двери - открываться и закрываться. Но проблема в том, что их будет МНОГО, они НЕВИДИМЫЕ, и их нужно ВРУЧНУЮ РАССТАВЛЯТЬ, а потом ещё проверять, действительно ли ты заткнул все невидимые дырки в невидимых стенах или нет. Можно, конечно, сделать эти невидимые стены видимыми на этапе планирования сцены, но это всё равно много возни впустую над каждой сценой. А универсальный алгоритм с рейкастом будет работать на любой, даже неподготовленной сцене.
>>38704
>по поиску пути с помощью навигационного сервера
Это который в 4.0 добавили? Я думаю, лучше подождать релиза четвёрки. Какой смысл делать туториал на версию движка, которая может измениться к релизу? Даже несмотря на то, что она уже в бете и "feature freeze", это не гарантирует, что вот прям абсолютно точно ничего не изменится.
>>38727
Я на 3.5 сижу и там Сервер, а когда пытаешься использовать Navigation2D движок ругается, что я использую устаревший мусор.
Но я уже начал потихоньку разбираться. Уже заставил двигаться по тайлам персонажа, но не понимаю, как добавить обход препятствий.
>Это который в 4.0 добавили?
Я на 3.5 сижу и там Сервер, а когда пытаешься использовать Navigation2D движок ругается, что я использую устаревший мусор.
Но я уже начал потихоньку разбираться. Уже заставил двигаться по тайлам персонажа, но не понимаю, как добавить обход препятствий.
>>38704
Делал по описанию, в блоге, заработало
https://godotengine.org/article/navigation-server-godot-4-0
Кто-то выкладывал демку
https://godotengine.org/asset-library/asset/1427
Но честно говоря это сырая штука, которая требует каких-то странных костылей
https://github.com/godotengine/godot/issues/60546
Делал по описанию, в блоге, заработало
https://godotengine.org/article/navigation-server-godot-4-0
Кто-то выкладывал демку
https://godotengine.org/asset-library/asset/1427
Но честно говоря это сырая штука, которая требует каких-то странных костылей
https://github.com/godotengine/godot/issues/60546
>>38727
Я написал "дверь" в кавычках, знаешь, как бывает в играх когда нельзя подойти к сундуку или выходу, пока босса не убил.
Не нужно, зачем сразу начинать с выдумок? Если у тебя, скажем, шестиугольные платформы - автоматически генеришь шесть стен по периметру.
А это как раз проще, потому что, как я писал у стены есть объем, и они будут перекрывать друг друга, исключая дыры - а вот как ты собираешься проверять и доказывать, что твой луч правильно работает во всех возможных положениях, ракурсах и углах поворота - я хз даже.
>Дверь - это затычка для дырки в стене, которую игрок видит.
Я написал "дверь" в кавычках, знаешь, как бывает в играх когда нельзя подойти к сундуку или выходу, пока босса не убил.
>нужно ВРУЧНУЮ РАССТАВЛЯТЬ
Не нужно, зачем сразу начинать с выдумок? Если у тебя, скажем, шестиугольные платформы - автоматически генеришь шесть стен по периметру.
> потом ещё проверять, действительно ли ты заткнул все невидимые дырки в невидимых стенах или нет.
А это как раз проще, потому что, как я писал у стены есть объем, и они будут перекрывать друг друга, исключая дыры - а вот как ты собираешься проверять и доказывать, что твой луч правильно работает во всех возможных положениях, ракурсах и углах поворота - я хз даже.
>>38741
Это ж для 3д. Наверное в 2д по другому надо
Я её смотрел. Она кривая пипец. Все дергается, застревает и вообще пипец какой-то.
А вот это не видел. Посмотю
А что все таки делать, если штука сырая?
Единственное, что мне приходит в голову это написать A* и работать с помощью него
>https://godotengine.org/article/navigation-server-godot-4-0
Это ж для 3д. Наверное в 2д по другому надо
Я её смотрел. Она кривая пипец. Все дергается, застревает и вообще пипец какой-то.
А вот это не видел. Посмотю
А что все таки делать, если штука сырая?
Единственное, что мне приходит в голову это написать A* и работать с помощью него
>>38747
Нет, там тоже самое будет. В Гоноре как раз использовал, но глючит.
Просто я тоже с этой проблемой сразу столкнулся, но не разобрался еще.
Суть в том, что навигация не учитывает радиус агента и он идет по "кромке" стены. Что конечно приводит к застреванию в коллайдеры. Это можно исправить в простых случаях, но общего я пока не придумал.
Да вот тоже подумываю над этим путем.
Могу еще из своей игры выложить демку.
>Наверное в 2д по другому надо
Нет, там тоже самое будет. В Гоноре как раз использовал, но глючит.
>на проблему человек жалуется..
Просто я тоже с этой проблемой сразу столкнулся, но не разобрался еще.
Суть в том, что навигация не учитывает радиус агента и он идет по "кромке" стены. Что конечно приводит к застреванию в коллайдеры. Это можно исправить в простых случаях, но общего я пока не придумал.
> приходит в голову это написать A* и работать с помощью него
Да вот тоже подумываю над этим путем.
Могу еще из своей игры выложить демку.
>>38755
Хорошо, тогда надо посмотреть.
У меня сейчас единственная проблема в том, что я не понимаю, как настроить препятствия из ноды Area2D. Хотя, скорее всего, в будущем я тоже столкнусь с проблемой, как у тебя
Было бы неплохо
>Нет, там тоже самое будет.
Хорошо, тогда надо посмотреть.
>Просто я тоже с этой проблемой сразу столкнулся, но не разобрался еще.
У меня сейчас единственная проблема в том, что я не понимаю, как настроить препятствия из ноды Area2D. Хотя, скорее всего, в будущем я тоже столкнусь с проблемой, как у тебя
>Могу еще из своей игры выложить демку.
Было бы неплохо
>>33955 (OP)
А нет простого способа сгенерировать CollisionShape из CSG-нод?
Я знаю, что можно нажать галочку "use collision", но это создаёт статичный объект.
Я знаю, что можно экспортировать в .obj, затем импортировать и нажать "generate collision shape".
Но вот простого способа сразу получить CollisionShape из CSG-ноды не вижу. Может, я что-то упускаю?
А нет простого способа сгенерировать CollisionShape из CSG-нод?
Я знаю, что можно нажать галочку "use collision", но это создаёт статичный объект.
Я знаю, что можно экспортировать в .obj, затем импортировать и нажать "generate collision shape".
Но вот простого способа сразу получить CollisionShape из CSG-ноды не вижу. Может, я что-то упускаю?
>>38817
Нормально работает или как навигация и сохранения с использованием Resources?
Нормально работает или как навигация и сохранения с использованием Resources?
Я все таки решился попробовать поработать с Navigation2D,но с ним тоже вылезла проблема. Как использовать NavigationObstacle2D для создания препятствий? Я в _ready пихаю nav_obstacle.set_navigation(levelNavigation), но это не работает
nav_obstacle - NavigationObstacle2D на ноде
levelNavigation - Navigation2D
nav_obstacle - NavigationObstacle2D на ноде
levelNavigation - Navigation2D
>>38736
Препятствия должны вырезать дырку в навмеше. После своих перемещений (если препятствия движущиеся) они посылают серверу сигнал повторить запекание навмеша. Дальше сам.
>>38564
Не только. Я давно над этим размышляю, да всё руки не доходят набросать прототип (в тридэ, в двадэ делал много лет назад, и даже что-то получалось). Идея в том, что движущийся анимированный персонаж двигается всегда с одной скоростью и с накладываемыми анимацией ограничениями, то есть, например, если персонаж бежит вперёд и тут навстречу враги, он не может мгновенно развернуться и бежать обратно. Сначала он тормозит, потом перетаптывается разворачиваясь, потом разбегается. Снова.
Учитывая это, возникла идея не привязывать нажатия кнопок к вектору движения напрямую, как этому учат в большинстве туториалов, а привязать нажатия кнопок к активации движения по навмешу. Ты прожал "вперёд" и у персонажа появилась точка перед ним, к которой он должен идти. И он сообразно своей внутренней логике переключает свою внутреннюю стейтмашину, чтобы отобразить анимации движения. Пока ты держишь кнопку, контроллер просто добавляет ещё одну точку в маршрут, если предыдущая достигнута, либо ждёт. Однако, как показывает гифка здесь >>38564 сервер навигации не предоставит мне инструменты чтобы персонаж остановился, если точка маршрута за границей навмеша. Проблема.
В общем, всё это пустой пиздёж, надо садиться за код и кодить.
> не понимаю, как добавить обход препятствий
Препятствия должны вырезать дырку в навмеше. После своих перемещений (если препятствия движущиеся) они посылают серверу сигнал повторить запекание навмеша. Дальше сам.
>>38564
> Навигация это скорее если ты кликаешь и персонаж как в РТС туда идет.
Не только. Я давно над этим размышляю, да всё руки не доходят набросать прототип (в тридэ, в двадэ делал много лет назад, и даже что-то получалось). Идея в том, что движущийся анимированный персонаж двигается всегда с одной скоростью и с накладываемыми анимацией ограничениями, то есть, например, если персонаж бежит вперёд и тут навстречу враги, он не может мгновенно развернуться и бежать обратно. Сначала он тормозит, потом перетаптывается разворачиваясь, потом разбегается. Снова.
Учитывая это, возникла идея не привязывать нажатия кнопок к вектору движения напрямую, как этому учат в большинстве туториалов, а привязать нажатия кнопок к активации движения по навмешу. Ты прожал "вперёд" и у персонажа появилась точка перед ним, к которой он должен идти. И он сообразно своей внутренней логике переключает свою внутреннюю стейтмашину, чтобы отобразить анимации движения. Пока ты держишь кнопку, контроллер просто добавляет ещё одну точку в маршрут, если предыдущая достигнута, либо ждёт. Однако, как показывает гифка здесь >>38564 сервер навигации не предоставит мне инструменты чтобы персонаж остановился, если точка маршрута за границей навмеша. Проблема.
В общем, всё это пустой пиздёж, надо садиться за код и кодить.
>>38940
Надо проверить, у NavigationAgent есть is_target_reacheable() не путать с is_target_reached()
>сервер навигации не предоставит мне инструменты чтобы персонаж остановился, если точка маршрута за границей навмеша
Надо проверить, у NavigationAgent есть is_target_reacheable() не путать с is_target_reached()
>>38957
Ок, поглядим.
Забыл сказать, для чего это нужно: Концепт игры со сменой персонажей. Захват тел типа. Для этого надо, чтобы игрок мог управлять любым НПЦ. В этой концепции какого-то особенного персонажа игрока нет, им будет любой НПЦ, стало быть, чтобы не дублировать логику движения, контроллер персонажа просто цепляется к существующей у НПЦ навигационной модели и юзает её вместо ИИ.
Ок, поглядим.
Забыл сказать, для чего это нужно: Концепт игры со сменой персонажей. Захват тел типа. Для этого надо, чтобы игрок мог управлять любым НПЦ. В этой концепции какого-то особенного персонажа игрока нет, им будет любой НПЦ, стало быть, чтобы не дублировать логику движения, контроллер персонажа просто цепляется к существующей у НПЦ навигационной модели и юзает её вместо ИИ.
>>38940
Эм, это как бы понятно, но разве не это должен делать NavigationObstacle2D? Или зачем эта нода тогда нужна?
>Препятствия должны вырезать дырку в навмеше. После своих перемещений (если препятствия движущиеся) они посылают серверу сигнал повторить запекание навмеша. Дальше сам.
Эм, это как бы понятно, но разве не это должен делать NavigationObstacle2D? Или зачем эта нода тогда нужна?
>>39005
Вот бы мне ответил анон, который в курсе и объяснил
Вот бы мне ответил анон, который в курсе и объяснил
>>38820
А-стар из коробки работает абсолютно нормально, бери да используй. Я пробовал сам - всё ок. Есть только один маленький нюанс, о котором тут как-то упоминали, но на гитхабе никто об этом не возражал: в Годо а-стар настроен на вес узла, а не связи между узлами. То есть вход в узел с любого другого узла равен весу узла, на который ты переходишь, а у связей нет весов вообще. С одной стороны, это вообще не проблема для большинства игр и ситуаций, но сдругой, может усложнить настройку в некоторых специфичных случаях. Пример: узел "замок", у него есть связи с дорогой, но одна связь через мост, а другая через ров с крокодилами. Анон в одном из прошлых тредов жаловался, что в других реализациях а-стар ты можешь назначить большой вес связи "ров с крокодилами", а в реализации а-стар Годо ты вынужден создавать дополнительные узлы для моста и для рва, чтобы реализовать задуманные маршруты. По-моему, проблема высосана из пальца, но тот анон сильно буянил по этому поводу.
А что с ними не так? Какие проблемы? По идее, такие сохранения будут работать как сохранение обычных файлов проекта. С сохранением и загрузкой файлов проекта никаких проблем нет. Почему тогда будут проблемы с сохранениями игры? Другое дело, что для надёжности и независимости от версий движка лучше всё же сделать собственную систему сохранений на JSON.
>>38824
Потому что:
1. Самый популярный из независимого опенсурса; можешь убедиться, поискав на гитхабе альтернативы.
2. Опенсорс развивается тем лучше, чем он популярнее. С популярностью приходят инвестиции, пул-реквесты от заинтересованных и т.д. Профит для всех.
3. Юнити работает ещё хуже, это всем известно.
Преимущества Юнити на данный момент:
- обучают в вузах, берут на работу;
- много платных и бесплатных уроков;
- много ассетов, в т.ч. скриптов и плагинов.
Чтобы Годо окончательно догнал и перегнал Юнити, он должен стать достаточно популярен, чтобы появилось больше вакансий, уроков и аддонов. Естественно, для этого нужно как-то убедить перейти на него прямо сейчас...
>>38826
Ты не поверишь, но шизы - и есть прозревшие. Только не те шизы, которые несут всякую дичь и видят глюки, а шизы, сохранившие рассудок и критический взгляд на вещи. Вот только движкописанием зачастую занимаются не прозревшие, а ньюфаги...
>Нормально работает или как навигация
А-стар из коробки работает абсолютно нормально, бери да используй. Я пробовал сам - всё ок. Есть только один маленький нюанс, о котором тут как-то упоминали, но на гитхабе никто об этом не возражал: в Годо а-стар настроен на вес узла, а не связи между узлами. То есть вход в узел с любого другого узла равен весу узла, на который ты переходишь, а у связей нет весов вообще. С одной стороны, это вообще не проблема для большинства игр и ситуаций, но сдругой, может усложнить настройку в некоторых специфичных случаях. Пример: узел "замок", у него есть связи с дорогой, но одна связь через мост, а другая через ров с крокодилами. Анон в одном из прошлых тредов жаловался, что в других реализациях а-стар ты можешь назначить большой вес связи "ров с крокодилами", а в реализации а-стар Годо ты вынужден создавать дополнительные узлы для моста и для рва, чтобы реализовать задуманные маршруты. По-моему, проблема высосана из пальца, но тот анон сильно буянил по этому поводу.
>сохранения с использованием Resources
А что с ними не так? Какие проблемы? По идее, такие сохранения будут работать как сохранение обычных файлов проекта. С сохранением и загрузкой файлов проекта никаких проблем нет. Почему тогда будут проблемы с сохранениями игры? Другое дело, что для надёжности и независимости от версий движка лучше всё же сделать собственную систему сохранений на JSON.
>>38824
>А чего все так убеждают пересаживаться на годот, если он работает так криво?
Потому что:
1. Самый популярный из независимого опенсурса; можешь убедиться, поискав на гитхабе альтернативы.
2. Опенсорс развивается тем лучше, чем он популярнее. С популярностью приходят инвестиции, пул-реквесты от заинтересованных и т.д. Профит для всех.
3. Юнити работает ещё хуже, это всем известно.
Преимущества Юнити на данный момент:
- обучают в вузах, берут на работу;
- много платных и бесплатных уроков;
- много ассетов, в т.ч. скриптов и плагинов.
Чтобы Годо окончательно догнал и перегнал Юнити, он должен стать достаточно популярен, чтобы появилось больше вакансий, уроков и аддонов. Естественно, для этого нужно как-то убедить перейти на него прямо сейчас...
>>38826
>Похоже движкописцы не шизы, а прозревшие
Ты не поверишь, но шизы - и есть прозревшие. Только не те шизы, которые несут всякую дичь и видят глюки, а шизы, сохранившие рассудок и критический взгляд на вещи. Вот только движкописанием зачастую занимаются не прозревшие, а ньюфаги...
>>38820
А-стар из коробки работает абсолютно нормально, бери да используй. Я пробовал сам - всё ок. Есть только один маленький нюанс, о котором тут как-то упоминали, но на гитхабе никто об этом не возражал: в Годо а-стар настроен на вес узла, а не связи между узлами. То есть вход в узел с любого другого узла равен весу узла, на который ты переходишь, а у связей нет весов вообще. С одной стороны, это вообще не проблема для большинства игр и ситуаций, но сдругой, может усложнить настройку в некоторых специфичных случаях. Пример: узел "замок", у него есть связи с дорогой, но одна связь через мост, а другая через ров с крокодилами. Анон в одном из прошлых тредов жаловался, что в других реализациях а-стар ты можешь назначить большой вес связи "ров с крокодилами", а в реализации а-стар Годо ты вынужден создавать дополнительные узлы для моста и для рва, чтобы реализовать задуманные маршруты. По-моему, проблема высосана из пальца, но тот анон сильно буянил по этому поводу.
А что с ними не так? Какие проблемы? По идее, такие сохранения будут работать как сохранение обычных файлов проекта. С сохранением и загрузкой файлов проекта никаких проблем нет. Почему тогда будут проблемы с сохранениями игры? Другое дело, что для надёжности и независимости от версий движка лучше всё же сделать собственную систему сохранений на JSON.
>>38824
Потому что:
1. Самый популярный из независимого опенсурса; можешь убедиться, поискав на гитхабе альтернативы.
2. Опенсорс развивается тем лучше, чем он популярнее. С популярностью приходят инвестиции, пул-реквесты от заинтересованных и т.д. Профит для всех.
3. Юнити работает ещё хуже, это всем известно.
Преимущества Юнити на данный момент:
- обучают в вузах, берут на работу;
- много платных и бесплатных уроков;
- много ассетов, в т.ч. скриптов и плагинов.
Чтобы Годо окончательно догнал и перегнал Юнити, он должен стать достаточно популярен, чтобы появилось больше вакансий, уроков и аддонов. Естественно, для этого нужно как-то убедить перейти на него прямо сейчас...
>>38826
Ты не поверишь, но шизы - и есть прозревшие. Только не те шизы, которые несут всякую дичь и видят глюки, а шизы, сохранившие рассудок и критический взгляд на вещи. Вот только движкописанием зачастую занимаются не прозревшие, а ньюфаги...
>Нормально работает или как навигация
А-стар из коробки работает абсолютно нормально, бери да используй. Я пробовал сам - всё ок. Есть только один маленький нюанс, о котором тут как-то упоминали, но на гитхабе никто об этом не возражал: в Годо а-стар настроен на вес узла, а не связи между узлами. То есть вход в узел с любого другого узла равен весу узла, на который ты переходишь, а у связей нет весов вообще. С одной стороны, это вообще не проблема для большинства игр и ситуаций, но сдругой, может усложнить настройку в некоторых специфичных случаях. Пример: узел "замок", у него есть связи с дорогой, но одна связь через мост, а другая через ров с крокодилами. Анон в одном из прошлых тредов жаловался, что в других реализациях а-стар ты можешь назначить большой вес связи "ров с крокодилами", а в реализации а-стар Годо ты вынужден создавать дополнительные узлы для моста и для рва, чтобы реализовать задуманные маршруты. По-моему, проблема высосана из пальца, но тот анон сильно буянил по этому поводу.
>сохранения с использованием Resources
А что с ними не так? Какие проблемы? По идее, такие сохранения будут работать как сохранение обычных файлов проекта. С сохранением и загрузкой файлов проекта никаких проблем нет. Почему тогда будут проблемы с сохранениями игры? Другое дело, что для надёжности и независимости от версий движка лучше всё же сделать собственную систему сохранений на JSON.
>>38824
>А чего все так убеждают пересаживаться на годот, если он работает так криво?
Потому что:
1. Самый популярный из независимого опенсурса; можешь убедиться, поискав на гитхабе альтернативы.
2. Опенсорс развивается тем лучше, чем он популярнее. С популярностью приходят инвестиции, пул-реквесты от заинтересованных и т.д. Профит для всех.
3. Юнити работает ещё хуже, это всем известно.
Преимущества Юнити на данный момент:
- обучают в вузах, берут на работу;
- много платных и бесплатных уроков;
- много ассетов, в т.ч. скриптов и плагинов.
Чтобы Годо окончательно догнал и перегнал Юнити, он должен стать достаточно популярен, чтобы появилось больше вакансий, уроков и аддонов. Естественно, для этого нужно как-то убедить перейти на него прямо сейчас...
>>38826
>Похоже движкописцы не шизы, а прозревшие
Ты не поверишь, но шизы - и есть прозревшие. Только не те шизы, которые несут всякую дичь и видят глюки, а шизы, сохранившие рассудок и критический взгляд на вещи. Вот только движкописанием зачастую занимаются не прозревшие, а ньюфаги...
>>38940
Максимально мерзкая схема управления в любых играх, что 2D, что 3D, что от первого лица, что от третьего. Нет, чисто побаловаться - можно, но постоянно так играть, особенно в динамичный экшн, просто отвратительно.
Говно идея. Даже если бы навигация в Годо была идеальной, самой совершенной из всех, которые в принципе могут существовать - идея говно. Это как взять самое худшее из игр, в которых ты вынужден кликать на точку назначения, чтобы персонаж шёл, и смешать с лучшим, что есть в геймдеве - движением на WASD.
Если так сильно хочешь поиздеваться над игроком, добавив задержку всем движениям, сделай так: вместо KinematicBody используй RigidBody, а вместо move() используй add_force(). Вектор движения, получаемый из кнопок WASD+пробел, оставь без изменений. Тогда ты получишь плавный разгон, плавное торможение и плавный разворот в любом направлении. Будешь блевать радугой от удовольствия, не прибегая к извращениям с навмешами.
>>38965
Почему твой контроллер движений НПЦ такой странный? Твои НПЦ должны запрашивать у навигационной модели маршрут, а затем следовать точкам маршрута, виртуально нажимая кнопки WASD+пробел. Игрок, беря под контроль НПЦ, не ставит перед ним навигационные точки, а напрямую контролирует тело, выстраивая маршрут в собственной голове ИРЛ. Это самое органичное решение, которое не будет вызывать проблем с контроллем как у игрока, так и у НПЦ. А ты что-то там извращешь непонятное, у тебя случайно не пошаговая стратегия на сетке?
>если персонаж бежит вперёд и тут навстречу враги, он не может мгновенно развернуться и бежать обратно. Сначала он тормозит, потом перетаптывается разворачиваясь, потом разбегается.
Максимально мерзкая схема управления в любых играх, что 2D, что 3D, что от первого лица, что от третьего. Нет, чисто побаловаться - можно, но постоянно так играть, особенно в динамичный экшн, просто отвратительно.
>возникла идея не привязывать нажатия кнопок к вектору движения напрямую, как этому учат в большинстве туториалов, а привязать нажатия кнопок к активации движения по навмешу. Ты прожал "вперёд" и у персонажа появилась точка перед ним, к которой он должен идти
Говно идея. Даже если бы навигация в Годо была идеальной, самой совершенной из всех, которые в принципе могут существовать - идея говно. Это как взять самое худшее из игр, в которых ты вынужден кликать на точку назначения, чтобы персонаж шёл, и смешать с лучшим, что есть в геймдеве - движением на WASD.
Если так сильно хочешь поиздеваться над игроком, добавив задержку всем движениям, сделай так: вместо KinematicBody используй RigidBody, а вместо move() используй add_force(). Вектор движения, получаемый из кнопок WASD+пробел, оставь без изменений. Тогда ты получишь плавный разгон, плавное торможение и плавный разворот в любом направлении. Будешь блевать радугой от удовольствия, не прибегая к извращениям с навмешами.
>>38965
>Для этого надо, чтобы игрок мог управлять любым НПЦ. В этой концепции какого-то особенного персонажа игрока нет, им будет любой НПЦ, стало быть, чтобы не дублировать логику движения, контроллер персонажа просто цепляется к существующей у НПЦ навигационной модели и юзает её вместо ИИ.
Почему твой контроллер движений НПЦ такой странный? Твои НПЦ должны запрашивать у навигационной модели маршрут, а затем следовать точкам маршрута, виртуально нажимая кнопки WASD+пробел. Игрок, беря под контроль НПЦ, не ставит перед ним навигационные точки, а напрямую контролирует тело, выстраивая маршрут в собственной голове ИРЛ. Это самое органичное решение, которое не будет вызывать проблем с контроллем как у игрока, так и у НПЦ. А ты что-то там извращешь непонятное, у тебя случайно не пошаговая стратегия на сетке?
>>38940
Максимально мерзкая схема управления в любых играх, что 2D, что 3D, что от первого лица, что от третьего. Нет, чисто побаловаться - можно, но постоянно так играть, особенно в динамичный экшн, просто отвратительно.
Говно идея. Даже если бы навигация в Годо была идеальной, самой совершенной из всех, которые в принципе могут существовать - идея говно. Это как взять самое худшее из игр, в которых ты вынужден кликать на точку назначения, чтобы персонаж шёл, и смешать с лучшим, что есть в геймдеве - движением на WASD.
Если так сильно хочешь поиздеваться над игроком, добавив задержку всем движениям, сделай так: вместо KinematicBody используй RigidBody, а вместо move() используй add_force(). Вектор движения, получаемый из кнопок WASD+пробел, оставь без изменений. Тогда ты получишь плавный разгон, плавное торможение и плавный разворот в любом направлении. Будешь блевать радугой от удовольствия, не прибегая к извращениям с навмешами.
>>38965
Почему твой контроллер движений НПЦ такой странный? Твои НПЦ должны запрашивать у навигационной модели маршрут, а затем следовать точкам маршрута, виртуально нажимая кнопки WASD+пробел. Игрок, беря под контроль НПЦ, не ставит перед ним навигационные точки, а напрямую контролирует тело, выстраивая маршрут в собственной голове ИРЛ. Это самое органичное решение, которое не будет вызывать проблем с контроллем как у игрока, так и у НПЦ. А ты что-то там извращешь непонятное, у тебя случайно не пошаговая стратегия на сетке?
>если персонаж бежит вперёд и тут навстречу враги, он не может мгновенно развернуться и бежать обратно. Сначала он тормозит, потом перетаптывается разворачиваясь, потом разбегается.
Максимально мерзкая схема управления в любых играх, что 2D, что 3D, что от первого лица, что от третьего. Нет, чисто побаловаться - можно, но постоянно так играть, особенно в динамичный экшн, просто отвратительно.
>возникла идея не привязывать нажатия кнопок к вектору движения напрямую, как этому учат в большинстве туториалов, а привязать нажатия кнопок к активации движения по навмешу. Ты прожал "вперёд" и у персонажа появилась точка перед ним, к которой он должен идти
Говно идея. Даже если бы навигация в Годо была идеальной, самой совершенной из всех, которые в принципе могут существовать - идея говно. Это как взять самое худшее из игр, в которых ты вынужден кликать на точку назначения, чтобы персонаж шёл, и смешать с лучшим, что есть в геймдеве - движением на WASD.
Если так сильно хочешь поиздеваться над игроком, добавив задержку всем движениям, сделай так: вместо KinematicBody используй RigidBody, а вместо move() используй add_force(). Вектор движения, получаемый из кнопок WASD+пробел, оставь без изменений. Тогда ты получишь плавный разгон, плавное торможение и плавный разворот в любом направлении. Будешь блевать радугой от удовольствия, не прибегая к извращениям с навмешами.
>>38965
>Для этого надо, чтобы игрок мог управлять любым НПЦ. В этой концепции какого-то особенного персонажа игрока нет, им будет любой НПЦ, стало быть, чтобы не дублировать логику движения, контроллер персонажа просто цепляется к существующей у НПЦ навигационной модели и юзает её вместо ИИ.
Почему твой контроллер движений НПЦ такой странный? Твои НПЦ должны запрашивать у навигационной модели маршрут, а затем следовать точкам маршрута, виртуально нажимая кнопки WASD+пробел. Игрок, беря под контроль НПЦ, не ставит перед ним навигационные точки, а напрямую контролирует тело, выстраивая маршрут в собственной голове ИРЛ. Это самое органичное решение, которое не будет вызывать проблем с контроллем как у игрока, так и у НПЦ. А ты что-то там извращешь непонятное, у тебя случайно не пошаговая стратегия на сетке?
>>39240
Я немного не понял, ты вроде сначала написал, что Годотовская реализация работает с весами, а потом, что их не поддерживает.
Да там сначала туториалы люди снимали, говоря, что надо использовать их, а не Json, а потом начали вопить о каких-то ошибках и уязвимостях системы. В итоге сам допетрил, как пройтись по нодам, чтоб их сохранить в православный Json
Ну вот я перешел. И что дальше? Я вообще не понимаю функционала некоторых нод/функций и как они работают, а никто объяснить не может. Я спрашиваю про NavigationObstacle2D, а все молчат. Неужели никто не пользуется этим и все используют A*, но если так, тогда зачем вообще эта навигационная нода?
Как должно появиться больше уроков/аддонов, если люди не понимают годот?
Вот Love2d тоже опен-сурсный, но в него я как-то легко вкатился, а тут...
>А-стар
Я немного не понял, ты вроде сначала написал, что Годотовская реализация работает с весами, а потом, что их не поддерживает.
>Resources
Да там сначала туториалы люди снимали, говоря, что надо использовать их, а не Json, а потом начали вопить о каких-то ошибках и уязвимостях системы. В итоге сам допетрил, как пройтись по нодам, чтоб их сохранить в православный Json
>Естественно, для этого нужно как-то убедить перейти на него прямо сейчас.
Ну вот я перешел. И что дальше? Я вообще не понимаю функционала некоторых нод/функций и как они работают, а никто объяснить не может. Я спрашиваю про NavigationObstacle2D, а все молчат. Неужели никто не пользуется этим и все используют A*, но если так, тогда зачем вообще эта навигационная нода?
Как должно появиться больше уроков/аддонов, если люди не понимают годот?
Вот Love2d тоже опен-сурсный, но в него я как-то легко вкатился, а тут...
>>39270
В годоте веса узлов, и нет весов связей ("дорог") между ними.
НавСервер добавили недавно, еще никто не разобрался. Сам потыкай, хуле.
>Годотовская реализация работает с весами, а потом, что их не поддерживает.
В годоте веса узлов, и нет весов связей ("дорог") между ними.
>Я спрашиваю про NavigationObstacle2D, а все молчат.
НавСервер добавили недавно, еще никто не разобрался. Сам потыкай, хуле.
>>39276
А как тогда сделать в старой системе, которая Navigation2D, препятствия?
Не, я недостаточно умный для этого.
>НавСервер добавили недавно, еще никто не разобрался.
А как тогда сделать в старой системе, которая Navigation2D, препятствия?
>Сам потыкай, хуле.
Не, я недостаточно умный для этого.
>>39270
А-стар работает с графом (гугли). У графа есть узлы и связи. Вот в Годо а-стар принимает веса узлов, но не веса связей. Правда, я не уверен, но вроде бы "весом связи" можно считать расстояние между узлами, т.к. в отличие от математического графа в реализации Годо а-стар использует пространственные позиции для узлов. Эх... Не важно, лучше сам почитай в документации.
В первую очередь читай документацию и гитхаб. Контент на Ютубе никем не контролируется, разработчики движка не могут заставить удалить плохое видео.
Читай документацию в первую очередь.
F1 в помощь, всё основное есть в редакторе.
Да тут вообще редко могут помочь, нас 3.5 пользователя Годо здесь, из них 1.5 как бы делают что-то (я не из них, по крайней мере сейчас).
Поспрашивай лучше в официальном дискорд-канале, там уж точно должны пояснить (на английском).
Честно? Без понятия. Я пробовал делать навигацию на а-старе и мне зашло (делаю 3D), а в навигации Годо я сам не разобрался и забил до лучших времён, потому что не вижу никаких преимуществ. Теоретически, система навигации должна упрощать настройку сцены и перестраивать пути соответственно динамически меняющимся препятствиям, но я считаю, что для каждой игры должно быть своё решение, и универсальная система невозможна. Наверное, разработчики движка считают иначе...
А-стар работает с графом (гугли). У графа есть узлы и связи. Вот в Годо а-стар принимает веса узлов, но не веса связей. Правда, я не уверен, но вроде бы "весом связи" можно считать расстояние между узлами, т.к. в отличие от математического графа в реализации Годо а-стар использует пространственные позиции для узлов. Эх... Не важно, лучше сам почитай в документации.
>туториалы люди снимали
В первую очередь читай документацию и гитхаб. Контент на Ютубе никем не контролируется, разработчики движка не могут заставить удалить плохое видео.
>не понимаю функционала некоторых нод/функций и как они работают
Читай документацию в первую очередь.
F1 в помощь, всё основное есть в редакторе.
>спрашиваю про NavigationObstacle2D, а все молчат
Да тут вообще редко могут помочь, нас 3.5 пользователя Годо здесь, из них 1.5 как бы делают что-то (я не из них, по крайней мере сейчас).
Поспрашивай лучше в официальном дискорд-канале, там уж точно должны пояснить (на английском).
>тогда зачем вообще эта навигационная нода?
Честно? Без понятия. Я пробовал делать навигацию на а-старе и мне зашло (делаю 3D), а в навигации Годо я сам не разобрался и забил до лучших времён, потому что не вижу никаких преимуществ. Теоретически, система навигации должна упрощать настройку сцены и перестраивать пути соответственно динамически меняющимся препятствиям, но я считаю, что для каждой игры должно быть своё решение, и универсальная система невозможна. Наверное, разработчики движка считают иначе...
>>39292
А, все, я допер про что ты. Вес будет считаться не по "цене" каждой связи, а по "цене" узла, который мы собираемся пересечь. Ну да, проблема не критичная, но иногда может подпортить жизни
Может я изнежен всякими GMS и Love2D, но в годоте максимально неудобная и неинформативная документация. Будто писалась не для пользователя, а конкретно для разработчика годота. Просто в вышеперечисленных, даже если что-то и не понимал в документации, то было легко найти ответ в ютубе - хороший, понятный и всеобъемлющий.
Попробую его найти и поспрашивать. Надеюсь с моим английским меня поймут
Да как бы А хорош до годота им и пользовался, но меня привлекло то, что Годот в Navigation2D сам строит граф, по которому можно перемещаться. В A же придется самому с этим страдать. И я понимаю, что я что-то сложного хотел, но, вроде, нет, вроде все просто, нужен тупой обход препятствий. Я просто не знаю, как можно влиять на то, что построил годот
А, все, я допер про что ты. Вес будет считаться не по "цене" каждой связи, а по "цене" узла, который мы собираемся пересечь. Ну да, проблема не критичная, но иногда может подпортить жизни
>Документация
Может я изнежен всякими GMS и Love2D, но в годоте максимально неудобная и неинформативная документация. Будто писалась не для пользователя, а конкретно для разработчика годота. Просто в вышеперечисленных, даже если что-то и не понимал в документации, то было легко найти ответ в ютубе - хороший, понятный и всеобъемлющий.
>Поспрашивай лучше в официальном дискорд-канале
Попробую его найти и поспрашивать. Надеюсь с моим английским меня поймут
>Честно? Без понятия. Я пробовал делать навигацию на а-старе и мне зашло
Да как бы А хорош до годота им и пользовался, но меня привлекло то, что Годот в Navigation2D сам строит граф, по которому можно перемещаться. В A же придется самому с этим страдать. И я понимаю, что я что-то сложного хотел, но, вроде, нет, вроде все просто, нужен тупой обход препятствий. Я просто не знаю, как можно влиять на то, что построил годот
>>39295
Писец, из-за звездочек курсив поставился
Писец, из-за звездочек курсив поставился
>>39295
Хочешь, чтобы я сел за компьютер, разобрался с 2Д навигацией лично, а потом тебе разжевал?
Ты как будто на сайте не был:
https://godotengine.org/community
У любого серьёзного инструмента API должно быть описано достаточно сухо. У Годо хорошая документация АПИ. Учить самым азам должны туториалы, которые тоже есть в документации, но только на сайте, и демки, которые можно скачать из "лаунчера" Годо или с гитхаба. Проблема со старой навигацией в том, что она устарела, и поэтому туториалы по ней вроде уже начали вырезать, а демки - обновлять до нового сервера навигации.
Хочешь, чтобы я сел за компьютер, разобрался с 2Д навигацией лично, а потом тебе разжевал?
>Попробую его найти
Ты как будто на сайте не был:
https://godotengine.org/community
>максимально неудобная и неинформативная документация
У любого серьёзного инструмента API должно быть описано достаточно сухо. У Годо хорошая документация АПИ. Учить самым азам должны туториалы, которые тоже есть в документации, но только на сайте, и демки, которые можно скачать из "лаунчера" Годо или с гитхаба. Проблема со старой навигацией в том, что она устарела, и поэтому туториалы по ней вроде уже начали вырезать, а демки - обновлять до нового сервера навигации.
1,7 Мб, mp4,800x600, 0:57
В общем, я попробовал - накидать навигацию с помощью NavigationAgent2D достаточно просто, но сложно настроить обход агентами друг друга без глюков. И, насколько я понял, обход агентами друг друга действует только как небольшое отклонение от маршрута, т.е. если агент перекрывает собой узкий проход и не двигается, сервер навигации даже не пытается построить новый маршрут - продолжает тыкать агента в очевидный (!) тупик (т.е. буквально в стену), к тому же is_target_reachable() продолжает возвращать true.
А вот NavigationObstacle2D я не смог заставить работать. Использовать Navigation2D не стал, т.к. её как-то сложно настроить и всё равно планируют удалить, так зачем с ней тогда мучиться?
>>38917
Судя по скриншотам и файлам здесь:
https://github.com/godotengine/godot/issues/57967
Для использования NavigationObstacle2D не нужна нода Navigation2D, но такое препятствие будет всегда круглым, а его обход - это корректировка маршрута, а не построение нового. Т.е. ровно как с агентами.
Как я понимаю, для создания настоящих препятствий нужно динамически выключать/вырезать регионы из навмеша, только тогда сервер навигации соизволит перестроить маршрут заново с учётом новых препятствий. Но я сомневаюсь, что это разумно делать для любых постоянно движущихся объектов (вроде автомобилей).
Вывод: для реальной игры нужно делать свою собственную систему навигации, не полагаясь на то, что попытались сделать "для всех".
А вот NavigationObstacle2D я не смог заставить работать. Использовать Navigation2D не стал, т.к. её как-то сложно настроить и всё равно планируют удалить, так зачем с ней тогда мучиться?
>>38917
>Я в _ready пихаю nav_obstacle.set_navigation(levelNavigation), но это не работает
Судя по скриншотам и файлам здесь:
https://github.com/godotengine/godot/issues/57967
Для использования NavigationObstacle2D не нужна нода Navigation2D, но такое препятствие будет всегда круглым, а его обход - это корректировка маршрута, а не построение нового. Т.е. ровно как с агентами.
Как я понимаю, для создания настоящих препятствий нужно динамически выключать/вырезать регионы из навмеша, только тогда сервер навигации соизволит перестроить маршрут заново с учётом новых препятствий. Но я сомневаюсь, что это разумно делать для любых постоянно движущихся объектов (вроде автомобилей).
Вывод: для реальной игры нужно делать свою собственную систему навигации, не полагаясь на то, что попытались сделать "для всех".
>>39358
Надо будет попробовать, а ты вызываешь в каждом physics_process $NavigationAgent.get_next_location()?
>сервер навигации даже не пытается построить новый маршрут
Надо будет попробовать, а ты вызываешь в каждом physics_process $NavigationAgent.get_next_location()?
>>39360
Да, всё так, без этого бы ничего вообще не работало. Для обхода других персонажей присваиваю скорость через set_velocity, только в обработчике завершения вычислений делаю смещение персонажа на safe_velocity. Но это, похоже, вообще не влияет на вычисление нового маршрута, да это и не помогло бы - маршрут строится без учёта расположения агентов на карте (на видео видно, когда я пытаюсь перейти мост в правом нижнем углу).
Да, всё так, без этого бы ничего вообще не работало. Для обхода других персонажей присваиваю скорость через set_velocity, только в обработчике завершения вычислений делаю смещение персонажа на safe_velocity. Но это, похоже, вообще не влияет на вычисление нового маршрута, да это и не помогло бы - маршрут строится без учёта расположения агентов на карте (на видео видно, когда я пытаюсь перейти мост в правом нижнем углу).
>>39358
Добавь агенту ноду Line2D
В коде сделай
$Line2D.points = $NavigationAgent2D.get_nav_path()
Тогда ты в реальном времени увидишь что маршрут пересчитывается где-то раз в секунду.
Добавь агенту ноду Line2D
В коде сделай
$Line2D.points = $NavigationAgent2D.get_nav_path()
Тогда ты в реальном времени увидишь что маршрут пересчитывается где-то раз в секунду.
>>39364
А, не, я же сам периодически пересчитываю маршрут (присваивая target_location)
А так почитал блог, получается что obstacle только притормаживает тебя при движении по маршруту.
А, не, я же сам периодически пересчитываю маршрут (присваивая target_location)
А так почитал блог, получается что obstacle только притормаживает тебя при движении по маршруту.
Я так понимаю что пилят другую либу - надо просто подождать?
https://github.com/godotengine/godot-proposals/issues/4522#issuecomment-1280113160
https://github.com/godotengine/godot-proposals/issues/4522#issuecomment-1280113160
Как же хочется 3D тяночку смоделировать в Блендере и няшиться с ней в Годо, чтобы ходила за мной и что-нибудь вместе с ней делали, но сил не хватает, депрессия приковывает к постели...
>>39358
Ух, спасибо, что разобрался, анон.
Да уж, печально, что Навигация в годоте оказалась настолько бесполезной. Пойду заниматься Astar'ом
Ух, спасибо, что разобрался, анон.
Да уж, печально, что Навигация в годоте оказалась настолько бесполезной. Пойду заниматься Astar'ом
>>39430
У меня только нетбук с 1 ГБ памяти и какой-то проблемой дисплея, делать на нём что-то сложное сейчас вообще не вариант. На смартфоне вообще жесть как неудобно с чем-либо серьёзным работать даже с подключённым комплектом ПК-клавомыши.
Но встать и сесть за компьютер не проблема. Проблема что-нибудь толковое сделать и быть довольным результатом, чтобы не огорчаться.
У меня накопилось за несколько лет множество заготовок тел гуманоидов, но все "какие-то не такие", у большинства лицо даже не начато, либо вышло всратым, нет текстур, доделанного скелета и тем более анимаций. Могу часами таскать туда-сюда отдельные вершины и квады, но так и не добиться желаемой формы. Лепку пробовал, но это какое-то извращение, фича без задач, особенно если твой идеал - гладкие формы.
Брать готовое не хочу, т.к. сколько ни смотрел, всё не нравится. Да и основная идея "сделать своими руками" не равнозначна "взять готовое", это вообще полные противоположности. А ещё я толком не могу представить себе мысленно, чего я хочу...
У меня только нетбук с 1 ГБ памяти и какой-то проблемой дисплея, делать на нём что-то сложное сейчас вообще не вариант. На смартфоне вообще жесть как неудобно с чем-либо серьёзным работать даже с подключённым комплектом ПК-клавомыши.
Но встать и сесть за компьютер не проблема. Проблема что-нибудь толковое сделать и быть довольным результатом, чтобы не огорчаться.
У меня накопилось за несколько лет множество заготовок тел гуманоидов, но все "какие-то не такие", у большинства лицо даже не начато, либо вышло всратым, нет текстур, доделанного скелета и тем более анимаций. Могу часами таскать туда-сюда отдельные вершины и квады, но так и не добиться желаемой формы. Лепку пробовал, но это какое-то извращение, фича без задач, особенно если твой идеал - гладкие формы.
Брать готовое не хочу, т.к. сколько ни смотрел, всё не нравится. Да и основная идея "сделать своими руками" не равнозначна "взять готовое", это вообще полные противоположности. А ещё я толком не могу представить себе мысленно, чего я хочу...
ебать, не увидел переката
перепощу сюда
Всю жизнь мечтал делать игори
нашел godot
накодил велосипедов за пару вечеров
идей и мотивации делать чтото законченное - ноль, даже простое дизморалит люто чет
https://alkaon.itch.io/testos
можно похуесосить
не против собраться гденить в чатике и ченить попилить совместно в свободное время, если идея интересная
алсо двиг потрясающий, разобрался практически сходу, при этом в юнити не смог освоится вообще
гдскрипт - заебумба кстати, максимально понятно, мой навык кодинга - хеллоуворлды на питоне и джаваскрипте
перепощу сюда
Всю жизнь мечтал делать игори
нашел godot
накодил велосипедов за пару вечеров
идей и мотивации делать чтото законченное - ноль, даже простое дизморалит люто чет
https://alkaon.itch.io/testos
можно похуесосить
не против собраться гденить в чатике и ченить попилить совместно в свободное время, если идея интересная
алсо двиг потрясающий, разобрался практически сходу, при этом в юнити не смог освоится вообще
гдскрипт - заебумба кстати, максимально понятно, мой навык кодинга - хеллоуворлды на питоне и джаваскрипте
>>39473
Нихуя не понял что делать, убежал на экран просто.
Кто-нибудь подскажет во сколько лучше постить на итчио чтобы мое говно тут же не утонуло без просмотров?
Нихуя не понял что делать, убежал на экран просто.
Кто-нибудь подскажет во сколько лучше постить на итчио чтобы мое говно тут же не утонуло без просмотров?
>>39508
Да это просто набор механик для песочницы которые я накодил пока разбирался с движком
разбирался как карту сделать, анимации, и все такое
Можно поднимать предметы, есть инвентарь, дверь открывается только когда предмет в инвентаре активен
Яблоки и шоколадки стакаются, можно выкидывать по X
Я вроде туда еще врагов пихал, но не стал их включать прост
Ничего конретного там нет по сути
Да это просто набор механик для песочницы которые я накодил пока разбирался с движком
разбирался как карту сделать, анимации, и все такое
Можно поднимать предметы, есть инвентарь, дверь открывается только когда предмет в инвентаре активен
Яблоки и шоколадки стакаются, можно выкидывать по X
Я вроде туда еще врагов пихал, но не стал их включать прост
Ничего конретного там нет по сути
>>39473
Это гарантированный способ увеличить прокрастинацию в десятки раз.
> собраться гденить в чатике и ченить попилить совместно в свободное время
Это гарантированный способ увеличить прокрастинацию в десятки раз.
>>39542
Прокрастинация меня хитнула когда я механ доделал. Теперь вместо допила просто играю в свой огрызок и мне норм, а там даже меню и рестарта нет.
Другой анон
Прокрастинация меня хитнула когда я механ доделал. Теперь вместо допила просто играю в свой огрызок и мне норм, а там даже меню и рестарта нет.
Другой анон
>>39459
Странное утверждение, т.к. рисовать объекты на порядки сложнее, чем писать код. Код ты пишешь по строгим правилам, а в рисовании такого нет.
>>39460
Не надо, но может помочь в освоении.
Если ничего не знаешь - начинай сразу с GDScript.
>>39464
Частое заблуждение, но GDScript очень отдалённо напоминает Python, разве что отступами.
>Рисовать объекты не легче, чем код писать
Странное утверждение, т.к. рисовать объекты на порядки сложнее, чем писать код. Код ты пишешь по строгим правилам, а в рисовании такого нет.
>>39460
>надо уже знать к-л язык?
Не надо, но может помочь в освоении.
Если ничего не знаешь - начинай сразу с GDScript.
>>39464
>питон
Частое заблуждение, но GDScript очень отдалённо напоминает Python, разве что отступами.
>>39473
https://godotengine.org/community
Я лично против где-либо собираться. Если бы я хотел сидеть в чате, я бы сидел в чате, а не в /гд/.
А как ты к геймдеву пришёл, если нет ни идей, ни мотивации? Или у тебя депрессия?
Гдачую, юнити слишком сложна, пытался несколько раз в разные года и в итоге окончательно забил.
>>39542
Гдачую, если нет строгого организатора/лидера, который будет пинать всех, указывать и руководить, то всё скатится в обычный чатик. Но терпеть строгого лидера энтузиасты обычно не любят (если не мазохисты или не друзья детства, лол) и быстро сливаются.
>>39556
Повезло тебе. Меня мои недоделки не увлекают достаточно, играю в чужие игры и забиваю на свои.
>собраться гденить в чатике
https://godotengine.org/community
Я лично против где-либо собираться. Если бы я хотел сидеть в чате, я бы сидел в чате, а не в /гд/.
>идей и мотивации делать чтото законченное - ноль, даже простое дизморалит люто чет
А как ты к геймдеву пришёл, если нет ни идей, ни мотивации? Или у тебя депрессия?
>при этом в юнити не смог освоится вообще
Гдачую, юнити слишком сложна, пытался несколько раз в разные года и в итоге окончательно забил.
>>39542
>Это гарантированный способ увеличить прокрастинацию в десятки раз.
Гдачую, если нет строгого организатора/лидера, который будет пинать всех, указывать и руководить, то всё скатится в обычный чатик. Но терпеть строгого лидера энтузиасты обычно не любят (если не мазохисты или не друзья детства, лол) и быстро сливаются.
>>39556
>Теперь вместо допила просто играю в свой огрызок и мне норм, а там даже меню и рестарта нет.
Повезло тебе. Меня мои недоделки не увлекают достаточно, играю в чужие игры и забиваю на свои.
>>39561
Может он про проэктирование, пишешь то ты по правилам, но что и как писать еще надо придумать.
>>39568
Ну я просто вкатился во все это чисто с целью сделать что мне надо, потому что девайс на котором я в это играл тупа сдох. Теперь только лениво допиливаю фичи ради интереса, либо потому что хотелось чтобы они были в той игрушке.
Может он про проэктирование, пишешь то ты по правилам, но что и как писать еще надо придумать.
>>39568
>Меня мои недоделки не увлекают достаточно
Ну я просто вкатился во все это чисто с целью сделать что мне надо, потому что девайс на котором я в это играл тупа сдох. Теперь только лениво допиливаю фичи ради интереса, либо потому что хотелось чтобы они были в той игрушке.
>>39568
возможно
если именно про геймдев:
появляется идея
я сижу чуть больше суток нонстопом, начинаю чтото клепать, кайфую, и после того как поспишь уже ничего не хочется, этот проект раздражает
так впринципе с любой деятельностью, которая в теории должна приносить удовольствие
>Или у тебя депрессия?
возможно
если именно про геймдев:
появляется идея
я сижу чуть больше суток нонстопом, начинаю чтото клепать, кайфую, и после того как поспишь уже ничего не хочется, этот проект раздражает
так впринципе с любой деятельностью, которая в теории должна приносить удовольствие
>>39572
Жиза, проще вообще не спать. А то потом утром все остоебывает и просто сидишь ютубы скроллишь.
Жиза, проще вообще не спать. А то потом утром все остоебывает и просто сидишь ютубы скроллишь.
>>39568
Решительно двачую.
Если кому-то надо где-то собраться попиздеть, то скажу вам по секрету в дискорде и в телеге есть официальные русскоязычные годот-каналы.
> Я лично против где-либо собираться. Если бы я хотел сидеть в чате, я бы сидел в чате, а не в /гд/.
Решительно двачую.
Если кому-то надо где-то собраться попиздеть, то скажу вам по секрету в дискорде и в телеге есть официальные русскоязычные годот-каналы.
>>39587
Покажи на примере кода, как они похожи, а то я дурачок наверное, вкатываюсь в питон джва года с нулевым результатом, а в гдскрипт вкатился за неделю.
> напоминает Python буквально всем
Покажи на примере кода, как они похожи, а то я дурачок наверное, вкатываюсь в питон джва года с нулевым результатом, а в гдскрипт вкатился за неделю.
>>39611
То есть по существу вопроса ты отвечать не будешь? Ясно. Репорт движкосрачеру.
> ты точно дурачок
То есть по существу вопроса ты отвечать не будешь? Ясно. Репорт движкосрачеру.
>>39571
Есть паттерны проектирования. Многое не нужно изобретать, достаточно выбрать подходящее.
Делаешь ремейк игры со старых консолей?
>>39572
У меня подобное уже несколько лет...
>>39574
Нужно попытаться заставить себя сесть за проект через силу, авось втянешься. Я иногда с самого пробуждения несколько часов кодил или моделировал что-то, забывая поесть и попить. Но на то, чтобы начать, конечно, тоже нужна мотивация...
>>39587
Напоминает, но это не одно и то же. С тем же успехом можно владеть любым другим императивным языком, в любом случае придётся осваивать GDScript как новый язык, а не уже знакомый.
>>39604
Синтаксис if/while похож. Отступы значащие.
>проэктирование
Есть паттерны проектирования. Многое не нужно изобретать, достаточно выбрать подходящее.
>девайс на котором я в это играл тупа сдох
Делаешь ремейк игры со старых консолей?
>>39572
>после того как поспишь уже ничего не хочется, этот проект раздражает
У меня подобное уже несколько лет...
>>39574
>утром все остоебывает
Нужно попытаться заставить себя сесть за проект через силу, авось втянешься. Я иногда с самого пробуждения несколько часов кодил или моделировал что-то, забывая поесть и попить. Но на то, чтобы начать, конечно, тоже нужна мотивация...
>>39587
>напоминает
Напоминает, но это не одно и то же. С тем же успехом можно владеть любым другим императивным языком, в любом случае придётся осваивать GDScript как новый язык, а не уже знакомый.
>>39604
>как они похожи
Синтаксис if/while похож. Отступы значащие.
204 Кб, 900x500Одна из последних моих попыток сделать 3D персонажа или базу персонажа для игры. Начал давно, в 2021, последний раз что-то редактировал в начале лета. Не пойму, что мне не нравится, но мотивации продолжать вообще нет. Хоть садись и делай всё заново, с нуля... что я, собственно, и делаю каждый раз... поэтому ничего не доделываю. Да, это какой-то перфекционизм, но если бы я хотя бы знал, чего я хочу/что мне не нравится/что мне понравилось бы, было бы куда проще.
Что же делать? Наплевать и доделать хоть что-то до конца, чтобы было чувство завершённости и опыт? Вообще не пойму, чем я недоволен, если я хотел сделать базу, которую можно было бы менять шейпкеями в игре. Все пропорции/объёмы можно было бы поправить в игре, хоть каждый день по настроению менять...
Что же делать? Наплевать и доделать хоть что-то до конца, чтобы было чувство завершённости и опыт? Вообще не пойму, чем я недоволен, если я хотел сделать базу, которую можно было бы менять шейпкеями в игре. Все пропорции/объёмы можно было бы поправить в игре, хоть каждый день по настроению менять...
4 Кб, 468x265>>39668
Да, я тут ещё понял недавно, что для базовой модели нужны более нейтральные пропорции, а-ля прямоугольник без чётко выраженной груди, талии и бёдер, а уже шейпкеями делать возможность увеличить грудь, сузить талию, расширить бёдра и т.д. По идее, можно даже не делать отдельную мужскую модель, т.к. на таком уровне детализации (нет половых органов и других мелких деталей) заметной разницы между мужчиной и женщиной нет, а фигуру можно менять шейпкеями - т.е. должно хватить одной базовой модели. Странно, что во всех играх, что я видел, делают две разных модели - выглядит нерационально, удваивает работу дизайнеров.
На пикриле пример из документации Блендера, как два шейпкея позволяют сделать разные фигуры. Если добавить третий шейпкей для "талии" - получим все возможные человеческие фигуры. Я потестил немного, очень просто делать, но как это поддерживается Годо пока не ясно (я имею в виду качество/оптимизации, сама фича есть).
Но это, похоже, нужно новую модель делать, не хочу эту портить/изменять дальше. Да... наверное, моя проблема в том, что я всё время боюсь "испортить" модель, если продолжу над ней как-либо работать. Не в плане невозможности откатить изменения, а в плане того, что я не способен сделать лучше и боюсь этого (сложно объяснить).
>менять шейпкеями
Да, я тут ещё понял недавно, что для базовой модели нужны более нейтральные пропорции, а-ля прямоугольник без чётко выраженной груди, талии и бёдер, а уже шейпкеями делать возможность увеличить грудь, сузить талию, расширить бёдра и т.д. По идее, можно даже не делать отдельную мужскую модель, т.к. на таком уровне детализации (нет половых органов и других мелких деталей) заметной разницы между мужчиной и женщиной нет, а фигуру можно менять шейпкеями - т.е. должно хватить одной базовой модели. Странно, что во всех играх, что я видел, делают две разных модели - выглядит нерационально, удваивает работу дизайнеров.
На пикриле пример из документации Блендера, как два шейпкея позволяют сделать разные фигуры. Если добавить третий шейпкей для "талии" - получим все возможные человеческие фигуры. Я потестил немного, очень просто делать, но как это поддерживается Годо пока не ясно (я имею в виду качество/оптимизации, сама фича есть).
Но это, похоже, нужно новую модель делать, не хочу эту портить/изменять дальше. Да... наверное, моя проблема в том, что я всё время боюсь "испортить" модель, если продолжу над ней как-либо работать. Не в плане невозможности откатить изменения, а в плане того, что я не способен сделать лучше и боюсь этого (сложно объяснить).
>>39473
Я протестировал, но так и не смог ничего в руки подобрать. Какой клавишей подбирать? Нажимал всё, что пришло в голову, но могу только ходить и тыкать рукой. А так, начинание годное у тебя, продолжай. Планируешь что-то на тему космической станции, как SS13?
На счёт графики могу сказать - не забывай о контрасте, персонаж и предметы не должны сливаться с фоном/полом в любой возможной ситуации. Если не получается выделить спрайт цветом, лучше сделать ему обводку, чем позволять сливаться с фоном.
>накодил велосипедов за пару вечеров
Я протестировал, но так и не смог ничего в руки подобрать. Какой клавишей подбирать? Нажимал всё, что пришло в голову, но могу только ходить и тыкать рукой. А так, начинание годное у тебя, продолжай. Планируешь что-то на тему космической станции, как SS13?
На счёт графики могу сказать - не забывай о контрасте, персонаж и предметы не должны сливаться с фоном/полом в любой возможной ситуации. Если не получается выделить спрайт цветом, лучше сделать ему обводку, чем позволять сливаться с фоном.
>>39696
Мышкой у него вроде
Мышкой у него вроде
>>39616
Со старых консолей можно поиграть во все что захочешь через эмули. Я делаю сраный тетрис-матч3 со своего первого мп3. Это Columns с NES, но немного другой.
Залипал в него в отпусках, потому что делать больше было нехуй в дороге. А так чилишь себе на полке в поезде, в ушах плейлист, в руках хоть что-то.
То что я собрал в годо за пару вечеров под гайд с ютуба "делаем матч3" вышло 1 в 1 как было, ну разве что скорость падения другая.
>Делаешь ремейк игры со старых консолей?
Со старых консолей можно поиграть во все что захочешь через эмули. Я делаю сраный тетрис-матч3 со своего первого мп3. Это Columns с NES, но немного другой.
Залипал в него в отпусках, потому что делать больше было нехуй в дороге. А так чилишь себе на полке в поезде, в ушах плейлист, в руках хоть что-то.
То что я собрал в годо за пару вечеров под гайд с ютуба "делаем матч3" вышло 1 в 1 как было, ну разве что скорость падения другая.
>>39668
А вот моя. Недавно вот делать было нехуй.
> Одна из последних моих попыток сделать 3D персонажа
А вот моя. Недавно вот делать было нехуй.
>>39779
Ну надо ж как-то отпиздеться. У меня-то стационарник с ПЕЧью, как оно на встройке могу только предполагать.
Ну надо ж как-то отпиздеться. У меня-то стационарник с ПЕЧью, как оно на встройке могу только предполагать.
>>39758
Слишком токсично для нашего уютного треда.
Слишком токсично для нашего уютного треда.
>>39738
Это Маша Баронова? Или Катя Заштопик?
Это Маша Баронова? Или Катя Заштопик?
136 Кб, 1124x593>>39738
Твоя ли? Это же из MakeHuman (пикрил).
Я пытаюсь сделать меш, риг, текстуры, анимации - всё с нуля, чтобы иметь контроль и меньше зависимостей. Будет глупо выглядеть, если я возьму готовое, и не смогу органично дополнить своими идеями, т.к. не разбираюсь в технологии или не имею нужных навыков.
>>39758
Угадал или подсмотрел?
>>39772
Я думаю, тут дело не в полигонах, а в текстурах и стилизации лица. Текстуры - мыльные "типа фотки", лицо - попытка в реализм. Если бы стилизация была более мультяшной, модель выглядела бы куда лучше даже с тем же количеством полигонов и тем же разрешением текстур. Всё портит попытка в реализм - как было модно в нулевых.
>А вот моя.
Твоя ли? Это же из MakeHuman (пикрил).
Я пытаюсь сделать меш, риг, текстуры, анимации - всё с нуля, чтобы иметь контроль и меньше зависимостей. Будет глупо выглядеть, если я возьму готовое, и не смогу органично дополнить своими идеями, т.к. не разбираюсь в технологии или не имею нужных навыков.
>>39758
>Привет из начала нулевых.
Угадал или подсмотрел?
>Initial release: 2000; 22 years ago
>>39772
>Зато на встройке не лагает.
Я думаю, тут дело не в полигонах, а в текстурах и стилизации лица. Текстуры - мыльные "типа фотки", лицо - попытка в реализм. Если бы стилизация была более мультяшной, модель выглядела бы куда лучше даже с тем же количеством полигонов и тем же разрешением текстур. Всё портит попытка в реализм - как было модно в нулевых.
документация хреновенькая
>>39803
Ты - сможешь. Поскольку ты свои меши делаешь. Там такие же, на квадах, ничего необычного. И скелеты такие же. И морфы. Ты можешь взять этот готовый опенсорсный проект и без задней мысли допиливать под себя. Мультяшность добавить, например.
> если я возьму готовое, и не смогу органично дополнить своими идеями
Ты - сможешь. Поскольку ты свои меши делаешь. Там такие же, на квадах, ничего необычного. И скелеты такие же. И морфы. Ты можешь взять этот готовый опенсорсный проект и без задней мысли допиливать под себя. Мультяшность добавить, например.
>>39676
Ты всё таки погоняй мейкхуман. Зарядись идеями дидов из нулевых. Там как раз одна модель на оба пола, точнее говоря, там нет пола, там один слайдер, с помощью которого ты можешь задать "мужиковатость" или "бабость" модели. В процентах.
> как два шейпкея позволяют сделать разные фигуры
> Странно, что во всех играх, что я видел, делают две разных модели - выглядит нерационально, удваивает работу дизайнеров.
Ты всё таки погоняй мейкхуман. Зарядись идеями дидов из нулевых. Там как раз одна модель на оба пола, точнее говоря, там нет пола, там один слайдер, с помощью которого ты можешь задать "мужиковатость" или "бабость" модели. В процентах.
>>39888
Хули толку от хайполи зибраша в геймдеве? Ты сначала ретоп освой и уже показывай готовые к продакшену лоуполи с запечённым в текстурах хайполи.
А хайполи свои в /td/ иди показывай.
Хули толку от хайполи зибраша в геймдеве? Ты сначала ретоп освой и уже показывай готовые к продакшену лоуполи с запечённым в текстурах хайполи.
А хайполи свои в /td/ иди показывай.
>>39844
Меши мешам рознь...
Какие модели ни качаю - постоянно какие-то сложные настройки скелета, а то и вовсе Rigify используют, у него какое-то сложное устройство.
Легко сказать. Если бы это было так легко... На самом деле годная стилизация сложнее реализма, т.к. реализм - это буквальное копирование.
>>39846
А там есть текстура кожи?
>>39895
Завидуешь что ли?
Я слышал, это стандарт индустрии. В /td/ говорили, что "сейчас никто не начинает с лоуполи, двигая отдельные полигоны". Ну, не знаю, мне приятнее полигоны двигать, но, наверное, профессиональным артистам удобнее лепкой заниматься.
Вообще, сомневаюсь, что скульптинг имеет смысл для персонажа, у которого кожа - сплошная заливка.
>Поскольку ты свои меши делаешь
Меши мешам рознь...
>скелеты такие же
Какие модели ни качаю - постоянно какие-то сложные настройки скелета, а то и вовсе Rigify используют, у него какое-то сложное устройство.
>Мультяшность добавить
Легко сказать. Если бы это было так легко... На самом деле годная стилизация сложнее реализма, т.к. реализм - это буквальное копирование.
>>39846
>Там как раз одна модель на оба пола, точнее говоря, там нет пола, там один слайдер
А там есть текстура кожи?
>>39895
>А хайполи свои в /td/ иди показывай.
Завидуешь что ли?
>Хули толку от хайполи зибраша в геймдеве
Я слышал, это стандарт индустрии. В /td/ говорили, что "сейчас никто не начинает с лоуполи, двигая отдельные полигоны". Ну, не знаю, мне приятнее полигоны двигать, но, наверное, профессиональным артистам удобнее лепкой заниматься.
Вообще, сомневаюсь, что скульптинг имеет смысл для персонажа, у которого кожа - сплошная заливка.
>>39905
С лоуполи и не начинают, к нему приходят. Ты в игру свои 2кк вершин не засунешь.
С лоуполи и не начинают, к нему приходят. Ты в игру свои 2кк вершин не засунешь.
>>39926
Кто сказал? Я с лоуполи начинаю всегда.
Кто "ты"? Я выше кидал модель - там 1к вершин.
Не понимаю, зачем скульптить модель на 2кк вершин. Кто будет рассматривать все эти мелкие жилки, пупырышки, вмятинки и прочие дефекты в настоящей игре? Посмотрите на аниме - там даже лицо человека в виде залитого одним цветом овала, не говоря уж об остальном теле, пропорции которого в большинстве случаев реалистичны (очень редко встречается аниме с карикатурными пропорциями тела, если не считать чибиков и отдельные кадры/ляпы), но кожа - чистая заливка. Зачем нужно скульптить 2кк вершин, если тебя интересует заливка одним цветом простых цилиндров и полусфер?
Вот выше у анона какой-то монстр, наверное, для хоррора и/или шутера. Да, таких монстров только скульптом можно сделать. Но для абстрактной аниме-тян скульпт просто не имеет смысла, у таких моделек 99% кожи вообще никакой текстуры не имеют, чистая заливка (я скачивал бесплатные, проверял).
>С лоуполи и не начинают, к нему приходят.
Кто сказал? Я с лоуполи начинаю всегда.
>Ты в игру свои 2кк вершин не засунешь.
Кто "ты"? Я выше кидал модель - там 1к вершин.
Не понимаю, зачем скульптить модель на 2кк вершин. Кто будет рассматривать все эти мелкие жилки, пупырышки, вмятинки и прочие дефекты в настоящей игре? Посмотрите на аниме - там даже лицо человека в виде залитого одним цветом овала, не говоря уж об остальном теле, пропорции которого в большинстве случаев реалистичны (очень редко встречается аниме с карикатурными пропорциями тела, если не считать чибиков и отдельные кадры/ляпы), но кожа - чистая заливка. Зачем нужно скульптить 2кк вершин, если тебя интересует заливка одним цветом простых цилиндров и полусфер?
Вот выше у анона какой-то монстр, наверное, для хоррора и/или шутера. Да, таких монстров только скульптом можно сделать. Но для абстрактной аниме-тян скульпт просто не имеет смысла, у таких моделек 99% кожи вообще никакой текстуры не имеют, чистая заливка (я скачивал бесплатные, проверял).
>>39942
Это не лоуполи, а блокинг. Если ты делаешь больше, чем блокинг и считаешь это лоуполи, то ты делаешь лишнюю работу каждый раз.
>Кто сказал? Я с лоуполи начинаю всегда.
Это не лоуполи, а блокинг. Если ты делаешь больше, чем блокинг и считаешь это лоуполи, то ты делаешь лишнюю работу каждый раз.
>>39696
Надо тыкнуть ЛКМ по предмету, находясь рядом с ним
аналогично с коробками на которых написано APPLE и CHOCO
да, изначально план был такой
нууу, я сделал так что при наведении на предмет, он увеличивается немного
про персонажа согласен что он сливается, надо учесть в будущем
>Какой клавишей подбирать? Нажимал всё, что пришло в голову, но могу только ходить и тыкать рукой.
Надо тыкнуть ЛКМ по предмету, находясь рядом с ним
аналогично с коробками на которых написано APPLE и CHOCO
>Планируешь что-то на тему космической станции, как SS13?
да, изначально план был такой
>На счёт графики могу сказать - не забывай о контрасте, персонаж и предметы не должны сливаться с фоном/полом в любой возможной ситуации.
нууу, я сделал так что при наведении на предмет, он увеличивается немного
про персонажа согласен что он сливается, надо учесть в будущем
>>40023
На что? Время и нервы на это тратят рабы в студиях, тут (надеюсь) все пилят что хотят и когда хотят.
На что? Время и нервы на это тратят рабы в студиях, тут (надеюсь) все пилят что хотят и когда хотят.
>>40054
Ну я себе сделал то во что играл 12 лет назад, а теперь не могу, это плохо что-ли? Ничего не потерял с этого.
Ну и всмысле нахуй "зачем", захотелось. Может еще спросишь зачем музыку пишут, картины. Лежать в потолок смотреть нужно?
Ну я себе сделал то во что играл 12 лет назад, а теперь не могу, это плохо что-ли? Ничего не потерял с этого.
Ну и всмысле нахуй "зачем", захотелось. Может еще спросишь зачем музыку пишут, картины. Лежать в потолок смотреть нужно?
>>40059
Где то на 2 из 10.
Где то на 2 из 10.
Можно как-то определить размер Label еще до того, как он инициализируется, зная только длину текста, шрифт и размер шрифта? Ну типа Годот как-то же самостоятельно считает размер, исходя из этих параметров. У меня просто есть куча лэйблов с разным текстом, которые динамически добавляются в сцену, и хотелось бы им всех задать custom minimum size самого большого и динамически менять при смене шрифтов.
>>40134
Исходники в помощь.
> Ну типа Годот как-то же самостоятельно считает размер, исходя из этих параметров.
Исходники в помощь.
>>40134
Если текст в одну строку:
var size = $Label.get_font("normal_font").get_string_size($Label.text)
Если текст в несколько строк:
var size_with_text_wrap = $Label.get_font("normal_font").get_wordwrap_string_size($Label.text,1000)
Где 1000 - максимальное количество пикселей в строке перед переносом строки
Если текст в одну строку:
var size = $Label.get_font("normal_font").get_string_size($Label.text)
Если текст в несколько строк:
var size_with_text_wrap = $Label.get_font("normal_font").get_wordwrap_string_size($Label.text,1000)
Где 1000 - максимальное количество пикселей в строке перед переносом строки
W4Games собрали 8.5 млн долларов на развитие Godot, а так же сервисов по разработке и публикации на различных платформах.
>>40308
Эх, жаль, жаль. Но если вдруг какие варики появятся, ты свистни, я на созвоне. Обнял.
Эх, жаль, жаль. Но если вдруг какие варики появятся, ты свистни, я на созвоне. Обнял.
>>40023
Это хобби. Godot отлично подходит для хобби.
Ты играешь в игры? А зачем ты играешь в игры? Вот и тут то же самое.
>>40059
Если тебя устраивает использовать нейросеть и качество производимого ею контента - пожалуйста, тебя никто не ограничивает, это тоже своего рода хобби. Некоторых людей до сих пор интересует рисовать линии от руки, либо их не удовлетворяет качество/способ работы с нейросетями. В любом случае, это всё не более чем вопрос субъективного удобства инструмента. Вот Godot нам удобен для геймдева как хобби, мы его и используем.
>>40066
Мне кажется, он имел в виду это:
>Зачем вы тратите на это время и нервы?
Это хобби. Godot отлично подходит для хобби.
Ты играешь в игры? А зачем ты играешь в игры? Вот и тут то же самое.
>>40059
>>зачем музыку пишут, картины
>Ведь с этим отлично справляются нейросети.
Если тебя устраивает использовать нейросеть и качество производимого ею контента - пожалуйста, тебя никто не ограничивает, это тоже своего рода хобби. Некоторых людей до сих пор интересует рисовать линии от руки, либо их не удовлетворяет качество/способ работы с нейросетями. В любом случае, это всё не более чем вопрос субъективного удобства инструмента. Вот Godot нам удобен для геймдева как хобби, мы его и используем.
>>40066
>Тут обсуждают конкретный движок
Мне кажется, он имел в виду это:
>Зачем вы тратите время на Godot, когда есть Unity UE Falco Engine?
>>40285
Давайте лучше муви мейкер обсудим:
https://godotengine.org/article/movie-maker-mode-arrives-in-godot-4
Кто-нибудь уже пробовал/собирается попробовать записать что-то?
Давайте лучше муви мейкер обсудим:
https://godotengine.org/article/movie-maker-mode-arrives-in-godot-4
Кто-нибудь уже пробовал/собирается попробовать записать что-то?
>>40421
Есть этому пара применений... Надо было кое-какие видео рендерить, можно этим в блендере заниматься, но скриптить в годоте-то привычнее.
Есть этому пара применений... Надо было кое-какие видео рендерить, можно этим в блендере заниматься, но скриптить в годоте-то привычнее.
98 Кб, 738x589>>40033
Именно так. По крайней мере я в данное время вообще отошёл от игор и пилю на годоте удобные утилиты строковых конвертаций всякого разного файла.
> тут (надеюсь) все пилят что хотят и когда хотят
Именно так. По крайней мере я в данное время вообще отошёл от игор и пилю на годоте удобные утилиты строковых конвертаций всякого разного файла.
>>40425
Ну и для чего тебе нужна 306-я строка всех файлов в папке?
Рекомендую создать специальный скрипт:
И писать в нём статичные функции для упрощения типовых ситуаций.
В частности, можно было бы сильно упростить запись кода с твоего скриншота.
Ну, это может быть в ущерб памяти и/или скорости, но код легче читать и расширять.
Ну и для чего тебе нужна 306-я строка всех файлов в папке?
>утилиты строковых конвертаций всякого разного файла
Рекомендую создать специальный скрипт:
>class_name IOUtils
>extends Reference
И писать в нём статичные функции для упрощения типовых ситуаций.
В частности, можно было бы сильно упростить запись кода с твоего скриншота.
Ну, это может быть в ущерб памяти и/или скорости, но код легче читать и расширять.
Бамп
>>40437
Чтобы сплитнуть по =, и тримнуть по ", очевидно. А потом всё распарсенное сохранить в один общий файл.
> Ну и для чего тебе нужна 306-я строка всех файлов в папке?
Чтобы сплитнуть по =, и тримнуть по ", очевидно. А потом всё распарсенное сохранить в один общий файл.
>>40437
Код своё отработал и больше не нужен. Но на предложения по упрощению я бы посмотрел.
> можно было бы сильно упростить запись кода с твоего скриншота
Код своё отработал и больше не нужен. Но на предложения по упрощению я бы посмотрел.
11 Кб, 595x182>>40462
Полагаю так и должно быть. В сишечке же так, и в питоняше. В текс_товом файле нет никакой метаинформации о строках. Их можно только самому найти по переводам строк. Т.е. ты можешь или прочитать весь файл целиком в память (по уму конечно кусками через буфер - вдруг файл 256 гиговый) и заполнить массив отступов (строка 0: 0, строка 1: 13, итд) или читать последовательно по символам и считать переводы строк. Есть еще вариант что у тебя текс_товый файл жесткой структуры, как база данных, и тогда читать строку например кажым 80-м символом, но это ненадежно - кто угодно может вставить пробел в любое место.
З.ы. слово с _ - запрещенное.
Полагаю так и должно быть. В сишечке же так, и в питоняше. В текс_товом файле нет никакой метаинформации о строках. Их можно только самому найти по переводам строк. Т.е. ты можешь или прочитать весь файл целиком в память (по уму конечно кусками через буфер - вдруг файл 256 гиговый) и заполнить массив отступов (строка 0: 0, строка 1: 13, итд) или читать последовательно по символам и считать переводы строк. Есть еще вариант что у тебя текс_товый файл жесткой структуры, как база данных, и тогда читать строку например кажым 80-м символом, но это ненадежно - кто угодно может вставить пробел в любое место.
З.ы. слово с _ - запрещенное.
>>40461
Это нерационально, копипастить такие большие куски кода для простых одноразовых задач. Что, если ты допустишь ошибку при копировании? Придётся перечитывать код в поисках ошибки, отлаживать его.
1. Разделить алгоритм на шаги.
2. Шаги запаковать в удобные функции.
3. Профит.
Пример:
Преимущества: каждый метод можно протестировать и использовать без проблем от копипасты; уникальный код выделен в отдельный метод - абстрагирован от поиска файлов, т.е. его проще читать и отлаживать.
Недостатки: выделяется память под список путей до всех найденных файлов; метод вызывается через Object.call(), которому нужна строка, что намекает на снижение скорости выполнения кода (движок будет искать метод по имени? или там какая-то магическая оптимизация?).
>Код своё отработал и больше не нужен.
Это нерационально, копипастить такие большие куски кода для простых одноразовых задач. Что, если ты допустишь ошибку при копировании? Придётся перечитывать код в поисках ошибки, отлаживать его.
>предложения по упрощению
1. Разделить алгоритм на шаги.
2. Шаги запаковать в удобные функции.
3. Профит.
Пример:
>func main():
>var files := IOUtils.get_file_list("c:\path\", ".ext", IOUtils.NON_RECURSIVE)
>var results := IOUtils.for_each_file(files, self, "do_work")
>IOUtils.save_as_text_file("output.txt", results)
>func do_work(file: File):
>var line := IOUtils.get_one_text_line(file, 306)
># здесь твой код, обрабатывающий line
>return line
Преимущества: каждый метод можно протестировать и использовать без проблем от копипасты; уникальный код выделен в отдельный метод - абстрагирован от поиска файлов, т.е. его проще читать и отлаживать.
Недостатки: выделяется память под список путей до всех найденных файлов; метод вызывается через Object.call(), которому нужна строка, что намекает на снижение скорости выполнения кода (движок будет искать метод по имени? или там какая-то магическая оптимизация?).
>>37916
Я тут почитал по диагонали, как это (MVC) предлагается делать в Unity...
https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development
Вкратце, модель рано или поздно вырастет в огромного неуправляемого монстра, которого невозможно разделить на части, ничего не сломав. Да, ты отделяешь модель от вьювера и модель от контроллера, но сама модель получается огромным монолитным куском багофич.
В Godot, ты можешь открыть любую сцену и нажать F6. Если ты не наломал дров, то эта сцена запустится и будет работать, ничего не сломав и не сломавшись сама. Если применять MVC, ты уже не сможешь нажать F6 и запустить кусок проекта без всего остального, потому что тебе обязательно нужно загрузить ВСЮ модель, даже если ты не будешь её всю видеть и/или модифицировать. Теряется ручка управления, за которую ты можешь в любой момент дёрнуть, чтобы проверить часть игры (или перенести в другую игру).
Да, теоретически, модель можно разделить на кучку объектов, но ко всем этим объектам будет одна (1) точка доступа, узкая дырочка для всех команд от контроллера и запросов от вьювера. Нет дырочки - нет возможности увидеть, что творится с частью модели или как-то ею управлять. А если насверлить кучу отверстий, то получится самая обыкновенная лапша, в которой связи идут из множества мест в другое множество мест...
Так что я не думаю, что MVC так уж хорош для большой игры, в которой множество объектов должны существовать независимо друг от друга и игры в целом. Если у нас есть дробовик, из него должны вылетать пули, даже если он находится в абсолютном вакууме, а не только когда он находится на уровне с мишенями. Если у нас есть человечек, он должен страдать от голода независимо от того, находится он внутри вселенной или существует где-то вне пространства-времени. Если мы дали человечку дробовик, он должен мочь из него выстрелить даже если ему не в кого стрелять... И так далее. На счёт Unity не знаю, но Godot заточен именно на такую разработку, и это выглядит достаточно удобным даже в больших проектах - главное правильно это всё использовать, не натягивая лапшу от человечка к дробовику, от дробовика к оленю и от оленя к желудку человечка, иначе получится та же самая лапшичная модель.
Минус, конечно, очевиден - всё это будет сложно перенести на другой язык/движок/платформу в случае если Godot/GDScript перестанет удовлетворять требованиям разработчика игры. Но вряд ли этот минус оправдывает создание плотного комка абстрактной лапши внутри динамической библиотеки с одной дырочкой для доступа ко всем возможным данным и функциям. Библиотеку может и можно тестировать по частям автотестами, а вот игру разрабатывать по частям в такой библиотеке не получится - либо подключил библиотеку, либо отключил...
Или я чего-то не понимаю. Голова болит что-то...
>MVP (Model-View-Presenter) где эта наша сложная логика - модель
Я тут почитал по диагонали, как это (MVC) предлагается делать в Unity...
https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development
Вкратце, модель рано или поздно вырастет в огромного неуправляемого монстра, которого невозможно разделить на части, ничего не сломав. Да, ты отделяешь модель от вьювера и модель от контроллера, но сама модель получается огромным монолитным куском багофич.
В Godot, ты можешь открыть любую сцену и нажать F6. Если ты не наломал дров, то эта сцена запустится и будет работать, ничего не сломав и не сломавшись сама. Если применять MVC, ты уже не сможешь нажать F6 и запустить кусок проекта без всего остального, потому что тебе обязательно нужно загрузить ВСЮ модель, даже если ты не будешь её всю видеть и/или модифицировать. Теряется ручка управления, за которую ты можешь в любой момент дёрнуть, чтобы проверить часть игры (или перенести в другую игру).
Да, теоретически, модель можно разделить на кучку объектов, но ко всем этим объектам будет одна (1) точка доступа, узкая дырочка для всех команд от контроллера и запросов от вьювера. Нет дырочки - нет возможности увидеть, что творится с частью модели или как-то ею управлять. А если насверлить кучу отверстий, то получится самая обыкновенная лапша, в которой связи идут из множества мест в другое множество мест...
Так что я не думаю, что MVC так уж хорош для большой игры, в которой множество объектов должны существовать независимо друг от друга и игры в целом. Если у нас есть дробовик, из него должны вылетать пули, даже если он находится в абсолютном вакууме, а не только когда он находится на уровне с мишенями. Если у нас есть человечек, он должен страдать от голода независимо от того, находится он внутри вселенной или существует где-то вне пространства-времени. Если мы дали человечку дробовик, он должен мочь из него выстрелить даже если ему не в кого стрелять... И так далее. На счёт Unity не знаю, но Godot заточен именно на такую разработку, и это выглядит достаточно удобным даже в больших проектах - главное правильно это всё использовать, не натягивая лапшу от человечка к дробовику, от дробовика к оленю и от оленя к желудку человечка, иначе получится та же самая лапшичная модель.
Минус, конечно, очевиден - всё это будет сложно перенести на другой язык/движок/платформу в случае если Godot/GDScript перестанет удовлетворять требованиям разработчика игры. Но вряд ли этот минус оправдывает создание плотного комка абстрактной лапши внутри динамической библиотеки с одной дырочкой для доступа ко всем возможным данным и функциям. Библиотеку может и можно тестировать по частям автотестами, а вот игру разрабатывать по частям в такой библиотеке не получится - либо подключил библиотеку, либо отключил...
Или я чего-то не понимаю. Голова болит что-то...
>>37916
Я тут почитал по диагонали, как это (MVC) предлагается делать в Unity...
https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development
Вкратце, модель рано или поздно вырастет в огромного неуправляемого монстра, которого невозможно разделить на части, ничего не сломав. Да, ты отделяешь модель от вьювера и модель от контроллера, но сама модель получается огромным монолитным куском багофич.
В Godot, ты можешь открыть любую сцену и нажать F6. Если ты не наломал дров, то эта сцена запустится и будет работать, ничего не сломав и не сломавшись сама. Если применять MVC, ты уже не сможешь нажать F6 и запустить кусок проекта без всего остального, потому что тебе обязательно нужно загрузить ВСЮ модель, даже если ты не будешь её всю видеть и/или модифицировать. Теряется ручка управления, за которую ты можешь в любой момент дёрнуть, чтобы проверить часть игры (или перенести в другую игру).
Да, теоретически, модель можно разделить на кучку объектов, но ко всем этим объектам будет одна (1) точка доступа, узкая дырочка для всех команд от контроллера и запросов от вьювера. Нет дырочки - нет возможности увидеть, что творится с частью модели или как-то ею управлять. А если насверлить кучу отверстий, то получится самая обыкновенная лапша, в которой связи идут из множества мест в другое множество мест...
Так что я не думаю, что MVC так уж хорош для большой игры, в которой множество объектов должны существовать независимо друг от друга и игры в целом. Если у нас есть дробовик, из него должны вылетать пули, даже если он находится в абсолютном вакууме, а не только когда он находится на уровне с мишенями. Если у нас есть человечек, он должен страдать от голода независимо от того, находится он внутри вселенной или существует где-то вне пространства-времени. Если мы дали человечку дробовик, он должен мочь из него выстрелить даже если ему не в кого стрелять... И так далее. На счёт Unity не знаю, но Godot заточен именно на такую разработку, и это выглядит достаточно удобным даже в больших проектах - главное правильно это всё использовать, не натягивая лапшу от человечка к дробовику, от дробовика к оленю и от оленя к желудку человечка, иначе получится та же самая лапшичная модель.
Минус, конечно, очевиден - всё это будет сложно перенести на другой язык/движок/платформу в случае если Godot/GDScript перестанет удовлетворять требованиям разработчика игры. Но вряд ли этот минус оправдывает создание плотного комка абстрактной лапши внутри динамической библиотеки с одной дырочкой для доступа ко всем возможным данным и функциям. Библиотеку может и можно тестировать по частям автотестами, а вот игру разрабатывать по частям в такой библиотеке не получится - либо подключил библиотеку, либо отключил...
Или я чего-то не понимаю. Голова болит что-то...
>MVP (Model-View-Presenter) где эта наша сложная логика - модель
Я тут почитал по диагонали, как это (MVC) предлагается делать в Unity...
https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development
Вкратце, модель рано или поздно вырастет в огромного неуправляемого монстра, которого невозможно разделить на части, ничего не сломав. Да, ты отделяешь модель от вьювера и модель от контроллера, но сама модель получается огромным монолитным куском багофич.
В Godot, ты можешь открыть любую сцену и нажать F6. Если ты не наломал дров, то эта сцена запустится и будет работать, ничего не сломав и не сломавшись сама. Если применять MVC, ты уже не сможешь нажать F6 и запустить кусок проекта без всего остального, потому что тебе обязательно нужно загрузить ВСЮ модель, даже если ты не будешь её всю видеть и/или модифицировать. Теряется ручка управления, за которую ты можешь в любой момент дёрнуть, чтобы проверить часть игры (или перенести в другую игру).
Да, теоретически, модель можно разделить на кучку объектов, но ко всем этим объектам будет одна (1) точка доступа, узкая дырочка для всех команд от контроллера и запросов от вьювера. Нет дырочки - нет возможности увидеть, что творится с частью модели или как-то ею управлять. А если насверлить кучу отверстий, то получится самая обыкновенная лапша, в которой связи идут из множества мест в другое множество мест...
Так что я не думаю, что MVC так уж хорош для большой игры, в которой множество объектов должны существовать независимо друг от друга и игры в целом. Если у нас есть дробовик, из него должны вылетать пули, даже если он находится в абсолютном вакууме, а не только когда он находится на уровне с мишенями. Если у нас есть человечек, он должен страдать от голода независимо от того, находится он внутри вселенной или существует где-то вне пространства-времени. Если мы дали человечку дробовик, он должен мочь из него выстрелить даже если ему не в кого стрелять... И так далее. На счёт Unity не знаю, но Godot заточен именно на такую разработку, и это выглядит достаточно удобным даже в больших проектах - главное правильно это всё использовать, не натягивая лапшу от человечка к дробовику, от дробовика к оленю и от оленя к желудку человечка, иначе получится та же самая лапшичная модель.
Минус, конечно, очевиден - всё это будет сложно перенести на другой язык/движок/платформу в случае если Godot/GDScript перестанет удовлетворять требованиям разработчика игры. Но вряд ли этот минус оправдывает создание плотного комка абстрактной лапши внутри динамической библиотеки с одной дырочкой для доступа ко всем возможным данным и функциям. Библиотеку может и можно тестировать по частям автотестами, а вот игру разрабатывать по частям в такой библиотеке не получится - либо подключил библиотеку, либо отключил...
Или я чего-то не понимаю. Голова болит что-то...
>>40566
Какого плана информация тебе нужна?
Документация - есть, хорошая, даже встроена в редактор.
Базовые туториалы - есть, официальные и любительские.
Как делать сложные вещи - ты должен сам разобраться, а не требовать от других.
Движок - это инструмент.
Документация и туториалы учат пользоваться инструментом.
Как с помощью этого инструмента сделать что-то стоящее ты должен сам понять.
Для сравнения: молоток - это инструмент.
Туториал научит тебя правильно держать молоток и забивать гвоздь.
Но сколотить этим молотком себе сарай из досок и гвоздей ты должен сам.
В конце концов, высокоуровневый геймдизайн от движка не зависит.
>в плане информации
Какого плана информация тебе нужна?
Документация - есть, хорошая, даже встроена в редактор.
Базовые туториалы - есть, официальные и любительские.
Как делать сложные вещи - ты должен сам разобраться, а не требовать от других.
Движок - это инструмент.
Документация и туториалы учат пользоваться инструментом.
Как с помощью этого инструмента сделать что-то стоящее ты должен сам понять.
Для сравнения: молоток - это инструмент.
Туториал научит тебя правильно держать молоток и забивать гвоздь.
Но сколотить этим молотком себе сарай из досок и гвоздей ты должен сам.
В конце концов, высокоуровневый геймдизайн от движка не зависит.
>>40501
Что делает конктрукция эта, видел в видосах такие штуки, но нихуя не понял. Настолько что не знаю что искать. При использоваии где-либо results вызывается ду_ворк чи шо?
>var results := IOUtils.for_each_file(files, self, "do_work")
Что делает конктрукция эта, видел в видосах такие штуки, но нихуя не понял. Настолько что не знаю что искать. При использоваии где-либо results вызывается ду_ворк чи шо?
>>40586
Точно, я даже что-то похожее уже делал у себя.
>>40579
Если нужна теория, то вот:
https://en.wikipedia.org/wiki/Iterator
https://en.wikipedia.org/wiki/Higher-order_function
В данном случае можно так реализовать:
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-call
Можно, конечно, сделать и применить универсальный for_each(), но я просто показал пример IOUtils, в котором функция предназначена конкретно для работы с файлами по их именам.
Универсальный метод, который стоит сохранить в ArrayUtils.gd:
С его помощью можно перебрать тот же массив имён файлов, но тогда создание и открытие File будет происходить в методе method, имя которого мы передаём в эту функцию. Типа, да, так можно, но строчки кода открытия/закрытия придётся повторять для каждого method, который мы хотим создать, так почему бы не убрать их в специально созданный для файлов for_each_file? При условии, что for_each_file будет вызываться всего один раз на каждый список файлов (иначе будет открывать и закрывать одни и те же файлы, когда можно было бы один раз открыть и держать открытыми, пока не закончишь всю работу).
...я глянул свой собственный код и вспомнил, что можно сделать чуть иначе:
По сути то же самое, только чуть компактнее.
https://docs.godotengine.org/en/stable/classes/class_funcref.html
Использование будет таким:
Не знаю, что всё-таки лучше использовать, смотри сам.
Кстати говоря, в некоторых ЯП даже такое есть!
https://en.wikipedia.org/wiki/Lazy_evaluation
Но в Godot такого нет (и это хорошо).
Есть другая штука, но, вроде, тоже связанная с оптимизациями - call_deferred:
Но этот метод по очевидной причине не позволяет вернуть значение, поэтому данные придётся сохранить в тот объект, из которого этот метод вызвали. К тому же ты не знаешь наверняка, когда он выполнится, и должен как-то об этом узнать, например, через сигналы.
>MVC может быть применём в рамках одной сцены, а не всей игры.
Точно, я даже что-то похожее уже делал у себя.
>>40579
>не знаю что искать
Если нужна теория, то вот:
https://en.wikipedia.org/wiki/Iterator
https://en.wikipedia.org/wiki/Higher-order_function
>>var results := IOUtils.for_each_file(files, self, "do_work")
В данном случае можно так реализовать:
>static func for_each_file(filenames: PoolStringArray, object: Object, method: String) -> Array:
>_ var result: Array = []
>_ result.resize(filenames.size()) # для ускорения
>_ for x in filenames.size():
>_ _ var file = File.new()
>_ _ file.open(filenames[x], File.READ_WRITE)
>_ _ result[x] = object.call(method, file) # вызов метода по имени
>_ _ file.close()
>_ return result
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-call
Можно, конечно, сделать и применить универсальный for_each(), но я просто показал пример IOUtils, в котором функция предназначена конкретно для работы с файлами по их именам.
Универсальный метод, который стоит сохранить в ArrayUtils.gd:
>static func for_each(data: Array, object: Object, method: String) -> Array:
>_ var result: Array = []
>_ result.resize(data.size()) # для ускорения
>_ for x in data.size():
>_ _ result[x] = object.call(method, data[x]) # вызов метода по имени
>_ return result
С его помощью можно перебрать тот же массив имён файлов, но тогда создание и открытие File будет происходить в методе method, имя которого мы передаём в эту функцию. Типа, да, так можно, но строчки кода открытия/закрытия придётся повторять для каждого method, который мы хотим создать, так почему бы не убрать их в специально созданный для файлов for_each_file? При условии, что for_each_file будет вызываться всего один раз на каждый список файлов (иначе будет открывать и закрывать одни и те же файлы, когда можно было бы один раз открыть и держать открытыми, пока не закончишь всю работу).
...я глянул свой собственный код и вспомнил, что можно сделать чуть иначе:
>static func for_each_file(filenames: PoolStringArray, method: FuncRef) -> Array:
>...
>_ _ result[x] = method.call_func(file)
>...
>static func for_each(data: Array, method: FuncRef) -> Array:
>_ _ result[x] = method.call_func(data[x])
>...
По сути то же самое, только чуть компактнее.
https://docs.godotengine.org/en/stable/classes/class_funcref.html
Использование будет таким:
>var results := IOUtils.for_each_file(files, funcref(self, "do_work"))
>var results := ArrayUtils.for_each(files, funcref(self, "do_work"))
Не знаю, что всё-таки лучше использовать, смотри сам.
>При использоваии где-либо results вызывается ду_ворк
Кстати говоря, в некоторых ЯП даже такое есть!
https://en.wikipedia.org/wiki/Lazy_evaluation
Но в Godot такого нет (и это хорошо).
Есть другая штука, но, вроде, тоже связанная с оптимизациями - call_deferred:
>Calls the method on the object during idle time.
Но этот метод по очевидной причине не позволяет вернуть значение, поэтому данные придётся сохранить в тот объект, из которого этот метод вызвали. К тому же ты не знаешь наверняка, когда он выполнится, и должен как-то об этом узнать, например, через сигналы.
>>40586
Точно, я даже что-то похожее уже делал у себя.
>>40579
Если нужна теория, то вот:
https://en.wikipedia.org/wiki/Iterator
https://en.wikipedia.org/wiki/Higher-order_function
В данном случае можно так реализовать:
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-call
Можно, конечно, сделать и применить универсальный for_each(), но я просто показал пример IOUtils, в котором функция предназначена конкретно для работы с файлами по их именам.
Универсальный метод, который стоит сохранить в ArrayUtils.gd:
С его помощью можно перебрать тот же массив имён файлов, но тогда создание и открытие File будет происходить в методе method, имя которого мы передаём в эту функцию. Типа, да, так можно, но строчки кода открытия/закрытия придётся повторять для каждого method, который мы хотим создать, так почему бы не убрать их в специально созданный для файлов for_each_file? При условии, что for_each_file будет вызываться всего один раз на каждый список файлов (иначе будет открывать и закрывать одни и те же файлы, когда можно было бы один раз открыть и держать открытыми, пока не закончишь всю работу).
...я глянул свой собственный код и вспомнил, что можно сделать чуть иначе:
По сути то же самое, только чуть компактнее.
https://docs.godotengine.org/en/stable/classes/class_funcref.html
Использование будет таким:
Не знаю, что всё-таки лучше использовать, смотри сам.
Кстати говоря, в некоторых ЯП даже такое есть!
https://en.wikipedia.org/wiki/Lazy_evaluation
Но в Godot такого нет (и это хорошо).
Есть другая штука, но, вроде, тоже связанная с оптимизациями - call_deferred:
Но этот метод по очевидной причине не позволяет вернуть значение, поэтому данные придётся сохранить в тот объект, из которого этот метод вызвали. К тому же ты не знаешь наверняка, когда он выполнится, и должен как-то об этом узнать, например, через сигналы.
>MVC может быть применём в рамках одной сцены, а не всей игры.
Точно, я даже что-то похожее уже делал у себя.
>>40579
>не знаю что искать
Если нужна теория, то вот:
https://en.wikipedia.org/wiki/Iterator
https://en.wikipedia.org/wiki/Higher-order_function
>>var results := IOUtils.for_each_file(files, self, "do_work")
В данном случае можно так реализовать:
>static func for_each_file(filenames: PoolStringArray, object: Object, method: String) -> Array:
>_ var result: Array = []
>_ result.resize(filenames.size()) # для ускорения
>_ for x in filenames.size():
>_ _ var file = File.new()
>_ _ file.open(filenames[x], File.READ_WRITE)
>_ _ result[x] = object.call(method, file) # вызов метода по имени
>_ _ file.close()
>_ return result
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-call
Можно, конечно, сделать и применить универсальный for_each(), но я просто показал пример IOUtils, в котором функция предназначена конкретно для работы с файлами по их именам.
Универсальный метод, который стоит сохранить в ArrayUtils.gd:
>static func for_each(data: Array, object: Object, method: String) -> Array:
>_ var result: Array = []
>_ result.resize(data.size()) # для ускорения
>_ for x in data.size():
>_ _ result[x] = object.call(method, data[x]) # вызов метода по имени
>_ return result
С его помощью можно перебрать тот же массив имён файлов, но тогда создание и открытие File будет происходить в методе method, имя которого мы передаём в эту функцию. Типа, да, так можно, но строчки кода открытия/закрытия придётся повторять для каждого method, который мы хотим создать, так почему бы не убрать их в специально созданный для файлов for_each_file? При условии, что for_each_file будет вызываться всего один раз на каждый список файлов (иначе будет открывать и закрывать одни и те же файлы, когда можно было бы один раз открыть и держать открытыми, пока не закончишь всю работу).
...я глянул свой собственный код и вспомнил, что можно сделать чуть иначе:
>static func for_each_file(filenames: PoolStringArray, method: FuncRef) -> Array:
>...
>_ _ result[x] = method.call_func(file)
>...
>static func for_each(data: Array, method: FuncRef) -> Array:
>_ _ result[x] = method.call_func(data[x])
>...
По сути то же самое, только чуть компактнее.
https://docs.godotengine.org/en/stable/classes/class_funcref.html
Использование будет таким:
>var results := IOUtils.for_each_file(files, funcref(self, "do_work"))
>var results := ArrayUtils.for_each(files, funcref(self, "do_work"))
Не знаю, что всё-таки лучше использовать, смотри сам.
>При использоваии где-либо results вызывается ду_ворк
Кстати говоря, в некоторых ЯП даже такое есть!
https://en.wikipedia.org/wiki/Lazy_evaluation
Но в Godot такого нет (и это хорошо).
Есть другая штука, но, вроде, тоже связанная с оптимизациями - call_deferred:
>Calls the method on the object during idle time.
Но этот метод по очевидной причине не позволяет вернуть значение, поэтому данные придётся сохранить в тот объект, из которого этот метод вызвали. К тому же ты не знаешь наверняка, когда он выполнится, и должен как-то об этом узнать, например, через сигналы.
>>40692
Всм? Я меньше чем за штуку в месяц не берусь.
Всм? Я меньше чем за штуку в месяц не берусь.
У меня сгорело очко от юнити когда я сделал билд своей игры, отправил трём друзьям, у одного не запустилось, у двух других игра играется ВООБЩЕ по-другому нежеле у меня на компе.
Это я криворукий и что-то не так сделал или это прикол у юнити такой? Как с этим дела в Годоте?
Это я криворукий и что-то не так сделал или это прикол у юнити такой? Как с этим дела в Годоте?
>>40790
Годот требовательнее к технической подготовке разраба.
У меня такое было когда начинал в твг участвовать. У кого-то не запускалась, у кого-то не захватывался экран на стрим, у кого-то неправильное разрешение было. У кого-то на встройке графика отличается. У кого-то физика тормозит на меньшем количестве объектов, чем добавлено в игру. Часть багов со временем поправили в движке, часть я набрался опыта, и с такими проблемами не сталкивался.
Ну про delta time тебе писали уже, без подробностей скорее всего дело в этом. Без подробностей больше нечего добавить.
Годот требовательнее к технической подготовке разраба.
У меня такое было когда начинал в твг участвовать. У кого-то не запускалась, у кого-то не захватывался экран на стрим, у кого-то неправильное разрешение было. У кого-то на встройке графика отличается. У кого-то физика тормозит на меньшем количестве объектов, чем добавлено в игру. Часть багов со временем поправили в движке, часть я набрался опыта, и с такими проблемами не сталкивался.
Ну про delta time тебе писали уже, без подробностей скорее всего дело в этом. Без подробностей больше нечего добавить.
>>40790
Ты имеешь в виду скорость движений? Или расположение элементов GUI? Или что-то ещё?
Если скорость другая - это проблема того, что у твоих друзей другая частота кадров. Чтобы исправить её, ты должен умножать смещения на длительность кадра (delta). В Godot с этим проблем нет, как и в Unity.
Если интерфейс поломался - это проблема из-за другого разрешения экрана. Чтобы исправить её, нужно привязывать элементы экрана к процентам относительно сторон экрана, или использовать специальные контейнеры, которые автоматически размещают элементы GUI. В Godot с этим всё замечательно, а вот что там в Unity я так и не разобрался.
Если проблема с рендерингом - это может быть из-за другой видеокарты или драйвера видеокарты. Насколько я знаю, в Unity несколько разных пайплайнов для графики, у каждого свои особенности. В Godot 3.x таких пайплайнов всего два, оба на базе OpenGL: GLES2 и GLES3. В Godot 4.0 есть новые пайплайны Vulkan и Vulkan Mobile, а от GLES2 решили отказаться, оставив GLES3. У Godot есть какие-то проблемы с запуском на встроенных видеочипах ноутбуков, но в остальном, насколько я знаю, рендерер Godot стабилен, хотя результат может отличаться на десктопе, в вебе и на мобилках из-за отличий в железе и графических API. Ну, короче, проблемы со стороны графики неизбежны вне зависимости от выбора движка из-за огромного зоопарка железа и связанных с ними драйверов и API.
>>40802
Странно, у меня с OBS в Godot ни разу проблемы не было на ветке 3.x. Работают все способы захвата без проблем, как, наверное, с любой OpenGL игрой. Хотя я не пробовал записывать полноэкранный режим, но вряд ли OBS с ним не справится (там куча опций на все случаи жизни). Скорее всего тот стример что-то не понял или использовал какой-то другой софт для стрима.
Не проблема движка, а нехватка скорости ЦПУ. Если взять движок, у которого физика на ГПУ, проблем будет ещё больше из-за зоопарка видеокарт.
>играется ВООБЩЕ по-другому
Ты имеешь в виду скорость движений? Или расположение элементов GUI? Или что-то ещё?
Если скорость другая - это проблема того, что у твоих друзей другая частота кадров. Чтобы исправить её, ты должен умножать смещения на длительность кадра (delta). В Godot с этим проблем нет, как и в Unity.
Если интерфейс поломался - это проблема из-за другого разрешения экрана. Чтобы исправить её, нужно привязывать элементы экрана к процентам относительно сторон экрана, или использовать специальные контейнеры, которые автоматически размещают элементы GUI. В Godot с этим всё замечательно, а вот что там в Unity я так и не разобрался.
Если проблема с рендерингом - это может быть из-за другой видеокарты или драйвера видеокарты. Насколько я знаю, в Unity несколько разных пайплайнов для графики, у каждого свои особенности. В Godot 3.x таких пайплайнов всего два, оба на базе OpenGL: GLES2 и GLES3. В Godot 4.0 есть новые пайплайны Vulkan и Vulkan Mobile, а от GLES2 решили отказаться, оставив GLES3. У Godot есть какие-то проблемы с запуском на встроенных видеочипах ноутбуков, но в остальном, насколько я знаю, рендерер Godot стабилен, хотя результат может отличаться на десктопе, в вебе и на мобилках из-за отличий в железе и графических API. Ну, короче, проблемы со стороны графики неизбежны вне зависимости от выбора движка из-за огромного зоопарка железа и связанных с ними драйверов и API.
>>40802
>не захватывался экран на стрим
Странно, у меня с OBS в Godot ни разу проблемы не было на ветке 3.x. Работают все способы захвата без проблем, как, наверное, с любой OpenGL игрой. Хотя я не пробовал записывать полноэкранный режим, но вряд ли OBS с ним не справится (там куча опций на все случаи жизни). Скорее всего тот стример что-то не понял или использовал какой-то другой софт для стрима.
>физика тормозит на меньшем количестве объектов
Не проблема движка, а нехватка скорости ЦПУ. Если взять движок, у которого физика на ГПУ, проблем будет ещё больше из-за зоопарка видеокарт.
>>40790
Ты имеешь в виду скорость движений? Или расположение элементов GUI? Или что-то ещё?
Если скорость другая - это проблема того, что у твоих друзей другая частота кадров. Чтобы исправить её, ты должен умножать смещения на длительность кадра (delta). В Godot с этим проблем нет, как и в Unity.
Если интерфейс поломался - это проблема из-за другого разрешения экрана. Чтобы исправить её, нужно привязывать элементы экрана к процентам относительно сторон экрана, или использовать специальные контейнеры, которые автоматически размещают элементы GUI. В Godot с этим всё замечательно, а вот что там в Unity я так и не разобрался.
Если проблема с рендерингом - это может быть из-за другой видеокарты или драйвера видеокарты. Насколько я знаю, в Unity несколько разных пайплайнов для графики, у каждого свои особенности. В Godot 3.x таких пайплайнов всего два, оба на базе OpenGL: GLES2 и GLES3. В Godot 4.0 есть новые пайплайны Vulkan и Vulkan Mobile, а от GLES2 решили отказаться, оставив GLES3. У Godot есть какие-то проблемы с запуском на встроенных видеочипах ноутбуков, но в остальном, насколько я знаю, рендерер Godot стабилен, хотя результат может отличаться на десктопе, в вебе и на мобилках из-за отличий в железе и графических API. Ну, короче, проблемы со стороны графики неизбежны вне зависимости от выбора движка из-за огромного зоопарка железа и связанных с ними драйверов и API.
>>40802
Странно, у меня с OBS в Godot ни разу проблемы не было на ветке 3.x. Работают все способы захвата без проблем, как, наверное, с любой OpenGL игрой. Хотя я не пробовал записывать полноэкранный режим, но вряд ли OBS с ним не справится (там куча опций на все случаи жизни). Скорее всего тот стример что-то не понял или использовал какой-то другой софт для стрима.
Не проблема движка, а нехватка скорости ЦПУ. Если взять движок, у которого физика на ГПУ, проблем будет ещё больше из-за зоопарка видеокарт.
>играется ВООБЩЕ по-другому
Ты имеешь в виду скорость движений? Или расположение элементов GUI? Или что-то ещё?
Если скорость другая - это проблема того, что у твоих друзей другая частота кадров. Чтобы исправить её, ты должен умножать смещения на длительность кадра (delta). В Godot с этим проблем нет, как и в Unity.
Если интерфейс поломался - это проблема из-за другого разрешения экрана. Чтобы исправить её, нужно привязывать элементы экрана к процентам относительно сторон экрана, или использовать специальные контейнеры, которые автоматически размещают элементы GUI. В Godot с этим всё замечательно, а вот что там в Unity я так и не разобрался.
Если проблема с рендерингом - это может быть из-за другой видеокарты или драйвера видеокарты. Насколько я знаю, в Unity несколько разных пайплайнов для графики, у каждого свои особенности. В Godot 3.x таких пайплайнов всего два, оба на базе OpenGL: GLES2 и GLES3. В Godot 4.0 есть новые пайплайны Vulkan и Vulkan Mobile, а от GLES2 решили отказаться, оставив GLES3. У Godot есть какие-то проблемы с запуском на встроенных видеочипах ноутбуков, но в остальном, насколько я знаю, рендерер Godot стабилен, хотя результат может отличаться на десктопе, в вебе и на мобилках из-за отличий в железе и графических API. Ну, короче, проблемы со стороны графики неизбежны вне зависимости от выбора движка из-за огромного зоопарка железа и связанных с ними драйверов и API.
>>40802
>не захватывался экран на стрим
Странно, у меня с OBS в Godot ни разу проблемы не было на ветке 3.x. Работают все способы захвата без проблем, как, наверное, с любой OpenGL игрой. Хотя я не пробовал записывать полноэкранный режим, но вряд ли OBS с ним не справится (там куча опций на все случаи жизни). Скорее всего тот стример что-то не понял или использовал какой-то другой софт для стрима.
>физика тормозит на меньшем количестве объектов
Не проблема движка, а нехватка скорости ЦПУ. Если взять движок, у которого физика на ГПУ, проблем будет ещё больше из-за зоопарка видеокарт.
>>40802
Что ты имеешь в виду? Объясни.
На мой взгляд, Unity требовательнее, т.к. обязывает устанавливать стороннюю IDE для C#, выбирать пайплайн и ассеты для базового функционала... В Godot, напротив, ты просто запускаешь редактор, создаёшь проект, и сразу можешь следовать туториалам без какой-то особой подготовки, настройки, скачивания и установки кучи каких-то непонятных новичку вещей. Все необходимые вещи есть из коробки и работают, обычно, без проблем с настройками по умолчанию. Техническая подготовка нужна только если ты хочешь делать что-то необычное или писать код на каком-то стороннем языке, а не на GDScript.
>требовательнее к технической подготовке
Что ты имеешь в виду? Объясни.
На мой взгляд, Unity требовательнее, т.к. обязывает устанавливать стороннюю IDE для C#, выбирать пайплайн и ассеты для базового функционала... В Godot, напротив, ты просто запускаешь редактор, создаёшь проект, и сразу можешь следовать туториалам без какой-то особой подготовки, настройки, скачивания и установки кучи каких-то непонятных новичку вещей. Все необходимые вещи есть из коробки и работают, обычно, без проблем с настройками по умолчанию. Техническая подготовка нужна только если ты хочешь делать что-то необычное или писать код на каком-то стороннем языке, а не на GDScript.
>>40806
Проблема была с полноэкранным режимом в винде. Она же была проблемой скриншотов (когда сохранялся только первый кадр после запуска игры). С тех пор она уже исправлена. Там еще нашли забавный workaround запускать игру в разрешении 1920x1081. Можешь поискать по issue fullscreen windows
Само собой, но сам понимаешь когда стримят пару десятков игр, мало кто будет разбираться - просто пропустят как нерабочую.
Есть проблема с которой я до конца так и не разобрался. Когда после какого-то кол-ва физикбоди простой move_and_slide дает просадку, дискретно, вот еще нормально и уже все.
>Хотя я не пробовал записывать полноэкранный режим
Проблема была с полноэкранным режимом в винде. Она же была проблемой скриншотов (когда сохранялся только первый кадр после запуска игры). С тех пор она уже исправлена. Там еще нашли забавный workaround запускать игру в разрешении 1920x1081. Можешь поискать по issue fullscreen windows
>Скорее всего тот стример что-то не понял
Само собой, но сам понимаешь когда стримят пару десятков игр, мало кто будет разбираться - просто пропустят как нерабочую.
>Не проблема движка, а нехватка скорости ЦПУ.
Есть проблема с которой я до конца так и не разобрался. Когда после какого-то кол-ва физикбоди простой move_and_slide дает просадку, дискретно, вот еще нормально и уже все.
>>40810
Ой, да ладно, если только 3D в большом мире делаешь, а не типичную 2D платформеро-бродилку. Как будто каждый васян делает попенворлд 3D экшон ММО.
>>40809
Это я знаю, да. Это не проблема на самом деле, такое наблюдается во множестве игр на других движках. Поэтому ты либо реализуешь функцию скриншота непосредственно в игре, либо пусть делают скриншоты через оверлей стима, а не принтскрин->мспейнт... Windows может завтра опять переделать свой менеджер окон, и что теперь, игровым движкам снова адаптироваться?
Эта функция вроде делает несколько проверок коллизий за один вызов. Логично, что чем больше физических тел, тем сложнее поиск столкновений. Пробуй объединить множество неподвижных тел в один StaticBody, а композиции подвижных тел лучше объелинять в один RigidBody. Я пробовал запихивать до 1000 CollisionShape в один RigidBody и не испытывал проблем, а это всё-таки визуально большое количество. Но на практике, имхо, лучше чтобы физики было минимум... от неё всегда проблемы, в любой игре, на любом движке(
>в плане оптимизаций
Ой, да ладно, если только 3D в большом мире делаешь, а не типичную 2D платформеро-бродилку. Как будто каждый васян делает попенворлд 3D экшон ММО.
>>40809
>Она же была проблемой скриншотов (когда сохранялся только первый кадр после запуска игры).
Это я знаю, да. Это не проблема на самом деле, такое наблюдается во множестве игр на других движках. Поэтому ты либо реализуешь функцию скриншота непосредственно в игре, либо пусть делают скриншоты через оверлей стима, а не принтскрин->мспейнт... Windows может завтра опять переделать свой менеджер окон, и что теперь, игровым движкам снова адаптироваться?
>Когда после какого-то кол-ва физикбоди простой move_and_slide дает просадку, дискретно, вот еще нормально и уже все.
Эта функция вроде делает несколько проверок коллизий за один вызов. Логично, что чем больше физических тел, тем сложнее поиск столкновений. Пробуй объединить множество неподвижных тел в один StaticBody, а композиции подвижных тел лучше объелинять в один RigidBody. Я пробовал запихивать до 1000 CollisionShape в один RigidBody и не испытывал проблем, а это всё-таки визуально большое количество. Но на практике, имхо, лучше чтобы физики было минимум... от неё всегда проблемы, в любой игре, на любом движке(
>>37550
Скажи честно, по какой причине спрашивал? Тебе игра интересна или ты тот анон, который регулярно бампает мёртвые треды? Я подумываю вернуться к тому проекту в очередной раз и попробовать отрефакторить некоторые системы, возможно, довести механику строительства до играбельного состояния... хотя я по-прежнему не уверен, как именно она должна выглядеть.
>как прогресс?
Скажи честно, по какой причине спрашивал? Тебе игра интересна или ты тот анон, который регулярно бампает мёртвые треды? Я подумываю вернуться к тому проекту в очередной раз и попробовать отрефакторить некоторые системы, возможно, довести механику строительства до играбельного состояния... хотя я по-прежнему не уверен, как именно она должна выглядеть.
>>40814
В 2д бродилке я с тем же самым столкнулся. Но пока так и не разобрался с причиной. Возможно с какого-то количества данные перестают влезать в кэш и начинается при каждом сравнении двух объектов выгруза-загрузка. Потому что именно резкая просадка, не постепенное замедление с кол-вом. Хотя может быть так квадратичная сложность и выглядит. Еще может быть проблема не в самом move_and_slide, а в Area для поля зрения.
Но функцию захвата видео-то я не буду реализовать сам. А проблема была как я ее описал - у других участников нормально стримилась игра, а моя нет.
Ну да, это само собой разумеется.
>Ой, да ладно, если только 3D в большом мире делаешь, а не типичную 2D платформеро-бродилку.
В 2д бродилке я с тем же самым столкнулся. Но пока так и не разобрался с причиной. Возможно с какого-то количества данные перестают влезать в кэш и начинается при каждом сравнении двух объектов выгруза-загрузка. Потому что именно резкая просадка, не постепенное замедление с кол-вом. Хотя может быть так квадратичная сложность и выглядит. Еще может быть проблема не в самом move_and_slide, а в Area для поля зрения.
>Поэтому ты либо реализуешь функцию скриншота непосредственно в игре
Но функцию захвата видео-то я не буду реализовать сам. А проблема была как я ее описал - у других участников нормально стримилась игра, а моя нет.
>Windows может завтра опять переделать свой менеджер окон, и что теперь, игровым движкам снова адаптироваться?
Ну да, это само собой разумеется.
>>40826
Если неправильно использовать (умножать на эту величину дважды), то вместо компенсации эффекта может произойти его усиление. Некоторые API движка могут учитывать эту величину неявно - к ним дополнительно добавлять дельту нельзя. Смотри туториалы и документацию, скорее всего ты неправильно что-то понял.
>>40818
Кэш процессора?
Так у OBS несколько вариантов захвата для игр в полноэкранном режиме, что-то да подходит. Помню, помучился, выбирая режим для Overwatch, который на каком-то велосипеде работает, между прочим...
>не должно быть, ибо я ипользую Time.deltaTime
Если неправильно использовать (умножать на эту величину дважды), то вместо компенсации эффекта может произойти его усиление. Некоторые API движка могут учитывать эту величину неявно - к ним дополнительно добавлять дельту нельзя. Смотри туториалы и документацию, скорее всего ты неправильно что-то понял.
>>40818
>перестают влезать в кэш
Кэш процессора?
>функцию захвата видео
Так у OBS несколько вариантов захвата для игр в полноэкранном режиме, что-то да подходит. Помню, помучился, выбирая режим для Overwatch, который на каком-то велосипеде работает, между прочим...
Вкатился по чуток в годню, потыкался в 2д, вот щас про 3д читаю\смотрю и не втупаю, есть ли возможность в 3d GridMap как-то не ровности сделать?
>>40939
Что ты имеешь в виду? Смещение одного блока в сторону на дробное число клеток? Типа, сместить блок на 0.x одной клетки? Такой функции нет, но ты можешь просто сделать свои клетки в 1/0.x раза меньше - тогда ты сможешь расставлять блоки более свободно, чем по крупной сетке.
https://docs.godotengine.org/en/stable/classes/class_gridmap.html#class-gridmap-property-cell-size
Если же ты имеешь в виду визуально "неровные" блоки, то ты должен сам сделать дополнительный "неровный" меш и добавить его в MeshLibrary.
GridMap внутри использует оптимизации на базе MultiMeshInstance и обращений к серверам - рендеринга и физики. Если тебя не устраивает стандартный функционал GridMap и ты не можешь его расширить, то не так уж сложно написать собственный инструмент расстановки блоков по сетке на GDScript или C#.
https://docs.godotengine.org/en/stable/classes/class_multimeshinstance.html
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
>есть ли возможность в 3d GridMap как-то не ровности сделать?
Что ты имеешь в виду? Смещение одного блока в сторону на дробное число клеток? Типа, сместить блок на 0.x одной клетки? Такой функции нет, но ты можешь просто сделать свои клетки в 1/0.x раза меньше - тогда ты сможешь расставлять блоки более свободно, чем по крупной сетке.
https://docs.godotengine.org/en/stable/classes/class_gridmap.html#class-gridmap-property-cell-size
Если же ты имеешь в виду визуально "неровные" блоки, то ты должен сам сделать дополнительный "неровный" меш и добавить его в MeshLibrary.
GridMap внутри использует оптимизации на базе MultiMeshInstance и обращений к серверам - рендеринга и физики. Если тебя не устраивает стандартный функционал GridMap и ты не можешь его расширить, то не так уж сложно написать собственный инструмент расстановки блоков по сетке на GDScript или C#.
https://docs.godotengine.org/en/stable/classes/class_multimeshinstance.html
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
>>40939
Есть мнение что гридмап нафик не нужен и было даже голосование чтобы его выпилить из коры в аддоны (но оно не прошло). Он хорош для новичков, каких то игр попроще, для геймджемов, для вспомогательных инструментов если превращаешь 2д тайловую игру в 3д, для коллайдеров. Но вот когда я делал террейн с холмами, домики по гриду уже расставлять не очень удобно, а если еще захотеть, чтобы домики были выровнены не только по сетке, но и по 30 или 45 градусов - то вообще никак.
Но если у тебя что-то вроде 3д платформера с кубами, в духе майнкрафта. То можно использовать такой прием -когда шаг ячейки меньше размера куба. Тогда у тебя появляется возможность ставить, например, 1 метровый тайл на высоте 0, 0.25, 0.5 метров, что дает лесенку. Или как на пике, смешивать большие и малые тайлы, когда малые стоят как бы посередине больших.
Есть мнение что гридмап нафик не нужен и было даже голосование чтобы его выпилить из коры в аддоны (но оно не прошло). Он хорош для новичков, каких то игр попроще, для геймджемов, для вспомогательных инструментов если превращаешь 2д тайловую игру в 3д, для коллайдеров. Но вот когда я делал террейн с холмами, домики по гриду уже расставлять не очень удобно, а если еще захотеть, чтобы домики были выровнены не только по сетке, но и по 30 или 45 градусов - то вообще никак.
Но если у тебя что-то вроде 3д платформера с кубами, в духе майнкрафта. То можно использовать такой прием -когда шаг ячейки меньше размера куба. Тогда у тебя появляется возможность ставить, например, 1 метровый тайл на высоте 0, 0.25, 0.5 метров, что дает лесенку. Или как на пике, смешивать большие и малые тайлы, когда малые стоят как бы посередине больших.
Привет аноны, первый раз в треде. Начал делать один проект на LOVE2D, но понял, что я за неимением архитектурных навыков я потрачу больше времени на создание велосипедов или создание базовых функций (вроде нормального редактора карт, загрузки ассетов и прочего). Решил поменять инструмент на движок, ведь всё же хочется заниматься непосредственно логикой игры, а не программировать смену кадров анимации.
Думаю, годот мне подходит больше всего. В движках я больше всего ценю простоту и минимализм, непрегруженность интерфейса. Появилось пару вопросов относительно годота.
1. Как тут обстоит дела с 2Д анимациями? Как вообще это реализовано? Я могу и с тайлсета анимировать и с набора отдельных картинок?
2. Насколько просто скомпилировать и распространить exeшник?
3. Если ли встроенный контроль версий?
Думаю, годот мне подходит больше всего. В движках я больше всего ценю простоту и минимализм, непрегруженность интерфейса. Появилось пару вопросов относительно годота.
1. Как тут обстоит дела с 2Д анимациями? Как вообще это реализовано? Я могу и с тайлсета анимировать и с набора отдельных картинок?
2. Насколько просто скомпилировать и распространить exeшник?
3. Если ли встроенный контроль версий?
>>40978
Ты наверное имел в виду спрайтшит. Но вообще да, можешь анимировать и тайлсет, и со спрайтшита, и набор картинок.
Есть 2 способа
Первый это AnimatedSprite, его проще настроить, но он дает меньше контроля.
Второй это AnimationPlayer, который позволяет анимировать практически любое свойство в движке. К нему наворачивают еще AnimationTree, машины состояний, блендинг (смешивание анимаций) и т.д. Получается мощная конструкция. Как это выглядит примерно можно посмотреть тут https://www.youtube.com/watch?v=Xf2RduncoNU
Очень просто. Если ты не модифицируешь движок, ты пользуешься стандартными шаблонами экспорта. По сути ты нажимаешь кнопку "скачать", тебе скачивается пол гигабайта под все платформы, и потом ты нажимаешь "экспорт" и экспортируешь под винду, линукс, андроид и т.д. Есть нюансы с настройкой (иконки под винду), но это все легко поправить руками в крайнем случае.
В 3 кажется нет, в 4 будет.
Ну, просто создай гит репу в папке проекта пока.
Видел ассет но не пользовался и не знаю стоит ли рекомендовать https://godotengine.org/asset-library/asset/1410
>Я могу и с тайлсета анимировать
Ты наверное имел в виду спрайтшит. Но вообще да, можешь анимировать и тайлсет, и со спрайтшита, и набор картинок.
Есть 2 способа
Первый это AnimatedSprite, его проще настроить, но он дает меньше контроля.
Второй это AnimationPlayer, который позволяет анимировать практически любое свойство в движке. К нему наворачивают еще AnimationTree, машины состояний, блендинг (смешивание анимаций) и т.д. Получается мощная конструкция. Как это выглядит примерно можно посмотреть тут https://www.youtube.com/watch?v=Xf2RduncoNU
>Насколько просто скомпилировать и распространить exeшник?
Очень просто. Если ты не модифицируешь движок, ты пользуешься стандартными шаблонами экспорта. По сути ты нажимаешь кнопку "скачать", тебе скачивается пол гигабайта под все платформы, и потом ты нажимаешь "экспорт" и экспортируешь под винду, линукс, андроид и т.д. Есть нюансы с настройкой (иконки под винду), но это все легко поправить руками в крайнем случае.
>Если ли встроенный контроль версий?
В 3 кажется нет, в 4 будет.
Ну, просто создай гит репу в папке проекта пока.
Видел ассет но не пользовался и не знаю стоит ли рекомендовать https://godotengine.org/asset-library/asset/1410
>>41011
Понял, спасибо за ответ.
Думаю буду использовать годот. Правда один момент не понимаю, посмотрел гайд по настройке для пиксель-арта.
Выключил блюринг при импорте, поставил кратное разрешение(пик1) и растягивание(пик 2), но разрешение всё равно растягивает неправильно (пик 3). Что делать?
Понял, спасибо за ответ.
Думаю буду использовать годот. Правда один момент не понимаю, посмотрел гайд по настройке для пиксель-арта.
Выключил блюринг при импорте, поставил кратное разрешение(пик1) и растягивание(пик 2), но разрешение всё равно растягивает неправильно (пик 3). Что делать?
>>41035
https://www.reddit.com/r/godot/comments/fah25e/best_way_to_achieve_pixel_perfect_rendering/
Там еще пара пунктов написано
Включить Pixel Snap в свойствах проекта Project > Project Settings > Rendering > Quality > 2D > Use Pixel Snap
И отключить у спрайта Centered.
Предположу что так происходит если позиция твоего спрайта не в целых координатах стоит, например (13.23, 15.099). В принципе это можно из кода решить, если всегда округлять координаты. Но наверное pixel snap это же делает.
https://www.reddit.com/r/godot/comments/fah25e/best_way_to_achieve_pixel_perfect_rendering/
Там еще пара пунктов написано
Включить Pixel Snap в свойствах проекта Project > Project Settings > Rendering > Quality > 2D > Use Pixel Snap
И отключить у спрайта Centered.
Предположу что так происходит если позиция твоего спрайта не в целых координатах стоит, например (13.23, 15.099). В принципе это можно из кода решить, если всегда округлять координаты. Но наверное pixel snap это же делает.
>>41038
pixel snap включен, centered не стоит, координаты целые.
pixel snap включен, centered не стоит, координаты целые.
>>41035
Я еще попроверяю конечно, но вот еще идея - у тебя Fullscreen и 720p. А разрешение экрана у тебя небось 1080p, в 1,5 раза больше.
Я еще попроверяю конечно, но вот еще идея - у тебя Fullscreen и 720p. А разрешение экрана у тебя небось 1080p, в 1,5 раза больше.
>>41039
Точнее у тебя 768p.
Надо подумать как это фиксится.
Т.е. 720 растягиается до 768 и какие то пиксели выходят дублирующимися.
Точнее у тебя 768p.
Надо подумать как это фиксится.
Т.е. 720 растягиается до 768 и какие то пиксели выходят дублирующимися.
>>41044
1280*
1280*
>>41044
Да можно, просто непонятно надо ли это в этой игре - у него простой черный фон, можно просто леттербокс сделать. Наоборот выставлять игре разрешение экрана.
Да можно, просто непонятно надо ли это в этой игре - у него простой черный фон, можно просто леттербокс сделать. Наоборот выставлять игре разрешение экрана.
>>40961
Я тебе щас напишу решение, простое и очевидное для всех, кроме тебя (с).
И ты когда прочтёшь, то аж охуеешь как тот чувак из уральских пельменей "А что, так можно было?"
Итак, готов? Набрал воздуха в грудь? На стульчик присел? За подлокотники держишься?
Гридмап - это объект Spatial, следовательно его можно повернуть на любой нужный угол. Ты пытался все домики впихнуть в одну мапу, и разумеется всё оказалось слишком ровно, не по ландшафту. Но что если я скажу тебе, что в сцене может быть не один гридмап, а несколько, и каждый из них смещён и повёрнут, как тебе надо.
> Но вот когда я делал террейн с холмами, домики по гриду уже расставлять не очень удобно, а если еще захотеть, чтобы домики были выровнены не только по сетке, но и по 30 или 45 градусов - то вообще никак.
Я тебе щас напишу решение, простое и очевидное для всех, кроме тебя (с).
И ты когда прочтёшь, то аж охуеешь как тот чувак из уральских пельменей "А что, так можно было?"
Итак, готов? Набрал воздуха в грудь? На стульчик присел? За подлокотники держишься?
Гридмап - это объект Spatial, следовательно его можно повернуть на любой нужный угол. Ты пытался все домики впихнуть в одну мапу, и разумеется всё оказалось слишком ровно, не по ландшафту. Но что если я скажу тебе, что в сцене может быть не один гридмап, а несколько, и каждый из них смещён и повёрнут, как тебе надо.
>>41052
Сомневаюсь что это будет производительно. Ну и удобство редактирования будет сомнительное. Просто представь сколько прокликиваний надо будет чтобы добраться до нужного. А потом заметить что подвигал не тот.
Сомневаюсь что это будет производительно. Ну и удобство редактирования будет сомнительное. Просто представь сколько прокликиваний надо будет чтобы добраться до нужного. А потом заметить что подвигал не тот.
>>41054
В любом случае надо тестить. И желательно не на кубах, а на более хайполи модельках. Я же не вижу проблем. Гридмап работает на меш инстансах? Он это делает для производительности? Почему же производительность станет хуже, если гридмапов будет больше одного?
В редакторе всё есть для удобства редактирования. Часть нод можно сгруппировать. Другую часть сделать с невыбираемыми потомками. Не вижу проблемы.
> Сомневаюсь что это будет производительно.
В любом случае надо тестить. И желательно не на кубах, а на более хайполи модельках. Я же не вижу проблем. Гридмап работает на меш инстансах? Он это делает для производительности? Почему же производительность станет хуже, если гридмапов будет больше одного?
> удобство редактирования будет сомнительное
В редакторе всё есть для удобства редактирования. Часть нод можно сгруппировать. Другую часть сделать с невыбираемыми потомками. Не вижу проблемы.
42 Кб, 1269x673Причём неправильно скейлится оно только в фуллскрине, в оконном режиме всё выглдяит нормально.
>>41046
что за леттербокс?
>>41046
что за леттербокс?
>>41056
Ну, выставить окну разрешение экрана, а сверху и снизу добавить черных полос.
Ну, выставить окну разрешение экрана, а сверху и снизу добавить черных полос.
>>41052
Это имеет смысл только в двух случаях:
1. Ты собираешь каждый домик из большого количества отдельных блоков. Один такой домик = один гридмап. Гридмап упрощает строительство домика и одновременно оптимизирует рендеринг с физикой.
2. У тебя есть посёлки, в каждом из них много домов, но дома эти расставлены по сетке. Один посёлок = один гридмап. Сомнительная ситуация.
>>41055
Каждый гридмап - отдельная сущность. Они никак друг с другом не взаимодействуют. Если у тебя один домик в гридмапе, он ни с чем не будет объединяться, даже если у тебя есть такой же домик в другом гридмапе. Так что гридмап имеет смысл только если у тебя много одинаковых объектов на сетке в одном компактном месте (чанк).
>в сцене может быть не один гридмап, а несколько, и каждый из них смещён и повёрнут, как тебе надо.
Это имеет смысл только в двух случаях:
1. Ты собираешь каждый домик из большого количества отдельных блоков. Один такой домик = один гридмап. Гридмап упрощает строительство домика и одновременно оптимизирует рендеринг с физикой.
2. У тебя есть посёлки, в каждом из них много домов, но дома эти расставлены по сетке. Один посёлок = один гридмап. Сомнительная ситуация.
>>41055
>Гридмап работает на меш инстансах? Он это делает для производительности? Почему же производительность станет хуже, если гридмапов будет больше одного?
Каждый гридмап - отдельная сущность. Они никак друг с другом не взаимодействуют. Если у тебя один домик в гридмапе, он ни с чем не будет объединяться, даже если у тебя есть такой же домик в другом гридмапе. Так что гридмап имеет смысл только если у тебя много одинаковых объектов на сетке в одном компактном месте (чанк).
>>41060
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#stretch-shrink
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#stretch-shrink
>If, for example, you set Shrink to 4 and leave Stretch Mode on Disabled, each unit in your scene will correspond to 4×4 pixels on the screen.
>>41056
Есть еще одна идея - сделай чтобы у спрайта были четные ширина и высота, если они нечетные.
Есть еще одна идея - сделай чтобы у спрайта были четные ширина и высота, если они нечетные.
>>41055
Потому что каждый будет со своими дроуколлами, со своим оверхедом и обходами структур, что у него там внутри, octree?
>Почему же производительность станет хуже, если гридмапов будет больше одного?
Потому что каждый будет со своими дроуколлами, со своим оверхедом и обходами структур, что у него там внутри, octree?
>>41044
Кажется в годоте нельзя поменять разрешение экрана, там не настоящий эксклюхивный фулскрин, а окно без рамки. То есть не как в старых играх которые мигают экраном когда физически меняют разрешение.
Кажется в годоте нельзя поменять разрешение экрана, там не настоящий эксклюхивный фулскрин, а окно без рамки. То есть не как в старых играх которые мигают экраном когда физически меняют разрешение.
104 Кб, mp4,800x600, 0:08
>>41069
Так я и не хочу растянуть картинку, я хочу поменять разрешение экрана пользователя. Неужели нельзя этого сделать (программно или интерфейсно)?
Так я и не хочу растянуть картинку, я хочу поменять разрешение экрана пользователя. Неужели нельзя этого сделать (программно или интерфейсно)?
>>41070
Пожалуйста, не надо так делать.
Во-первых, не все режимы поддерживаются всеми мониторами. Если приложение запрашивает неподдерживаемый режим, в лучшем случае приложение не сможет нормально работать, в худшем произойдёт сбой работы монитора и пользователь будет вынужден перезагружать компьютер.
Во-вторых, некоторые мониторы имеют проблемы с переключением даже на поддерживаемые режимы. Особенно это касается старых мониторов с высыхающими конденсаторами или что у них там изнашивается. Лично у меня при переключении режимов иногда происходит такой глюк - монитор зависает в бесконечном переключении режимов и никак не реагирует, приходится перезагружать весь компьютер вместе с монитором.
В-третьих, переключение режима монитора сбивает настройки других окон приложений, во всяком случае на Windows. После игры в разрешении 800x600 потом ВСЕ виндовые окна скукожены в левый верхний угол, приходится вручную каждое окошко раскукоживать и располагать как привык.
В-четвёртых, я не уверен на счёт этого, но подозреваю, что люди с плохим зрением или слухом пользуются различными вспомогательными окнами, которые работают поверх всех остальных приложений, включая игры. Внезапное переключение разрешения монитора может сбивать работу таких приложений. Для примера, просто посмотри как кукожит оверлей стима - работать с ним на маленьком разрешении невозможно, т.к. оно для этого не рассчитано. А представь, что пользователь зависит от этого приложения...
Короче, оставь монитор пользователя в покое. Это прошлый век. Даже раньше был целый зоопарк мониторов, а сейчас тем более. Скажем, пользователь с ультравайд 4К монитором наверняка будет очень недоволен, что ты пытаешься переключить его монитор в какое-то древнее убожество...
>я хочу поменять разрешение экрана пользователя
Пожалуйста, не надо так делать.
Во-первых, не все режимы поддерживаются всеми мониторами. Если приложение запрашивает неподдерживаемый режим, в лучшем случае приложение не сможет нормально работать, в худшем произойдёт сбой работы монитора и пользователь будет вынужден перезагружать компьютер.
Во-вторых, некоторые мониторы имеют проблемы с переключением даже на поддерживаемые режимы. Особенно это касается старых мониторов с высыхающими конденсаторами или что у них там изнашивается. Лично у меня при переключении режимов иногда происходит такой глюк - монитор зависает в бесконечном переключении режимов и никак не реагирует, приходится перезагружать весь компьютер вместе с монитором.
В-третьих, переключение режима монитора сбивает настройки других окон приложений, во всяком случае на Windows. После игры в разрешении 800x600 потом ВСЕ виндовые окна скукожены в левый верхний угол, приходится вручную каждое окошко раскукоживать и располагать как привык.
В-четвёртых, я не уверен на счёт этого, но подозреваю, что люди с плохим зрением или слухом пользуются различными вспомогательными окнами, которые работают поверх всех остальных приложений, включая игры. Внезапное переключение разрешения монитора может сбивать работу таких приложений. Для примера, просто посмотри как кукожит оверлей стима - работать с ним на маленьком разрешении невозможно, т.к. оно для этого не рассчитано. А представь, что пользователь зависит от этого приложения...
Короче, оставь монитор пользователя в покое. Это прошлый век. Даже раньше был целый зоопарк мониторов, а сейчас тем более. Скажем, пользователь с ультравайд 4К монитором наверняка будет очень недоволен, что ты пытаешься переключить его монитор в какое-то древнее убожество...
2 Кб, 196x124>>41070
Это тебе несильно поможет, потому что в таком случае растягивать будет матрица монитора на те же несущесвтующие пиксели.
Я все же думаю что решение должно быть таким.
Это тебе несильно поможет, потому что в таком случае растягивать будет матрица монитора на те же несущесвтующие пиксели.
Я все же думаю что решение должно быть таким.
11 Кб, 1360x768>>41069
>>41071
Просто ситуация такая
Где-то у 70% людей 1920х1080, 1280х720 или другое true 16:9.
У остальных всякие 1366х768, 3:4, 16:10 и прочее, а это 30%, довольно большая часть аудтории.
Мне видятся возможными только три варианты (добавьте свои, если я ошибаюсь).
1) Поставить текущие скейлы. В итоге у всех с 16:9 - нормальные пиксели, у остальных 30% - скукоженные, а это неприемлемо.
2) Мануально изменять разрешение, на ближайшее поддерживаемое 16:9. Меньше всего геморроя.
3) Скейлить, как пикрил, с полосками, отцентрировать картинку, гуи и все визуальные элементы. Проблема в том, что придётся настраивать offse вручную для множества различных мониторов
>>41071
Просто ситуация такая
Где-то у 70% людей 1920х1080, 1280х720 или другое true 16:9.
У остальных всякие 1366х768, 3:4, 16:10 и прочее, а это 30%, довольно большая часть аудтории.
Мне видятся возможными только три варианты (добавьте свои, если я ошибаюсь).
1) Поставить текущие скейлы. В итоге у всех с 16:9 - нормальные пиксели, у остальных 30% - скукоженные, а это неприемлемо.
2) Мануально изменять разрешение, на ближайшее поддерживаемое 16:9. Меньше всего геморроя.
3) Скейлить, как пикрил, с полосками, отцентрировать картинку, гуи и все визуальные элементы. Проблема в том, что придётся настраивать offse вручную для множества различных мониторов
>>41074
Не, это можно посчитать автоматически как (window_size-viewport_size) / 2, только конкретные переменные сейчас не подскажу.
>Проблема в том, что придётся настраивать offse вручную для множества различных мониторов
Не, это можно посчитать автоматически как (window_size-viewport_size) / 2, только конкретные переменные сейчас не подскажу.
19 Кб, 1201x470>>41072
Двачую.
>>41067
Я думаю, тебе вот так нужно сделать: пикрил.
Тогда у тебя будут пиксели 4x4, чёткие и без перетяжек.
Поля будут расширяться при увеличении разрешения экрана.
>>41074
Но в Terraria ты можешь скейлить на любую величину с 0.6 до 2.0 с шагом 0.01, при этом на мобилках, где полный зоопарк разрешений. И это выглядит нормально.
Тебе - может быть (вряд ли). Пользователю - определённо нет (личный опыт).
У меня, если что, 16:10. Не испытываю проблем с пикселями, если игра не пытается устанавливать какое-то стрёмное разрешение экрана.
Не придётся, ведь ты сидишь на Godot, а не на какой-нибудь юнити (подмигивает).
>Я все же думаю что решение должно быть таким.
Двачую.
>>41067
Я думаю, тебе вот так нужно сделать: пикрил.
Тогда у тебя будут пиксели 4x4, чёткие и без перетяжек.
Поля будут расширяться при увеличении разрешения экрана.
>>41074
>у остальных 30% - скукоженные, а это неприемлемо.
Но в Terraria ты можешь скейлить на любую величину с 0.6 до 2.0 с шагом 0.01, при этом на мобилках, где полный зоопарк разрешений. И это выглядит нормально.
>Меньше всего геморроя.
Тебе - может быть (вряд ли). Пользователю - определённо нет (личный опыт).
У меня, если что, 16:10. Не испытываю проблем с пикселями, если игра не пытается устанавливать какое-то стрёмное разрешение экрана.
>придётся настраивать offse вручную для множества различных мониторов
Не придётся, ведь ты сидишь на Godot, а не на какой-нибудь юнити (подмигивает).
>>41075
Хорошо, убедил. Оцени тогда алгоритм действий и правильно ли я всё понял:
У нас стоит width-height 320x180, включенный фулл скрин, нет stretch и shrink 4 по умолчанию. Где-нибудь в коде у нас проверяется, какое сейчас разрешение окна. Если оно 16:9, допустим 1920х1080 ил 1280х720, то мы подбираем правильный shrink, 4 или 6 (его же можно изменить программно, да?)
Если же разрешение иное, то у нас объекты и гуй двигается на windows h - viewport h / 2.
Хорошо, убедил. Оцени тогда алгоритм действий и правильно ли я всё понял:
У нас стоит width-height 320x180, включенный фулл скрин, нет stretch и shrink 4 по умолчанию. Где-нибудь в коде у нас проверяется, какое сейчас разрешение окна. Если оно 16:9, допустим 1920х1080 ил 1280х720, то мы подбираем правильный shrink, 4 или 6 (его же можно изменить программно, да?)
Если же разрешение иное, то у нас объекты и гуй двигается на windows h - viewport h / 2.
>>41078
https://docs.godotengine.org/en/stable/classes/class_panel.html
Ну так читай документацию, туториалы. Быстрее найдёшь ответ, чем задавать здесь и ждать, когда мы прочитаем и ответим.
>>41077
У ноды Viewport точно всё можно менять на ходу.
>что за panel?
https://docs.godotengine.org/en/stable/classes/class_panel.html
>Panel is a Control that displays an opaque background. It's commonly used as a parent and container for other types of Control nodes.
>Простой первый раз godot юзаю
Ну так читай документацию, туториалы. Быстрее найдёшь ответ, чем задавать здесь и ждать, когда мы прочитаем и ответим.
>>41077
>его же можно изменить программно, да?
У ноды Viewport точно всё можно менять на ходу.
12,6 Мб, webm,1920x1080, 0:34
>>40816
Просто увидел видео, стало интересно делалось ли дальше. Так то у меня тоже валяются проекты разной недоделанности, которые забросил из-за малого интереса к ним.
>Скажи честно, по какой причине спрашивал?
Просто увидел видео, стало интересно делалось ли дальше. Так то у меня тоже валяются проекты разной недоделанности, которые забросил из-за малого интереса к ним.
>>41079
ну я и пошёл смотрть туториал, а там с самого начала ( с разрешения) ни как у меня, у него норм все скейлится видимо монитор 16:9.
ну я и пошёл смотрть туториал, а там с самого начала ( с разрешения) ни как у меня, у него норм все скейлится видимо монитор 16:9.
>>41081
О, я тоже пробовал сделать модель самолёта: >>832864 →
Разница в том, что в одном проекте по задумке нужно строить из отдельных блоков-модулей летающую базу/дом (удобнее всего будет дирижабль, иначе нужен автопилот), чтобы путешествовать от куска летающей суши до другого куска в поиске ресурсов (ресурсы кончаются -> остров медленно рушится в пропасть -> пора валить), а во втором случае я просто попытался повторить аркадный самолёт как в GTA SA, по памяти...
Больше всего раздражает, что я не могу даже просто придумать что-то интересно выглядящее, не говоря уж о том, чтобы нарисовать и смоделировать... Предположим, что картинки и модельки можно взять бесплатные на первое время, но чтобы что-то взять, нужно сначала придумать, что ты хочешь взять... Тот же летающий дирижабль. Из каких блоков он должен состоять, чтобы не выглядеть летающей коробкой из-под обуви с дырками? Я разные варианты пробовал - всё фигня какая-то получается, у всего нахожу существенные недостатки. Летающие острова - вообще хрен знает как их сделать красиво (с учётом процедурности). Город и дома без строго квадратной сетки? Как такое возможно?! Вообще в голове не укладывается, как люди такое придумывают. Как им в голову такое приходит...
Правильно мне психиатр в детстве сказал, что у меня фантазии нет. Воображение работает хорошо, а вот придумать что-то новое - каждый раз проблема.
О, я тоже пробовал сделать модель самолёта: >>832864 →
Разница в том, что в одном проекте по задумке нужно строить из отдельных блоков-модулей летающую базу/дом (удобнее всего будет дирижабль, иначе нужен автопилот), чтобы путешествовать от куска летающей суши до другого куска в поиске ресурсов (ресурсы кончаются -> остров медленно рушится в пропасть -> пора валить), а во втором случае я просто попытался повторить аркадный самолёт как в GTA SA, по памяти...
Больше всего раздражает, что я не могу даже просто придумать что-то интересно выглядящее, не говоря уж о том, чтобы нарисовать и смоделировать... Предположим, что картинки и модельки можно взять бесплатные на первое время, но чтобы что-то взять, нужно сначала придумать, что ты хочешь взять... Тот же летающий дирижабль. Из каких блоков он должен состоять, чтобы не выглядеть летающей коробкой из-под обуви с дырками? Я разные варианты пробовал - всё фигня какая-то получается, у всего нахожу существенные недостатки. Летающие острова - вообще хрен знает как их сделать красиво (с учётом процедурности). Город и дома без строго квадратной сетки? Как такое возможно?! Вообще в голове не укладывается, как люди такое придумывают. Как им в голову такое приходит...
Правильно мне психиатр в детстве сказал, что у меня фантазии нет. Воображение работает хорошо, а вот придумать что-то новое - каждый раз проблема.
>>41077
Знаешь, я тут подумал - лучше всего будет сделать опцию в настройках для увеличения размера пикселей в любое количество раз. И ещё дополнительная галка для того, чтобы переключить режим "растягивания пикселей" под произвольное разрешение, если игроку не нравится играть с чёрными полями по краю экрана и при этом он не против "перетянутых" пикселей. Можно сделать даже хоткеи для настройки в процессе игры, как бывает в некоторых играх и эмуляторах.
Кстати, я вспомнил, что встречаются дисплеи 1600x900. В твоём случае это shrink = 5.
CenterContainer не забудь задать Grow Direction, чтобы он правильно по центру экрана был. Якори должны быть в центре экрана (0.5, есть кнопка в верхнем меню, Layout > Center).
>мы подбираем правильный shrink, 4 или 6
Знаешь, я тут подумал - лучше всего будет сделать опцию в настройках для увеличения размера пикселей в любое количество раз. И ещё дополнительная галка для того, чтобы переключить режим "растягивания пикселей" под произвольное разрешение, если игроку не нравится играть с чёрными полями по краю экрана и при этом он не против "перетянутых" пикселей. Можно сделать даже хоткеи для настройки в процессе игры, как бывает в некоторых играх и эмуляторах.
Кстати, я вспомнил, что встречаются дисплеи 1600x900. В твоём случае это shrink = 5.
CenterContainer не забудь задать Grow Direction, чтобы он правильно по центру экрана был. Якори должны быть в центре экрана (0.5, есть кнопка в верхнем меню, Layout > Center).
>>41087
Я не знаю, что там у тебя с движением, но вот так можно добиться чёткого попиксельного смещения: Vector2.round() - без этого могут наблюдаться артефакты. В Godot 4.0 вроде будут целочисленные векторы, тогда округление не понадобится.
На видео есть артефакты из-за записи и сжатия.
Я не знаю, что там у тебя с движением, но вот так можно добиться чёткого попиксельного смещения: Vector2.round() - без этого могут наблюдаться артефакты. В Godot 4.0 вроде будут целочисленные векторы, тогда округление не понадобится.
На видео есть артефакты из-за записи и сжатия.
>>41087 >>41088
Не-не-не, вот метод лучше, нужно через ViewportTexture выводить картинку из Viewport в TextureRect, тогда контроля за отображением будет куда больше, чем с ViewportContrainer. Вообще, ViewportContrainer очень огорчает своими ограничениями, непонятно, зачем он вообще такой ограниченный нужен. Юзайте текстуру и будет вам счастье. Её можно растянуть на весь экран с созданием аккуратных полей, хотя пиксели тогда, наверное, будут растягиваться на дробное число, но на моём экране визуально всё норм, и я не вижу причины не сделать такую опцию в настройках игры.
Если честно, я вообще не понимаю всей этой темы с "pixel perfect" графикой, поскольку на современных дисплеях эти самые пиксели нихрена не разглядишь с нормального расстояния. Вот у меня дисплей 2008 года примерно, думаете я вижу пиксели? Да нифига, нужно с лупой разглядывать матрицу, чтобы различить пиксели друг от друга. А на современных дисплеях должно быть ещё круче... Так что если у кого-то пиксельарт растянуло на 1 пиксель больше, чем нужно, то я этого вообще не замечу, если меня носом не ткнуть в этот пиксель. Есть ли смысл так париться в таком случае?
Не-не-не, вот метод лучше, нужно через ViewportTexture выводить картинку из Viewport в TextureRect, тогда контроля за отображением будет куда больше, чем с ViewportContrainer. Вообще, ViewportContrainer очень огорчает своими ограничениями, непонятно, зачем он вообще такой ограниченный нужен. Юзайте текстуру и будет вам счастье. Её можно растянуть на весь экран с созданием аккуратных полей, хотя пиксели тогда, наверное, будут растягиваться на дробное число, но на моём экране визуально всё норм, и я не вижу причины не сделать такую опцию в настройках игры.
Если честно, я вообще не понимаю всей этой темы с "pixel perfect" графикой, поскольку на современных дисплеях эти самые пиксели нихрена не разглядишь с нормального расстояния. Вот у меня дисплей 2008 года примерно, думаете я вижу пиксели? Да нифига, нужно с лупой разглядывать матрицу, чтобы различить пиксели друг от друга. А на современных дисплеях должно быть ещё круче... Так что если у кого-то пиксельарт растянуло на 1 пиксель больше, чем нужно, то я этого вообще не замечу, если меня носом не ткнуть в этот пиксель. Есть ли смысл так париться в таком случае?
>>41087
>>41088
>>41092
За твои(или ваши) ответы конечно спасибо, но я вчера только освоился как кинетикБоди двигать, я не думаю, что мне до всяких контейнеров ещё далеко. В love2d было проще в этом плане, там можно было ставить эксклюзивное разрешение экрана, но это фреймворк и никаких инструментов не было, приходилось самому даже загрузку ресурсов парсером писать. Эх, опять всё с нуля изучать.
>>41092
Да, я сразу замечаю, прям в глаза бросается, плюс там не один пиксель, а паттерн целый, в особенности заметно во время дизеринга.
Короче пойду тогда какой-нибудь прототип пилить чтобы в целом в движке разобраться. Удобно, кстати, что доки можно прям по клику в редакторе посмотреть. Правда, думаю, разработку это на месяц-другой затянет. На самом деле было бы замечательно, если бы был кто-нибудь, кому я могу написать в телегу или дс, чтобы не засирать тред вопросами. Гуглить я конечно умею и английский с1, но иногда можно намного быстрее решить проблему задав прямой вопрос, чем формулировать запрос и разбираться.
>>41088
>>41092
За твои(или ваши) ответы конечно спасибо, но я вчера только освоился как кинетикБоди двигать, я не думаю, что мне до всяких контейнеров ещё далеко. В love2d было проще в этом плане, там можно было ставить эксклюзивное разрешение экрана, но это фреймворк и никаких инструментов не было, приходилось самому даже загрузку ресурсов парсером писать. Эх, опять всё с нуля изучать.
>>41092
>Есть ли смысл так париться в таком случае?
Да, я сразу замечаю, прям в глаза бросается, плюс там не один пиксель, а паттерн целый, в особенности заметно во время дизеринга.
Короче пойду тогда какой-нибудь прототип пилить чтобы в целом в движке разобраться. Удобно, кстати, что доки можно прям по клику в редакторе посмотреть. Правда, думаю, разработку это на месяц-другой затянет. На самом деле было бы замечательно, если бы был кто-нибудь, кому я могу написать в телегу или дс, чтобы не засирать тред вопросами. Гуглить я конечно умею и английский с1, но иногда можно намного быстрее решить проблему задав прямой вопрос, чем формулировать запрос и разбираться.
>>41189
Пилил, но не игру, а утилиты, которые соединяются по сети с другими, в вариантах годот к годоту, годот к клиенту на андроиде, годот к серверу на жабаскрипте через вебсокеты. Все стабильно, нра.
Пилил, но не игру, а утилиты, которые соединяются по сети с другими, в вариантах годот к годоту, годот к клиенту на андроиде, годот к серверу на жабаскрипте через вебсокеты. Все стабильно, нра.
>>41134
Да это одна из самых простых частей, на самом деле.
https://docs.godotengine.org/en/stable/tutorials/ui/gui_containers.html
Ничего страшного, пиши здесь, у нас соревнование с юнити - кто больше тредов создаст.
>>41189
Я щупал тестовый проект с мультиплеером. Вроде работал, но я не разбирался.
>>41230
Круто, а я хотел бы сделать клиент чатбота на Godot с мозгами на локальном сервере.
>до всяких контейнеров ещё далеко
Да это одна из самых простых частей, на самом деле.
https://docs.godotengine.org/en/stable/tutorials/ui/gui_containers.html
>чтобы не засирать тред вопросами
Ничего страшного, пиши здесь, у нас соревнование с юнити - кто больше тредов создаст.
>>41189
Я щупал тестовый проект с мультиплеером. Вроде работал, но я не разбирался.
>>41230
Круто, а я хотел бы сделать клиент чатбота на Godot с мозгами на локальном сервере.
>>41280
Пока не смотрел.
Пока не смотрел.
>а это одна из самых простых частей, на самом деле.
Надеюсь, я пока-что даже не буду чекать, чтобы не забивать голову, пока не дойду до этого места в туториале.
Обучение, кстати, идёт "полным" ходом. Смотрю видео-туториал, автор сделал перемещение за 3 минуты, но оно мне не понравилось, решил реализовать своё. Потратил 8 часов, переписывая несколько раз. В итоге, всё работает просто идеально, но вангую что это говнокод и можно было бы найти намного более элегантное решение. Да и быстрее это всё сделать.
57 Кб, 861x861Ананас, объясните доступно или на примере всего пара вещей, а именно:
1) Для чего используете Классы GScripts?
2) Можно пример использования своих классов и их наследования в Godot?
Хочу разобраться с этим, но в голову не приходит для чего применить всё это.
1) Для чего используете Классы GScripts?
2) Можно пример использования своих классов и их наследования в Godot?
Хочу разобраться с этим, но в голову не приходит для чего применить всё это.
>>41341
Делаешь класс Enemy с логикой ходьбы/стрельбы/етц. Потом пилишь подкласс с extend Enemy и допиливаешь в нем тип стрельбы например. Один может с шотганом быть, другой с пулеметом, третий ходить чуть иначе.
Нужно это чтобы не копипастить навигацию 2 или больше раз.
Делаешь класс Enemy с логикой ходьбы/стрельбы/етц. Потом пилишь подкласс с extend Enemy и допиливаешь в нем тип стрельбы например. Один может с шотганом быть, другой с пулеметом, третий ходить чуть иначе.
Нужно это чтобы не копипастить навигацию 2 или больше раз.
>>41341
В первую очередь для статической типизации.
Чтобы ловить потенциальные ошибки, когда пишешь get_all_guns() а в ней случайно вернул Bullet вместо Gun.
В первую очередь для статической типизации.
Чтобы ловить потенциальные ошибки, когда пишешь get_all_guns() а в ней случайно вернул Bullet вместо Gun.
>>41319
Пости код сюда, оценим. Там же не 1500 строк?
>>41341
Это ООП. Ты ООП знаешь? Вот это - ООП.
Проще будет, если ты освоишь ООП. Тогда примеры использования в Godot будут тебе очевидны.
>>41369
Вот это лучше решить через композицию классов, чем через наследование. Тип оружия - отдельный класс, ходьба - отдельный класс. Иначе потом задолбаешься менять дерево наследований...
>Потратил 8 часов
>перемещение
>вангую что это говнокод
Пости код сюда, оценим. Там же не 1500 строк?
>>41341
>Классы GScripts
Это ООП. Ты ООП знаешь? Вот это - ООП.
>пример использования
Проще будет, если ты освоишь ООП. Тогда примеры использования в Godot будут тебе очевидны.
>>41369
>Один может с шотганом быть, другой с пулеметом, третий ходить чуть иначе.
Вот это лучше решить через композицию классов, чем через наследование. Тип оружия - отдельный класс, ходьба - отдельный класс. Иначе потом задолбаешься менять дерево наследований...
>>41406
Я имею в виду, не нужно скатываться в полное ЕЦС и разделять всё на кучку компонентов. Однако в ООП кроме наследования есть ещё композиция и агрегация. И в ряде случаев они намного лучше, чем наследование. Сложно привести конкретные примеры...
Блин, реально сложно. По сути любую задачу наследования можно решить через композицию, при этом с точки зрения геймдева это будет лучше, чем связывать себя ограничениями наследования.
В своих собственных проектах я пришёл к выводу, что если бы я не использовал наследование, некоторые вещи было бы проще сделать...
Ну, вот вам пока картинки. Пойду разберусь в теме.
Я имею в виду, не нужно скатываться в полное ЕЦС и разделять всё на кучку компонентов. Однако в ООП кроме наследования есть ещё композиция и агрегация. И в ряде случаев они намного лучше, чем наследование. Сложно привести конкретные примеры...
Блин, реально сложно. По сути любую задачу наследования можно решить через композицию, при этом с точки зрения геймдева это будет лучше, чем связывать себя ограничениями наследования.
В своих собственных проектах я пришёл к выводу, что если бы я не использовал наследование, некоторые вещи было бы проще сделать...
Ну, вот вам пока картинки. Пойду разберусь в теме.
Вот тут некий адепт ООП защищает наследование:
https://youtu.be/i9QLHpbyUyw
Сразу говорю: он заблуждается.
Его примеры:
1. Программист и уборщица "наследуются" от общего для них класса сотрудник - сотрудник имеет метод для получения зарплаты, а программист и уборщица - необходимые конкретной роли навыки.
2. Условный дуб наследуется от дерева, дерево наследуется от растения; аналогично с животными.
Почему его примеры ошибочны?
1. Он сам предложил ситуацию, когда уборщица повышается до программиста. Вот только в системе наследования ООП это невозможно, лол! В реальности не существует никакого наследования. Объекты проще всего воспринимать не как наследники свойств категорий, а как композиции свойств. Т.е. программист - это человек, у которого есть навыки программирования, а уборщица - это человек с навыками уборщицы. Если мы хотим перевести уборщицу на должность программиста, мы с помощью агрегации даём уборщице навык программирования и она теперь может выполнять роль программиста ничуть не хуже того, кто был программистом изначально.
2. Пример из биологии тоже в корне неправильный, потому что даже в реальной биологии классификацию довольно часто приходится изменять, когда биологи внезапно открывают некие новые свойства уже известных растений и животных. То есть в реальности, когда мы смотрим на растение или животное, мы видим некий набор свойств и не более того. Мы можем мысленно представить себе некую иерархию свойств, но это только наша выдумка. Особенно явно видны недостатки концепции наследования в биологии на примере паразитов: предки паразитов в прошлом имели БОЛЬШЕ свойств и методов, но в результате эволюции утратили эти свойства, став полностью зависимыми от организма-носителей. Их предки были зрячими, например, а они теперь слепы. Т.е. опять же возвращаемся к композиции/агрегации: если мы хотим сделать из клетки вирус, мы меняем её набор свойств (лишаем клеточной оболочки, органелл и т.д.) и получаем желаемый результат без проблем наследования (когда у потомка есть неиспользуемые свойства предка, или когда приходится перезаписывать методы предка).
Возможно, в обычном программировании это всё не так очевидно. Но в геймдеве мы не просто код пишем, мы моделируем реальный мир или что-то похожее на реальный мир. И пытаясь применить наследование к реальному миру, мы вставляем себе палки в колёса, потому что наследование в реальном мире не существует, кроме как абстрактная концепция в мыслях людей.
Так что когда в следующий раз захочешь сделать кошку наследником млекопитающего - НЕ ЕШ, ПОДУМОЙ: будет лучше наделить кошку набором навыков и свойств, характерных для кошки, которые в будущем можно использовать и для других животных.
При этом это всё не касается ЕЦС, это всё ещё старое-доброе ООП с объектами как контейнерами данных и методов, к которым можно обращаться по ссылке на кучу, но при этом объекты собираются из других объектов и могут при необходимости разбираться или пересобираться (как в десигн-тайм, так и в рантайме).
https://youtu.be/i9QLHpbyUyw
Сразу говорю: он заблуждается.
Его примеры:
1. Программист и уборщица "наследуются" от общего для них класса сотрудник - сотрудник имеет метод для получения зарплаты, а программист и уборщица - необходимые конкретной роли навыки.
2. Условный дуб наследуется от дерева, дерево наследуется от растения; аналогично с животными.
Почему его примеры ошибочны?
1. Он сам предложил ситуацию, когда уборщица повышается до программиста. Вот только в системе наследования ООП это невозможно, лол! В реальности не существует никакого наследования. Объекты проще всего воспринимать не как наследники свойств категорий, а как композиции свойств. Т.е. программист - это человек, у которого есть навыки программирования, а уборщица - это человек с навыками уборщицы. Если мы хотим перевести уборщицу на должность программиста, мы с помощью агрегации даём уборщице навык программирования и она теперь может выполнять роль программиста ничуть не хуже того, кто был программистом изначально.
2. Пример из биологии тоже в корне неправильный, потому что даже в реальной биологии классификацию довольно часто приходится изменять, когда биологи внезапно открывают некие новые свойства уже известных растений и животных. То есть в реальности, когда мы смотрим на растение или животное, мы видим некий набор свойств и не более того. Мы можем мысленно представить себе некую иерархию свойств, но это только наша выдумка. Особенно явно видны недостатки концепции наследования в биологии на примере паразитов: предки паразитов в прошлом имели БОЛЬШЕ свойств и методов, но в результате эволюции утратили эти свойства, став полностью зависимыми от организма-носителей. Их предки были зрячими, например, а они теперь слепы. Т.е. опять же возвращаемся к композиции/агрегации: если мы хотим сделать из клетки вирус, мы меняем её набор свойств (лишаем клеточной оболочки, органелл и т.д.) и получаем желаемый результат без проблем наследования (когда у потомка есть неиспользуемые свойства предка, или когда приходится перезаписывать методы предка).
Возможно, в обычном программировании это всё не так очевидно. Но в геймдеве мы не просто код пишем, мы моделируем реальный мир или что-то похожее на реальный мир. И пытаясь применить наследование к реальному миру, мы вставляем себе палки в колёса, потому что наследование в реальном мире не существует, кроме как абстрактная концепция в мыслях людей.
Так что когда в следующий раз захочешь сделать кошку наследником млекопитающего - НЕ ЕШ, ПОДУМОЙ: будет лучше наделить кошку набором навыков и свойств, характерных для кошки, которые в будущем можно использовать и для других животных.
При этом это всё не касается ЕЦС, это всё ещё старое-доброе ООП с объектами как контейнерами данных и методов, к которым можно обращаться по ссылке на кучу, но при этом объекты собираются из других объектов и могут при необходимости разбираться или пересобираться (как в десигн-тайм, так и в рантайме).
Вот тут некий адепт ООП защищает наследование:
https://youtu.be/i9QLHpbyUyw
Сразу говорю: он заблуждается.
Его примеры:
1. Программист и уборщица "наследуются" от общего для них класса сотрудник - сотрудник имеет метод для получения зарплаты, а программист и уборщица - необходимые конкретной роли навыки.
2. Условный дуб наследуется от дерева, дерево наследуется от растения; аналогично с животными.
Почему его примеры ошибочны?
1. Он сам предложил ситуацию, когда уборщица повышается до программиста. Вот только в системе наследования ООП это невозможно, лол! В реальности не существует никакого наследования. Объекты проще всего воспринимать не как наследники свойств категорий, а как композиции свойств. Т.е. программист - это человек, у которого есть навыки программирования, а уборщица - это человек с навыками уборщицы. Если мы хотим перевести уборщицу на должность программиста, мы с помощью агрегации даём уборщице навык программирования и она теперь может выполнять роль программиста ничуть не хуже того, кто был программистом изначально.
2. Пример из биологии тоже в корне неправильный, потому что даже в реальной биологии классификацию довольно часто приходится изменять, когда биологи внезапно открывают некие новые свойства уже известных растений и животных. То есть в реальности, когда мы смотрим на растение или животное, мы видим некий набор свойств и не более того. Мы можем мысленно представить себе некую иерархию свойств, но это только наша выдумка. Особенно явно видны недостатки концепции наследования в биологии на примере паразитов: предки паразитов в прошлом имели БОЛЬШЕ свойств и методов, но в результате эволюции утратили эти свойства, став полностью зависимыми от организма-носителей. Их предки были зрячими, например, а они теперь слепы. Т.е. опять же возвращаемся к композиции/агрегации: если мы хотим сделать из клетки вирус, мы меняем её набор свойств (лишаем клеточной оболочки, органелл и т.д.) и получаем желаемый результат без проблем наследования (когда у потомка есть неиспользуемые свойства предка, или когда приходится перезаписывать методы предка).
Возможно, в обычном программировании это всё не так очевидно. Но в геймдеве мы не просто код пишем, мы моделируем реальный мир или что-то похожее на реальный мир. И пытаясь применить наследование к реальному миру, мы вставляем себе палки в колёса, потому что наследование в реальном мире не существует, кроме как абстрактная концепция в мыслях людей.
Так что когда в следующий раз захочешь сделать кошку наследником млекопитающего - НЕ ЕШ, ПОДУМОЙ: будет лучше наделить кошку набором навыков и свойств, характерных для кошки, которые в будущем можно использовать и для других животных.
При этом это всё не касается ЕЦС, это всё ещё старое-доброе ООП с объектами как контейнерами данных и методов, к которым можно обращаться по ссылке на кучу, но при этом объекты собираются из других объектов и могут при необходимости разбираться или пересобираться (как в десигн-тайм, так и в рантайме).
https://youtu.be/i9QLHpbyUyw
Сразу говорю: он заблуждается.
Его примеры:
1. Программист и уборщица "наследуются" от общего для них класса сотрудник - сотрудник имеет метод для получения зарплаты, а программист и уборщица - необходимые конкретной роли навыки.
2. Условный дуб наследуется от дерева, дерево наследуется от растения; аналогично с животными.
Почему его примеры ошибочны?
1. Он сам предложил ситуацию, когда уборщица повышается до программиста. Вот только в системе наследования ООП это невозможно, лол! В реальности не существует никакого наследования. Объекты проще всего воспринимать не как наследники свойств категорий, а как композиции свойств. Т.е. программист - это человек, у которого есть навыки программирования, а уборщица - это человек с навыками уборщицы. Если мы хотим перевести уборщицу на должность программиста, мы с помощью агрегации даём уборщице навык программирования и она теперь может выполнять роль программиста ничуть не хуже того, кто был программистом изначально.
2. Пример из биологии тоже в корне неправильный, потому что даже в реальной биологии классификацию довольно часто приходится изменять, когда биологи внезапно открывают некие новые свойства уже известных растений и животных. То есть в реальности, когда мы смотрим на растение или животное, мы видим некий набор свойств и не более того. Мы можем мысленно представить себе некую иерархию свойств, но это только наша выдумка. Особенно явно видны недостатки концепции наследования в биологии на примере паразитов: предки паразитов в прошлом имели БОЛЬШЕ свойств и методов, но в результате эволюции утратили эти свойства, став полностью зависимыми от организма-носителей. Их предки были зрячими, например, а они теперь слепы. Т.е. опять же возвращаемся к композиции/агрегации: если мы хотим сделать из клетки вирус, мы меняем её набор свойств (лишаем клеточной оболочки, органелл и т.д.) и получаем желаемый результат без проблем наследования (когда у потомка есть неиспользуемые свойства предка, или когда приходится перезаписывать методы предка).
Возможно, в обычном программировании это всё не так очевидно. Но в геймдеве мы не просто код пишем, мы моделируем реальный мир или что-то похожее на реальный мир. И пытаясь применить наследование к реальному миру, мы вставляем себе палки в колёса, потому что наследование в реальном мире не существует, кроме как абстрактная концепция в мыслях людей.
Так что когда в следующий раз захочешь сделать кошку наследником млекопитающего - НЕ ЕШ, ПОДУМОЙ: будет лучше наделить кошку набором навыков и свойств, характерных для кошки, которые в будущем можно использовать и для других животных.
При этом это всё не касается ЕЦС, это всё ещё старое-доброе ООП с объектами как контейнерами данных и методов, к которым можно обращаться по ссылке на кучу, но при этом объекты собираются из других объектов и могут при необходимости разбираться или пересобираться (как в десигн-тайм, так и в рантайме).
>>41413
Чё там сложного?
Вася - двачер, при этом Вася - человек. То, что он человек - это наследование. То что он двачер - композиция. Когда мы в других тредах срались на тему композиции, часто приводились в пример мимики из множества игор, но известные как правило, как мимики из дарксоулс. Мимик выглядит как сундук, но действует как монстр. Если вся игра основана на наследовании, то когда захочется добавить в игру мимика, придётся много переделывать и копипастить.
Но я всегда удивлялся с такого примера. Что значит "захочется добавить"? В игру вся база добавляется на этапе предпродакшена, обкатывается на кубах, когда в прототип легко добавить хоть мимика, хоть говорящее дерево. Потом уже всё. Если в вашей галере, анончики, предлагают вносить в игру изменения на этапе продакшена, или если в вашей галере вообще предпродакшена не знают, то я бы советовал валить с такой галеры говноделов.
> Сложно привести конкретные примеры...
> Блин, реально сложно.
Чё там сложного?
Вася - двачер, при этом Вася - человек. То, что он человек - это наследование. То что он двачер - композиция. Когда мы в других тредах срались на тему композиции, часто приводились в пример мимики из множества игор, но известные как правило, как мимики из дарксоулс. Мимик выглядит как сундук, но действует как монстр. Если вся игра основана на наследовании, то когда захочется добавить в игру мимика, придётся много переделывать и копипастить.
Но я всегда удивлялся с такого примера. Что значит "захочется добавить"? В игру вся база добавляется на этапе предпродакшена, обкатывается на кубах, когда в прототип легко добавить хоть мимика, хоть говорящее дерево. Потом уже всё. Если в вашей галере, анончики, предлагают вносить в игру изменения на этапе продакшена, или если в вашей галере вообще предпродакшена не знают, то я бы советовал валить с такой галеры говноделов.
>>41422
Наследовать следует только максимально фундаментальные атрибуты, набор которых вообще не будут изменен никогда. Например, собственно, наследование нод от общего предка Node. В случае с кошкой да, лучше не париться и накидать ей поведений в чайлды, но кошка всегда останется Node.
Наследовать следует только максимально фундаментальные атрибуты, набор которых вообще не будут изменен никогда. Например, собственно, наследование нод от общего предка Node. В случае с кошкой да, лучше не париться и накидать ей поведений в чайлды, но кошка всегда останется Node.
>>41427
Поэтому индихуи пилят свое говно по 10 лет? Типа "О, а сегодня я добавлю это" и потом 2 месяца корчит свой код чтобы это самое это работало?
Как тогда стать бигбрейном, который с нуля до релиза продумает все мелочи?
Поэтому индихуи пилят свое говно по 10 лет? Типа "О, а сегодня я добавлю это" и потом 2 месяца корчит свой код чтобы это самое это работало?
Как тогда стать бигбрейном, который с нуля до релиза продумает все мелочи?
4,6 Мб, 2880x1800Го в Российский Автопром кодить на Годоте?
У нас уже есть один очень клёвый годотер с вашего форума, хотелось бы как минимум ещё одного! А ещё у него очень много весёлых и замечательных видео про вас.
hh.ru/vacancy/72736381
У нас уже есть один очень клёвый годотер с вашего форума, хотелось бы как минимум ещё одного! А ещё у него очень много весёлых и замечательных видео про вас.
hh.ru/vacancy/72736381
>>41553
Сразу мимо, не взлетит.
Прежде чем по России/СНГ смогут свободно ездить электромобили, нужно наладить систему зарядных станций, которые будут расставлены так же часто или даже чаще, чем бензоколонки. Маск с его электроколясками подошёл к проблеме радикально - построил свои собственные зарядные станции по всему США, но у них совершенно другие условия. У нас Петрович сможет заряжать свою коляску только от домашней розетки или переносного топливного генератора, ну и зачем ему эта коляска? Чтобы мультики по встроенному монитору смотреть?
Вот сделайте сначала систему зарядных станций, чтобы можно было заменить двигатель внутреннего сгорания на электрический в любом Запорожце, Жигуле и Москвиче, а уже потом задумывайтесь о каких-то беспонтовых примочках вроде дисплея с игрушками. Серьёзно, вы хоть понимаете, почему троллейбусы много десятилетий служат во многих городах, а частный транспорт до сих пор пердит продуктами горения?
Вот создайте условия, которые позволят переоборудовать любой существующий автомобиль в электромобиль - тогда и посмотрим, стоит ли вам разрабатывать какие-то мультики для бортового компьютера, который, кстати, тоже можно установить на совершенно любой существующий транспорт - было бы желание; но желания этого обычно нет, ибо нет смысла - у такого встроенного компьютера по определению меньше возможностей, чем у самого слабого ноутбука, а все эти проекторы на лобовое стекло - обычные периферийные устройства, а не что-то напрямую зависящее от специализированного компьютера.
Вывод: это стартап для отмывания или распила денег, или ещё какая-то мутная схема, либо просто крайне неудачный проект не шарящих в теме студентов, которые в силу своей неопытности считают себя профессионалами. И это я даже не говорил обо всём остальном в вакансии - нужно быть буквально всем и делать всё, иметь 3-6 лет опыта работы непонятно кем непонятно где, но относиться к тебе будут как к никчёмному новичку и оплачивать неизвестно как, то есть сразу рассчитывай на гроши. Я уж молчу о том, что предлагают работать над встраиваемым ПО на удалёнке, то есть у разработчика не будет доступа к реальному железу, под которое он делает свою программу - а это серьёзная заявка на эпичный фейл - как предлагать тренироваться к соревнованию по плаванию, ни разу в жизни не прикасаясь к объёму воды больше маленькой ванной. Больше похоже на попытку обмануть программиста, ничего ему не заплатив за работу, или заплатив символический минимум.
А самое смешное - искать людей с soft skills на, вы только подумайте, анонимных имиджбордах! Сразу видно, что человек посторонний и в местном контингенте вообще не разбирается.
Если посмотреть их страничку компании - заявляют о 300 сотрудниках, но в вакансиях по-прежнему "нужны все, и все опытные", то есть по факту у них никого нет. Говорю же, студентики со взглядом горящим или старпёр, пытающийся в очередной раз попилить какие-то гранты, как делает это с 90-х, если не раньше (не они первые, не они последние). Выкатят свой "атом", он проедет 10 км и разрядится, а дальше будут буксировать до ближайшей розетки с помощью обычного пердящего УАЗ 469, который 50 лет служил и ещё столько же прослужит безо всяких встроенных компьютеров. Зато на встроенном мониторчике можно мультики смотреть и в игрушки играть, вот ведь радость для зумеров! Вот сидишь 10 часов у розетки под окнами своей избы в деревне и смотришь мультики - киберпанк, который мы не ждали, но заслужили.
Простите за оффтоп, горит с этих стартапов. Может у них что-то и получится, но доверять им я бы не стал.
>инновационный электромобиль
Сразу мимо, не взлетит.
Прежде чем по России/СНГ смогут свободно ездить электромобили, нужно наладить систему зарядных станций, которые будут расставлены так же часто или даже чаще, чем бензоколонки. Маск с его электроколясками подошёл к проблеме радикально - построил свои собственные зарядные станции по всему США, но у них совершенно другие условия. У нас Петрович сможет заряжать свою коляску только от домашней розетки или переносного топливного генератора, ну и зачем ему эта коляска? Чтобы мультики по встроенному монитору смотреть?
Вот сделайте сначала систему зарядных станций, чтобы можно было заменить двигатель внутреннего сгорания на электрический в любом Запорожце, Жигуле и Москвиче, а уже потом задумывайтесь о каких-то беспонтовых примочках вроде дисплея с игрушками. Серьёзно, вы хоть понимаете, почему троллейбусы много десятилетий служат во многих городах, а частный транспорт до сих пор пердит продуктами горения?
Вот создайте условия, которые позволят переоборудовать любой существующий автомобиль в электромобиль - тогда и посмотрим, стоит ли вам разрабатывать какие-то мультики для бортового компьютера, который, кстати, тоже можно установить на совершенно любой существующий транспорт - было бы желание; но желания этого обычно нет, ибо нет смысла - у такого встроенного компьютера по определению меньше возможностей, чем у самого слабого ноутбука, а все эти проекторы на лобовое стекло - обычные периферийные устройства, а не что-то напрямую зависящее от специализированного компьютера.
Вывод: это стартап для отмывания или распила денег, или ещё какая-то мутная схема, либо просто крайне неудачный проект не шарящих в теме студентов, которые в силу своей неопытности считают себя профессионалами. И это я даже не говорил обо всём остальном в вакансии - нужно быть буквально всем и делать всё, иметь 3-6 лет опыта работы непонятно кем непонятно где, но относиться к тебе будут как к никчёмному новичку и оплачивать неизвестно как, то есть сразу рассчитывай на гроши. Я уж молчу о том, что предлагают работать над встраиваемым ПО на удалёнке, то есть у разработчика не будет доступа к реальному железу, под которое он делает свою программу - а это серьёзная заявка на эпичный фейл - как предлагать тренироваться к соревнованию по плаванию, ни разу в жизни не прикасаясь к объёму воды больше маленькой ванной. Больше похоже на попытку обмануть программиста, ничего ему не заплатив за работу, или заплатив символический минимум.
А самое смешное - искать людей с soft skills на, вы только подумайте, анонимных имиджбордах! Сразу видно, что человек посторонний и в местном контингенте вообще не разбирается.
Если посмотреть их страничку компании - заявляют о 300 сотрудниках, но в вакансиях по-прежнему "нужны все, и все опытные", то есть по факту у них никого нет. Говорю же, студентики со взглядом горящим или старпёр, пытающийся в очередной раз попилить какие-то гранты, как делает это с 90-х, если не раньше (не они первые, не они последние). Выкатят свой "атом", он проедет 10 км и разрядится, а дальше будут буксировать до ближайшей розетки с помощью обычного пердящего УАЗ 469, который 50 лет служил и ещё столько же прослужит безо всяких встроенных компьютеров. Зато на встроенном мониторчике можно мультики смотреть и в игрушки играть, вот ведь радость для зумеров! Вот сидишь 10 часов у розетки под окнами своей избы в деревне и смотришь мультики - киберпанк, который мы не ждали, но заслужили.
Простите за оффтоп, горит с этих стартапов. Может у них что-то и получится, но доверять им я бы не стал.
>>41553
Сразу мимо, не взлетит.
Прежде чем по России/СНГ смогут свободно ездить электромобили, нужно наладить систему зарядных станций, которые будут расставлены так же часто или даже чаще, чем бензоколонки. Маск с его электроколясками подошёл к проблеме радикально - построил свои собственные зарядные станции по всему США, но у них совершенно другие условия. У нас Петрович сможет заряжать свою коляску только от домашней розетки или переносного топливного генератора, ну и зачем ему эта коляска? Чтобы мультики по встроенному монитору смотреть?
Вот сделайте сначала систему зарядных станций, чтобы можно было заменить двигатель внутреннего сгорания на электрический в любом Запорожце, Жигуле и Москвиче, а уже потом задумывайтесь о каких-то беспонтовых примочках вроде дисплея с игрушками. Серьёзно, вы хоть понимаете, почему троллейбусы много десятилетий служат во многих городах, а частный транспорт до сих пор пердит продуктами горения?
Вот создайте условия, которые позволят переоборудовать любой существующий автомобиль в электромобиль - тогда и посмотрим, стоит ли вам разрабатывать какие-то мультики для бортового компьютера, который, кстати, тоже можно установить на совершенно любой существующий транспорт - было бы желание; но желания этого обычно нет, ибо нет смысла - у такого встроенного компьютера по определению меньше возможностей, чем у самого слабого ноутбука, а все эти проекторы на лобовое стекло - обычные периферийные устройства, а не что-то напрямую зависящее от специализированного компьютера.
Вывод: это стартап для отмывания или распила денег, или ещё какая-то мутная схема, либо просто крайне неудачный проект не шарящих в теме студентов, которые в силу своей неопытности считают себя профессионалами. И это я даже не говорил обо всём остальном в вакансии - нужно быть буквально всем и делать всё, иметь 3-6 лет опыта работы непонятно кем непонятно где, но относиться к тебе будут как к никчёмному новичку и оплачивать неизвестно как, то есть сразу рассчитывай на гроши. Я уж молчу о том, что предлагают работать над встраиваемым ПО на удалёнке, то есть у разработчика не будет доступа к реальному железу, под которое он делает свою программу - а это серьёзная заявка на эпичный фейл - как предлагать тренироваться к соревнованию по плаванию, ни разу в жизни не прикасаясь к объёму воды больше маленькой ванной. Больше похоже на попытку обмануть программиста, ничего ему не заплатив за работу, или заплатив символический минимум.
А самое смешное - искать людей с soft skills на, вы только подумайте, анонимных имиджбордах! Сразу видно, что человек посторонний и в местном контингенте вообще не разбирается.
Если посмотреть их страничку компании - заявляют о 300 сотрудниках, но в вакансиях по-прежнему "нужны все, и все опытные", то есть по факту у них никого нет. Говорю же, студентики со взглядом горящим или старпёр, пытающийся в очередной раз попилить какие-то гранты, как делает это с 90-х, если не раньше (не они первые, не они последние). Выкатят свой "атом", он проедет 10 км и разрядится, а дальше будут буксировать до ближайшей розетки с помощью обычного пердящего УАЗ 469, который 50 лет служил и ещё столько же прослужит безо всяких встроенных компьютеров. Зато на встроенном мониторчике можно мультики смотреть и в игрушки играть, вот ведь радость для зумеров! Вот сидишь 10 часов у розетки под окнами своей избы в деревне и смотришь мультики - киберпанк, который мы не ждали, но заслужили.
Простите за оффтоп, горит с этих стартапов. Может у них что-то и получится, но доверять им я бы не стал.
>инновационный электромобиль
Сразу мимо, не взлетит.
Прежде чем по России/СНГ смогут свободно ездить электромобили, нужно наладить систему зарядных станций, которые будут расставлены так же часто или даже чаще, чем бензоколонки. Маск с его электроколясками подошёл к проблеме радикально - построил свои собственные зарядные станции по всему США, но у них совершенно другие условия. У нас Петрович сможет заряжать свою коляску только от домашней розетки или переносного топливного генератора, ну и зачем ему эта коляска? Чтобы мультики по встроенному монитору смотреть?
Вот сделайте сначала систему зарядных станций, чтобы можно было заменить двигатель внутреннего сгорания на электрический в любом Запорожце, Жигуле и Москвиче, а уже потом задумывайтесь о каких-то беспонтовых примочках вроде дисплея с игрушками. Серьёзно, вы хоть понимаете, почему троллейбусы много десятилетий служат во многих городах, а частный транспорт до сих пор пердит продуктами горения?
Вот создайте условия, которые позволят переоборудовать любой существующий автомобиль в электромобиль - тогда и посмотрим, стоит ли вам разрабатывать какие-то мультики для бортового компьютера, который, кстати, тоже можно установить на совершенно любой существующий транспорт - было бы желание; но желания этого обычно нет, ибо нет смысла - у такого встроенного компьютера по определению меньше возможностей, чем у самого слабого ноутбука, а все эти проекторы на лобовое стекло - обычные периферийные устройства, а не что-то напрямую зависящее от специализированного компьютера.
Вывод: это стартап для отмывания или распила денег, или ещё какая-то мутная схема, либо просто крайне неудачный проект не шарящих в теме студентов, которые в силу своей неопытности считают себя профессионалами. И это я даже не говорил обо всём остальном в вакансии - нужно быть буквально всем и делать всё, иметь 3-6 лет опыта работы непонятно кем непонятно где, но относиться к тебе будут как к никчёмному новичку и оплачивать неизвестно как, то есть сразу рассчитывай на гроши. Я уж молчу о том, что предлагают работать над встраиваемым ПО на удалёнке, то есть у разработчика не будет доступа к реальному железу, под которое он делает свою программу - а это серьёзная заявка на эпичный фейл - как предлагать тренироваться к соревнованию по плаванию, ни разу в жизни не прикасаясь к объёму воды больше маленькой ванной. Больше похоже на попытку обмануть программиста, ничего ему не заплатив за работу, или заплатив символический минимум.
А самое смешное - искать людей с soft skills на, вы только подумайте, анонимных имиджбордах! Сразу видно, что человек посторонний и в местном контингенте вообще не разбирается.
Если посмотреть их страничку компании - заявляют о 300 сотрудниках, но в вакансиях по-прежнему "нужны все, и все опытные", то есть по факту у них никого нет. Говорю же, студентики со взглядом горящим или старпёр, пытающийся в очередной раз попилить какие-то гранты, как делает это с 90-х, если не раньше (не они первые, не они последние). Выкатят свой "атом", он проедет 10 км и разрядится, а дальше будут буксировать до ближайшей розетки с помощью обычного пердящего УАЗ 469, который 50 лет служил и ещё столько же прослужит безо всяких встроенных компьютеров. Зато на встроенном мониторчике можно мультики смотреть и в игрушки играть, вот ведь радость для зумеров! Вот сидишь 10 часов у розетки под окнами своей избы в деревне и смотришь мультики - киберпанк, который мы не ждали, но заслужили.
Простите за оффтоп, горит с этих стартапов. Может у них что-то и получится, но доверять им я бы не стал.
>>41427
То есть ты предлагаешь сделать так:
Но зачем?
Это устаревший подход из корпоративной среды, не соответствующий современным реалиям. Да, ты прав, старые ААА-игры так и делали:
- пишут диздок в 5-10 раз толще Библии;
- делают прототип(ы) на условных кубах;
- доделывают игру до релизной версии;
- вырезают то, что не успели доделать;
- выводят игру в релиз на дисках;
- редко патчат некоторые баги;
- переходят к новому проекту.
Стоит ли говорить, что это порочная схема? Игра - это не книга и не фильм. Игра - это программное обеспечение. А программное обеспечение должно жить и обновляться всё время, пока оно кому-нибудь нужно. Хороший пример - некоторые онлайн-игры, которые существуют 90-х и продолжают обновляться. Но есть аналогичные офлайн-проекты, которые тоже продолжают обновляться даже после достижения стабильной 1.0 версии. Выходит 1.1, 1.2, 1.3, рано или поздно появляется 2.0, ломающая совместимость с версиями 1.x ветки, а ещё через несколько лет очередь доходит до версии 3.0, потом 4.0 и т.д. Игра должна жить, и она живёт, пока получает обновления. В такой системе невозможно предсказать всё, что будет нужно или захочется добавить, поэтому диздок перерождается в документацию, которая обновляется параллельно обновлениям ПО и доступна игрокам так же, как разработчикам игры доступна документация на игровой движок. Хотя обычно это всё-таки неофициальная документация, но это из-за безответственности разрабов - по-хорошему к любой игре должна быть официальная документация со всеми описаниями багофич и API.
Короче, я к чему это веду - нельзя делать код игры тяп-ляп без рассчёта на нововведения. Архитектура должна быть гибкой, без этого ты будешь буксовать на каждой новой фиче. Конечно, рано или поздно обнаруживаются недостатки принятых решений, и тогда приходится увеличивать мажорную версию, ломая совместимость с предыдущими. Но версия 1.0 должна быть достаточно стабильной, чтобы можно было безболезненно вводить фичи в минорных версиях (1.x).
>>41443
Для этого нужно иметь много опыта создания игр с нуля и до релиза. Короче, учиться на ошибках. Ты всё равно не поверишь утверждениям кого-либо, что твои идеи слишком сложны или невозможны, либо будут скучны или избыточны для игрока, и в своих первых проектах напланируешь всякой чепухи. К гибкой архитектуре тоже приходишь не сразу - в самом начале все новички пишут плохой код, в котором сами не могут разобраться.
>Вася - человек. То, что он человек - это наследование.
То есть ты предлагаешь сделать так:
>class_name Vasya extends Human
Но зачем?
>Но я всегда удивлялся с такого примера. Что значит "захочется добавить"? В игру вся база добавляется на этапе предпродакшена, обкатывается на кубах, когда в прототип легко добавить хоть мимика, хоть говорящее дерево. Потом уже всё.
Это устаревший подход из корпоративной среды, не соответствующий современным реалиям. Да, ты прав, старые ААА-игры так и делали:
- пишут диздок в 5-10 раз толще Библии;
- делают прототип(ы) на условных кубах;
- доделывают игру до релизной версии;
- вырезают то, что не успели доделать;
- выводят игру в релиз на дисках;
- редко патчат некоторые баги;
- переходят к новому проекту.
Стоит ли говорить, что это порочная схема? Игра - это не книга и не фильм. Игра - это программное обеспечение. А программное обеспечение должно жить и обновляться всё время, пока оно кому-нибудь нужно. Хороший пример - некоторые онлайн-игры, которые существуют 90-х и продолжают обновляться. Но есть аналогичные офлайн-проекты, которые тоже продолжают обновляться даже после достижения стабильной 1.0 версии. Выходит 1.1, 1.2, 1.3, рано или поздно появляется 2.0, ломающая совместимость с версиями 1.x ветки, а ещё через несколько лет очередь доходит до версии 3.0, потом 4.0 и т.д. Игра должна жить, и она живёт, пока получает обновления. В такой системе невозможно предсказать всё, что будет нужно или захочется добавить, поэтому диздок перерождается в документацию, которая обновляется параллельно обновлениям ПО и доступна игрокам так же, как разработчикам игры доступна документация на игровой движок. Хотя обычно это всё-таки неофициальная документация, но это из-за безответственности разрабов - по-хорошему к любой игре должна быть официальная документация со всеми описаниями багофич и API.
Короче, я к чему это веду - нельзя делать код игры тяп-ляп без рассчёта на нововведения. Архитектура должна быть гибкой, без этого ты будешь буксовать на каждой новой фиче. Конечно, рано или поздно обнаруживаются недостатки принятых решений, и тогда приходится увеличивать мажорную версию, ломая совместимость с предыдущими. Но версия 1.0 должна быть достаточно стабильной, чтобы можно было безболезненно вводить фичи в минорных версиях (1.x).
>>41443
>Как тогда стать бигбрейном, который с нуля до релиза продумает все мелочи?
Для этого нужно иметь много опыта создания игр с нуля и до релиза. Короче, учиться на ошибках. Ты всё равно не поверишь утверждениям кого-либо, что твои идеи слишком сложны или невозможны, либо будут скучны или избыточны для игрока, и в своих первых проектах напланируешь всякой чепухи. К гибкой архитектуре тоже приходишь не сразу - в самом начале все новички пишут плохой код, в котором сами не могут разобраться.
>>41427
То есть ты предлагаешь сделать так:
Но зачем?
Это устаревший подход из корпоративной среды, не соответствующий современным реалиям. Да, ты прав, старые ААА-игры так и делали:
- пишут диздок в 5-10 раз толще Библии;
- делают прототип(ы) на условных кубах;
- доделывают игру до релизной версии;
- вырезают то, что не успели доделать;
- выводят игру в релиз на дисках;
- редко патчат некоторые баги;
- переходят к новому проекту.
Стоит ли говорить, что это порочная схема? Игра - это не книга и не фильм. Игра - это программное обеспечение. А программное обеспечение должно жить и обновляться всё время, пока оно кому-нибудь нужно. Хороший пример - некоторые онлайн-игры, которые существуют 90-х и продолжают обновляться. Но есть аналогичные офлайн-проекты, которые тоже продолжают обновляться даже после достижения стабильной 1.0 версии. Выходит 1.1, 1.2, 1.3, рано или поздно появляется 2.0, ломающая совместимость с версиями 1.x ветки, а ещё через несколько лет очередь доходит до версии 3.0, потом 4.0 и т.д. Игра должна жить, и она живёт, пока получает обновления. В такой системе невозможно предсказать всё, что будет нужно или захочется добавить, поэтому диздок перерождается в документацию, которая обновляется параллельно обновлениям ПО и доступна игрокам так же, как разработчикам игры доступна документация на игровой движок. Хотя обычно это всё-таки неофициальная документация, но это из-за безответственности разрабов - по-хорошему к любой игре должна быть официальная документация со всеми описаниями багофич и API.
Короче, я к чему это веду - нельзя делать код игры тяп-ляп без рассчёта на нововведения. Архитектура должна быть гибкой, без этого ты будешь буксовать на каждой новой фиче. Конечно, рано или поздно обнаруживаются недостатки принятых решений, и тогда приходится увеличивать мажорную версию, ломая совместимость с предыдущими. Но версия 1.0 должна быть достаточно стабильной, чтобы можно было безболезненно вводить фичи в минорных версиях (1.x).
>>41443
Для этого нужно иметь много опыта создания игр с нуля и до релиза. Короче, учиться на ошибках. Ты всё равно не поверишь утверждениям кого-либо, что твои идеи слишком сложны или невозможны, либо будут скучны или избыточны для игрока, и в своих первых проектах напланируешь всякой чепухи. К гибкой архитектуре тоже приходишь не сразу - в самом начале все новички пишут плохой код, в котором сами не могут разобраться.
>Вася - человек. То, что он человек - это наследование.
То есть ты предлагаешь сделать так:
>class_name Vasya extends Human
Но зачем?
>Но я всегда удивлялся с такого примера. Что значит "захочется добавить"? В игру вся база добавляется на этапе предпродакшена, обкатывается на кубах, когда в прототип легко добавить хоть мимика, хоть говорящее дерево. Потом уже всё.
Это устаревший подход из корпоративной среды, не соответствующий современным реалиям. Да, ты прав, старые ААА-игры так и делали:
- пишут диздок в 5-10 раз толще Библии;
- делают прототип(ы) на условных кубах;
- доделывают игру до релизной версии;
- вырезают то, что не успели доделать;
- выводят игру в релиз на дисках;
- редко патчат некоторые баги;
- переходят к новому проекту.
Стоит ли говорить, что это порочная схема? Игра - это не книга и не фильм. Игра - это программное обеспечение. А программное обеспечение должно жить и обновляться всё время, пока оно кому-нибудь нужно. Хороший пример - некоторые онлайн-игры, которые существуют 90-х и продолжают обновляться. Но есть аналогичные офлайн-проекты, которые тоже продолжают обновляться даже после достижения стабильной 1.0 версии. Выходит 1.1, 1.2, 1.3, рано или поздно появляется 2.0, ломающая совместимость с версиями 1.x ветки, а ещё через несколько лет очередь доходит до версии 3.0, потом 4.0 и т.д. Игра должна жить, и она живёт, пока получает обновления. В такой системе невозможно предсказать всё, что будет нужно или захочется добавить, поэтому диздок перерождается в документацию, которая обновляется параллельно обновлениям ПО и доступна игрокам так же, как разработчикам игры доступна документация на игровой движок. Хотя обычно это всё-таки неофициальная документация, но это из-за безответственности разрабов - по-хорошему к любой игре должна быть официальная документация со всеми описаниями багофич и API.
Короче, я к чему это веду - нельзя делать код игры тяп-ляп без рассчёта на нововведения. Архитектура должна быть гибкой, без этого ты будешь буксовать на каждой новой фиче. Конечно, рано или поздно обнаруживаются недостатки принятых решений, и тогда приходится увеличивать мажорную версию, ломая совместимость с предыдущими. Но версия 1.0 должна быть достаточно стабильной, чтобы можно было безболезненно вводить фичи в минорных версиях (1.x).
>>41443
>Как тогда стать бигбрейном, который с нуля до релиза продумает все мелочи?
Для этого нужно иметь много опыта создания игр с нуля и до релиза. Короче, учиться на ошибках. Ты всё равно не поверишь утверждениям кого-либо, что твои идеи слишком сложны или невозможны, либо будут скучны или избыточны для игрока, и в своих первых проектах напланируешь всякой чепухи. К гибкой архитектуре тоже приходишь не сразу - в самом начале все новички пишут плохой код, в котором сами не могут разобраться.
>>41427
И это отличная иллюстрация против наследования, когда ты захочешь ввести расу орков...
> Вася - человек. То, что он человек - это наследование
И это отличная иллюстрация против наследования, когда ты захочешь ввести расу орков...
>>41719
Моя оценка: 1 вменяемость из 10, буду удалять ещё.
>вменяемый вариант
>407 КБ вместо 1 КБ
>лишний exe вместо cmd
>хочешь изменить - делай свой cmd
Моя оценка: 1 вменяемость из 10, буду удалять ещё.
>>41731
Знаешь, а ты прав. Я поторопился не потестировав. Проблему то это не решило.
Если запускать годот из командной строки, или из батника, он все равно пишет в эту консоль. Даже если запускать через start godot.exe, что вообще-то должно запускать отдельное окно.
Я то подумал, что сделали по уму, и основной годот всегда оконный, а второй exe цепляет к нему консоль. Надо будет им баг репорт написать.
Знаешь, а ты прав. Я поторопился не потестировав. Проблему то это не решило.
Если запускать годот из командной строки, или из батника, он все равно пишет в эту консоль. Даже если запускать через start godot.exe, что вообще-то должно запускать отдельное окно.
Я то подумал, что сделали по уму, и основной годот всегда оконный, а второй exe цепляет к нему консоль. Надо будет им баг репорт написать.
>>41737
Так и должно быть, в чём твоя проблема? Ты хочешь консоль или нет? Определись.
Что, зачем, почему? Godot и так оконный. Консоль - это cmd.exe от Windows, а не Godot.
Попробуй вбить в консоль Windows такую строку:
Поясняю:
start - запускает программу или команду в отдельном окне;
cmd - стандартная консоль Windows с древних времён;
/k - параметр cmd, оставляющий её открытой после выполнения команды;
godot.exe - запрос cmd на запуск редактора Godot.
Что должно произойти:
1. Тот cmd.exe, в котором ты ввёл команду, запустит новый cmd.exe.
2. Второй cmd.exe запустит в себе Godot.exe.
3. Godot.exe будет срать в тот второй cmd.exe, который его запустил.
4. При этом первый cmd.exe, в котором ты открыл команду, останется чист и независим.
5. При закрытии:
- первого cmd.exe - ничего не произойдёт, т.к. он независим;
- второго cmd.exe - закроется Godot, т.к. он с ним связан;
- godot.exe - второй cmd.exe перейдёт в режим ожидания команды.
Вместо параметра /k можешь использовать /c, если хочешь, чтобы консоль закрылась вместе с Godot, однако, это нерационально делать, потому что в случае неожиданного падения Godot ты не сможешь прочитать сообщение об ошибке, потому что консоль закроется сама. Поэтому используй параметр /k.
Ещё раз: зачем тебе нужен отдельный exe, который будет открывать какую-то там консоль? Ты же всё равно подразумеваешь консоль Windows/Linux, а не какое-то особое окошко на Control нодах в Godot? Потому что вся суть использования консоли - это вывод простого текста в софт от третьих лиц, который гарантированно не упадёт с ошибкой в случае падения с ошибкой твоей программы (в данном случае Godot.exe). Если ты хочешь какую-то кастомную консоль, ну, напиши тогда свою консоль, только я не понимаю, зачем тебе это нужно, когда есть консоль в той ОС, на которой ты сидишь.
>Если запускать годот из командной строки, или из батника, он все равно пишет в эту консоль.
Так и должно быть, в чём твоя проблема? Ты хочешь консоль или нет? Определись.
>основной годот всегда оконный, а второй exe цепляет к нему консоль
Что, зачем, почему? Godot и так оконный. Консоль - это cmd.exe от Windows, а не Godot.
>Даже если запускать через start godot.exe, что вообще-то должно запускать отдельное окно.
Попробуй вбить в консоль Windows такую строку:
>start cmd /k godot.exe
Поясняю:
start - запускает программу или команду в отдельном окне;
cmd - стандартная консоль Windows с древних времён;
/k - параметр cmd, оставляющий её открытой после выполнения команды;
godot.exe - запрос cmd на запуск редактора Godot.
Что должно произойти:
1. Тот cmd.exe, в котором ты ввёл команду, запустит новый cmd.exe.
2. Второй cmd.exe запустит в себе Godot.exe.
3. Godot.exe будет срать в тот второй cmd.exe, который его запустил.
4. При этом первый cmd.exe, в котором ты открыл команду, останется чист и независим.
5. При закрытии:
- первого cmd.exe - ничего не произойдёт, т.к. он независим;
- второго cmd.exe - закроется Godot, т.к. он с ним связан;
- godot.exe - второй cmd.exe перейдёт в режим ожидания команды.
Вместо параметра /k можешь использовать /c, если хочешь, чтобы консоль закрылась вместе с Godot, однако, это нерационально делать, потому что в случае неожиданного падения Godot ты не сможешь прочитать сообщение об ошибке, потому что консоль закроется сама. Поэтому используй параметр /k.
Ещё раз: зачем тебе нужен отдельный exe, который будет открывать какую-то там консоль? Ты же всё равно подразумеваешь консоль Windows/Linux, а не какое-то особое окошко на Control нодах в Godot? Потому что вся суть использования консоли - это вывод простого текста в софт от третьих лиц, который гарантированно не упадёт с ошибкой в случае падения с ошибкой твоей программы (в данном случае Godot.exe). Если ты хочешь какую-то кастомную консоль, ну, напиши тогда свою консоль, только я не понимаю, зачем тебе это нужно, когда есть консоль в той ОС, на которой ты сидишь.
>>41737
Так и должно быть, в чём твоя проблема? Ты хочешь консоль или нет? Определись.
Что, зачем, почему? Godot и так оконный. Консоль - это cmd.exe от Windows, а не Godot.
Попробуй вбить в консоль Windows такую строку:
Поясняю:
start - запускает программу или команду в отдельном окне;
cmd - стандартная консоль Windows с древних времён;
/k - параметр cmd, оставляющий её открытой после выполнения команды;
godot.exe - запрос cmd на запуск редактора Godot.
Что должно произойти:
1. Тот cmd.exe, в котором ты ввёл команду, запустит новый cmd.exe.
2. Второй cmd.exe запустит в себе Godot.exe.
3. Godot.exe будет срать в тот второй cmd.exe, который его запустил.
4. При этом первый cmd.exe, в котором ты открыл команду, останется чист и независим.
5. При закрытии:
- первого cmd.exe - ничего не произойдёт, т.к. он независим;
- второго cmd.exe - закроется Godot, т.к. он с ним связан;
- godot.exe - второй cmd.exe перейдёт в режим ожидания команды.
Вместо параметра /k можешь использовать /c, если хочешь, чтобы консоль закрылась вместе с Godot, однако, это нерационально делать, потому что в случае неожиданного падения Godot ты не сможешь прочитать сообщение об ошибке, потому что консоль закроется сама. Поэтому используй параметр /k.
Ещё раз: зачем тебе нужен отдельный exe, который будет открывать какую-то там консоль? Ты же всё равно подразумеваешь консоль Windows/Linux, а не какое-то особое окошко на Control нодах в Godot? Потому что вся суть использования консоли - это вывод простого текста в софт от третьих лиц, который гарантированно не упадёт с ошибкой в случае падения с ошибкой твоей программы (в данном случае Godot.exe). Если ты хочешь какую-то кастомную консоль, ну, напиши тогда свою консоль, только я не понимаю, зачем тебе это нужно, когда есть консоль в той ОС, на которой ты сидишь.
>Если запускать годот из командной строки, или из батника, он все равно пишет в эту консоль.
Так и должно быть, в чём твоя проблема? Ты хочешь консоль или нет? Определись.
>основной годот всегда оконный, а второй exe цепляет к нему консоль
Что, зачем, почему? Godot и так оконный. Консоль - это cmd.exe от Windows, а не Godot.
>Даже если запускать через start godot.exe, что вообще-то должно запускать отдельное окно.
Попробуй вбить в консоль Windows такую строку:
>start cmd /k godot.exe
Поясняю:
start - запускает программу или команду в отдельном окне;
cmd - стандартная консоль Windows с древних времён;
/k - параметр cmd, оставляющий её открытой после выполнения команды;
godot.exe - запрос cmd на запуск редактора Godot.
Что должно произойти:
1. Тот cmd.exe, в котором ты ввёл команду, запустит новый cmd.exe.
2. Второй cmd.exe запустит в себе Godot.exe.
3. Godot.exe будет срать в тот второй cmd.exe, который его запустил.
4. При этом первый cmd.exe, в котором ты открыл команду, останется чист и независим.
5. При закрытии:
- первого cmd.exe - ничего не произойдёт, т.к. он независим;
- второго cmd.exe - закроется Godot, т.к. он с ним связан;
- godot.exe - второй cmd.exe перейдёт в режим ожидания команды.
Вместо параметра /k можешь использовать /c, если хочешь, чтобы консоль закрылась вместе с Godot, однако, это нерационально делать, потому что в случае неожиданного падения Godot ты не сможешь прочитать сообщение об ошибке, потому что консоль закроется сама. Поэтому используй параметр /k.
Ещё раз: зачем тебе нужен отдельный exe, который будет открывать какую-то там консоль? Ты же всё равно подразумеваешь консоль Windows/Linux, а не какое-то особое окошко на Control нодах в Godot? Потому что вся суть использования консоли - это вывод простого текста в софт от третьих лиц, который гарантированно не упадёт с ошибкой в случае падения с ошибкой твоей программы (в данном случае Godot.exe). Если ты хочешь какую-то кастомную консоль, ну, напиши тогда свою консоль, только я не понимаю, зачем тебе это нужно, когда есть консоль в той ОС, на которой ты сидишь.
>>41738
Наоборот. Это раньше была проблема включить консоль, ради чего начали городить все эти cmd. Теперь же мне надо ее отключить.
Мне нужно, чтобы при запуске start godot.exe годот запускался отдельно от консоли, не писал в нее сообщения, а также не закрывался при закрытии этой консоли. Мне не нужен второй Cmd /k который ты описываешь...
Я понимаю что в винде все криво, но тут уже авторы движка не разобрались, привязав логику не к галочке настроек, как было, а к левому событию (запуск из командной строки). Это примерно как приделать включение света к открыванию двери. Кому-то это покажется прикольно, что в туалете свет загорается сам, а у меня вот другая планировка и мне не надо чтобы свет горел все время когда комната проветривается.
Отдельный exe помог бы тут так - если запускается основной exe, то он запускается в оконном режиме и игнорирует консоль, даже если запущен из консоли или батника.
Второй лаунчер имеет более сложную логику - он запускает первый exe с флагом, указав тому чтобьы он сделал attach к консоли; причем, это будет либо консоль/батник, из которой запустили лаунчер, либо, если запускали без нее, то лаунчер сам запустит консоль и передаст ее.
В принципе тут можно обойтись и одним exe, но проще двумя. Потому что если будет один, то ему, возможно, придется перезапускать себя, как тут описано на примере ildasm
https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
Наоборот. Это раньше была проблема включить консоль, ради чего начали городить все эти cmd. Теперь же мне надо ее отключить.
Мне нужно, чтобы при запуске start godot.exe годот запускался отдельно от консоли, не писал в нее сообщения, а также не закрывался при закрытии этой консоли. Мне не нужен второй Cmd /k который ты описываешь...
Я понимаю что в винде все криво, но тут уже авторы движка не разобрались, привязав логику не к галочке настроек, как было, а к левому событию (запуск из командной строки). Это примерно как приделать включение света к открыванию двери. Кому-то это покажется прикольно, что в туалете свет загорается сам, а у меня вот другая планировка и мне не надо чтобы свет горел все время когда комната проветривается.
Отдельный exe помог бы тут так - если запускается основной exe, то он запускается в оконном режиме и игнорирует консоль, даже если запущен из консоли или батника.
Второй лаунчер имеет более сложную логику - он запускает первый exe с флагом, указав тому чтобьы он сделал attach к консоли; причем, это будет либо консоль/батник, из которой запустили лаунчер, либо, если запускали без нее, то лаунчер сам запустит консоль и передаст ее.
В принципе тут можно обойтись и одним exe, но проще двумя. Потому что если будет один, то ему, возможно, придется перезапускать себя, как тут описано на примере ildasm
https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
33 Кб, 278x386>>41744
Я всё понял, ты тот чувак с пикрила, угадал? https://xkcd.com/1172/
Тогда тебе нужна эта команда:
Поясняю:
cmd - вызывает новую консоль, но внутри той же консоли, в которой ты вводишь эту строку;
/c - заставляет эту новую консоль закрыться сразу после выполнения следующей команды;
start - запускает указанное приложение;
godot.exe - собственно наше приложение.
Что происходит:
1. Тот cmd, в котором ты вводишь эту команду, запускает второй cmd.
2. Второй cmd выполняет команду "start godot.exe" и немедленно выходит.
3. Запущенный godot.exe думает, что никакой консоли нет, и ни от кого не зависит.
4. Первый cmd видит, что второй cmd завершился, и ожидает ввода следующей команды.
При желании можешь запустить такой командой из одной консоли сколько угодно Godot'ов - они все будут независимыми и никто из них не будет срать ни в какую консоль (логи скорее всего будут направлены в log-файл, но я не проверял).
А теперь рассказывай, почему ты маешься такими извращениями?..
Лол, это не авторы движка не разобрались, это ты, линуксоед, не смог в Windows разобраться. Стыдно!
>Мне нужно, чтобы при запуске start godot.exe годот запускался отдельно от консоли, не писал в нее сообщения, а также не закрывался при закрытии этой консоли.
Я всё понял, ты тот чувак с пикрила, угадал? https://xkcd.com/1172/
Тогда тебе нужна эта команда:
>cmd /c start godot.exe
Поясняю:
cmd - вызывает новую консоль, но внутри той же консоли, в которой ты вводишь эту строку;
/c - заставляет эту новую консоль закрыться сразу после выполнения следующей команды;
start - запускает указанное приложение;
godot.exe - собственно наше приложение.
Что происходит:
1. Тот cmd, в котором ты вводишь эту команду, запускает второй cmd.
2. Второй cmd выполняет команду "start godot.exe" и немедленно выходит.
3. Запущенный godot.exe думает, что никакой консоли нет, и ни от кого не зависит.
4. Первый cmd видит, что второй cmd завершился, и ожидает ввода следующей команды.
При желании можешь запустить такой командой из одной консоли сколько угодно Godot'ов - они все будут независимыми и никто из них не будет срать ни в какую консоль (логи скорее всего будут направлены в log-файл, но я не проверял).
А теперь рассказывай, почему ты маешься такими извращениями?..
>Я понимаю что в винде все криво, но тут уже авторы движка не разобрались
Лол, это не авторы движка не разобрались, это ты, линуксоед, не смог в Windows разобраться. Стыдно!
74 Кб, 263x191>>41748
Но это ты предлагаешь извращение. Ты там выше жаловался на лишние несколько килобайт, а сейчас предлагаешь, для того что должен уметь .exe из коробки (запуск в окне), запускать ДОПОЛНИТЕЛЬНУЮ программу (cmd.exe) которая создаст новый терминал (!) загружая шрифты и прочие оснастки которые в нем крутятся, чтобы... Он тут же мигнул и закрылся!
Это реально что-то уровня пикрил.
Но это ты предлагаешь извращение. Ты там выше жаловался на лишние несколько килобайт, а сейчас предлагаешь, для того что должен уметь .exe из коробки (запуск в окне), запускать ДОПОЛНИТЕЛЬНУЮ программу (cmd.exe) которая создаст новый терминал (!) загружая шрифты и прочие оснастки которые в нем крутятся, чтобы... Он тут же мигнул и закрылся!
Это реально что-то уровня пикрил.
65 Кб, 640x788>>41744
Ещё забыл уточнить:
Это почему ты туалет проветриваешь открыванием двери, лол? В нормальной планировке в туалете есть вентиляция/вытяжка, которая высасывает все запахи даже при закрытой двери. Если ты дверь в туалет держишь открытой и у тебя в туалете воняет, то эта вся вонь в другие комнаты перейдёт - зачем? Лучше уж пусть в туалете воняет, чем во всей квартире/во всём доме. А если у тебя вентиляция/вытяжка не предусмотрена, сам виноват, что построил такую непродуманную херню/выбрал эту квартиру при покупке... Думать надо было! А теперь на кого-то ругаешься, что он предлагает дельное решение, которое тебе не подходит из-за твоей же собственной ошибки с проветриванием того, что проветривать по определению не нужно или даже вредно.
Т.е. ты сам себе палки в колёса ставишь и ещё на кого-то ругаешься.
>>41749
WTF, ты вообще Godot хоть раз запускал? Он всегда в окне запускается. Без консоли. Чтобы консоль была, нужно эту консоль сначала открыть - вручную или через bat/cmd - и только потом в ней запустить Godot. Режим по умолчанию - окно без консоли, режим для извращенцев - консоль с окном. В ЧЁМ ТВОЯ ПРОБЛЕМА?
Лол, так ты же САМ только что жаловался, что ты запускаешь cmd.exe и в нём вбиваешь godot.exe, из-за чего Godot начинает срать в консоль, тебе НЕПРИЯТНО и ты хочешь по какой-то извращённой причине запускать godot.exe из cmd.exe без вывода журнала событий godot в эту консоль... Ты сам представляешь, на что ты жалуешься? Ты буквально жалуешься на то, что ты сам, осознанно делаешь. ЗАЧЕМ ты это делаешь?
На моём древнем процессоре это за долю секунды происходит. Никакой новый терминал не создаётся и никакие шрифты не загружаются... ты просто даже не пробовал вводить указанную мной команду. Скажи честно, тебе просто посраться с кем-нибудь хочется, правда?
Мигает только заголовок окна консоли, если на него не смотреть - ничего не заметишь. Это реально не то, что ты там себе выдумываешь. Вот попробуй и реши сам, нужно оно тебе или нет. Хотя ты по-прежнему не сказал, ЗАЧЕМ тебе нужно такое извращение, когда ты можешь ПРОСТО запустить Godot как делают все нормальные люди - с ярлыка в каком-либо меню или в какой-либо папке. Тебе не нужно запускать консоль, если тебе не нужен вывод журнала событий в консоль.
Я вообще не понимаю, в чём твоя проблема, ведь если ты настолько привык к линуксу, то там, ВНЕЗАПНО, любое приложение при запуске с консоли занимает эту консоль ПОД СЕБЯ, и тебе нужно открывать новую консоль в отдельном окне/вкладке, чтобы делать что-то другое. Это буквально стандартное поведение, а ты жалуешься, что Godot на Windows ведёт себя так же, как он ведёт себя на Linux? В чём твоя проблема, беды с башкой?
Ещё забыл уточнить:
>Это примерно как приделать включение света к открыванию двери. Кому-то это покажется прикольно, что в туалете свет загорается сам, а у меня вот другая планировка и мне не надо чтобы свет горел все время когда комната проветривается.
Это почему ты туалет проветриваешь открыванием двери, лол? В нормальной планировке в туалете есть вентиляция/вытяжка, которая высасывает все запахи даже при закрытой двери. Если ты дверь в туалет держишь открытой и у тебя в туалете воняет, то эта вся вонь в другие комнаты перейдёт - зачем? Лучше уж пусть в туалете воняет, чем во всей квартире/во всём доме. А если у тебя вентиляция/вытяжка не предусмотрена, сам виноват, что построил такую непродуманную херню/выбрал эту квартиру при покупке... Думать надо было! А теперь на кого-то ругаешься, что он предлагает дельное решение, которое тебе не подходит из-за твоей же собственной ошибки с проветриванием того, что проветривать по определению не нужно или даже вредно.
Т.е. ты сам себе палки в колёса ставишь и ещё на кого-то ругаешься.
>>41749
>для того что должен уметь .exe из коробки (запуск в окне)
WTF, ты вообще Godot хоть раз запускал? Он всегда в окне запускается. Без консоли. Чтобы консоль была, нужно эту консоль сначала открыть - вручную или через bat/cmd - и только потом в ней запустить Godot. Режим по умолчанию - окно без консоли, режим для извращенцев - консоль с окном. В ЧЁМ ТВОЯ ПРОБЛЕМА?
>запускать ДОПОЛНИТЕЛЬНУЮ программу (cmd.exe)
Лол, так ты же САМ только что жаловался, что ты запускаешь cmd.exe и в нём вбиваешь godot.exe, из-за чего Godot начинает срать в консоль, тебе НЕПРИЯТНО и ты хочешь по какой-то извращённой причине запускать godot.exe из cmd.exe без вывода журнала событий godot в эту консоль... Ты сам представляешь, на что ты жалуешься? Ты буквально жалуешься на то, что ты сам, осознанно делаешь. ЗАЧЕМ ты это делаешь?
>которая создаст новый терминал (!) загружая шрифты и прочие оснастки которые в нем крутятся
На моём древнем процессоре это за долю секунды происходит. Никакой новый терминал не создаётся и никакие шрифты не загружаются... ты просто даже не пробовал вводить указанную мной команду. Скажи честно, тебе просто посраться с кем-нибудь хочется, правда?
>чтобы... Он тут же мигнул и закрылся!
Мигает только заголовок окна консоли, если на него не смотреть - ничего не заметишь. Это реально не то, что ты там себе выдумываешь. Вот попробуй и реши сам, нужно оно тебе или нет. Хотя ты по-прежнему не сказал, ЗАЧЕМ тебе нужно такое извращение, когда ты можешь ПРОСТО запустить Godot как делают все нормальные люди - с ярлыка в каком-либо меню или в какой-либо папке. Тебе не нужно запускать консоль, если тебе не нужен вывод журнала событий в консоль.
Я вообще не понимаю, в чём твоя проблема, ведь если ты настолько привык к линуксу, то там, ВНЕЗАПНО, любое приложение при запуске с консоли занимает эту консоль ПОД СЕБЯ, и тебе нужно открывать новую консоль в отдельном окне/вкладке, чтобы делать что-то другое. Это буквально стандартное поведение, а ты жалуешься, что Godot на Windows ведёт себя так же, как он ведёт себя на Linux? В чём твоя проблема, беды с башкой?
65 Кб, 640x788>>41744
Ещё забыл уточнить:
Это почему ты туалет проветриваешь открыванием двери, лол? В нормальной планировке в туалете есть вентиляция/вытяжка, которая высасывает все запахи даже при закрытой двери. Если ты дверь в туалет держишь открытой и у тебя в туалете воняет, то эта вся вонь в другие комнаты перейдёт - зачем? Лучше уж пусть в туалете воняет, чем во всей квартире/во всём доме. А если у тебя вентиляция/вытяжка не предусмотрена, сам виноват, что построил такую непродуманную херню/выбрал эту квартиру при покупке... Думать надо было! А теперь на кого-то ругаешься, что он предлагает дельное решение, которое тебе не подходит из-за твоей же собственной ошибки с проветриванием того, что проветривать по определению не нужно или даже вредно.
Т.е. ты сам себе палки в колёса ставишь и ещё на кого-то ругаешься.
>>41749
WTF, ты вообще Godot хоть раз запускал? Он всегда в окне запускается. Без консоли. Чтобы консоль была, нужно эту консоль сначала открыть - вручную или через bat/cmd - и только потом в ней запустить Godot. Режим по умолчанию - окно без консоли, режим для извращенцев - консоль с окном. В ЧЁМ ТВОЯ ПРОБЛЕМА?
Лол, так ты же САМ только что жаловался, что ты запускаешь cmd.exe и в нём вбиваешь godot.exe, из-за чего Godot начинает срать в консоль, тебе НЕПРИЯТНО и ты хочешь по какой-то извращённой причине запускать godot.exe из cmd.exe без вывода журнала событий godot в эту консоль... Ты сам представляешь, на что ты жалуешься? Ты буквально жалуешься на то, что ты сам, осознанно делаешь. ЗАЧЕМ ты это делаешь?
На моём древнем процессоре это за долю секунды происходит. Никакой новый терминал не создаётся и никакие шрифты не загружаются... ты просто даже не пробовал вводить указанную мной команду. Скажи честно, тебе просто посраться с кем-нибудь хочется, правда?
Мигает только заголовок окна консоли, если на него не смотреть - ничего не заметишь. Это реально не то, что ты там себе выдумываешь. Вот попробуй и реши сам, нужно оно тебе или нет. Хотя ты по-прежнему не сказал, ЗАЧЕМ тебе нужно такое извращение, когда ты можешь ПРОСТО запустить Godot как делают все нормальные люди - с ярлыка в каком-либо меню или в какой-либо папке. Тебе не нужно запускать консоль, если тебе не нужен вывод журнала событий в консоль.
Я вообще не понимаю, в чём твоя проблема, ведь если ты настолько привык к линуксу, то там, ВНЕЗАПНО, любое приложение при запуске с консоли занимает эту консоль ПОД СЕБЯ, и тебе нужно открывать новую консоль в отдельном окне/вкладке, чтобы делать что-то другое. Это буквально стандартное поведение, а ты жалуешься, что Godot на Windows ведёт себя так же, как он ведёт себя на Linux? В чём твоя проблема, беды с башкой?
Ещё забыл уточнить:
>Это примерно как приделать включение света к открыванию двери. Кому-то это покажется прикольно, что в туалете свет загорается сам, а у меня вот другая планировка и мне не надо чтобы свет горел все время когда комната проветривается.
Это почему ты туалет проветриваешь открыванием двери, лол? В нормальной планировке в туалете есть вентиляция/вытяжка, которая высасывает все запахи даже при закрытой двери. Если ты дверь в туалет держишь открытой и у тебя в туалете воняет, то эта вся вонь в другие комнаты перейдёт - зачем? Лучше уж пусть в туалете воняет, чем во всей квартире/во всём доме. А если у тебя вентиляция/вытяжка не предусмотрена, сам виноват, что построил такую непродуманную херню/выбрал эту квартиру при покупке... Думать надо было! А теперь на кого-то ругаешься, что он предлагает дельное решение, которое тебе не подходит из-за твоей же собственной ошибки с проветриванием того, что проветривать по определению не нужно или даже вредно.
Т.е. ты сам себе палки в колёса ставишь и ещё на кого-то ругаешься.
>>41749
>для того что должен уметь .exe из коробки (запуск в окне)
WTF, ты вообще Godot хоть раз запускал? Он всегда в окне запускается. Без консоли. Чтобы консоль была, нужно эту консоль сначала открыть - вручную или через bat/cmd - и только потом в ней запустить Godot. Режим по умолчанию - окно без консоли, режим для извращенцев - консоль с окном. В ЧЁМ ТВОЯ ПРОБЛЕМА?
>запускать ДОПОЛНИТЕЛЬНУЮ программу (cmd.exe)
Лол, так ты же САМ только что жаловался, что ты запускаешь cmd.exe и в нём вбиваешь godot.exe, из-за чего Godot начинает срать в консоль, тебе НЕПРИЯТНО и ты хочешь по какой-то извращённой причине запускать godot.exe из cmd.exe без вывода журнала событий godot в эту консоль... Ты сам представляешь, на что ты жалуешься? Ты буквально жалуешься на то, что ты сам, осознанно делаешь. ЗАЧЕМ ты это делаешь?
>которая создаст новый терминал (!) загружая шрифты и прочие оснастки которые в нем крутятся
На моём древнем процессоре это за долю секунды происходит. Никакой новый терминал не создаётся и никакие шрифты не загружаются... ты просто даже не пробовал вводить указанную мной команду. Скажи честно, тебе просто посраться с кем-нибудь хочется, правда?
>чтобы... Он тут же мигнул и закрылся!
Мигает только заголовок окна консоли, если на него не смотреть - ничего не заметишь. Это реально не то, что ты там себе выдумываешь. Вот попробуй и реши сам, нужно оно тебе или нет. Хотя ты по-прежнему не сказал, ЗАЧЕМ тебе нужно такое извращение, когда ты можешь ПРОСТО запустить Godot как делают все нормальные люди - с ярлыка в каком-либо меню или в какой-либо папке. Тебе не нужно запускать консоль, если тебе не нужен вывод журнала событий в консоль.
Я вообще не понимаю, в чём твоя проблема, ведь если ты настолько привык к линуксу, то там, ВНЕЗАПНО, любое приложение при запуске с консоли занимает эту консоль ПОД СЕБЯ, и тебе нужно открывать новую консоль в отдельном окне/вкладке, чтобы делать что-то другое. Это буквально стандартное поведение, а ты жалуешься, что Godot на Windows ведёт себя так же, как он ведёт себя на Linux? В чём твоя проблема, беды с башкой?
>>41751
Ты бы хоть читал что цитируешь:
>Это почему ты туалет проветриваешь открыванием двери, лол? В нормальной планировке в туалете есть вентиляция/вытяжка
Ты бы хоть читал что цитируешь:
>а у меня вот другая планировка и мне не надо чтобы свет горел все время когда комната проветривается.
15 Кб, 321x476>>41751
WYF, ты вообще мой пост читал? Я запускаю БАТНИК, который делает еще другие вещи, не только запуск годота. Прикинь, когда кликают по БАТНИКУ, там запускается консоль, которая мне и нужна, а вывод годота в нее не нужен. Более того, годот естественно портит вывод в консоль своими сообщениями, в результате ее лог становится нечитаемым и не анализируемым. Конечно, твой костыль можно приспособить, но почему бы это не сделать просто нормальным режимом при запуске .exe?
Понятно, надо просто моргать и не смотреть на экран, потому что разработчики движка не разобрались как аттачить консоль. Слушай, а может ты движкосрачер? Хотя даже там такой чуши мне хейтеры годота не писали.
>WTF, ты вообще Godot хоть раз запускал? Он всегда в окне запускается. Без консоли.
WYF, ты вообще мой пост читал? Я запускаю БАТНИК, который делает еще другие вещи, не только запуск годота. Прикинь, когда кликают по БАТНИКУ, там запускается консоль, которая мне и нужна, а вывод годота в нее не нужен. Более того, годот естественно портит вывод в консоль своими сообщениями, в результате ее лог становится нечитаемым и не анализируемым. Конечно, твой костыль можно приспособить, но почему бы это не сделать просто нормальным режимом при запуске .exe?
>Мигает только заголовок окна консоли, если на него не смотреть - ничего не заметишь.
Понятно, надо просто моргать и не смотреть на экран, потому что разработчики движка не разобрались как аттачить консоль. Слушай, а может ты движкосрачер? Хотя даже там такой чуши мне хейтеры годота не писали.
>>41754
Сам-то читал цитату?
О других комнатах речи не шло. Туалет - это комната.
Т.е. он буквально проветривает туалет. Открытой дверью.
>>41755
На, кушай, смотри не обляпайся:
@echo off
chcp 1251
cls
echo пук
cmd /c start Godot.exe
:fart
echo пук
goto fart
Не костыль, а лайфхак. Фил зе дифференсе!
Я протестировал (на Godot 3.5). Ничего там не мигает.
Это ты, походу, движкосрачер, всё время какие-то косяки Godot ищешь, да найти не можешь - вот и бесишься от бессилия. Выдумал на ходу какой-то батник с Test-тами, лишь бы реальным делом не заниматься. Вот что тебе может быть нужно делать в батнике непосредственно перед запуском Godot? Ты игры делаешь или что? Я с Godot уже 2-3 года занимаюсь, ни разу не приходилось в батнике перед запуском Godot что-то делать. Но ты нашёл, до чего докопаться, и теперь дельные советы не слушаешь - копротивляешься, лишь бы Godot в чём-то обвинить.
>комната
Сам-то читал цитату?
>...что в туалете свет загорается сам
О других комнатах речи не шло. Туалет - это комната.
Т.е. он буквально проветривает туалет. Открытой дверью.
>>41755
На, кушай, смотри не обляпайся:
@echo off
chcp 1251
cls
echo пук
cmd /c start Godot.exe
:fart
echo пук
goto fart
>костыль
Не костыль, а лайфхак. Фил зе дифференсе!
>просто моргать и не смотреть на экран
Я протестировал (на Godot 3.5). Ничего там не мигает.
>Слушай, а может ты движкосрачер?
Это ты, походу, движкосрачер, всё время какие-то косяки Godot ищешь, да найти не можешь - вот и бесишься от бессилия. Выдумал на ходу какой-то батник с Test-тами, лишь бы реальным делом не заниматься. Вот что тебе может быть нужно делать в батнике непосредственно перед запуском Godot? Ты игры делаешь или что? Я с Godot уже 2-3 года занимаюсь, ни разу не приходилось в батнике перед запуском Godot что-то делать. Но ты нашёл, до чего докопаться, и теперь дельные советы не слушаешь - копротивляешься, лишь бы Godot в чём-то обвинить.
>>41762
Нет, не игры. Утилиты. Много чего делает, коммерческая тайна.
Отучайся так мыслить. Это неконструктивно. Особенно в опен сорсе. Линукс не меньше 10 лет так потерял, когда вместо мастдая все плодили дистрибутивы и говорили УМВР, вместо того чтобы ориентироваться на удобство пользователей.
Я бы и не докапывался, если бы каждая новая версия не ломала поведение. Сначала были просто exe, потом появился cmd с /k, теперь опять все переписывать на cmd /c, а потом они таки решат исправить поведение и опять что-то переделают.
Кстати, а как с твоим докапыванием поступим? Ты же написал, что два exe неправильно. Как же так, святая команда ошиблась?
>что тебе может быть нужно делать в батнике непосредственно перед запуском Godot? Ты игры делаешь или что?
Нет, не игры. Утилиты. Много чего делает, коммерческая тайна.
>мне не нужно значит никому не нужно, поэтому никому не нужно
Отучайся так мыслить. Это неконструктивно. Особенно в опен сорсе. Линукс не меньше 10 лет так потерял, когда вместо мастдая все плодили дистрибутивы и говорили УМВР, вместо того чтобы ориентироваться на удобство пользователей.
>Но ты нашёл, до чего докопаться
Я бы и не докапывался, если бы каждая новая версия не ломала поведение. Сначала были просто exe, потом появился cmd с /k, теперь опять все переписывать на cmd /c, а потом они таки решат исправить поведение и опять что-то переделают.
Кстати, а как с твоим докапыванием поступим? Ты же написал, что два exe неправильно. Как же так, святая команда ошиблась?
>>41767
Так ведь это нормально. Если у тебя какой-то чёткий порядок дел, который ты не можешь себе позволить менять прямо сейчас - не обновляй софт, от которого зависит этот порядок. Я вот редко обновляю софт: все автоматические обновления отключил; если у программы нет критических багов и меня набор функций устраивает - не обновляю, пока не узнаю о выходе версии с очень полезной фичей, да и в таком случае десять раз подумаю, прежде чем обновляться. Godot - не исключение, редко проверяю новые версии и обновляюсь только когда прочитаю список изменений. Если ты не первый год за ПК работаешь, давно должен был себя к этому приучить и не жаловаться, ведь это норма.
С файлами exe на Windows такая фигня, что даже если ты не используешь никакие "инсталяторы", Windows автоматически регистрирует exe где-то у себя в реестре. И если ты реестр не чистишь, у тебя там скапливается очень много лишнего мусора на каждый из этих exe, даже если ты давно удалил файл, переименовал или переместил его в новую папку. CCleaner на такие записи в реестре пишет что-то вроде "возможно, программа удалена некорректно", когда связанного с записью exe больше нет. Короче... Батник был лучше. Легче, чище, надёжнее.
Возможно, есть причины сделать exe. Возможно, это как-то связано с Windows 11 и UWP, т.к. Microsoft постоянно что-то меняют. Может быть, механизм bat/cmd уходит на покой - и в будущих версиях Windows перестанет работать. Нужно смотреть на гитхабе, по какой причине они решили перейти на отдельный exe файл, в чём причины и преимущества.
Мне просто не понравилось, что они решили сделать отдельный жирный exe - мало того, что он в 400 раз жирнее прежнего cmd, так они же на C++ кодят, почему у них простой лаунчер 400 КБ весит? Как будто там какая-то очень жирная библиотека на 390+ КБ зашита, зачем она там? Но, опять же, я сужу по одному твоему скриншоту и не знаю, что там на гитхабе обсуждали - наверняка причины всего этого есть и их обсуждали.
В любом случае, их решения всё же пока что лучше, чем у Unity с UE, а в крайнем случае никто не запрещает сделать свой форк с лаунчером и кастомными консолями. А я вообще регулярно думаю о том, чтобы написать свой собственный ЯП с виртуальной машиной и библиотеками, так что особо меня не слушай...
>если бы каждая новая версия не ломала поведение
Так ведь это нормально. Если у тебя какой-то чёткий порядок дел, который ты не можешь себе позволить менять прямо сейчас - не обновляй софт, от которого зависит этот порядок. Я вот редко обновляю софт: все автоматические обновления отключил; если у программы нет критических багов и меня набор функций устраивает - не обновляю, пока не узнаю о выходе версии с очень полезной фичей, да и в таком случае десять раз подумаю, прежде чем обновляться. Godot - не исключение, редко проверяю новые версии и обновляюсь только когда прочитаю список изменений. Если ты не первый год за ПК работаешь, давно должен был себя к этому приучить и не жаловаться, ведь это норма.
>Ты же написал, что два exe неправильно.
С файлами exe на Windows такая фигня, что даже если ты не используешь никакие "инсталяторы", Windows автоматически регистрирует exe где-то у себя в реестре. И если ты реестр не чистишь, у тебя там скапливается очень много лишнего мусора на каждый из этих exe, даже если ты давно удалил файл, переименовал или переместил его в новую папку. CCleaner на такие записи в реестре пишет что-то вроде "возможно, программа удалена некорректно", когда связанного с записью exe больше нет. Короче... Батник был лучше. Легче, чище, надёжнее.
>Как же так, святая команда ошиблась?
Возможно, есть причины сделать exe. Возможно, это как-то связано с Windows 11 и UWP, т.к. Microsoft постоянно что-то меняют. Может быть, механизм bat/cmd уходит на покой - и в будущих версиях Windows перестанет работать. Нужно смотреть на гитхабе, по какой причине они решили перейти на отдельный exe файл, в чём причины и преимущества.
Мне просто не понравилось, что они решили сделать отдельный жирный exe - мало того, что он в 400 раз жирнее прежнего cmd, так они же на C++ кодят, почему у них простой лаунчер 400 КБ весит? Как будто там какая-то очень жирная библиотека на 390+ КБ зашита, зачем она там? Но, опять же, я сужу по одному твоему скриншоту и не знаю, что там на гитхабе обсуждали - наверняка причины всего этого есть и их обсуждали.
В любом случае, их решения всё же пока что лучше, чем у Unity с UE, а в крайнем случае никто не запрещает сделать свой форк с лаунчером и кастомными консолями. А я вообще регулярно думаю о том, чтобы написать свой собственный ЯП с виртуальной машиной и библиотеками, так что особо меня не слушай...
>>41767
Так ведь это нормально. Если у тебя какой-то чёткий порядок дел, который ты не можешь себе позволить менять прямо сейчас - не обновляй софт, от которого зависит этот порядок. Я вот редко обновляю софт: все автоматические обновления отключил; если у программы нет критических багов и меня набор функций устраивает - не обновляю, пока не узнаю о выходе версии с очень полезной фичей, да и в таком случае десять раз подумаю, прежде чем обновляться. Godot - не исключение, редко проверяю новые версии и обновляюсь только когда прочитаю список изменений. Если ты не первый год за ПК работаешь, давно должен был себя к этому приучить и не жаловаться, ведь это норма.
С файлами exe на Windows такая фигня, что даже если ты не используешь никакие "инсталяторы", Windows автоматически регистрирует exe где-то у себя в реестре. И если ты реестр не чистишь, у тебя там скапливается очень много лишнего мусора на каждый из этих exe, даже если ты давно удалил файл, переименовал или переместил его в новую папку. CCleaner на такие записи в реестре пишет что-то вроде "возможно, программа удалена некорректно", когда связанного с записью exe больше нет. Короче... Батник был лучше. Легче, чище, надёжнее.
Возможно, есть причины сделать exe. Возможно, это как-то связано с Windows 11 и UWP, т.к. Microsoft постоянно что-то меняют. Может быть, механизм bat/cmd уходит на покой - и в будущих версиях Windows перестанет работать. Нужно смотреть на гитхабе, по какой причине они решили перейти на отдельный exe файл, в чём причины и преимущества.
Мне просто не понравилось, что они решили сделать отдельный жирный exe - мало того, что он в 400 раз жирнее прежнего cmd, так они же на C++ кодят, почему у них простой лаунчер 400 КБ весит? Как будто там какая-то очень жирная библиотека на 390+ КБ зашита, зачем она там? Но, опять же, я сужу по одному твоему скриншоту и не знаю, что там на гитхабе обсуждали - наверняка причины всего этого есть и их обсуждали.
В любом случае, их решения всё же пока что лучше, чем у Unity с UE, а в крайнем случае никто не запрещает сделать свой форк с лаунчером и кастомными консолями. А я вообще регулярно думаю о том, чтобы написать свой собственный ЯП с виртуальной машиной и библиотеками, так что особо меня не слушай...
>если бы каждая новая версия не ломала поведение
Так ведь это нормально. Если у тебя какой-то чёткий порядок дел, который ты не можешь себе позволить менять прямо сейчас - не обновляй софт, от которого зависит этот порядок. Я вот редко обновляю софт: все автоматические обновления отключил; если у программы нет критических багов и меня набор функций устраивает - не обновляю, пока не узнаю о выходе версии с очень полезной фичей, да и в таком случае десять раз подумаю, прежде чем обновляться. Godot - не исключение, редко проверяю новые версии и обновляюсь только когда прочитаю список изменений. Если ты не первый год за ПК работаешь, давно должен был себя к этому приучить и не жаловаться, ведь это норма.
>Ты же написал, что два exe неправильно.
С файлами exe на Windows такая фигня, что даже если ты не используешь никакие "инсталяторы", Windows автоматически регистрирует exe где-то у себя в реестре. И если ты реестр не чистишь, у тебя там скапливается очень много лишнего мусора на каждый из этих exe, даже если ты давно удалил файл, переименовал или переместил его в новую папку. CCleaner на такие записи в реестре пишет что-то вроде "возможно, программа удалена некорректно", когда связанного с записью exe больше нет. Короче... Батник был лучше. Легче, чище, надёжнее.
>Как же так, святая команда ошиблась?
Возможно, есть причины сделать exe. Возможно, это как-то связано с Windows 11 и UWP, т.к. Microsoft постоянно что-то меняют. Может быть, механизм bat/cmd уходит на покой - и в будущих версиях Windows перестанет работать. Нужно смотреть на гитхабе, по какой причине они решили перейти на отдельный exe файл, в чём причины и преимущества.
Мне просто не понравилось, что они решили сделать отдельный жирный exe - мало того, что он в 400 раз жирнее прежнего cmd, так они же на C++ кодят, почему у них простой лаунчер 400 КБ весит? Как будто там какая-то очень жирная библиотека на 390+ КБ зашита, зачем она там? Но, опять же, я сужу по одному твоему скриншоту и не знаю, что там на гитхабе обсуждали - наверняка причины всего этого есть и их обсуждали.
В любом случае, их решения всё же пока что лучше, чем у Unity с UE, а в крайнем случае никто не запрещает сделать свой форк с лаунчером и кастомными консолями. А я вообще регулярно думаю о том, чтобы написать свой собственный ЯП с виртуальной машиной и библиотеками, так что особо меня не слушай...
>>41508
Как бы сказать, проблем много. Это не ошибки, просто такой код зачастую вызывает проблемы. Будет лучше всего, если ты своими словами опишешь, какого поведения хотел добиться, а я (или кто-то другой) накидаю тебе код, который будет это поведение реализовывать. Потому что, скорее всего, весь твой код можно свернуть в одну сравнительно простую операцию, но изучать его в таком виде сложно - проще будет, если ты словами опишешь, чего ты хотел. Скорее всего твоя проблема в том, что ты слабо разбираешься в булевой логике, из-за этого получилось столько if-ов с проверками 4-х клавиш.
На счёт считывания состояний клавиш читай это:
https://docs.godotengine.org/en/stable/tutorials/inputs/index.html
>Только чур не блевать.
Как бы сказать, проблем много. Это не ошибки, просто такой код зачастую вызывает проблемы. Будет лучше всего, если ты своими словами опишешь, какого поведения хотел добиться, а я (или кто-то другой) накидаю тебе код, который будет это поведение реализовывать. Потому что, скорее всего, весь твой код можно свернуть в одну сравнительно простую операцию, но изучать его в таком виде сложно - проще будет, если ты словами опишешь, чего ты хотел. Скорее всего твоя проблема в том, что ты слабо разбираешься в булевой логике, из-за этого получилось столько if-ов с проверками 4-х клавиш.
На счёт считывания состояний клавиш читай это:
https://docs.godotengine.org/en/stable/tutorials/inputs/index.html
>>41788
чтобы персонаж ходил в сторону последней зажатой клавиши даже если направления противоположные. Допустим, зажали w, пошли вверх, не отпуская w нажали s, пошли вниз, если отпустили s, то опять пошли вверх.
Что ты имеешь в виду? За что там шарить? там операций не так много... конъюнкция дизъюнкция импликация и т.д., есть ещё всякие побитовые сдвиги и побитовая проверка. Так написал потому что это единственный способ с которым работает так как мне надо.
>словами опишешь
чтобы персонаж ходил в сторону последней зажатой клавиши даже если направления противоположные. Допустим, зажали w, пошли вверх, не отпуская w нажали s, пошли вниз, если отпустили s, то опять пошли вверх.
>Скорее всего твоя проблема в том, что ты слабо разбираешься в булевой логике
Что ты имеешь в виду? За что там шарить? там операций не так много... конъюнкция дизъюнкция импликация и т.д., есть ещё всякие побитовые сдвиги и побитовая проверка. Так написал потому что это единственный способ с которым работает так как мне надо.
>>41790
Опачки? В какой версии её ввели? Вот будет обидно, если она всегда там была.
> Input.get_vector()
Опачки? В какой версии её ввели? Вот будет обидно, если она всегда там была.
>>41811
Сам спросил - сам ответил. В 3.4.
Сам спросил - сам ответил. В 3.4.
>>41772
Кстати да. Им удалось продавить свой помершел. Даже сторонние девелоперы консольных утилит (scoop например) рекомендуют юзать помершел.
мимо проходил, ваш срач не читал
> Может быть, механизм bat/cmd уходит на покой - и в будущих версиях Windows перестанет работать.
Кстати да. Им удалось продавить свой помершел. Даже сторонние девелоперы консольных утилит (scoop например) рекомендуют юзать помершел.
мимо проходил, ваш срач не читал
>>41789
Хорошо. Не знаю, зачем тебе это может быть нужно - странная схема управления, конечно... Но я бы сделал это так - используя массив зажатых клавиш, которому нажатые клавиши добавляются в конец, при отпускании клавиши она из массива удаляется, а при выборе направления движения используется последняя запись в этом массиве - т.е. гарантированно последняя нажатая клавиша. При этом количество сохранённых клавиш ограничено только количеством интересующих тебя действий и физическими возможностями клавиатуры пользователя: на механической скорее всего можно зажать все клавиши сразу, на мембранной будут ограничения. У меня мембранная и я смог полноценно протестировать этот код только благодаря тому, что назначил действия одновременно на WASD и стрелочки - в такой конфигурации я могу держать зажатыми все 4 клавиши направления. На механической, наверное, можно зажать и 8 или больше клавиш, если тебе это настолько нужно, но вряд ли хорошо завязывать на это геймплей - ведь у большинства игроков, скорее всего, обычные мембранные клавиатуры.
Недостатки: хранение и сравнение множества строк, операции с массивом. Но это всё быстро.
Достоинства: легко дополнить другими действиями, код хорошо читается - понятен сразу.
А зачем тебе нужно всё это? Что-то я не встречал в играх подобного управления.
>зажали w, пошли вверх, не отпуская w нажали s, пошли вниз, если отпустили s, то опять пошли вверх.
Хорошо. Не знаю, зачем тебе это может быть нужно - странная схема управления, конечно... Но я бы сделал это так - используя массив зажатых клавиш, которому нажатые клавиши добавляются в конец, при отпускании клавиши она из массива удаляется, а при выборе направления движения используется последняя запись в этом массиве - т.е. гарантированно последняя нажатая клавиша. При этом количество сохранённых клавиш ограничено только количеством интересующих тебя действий и физическими возможностями клавиатуры пользователя: на механической скорее всего можно зажать все клавиши сразу, на мембранной будут ограничения. У меня мембранная и я смог полноценно протестировать этот код только благодаря тому, что назначил действия одновременно на WASD и стрелочки - в такой конфигурации я могу держать зажатыми все 4 клавиши направления. На механической, наверное, можно зажать и 8 или больше клавиш, если тебе это настолько нужно, но вряд ли хорошо завязывать на это геймплей - ведь у большинства игроков, скорее всего, обычные мембранные клавиатуры.
Недостатки: хранение и сравнение множества строк, операции с массивом. Но это всё быстро.
Достоинства: легко дополнить другими действиями, код хорошо читается - понятен сразу.
А зачем тебе нужно всё это? Что-то я не встречал в играх подобного управления.
>>41789
Решение таково:
1. Регистрируем для кнопок pressed и released отдельно.
2. Складываем в две отдельные очереди.
3. Стейтмашина персонажа обрабатывает очереди.
Но вообще да, управление странное и будет работать только на клавишах клавиатуры, ни на стиках, ни на крестовинах геймпадов такое не заработает по очевидной причине: нажатие в противоположную сторону идет после прохождения стиком центра, следовательно предыдущая сторона будет отпущена перед нажатием текущей.
> чтобы персонаж ходил в сторону последней зажатой клавиши даже если направления противоположные.
Решение таково:
1. Регистрируем для кнопок pressed и released отдельно.
2. Складываем в две отдельные очереди.
3. Стейтмашина персонажа обрабатывает очереди.
Но вообще да, управление странное и будет работать только на клавишах клавиатуры, ни на стиках, ни на крестовинах геймпадов такое не заработает по очевидной причине: нажатие в противоположную сторону идет после прохождения стиком центра, следовательно предыдущая сторона будет отпущена перед нажатием текущей.
Тред утонул или удален.
Это копия, сохраненная 19 апреля в 06:36.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 19 апреля в 06:36.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.