Шапка: 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 направления, атака и дамаг, но при этом без генерации, как-то неполноценно чтоли будет. По крайне мере я привязываюсь больше именно к фигуркам, а не аватаркам
А так задумка интересная, но тут да, нужно сесть и рисовать.
Все просто ебанулись на симуляторах ларьков, остановитесь
Ещё я охуел от того, сколько РТС сейчас выходит, обновляется или в разработке, но это богоудоное дело, продолжайте