Шапка: https://hipolink.me/godothread
Предыдущий 81: >>1092274 (OP)
---
Maintenance release: Godot 4.7.1: https://godotengine.org/article/maintenance-release-godot-4-7-1/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
>пик1
Зачем на коробках говном намазали? Норм же пикча была. Какая-то прям уж чрезмерная шиза на движкосраче.
>>1097241 →
Это из-за несовместимости файловой системы Windows и Linux/Android. Если ты создашь файл MyScene.tscn и myscene.tscn, то в линуксе это будет 2 разных файла, а виндоус - одинаковый и какой-то из них перезапишет второй. И да, это выстреливало у людей в разных проектах, при скачивании аддона или при экспорте на телефон. Поэтому логичнее называть все в одном регистре, но тогда слова сливаются, поэтому добавляют подчеркивание my_scene.tscn
Да и в с++ такой стандарт, так что лучше сразу привыкать к хорошему.
>Зачем на коробках говном намазали?
Это же милые змейки с глазками.
>Это из-за несовместимости файловой системы
Я это знаю, на практике никогда такого не случалось, если придерживаешься одного стиля (например у джавистов).
Как-будто проблема преувеличена.
То что можно случайно рекурсивно снести папку .gdignore со всеми сорцами - их не беспокоит, а проблема 1% процента линуксоидов, которые это знают с рождения на генетическом уровне - беспокоит
Кто полжизни жил с верблюдом (или паскалем), это может помочь, все равно все соло сидят.
Как ты вообще с такой чувствительной мотивацией что-то сделал.
Я не умею рисовать. Хочется чтобы было симпатично, это легко. Я взял иконку и подписал ее названием аддона. А потом оказалось что надо ее очень большую делать и вообще красивую. Ну я и забил, мне лень этим заниматься. Старый ассет стор был в этом плане куда добрее.
Вот кто украл твою мотивацию.
https://store.godotengine.org/asset/godot-foundation/scene-changer-demo/
Я же написал что хочется чтобы было красиво. Сделать в пеинте картинку пустую дело нехитрое. Привлечет ли аддон этим внимание? Нет.
Опять кринжово-нейрослоповый перекат...
Тебе не надоело этот ШИЗО РИФТ пиарить?
>>1097230 →
>"фу..." (особенно после артов херстоуна)
Фу - это кринжово-слоповый арт всратстоуна.
Они слопили свои карточки ещё до нейросетей.
>>1097226 →
>Есть ли готовые кодовые базы
>>1097330 →
>есть локации, ты ходишь по ним
>находишь НПС/врагов/сюжетное
>сидишь напротив соперника
>ещё окружение будет решать
За код не беспокойся, ты забросишь из-за арта.
>>1097379
>Сделал классный аддон... аддон классный кстати!
Пруфов, я так понимаю, не будет?
>>1097384
>не умею рисовать. Хочется чтобы было симпатично
Я бы дал советы, но, по-моему, ты просто троллишь.
Нихуя ты натолстил. Если бы на симпатичный дизайн внимания не обращали и на нормальное оформление, то дохуя каких продуктов бы не продались. Ты еще расскажи сказку что капсула в стиме не решает, ага.
>>1097396
> Пруфов, я так понимаю, не будет?
Ну на пруф. Аддон за тебя автоматом генерирует мапки пикрил 1 вида чтобы можно было потом удобно без ебли с уидами загружать ресурсы как например. Поменял путь ресурса с картинкой или звук - генератор за тебя маппинг пересоздаст и ты будешь уверен что твой меин меню или Sounds.Attack всегда один и тот же.
SignalManager.switch_ui_scene.emit(UIConsts.MAIN_MENU)
SignalManager.switch_ui_scene.connect(_on_switch_ui)
func _on_switch_ui(sceneUiName: StringName) -> void:
var new_ui_path: StringName = UIDMaps.UI_PATHS.get(sceneUiName, "")
var new_ui_resource: PackedScene = SceneLoaderManager.load_scene(new_ui_path)
var new_ui_node: Node = new_ui_resource.instantiate()
add_child(new_ui_node)
И твой охуительный совет небось будет "открой чатгпт и сгенерь лол)))"
Это еще что. Когда/если игру сделаешь, и начнешь публиковать ее, охуеешь сколько ассетов разных размеров и аспектов требуется. Плюс видосы еще. Сидишь нарезаешь как дурак. Я после энной игры уже не делаю готовые картинки, а имею отдельные слои каждого элемента картинки, чтобы потом, по требованию, накидать их по-быстрому и, например, не отпиливать персонажу половину головы. И так под каждый стор.
Когда сделаю тогда и пригоню как блинчик, все верно. Сейчас в процессе полировки демки. Ее пока думаю через итч погонять и потом залить в стим расширенную версию с новым уровнем и добавить в демо несколько ачивок.
>Аддон за тебя автоматом генерирует мапки
Я не понял, ты реализовал механизм перетаскивание с UID неймингом?
>ты натолстил
Я выбираю только розовые аддоны, функционал мне не интересен
Да, браток, я тоже помню что уид 57865336776pfsxxikbcdse это ссылка на сцену двери, я же в голове все их держу
Извини, но это какой-то ненужный велосипед...
>И твой охуительный совет небось будет
Не обвешивать свой проект лапшой типа:
>SignalManager.switch_ui_scene.emit
Потом очень больно будет переделывать.
А что касается UID в скриптах - я ими не пользуюсь принципиально, разве что в грубом прототипе, что планируется выкинуть/удалить в тот же день. Для постоянного кода, который планируется в будущем использовать, где нужна надёжность, лучше так:
>@export var main_menu: PackedScene
>@export var pause_menu: PackedScene
>@export var settings_menu: PackedScene
И пробросить нужные файлы в инспекторе.
Если нужна только ссылка на файл, тогда:
>@export_file var main_menu_path: String
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#strings-as-paths
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-annotation-export-file
>Note: The file will be stored and referenced as UID, if available. This ensures that the reference is valid even when the file is moved. You can use ResourceUID methods to convert it to path.
>Тебе не надоело этот ШИЗО РИФТ пиарить?
О, красиво выглядящая 3д игра. Спасибо, что подсказал, а то я бы не обратил внимания.
>игра
Скорее "симулятор ходьбы по комнатам с !!!КРУТЫМИ ШЕЙДЕРАМИ!!!"...
Как технодемо шейдеров в Godot - это круто, не спорю, но в чём там игра-то?
Самое главное, в своём проекте ты задолбаешься такое имплементировать...
А в моей игре давно подобное имплементировано. Окклюжн куллинг комнат, анимированные трансформации некоторых объектов окружения. Этим кайфово заниматься.
Мне до демки ещё месяца два. Там такая игра что для демки надо 90% механик сделать.
Ого, я же так люблю лишний раз курсорами мыши водить, это же так удобно. Возможно - чисто возможно - была какая-то причина, по которой много кодовой базы запретили юзать var? Надеюсь что поиск ты тоже не через ctrl+f делаешь, а через панель сверху мышкой.
А вообще заебал жирнить, да.
>>1097412
> Не обвешивать свой проект лапшой типа:
Круто, еще ламерские советы будут? Я так понимаю тебя ui напрямую с основным кодом связано, с удовольствием посмотрел бы на портянку состояний когда у тебя игрок связан с окном паузы. Твои системы должны быть настолько разделены, чтобы ты буквально мог скопировать папку ui и условную core в новый проект и они бы там завелись с полпинка. Пописал бы хоть разок в жизни ui на фронту или на винаппы - знал бы про паттерны как это все должно между собой общаться и жить, чтобы в будущем не было попоболи.
> @export
Походу чукча не очень читатель и не знает про проблемы экспорта. В целом мне все понятно, тут все ожидаемо было.
>Тебе не надоело этот ШИЗО РИФТ пиарить?
Обычно видосы с ним приносил я, а не ОП. И я поддерживаю решение пихнуть в шапку - так меньше тупых вопросов типа "умеет ли годот в 3д". Именно с этой целью и приношу.
Я бы вообще в каждый перекат по 3д игре пихал.
> censored.png
Теряется смысл сидения на берегу реки, если по ней проплывают какие-то безымянные ящики. Годетта не для того на берегу реки сидела.
>скопировать папку ui и условную core в новый проект
Скопировал, а там:
>Синглтон <синглтон> не синглтон, попробуйте синглтонить тоньше.
Лады, настроил этот синглтон, а там:
>Функция не функция, <синглтон> не тот синглтон, попробуйте другой.
ОК, попутал что-то, бывает, попробуем что-то другое:
>ERROR: ACCESS VIOLATION
WTF??? Придётся прочёсывать весь код и рефакторить его полностью...
>Походу чукча не очень читатель и не знает про проблемы экспорта
Ну так поведай нам об этих Великих Проблемах Экспорта, ЧИТАТЕЛЬ.
>>1097454
>так меньше тупых вопросов типа "умеет ли годот в 3д"
У таких сил не хватит на то, чтобы сделать игру: это ж гуглить надо!
-------------------------------------------
func _ready():
...._start.call_deferred()
func _start():
....pass
-------------------------------------------
Если дернуть call_deferred в _ready она очередью отработает после всех _ready до первого _proccess. Пользуйтесь
>Ого, я же так люблю лишний раз курсорами мыши водить, это же так удобно
Ну да, она же на соседнем столе. Вообще uid удобен для постоянного рефакторинга и перетаскивания. Если ты человек без мышки, то тебе и uid ненужон.
>Надеюсь что поиск ты тоже не через ctrl+f делаешь
Забавно, но чаще почему-то нужен ctrl+shift+f (наверное, потому что есть список методов) или Ctrl + R анализируя твои вскрики, я делаю вывод, что эти хоткеи я узнал еще до твоего рождения
>пик
Я представляю как тебе больно, давайте скинемся и купим человеку мышку, пускай новыми фичами хоть попользуется.
>Возможно - чисто возможно - была какая-то причина, по которой много кодовой базы запретили юзать var?
Ппц у тебя бардак в голове.
>и не знает про проблемы экспорта
Экспорт самая удобная форма uid.
Какой чепухой люди готовы заниматься чтобы не делать игры.
>Синглтон <синглтон> не синглтон, попробуйте синглтонить тоньше.
Будем честны, когда мы создаем новый проект мы мержим или вообще копируем файл project.godot. Руками заново писать инпуты, группы и прочее настройки - такое себе. Вместе с этим залетают и синглтоны, а там и папка core с 80% кодом, который пора выкинуть.
Вообще, я заметил локатор Game.some_service довольно популярен. А локатор между сценами нужен по-любому, особенно на прототипах (ручной DI это звездец вообще)
Кто мы, кто мы-то? У меня каждая игра в другом жанре в другом стиле с другой графикой и с другим управлением. Сейчас бы переносить все из пиксельного пошагового паззла в 3д гоночки.
>вопросов типа "умеет ли годот в 3д"
Так все знают что не умеет и сделать демку на 10 секунд не равно в уметь
Человек-оркестр.
А я и голоса в голове мы стагнируем в Два-Ди
Прост интересно как именно разные жанры делаются, какие особенности, подводные камни и все такое.
Если кому надо (может ошибку найдет)
https://hastebin.com/share/reyocizavi.swift
Простая задача оказалась не очень простой из-за того что в сигналах может быть разное число аргументов.
>Простая задача оказалась не очень простой из-за того что в сигналах может быть разное число аргументов.
А зачем ты анбиндишь аргументы своей же _on_signal у которой нет аргументов? Не понял логику
Если сигнал передает аргумент, а у коллбэка его нет - вылетает ошибка. Я хз, можно ли сделать лучше.
Они реально придумали костыль, вместо того чтобы всегда передавать один объект (в других языках - event). При этом еще назвали unbind, что звучит как противодействие bind.
>Если сигнал передает аргумент, а у коллбэка его нет - вылетает ошибка.
Да, понял, логика чутка не сходится - аргумент анбиндится у коллбека
Можно вот так написать, не создавая лишний обьект без надобности:
>var callback: Callable = _on_signal
>что звучит как противодействие bind.
Этот анбинд скорее всего сохраняется в объекте Callback и сигнал делат что-то типа
> callback.bind(arg).unbind(callback.unbind_count).call()
>Можно вот так написать, не создавая лишний обьект без надобности:
>>var callback: Callable = _on_signal
Аргумент unbind не абсолютный.
Ты передашь 3, потом 1 - в итоге у тебя будет висеть 2 (а не 1 как ожидал и это свалиться с ошибкой, потому что меньше можно, больше нельзя). С новыми объектами такой "памяти" нет.
>что звучит как противодействие bind.
Я хотел сказать отменяющий. В общем, обычно "bind" это что-то прикрепляют и открепляют. Я зол на то, что это херово гуглилось, а потом еще не очевидно понималось.
А в пошаговой херне без WaitGroup вообще тяжко (или я тупой, но точно я не хочу размазывать логику по сигналам)
https://www.youtube.com/watch?v=4zmN3z5yUSM
[crying mode]
Забавно, когда видишь ячейко-ориентированную пошаговую игру - думаешь как легко такое можно сделать. А на деле же это ппц когда у тебя уже есть движок.
Ну например волк/медведь занимает уже два тайла, а тролль все четыре - ты уже думаешь в рамках body-коллайдеров, а не одного тайла.
Потом области и взаимодействие. Тебе надо с нуля писать квадратную арену и вычисления того кто туда попадает и кто выходит, а с учетом выше информации у тебя и сами объекты уже не точка в пространстве, а какой-то объем тайлов.
Так же перемещение, ты постепенно начинаешь используешь tween'ы чтобы имитировать импульс движения.
То есть, ты начинаешь писать свою физику, только единица вычисления у тебя ячейка 64х64. А писать свою физику - ну такое себе.
Сразу же появляется мысль - просто адаптировать коллайдеры под квадратные тайлы. Но тогда рушиться все. Вся простота дешевизна тайлового расчета, даже AStar начинает посасывать с навигацией (и уже хочется выкинуть его, а ты все еще в тайловой-перемещении). И я молчу про производительность.
Мне уже кажется что для кого-то 3д шутана - беги стреляй, кода будет на порядок меньше, чем для тайловой пошаговой игры, где тебе нужно все переизбирать (а я же не собираюсь писать свой движок, да?).
И вот ловишь кризис - а может ну его? И сделать просто реалтайм top-down RPG - добавить стрельбу, а чтобы не просрать дух средневековьея - засунуть пост-апокалипсис. Ведь стрельба лучше смотрится чем когда спрайты трутся близи. В общем, опять кризис почаны.
Думать, унижен, прокрастинация.
бля ну я не такой как другие они то хуйню делают а у меня все четко разложено по уму
>рим ворлд
Сначала нужно книгу от великого прочитать. Только гений может написать книгу по геймдизайну за 5 лет до релиза своей первой игры.
Надеюсь там рассказывается как раскрутить пустую игру на кикстартере и заработать на мододелах.
>данжеон/рим ворлд
Если серьезно, кидай задумку. Игру ты на вряд ли сделаешь, а мы хоть обмусолим. Я примерно в такой же области стагнирую
Вообще не о чем. Многопоточность это такая штука, в которую стоит инвестировать свое время, чтобы потом задница не сгорела от странных плавающих проблем.
А вы тоже в годот видосах смотрите какая у челиков видеокарта? :3
1 пошаговой jrpg боёвки
2 перемещения по локации как в elin или rpg maker (квадратная сетка), дискретные ходы, угол обзора не важен.
3 диалогов, как в визуальных новеллах
4 генерации локаций
Это, вроде, не сложно сделать, но, наверняка, до меня это уже 100 раз в годоте делали и лучше просто скопировать. Поэтому я сам не тороплюсь начинать, а готовлюсь пока.
Пошаговые бои на системе AP
Четыре клана, у каждого своя глазная техника и узоры. Прокачка до трёх стадий, а через события в битвах смертельные раны, смерть родственника, может пробудиться высшая форма: 20 уникальных вариантов узор отображаемых прямо на кукле персонажа. Способности жгут здоровье глаза, так что можно ослепнуть навсегда. Глаза разрешено пересаживать и собирать комбинации заклинаний разных кланов.
Оружие учебное оружие для всех но первых же боях оно навсегда превращается в уникальный тип (от генов и атрибутов) - (двуручный меч, катана, парные серпы, сюрикены и так далее ), получает свой скин и случайный модификатор, а позже открывает особые приёмы.
Стихии (Огонь, Вода, Молния, Земля, Воздух) пробуждаются прямо по ходу сражений. Можно выучить до трёх случайных заклинаний.
Тело собрано из отдельных частей: голова, торс, руки, ноги, органы. Критические удары вызывают кровотечения, переломы, пробивают броню. Шрамы и травмы остаются навсегда и отображается на скине персонажа.
Бойцов можно выращивать (до определённого момента). Они наследуют около полусотни генов: цвет волос, склонность к стихиям, атрибуты, модификаторы оружия. Взрослеют за несколько недель и сразу идут в бой. Потеря бойца — это разрыв рода.
Игровой цикл строится на турнирах один на один и миссиях. Персонажи растут по принципу «что тренируешь, то и качается», плюс большое древо перков. Погибшие попадают на кладбище с полной историей жизни. Выжившие сражаются, пока не останется последний — он уходит в Новую игру+ как финальный босс.
> А вы тоже в годот видосах смотрите какая у челиков видеокарта? :3
Начинаем смотреть, а потом теряем сознание, с частичной потерей памяти.
>Начинаем смотреть, а потом теряем сознание, с частичной потерей памяти.
Пробовал выключить и включить?
> на системе AP
Что это?
>паста
Обязательно покажи демку всего этого если санитары не отберут
Мне больше было интересно как ты совместишь даркест данжеон и римворлд и главное зачем? Сама по себе боевка в римке не самая плохая, чтобы превращать это в пошаговую. Но вот ближний бой там идиотский (судя по видосам, в начале ближнего боя не было, это было чисто ковбойский вариант). Это говорит о том, что начальный дизайн всегда определяет игру (а люди постоянно начинают с процедурной генерации, вместо основного геймплея).
Делай.
AP- action point это что бы каждый удар мечем/магия стоит свое количество очков действий,
в рим ворлде боевка просто авто-бой где ты один раз команду дал и персонаж режет/стреляет, для целей римворлда достаточно, но если игра про сами бои такая система не подходит, потому что в рамках боя нужно использовать десяток видов атак/бафоф/расходников предметов
Если разделять на тактическую и стратегическую карту то римка это уже тактическая карта.
Например есть герои3 - ты ходишь по миру - стратегическая. Сам бой на поле это тактический.
Как ты хочешь переключить из плавной анимации в пошаговую на одном и том же типе карты?
>в рим ворлде боевка просто авто-бой где ты один раз команду дал
Посмотри как популярные игроки мансят группами и разводят пачки. Там много контроля с паузами. Просто люди привыкли к киллбоксам.
ИМХО: лучше сделать полностью автоматических юнитов, чтобы они в ближнем бою сходились с врагами, а ты просто кастовал скиллы/ауры на минимальной скорости (без нудятины в виде шагов)
у меня в идеи нету стратегической карты
есть один хаб где делаются всякие улучшение, тренировки, магазин, выбор режимы турнира
и вторая сцена уже самой битвы тоесть это как в даркест данжеон хаб -> битва, только твой противник не абстрактный скелет, а реальный персонаж другого клана который так же учавствуется в боях, так же получает травмы, пробуждает способности, тоесть он существует даже за кадром и их десяток
а сам бой детализирован как по системе римворлда, что бы каждая поврежденные орган/отрубленная конечность влияла на атрибуты персонажа
как ты говоришь в римворлде тоже паузят/мансят группы врагов, но ведь это обрубок получается, тот же самый пошаг только с двумя действиями, атаковать -> отойти и так по кругу, лучше это же систему развернуть в глубину что бы игрок принимал решение какой скилл нажать сейчас, как накопить очков что бы билд синергировал с доступными заклинаниями, пробафаться сейчас что бы потом раздать критов, это полноценный слой тактики и мне кажется он необходим в игре которая буквально строится на этих боях, а то получится МЯСОКУБ со 2 пика
история сама пишется
Так бы и сказал что хочешь здоровье и повреждения по органам. Потому что когда вспоминают римку думают о другом совсем.
В пошаговых играх именно тактическая составляющая быстро надоедает, даже в серии тотал вар хочется скипнуть бой (может у меня только так). Поэтому отказ от стратегической карты может быть ошибка (ради чего играть - у тебя нет приключения, бой ради боя)
ну как бы бой и является самим приключением, он наполнен историей сам по себе, генерация историй, уникальные билды прокачки, вон в slay the spire смотришь в отзывах там люди по 50-600 часов наигрывают, в боевке ее и заключен весь смысл путешествия
>Slay the Spire
Я не играл но, по фото это около ККИ? У кки отдельный пласт стимуляций и мотиваций.
Я скажу через призму херстоуна.
Во первых выпадение карт случайно, а значит каждый бой не похож на предыдущий (что и угнетает в пошаговом тактическом бое именно тактическом, потому что всякие цивилизации и гладиусы норм заходят, даже на 10часов игры одной сессии). Ты буквально испытываешь всплеск гормонов в башке когда выпадает или не выпадает нужная карта (в нужной момент). Мне думается там стимуляции на уровне лудомании (когда тебе победная комбинация выпадает в сложном бою).
Во вторых это коллекционирование - это сильный стимул (даже гаче не снились те донаты).
В третьих билдостроение и синергии карт. Собрать синергию в колоде это круче чем бой.
Что-то там еще есть, но мне лень вспоминать. Но в тоже время ты не сделаешь коллекционных монстров, это другая иммерсивность. Юнит живой и должен умирать, не умирающий юнит сразу режет восприятие.
>Почему из коробки нет WaitGroup?
Если кратко: это костыль для говнокода.
>>1097591
>может быть разное число аргументов
RTFM и следи за новостями движка почаще:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#variadic-functions
Но сам я не проверял такого рода говнокоды.
>>1097620
>А в пошаговой херне без WaitGroup вообще тяжко
Попробуй сделать шаг назад, посмотреть на свою архитектуру со стороны и попытаться объяснить конкретную проблему тому, кто не разбирается в ней (резиновой утке, LLM чатботу, гдачерам ИТТ). Тогда, возможно, к тебе придёт осознание, как будет лучше.
Думаю, главное, это осознать, что абсолютно любая видеоигра "пошаговая" из-за чёткого деления всего происходящего на экране на дискретные кадры - единственное отличие "экшена" от, скажем, простых шахмат, является то, что "экшен" имеет действие по умолчанию, называемое "idle", которое выбирается автоматически, если игрок не нажимает кнопки. Т.е. пошаговость никуда не девается, просто шаг экшена сокращается до 1/60 секунды или даже меньше.
В экшен-играх редко требуется ждать завершения множества событий, следовательно, и в геймплее пошаговой игры этого делать не стоит. Ты просто передвигаешь фишки по доске - один раз за шаг - и возвращаешься к слушанью ввода игрока. Где тут приходится ожидать несколько сигналов? Нигде.
>например волк/медведь занимает уже два тайла, а тролль все четыре - ты уже думаешь в рамках body-коллайдеров, а не одного тайла.
Бред какой-то, зачем тебе это? Если я не ошибаюсь, большинство пошаговых игр делает 99% мобов/NPC одноклеточными, как и игрок. Да-да, как ты себе и представил: маленькая крыска/змейка занимает на клеточном поле столько же, сколько 4-хметровый турбокачок с громадной битой, и эта же клетка приравнивается к дверному проёму. Единственное исключение - какие-то супер-мега-боссы, которые фиксируются в центре арены и никуда не ходят.
Это называется "игровая условность". В шахматах, к примеру, все фигуры занимают одну клетку, хотя они символизируют разные по размеру ИРЛ объекты. Тут главное, это подумать: нужны ли объекты с разными габаритами для геймплея или нет? Что они дадут? Реалистичность ради реалистичности оставь ААА киношникам, делающим мокап циркового медведя с единственной целью "сделать прям как в жЫзни!!!".
Ну а если тебе прям очень нужен противник, который блокирует своей тушей 2x2 клетки, то я не вижу здесь совершенно никакой проблемы. Ты просто заюзаешь банальный код Тетриса, который пишется даже без специального игрового движка за один вечер и используется с совершенно любой геометрией.
>Если кратко: это костыль для говнокода.
Вообще это база там где есть корутины. Не помню как называется в дотнете, но в го это точно WaitGroup.
>RTFM и следи за новостями движка почаще:
Я хз, я порой гуглю чистое API и даже в документацию попасть не могу. Какое-то безумие с этими вашими нейронками.
Да, это упростило код. Ты странный, кидаешься, но все равно помогаешь. Значит еще не все потеряно с тобой.
https://hastebin.com/share/zehunagere.go
>и в геймплее пошаговой игры этого делать не стоит
Меня пока все устраивает. Я не хочу метод дробить на 3-4 сигнала, когда есть корутины. Тем более там такая тесная и местечковая логика (буквально подождать твин итд), что вообще не хочется гадить в сигналы.
Помогли бы анонимные функции (хендлеры), но лучше одна обертка чем где-то обосраться потом в лямбде
Почему надо ждать? Да потому что надо видеть шаг и не допустить прокликивание (перс просто полетит как в реалтайме). А в дальнейшем нельзя допускать чтобы весь мир прокликивался быстро (это шахматы, а не экшн). Ну и в целом в стоуншарде иногда не чувствуется ход в бою, этого я хочу избежать. И надо еще решать проблему дабл-клика мышки у людей. Это в вебе раньше было сложно поймать эту фигню, тут это легко будет
>тактическая составляющая быстро надоедает
Блин, ну не умеешь, не любишь играть в тактику - не вылезай со своими советами "это надоест", когда тут анонимус твёрдо и чётко хочет сделать свою тактику. Игровой жанр существует, у него есть свои фанаты, аудитория. Ты же не попадаешь в эту аудиторию - не проблема, играй в другие игры, и разрабатывай свои в других жанрах. Зачем мешать другим геймдевам?
Ты пришёл на детскую площадку, увидел, как дети в кукольный домик играют, и начал: "а чё это вы тут с куколками играете, это же быстро надоедает, вот возьмите набор юного тракториста, перебирайте реалистичную модель дизельного двигателя!" - это нормально вообще? Кто ты после этого, а? Тут всё практически то же, только анонимус хочет своих виртуальных куколок и чтоб они месили друг друга до соплей, крови и шрамов. Чё ты к нему пристал?
>>1097704
Я вижу, ты сильно увлечён своей идеей игры, и много напридумывал уже. Советую притормозить немного, проанализировать задумки и выделить главное - тот фундамент, без которого всё остальное не работает. Реализуй этот фундамент без графики и деталей, чтоб получился играбельный прототип, а потом уже думай, интегрировать какие-то дополнительные детали или отложить на потом. А то у тебя сейчас много всего, и непонятно, как всё это будет балансироваться - я-то приблизительно понял все твои идеи, но сплести из отдельных идей целую игру всегда очень сложно.
>Бред какой-то, зачем тебе это?
Потом покажу. Простыми словами - мишка длинный и юнит залезает на спрайт. А так юнит будет бить ему по жопе. Очень сильно ощущается проблема с мини-боссами, ты либо пытаешь в тайле уместиться, а хочешь все равно жирнича и спрайты налезают (в стонике есть момент когда вообще не видно из-за суммонов босса), либо просто уже сделать честный 2х2
Так же урон по области (например огненное поле). Если игрок видит что юнит цепляет огонь - значит правда должен цеплять.
>Да-да, как ты себе и представил: маленькая крыска/змейка занимает на клеточном поле столько же,
Абалдеть.
>Единственное исключение - какие-то супер-мега-боссы, которые фиксируются в центре арены и никуда не ходят.
Уже научились ходить
https://rutube.ru/video/9bd401f4c2f64b03f688bb3b60e8c3ce/
>Ты просто заюзаешь банальный код Тетриса, который пишется даже без специального игрового движка за один вечер и используется с совершенно любой геометрией.
Все это напишется, но когда по соседству готовые коллайдеры, как-то завидно, что можно вообще о таких деталях не думать (надо же поныть).
да не, чел мне все по делу писал, нужно тоже со всех сторон обдумывать вкатит или нет игрокам, а так да понятно в планах просто каждую механику задуманную в единичном экземпляре собрать и сидеть месяцами множить мясо на готовый скелет
>Блин, ну не умеешь, не любишь играть в тактику
Стратегии и пошаговые самые мои любые жанры.
Я не говорю что нельзя сделать интересную пошаговую. Есть вариант с 3D, где анимация как в экшене тебя развлекает, есть фулл пошаговые где игра тебя держит стратегией и планированием, есть рандомайзер ККИ (но плохой рандомайзер как XCOM), есть билдостроение. А есть герои где ты играешь одним отрядом убер-стрелков или одним и тем же прокастом.
А есть боевые братки. Просто дикий дефицит в тактике, но из-за одушевления юнитов ты ощущаешь ценность каждого в отряде.
Вот этот стример привносит просто дикую иммерсивность для относительно пустой игры.
https://www.youtube.com/watch?v=s46G5SBVBO8&list=PLbWv5TDR2JwC0DsdGsMfHieSuqY-X6DTE
>Ты странный, кидаешься, но все равно помогаешь.
Н-не то, что бы я хотел п-помочь такому т-тупому быдлокодеру, просто... Просто я мимо проходил и... Случайно вспомнил нужную информацию. Не пойми неправильно, это не потому что... Аргх! (ударил в лоб, покраснев, словно помидор, развернулся и убежал)
>не допустить прокликивание
Имхо, лучше делать в точности наоборот: разрешать полностью скипать все ненужные анимации ходов, "ускоряя" геймплей по требованию игрока вплоть до "реалтаймового", если игрок будет достаточно шустро прожимать все клавиши действий. Это база, без этой функции играть в пошаговые игры тяжко и скучно.
Вот как я вижу идеальный пошаговый синглплеер:
1. Игрок видит статичное состояние мира.
2. Игрок выбирает своё следующее действие.
3. Игра СРАЗУ ЖЕ переходит на следующий шаг.
4. Игра запускает анимации, типа:
>tween.tween_property(self, "position", actual_pos, time)
5. ЕСЛИ игрок нажмёт кнопку действия:
5.1. Игра скипает все анимации:
>if tween: tween.kill() # прерывание
>position = actual_pos # скачок
5.2. Переходим на шаг 3.
6. Если игрок ничего не нажал, переходим к 1.
Такая схема позволяет игрокам:
- играть (думать) так медленно, как они хотят;
- быстро скипать любые скучные моменты игры.
Ну, да, нужна задержка ~100 мс против дабл-клика.
>>1097765
Ты смешиваешь проблемы спрайтов с проблемами геймплея... Раньше такие игры ASCII символы юзали вообще, и нормально выглядело, потом вместо этих символов нацепили 32x32 спрайты и стало КРУТО, а некоторые даже 3D модели умудряются сделать. Т.е. геймплей задаёт формат графики, а не наоборот. Ну, разумеется, бывают проблемы из-за наложения нескольких спрайтов, но игроки к этому привычны, определить положение обычно поможно с помощью дополнительного экрана/GUI с точной информацией.
Ты же не симулятор ходьбы по спрайтам делаешь, от спрайтов нужно только чтобы игрок мог определить опасного врага/ценный лут/безопасное место, без специальной книжки со списком "(B) - это bear, а (b) - barrel, смотри не перепутай, когда делаешь /piss".
Ну а если хочешь красоту наводить, то, наверное, ты перепутал жанр, и нужно делать экшон, суть токова: ходишь красивой тянкой по подземельям, лупишь монстриков няшных в бубен, если проиграл - сценка прикольная на половину экрана, а самое приятное - респавн без потери лута... одежду покупать можно... подземные корованы грабить... Джве минуты хочу.
>быдлокодеру
Забавно это слышать от человека который не знает про WaitGroup, а корутины это быдлокод.
>Игра СРАЗУ ЖЕ переходит на следующий шаг.
Когда начнешь делать игры - увидишь что такой переход выглядит мгновенным и непонятным для игрока (нет вообще перехода, чистая телепортация). В оригинале даже добавили небольшой прыжок, чтобы ощущался фидбэк от клика/шага.
У меня прыжок по параболе как затычка, в реале там немного по другому сделано, чтобы вне боя двигаться почти реалтайм.
Норм получится, не переживай. Еще через год присоединишься к проекту, я тебя знаю.
>>1097776
в чем смысл вашего спора если можно попросить чат гпт написать скрипт и он сделает оптимальный метод хехе село бля) развивайтесь
Они тут в отрицании всего, что касается нейронок. Тяжелая травма от общения с Алисой. Небось до сих пор код руками пишут.
>Забавно это слышать от человека который не знает
Забавно видеть человека, не знающего о цундерах...
>переход выглядит мгновенным и непонятным
Ну, удачи с игрой, в которой игрок делает так:
1. Ткнул влево (вправо/вверх/вниз).
2. Подождал 1-2-5-10 секунд анимации...
3. Повторил 1-2 шаги 100-500 раз, зевая от скуки.
4. Оооо, геймплей!!!! ...это слайм на 3.5 шага...
5. Повторяем с шага 1 до тошноты.
6. Умер от скуки (и механики голода).
Ещё добавь супер-долгие катсцены, будет 10/10.
>Еще через год присоединишься к проекту
К т-тебе?! Да ни за что на свете!.. д-дурашка...
>>1097780
В чём смысл поста если ты мог спросить чатжпт?
>К т-тебе?! Да ни за что на свете!.. д-дурашка...
Да, ты еще предложишь другое название. Название реально поменяем, а стиль оставим. Это я точно помню. Из-за тебя потом уйдет часть кор команды на втором проекте.
Как всегда нейродебил пытается усидеть на всех стульях. Используя еще примитивные приемы лести, чтобы сосать токены у далеких от технической области людей.
Кстати, есть годная общепризнанная библия геймдева? Чтоб ёмко без размусоливаний
У тебя есть знания, которые могу приносить миллионы долларов даже не работая. То есть, качество таких знаний позволяют полностью инвестировать и не работать - только руководить (или расписать ТЗ). Но вместо этого ты год-два-три пишешь книгу, постоянно перечитываешь, фиксишь, еще издатель тебе фиксы присылает. И в итоге за 4 года продаж ты получаешь 50-100$, вместо миллионов за свои знания.
Что-то не очень, да?
Запомни «Кто умеет — делает, кто не умеет — тот учит»
Да ладно, обычная ноутбучная встройка, ничего выдающегося
>нейродебил
>Используя еще примитивные приемы лести
Хммм, не могу понять - это ad hominem или на ступеньку выше?
В любом случае, растёшь! Хотя бы не просто поток оскорблений.
>>1097784
Базированная нейротянучка, молодец! Всё знаешь! Так держать!
>>1097786
Ты тут кого-то с кем-то перепутал или я не знаю твоего мема...
>>1097813
Можно быть тренером и при этом не быть мастером спорта.
>В любом случае, растёшь! Хотя бы не просто поток оскорблений.
Ты говно!
>Можно быть тренером и при этом не быть мастером спорта.
Тренер как раз нужен как субличность, а не учитель. Он тренирует/развивает тебя и дополняет (учит только в начале). Например матч - ты выпал в тильт из-за неудачи, но в реале все еще можно перевернуть. Сам ты из под тильты это не сделаешь никогда (поверь), а тренер сбросит эту херню.
Возведи меня в авторитет и представь я буду каждый день приходить и наставлять тебя делать игру. И уже не будет такого "ладно, еще одну серию аниме посмотрю". Удобно же
Речь не о том, что делает тренер/учитель, а о том, что у человека может не быть возможности или даже желания самостоятельно достичь чего-то, но есть возможность или желание помочь кому-то другому достичь этого. Вот ты говоришь про "миллионы денег", а разве все люди хотят достичь "миллионов денег" любой ценой? Есть масса людей, которым хочется просто расслабляться и ничего не делать. Они могут расслабляться после смены на заводе или в офисе, и не стремиться к повышению зарплаты, потому что им не нужно. Если у такого человека ВНЕЗАПНО есть какой-то опыт и глубокие мысли по геймдеву, он не побежит сломя голову договариваться с инвесторами, издателями и площадками, собирать и управлять сотрудниками, вести налоговый учёт, арендовать офис и машины, и строить свою ММОРПГ, которая перевернёт весь мир - но он мог бы передать свои мысли кому-то, кому не лень заниматься всем этим и получить профит.
По крайней мере, в теории, такие люди точно должны существовать, и они наверняка написали какие-то книги. Но я подобными книгами никогда не интересовался, так что не знаю. Я пробовал начать читать пару книжек на тему геймдизайна - не затянуло, я вообще только форумы читаю последние несколько лет. Но говорить "все книги написаны шарлатанами, которые ничего не знают и не понимают, потому что если б знали и понимали, то не писали бы" - как-то глупо, попахивает какой-то теорией заговора, по которой все люди действуют одинаково и обязательно в корыстных целях.
>"все книги написаны шарлатанами,
Ты возводишь до бинарного мышления. Почему сразу шарлатаны? Там скорее всего есть какая-то информация, но ценность такой информации сомнительная.
Ты уже пришел из мира игр и уже скорее всего будешь просто повторять какие-то удобные вещи.
Там был эксперимент, вкратце сажали людей которые никогда не играли и они терялись в базовых вещах которые известны нам игрокам. Так же я с девушкой играл, она тоже терялась в каких-то примитивных вещах, о которых я даже не задумывался и делал по интуиции.
Просто играй - повторяй удобное - все, весь геймдизайн (если только тебе не нужно разводить людей на алмазики).
> Есть масса людей, которым хочется просто расслабляться и ничего не делать. Они могут расслабляться после смены на заводе или в офисе, и не стремиться к повышению зарплаты, потому что им не нужно.
А помнишь у тебя была мечта? Сколько мыслей ты тратил на обдумывание геймплея, иногда даже не мог заснуть? А помнишь ту радость и то чувство когда что-то у тебя получалось? Сражу же хотелось даже поделиться, хотя для всех остальных это полная фигня.
Хочешь получить доступ к этому потоку снова? Хочешь этот порыв вместо "прийти с работы и играть, смотреть тупо в экран?". Неужели "это" лучше чем тот вайб?
>ценность такой информации сомнительная
>Просто играй - повторяй удобное - все, весь геймдизайн
Хмм... Есть куча подводных камней, которые трудно заметить, когда ты как игрок делаешь свою собственную игру.
Например, банальное управление: ты привык к определённым клавишам, и даже не задумываешься о том, что кому-то приходится ребиндить клавиши на другие, и в итоге не делаешь ребинд клавиш по всей игре, и из-за этого кто-то страдает.
Баги: ты привык, что у тебя в игре что-то сломано, и забыл пофиксить, потому что интуитивно прожимаешь самую безопасную комбинацию, а игроки этой комбинации не знают и будут тыкаться в софт-локи и баттхёртить из-за незаметного для тебя бага.
Упрощение (QoL) игры: ты можешь накрутить кучу разнообразных механик и потом сломать всю игру одним новым дополнением, которое делает все механики ненужными, не догадываясь, что многие игроки выбирают по умолчанию путь наименьшего сопротивления, а не самый фановый путь; например, твоя игра имеет много механик перемещения и интересные для исследования карты, а ты позже внедряешь в игру необходимость бегать за 20 км и телепорты для быстрого скипа этого бега за 20 км - в итоге все твои игроки только и делают, что телепортируются, а механики движения и все эти красоты на карте остаются никому не нужными, и игроки жалуются, что игра "пустая".
Также и с балансом противников: тебе может казаться, что реально умные враги - это 10/10 механика, ведь тебе известно, как твои NPC организуют свои нападения, перемещаются где-то за стенами и обходят игрока со спины, и тебе известно, где этих NPC поймать и как их скрытно убить, а игроку всё это неизвестно - с его точки зрения, игра тупо заспавнила читерских мобов и несправедливо убила его, всё, он рейджквайнтул, удалил игру, написал злобный отзыв и больше не вернётся.
Мультиплеер - это вообще ад для дизайна из-за того, что все люди разные и среди широкой аудитории обязательно найдутся абьюзеры, гриферы, читеры и прочий сброд, который найдёт любую уязвимость в твоей игре, чтобы сознательно испортить настроение другим игрокам, и не всегда ты можешь "легально" наказать их, не навредив честным игрокам/не нарушив правила.
Большинство игроков не задумываются о таких нюансах, потому что разработчики оставляют всё это за кулисами... Поэтому "просто играть и повторять удобное" недостаточно для достаточно хорошей, надёжной, устойчивой, весёлой для всей своей ЦА игры.
>А помнишь у тебя была мечта?
Что-то я не понял, к чему ты это написал. Я так-то безработный...
Двачую.
>>1097813
Есть еще проще аргумент.
Мы сидим в треде опенсорс движка. По логике того постера, его бы не раздавали бесплатно, ведь на знаниях, заложенных в его написание, можно было заработать миллионы.
Есть разные причины, почему люди делятся знаниями. Очевидный пример, когда уже делал игры и вышел на пенсию. Или когда нет навыка "инвестировать" или навыка "управлять другими через написание ТЗ" или устал от этого.
Ты будешь и так с лупой смотреть другие игры которые копируешь (я вчера смотрел на скорости 0.25 анимацию). Только практика. Только хардкор.
>>1097903
Вот из-за таких умозаключений ты и бедный. Около технические книги пишут чтобы заработать. Поэтому есть 100500 книг по синтаксису С++, но 1,5 книги что делать с этим С++ дальше (это условно, но реально 90-99% книг это покрытие рынка спроса вкатунцов, а не альтруизм. Реальные сложные темы где нужна информация - ты будешь выгрызать кровью и потом, а писать их никто не будет, потому мало кто купит).
>Вот из-за таких умозаключений ты и бедный
Но я богатый... РНН рантье...
>Запомни «Кто умеет — делает, кто не умеет — тот учит»
Очень ограниченное понимание. Немало успешных людей переходят на новый уровень - обучение своему опыту. Это новая ступень удовлетворения своих потребностей. По себе знаю. И задача тут найти среди инфоцыганского мусора вот именно таких
Да, только опять почти все книги только по вкату. Офигенно когда у тебя опыт 20 лет и ты решил поделиться знаниями о синтаксисе (особенно когда с годами некоторые тонкости забываешь и не используешь).
>>1097917
>Не. Сегодня у тебя вангование не задалось.
Не закрывайся от нас, мы с тобой.
Кто еще поддержит тебя когда ты снова сорвешься?
Какие подводные такого подхода (мы вешаем прям чисто скрипт как ноду)?
Именно случаи когда объект представлен в виде единичного сервиса (а не пачки экземпляров, где такой подход не подойдет).
Мнение? Это выглядит по ньюфаже, но мне правда интересно кто использует такой подход или кто обжегся. С локатором вроде как удобно, но засоряет сцену.
>когда ты снова сорвешься
Сорвётся делать игры? Делать игры же?
>>1097903
>сидим в треде опенсорс движка
База. А ведь сколько безызвестных движков было написано в надежде на продажи...
>>1097913
>пишут чтобы заработать. Поэтому есть 100500 книг по синтаксису С++...
Почему ты всё про книги да про книги (которые давно бесплатно можно качать с официальных сайтов в PDF, а не только покупать макулатуру в местном книжном)? Существует масса ютуберов, которые точно так же снимают туториалы по базовым основам какого-то инструмента, а на более сложных темах пукают и обмякают. На что они рассчитывают? Платные курсы делать? Для кого, если они и так всё давно уже бесплатно рассказали? На патреоне сочувствующих собирать? Тоже такая себе затея, если ты не топ среди топов.
Просто существует такой тип людей, которым нравится поучать кого-нибудь тому, что они узнали, даже если поверхностно. Вот есть задроты, которые читают энциклопедию от корки до корки и могли бы ответить на любой вопрос о жизни, вселенной и всём таком, но первыми никогда не заговаривают о своих знаниях. А есть те, кто открыл энциклопедию на случайной странице, прочитал один абзац, охнул от удивления, и поскорее побежал рассказывать всем, кого знает, в стиле "а вы знали, что у многоножек дыхательный аппарат на каждом сегменте тела, а не как у других животных, а ещё он не закрывается, поэтому они вынуждены жить во влажной среде" - если спросить такого о каких-то подробностях, он без понятия, он не биолог, он просто поделился теми крупицами информации, которые его самого увлекли. А когда делиться вот совсем не с кем и при этом в жопе сверлит желание - идёшь на ютуб со своими рассказами, или блог в интернете заводишь, книгу пишешь...
По сути, у таких людей нет ни времени, ни терпения изучать предмет в глубину. Но делиться им не терпится.
>Почему ты всё про книги да про книги
Стартовая нить срача разговора была именно про книги.
>>1097803
>>1097813
>Сорвётся делать игры? Делать игры же?
Когда вышел из запоя только в челябинском банке.
Какие подводные ты ожидаешь? Ну создал ноды и создал. Ты хочешь узнать, может ли движок заглючить и сломаться? Может ли потеряться какой-то блок данных? Или ты про то, можешь ли ты случайно выстрелить себе в ногу говнокодом и потом мучиться рефакторингом? Само по себе добавление нод ни к чему не приведёт, это самая базовая операция Godot. А последствия для поддержки тобой твоего кода зависят от того, что ты там с этим кодом в нодах делаешь и зачем... Я вот с первого взгляда не понимаю, что и зачем ты разбил на 4 отдельных ноды - у тебя уже есть код или это пустышки? Если пустышки, лучше сначала в одном скрипте набросай, потом порежешь на части по настроению...
Алсо, чисто субъективное, но я бы назвал так:
>Turn
>- State
>- Input
>- Step
Без лишних "менеджеров", и тем более без приставок. Ты же дерево составляешь, в дереве сразу видно "приставку" в виде родителя, который по умолчанию является "менеджером" для всех своих детей, поскольку управляет их жизнью (за редким исключением "прыгающей" по дереву ноды, которая никому кроме себя не принадлежит, хотя и меняет родителей).
Другой пример:
>NPC
>- Alice
>- Betty
>- Carla
Тут очевидно же, что нода NPC - "менеджер NPC", а ноды-потомки - это сами NPC.
>Или ты про то, можешь ли ты случайно выстрелить себе в ногу говнокодом и потом мучиться рефакторингом?
this
>>1097943
>Я вот с первого взгляда не понимаю, что и зачем ты разбил на 4 отдельных ноды
Ну класс должен иметь одну ответственность - база.
Менеджер - главный скрипт отвечающий за переходы, в нем регистрируются все "шагающие", он переключает и исполняет. Главный управленец.
State - все состояния (аля стейтмашина без машины), просто чтобы в менеджер не срать и отделить состояния от простых переменных.
Input - тут все перехваты импутов для игры, по идеи надо делать отдельно, но чет пока на практике импуты сильно завязаны к контексту игры, я прям в Turn и засунул (скажем для UI в другое место положу).
Step - есть общий код (движения, атака итд.), пока тут лежит, еще не сообразил как лучше сделать.
>Алсо, чисто субъективное, но я бы назвал так:
Хотелось бы, но нет namespace. У меня этих "State" уже 3 штуки. Приходится всегда прификсы писать.
Только что проверил - без названия "class_name" нельзя прикрепить чисто скрипт. Но можно создать просто ноду2д и к нему уже прикрепить скрипт.
Ощущение говнокода, надо думать.
>Менеджер - главный скрипт отвечающий за переход
Можешь реализовать подмену стандартного SceneTree на свой:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Если эти ноды создаются и добавляются в рантайме через add_child(), тогда, возможно, тебе вообще не нужны ноды - достаточно будет RefCounted. Если тебе нужны какие-то @export параметры, но не нужны ноды, тогда достаточно будет Resource. Если будешь делать через RefCounted, то не обязательно даже выносить в отдельный .gd файл, т.к. существуют "inner classes", которые описываются типа такого:
>class_name TurnManager extends Node
>class TurnState: # подразумевается extends RefCounted, писать не обязательно
>_ var...
>_ func...
>class TurnStateIdle extends TurnState:...
И так далее, всё в одном файле. Единственный минус внутренних классов - они не могут быть потомками Node/Resource, только Object/RefCounted. Но к ним можно обращаться извне их файла через точку:
>var state := TurnManager.TurnStateIdle.new()
Если не ошибаюсь, это должно работать без проблем (давно не проверял).
>>1097978
Вот только сам Godot уже "менеджерит" состояния всех нод - _process, _input и т.д. Нет необходимости навешивать что-то поверх этого, если ты изучишь, поймёшь и примешь то, как именно работает Godot. Именно поэтому мы можем кидать ноды на сцену, писать код в _process, _input и т.п. и оно "just works" - всю тяжёлую работу по менеджменту Godot уже делает под капотом, остаётся только писать свою игру.
>Вот только сам Godot уже "менеджерит" состояния всех нод - _process, _input и т.д
Тут менеджер игровой логики, не движка. Ты что-то смешал все. Я потом просто код кину, посмотришь что это, мне лень писать.
Как в такой обстановке можно что-то делоть? Есть ответы у вас? Принимаются аргументированные возражения
Так давно решено - хендкрафт только больше станет цениться.
скинь ссылки на готовые результаты, что там тебя так впечатлило. я пока видел только условные клоны аркадных игр, может чуть сложнее.
прикол ведь в том, что создание тетриса через вайбкод - это "make tetris" промпт, потому что само слово tetris уже содержит огромное кол-во информации. это не слово само по себе, а ссылка на массив слов "линии сгорают, очки, тетрамино, ...". но ведь если у меня некая механика достаточно конкретная и не имеет явного точного референса, то придется писать не "make mygame", потому mygame не ссылка на что-то, потому что моей игры еще нет, придется писать целиком весь массив инфы, и уже результат будет ну так сяк, ни одного проекта, размера больше чем недельный джем, при это фулл вайбкоженного, не видел пока, чтобы оно прям впечатлило.
https://youtu.be/rKW0jqAAA8A
https://youtu.be/XYCyGbZIR2M
https://youtu.be/5xTj9XOHgQI
Эти особенно удивили. Платформер субмарина вообще пушка
Ну, справедливости ради, эти модели вышли буквально недавно и до какого либо вразумительных примеров ждать полгода-год.
Это не работает с играми, это вообще не особо работает большинству пахую как раз.
1) Нельзя выбрать все кадры (хоткеем)? Можно только мышкой выделить? Нейронки советуют безумие - сделать Ctrl + A но это хоткей создание ноды
2) Нельзя масштабировать мышкой (пропорционально растягивая и сужая по времени)? Только через меню редактирования - фиксированными цифрами?
https://github.com/godotengine/godot-proposals/issues/3532
Ну ладно, чё. У нас у всех же есть врожденное ощущение скорости анимации
Это очень хороший вопрос.
Исследовал эту тему. Тут главная ошибка наследование от Node2D когда это не нужно. Для Node2D делается много телодвижений (движком меняется трансформация, дергается canvas и рендерСервер). Поэтому по возможности лучше унаследовать от Node.
НО! Node тоже не совсем бесплатная фигня, но главная проблема что очень легко вылететь в прогрессию. У тебя 20-30 нод-скриптов у юнита и ты спавнишь 100 юнитов, они в сумме породят 2000-3000 нод. От чего уже будет не так сладко. Это все еще не критично, но показывает как легко попасть в прогрессию, а движок будет делать пустые ненужные телодвижения работы с деревом.
Так что это фигня, я заведомо решил делать игру для калькуляторов, поэтому зачем самому себе гадить.
Они ж там игры не делают и косплеят бабок на лавках, какая им разница. А тут повод порадоваться за тулзы, которые лично ты используешь.
>make smaller games faster
Туда ли ты притащил? Тут местные гении по 10 лет пилят в стол, никому ничего не показывая, трясясь за идею. А потом пук-кек и выгорел.
>говно
>гавно
Это как раз случай, когда надо выключить юношеский максимализм, включить лобные доли отвечающие за критическое мышление и начать постигал азы геймдева.
Пора.
Я Энцо Феррари от геймдева, своим именем говно подписывать отказываюсь.
>Нефига не понял
Нужно чтобы богатый рантье купил игру и декомпилировал для чатика. Чисто в исследовательских целях.
Как вам идея?
Да, она на годоте.
https://www.reddit.com/r/gamedev/comments/1v9z4vi/comment/p0joezf/?context=3
>в реале что-то с шейдерами.
Позиции зелёных кружков считаются в так называемом Compute Shader, т.е. на видеокарте https://docs.godotengine.org/en/latest/tutorials/shaders/compute_shaders.html
Их физика скорее всего интегрирование Верле, большего тут вроде не надо
https://www.youtube.com/watch?v=lS_qeBy3aQI
>большего тут вроде не надо
дополню:
Ну или физика, как в пиксельных играх типа Noita, с вектором гравитации направленным вправо, там вообще ещё проще, тодже есть видео всякие как сделать
>вы только посмотрите на это
Ты это и за десять лет не сделаешь. И я тоже не сделаю. Там какие-то хардкорные математики с GPGPU знаниями, добытыми потом и кровью, а не визуальная новелла или симулятор ходьбы на стандартных нодах.
>make smaller games faster
Им мало игр-однодневок на 2.1 часа геймплея с бесплатными ассетами и геймплеем из 90-х? У них там совершенно не то, что может сделать 99.99% вкатунов в геймдев, прочитав "делайте маленькие игры быстрее"...
>>1098104
>AnimationPlayer
Он пока не подходит для сложных анимаций. Хочешь сложные анимации для 3D - экспортируй из Blender. Для 2D существует множество программ, платных и бесплатных, но лично я ничего порекомендовать не могу пока.
Совет по анимации: сначала сделай все ключевые позиции - начало, конец, резкие повороты - потом проиграй и подвигай ключи, чтобы было правильное ощущение времени - и только после того, как будешь этим доволен, заполняй промежутки между ключевыми позициями интерполяцией и мелкими деталями. Тогда тебе никогда не придётся сжимать/разжимать длинную портянку ключей, кроме динамической адаптации к скорости движения, которая делается внешним параметром плеера/дерева анимаций, а не движением ключей на дорожке.
Создавать анимацию "ключ за ключом" выглядит логично только на первый взгляд новичка - потом осознаёшь, что таким способом ты никогда не сможешь попасть в нужное тебе ощущение, и переходишь на "сверху вниз" (хотя в случае дорожки правильнее сказать "снаружи вовнутрь" или "с краёв к середине").
Я сегодня почти сразу "угадал" скорость (и нужна была только скорость), но в теории есть speed_scale, можно подвигать ползунок, а потом относительно масштабировать все ключи.
Делоть. Только вот если будет успех нейрокабанычи скопируют, а я буду сосать лапу без ресурсов на агромаркетинг
https://store.godotengine.org/asset/blackwater-gator-studios/gator-sprite-studio/
Это жесть. Похоже, геймдев мёртв. Всем придётся играть в Майнкрафт и другие старые игры.
>геймдев мёртв
А мы еще саботируем тем что не делаем игры!
геймдев на подьеме, игры будут все лучше и лучше более сложный и глубокие механики внедряться, щяс нельзя будет сделать залупу порашную потому что ее способен сделать каждый. мы входим в век величайших игр когда каждый способен создать что либо
>А ведь в статикодрисне пришлось бы все методы обмазать асинками
Нет, не пришлось бы
Кодинг де-факто теперь мертв. В вебдеве например он еще мертвей. Я код писал всю жизнь, и крайне странно за всем этим наблюдать, но что есть, то есть. Не небывали, говоря что coding is solved. Только самые тугие динозавры вроде пары местных этого не просекли и все еще потешно набирают код своими крошечными лапками. Взрывная волна метеорита и до них докатится.
Значит остаётся делать то, что получается у меня лучше всего: придумывать истории, сеттинги, целые вселенные, с космогоническими системами, непротиворечиво укладывающимися в общую канву. А игоры по моим историям мне сделает робот.
Просвещайся.
Но с этим нейронки еще лучше чем с кодом, и давно уже. Даже печатные нейрокниги давно есть.
>пук среньк
>Боб Нистром
Так-же, он тебе может показать как реализовать геймлуп для пошаговых перделок https://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/
Если сделаешь достойную игру, а не очередной безыдейный ассетфлип (чем и являются все клоны уже успешных игр), то никакие кабанычи тебе не страшны, а даже наоборот - если они с тебя скопируют, то игроки пронюхают о существовании твоей игры через их маркетинг. То есть кабан тратит деньги на клон, тратит деньги на маркетинг, а игрок обжигается об его агрессивную монетизацию и ищет альтернативы, в результате чего находя тебя с твоим оригиналом. Просто сам не будь кабаном и люди к тебе потянутся. Конечно, есть нюанс: если кабан заявит на тебя за нарушение авторских прав, автоматическая система торговой площадки может встать на его сторону, и без судебного разбирательства твою игру не вернут. Поэтому нужно качать права первым, а не дожидаться, когда кабан решит устроить чистку конкурентов.
>>1098396
Очередной ненужный велосипед с квадратными колёсами от того, кому просто заняться нечем. Лучше бы сделали какой-то более эффективный мост между Godot и другими программами, которые лучше подходят для создания контента. Пока единственная киллер-фича твоей программы в том, что она находится внутри другой программы - у тебя нет киллер-фичи, а значит, твою программу нет смысла скачивать даже бесплатно... Хотя, возможно, такие плагины могут помочь тем, у кого нет доступа к установке нормальных программ на каких-то экзотических платформах. Например, я долгое время перебирал пиксель-арт программы на Android и не нашёл ни одной, которая бы работала совсем без проблем. Если кто-то геймдевит на Godot на Android и хочет пиксель-арт редактор, ему, возможно, будет выгоднее установить плагин на Godot, чем рыться в гугл-помойке в поисках стоящей проги. Но на Windows/Linux и так достаточно программ для рисования, "победить" которые уже нереально.
>>1098415
Чего ты там дожидаешься-то? Это для пошаговой игры? С await'ами можно больно выстрелить себе в ногу, если ты забудешь, кто кого ждёт, и прервёшь событие или запустишь его дважды за один раз. Я лично даже не представляю, можно ли как-то легко дебажить await? По моему опыту, Godot позволяет легко посмотреть: состояние дерева, состояние нод, состояние переменных, стек вызовов функций... Но как посмотреть, кто кого в данный момент "ждёт", я не знаю. Это отображается в стеке вызовов?.. Короче, я стараюсь не использовать await без крайней на то необходимости, когда по-другому никак. И при чём тут статические языки? В статических языках тоже бывает понятие "события"/"сигнала"...
>>1098420 >>1098434
Вы что, кабанчики или гребцы вёслами на галере? Не понимаю вашей паники. Вы так говорите, будто вы всю жизнь вязали одежду на продажу, а потом кабан со швейным станком не просто пришёл, а пришёл, сломал ваши спицы, сжёг клубок ниток и пропихнул закон, уголовно преследующий любого, кто попытается заниматься вязанием одежды вручную. Если вам нравится писать код вручную - никто не обязывает вас юзать нейронки, пишите сколько захотите и чего захотите. Если вам нравится делать игры вручную, с ручным артом и ручным кодом - делайте смело, никто не отберёт у вас инструменты и не прикажет генерировать нейронкой. Вы разводите панику на пустом месте, как будто завтра все компьютеры загорятся и испарятся, а всем людям вживят чипы с принудительным нейрослопом. Даже в случае какого-то глобального катаклизма, останется возможность делать кустарные компьютеры на примитивных транзисторах, программировать их вручную и делать простейшие игры на этом - так что даже в случае апокалипсиса ваши хобби будут довольно защищены от исчезновения. Разве нет?
>>1098480
Креативность имеющихся сегодня LLM опирается только на генератор случайных чисел, который помогает выбрать токены, находящиеся дальше усреднённого статистически значения, но даже с ним модель стремится к чему-то статистически среднему. Более того, проблема с этой креативностью в том, что чем дальше LLM уходит от средних значений своего датасета, тем хуже становится её логика, знания деталей и интеллект в целом. Я неоднократно видел, как LLM впадает в "колею" усреднённых шаблонов, и также неоднократно видел, как LLM резко тупеет, если попытаться своими промптами "выбить из колеи", потому что LLM просто не знает, как ей действовать в описанной ситуации. Это, по всей видимости, фундаментальная проблема архитектуры и/или способа тренировки. Креативность людей в этом плане не сильно лучше, но люди хотя бы не деградируют до пускающих слюну дебилов, когда им подбрасывают незнакомую идею и предлагают что-то сочинить с ней: если писатель имеет высокий интеллект, он не потеряет его, попытавшись написать о том, о чём он раньше не писал. Другими словами, креативность LLM хороша только до тех пор, пока ты не познакомился с тем, какие шаблоны поведения заложены в эту конкретную модель конкретным датасетом; как только ты начинаешь узнавать с первого взгляда шаблоны, модель перестаёт казаться креативной, и выбить её из этого состояния без доучивания на неизвестном тебе датасете (или RLHF) просто нереально.
Но это всё не важно. Даже когда ИИ научатся эффективной креативности без потери интеллекта, возвращаемся к тому же аргументу: никто не отбирает у вас ваше воображение, вы можете сами креативить что захотите, вам это никто не запретит, никто не посадит принудительно на кучу веществ, убивающих мышление, не вырежет кусок мозга и т.д. Я думаю, стоит рассматривать ИИ скорее как партнёра по креативности, чем "замену": если раньше люди могли собираться только сами с собой для посиделок с рассказами, теперь любой сможет устроить такие посиделки с ИИ, обмениваясь с ним своими креативностями и получая от этого удовольствие. Разве это не прекрасно? Радоваться надо.
> с этим нейронки еще лучше чем с кодом, и давно уже
Но читать такое ты не будешь. Ясно.
-Мам, можно мне loop от Боба Нистрома?
-Нет, у нас есть дома корутины!
Я не знаю насколько это практично в дальнейшем, но я бегло написал и пока этого хватает. Корутины не так тяжелы как кажутся, если стейтами не дать их множить в кадре.
> С await'ами можно больно выстрелить себе в ногу
Только на нескольких сигналах (нужен WaitGroup).
Дебаг не может нигде (кроме, вроде, языка котлина, но это не точно).
Это лучше читается чем дробить хендлерами по сигналам. Если это не сигналы, то читается ровно так же как видишь. По производительности дешево.
Да, можно сделать лучше, если бы не кривая система ввода через _unhandled_input(). Это все адаптация из-за него. поныл, но уже привык к продуманности годота, мне еще пасфаендер переписывать, потому что кто-то решил сделать часть API через виртуальный методы, краусавцы
>ваши хобби
Какие хобби? Это бизнес. Вопрос в конкуренции. Всё началось с того момента, как люди начали вести осёдлый образ жизни в связи с аграрной революцией. Мужики, живущие в лесу больше рисковали, у них могло не хватать еды зимой и т.д. Из-за этого и с девушками могло быть сложнее познакомиться. Сейчас так вообще какой шанс лесному отшельнику жениться и жить спокойно с семьёй в своей землянке?
Аналогично и со всякими печатными станками. Люди зарабатывали переписыванием книг, а теперь они становятся луддитами.
Но генеративные нейронки это нифига не технологии. Это другой тип получения преимущества в конкуренции. В средневековье, например, можно было бы получить условное гражданство какого-то королевства, чтобы иметь свою землю. Но для этого надо сходить в военный поход и проявить себя. Были ли луддитами те, кто отказывался от этого? Нет! Так же и с нейронками долбанными. Технологий там немного, больше перераспределение власти.
Да, вроде сначала удобно, привязал через перетаскивание + Alt и делай что хочешь.
НО
-Как только переименовываешь добавленное через Alt тут же слетает привязка (хотя бы протестили чтоли, ну бага же).
-Если ошибка в коде обновление инспектора прекращается. Вот этот инпут лаг просто раздражает. Ты сохранил, а поля еще нет, потому что там где-то в коде что-то не то (в основном с теми же именами).
-Легко запутаться между Нодой и скриптом (открыта одна нода, открыт скрипт из другой ноды - к этому можно привыкнуть?).
-Иногда просто слетают привязки, хз с чем связанно? наверное с переименованием и "импут лагом" инспектора (мне везет, в общем).
Было бы идеально, но увы.
Единственное к чему пришел для статичных нод, это привязывать через нотацию "$SomeName" в родительском скрипте сцене и потом дергать в потомках через owner. Если что-то меняется то только в одном месте (в родители).
Когда постоянно меняешь ноды (прототипируешь) очень этот nodepath неудобен.
Кто не понял
1) В корневой ноде скрипте сцены.
2) В любом ноде по сцене (пофиг на вложенность).
func
shot from pistols
и все что бы сам движок все понимал нахера мне каую то логику писать deal damage if hp туда сюда чето епта что за хуйня отсталая
Потому что простота хуже воровства
Как только ты захочешь больше контроля и то как пистолет должен стрелять, твоя абстракция потечет как фонтан.
Не сразу заметил что автокомплита нет, но кому это надо в прототите :)
>Какие хобби? Это бизнес.
После таких слов обычно пишут "дальше не читал", но ладно, так уж и быть, прочитал.
Ты пойми, что геймдев - это дерьмовый бизнес, особенно если ты соло. Многие завидуют, когда видят, как кто-то там на западе заработал сколько-то там сотен тысяч долларов "за один день с релиза" - и они хотят так же, но когда им говоришь - "работай" - они, внезапно, ничего не хотят. Сколько денег тебе нужно на еду, на кров, электричество, запчасти для компа? Сколько нужно для маркетинга, связей с сообществом игроков? Что из ассетов и у кого ты закажешь, чтобы твоя игра не выглядела как поделка 5-летнего ребёнка на скретче? А потом нужно отщипывать проценты от прибыли площадке, издателю, государству, всем остальным промежуточным лицам. И сколько ты планируешь на остаток прожить? Месяц? После нескольких лет работы? С огромным риском не получить ничего, кроме расходов, то есть с риском улететь в глубокий минус. Это не бизнес, а слот-машина, которая заманивает яркими картинками, громкими звуками и обещанием выиграть джекпот, тогда как большинство игроков будут медленно, но верно уходить в минус...
Поэтому рассматривать геймдев как бизнес будут только наивные дураки или те, у кого уже есть надёжный капитал, которым можно рискнуть и который не жалко потерять впустую в случае, если схема не выгорит, потому что у них есть стабильный пассивный заработок, которого хватает на жизнь, т.е. они не рискуют своей жизнью и свободой. А всем остальным, кто живёт от зряплаты до зряплаты, стоит рассматривать геймдев только как хобби - приятное времяпрепровождение, которое вряд ли принесёт что-то кроме расходов. Ты мог бы заниматься рисованием масляными красками без надежды продать картину с аукциона, но вместо этого занимаешься геймдевом без надежды продать игру за миллионы долларов - что то хобби, что это хобби, разницы никакой.
>Как только переименовываешь тут же слетает привязка
Неправда, ничего не слетает, в .tscn все ссылки обновляются автоматически.
>Если ошибка в коде обновление инспектора прекращается
Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
>открыта одна нода, открыт скрипт из другой ноды
Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
>это привязывать через нотацию "$SomeName"
Главное, используй кэширование, как-то так, например:
>@onready var _my_node := $MyNode as MyNodeClass
Тогда ты не будешь дёргать дерево сцены на каждом get_node().
>потом дергать в потомках через owner
Это не очень подход. Предок становится _ready после всех потомков.
>Когда постоянно меняешь ноды (прототипируешь)
Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html
>>1098744
>автокомплита нет
Можно как-то так попробовать:
>var _o: MyOwnerClass
>func _ready() -> void:
>_ await owner.ready
>_ _o = owner as MyOwnerClass
Но я не уверен, можно ли ждать owner.ready в _ready его потомка...
Что-то такое обычно делается одним из двух способов:
1. Объекты в ООП абстрагируют всё настолько сильно, что тебе достаточно просто "соединить ниточками" несколько крупных блоков и получить желаемое поведение. На этом построены некоторые "визуальные языки", типа Blueprint в UE, геоноды в Blender и т.п. Обычно объекты пишутся программистом, который реализует базовое поведение крупных блоков, а ниточки натягивает дизайнер, который уже определяет, как блоки сочетаются друг с другом в композицию.
2. Domain-Specific Language (DSL): создаётся специальный парсер, который позволяет описывать действия на более естественном языке, скрывая все подробности под капотом интерпретатора. Такое часто можно встретить в визуальных новеллах типа RenPy и движках для текстовых игр, где простой синтаксис более понятен и привычен для писателя, чем для программиста. Программист может дополнять и расширять DSL своими модулями, а уже писатель создаёт композицию.
Теоретически, LLM могла бы использоваться для генерации крупных блоков, которые юзер соединяет ниточками, или для создания/расширения DSL для записи юзером. При условии, что LLM способна выдать надёжный результат, подобные блоки-дополнения были бы более удобным применением LLM, чем если вы генерируете код (вайбкодите) через LLM напрямую. Подумайте: вместо того, чтобы описывать на обычном языке что-то вроде "передвинь пистолет вверх на 50 пикселей сразу после выстрела" и ждать, когда LLM что-то там сгенерирует, вы можете сначала попросить себе универсальный "двигатель объекта" и "стрелятор объектами", а потом соединить ниточками "двигатель" с объектом "пистолет" и "пистолет" со "стрелятором", а потом вбить нужное вам число пикселей в "двигатель", не тратя время на ожидание потенциально багнутого/испорченного кода из LLM. При условии, что все эти блоки, конечно, не содержат багов. Но абстрактный изолированный от всего код LLM должна генерировать более эффективно, чем ту лапшу, которую она стремится сделать, прочитав весь код проекта за раз...
так же я который с опытом програмирования 2 недели щяс это все прочитавший
>Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
Хз что, может автосейв и с этим баги. в эпоху GIT зачем вообще руками сейвить? В общем, даже не хочу разбираться, как-будто можно было для дерева тоже UID придумать, или сделать автозамену nodepath который через доллар.
>Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Где?? Все перерыл.
>Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
Знаю, сомнительная штука. Кто-то вообще пользуется? Как-будто хочется пометить либо все либо ничего. Никогда не знаешь что и куда перетащишь или переименуешь (может только с опытом).
>Можно как-то так попробовать:
Да все равно переменную заводить, проще уже @onreаdy на предка сделать.
Не хватало что-то типа phpDoс/JSDoc где ты редактору можешь указать тип для автокомплита, не вмешиваясь в код, нечто типа
#@var owner: TypeName
>Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Это? Не совсем то. Он еще дергает окно файловой системы (интересно зачем).
Вот если бы по клику ноды такое было.
Unique Nodes удобно юзать, когда у тебя что-то вроде:
>Menu
>_ CenterContainer
>_ _ PanelContainer
>_ _ _ ScrollContainer
>_ _ _ _ VBoxContainer
>_ _ _ _ _ HBoxContainer
>_ _ _ _ _ _ Label
>_ _ _ _ _ _ LineEdit
В прототипе всё это может как-то поменяться или перестроиться, но ты хочешь сохранить ссылку на LineEdit без изменений, потому что там важное поле ввода для чего-то. У тебя есть два способа:
>@export var input_field: LineEdit
И выбрать ноду в инспекторе. Или поставить галочку на Unique Node и:
>@onready var _input_field: LineEdit = $%LineEdit
В первом случае связь сохраняется, если ты меняешь путь или даже имя самой ноды, а во втором случае связь сохраняется, только если ты меняешь положение/путь до ноды в дереве этой сцены.
>>1098792
Ну, обычно у тебя 1 сцена = 1 главный скрипт, а все остальные скрипты являются очень второстепенными/неважными и/или принадлежат отдельным вложенным сценам, которые ты обычно открываешь в новой вкладке, когда тебе хочется как-то их скрипт отредактировать, потому что скрипт завязан на внутренности своей сцены.
Выбор ноды и скрипта в редакторе скриптов не связаны, потому что часто бывает такая ситуация, когда ты должен смотреть на один скрипт и на параметры совершенно другой ноды в сцене. Скажем, SubViewport и Camera2D/3D - они обычно управляются из какого-то постороннего скрипта, а у самих если скрипт и есть, то он не связан с текущей сценой... И если бы редактор каждый раз открывал скрипт какой-то другой по клику на ноду, это было бы дико неудобно, не так ли? Ты можешь открыть нужный скрипт в любой момент по клику на значок "белого листа бумаги" сбоку от ноды, если к этой ноде привязан скрипт.
>В первом случае связь сохраняется, если ты меняешь путь или даже имя самой ноды, а во втором случае связь сохраняется, только если ты меняешь положение/путь до ноды в дереве этой сцены.
ИИшка говорит что редактор следит за переименованием у % (но как она галлюцинирует, ппц, надо это проверять).
Да, со сложным ГУИ это пригодится, согласен (я еще с таким не сталкивался).
>Ну, обычно у тебя
Я уже пришел к какой-то гармонии, мне думается сегодня был последний фулл-рефакторинг. Можно уже начать делать игру. Наверно
Не хороший майндсет. Чтобы заработать миллионы, нужно:
а) хорошая игра
б) относительно незанятая ниша или подниша
в) пиар
Естесственно, что если что-то из этого не делать, то шанс получения плохого результата велик. Хотя правда, что для этого нужно действительно много работать. Чтобы отточить гладкость игры до максимума, чтобы проводить тесты на игроках, чтоб задать основное движение по пиару.
>Чтобы заработать миллионы, нужно:
По собственному опыту советы даешь?
>а) хорошая игра
Кто делает плохие? Игра должна цеплять. А там пусть хоть зеленые точки на экране.
>б) относительно незанятая ниша или подниша
Всегда есть шанс перевернуть любого титана.
>в) пиар
Дорого, у тебя есть только сарафанное радио. Кому-то достаточно наныть на стриме на 200.000$, кому-то придется работать с соцсетями.
дорогу осилит идущий
>редактор следит за переименованием у %
Бред. Символ "%" - это сокращение от get_node(). Редактор даже не предупреждает тебя, если строка в get_node() приведёт к ошибке в рантайме, то есть он за ней не следит. Ещё раз: ты не должен присваивать "%" к @export, т.к. @export нужен только для указания нод через панель инспектора; если ты хочешь брать ноду через "%", тогда используй @onready вместо @export. Разница критическая - т.к. инициализация @export происходит ещё до _init сцены, а вот инициализация @onready происходит непосредственно перед _ready ноды. Поскольку "%" обращается к дереву, у предка он должен происходить только после всех _ready потомков, т.е. в @onready. Возможно, "%" в @export сейчас работает из-за какого-то нового бага - не помню, чтобы это работало раньше.
>>1098814
>хорошая игра
Слишком абстрактное и субъективное понятие. "Хорошесть" игры складывается из многих сложных, неочевидных вещей, и, к тому же, зависит от выбранной целевой аудитории (которую ты отнёс к "нише", хотя это разные понятия). Ты сам свою игру можешь хоть лучшей в мире считать, но если другие люди с тобой не согласны, ты эту игру почти никому не продашь; в то же время, если тебя самого воротит от своей игры, но ты пытаешься сделать "хорошую игру" для других людей, вряд ли у тебя получится действительно хорошо без серьёзных навыков геймдизайнера.
В общем... Лучше делать так, чтобы твоя игра была для тебя удовольствием. Даже если она не сыщет большой популярности у других людей, ты хотя бы не будешь сильно расстроен из-за этого. Если ты будешь делать игру для других через силу, ты потом вдвойне разочаруешься, когда она окажется никому не нужной.
>когда она окажется никому не нужной
Не, ну хотя бы 4000 продаж за 10 лет можно насобирать, если постоянно долбиться в это. И если игра хоть немного стоющая.
Этого достаточно для небольшой игры, которую можно за годик сделать.
Так проще на яндекс пойти там и то больше в месяц выйдет.
Ну, если тебя продажи волнуют больше игр - делай как знаешь...
Я вот вообще уже давно не хочу ничего никуда публиковать...
>Бред. Символ "%"
Ну и зачем этот понос? Ну, проверил - молодец, взял бы просто написал.
Там не просто была приписка что нужно проверить утверждение ИИшки. Нет, надо прям просраться, забрызгать монитор, высрать нечитаемую пасту.
>@export нужен только для указания нод через панель инспектора;
Не только, редактор следит за перемещением и переименованием. Это, вероятно, какая-то попытка победить бестолковый NotePath.
Но вот когда в реальности ты будешь переименовывать ноду со скриптом без самого переименования скрипта? А значит слетят типы, а значит искать зависимость по скриптам (снова Ctrl + Shift + R). В итоге ты приходишь к мысли что вообще не хочешь видить nodepath (или минимизировать его до одного места в сцене).
>прямо щяс украду весь интерфейс
Как-будто они сделали тоже самое.
Да чё там рассказывать, даже локально всё лагает и нихуя не работает блять. Пока заставил только бегать прыгать и говно собирать в инвентрь
Ты делаешь мультиплеер так, будто у тебя есть доведённый до релиза синглплеер, и игорьки просили онлайна.
Ну технически игра готова процентов на 80 если мультик тот же не брать.
Ты каждый кадр пакеты отправляешь? Почему на локалке лагает?
А хз я replication interval побольше сделал а щас до нуля понизил и збс стало, но анимации все поломанный всё равно, а чё там с предметами и оружием происходит я ваще молчу.
>надо прям просраться
Ты чё такой злой, пупсик? Тебя кто-то обидел?
>переименовывать ноду со скриптом без самого переименования скрипта
Ну, бывало такое, а что? Имя/класс скрипта - это общая категория, типа "Button" - "какая-то там кнопка", тогда как имя ноды - это конкретное имя объекта, типа "Play", "Exit", "Restart", "Vasya", "Stats" и т.д. Имя ноды не должно менять имя скрипта и тем более его класс, потому что у тебя может быть много нод одного класса, но с разными именами и предназначениями.
Ещё можно вспомнить, что из-за того, что у нас пока нет namespace, приходится делать длинные имена классов, а нодам в дереве удобнее иметь короткие имена. Я лично у стандартных нод часто удаляю лишние суффиксы вроде "Container", от которых нет никакого толку для меня, и аналогично поступаю с собственными нодами, если дал им длинное название класса.
>А значит слетят типы, а значит искать зависимость по скриптам
Если у тебя там везде указаны типы, то Godot сам тебе укажет на все места, где типы не совпадают. Если не указывает, значит, ты что-то не то делаешь, типа, передаёшь типизированный объект через нетипизированный аргумент функции или вроде того. GDScript по умолчанию нетипизированный и требует усилий для полноценной типизации по всему проекту...
Лично у меня единственной проблемой с переименованием классов GDScript было то, что Godot кэшировал какие-то данные о классах в... не помню, ClassDB, что ли?.. И в результате, если ты два класса переименовал по-быстрому, они могли как-то конфликтовать в РЕДАКТОРЕ, типа редактор сыпался ошибками "это не то, давай другое". Помогал сброс кэша.
>вообще не хочешь видить nodepath
Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его. Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"? А ещё я стараюсь хранить все объекты как можно более локально. Поэтому я редко взаимодействую с какими-то сложными NodePath.
>Ты делаешь мультиплеер так, будто у тебя есть доведённый до релиза синглплеер
По-моему, одной из великих истин геймдева является то, что если ты хочешь мультиплеер - придётся делать его с самого начала, а синглплеер пришивать к мультиплееру сбоку, через фейковый локальный сервер для одного игрока. Потому что сделать наоборот - мультиплеер на базе работающего синглплеера - всегда намного сложнее, если о мультиплеере изначально никто не задумывался и хотели только "довести до релиза синглплеер". Исключения бывают, но там, скорее всего, пришлось переписывать половину игры с нуля, чтобы накрутить мультиплеер на уже вышедшую игру. Да, делать мультиплеер своей самой первой игрой - не стоит, но если ты всё-таки хочешь мультиплеер, он должен быть с самого начала, когда игры толком ещё нет (одна из сложностей мультиплеерных игр).
>>1098956
А ты какие инструменты используешь? Что-то из встроенного в Godot? Документацию читал?
>>1098904
>потратила миллионы на разработку этого интерфейса
Да хоть миллиарды. Выглядит как-то неприятно и неудобно. Делай что-то лучше этого.
Ну я через rpc и synchronyzer делаю, думал netfox подключить а он ни в какую работать не хотел.
>удаляю лишние суффиксы вроде "Container
Эти суффиксы даются не от пафоса, а для того чтобы в сотнях классах понять с чем ты сейчас работаешь. Это менеджер, сервис, компонент, хелпер, хендлер, модель/сущность, репа (бд в сингл игре - как тебе такое Илон Маск?) итд.
Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали. То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны. У нас сразу появляется два мира - мир дерева SceneTree и мир скриптов (preload(uid) хоть как-то дает возможность не срать в скоуп имен, тихо намекая делать игру на сервисах). Вот только нахера нам нужно все кроме SceneTree?
И самое страшное, что если появиться скоуп имен, они скорее всего возьмут модули питона, а не неймспейсы шарпов.
>Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"?
Это другое, это не отменяет проблемы. Это скорее подход к взаимодействию между нодами, мы же на этапе организации кода вообще.
Да, сигналы дают контракт (интерфейс) взаимодействия. Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы? Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
На самом деле я утрирую, но сигналы приятны опять же для мелких демо игр. Вот тот же turn-base loop на сигналах выглядит мерзко, потому что момент переключения перемешивается с сигналами ожидания анимации - основная базовая логика замешивается с местечковой логикой действия юнита. И все равно нужны состояния, которые надо чекнуть в следующем кадре, тогда к чему вообще эти ивенты, если на состояниях будут проще и мы все равно узнаем все изменения в следующем кадре (ну или я тупой просто, не нашел элегантного решения)
>Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его.
Когда прототипируешь (не до конца еще понимаешь общую картину), постоянно меняешь название и иерархию. Но все равно это быстрее чем на шарпах или, упаси, расте
> Исключения бывают, но там, скорее всего, пришлось переписывать половину игры с нуля
А она есть, эта игра? Чтобы переписать её с нуля?
>>1098952
> готова процентов на 80
80 процентов продукта это 20 процентов усилий, а оставшиеся 20 процентов продукта это 80 процентов усилий. ©
@monkey чья цитата?
Это вариация принципа Парето, где 80/20 изначально про распределение богатства, а вот про последние 20% продукта как самые трудные — просто расхожая фраза из геймдева и софта без конкретного автора. Часто приписывают кому угодно, от анонимных разработчиков до менеджеров проектов.
В современных играх программирование обычно занимает 20-30% от общих трудозатрат команды, остальное уходит на арт, анимации, звуки и дизайн уровней. В инди-проектах на Godot код может весить больше, до 40-50%, потому что один-два человека тянут всё. В ААА процент кода падает ещё ниже, так как студия нанимает сотни художников и аниматоров под один движок.
Код может быть прямо зависеть от игры. Если это какой-то симулятор фактории в римворде, то тебе даже анимировать не захочется, от обилия веселой отладки.
Ты будешь разговаривать с другим инди разработчиком - у вас может быть два совершенно разных опыта. Один будет говорить как трахался с бленд анимацией, другой будет жаловаться как искал причину почему курицы перестают кушать на 4 игровой день.
> Если это какой-то симулятор фактории в римворде
Судя по первому сообщению это очередная онлайн дрочильня эрпогэ. Давай не будем выдумывать крайние случаи.
>Только мои игори - это игори, а твои игори - это не игори.
Тут надо заметить, что у стены изначально в редакторе нет коллижн шейпа, у меня там лежит хуйнюшка которая в своем _ready создает нужную форму и подкладывает ее стене (обычный Control, который генерит четыре коллижн шейпы, образующие пустой внутри прямоугольник в форме этого контроля. я это использую чтобы вручную не расставлять все стены, а выставить один квадрат и он автоматически построит "комнату")
Так вот я убрал эту хуйню и поставил коллижн шейпы сразу в редакторе (в точности те же самые, скопировал их из сгенеренных через Remote). Баг пропал.
Я в ахуе, потому что вообще непонятно, почему так. Ставишь форму заранее — все ок, ставишь форму через _ready — проваливается. Я б понял, если бы коллизия совсем проебалась, типа форма не смогла добавиться так поздно, физический движок уже чето запек. Но так ведь он ее вроде как видит, иногда коллизия срабатывает, а иногда нет. Да и до этого у меня characterBody2D бегали по этой хуйне без проблем через move&slide, проблемы начались только когда мне потребовалось трогать test_move и move_and_collide
Хз короче, я сам долбоеб конечно что такое сделал, но результат очень странный
Не думаю, что виноват _ready...
>>1099092
>только на пару пикселей
Попробуй спавнить его чуть выше стены. Обычно нерационально спавнить физические объекты в непосредственной близости от стен и полов - им необходимо некоторое пространство вокруг.
>Я б понял, если бы коллизия совсем проебалась
Создание коллизий, добавленных в редакторе, будет, очевидно, раньше твоего кода в _ready, и в некоторых ситуациях, физический движок успевает начать свою работу, прежде чем ты доделаешь свою сцену... Это нормально, просто "процедурная генерация" должна принимать во внимание такие нюансы и не спавнить физические объекты слишком близко друг к другу.
Правда, я обычно в 3D. В 2D физика нестабильнее. Физически "тяжёлым" 2D играм лучше поискать альтернативу, например, Box2D или Rapier2D...
Алсо, если тебе не нужна рантайм генерация:
>обычный Control, который генерит четыре коллижн шейпы, образующие пустой внутри прямоугольник в форме этого контроля. я это использую чтобы вручную не расставлять все стены, а выставить один квадрат и он автоматически построит "комнату"
Лучше сделай @tool скрипт, который после нажатия @export_tool_button создаёт (или обновляет) все необходимые тебе коллизии в редакторе. Подобные утилиты эффективнее рантайм генерации - нужные операции выполняются один раз, а не каждый раз.
Релевантное:
https://docs.godotengine.org/en/stable/tutorials/plugins/running_code_in_the_editor.html
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#export-tool-button
>чтобы в сотнях классах понять с чем ты сейчас
В дереве сцен иконки цветные, забыл? А на панелях инспектора класс ноды, а не её имя. Вообще, мы же параметр Node.name обсуждаем, при чём тут класс?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-name
>Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали.
Интерпретатор GDScript - это, вроде бы, один switch, навешивать новые фичи в язык тяжело, а ещё их же поддерживать потом нужно. Неймспейсы становятся необходимы, только когда у тебя буквально тысячи независимых классов-компонентов от независимых провайдеров (а.к.а. разработчиков аддонов), т.е. в большинстве Godot-проектов неймспейсы не нужны.
>То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны.
Эээм, ты вообще хоть что-то делал по туториалам?.. Собственное название скрипта/класс нод нужны для размещения множества нод одного класса в сценах.
>возможность не срать в скоуп имен
Просто не пиши строчку class_name в своих скриптах и пользуйся утиной типизацией, например:
>func _on_object_enter(object: Node):
>_ if "receive_damage" in object:
>_ _ object.receive_damage(damage)
Работает как часы, ноль проблем.
Также существуют "внутренние скрипты" сцен: если добавляешь скрипт нажатием кнопки на ноде, в меню выбирай "внутренний/встроенный" (не помню точно) - полученный скрипт будет безымянным и сохранится непосредственно в .tscn. Одна сцена может иметь неограниченное число таких скриптов. У них вообще невозможно задать class_name, но оно и не нужно. Чрезвычайно годная фича Godot/GDScript, ящитаю.
>Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы?
Это не проблема, пока ты следуешь чётким правилам, которые сам принял и стараешься не нарушать нигде.
>мы же на этапе организации кода вообще
>Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
Ты делишь шкуру неубитого медведя. Вот когда/если начнутся такие проблемы, тогда и будем их решать... Наверняка выгоришь и забросишь до этих проблем.
>не нашел элегантного решения
Ладно, уговорил, попробую сделать пошаговую...
>постоянно меняешь название и иерархию
Ну, так говорили же уже - юзай @export, он всегда отслеживает все изменения в дереве сцены. В 3.x существовал похожий механизм, вроде и сейчас он существует, поэтому у нас есть тип "NodePath", не использующийся толком нигде. Т.е. даже на 3.x не существовало такой уж большой проблемы, а в 4.x сплошное удовольствие работать же...
>Протестируй
Сколько платишь за бета-тест своего вайб-совета?
Нейронка права на счёт депенетрации move_and_slide, однако, остальные советы вырваны из контекста. Но, аноним выше сказал, что если вручную расставить - нормально выходит, т.е. вряд ли нужно делать свой механизм депенетрации. И ему в принципе не нужно размещать свои коллизии прямо в рантайме.
>>1099040
>очередная онлайн дрочильня эрпогэ
Почему РПГ, а не лутер-шутер, например?
>>1099035 >>1099038
Вы оба правы по-своему. ААА студии делают игры в преимущественно художественном плане, на заранее подготовленном движке, поэтому кода там немного. Индюки делают свою "факторио в римворлде", вот и получается, что кода больше, чем какого-либо арта. Естественно, конкретный "процент кода" невозможно определить, но то, что арт/дизайн в играх зачастую перевешивает любой код - это факт и база.
>Ладно, уговорил, попробую сделать пошаговую...
Давай, чекну. Там фулл пошаговость (из последних игра stoneshard)
ходит игрок -> ходит мир -> ходит игрок -> ходит мир
Только фатальный недостаток такой игры, если задержка хода больше 150-200мс, становится неприятно играть (импут лаг).
То есть
-минимум анимации (ждать анимации это вообще фатальный минус, но иначе расинхрон действий)
-не очень большое число юнитов в расчете (вне вьюпорта вообще бы анимацию отключать и перемещение делать просто global_position = target)
+ ближний бой не такой унылый как в остальных 2D топ даун играх, можно реально какую-то тактику и синергию скиллов сделать (билдостроение/"шахматы" же).
В общем, минимальная возможность для творчества. Возможно поэтому сам стоншард так медленно развивается. Не то чтобы игра мечты, но пока других идей нет.
>успевает начать свою работу, прежде чем ты доделаешь свою сцену
Как ни странно, артефакт происходил не только в самом начале при загрузке, а даже если поставить тело в отдалении и только потом оно через какое-то время коллайдит. Меня это и удивило
>>1099112
>Лучше сделай @tool
Уже сделал, да. самое здравое решение, стоило изначально так делать
>>1099113
>Протестируй
Лень. Объяснение звучит логично, меня просто раскорежило от того, что коллизия ломалась только чуть-чуть, а частично продолжала работать
>@export var something_default: int = 1
Потом присваиваете это к "приватной" переменной того же класса:
>var _something := something_default
Допустим, что в наше поле в инспекторе введено число "2".
Вопрос: что будет в _something в _ready? 0, 1 или 2?
Правильный ответ: в _something будет 1, а не 2.
Объяснение. Сначала - инициализация:
_something = something_default = 1
Только потом - десериализация:
something_default = 2
Итог: используйте @onready или присваивайте значение в _ready.
НЬЮФАГ С НОГИ ЗАЛЕТАЕТ В ТРЕД
@
ДАЖЕ ПОНГ НЕ МОЖЕТ СДЕЛАТЬ САМ
@
ХОЧЕТ ММО-ЛУТЕР-ШУТЕР-РПГ С НУЛЯ
@
ЗАЛИЛ ВЛАЖНЫЕ ФАНТАЗИИ В ЧАТЖПТ
@
ПУК МНЯМ ВРОДЕ ТАК НЕ ПОЛУЧИЦЦА
@
ЫЫЫЫЫ ЧАТЖПТ СКАЗАЛ НИЗЯЯЯ((((
@
ЧЁ ПРАВДА НИЗЗЯЯЯ((( А ПАЧИМУ(((
@
А НУ ПАДСКАЧИЛИ РАЗАБРАЛИ)))
@
И ЧТОБ ПАНЯТНА БЫЛА ОК)))
да я уже решил вопрос просто поинтересовался у заинтересованных
Я хз какие решения используются в годоте для сети, но в теории ты можешь сам написать любой сетевой протокол (и это довольно не сложно и интересно).
Синий из "Атаки титанов" прав - вы не хотите учиться и лезете все глубже туда, где уже непростительно отсутствие знаний и вы буквально галлюцинируете вместе с нейронкой, потому что она создана лобызать твои хотелки.
Как правильно это фиксить в реалиях годоти?
У тебя график неправильный же...
>Синий из "Атаки титанов"
Ты не узнал знаменитый icon.png?..
Во-первых, SubViewport обычно используют с галочкой "Own World3D"... То есть подразумевается, что SubViewport рендерит только те объекты, которые размещены в его потомках. Сейчас у тебя, судя по всему, один или оба вьюпорта рендерят то, что им не принадлежит. Хотя на обычные Label это влиять не должно...
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-property-own-world-3d
Во-вторых, у тебя там случайно не Label3D надписи? Если это они, тогда придётся либо крутить в них настройки, либо как-то переносить их на отдельный слой с высоким разрешением (т.е. отдельный SubViewport чисто для них). А вообще, лучше вместо Label3D юзать обычные Label, которые двигаются с помощью Camera3D.unproject_position(world_point) - тогда будет максимум возможностей с минимум глюков.
https://docs.godotengine.org/en/stable/classes/class_camera3d.html#class-camera3d-method-unproject-position
>Во-первых, SubViewport обычно используют с галочкой "Own World3D"
Увы, не мой случай - я использую два вьюпорта, ближайший к камере из них с флагом Transparent BG, они должны накладываться друг на друга, камеры у них синхронизированы по трансформу, если врубить собственный 3д ворлд - такой сетап перестает работать.
> Во-вторых, у тебя там случайно не Label3D надписи?
Да, он самый. Заметил, что надписи ещё и клипают сквозь геометрию.
Пока надумал, что буду пользоваться обычными лейблами и прикреплять их к специальному отдельному канвасу. За Camera3D.unproject_position(world_point) - спасибо.
>буду пользоваться обычными лейблами
Вот подробнее про это и сравнение разных вариантов:
https://docs.godotengine.org/en/stable/tutorials/3d/3d_text.html
>если врубить собственный 3д ворлд - такой сетап перестает работать
Ну, как вариант, можно сделать третий SubViewport, у которого разрешение близкое к оригинальному, own_world_3d = true и сложены внутрь все Label3D, которые контролируются через RemoteTransform3D.
>клипают сквозь геометрию
Можно выключить depth test, если у тебя камера строго сверху и перекрывать надписи нечем.
У Label3D есть баг, из-за которого они блюрятся на фоне неба, если в настройках камере включить DoF...
>Ты не узнал знаменитый icon.png?..
Узнал, но по криповости (зловещей долины) он напоминает больше атаку титанов.
>У тебя график неправильный же...
Не, там все правильно. Если вайбкодя не будет учиться и постигать то что дает нейронка, он отстанет от рациональной части кода и попадет в тупик (остановиться развитие игры, этакий бесконечный лимб с нейродебилом).
Набросал пока хождение по клеточкам с лимитом на радиус хода (если интересно, алгоритм пути - flood fill через рекурсию со счётчиком шагов, это очень легко реализовать), определением препятствий и перепада высот (герой не может зайти на клетку выше, чем его способность к прыжку, но может спрыгнуть ниже). Завтра планирую продолжить. Нужно реализовать врагов и режим атаки, а также GUI для отображения, хотя бы, очереди команд.
Схема хода планируется такая: "позиционирование героев" -> "заполнение очереди атак" -> "подтверждение хода" -> "выполнение очереди атак и контр-атак" -> "перемещение и атаки противников" -> ... Сразу скажу: не я это всё придумал, есть много очень старых игр с такой схемой, просто это база, без которой остальное не заработает, и выдумывать что-то новое в этом жанре мне пока что не хочется (но я уже думаю, как это всё облегчить).
Из более отдалённых планов: сделать генерацию местами гладкого, местами обрывистого ландшафта вместо тех квадратиков на GridMap, что есть сейчас; нарисовать какие-нибудь спрайты героев - хочу попробовать 2.5D стиль, поэтому и использовал icon.png в Sprite3D; накидать классы героев с характеристиками и способностями; сделать центральный штаб и механизм поиска-генерации таких вот мелких карт, а также, естественно, условия проигрыша и победы, выход из локации в штаб, получение новых героев и т.д. - что я уже давно хотел сделать, но не решался.
В прошлом мне хотелось реализовать эту задумку как "геройский шутер" с полноценными 3D моделями, но сейчас пошаговая тактика с 2.5D графикой привлекает больше, как минимум потому, что это мне точно по силам. Если не забью, конечно... Рисовать можно будет по ходу дела подучиться, это не такая уж большая проблема...
Фух, за последние пару дней столько всего в голову полезло из-за одной только мысли сделать такую игру...
>Там фулл пошаговость
>ходит игрок -> ходит мир
Меня больше тянет к жанру "Tactical RPG", наподобие Disgaea, где игрок управляет командой довольно уникальных героев-специалистов по отдельности за один ход, а не одним героем-универсалом. Я не знаю, чего ты так к этому Stoneshard прицепился - по трейлеру там "Open World Survival Craft", а не полноценные "шахматы"...
>>1099124
>если задержка хода больше 150-200мс, становится неприятно играть (импут лаг)
Ты про управление через WASD, когда одно нажатие == ход на одну клетку вбок?
>минимум анимации (ждать анимации это вообще фатальный минус
А я вот во многие игры не поиграл бы, если бы не их прикольные анимации...
>не очень большое число юнитов в расчете
Чем меньше специалистов, тем меньше "тактики" и больше "вдарь посильнее".
>В общем, минимальная возможность для творчества.
По-моему, всё в точности наоборот - возможностей для творчества больше.
Во-первых, пошаговая игра не требует от игрока быстрой реакции на события, а потому и сама не обязана быстро откликаться, что открывает возможность к созданию анимаций как в настоящих мультиках, например, герой может реально присесть перед прыжком, а не взлетать с места словно ракета - к чему вынуждены прибегать все экшен-игры, чтобы ускорить отклик на ввод; больше прикольных анимаций - больше кайфа от наблюдения за игрой, в которой всегда что-то двигается и происходит, а не как в обычных экшенах, где героям тупо некогда двигаться.
Во-вторых, габариты героев, предметов и способностей не играют никакой роли, т.к. всё происходит на шахматной доске, где всё помещается в одну клетку, двигается и атакует строго по клеткам, что позволяет совместить всякий абсурд в спрайтах, катсценах и анимациях со строгими и понятными правилами, избегая мороки с коллизиями.
В-третьих, пока ты не позволяешь игроку собрать имбу-универсала, ты можешь добавлять в игру большое число специалистов и их специальных способностей, которые игрок может комбинировать, и такие комбинации можно быстро наращивать, потому что все взаимодействия стандартизированы по клеточкам и ходам.
В-четвёртых, тут можно сделать более любопытные вещи с ИИ противников, поскольку им не нужно "кричать и бежать на игрока" как в стандартном экшене - они могут быть умнее или необычнее и не вызывать у игрока недовольства, а у героев игрока может быть куда больше интересных взаимодействий с врагами.
В-пятых, процедурная генерация на клеточном поле в разы проще, и при этом выглядит весьма естественно - ведь ходишь ты по клеточкам, а потому и карта должна быть клеточной - отображать клетки на полу, а вот делать шутер на клеточной и тем более ступенчатой карте было бы странно и некрасиво, при этом тебя никто не ограничивает налепить что-то неклеточное в качестве декоративных препятствий, главное - заполнить клеточки правильно, чтобы правила перехода по клеточкам соблюдались независимо от визуала, что куда проще реализовать, чем коллизии.
В общем, на мой взгляд, это топовый жанр, с нераскрытым потанцевалом, хидден гем, так сказать.
>Не то чтобы игра мечты, но пока других идей нет.
Если не находишь в этом всём фана - лучше не берись за это.
О я тоже пошаговую партийную игру делаю. С оглядкой на rogue trader и divinity. Но масштабы более-менее человеческие и дичь с объектами на клетках творить не могу. У меня визуал локации живёт отдельно, только совпадая с состояниями гексов.
Мы про два разных жанра говорим. Там разная "пошаговость". Пока ты не глянешь игру (она там весит копейки и работает на всем) или стрим, мы не поймем друг друга.
>Я не знаю, чего ты так к этому Stoneshard прицепился
Я в JRPG не играл, но для меня (ИМХО) где есть разделение мира на стратегический геймплей и тактический бой - игры надоедают буквально за пару часов. Может у меня детская травма от героев, но каждый бой это одно и тоже. В тоже время когда действия происходят только на стратегической карте (типа цивы) - тебе не так все угнетает (но это 4х стратегия). Стоншард же показал, что можно сделать хорошую приключенческую (опенворд) игру и передать дух РПГ (а не рогалика, хотя есть эти элементы). Есть тоже множество претензий к игре, но этот вариант даже меня не угнетает так быстро как тактические turn-base.
Почему пошаговость и шахматы - там синергия скиллов и билдострой, от чего решение бросить сетку на одного, и не бить противника со сломанной рукой - может стоит тебе исхода боя. Бои как повторяются так и нет, но они не угнетают точно.
Окей, мне нравится рпг - почему не сделать реалтайм? Ну опять же момент пошаговости - ты не ничего не делаешь - мир ничего не делает (остановился - подумал - покакал), не надо делать игру на тупых стрейфах (игрушка даунов). В такой стиле ближний бой не выглядит убогим (свойство всех 2D top down игр). В общем, как-будто есть потенцевал.
>Если не находишь в этом всём фана - лучше не берись за это.
Так это проект онли в стол. Я не вижу себя через 1.5 года в стиме (не уверен увижу ли вообще стим). Но мне нравится создавать что-то ради "создования" (да и я не могу фулл-тайм работать).
Я эти два спрайта месяц назад нарисовал под впечатлением от игры и не решался начать (мусолил другую фантазию). Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать для себя, публиковать идеи (потому что украсть тут нечего). При этом есть 100500 проверенных фич, которыми можно втихую "вдохновиться". Идеально.
Выглядит годно. Но мне кажется тут лучше бы зашли гексы из Endless Legend с ступенчатыми переходами.
Полный туман войны (черная жопа на всю мапу) - самое идиотское наследие РТС. Нужно очень много раз подумать нужен он в текущей игре или нет (иногда правда нужен).
Если твоя карта клеточная - туман несложно сделать.
Если ты не вайбкодя, то опиши свою проблему здесь.
>>1099510
Чернота хороша для сеттинга типа Age of Empires. Представь: ты - племя вчерашних пещерных людей, и совершенно ничего не знаешь о мире вокруг пещеры. Постапокалипсис типа Fallout тоже хорошо впишется. Фэнтези пещеры/данжи и подобные штуки - тоже. Но технологически развитой цивилизации, которая тупо захватывает знакомые клочки земли, это не идёт.
Карта клеточная, но меши в локации живут отдельно от клеток. Условно говоря вместо того чтобы распиливать стену на клетки я делаю целиковый меш и обозначаю клетки как непроходимые.
нет для своей игры делаю так как рисовать нихуя не умею, а надо иметь 100 нпс разной внешности
идея такую же куклу как в римворлде взять и просто имперсивности добавить, если в голову прилетело катаной спрайты шрамов накидывать или глаз выкололи то закрыть его еще бы волосы научиться рисовать
Можно показать всю карту, со всеми артефактами, но что происходит там скрыть (этакий серый туман войны). Тогда у игрока сразу образуется план куда и зачем идти. Например тебе нужен ресурс сталь - ты идешь к этой стали. Или видишь что там стали очень много - сразу же воспринимаешь область как стратегически важную. Но что тебя там ждет это уже отдельная тема. Для сетевой игры можно так создавать точки столкновения (да и для AI в сингле так же можно делать). Опять же, раннее пройденная местность скрыта и неожиданно тебя может ждать засада на пути снабжения (если не позаботился о разведке).
А черная задница это черная задница, особенно эти нераскрытые клочки. Но опять же зависит от игры.
Длина меча на два тайла - мое почтение.
Если это рим-лайк - смотри что у тебя будет в игре, у тебя слишком мелкие детали, которые пропадут в размерах игры. Но вообще пару раз разместишь в игре поймешь что надо делать.
Тогда так: процедурно генерируй меш-стенку, по типу экструзии одной линии - границы видимости - от пола до неба, и накидывай на неё какой-нибудь шейдер.
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
>>1099519
Нормально. Лучше сделать кривой плейсхолдер и переделать потом, чем сидеть-потеть над идеальной графикой, а потом обнаружить, что игра не работает.
>>1099526
>нужен ресурс сталь - ты идешь к этой стали
Жопой чувствуешь, что где-то глубоко под землёй в непроходимом лесу есть залежи стали, и все твои противники, даже обезьяны и крокодилы, тоже уже прочувствовали эти залежи и несутся их добывать? Офигенная стратегия, 10 стратегов-эсперов из 10...
Куклы в римки это отдельное умение продать игру с плейсхолдерами. Хочешь визуализировать оторванные ручки ножки, нужны ручки и ножки и тайлы больше 128х128 и вообще добро пожаловать в вектор.
Но хз как там с цензурой стима будет.
>и несутся их добывать?
Неожиданно стратегии это про получение и удержание стратегических ресурсов, а не про приключение или тупой покрас. Чтобы отбить сталь у крокодилов, нужно уже планирование - за что и играют в эти игры - приключение с неизвестной местностью оставь героям меча и говна.
Скорее всего разведотряд частично погибнет об крокодилов. Но тогда ты уже знаешь что эта сталь не так проста и будешь планировать экспедиционный отряд для неё (взвесив за и против, потому что крокодилы требуют солидного отряда и ресурсов).
Так же нужно сразу планировать оборону, потому что об этой стали знаю все! А не только в конце игры и случайно.
А опытный игрок разместит разведку в лесу, чтобы освещать происходящее в округе и дождётся когда ИИшка частично разобьет отряд крокодилов, сделав тебе половину работы.
Ппц, мы можем в стратегии - использовать стратегию, абалдеть!
> Тогда так: процедурно генерируй меш-стенку
Не мой варик по нескольким причинам сразу, но мы с нейронкой поштурмили эту проблему и вроде как нашли решение, но придётся клетки запекать по колайдерам мешей и туман скорее по клеткам будет работать + хаки чтобы показывать стены не на гексах
>Мы про два разных жанра говорим...
Пикрил: >>1099240
С чего мы вообще начали? "Как сделать ходы для пошаговой игры на нодах и сигналах Godot", нет? Так что поджанр конкретной игры не так уж и важен, пока игра относится к "пошаговым". По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических рогаликов.
>Я в JRPG не играл
>Пока ты не глянешь игру
>она там весит копейки и работает на всем
Раз так, тогда сыграй в Disgaea DS (35 Мб):
https://archive.org/download/pack-roms-nintendo-ds-eu-usa-jap-rabbits-games/Disgaea%20DS%20%28USA%29.zip
Эмулятор, например, Lemuroid (12 Мб):
https://github.com/Swordfish90/Lemuroid/releases/download/1.15.0/lemuroid-app-free-dynamic-release.apk
>каждый бой это одно и тоже
Не любишь однообразные комбо?..
Если не делать имбу-универсала, которая может делать что угодно, бои интересны, особенно на процедурных картах, где передвижение ограничено: все тиммейты имеют свои достоинства и недостатки, и приходится думать, кого куда поставить, кем пожертвовать, кого срочно эвакуировать в тыл и т.д. Интересный геймплей, хотя уникального контента в этой версии игры мало. Правда, на сюжетку я забил и копался только в процедурно-случайных локациях "внутри" шмоток (необычная механика прокачки шмоток - найди и побей NPC, чтобы разблокировать бонус). Собственно, меня вдохновили на этот проект именно эти случайные локации.
>Стоншард же показал, что можно сделать...
Лучше в Elin сыграй - контента и механик точно больше. Лучше всего начинать играть вслепую и разбираться самостоятельно, иначе испортишь удовольствие.
>передать дух РПГ, а не рогалика
Мне кажется, ты что-то путаешь. Жанр rogue-like - это в первую очередь RPG, во вторую очередь dungeon crawler, а уже потом - процедурная генерация и т.п.
>>1099397
>Я эти два спрайта месяц назад нарисовал
Помню, видел твои посты где-то.
>Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать
На мой взгляд, главный недостаток "опенворлда" в том, что ты вынужден заполнить большую карту бесполезным для игрока филлером, который игрок хочет поскорее скипнуть с помощью фаст-тревела или телепортации, и добавлять на эту огромную карту новые точки интереса сложно. Почему бы не вырезать весь филлер, оставив только точки интереса, которые игрок может выбрать из меню и перейти сразу к главному блюду игры? Да, это не будет "опенворлдом", потому что игра делится на "комнаты", но так ведь только лучше для игрока. Игре необходим опенворлд тогда и только тогда, когда перемещение по полям, горам и морям - самое главное. А когда эти поля, горы и моря вызывают лишь раздражение и скуку, то зачем они?
>>1099401
>гексы из Endless Legend с ступенчатыми переходами
Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы, в левел-дизайн, в понимание игроком игровых правил и т.д.
Для карт я планирую что-то ближе к комнатам, коридорам и мостам, которые удобнее собирать из квадратных тайлов и заготовленных сцен-шаблонов.
>>1099370
>Но масштабы более-менее человеческие
Что ты имеешь в виду под "масштабами"?
> По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических
Как раз таки нет, потому что в фулл пошаговой надо ждать все анимации, а это еще спагетти из сигналов (на которые ты должен был нарваться сам в процессе, но увы ты сделал вообще другое).
Да и речь не была меряться письками вида сложно не сложно, любая turn-base основа делается за час. Я хотел чтобы ты прочувствовал как херова размазывать логику по сигналам (особенно эти мелкие анимации).
>Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы
Непонятно что они добавляют, есть же "тот" сайт который все с гексами разбирает (даже много лишнего). Ты по сути как с тайлами работаешь, только с гексами - (один раз обертку написал и больше с точными координатами вообще не работаешь, только с нумерацией TileMapLayer и быть может соседями)
>"тот" сайт
Соседи для odd-r, он же (HEXAGON STACKED в годоте)
https://www.redblobgames.com/grids/hexagons/#coordinates-offset
Там в соседнем треде вайбкодя носиться с изометрией,
>>1099523 →
Но такое ощущение (судя по видео) что нейронка про соседей в изометрии ему ничего не говорит. А они там тоже не так просто вычисляются (так же зависят от четности "y", если это ISOMETRIC STACKED).
>Непонятно что они добавляют
Вот и я о том же - зачем гексы?..
>>1099570
>но увы ты сделал вообще другое
Что не так-то, у меня же пошаговая игра?
>как херова размазывать логику по сигналам
Не размазывай. Вызывай вниз - сигналь наверх.
Принес геймплейную идею в тред. Вдруг кому-то пригодится. Значит смотрите. Идея подойдёт к играм в жанрах песочниц и рпг. Если у вас есть различная пища в мире игры, то в какой-то момент развития персонажа она превращается в мусор, забивающий инвентарь, потому что игрок либо лечится шприцами в нф-сеттингах, либо зельями/магией в фентези и ему нет смысла есть все эти ягоды, корешки, грибочки, хлеб, мясо, сыр.
Вопрос. Как решить эту проблему?
Многие разрабы вводят систему потребностей, превращая персонажа в тамагочи. Фи.
И тут меня осенило. Вся лутаемая пища автоматически складируется когда игрок возвращается на базу и игроку доступна мини-игра с обедами в столовке. Чем разнообразнее еда на складе, тем богаче меню в столовой. Тем больше здоровья восстанавливается.
Этому проекту почти джва года уже - начал диздок заполнять 2024.10.23, а спустя пару недель, осознал колоссальный объём работ и забросил; год назад я пробовал сделать врата >>1039341 → и забросил.
Таких проектов у меня много, думаю, уже десятки... Замечаю даже, что многие мои задумки новых игр вращаются вокруг одних и тех же нескольких тем... Раздражает, но, может, это вполне естественно?..
>>1099671
Зачем делать бесполезную еду? Если хочешь еду, то изначально наделяй её "магическими" баффами. Вот, например, бутерброд с рыбой даёт буст к рыбалке на некоторое время: есть смысл взять хлеб на рыбалку, развести костёр и бустить скилл рыбалки на месте. Занимаешь игрока осмысленной работой внутри ОСНОВНОГО игрового процесса, чтобы игрок мог почувствовать, что его решения важны => фан. Т.е. необходимо создать ощущение "это Я решил взять и приготовить бутерброд, и это было полезно", а не "принудительная мини-игра опять отнимает время".
Дополню геймплейную идею. База должна быть доступна "из кармана" как потайное пространство, грубо говоря база-мешок, которую ты можешь в любой момент достать и нырнуть в нее, а потом вынырнуть, оказавшись в точности в той же локации, где занырнул.
Потому что все базастрои быстро доебывают необходимостью пиздохать туда-сюда.
Когда в скурим играл с таким модом. Буквально база-мешок была, и ты жил в мешке, заворачиваясь внутрь в него.
Похожая механика есть в Elin: ты можешь купить себе палатку, что работает как дополнительная локация с передвижным входом, и может снижать вес лута до смешных 10% от исходного. Внутри можно растить грибочки, крафтить, спать и даже рыбачить, всё пока монстры снаружи вежливо ждут твоего выхода... Но настоящие базы всё равно фиксированные (можно телепортировать, но только за большие деньги).
Но такое далеко не всем играм подходит... Алсо, твой вариант уж слишком упрощает геймплей. Зачем тебе стараться и потеть, если ты можешь жить на базе безвылазно? Сидеть там и растить картошку, скот разводить. Удаляем 99% игры, оставляем лишь базу.
Мне интереснее, когда мобильная база физически присутствует рядом с игроком и ты её защищаешь... Повозка хотя бы какая-то, а лучше дом на колёсах. Космический корабль или что-то в этом духе. Но это, естественно, также не подходит большинству игр.
>>1099680
Убираем остопизденевший открытый мир, и делаем локацию-базу и порталы из неё в локации-арены для кача и лута.
Столько проблем решаем сразу.
>делаем локацию-базу и порталы из неё в локации-арены для кача и лута
Согласен. Джва года жду такую игру.
Жанр обычно называют rogue-lite.
Алсо extraction shooter подходит.
>Этому проекту почти джва года уже
Аа, ну меня тогда ещё не было.
>осознал колоссальный объём работ и забросил
Почему бы не попробовать урезать объем? Допустим сократить партийную рпг или что там у вас изначально в ветке до просто файтов на аренах в демке скачи и мочи вроде так было, просто кастомные битвы на аренах? Намоделить юнитов, раздать способности и мб залить куда нибудь. На условный вопрос, в чем поинт для игрока играть? Просто файтится, потому что этот игрок будет любить тактикульные битвы мне лично например нравится боевка в классических фолычах и х-ком, и участвовал там в каждой битве. Или ты о каком объеме говориш?
>>Непонятно что они добавляют
>Вот и я о том же - зачем гексы?..
Непонятно какой сложности добавляют, пару расчетов обернуть и потом как с тайлами (с номерами) работаешь. В 3Д вроде даже сетка готовая есть (но и её не долго сделать).
>Что не так-то, у меня же пошаговая игра?
Три раза уже объяснил, ты троллишь? Это две разные игры.
Хотели обсудить проблему дизайна сигналов в фулл-пошаговом мире, вместо этого достал какую-то свою старую игру, не показал кода, обмазал блюром.
Мы точно хотели спагетти-код на сигналах посмотреть (вместо loop'a), или ты просто зашел показать свою старую демку?
Твои же слова
>Ладно, уговорил, попробую сделать пошаговую...
Есть ли в пропоузалах у мейнтейнеров что-нибудь типа il2cpp (итоговый байткод гдскрипта вместо оригинальных файлов), чтобы хотя бы получался разъебанный полурабочий проект, а не буквально оригинал?
Просто еду не надо делать бесполезной. Тем более у еды есть узнаваемая разнообразная форма (суп от яичницы ты отличишь точно) чем такое же разнообразие у склянок. Еда должна иметь долгий единичный бафф, ты буквально выбираешь съесть на бафф урона, или реген хп (кап делать не надо, просто одна еда сменяет другую).
И вуаля, еда становится частью основного геймплея (частично так сделано в реквием сборках скайрима, там еда важная часть дроча статов)
А как иначе? Половина релизов в стиме получает меньше 10 отзывов. Из ИТТ до стима доползают единицы, но все еще неудержимо трясутся за воровство. Как хиккан, впервые за годы оказавшийся на улице, считающий что все на него смотрят и смеются.
Нужно не заплевывать монитор, а объяснить анону, что вопрос обфускации можно отложить в самый конец проекта. Кому-то это нужно, кому-то нет, но табуировать тему - зачем?
>Непонятно какой сложности добавляют
Вот попробуешь поработать с гексами - поймёшь...
Ты не ответил - зачем делать гексы? В чём причина?
>две разные игры
Я не спорю, что игры разные, но обе - пошаговые.
>фулл-пошаговом мире
Чем "фулл-пошаговость" отличается от "turn-based"?
https://en.wikipedia.org/wiki/Timekeeping_in_games
>In turn-based games, game flow is partitioned into defined parts, called turns, moves, or plays. Each player is allowed a period of analysis (sometimes bounded, sometimes unbounded) before committing to a game action.
У тебя два "игрока": человек и игровой мир. Каждый анализирует ситуацию на поле некоторое время и совершает игровые действия, отмеряемые шагами. Некоторые игры могут себе позволить двигать NPC непосредственно в момент движения игрока, но на "пошаговость" эта одномоментность не влияет. Мне хотелось бы видеть ход врагов с анимациями, чтоб прослеживалось то, как они реагируют на игрока.
>вместо этого достал какую-то свою старую игру
>ты просто зашел показать свою старую демку
Ты не так понял. Задумки появились давно, но код и остальные ассеты я сделал после недавнего поста... "Проект" появляется на этапе идеи "а было бы круто", поэтому папки проекта с кодом раньше не было. Ну, разумеется, не считая той катсценки с порталом...
>не показал кода
>хотели спагетти-код на сигналах посмотреть
Там пока что очень сырой набросок, который нужно отрефакторить и причесать, прежде чем показывать. Фактически я свалил все приходящие в голову идеи в считанные 5-6 скриптов, когда по-хорошему нужно разделить обязанности на бОльшее число классов. Особенно меня позабавило то, как Player перерос из обыкновенной камеры в God Object, знающий всё и являющийся по сути почти всем. Надо разделять.
>>1099688
>урезать объем
>Намоделить юнитов
В том-то и дело, что "юниты" - это самое сложное и трудозатратное в изначальной задумке, т.к. я хотел реализовать "как Overwatch, только offline", чтоб 3D персонажи бегали с тобой в одной команде и могли выполнять боевые задачи, но - и это главное - суть задуманного была не в геймплее как таковом, т.к. фундаментально это гача-игра, а в том, чтобы были прикольные персонажи с анимациями и т.п. А я и 1 персонажа не могу довести до презентабельного состояния... куда уж там десятки, даже сотни самых разнообразных персонажей... И реалтайм геймплей, конечно, накладывает ограничения на то, что можно реализовать в виде 3D мешей и анимаций, т.к. там критически важен отклик игры и реакции NPC...
Так что я уже "урезал объём" посредством отказа от реалтайма и заменой 3D на 2D спрайты в 3D мире. Я подумывал и о том, чтобы сделать чисто 2D игру, но подобное как-то совсем не привлекает. А тут что-то подумалось: а что, если попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать, но все герои нарочито двухмерные и анимированные с помощью деформаций, а не (только) покадрово? Это ж весьма неплохо выглядит в некоторых играх, имхо. Так я, теоретически, могу наштамповать десятки любых прикольных персонажей и даже сделать простое API, позволяющее любому добавить в игру персонажа из нескольких картинок и файла конфигурации.
В рисовании, я, увы, не силён, но мои рисунки мне нравятся... Вот и подумалось, что если я возьму простенький стиль, то нарисовать 2-3-4 спрайта на персонажа всё равно будет проще, чем сидеть над проработкой 3D моделей на уровне овервотча.
Алсо, по задумке, "количество >>> качество", то есть геймплейный цикл предполагает, что ты находишь множество неинтересных тебе персонажей, которых подбросил тебе рандом, порой даже теряешь тех, что понравились тебе (пермасмерть), и находишься в бесконечном поиске чего-то нового. Так что, кроме аватарок, нужны ещё будут рандомные параметры: "аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль". Контраст между этим и "ого, как удачно совпало", по задумке, должен быть наиболее впечатляющим.
Где-то в старых тредах уже описывал эту игру...
У меня были схемы геймплея, но их нужно обновить.
>Вот попробуешь поработать с гексами - поймёшь...
Полгода назад тестил говнину. Больше боялся этих гексов чем реальных проблем.
>Ты не ответил - зачем делать гексы? В чём причина?
Помимо того что ты и сам знаешь - хорошо подходит к плавным высотам для 3D.
>Чем "фулл-пошаговость" отличается
Тем что нужно ждать конца анимации всех кто ходит в локации (даже игрока). Я уже говорил ни раз.
>Пик1
У этого чела есть подробный туториал, правда на юнити, но думаю тебе достаточно скила чтобы адаптировать в годот
https://catlikecoding.com/
>Пик2,3
Увы по годоту таких масштабных туториалов нет, но чтобы не травмировать движкосрачника, кину тутор по true-top-down-2d, выглядит прикольно.
https://catlikecoding.com/godot/true-top-down-2d/
> хорошо подходит к плавным высотам для 3D.
То есть, ко всяким шумам, типа Перлина
>попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать
>Это ж весьма неплохо выглядит в некоторых играх
сразу рагнарек вспоминается
>аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль
а сами спрайты персонажа не будут генерироваться? Мне кажется это самое тяжелое было бы, даже 4 кадра 2 направления, атака и дамаг, но при этом без генерации, как-то неполноценно чтоли будет. По крайне мере я привязываюсь больше именно к фигуркам, а не аватаркам
А так задумка интересная, но тут да, нужно сесть и рисовать.
Все просто ебанулись на симуляторах ларьков, остановитесь
Ещё я охуел от того, сколько РТС сейчас выходит, обновляется или в разработке, но это богоудоное дело, продолжайте
>сколько РТС сейчас выходит
Незаслуженно забытый жанр, до сих пор не пойму почему произошел упадок интереса (пришлось десятилетиями долбиться в монопольные подделки пароходов)
РТС был убит онлайном, где казуалы оказались раскаты в лепеху окрщиками с надроченым микроконтролем. А в соло уже неинтересно.
Возможно это тоже повлияло, но как-будто было что-то еще.
Знаешь, дети девяностых и нулевых имели более яркое абстрактное мышление (яркую фантазию) и в условиях слабых компов приходилось додумывать погружение. Это для тех лет ты генерал управляющий своей армией, своей маленькой колонией, имерией, а для нового поколение с более ярким контентом и даже видео контентом - игра превращается в однообразный кликер.
Как я пришел к такой мысле.
Я расспрашивал в дискорде про HOI4 у подрастающего поколения (где тимой мы играли в другую игру), для кого-то есть то погружение управления странной в историческую эпоху, ощущение командование армий и дивизиями, а кому-то игра видеться просто как однообразный кликер (чем технически она и есть).
Думаю из-за этого РТС и сгинула. В эпоху изобилия контента, нужно более значительное усилие чтобы передать абстрактное погружение, иначе игра будет просто кликером
Никому не показывайте свои игры до релиза.
Слот оплачен, Габен не озадачен.
На пик 2 как будто проёбаны пропорции. При таком калибре под башней ещё механизм заряжания на несколько метров вниз уходит. Ну и ноги врятли такое выдержат. Короче я бы такое не купил.
>глянешь игру
>Стоншард же показал, что
>этот вариант даже меня не угнетает
Я попробовал сыграть... Одним словом - Д У Х О Т А, как это сегодня модно говорить: душный интерфейс, душные описания душных механик, душная графика, душная музыка, душный мир про душных людей и душных зомби. Игра с порога наваливает на игрока 100500 ненужных механик, вынуждающих игрока сидеть и разбираться в сотне разных ненужных параметров, и применять кучу предметов для того, что в любой игре здорового человека в принципе отсутствует (вроде переломов костей и "болевых ощущений" персонажа). При этом вся боёвка сводится к тому, что слабого врага ты закликиваешь насмерть, а от сильного убегаешь (а-ля Stardew Valley, только тут тебе могут ногу сломать и ты уже не убежишь никуда, лол). Ради чего в это уныние играть? Ради усиления депрессии в реальной жизни? У меня и в реальности достаточно боли и страданий от бессилия... Такого рода игры специально создаются, чтоб нельзя было почувствовать подвох и рефанднуть за 2 часа, а потом игрок испытывает чувство потраченного впустую времени и начинает оправдывать игру, мол, "наверное, это я ничего не понял, а игра-то хорошая - не зря время на неё потратил". Но я уже опытный, меня такими грязными трюками не проведёшь, я слишком много игр перепробовал.
>>1099753
>плавным высотам для 3D
А нужны ли эти "плавные высоты", если они будут настолько неприятно выглядеть? Повторюсь, я успешно реализовал генерацию из шестигранных призм около пяти лет назад, и мне не понравилось. Шестигранные призмы добавляют массу головной боли как с точки зрения математики (в туториалах не рассказывают), так и с точки зрения графики - делать красиво на основе шестигранных призм практически невозможно. "Плавные высоты" можно сделать и на обычной карте высот, как это делается в большинстве нормальных игр, а если нужны именно кубики - то существует техника "марширующих кубов", сглаживающая углы намного лучше, чем призмы. Вопрос только в том, нужны ли конкретной игре такие бесформенные обмылки?
>>1099763
>а сами спрайты персонажа не будут генерироваться?
>при этом без генерации, как-то неполноценно чтоли будет
"Аватар" - это и есть спрайты, которые бегают по карте... По лору, который я придумывал два года назад, сеттинг игры - постапокалипсис в масштабах мультивселенной. Из-за вышедших из-под контроля экспериментов множество ранее параллельных вселенных столкнулись, а их пространство-время перепуталось и стало в основном нестабильным. Но иногда в мире всё ещё встречаются временные или постоянные участки стабильного пространства. Игрок находится на космической станции, выжив только за счёт того, что станция была в постоянно стабильном пространстве. У станции есть портал, который можно настроить на другие участки, где иногда возникают другие порталы. Геймплей представляет собой отправку героев на исследование временно стабильного участка с добычей лута и спасением новых персонажей (нужно успеть вернуть всех своих персонажей и/или их трупы в портал, пока зона не разрушилась; оживить можно лишь тех, кто успел добраться до станции хотя бы в мёртвом виде). При этом, так как один и тот же персонаж существовал во множестве параллельных вселенных, в новой, слитой в неразбериху реальности можно встретить этого персонажа много раз подряд - и они все будут независимыми личностями со своими особенностями, но внешне они как близнецы. То есть, их спрайты похожи друг на друга, потому что по лору они одни и те же существа, но из разных вселенных. Ну, конечно, можно накинуть какие-то элементы вроде волос и одежды в виде масок, позволяющих менять оттенок из кода (CanvasItem.modulate или self_modulate), типа как в Skull Girls...
>Одним словом - Д У Х О Т А,
Ну ты задушнил. Я про механику фулл-пошагового мира.
А так да, там многое в игре сделано чтобы искусственно затянуть геймплей, игра просто завуалированная доилка. Но в тоже время может передать погружение.
>видео
Почему редотики ничего не делают? они и в жизни ничего не делают, но я про демку твою
>пусть тут у него на экране будет показываться как и у меня
Что-то такое имеется в движке, но я не разбирался в деталях, почитай сам:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для постоянной синхронизации состояния нод, как я понял, есть вот эти ноды:
https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html
https://docs.godotengine.org/en/stable/classes/class_multiplayerspawner.html
>слей зе спайр 2 с коопом, то легко ли переделывать
Если каждый игрок ждёт своего "хода" - должно быть относительно легко...
Самые большие трудности с мультиплеером у экшен-игр - игр "на реакцию".
>>1100090
Во-первых, нужно скукожить вьюпорт, не затрагивая рендеринг GUI:
https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html
Открываешь "Project Settings > Rendering > Scaling 3D", там выбираешь:
>Mode = Nearest # чтоб "пиксели" не размазывало по экрану
>Scale = по вкусу: 0.5 (2x2), 0.3333 (3x3), 0.25 (4x4), 0.2 (5x5)...
Во-вторых, для кубиков и декораций на 3D сетке можно юзать GridMap:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
В-третьих, для "2.5D спрайтов" можно использовать ноду Sprite3D:
https://docs.godotengine.org/en/stable/classes/class_sprite3d.html
Настройки для начала можешь выбрать такие:
>billboard = billboard_fixed_y (чтоб смотрели в камеру)
>texture_filter = nearest (чтоб крупные пиксели были)
Также очень рекомендую заранее ознакомиться с SubViewport:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/shaders/using_viewport_as_texture.html
Например, можно рендерить стопку из картинок в единственный Sprite3D:
>Sprite3D # что видим на экране, использует ViewportTexture
>_ SubViewport
>_ _ Sprite2D # голова
>_ _ Sprite2D # тело
>_ _ Sprite2D # оружие и т.п.
>_ _ AnimationPlayer и т.д.
Освещение и лампочки, скорее всего, самые обычные для 3D.
Текстуры в той игре сгенерированы нейронкой и/или сжаты.
Звучит сложно, но всё это делается в Godot за минуты...
>>1100044
>Но в тоже время может передать погружение.
У тебя джва места для сидения:
1. В кресле приятно сидеть - утопаешь в его мягкости, аж в сон клонит.
2. На колышке неудобно сидеть - жопа болит, елозишь, ругаешься.
На каком "погрузишься", а на каком - "можешь погрузиться"?
Вопрос с подвохом. Думай.
>Почему редотики ничего не делают?
Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
>Зачем?
Какая разница? Нравится ему такое - пусть дрочит. Бумер-шутеры же как-то взлетели - то есть нравятся людям...
>Вопрос с подвохом. Думай.
Да я уже давно понял что тут нельзя поговорить за геймдизайн, сидят все те же ноулайферы как во всяких убежищах тешат свое самолюбие, коротают время, компенсируют социальную активность, вместо конструктивного диалога по теме. Ты вроде норм разговаривал, потом опять сорвался до "ряяяя"
>>Почему редотики ничего не делают?
>Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
Я спустя два-три месяца понял, что в игре с боевкой первое что нужно делать эту саму боевку, да вообще ключевую механику чтобы прочувствовать что до как будет в реальности. А ты в индустрии около десяти лет, делаешь в первую очередь арку ворот, завершение миссии, вырвиглазные блюры, майнкрафт местность с дикими переходами, бестолковую "дышащую" 2D idle анимацию спрайтов для плейсхолдеров. Из реального что тебе нужно сейчас - ты сделал только flood fill.
Вот и думай.
>поговорить за геймдизайн
Имеет ли смысл подробно расписывать очевидные вещи?..
>ты в индустрии
Какая индустрия, это просто хобби. Я ни на что не рассчитываю.
>в игре с боевкой первое что нужно делать эту саму боевку
А чего её делать, она и так известна. В Disgaea так и не играл? Ладно...
>ключевую механику чтобы прочувствовать что до как будет в реальности
Вот я и сделал:
>арку ворот, завершение миссии
- нужно обязательно, ибо без "Game Over" это всё не игра, а песочница.
>майнкрафт местность с дикими переходами
>"дышащую" 2D idle анимацию спрайтов
- нужны обязательно, такими я их и представлял, делается очень легко.
В общем, получилось, как я и планировал, поэтому и радуюсь этому.
>вырвиглазные блюры
Не блюр, а блум, и почему бы и нет? Это одна галочка в инспекторе...
>Из реального что тебе нужно сейчас - ты сделал только flood fill.
Так я его по памяти набросал, потому что не разобрался, что лучше.
Кстати, спасибо, что напомнил - накинул движение по диагоналям.
>- нужно обязательно, ибо без "Game Over" это всё не игра, а песочница.
Ощущение закрытие гештальта в игре нужно геймеру, а не разработчику.
Меньше звезди, больше делай.
PS
>блум
Да, это ппц.
>Ощущение закрытие гештальта в игре
WAT? Игра литералли про то, как отправить команду придурочных ребят/девчат/монстров в некое очень неблагоприятное место и попытаться вывести их по возможности живыми и здоровыми, и с сувенирами. Наподобие сериала Stargate, но абсурдная комедия. Некоторые "миссии" могут вообще не иметь никаких противников и, следовательно, боестолкновений.
...а вообще, главная проблема в том, в какой момент позволять составлять отряд для отправки: когда ты посмотрел зону и знаешь, что в ней есть, когда лишь некоторые детали известны, или когда вообще нет информации? Полагаю, первый вариант уж слишком простой, а последний слишком хардкорный. Нужны промежуточные детали, типа "там очень холодно -> пригодятся герои с огненными способностями".
>Меньше звезди, больше делай.
Я так не умею... Алсо на днях серьёзно заболел...
>Алсо на днях серьёзно заболел...
Это все прокрастинация, шизофрения не лечится все равно.
Если так хочется выводит годят из миссии - сделай широкую область высадки/эвакуации, а не ворота. Или же по краем карты области выхода.
Но все равно ты не то делаешь. Сделай сначала боевку, пару билдостроений и уже потом делай все остальное.
Это какой-то мем? У меня тут температура, голова, горло и суставы болят, сопли рекой текут и т.д. Это впервые за несколько лет (я ж дома сижу, от чего заболевать?) и именно тогда, когда я загорелся интересным проектом (впервые за... сколько?). Эх.
>>1100574
>широкую область высадки/эвакуации
В Disgaea DS это буквально 1 клеточка: клетку спавна возможно окружить 4 врагами и не давать игроку заспавнить больше 1 героя, а на клетке выхода очень часто находится неподвижный враг, у которого ещё и неуязвимость бывает из-за карты (нужно столкнуть). Однако, это всё компенсируется другими механиками, поэтому может не работать в другой игре. Посмотрим, нужно несколько вариантов попробовать сначала.
>Сделай сначала боевку
А я разве отказывался? Просто это не так-то просто организовать, оказывается. Каждой способности необходимы свои паттерны как в шахматах, и их необходимо накладывать на местность как будто это Тетрис, проверки всякие... Нужен генерализованный механизм, позволяющий вставлять новые атаки в существующую последовательность действий, без написания ad-hoc костылей на каждый паттерн... Нетривиальная штука по сравнению с шутанами.
Алсо, я не уверен, как генерализовать персонажей. Предполагается, что количество комбинаций может выходить за триллионы, т.е. делать по отдельности вообще не вариант. Нужно соединять компоненты. Непонятно только, какими они тут должны быть. Мне кажется, это важнее, чем паттерны атак...
Ладно, всё равно забью в скором времени (спойлер: ВНЕЗАПНО обнаружу, что моих скиллов рисования недостаточно, а все альтернативы не нравятся).
>и именно тогда, когда я загорелся интересным проектом
Это прям реальная херня. Как только появляется вдохновение возиться - вылезает какая-то проблема. Я уже даже не удивляюсь.
А если тратишь время на какую-то развлекательную чепуху - пожалуйста, деградируй.
По игре - сделай карточную боевку с синергией разных скиллов, сейчас это хит.
Slay the Spire - показал, что иногда можно забыть плейсхолдеры.
В Project Settings > Physics по-умолчанию стоят значения, чтобы всё вниз летело, убери их.
>если на полу нет коллайдера
Почему у тебя есть пол, но нет коллайдера?
>найти подробный ман на move_and_slide()
Можешь просто исходники почитать:
https://github.com/godotengine/godot/blob/master/scene/3d/physics/character_body_3d.cpp#L43
>Как сделать, чтобы игрок не проваливался через пол, если на полу нет коллайдера
Просто не юзай вектор гравитации. Вместо:
>velocity = input × speed + gravity
>move_and_slide()
Делай так:
>velocity = input × speed
>move_and_slide()
И тогда гравитация тебя не будет волновать.
>кастомная физика без встроенной гравитации
Вариант А:
- удочеряешься от RigidBody3D
- ставишь галочку custom_integrator = true
- пишешь свою физику в _integrate_forces():
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-private-method-integrate-forces
Вариант Б:
- удочеряешься от PhysicsBody3D
- юзаешь test_move() для теста коллизий
- юзаешь move_and_collide() вместо move_and_slide()
- соскальзывания сам реализуешь (см. исходники)
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-move-and-collide
>В XR режиме как будто живет своей жизнью
Может, это потому, что ты двигаешь XROrigin?
>поставить Dummy physic engine на весь проект
"Свою физику" ты обычно делаешь на базе какого-то существующего физического движка, в 3D Jolt будет оптимален, что-то другое тебе там выбирать не надо.
Почитай хотя бы начальные туториалы и поделай классические игры, прежде чем лезть в VR болото...
>>1100733
Эта настройка влияет только на RigidBody...
>карточные бои
Это какое-то издевательство над игроком, не? Игрок собирает хорошую колоду потом, кровью, гриндом и микротранзакциями, а RNG говорит: "неее, братишка, сегодня тебе выпадут все самые худшие карты, а вот противнику я выдам самые лучшие карты", и дальше остаётся только прокликивать до проигрыша. Так?
Случайный урон - это нормально: ты осознано кинул фаерболл против ледяного противника - из-за осечки получилось не так мощно, но всё-таки осмысленно, и следующий слабый фаерболл его уж точно добьёт. А случайные карты (приёмы) - это бред: перед тобой - ледяной противник, а из колоды вылезает "пописать водичкой" (+здоровье к ледяным монстрам), "пукнуть ветром" (у ледяных иммунитет), "отложить земляных кирпичей" (+защита от нападений из-под земли) - и ты закономерно огребаешь, а по чьей вине? По вине разработчика, что сделал несправедливую игру.
Пусть карты остаются у всяких там лудоманов и не усложняют и без того проблемный геймплей всех остальных возможных жанров видеоигр...
да, но при грамотном дизайне, у игрока будет не ощущение нечестности, а ощущение "эх, почти, вот в новом забеге я уж точно затащу". рандом штука, которая работает иногда не твою пользу, а иногда очень даже в твою. это просто правила игры, которые ты принимаешь как данность. в остальном-то игра скилл бейсед, собрать правильный билд, найти интересные взаимодействия, даже правильно разыграть карты в одном ходу, так как иногда могут проглядываться неочевидные, но очень выгодные мувы. в том же StS я бывало вот прям сосал у босса, а потом переигрывал его несколько раз, находя более лучшие в долгосрок и краткосрок вещи, и в итоге побеждал. да, иногда всевозможные комбинации дают прогирыш, но это означает, что ты с самого начала значит не очень удачный билд собрал, так или иначе. конечно, бывают сиды, где и супер билда нет, и ивенты с картой говно, но это около границы нормального распределения шанс, вероятность мала, не повод отказываться от концепции рандомного-всего.
мимо
Как раз по теории геймдизайна, все ровно наоборот.
Из-за осечки не получилось - это выходной (output) рандом, игрок не может повлиять, просто смотрит в экран.
Карты пришли в руку - входной (input) рандом, игрок может совершать осознанные выборы, чтобы смягчить ситуацию (а еще он знает, какие карты скоро придут дальше).
https://www.youtube.com/watch?v=dwI5b-wRLic
Тут вопрос не в том, "как бы добавить ещё больше рандома", а "сколько рандома - это уже перебор?"... Нужно смотреть игру в целом, оценивать риски, на которые идёт игрок, и нужно ли ему бОльше риска.
Например, если герои (колоды) умирают один раз и навсегда, риск у игрока изначально высок, и делать рандомную ловушку, которая убивает героя простым броском кубика, будет тупо жестоко/несправедливо. Соответственно, нужен бесконечный респавн/реролл ситуации, чтоб игроку "повезло в следующий раз". Но, допустим, в игре уже есть такая слот-машина, что приходится рероллить - зачем делать вторую?..
>Из-за осечки не получилось
>игрок не может повлиять
Этот риск закладывается в план. Вот допустим, минимальный урон =5, максимальный =10. Тогда противника со здоровьем в 50 очков можно убить, в наихудшем случае, за 10 ударов, а можно и за 5. Т.е. необходимо выдержать минимум 9 атак противника, ОДНАКО, есть шанс испытать всего лишь 4 атаки и победить, получив минимальный урон. Круто же!
не понял тебя. выше написали про StS, на что в ответ претензия, что рнг это издевательство над игроком, на что я ответил, что как раз StS очень удачный пример, что нет, не издевательство, а база.
>Этот риск закладывается в план.
ну так, StS так и разработан был.
асимптотически, что у тебя самого лучше получается и интересно, то и лучше, а так - кооп хоррор, инкрементал.
>написали про StS
В ответ на вот этот проект: >>1100032
Насколько я знаю, между ними ничего общего.
Предлагаешь анонам делать 1-в-1 клоны StS что ли?
>Насколько я знаю, между ними ничего общего.
плохо знаешь, карточки могут быть и в опен ворлд рпг. тем более я не предлагал их обязательное наличие, просто ответил на дурацкий пост, что карты это слишком рандомно и фу.
>Предлагаешь анонам делать 1-в-1 клоны StS что ли?
ну, так хотя бы кто-то вашу игру купит.
>карты это слишком рандомно
А где контр-аргумент, кроме "у StS как-то получилось (ЕСЛИ готов проходить одно и то же с нуля, надеясь, что рандом будет благосклонен в следующий раз"?
Ты только подтвердил, что карточки - это рандом.
>игру купит
Лол...
>Ты только подтвердил, что карточки - это рандом.
я не отрицал существование рандома, а указывал на то, что его наличие не отменяет присутствие скилла в целом и что фукать в эту сторону - фу. рандом, подобный StS, это база геймдева.
>ЕСЛИ готов проходить одно и то же с нуля, надеясь, что рандом будет благосклонен в следующий раз
ну, дяденьки у автоматов, которые дергают за канат, чтобы макака поймала банан, вроде готовы.
>Лол...
да лолкай на здоровье лол.
>дяденьки у автоматов
С чего ты взял, что это ЦА? Нужно знать ЦА.
>рандом, подобный StS, это база геймдева
У тебя какое-то зашоренное видение рандома... Ты обнаружил рандом в StS в форме "карточек" (чисто визуальный элемент), и теперь уверен, что все игры обязательно должны включать в себя "карточки"?..
Рандом в синглплеерных играх нужен, поскольку без рандома игра будет проходиться одинаково. Если в стандартном шутере монстры прыгают из строго определённых позиций в определённое время, и ни монстры, ни оружие не добавляют случайности, весь геймплей будет сводиться к строго определённой и оптимальной последовательности действий, которую возможно заучить наизусть и исполнять как музыку. Интересно ли это игрокам? Большинству - нет, иначе занимались бы исполнением музыки, а не играми (существующие игры без рандома часто про музыку; геймплей синхронизируется с саундтреком и т.д.).
Но нужно ли добавлять рандом в шутер именно как случайные "карточки способностей"? Вот перед тобой монстр, а ты стоишь, выбираешь между "BFG9000" и "вскрикнуть и убежать", а потом тебе подкидывают перекачанного босса, а у тебя нет больше "BFG9000". Карточки здесь полностью нарушают жанр игры, т.е. лишают целевую аудиторию удовольствия от игры.
https://www.youtube.com/watch?v=a4rBBP3UBow
Main нода, в ней подгружаемые-заменяемые контейнеры на элементы игры, уровни, уй и прочее. Видос не смотрел.
Чёт я расстроился и демотивировался.
Вряд ли я смогу нарисовать героев...
чювак я же смог своих нарисовать и ты своих уродов нарисуешь, помоему не важно как они выглядят а главное создать базу механик а уже потом если механики работают можно и художника нанять
мне видится что важно отображать информацию про обоих персонажей и игрока и врага так так как как они сами по сути одинаковые только разница в том кто управляет
и вот хз должно ли это в таком виде выглядеть или странным кажется?
Ты скорее всего утратил мотивацию, а мозг логично подобрал причину (мозги любят завуалировать).
Не планируй, не думай, просто открывай проект каждый день и копошись. Делай что любишь - создавай миры. Похер на сравнение или оценку, похер на план, просто кайфуй с чего кайфовал раньше.
Блинб чет быстро. Пробовал сначала замоделить или скачать ассет понравившейся аниме девочки, а потом по контурам обводить?
>>1101327
Мне кажется было бы лучше поставить врага дальше и сделать его меньше, а игрока больше и ближе или вообще вращать камеру, как у чувака с розовыми хомяками
>>1101340
Я сейчас даже на спрайты подзабил (заипался рисовать и потом дропать), буду делать что-то на уровне таких форм
>>1096462 →
Вы думали это корабль? НЕТ! Это ковбой ёптить.
>и вот хз должно ли это в таком виде выглядеть или странным кажется?
Норм, добавь анимации удара (например взмах меча) и слегка двигай спрайт юнита. Будет уже норм смотреться
Попробуй использовать PanelContainer с рамками. Я бы раскидал их в разные углы экрана, чтобы не слипались.
Алсо, увеличь им лбы. Аниме-глаза растягиваются вниз, а не вверх, начинаясь примерно с середины лица.
> добавь анимации удара
Что-то типа из этого рода. Помни только от ярких вспышек/всплесков люди могут быстро уставать.
хорошие варианты спс
>>1101347
да офк надо будет подзапариться каждому оружию свой эффект удара можно еще и по цветам их менять
Спасибо, благодаря тебе я решился на идею с чиби-фишками. А то ломал голову над тем, как же вписать в рамки 1x1x2м героев с разными габаритами так, чтоб это не выглядело слишком тупо.
>>1101340
>Делай что любишь - создавай миры
Мне в голову постоянно то порнуха какая-то лезет, то какая-то кринжатина - показывать другим людям стыдно. Но показывать что-то кому-то хочется, иначе зачем это всё? Нет мотивации сидеть и делать что-то творческое в стол, не имея надежды кому-либо это всё продемонстрировать.
>>1101342
>Пробовал сначала замоделить
Вкатился в 3D, когда понял, что для 2D мои руки слишком неточные (не могу ни одной нужной линии провести), но решил попытаться-таки подкачать скилл в 2D, потому что 3D из фантазии совсем без хотя бы эскизов делать слишком трудно, но рисовать случайные картинки - скучно, поэтому начал думать над тем, какую игру можно сделать, но только так, чтобы это была не порнуха... И вспомнил про этот проект - подумалось, можно переделать на 2.5D пошаговую тактику, используя плоские картинки вместо моделек. В итоге я неделю не притрагивался к рисованию, потому что ковырялся в редакторе сцен и кода, а потом слёг с температурой.
Ты уже ограничил себя размером тайла, такими вот стройными персонажами. Плоска поверхность позволяет натянуть жирного монстра в 1.2-1.5 размера, а тут нет.
Идея фишек - хорошая, смотри как интересно сделали в battle brothers. Экономия в пол тела, фишки жирные помещается любой арт.
Местность хорошая, если бы по разным сторонам стреляли какие-то пушки/танки - что-то с баллистикой (и явным видимым полетом). Туда же авиацию. Но не делай симулятор ходьбы (пустых передвижений) в тактической карте.
>3D
Мне думается без скилла в 2Д там все равно делать нечего. Ощущение перспективы (да, да, даже в 3Д) и пропорций - это надо все равно тренировать (даже если по рефу делаешь). Я 3д обхожу стороной, потому что ощущаю что работы больше и еще практика показала что плохое 2д смотрится лучше чем плохое лоуполи 3д.
>Мне в голову постоянно то порнуха какая-то лезет, то какая-то кринжатина - показывать другим людям стыдно
Ты недавно в интернете? Хотя с порно не советую работать.
>>1101717
Написал длинный ответ, но стало стыдно, удалил.
В общем, просто знай, что у меня своя задумка.
>плохое 2д смотрится лучше чем плохое 3д
Обычно всё в точности наоборот же...
Почему при быстрых скоростях эта штука дает 0, но обсчитывает столкновение (объект честно отлетает)?
1) Используется в func _physics_process()
2) 60fps
3) стоит после move_and_slide()
Есть способ обсчитать столкновение двух CharacterBody2D, без создание еще одного коллайдера с Area2D и сигналом?
В общем, если объект стоит, иногда (по фазе луны, или положению юпитера) get_slide_collision_count у стоящего объекта может вернуть 0 (но чаще больше 0)
Живите с этим.
>>1101801
Не, ну я согласен, когда физика не успевает. Но блин срабатывает же bounce. Ну ё-моё...., Как же так..., Годони?? Ты мне был как брат!
>4.7.1
Что то не запускались проекты на старых Андроидах >12 ,откатился на 4.6.3, - норм стало.
Там, скорее всего, подняли Android target SDK для соотвтетствия тому, что принимают в гугл плей. Вроде бы теперь это Android 16 и AAB вместо APK.
https://forum.godotengine.org/t/how-to-target-latest-android-sdk/142631
Там где-то ручками можно выбрать, минимальный поддерживаемый это Android 5.
Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Суть в том, что CharacterBody сам по себе не толкает другие объекты, он только "создаёт препятствие" на пути других объектов (которое выглядит для этих объектов как неподвижный StaticBody), и если эти другие объекты задетектят препятствие, то они могут подвинуться. Но препятствие создаётся только когда CharacterBody реально останавливается, а скольжение/отскоки происходят как бы "в уме", то есть получается так:
1. CharacterBody размером N двигается с большой скоростью, покрывая N10 пикселей за тик.
2. CharacterBody видит препятствие на расстоянии N5 от него, и сразу вычисляет отскок на N5.
3. Для того препятствия, этот CharacterBody никогда не касался его, и даже не стоял рядом.
Если ты хочешь надёжно толкать объекты своим CharacterBody, тогда ты должен детектить столкновения на стороне CharacterBody и отправлять запрос типа apply_impulse тем объектам, с которыми ты столкнулся, будь то RigidBody или CharacterBody (последним придётся свой метод сделать - рекомендую использовать то же имя, что и у RigidBody, чтоб заюзать duck typing).
Алсо, если ты там что-то вроде бильярда делаешь, то лучше используй RigidBody - там уже все отскоки и движение по траекториям сделаны за тебя. CharacterBody имеет смысл только для персонажей, которые твёрдо стоят на ногах и не толкают телом других персонажей.
>Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Я могу быстро вычленить демку, скажи как подготовить (удалить просто ".godot" и все поместить в архив или еще что-то нужно?). У меня 4.7.1
Проблема текстом:
Два CharacterBody2D
I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
II) Б - двигается все время на A.
III) Логика такая - в A мы проверяем get_slide_collision_count и удаляем Б. (я случайно сделал так для отладки и поймал эту багу)
Что происходит
1) Небольшая скорость - все работает норм A детектит Б всегда, get_slide_collision_count() > 0
2) Высокая скорость (появление проблемы) - все работает как при 1 случае, но иногда (примерно 1 из 10) - Б сталкивается с A, но get_slide_collision_count == 0 и он не удаляется, при этом отскакивает от А.
Коллизия такая
name::Layer/Mask
A::1/2
Б::2/1
Еще у меня у меня везде CollisionPolygon2D с острой мордочкой (мне кажется что-то связанно с этим тоже).
В чем реальная ошибка - отскок (bounce) Б от А происходит, то есть движок определяет коллизию, но указывает в get_slide_collision_count == 0
Как-будто есть две отдельные логики на условие столкновение и формирование объектов столкновения (например какой-то угол меньше чем нужно и get_slide_collision_count затирается со всеми объектами).
Звучит так что надо уже ишью оформить или залесть в сорцы, но мне чет лень так (да и мне кажется я что-то не понимаю или ошибся и не вижу).
В общем, про демку скажи, я подготовлю и скину (там не долго).
>>1102009
Проще скинуть демку.
Взрывы это смерть по таймауту 4 секунды, чтобы они орбитами как планеты не летали. Ограничил количество 5 штуками.
Дольше искал файлообменник, надеюсь норм.
https://transfiles.ru/t7l2t
>2. CharacterBody видит препятствие на расстоянии N5 от него, и сразу вычисляет отскок на N5.
>3. Для того препятствия, этот CharacterBody никогда не касался его, и даже не стоял рядом.
Теперь, кажется, понимаю как работает. Если что поправь.
Если оба А и Б CharacterBody
Если Б движется и вычисляется отскок с А (сам А неподвижен), то состояния будет такие:
А::get_slide_collision_count == 0 // ничего не узнает
Б::get_slide_collision_count == 1 // посчитал, добавил но никому не сообщил об столкновение.
Как вариант передавать друг другу импульсы?
В общем. У меня есть персонаж, на него бежит волк, в моменте волк совершает прыжок и сталкивается с персонажем - я хочу чтобы волк толкнул игрока и сам отреагировал по массе.
Мне нужно
1) Передавать друг другу импульсы и рассчитывать самому импульс (масса на скорость)
2) Заменить волка на RigidBody?
3) Заменить и волка и персонажа на RigidBody (чтобы само считалось)?
Я примерно понимаю как можно рассчитать все искусственно, но хочу максимально задействовать физику годота, чтобы волк даже массу пуль чувствовал (они его немного тормозили)
Ты навайбкодил нейронкой что-то, что сам не понимаешь, а теперь просишь анонов из треда разобраться?
>>1102067
>хочу максимально задействовать физику годота
Это крайне глупая затея. GodotPhysics(2D/3D) писали из-за синдрома Not Invented Here и поддерживают только потому, что многие юзеры привязались к этому решению. Движки физики самого Godot очень медленные и уж слишком неточные/нестабильные. Вон, для новых проектов 3D физикой автоматически выбирается Jolt, что и быстрее, и точнее/стабильнее. Для 2D тоже есть альтернативы, но нужно скачивать отдельно, если нужно.
Более того, в геймдеве крайне редко бывает универсальное решение, которое подходило бы всем играм, да и в отдельно взятой игре часто получается так, что нельзя написать универсальный компонент. Поэтому геймдев - это самая костыльно-велосипедная часть айти. Если тебе нужно решить задачу "ловить снаряды лицом мелкого кораблика", то ты можешь навесить круглую Area2D вокруг корабля, ограничить максимальную скорость, и потом экспериментальным путём подогнать параметры так, чтобы глюков было, скажем, менее 1 на 100 попыток. А можешь сделать как-то по-другому - какая разница? Твоя игра - тебе решать.
Просто имей в виду, что если ты сегодня делаешь клон Asteroids, а завтра хочешь сделать каких-то "волков, прыгающих через игрока", тебе, скорее всего, придётся перестраивать кучу сцен и переписывать кучу кода, а потом снова подгонять параметры, потому что это будет уже совсем другая игра с другими ощущениями. Определись сначала с игрой, потом уже пиши костыли и велосипеды под эту конкретную игру. Не можешь определиться с игрой? Делай прототипы - прототипам можно быть глючными и ненадёжными, потому что ты их всё равно никому не дашь. Если прототип играется норм (закрывая глаза на глюки), тогда переписывай заново, используя полученные знания и опыт для создания оптимальных костылей и велосипедов. Вот и весь секрет.
Впрочем, извини, если что. Я в плохом настроении.
>волк совершает прыжок
У тебя сейчас игра в 2D с видом сверху - как прыжок будешь делать? Можно симулировать через масштаб (scale), но нужно быть аккуратнее с физикой (уже не помню, какие проблемы могут быть, но я делал так).
>Заменить и волка и персонажа на RigidBody
Это самое очевидное, если тебя устраивает движение со скольжением. Поиграйся с linear_damp и angular_damp, чтобы сделать персонажа чуть более отзывчивым, или сделай аналог этих свойств в своём коде.
>Ты навайбкодил нейронкой что-то, что сам не понимаешь, а теперь просишь анонов из треда разобраться?
Фига ты дебил, ты хоть открывал? Там кода на 5-10 минут.
Это так называемый playgrоund, проекты "огрызки" для тестов чего-либо. Я поймал проблему у себя в проекте, начал чистить, понял что вилкой ничего не почищу, пошел воспроизвел в playground.
Нигде не написано что во время bounce не передает информацию с тем чем взаимодействует. Может в геймдеве это норм, но с точки зрения архитектуры это немного костыль (ты уже просчитал взаимодействие - почему бы ему не дать инфу о коллизии, которая в сравнение с расчетом уже бесплатная).
Я у себя давно уже переделал под арену, но мне хотелось понять почему так происходит. Но ты вместо ответа додумал свое и сам с этого взорвался. Я вообще не вайбкожу, но использую иногда ИИ для обучения, он хорошо показываеn "best practice".
PS волка не покажу.
>У тебя сейчас игра в 2D с видом сверху - как прыжок будешь делать?
Мы же не фулл top, мы как-будто смотрим на мир под углом. Даже в римке есть перспектива и объем (художник местами передал один и тот же "угол", а есть старые спрайты фиг пойми в какой проекции, наверное еще сам гений рисовал).
-Волк движется - скорость 1х
-Становиться близко, рывок - скорость 10х
-Можно даже слегка анимировать спрайт (поднять слегка в самом начале и опустить конце).
>(художник местами передал один и тот же "угол", а есть старые спрайты фиг пойми в какой проекции, наверное еще сам гений рисовал)
Пример до и после.
Если вы стеснялись своих плейсхолдеров, эти спрайты заработали 55 000$ за 8 дней (14 500$ за первый день).
>I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
>II) Б - двигается все время на A.
Так это абсолютно нормально, прочитай что написано в доках про get_slide_collision_count. Оно возвращает счет коллизий, возникших в последний вызов move_and_slide. move_and_slide пытается сдвинуть тело на скорость*дельта, если у него не получается, он записывает коллизию в свой списочек коллизий. Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости. Если у тела нулевая скорость — он заметит коллизию в move_and_slide только если что-то встанет к нему вплотную или пересечется с ним. То же будет если он движется в направлении от волка или перпендикулярно движению волка. Тело не обязано знать, что в него кто-то там врезался, оно вообще может "не видеть" волка, даже если волк видит тело, если разрабу захотелось так настроить слои и маски.
Коллизия для конкретного тела — это конкретно ситуация "я пытаюсь сдвинуться на такой-то вектор, но если я так сдвинусь, мой хитбокс будет пересекаться с хитбоксом другого тела (которое я вижу через мою коллижн маску), поэтому мне приходится сдвинуться на какую-то другую величину". Все. Если тебе хочется обрабатывать бильярдные удары волком — как тебе уже написали, в налетающем объекте (ну и вообще во всех) делай типа
var collision_occured := move_and_slide()
if collision_occured:
____for i in get_slide_collision_count():
________var collider := get_slide_collision(i)
________if collider is MyCharacterBody:
____________collider.do_whatever_that_i_want_to_do_when_wolf_hits_this_body(...)
>________var collider := get_slide_collision(i).get_collider()
фикс
Бессмысленная стена воды, в годоте используется физика jolt.
>прочитай что написано в доках про get_slide_collision_count.
Там буквально ничего не говориться. Точнее говориться ровно то что ожидаешь. А ожидаешь получить все коллизии.
>Тело не обязано знать, что в него кто-то там врезался
Ну мы как бы с коллайдерами работаем, что значит не обязательно, нафига мы его добавили (для столкновений, а значит и коллизии ловить).
>Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости
Ты же видишь спокойно пропадают (если нет отскока). Сделай в демо круглые коллайдеры и будет 0 отскоков - будут исчезать все (если двигать не будешь).
В общем, там есть демо, ведёт себя эта шняга не интуитивно, информации настолько мало что даже ИИшка объяснить не может. Но судя по сорцам работает как объяснил анон (move_and_slide похер кроме себя, нет обмена, нет системы какой-то)
https://github.com/godotengine/godot/blob/63b7e027254e6b77b3d1036c89973060fb5be088/scene/2d/physics/character_body_2d.cpp#L45
Интереснее там _move_and_slide_floating с полем класса motion_results
Единственный вариант, не добавляя арен (Кто экономит на аренах? Лайк, подписка), это передавать ручками инфу между объектами, но надо учитывать момент, что иногда они будут касаться и детектить друг друга (безумие писать такое не на уровне сорцев движка).
В общем, годот как раскраска, многое нужно доделать самому.
Детекти резкое изменение вектора или скорости постфактум. Хотя я для таких целей действительно Area с запасом использую
>>Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости
Я не так прочел, но оказалось это еще хуже, в общем, это из серии - не будешь ничего в кадре вызывать - не будет и багов (ничего не будет).
Я там не ищу решение, я воссоздаю проблему с коллизией (неочевидное поведение, плавающая ошибка, магическая ошибка).
>Там кода на 5-10 минут.
Зачем в том коде столько бессмысленных "TODO"?
>>1102084
>мы как-будто смотрим на мир под углом
Это сложнее правильно анимировать с физикой...
>>1102167
Мне кажется, ты просто используешь инструмент не по прямому назначению. CharacterBody нужны для "персонажей", там буквально иконка человечка, а ты пытаешься реализовать пулю/снаряд/стрелу и т.п. Попадание в цель - это обычно код снаряда, а не пострадавшей от него цели, наподобие такого:
>func _on_body_enters(body):
>_ if "take_damage" in body:
>_ _ body.take_damage(my_damage_value)
>_ spawn_explosion() # если это ракета
>_ queue_free() # самоуничтожение
Дальше подгоняешь параметры, чтоб не пролетало.
>>1102141
>в годоте используется физика jolt
Только для 3D, с недавних пор. Мы обсуждаем 2D.
>>1102129
Всё так.
>ИИ для обучения хорошо показывает "best practice"
Судя по опыту других анонов с ИИ на Godot - эти "best practice" в кавычках неспроста... LLM может всякого галлюцинационировать и обернуть в убедительную обёртку, ещё и приправит приторной лестью. А ты и поверишь в это... Уж лучше самому по всем граблям пройтись и понять, что и как, чем верить многократно пережёванной информации из неизвестного и потому ненадёжного источника (на чём тренировали LLM? на большинстве сайтов в интернете тупо мусор сейчас).
>Зачем в том коде столько бессмысленных "TODO"?
Playground - это слепки (временные копии) от реальных проектов в начале своей жизни. Или почищенные копии.
А тодошки с маркером это для отката, чтобы потом почистить и протестировать что-то еще, не перечитывая весь код (через глобальный поиск). Playground может обрастать полезным кодом, поэтому откатить лучше чем потом в 100500 копиях искать нужный вариант.
>Мне кажется, ты просто используешь инструмент не по прямому назначению.
Не надо додумывать и опять мне предлагать арену. Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение, это какой-то абсурд (сама проблема давно решена).
>Судя по опыту других анонов с ИИ на Godot - эти "best practice" в кавычках неспроста...
Я полностью понимаю код и обычно спрашиваю какие-то мелкие вещи (особенно херотень с углами и синусами, которую я на память не помню/не знаю).
Собственно почему я докопался с коллизией, я хотел понять почему так работает.
У ИИшки еще удобно спрашивать "что тут происходит", она даже ASCII рисунки делает. А ты делал схематические рисунки для анонов?
Годот решения очень плохо гугляться. Часто ссылки приводят на какой-то узкоспецифичный вопрос с таким же узкоспефичным ответом.
Такое ощущение - хайп годота попал в эру ИИ и люди просто не спрашивают то что раньше бы спрашивали друг у друга, все ньюфажные вопросы исчезают в бездне ИИ я даже скучаю по stackoverflow
>А тодошки с маркером
Рубрика Лайфхаки
Кто не понимает что за маркер и зачем он.
Чтобы найти точно все места через Ctrl+Shift+F
Такое еще использую чтобы связать несколько разных участков кода какой-то общей связью/информацией
# INFO: [2026-08-13--1647] Какой-то комментарий если надо
Теперь по [2026-08-13--1651] можно найти все места, при этом маркер всегда уникален (из-за даты и времени создания маркера)
Ты про рендеринг 3D? Ну, попробуй "пикселизировать" (уменьшить разрешение). Щас это популярно.
>>1102241
>слепки (временные копии) от реальных проектов в начале своей жизни
ИМХО, бред какой-то, никогда даже не думал сделать такое. Если мне нужно что-то там мелкое протестировать в Godot, я просто создаю новую сцену/скрипт/ресурс в папке res://test или типа того, где хранится всякий "мусор", который я планирую потом удалить или переписать начисто. Так как я не создаю лишних синглтонов (автозагрузочных сцен), любая новая сцена в моём проекте может запускаться независимо от всего остального проекта, т.е. у меня никогда не возникает необходимости делать "чистую" копию проекта...
>может обрастать полезным кодом, поэтому откатить лучше
Эм, а зачем "откатывать" полезный код? Если код полезный, ты его переносишь из res://test в res://game или в res://utils (для кода, который может пригодиться в нескольких разных проектах), или оформляешь как аддон в res://addons (для кода, который можно передать другим через гитхаб), что-то в этом духе. Откатывать не надо.
>...чем потом в 100500 копиях искать нужный вариант
Сам себе создал проблемы (копии копий копий) и героически их преодолеваешь?
>Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение
Во-первых, физика в играх - это по определению неточная штука, потому что ей нужно работать минимум 30 или даже 60 раз в секунду и оставлять время на графику, звук, логику и т.д. Точные столкновения возможны только в научных симуляциях, которым позволено "тормозить", потому что от них требуется не скорость как в играх, а точность результатов. Разве это не очевидно?..
Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров, но ты должен хорошо понимать, что делает физический движок и чего он не делает. Сами по себе "коллайдеры" - это просто данные, описывающие какие-то части симуляции (фигуры в пространстве), а что с ними происходит - это уже другой вопрос. Если ты размещаешь коллайдеры в RigidBody, то они будут двигаться и реагировать на всё сами. Если ты размешаешь их в StaticBody, они ничего сами не делают, только мешают другим. А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение" (в Godot 3 этот класс назывался KinematicBody), которое ставится в противовес "динамическому" (RigidBody). Использовать CharacterBody как "пассивный датчик столкновений" - это использование не по назначению, потому что он предназначен быть "кинематическим двигателем". Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
>арену
"Area" переводится как "область" (площадь и т.п.), и подразумевает просто абстрактный участок пространства, который детектирует пересечения с другими участками пространства и также с физическими объектами в пространстве. "Арена" (arena) - это место, где кто-то с кем-то дерётся или сражается, типа боксёрского ринга. Не надо искажать слова, пиши "Area".
>res://test
Ну так тебе все равно придется копии делать, ты не хочешь в игровые скрипты гадить. Проще даже в моменте проект скопировать - и нагадить там.
Тест сцены для проверки механики я тоже делают, но они в рамках игровой логики, а не тотального дебага с 100500 временными изменениями под тест.
>>арену
Это был тонкий тролинг продолжая тему волков в цирке - ну типа арена - цирк, волки - ну вы поняли, смешно же, че не смеешься? А потом я правда затупил под усталость. Вот только нафига ты высираешь целую пасту на всякую фигню? Мог бы кратко стебануться. Лучше бы по движку так писал.
>Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров
Как для CharacterBody без Area?
>Во-первых, физика в играх - это по определению неточная штука
Еще раз, в той ситуации физика работает нормально, там все взаимодействуйте с коллизией. Проблема начинается только в отскоке, который регистрируется только у одно стороны (что уже по логике факап).
Коллайдеры тоже не бесплатная штука, чтобы им разбрасываться, да и хочется получить точку столкновения и нормаль.
В общем, опасная фигня, несущая в себе очень трудновоспроизводимую ошибку, если отскоки в игре у тебя редки (относительно малые скорости движения).
>Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
Это говнокод. Вместо глобальной системы или просто передачи сообщений между объектами (это, кстати, сложнее, но движок знает порядок вызовов), там тупо поле класса (хотя это поле public).
Vector<PS2DT::MotionResult> motion_results;
Но да, поделать нечего, нужно только смериться, понять и простить. Таков путь.
Когда-нибудь я напишу свою физику для 2D с блэкджеком и волками. Но не сегодня.
Но если ИИ знает ответ на вопрос, значит он его где-то прочитал...
>Но если ИИ знает ответ на вопрос, значит он его где-то прочитал...
Он вероятностно подбирает в зависимости от контекста, причем иногда не только словами, а слогами или даже буквой за буквой. Понимая как работает эта хрень, в жизнь не доверишь ему код.
Мне один раз высрал правильный код, но написал оператор "+=" вместо "=" просто потому что где-то токен += был чуть выше, а не потому что он "знал".
Было бы круто если бы он реально знал/понимал без вероятностей.
> А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение"
Кстати, почему тогда CharacterBody отскакивает от CharacterBody?
В теории, если отключить отскок это бы полностью нивелировало проблему.
velocity += direction * speed
Нет никакого отскока и рикошета!!! ВНИМАНИЕ! Это я сам создаю рикошет!!!
Вы понимаете что ИИ стала умнее двачеров? Умнее меня, тебя и меня!!! ЭТО ВСЕ, ПОЧАНЫ, ЭТО СИНГУЛЯРИТИ!!!
>Это я сам создаю рикошет!!!
Я... ЧЕЛОВЕК... РИКОШЕТ!
Все, теперь это мое погоняло в чатике.
Живите с этим
>Вы понимаете что ИИ стала умнее двачеров?
Нет. Тут предпочитают голову в песок и отрицание.
>отрицание
Было б что отрицать... Ну может нейронка слепить веб-игру для слабоумных младенцев в Яндекс.Слоп и принести три копейки из-за того, что игру удалят за неактивность (а хочешь активность - плати, норм развод). А если я хочу ГТА? И не на кубиках, а нормально. Как бесплатная из числа ещё доступных нейронка мне поможет? Или опять платить за кота в мешке, который может помочь, а может и навредить? Мы в СНГ живём и покупаем всё что нужно для домашнего и рабочего компьютера на торрент-трекерах, а последние годы снаружи нам активно запрещают покупать (хотя мы и не собирались). И ты НАМ предлагаешь платить за токены для слот-машины в казино? Лол...
Или ты так радуешься за барина с триллионами долларов капитала, у которого суперкомпьютер в личном пользовании?
>>1102440
Мы всё ещё понимаем, что игра это на 90% арт, сторителлинг, геймплей. То, что тебе нейронка накидывает чарактер-контроллер, который итак есть искаропки, это не делает тебе игру. 90% работы всё ещё не сделано.
>Мы всё ещё понимаем, что игра это на 90% арт, сторителлинг, геймплей.
Потом появляется такая игра как римволд-в-фактории и все эти высказывания рушатся, потому что 90% там это код и безудержная отладка механик.
Игры разные.
https://godotengine.org/article/submissions-open-godot-2026-showreel/
Отправляй, слышь
>юзаю ч/б картинку как карту высот для расчетов
В любой непонятной ситуации с языком шейдеров - конвертируй StandardMaterial3D в ShaderMaterial:
>uniform sampler2D texture_heightmap : hint_default_black, filter_linear_mipmap, repeat_enable;
У тебя такая строчка какой-то неправильный результат создаёт?
>у меня загружается криво
В каком формате данные в картинке? Я погуглил - данные могут быть по-разному закодированы. Если твой редактор графики закодировал данные в другом формате, Godot может неправильно их интерпретировать. Попробуй взять эту картинку и переэкспортировать с другими настройками экспорта/пересохранить через другой редактор картинок. Подробнее подсказать не могу, т.к. сам не разбираюсь в этих "color space" - нафиг их вообще придумали, непонятно...
>>1101862 →
>Я правильно понял что для рендеринга на процессоре нужно что-то с кодингом на си или плюсах для скорости
Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps) - да, тогда тебе нужен компилируемый язык и вдобавок куча всяких оптимизаций для твоих алгоритмов работы с графикой, иначе не взлетит. Если тебе достаточно сгенерировать одну картинку за сколько угодно времени - язык тут вообще не важен.
>>1102028 →
>Годот мне понравился, а как там с вычислениями на проце, не будет медленно из-за недопитона?
По моему опыту, если ты в функции _draw() пишешь простой код для рисования 2D элементов GUI - в большинстве случаев ты даже не заметишь работу своего кода, это будет мгновенно (результат как-то кэшируется и его можно обновить запросом queue_redraw, но даже в реальном времени норм). Также ты можешь генерировать пикселями в Image, но разумное разрешение будет где-то до 256x256 (если в один поток). Всё во многом зависит от того, что ты хочешь сделать - если тебе достаточно шум Перлина налепить, то это будет быстро и для бОльших разрешений (ибо ты просто обращаешься к API движка, который всё на C++ делает), а если ты напишешь вручную что-то вроде нейросетки с сотней нейронов на пиксель - то разрешение, рациональное для реального времени (скажем, 30 кадров в секунду), на процессоре на GDScript, будет намного меньше, и такое будет лучше переписать на шейдеры или на C++. Рекомендую для начала сделать прототип на GDScript, а уже потом переписывать на что-то другое, если результат выглядит норм (кроме шейдерных эффектов, разумеется - их проще сразу в шейдере написать, чем делать for x in size: for y in size:).
Спасибо за подсказку, анон, походу сама пнгшка с картой высот была кривая (рипнута из игры). Нарисовал просто линейный градиент, все сошлось с маном - без source_color ровно, с ним - криво.
>>1102788
>Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps)
На проце только всякие древние алгоритмы, которые плохо распараллеливаются для шейдеров (о которых в той древности и не думали), скорее всего скорость современных процов компенсирует слоупочность недопитона. Может еще придумаю как сделать генерацию кадров на шейдерах, если недопитон таки не вытянет.
>в игре с боевкой первое что нужно делать эту саму боевку
>>1100574
>Но все равно ты не то делаешь. Сделай сначала боевку
Ладно, вот тебе боёвка... Пока что это грубый прототип, нужно будет отрефакторить его полностью.
Если непонятно по видео - урон у всех героев фиксированный (-15 здоровья), но даётся бонус или штраф за разницу высоты между атакующим и защищающимся. Поэтому в данный момент оптимальная тактика одна - забраться повыше и заманить врага на клетку пониже, получая бонус до x2 от базового урона. Чтобы было больше интересных тактик, придётся добавлять многие другие способности для различных героев.
По моей задумке, во время применения навыка (которое сейчас мгновенное) на экране должны появляться полноразмерные (не чиби) 2D спрайты героев игрока (которые применяют навык) и противника (на которых подействует навык), слегка анимироваться (всего 2-3 кадра или Live2D анимация), и исчезать с экрана. Т.е. фигурки с чибиками показывают положение в пространстве, а изображение навыков происходит в 2D.
Также по задумке, можно будет перемещать надгробия и воскрешать героев, поэтому они не исчезают. Основной задачей игрока является "найти и забрать новых героев и/или лут, не потеряв при этом уже имеющихся героев", при этом, погибшего героя можно забросить в портал и вернуть к жизни после того, как миссия будет завершена... Возможно даже пожертвовать кем-то, чтобы спасти более ценного героя.
>Может еще придумаю как сделать генерацию кадров на шейдерах, если недопитон таки не вытянет.
Важно понимать GDScript это не питон, они похоже только синтаксически (визуально), дальше сходство заканчивается. Он никаким образом не собирает недостатки интерпретатора питона, это два разных мира.
Godot shader language - это вообще другое, это даже не GDScript.
Суть обычно простая, если ты не знаешь как устроен и работает GDScript и GDShader - то думать об оптимизации тебе еще очень рано. Так что никакой "недо-питон" тебе там ничего не испортит, если сам не испортишь.
Без агрессии, но понизь планочку. Годот достаточно гибкий для многих извращений, плюс у тебя есть сорцы. Так что грызи этот камень без импульсивный выпадов типа "недо-питон", "вытянет", "слоупочность".
Просто с пассивной агрессией тебя быстро пошлют нахер, а технически грамотных анонов тут полторы штуки (и все они психически стабильны как последние элементы таблицы Менделеева) - так что держишь за них.
Добро пожаловать в комьюнити :)
>Ладно, вот тебе боёвка...
О, ты выжил после болезни, поздравляю.
Сделай хотя бы легкий выпад во время удара (юнита на юнит). Делается он быстро, зато сильный фидбек по восприятию от боя.
Ну или что-то свое, не хватает фидбека по восприятию, цифорок мало (да, я прочитал что ты хочешь сделать отдельный экран)
>По моей задумке, во время применения навыка (которое сейчас мгновенное) на экране должны появляться полноразмерные (не чиби) 2D спрайты героев игрока (которые применяют навык) и противника (на которых подействует навык), слегка анимироваться (всего 2-3 кадра или Live2D анимация), и исчезать с экрана. Т.е. фигурки с чибиками показывают положение в пространстве, а изображение навыков происходит в 2D.
Вот, поэтому я и говорю что надо делать первую очередь важный геймплей или боевку. Есть подозрения что этот экран может раздражающе "мигать" и бить по мозгам/глазам, поэтому надо сразу протестить, это может изменить половину боевки и геймплея.
>пик2
С учебы не видел блок-схем. На самом деле тугая и неудобная штука, умерло так же как умерло UML.
Мы обычно разрабатываем снизу вверх, попробуй набросать логику сверху вниз. Создать все классы/объекты, прописать взаимодействия между ними (забивая методы pass, а лучше как в котлине сделать функцию TODO() которая бросает исключение если забыл имплементировать). А уже потом заполняй реальным кодом.
То есть, ты как бы оперируешь взаимодействием на уровне объектов и из методов, а реализацию оставляешь на потом.
Ты опытный кодер, поймешь что это читается и проектируется проще и быстрее.
>fix
То есть, ты как бы оперируешь взаимодействием на уровне объектов и их методов
>>1102845
Ну наверное что-то такое:
GameManager.newRound()
GameManager.loadRound()
GameManager.saveRound()
GameManager.startRound()
RoundManager().searchTarget()
RoundManager().chooseTeam()
RoundManager().chooseBadUnit()
RoundManager().activationGate()
RoundManager().restoreCamera()
RoundManager().nextRound()
TacticalСombat.chooseUnit()
TacticalСombat.moveUnitTo()
TacticalСombat.serachUnit()
TacticalСombat.serachLoot()
TacticalСombat.collectLoot()
TacticalСombat.nextRound(currentRoundManager)
TacticalСombat.atack(currentAtackManager)
TacticalСombat.isTimeUp()
TacticalСombat.getAllUnit() > 0
Тут пока я набросал, уже стало видно какие взаимодействия надо поменять и что некоторые объекты надо поделить еще (слишком много на себя берут, не по роли). Но ты уже сам разберешься. В любом случае проектировать весело, ты буквально думаешь, "о мне нужно тут проверить кончилось ли время - значит мне нужен метод/свойство isTimeUp()". Ты уже мыслишь абстракцией выше - ты не думаешь как ты это сделаешь, ты просто говоришь - тут нужно это и потом это сделаешь.
Это и есть проектирование сверху вниз. Сначала абстракции/взаимодействие - потом код
Если что это я по твоей блок-схеме накидал. Это грубая декомпозиция предметной области как есть, без проектирования.
То есть, ты сначала делаешь как лезет в голову, потом смотришь на объекты - и улучшаешь если надо. Я к тому, что вижу все проблемы и что раунд не должен с юнитами работать и TacticalСombat надо поделить итд. Это прототипирование и временно говнить можно, мозг не резиновый
Добрый день. С годотом не знаком, но вижу, что на нем в основном 2д-игрули делают.
Подскажите, потянет ли он фпс с графикой уровня второй халвы? С модельками врагов, а не растровыми картинками, как во втором думе, и большими 3д-уровнями на манер старых шутанов.
Godot-то потянет, а ты - потянешь делать 3D модели с анимациями на уровне HL2? Или ты думаешь, что раз движок потянет, то модели у тебя сами появятся? Вот поэтому многие и делают 2D вместо 3D - это проще в большинстве случаев, если ты не кинцо снимаешь и не чужие/ворованные ассеты флипаешь/слопаешь.
Рубрика лайфхаки
>а лучше как в котлине сделать функцию TODO() которая бросает исключение если забыл имплементировать
Исключений и глобальных функций нет, но можно сделать что типа как на пикчах."xx" это глобальный синглтон, по совместительству сервис-локатор, не спрашивайте почему "xx"
Хм, демка выглядит красиво. Значит, с графикой проблем нет. А как насчет масштаба уровней халвы или кваки? Мешей врагов со своими поведенческими скриптами?
>>1102923
>а ты - потянешь делать 3D модели с анимациями на уровне HL2?
За кого ты меня принимаешь, за профессионала, что ли?!Нет, конечно! Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
С чего ты решил что вообще могут быть проблемы?
Тебе сказали большинство делает 2Д - потому что это реалистично и достижимо, а не потому что это потолок движка.
У тебя не потянет графику 2004 года, если у тебя будет компьютер 2000 года.
>А как насчет масштаба уровней халвы или кваки?
Понятия не имею, какие там масштабы. Но если взять, к примеру, GTA 5 или даже GTA SA (оригинал, не переиздание) - чтобы повторить такое на Godot, придётся попотеть со скриптами загрузки-выгрузки чанков карты, потому что из коробки этого механизма нет. Также, хотя в движке есть "auto LOD" (генерирует сразу несколько промежуточных мешей низкого разрешения при импорте меша из gltf формата и автоматически их использует), возможно, тебе придётся вручную настраивать LODы таких вещей, как группа деревьев в лесу или группа соседних зданий. И, конечно, спавн-деспавн машинок и человечков - полностью на тебе, Godot только крутит то, что ты заспавнил, даже если ты заспавнил это за миллионы километров от камеры и игрок этого не видит. На счёт системы оклюдеров у меня большие вопросы, т.к. ещё во времена Godot 3 я их мельком пощупал и не смог разобраться, а в Godot 4 они что-то другое прикрутили... вроде бы. А оклюдеры нужны, чтобы, например, скрывать то, что находится за большим домом или за высоким холмом. Вроде бы разрабы обещали сделать так, чтоб оно автоматически работало, но я не разобрался, как это проверить...
Вкратце - сделать на Godot можно хоть GTA 5 при желании, но потребуется попотеть над своим кодом.
>Мешей врагов со своими поведенческими скриптами?
На счёт мешей - в Godot все анимации Skeleton3D пока что происходят только на CPU, поэтому большое число персонажей с анимациями упрётся в предел одного ядра CPU. В "больших" играх/движках данную проблему решают так: запекают анимации в текстуры и воспроизводят их специальным шейдером на GPU, что даёт им какое-то преимущество, особенно с толпой одинаковых внешне зомби или типа того. На Godot подобную оптимизацию тоже можно провернуть, но придётся делать своё решение или искать какой-то аддон.
На счёт скриптов поведения - всё зависит только от тебя. Есть несколько рекомендаций: не использовать _process (только _physics_process и только для движения); не опрашивать ничего из скрипта моба, а ждать сигнала/команды извне; группировать мобов и рассылать команды по одной группе за кадр, чтобы они принимали решения сообща, но размазывали нагрузку от своего думанья на несколько кадров. В общем и целом, для типичного 3D шутера можешь не беспокоиться о нагрузке от скриптов поведения.
Также стоит упомянуть, что если твои мобы будут на основе CharacterBody3D, это может оказаться сильно затратнее, чем на основе RigidBody3D и тем более Area3D, особенно если мобы начнут где-нибудь толпиться (move_and_slide делает кучу лишних проверок коллизий, а проверки коллизий дороже всего там, где много скопившихся физических тел). Но если не делаешь симулятор толпы со 150+ человек в одном месте для древних компов - думаю, можешь не волноваться по этому поводу. Графика начнёт проседать раньше.
>Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
Если будешь регулярно этим заниматься, то со временем начнёт получаться всё лучше и лучше. А там поди уже Godot 5.0 выйдет и всё будет хорошо... а твоя игра всё так же на стадии препродакшен-прототипов... Главное - не сидеть и ждать Godot, а делать что-то своими руками и ждать Godot. Смотри не перепутай!
>не опрашивать ничего из скрипта моба
Почему? Не ну опрашивать из скрипта моба это понятно (не та компетенция), я имею ввиду ты думаешь в каком-нибудь менеджеры в процессах операция вида "if flag:" будут дорогими (если типизирован flag)?
Там скорее будет адок операторов ветвлений, но по производительности это не будет дорогим.
У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры. Поэтому я когда увидел как пчел делает стрельбу на таймере - прифигел от такой вольности (может себе позволить).
Вообще, из-за того что мы постоянно крутимся в loop'е, отстрелить себе что-то намного проще чем в каком-нибудь бэкенде. Так же легко можно забыть какие-то пули удалить или партиклы. Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать?? Так же очень легко можно зациклить объекты. А пошаговое удаление массива с начала списка вообще тренд в примерах годота.
В общем, ньюфагу не о том надо переживать, он и без движка себе проблем создаст. А если вайбкодя то и смысла нет, его сам код уже не интересует, у него уже будущее.
>Почему?
Потому что гугли обзоры говнокода YandereDev.
Если у тебя в коде такая портянка:
>class_name Student extends CharacterBody3D
>func _process(delta: float) -> void:
>_ if Global.time == TIME_FOR_BREAKFAST:
>_ _ move_to(kitchen)
>_ if Global.time == TIME_FOR_CLASSROOM:
>_ _ move_to(classroom)
>_ if ...
То ты, скорее всего, не почувствуешь никакой проблемы, пока у тебя только 1 NPC это делает. Но если у тебя 50 NPC, то они все будут выполнять эти инструкции "одновременно" (на самом деле последовательно, но не суть), каждый кадр дёргая какой-то глобальный таймер и проверяя, не пора ли им кушать или идти делать уроки. И это всё накладывается друг на друга и быстро тормозит игру... особенно если у тебя подобным обмазана каждая игровая механика.
Тебе, наверное, кажется это очевидным и глупым, но некоторые (вроде YandereDev) годами пишут такие портянки говнокода и порой даже получают тысячи долларов в месяц за эту работу. Пока их код не сольют и не начнут высмеивать.
>У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры
Это всё где-то под капотом на C++ зарыто и, вполне возможно, опирается на API операционки.
Но в любом случае, такой код:
>func _on_breakfast_timer_timeout() -> void:
>_ move_to(kitchen)
>func _on_classroom_timer_timeout() -> void:
>_ move_to(classroom)
Будет в тысячи раз эффективнее. Потому что тут у тебя всего 2 таймера хоть на 100, хоть на 100500 учеников в школе, и просадка частоты кадров будет заметна только когда вся эта толпа ринется в столовку или в класс, а не буквально каждый кадр всё время работы игры. А чтобы избежать резкой просадки в данном случае - делишь школоту на группы и раздаёшь им приказы не сразу, а постепенно, чтоб выдвигались человек по 10 за кадр максимум. Тогда частота кадров и высокая, и стабильная, без скачков.
>Так же легко можно забыть какие-то пули удалить или партиклы
Просто выводи на экран количество node/object и отдельно orphan nodes:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Тогда легко заметишь "утечку памяти" до того, как переполнится RAM.
В профайлере эта инфа тоже есть, но его отдельно открывать надо...
>Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать??
Если на C# - то лучше пулл, если на GDScript/C++ - то разницы мало. Пулл для пуль и прочих эффектов - это пошло с Unity и C#, потому что у C# сборка мусора с задержкой, и если ты настреляешь миллион пуль, сборщик мусора может затормозить игру до неиграбельного состояния, пока не найдёт и не уничтожит все висящие в памяти ненужные пули. Поэтому на C# пулл - маст хэв, а на нормальных языках нагрузка от удаления и пересоздания объектов не такая большая, так что можно не париться...
Но тут есть маленький нюанс... Godot автоматически удаляет ненужные ресурсы, поэтому с таким кодом:
>var explosion: PackedScene
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn")
>func explode() -> void:
>_ add_child(scene.instantiate())
Ты можешь заметить (особенно на слабом ПК), что это иногда вызывает задержку, в отличие от такого:
>var explosion: Node
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn").instantiate()
>func explode() -> void:
>_ add_child(scene.duplicate())
Что задержки не вызывает. По-моему, это связано с каким-то ресурсом в системе частиц или шейдеров. В первом варианте кода, происходит удаление не только нод сцены, но и связанных ресурсов, которые используются всеми нодами-клонами этой сцены. То есть, если ты создашь 10 взрывов одновременно, задержки не будет, а если ты создаешь взрыв, дождёшься его удаления, и потом снова создашь, то будет задержка, потому что все ресурсы удалились. Второй вариант кода сохраняет ссылку на образец сцены, которая удерживает в RAM все связанные с ней ресурсы, поэтому взрыв происходит без задержек в любом случае. Я это обнаружил чисто опытным путём - долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
>пошаговое удаление массива с начала списка
Где ты такое видел? Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры - выяснили, что оптимальнее всего развернуть массив задом наперёд через reverse() и удалять с конца, а потом снова сделать reverse(), если тебе обязательно нужно удалить несколько элементов из головы и сохранить порядок. Но, если у тебя очень маленький массив и удаления случаются относительно редко - пофиг вообще, делай так, как будет понятнее в будущем, когда будешь код читать. Как говорится, "преждевременная оптимизация - корень всех зол" или как там... Просто некоторые вещи - это даже не оптимизация, а логичный способ делать вещи (как в случае с таймером, который сигналит школьникам, а не школьники смотрят на часы).
>из-за того что мы постоянно крутимся в loop
Все компьютерные программы с каким-то интерактивным интерфейсом (GUI и некоторые CLI) "крутятся в loop" в том или ином виде. Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс, а игровое приложение каждые <16 мс гоняет различные симуляции, анимации и прочие тяжёлые вещи, помимо стандартного ожидания событий от операционки. Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Кстати, Godot имеет настройки проекта для оптимизации работы движка под GUI-приложение.
>ньюфагу не о том надо переживать, он и без движка себе проблем создаст
Хочешь больше ньюфагов уровня YandereDev, чтоб движок считали медленным? Если вопрос про скрипты - надо предупредить...
>гугли обзоры говнокода YandereDev
А, не гугли, там ничего полезного. Я и сам не смотрел их, лол, только картинки-мемы листал в своё время. Но вот этот мем с опросом общего таймера каждым школьником каждый кадр пробивает на смешок уже сколько, лет шесть?.. Не делайте так...
TL;DR: оптимизация алгоритма >>>> оптимизация языка/интерпретатора/компилятора.
Ну
if Global.time == TIME_FOR_BREAKFAST:
Смотри у тебя было реально там 10 юнитов и ты не чувствовал проблему. А потом делаешь следующую игру - у тебя 150 юнитов и ты ощущаешь лаг в моменте. Только теперь это стало плохим решением. Но это решение все еще масштабируется. Ты заводишь условный Баланс-менеджер в котором есть информация кто и как должен распределиться и получается следующий код (это плохой код, просто показываю следующий возможный шаг)
if BalanceManager.canExecute(self, status, delta)
Но важно - лаг возникает не из-за проверок if...else, и от BalanceManager, которые сложнее (там хэшмапа и пару if...else - это все еще быстро), а возникает именно из-за задачи, которую они будут выполнять.
То есть, сигналы тут практичнее, но проблема то в том, что сейчас в один момент у тебя будет 150 поисков пути! Вот где закрадывается проблема, сигналы не как не решают саму проблему, а даже немного скрывают (потому что логика начинает размазываться по сигналами и если сразу же будут еще сигналы или их очень много это будет почти GOTO лапша).
В то время ты раз написал балансировщик и не паришься.
_ready()
# Очень легкое каждый тик (обычно тик равен 60/секунду)
__TickManager.registerOneTick(self, liteTaskMethod)
# Что-то потяжелее, каждые 250 тиков (~4,16 сек)
__TickManager.registerTick250(self, rareTaskMethod)
# Очень редко, например рост растений, проверка гниения раз 2000 тиков (~33 сек)
__TickManager.registerTick2000(self, longTaskMethod)
Это, кстати, тики из римки, я бы сделал кратное "60" (240, 2400), но кто поймет гения.
Все, теперь проблемы вообще нет, мы регистрируем методы куда нужно, например делаем Tick60 (раз в секунду) для поиска пути и просто закидываем метод в тик менеджер. Надо учесть что внутри тик менеджер не просто складывает все в мапу, он еще делает смешение по времени, чтобы тот же Tick60 не запустил все таски в конце секунды, а тоже размазал по времени.
Можно пойти дальше, ты можешь даже регистрировать насколько сейчас перегружена игра и что-то распределять по другому, но главное это уже проблема твоего тик менеджера, а не логики юнита (конечно твоя проблема, мы просто делегировали проблему другому модулю, но если там написано хорошо, то ты уже не думаешь об этом так глубоко, теперь тебе надо только раскидать по таскам твои активные методы).
В общем, есть такая проблема в разработке называется "преждевременная оптимизация корень всех зол" (гуглится, кому надо), программисты очень часто оптимизируют там где проблемы не было, буквально тратят тонну ресурсов/времени экономия на спичках, когда узкое горлышко видно только через профайлер/замеры, так что вариант
if Global.time == TIME_FOR_BREAKFAST
Не говнокод, это просто решение для простой задачи - тут не нужно абстракций (сигналы, менеджера) если не нужно оптимизаций. Главное что этот код проще сопровождать.
>TickManager.registerTick2000(self, longTaskMethod)
Но это то же самое, что и "сигналы"...
Смысл же в том, что _process() выполняется каждый кадр - если игра рендерит 100 кадров в секунду, тогда _process() вызывается 100 раз за секунду у каждой ноды, а если у нас 100 нод - это уже 10 тысячи _process() в секунду. Если ты 10 тысяч раз в секунду делаешь какую-то БЕССМЫСЛЕННУЮ проверку, то это всё будет складываться и уже не будет "экономией на спичках", нет? Ведь даже если одна проверка происходит за 0.0001 мс, то 10 тысяч таких проверок - это уже +1 мс к твоему времени кадра, а это много. А твой TickManager делает эту проверку 1 раз за 2000 тиков для ВСЕХ нод, которые у него зарегистрировались, и только когда эта проверка срабатывает, только тогда он передаёт им команду выполнить что-то, что им нужно выполнять раз в 2000 тиков.
Также нужно помнить, что в Godot даже пустой _process() нагружает движок, и лучше делать set_process(false), если ты зачем-то объявил _process() в своём коде, но не используешь его 99% времени. Конечно, это начинает проявлять себя только когда у тебя достаточно много таких нод, но всё равно стоит иметь в виду.
А то накодят такого, а потом "ваш недопитон слишком медленный"...
>долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
Ну вот как-будто для чего-то частого захочется написать один раз какой-то пулл который бы имел в запасе n-объектов, а если надо расширялся (сохраняя размер, или если надо сжимался обратно). Подсчет ссылок тоже прям не совсем дешевый, лишний раз аллоцировать тоже не хочется
> Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры
Да, потому что как раз аллоцируется новый массив каждый раз. Такое лучше не замерять, а один раз прочитать про "Сложность алгоритмов", на хабре вроде была хорошая статья.
>реверс
Я для поиска пути хранил индекс не трогая массив вообще. Позже это еще оказалось удачным решением, потому что в нескольких алгоритмов требовалось посмотреть на предыдущий гекс. Это чем-то напоминает работу с seek в файловом дескрипторе, где как-будто катаешься туда-сюда по магнитной ленте (я не такой старый)
>Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс
Это не так, иначе проц улетал бы. Там устроенно на прерываниях. Все буквально спят.
Вот интересно глянуть как устроен таймер в годот.
>Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Да он крутиться в цикле, но "зависает" на методе ожидающий результата прерывания (от сетевой карты), поэтому в простое ничего не жрет вообще.
Это чем-то напоминает ожидания сигнала на await - корутина просто спит. Спящих 100.000 корутин не должны грузить никак (пока не придет сигнал).
>Хочешь больше ньюфагов уровня YandereDev
Я иногда намеренно пишу простой код (который по совместительству говнокод). Сопровождение кода важнее понтов (принципы KISS и YAGNI).
>Но это то же самое, что и "сигналы"...
Да это фактически регистрация хендлеров у системный ивентов.
Только тут вся логика нагрузки и распределения в одном месте, а не в сигналах.
>>1103034
>Смысл же в том, что _process() выполняется каждый кадр
Вот, как раз тики и нужны, у них своя частота (TPS), прям как у _physics_process свои тики. То есть, при 144Hz у тебя все равно будет 60 TPS на секунду.
Я как-то тут ныл что хочу переписать тикменеджер на С++, но надо тестить, как-будто я могу получить нефига. if...else там должны занимать наносекунды - вы
>>1103034
>Также нужно помнить, что в Godot даже пустой _process() нагружает движок, и лучше делать set_process(false),
Насколько я помню, если ты не имплементировал в скрипте виртуальный метод _process - движок сам исключит его.
Да, вызов функции дороже условия if в 10 раз. А разница между if и emit'ом в 60раз!
Но чел, это наносекунды, не парься за эту хрень. Один блядский пасфаендер убьет все твои милларды Ifов и миллионы сигналов (утрирую, но могу показать как его колбасит на картах 250х250).
У тебя когнитивное искажение по поводу производительности (без агрессии). Операторы трогать вообще не нужно, надо только думать об аллокациях, обычно проблема в этом.
Я тоже когда-то все замерял в пхп, до сих пор помню, что
variable++
obj->variable++
7 раз медленнее (тоже наносекунды там). Но какая в этом разница, когда мы суммарно на БД висим и спим 100мс. Хоть раст или С++ принеси туда, все равно спишь на вводе/выводе больше время или пинге. ну это я уже о своем наныл, просто не нужно "экономить на спичках".
>вводе/выводе больше время или пинге
пинг тоже i/o - но кому не пофиг
Я не нашел ту старую классную табличку с восприятием времени. Но примерно/
Если представить что 1 наносекунда это 1 секунда.
То операция if занимала бы 5 секунд. Доступ к памяти почти две минуты. То есть, прочитать из памяти дороже операции if (и арифметики) в ~20раз!
Доступ к жесткому диску (HDD) вообще две недели.
А одна секунда времени было бы 31,7 лет
PS поиск пути в 62000 клеток от края до края на сложной местности занял бы 231 день. А ты переживаешь за 5 секунд if bool
>PS поиск пути в 62000 клеток от края до края на сложной местности занял бы 231 день.
Я наврал, я перепутал 2,3 дня.
В общем, самое интересное, что 1 кадр в 0.016 - это 193 дней
>Ведь даже если одна проверка происходит за 0.0001 мс, то 10 тысяч таких проверок - это уже +1 мс к твоему времени кадра, а это много
Ты бы ужаснулся, но каждый кадр там перебираться все хендлеры! Это можно сделать в будущем лучше, но на этапе прототипа это копейки. Заметь, мы можем менять и перестраивать тик менеджер, переписать даже на С++ (сделать разные и сравнить), но игровая логика уже никак не будет меняться, в этом сила сервисов/менеджера, мы инкапсулируем кишки, получая поверх API которое не будет меняться (но можно заменить алгоритмы).
Кстати, если предать усилия - можно сделать копию римки, которая не будет так сильно лагать. Прикинь, школота бв в движкосрачнике прифигела и бегала - мол, около-клон на годоте работает лучше чем на U (мне думается, можно получить на порядок)! Но мы то будем знать, что вся заслуга в оптимизации и алгоритмах.
И я не знаю почему у меня в игровых сутках 36 часов, кто знает о чем думал тот человек полгода назад. o_0
>>1103102
Мы уже праздновали в движкосрачнике.
Живите с этим. но лучше используйте git
>софтлинки? хардлинки?
Junction Point
Честно говоря впервые использую ссылки на винде, тут они немного другие.
Git - Submodules будут практичнее, но пока прототипы не заслужили место на гите.
>для чего-то частого захочется написать один раз какой-то пулл
Недостаток приёма с "пуллом" в том, что тебе придётся постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию, иначе могут появиться неприятные баги, которые трудно заметить и поймать. А если ты каждый раз создаёшь новый объект (или дублируешь объект-прототип), то все параметры гарантированно будут в состоянии по умолчанию, и тебе не придётся ручками куда-то записывать вещи типа "value = default_value".
>как раз аллоцируется новый массив каждый раз
Вообще-то, удаление элементов с начала массива приводит к циклу for, который пробегается по всей длине массива и переносит значения элементов на -1 назад, а потом длина массива сокращается на -1. Поэтому, чем твой массив длиннее, тем более затратно удаления с начала массива. Никакой новой аллокации не происходит - массив остаётся на своём месте в памяти. Уж не знаю, почему нельзя перенести указатель начала массива на +1, уменьшив длину на -1.
>Там устроенно на прерываниях. Все буквально спят.
Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
>>1103037
Зачем ты галлюцинации нейроночные постишь? Сам замерь, если так надо.
>>1103039
>А ты переживаешь за 5 секунд if bool
Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
И откуда этот bool берётся? Может, там целая матрёшка запросов куда-то.
>>1103120
>можем менять и перестраивать тик менеджер
Это всё просто прекрасно, а что с игрой? Где игра?
>>1103149
Зачем всё это? Игры делаются и без этого.
По-хорошему, Godot давно нужна локальная библиотека аддонов, чтобы юзер мог сваливать все свои аддоны в одну папку вне папки текущего проекта, а в настройках проекта подключать нужные аддоны одной галочкой, и чтобы они не копировались никуда, а оставались в библиотеке. Если в локальной аддона нет - он скачивается из интернета. Ну и, разумеется, в настройках проекта указывается версия аддона, если обновляться до актуальной почему-то не выходит.
>Уж не знаю, почему нельзя перенести указатель начала массива...
А, понял. Указатель на начало массива может храниться в разных местах программы, и если бы мы сдвинули начало в сторону, то все эти разные места программы больше не ссылались бы на начало массива, и в лучшем случае был бы EAV, а в худшем - ошибка в вычислениях, которую трудно найти. Этого всего можно было бы избежать, обернув массив в объект-обёртку, который находится в одном месте памяти, тогда как начало массива плавает в памяти, но тогда каждый запрос к данным массива вызывал бы не один, а два перехода по памяти, и в общем случае это было бы хуже, чем однократное копирование всех элементов в на ячейку влево... С удалением элементов с конца массива такой проблемы нет, потому что сокращение длины не влияет на указатель начала.
>постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию
Это его основная задача.
if ! has_method("restore"):
....push_error("Ты что в меня суешь?!")
>>1103195
>удаление элементов с начала массива
Не знаю как там сделано, но с базовыми алгоритмами лучше не мудрить (наверное сдвиг правда будет чаще чем релокация, я тут тупанул).
Но вообще для таких штук специально придумали слайсы.
>>1103195
>Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
Не знаю что под этим подразумевают - может как раз это про таймеры? Но в ОС буквально спят - то есть не просыпаются вообще, пока не придет прерывание/сигнал.
>>1103195
>Зачем ты галлюцинации нейроночные постишь?
Там приблизительно, но реальность где-то такая есть. Типизированный if очень быстрый (если не дернет ОЗУ) это одна дешевая инструкция.
>Сам замерь, если так надо.
Чтобы честно замерять нанохерню, нужен тулинг типа System.nanoTime(), нужно 100К запусков и все равно шум от ОС насрет. То есть, это настолько фигня что трудно даже замерить.
>Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
Если я сейчас каждую секунду буду создавать в коде if мне понадобиться
миллиардах - 31 год (если я начну сегодня, то я на вряд ли успею до конца жизни)
триллионах - 31709 лет (оставим это бессмертным Архонтам).
Нужно где-то больше 60 вызовов if чтобы они сравнились с одним сигналом.
Может даже больше, мы в динамическом языке, а тут сплошные "прыжки" по указателям в памяти.. В общем, не там ты экономишь. Это не говорит что сигналы тяжелые, это говорит что if безумно легкий, как 1+1.
>И откуда этот bool берётся?
; 1. Загружаем bool из памяти в 8-битный регистр AL
mov al, [condition]
; 2. Проверяем значение (логическое "И" само на себя)
test al, al
Дальше прыжки по веткам, местная GOTO радость.
>>1103195
>Это всё просто прекрасно, а что с игрой? Где игра?
Я увидел как играют другие - и понял что я не смогу конкурировать с таким числом модов.
Это буквально конструктор как скайрим.
Я наигрался в римку и понял насколько она унылое говно и два раза развести так людей не получится.
Я увидел dwarf fortress и song of six и понял что переизобретаю их.
Я свичнулся на другой проект на котором вообще выгорел (там и идеи говно и я говно).
>Зачем всё это? Игры делаются и без этого.
Я затрахался синхронизировать накопившийся общий код из разных проектов.
Надо это как-то говнокод унифицировать.
>По-хорошему, Godot давно нужна локальная библиотека аддонов
Нужно, а еще нужны неймспейсы, чтобы твои адонны с моими классами не пересекались.
Причём, нужна не просто обычная скелетная анимация, а обманка через шейдер.
Простое изменение масштаба вершин с позиции ноды и до той где она должна быть это понятно, но всрато.
Читал про VAT, но для дерева, у которого больше 4к вершин это не подойдёт вроде как. (Да и даже если бы и подошло, представим десятки разных видов деревьев...для каждого запекать vat это пиздец, памяти пздц съест).
Была идея как-то мутить через uv2, но чёт пока не допетрю как это сделать.
Короче, кто-то такое трогал?
ИРЛ растения так растут, что даже если ты сознательно пытаешься контролировать их рост, это происходит как-то так: никаких изменений... никаких изменений... никаких изменений... стоп, а это откуда появилось, да уже большое?!.. Поэтому просто возьми несколько разных мешей-"стадий роста" и подменяй их друг на друга, пока игрок отвернулся от растения в сторону.
Для мультяшных симуляторов фермы (клоны Harvest Moon) часто практикуют анимацию scale через Tween, опционально - с кучей вылетающих из растения частиц-блёсток, особенно когда растение достигло стадии сбора продуктов. Короче, импровизируй.
Или ты хочешь симулятор тех видосиков "ускоренная съёмка роста"?
любитель растить всякое на подоконниках
Однажды он появится и принесёт релиз.
Зря мозги ебешь. Я бы просто твинил их по-кусочкам, или даже целиком если лень.
Именно как ускоренная съёмка. Я пару месяцев назад натыкался на пост, сук не помню на реддите или на годотских форумах, и найти нихуя не получается. Там чувак сделал типо роста цветков. Но там по сути uv2 мапа, где по оси y - когда вершина начинает расти (и все что на ней, назовем веткой хуй знает) а по x откладываешь вершины в порядке, собственно, роста этих "веток". Вроде и по логике работы все правильно, но с деревьями такое не прокатит, т.к. руками это делать - ёбнешься в край...можно конечно в том же блендере какой нить скрипт написать попробовать...хуй знает короче
И опять же, не получится полноценного роста. Будет появление вершин из бездны в нужную позицию. А в жизни ж как, вот веточка растёт, а будущие листья следуют за ней со своими местами роста.
Пробовал в параметр vertex color закодировать удалённость узла ветки от основания дерева? Если я правильно тебя понял - нужно раскрасить меш так, чтобы основание дерева было чёрным, а кончики веточек наверху - белыми. И вот этот градиент снизу вверх в шейдере использовать для scale = 0, чтоб разворачивать дерево в обратном порядке... Правильно понимаю?..
А о чём твоя игра? Это ты недавно что-то писал про то, что у тебя всего 1 дерево на всю игру? Если твоя игра подразумевает реиграбельность, то не лучше ли генерировать дерево процедурно из кода, и из кода же анимировать его рост, чтобы у каждого игрока/каждую новую игру выростало какое-то по-настоящему уникальное дерево, а не заготовленный тобой заранее ассет?
Сгенерировать дерево из кода относительно несложно, если нужно только одно (не нужна оптимизация).
Раньше были яндекс/гугл диски и прочие облака. Суть - ставишь ПО, а файлы синхронизуются между пеками (возможно и телефонами).
Так же есть софт без облаков. Гугли.
Вы не поверите, но есть секретная техника: подключение смартфона к ПК... по USB! Как флешку!!! Круто, правда?!!
Я просто уже перестал им пытаться что-то обьяснить. Пусть ебутся как хотят.
кидай по вифи тогда
я как-то от нехуй делать запускал квейк 2 по локалке между пк, ретро-ноутом, смартом и псп
>Я просто уже перестал им пытаться что-то обьяснить.
Мы все равно тебя любим.
Ну, vertex color у меня занят под ветер. Может быть и решу избавиться и сделаю ветер по-другому. И градиент если делать, то всё равно не получится никак контролировать pivot point'ы откуда ветки и листья растут. Да, вершины будут масштабироваться с разной скоростью, но либо от самих себя, либо от позиции ноды, других данных у тебя нет.
Да, я тот чел с деревом. То дерево одно, да, эти же просто деревья.
>Сгенерировать дерево из кода относительно несложно
Сколько не смотрел попытки всяких тытруберов, разного рода генераторы, чёт всё всегда какое-то всратое получается.
Да, дерево это один меш если что.
Так то, проблема pivot точек роста решается, если каждая ветка будет отдельным мешем со своим пивотом. И потом, когда дерево выросло - меняем на то где один меш.
Конечно, если у веток кроме листьев есть ещё и подветки, то тогда тоже получается костыль (ветка со всеми подветками и листьями будет масштабироваться одинаково).
Может быть компьют шейдером? У самого в планах что-то похожее на VAT, но детали не продумывал. Точнее, в VAT бы просто хранилась сама структура/иерархия ветвей. Можно подсмотреть как у других делается (procedural vegetable editor например)
А вот ветер, кмк, как раз делать проще считая на лету в глобальном пространстве просто передавая вектор ветра.
Боюсь этих ваших компьют шейдеров, да и вообще, ну ебаный в рот, это же не симуляция эрозии какая-нибудь, попроще ж должно быть...это ж рост...ну ё моё.
А насчёт ветра, да я подумывал попроще сделать.
>Я увидел как играют другие
Где, на ютубе/твиче/обсуждениях реддит? У любой популярной игры основная аудитория - это казуалы, которые поиграют от силы 10-100 часов в ваниллу и забрасывают игру. Никакие моды им не нужны. Все модификации создают задроты для задротов, что надрачивают 5000+ часов с каким-то порномодом, ломающим баланс ради какой-то ненужной фигни, и наверняка тебе не понять, почему они это делают (порнографии и так больше, чем когда-либо было необходимо, зачем ещё и в игры это тащить?).
>Это буквально конструктор как скайрим
Опять же, большинство игроков в скайрим - казуалы, забросившие его через месяц после релиза. Все эти модификации с фурри-модельками и сексом юзает небольшая горстка задротов, у которых своё мелкое сообщество, и они - не твоя аудитория. Если казуалы попробовали скайрим и двинулись дальше, то они же попробуют твою игру и двинутся дальше. А вот если задротам понравилось дрочить на скайрим, то они, естественно, так и останутся дрочить в скайриме - не запретят же им это делать, верно? То есть они осели в скайриме и больше в другие игры не поиграют.
>два раза развести так людей не получится
А ты не пытайся "развести людей". Если бы ты хотел "разводить людей", то занимался бы стандартным ассетфлиперством: накачал бесплатных ассетов, сваливаешь всё в кучу, наклеиваешь какой-то очень популярный в этом месяце мем и забрасываешь в маркетплейсы. Вот сейчас этот мем с колобком - не понимаю, чего его обсуждают, но ты бы мог всего за несколько дней слепить игру про колобка и засрать несколькими вариантами кучу площадок. Вот люди пытаются гуглить колобка - а там твоя игра. Развод! Множество геймдевов-ассетфлиперов-слоповиков перебиваются так десятилетиями, кто-то даже свои компании создаёт, как тот же Фалько. Почему ты не занимаешься таким, если мечтаешь "разводить"?
Поэтому не стремись "развести людей" - это не твоё.
>всё всегда какое-то всратое получается
Реальные растения тоже "всратые". Кора деревьев трескается, потому что это мёртвые "чешуйки кожи", остающиеся на поверхности растущей ткани. Но и внутренности ствола - тоже мёртвые; живая только прослойка между корой и сердцевиной; если она повреждается - часть дерева выше тупо отмирает. Заложенные ростовые почки могут мутировать и превратиться в отвратный нарост с кучей веточек. Нормальные листья формируются, только если их совершенно ничего не касается, иначе - уродцы. Все растения следят за окружающей средой, вырастая изнеженными уродцами без раздражителей или карликовыми уродцами с раздражителями. Если два растения одного вида растут достаточно близко - то срастаются во одно, наподобие сиамских близнецов. Многие растения агрессивно сопротивляются другим видам, буквально душат друг друга корнями. А также множество паразитов/травоядных животных всё это усугубляют. Поэтому растения по умолчанию растут всратыми уродцами, это их нормальное состояние.
Поэтому самое "всратое" в генераторах растений - избыточная симметрия/равномерность/точность вычисленных позиций/углов, однородность текстур. Добавляешь побольше хаоса, побольше рандомных искажений от базовой формулы-"ДНК" растения - и получатся прекрасные уродцы, прямо как в жизни.
>Поэтому самое "всратое" в генераторах растений - избыточная симметрия/равномерность
Ну да, это и имел ввиду, слишком "паттерно" чтоли. Кстати, как вообще работают сохранения в играх, где всё генератором делается? Допустим у тебя каждое дерево уникально, а их сотни или больше. Ведь не станешь все это дело как-то хранить? Или они сиды генератора сохраняют и при загрузке перегенирируют?