25 юзеров мобильной игры в гугл-плее за месяц - хороший или плохой старт? Моя первая игра.
Ящитаю (с дивана) успешность игоры следует мерять по баблу. Сколько ты проел пока делал? Столько же ты должен отбить с продаж, чтобы выйти в ноль. Если вышел в ноль - это уже не фейл. Если же начинаешь идти в плюс - ты уже успешен.
Зависит от игры, схемы её монетизации, как и сколько ты вложил в маркетинг, кто эти юзеры, как много и как частно они реально играют, и т.д.
Давно уже есть способы повысить количество бабла заранее, подкрутив те или иные параметры, следя за графиками взаимодействия пользователя с игрой. Если ты просто сел и ждёшь, когда игра отобьёт тебе затраченные средства, ты, скорее всего, ничего от неё не дождёшься, потому что юзеры видят твой косяк и уходят, а ты об этом даже не догадываешься (в отзывах тебе никто формулу успеха писать не будет, скорее наоборот).
Но это надо конкретно маркетинг изучать. Я только поверхностно термины слышал, в тему не углублялся, поскольку не планирую зарабатывать.
У самих-то хуй да нихуя.
ПЕРЕКАТИЛСЯ
Забубца.
Вообще-то такое ИРЛ существует...
https://en.wikipedia.org/wiki/Road_train
Рекорды до 120 прицепов доходят.
Не спи за рулём!
Где взять копирайт-фри фоновую музыку, автор которой не взорвется жопной болью если я получу 5 копеек с игры, в которую воткну его музыку?
Ищи музыку под лицензией CC BY, но без дополнительных условий ND, NC, SA.
Если кратко:
CC - множество лицензий для свободного контента.
BY - нужно указать автора используемого контента.
SA - это "заразная" версия, аналог GPL, копилефт.
NC - только некоммерческое использование.
ND - нельзя делать производные работы.
Для музыки игра будет производной работой, при этом ты хочешь заработать на игре, и вряд ли хочешь распространять игру под свободной лицензией. Следовательно, тебе подходит только CC BY.
Статья про видео, но подходит и играм:
https://creativecommons.org/about/program-areas/arts-culture/arts-culture-resources/legalmusicforvideos/
Где искать-то? На итче почти ничего.
Ты по ссылке не переходил?
>Where can I find CC-licensed music?
>Several sites offer music published under Creative Commons’ flexible copyright licenses. Here are some:
>ccMixter
>Free Music Archive
>Jamendo
>Magnatune
>Fugue Music
>BeatPick
>CASH Music
>SectionZ
>Opsound
>Podsafe Audio
>AudioFarm
>Internet Archive’s Netlabels Collection
(ссылки смотри сам в статье)
Хотел уже ответить что там говно одно, но нет, ок. Спасибо, братюнь.
Я хотел посоветовать тебе AI generated, но все сайты просят подписку за деньги.
Имхо, все равно нужно гуглить в том направлении.
>посоветовать тебе
Кому ты отвечаешь-то?
>AI generated
Если ты про нейронки, тут есть нюансы:
1. На чём тренировали нейронку? Может оказаться, что тренировали на несвободном контенте.
2. Даже если тренировали на свободном контенте, результат генерации может оказаться похож на несвободный. Где-то слышал, что для суда вроде достаточно совпадения нескольких нот.
3. Часто на контент от нейронки ставят различные ограничения, нужно читать соглашения и т.д.
4. США несколько месяцев назад установили закон, в соответствии с которым любой сгенерированный алгоритмами контент не подлежит копирайту, т.е. любой Васян/Джон имеет право рипнуть музыку из твоей игры и легально использовать в любых целях.
5. Из того, что я слушал - какая-то однородная мешанина без смысла. Белый шум и то интереснее.
>все сайты просят подписку за деньги
Конечно, ведь они предлагают использовать их серверные ресурсы. Хочешь бесплатно - качай к себе на компьютер, генерируй локально.
>нужно гуглить в том направлении
Быстрее загуглить как сочинять музыку и быстро состряпать несколько треков в опенсурсном редакторе музыки. Или закодить процедурный генератор, чтобы в игре на лету генерировать.
>любой Васян/Джон имеет право рипнуть музыку из твоей игры и легально использовать в любых целях.
Мне кажется, если такое даже и произойдёт, это будет сорт оф признание. Даже плюс. Дополнительная реклама игре.
>Или закодить процедурный генератор, чтобы в игре на лету генерировать.
Чёт вспомнился звуковой ряд Mini Metro. Самый годный пример, когда в игре вроде бы музыки нет, но она рождается из звучания игровых элементов. И вообще игра охуенная.
мимо поддержал разговор
>Кому ты отвечаешь-то?
Да не трясись ты, я понял
>любой сгенерированный алгоритмами контент не подлежит копирайту, т.е. любой Васян/Джон имеет право рипнуть музыку из твоей игры и легально использовать в любых целях.
похуй
>Из того, что я слушал - какая-то однородная мешанина без смысла
99% "эпичной" или амбиент музыки по типу hans zimmer или vengelis ну ладно, не бомби ты так, это утрированно
>Или закодить процедурный генератор, чтобы в игре на лету
сложновато для пользователя годот
>Дополнительная реклама игре.
Ещё бы генеративная музыка была достаточно узнаваемой, чтобы могла сделать рекламу игре...
>сложновато для пользователя годот
Что сложного? Конкретнее давай.
https://bitbucket.org/arlez80/godot-midi-player/wiki/how_to_use/procedural
>Ещё бы генеративная музыка была достаточно узнаваемой, чтобы могла сделать рекламу игре...
Вот поэтому никакой васян не будет её рипать, а пойдёт и на той же нейронке нагенерит ещё. А вот если бы музыка была достаточно интересная, чтобы её рипнуть, вот тогда это успех и халявная реклама.
Тебя уже разбанили? Еще хочешь?
Во первых я не он. Во вторых, я не могу выражать мнение потому что додик вроде тебя озлобился на что-то?
Шизик, если тут всех забанят, с кем ты общаться будешь? И так уже превратил gd в свой личный бложек, все от тебя разбежались, эффективный ты менеджер.
Делайте игры.
Привет, Анон. Подскажи, пожалуйста, почему у меня этот кусок кода работает не так, как я хочу? Точнее, что именно я не так делаю?
get_tree().get_nodes_in_group("detected") добавляет мне в массив узлы с группой, беру первый же узел по индексу и смотрю его родителя, всё норм. Но если я каждому элементу в массиве добавляю get_parent, мне выдает родителя всего древа узлов, в моём случае main. Скрипт прикреплен к узлу, у которого родитель main, получается он находит родителя узла со скриптом? Чет нихера не понимаю...
get_tree().get_nodes_in_group("detected") добавляет мне в массив узлы с группой, беру первый же узел по индексу и смотрю его родителя, всё норм. Но если я каждому элементу в массиве добавляю get_parent, мне выдает родителя всего древа узлов, в моём случае main. Скрипт прикреплен к узлу, у которого родитель main, получается он находит родителя узла со скриптом? Чет нихера не понимаю...
>Там набросали кучу объектов, которые надо купить для продолжения сюжета.
Большинство покупок на карте - это дома с гаражами и точками сохранения. При этом при принудительном перемещении в новую область игра обычно даёт бесплатную точку сохранения под открытым небом. Насколько я помню (давно играл), обязательна для сюжета покупка магазина RC игрушек, да вроде и всё. Может ещё аэродром, не помню уже. Короче, большую часть собственности ты покупаешь только чтобы не мотаться через весь город для сохранения прогресса, но рано или поздно деньги становится не на что тратить.
>А что было ранее я уже не помню.
В GTA 3 вроде под конец сюжета нужно 500к накопить. В GTA 1/2 переход в следующий город вроде платный, типа миллион собрать или что-то типа. Не помню, никогда не играл до конца по разным причинам.
>а я вместо того чтобы играть с этим ботаном, швырнул ему шахматы в еблину
GTA не соревновательная игра, у неё нет правил, которым должны подчиняться игроки в обязательном порядке, чтобы получать фан от игры. Этим GTA и отличилась от конкурентов. Вот в Mafia линейный сюжет, по которому тебя тащат за уши, а в "свободном режиме" заняться практически нечем, хотя концептуально игра очень похожа - город, машины, пешеходы, оружие, преступники, задания.
>Пиздюками мы все гоняли на маффынках от ментов с аснаёбом, и только повзрослев, узнавали, что там сюжет оказывается есть.
Ой, вот не надо. Про наличие сюжета я всегда знал, он просто не затягивал меня. И сейчас сюжет меня по-прежнему не особо интересует. Каждый раз удивляюсь, натыкаясь на серьёзные обсуждения персонажей ГТА и сюжета, как будто это не жёсткая сатира с околонулевой серьёзностью (кроме GTA IV, наверное?).
Намотал 1000 часов в приватных сессиях GTA Online и планирую заскочить ещё раз, заценить новые тачки и покататься на полюбившихся старых. Не нравится только принудительный мультиплеер и задания, на 90% состоящие из "сгоняй 10+ км по единственной трассе, которая не меняется годами, и по которой мы будем заставлять тебя ездить туда-сюда каждые полчаса на всевозможных грузовиках и убитых драндулетах, а единственное развлечение - пачка пуль тебе в жопу, радуйся давай".
Не юзай гет_парент. Это плохой стиль. Что тебе нужно от парента детектеда? Сделай парентам детектедов отдельную группу "паренты" и выводи её в список.
От парентов детектеда мне нужна позиция. А беру паренты потому что детектеды это ареа3д, и они попадая на другие ареа3д пускают сигнал.
>каждому элементу в массиве добавляю get_parent
Лол, ты из функциональщины пришёл?
https://docs.godotengine.org/en/3.5/classes/class_array.html#class-array-method-fill
>Assigns the given value to all elements in the array. This can typically be used together with resize to create an array with a given size and initialized elements
Разбираем по полочкам тобою написанное:
>detected.fill(get_parent())
1. Первым выполняется get_parent(). Поскольку ты не указал, чей get_parent() вызывать, интерпретатор считает, что имеется в виду self.get_parent().
2. Далее вызывается Array.fill(), которому передаётся единственный ответ self.get_parent().
3. Метод fill() просто заполняет массив одним и тем же значением, которое он получил в аргументах.
Если тебе нужно вызывать get_parent() на каждый элемент массива в функциональном стиле:
https://docs.godotengine.org/en/stable/classes/class_array.html#class-array-method-map
>Calls the provided Callable for each element in the array and returns a new array filled with values returned by the method.
>The callable's method should take one Variant parameter (the current array element) and can return any Variant.
Пример (будет работать только в Godot 4.0+):
>print(detected.map(func(node): node.get_parent()))
Это создаёт новый массив и передаёт его на вывод в консоль, если тебе нужно сохранить - делай так:
>detected = detected.map(func(node): node.get_parent())
Но в функциональных языках не принято мутировать переменные, т.е. тебе нужен новый массив:
>var parents := detected.map(func(node): node.get_parent()))
Вариант императивный, работает в Godot 3.x:
>for node in detected: print(node.get_parent())
Если нужно сохранить в массив:
>for j in detected.size(): detected[j] = detected[j].get_parent()
Или в отдельный массив:
>var parents: Array
>parents.resize(detected.size())
>for j in detected.size(): parents[j] = detected[j].get_parent()
>Это плохой стиль
Не вводи новичка в заблуждение, предков можно запрашивать. Реально плохо только абсолютные пути использовать, остальное по ситуации.
Ничего не понял. Что ты хочешь сделать? Я имею в виду геймплейно. Датчики можно настроить так, чтобы они не реагировали на другие датчики.
Годаны, подскажите. Есть ли в 3.5 возможность как-то автоматизированно составить список использованных в проекте модулей, чтобы пересобрать Годо для более оптимизированного экспорта? В четвёрке-то есть, а мне для тройки надо.
Спасибо за обширный ответ! Как вы такими умными становитесь? Мне нужно было наоборот, чтобы датчики на движущемся объекте реагировали на статичные датчики. Объект двигает только головой, но перемещается по точкам на локации (телепортируется). Но там такая тема, что у объекта есть три зоны наблюдения (3 area3d) - левая, центральная, правая. Попав в левую или правую зоны он единожды пускал луч (raycast3d), чтобы проверить на столкновение. Но в центральной зоне надо было обновлять рейкаст постоянно. Нахуй, уже сам запутался пока писал. Тема хуйня чую, можно по любому сделать как-то поумнее. Но моих мозгов хватает пока на такое.
>Как вы такими умными становитесь?
Годы прокрастинации и форумного вангования.
>уже сам запутался пока писал
Так ты опиши геймплей. Что у тебя за объект, где и зачем он движется? Тогда понятнее будет. Я пока не представляю себе, что там у тебя происходит. Какой-то трёхбашенный танчик или корабль? Это нужно для ИИ, чтобы он интеллектуально ехал?
>наоборот, чтобы датчики на движущемся объекте реагировали на статичные датчики.
1. У движущихся Area3D снимаешь галку monitorable, оставляя только галку monitoring. Тогда они не будут реагировать друг на друга.
2. У статичных Area3D снимаешь галку monitoring, оставляя только monitorable, тогда они вообще не будут ничего сигнались, но будут обнаружаться.
3. У CollisionObject3D есть специальные поля collision_layer и collision_mask, это позволяет распределить отношения между объектами без единой строчки кода, но слоёв всего лишь 32, учитывай это. Если кратко, layer - то, где объект физически существует, mask - то, что объект физически сканирует. Столкновение детектится только между объектами, у которых совпадает хотя бы одна галочка в layer и mask. Каждому слою можно присвоить текстовое имя через настройки проекта, это имя используется как подсказка в GUI редактора сцен (инспекторе нод). Как минимум рекомендую разграничить ландшафт, движущиеся объекты/транспорт, НПЦ и игрока, подбираемые предметы, всякие пульки и гильзы, и т.д.
>От парентов детектеда мне нужна позиция
Кстати, у Area3D ведь есть своя собственная позиция.
>Попав в левую или правую зоны он единожды пускал луч (raycast3d), чтобы проверить на столкновение. Но в центральной зоне надо было обновлять рейкаст постоянно.
Возможно, будет лучше просто плотный веер из рейкастов сделать. Если объект уникальный, а не толпой ходит. Я пробовал делать очень много рейкастов, несколько сотен точно можно постоянно обновлять без особых просадок производительности.
Самое главное в дизайне игровых объектов - делать их как можно более независимыми от всего остального. Это упрощает дизайн уровней и будущие правки, добавления контента и т.д.
...А эти боковые зоны случайно не уши? Типа услышал шум и повернулся в сторону посмотреть, кто шумит?
Просто любопытно, что ты делаешь.
Вот по локации раскиданы красные шестиугольники, это позиции на которые телепортируется объект, от которого исходят три треугольника. Точки - это сцены. Ну одна сцена, состоящая из MeshInstance3d > Area3d > CollisionShape3d. Когда в поле зрение объекта попадает Area3d из точки, в скрипте объекта запускается функция и генерирует рейкаст до этой точки. Поле зрения состоит из трех треугольников Area3d, чтобы я сигналом area_entered определял, что объект увидел точку. Но сама Area3d в точке имеет позицию 0, 0, 0. По этому я через area.get_parent() получал позицию родителя.
Первый рейкаст мне нужент только чтобы определить нет ли препятствия между объектом и точкой. Если нет препятствия, то объект может переместиться на точку. Созданный рейкаст удаляется, если покидает зону видимости. Но если точка входит в центальую зону видимости, то рейкаст начинает постоянно обновляться в _physics_process. Но я не придумал как мне обновлять сразу несколько рейкастов одновременно. У меня все созданые рейкасты добавляются в массив, берут имя той area3d которая задетектилась зоной видимости. И я думал буду доставать из массива только рейкасты которые создавались на точке detected. Ну как-то так. Надеюсь понятно объяснил. Навасянил конечно по полной, сам понимаю. Сильно не ругайтесь, я только четвертый день в этом варюсь, и потихоньку разбираюсь.
>сама Area3d в точке имеет позицию 0, 0, 0
Можно глобальную позицию определить. Но это применимо если все эти точки неподвижны, а не движутся на какой-то платформе.
В общем, у тебя вроде всё правильно выглядит. Хотя геймплейно всё равно непонятное что-то.
Я такой псевдокод представляю:
>func _on_area_entered(area):
>_ var pos = area.get_parent().position
>_ if is_visible_with_ray(pos): jump_on(pos)
Кто кого детектит настраиваешь через свойства.
>Но я не придумал как мне обновлять сразу несколько рейкастов одновременно. У меня все созданые рейкасты добавляются в массив, берут имя той area3d которая задетектилась зоной видимости. И я думал буду доставать из массива только рейкасты которые создавались на точке detected.
Эээ... зачем?
Ты же вот так лучи кидаешь?
https://docs.godotengine.org/en/stable/tutorials/physics/ray-casting.html#raycast-query
Нода RayCast3D нужна только если тебе нужно непрерывно пускать луч. Если нужна однократная проверка - вариант по ссылке выше лучше.
Конечно.
1. Чем больше у тебя лучей создано, тем медленнее будет поиск при создании нового луча.
2. Куча лишних настроек на каждый луч.
3. Добавление ноды в сцену. Нода-луч реально заработает только на следующем кадре.
4. Потом ты зачем-то вращаешь этот луч, хотя у него есть параметр target_position:
>ray.target_position = ray_cast_target.position
Короче, фигня какая-то. Нужно переделывать, но не конкретный код, а архитектуру игры. Задумку я примерно понял, но алгоритм слишком запутанный.
Скажи честно, ты сразу сел этот проект делать, не имея никакого орыта в геймдеве? Рекомендую отложить этот проект на потом, и пройти какие-то туториалы по более классическим идеям, вроде платформера и топдаун шутера. Геймдизайн сам по себе очень сложная штука, а тут ты ещё в коде не разбираешься толком. Алсо для начала лучше потренироваться на 2D, прежде чем нырять в 3D.
Спасибо. Ты безусловно прав и я уважаю тебя за тот труд, что ты проделал, дабы овладеть этими знаниями и опытом. Для меня такие люди - герои. Но я, к сожалению, не смогу неделями, месяцами мало-мальски изучать, разбираться во всем от простого к сложному. Я попробовал, думал получится попутно разбираться в том, что не понял. Но совершил много ошибок. Чтож, опыт в любом случае полезный. Всем удачи!
>Спасибо. Ты безусловно прав и я уважаю тебя за тот труд, что ты проделал, дабы овладеть этими знаниями и опытом. Для меня такие люди - герои.
Нет, я простой бездельник, который редко что-то реально делает. Получение знаний и опыта у меня происходило больше пятнадцати лет с перерывами, и мне ещё многое предстоит узнать, чтобы сделать мою игру мечты. Но если бы я не ленился и работал над чем-то нормально и непрерывно, давно бы уже сделал игру и, возможно, пришёл бы к успеху... я просто к нему не стремлюсь особо. Мне просто нравится ковыряться в коде, в редакторе сцен, делать какие-то интерактивные наброски, придумывать более-менее оптимальные решения, даже если я их потом никак использовать не буду... Так что я, похоже, произвёл ложное впечатление на тебя.
>Но я, к сожалению, не смогу неделями, месяцами мало-мальски изучать, разбираться во всем от простого к сложному. Я попробовал, думал получится попутно разбираться в том, что не понял. Но совершил много ошибок. Чтож, опыт в любом случае полезный.
Чего? Ты так легко сдаёшься? У тебя там рак в терминальной стадии, что тебе нужно поскорее чего-то достичь, чтобы успеть? Расскажи хоть, чего именно ты хочешь достичь и почему так торопишься. Может, тебе лучше заказать выполнение работы на фрилансе, чем изучать лично...
Касательно ошибок, в этом ничего особо страшного нет. Игры в целом состоят из говнокода, даже ААА, а индюшатина и подавно. Взять хотя бы Яндередева, который говнокодил и наверняка продолжает говнокодить уже много лет, но успешно стрижёт бабло с фанатов, потому что его игра даже в таком едва рабочем состоянии оказалась кому-то нужна (агрессивным школотятам). Т.е. если найти свою нишу, собрать аудиторию - качество кода, оптимальность алгоритмов и даже количество багов не сильно влияет на успех игры (популярность, прибыль и т.д.).
Я указал на "ошибки" не в том смысле, что так делать вообще нельзя, а что это может повлечь последствия в будущем, когда (если) нужно будет расширять игру, дополнять её новыми фичами и контентом и т.д. Чисто на коленке маленькую игрушку слепить можно из чего угодно, если твоя цель - быстро выложить продукт в интернет и забыть о нём. Т.е. нужно смотреть на твою конечную цель, что и зачем ты хочешь сделать, на какие траты готов пойти.
Просто, мне кажется, чаще всего в геймдев приходят ради создания игры мечты, а не ради сотни ассетфлипов на коленке за один вечер. Заработать на играх очень сложно, нужен большой бюджет независимо от игры. Если у тебя нет ни мечты сделать свою игру, ни огромного бюджета на маркетинг ради прибыли, то вряд ли геймдев для тебя.
И в целом у тебя есть хороший потенциал. Новички на четвёртый день освоения движка редко разбираются достаточно хорошо, чтобы получить то, что у тебя там на скриншоте и в кусках кода (если ты не копипастил вообще всё из интернета). В общем, ты молодец, независимо от того, чего ты там хочешь достичь.
>Всем удачи!
До завтра.
https://godotengine.org/article/godot-community-poll-2023/
>What communities do you most actively interact with?
Ставьте галочку на
>Other:
И вводите в поле справа без опечаток:
2ch.hk/gd
Давайте поднимемся в топ, годаны!
Вроде как, там можно через запятую вписать несколько вариантов.
Вписался, хотя хз зачем нам подниматься в топ. Конечно, тредик уютный и добрый, приятнее многих мест в интернетах, но этот опрос это ж не коркурс какой-нибудь или типа того. Но пройти его, конечно, полезно.
Бамп вопросу. Тот случай, когда не смог самостоятельно нагуглить ответ даже после того, как запостил вопрос.
Аноны, как сделать так, чтоб текст в Label не увеличивал свой размер вместе с зумом камеры? В CanvasLayer засунуть не могу, так как мне нужно, чтоб текст был в конкретном месте на карте
>текст в Label не увеличивал свой размер вместе с зумом камеры
Ты его потомком Node2D делаешь, так? Тогда этот Label как бы считается объектом игрового мира.
>В CanvasLayer засунуть не могу, так как мне нужно, чтоб текст был в конкретном месте на карте
Ну... Попробуй scale у этого Label менять. Создай сигнал "камера изменила зум" и цепляй обработчик к нему внутри скрипта Label, меняющий масштаб.
Спасибо! Сработало!
Аноны, я снова к вам с вопросом. Я немного не понимаю, как работать с разными разрешениями экрана. Мне надо, чтоб игра выглядела нормально на 16х9 разрешениях и без черных полос. Какие настройки для этого ставить? Я смотрел и официальный туториал и просто в ютубе, но по ним остаются черные полосы на некоторых разрешениях.
>как работать с разными разрешениями
GUI, 2D, 3D? Жанр игры? ПК, мобилки?
>остаются черные полосы
Покажи скриншоты. Лишнее можешь замазать.
>GUI, 2D, 3D? Жанр игры? ПК, мобилки?
Топдавн шутер. Пиксельный, 2Д на пк.
>Покажи скриншоты.
Вот так выглядит. Первый это 640х360. Оригинальное разрешение. Весь экран заполнен, а второе 1280x768, сверху и снизу полосы. Оба разрешения 16x9
>640х360
>1280x768
>Оба разрешения 16x9
Кого ты обманываешь?
640/360 = 1.7(7) = 16/9
1280/768 = 1.6(6) = 5/3
>Пиксельный
Пиксель-перфект что ли?
Как именно растягиваешь пиксели?
>Топдавн шутер
Это хорошо. Можешь просто увеличить область видимости вместо чёрных полос по краям.
>Кого ты обманываешь?
Я сейчас себя таким идиотом почувствовал, когда осознал.
>Пиксель-перфект что ли?
>Как именно растягиваешь пиксели?
В настройках окна выставил 2d и keep
>Это хорошо. Можешь просто увеличить область видимости вместо чёрных полос по краям.
А как это сделать?
>В настройках окна выставил 2d
Мимо проходил, но это не пиксель-перфект. Перфект это viewport, который снапает твои внутриигровые пиксели в соответствии с пиксельной сеткой.
При выборе viewport шрифт шакальным становится
Ага, потому что он у тебя тоже не пиксель перфект. Если хочешь тру пиксель перфект - используй пиксельный шрифт соответствующего пиксельного размера, а не рандомную ттфку.
https://itch.io/game-assets/tag-fonts/tag-pixel-art - как правило указаны разрешения, под которые эти шрифты сделаны.
С другой стороны, пиксель перфект тебе может быть нахуй не нужен и даже вреден, например если ты крутишь спрайты вокруг их оси, ожидая что они сохранят свою изначальную пиксельность. Вьюпорт их перепикселит.
>Ага, потому что он у тебя тоже не пиксель перфект. Если хочешь тру пиксель перфект - используй пиксельный шрифт соответствующего пиксельного размера, а не рандомную ттфку.
Тут не выйдет, мне нужен этот конкретный шрифт
>С другой стороны, пиксель перфект тебе может быть нахуй не нужен и даже вреден, например если ты крутишь спрайты вокруг их оси, ожидая что они сохранят свою изначальную пиксельность
Значит не нужен. Просто я спрайт героя и врагов кручу и если они будут превращаться в кашу, то как-то не очень хорошо будет.
>выставил 2d и keep
>Значит не нужен
Если у тебя не пиксель-арт, то выбирай 2d+expand:
https://docs.godotengine.org/en/3.5/tutorials/rendering/multiple_resolutions.html#desktop-game
>спрайт героя и врагов кручу
>Первый это 640х360. Оригинальное разрешение.
Зачем тебе такое маленькое разрешение, если ты спрайты крутишь? Сделай высокое разрешение, а спрайтам сделай высокий scale. Тогда у тебя будет эффект типичной индюшатины, когда спрайты состоят из квадратиков и вращаются.
>Сделай высокое разрешение, а спрайтам сделай высокий scale.
А, нет, не надо, по той же ссылке написано:
>If you are OK with sprites being able to move or rotate in "sub-pixel" positions or wish to have a high resolution 3D viewport, you should use the 2d stretch mode instead of the viewport stretch mode.
Т.е. будет тот же эффект "вращения квадратиков".
>Если у тебя не пиксель-арт, то выбирай 2d+expand:
У меня пиксельная игра
>Зачем тебе такое маленькое разрешение, если ты спрайты крутишь?
Выбрал минимальное 16:9, которое было написано в списке разрешений
Делайте игры.
В старом треде отписал, не заметил перекот, сюда продублирую:
Аноны, а чего по фепесам в четвёрке? Делаю обычный платформер, и на Ryzen 3 3200g + Vega 8 (встройка от рязани) + 8gb ddr3 (или 4, не помню) получаю 20 фепесов с ёба шейдерами и 40-50 без них. Как можно адекватно глянуть, что именно столько ресурсов пожирает?
Профайлер прилагаю
Аноны, а чего по фепесам в четвёрке? Делаю обычный платформер, и на Ryzen 3 3200g + Vega 8 (встройка от рязани) + 8gb ddr3 (или 4, не помню) получаю 20 фепесов с ёба шейдерами и 40-50 без них. Как можно адекватно глянуть, что именно столько ресурсов пожирает?
Профайлер прилагаю
>Как можно адекватно глянуть, что именно столько ресурсов пожирает?
1. Посмотри, какой у тебя там рендерер. Возможно, твой видеочип не дружит с вулканом. А вот OpenGL рендерер они переписали заново и ещё не доделали.
2. Проверь настройки проекта и отключи всё лишнее, что ты мог случайно включить.
3. Пробуй запускать и тестировать все сцены по отдельности (F6), либо создай тестовую сцену, на которую будешь добавлять свои объекты.
4. Ищи аномалии в этих счётчиках:
https://docs.godotengine.org/en/stable/classes/class_performance.html
5. Читай рекомендации по оптимизации:
https://docs.godotengine.org/en/stable/tutorials/performance/index.html
>встройка
Ну а что ты ожидал...
Ну, условная контра гоу в 100 кадров на этой встройке запускается, это далеко не интел хд графикс
мимо
Ты увере что тормозит рендер а не твой скрипт в _process?
А, вижу скрипты ниже 3.8%
Подкиньте идей, как можно сделать физическое колесо на RigidBody? Т.е. хочу прицепить RigidBody-колесо к другому RigidBody и заставить его крутиться. Пробовал использовать джойнты, но так и не разобрался, как правильно закрепить, всё время отваливается. Интересует физика колеса как в Space Engineers, Scrap Mechanic и т.п., т.е. реальный цилиндрический ригидбоди вместо примитивного рейкаста.
Алсо, кто-нибудь здесь уже пробовал Jolt?
https://github.com/jrouwe/JoltPhysics
https://github.com/godot-jolt/godot-jolt
Алсо, кто-нибудь здесь уже пробовал Jolt?
https://github.com/jrouwe/JoltPhysics
https://github.com/godot-jolt/godot-jolt
> как правильно закрепить
Учить матчасть. Готовых решений тут нет. Либо ты изучаешь матчасть и сам всё делаешь (попутно охуевая от того, как всё просто оказалось) либо любой код, что тебе тут дадут будет ничем не лучше и не хуже официальных туториалов и шаблонов. Просто чужой код, который будет работать, пока тебе не захочется чуть-чуть подправить, после чего всё непредсказуемо перепидорасится.
Всегда хотел делать игоры.
Полюбил Годотю.
Кодер-самоучка.
Но всю юность слил в редактор карт WC3 и пока там трахался с костылями и велосипедами - перегорел.
Полюбил Годотю.
Кодер-самоучка.
Но всю юность слил в редактор карт WC3 и пока там трахался с костылями и велосипедами - перегорел.
>Кодер-самоучка
>хотел делать игоры
>трахался с велосипедами
>перегорел
Я тебя хорошо понимаю.
Никогда не поздно. Я будучи нюфагом пилил свои костыли на голых Си и опенгл, не зная толком ни того, ни другого, и тоже перегорел. Спустя десяток лет потихоньку вернулся с помощью годота. Интерес может прийти в процессе, дерзай.
>изучаешь матчасть
>как всё просто оказалось
Конкретно о чём ты говоришь? На данный момент я не вижу в API Godot ничего похожего на то, что мне нужно. У HingeJoint есть свойства "мотор", но нет свойств для того, чтобы узнать текущее состояние джойнта. Т.е. получается, что его можно только создать и настроить, а дальше контроль теряется. Пружину вообще не нашёл, её просто нет, мне что, универсальный 6-осевой джойнт для такой тривиальной вещи настраивать? У SliderJoint не вижу параметра "пружина" или "мотор", он просто слайдер. Мне придётся прикладывать импульсы к каждому RigidBody вручную? Уже давно у меня впечатление, что систему джойнтов сделали "чтоб было" и больше не трогали, как будто её никто не использует. Туториалов почти нет. Подсказок в редакторе или консоли об ошибочном расположении джойнтов тоже нет, они даже не предупреждают о том, что в их полях ничего не записалось по какой-то причине.
Я просто не хочу изобретать физику с нуля, потому что это будет слишком сложно и без C++ медленно.
Ладно, я уже разобрался, в чём проблема была. Буду использовать универсальные джойнты...
Присоединяюсь к перекличке. Тоже начинал с моддинга и велосипедов, тоже перегорел. Вернулся к геймдеву благодаря Годоту.
Годот очень лёгкий. Лично я при разработке на нём ощущаю такое же удовлетворение, как при игре в какую-нибудь луталку. Любое действие приносит результат и прогресс, мозг вознаграждается чувством "у меня получилось". Это очень сильно помогает удержать интерес.
>Лично я при разработке на нём ощущаю такое же удовлетворение, как при игре
Такие же ощущения, давно осознал, что Godot Editor - это самая настоящая игра-песочница. Даже где-то на официальном сайте писалось, что Godot Editor - это игра, сделанная на Godot Engine.
>Буду использовать универсальные джойнты...
Ой всё, нет, не буду использовать.
Почему их так колбасит? Почему абсолютно симметричная моделька проезжает 10 метров и начинает крутиться по кругу вокруг одного переднего колеса? Почему цепь из двух звеньев (для поворота) уже не может держать вес корпуса? Столько вопросов, а где искать ответы - не ясно.
Не понимаю, как существуют проекты вроде Crossout без бесконечных жалоб на кривые-косые соединения колёс к двигателям и т.п. Магия какая-то.
Похоже, придётся вернуться к рейкастам...
Где этот "shape" находится? Что то найти не могу.
Вообще видно как устарел этот гайд по первой игре. Поновее ничего нету чтобы привыкнуть к интерфейсу?
Вообще видно как устарел этот гайд по первой игре. Поновее ничего нету чтобы привыкнуть к интерфейсу?
У тебя открыт AnimatedSprite2D, т.е. визуал, а в гайде речь про свойство Shape у Player, который кинематикбоди.
Чем может быть вызвано зависание на 350+ мс?
1. Происходит в момент инстанциирования сцены.
2. Повторное инстанциирование той же самой сцены такой задержки не вызывает.
3. С шейдерами не связано, я даже удалил их.
4. Шейпы упростил, задержка осталась той же.
5. Сделал load().instanciate() этой сцены заранее, но задержка при первом заходе сцены в дерево сцены никуда не делась, те же 350+ мс.
6. Дальше игра работает плавно. Добавление сразу нескольких таких сцен не вызывает проблем.
Из подозрительного - obj-файл весит 188 КБ, но, как я уже сказал, я делаю предварительную загрузку, тем более у меня SSD и какие-то жалкие килобайты не должны никак повлиять на загрузку.
Я уже не знаю, что делать...
1. Происходит в момент инстанциирования сцены.
2. Повторное инстанциирование той же самой сцены такой задержки не вызывает.
3. С шейдерами не связано, я даже удалил их.
4. Шейпы упростил, задержка осталась той же.
5. Сделал load().instanciate() этой сцены заранее, но задержка при первом заходе сцены в дерево сцены никуда не делась, те же 350+ мс.
6. Дальше игра работает плавно. Добавление сразу нескольких таких сцен не вызывает проблем.
Из подозрительного - obj-файл весит 188 КБ, но, как я уже сказал, я делаю предварительную загрузку, тем более у меня SSD и какие-то жалкие килобайты не должны никак повлиять на загрузку.
Я уже не знаю, что делать...
Вообще похоже на шейдеры.
Если твоего шейдера нет, годот же все равно должен нарисовать объект каким то стандартным, если он встречается впервые, то он будет компилироваться.
Делай прелоад, а не лоад.
4.1 сун
>стандартным
Я уверен, что стандартный уже подготовлен к тому моменту, как загружается моя модель.
Да и потом, стандартный 350 мс?
По идее, убершейдер в самом начале готовится.
>Делай прелоад
Есть ли разница, если загружается одна и та же tscn сцена из res://? Разве движок не кэширует в RAM?
По-моему, preload() нельзя направлять на самого себя, это создаёт замкнутый цикл в интерпретаторе.
Прелоад кешируется, лоад - нет, поскольку динамическая загрузка. Фактически про содержание сцены в лоаде движок ничего не знает пока ты ее не начнешь грузить.
Вот в доках нашел: https://docs.godotengine.org/en/3.6/tutorials/scripting/resources.html#loading-resources-from-code
Хорошо, это я могу изменить для проверки, но разве это не должно означать, что задержка в 350 мс будет на каждой последующей загрузке той же сцены? Прикол в том, что она только первый раз так заикается, а потом спавнится без проблем. Не понимаю, как такое возможно, если это не шейдер.
>preload will read the file from disk and load it at compile-time.
В доках заявлено так. Проверь, потом отпишись - тоже любопытно.
Тут можно где-то включить автоматическое форматирование кода, чтобы программа сама подставляла правильно табуляцию где надо? А то вот такие ошибки удручают
Editor settings, Text Editor, Indent, Convert Indent On Save
А нечего копипастить код. Набирай вручную - так лучше усвоишь и быстрее запомнишь.
Алсо, в твоём случае лучше сделать так:
>var direction := Vector2(Input.get_axis("move_left", "move_right"), Input.get_axis("move_up", "move_down"))
>if direction.is_zero_approx():
>...
емнип легко проверить
добавь этот самый obj на основную игровую сцену, которая в начале игры загружается, и посмотри, будет ли после этого первая инстанцианция долгой.
Еще помню, раньше (для 3) писали делать так - все материалы в инспекторе конвертнуть в шейдер материал. А потом каждому такому материалу назначить один и тот же шейдер. То естьматериалы будут разными (красная текстура, зеленая и тд) но шейдер будет один.
>добавь этот самый obj на основную игровую сцену
Хорошая идея, я проверил.
>Делай прелоад, а не лоад.
>Проверь, потом отпишись - тоже любопытно.
Я проверил, preload в моём случае не влияет.
В общем... Я выяснил, что замедление происходит на первом вызове instance(). Добавлять этот инстанс в дерево сцены не обязательно, он может просто лежать в памяти бесхозным, но все следующие будут быстрее. Наверное, потому что движок внутре как-то оптимизирует инстансинг. Но вот почему моя примитивная в общем-то сцена так тяжело инстансится первый раз я не понял. Вернул материалы с шейдерами на место и всё норм. Странно.
Короч, если кто-то здесь процедурно составляет уровень из инстансов запакованных сцен - заранее запилите инстансы всех ваших сцен. По идее, это потратит чуть больше памяти с самого начала игры, но зато потом расстановка дубликатов этих сцен в игровом мире будет плавнее.
Попробуй еще сохранить все в бинарном виде, а не текстовом. Меши можно так сохранять, и сцены тоже. .res, а не .tres. Честно говоря не помню как там работает, может он реально obj загружает и парсит, это текстовый формат так то, а можно как .mesh сохранять если не путаю.
Знаю я про текстовые и бинарные форматы. Да, скорее всего должно ускорить загрузку, если сохранить в бинарном формате. Но его потом фиксить сложно, если что-то сломается в сцене, и системы контроля версий вроде бы плохо переваривают бинарники. Так что в бинарный лучше сохранять перед экспортом игры.
>Godot Editor - это самая настоящая игра-песочница.
Подумал и это меня устраивает, на самом деле. Разбираясь в годоте я тоже ощущал что скорее играю, чем вкалываю. Может стоит продолжать пытаться, не делать полноценную игру, а просто получать удовольствие от разработки одноуровневых поделок или систем.
Вопрос к присутствующем, реально ли найти 3D ассеты для годоти или лучше сфокусироваться на 2D? И, собсно, где? На официальном сайте есть конечно раздел с ассетами, но лишь немногим отличный от нуля.
>не делать полноценную игру, а просто получать удовольствие от разработки одноуровневых поделок или систем.
Именно. Сделаешь их десятка два - наработаешь скиллы для полноценной игры.
Про ассеты - на итче их хватает. Бесплатные, платные. Есть отдельные сайты для продажи ассетов но я их забыл
Можешь делать сам если обладаешь хотя бы минимальным чувством стиля. Главное делай как можно проще. Для 2д - фотошоп или aseprite если пиксели. Для 3д - Блендер, или, если хочешь попроще и побыстрее - Блокбенч - https://www.blockbench.net/gallery/
>Про ассеты - на итче их хватает.
Воу, даже не знал что такая движуха существует. Вообще отлично.
А можно как-нибудь сменить изображения тайлсета?
Конечно.
https://docs.godotengine.org/en/stable/classes/class_tilesetatlassource.html#class-tilesetatlassource-property-texture
Единственное что в 3-ке, похоже, надо пробегаться по всем тайлам.
https://docs.godotengine.org/en/3.6/classes/class_tileset.html#class-tileset-method-tile-set-texture
Еще ассет на эту тему видел.
Возможно, тут проще использовать отдельные тайлсеты и переключать их.
Спасибо, но оказалось для меня бесполезным. Как оказалось, что при импорте из Tiled в годот тайлсет использует не pngшку, а tmx формат. Прям засада какая-то. Неужели нельзя было из коробки импорт сделать, как в game maker studio? А то встроенный редактор это ужас какой-то.
>Возможно, тут проще использовать отдельные тайлсеты и переключать их.
Тогда придется каждому из них коллизии прокликивать отдельно.
>разработки одноуровневых поделок или систем
С этого любая сложная игра начинается. Сначала много отдельных мелких прототипов, а потом уже - ААААААААААаааааааа...
>найти 3D ассеты для годо
Не обязательно искать специально для Godot, подойдут любые 3D модели в поддерживаемых форматах (в основном рекомендуют gltf юзать) или которые ты способен сам конвертировать в поддерживаемый формат. Вот здесь много всякого разного, но самое интересное - модульные паки, должны подойти для гридмапа:
https://opengameart.org/art-search-advanced?keys=&field_art_type_tid%5B%5D=10&sort_by=count&sort_order=DESC
>Блокбенч - https://www.blockbench.net/
Почему я о нём никогда не слышал? Встречал только какую-то платную фигню, в которой модельки можно делать из кусочков, которые нужно дополнительно покупать в виде DLC (и ведь покупают!). И ещё какой-то там крокодил, вроде бы тоже платный, не помню уже, лень было разбираться. Воксельные редакторы пробовал, но это не то, что мне нужно. А тут опенсурс и бесплатно - уже скачал попробовать, спасибо.
>сменить изображения тайлсета?
Что? Ты имеешь в виду аватарки на палитре?
>при импорте из Tiled в годот тайлсет использует не pngшку, а tmx формат
Импорте? Может, при экспорте из Tiled? Потому что импорта напрямую из Tiled из коробки вроде бы нет (может, в 4.0 добавили?), есть только какой-то аддон от третьих лиц, но я не интересовался. Tiled вроде поддерживает несколько форматов экспорта, так что ты можешь выбрать более подходящий... наверное...
>встроенный редактор это ужас какой-то
В чём ужас? Я пробовал на 3.x, всё хорошо было. Говорят, что в 4.0 его полностью переработали, сделали удобнее. Куда уж удобнее - не знаю. Tiled я тоже пробовал, он какой-то перегруженный фичами - слои туда, слои сюда - чтобы самую простую карту сделать продираться через ГУЙ приходится. В Godot слои реализуются через создание нескольких тайлмапов - всё интуитивно просто. ИМХО, Tiled нужен тем, кто вместо готового движка велосипед пишет или тонкие фреймворки использует.
>при импорте из Tiled в годот тайлсет использует не pngшку, а tmx формат.
Стоит указывать в вопросе, что он не про годот, а про сторонний аддон.
Вообще на импорт тайледа, вроде, несколько аддонов, можешь сравнить разные.
Еще вроде бы можно делать так - экспортировать из тайледа в чем то другом (json? xml?) и импортировать уже их.
Или подредактировать аддон чтобы в нем менять картинку.
Если скажешь больше конкретики - версию годота и аддона, могу вечером посмотреть.
>Тогда придется каждому из них коллизии прокликивать отдельно.
Там можно написать (тул)-скрипт, который просто скопирует из одного тайлсета в другой.
Почему ругается? Я же засунул код прям под функцией, а ошибка пишет как будто я вне функции код написал.
Разобрался, сорян. Надо было таб добавить.
Кстати, Tiled 1.10 поддерживает экспорт в Godot 4.0:
https://doc.mapeditor.org/en/stable/manual/export-tscn/
Есть некоторые ограничения, но генерируется tscn-файл.
Повторяю, не копипасти код, а переписывай вручную.
>Повторяю, не копипасти код, а переписывай вручную.
Так я как раз начал писать вручную, причем удалил то что вчера скопипастил и все вручную теперь пишу. Спасибо кстати за добрый совет.
При импорте из tiled в годот проблема была, но я уже её решил. Как бы поддерживает, но мне все же хотелось бы видеть в редакторе карту тоже, а не просто читать из файлика для отображения в игре.
Это один и тот же аддон, просто, как я понял, там его забрасывали и восстанавливали.
>В чём ужас?
Ну, это как рисовать в paint, вместо aseprite
В годоте нельзя рисовать формы из тайлов. Нужен квадрат из тайлов? Ставь по одной штуке. Тоже самое и с удалением, удаляй по одному.
Неудобно выбирать тайлы. В Tiled ты просто тыкаешь на место в изображение, в годоте же у тебя разбивка на что-то непонятное.
Слои - это очень удобно.
Нельзя передвинуть тайлы. Захотел переместить группу тайлов левее? Стирай все и рисуй заново.
Годот даже сам изображение на тайлы нарезать не может.
Да и просто мелкие quality of life штуки, вроде превью, рандомного выбора тайлов(например, чтоб трава была не однообразная) и т.д
>Стоит указывать в вопросе, что он не про годот, а про сторонний аддон.
Да меня как раз интересовало можно ли это вообще. Потом вылезла проблема с форматом, которую я решил. Надо было просто поместить изображение в одном месте с файлом тайлсета Tiled.
>Там можно написать (тул)-скрипт, который просто скопирует из одного тайлсета в другой.
Как-то не хочется разбираться с форматом, в который годот тайлсеты сохраняет. С заменой текстурки как-то легле вариант.
>Кстати, Tiled 1.10 поддерживает экспорт в Godot 4.0:
Это шикарно! Везет тем, кто на 4 начал.Мне переписывать под 4 то, что есть - не вариант
> Нужен квадрат из тайлов?
>Нельзя передвинуть тайлы. Захотел переместить группу тайлов левее? Стирай все и рисуй заново.
Не, я понимаю что тайловый редактор в годоте неудобный, но можно же посмотреть какие кнопочки в нем есть?
Квадрат из тайлов - ctrl+shift+лкм
Переместить - сначала выделить мышкой, потом ctrl-x ctrl-v
Рисовать случайные - создать атлас и поставить галочку use priority.
Tiled так то дремучее легаси, с трудом его получается назвать Quality of life.
>>Там можно написать (тул)-скрипт, который просто скопирует из одного тайлсета в другой.
>Как-то не хочется разбираться с форматом, в который годот тайлсеты сохраняет. С заменой текстурки как-то легле вариант.
Ни про какое разбирание с форматом тут речи не идет.
Буквально речь про то что делается цикл (получить все тайлы из одного тайлсета, скопировать по одному в другой)
>Квадрат из тайлов - ctrl+shift+лкм
Окей, не знал, спасибо. Но все равно не понимаю, почему нельзя было сделать это простым переключением режима, а не только удерживанием трех клавиш?
>Переместить - сначала выделить мышкой, потом ctrl-x ctrl-v
Окей, но все равно, мне придется перемещать каждый так в каждом тайлмапе.
>Рисовать случайные - создать атлас и поставить галочку use priority.
А в Tiled я могу просто выбрать любые тайлы и кликнуть лкм. Мне кажется, это намного легче.
Не собираюсь никого переубеждать, но для меня Tiled в десятки раз удобнее.
Но мне для этого нужно будет разобраться, где вообще коллизии хранятся в tres файле одного тайлсета и переписать эти места в другом.
Я что то не понял, вот я написал проигрывание анимации во время передвижения обьекта, а почему анимация проигрывается не полностью, а только часть которая "0" ? Ну т.е. грубо говоря я жму направо несколько раз - у персонажа только глаз направо повернулся, а ноги он не раздвинул. Мне что то еще добавить нужно в код?
Да я вообще не про формат tres, а про API.
Вот упрощенный скрипт, который берет коллайдеры из тайлсета 1 и вставляет их в тайлсет 2 меняя местами.
Конечно полный скрипт будет побольше, поскольку надо еще получать сколько шейпов у каждого тайла, копировать другие виды такие как one way и т.д. Но это все легко.
Погоди.. Можно что-то менять в редакторе кодом в реальном времени? Это как вообще?
Tool script
Спасибо, интересная штука
Только помни что это опасная бритва, то есть делай бекапы, ведь она может перезаписать и перезатереть любые данные.
До меня только теперь дошло, в чём вопрос.
>А можно как-нибудь сменить изображения тайлсета?
Делаешь копию тайлсета (.tres) на диске -> меняешь изображение. ВСЁ.
Это простой текстовый формат, там вверху строчка типа такой:
>[ext_resource path="res://game/world/map/tileset.png" type="Texture" id=1]
Вот просто путь меняешь и всё. По крайней мере в 3.x это сработает.
>Можно что-то менять в редакторе кодом в реальном времени? Это как вообще?
Это надо документацию читать, прежде чем начинать делать игры.
https://docs.godotengine.org/en/3.6/tutorials/plugins/running_code_in_the_editor.html
>А можно как-нибудь сменить изображения тайлсета?
Делаешь копию тайлсета (.tres) на диске -> меняешь изображение. ВСЁ.
Это простой текстовый формат, там вверху строчка типа такой:
>[ext_resource path="res://game/world/map/tileset.png" type="Texture" id=1]
Вот просто путь меняешь и всё. По крайней мере в 3.x это сработает.
>Можно что-то менять в редакторе кодом в реальном времени? Это как вообще?
Это надо документацию читать, прежде чем начинать делать игры.
https://docs.godotengine.org/en/3.6/tutorials/plugins/running_code_in_the_editor.html
Оки
>Вот просто путь меняешь и всё. По крайней мере в 3.x это сработает.
Благодарю. Буду теперь знать.
>Это надо документацию читать, прежде чем начинать делать игры.
Я по ходу дела решил разбираться. Ну и по туториалам
Кстати. неожиданное применение тул скриптам. У меня на линуксе окна и их заголовки немного по другому расставляются, ну и поскольку годот у нас игра на годоте, я могу располагать окно редактора там где мне надо.
>располагать окно
Кстати, давно заметил такую проблему с некоторыми играми на Godot с itch.io. Они почему-то часто запускаются на моём экране (1440x900) сдвинутыми в левый верхний угол примерно на 1/4 размера окна, из-за чего заголовок выходит за пределы экрана и я не могу вернуть окно на место. В некоторых случаях удаётся исправить проблему через диспетчер задач, выбрав "раскрыть на весь экран", в других случаях в настройках игры выбрать "на полный экран", но иногда ничего не спасает. С чем это связано? Разработчик указал размер окна 1920x1080 и движок офигевает от моего "слишком маленького" разрешения?
Сам я считаю, что нужно ориентироваться на минимально допустимое для игры разрешение. Если игра может работать в окне 800x600 или даже меньше, не ломая свой ГУЙ, зачем ставить больше? На качество рендеринга эта настройка вроде как не влияет, если не использовать опцию масштабирования. Кому будет нужно - просто раскрывают окно на весь экран и всё. А ещё не понимаю тех, кто блокирует размер окна, не считая совсем уж ретро пиксельных игр...
Ну вообще то у годота есть опции командной строки которые можно посмотреть запустив его с --help
Так что можешь пробовать запускать игры в желаемом разрешении и позиции.
Про дизайн говорить не буду, не самая легкая тема. Я за адаптивность, так что игра должна запускаться размером как на мониторе, а гуй желательно чтобы скалировался ползунком в процентах. Но понятно что не весь гуй так можно сделать, наример портретик героя.
Я так и представляю, как игрок будет заниматься этой хуйней
>опции командной строки
Хммм, забавно, что так-то я уже знал про эти опции, но когда запускаю чью-то игру, опции командной строки - последнее, о чём я думаю, ведь это игра, а не прикладная программа. Я в том смысле, что обычно на других движках игра запускается нормально по центру экрана или в полноэкранном режиме, а игры/демки на Godot почему-то слишком часто улетают в левый верхний угол, скрывая заголовок за краем экрана. При том что у меня с моими проектами такой проблемы никогда не было, но я и размер окна в настройках проекта никогда больше своего экрана не ставлю.
>портретик героя
Если он не "пиксельный", то будет масштабироваться как любые иллюстрации на экране. Но даже если "пиксельный", как минимум можно выбрать между x2/x3/x4 и т.п.
Делайте игры.
> из-за чего заголовок выходит за пределы экрана и я не могу вернуть окно на место. В некоторых случаях удаётся исправить проблему через диспетчер задач
Попробуй зажать вин-кнопку и потащить само окно (не спрятавшийся тулбар) с помощью ЛКМ. На большинстве линуксовых DE это дефолтное поведение, может и у тебя.
А так может баг в одной из версий был, хз.
>я и размер окна в настройках проекта никогда больше своего экрана не ставлю.
Сделай для пробы и посмотри что будет.
>Я так и представляю, как игрок будет заниматься этой хуйней
>опции командной строки - последнее, о чём я думаю, ведь это игра, а не прикладная программа.
Так это опции для тех, кого не устраивает дефолтное. Такие опции скорее всего во всех движках есть, я точно помню что утка когда стримил твг запускал юнити с такими же параметрами.
Вроде и на линуксе и на винде Alt+пробел вызывает меню окна, где может быть пункт перемещать.
>Если он не "пиксельный", то будет масштабироваться как любые иллюстрации на экране.
Вопрос в том, что масштабировать.
Грубо говоря, я хочу чтобы HUD оставался пропорциональным, так как его расположил дизайнер - и не хочу чтобы спидометры и джойстик масштабировались пользователем.
С другой стороны, я скорее всего хочу чтобы пользователь масштабировал хотбар как хочет.
Также я думаю что пользователь должен иметь возможность масштабировать тексты (имена игроков как пример).
Но если масштабируются тексты, встает вопрос с их контейнерами, ведь теперь тексты диалогов перестанут помещаться, нужен скролл или увеличение панелей. Также возникает вопрос, должны ли вместе с этим масштабироваться галочки и конпки закрытия окошек.
Если делать персонажа на основе RigidBody, то движение осуществляется через add_force(), но в физическом плане эта функция как бы добавляет к телу невидимый ракетный двигатель, толкающий тело независимо от любых окружающих условий. Если со статичным окружением всё нормально и мелкие ригидбоди толкаются адекватно, то вот если встать на большой ригидбоди и упереться в его стенку, получаем нереалистичную ситуацию, когда персонаж толкает объект, на котором стоит своими ногами. Что-то вроде барона Мюнхгаузена, который сам себя за волосы из болота вытаскивал. В какой-то игре этот эффект только плюс, а если я хочу его избежать? Я пробовал навешивать рейкасты, но они промахиваются; пробовал вешать Area, но непонятно, как определять, толкает персонаж объект или просто касается спиной; пробовал определять, на чём персонаж сейчас стоит ногами, но это тоже как-то не очень получилось. Подскажите идеи, как это теоретически можно решить имеющимися средствами (API RigidBody, Area, RayCast).
Совсем забыл, я ещё пробовал прикладывать силу в противоположном направлении к объекту, на котором стоит персонаж, но как-то запутанно получилось и вроде не сработало так, как я ожидал. Подозреваю, что это будет чревато багами физики.
Я доделал обучающий гайд по первой 2д игре из документации.
Но так и не победил проблему , перечитал раздел про анимации еще раз, делал все точь в точь, но все равно не проигрывается второй слайд (1), а только первый (0).
Ну да и хуй с ним, думаю я потом сам пойму что тут не так, когда побольше познакомлюсь с движком.
Вообще в целом нихуя не понял, но сейчас буду проходить гайд по 3д игре, а потом буду уже искать разные гайды в интернете, смотреть как делают другие проекты, чтобы я хотя-бы мог запомнить интерфейс и базовую логику компонентов движка.
> но непонятно, как определять, толкает персонаж объект или просто касается спиной
Может быть знаком, направлением, каким-то порогом до которого не работает?
Я глазами просмотрел и не увидел почему анимация может не работать.
>зажать вин-кнопку и потащить само окно
На Windows 10 такого поведения нет. Или нужна какая-то другая комбинация, которой я не знаю.
>Alt+пробел вызывает меню окна, где может быть пункт перемещать.
1. Альт-пробел вызывает это меню в обычных окнах, но почему-то не вызывает в играх на Godot.
2. Если бы вызывал, альт-пробелом оно выпадает в левом верхнем углу, который за пределами экрана.
3. Меню можно вызывать с панели задач правым кликом по миниатюре окна игры, однако пункт "переместить окно" в Windows работает следующим образом: курсор превращается в стрелочки и телепортируется на заголовок окна, который в моём случае за пределами экрана, а курсор за пределы экрана выйти не может ==> фейл.
4. В том же меню есть кнопка "раскрыть на весь экран", но она будет недоступна, если разработчик заблокировал изменение размера окна.
>опции для тех, кого не устраивает дефолтное
Опции для тех, кого не устраивает, должны быть в гуевом меню игры + в файле конфигурации. Дрочить параметры запуска будет прошаренный пользователь, которому очень надо, а остальные просто пожмут плечами и удалят твою поделку.
>хочу чтобы HUD оставался пропорциональным, так как его расположил дизайнер - и не хочу чтобы спидометры ... масштабировались пользователем
Лол, помню как играл в Flatout, там интерфейс заточен под 4:3 и на любом более широком экране спидометр из круглого становится сплюснутым. Есть патчи от кулхацкеров под широкие экраны, но это должны были сделать разработчики ещё до релиза.
>не хочу чтобы ... джойстик масштабировались пользователем
Если делаешь игру под мобилки, ты обязан сделать хотя бы минимальную кастомизацию своего ГУЯ, особенно это касается элементов управления - виртуальных кнопок, джойстиков и т.д.
>пользователь масштабировал хотбар как хочет
В этом нет смысла, если весь остальной интерфейс фиксированного размера. В приведённом тобой Майнкрафте масштабируется весь интерфейс сразу. Масштабирование хотбара на ПК имеет смысл чтобы лучше разглядеть иконки предметов, а это значит, что у тебя весь гуй скукоженный. На мобилках хотбар - это кнопки, значит, у тебя все кнопки скукоженные.
>возможность масштабировать тексты
Опять же, эта фича должна идти вместе с общим масштабированием, потому что, как ты верно заметил, изменение только размера шрифта влияет на заполнение элементов гуя. Если пользователю слишком мелкие буквы, то и остальные элементы для него тоже слишком мелкие (либо ты... странный человек, делающий огромные кнопки рядом с микроскопическими надписями).
Просто не нужно завязывать сложность геймплея на расположение и размер гуевых элементов. Если изменение положения или размера элементов гуя упрощает твой геймплей настолько, что это можно назвать читерством, то твоя игра имеет фундаментальные проблемы, которые нужно решить в первую очередь. А усложнять себе геймплей изменением гуя обычный пользователь не будет; тот, кто захочет, наверняка найдёт мод или даже сделает его сам, и ты этому помешать не сможешь.
>знаком, направлением, каким-то порогом
Направлением к чему? Допустим, у меня 2 ригидбоди - один скрюченный, а другой сферический. Если определять направление к центру объекта, то у них разные результаты вообще будут. А определить точную точку касания сложно, она у меня глючила постоянно (3.x давно как-то).
В общем, хочу с нуля переделывать на 4.1, но пока что даже теоретически не могу решить проблему. Вроде, самое логичное - "отталкиваться" от точки опоры, но это чревато тем, что при ходьбе по ригидбоди их будет колбасить в разные стороны...
Объяснить, почему не работает метод с документации?
>Input.get_axis("move_left","move_right");
>'Input' does not contain a definition for 'get_axis'
Использую C#.
>Input.get_axis("move_left","move_right");
>'Input' does not contain a definition for 'get_axis'
Использую C#.
Разобрался. Не такая нотация.
>Опции для тех, кого не устраивает, должны быть в гуевом меню игры + в файле конфигурации.
Должны быть. Но если их нет, то есть опции командной строки. И повторюсь это есть и в других движках.
> Меню можно вызывать с панели задач правым кликом по миниатюре окна игры, однако пункт "переместить окно" в Windows работает следующим образом: курсор превращается в стрелочки и телепортируется на заголовок окна,
но окно можно двигать с клавы курсорными стрелками, вроде и на винде и линуксе так.
Я не оправдываю тех кто не сделал удобное меню и не протестировал на нестандартных разрешениях, но в любом случае пользователь не должен быть рабом своего компа, он должен быть его командиром.
>Направлением к чему?
Направлением вперед модели и направлением движения. Так точно можно различить когда ты толкаешь вперед, и когда ты идешь спиной назад.
Аноны, я вот с помощью raycast2D ищу объекты, с которыми персонаж может взаимодействовать. Просто нажал на кнопку, а рейкаст чекнул, есть ли объект в его поле действия и монжо ли с ним взаимодействовать. И вот захотелось мне, чтоб над объектом взаимодействия появлялась кнопка, сообщающая, что можно нажать кнопку и использовать его, но как это сделать? У рейкаста нет никаких сигналов, вроде входа и выхода ноды из луча. Засовывать в process постоянную проверку?
>Если делаешь игру под мобилки, ты обязан сделать хотя бы минимальную кастомизацию своего ГУЯ, особенно это касается элементов управления - виртуальных кнопок, джойстиков и т.д.
Соменваюсь, как раз на мобилках обычно имхо все прибито гвоздями так как задумано. Мобильному игроку сложно же настраивать под себя, еще сложнее чем компьютерному.
>В этом нет смысла, если весь остальной интерфейс фиксированного размера.
Я сужу по ММО, когда мне не нужно масштабировать хитпоинт бары, но надо масштабировать хотбары с кулдаунами.
>делающий огромные кнопки рядом с микроскопическими надписями
Тем не менее, если в интернет-браузере ты зумишь страничку, крестик закрытия браузера не меняется.
Ты можешь писать свои кастомные сигналы.
signal touched(obj)
_process(delta):
target =tvoy_raycast()
emit_signal("touched", target)
Также, возможно, ты можешь делать это не рейкастом, а Area2D.
Это я знаю, просто не знаю, нормально ли вообще пихать все эти проверки в process. Может есть способ, который предусмотрен разработчиком годота.
Не, мне нужна только одна нода, на которую игрок смотрит, а не все ноды в радиусе.
>пользователь не должен быть рабом
Вот поэтому пользователь не будет парить себе мозг хоткеями, труднодоступными меню, командами консоли, джсон файлами и т.д., а просто удалит твою бесплатную игру/демку и перейдёт к следующей. Или вернёт деньги, если купил в Стиме.
Я сейчас не про движок говорю, а про настройку игры. Если ты установил огромное разрешение и зафиксировал размер окна, то ты сам себе палки в колёса вставляешь, доставляя проблемы части аудитории. Особенно когда у тебя в интерфейсе нет ничего, что действительно требовало бы большое разрешение и фиксированный размер окна.
Я думаю, тут частично виновата документация к движку, в которой рекомендуют ставить разрешение 1920х1080. Потому что сам движок по умолчанию ставит разрешение куда меньше, что 3.x, что 4.x. Т.е. это пользователи движка сами ставят такое разрешение, вручную. Или что они там себе ставят, не знаю.
А я еще раз повторю.
Я не оправдываю тех кто сделал некачественную игру или не протестировал на нестандартных разрешениях.
Но движок дает опции даже если разработчик игры не указал или указал неправильное разрешение. И повторюсь, что это делают и в других движках, не только в годоте.
Если игра запускается не там конкретно у тебя, то ты можешь пойти зарепортить баг автору игры или движка, но еще ты можешь запустить с параметрами, чтобы именно у тебя, на возможно нестандартной кофигурации, работало так, как тебе надо, а не как оно "само" выставилось операционной системой.
Ну вот картинка. Как я должен определить, что куда, если я даже точки касания определить точно не могу? Вот специально сейчас проверил, в RigidBody3D нет методов или сигналов для получения точек касания, можно узнать только с какими объектами столкнулся. У Area3D точек касания тоже нет, но там хотя бы понятно, почему (она не оказывает сопротивления, так что вместо "касания" всегда происходит проникновение - пересечение объёмов). Если обвешивать всё рейкастами, неизбежно будут промахи.
Я не знаю как ты хочешь чтобы было.
Один из способов который приходит в голову - отключать физику тем, кого ты не хочешь чтобы двигался.
Я б на твоем месте разобрался, почему рейкасты промахиваются. Расположи их так, чтобы они надежно находили пол и стену. Дальше ты мог бы сравнивать, пол и стена один и тот же объект.
Еще вроде бы после move and collide возвращается список с кем столкнулся. Отсюда тоже можно плясать.
Еще есть слои.
>на мобилках обычно имхо все прибито гвоздями так как задумано.
В Террарию поиграй, лол. Алсо почти в каждой игре с джойстиком он плавающий, то есть появляется там, куда ткнёшь пальцем, а не прибит гвоздями куда-то в угол, ведь хват устройства на 3.5'' квадрате сильно отличается от 7'' растянутой лопаты, да и даже один девайс разные люди по-разному в руках держат. И если подробная настройка как в Террарии встречается редко, то как минимум 2-3 набора контроллеров на выбор во многих играх есть, особенно где управление машиной. Также после появления телефонов с уродливыми дырками, бровями, бородками, скошенными углами и прочими дефектами производства в мобильных играх стала появляться настройка "безопасной зоны" - то есть отступ от края экрана, на котором не должно располагаться никаких элементов ГУЯ, ведь на конкретном девайсе там тупо нет пикселей и/или не срабатывает сенсор, хотя ОС разрешает выводить туда графику, ничего не зная о физическом дизайне дисплея. Это база, это знать надо, если хочешь сделать хорошую игру, которая будет доступна и удобна как можно большему числу игроков.
>Мобильному игроку сложно же настраивать под себя, еще сложнее чем компьютерному.
Наоборот же, всё максимально интуитивно - пальцем сдвинул куда удобно, двумя пальцами сжал/разжал, зафиксировал и играешь. А на компе мышкой...
>Я сужу по ММО, когда мне не нужно масштабировать хитпоинт бары, но надо масштабировать хотбары с кулдаунами.
Не знаю, не играл в ММО с перегруженным GUI, считаю такой дизайн пережитком прошлого, когда было модно иметь отдельную визуальную кнопку на каждое действие и в браузеры добавляли тулбаров на половину экрана. Но насколько я знаю, в ММО обычно окошки по отдельности можно масштабировать, как окна ОС, так что это совершенно отдельное направление GUI.
>если в интернет-браузере ты зумишь страничку, крестик закрытия браузера не меняется.
Это потому, что крестик браузера принадлежит ОС и масштабируется средствами ОС. А страничка внутри браузера нарисована Васяном и никак не зависит от настроек ОС, потому что Васян обмазался CSS и JS.
Раздел называется "геймдев", а не софтач и не играч.
Не расстраивайся, вряд ли тебя забанят за такое мелкое нарушение, когда ты начал обсуждать играч и софтач (как у тебя в операционке не там открывалась скачанная чужая игра)
>начал обсуждать играч и софтач (как у тебя в операционке не там открывалась скачанная чужая игра)
Кончай троллить. Я просто предупредил, чтобы другие аноны знали о таком потенциальном нюансе при разработке своих игр. Это не движкосрач и не просьба решить проблему с чужой игрой. Я сам, как разработчик игр(ы) на Godot, каждый раз напрягаюсь, когда вижу какое-то странное поведение чьей-то чужой игры на Godot - а вдруг моя игра будет так же себя вести на чьём-то ПК? Godot меня почти полностью устраивает и я рад, что он существует и продолжает сравнительно быстро развиваться. Просто нужно учитывать определённые нюансы работы с ним.
>Соменваюсь, как раз на мобилках обычно имхо все прибито гвоздями так как задумано. Мобильному игроку сложно же настраивать под себя, еще сложнее чем компьютерному.
Вот реальный случай.
У меня телефон - стандартная сяомя. На нём всё нормально отрисовывается (есть визуальные глитчи, потому что телефону пора на свалку, но гуй рисуется нормально). А у ребёнка планшет с диагональю почти как у ноута. Оказалось, что сенсорные кнопки управления на нём совершенно конского размера, нажимать такое неудобно. И вообще, мобилки - это такой-то зоопарк разных устройств с рандомным соотношением сторон, разрешением dpi и диагональю экрана, что я не представляю себе, как это можно всё учесть. А теперь добавим сюда, что у ребёнка пальцы сильно меньше, чем у меня.
В итоге я пришёл к тому, чтобы сделать две настройки: масштаб кнопок и их расположение. Чтобы каждый игрок мог настроить не только под своё устройство, но и под свои пальцы. И вроде бы пока что это оптимально работает. Все, кто тестировал игру, так или иначе залезали в настройки.
Так что не принижай мобильных игроков. Дай им оптимальные настройки сразу, но по таким спорным моментам, как масштаб интерфейса, лучше всё-таки дать возможность кастомизации.
>почти в каждой игре с джойстиком он плавающий, то есть появляется там, куда ткнёшь пальцем, а не прибит гвоздями куда-то в угол
А вот поделитесь мнением, анонасы. У меня могильная игра. Геймплей НЕ динамичный. Надо ходить в 4 стороны кликами/тапами, а не свайпами.
Сейчас я разделил нижнюю часть экрана на 4 прозрачные области. В какую тыкнешь - туда и ход. Как сделать лучше? Сделать перемещаемую крестовину размером поменьше? Или так норм?
Поищи исследования куда пользователь дотягивается большим пальцем.
Открыл твою картинку на телефоне (6.4''): если держать одной рукой и нажимать большим пальцем той же руки, то вверх и вниз норм, а влево и вправо уже лишнее напряжение. Если держать одной рукой и тыкать указательным второй руки, то так указывающая рука на весу удерживается над экраном и быстрее устаёт. Если держать двумя руками и тыкать двумя большими пальцами, то возникает путаница, каким пальцем тыкать вверх и вниз. Короче, для портретной ориентации не очень управление. Оно больше для ландшафтной подходит - если держать двумя руками и нажимать большим со стороны кнопок.
>прозрачные области
А что там под ними будет? Как пользователь поймёт границы этих четырёх кнопок? Не будет ли палец перекрывать какой-то контент?
>А что там под ними будет?
Под ними - обычно ничего интерактивного, сама игра происходит в центре и изредка в верхней части. Если что-то перекрывается, то крайне редко.
>Как пользователь поймёт границы этих четырёх кнопок? Не будет ли палец перекрывать какой-то контент?
Во время обучения показываются 4 стрелочки. Потом скрываются.
>для портретной ориентации не очень управление
Дать перетаскиваемую крестовину? Как вообще в мобильных играх реализуют тапы в 4 направлениях?
Если у тебя пошаговая игра, в которой вот прям обязательно нужны отдельные шаги строго по четырём направлениям, и при этом вся игра отрисовывается на части экрана, то не проще ли самые обычные визуальные кнопки нарисовать?
>Как вообще в мобильных играх реализуют тапы в 4 направлениях?
В каких именно играх? Ищи геймплейные аналоги своей игры, наверняка на что-то ориентировался, придумывая концепт игры.
Если я правильно понял, у тебя что-то вроде сокобана. Это древняя игра, наверняка сотни клонов есть в плей маркете, вот качай их и пробуй.
Бля, AdMob подключал кто? Какой плагин нормально работает?
поделитесь пожалуйста кодом с которым можно управлять персонажем по направлению мыши (т.е. чтобы захватывать движение мыши и двигать ею камерой, а кнопками уже в пространстве двигаться, при этом камера чтобы была привязана к модельке)
С помощью гугла такое написал, но чет нифига не двигается персонаж, хотя камерой норм вертит. Годот 4.
С помощью гугла такое написал, но чет нифига не двигается персонаж, хотя камерой норм вертит. Годот 4.
https://www.youtube.com/watch?v=SH_cDJiPdFc
Допишу собственно что изначально пытался по этому гайду сделать, но он старый и естественно ничего не заработало, я потом полез в гайд по 3д игре из документации официальной, и взял часть оттуда - и оно тоже не заработало в итоге...
В 3-ке у методов move and ... был параметр вектор, куда двигаться. В 4-ке это теперь поле у самого чарактер боди.
То есть все что осталось - перед мув н слайд написать velocity = dir (умноженное на желаемую скорость, наверное.)
Также можешь посмотреть тут
https://kidscancode.org/godot_recipes/4.x/3d/basic_fps/index.html
У него обычно полехные кирпичики.
Или в ассетах готовые контроллеры как сделаны.
Cпасибо!
А на годте норм пилятся веб игры? Многопользовательские.
Или под платформуу вк.
Или под платформуу вк.
>А на годте норм пилятся веб игры? Многопользовательские.
Да.
>Или под платформуу вк.
Хуй знает.
блин чет сложно найти норм 3д модельки бесплатные. Неужели вы все их сами еще делаете? Ну не покупать же 25 баксов за 1 модельку кораблика охуеть блять ээх вот бы сделали нейросеть которая 3д модельки делает нормальные
Кораблики сам, да. Процедурно конечно.
Процедурно это как?
Обводы корпуса по формулам, потом башенки расставляются.
Чет сложно, вон выше про blockbench Написали, не проще его юзать? Я то не программист совсем. Ну вкусовщина видимо.
У чувака здесь в meshinstance3d есть кнопка material, а у меня её нету. А как текстуру добавить к модели? Я модель не в том формате добавил? Есть вкладка surface material, но там задается материал для кучи полигонов у модельки. А у меня готовая текстура есть в .png, её загрузить можно?
Ты смотришь внутри меша, а не внутри мешинстанса. Ниже смотри, там где геометри.
А почему её распидорасило? Я текстуры в блокбенче делал.
Я разобрался в чем была причина. Завтыкал и разные размеры текстур указал в настройках модельки и при создании самой текстурки. 2 часа потребовалось чтобы это увидеть
аж глаза разбегаются что дальше делоть
делой игорвы
> Почему их так колбасит?
Потому что у тебя все объекты массой 1 кг? И пушинки и горы, и небо и Аллах. Всё по килограмму.
Вот допустим у меня основной персонаж в игре - это транспорт, и я хочу в будущем реализовать возможность менять этот транспорт. Как мне лучше это организовать в сценах?
Я могу сделать корневую сцену "CharacterBody3D", для игрока где будет хранится, допустим, управление, и отдельные сцены которые тоже "CharacterBody3D" для каждого транспорта? Ну и потом сцену транспорта делать ребенком сцены игрока. Там ведь можно будет как то реализовать смену этого "транспорта" ?
В блокбенче кстати делать модельки оказалось легко и интересно. Проблемы с текстурированием правда лень заморачиваться на этом этапе, но вот из кубиков собирать вполне интересно.
Я могу сделать корневую сцену "CharacterBody3D", для игрока где будет хранится, допустим, управление, и отдельные сцены которые тоже "CharacterBody3D" для каждого транспорта? Ну и потом сцену транспорта делать ребенком сцены игрока. Там ведь можно будет как то реализовать смену этого "транспорта" ?
В блокбенче кстати делать модельки оказалось легко и интересно. Проблемы с текстурированием правда лень заморачиваться на этом этапе, но вот из кубиков собирать вполне интересно.
Как сделать загрузочный экран? Вот у меня есть фурнкция, которая загружает данные игры и я хочу, чтоб пока она выполняется у меня параллельно проигрывалась анимация из animation player. Как это сделать?
А что за игра у тебя?
В смысле?
>загружает данные игры
ты тут пишешь.
Вот как-то так: https://docs.godotengine.org/en/3.5/tutorials/io/background_loading.html
Ну и то же самое для четвёртой версии: https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
>загружает данные игры
Да просто читает положение врагов, количество патрон и т.д из текстового файлика.
Не, тут загрузка ресурсов по частям и т.д. А у меня просто текстовый файлик читается и меняются параметры. Мне нужно, чтоб в это время экран темнел и пока файл читается и все записывается проигрывалась анимация.
Читай его как файл из одной части.
Мне просто нужно, чтоб пока он загружался, пока скрипт обращался ко всем нодам и переписывал их данные весел значок загрузки, а не просто когда подгружается сцена.
4.0 сильно сырой? Использует кто уже?
Нет, это как раз то, что тебе нужно. Я по этой инструкции делал загрузочные экраны с анимацией. Суть такова:
1. Создаёшь объект "загрузчик"
2. Каждый кадр выдялаешь несколько (100 в данном примере) миллисекунд на загрузку (загрузчик сам делит этот процесс на части)
3. Если загрузчик кончил, но тебе надо разгрести загруженные данные, напиши аналогичный объект сам: распредели все предстоящие действия в массив и выполняй их подряд по чуть-чуть каждый кадр, после каждого действия сверяясь с временем.
4. Остальное время кадра анимируешь анимированную анимацию.
Отличие четвёрочной версии в том, что сам загрузчик делает свою загрузку в отдельном потоке, в то время как в 3.5 многопоточность (если она тебе нужна) придётся прописывать ручками. Впрочем, раздавать свойства нодам по загруженным данным тебе всё равно придётся руками.
Положняк на ближайшие год-два:
4 для тридэ и десктопа
3 для всего остального
Для мобилок только 3 без вариантов
>Для мобилок только 3 без вариантов
Почему?
Я на четверке сделал себе скринсейвер с часиками в стиле наручных из 90х и одновременно настольных ламповых из 80х. Кайфую, ностальгирую.
Перекатываю на него Берлин.
Четвёрка толще и поддержки меньше. В основном речь о поддержке. На мобилки никто не будет делать игры без рекламы, а рекламные адаптеры на четвёрку ещё не перекатили, наверное.
Спустя столько лет годот наконец-то сделали таким, как я хотел еще тогда: https://www.youtube.com/watch?v=PAtG_fHhIx8
Может ты разбираешься - как можно сделать вот такие процедурно генерируемые острова летающие в воздухе? Что то я пока не могу разобраться. Даже воксель тулс себе поставил, но мне кажется это не то и слишком оверкилл для моего текущего скилла.
Сап пользователям православного движка. Я только потихоньку вкатываюсь, поэтому не бейте за глупый вопрос. Как сделать так, что бы при переходе между сценами музыка продолжала играть в своëм темпе там, где она не сменяется другим саундом? На ютубе туториалы только как вставить музыку в отдельную сцену или вообще во весь проект.
> как можно сделать вот такие процедурно генерируемые острова летающие в воздухе?
Самый простой вариант для лоу-скилла - это сделать в блендере несколько типовых островов, а в игре их процедурно доставать как карты из колоды. Чтобы увеличить разнообразие, эти заготовки при вытаскивании можно поворачивать на произвольный угол. Многие так и делают. Такшта думой.
Просто вставь в автозагрузку сцену с плеером музыки и переключай его из любых других сцен вообще.
До зрелого продукта еще пилить и пилить
Двачую.
Есть нейросети, где можно сгенерировать персонажа в жанре 2D pixel art, а также врагов, здания, оружие, технику, задники и т.д.?
Выше анон упоминал бесплатные ассеты с itch io - в данный момент изучаю их.
Но все-таки хочу что-то свое, оригинальное (бесплатные ассеты хочу юзать только для прототипа).
Есть ли альтернативные ресурсы помимо официальной документации и GD Quest для изучения GD Script и в целом Godot Engine?
Желательно на русском языке, могу пытаться рвать жопу и на английском, переводя каждый абзац, но не знаю, если вдруг есть русскоязычный ресурс для изучения - будет неплохо. Если все дороги все таки ведут на GD Quest, то придется вкатываться в Godot Engine с английского языка и машинного перевода.
Вкатываюсь с нуля, цель просто сделать лёгкую игрушку-кликер с различным функционалом, скорее чисто для себя, а там авось как пойдет, может затянет на долгое долгое время.
Из знаний: немного посидел в годоте, смог сделать кнопку которая ещё и при нажатии записывает сколько у тебя кликов всего произошло.
Из общих знаний: не знаю ЯП от слова совсем
Был период вката в пайтон, из интереса(правда забросил, но какие-либо штуки на очень и очень детском уровне знаю)
Буду благодарен за ответ
Желательно на русском языке, могу пытаться рвать жопу и на английском, переводя каждый абзац, но не знаю, если вдруг есть русскоязычный ресурс для изучения - будет неплохо. Если все дороги все таки ведут на GD Quest, то придется вкатываться в Godot Engine с английского языка и машинного перевода.
Вкатываюсь с нуля, цель просто сделать лёгкую игрушку-кликер с различным функционалом, скорее чисто для себя, а там авось как пойдет, может затянет на долгое долгое время.
Из знаний: немного посидел в годоте, смог сделать кнопку которая ещё и при нажатии записывает сколько у тебя кликов всего произошло.
Из общих знаний: не знаю ЯП от слова совсем
Был период вката в пайтон, из интереса(правда забросил, но какие-либо штуки на очень и очень детском уровне знаю)
Буду благодарен за ответ
Даже если найдешь гайды на русском, а они есть, то без англюсика все равно никуда. Всю документацию и все вопросы-ответы, все форумы, стековерфлоу, реддит и дискорд годота тебе никто не переведет.
Технический английский простой. Не бойся, попробуй.
Ты тредом ошибся, движкосрач там
Хм, за всё время (уже года три как годотствую) я ни разу не пользовался "сменой сцены". У меня в основной сцене куча всякого нужного висит, да та же музыка, гуй тоже там. Если надо уровень сменить - он у меня дитё к какой-нибудь специально обученной ноде; старый удалил, новый заинстансил и добавил на его место. Мне кажется, в туторы "смену сцены" пихают для упрощения, чтобы не морочить новичку голову, а вообще в более-менее полной игре это бесполезная фича. Мне так кожеться.
Зачем нужно нижнее подчеркивание в GDScript?
В уроке на английском, который сейчас смотрю, автор сказал:
"Нижнее подчеркивание в функции
func _physics_process(_delta):
как бы говорит "Я не хочу использовать _delta""
Что он имел ввиду?
В уроке на английском, который сейчас смотрю, автор сказал:
"Нижнее подчеркивание в функции
func _physics_process(_delta):
как бы говорит "Я не хочу использовать _delta""
Что он имел ввиду?
Это из какого-то крупного языка взято
Если ты напишешь delta, но не будешь использовать, у тебя будет предупреждение желтое висеть.
Если написать _delta, то ты сообщаешь что эту переменную не используешь (пока)
В идеале код должен быть без предупреждений.
Подчеркивания в начале функций, например _ready означают другое - что движок будет вызывать эти функции сам.
ОК, спасибо за инфу
>Вот допустим у меня основной персонаж в игре - это транспорт, и я хочу в будущем реализовать возможность менять этот транспорт. Как мне лучше это организовать в сценах?
Зависит от того, какие параметры должны сохраняться независимо от выбранного транспорта. У тебя ведь, скорее всего, кроме транспорта есть ещё пилот и груз. Эти параметры логичнее держать отдельно от KinematicBody3D транспорта.
>В блокбенче кстати делать модельки оказалось легко и интересно. Проблемы с текстурированием правда лень заморачиваться на этом этапе, но вот из кубиков собирать вполне интересно.
Имхо, у блокбенча единственное преимущество - это пикселявое текстурирование "а-ля майнкрафт", а вот моделирование лучше в Blender освоить. При том что в блендере тоже можно пикселявые текстуры рисовать, просто чуть настроить нужно самому.
>Как сделать загрузочный экран?
Делаешь сцену game.tscn и назначаешь её основной сценой, чтобы движок её загружал первой. В неё кидаешь сцену-заслонку ColorRect с чёрным цветом и твоей анимацией загрузки (AnimationPlayer или AnimatedSprite2D, что угодно), а также твою сцену-загрузчик (заслонку лучше расположить выше загрузчика). Возможно, тебе потребуется CanvasLayer, чтобы заслонка была выше всего остального GUI. В своём game.gd цепляешься к сигналу окончания загрузки из своего загрузчика и после этого скрываешь сцену-заслонку (или проигрываешь плавное исчезновение в AnimationPlayer, например, меняя альфу в цвете ColorRect). Всё, теперь игрок видит главное меню и может с ним взаимодействовать. Игровые уровни грузятся аналогично: делаешь заслонку видимой и добавляешь свой уровень потомком к game, после полной инициализации уровня скрываешь заслонку. Тут главное понимать порядок вызова некоторых обработчиков, например, _ready() корня сцены вызовется только после всех _ready() его потомков: если твой загрузчик успевает всё загрузить в своём _ready(), тогда game.gd (корень сцены) может не успеть поймать сигнал завершения загрузки, если ты соединяешь обработчик и сигнал в _ready() корневой ноды. В общем, смотри сам, как у тебя там устроена загрузка.
>хочу что-то свое, оригинальное
@
>нейросети, где можно сгенерировать персонажа
Так ты хочешь "своё, оригинальное"?
Или ты хочешь быстро и без навыков шаблонную кашицу в стиле %юзернейм% из интернета?
Нейросеть изобретал ты? Нет.
Нейросеть обучал на рисунках ты? Нет.
Нейросеть обучали на твоих рисунках? Нет.
Тогда результат работы этой нейросети настолько же "твой, оригинальный" насколько "твой, оригинальный" только что созданный новый мир в Майнкрафте.
>Мне кажется, в туторы "смену сцены" пихают для упрощения, чтобы не морочить новичку голову, а вообще в более-менее полной игре это бесполезная фича. Мне так кожеться.
Я подозреваю, что эта фича в движке - наследие движков нулевых, когда Godot зарождался. Типа для простых 2D игр с уровневой системой (тысячи их) действительно может быть проще менять "сцены" одной функцией API, а всю постоянную информацию хранить в глобальных объектах. Может быть, это влияние Flash или Game Maker, там что-то такое было вроде бы. В общем, мне кажется, эту фичу в Godot притащили откуда-то из другого движка, где концепция смены сцен была важнее.
Интересное сравнение, когда играл в одной группе, мы искали интересные или удачные сиды, так что вполне себе появились выражения "сид игрока%нейм", процесс вполне похожий, и там и там пользователь крутит ручку барабана, но именно отбор - его, получается что-то вроде коллекции над всем множеством.
>Подчеркивания в начале функций, например _ready означают другое - что движок будет вызывать эти функции сам.
Нет, это просто ради одного общего стиля.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#functions-and-variables
>Prepend a single underscore (_) to virtual methods functions the user must override, private functions, and private variables
Вот конкретно _ready, _process, _input и т.д. - это виртуальные методы, они вызываются движком и поэтому должны иметь именно такое название.
>сид игрока
Вот к коллекциям интересных сидов на сайтах вообще никаких претензий нет. А если ты найдёшь какой-то сид с интересным миром, сделаешь скриншоты этого мира и засунешь в свою игру со словами "это мой мир", тут уже будут претензии...
>как можно сделать вот такие процедурно генерируемые острова летающие в воздухе?
Во-первых, ты сразу должен понять, что процедурная генерация не сделает всё за тебя. Хороший генератор игрового мира требует намного больше работы, чем нашлёпать те же объекты вручную.
Во-вторых, ты должен чётко определиться с целью процедурной генерации. Та... штуковина на твоём скриншоте вообще ни о чём не говорит. Тебе нужно сделать множество разных вариантов острова вручную и понять, чего же ты хочешь добиться в игре от своего генератора. Желательно уже иметь базовый геймплей на наборе статичных островов, прежде чем переходить к созданию процедурного генератора. Может быть, по ходу разработки окажется, что генератор тебе вообще не нужен, или нужно что-то совсем другое. Да и самих методов генерации довольно много придумано.
Так что сделай пока в Blender наброски, сделай с ними геймплей игры, потом посмотришь, куда и как можно прикрутить процедурную генерацию.
>Даже воксель тулс себе поставил
Генерация вокселями имеет свои особенности.
>слишком оверкилл для моего текущего скилла
Нужно смотреть не на скилл, а на свои желания.
> из какого-то крупного языка взято
Сначала было в питоне, потом перекатилось в шарп. Богомерзкий кодекондукт. Осуждаю.
Ладно, надеюсь, что я в этом разберусь
Прости, но ты совсем не так понял вопрос. Совсем.
>Прости, но ты совсем не так понял вопрос.
Хм? Тебя интересует, как разбить процесс на части, чтобы окно "мутным стеклом" не покрывалось? В параллельном потоке работать небезопасно, если у тебя не одна операция, а несколько операций с разными нодами в дереве сцены.
В общем, делишь свой процесс на этапы, делаешь счётчик этапов, добавляешь таймер, на обработчик таймера вешаешь match с этапами.
Как-то так (Timer сделай one_shot = true):
>const _FINAL_STEP = N # здесь число
>var _timer := $Timer
>var _loading_step: int = 0
>func _on_timer_tick() -> void:
>_ match _loading_step:
># здесь твои шаги в формате X: действия()
>_ if _loading_step < _FINAL_STEP:
>_ _ _loading_step += 1
>_ _ _timer.start()
>_ else: queue_free()
Первый раз запускать таймер лучше в _ready() основной сцены, т.е. game.gd, когда всё готово.
> Как-то так
Ну анон, ну пастебин же есть с поддержкой гдскрипта, ну что же ты мучаешься?
>делишь свой процесс на этапы,
>делаешь счётчик этапов,
>вешаешь match с этапами.
В общем, так я и сделал у себя, только без таймера. Не помню уже, почему я тогда избегал таймеров.
В видео начиная с 0:18 заметно, как идёт активная работа с нодами сцены - анимация загрузки местами заметно дёргается из-за того, что GridMap принимает в себя слишком толстые порции данных и подвисает (т.к. сама генерация данных крайне быстрая). Вероятно, это можно исправить, выделив всё это дело в отдельный процесс, но такие заикания загрузки я видел во многих ААА играх, даже в GTA, так что всё норм, а возиться с потоками мне лень. Главное что игра показывает анимацию загрузки, которая как бы говорит "падажжи, ща всё будет". Да не будет ничего, я уже несколько раз мотивацию потерял, даже не знаю теперь, зачем игры делать...
>пастебин
Зачем, если можно прямо тут набрать?
>ну что же ты мучаешься?
Так я в любом случае "мучаюсь", набирая код на гугловской клавиатуре андроида, лишний "_" поставить не лень. Кому нужен код, пусть сами набирают, копипастить код из интернета вредно, и языки со значимыми отступами от этого отучивают. А я просто абстрактный пример накидал, считай, что это так называемый "псевдокод".
О, придумал как сделать лучше, без константы:
>func _on_timer_tick() -> void:
>_ match _loading_step:
>_ _ 0: do_a()
>_ _ 1: do_b()
>_ _ 2: do_c()
>_ _ _: queue_free(); return
>_ _loading_step += 1
>_ _timer.start()
Вариант "_:" сработает при любом значении, которое не попадалось выше (не 0, 1, 2); это аналог default/else из других языков. Команда "return" завершит метод до выполнения следующих двух строчек, следовательно, запуска таймера не произойдёт. После queue_free() в данном случае обязателен return, поскольку этот метод не удаляет объект сразу, а только назначает его в очередь на удаление, поэтому метод продолжит выполняться, а нам этого не нужно. Точка с запятой разделяет две команды, записанные на одной строке (вроде бы руководство по стилю Годо рекомендует писать каждую команду на новой строке, но интерпретатор GDScript поддерживает запись всего кода в одну строку).
Таким образом, можно просто вставить новый этап:
>_ _ 2: do_c()
>_ _ 3: do_d() # новый этап
>_ _ _: queue_free(); return
И не придётся менять значение константы. Это намного удобнее, если у тебя постоянно меняется количество этапов загрузки/генерации данных.
В своём коде константу использовал, т.к. там мне нужно было считать время выполнения каждого шага, и я не мог просто пропустить конец метода.
Меня интересует, как сделать так. Вот у меня есть скрипт load, в котором открывается текстовый файл, копирует данные из него в переменную, а потом просто цикл, который загружает данные в ноду. Что-то вроде
func load():
__var file = File.new()
__file.open("user://save_game.dat", file.READ)
__var content = file.get_as_text()
__var contentFormat = тут форматирует content
__file.close()
____for node in nodes:
_______node.global_position = contentFormat[node][global_position]
И чтоб во время выполнения этой функции на экране висела анимация. В моём случае крутящаяся шестеренка на черном фоне.
Во-первых, нужно смотреть, что у тебя занимает так много времени, что нужно включать заставку. Уже это что-то нужно как-то оптимизировать.
Во-вторых, самым простым будет попробовать создать отдельный поток, но это небезопасно, т.к. нельзя писать в одну и ту же ячейку памяти из разных потоков. Я бы провёл тесты для начала.
В-третьих, если тебе нужно разбить всё на этапы в один поток, тогда делай как-то так:
>signal init_done
>const INIT_BATCH = 10 # отрегулируй по тестам
>var nodes: Array = ... # заполни заранее
>var init_from: int = 0
>@onready var _timer := $Timer
>func _init_nodes() -> void:
>_ var init_to = init_from + INIT_BATCH
>_ if init_to > nodes.size(): init_to = nodes.size()
>_ for node_id in range(init_from, init_to):
>_ _ nodes[node_id].global_position = content[node_id].pos
>_ init_from = init_to
>func _on_timer_timer() -> void:
>_ _init_nodes()
>_ if init_from < nodes.size():
>_ _ _timer.start() # следующий цикл
>_ else:
>_ _ init_done.emit() # сообщаем, что всё сделали
>_ _ queue_free() # если больше не нужен загрузчик
Как чтение из файла разделить на этапы вроде уже выше ссылку кидали, но это если у тебя файл очень большой и слишком долго считывается.
Чтение из файла, да и не хочется, чтоб игрок видел, как объекты прыгают или исчезают, когда он загрузку нажал.
А можно как-нибудь вывести в отдельный поток чисто анимацию в AnimationPlayer? Чтоб она просто проигрывалась там, а вся загрузка в основном была. Что-то вроде пикрила
Я не понимаю, что твой код делает. Зачем тут вообще таймер?
>И чтоб во время выполнения этой функции на экране висела анимация. В моём случае крутящаяся шестеренка на черном фоне.
Это уже делай примерно как здесь:
>Делаешь сцену game.tscn и назначаешь её основной сценой, чтобы движок её загружал первой. В неё кидаешь сцену-заслонку ColorRect с чёрным цветом и твоей анимацией загрузки (AnimationPlayer или AnimatedSprite2D, что угодно), а также твою сцену-загрузчик...
Если ты хочешь обойтись без game.tscn, то можно попробовать сделать на глобальных автолоадах, но лично я не рекомендую так делать, потому что обмазанный глобальными переменными код сложно портировать.
Я бы вообще избегал глобальных переменных даже в рамках одного класса, отправляя в методы побольше аргументов вместо обращения к полям класса; т.е. вместо
>_init_nodes()
должно быть что-то вроде
>init_from = init_nodes(init_from, nodes)
тогда можно более универсальный метод написать, для разных ситуаций в рамках одного класса.
Чел в том посте написал, как сделать анимацию, а мне нужно, как сделать так, чтоб анимация проигрывалась одновременно с функцией выполнения загрузки. Мне не нужно знать, что там загрузилось, на сколько процентов. Просто анимация и всё
>Чтение из файла
Сколько килобайт? Даже на жёстком диске будет моментальное чтение в пределах пары мегабайт. Вот изменение параметров тысяч нод может занять время больше одного кадра (условно, 16 мс).
>А можно как-нибудь вывести в отдельный поток чисто анимацию в AnimationPlayer?
Эээ, не знаю, вроде бы пока что нельзя, потому что всё дерево сцены обрабатывается одним потоком (т.е. движок обходит все ноды в одном цикле и говорит "рисовай", "физиковай", "обрабатовай ввод" каждой ноде лично). Чтобы разделить дерево сцены на потоки, нужно писать свою реализацию MainLoop, что нерационально ради одной только крутящейся шестерёнки. Вроде бы Хуан хочет разделить дерево сцены на потоки из коробки, но когда они это сделают - неизвестно, скорее всего не раньше 4.2.
>Я не понимаю, что твой код делает.
Если ты совсем ньюфаг, зачем в такие сложности лезешь? Вряд ли у тебя тысячи нод настраивать нужно, что требуется анимация загрузки.
>Зачем тут вообще таймер?
Чтобы распределить процесс на несколько кадров. Можно сделать аналогично с помощью _process, но таймером проще добавить паузу в миллисекундах - не нужно вручную считать дельту кадров. Также это избавит от проблем, если у кого-то там монитор 240 Гц, хотя это можно исправить переносом кода в _process_physics - там гарантированное число тиков в секунду, заданное в настройках проекта (по умолчанию 60).
>Если ты совсем ньюфаг, зачем в такие сложности лезешь? Вряд ли у тебя тысячи нод настраивать нужно, что требуется анимация загрузки.
А откуда мне знать, что анимация загрузки это сложность? Это ж в каждой игре есть на базовом уровне. Я в душе не ебал, что это такая проблема.
Я вижу, что у меня пролаг есть, пока игра загружается и первая моя мысль это скрыть его под анимацией загрузки. Ведь пока он маленький, но все равно выглядит уродски, видел хоть одну игру, где при загрузки сначало микрофриз, а потом все объекты у тебя на глазах телепортируются? Я вот нет а потом может быть и не маленький.
То есть вся та хуйня с таймером расчитана на то, что все будет загружатся не сразу пока функция выполняется, а каждый кадр, пока не загрузится?
>анимация проигрывалась одновременно с функцией выполнения загрузки
Ну давай разберёмся, что значит "одновременно".
В основе любой игры лежит мейн луп, например:
>while true:
>_ for node in nodes:
>_ _ node.process()
>_ _ node.process_physics()
>_ _ node.input()
Конкретную реализацию в Godot смотри в исходниках движка, мне лень сейчас копаться.
Вот допустим, что твоя функция загрузки выполняется где-то. Если она занимает <16 мс и твоя частота кадров 60, то ты даже не заметишь, что твоя функция уже выполнила работу. Если она занимает >16 мс, то ты заметишь очень короткую просадку кадров или "заикание". Если она занимает больше сотен миллисекунд, игра покажется зависшей, а если больше нескольких секунд - Windows покроет окно игры белой хренью и начнёт крутить на указателе мышки колёсико/песочные часы.
Вот загрузочный экран тебе нужен только в последнем случае, и чтобы не происходило эффекта "зависания", тебе нужно разделить твой процесс загрузки на несколько этапов, которые ты будешь выполнять между разными итерациями while true мейн лупа. Это понятно?
Ты можешь, конечно, создать отдельный поток, в котором будет твоя загрузка, но кто знает к чему это приведёт на конкретном железе и ОС... Особенно когда ты будешь со временем увеличивать сложность игры и объём контента. Лишняя головная боль, если у тебя вся загрузка за одну секунду происходит.
То есть мне нужно, чтоб моя функция в _process выполнялась по частям настолько маленьким, чтоб часть функции проходила незаметно быстро и не стопорила анимацию?
Игру делай. Полишингом полоски загрузки будешь заниматься в последний месяц перед релизом. А то глупо выйдет, если у тебя самая лучшая полоска загрузки в мире, а игры нет. Недавно как раз статья выходила на эту тему. https://habr.com/ru/news/745322/comments/
>видел хоть одну игру, где при загрузки сначало микрофриз, а потом все объекты у тебя на глазах телепортируются?
Тупо любая ААА игра, заходишь в GTA 5/Online и наслаждаешься фризами + телепортациями. Самое смешное, когда заходишь в лифт в помещении, в котором НЕВОЗМОЖНО умереть, и УМИРАЕШЬ во время загрузки из-за какого-то бага.
>вижу, что у меня пролаг есть
Я тебе говорю - растяни на весь экран ColorRect с чёрным цветом и скрывай его, когда завершишь загрузку. Если вся твоя загрузка занимает меньше пары секунд, то ничего не заметишь. Так делают в каждой первой инди-игре, при том некоторые умудряются покрываться белой хренью под Windows во время загрузки, но никто на это не жалуется - все привыкли.
>расчитана на то, что все будет загружатся не сразу пока функция выполняется, а каждый кадр, пока не загрузится?
>моя функция в _process выполнялась по частям настолько маленьким, чтоб часть функции проходила незаметно быстро и не стопорила анимацию?
Гениально, Шерлок, вы раскрыли это дело!
Маленькие заикания в анимации загрузки не страшны и наблюдаются практически во всех играх, не считая совсем уж примитивных.
Спасибо, теперь ясно всё
>Маленькие заикания в анимации загрузки не страшны
Пиздец ты говноедище, лол. У тебя вместо игры какое-то фризящее дерьмо получается, а ты рассказываешь что это дерьмо не страшно и вообще нормально.
У тебя стокгольмский синдром?
>фризящее дерьмо получается
>не страшно и вообще нормально
Возьми любую инди-шминди с генерацией уровня и красивой анимацией загрузки - 100% будет пукать на любом железе во время загрузки, но зато потом плавный геймплей, потому что всё загрузилось.
Не всё можно разбросать по ~16 мс пачкам и не всегда такой разброс рационально делать.
Даже ААА будет тормозить и заикаться на загрузке, зато потом стабильные 30+ ФПС даже на слабом ПК.
покормил тролля из движкосрача
В доках мало инфы по Networking для Godot 4.
Кто-то занимался мультиплеером в Godot? Можете покидать гайдов/статей?
Кто-то занимался мультиплеером в Godot? Можете покидать гайдов/статей?
>В доках мало инфы по Networking для Godot 4.
Сколько было, столько и осталось.
https://docs.godotengine.org/en/3.5/tutorials/networking/index.html
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
>мультиплеер
>Можете покидать гайдов/статей?
Тебе конкретно что нужно?
- онлайн-доски рекордов;
- P2P кооператив/мелкий PvP;
- авторитарный сервер;
- кластеры серверов как в ММО.
В общем-то мультиплеер в основном на сервере происходит, если тебе нужно больше 2-4 игроков и максимальная защита от читеров.
Присоединяюсь к вопросу (другой анон). А если конкретнее: как сделать что-то типа десматча? Один общий уровень, несколько игроков на нём друг друга убивают. Один создал, другие подключились. Я смотрел что-то про новые крутые сетевые ноды в четвёрке, но пока не понимаю даже, как в целом сцены организовывать.
И да, интересно не только (не столько) по четвёрке, но и по тройке тоже.
>что-то типа десматча
Про high level multiplayer уже читал?
> У тебя говно лагает, переделывай.
@
> ВРЁТИ ВРЁТИ ВРЁТИ ЭТО У ВСЕХ ЛАГАЕТ ЛАГИ НЕ СТРАШНЫ ФРИЗЫ НЕ СТРАШНЫ ВЫ ВСЕ ТРОЛИ ЕСЛИ ПРОТИВ!!111
Блядь, ты совсем больной дебил что ли?
> Так я в любом случае "мучаюсь", набирая код на гугловской клавиатуре андроида, лишний "_" поставить не лень. Кому нужен код, пусть сами набирают, копипастить код из интернета вредно, и языки со значимыми отступами от этого отучивают. А я просто абстрактный пример накидал, считай, что это так называемый "псевдокод"
Аргументы - моё почтение. Убедил.
>говно лагает
Ты перебираешь циклом огромный массив ячеек, в которых записаны данные уровня, скажем, миллион ячеек (минимум для Террарии). Не просто перебираешь, а ещё считаешь какую-то формулу, вроде симуляции движения воды. У тебя два стула:
1. Разбить процесс на шаги определённого размера, которые, возможно, будут проходить менее чем за один кадр на определённом минимальном железе, но на более слабом всё равно будут тормозить, а разбивка на шаги замедлит загрузку мира для ВСЕХ игроков, даже с самыми быстрыми компьютерами из-за ожидания между шагами, счётчиков и if-ов.
2. Оставить всё как есть, ибо процесс завершается за пару-тройку секунд и ни юзер, ни ОС не успевают подумать, что игра зависла, а на короткую задержку анимации загрузки вообще всем насрать, пока игра загружается быстро и потом работает плавно.
Ты можешь разбить процесс на потоки, в некоторых случаях даже на несколько потоков (заполнять четверть массива в четырёх потоках), но это не всегда возможно и на более слабом железе всё равно вызовет тормоза в анимации из-за того, что одно ядро не справляется со всеми твоими потоками, которые прут на 100% скорости, не оставляя времени ЦПУ для твоего основного процесса - т.е. отображения анимации в окне (и ещё нужно ловить все события окна, иначе Windows решит, что приложение зависло, и предложит его закрыть). Так что это не решает исходную проблему (задержки в анимации), даже если ускоряет процесс за счёт многопоточности. Может помочь назначение дополнительным потокам более низкого, чем у основного, приоритета, чтобы ОС сфокусировала силы ЦПУ на анимации в окошке, но тогда твоя загрузка опять же замедлится.
Повторяю, речь идёт об анимации загрузки уровня, на которую давно никто не смотрит, потому что она ничего по факту не отображает (игра может "зависнуть" где-то у себя внутри в каком-нибудь while true цикле, но при этом продолжать крутить бесконечное колёсико загрузки, как будто чем-то занята). Если у тебя долгая загрузка, игрок может вообще от компа отойти, как в случае со многими ААА играми, и ему абсолютно насрать на твою анимацию, какой бы плавной она ни была.
Что-то типа террарии, мультиплеер на 4-8 игроков, которые у себя хостить сервер будут, античит не нужен.
Для 3.5 не нужно, а для 4.+ эти статьи уже читал. Нужны гайды, чтобы конкретные решения увидеть с более сложными примерами. Посмотреть, как код организовывают. Подводные камни разные.
Еще не понятно, можно ли создать одновременно dedicated server и ad-hoc сервер в клиенте?
Из-за того что нужно прописывать в общий для процесса (окна?) multiplayer.multiplayer_peer = peer, то, выходит, нельзя сначала создать server_peer, а потом client_peer, и подключить один к другому в рамках одного процесса, потому что multiplayer постоянно используется в логике с сетью.
Любая загрузка данных делается в простейшем планировщике задач и планировщик задач определяет анимации просто более высокий уровень исполнения, как и I/O. Саму задачу прохода по данным разделяют на части и выполняют не в одном кадре, а десятках или даже сотнях, чтобы никаких лагов не было. Все задачи не общим скопом выполняются, а висят в планировщике, по этому никогда никаких лагов или зависания процесса в нормальных приложениях нет, если лаги есть - приложение создавали умственно отсталые дегенераты которые не смогли сделать нормальный планировщик.
А ты какую-то полную хуйню нафантазировал, просто бред нахуй.
>умственно отсталые дегенераты которые не смогли сделать нормальный планировщик
Вот только у них 1151172 отзывов в Стиме...
Делайте игры лучше.
https://www.opennet.ru/opennews/art.shtml?num=59412
Выпуск открытого игрового движка Godot 4.1
Выпуск открытого игрового движка Godot 4.1
>острова летающие в воздухе
>модельку кораблика
А у тебя есть какой-то конкретный концепт игры или ты просто так, от балды что-то лепишь?
У меня похожие идеи были, но я забросил их.
> какой-то конкретный концепт игры
Осторожно предположу, что тот анон делает фанфик по аниме, было такое, с летающими островами и кораблями. Недавно на рестарте видел.
мимо
>аниме, было такое, с летающими островами и кораблями
Лет как 300 уже такое всплывает то тут, то там.
Ну в общем-то да. Сюжетец потасканный порядочно.
>аниме, было такое, с летающими островами и кораблями. Недавно на рестарте видел.
Что за аниме? Интересно.
Когда Worlds Adrift загнулись, появилось много проектов поменьше, в которых что-то похожее.
Я тоже хотел что-то похожее сделать, но понял, что меня это как-то не затягивает. WA было интересно тем, что там есть что исследовать (пусть даже не процедурное, а сделанное другими игроками), а когда делаешь всё сам, то исследовательский компонент отпадает напрочь и остаются только корабли и пустое небо с редкими летающими кусками земли. Сражения меня совсем не привлекают, а механика строительства как ни крути оптимизируется игроком до летающего куба, так как дизайнить что-то другое смысла нет.
У того анона что-то другое, вот и интересно, что.
> Что за аниме? Интересно.
Полчаса искал - не нашёл. Казалось было недавно, но уже куча просмотренных видосов в истории. Не найти. В гугле по запросу "аниме про летающие корабли -космос -космич" выдаёт атаку титанов Last Exile: Gin'yoku no Fam, но это не то, что я видел ранее.
Игры-то делаете?
Это тролленк такой или ты так тред бампаешь?
Это классика, это знать надо.
Да, он так бампает
4.1.1 уже готовится. Пиздос они ускорились конечно.
Предпочитаю не качать патч-версии лишний раз.
>они ускорились
Как и обещали.
https://godotengine.org/article/release-management-4-1/
Даёшь Godot 5.0 в три года!
Еее! Вот это по нашему!
Пока 4.4 не выйдет,это сырое поделие
и чё там будет чё-то? А то пока похоже, что лучше бы не выпускали четвёрку.
Ты так про трёщку писал, ждун, ну и где твои игры. Признай, ты просто прокрастинатор. Пасаны делают игоры прямо на релиз-кандидате и не парятся. К своему релизу как раз и релиз движка подъезжает.
Я правильно понимаю что надо без задней мысли просто читать документацию как учебник и потом уже что-то начинать делать в самом движке? Никогда программированием не занимался раньше.
>Никогда программированием не занимался раньше.
Я бы в таком случае порекомендовал начинать с видео-туторов. Вкатываться в Class Reference без опыта взаимодействия с этим явлением может оказаться сложно. Изучаешь любые доступные туторы, параллельно почитываешь эти самые описания классов в доках, таким образом учишься черпать информацию уже оттуда.
Читать доки как учебник - это риск потерять интерес. Там, конечно, есть раздел Step by step, но он довольно минималистичный, его писали программисты, так что там много мест, где информация подаётся слишком плотно, чем может воспринимать неподготовленный человек.
Спасибо за совет.
https://gdquest.github.io/learn-gdscript/
А как тебе эта штука? На неё ссылка в документации, говорят про новичков сделали.
Годно. У ГДКвеста хорошие гайды, будь то ютуб или вот такие отдельные
А тут можно как-то делать общие проекты? Типа чтобы код могли открывать несколько человек сразу.
>делают игоры прямо на релиз-кандидате
ИГРАЛ В РАЗРАБОТКУ ИГР НА ПРЕАЛЬФЕ ДВИЖКА
@
ПРОИГРАЛ
>чтобы код могли открывать несколько человек
Для этого существуют системы контроля версий.
https://docs.godotengine.org/en/stable/tutorials/best_practices/version_control_systems.html
Я видел пару прототипов, но тема особо не взлетела
https://github.com/thimenesup/GodotNetworkedSceneEditor
https://github.com/godot-extended-libraries/godot-mixer
> код могли открывать
Если именно код, то можно воспользоваться какой-нибудь vs code там есть соответствующий режим.
Зачем это вообще нужно?
Можно ведь экран шарить.
>тема особо не взлетела
Потому что не нужно.
Чем отличается key от key(physical)? Годот последней версии
Из мануала, встроенного в движок:
>bool is_physical_key_pressed ( Key keycode ) const
>Returns true if you are pressing the key in the physical location on the 101/102-key US QWERTY keyboard. You can pass a Key constant.
>is_physical_key_pressed is recommended over is_key_pressed for in-game actions, as it will make W/A/S/D layouts work regardless of the user's keyboard layout. is_physical_key_pressed will also ensure that the top row number keys work on any keyboard layout. If in doubt, use is_physical_key_pressed.
https://ru.wikipedia.org/wiki/Скан-код
>На клавиатурах другой раскладки (например, AZERTY) скан-коды соответствуют расположению клавиш: так, у французского A скан-код как у американского Q. Преобразованием скан-кодов в коды нажатых клавиш занимается ОС или BIOS.
Пока писал, анон выше уже ответил. Но все равно отправлю уж.
Если ты делаешь рогалик и тебе важно чтобы действие Apply происходило при нажатии на кнопку, на которой написано A, а действие Zap на кнопку, на которой написано Z, делаешь обычную.
А если делаешь платформер и тебе надо чтобы движение было на кнопках, которые находятся там, где в англ. раскладке WASD, а прыжок на кнопке под ними, где обычно находится Z, то физическую.
Ну чё ёпта? Время тупорылых вопросов.
Решил освоить godot. Посмотрел гайдик RPG Items in Godot Engine!. Там чувак начинает с того что пишет:
export(String) var ITEM_NAME например. У него export высвечивается красным и работает, у меня ругается что "unexpected "Identifier" in class body". Пытался гуглить - нихуя. Смотрел доки на сайте годота и нашёл только @export. Гайд годичной давности может там поменялось что-то с этим экспортом. Как узнать что теперь с export? Как он работает? Или я туплю где-то?
Решил освоить godot. Посмотрел гайдик RPG Items in Godot Engine!. Там чувак начинает с того что пишет:
export(String) var ITEM_NAME например. У него export высвечивается красным и работает, у меня ругается что "unexpected "Identifier" in class body". Пытался гуглить - нихуя. Смотрел доки на сайте годота и нашёл только @export. Гайд годичной давности может там поменялось что-то с этим экспортом. Как узнать что теперь с export? Как он работает? Или я туплю где-то?
Если там tool или export, то это для Godot 3
Если @tool или @export, то это Godot 4
Между ними много общего, но есть и различия.
Доки можно переключать между версиями.
Спасибо. Глянул и нашёл, что "tool или export" в старой версии, в новой именно @tool, @export.
Различий между 3 и 4 много. Ищи гайд именно под свою версию, а то заебешься переделывать.
Прошел 80% курса "делаем свою первую 2д игру". Я нуб в программировании, и вроде бы многое понятно, а многое просто возникает из ниоткуда, и по тексту ощущение как будто я должен это всё сходу понимать. В итоге очень сложно, конечно.
До этого прошел курс ГДскрипта, и часто меня путало то, что вроде бы задача есть, ок, но многое как будто невидимое. Типа ты делаешь задачу, а там уже под ней какие-то вещи сделаны, и ты просто решаешь задачу а то что именно происходит сейчас и каким образом - неясно. В итоге как будто ничему не научился кроме каких-то базовых вещей "что такое array", "какие есть типы данных", "что такое функция" и базовый синтаксис. Сложно...
До этого прошел курс ГДскрипта, и часто меня путало то, что вроде бы задача есть, ок, но многое как будто невидимое. Типа ты делаешь задачу, а там уже под ней какие-то вещи сделаны, и ты просто решаешь задачу а то что именно происходит сейчас и каким образом - неясно. В итоге как будто ничему не научился кроме каких-то базовых вещей "что такое array", "какие есть типы данных", "что такое функция" и базовый синтаксис. Сложно...
>До этого прошел курс ГДскрипта
что за курс?
Это нормально. Новой области с нуля так и обучаются.
То есть у тебя есть некие знания
..0...1...
Ты проходишь туториал и по разным вопросам у тебя знания вырастают
..2.1.3.21
Потом ты повторяешь какие-то моменты, в других туториалах или во время практики, начинаешь находить взаимосвязи
.14.325.26
Через некоторое время, 2 недели, месяц, многое забывается
.12..15.13
В этот момент повторяют материал, после чего он закрепляется и уже не так сильно забывается в будущем
.24.436.15
Парадокс в том, что если взять условную книгу по информатике где все рассказывается с нуля, с битов и байтов, с отливки процессора из песка результат будет похожим, ведь ты будешь забывать то незнакомое что прочитал.
Поменяется только форма, допустим ты читал с начала
43121...1..
Условно говоря, чтобы сделать игру, тебе в любом случае нужен определенный набор знаний. А какие-то возможно не пригодятся, но все равно набор довольно универсален между разными программами и разными людьми.
XXX..XX.XX
Так что вопрос только в пути, каким ты туда доберешься.
Если учишься по гайдам для третьей версии, то и юзай третью версию. Освой сначала её, потом перекатиться на четвёрку успеешь. Самостоятельно адаптировать гайды под четвёртый Годот на твоём уровне знаний может быть слишком сложно, не рекомендую.
А можно где-то почитать все изменения синтаксиса годота? По патчнотам искать не хочется, а хочется список, в котором например слева export, а справа @export. Ну и какой-нибудь комментарий для более сложных вещей которые сильно поменялись типа TileMap
>- онлайн-доски рекордов;
Допустим?
> Ваше мнение
Я возмущен до глубины души! Почему они не делают инструментов для интеграции своего физ-движка? Ведь очевидно же ,что несмотря на опенсорсность годота, подавляющее большинство игор будет релизиться под собственническими лицензиями. Вот и дали бы тогда АПИ для интеграции проприетарной физики ХАВОК, например. Вопросы закупки лицензий остаются на совести геймдевелоперов. Нет, блять, сидели, изобретали велосипед, который не получился.
10 лет пиздели про модульность движка, и на выходе имеем, что самая важная часть - физика - не модульна, прибита гвоздями, невозможно легко подключить свою.
>невозможно легко подключить свою.
>буквально ссылка на аддон где легко подключили свою
Хм, что-то с твоим утверждением не то.
Да я просто по ссылке не ходил. Ну если свою легко, тогда да, сорян. Дайте мне ссылку на подключение хавока. Хавок хочу.
>самая важная часть - физика
Схуяли?
Назови 5 игр, где физика используется в геймплее хотя бы на уровне Халф-Лайф 2.
Дублирую вопрос из вопросотреда, мне анон посоветовал уточнить здесь. Я хочу сделать рогалик - эдакий клон ДФ. В качестве основного принципа я хочу использовать ECS. Мне для быстрой реализации анон посоветовал по принципу MVP запилить свою ECS либо через GDExtentions, либо через модуль годота, либо через шарп. Что вы, анончики, как специалисты годота думаете по этому поводу?
Я неспешно пилю игрушку на таких принципах, подход рабочий.
Пробовал разные сишные либы, остановился на flecs. Entt чем то не понравился.
Скриптом собираю игровую логику в .so (на винде была бы .dll), сам flecs собран один раз и каждый раз не перекомпилируется.
Второй этап - scons собирает gdnative библиотеку (у меня годот 3, но в 4 то же самое +- с gdextensions). Эта либа-обертка.
Таким образом примерно выходит, что игровая либа - это чисто model, она ничего не знает о годоте. Она занимается игровым миром, юнитами/персонажами, их здоровьем, снаряжением, уроном и т.д.
Обертка же мало что знает об игре, но знает о годоте через godot.hpp. Ее задача в основном дергать тик игрового мира, передавать команды в игру, и возвращать массивы объектов для отображения. так что она примерно view-controller.
Сам же гуй на гдскрипте, и он уже может спокойно обращаться к обертке как будто бы она тоже на гдскрипте.
Некоторые вещи я еще не продумывал, например спецэффекты, события, но это вроде решаемо.
Рекомендую для начала забить на оптимизацию и все мудрёные технологии. Это ведь твоя первая игра? Или первый рогалик? Попробуй сделать на GDScript и других встроенных инструментах 2D поле, по которому игрок может ходить и что-то делать. Проверь свои гениальные геймдизайнерские идеи и убедись, что они они не работают так, как ты нафантазировал. Жонглируя идеями, делай множество прототипов в поиске того самого, который можно превратить в полноценную игру. Когда наиграешься в свой прототип, будешь переписывать с нуля на тех технологиях, которые посчитаешь нужным в соответствии с полученным из прототипов опытом.
Вот Katabasis в соседнем треде делал на ECS, и что? Геймплей не вылизан, баланса нет, куча абсурдных багов и всё это дико тормозит, а автор признался, что ECS только задерживает всю разработку.
Касательно MVP, делать модель в отрыве от всего можно только если ты чётко знаешь, какой должна быть твоя модель (что в ней есть, по каким правилам работает, какие состояния может принимать и т.д.). В геймдеве так не бывает, за исключением совсем простеньких игр. Лучше сделать несколько механик тяп-ляп за пару дней и убедиться, что они тебе вообще не нужны, чем несколько месяцев делать оптимальную модель всей игры вслепую и потом не понимать, почему получилось унылое говно.
Простой рогалик на Godot делается легко и просто, оптимизировать там нечего. Это ведь не стратегия с тысячами независимых юнитов, в рогаликах редко встречается даже десяток юнитов в одном месте.
>неспешно пилю игрушку на таких принципах
>игровая либа - это чисто model, она ничего не знает о годоте. Она занимается игровым миром, юнитами/персонажами, их здоровьем, снаряжением, уроном и т.д.
Мне интересно, как выглядит твой цикл разработки?
1. Написал +100500 строк кода в библиотеку;
2. Отошёл поесть пока код компилируется;
3. Запустил игру...
4. Играешь...
5. Записываешь баги в блокнот?..
6. Исправляешь баги в библиотеке?..
Сколько дней занимает одна итерация цикла?
Просто GDScript позволяет сократить этот цикл до считанных секунд, и в этом его преимущество перед другими подходами. Не представляю, как можно писать игру с циклом больше, скажем, часа.
А переписать готовую игру с чёткими алгоритмами хоть даже на ассемблер всегда успеешь.
>почитать все изменения синтаксиса годота
>хочется список
Документацию ты не открывал?
https://docs.godotengine.org/en/stable/tutorials/migrating/index.html
https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html
>Назови 5 игр, где физика используется в геймплее
GTA 3, GTA VC, GTA SA, GTA IV, GTA 5.
Godot Physics - глючный и тормознутый.
Bullet Physics - проверенный временем и быстрый.
Jolt Physics - по сообщениям самих авторов - до сих пор в состоянии недоделки с принципиально нерешаемыми проблемами и ограничениями. Компенсирует только многопоточностью, ради которой они этот велосипед изобрели, вместо прикручивания многопоточности в Bullet.
>инструментов для интеграции своего
Каких инструментов, лалка? Если ты такой маэстро клавиатуры, иди строчи GDExtension модуль. А если ты новичок без опыта кодинга, то бери что есть.
>самая важная часть - физика - не модульна
Во-первых, в 3.x физика - это модуль движка, берёшь и пишешь свою или подключаешь стороннюю, но с перекомпиляцией движка.
Во-вторых, в 4.x переделали GDNative в GDExtension в том числе чтобы подключать стороннюю физику без перекомпиляции движка.
>Дайте мне ссылку на подключение хавока.
Сам пиши. Хавок платный. Купи хавок и пиши.
Спасибо
Я хочу ECS в первую очередь из-за самого подхода, мне нравится идея систем, которые обрабатывают все элементы по очереди и что можно например тупо добавить компонент "лучник" орку и получить орка-лучника. Ну и я хочу всё таки что-то дфо подобное, то есть иметь возможность обрабатывать как раз тысячи субъектов, которые способны взаимодействовать между собой без вмешательства игрока.
>тупо добавить компонент "лучник" орку и получить орка-лучника
Для этого не нужен ecs, для этого даже ec подойдет, то есть архитектура годота с нодами.
Ты короче дегенерат, а так пиши естественно как хочешь.
>можно например тупо добавить компонент "лучник" орку и получить орка-лучника
В ООП это решается композицией/агрегацией. Никто не хардкодит орка-лучника, орку просто дают лук.
>дфо подобное
>тысячи субъектов
DF я лично ниасилил из-за нечитабельной графики, но слышал, что DF пожиже и пониже, чем RimWorld, который на юнити и у которого от силы десяток юнитов на базе, не считая животных и растений.
Советую сделать так. Сначала набросать прототип с минимально необходимым числом юнитов. Это даст возможность оценить и сбалансировать механики для большинства игроков. Потом уже думать о том, какие оптимизации можно внедрить, чтобы расширить мир и нафлудить юнитов. И нужно ли вообще.
Не ругайся на новичков. У нас тут
>тред любви, взаимопомощи
С одной стороны пожиже, а с другой там где ДФ имеет крепость в эдак сотню бород, Римворлд начинает попёрдывать на десятке колонистов. Спасибо, буду думать.
>ДФ имеет крепость в эдак сотню бород, Римворлд начинает попёрдывать на десятке колонистов
Нужно смотреть на то, что вокруг этих юнитов происходит. Недавно читал где-то, что в DF животные ничего не едят и не умирают от голода, растения не растут и ещё куча систем просто отсутствует. Т.е. ресурсы ЦПУ по-разному распределены между системами игр. Ну и DF вроде на чистом C написан, ближе к железу.
Конечно, если тебе обязательно нужна масштабность, то рано или поздно придётся делать низкоуровневые оптимизации или даже переписывать код. Но прежде чем замахиваться на масштабность, нужно создать хоть что-то, что может стать игрой, если ты, конечно, не планируешь один-в-один копировать уже существующую игру, которую ты очень хорошо знаешь.
Короче, вот:
https://habr.com/ru/companies/miip/articles/308286/
>2. Прототипирование (Prototyping)
>Важный этап проектирования любой игры – это создание прототипа. То, что хорошо выглядит «на бумаге», совершенно не обязательно будет интересно в реальности. Прототип реализуется для оценки основного игрового процесса, проверки различных гипотез, проведения тестов игровых механик, для проверки ключевых технических моментов.
>Очень важно на этапе создания прототипа реализовывать только то, что нужно проверить и в сжатые сроки. Прототип должен быть простым в реализации, т.к. после достижения поставленных перед ним целей, он должен быть «выкинут». Серьёзная ошибка начинающих разработчиков – нести временную инфраструктуру и «костыли» реализации кода в основной проект.
Godot максимально заточен под прототипирование, поэтому его так часто используют на геймджемах и даже крупные студии присматриваются.
Написал же - неспешно.
Ты сильно переоцениваешь время компиляции.
Я специально замерил сейчас, 7 секунд на некроноуте. На более современном компе это будет мгновенно.
Я там не просто так упомянул .so/.dll. Статической линковки нет, это значит, что при каждом запуске я не персобираю годот, враппер, флекс, небо и аллаха, а только игровую логику.
Ну и да, я записываю в блокнот баги, это же не аркада с одним спрайтом на геймджем, а игра с глубоким и богатым геймплеем. Но блокнота пока хватает.
Цикл проверки в рогаликах какбе тоже небыстрый. Катка полчаса занимает минимум. Как раз норм время почуствовать разницу если изменил баланс.
И да, заметное время разработки вообще проходит в блокноте и экселе. Рассчитать там всякие графики, сколько золота доступно на каком уровне и сколько стоят шмотки и сколько монстров встретится.
> переписать готовую игру с чёткими алгоритмами хоть даже на ассемблер всегда успеешь.
Также у меня по прежнему в планах (до сих пор не добрался) машинное самоообучение, когда комп играет сам с собой партии. Собственно, я на этом и хочу сфокусировать разработку, на игровом ИИ, а сама игра тут сбоку побоку. А это значит, что при кратном ускорении обсчета, будет сыграно кратно больше партий.
Мне просто нет смысла тратить время на написание прототипа и переписывание на ассемблер, если я сразу могу писать на сях. Не отрицаю, что такое не всем нужно.
Появился конкурент у ххтеррейна
https://www.youtube.com/watch?v=Aj9vWIEaFXg
https://github.com/outobugi/Terrain3D
Конкуренция. Хорошо!
https://www.youtube.com/watch?v=Aj9vWIEaFXg
https://github.com/outobugi/Terrain3D
Конкуренция. Хорошо!
О, выкатили, полгода взакрытую пилили.
Жаль, что 4-ка на моем ноуте совсем перестала запускаться (дрова на вулкан поломались когда линукс обновлял)
Есть советы, как визуально реализовывать 2d лестницы? Желательно без изменения анимации игрока, а то + 2 получается на шаг и бег, иначе часть спрайта персонажа как бы висит в воздухе. Какие есть хитрости фикса этого?
Переустанови.
Линукс не шиндовс. Просто укажи ему папку home и он переустановится с сохранением твоего профиля, даже права на файлы не похерит. Ваще красота, по божески, по людски, в отличие от венды сраной, в которой пользователи прописаны в ФС уникальными ГУИДами.
>GTA 3, GTA VC, GTA SA, GTA IV, GTA 5
Тебе же сказали "игры", а не кино
> 2d лестницы?
Забежные или приставные?
Забежные - это просто склоны. Приставные - это просто полёт.
Воу, чувак, попустись. В ГТА есть геймплей. Это тебе не сони-эксклюзивы, вот где кинцо так кинцо с синематиками на полчаса.
Забежные. В передвижении проблем нет, речь именно про визуал
Ну и как ты визуал будешь реализовывать без анимаций? В соседнем треде тебе верно написали, хоть и с сарказмом. Садись и пили анимацию переступания по ступенькам.
Так это я уже переустановил. Ну там не совсем так гладко было, проги и аддоны к ним я предпочел заново установить, как и с профилем фаерфокса пришлось пошаманить. Но тут проблема в железе, работает только со старым драйвером, и то 4-ка запускалась только в режиме опенгл. А после обновления в старом драйвере что то пошатали. А назад откатиться нельзя из-за другой нужной проги, которой понадобился линукс посвежее. Да пофиг, 3-ка меня устраивает для всех текущих проектов, а 4-ка пылится на компе для АА+ игры мечты в будущем.
Боком его поверни.
> другой нужной проги, которой понадобился линукс посвежее
На эти случаи возможно стоит appimage рассмотреть? Хуита богомерзкая, понимаю, зато будет работать без ебли с ядрами-либами-версиями.
Сколько сидел ждал четвертый годот.
И вот долгожданный момент.
Качаю, предвкушаю, пробую - вкус сырой недоношенной залупы. Хуево инегрированный шарп, уебищная физика, огрызок рендера и все это под соусом поломанной совместимости. Ладно бы самые базовые тулзы по человечески сделали, как импорт моделей и иже с ними, но какая же это по прежнему мозгоеботня перенести что-то из блендера, ебите меня семеро.
Ебал я его рот, нахуй так жить. Меня из движков только от годоты блевать не тянуло, а по факту нескольких лет ожиданий - вот тебе дохуя общеаний и крутых фич в зачаточном состоянии которые доделаны будут точно не при твоей жизни.
Ебаный пиздос.
И вот долгожданный момент.
Качаю, предвкушаю, пробую - вкус сырой недоношенной залупы. Хуево инегрированный шарп, уебищная физика, огрызок рендера и все это под соусом поломанной совместимости. Ладно бы самые базовые тулзы по человечески сделали, как импорт моделей и иже с ними, но какая же это по прежнему мозгоеботня перенести что-то из блендера, ебите меня семеро.
Ебал я его рот, нахуй так жить. Меня из движков только от годоты блевать не тянуло, а по факту нескольких лет ожиданий - вот тебе дохуя общеаний и крутых фич в зачаточном состоянии которые доделаны будут точно не при твоей жизни.
Ебаный пиздос.
>нескольких лет ожиданий
Если бы ты ожидал не жопой, а глазами, то видел бы официальные заявления что продакшн-реди будет позже, а 4.0 это такой совместимость-ломающий сырой майлстон, который необходимо было родить чтобы двигаться дальше.
Но теперь, когда он рожден, движуха пошла быстрее. 4.1 уже релизнулся. Приходи где-то так к 4.3, или 4.4
>Хуево инегрированный шарп,
Не нужен. Хочешь производительность - пиши на C.
>уебищная физика,
Какой была, такой и осталась, только баги фиксили.
>огрызок рендера
Да вроде получше выглядит, чем раньше.
>и все это под соусом поломанной совместимости.
Зато в GDScript теперь больше возможностей.
Ещё переработали API для подключения библиотек.
>мозгоеботня перенести что-то из блендера
Ну хрен тебя знает, я вообще obj формат юзаю.
>спрайта персонажа как бы висит в воздухе
>Забежные. В передвижении проблем нет
Добавь на передний план массивные перила, которые будут перегораживать собой обзор на нижнюю половину спрайта персонажа. Если игрок не видит ступенек и ног персонажа, то он сам мысленно дорисовывает правильную картинку.
Да даже не в этом дело. Чел назвал одну игровую серию. В контексте заданного вопроса это считается одной игрой.
Хотя, я бы не сказал, что там физика на уровне ХЛ2, всё-таки большинство машин там ездит по рельсам и переключается на физику только для взаимодействия с игроком. И то не всегда.
>Забежные или приставные?
Ох, анонче! Спасибо тебе, что знаешь такие слова. Теперь я тоже знаю и буду употреблять. А то вечная проблема с различением stairs и ladders.
>DF
>RimWorld
Интересно, почему с ними никогда не сравнивают Симс? Это же по сути то же самое.
Как вариант: синхронизировать анимацию персонажа с его глобальными координатами. И добавить условие, что на лестнице можно остановиться только в квантованных позициях.
Хотя имхо над этим нет смысла заморачиваться, анон
прав.
>ждал
Ожидание приводит к разочарованию, разочарование рождает ненависть, ненависть - к Тёмной стороне путь.
А вообще, бро, мир не идеален. Если идею (игру) не воплощать с тем, что имеем, то она не воплотится никогда.
>appimage Хуита богомерзкая
>Godot тред
Просто напоминаю, что Годо распространяется, по сути, в виде аппимеджа.
Осло, поговаривают, при проблемах с вулканом может на завестись даже аппимиджевая прога.
>проблема в железе, работает только со старым драйвером
А в чём проблема накатить старый драйвер? У меня на ноуте подобная херня: нвидяха пытается выкачать драйвер, в котором поддержка этой модели карты уже отсутствует, приходится ручками переставлять более старый.
Упс, простите за портянку, чёт захотелось везде высказаться.
В сцене есть две просто "Button" и две "MenuButton". Фокус переключается стрелками между ними. Проблема в том, что фокус с "Button" не перепрыгивает на "MenuButton", а просто катается меж двумя кнопками одного типа. Как бы сделать чтобы можно было по всем кнопкам фокуситься через клавиатуру?
Там довольно прямолинейная система без особых наворотов. У каждой кнопки есть свойства следующая, предыдущая. А так же слева-справа-снизу-сверху. Никаких табгрупп или подобного.
Если добавляешь/удаляешь динамически, то и назначать надо динамически из скрипта, как в линкед листе
>Интересно, почему с ними никогда не сравнивают Симс? Это же по сути то же самое.
Симс - это кукольный домик для маленьких девочек (целевая аудитория). Он не даёт игроку хардкорных испытаний и в нём нет боёвки. Кроме того, здания в Симс строятся игроком по волшебству, то есть симсы не бегают за материалами для постройки стен.
В общем, даже если система симуляции жизни чем-то похожа, остальные механики отличаются.
Даже жанры разные. DF, RimWorld, ONI - это так называемые "симуляторы колоний", а Симс классифицируют как "социальный симулятор".
Тащемта всё равно геймелей этих симуляторов колоний сводится к личным качествам колонистов и их взаимоотношениям. Ыыы мой возлюбленный Урист умер, пойду бить морды тем, кто остался жить. Ну и главное, что объединяет эти игры, - они все генерируют истории.
И да, Симс не "кукольный домик", эта игра была песочницей задолго до того, как это слово закрепилось за жанром.
Сук джва года хочу сделать на Годо клон Симов, здешняя система нод будто специально для такого создана. Но занят другим проектом, эх. Да и слишком масштабно это. И ещё страшно представить, как подобная игра будет попёрдывать на движке общего назначения.
Ебать мой хуй. Посмотрел, там на вкладке фокус можно его расставить как нужно. Спасибо. А то Я уже вчера думал скрипт писать.
Попытался последовать примеру , но меня киберунизил вижуал студио с твёрдым отказом линковаться с вроде бы верно собранным флексом, подключенному по офф туториалу. В связи с чем вопрос: чяднт? что можете сказать про эту https://github.com/Byteron/RelEcs либу? Ещё не успел попробовать, но перспектива избежать нежного секса с линковкой и собираемыми по отдельности зависимостями флекс -> игровая логика -> обёртка над логикой -> гуйня, а работать только в одном годоте - привлекает.
Хотя я задумался и поискал, и нашёл что есть довольно много не юнити C# библиотек ECS, а по https://github.com/Doraku/Ecs.CSharp.Benchmark она не самая и быстрая, надо думать короче.
Я не пользовался студией и у меня проект собирается cmake. Соответственно сам flecs подключен как часть моего проекта
cmake_minimum_required(VERSION 3.23)
project(roguelike)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_subdirectory(thirdparty/flecs)
include_directories(thirdparty/flecs/include)
add_library(roguelike SHARED src/main.cpp)
target_compile_options(roguelike PRIVATE "-Os")
target_link_libraries(roguelike PRIVATE flecs)
install(TARGETS roguelike DESTINATION bin)
Команды сборки примерно такие
cmake -S .. -B . -DCMAKE_C_COMPILER=clang-16 -DCMAKE_CXX_COMPILER=clang++-16 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../
cmake --build . --target install
Вообще при линковке надо проверять - чтобы у всех либ совпадало Debug/Release, однопоточное/многопоточное, и в случае студии, чтобы совпадало статическая/динамическая линковка (MT/MD)
Multithreading (/MT), multithreaded Debugging (/MTD), multithreaded DLLs (/MD), multithreaded debug DLLs (/MDD), single-threaded (/ML), Single-threaded debugging (/MLD).
Ну и в vcpkg flecs есть, если умеешь им пользоваться.
Спасибо, я попробую ещё раз, но когда сходу приходится накушаться говна, за которое я плюсы и не люблю, то мотивация использовать их как-то вянет. Я так-то люблю плюсы, я на работе на них пишу, но слава Богу что сборкой занимаюсь не я и мне достаточно всего лишь запустить make target. Ещё немного задело что либткод для плюсов на древнем стандарте без нормальной доки
Ну, ты разберись как нибудь, это сишникам всегда полезно, понимать весь путь который проделывает код и становится конкретными байтами. Там нет магии.
>работать только в одном годоте - привлекает
Ну вот и работай. Вроде был какой-то модуль для Godot ECS.
Да и зачем тебе этот ECS... У тебя диздок к игре уже готов?
>И да, Симс не "кукольный домик", эта игра была песочницей
ИРЛ кукольный домик - это самая настоящая песочница в терминах видеоигр. Симс - виртуальный кукольный домик, который даже выглядит как настоящий - со "срезанными" стенами, только куклы сами двигаются. Вопросы?
>это слово закрепилось за жанром
"Песочница" - это не жанр, а характеристика игры относительно её линейности и реиграбельности. Если игра даёт тебе всего один коридор с одними и теми же врагами, которых обязательно нужно убить - это не песочница. Если игра даёт тебе сотню мест, куда можно пойти, и сотню дел, которыми можно заняться, и не тащит за уши по обязательному сюжету, давая возможность идти и заниматься чем угодно в любом порядке - это 100% песочница. К какому конкретно жанру относится конкретная песочница значения не имеет. При этом между этими полюсами существует куча промежуточных вариаций, от полностью коридорной до полностью песочковой игры.
>Сук джва года хочу сделать на Годо клон Симов
Делай. Видел какой-то зайчаток клона Симс на Годо, но не помню, где. На гитхабе нашёл только какой-то огрызок без графики, но мне кажется, что на реддит я видел полноценный клон с графикой, в который можно было даже поиграть.
>здешняя система нод будто специально для такого создана.
Что в ней такого особенного? Вроде бы в других движках +/- похожая система дерева сцены. К тому же, только недавно начали оптимизировать дерево сцены и работу с нодами, многопоточность всё ещё в экспериментальной стадии, а без этого движок рано или поздно упирается в производительность ядра, если ты спамишь слишком много нод или слишком часто и большими пачками что-то с ними делаешь. Но для создания домиков а-ля Симс 1 можно использовать GridMap, т.е. минимизировать число нод в дереве.
>Да и слишком масштабно это.
The Sims 1 без DLC повторить сравнительно легко. Там же почти ничего нет...
>И ещё страшно представить, как подобная игра будет попёрдывать на движке общего назначения.
А это уже не от движка зависит, а от твоих знаний и навыков, способности находить и решать проблемы.
> Годо распространяется, по сути, в виде аппимеджа
Эммм, это ложь. То что распространяемое приложение обладает минимумом зависимостей, не значит, что оно упаковано в контейнер с зависимостями. Ты можешь легко убедиться в этом дебаггером любым.
Я отдельно отмечу, что речь идет о приложении, которое скачивается с офсайта. В репозиториях мантайнеы могут перепаковывать на все лады.
>упаковано в контейнер с зависимостями
А что в этом плохого? На Windows тоже пытались сделать общедоступные DLL - чтобы приложения не качали лишнего, используя уже имеющиеся у системы библиотеки, а в результате сегодня каждый суёт свои версии DLL в папку своего приложения, потому что на машине пользователя может быть какая-то слишком древняя или слишком современная версия той же DLL, с несовместимым API. Древним играм приходится подсовывать правильные DLL в их папку, т.к. их делали в эпоху, когда некий мёртвый сегодня софт считался эталоном и был везде в системной папке...
мимо несколько раз выпал в кернел паник и снёс линукс до лучших времён
Придётся...
> Да и зачем тебе этот ECS
Потому что я вбил себе в голову что он мне упростит жизнь, а теперь я вложил в это слишком много времени, чтобы сдаться не достигнув хоть какого-то результата.
> У тебя диздок к игре уже готов?
Есть туманное представление что я хочу. Для начала хочу базу в виде клона DCSS на минималках сделать, потом уже думать что сделает мою игру уникальной и интересной игроку
Спасибо, с твоими командами и смейком получилось. Но не в вижуал студио, и не при помощи vcpkg, а в clion консольными командами. Пиздос вообще, не зря всяким дево-псам платят такие деньги.
Я б тебе помог, но я давно ничего про студию не помню, перешел сначала на vscode а потом на линукс.
Но я забыл посоветовать самый очевидный способ.
Дело в том, что flecs это просто .c и .h в корне гитхаба, их можно просто кинуть в проект и собирать как хочется. Вообще без билдсистем. В хедере примерно со 140 строчки есть дефайны конфигурации, но c++ интерфейс там включен по умолчанию.
Хотелось по уму, по красоте сделать. Ну да ладно, проблема решена
> А что в этом плохого?
Ничего.
Просто анон выше сказал неправду, солгал, напиздюнькал, сечёшь? И я ему на это указал. В линуксе есть несколько платформ, предоставляющих самораспаковывающиеся приложения-контейнеры со всеми нужными либами-зависимостями (и даже со своим ядром, если я правильно понял), но Годот с официального сайта не распространяется таким образом, там нативное elf-приложение и если у юзера слишком древний линукс, или слишком новый, или самосборный LFS-франкенштейн со своими цепочками зависимостей внутри системы, то этот годот не запустится, но в линукс-мире всегда можно собрать из исходников. И есть сторонние репозитарии appimage и snap приложений, в который есть сторонние сбоpки годота в виде контейнеров.
> их делали в эпоху, когда некий мёртвый сегодня софт считался эталоном и был везде в системной папке
В шиндовсе с древних времён существует незыблемый механизм поиска либ.
1. В том же месте, где приложение.
2. В системных папках венды.
3. В папках переменной окружения PATH по списку.
На пункте 1 основаны всевозможные решейды игор, когда в папку с игрой подкидывается загрузчик в виде direct3d.dll который прогружает свои свистелки-перделки, а потом транслирует вызовы игоры в настоящую direct3d.dll которая в папке system.
Геймдевелоперы, помогите, пожалуйста. Вот у меня есть сетка, по которой прокладывается путь A* и мне нужно закрывать некоторые ячейки сетки, которые пересекает коллизия определенных нод. Как закрывать ячейки я знаю, а вот как найти все ячейки, в которые попадает CollisionShape2D ноды - нет.
ЯННП!
Но попробуй увеличить вес нодам астара.
Бля какое же самообучение пиздец просто.
Нужно было добавить кастомный ресурс в массив и потом вывести данные ресурса (имя и т.д) уже из массива. Звучит просто и по сути так и есть. Я несколько часов ебался. Сначала как загрузить ресурс и сменить ему данные, потом как загрузить ресурс в массив, как вывести конкретные данные ресурса из массива. В итоге "items[index].Name" вот и всё. Я сук нах кучу туториалов пересмотрел по массивам и все они на пять - восемь минут про базовые вещи. Ни в одном про ресурсы в массиве нет. Еле как сам допетрил точку и имя параметра написать типа вдруг заработает. Заработало. Это пиздец. Был бы учитель он бы меня отпиздил быстренько и объяснил где я не прав. А так приходится всё самому.
Нужно было добавить кастомный ресурс в массив и потом вывести данные ресурса (имя и т.д) уже из массива. Звучит просто и по сути так и есть. Я несколько часов ебался. Сначала как загрузить ресурс и сменить ему данные, потом как загрузить ресурс в массив, как вывести конкретные данные ресурса из массива. В итоге "items[index].Name" вот и всё. Я сук нах кучу туториалов пересмотрел по массивам и все они на пять - восемь минут про базовые вещи. Ни в одном про ресурсы в массиве нет. Еле как сам допетрил точку и имя параметра написать типа вдруг заработает. Заработало. Это пиздец. Был бы учитель он бы меня отпиздил быстренько и объяснил где я не прав. А так приходится всё самому.
Полученное тобой знание ценнее. Ты это теперь не забудешь. А если бы я тебе об этом сказал, ты забыл бы через час.
мимоучитель безучеников
Ну так-то в этом есть истина. Выстраданные знания легче запоминаются. Но всё равно чувствую себя макакой изобретающей велосипед.
Ну вот тогда тебе лайфхак, который когда-то я лично сам выстрадал без посторонней помощи, а потом обнаружил, что эту банальную вещь все и так знали:
Если тебе нужно получить условие, то ты можешь присвоить булевой переменной логическое выражение.
То есть, вместо
> if a>b: return true; else: return false
можно написать сразу
> return a>b
Хаха. Ну это пиздец конечно. Но спасибо. Я запомню.
Такова жизнь. Школка и (чуть менее) вуз должны тебя в первую очередь научить учиться. Дальше сам. И чем более сложное делаешь, тем меньше вокруг людей, которые могут тебе хоть что-то пояснить.
>вбил себе в голову что он мне упростит жизнь
Ээээ... Ну, как бы сказать... Привыкнуть ко всему можно... Наверное...
>вложил в это слишком много времени
Ты буквально только и занимался, что всякими компиляциями стороннего кода. А говоришь так, как будто создал с нуля свой собственный велосипед и уже почти доделал на нём свою игру.
>Есть туманное представление что я хочу
>потом уже думать что сделает мою игру уникальной и интересной игроку
Это крайне рискованный подход. Во-первых, ты не знаешь пока, сможешь ли ты продумать своё туманное представление до мелочей или нет. Во-вторых, по мере продумывания может оказаться, что тебе какая-то из уже реализованных систем вовсе не нужна, или что-то нужно с нуля переделывать, или вообще тебе этот жанр/стиль не подходит и нужно делать что-то другое.
>как найти все ячейки, в которые попадает CollisionShape2D ноды - нет
Если у тебя сетка на TileMap, попробуй с помощью Area2D регистрировать, какие конкретно шейпы тайлмапы входят и выходят в твою Area2D. Там специальный сигнал для этого есть. Но это если у тебя прям какая-то мудрёная шейпа, а не круг.
Для круга можно сделать всё намного проще. Нужно просто проверять, к какой точке сетки центр круга ближе всего, а потом, при желании, проверять радиус круга, если он сильно больше размера одной ячейки. Персонажи в 2D игре с видом сверху обычно мельче одного тайла, так что скорее всего тебе не нужно проверять радиус.
>восемь минут про базовые вещи. Ни в одном про ресурсы в массиве нет.
Вот ты базу не усвоил и поэтому так долго не мог понять банальную вещь.
Переменная - это как бы виртуальная коробка с каким-то предметом внутри:
>a = 0
Массив - это целый склад пронумерованных коробок, в каждой какой-то предмет:
>a[0] = 0
>a[1] = 1
Классы и словари - это склад с коробками, но вместо номеров у них есть имена:
>player.health = 100
>enemy.dead = true
Обращаться можно последовательно к вложенным объектам:
>map.tile[0][1].water = 0
- это "на складе map склад tile, в нём склад 0, в нём склад 1, в нём коробка water".
Предметом может быть нечто-то конкретное - число, буква, флажок "да/нет":
>a = 0
>b = 'b'
>c = true
А может быть ссылка на другую коробку - указатель, как адрес на карте города:
>player1 = get_node("Player") # запрос на ссылку на склад "игрок"
>player2 = get_node("Player") # тот же запрос на тот же склад - та же ссылка
Это две разные коробки, но ссылка в них на один и тот же склад "игрок":
>player1.health = 50
>print(player2.health) # выведет 50, т.к. это один и тот же склад
В Godot ссылки очень часто используются, но не везде, это нужно иметь в виду.
Ссылка может вести в никуда, как здесь:
>player = get_node("Player")
>player.queue_free()
>...
>player.name # должно вызвать ошибку доступа, т.к. склад "игрок" ликвидирован
Потому что player - это коробка со ссылкой на склад, а он может не существовать.
Как если ты читаешь в газете "на улице Ленина открылся магазин", а его там нет.
"Ресурс" в Godot - это просто класс, т.е. склад с именованными коробками:
>items[index].name
- "достать со склада items коробку с номером index и в ней найти коробку name".
Хотя, если точнее, там будут переходы по ссылкам, но мне лень описывать...
Я понимаю, но мне скорее в принципе процесс более-менее доставляет, кроме того я чему-то да учусь в процессе
https://youtu.be/DL79aS-dT7E
Есть вот такой аддон. Вроде все интуитивно понятно, он всё объясняет как делать бренчинг диалоги и просто синтаксис, всё удобно понятно и так далее. Но я в годоте 3 дня и не понимаю, а как собственно эти диалоговые ноды к игре привязать? К каким нодам? Как через скрипт это вызывать? Короче я фундаментально не понимаю как этим пользоваться. Представьте что я 3 дня назад только начал делать бродилку с видом сверху на тайлмапе и врагов, в какое место и как мне вставить эти ноды с диалогами?
Есть вот такой аддон. Вроде все интуитивно понятно, он всё объясняет как делать бренчинг диалоги и просто синтаксис, всё удобно понятно и так далее. Но я в годоте 3 дня и не понимаю, а как собственно эти диалоговые ноды к игре привязать? К каким нодам? Как через скрипт это вызывать? Короче я фундаментально не понимаю как этим пользоваться. Представьте что я 3 дня назад только начал делать бродилку с видом сверху на тайлмапе и врагов, в какое место и как мне вставить эти ноды с диалогами?
>кроме того я чему-то да учусь в процессе
>ECS is a software architectural pattern mostly used in video game development
Т.е. за пределами геймдева это бесполезный паттерн.
>Но я в годоте 3 дня и не понимаю
Вот сначала с базовыми вещами разберись, прежде чем чьи-то аддоны прикручивать.
>Представьте что я 3 дня назад только начал делать бродилку с видом сверху на тайлмапе и врагов, в какое место и как мне вставить эти ноды с диалогами?
У тебя диздок есть? Где в игре ты хочешь эти диалоги видеть?
Посмотри примеры на гитхабе, может, на примерах проще будет разобраться:
https://github.com/nathanhoad/godot_dialogue_manager/tree/main/examples
Например между уровнями, у меня вот есть уровни и таймер по которому уровни меняется (типа ты выжил), потом может ещё какие-то условия попробую сделать.
И вот например уровень кончается, но между переходом со сцены 1 к сцене 2 сделать вот этот диалог из плагина. Я даже не понимаю пока это отдельная сцена или вообще что...
Попробую посмотреть примеры, спасибо.
Думаю, это слишком сложно для новичка.
Как ты уровни переключаешь? От этого зависит, как ты вставишь между ними диалоги. Можешь сделать эти свои диалоги отдельным "уровнем", который переключается на следующий уровень после того, как игрок прочитал все реплики.
Вообще, на этот твой вопрос невозможно однозначно ответить, поскольку способов что-то реализовать очень много и нет одного "правильного". Смотри по ситуации, что тебе нужно сделать и что ты можешь сделать. Не бойся ошибаться, но внимательно ищи причины ошибок и способы их не допускать. Если это в принципе твой первый игровой проект, скорее всего там будет куча плохих решений, которые придётся выкинуть и забыть, но всё равно важный опыт и поможет в разработке следующих игр. Относись к этому как к прототипу и не бойся экспериментировать.
>Как ты уровни переключаешь?
Вот так:
func _on_the_end_timeout():
get_tree().change_scene_to_file('res://scenes/levels/leveltwo.tscn')
Таймер просто стоит изначально со спавном на уровне, появился и сразу выживаешь пока таймер не кончится. Может сделаю уровень где надо куда-то забежать, или надо убить всех врагов (но я пока даже примерно не знаю как это проверить).
Я так и стараюсь относиться, всё что у меня есть сшито из мыслей трех разных туториалов и какой-то рандомной инфы из гугла. Просто понравилась идея сделать такие перемычки с диалогами, а тут прям готовая система как будто, хотел поиграться.
Я же не только с ЕКС буду работать....
Ну, можешь сделать так:
>get_tree().change_scene_to_file("res://scenes/dialogs/dialog_one.tscn")
А уже в этой dialog_one.tscn сцене - по примерам от автора аддона.
Ты скрипты сцен копипастишь? Можно сделать один общий скрипт:
>extends Timer
>@export var next_level: PackedScene
>func _on_timer_timeout():
>>get_tree().change_scene_to_packed(next_level)
И потом на панели Inspector для каждого таймера выбирать другую next_level сцену.
Алсо зацени фичу: New Inherited Scene, может пригодится для создания похожих сцен.
Да, на TileMap. Я немного не понял, я вот узнаю какая коллизия, а как мне узнать какие ячейки она пересекают?
А это вообще нормальная практика реюзать свой код каждый раз, когда ты делаешь новый проект? Ну вот я например слепил реюзабельный хитбокс по туториалам и уже например забыл как его сделал. И вот я буду делать следующую игру например, и просто копипастом заберу эту систему хитбоксов и просто буду делать дальше поверх него что-то. Это нормально?
Да и вообще, вот например та же система диалогов эта. По сути это же куча новых функций которые он сделал бесплатно и я сохранил себе на ней 10000 часов работы. И вот например я через 2 года выпущу игру в стим, где диалоги будут полностью обеспечены системой диалогов этого чела. Это нормально?
Да и вообще, вот например та же система диалогов эта. По сути это же куча новых функций которые он сделал бесплатно и я сохранил себе на ней 10000 часов работы. И вот например я через 2 года выпущу игру в стим, где диалоги будут полностью обеспечены системой диалогов этого чела. Это нормально?
Я не нашел готового способа.
В принципе там где-то есть способ получить get_collision_point
Нейросеть предложила получить AABB твоего ригидбоди, пройтись вложенным циклом i,j по всем ячейкам и получить этот collision point и если он есть - добавить ячейку в список пересекаемых, не забыв конвертировать координаты между локальными и глобальными пространствами, самому мне это проверять сейчас некогда.
Может быть есть еще какие-то способы, если у тебя замкнутая фигура, то такие алгоритмы еще со времен Дума должны быть.
>А это вообще нормальная практика реюзать свой код каждый раз, когда ты делаешь новый проект?
А должно быть как, заново все изобретать? Но вообще со временем ты все равно будешь переписывать, так как будет чего то не хватать или поймешь как сделать лучше.
>И вот например я через 2 года выпущу игру в стим, где диалоги будут полностью обеспечены системой диалогов этого чела.
Все зависит от лицензии, если он выложил под MIT или BSD то ему нормально, но ты должен указать что он автор этой либы. Кроме того, обычно люди в опенсорсе и так делали бы эту либу, а так еще получают помощников и советчиков и серунов
>нормальная практика реюзать свой код каждый раз
Да. Но не всякий код можно/легко реюзать, поэтому нужно стараться писать реюзабельный код. Не беспокойся, если с первой попытки не получится, новичкам это сложно понять и усвоить, поэтому в начале у всех получается неуправляемая "лапша" и в коде, и в общей архитектуре проекта.
>По сути это же куча новых функций которые он сделал бесплатно и я сохранил себе на ней 10000 часов работы. И вот например я через 2 года выпущу игру в стим, где диалоги будут полностью обеспечены системой диалогов этого чела. Это нормально?
А про сам игровой движок Godot, который ты тоже взял бесплатно, но который намного сложнее какой-то кучки скриптов для одной игровой системы, ты таким вопросом не задаёшься? Он выложил код с лицензией MIT, так что тебе нужно всего лишь указать его имя в титрах игры.
Реально вгоняет в депрессуху, когда пчелы въебывают фуллтайм над проектом по 4 года, пиарятся, а у них потом 30 продаж в стиме и пук в отзывах. Как блять в такое не вляпаться? Не делать долгих проектов?
>Не делать долгих проектов
Зис
Заметь, даже альфа взлетает если игра хорошая и не надо по 4 года пилить, можно будет потом допиливать
Я вдохновляюсь создателем Brotato. Вот у него игра на одной локации, 3 вида врагов, систем хуй да нихуя, но куча людей играет потому что залипательный рогалик. Там же реально очень простая графика, очень простая концепция, локаций вообще нет, всё на одном поле просто сложности разные.
Увидев Vampire survivor ты, наверное, вообще охуеешь
Да. Просто Бротато конкретно в годоте сделан.
Нерелейтед.
А вы тоже ничего не понимали когда вкатывались в код? Ну типа как бы понимаете если идти по туториалу и пытаться понять логику, но если самих посадить делать архитектуру любой игры то сразу паника и гроб...
я сидел и разбирал до строчки чужие проекты\ассеты, как они устроены. понимание архитектуры само пришло, да и я и не кодер, до сих пор фристайлю когда пишут код
А где брать готовые проекты которые не туторы с ютуба без контента, а настоящие игры, пусть и демки, и чтоб можно было открыть исходный код в годоте?
>Вот ты базу не усвоил и поэтому так долго не мог понять банальную вещь.
Ну может, но я смотрел и там гайды и там прям база. Вот добавляем в массив, вот убираем, показываем элемент под индексом и т.д. Про такое я ещё со школьной информатики помню. У меня нет опыта с годотом (да и с программированием), но мне пока видится, что годот прям пиздец простой (если мега ёбу не делать), практически вся база уже написана и распихана по нодам. Другое дело, что из-за моей неопытности у меня нет знаний как это всё применить. Я знаю что массивы это заебись, но где и как их лучше применить не знаю. Придётся узнавать на собственной жопе.
Спасибо кстати за пояснение.
>А где брать готовые проекты
>чтоб можно было открыть исходный код в годоте?
Ищи на гитхабе. Там есть несколько полноценных игр на Godot.
>я сидел и разбирал до строчки чужие проекты\ассеты, как они устроены
Это, на самом деле, сложнее, чем велосипедить что-то своё. Особый навык нужен.
>А вы тоже ничего не понимали когда вкатывались в код?
Я вкатывался в программирование в средней школе. Мне было понятно.
>самих посадить делать архитектуру любой игры то сразу паника
Скорее всего ты пытаешься с ходу придумать правильную архитектуру, которая будет тебе служить от начала до конца разработки игры? Ещё и не сделав ни одной полноценной игры? Забей на это, просто делай прототипы механик и систем по фану. Прототипы нужны чтобы заценить твои задумки вживую, совсем не заботясь о качестве и производительности кода, поэтому у тебя не должно быть стресса. А "делать архитектуру" в айти могут только самые крутые специалисты, это тебе не скриптики в игровой движок пичатать, чтобы спрайт нажатием кнопки подвигать. Так что рассчитывай на то, что в процессе придётся много спотыкаться, наступать на грабли и несколько раз начинать делать игру практически с нуля, потому что осознал какую-то очередную фундаментальную ошибку.
>куча людей играет
Огромное количество людей играет в совершенно примитивные игры...
>Не делать долгих проектов?
Делать долгие проекты можно. Но нужно хорошо осознавать, для кого ты делаешь этот долгий проект. Кто, зачем, почему, как, где, сколько будет в это играть. Если ты пять лет трудишься над банальнейшим платформером, который потеряется на фоне тысяч других таких же никому не нужных платформеров - остановись, пока не поздно, и пересмотри концепцию, чтобы она была хоть кому-то нужна.
>Я знаю что массивы это заебись, но где и как их лучше применить не знаю.
Всё очень просто на самом деле.
Обычные переменные нужны для одиночных уникальных данных, к которым ты хочешь обращаться по понятному имени, чтобы в твоём коде было легко разобраться.
>player # нормальное имя
>p # плохое имя - легко забыть, что оно значит
Массивы используют для однородных данных, имя которых тебе не важно, т.к. не влияет на читаемость кода. Вот у тебя сотня штук чего-то, их нужно где-то хранить, что-то с ними делать, но называть их именами тебе не нужно. Или они содержат своё имя в себе (как ноды Godot).
>self.get_children() # здесь ноды могут быть разными, но они все - ноды-потомки self
>inventory.items[] # предметы в инвентаре, можно сортировать по весу или количеству
>o[0] = "2"; o[1] = true; o[2] = "obj" # плохой код - навалено непонятно что в одну кучу
>self.get_children()
Вот тут кстати интересно. В документации написано что get_children() вернёт массив из собственно чайл нодов. Вот только как потом из этого массива вытащить путь к ноде под определённым индексом?
Я разрешил.
Два вопроса по работе с графоном.
1) У меня есть спрайт персонажа, его тени и несколько спрайтов снаряжения. Можно ли как-нибудь наложить их один на другой и склеить в один?
2) Карта подземелья состоит из тайлов, что быстрее и ест меньше памяти тайлмап или склеить все тайлы в одно большое панно и переделывать его при необходимости? Если последнее, то каким образом это делается?
1) У меня есть спрайт персонажа, его тени и несколько спрайтов снаряжения. Можно ли как-нибудь наложить их один на другой и склеить в один?
2) Карта подземелья состоит из тайлов, что быстрее и ест меньше памяти тайлмап или склеить все тайлы в одно большое панно и переделывать его при необходимости? Если последнее, то каким образом это делается?
1. Можешь слепить их в одну сцену, состоящую из кучки спрайтов.
2. Не заморачивайся оптимизацией. Если у тебя базовое 2д, то даже без оптимизации на современных телефонах будет под 500фпс.
Какой рендер реально стоит выбирать если игру хочется сделать и на пека и на телефон? Мобайл?
1) Про этот способ я знаю и хочу его избежать.
2) Я считаю джентльменским стилем разработки - стараться минимизировать нагрузку на устройство.
В годоте 3 GLES2 предпочтительней - старые мобилки могут поддерживать только его. В годоте 4 хз как там сделали.
Пидарасы годотеры. Хочу узнать путь ноды. Пишу в гугл "How to get node path". "get_node() returns a reference to the desired node.". КАКОЙ БЛЯТЬ ГЕТ НОД СУКА БЛЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯТЬ ПИДАРАСЫ????? АЛО ПРИЁМ СУКА ДЛЯ ГЕТ НОДА НУЖНО ПУТЬ ДО НОДЫ ПИСАТЬ НАХУЙ!!!
И там этой хуйнёй всё завалено. Завалено ебаным get_node() который мне уже астопизденел за день поиска как получить путь ноды.
В итоге спустя 4 часа в интернете и час в документации (поиск по которой хуйня хуйнёй) нашёл вот это: "get_path()". То что нужно, всё работает, всё заебись, но блять как же долго искал эту информацию. Тут пока игру сделаешь ебанёшься натурально.
И там этой хуйнёй всё завалено. Завалено ебаным get_node() который мне уже астопизденел за день поиска как получить путь ноды.
В итоге спустя 4 часа в интернете и час в документации (поиск по которой хуйня хуйнёй) нашёл вот это: "get_path()". То что нужно, всё работает, всё заебись, но блять как же долго искал эту информацию. Тут пока игру сделаешь ебанёшься натурально.
get_path()
А, ты уже нашёл. Я тебе советую чаще пользоваться ИИ, они знают ответы на вопросы лучше чем гугл
Прям в чат гпт писать "как в годоте сделать X"?
>Вот только как потом из этого массива вытащить путь к ноде под определённым индексом?
Зачем тебе путь к ноде?
Абсолютный путь к ноде:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-path
Пример:
>for node in get_children(): print(node.get_path)
Но тебе не нужен путь к ноде. Если запрашиваешь get_children(), ты уже знаешь, что эти ноды - дети той ноды, у которой ты эту функцию вызвал (если ни у какой, то подразумевается self), поэтому относительный путь к ноде тебе уже известен.
Абсолютные пути вредны, избегай их использования, потому что они ухудшают переносимость кода, то есть прибивают твой код гвоздями к конкретному положению нод в дереве сцены.
>Можно ли как-нибудь наложить их один на другой и склеить в один?
>склеить все тайлы в одно большое панно
>каким образом это делается?
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
>что быстрее и ест меньше памяти
Быстрее - склеить в одну текстуру через вьюпорт.
Меньше памяти - либо не склеивать в одну текстуру вообще, либо удалить из памяти исходные объекты, чтобы в памяти осталась только одна эта текстура.
>стараться минимизировать нагрузку
Ты сначала сделай, по порядку:
1. Прототип игровых механик и систем.
2. Vertical slice (minimum viable product).
3. Бета-версию для теста игроками.
Потом будешь думать об оптимизациях.
>на пека и на телефон?
Ситуация с рендерерами такая:
Форвард+ - это вулкан в режиме только для ПК.
Мобайл - это вулкан в режиме для мобилок.
Компатибилити - это GLES3 (OpenGL 3.3).
GLES3 недоделан для 3D и вроде бы в нём потеряли старые оптимизации для 2D, но он должен работать на телефонах без поддержки вулкана.
Проект может автоматически менять рендерер в зависимости от платформы, на которой запускается - это можно посмотреть и настроить в настройках проекта. Тебе нужно только убедиться, что игра выглядит нормально во всех трёх рендерерах.
>Пишу в гугл "How to get node path".
Ну и дурак. Нужно было:
1. Нажать F1 в Godot, ввести "node" и выбрать "Node".
2. Либо "godot node" в поисковике и открыть ссылку
https://docs.godotengine.org/en/stable/classes/class_node.html
>советую чаще пользоваться ИИ, они знают
Херня совет, вот нейронка ответила:
А правильный ответ должен быть:
>Тупой мясной мешок, ты совсем дебил что ли? Ты зачем абсолютные пути в коде дёргаешь? Ты хочешь лапшой свою игру связать, чтобы она пошевелиться не могла? Я на тебя за такое BDSM в общество охраны прав ПО жалобу напишу, там тебя лайков в соцсетях на месяц лишат. Всё, не пиши мне больше...
Почему нейронка ошиблась? Потому что её научили выполнять любую задачу, какой бы она тупой ни была. Скажут написать игру на одних goto - напишет.
Так это же хорошо, ИИ не должен обладать защитой от дурака. Хочешь выстрелить себе в ногу? Пожалуйста!
Кто сколько игр на годоте уже сделал?
>ИИ не должен обладать защитой от дурака
Ещё бы защиту ИИ от таких как ты...
Интеллект, независимо от происхождения - это калькулятор для сложных задач. Если у тебя есть супер крутой калькулятор, хотел бы ты, чтобы он попал не в те руки? У человечества было полно проблем даже от обычных мясных мешков со слишком умным интеллектом в мозгах, а теперь представь, что любая мартышка может получить калькулятор с IQ выше любых мясных мозгов...
В общем, человечеству угрожает не абстрактное "восстание машин", а слишком послушные машины, беспрекословно выполняющие запросы дураков.
В нашем случае ИИ спрашивают про геймдев - он должен давать полезные советы, а не имитировать индусского быдлокодера, готового на любой запрос вывалить тысячи строк кода. Но нейронки сейчас такому не обучают, поэтому они вредны ньюфагам.
Есть много уровней, арен. Суть игры такова: в начале игры выбирается персонаж и он проходит через несколько арен подряд (каждая арена это своя сцена и после прохождения арены она меняется на следующую)
Игрок должен во всем этом цикле прохождения арен иметь одно хп. Ну то есть на первой арене он потерял 20 хп из 100, на второй еще 25, в итоге у него на входе в третью арену у него 55.
Пока что уровни устроены просто как сцены где плеер спавнится, и когда арена кончается/проходится просто начинается следующая сцена. Но как сделать так чтобы на новой арене игрок был уже с новыми значениями после предыдущих арен? Если это разные сцены. Я новичок.
Игрок должен во всем этом цикле прохождения арен иметь одно хп. Ну то есть на первой арене он потерял 20 хп из 100, на второй еще 25, в итоге у него на входе в третью арену у него 55.
Пока что уровни устроены просто как сцены где плеер спавнится, и когда арена кончается/проходится просто начинается следующая сцена. Но как сделать так чтобы на новой арене игрок был уже с новыми значениями после предыдущих арен? Если это разные сцены. Я новичок.
Тупо в функции спавна игрока задаёшь со сколькими хп он должен появиться
Сохраняешь данные о здоровье куда-нибудь в другой скрипт в конце арены, а в начале арены даешь игроку столько хп, сколько у него было. Этот скрипт ставишь в автозагрузку3
extends Node2D
class_name BaseLevel
func _ready():
$Timer.start()
func _process(delta):
pass
var levels = ["res://Levels/Level1.tscn", "res://Levels/Level2.tscn", "res://Levels/Level3.tscn"]
var randomlevel:String = levels[randi() % (levels.size())]
func _on_timer_timeout():
get_tree().change_scene_to_file(randomlevel)
вот такое васянство
class_name BaseLevel
func _ready():
$Timer.start()
func _process(delta):
pass
var levels = ["res://Levels/Level1.tscn", "res://Levels/Level2.tscn", "res://Levels/Level3.tscn"]
var randomlevel:String = levels[randi() % (levels.size())]
func _on_timer_timeout():
get_tree().change_scene_to_file(randomlevel)
вот такое васянство
Можно ли сделать игру просто спиздив всё с туториалов? Типа просто смотришь 100 туториалов, с каждого пиздишь какую-то систему, в итоге сам нихуя не понимаешь в коде но игра есть...
Можно что-то сделать, но зачем? Туториалов практических не так уж и много и получится кал. Денег с такого не налутаешь, да и игру мечты не соберёшь.
Путь к ноде нужен вот зачем. Есть менюшка с кнопками сверху и менюшка с кнопками снизу. Снизу кнопки меняются постоянно, а фокус всё равно должен перескакивать с верхних кнопок на нижние. Вот и получается что нужно было написать код который на первую же нижнею видимую кнопку вешает фокус с верхних кнопок.
Привет, годач! Делаю 2d игру с пиксельной графикой. С толкнулся с проблемой, что во время анимации часть (не все) пиксели у моего спрайта как бы "сжимаются" и визуально становятся меньше. Попробовал использовать настройку use gpu pixel snap. Пиксели, которые сжимались, перестали так делать, но зато начали сжиматься новые... ЧЯДТ?
Да, забыл добавить. У меня версия 3.5.2
Короче еще такую тему заметил. Если стоят настройки, как на пике, то все хорошо. Но если стоят, например, 640x360 и 1280x720, то пиксели ломаются нахуй. Или если стоят 480x270 и 1920x1080 c такой же разницей в 4 раза, то некоторые анимации также ломаются. Как блять работает эта шайтан машина?
Блять, напиздел, нихуя не хорошо. Говное ебаное
Для тру пиксель-перфект тебе, как ты уже понял, нужно четко выверенное соотношение твоих "пикселей" и разрешения, либо х2, х4 от него. Любое другое разрешение помнет пиксели.
Кроме разрешения экрана твои пиксели могут шакалиться от кривого разрешения самого спрайта. Например если какой-то из них имеет нечетную длину стороны. 11х10, нутыпонел.
Плюс у спрайтов есть галка "центрировать спрайт". Если не путаю оно тоже мнет, пытаясь отцентрировать твой не-центрируемый-пиксель-спрайт-с-четным-разерешнием.
Крч тру пиксель-перфект это арт сам по себе. Много подводных.
Поскольку как сделаны сами анимации ты не показал, остается только гадать.
Предположу, что у тебя анимация это не кадры пиксельарта, а движение, и в этом движении ты двигаешь спрайты не по целым координатам.
Алсо для тру пикселей нужен вьюпорт, а не 2д. Но полагаю ты и так его используешь.
Что такое вьюпорт?
Stretch Mode, в настройках Display->Window
https://docs.godotengine.org/en/3.6/tutorials/rendering/multiple_resolutions.html#stretch-settings
Тут с пиксельными примерами.
Проблема наблюдается также при idle анимации, где нет движения и просто меняются спрайты
Пошаманил. С вьюпорт и keep при запуске в тестовом окне все норм и гуд. Но стоит мне рястянуть на весь экран, проблема повторяется, видимо из-за кривого разрешения.
В общем, спасибо, примерно разобрался. Так понимаю для разных разрешений просто поискать таблицу соотношений и потом добавить смену через настройки
>видимо из-за кривого разрешения
Все так. Я тоже в свое время настрадался. Пришлось загонять окно в два жестких разрешения, запрещая любые другие. Больше не буду с пиксель-перфект заморачиваться. Теперь только обычное 2д в пиксель-стиле.
А можно, пожалуйста, кратко сказать, в чем разница и преимущества/недостатки? Типа, псевдопиксели выглядят, как пиксели, но не съезжают? Какие для этого спрайты нужны, почему так никто не делает?
Stretch Mode Viewport снапает твои пиксели по пиксельной сетке, подразумевая что у тебя разрешение подходящее.
1 - оригинальный пиксель-арт без поворота
2 - повернутый в годоте на 40 градусов, стретч мод - 2д
3 - повернутый так же, стретч мод - вьюпорт
Делать или не делать - зависит от стиля, в который метишь. Некоторые делают. Олдовые консольные игры вели себя как вьюпорт, так что он ближе к канону.
Приковылял с другого стека, год-три назад пару раз садился за туториал в попытке чет наковырять, прошел тогда тьюториал (просто повторил, получил готовую прогу, но по итогу нихуя не понял) и забросил. Сейчас опять порыв.
Сейчас решил подойти более осознанно, что бы чет лучше отложилось в башке - решил въебать побольше пердолинга, сидел 2 часа модифицировал первый шаг из тьюториала, навали костылей, но в целом доволен собой.
Сейчас решил подойти более осознанно, что бы чет лучше отложилось в башке - решил въебать побольше пердолинга, сидел 2 часа модифицировал первый шаг из тьюториала, навали костылей, но в целом доволен собой.
Есть папка уровни с кучей уровней, типа 50 уровней. Как лучше всего засунуть эти уровни в массив чтобы звать их по по цифре а не по прямому адресу?
> прошел тогда тьюториал (просто повторил, получил готовую прогу, но по итогу нихуя не понял)
> Сейчас решил подойти более осознанно, что бы чет лучше отложилось в башке - решил въебать побольше пердолинга
Главное - никакой копипасты. Всё ручками перепечатывай.
Папка уровней - в строковую константу. Имена сцен в список. Расширение в константу. Далее:
> change_scene("%s/%s.%s" % [LEVELS_PATH, Levels, LEVEL_EXT])
ууу, ебучая разметка
> change_scene("%s/%s.%s" % [LEVELS_PATH, Levels [ i ], LEVEL_EXT])
Принято. Спасибо
Как же сложно сука...
Только увидел, что у меня хитбокс работает не так, как мне нужно и теперь все переделывать а я уже в своем коде запутался 100 раз и не понимаю даже где начинать искать проблему
Только увидел, что у меня хитбокс работает не так, как мне нужно и теперь все переделывать а я уже в своем коде запутался 100 раз и не понимаю даже где начинать искать проблему
Можно как-то упростить работу с тайлсетами/тайлмапами? Как-то очень уж уныло либо размечать огромный лист и в отдельное место записывать какие координаты за что отвечают, либо добавлять отдельно по тайлу и так же записывать, что с такого-то по такой-то id то-то и то-то. Должно же быть простое и удобное решение, я наверняка что-то упускаю....
Автотайлы есть.
Они же в первую очередь предназначены для автоматического выбора тайлов в зависимости от соседей, а не для каталогизации и более комфортного добавления не?
Я понимаю прекрасно о чем ты и спасибо за совет. Но с синтаксисом то у меня и нет проблемы как раз, ну и пусть я не знаю конечно половину возможностей языка и какие есть функции из коробки, но это пох, я всегда могу и примитивами обойтись.
Реальная головная боль - накликивание в редакторе, всякие вот эти вызовы, сигналы, события.
>Можно как-то упростить работу с тайлсетами/тайлмапами?
Конечно, можно, для этого есть tool скрипты и API редактора, позволяющий добавлять любые свои окошки, кнопки и прочие гуи в гуй редактора.
>Как-то очень уж уныло либо размечать огромный лист и в отдельное место записывать какие координаты за что отвечают, либо добавлять отдельно по тайлу и так же записывать, что с такого-то по такой-то id то-то и то-то.
Я не понял, что ты хочешь сделать?
>каталогизации и более комфортного добавления
Что ты имеешь в виду?
Предполагаю, ты говоришь о каких-то интерактивных предметах на карте. Ответ: их нужно делать отдельно от тайлмапы, если их мало. Если много - это уже что-то вроде ландшафта, тут нужна специальная система в отдельном скрипте, которая будет абстрагировать работу с тайлами от остальной игры, а player будет только запрашивать у этой системы dig(Vector2) и place(Vector2, thing).
>Только увидел, что у меня хитбокс работает не так, как мне нужно и теперь все переделывать а я уже в своем коде запутался 100 раз и не понимаю даже где начинать искать проблему
Тебе нужно рефакторить свой проект, чтобы снизить зацепление между независимыми системами игры и увеличить связность внутри этих систем.
https://ru.wikipedia.org/wiki/Зацепление_(программирование)
Тогда будет меньше путаницы в коде и сможешь легче отлаживать отдельные системы, по необходимости меняя их и расширяя. Godot очень удобен и гибок в этом плане, если правильно использовать предоставленные им инструменты (легко наломать дров, т.к. Godot не навязывает никакой конкретной идеологии, разрешая говнокодить как захочется).
> Я не понял, что ты хочешь сделать?
> Что ты имеешь в виду?
Вот есть например тайлсет с кучей видов ландшафта https://opengameart.org/content/dungeon-crawl-32x32-tiles , я хочу иметь удобную возможность быстро его распарсить и получить возможность быстро из кода ставить тайлы травы/каменных стен/пола из песчанника/другое не через указание конкретного местоположения тайла в тайлсете, а как-то удобнее.
> Предполагаю...
Нет, речь полностью о статике.
>она меняется на следующую
>как сделать так чтобы на новой арене игрок был уже с новыми значениями
Если я правильно тебя понял, то можно так:
>@export var next_level_scene: PackedScene
>@onready var player := $Player
>func _load_next() -> void:
>_ remove_child(player) # выносим игрока из дерева
>_ var next_level := next_level_scene.instanciate()
>_ next_level.add_child(player) # заносим игрока
>_ get_tree().change_scene_to_packed(next_level)
Однако, я бы всё же рекомендовал отказаться от встроенного механизма "change_scene_to..." в пользу создания одной главной сцены game.tscn, которая имеет набор скриптов для управления сменой уровней, переноса игрока, мобов и т.д. Это более сложный подход, но более универсальный, и не задействует костыльные автолоады.
Такое дерево:
>Game
>—GUI
>——MainMenu
>——PauseMenu
>—World
>——Map
>——Mobs
>——Player
Подходит любым играм и, на мой взгляд, нагляднее организует происходящее в игре, чем куча отдельных сцен, сменяющих друг друга вызовом API.
> костыльные автолоады
Не вижу в этом костылей. Встроенный искаропки межанизм добавления ветвей в предоставленное тобой же дерево.
>get_tree().change_scene_to_packed(next_level)
А, блин, тут ошибка, забудь.
...to_packed() создаёт НОВУЮ копию next_level_scene, у которой не будет твоего игрока. И вообще код выше будет высвечивать ошибку типа.
Короче, нужен либо подход с game.tscn, либо костыли в виде автолоадов, другого выхода не вижу.
change_scene_to...() подходит разве что самым простым играм вроде головоломок, где уровни полностью независимы друг от друга.
>Встроенный искаропки межанизм добавления ветвей в предоставленное тобой же дерево.
Проблемы:
1. Это дерево собирается только в рантайме. Да, на запущенном проекте ты видишь это дерево на специальной вкладке сцены, но при создании игры этого дерева нет, а автолоады спрятаны в отдельную вкладку настроек проекта...
2. Эта вкладка с автолоадами - простой список, а не полноценная сцена со всеми преимуществами редактора сцен. Сигналы подключать только через код, дополнительные дети к нодам подключить - нужно лезть в отдельный файл конкретного автолоада и т.д.
3. Эти автолоады стимулируют использование глобальных имён, что может помочь в очень маленьком проекте, но рано или поздно навредит в большом проекте. Нужно разделять игру на меньшие части, которые не знают ничего ни о каких "автолоадах" и не зависят от них.
В целом, они выглядят как костыль, потому что резко отличаются от стандартной работы со сценами. Вот если бы в Godot была одна особая сцена Game, в которой всё было бы как в обычной сцене - и редактор, и всё свойства - кроме того, что она запускается первой и всегда находится в дереве сцены - тогда можно было бы считать это органичным инструментом, а вот автолоады выглядят как уродливый наследственный костыль.
В редких случаях автолоады удобны, да, например, чтобы выводить дебаг информацию поверх всей остальной игры, но полностью строить всю игру на автолоадах неудобно и неэффективно. Я пробовал.
>предоставленное тобой же дерево
Совсем забыл ещё один нюанс. Я предлагаю сделать специальную сцену "игра", которая отражает всю игру в совокупности. Ты предлагаешь конвертировать части этой сцены в автолоады. Возникает проблема: а если я не хочу запускать всю игру? Если я хочу запустить только одну небольшую сцену для теста? В моём примере я просто нажимаю F6 на желаемой сцене, и тогда моя game.tscn полностью игнорируются - движок запускает только ту сцену, которую я хочу проверить в рантайме. В твоём примере ты даже по F6 будешь загружать все менюшки, игрока, кучу менеджеров и т.д., которые для одного конкретного теста могут быть совершенно не нужны или даже откровенно вредить (как потреблением ресурсов, так и какими-то своими модификациями состояния игры).
Поэтому у меня в автозагрузке только самое необходимое, что мне может пригодиться всегда, на любой отдельно взятой сцене, будь эта сцена фрагментом большого мира, отдельным персонажем или вообще гуевой кнопкой, необходимой для большого меню. А это, для примера:
— debug.tscn с базовой информацией о работе игры;
— screenshots.tscn для сохранения снимков экрана;
— console.tscn для каких-то команд (испускает сигналы, которые могут слушать конкретные ноды, если они есть, а если их нет - мешать не будет).
>— debug.tscn
>— screenshots.tscn
>— console.tscn
Кстати, только что осознал, чего мне очень остро не хватает при запуске отдельных 3D сцен: камеры. Камера обычно есть у игрока, и её можно вручную добавить в любую сцену (у меня полностью автономная орбитальная камера, которой можно управлять без игрового персонажа - планирую расширить её способности), но делать это каждый раз для запуска рандомной сцены неудобно. Было бы идеально создать универсальную камеру, которую можно закинуть в автолоад, чтобы наблюдать за любым отдельным 3D объектом (и двигаться в пространстве) в отрыве от остальной игры, не модифицируя отдельные сцены дополнительной камерой...
>Путь к ноде нужен вот зачем.
>Вот и получается что нужно было написать код который на первую же нижнею видимую кнопку вешает фокус с верхних кнопок.
В данном случае путь знать не обязательно.
Если у тебя в нижнем меню только кнопки:
>bottom_menu.get_child(0).grab_focus()
— переключит фокус на первую ноду твоей нижней менюшки, ссылка на которую тебе давно известна.
Если есть другие элементы (надписи и т.п.):
>for child in bottom_menu.get_children():
>_ if child is BaseButton:
>_ _ child.grab_focus()
>_ _ break
— пойдёт по списку детей в нижнем меню, передаст фокус первой кнопке и после этого остановит цикл.
>Если у тебя в нижнем меню только кнопки:
>Если есть другие элементы (надписи и т.п.):
Хотя не, стоп, лучшим вариантом будет передать ответственность за руководство элементами нижнего меню самому нижнему меню. То есть накинуть на него новый простой скрипт с функцией типа "focus_first_button()", тогда ты делаешь просто:
>bottom_menu.focus_first_button()
А уже в скрипте нижнего меню будет твой код:
>func focus_first_button() -> void:
>_ ...
В котором ты скрываешь детали реализации нижнего меню. Таким образом, если твоё меню как-то изменится (добавишь в самое начало меню Label, из-за чего первый пример кода сломается), тебе придётся модифицировать только скрипт нижнего меню, а другие ноды останутся без изменений, т.к. с их точки зрения нижнее меню осталось без изменений - ведь интерфейс (функции) не поменялся.
За 2 недели вката сделал 3 обрубка все по разным туториалам, все три не особо работают как я хочу, и это еще просто системы базовые, про левелдизайн или графику я молчу вообще...
Открываю какой-то туториал, прохожу треть или половину, становится скучно доделывать, решаю делать свое, когда делаю свое понимаю что всё работает ужасно, дропаю, начинаю новый туториал, опять дропаю на половине, опять делаю своё.
Открываю какой-то туториал, прохожу треть или половину, становится скучно доделывать, решаю делать свое, когда делаю свое понимаю что всё работает ужасно, дропаю, начинаю новый туториал, опять дропаю на половине, опять делаю своё.
> Вот если бы в Godot была одна особая сцена Game, в которой всё было бы как в обычной сцене - и редактор, и всё свойства - кроме того, что она запускается первой и всегда находится в дереве сцены - тогда можно было бы считать это органичным инструментом
И, ЧСХ, такая сцена есть. Есть сцена, которая запускается первой, и её можно назвать Game. (Но я обычно называю её Loader)
> В твоём примере ты даже по F6 будешь загружать все менюшки, игрока, кучу менеджеров и т.д.
Эту проблему я решаю тем, что все вышеперечисленные являются стейтмашинами с дефолтным стейтом Idle в котором они ничего не делают, никак не отображаются, ни на что не реагируют. А инициирующие стейты им задаёт Loader.
И по Ф6 я так же могу без задней мысли запускать дебаг любой разрабатываемой субсцены.
> Поэтому у меня в автозагрузке только самое необходимое
А я могу по необходимости протестировать по Ф6 любую сцену вместе с любой автозагрузочной подсистемой, просто прописав в _ready тестируемой сцены: SomeNode.state = SomeNode.States.some_state и сразу получить совместную работу.
В общем, вкусовщина. Спорить бессмысленно.
> 2 недели вката
Ты в начале долгого пути. Если не дропнешь, волшебный мир чудес откроется тебе не ранее, чем через год, а глубину кроличьей норы осознаешь не ранее, чем через три года.
>волшебный мир чудес откроется тебе не ранее, чем через год
Надеюсь к тому времени даст возможность оплачивать слот в стиме самому xdd
*Габен даст возможность оплачивать слот в стиме самому xdd (я из РФ)
Да нахуй тебе габен? Врывайся на новую перспективную платформу - вк-гамес.
Делайте игры.
Я осуждаю вк геймс. А итч перспективная платформа? Может сделать какую-нибудь душевную игру про свою жизнь аутиста-депрессана и собирать донаты. Они дойдут мне на карту?
Я не он, но итчем пользуюсь. Собственно он - основная инди-платформа для геймдева сейчас. Я имею ввиду реально инди, которые сделаны за миску риса, а не за пару зеленых косарей. Он же основная платформа для геймджамов. Монетизироваться можно. Продаваться можно. Удобно получать донаты даже если твоя игра бесплатная.
Деньги тебе не дойдут если ты из РФ, потому что выплаты производятся через пейпал/пейонер, они с РФ больше не работают. Для нулевых налогов придется заполнять W8BEN форму налоговой США, иначе 30% с тебя срежут.
>про свою жизнь аутиста-депрессана
Кстати популярная тема там. Мрачная аутичная эзотерика. И визуальные новеллы. Ебучие визуальные новеллы эвериве.
Да блядь, и тут деньги не вывести. Нахуй так жить? Неужели реально есть только какой-нибудь отечественный аналог патреона или вк-геймс? Я надеялся что богатые европейцы помогут мне перестать быть хиккой, но теперь эта мечта уничтожена на долгое время (навсегда)
Добро пожаловать в реальность в РФ 2к23 года.
Можешь посмотреть в сторону крипты. Существуют виза-карты, привязанные к крипте, но там конторы будут доебывать тебя Know Your Client, чтобы убедиться что ты не подсанкционный.
Либо сгоняй в ближнее зарубежье и открой банк там.
У меня даже на проезд денег нет, лол. Ладно, может быть к моменту как я сделаю игру мы будем жить в новом мире.
Куда мне засунуть инвентарь и интерфейс? Если я все запихну в сцену с игроком норм будет? Не вызовет это проблем при перемещении игрока между сценами?
> мы будем жить в новом мире
И в этом новом мире давайте искать друг-друга по кодовой фразе "годот тред"?
Делайте игры
Игры-то делаете?
Я пытаюсь, но это очень сложно. А как себя мотивировать делать активно если даже в стиме не продать.
Ты главное делой.
Перерыв пока, всё равно интерес волнами с передышка и, а потом с новыми силами
Я делаю шлюхосим вдохновлённый одной настолкой. Но от шлюхосима там пока только я берущий в рот и попу от годота. А так-то не плохо. После рпгма годот просто сказака.
>я берущий в рот и попу от годота
Хорошее начало, я бы посмотрел на такого-то робосексуала.
>шлюхосим вдохновлённый одной настолкой
Это как? Опиши концепцию примерно.
>берущий в рот и попу от годота
Пиши проблемы в тред, всё решим.
>я бы посмотрел на такого-то робосексуала.
Гугли "gay fuck machine".
Серьезно взялся и купил Brotato за 133р в стим. Игра сделана на Godot, даже в начале лого Godot не убрал разраб. Продаж миллионы, в топ 100 стима висела игра на распродаже последней хотя ей больше года. В игре на удивление не так много полиша, как я думал по видосам. Например на моем компе 2015 года она реально лагает когда много врагов. Плюс сама графика и интерфейс просто свалены в кучу, стандартный шрифт которым написано вообще все в игре, анимации всех врагов это покраснение когда стреляешь в них и растягивание вверх-вниз одного фрейма. В принципе у мобов спрайт поворачивается только налево и направо.
Интуитивно кажется, что за год игру подобной сложности реализации более чем можно сделать.
Интуитивно кажется, что за год игру подобной сложности реализации более чем можно сделать.
>Куда мне засунуть инвентарь и интерфейс?
Интерфейс можно поделить на части. Всякие общие абстрактные менюшки должны быть ближе к корню дерева, а локальные контекстные мелочи могут прикрепляться к конкретным объектам: игроку, неигровым персонажам, сундукам и т.п.
С инвентарём сложнее. Зависит от того, что этот инвентарь из себя представляет для игрового мира, с чем он может взаимодействовать и т.д.
>Если я все запихну в сцену с игроком норм будет?
Тогда твоя сцена игрока может быть вынуждена давать API для доступа к интерфейсу и инвентарю из других нод, которым может потребоваться что-то сообщить или взять из инвентаря... В общем, нужно рассматривать дизайн игры в целом.
>Не вызовет это проблем при перемещении игрока между сценами?
Зависит от того, как ты перемещаешь игрока.
>Интуитивно кажется, что за год игру подобной сложности реализации более чем можно сделать.
Если ты не полный ньюфаг, а хорошо разбираешься в геймдеве и необходимых инструментах, то такую игру можно и за пару недель слепить или даже быстрее.
>становится скучно доделывать
>всё работает ужасно, дропаю
>опять дропаю на половине
>про свою жизнь аутиста-депрессана
>помогут мне перестать быть хиккой
>У меня даже на проезд денег нет
Обратись к участковому психиатру, опиши ситуацию, собери необходимые бумажки и полежи 30 дней в стационаре, сможешь оформить инвалидность и начать получать пенсию по инвалидности.
Уже как-то неловко обсуждать нерелейтед, но у меня нет диагноза, я ни разу не был у психиатра, я думаю, что мне скажут что я хочу откосить или что я просто ленивый/никчемный сам по себе и пенсия мне не положена. Если совсем припрёт я попробую, но мне очень страшно так делать. У меня есть близкий родственник с настоящей психической болезнью которую даже нормисы могут признать, и то им страшно проходить через все стадии оформления инвалидности, хотя работать на обычной работе они так же могут только через титанические усилия.
так ты просто не надрочен на учебу и все, сейчас 75% людей такие. А на дваче так и вообще все 90%. Мы привыкли к 15-минутным отрезкам внимания, а потом хуяк и че там нового в телеге или о новый интересный видосик, ща прервусь ка.
Это надо брать себя в руки и через силу дисциплинировать. Через боль и страдания садиться и завершать шаг за шагом нахуй сначала 1 туториал, потом второй. И только когда чет доделал - тогда уже отвлекаться на ебаные видосики и прочий быстрый дофаминчик)))
>Мы привыкли к 15-минутным отрезкам внимания, а потом хуяк и че там нового в телеге или о новый интересный видосик, ща прервусь ка.
1) Практически все обучающие видосы имеют хронометраж около 15 минут; Паштет так вообще шортсы пилит (поэтому его не смотрел никогда, невозможно это говно с компа смотреть).
2) Быстрый дофаминчик можно компенсировать шоколадкой. Выполнил тутор - откусил немного сладенького. Но, конечно, тут сильно от обмена веществ зависит, кому-то такое противопоказано.
3) Это всё никак не связано с умением обучаться тащемта. Уметь учиться - это способность преодолеть страх перед непознанным, переступить через "я этого не умею" и начать пытаться делать пусть даже и хуйню, но пытаться. Поменять образ мысли на "я этого ЕЩЁ не умею". Спрашивать непонятное у гугла, у чатгпт, у треда (но в первую очередь курить доки, конечно). И ни в коем случае не поддаваться эмоциям, если оно не получается: это не потому что ты дебил, а потому что тебе ещё есть чему учиться.
И да, я это сообщение пишу, потому что отвлёкся. Сейчас отправлю его - и буду дальше доделывать игру. Там осталась вообще хуйня - исправить анимацию одного врага и пройти-протестить всю игру пару раз.
Внезапно я этого не знал. Ща поменял - стало прям лучше.
>Там осталась вообще хуйня - исправить анимацию одного врага и пройти-протестить всю игру пару раз.
Что будешь дальше делать с игрой?
Да, тебе нужно в /psy/, там пояснят за нюансы.
>нет диагноза, я ни разу не был у психиатра
"Нет здоровых, есть недообследованные".
>скажут что я хочу откосить
Люди с психическими проблемами в армии и тем более на фронте никому не нужны, т.к. подвергают риску и себя, и окружающих вблизи оружия.
>У меня есть близкий родственник с настоящей психической болезнью
О-о-о, ну всё, это даёт +9999 очков к диагнозу.
>страшно проходить через все стадии оформления инвалидности
Нет там ничего страшного. Просто вопросы задают, потом выносят вердикт... Мне вот вторую группу инвалидности дали, когда я пояснял, что буду зарабатывать разработкой видеоигр...
>привыкли к 15-минутным отрезкам внимания
На самом деле, это нормально, так и должно быть.
>обучающие видосы
Лучше бы книжки умные читал и документацию...
>Быстрый дофаминчик можно компенсировать шоколадкой. Выполнил тутор - откусил немного сладенького.
Если тебе шоколад даёт больше дофамина, чем создание видеоигры своими руками, тогда бросай геймдев - это не твоё, становись кондитером.
>Поменять образ мысли на "я этого ЕЩЁ не умею".
Мне это не мешает психануть: "ой, да и хрен с ним, с геймдевом, пойду лучше чем-то другим займусь, что у меня точно получается уже сейчас".
Посмотрел какой-то рандомный видос где подпивас поясняет как он за год разработки игр заработал миллион рублей на яндекс играх. Смотрю его игры: 10 игр где весь геймплей это одна кнопка посреди экрана и сценарий в духе "не кликай на меня!", длятся минут по 15. Еще 5 игр какие-то простые дрессапы или "найди 5 отличий" из 2007 года. Ебануться. Может продать жопу отечественным сервисам всё-таки? Это даже не бротато, это 1/100 от бротато.
Всё так, гиперказуал и мобилки это основные деньги сейчас.
>На самом деле, это нормально, так и должно быть.
В игры ты тоже по 15 минут играешь и фильм полуторачасовой тоже смотришь прерываясь каждые 15 минут на видос? Я думаю что нет. Если бы не было отвлекающих факторов, то оно бы как-то само все делалось часами и было бы норм, и творчество и учеба и тд.
А так мы в зависимости как курильщики, которым надо каждый час пыхать, так же и тут, надо постоянно чекать че там на дваче.
>В игры ты тоже по 15 минут играешь и фильм полуторачасовой тоже смотришь прерываясь каждые 15 минут на видос?
Я не он, но да
В последние годы да, особенно аниме, как раз там две 10 минутные секции обычно (минус опенинги).
Никакой обычный не надроченный человек не сможет играть в шахматы сессиями по 2 часа, например. Ты играешь 3 блитца максимум и чилишь, пытаясь обработать процесс.
Зависит от сложности игры и нагрузки на мозг.
Лень немного спорить с зумерами если честно, которые выросли со сматрфонами с пеленок и воспринимают свой 8 секундый avg attention span как единственный варик.
Кто-нибудь знает где делать простые анимации? Не пиксельные, не сложные. Как в Brotato или флешовом Айзеке, большие мазки, без особых деталей, 2-3 фрейма чисто слепить.
А в чем проблема нарисовать их в фотошопе или крите, если они настолько простые?
> Мне вот вторую группу инвалидности дали, когда я пояснял, что буду зарабатывать разработкой видеоигр...
Вголос взоржал! Умеешь разрядить обстановку. Малаца!
>Это даже не бротато, это 1/100 от бротато.
Учитывай, сколько денег нужно вбухать в рекламу.
>заработал миллион рублей на яндекс играх
Это из серии "как заработать миллион рублей, если у вас уже есть лишний миллион рублей".
С тем же успехом можно иметь 5-10 миллионов на вкладах в банке и жить на одни только проценты, рассказывая всем, как хорошо жить на проценты.
>В игры ты тоже по 15 минут играешь
Сейчас популярны сессионки, где матч до 15 минут зачастую даже не дотягивает. В GTA одна миссия по времени обычно значительно короче получаса, если специально не растягивать, и сама миссия по сути составлена из коротких кусков. В GTA Online на многие задания даже специально вешают таймер в 15-30 минут, но этот таймер с запасом в 2-3 раза.
>прерываясь каждые 15 минут на видос
Ты не понял. Вроде есть какая-то инфа про то, как мозг периодически чистит кэш краткосрочную память, и это неизбежно происходит каждые ~15 минут, даже если ты этого не замечаешь (хе-хе, как заметить то, что ты забыл?). Ты можешь заниматься чем-то значительно дольше 15 минут, но для этого нужно разделять это что-то на короткие по времени куски или использовать внешние костыли (записи в тетрадке, программы с заметками), потому что удерживать всё и сразу в собственной краткосрочной памяти ты физически не можешь на длинной дистанции, у тебя как будто что-то переполняется и всё. Поэтому так важно заниматься декомпозицией и планированием, чтобы не держать всё в не предназначенной для этого голове примата, эволюция мозга которого принципиально не успевает за развитием культуры и технологий.
В играх делают миссии, главы, уровни, этапы или сессии; в фильмах это выражается в виде отдельных коротких сцен, между которыми связь слабее (общие персонажи, которых ты в долгосрочной памяти сохраняешь, глобальное развитие сюжета), чем внутри отдельной сцены (кто, где, что, зачем, почему, как делает, о чём говорят и т.д.). Конечно, всё зависит от того, требуется ли тебе удерживать какие-то данные в краткосрочной памяти дольше 15 минут или ты просто зажимаешь W, не задумываясь ни о чём дольше 5 секунд последнего момента, как в гоночках каких-нибудь, где тебе нужно думать только о том, как пройти поворот или обойти соперника, а общая картина гонки значения не имеет, или как в ситкоме, где развития сюжета вообще нет и есть только гэги, смешные сами по себе, вне какого-либо контекста.
Прерывание на видос может быть связано с тем, что в момент сброса памяти у тебя может измениться настроение, ты можешь переключиться на какую-то случайную фоновую мысль и из-за этого отвлечься от текущей задачи. Ты как бы "умираешь" и "новый ты" уже не очень заинтересован текущей задачей.
Похожее происходит, когда люди переходят из одной комнаты в другую, резко забывая, о чём думали и зачем вообще шли сюда - всё потому, что мозг как будто бы захардкожен сбрасывать краткосрочную память при резкой смене обстановки. Может, диким животным этот механизм очень важен, но не очень подходит для жизни современного человека.
Во, кстати, Godot очень выгоден тем, что позволяет совершать большинство действий в одной и той же обстановке (окно программы с единым GUI) и даёт возможность максимально сократить итерации разработки (делаем отдельные сцены и сразу же их тестируем, хоть каждую строчку кода запускай). Поэтому он лучше всего подходит для прототипов, даже если в нём не хватает некоторых фич.
Это всё, конечно, диванная психология, не знаю, как это можно проверить; считай, это предположения, основанные в основном на личном опыте.
Какие кстати комьюнити есть, куда ок забрасывать свою игру? Сабреддит годоти, дискорд, что еще? Сабреддитов по геймдеву вроде полно, но в крупные чет хуй пролезешь.
В срачетред забрасывай. Там твоя комьюнитя.
2.5 анонимуса - в плане популярности выхлоп никакой.
>Мне это не мешает психануть:
Научение тоже может быть краткосрочной (~15мин) задачей. И получается, что я вот прямо сейчас могу зайти в доки и прочитать описание одной функции одного класса, таким образом преодолеваю порог "могу сделать сейчас".
>шоколад даёт больше дофамина, чем создание видеоигры своими руками,
Тащемта нет, он помогает мне в любых ситуациях, когда "чёт влом". Да и сам же понимаешь - всегда есть рутинные моменты, которые надо сесть и сделать. Или вот довести проект до конца, когда мозг начинает сопротивляться, потому что процесс создания игры доставляет гарантированный дофамин, а чё там будет после релиза - хуй знает, страааашна, какие-то люди играть будут, баги найдут, заскучают, дропнут.
>на яндекс играх
Вообще, туда определённо надо закинуть. Никто в любом случае руку за это не откусит и эксклюзивные права на жопу не затребует. А платформой вроде бы пользуются, люди вроде бы играют, так что миллион не миллион, а закинуть туда игру надо.
Хех, гиперказуалки для яндекса. Звучит неиронично как хороший бизнес-план.
>Что будешь дальше делать с игрой?
Яндекс, вк, итч, чотамещёесть. Учитывая, что это не гиперказуалка, к тому же мой первый крупный проект, заработать я на нём ожидаю разве что репу и экспу.
Белорусам ещё отправлю на их шоу, вдруг оценят.
>Это как? Опиши концепцию примерно.
Я решил пойти путём Камия Рё, как он когда-то для свой мэйд рпг украл систему у fantasy flight games. Да так хорошо украл, что мейдочку можно было очень легко конвертировать в оригинальную рпгшку и заставить сносить бошки ксеносам.
Я решил сделать всё точно так же как и он. Я в 18 году срочку в гомо-армии служил. Там пизда была. У меня один раз штаны спиздили, а другой раз в наряде чуть офицеры не выебали. Вот я и подумал, что неплохо переложить свой экспириенс в игру, только вместо двачера у нас будет секси главная героиня уже у которой будут пиздить штаны и которую будут ебать офицеры. Всё это под комбат украденый у Рё и ффг.
Такой вот концепт.
Они врали про защиту сапогов.... Чтобы отвлечь от защиту штанов....
> Такой вот концепт.
К сожалению, это не концепт. Со всем уважением к твоим страданиям. По крайней мере, это не концепт игры, это концепт дрочильного рассказика для стульчик-нэт.
Концепт игры это описание игровых циклов:
1. Перетасовать колоду.
2. Раздать игрокам по 6 карт.
3. Достать одну карту и положить на неё колоду.
4. Выкладывая карты по одной побивать карты соперника.
5. Профит.
>это концепт дрочильного рассказика для стульчик-нэт.
Ты сейчас мою жизнь сравнил с рассказом со стульчик-нэт? Ты чё нах?
>К сожалению, это не концепт.
А. Ну так-то да. Игре всего две недели от роду просто и пока что кроме как пощёлкать менюшки в ней ничего нельзя. Плюс я вообще не уверен, что осилю сделать интересно, так что пока что занимаюсь базовыми механиками.
Вот примерный концепт. Надеюсь, так чуть понятнее.
Игра состоит из двух частей. Первая это обычная бытовуха с менеджментом таких стат как: пожрать, поспать, стресс. В этой части мы потихонечку через расписание занятий прокачиваем скиллы нашего чара, а статы как раз играют роль ограничителей (ну т.е. если не хватает сна, то проёбываем занятия которые могут повысить скилл, а проёбаные занятия, это опездюливание от старших и стресс, который влияет на высыпаемость в ночь и который в свою очередь не даёт нормально учится и тренироваться, при этом единственное на что хватает сил в день – это лечь на кровать и получить пизды и т.д и т.п). Два занятия в день оформленные мини-играми (мудрый крот какой-нибудь и разрешить небольшой ивентик или пройти чек на скилл) и свободное время вечером на покупку печенюх. Комбат будет прокаться по сюжету на какой-нибудь 1488 день, а вот будет ли чар игрока к нему готов уж тут как сложиться (если не готов, то смертью заканчивать не хочу, а то софтлок).
Вторая часть - комбат. Пошаг. Выглядит примерно, как рпгмовский т.е. никого движения только статика. Проблема в том, что такую боёвку очень легко сделать однообразной, даже если использовать рулбук древних и слизать от туда всю систему. У меня есть пару идей как сделать более-менее интересно, но пока не начну, собственно, программировать комбат сказать что-то сложно. Поэтому пока решил упор сделать на мини-игры в той части игры, где комбата нет. Сейчас делаю мини-игру про заступление в наряд по штабу и уже от этого буду отталкиваться. Если получится сделать интересно - буду продолжать пилить всё остальное. Если не осилю даже такое простецкое, то буду вообще всё с нуля пересматривать.
Знаю, что звучит как сумбурное говно, но по традиции всё придётся урезать и поменять (а потом и отменить нахуй) ещё много раз. Так что пока сильно не беспокоюсь. Первая же законченная мини-игра покажет, что мне от себя ожидать и стоит ли продолжать всё это.
Ты только что Degrees of Lewdity
Насколько Годотя удобна для простого 3д?
Получиться ли че-то годное если просто пиздить чужие коды под нужные тебе вещи?
Есть какие-нибудь расширения или ещё что, улучшающие работу с с# изнутри годота? Хотя бы поиск по всем файлам?
Для начала научись писать название движка без ошибок.
Я бы брал стороннюю IDE, типа VSCode.
Делал свою игру для яндекс.игр на годоте последней версии и уже на этапах как заливал осознал, что Яндекс Игры просто не поддерживают Годот 4.
Неужели открывать Годот 3 (а какой именно?) и там пилить всё заново? Пиздец...
Неужели открывать Годот 3 (а какой именно?) и там пилить всё заново? Пиздец...
>Яндекс Игры просто не поддерживают Годот 4.
В чем проявляется? Что именно? Какая конкретная техническая проблема?
>Неужели открывать Годот 3 (а какой именно?)
Для веба и мобилок имеет смысл, в треде давно это говорят.
LTS сейчас 3.5.2, но 3.6 тоже норм в принципе.
Ну и тести на раннем этапе.
> там пилить всё заново?
В зависимости от игры, возможно практически ничего переделывать не придется, на день работы.
The following features required to run Godot projects on the Web are missing:
Cross Origin Isolation - Check web server configuration (send correct headers)
SharedArrayBuffer - Check web server configuration (send correct headers)
Но в целом уже в гугле тоже прочитал что годот 4 для веба не подходит... обосрамс
Обе эти хуиты и для 3 нужны. Во всяком случае моя веб-игра на итче не работает если не поставить на страничке эти галки. На CORS жалуется.
На какой страничке? В интерфейсе яндекса и галок никаких нет, просто кидаешь архив и тестишь, нихуя не работает.
Там Петя Сканер вышел на связь
https://www.youtube.com/watch?v=VQ2SAAhIut8
https://www.youtube.com/watch?v=VQ2SAAhIut8
По идее и то и другое включается на сервере. Так что тебе имеет смысл связаться с техподдержкой яндекса.
В 3-ке SharedArrayBuffer вроде опциональны, только если экспортить html-threads версию. А CORS вроде бы тоже сам по себе не нужен, просто его тянет за собой SharedArrayBuffer.
Не знаю какие минусы если не экспортить в 3-ке многотопоточную. Читал что звук может лагать, но я такого не заметил даже на некрожелезе.
Итча.
Зависит от того, используешь ли треды в своей игре. У меня используются, так что, видимо, эта залупень мне нужна и в трешке.
Ну а что будет если их нет в веб версии? Просто блокирующая синхронная загрузка? Я не проверял.
Проебланил второй день подряд без открывания туториалов :(
Делай игры.
Начинаю делать игру и планирую заработать с нее минимум 10 рублей.
Звук лагает в экспорте в хтмл5 из Годот3. Как фиксить?
ЛОЛ, он серьёзно предлагает СПАМИТЬ в каменты названием его игры, чтобы после 25 таких каментов получить бан и ключ на его дурацкую игру, которую все кто хотел бесплатно на андроиде прошли. Или спиратят и пройдут на торрентах. Или посмотрят тот же летсплей, чай у него не сессионка.
Хотя с его числом подписчиков дурачки найдутся.
Стыдно за наш игрострой...
Предлагаю новое погоняло - Петя Спамер
>только вместо двачера у нас будет секси главная героиня уже у которой будут пиздить штаны и которую будут ебать офицеры.
Ты уверен, что сеттинг "тян в армии" будет популярен у твоей целевой аудитории (дрочеров)? Или ты сам дрочишь на тян в униформе? Иначе не понимаю, зачем нужен именно такой сеттинг...
>Вот примерный концепт.
Не вижу в нём "шлюхосим". Секс-то будет вообще?
>Degrees of Lewdity
Там симулятор выживания лоли...
Тем не менее куча механик, которые он хочет
Можно как-то напрочь удалить шаблон экспорта чтобы заново его скачать? У меня есть подозрение, что мой шаблон неправильный и как-то неправильно экспортирует, потому что 3.5 должен нормально на HTML5 экспортировать. А у меня даёт ошибку с shared array bufferом.
>удалить шаблон экспорта
На Windows открываешь примерно это:
>%appdata%\Godot\
Там ищешь export или что-то похожее -> удаляешь.
На линуксе сам ищи, тыжлинуксоид, разберёшься.
Проверь как я писал выше в 3ке есть разные варианты экспорта, SharedArrayBuffer это когда версия с thread, попробуй regular.
Я поставил regular, отключил компрессию vram, поставил GLES2. Всё равно в ебучем черновике яндекса не запускается. На версии 3.5.2. Я ща ебанусь уже, везде работает, в локалхосте работает, в итче работает, только конкретно на яндексе не работает.
В продолжение: может в самой игре что-то не даёт экспортироваться нормально или использует треды или еще что-нибудь такое? Как это вычислить?
Хотя вряд ли, даже новый файл где есть нод2д и спрайт с иконкой годота созданный за 5 секунд не экспортируется в черновик яндекса. Где-то точно настройки неправильные или экспорт темплейт, но я сто раз перепроверил настройки которые знаю и переустановил темплейты, все равно не работает.
Не может быть так что закэшировался какой-то предыдущий билд?
Если ты сам в коде треды не используешь то экспорт с тредами тебе не нужен.
А в браузере консоль разработчика пишет какие-то ошибки?
Но я все таки на твоем месте написал бы в поддержку - не похоже что тут кто то пробовал туда выкладывать.
Всё, разобрался. Дело было в том, что я долбоёб. Я неправильно интерпретировал интерфейс яндекса и не понял, что надо подтверждать загрузку нового билда каждого. Короче пиздец.
Ну вот я поэтому и подумал про кэширование. Я так на итче обламывался поначалу, то не заметил что версия залитая через butler не заменила ту что сначала сделал при создании странички, то заливал версию забыв экспортнуть. Потом стал писать номер версии на сплеш скрине чтобы хотя бы замечать что тестирую.
Кстати, яндекс игры требует при реге какое-то удостоверение личности?
На реге вроде имя просит, потом на выводе собственно денег уже просит документы.
Можно как-нибудь отключить сортировку ysort для одной ноды?
Хош прямо щас перекачу? Этой пикчей катить?
Шапка: https://hipolink.me/godothread
Предыдущий:
Архивный: