Шапка: https://hipolink.me/godothread
Предыдущий: >>882096 (OP)
Архивный: >>873235 (OP)
Как-то в этот раз неудачно перекатил. Ну да ладно.
>Ты уверен, что сеттинг "тян в армии" будет популярен у твоей целевой аудитории (дрочеров)? Или ты сам дрочишь на тян в униформе? Иначе не понимаю, зачем нужен именно такой сеттинг...
Да "дрочерам" только дай подрочить, сеттинг не так и важен, хотя, конечно, хороший и проработанный хоть чуть-чуть будет плюсом. Моя целевая аудитория это - преимущественно я сам, так-как делаю говно, а не игры. А мне интересно над таким поработать, так что тут проблем нет. Уж лучше работать над чем-то интересным мне, так-как если оно не получится хорошо, то будет не так обидно за потраченное время.
>Не вижу в нём "шлюхосим". Секс-то будет вообще?
Да.
>Да "дрочерам" только дай подрочить
Это было бы верно в 90-х с распространением порноигр на дискетах среди знакомых, а не в эпоху неограниченного доступа в интернет...
>Моя целевая аудитория это - преимущественно я сам
Тогда ладно, просто любопытно было.
>так как делаю говно, а не игры.
С таким настроем развиваться тяжелее.
>Уж лучше работать над чем-то интересным мне, так как если оно не получится хорошо, то будет не так обидно за потраченное время.
Тут полностью согласен.
>Это было бы верно в 90-х с распространением порноигр на дискетах среди знакомых
Кринж
>а не в эпоху неограниченного доступа в интернет...
Толку от этого, если информации стало больше, но не очень? Все любители порноигр только и ждут обновления игр и скучают по новенькому.
А как заработать на этом если сейчас ни патреона, ни даже стима?
Кстати, моральный вопрос: я бы постеснялся выкладывать порноигру в стим со своего основного аккаунта. Типа там же мои данные, имя и связанный счет.
Самый пиздец это фурри, там основные деньги
>>890234
Выкладывать порноигру это в принципе задачка, учитывая законы
>информации стало больше, но не очень
При чём тут информация? Зайди в любой поисковик, выключи фильтры и набери "порно". Молодец, теперь можешь обдрочиться до потери пульса как тот хикка из Японии, откинувшийся с 42 оргазмов из-за того, что выкончал из себя все запасы воды.
>Все любители порноигр только и ждут обновления игр и скучают по новенькому.
Что там "новенького"-то?
>Ого, эту default_woman_01.obj натягивает на свой дрын default_man_01.obj, охренеть, дайте две!!
Так, что ли? Банальщина...
Я и сам считаю себя кумером, у меня прямо как в том мемесе дрочильная левая рука сильнее ведущей правой, лол. Рекорд был, наверное, раз 6 в день? Не помню точно, я обычно не считаю. Короче, я видел некоторые вещи, о которых ты, вероятно, даже не мог подумать. И даже их в интернете избыток, не хватает разве что совсем уж нишевых вещей. Всякой банальщины столько, что на всё дрочить некогда.
А порноигры вообще очень специфичная тема. Если картинки в интернете ты можешь быстро листать, у видео есть перемотка, то в игру с геймплеем (не ВН) приходится вкладывать куда больше времени и сил, так что на дрочку не остаётся ни сил, ни желания, да и контент чаще всего очень слабый, не заводит.
Так что мне очень сложно представить себе того человека, который ждёт очередной банальной порноигры, в которой нет ничего нового и дрочить тупо не на что, просто одно и то же в 100500-й раз.
Лол, повторяют одни и те же позы из раза в раз, хотя казалось бы - открой Камасутру и выбирай что-то наименее заезженное, нет, выбирают самые банальные, затраханные до дыр позы...
Удалено за ненадобностью - судя по статистике оно нахуй никому не нужно оказалось. Возможно переработают и вернут однажды, но это не точно.
Жоско. Придётся учить не понятное пограмирование. Ну хотя бы все остальное в движке довольно просто освоилось
Даже визуальное программирование - всё равно программирование, ты по сути всё равно описываешь что откуда взять и что с этим сделать.
Оно не делает получение результата принципиально проще.
Этого двачую. У меня тут есть соседний тред визуального программирования для детей (scratch/snap) и там я начинал делать транскомпилер, который бы выдавал код на гдскрипте из блоков визуального кода ( >>833827 → ), но лень матушка помогла мне осознать, что занятие это бессмысленное и безблагодатное (ну еще анон мудрый обрисовал мне грамотно весь фронт работ предстоящих). А так-то у меня пакрасате было. В специальный блок накидываешь блоки и формируешь готовый скрипт одним кликом мышки.
Карочи, не усложняйте себе жизнь и учите ЯПы. Визуальный кодинг - это игрушка дьявола, ежжы.
Я когда на рпгме работал просто ахуел от невозможности понимать js. Представляю какая каша в визуале. Код свой нужно от и до понимать (практически), а то заебёшся новые фичи вводить и дебагать.
>>890679
>Визуальный кодинг - это игрушка дьявола, ежжы.
Двачую.
>>890713
Я так учил. Есть гайд на ютубе "Пилим свою акшин рпг", там практически вся база и для тренировки само то. Потом начинаешь уже свои хотелки кодить. Если что-то не понятно, то гуглиш и спрашиваешь в этом треде. Сам гдскрипт не сложный и из моего опыта не столько нужно сам язык знать, сколько как его применить. Я в программировании около нулевой, но пока что работать в годоте довольно приятно и без всяких вижуалов.
Можно как-нибудь в годоте установить фокус на ноду через код, будто я кликнул на неё мышкой?
Здравствуйте, я Кирилл.
Хочу создать ТДшку со подачей стори ВН-стайл.
Там должен бегать рабочий и строить башенки, а злые будут набигать и убивать рабочего и башенки. Причем злые должны быть заскриптованы - одни в приоритете убивают рабочего, другие - башенки.
А еще там должна быть охрана дворца, которая помогает защищать строящиеся башенки. И техдрево для рабочего и злых.
Накидайте туториалов, джвадцать лет жду такую игру.
Вы получаете первое предупреждение.
Движкосрач в отдельном треде.
Визуальное программирование это когда не пишешь ни одной строчки кода, не надо даже знать что такое класс, это хорошо реализовано в UE5 на блюпринтах. VisualScript из годота выпиливают и правильно делают, поддерживать это говно слишком дорого и профита минимум.
Визуальное программирование - это когда блок-схему рисуешь вместо печатания слов.
Я очень хочу создать эту игру потому что её сюжет будет раскрывать тему которая коснулась лично меня и возможно даже очень многих двачеров. Если кого-то интересует подробнее - пишите в телеграм @MarganecRPG(я стесняюсь при всех на дваче писать а то вдруг засмеют за идею истории). Очень приветствую 3д модельеров, программистов(я сам в этом деле ну просто очень плох, вернее, у меня лучше идут дела с С# в Юнити чем с ГДскриптом), ну и дизайнеров интерфейса(я вроде бы и сам могу, а вроде бы и... ну на скринах можете видеть).
Наес. ГДСкрипт попроще шарпа. Все получится.
>>891469
Вполне. В 4 заебатую навигацию еще сделали.
В шарпе некоторые вещи удобнее, например те же несколько классов в одном файле
> несколько классов в одном файле
Гдскрипт может. С оговоpками конечно, но может.
Сколько раз сталкивался, в итоге все равно приходилось выносить класс в отдельный файл. Просто потому, что обычно это сущность которая нужна и из других классов.
Но как написал анон выше, в гдскрипте тоже можно ограниченно писать классы в одном файле.
class_name MainClass
extends Node
bla_bla
class ClassA:
_var a: int
_func methodA(): ...
var objA: ClassA
Как сделать так чтобы ходить, как сделать так чтобы спавнился прожектайл, как решить то, сё. И все гуглится. И игра сделалась просто по гуглу каждого момента. В чем минусы такой стратегии?
В том, что однажды не найдешь готовых решений, либо не сможешь склеить их в кучу.
А если я учусь и не добавляю код, если четко не понимаю, что он делает?
> обычно это сущность которая нужна и из других классов
Всю ночь размышлял над примером гарантированно локального класса, который уж точно нигде не потребуется и не придумал ничего, что нельзя было бы оспорить.
тот анон выше
> А если я учусь и не добавляю код, если четко не понимаю, что он делает?
Если я учусь, я создаю учебный проект, который не жалко стереть. Добавляю в него код, который я не знаю что делает, смотрю, что он делает, и после этого знаю, что код делает.
Кроме того, в большинстве случаев код самодокументируем, одного взгляда на него достаточно, чтобы узнать, что он делает.
>зачем они скопировали синтаксис для gdscript из ебучего питона?
Затем, что это база. Просто, удобно, лаконично.
>После жс, котлина и шарпа это такая поебота.
А мне после Паскаля физически больно видеть "{}".
>Каждый раз ебусь с этими отступами когда надо скопипастить блоки кода, каждую строку приходится перепроверять чтобы там что-нибудь не ебнулось с иерархией.
Копипастить код категорически вредно, не важно, копипастишь ты чужой код из интернета или свой собственный. Если ты чувствуешь необходимость в копипасте - знай, ты делаешь какое-то говно, которое потом несколько раз в ногу выстрелит и граблями по затылку ударит в любом проекте сложнее hello world. Помни это и избегай копипасты.
>Удаляешь один иф - и все по пизде пошло.
1. Выдели блок кода и нажми shift+tab, чтобы убрать отступы на один уровень. Чтобы добавить отступы на один уровень, выдели блок кода и нажми tab.
2. Твои функции/методы не должны содержать в себе больше 7 смысловых единиц. Если у тебя проблемы из-за одного if, тогда у тебя там, скорее всего, портянка на три экрана - срочно разделяй её на более короткие подпрограммы. Гугли Forth.
3. Godot разрешает иметь лишние отступы. Если твой if не имеет else, можно сделать так:
>func do_something(arg):
># if arg is something:
>_ _ actually_do(arg)
Как видишь, здесь есть лишний отступ из-за того, что if был удалён, но Godot ругаться не будет.
>Переносишь логику в отдельный метод - будь добр пересчитать невидимые табы.
Перенос в отдельный метод крайне прост:
1. Выделить блок кода.
2. Нажать shift+tab необходимое число раз.
3. Нажать ctrl+x и ctrl+v в другом месте,
- либо перетащить выделенный код мышкой,
- либо добавить новый func () перед блоком кода.
Кроме того, табы легко сделать видимыми и легко изменить их ширину в настройках редактора. Я привык к ширине в два пробела и включил отображение стрелочек - очень удобно и аккуратно.
Наконец, если тебе слишком часто приходится пересчитывать отступы, это значит, что у тебя там огромные портянки говнокода. Не проблема языка.
>Когда есть {} то вообще похкй на такие недопроблемы.
Ага, только код отвратительно выглядит и плохо читается, скобачки занимают лишние строки или визуально теряются на фоне остальных команд. Фигурные скобки - самый отвратный спецсимвол. Слишком похожи на () и [], в большинстве шрифтов слишком тонкие, "соски" размером меньше пикселя.
Единственный плюс операторных скобок - IDE может отформатировать твою портянку говнокода вместо тебя, но большинство говнокодеров даже не могут найти шорткат для этой функции.
Тоже раньше с подозрением относился к значимым отступам в коде, но теперь понимаю их важность.
Алсо, добавлю, что GDScript позволяет записывать код в одну строчку через точку с запятой:
>if something: do_1(); do_2(); else: do_else();
>for node in nodes: node.do(); node.queue_free();
>func do(x) -> int: var y=x; return x+y;
Так не рекомендуется делать из-за того, что такой код сложнее читать, но фича в языке есть и в некоторых случаях удобнее переноса каждой команды на отдельную строку с отступом.
>>891056
>Движкосрач
Ты чего так легко триггеришься? Возмущение особенностями незнакомого языка нормально. Я предполагаю, что тот анон просто не знает всех настроек и шорткатов редактора.
Особенно это касается новичков, которые только научились код печатать, но не шарят во всей теоретической базе программирования.
> Если ты чувствуешь необходимость в копипасте - знай, ты делаешь какое-то говно, которое потом несколько раз в ногу выстрелит и граблями по затылку ударит в любом проекте сложнее hello world. Помни это и избегай копипасты.
Решительно двачую. Копи/пасте должно работать только на уровне файловой системы. Ранее написанный код всем файлом целиком копипастится в нужную директорию и там подключается, и не требует каких-либо внутренних переделок. Это и есть модульность, а не эти вот копипастинги портянок кода из метода в метод.
>выносить класс в отдельный файл.
>сущность которая нужна и из других классов.
Если не ошибаюсь, к "локальным" классам можно обращаться извне скрипта, создавать их и т.д.
Прямо сейчас проверить не могу, но я когда-то экспериментировал с этим и у меня получалось.
Это, вроде бы, похоже на обращение к enum.
>В чем минусы такой стратегии?
1. В уроках из интернета часто грубый код, не оптимальный, годный только для обучения.
2. Конкретно твоя игра может требовать некие оптимизации, тогда как учебный код сделан для максимально общего случая.
3. Как уже сказали, ты можешь придумать то, чего в интернете в готовом виде нет. А у тебя нет навыка самостоятельного решения задач, потому что ты не создаёшь своим умом, а копипастишь.
4. Даже если ты понимаешь свою копипасту и запоминаешь все функции API движка, у тебя не формируется навыков решения задач в общем случае. Сейчас ты выучил только "если есть проблема, нужно загуглить и скопировать код".
Ну и по мелочи, вроде устаревшего кода в старых туториалах, вопросов лицензирования в случае достаточно крупных фрагментов кода и т.д.
Кстати да, модификаторов доступа тонет. Теоретически ничто не мешает сделать инстанс внутреннего класса из инстанса родительского класса, а может даже и из имени класса даже без инстанса.
Усё работает!
Нашёл вот такое обсуждение, где это упоминают:
https://github.com/godotengine/godot-proposals/issues/240#issuecomment-555785392
>Визуальное программирование - это когда блок-схему рисуешь вместо печатания слов.
Нет, блок-схемы - это визуальная версия императивного программирования.
>>891209
>Визуальное программирование это когда не пишешь ни одной строчки кода, не надо даже знать что такое класс
Нет, в визуальном программировании тоже приходится много печатать, и тоже нужно хотя бы интуитивно понимать различные концепции, связанные с программированием.
>>891197
>Чем принципиально отличается понятие "визуальное программирование" от того что в годоте сейчас?
VisualScript и ему подобные языки - это императивные языки с визуальным интерфейсом. Они не нужны, потому что слишком избыточны. А вот сцены с нодами Godot - это декларативный язык программирования с визуальным интерфейсом. Ты можешь создавать сцены с помощью ручной записи декларативного кода в .tscn и .tres файлы через блокнот, но это нерационально, потому что визуальный интерфейс проще для понимания и делает всю сложную рутину вместо тебя, избавляя от ошибок вроде неправильно поставленных скобочек.
Если ты заранее создашь все необходимые ноды (напишешь скрипты с class_name), тогда многие игры можно будет создавать исключительно декларативно, размещая и комбинируя разные ноды и сцены, создавая для них ресурсы и настраивая параметры, аналогично тому, как ты можешь создать новую физическую симуляцию, используя только базовые ноды RigidBody и CollisionShape, не написав ни одной строки кода - если бы не было визуального редактора, тебе пришлось бы вручную описывать сцену текстовой записью (где была бы куча вызовов .new() и трансформаций объектов).
Разумеется, декларативные языки обычно имеют ограничения по сравнению с императивными (поэтому, например, нельзя написать большинство программ на одном только HTML), то есть они не полны по Тьюрингу. Но используя GDScript для создания кастомных нод - то есть расширения базового языка сцен, теоретически, можно создать систему, полную по Тьюрингу, которую можно будет использовать исключительно операциями с нодами через визуальный редактор.
Главная проблема здесь в производительности - Godot не рассчитан на слишком большое количество нод и операций над ними, в документации рекомендуют минимизировать количество нод и использовать низкоуровневые API вместо нод. Что-то оптимизируют в 4.x, нужно тестировать.
На пикриле ответ поисковика на базе ИИ. До чего дошёл прогресс!
В процесс слишком часто. Каждые пять-десять-шестьдесят секунд не вариант?
У меня было 3 секунды и модер не пропустил на яндексе, типа он обновил и у него сбросились 3 секунды прогресса.
>Можно ли пихать функцию сохранения в _process?
Очевидно, что нет, потому что тогда 60+ раз в секунду будет происходить обращение к функциям ОС для записи на диск, что в принципе медленно и глючно даже с SSD, не говоря уж о медленном чипе памяти на мобилках. Кроме того, ты впустую расходуешь ресурс накопителя пользователя, что особенно существенно на мобилках, где зачастую нет возможности балансировать износ ячеек, а ещё сохранение в твоей игре рискует испортиться 60+ раз в секунду, т.е. тебе каждый раз нужно создавать резервную копию и делать операции создания, удаления и переименования файлов. А если у пользователя дисплей выдаёт 120 кадров в секунду (такие бывают даже на мобилках) или он отключит у себя вертикальную синхронизацию, то твоя операция сохранения будет происходить ещё чаще.
Тут очевидна проблема XY:
https://ru.wikipedia.org/wiki/Проблема_XY_(Ошибка_молотка)
З А Ч Е М ты хочешь сохранять игру 60+ раз в секунду на мобильном устройстве? Так не делают даже ММО, которые, по идее, должны сохранять достижения игрока непрерывно - но на практике можно столкнуться с откатом данных на несколько минут назад из-за каких-то проблем.
Если ты хочешь побороть сейв-скаминг, во-первых, доступ к файлам приложения на мобилках и так сильно ограничен, а пользователь с рутом сможет легко обойти твою защиту. Во-вторых, это бессмысленно, потому что если у тебя, допустим, данные достижений передаются в интернет, кто-то обязательно изучит API сервера достижений и запишет себя с результатом 4294967296, ни разу не запуская игровой клиент.
В первую очередь заботься о том, чтобы было интересно играть (геймдизайн), во вторую - чтобы играть было приятно (не было тормозов и багов), а все эти хитрожопые костыли можешь выкинуть.
>модер не пропустил на яндексе
>у него сбросились 3 секунды прогресса
Напиши этому школотёнку с модеркой, что ты передумал публиковать свой шедевр в их гнилой помойке, ведь ты загрузил им все необходимые файлы, а они не смогли пропустить их через свою дырявую модерацию за 3 секунды. Там такой шлак публикуют, жуть...
Возможно, у тебя просто функция сохранения совсем не работает и ты неправильно понял ответ модератора.
Сохранять прогресс нужно не по таймеру, а по событиям. Каждый "прогрессирующий" объект в игре должен уметь испускать сигнал (порождать событие) при котором игра автосохраняется.
>Каждый "прогрессирующий" объект в игре должен уметь испускать сигнал (порождать событие) при котором игра автосохраняется.
Это работает только если таких событий мало, а все остальные события сохранять не нужно. Если событий для сохранения много каждую секунду, рациональнее сохранять по таймеру.
> Если событий для сохранения много каждую секунду
Ну тогда наслаждайся отказами.
Кто-нить итт вообще создал хоть что-то на голове готовое на продакшн?
Кто-то наверняка создавал, но нужно быть титаническим олдом типа гологеймса, чтобы осмелиться показать свой релиз двачерам.
Смотря какого уровня. Я делаю мобильные кликалки и зарабатываю ими себе на пивас. На днях, надеюсь, третью рожу.
@
ЗАХОТЕЛ СДЕЛАТЬ СВОЙ МАЙНКРАФТ
@
С ГОДОТОМ И ШЛЮХАМИ
>>891926
>прогрессирующий объект в игре
>>891942
>наслаждайся отказами
В майнкрафте будешь перезаписывать весь чанк на диске после каждого добавления/удаления блока?
Почему не брать ассеты бесплатные с итч.ио? Они же по открытой лицензии.
Музыку беру (я сам пробовал писать, но только две бшки выдавил и понял, что + музыка и я просто не потяну всё это по времени). Остальное там не получится взять из-за того как графически выглядит игра (задники и ростовые спрайты персонажей). Заказать кому-то тоже не вариант, так-как я нищий бомж. Да и не хочу деньги тратить на то, что 90% не окупится. Плюс художник может помереть или ещё что и тогда вообще пиздец.
Ну а ты думал, почему всякие Тоади и Крисы Ханты десятилетия делают свои проекты?
> В майнкрафте будешь перезаписывать весь чанк на диске после каждого добавления/удаления блока?
Буду.
А что конкретно тебя смущает? Операции добавления блоков делает игрок ЗНАЧИТЕЛЬНО МЕДЛЕННЕЕ, чем компьютер обновляет экран.
Хорошо, я уточню ещё один момент, неочевидный, который вроде как не упоминался в этом дискассе (но мы его не раз обсуждали в прошлых тредах).
Сохранение состоит из двух частей:
1. Формирование массива данных для сохранения игры, производится в памяти, точнее в переменной. Множество автономных агентов сохранения отправляют свои данные в этот массив, через событийную (сигнальную) модель/парадигму, и это легко обрабатывается движком.
2. Запись актуального массива данных в сейв-файл на диске. Эта операция дорогостояща и выполняется по таймеру, раз в секунду, например. Менеджер сохранения должен уметь блокировать или приостанавливать запросы на добавление данных по п.1. во время записи файла.
> при том, что сами картинки получаются "ну такое себе". И это "ну такое себе" около 6 часов занимает. Как я должен и работать и игру делать одновременно?
Рисуй не просто "ну такое себе", рисуй примитивное говнище уровня детсадовских каракуль. И лабай на этом прототип. Потом если прототип окажется годный, привлечёшь спонсоров с баблом, на бабло наймёшь художника.
Снижай масштаб своих идей. Лучше сделать 3-4 законченных минималистичных игры, каждая из которых лучше предыдущей, чем 1 долгострой, на который никто не посмотрит.
Так вот в том-то и дело. Я знаю что разраб Stardew Valley, по моему, чисто сидел на шее у своей девушке и игру делал.
>>892026
Да я знаю, но. Во-первых с таким прототипом как я делаю инвесторов хуй будет. Да и потенциальная прибыль как бы такая какая планируется никого не заинтересует. Во-вторых да нужно было бы с каракуль начать, чтоб чисто код потрогать и геймплей обкатать, но я уже покодил менюшки, устал от кода чуть-чуть и мне захотелось на что-нибудь другое переключится. Переключился на рисование картинок. И вот если каракули буду рисовать, то удовольствия мало.
>>892034
Да я и так уже. Решил просто мини-игру пока сделать для игры, а там дальше посмотрим.
Я на прошлом проекте обосрался по полной с амбициями своими. Думал всякого сделаю, оказалось на всякое нужно миллион времени. В итоге случился лютый обосрамс. Но хоть опыт получил. Я же был совсем ещё нулёвый, а сейчас нулёвый +. Планирую разбить всю разработку на такие вот мини-игры и пилить потихоньку.
>крутой иммёрсив сим шутер от первого лица
Ясно... Нет, что ты в это понятие вкладываешь? Иммерсив - это, вроде, ААА-реализм про погружение на вагонетке в роль какого-нибудь бомжа, который что-то там делает по линейному сюжету с киношными катсценами, в мире очень избыточных статичных декораций...
А почему TrenchBroom? Не проще ли делать всю геометрию в Blender, а прототипирование уровней делать в Godot с помощью CSG нод?
>как сделать шоб камера крутилась
Есть разные способы, в зависимости от того, что тебе нужно получить в результате.
>не знаю как прыжок реализовать
Почти в каждом туториале по чарактер контроллеру прыжок подробно разбирается.
>Я очень хочу создать эту игру потому что её сюжет будет раскрывать тему которая коснулась лично меня и возможно даже очень многих двачеров.
Отец бросил мать и ушёл из семьи, а сына-сычина вырос девочкой внутри с характером избалованной принцессы? А в чём шутер? Стрелять спермой в потолок, лёжа на кровати и двачуя капчу?
>Если кого-то интересует подробнее - пишите в телеграм (я стесняюсь при всех на дваче писать а то вдруг засмеют за идею истории).
Это троллинг? Ты стесняешься анонимно рассказать историю игры, которую тебе рано или поздно придётся опубликовать на всеобщее обозрение, а палить свой сравнительно публичный аккаунт вот так вот сразу не стесняешься?
>лучше идут дела с С# в Юнити чем с ГДскриптом
GDScript удобнее, чем C# (и в Godot, и в Unity).
>дизайнеров интерфейса
Ты сначала игру сделай, дизайнер. Зачем тебе меню с настройками размера экрана (полнейший атавизм в современных играх, не считая труъ-пиксель-ретро дроча на Ъъъ-разрешение 320х240 в окошке), если у тебя игры даже в зачаточном состоянии нет? Да даже грубого прототипа основных механик нет. Алсо, модели с текстурами ты тоже раньше времени начал пилить, у тебя даже чарактер контроллера толком нет, а ты уже какие-то домики лепишь, зачем? В тренчбруме, лол, ты в кваку 20 лет карты пилил, прежде чем решил игру сделать? Не обижайся, все делают подобные организационные ошибки в самом начале, пытаясь делать декоративные детали раньше фундаментальных. Сделай сначала играбельный прототип на уровнях из CSGBox без текстур, только потом поговорим о том, какие модели тебе нужны.
>Операции добавления блоков делает игрок ЗНАЧИТЕЛЬНО МЕДЛЕННЕЕ, чем компьютер обновляет экран.
При чём тут экран? Игрок может спамить блоки со скоростью несколько блоков в секунду. А динамит уничтожает сразу десятки блоков. Даже если ты сделаешь всего одно сохранение на взрыв одного динамита, игрок просто наспавнит сотни блоков динамита и взорвёт только один, а остальные будут взрываться с интервалом в доли секунды. Ещё есть поршни, которые меняют блоки в чанках, и способны давать нагрузку больше динамита. Рельсы можно переключать, дверьми хлопать и т.д., всё это можно назвать "прогрессом" и всё это может происходить много раз в секунду.
Майнкрафт просто помечает изменённый чанк, а сохраняет весь мир позже, когда наступит время. Да, ты можешь потерять 5 минут игры, если у тебя вырубился электричество или крашнется ОС или сама игра, но зато шанс получить испорченный чанк или весь сейв в несколько раз меньше, а игра не делает лишних обращений к ОС и диску.
>Формирование массива данных для сохранения игры, производится в памяти
Массив данных в готовом для записи на диск формате, я так понимаю? Тогда это дорогостоящая операция, потому что хранение на диске отличается от формата, с которым игра работает в памяти.
Скажем, в том же Майнкрафте может быть трёхмерный массив чисел. Но на диск может записываться не весь этот массив, а сжатая его версия. Просто потому что нерационально хранить тысячи нулей, идущих подряд, это быстро раздувает сейв мира на гигабайты.
>Запись актуального массива данных в сейв-файл на диске. Эта операция дорогостояща и выполняется по таймеру, раз в секунду
Лол, сам понимаешь, что операция дорогостоящая, но предлагаешь теребить диск каждую секунду?
Даже SSD диски спотыкаются и тормозят, если у тебя огромный поток коротких файлов. Они быстры только если у тебя файл весом сотни МБ. В современных SSD запись вообще очень медленная, они быстро пишут только в специальный кэш.
Допустим, на HDD твоё избыточное созранение слабо влияет, но SSD и flash-память мобильных устройств это будет избыточно изнашивать. Особенно флеш-память, у неё нет выравнивания износа.
Ну и т.к. мы говорим про мобильные игры, я уверен, что лишние операции с диском излишне нагружают процессор, повышая температуру и ускоряя разряд аккумулятора. Слишком большая цена для игрока ради 1-5 минут геймплея в какой-то гиперказуалке.
>Как же много времени уходит на геймдев. Если ты соло разработчик, то натурально приходится ебашить практически всё свободное время и при этом один хрен ДОЛГА.
Жалуешься на время - значит, геймдев - не твоё.
Сравни с игрой в игры. Одни люди жалуются на гринд в какой-нибудь игре, другие молча заносят тысячи долларов, чтобы избежать этого гринда. А третьи просто тысячи часов гриндят и получают удовольствие. Если тебе не нравится делать игру, зачем себя заставлять? Это ведь не твоя работа, как я понял, а хобби.
>нужно ассетов нарисовать
>чисто до прототипа дотянуть
Тебе уже сказали, но ты всё неправильно делаешь. Сначала сделай прототип на цветных квадратах, а потом уже, когда отточишь этот прототип и признаешь его годным, можешь рисовать графику.
Дело тут не только в том, что неудачная задумка может поставить крест на десятках и сотнях часов рисования графики. Дело ещё в том, что интересная графика может скрывать под собой скучный геймплей. Ты легко можешь спутать интересную графику с интересным геймплеем. Чтобы избежать этого заблуждения, нужно сделать игру интересной даже с цветными квадратиками вместо полноценных спрайтов (или цветными кубами вместо сложных 3D моделей), а только потом уже заниматься раскрашиванием игры. Скучные провальные игры с качественной графикой так и рождаются - художник сразу сел и нарисовал кучу спрайтов, а игру так и не сделал. В то же время есть очень увлекательные игры на ASCII "графике", то есть без иллюстраций совсем, только с очень простыми символьными обозначениями для того, чтобы отличить один объект от другого.
Кстати, беда ассетфлипов отсюда же: ассетфлипер берёт готовые красивые ассеты и пытается вылепить из них игру, но вместо интересной игры у него получается только скучная сборка интересных ассетов. Сами по себе ассеты могут быть хороши, но они мешают разработчику создать интересную игру, обманывая его восприятие. Скажем, если тебе нравятся аниме-тян, ты можешь скачать готовую модельку аниме-тян и закинуть в движок, и тебе это понравится, но это не игра и для игрока ценность твоей работы равна нулю. Аналогично будет, если ты сам своими руками сделаешь эту аниме-тян и закинешь в движок, потому что для игрока нет разницы, что ты сделал сам, а что ты скачал; важно только, что игры у тебя нет, есть только интересная моделька, с которой нечего делать.
Даже ААА проекты начинаются с блокинга уровней и прототипов без финальной графики. А инди тем более важно начинать с прототипа без графики, потому что он не может позволить себе скучный симулятор ходьбы с очень дорогой графикой.
>картинки получаются "ну такое себе". И это "ну такое себе" около 6 часов занимает.
Можешь показать пример того, что выходит? Хотя бы рандомную картинку из интернета, похожую на то, что ты сам делаешь. Если тебе навыков не хватает, то с улучшением навыков ты будешь быстрее делать картинки лучшего качества. Также можно оптимизировать процесс работы и заменить инструменты. Для сравнения, проще накидать в 3D сцену из кубов и потом "обмазать" её, чем рисовать полностью с нуля, вымучивая образы из своего воображения. Так многие "крутаны" делают в контексте иллюстраций, а к играм это тем более применимо т.к. от игр не ожидают особой художественной ценности.
>>892036
>с таким прототипом как я делаю инвесторов
Можно попробовать краудсорсинг, если сможешь привлечь целевую аудиторию. Хотя краудсорсинг эффективнее с готовой графикой без прототипа...
>Да и потенциальная прибыль как бы такая какая планируется никого не заинтересует.
Если заранее знаешь, что проект провальный, зачем тогда его вообще начинать? Зачем вкладывать по 6 часов в каждую картинку, если в это потом никто играть не будет? Ради опыта прототип без графики ценнее кучки ассетов.
>я уже покодил менюшки, устал от кода чуть-чуть и мне захотелось на что-нибудь другое переключится.
Лол, у тебя там какие-то монструозные менюшки с десятком уровней вложенности и сотнями кнопок? Большинство игровых механик можно совсем без менюшек прототипировать, зачем тебе менюшки? Допустим, инвентарь сложно сделать, но это лишь небольшая механика от всей игры в целом.
Кроме того, в Godot менюшки - самое лёгкое.
>Переключился на рисование картинок. И вот если каракули буду рисовать, то удовольствия мало.
А мог бы сделать прототип и получать удовольствие от игры в прототип, мотивируя себя постепенно рисовать нормальную графику для него.
Конечно, если у тебя не симулятор ходьбы, в котором всё удовольствие от рассматривания картинок...
> При чём тут экран?
Потому что главный цикл игрового приложения, это цикл обновления экрана. Дальнейшее не читал, уж извини. Иди учи матчасть. Майнкрафтер. блять.
Ну это чушь. Либо пишешь ему аппеляцию что сейвы опциональны по их же правилам. Либо у тебя непонятно работает сейв и это действительно откат, тогда делай как все современные - чекпоинты или главы, миссии. Чтобы было ЯВНО видно игроку и модеру, что вот в этой точке был сейв.
>Жалуешься на время - значит, геймдев - не твоё.
>Если тебе не нравится делать игру, зачем себя заставлять?
Мне нравится делать игру. Я так просто поныть решил. У меня стаж геймдева 2 года. Если бы мне нравилось я бы уже бросил давно. Я же не дурак тратить столько времени на то, что мне не нравится.
>тебе уже сказали, но ты всё неправильно делаешь.
Я понимаю. Но концепт есть твёрдый. Спизженый, обкатаный и проверенный. С меня только видоизменение под свои нужды и доведение до ума. И опять таки я упомянал свою мега код сессию знакомства с годотом, когда я менюшки кодил. Я хочу переключится на другой вид деятельности. Мне кстати очень нравится этим геймдев, что если заебался что-то делать, то есть возможность переключится и при этом всё равно продуктивно время потратить. Так-то я понимаю риск, но готов на него если получаю удовольствие от процесса. А я получаю и именно по этому мега рискую и мне пох.
И я прям понимаю твою мысль. Рили очень легко проебаться на графике и оставить игру без, собственно, игры. Тысячи примеров имена который хуй теперь вспомнишь. Риск большой, но у меня есть некоторая уверенность в концепте, что позволяет мне рискнуть.
>Можешь показать пример того, что выходит?
Пик. Это я рисовал для себя. Что сейчас рисую скидывать не буду, я стесняюсь. Для игры чуть хуже выглядит, так-как там не иллюстрация всё таки, а чуть другое.
>Для сравнения, проще накидать в 3D сцену из кубов и потом "обмазать" её, чем рисовать полностью с нуля, вымучивая образы из своего воображения. Так многие "крутаны" делают в контексте иллюстраций, а к играм это тем более применимо т.к. от игр не ожидают особой художественной ценности.
Да. Я знаю про такие методы. Илюшке кувшину привет. Если к такому не прибегать, попа может лопнуть от напряга высерать каждый раз что-то оригинальное из головы.
>Можно попробовать краудсорсинг, если сможешь привлечь целевую аудиторию. Хотя краудсорсинг эффективнее с готовой графикой без прототипа...
Да там совсем порно. Тут как бы да. Плюс игра не большая, а то, над чем сейчас работаю и вовсе маленькое.
>Если заранее знаешь, что проект провальный, зачем тогда его вообще начинать?
Ну я не знаю наверняка. В голове звучит не плохо. Я просто пессимист и нытик. А ещё есть опыт обосрамса.
>Лол, у тебя там какие-то монструозные менюшки с десятком уровней вложенности и сотнями кнопок?
>Допустим, инвентарь сложно сделать, но это лишь небольшая механика от всей игры в целом.
Так вот я и работал над инвентарём. Причем я даже делал его не через сетку (где там тащишь и всё такое), а через обычный список. Но там очень много просто. Оружие, броня, потребляемое. Каждое со своими характеристиками. Эти характеристики должны выводится в инвентаре и в магазе. Возможность открыть инвентарь, возможность пойти в магаз. Экипировка всего эквипа. Вот над этим работал. Плюс я тупил много, так-как с годотом не работал никогда. Тем не менее было очень весело. Это потраченное время было весёлым, что уже хорошо.
>Кроме того, в Godot менюшки - самое лёгкое.
Ну с моего опыта сложно сказать, но так-то да. Я бы не сказал что было прям сложно. Я просто тупил.
>А мог бы сделать прототип и получать удовольствие от игры в прототип, мотивируя себя постепенно рисовать нормальную графику для него.
Бля. Кто-то делает игры чтобы в них потом играть? Я просто когда прошлую делал до того её затёр, что там пиздец. >Конечно, если у тебя не симулятор ходьбы, в котором всё удовольствие от рассматривания картинок...
Так вот в том-то и дело. Картинки важны очень в моей идее. И особенно в первом этапе этой идеи. Вот когда/если дойду до второго этапа, то там уже буду именно на кубах геймплей тестить.
>Пик. Это я рисовал для себя.
Красиво. Если тратишь много времени на одну линию из-за неточности (часто нажимаешь ctrl+z), попробуй векторный редактор (Inkscape норм) - там любую линию легко поправить и легко добиться чёткого, гладкого лайн-арта. В растровых редакторах векторные слои часто очень ограниченные и не раскрывают весь потенциал векторной графики.
Я сам имею опыт в растре, векторе, пикселях и 3D. Пиксель-арт мне не нравится, в 3D слишком много возиться для нормальной картинки, в растре нужно чтобы рука не дрожала на планшете, а вот вектор самый сбалансированный: можно рисовать любым устройством ввода, нет требований к точности, не слишком много технических нюансов, визуально базовый стиль приятен и популярен.
>Я просто пессимист и нытик. А ещё есть опыт обосрамса.
Но ты не сдался и продолжаешь работать, молодец. Меня завышенные и неоправданные ожидания совсем в депрессию скатили, сил ни на что нет.
>Оружие, броня, потребляемое. Каждое со своими характеристиками. Эти характеристики должны выводится в инвентаре и в магазе.
Делается универсальная система, а дальше просто описываешь предметы через tres ресурсы Godot. Главное придумать достаточно универсальную систему, чтобы потом костыли не пришлось делать.
Для примера: предмет несёт Dictionary со всеми характеристиками, для отображения достаточно универсальной нодой - она выводит значения всех ключей независимо от типа предмета и своего положения в дереве сцены. А магазину не нужен тип предмета - его волнует только стоимость и проведение транзакции с игроком. Тип предмета влияет только на слот на теле персонажа и способ использования.
Потом просто в редакторе выбираешь "создать новый ресурс - item.gd" и в полях инспектора вводишь путь к иконке, параметры и т.д. Особенно круто будет если предметы процедурно генерируются, тут без универсальной системы не обойтись, она должна всё подряд принимать.
>Кто-то делает игры чтобы в них потом играть?
Если игра сильно полагается на процедурную генерацию и эмерджентные механики, то почему бы и нет? Вполне возможно сделать игру, которая будет удивлять её разработчика. Тем более тебе всё равно в неё играть, если не хочешь, чтобы игроки жаловались на банальнейшие баги.
>Картинки важны очень в моей идее.
У тебя там, случайно, не симулятор свиданий?
Удачи в разработке. Главное - не выгореть.
>Красиво.
Спасибо.
>попробуй векторный редактор (Inkscape норм)
Спасибо за наводку. Я когда только начинал рисовал линии в растре и это просто жопа. Потом додумался векторный слой подключать. Стало в разы легче и быстрее и приятнее, но когда пытаюсь линию поправить у меня компьютер нах умирает от того сколько там точек в линии, а потому как бы вот. Попробую Inkscape, надеюсь там лучше, хотя мне кажется, что это просто у меня такой скилл низкий.
>Но ты не сдался и продолжаешь работать, молодец.
Ну как бы да. А что ещё остаётся? Я не могу просто сидеть на жопе и ничего не делать. По этому продолжаю работать, а это ещё и довольно интересно так что мне легче. Плюс у меня есть опыт не хороший. Один раз не по своей хотелке пришлось сдаться и пересмотреть планы на жизнь. Я от шока чуть не помер. Если ещё раз такое повторится я головой ебанусь, так что тут как бы только вперёд. Пусть там могут поджидать каловые массы, но даже если так, мне хоть будет чем себя утешить себя и пережить это всё зная что я старался.
Соболезную твоей ситуации, но даже совета дать не могу. Тут натурально бой с тенью.
>Делается универсальная система, а дальше просто описываешь предметы через tres ресурсы Godot.
Я так и сделал, но проебался чутка. Инвентарь игрока ресурс, а инвентарь магазина - нет. Плюс если переделать как нужно, там придётся похоже с инстансами разбираться (так как без них один хрен будет тоже самое что и сейчас, то есть просто готовые ноды кнопки каждая со своим кодом), а мне пока не хочется, так что пох, в другой раз. Благо предметы все прописаны мной и не генерируются. Но ресурсы это топ конечно. Я когда с ними стал разбираться мне очень понравилось как всё удобно и на сколько они облегчают работу.
>Тем более тебе всё равно в неё играть, если не хочешь, чтобы игроки жаловались на банальнейшие баги.
Да у меня там без генераций всяких. А играть да, я про это и говорю. Там в тестах так игру вдоль и поперёк пройдёшь, что тут уже как бы наигрался.
>У тебя там, случайно, не симулятор свиданий?
Не. Но близко. Я школьником был, прочитал Цукихиме и такой: "нихуя себе". Потом прочитал фейт и такой: "НИХУЯ СЕБЕ А ТАК МОЖНО БЫЛО!?". У меня была идея ещё тогда что-то подобное сделать, но даже мой куцый умишко школяра понимал, что писать по сюжету я не вывезу. Так что спустя около 7 лет решил всё таки что-то сделать, но с гейплеем, чтоб не так на нарратив полагаться. В итоге первая попытка оказалась не очень, но у меня теперь опыт есть.
>Удачи в разработке. Главное - не выгореть.
Спасибо. Удачи и тебе. Выгорания пиздец это. Лютая вещь.
>выгораю уже после того, как мне надо сделать хотя бы одну реальную задачу.
Вероятно, ты берёшь на себя слишком комплексную задачу, пытаясь решить её в один присест. Разбивай её на части, и решай эти части как индивидуальные задачи. Составляй план и отмечай выполненное.
https://ru.wikipedia.org/wiki/Декомпозиция
https://ru.wikipedia.org/wiki/Диаграмма_связей
Скажем, вместо
>сделать инвентарь какой-то простой
Ставь себе задачи сделать:
- кнопку с иконкой предмета;
- контейнер с параметрами предмета;
- всплывающую подсказку с параметрами;
- окно с произвольным числом кнопок по сетке;
- механику драг-н-дроп для отдельных кнопок;
и т.д.
Тогда ты не будешь путаться в том, что именно тебе необходимо сделать, и будешь чувствовать больше удовлетворения от того, что сделал больше задач.
>нужен хотя бы день чтобы отойти
Тебе везёт. Я после нескольких недель ежедневной работы над какой-нибудь фичей выгорал, полностью бросал свой проект и геймдев в целом на несколько месяцев. Типа, убил столько времени на совершенно не впечатляющий результат или вовсе пришлось выкинуть всю проделанную работу, и т.д.
>Годы депрессии уничтожили нервную систему
С этим к врачам обращайся.
>линии в растре и это просто жопа
>это просто у меня такой скилл низкий
Тут несколько причин. Да, конечно, чем больше ты тренируешься рисовать линии, тем лучше они будут, художники рекомендуют делать упражнения по рисованию одних только линий каждый день. Ещё влияет то, как именно ты рисуешь: вращая в большей степени запястным, локтевым или плечевым суставом; запястье не может провести длинные ровные линии, а с помощью локтя и плеча сложно делать короткие и точные отрезки. Размер графического планшета сильно влияет, так, на планшете с рабочей зоной размером А5 особо не развернёшься. Старые и дешёвые планшеты вносят кучу дополнительных ошибок из-за менее чувствительного сенсора. Так что даже если удаётся нарисовать ровную линию карандашом на бумаге, на компьютере это сделать сложнее. Крутаны покупают большие мониторы с пером вместо "слепой" доски для более точного контроля и зачастую делают наброски на бумаге, а на компе только обводят и раскрашивают. Ещё есть куча способов сделать линии лучше, от сглаживания в настройках программы до рисования на огромном холсте толстой кистью для последующего сжатия холста.
Короче, ты не одинок в этих проблемах, и дело далеко не только в абстрактном навыке.
>векторный слой
>пытаюсь линию поправить у меня компьютер нах умирает от того сколько там точек в линии
Krita? Там почему-то очень много точек создаётся.
>Попробую Inkscape, надеюсь там лучше
Да, с векторными линиями там однозначно лучше. Плюс куча удобных инструментов, которые я не встречал в растровых редакторах.
Знаю три основных техники рисования в векторе:
1. Инструмент "карандаш", аналог того векторного слоя в Krita: создаёт много точек, пока ты ведёшь перо. Чем быстрее ведёшь, тем меньше точек. Но в Inkscape есть очень удобный хоткей ctrl+L, позволяющий быстро сократить лишние точки в линии. Этим способом можно делать наброски от руки прямо в векторе.
2. Инструмент "ручка", имеет два режима работы: простые клики создают ломанную линию (острые углы), а если зажать и вести в сторону, можно делать кривые Безье. Любую точку в любой линии можно конвертировать в острую или гладкую, так что иногда я делаю ломанную и потом вручную сглаживаю её. Тут уже не обязательно работать пером, мышкой даже удобнее.
3. Инструменты "прямоугольник" и "овал", с помощью которых можно накидать силуэт или какую-то деталь, а потом использовать хоткеи для булевых операций над фигурами или сразу конвертировать в линии. Потом переходишь в режим редактирования (F2) и подгоняешь линии под желаемый результат. Мне лично такой метод нравится больше всего, он даёт возможность быстро визуализировать грубые формы и потом детализировать по необходимости. Чем-то напоминает рисование пятнами в растре, когда из бесформенных пятен постепенно формируются детали. Всё равно многие сложные объекты состоят из множества базовых форм, достаточно эти базовые формы немного деформировать. Особенно полезно при рисовании рукотворных предметов - там чаще всего встречаются прямые линии и овалы.
>А что ещё остаётся? Я не могу просто сидеть на жопе и ничего не делать.
Из твоих слов я сделал вывод, что у тебя есть основная работа. Не тяжело работать над игрой по 6 часов после рабочего дня?
>Но ресурсы это топ конечно. Я когда с ними стал разбираться мне очень понравилось как всё удобно и на сколько они облегчают работу.
Ага. В движке есть JSON и я постоянно порываюсь записывать данные в JSON, но, если подумать, ресурсы в Godot как раз выполняют всю ту работу, ради которой в других движках валяются длинные файлы конфигураций в JSON, XML или в своём формате, плюс встроенные функции инспектора.
>писать по сюжету я не вывезу. Так что спустя около 7 лет решил всё таки что-то сделать, но с гейплеем, чтоб не так на нарратив полагаться.
Мне кажется, визуальную новеллу всё же куда проще сделать нормально. Для визуальной новеллы достаточно быть писателем и художником, а для игры с геймплеем и сюжетом нужно быть писателем, художником, геймдизайнером, левелдизайнером, саунддизайнером, программистом и тестировщиком. Забить на сценарий можно только если у тебя его совсем нет, как в какой-нибудь песочнице без сюжета. Кроме того, как я понимаю, сценарий новеллы можно сравнительно легко переписать в определённых пределах без изменений в графике, а вот игру так радикально править - тяжело.
Потом, кто твоя целевая аудитория? Нужно заранее представлять, кто будет играть в твою игру, если ты не сам для себя игру делаешь. Смотреть на похожие игры и читать отзывы к ним - что игрокам нравится, что не нравится, чего бы они хотели. Не все хотелки адекватны, но в целом можно понять, почему тот или иной проект успешен или провалился. Отчасти поэтому мы редко видим уникальные игры, ведь их куда сложнее спроектировать как продукт для определённой аудитории, а многие уникальные так и остаются никому не известными...
>первая попытка оказалась не очень
На каком-то другом движке делал? RenPy?
Это не совсем то, я хочу чтобы если кнопка была зажата, то ивенты всё равно поступали, но медленно, как в _input
> медленно, как в _input
Но там не медленно. Там событийно. Событийно не значит медленно. С чего ты взял, что где-то что-то медленно? Если тебе нужны задержки, юзай таймер.
Ты что то странное себе напредставлял. Нажатие в _input прилетает ОДИН раз на каждое событие, а не с какой то медленной периодичностью. (Может быть, тебя вводит в заблуждение, что операционная система посылает нажатия кнопок при зажатой клавише, но это вообще то настраивается/отключается в системе)
>>892446
Сравнительно медленно с _process. Таймер звучит не очень, но
>>892449
Да, это я как-то не учёл. Надо подумать тогда как лучше.
С таймерами все ок. Тебе надо ловить два события, нажатие кнопки и отпускание кнопки. На нажатии кнопки, ты посылаешь в игру команду с этой кнопкой и запускаешь "длинный" таймер. Когда он срабатывает, проверяешь, нажата ли кнопка, посылаешь в игру команду, и запускаешь "короткий" таймер. Короткий таймер делает то же самое.
Отпускание кнопки принудительно останавливает оба таймера.
Алсо, в классических рогаликах для такой ходьбы есть специальная кнопка, может быть Shift+стрелки или G, стрелки - до ближайшего "объекта интереса" или стенки.
> Таймер звучит не очень
Кстати, это можно тоже через отдельную стейтмашину реализовать. Например, задаём такие стейты:
enum KeyStates { Released, Pressed, Holded}
И задаём два кастомных сигнала
signal PressedOnce
signal PressedAndHold
Затем реализуем следующий алгоритм.
1. По умолчанию стейт Released.
2. Если кнопка нажата, стейт выставляется в Pressed, испускается кастомный PressedOnce сигнал и запускается таймер.
3. Если кнопка отжата, возвращаемся в Released и сбрасываем таймер, если он сам не остановился (таймер одноразовый).
4. Когда таймер выстрелил, переводим стейт в Holded и в _process либо обрабатываем удерживание клавиши, либо испускаем PressedAndHold если Holded
>>892460
Спасибо, буду думать, но наверно пока что оставлю говяно на _input. А то если буду слишком долго возиться слишком долго с такой относительно минорной деталью до выпуска хоть какого-то базового прототипа, когда толком ничего нет, то могу потерять мотивацию и забить вообще на проект.
Верное решение. Не проеби мотивацию. Как я когда-то. Сижу теперь как сыч, без игор.
Очень сильно демотивирует что-то делать...
>>892449
>Может быть, тебя вводит в заблуждение, что операционная система посылает нажатия кнопок при зажатой клавише, но это вообще то настраивается/отключается в системе
Повторное нажатие может посылать клавиатура.
>>892452
>мне хочется чтобы функция обработки ввода возвращала значение с состоянием игры (можно обрабатывать противников/ожидание ввода/открыть инвентарь/другое).
Что? Зачем? Почему? Не пойму. ИМХО, ты что-то неправильно понимаешь в работе Godot.
_physics_process работает с установленной в настройках частотой, по умолчанию 60 Гц.
_process зависит от вертикальной синхронизации и максимальной частоты монитора, поэтому может колебаться от 60 Гц до 2000 и более Гц, но чаще всего встречаются частоты: 60/75/120/144/240 Гц.
_input и ему подобные срабатывают только когда генерируется событие ввода, а эти события могут генерироваться с частотой от 125 Гц для самого слабого офисного оборудования, от 500 Гц для игрового варианта и тысячи Гц для топового.
Т.е. в большинстве случаев _input срабатывает на порядки чаще _process, особенно для мыши.
Одна важная разница: в _input код выполняется не обязательно 125-500 раз в секунду, а только когда ОС генерирует событие. В _process же ты 60+ раз в секунду дёргаешь Godot API с вопросом:
>а сейчас есть ввод? а сейчас? ну а сейчас-то есть? что, и сейчас нет? ну сейчас-то точно есть ввод? а сейчас? что, серьёзно ничего? ну а сейчас?
А в _input тебе может прилететь 500 сообщений:
>ВНИМАНИЕ! МЫШ КРОДЁТСЯ НА 0.01 ПИКСЕЛЯ!
За одну секунду. И это даже не предел...
Рекомендую для игрового персонажа использовать _unhandled_input, этот обработчик вызывается только если событие не обработано GUI.
>Как перестать думать о том, что игра Ерохина похожа на мою
Перестать об этом думать. И думать о том, как сделать, чтобы твоя была лучше ерохи.
>Что? Зачем? Почему?
Потому что я делают рогалик с ецс, и я не хочу чтобы системы гонялись впустую пока игрок думает над нажатием кнопки
> _unhandled_input
Да, я его и использую, я обозвал его _input из-за схожего принципа работы: только когда срабатывает событие, а не несколько десятков раз в секунду
> схожего принципа работы
В начале кадра весь инпут помечен как анхандлед. Если происходит событие инпута, сначала вызывается коллбэк _анхандлед_инпут и если инпут остался с флагом анехандлед, тогда вызывается коллбэк _инпут.
Ты что-то путаешь. Не путай ньюфагов.
>Nodes can also process input events. When present, the _input function will be called for each input that the program receives. In many cases, this can be overkill (unless used for simple projects), and the _unhandled_input function might be preferred; it is called when the input event was not handled by anyone else (typically, GUI Control nodes), ensuring that the node only receives the events that were meant for it.
>>892523
>я не хочу чтобы системы гонялись впустую пока игрок думает над нажатием кнопки
Тогда ты можешь воспользоваться встроенной системой паузы, она очень гибкая:
https://docs.godotengine.org/en/stable/tutorials/scripting/pausing_games.html
>рогалик с ецс
Как оно устроено? Дерево сцены юзабельно?
Да, про упражнения я знаю. Они действительно помогаю, но я уже решил теперь чисто через практику, так веселее. Планшет у меня норм. Маленький наверное, но я точно не знаю. Брал за 3,5 рубля в 18 или 19 году. Пока что он на все 100% отрабатывает. Я бы с экраном купил, но это уже с первый денег.
>Krita? Там почему-то очень много точек создаётся.
Не. Я в CSP работаю. Он так-то очень даже не плохой, но в векторе точек много, машина не выдерживает.
>Чем быстрее ведёшь, тем меньше точек.
Вот это звучит очень полезно. Да как и остальное в общем-то.
>Из твоих слов я сделал вывод, что у тебя есть основная работа. Не тяжело работать над игрой по 6 часов после рабочего дня?
Есть. Но я не каждый же день по 6 часов над игрой сижу. Я бы уже дуба дал если бы так делал. На выходных в основном. Опять же бывают очень продуктивные например полтора месяца, когда я могу нон-стоп работать над игрой. Что-то около 70% процентов свободного времени. А бывают месяца, когда прям не идёт. Выгорание начинается, тогда мож 30% максимум по мелочам, но даже не смотря на такое, открываю рисовальню или код и работаю хотя бы чуть-чуть. Какие-нибудь мелкие задачи.
>В движке есть JSON
Я видел пару гайдов на ютубе, но не смотрел их, а потом как раз гайд на ресурсы попался и собственно с JSON так и не познакомился.
>Для визуальной новеллы достаточно быть писателем и художником
Ты ещё про музыку забыл. Она как бы тоже решает. Ну это если серьёзно подходить к делу. Я просто помню осты из фейта и принцессы, да даже в лете осты не плохие. Не знаю я. В внке у нас три компонента. Текст, графоуни и звук. Одно не очень и пизда практически всему проекту.
>а для игры с геймплеем и сюжетом нужно быть писателем, художником, геймдизайнером, левелдизайнером, саунддизайнером, программистом и тестировщиком.
Ну как бы да, но как бы нет. То есть в игре с геймплеем от тебя врядли будут ожидать историю "до слёз" или мега инструментальный саундтрек опять же "до слёз". Геймплейный луп заебатый? Ну вот и отлично, остальное, не хотелось бы говорить, что вторично, но есть пространство для манёвра. А вот в внке тут пиздец. Ну ладно, там ещё графен и музыка, хотя графен нужен. Но вот если история туфта, то это всё. А так-как я знаю, что я творческий импотент, то я в жизнь не рискну внку делать. Да, внка легче, но только если ты "талант" или что-то в этом роде. Взглянуть хотя бы на рувно. Там после лета его тысячи родилось и померло, и ничего так и не высрали.
>Потом, кто твоя целевая аудитория?
Порнушечники. Я люблю всякие игры с ф95 и это практически единственное, что меня вообще веселит из игр. Так что вопрос даже не стоял в каком жанре делать.
Пусть я и сам порнушечник, но игру с одной лишь только порнухой делать мне скучно. Я так не смогу. За прошлый проект я понял, что сама половая тема довльно скучная. Из разряда очень скучная. А потому попробую что-то придумать в геймплейном плане. Тут и вступает годот.
>На каком-то другом движке делал? RenPy?
Не. На рпгме. Но там постоянная фрустрация была от того, что я вообще с движком никак работать не мог. Там же js. Если что-то нужно изменить иди меняй в родном коде написанном японцем. Там жопа была. Плюс я себе целей поставил много, я же только начинал и не знал что сколько может по времени занять. Провалил в итоге 90% из них. Лол. Да. Ну ничего. Опыт хотя бы получил. В годоте работать веселее.
> Ты что-то путаешь.
Нет, я в точности сказал то, что написано там. Просто некоторые вещи подразумеваются, как само сабой разумеющееся и не проговаривается вслух. Я проговорил.
> When present, _input function will be called for each input that the program receives. In many cases, this can be overkill
"Каждая нода вызывает коллбэк _инпут, если он написан в скрипте. И это оверкилл." Но они не указывают явно, что это происходит на ВТОРОМ шаге. Они пишут:
> and the _unhandled_input function might be preferred; it is called when the input event was not handled by anyone else
"и коллбэк _анхандлед_инпут может быть предпочтительнее; он вызывается, когда событие инпута не обработано нигде ещё". Под этим подразумевается именно то, что я написал:
1. Обработанность инпута - это системный флаг.
2. В начале каждого фрейма этот флаг пуст.
3. Вызов mark_input_as_handled() заполняет флаг.
4. При заполненном флаге коллбэки _input не вызываются.
>Как оно устроено?
В качестве ецс Arch https://github.com/genaray/Arch. Решил раз либа на С#, то и всё надо на нём писать. Дерево сцены только для гуя и графических объектов. Игрок, неписи, в будущем объекты и вообще всё - энтити. Вообще, я пока следую туториалу для рогалика на расте (https://bfnightly.bracketproductions.com/rustbook/), потому что там как раз про эцс и структурированный план того что нужно делать.
Я не понимаю.
Есть ноды: A, B, C и D.
У каждой ноды есть оба рассматриваемых метода.
Есть событие клавиатуры "нажата W".
unhandled input:
A принимает, но игнорирует.
B принимает и вводит W в своё поле.
До C и D сообщение не доходит.
input:
A, B, C и D вынуждены принять и игнорировать.
Что здесь не так?
> То есть в игре с геймплеем от тебя врядли будут ожидать историю "до слёз" или мега инструментальный саундтрек опять же "до слёз".
Метал Гиар
А, стоп, возможно, это я что-то путаю. Я раньше столкнулся с проблемой, когда у меня чарактер контроллер принимает ввод с клавиатуры даже если открыт чат и ввод клавиатуры предназначен только для чата. Но, возможно, это было только из-за того, что я делал Input.get_axis(), а не из-за обработчика _input? Я не помню уже. Сильно с этим помучился, но не помню, что в итоге решил сделать.
3д билды на годоте тормозят, fps проседает ниже 30.
Короче, анон, я щас провёл тесты в движке и по тому что я увидел, выходит, что при маркировке хандледом перестают обрабатываться другие анхандледы. Хандледы же обрабатываются все равно. В общем я выше писал неверно.
Вот код и результаты теста на скринах. Выводятся только три принта. Четвёртый, из ноды А анхандлед - не выводится, потому что в ноде Б выставлен флаг и дальнейший коллбэк игнорирован.
>собственно с JSON так и не познакомился.
Там всё очень просто, достаточно документации:
https://docs.godotengine.org/en/stable/classes/class_json.html
Если захочешь писать какие-то данные вручную для загрузки через JSON, рекомендую взять вот это: https://hjson.github.io/ - там формат попроще для записи вручную и даже комментарии писать можно. Потом любым способом запускаешь их конвертер Hjson -> JSON и получившийся в результате файл загружаешь в Godot как JSON.
>Ты ещё про музыку забыл.
>Текст, графоуни и звук. Одно не очень и пизда практически всему проекту.
Лично меня музыка в играх особо не волнует. Да, если есть приятная музыка в тему - хорошо, но если музыки совсем нет - тоже хорошо. Чаще всего музыка не нравится, отвлекает, раздражает или просто бесполезна. Тем более в визуальных новеллах, которые суть короткие книги с простыми иллюстрациями а-ля диафильмы или слайд-шоу. Как часто ты встречаешь книгу с саундтреком, который обязательно нужно слушать во время чтения? Ладно ещё аудиокнига... А вот в играх с активным геймплеем звуки очень полезны, т.к. они влияют на погружение и могут использоваться для передачи полезной информации: тип поверхности по звуку шагов, рычание монстра, звон колокольчиков вблизи квестового предмета и т.д.
>То есть в игре с геймплеем от тебя врядли будут ожидать историю "до слёз" или мега инструментальный саундтрек опять же "до слёз".
Судя по постам на дваче, отзывам в стиме и обзорам на ютубе, сюжет в играх людей всё-таки достаточно сильно интересует, и ради сюжета играют чаще, чем ради затягивающего геймплея. Поэтому ААА игры чаще всего линейное кинцо, а не песочницы.
На счёт саундтрека, если тебя волнует саундтрек в визуальной новелле, то и в любой видеоигре он тебя тоже будет волновать. Но к саундтреку в играх добавляются важные звуки, зависящие от окружения, действий игрока и мобов, геймплейных механик и т.д. Было даже какое-то исследование, в котором людям предлагали оценить качество графики - но одна группа играла без звука, другая с плохим звуком, и третья с качественным звуком - так вот, выявилась зависимость субъективной оценки графики от наличия и качества звука. Т.е. с качественным звуком и графика выглядит приятнее.
Конечно, это связано с эмоциями, эмоциональной оценкой - если настроение поднимается музыкой, то графика оценивается выше, если настроение музыкой ухудшается, то и на графику ругаются чаще. Но в конечном итоге нас волнует только то, как игрок оценит игру в общем и целом - поэтому все компоненты игры должны быть на высоком уровне. Вполне возможно, что с сюжетом ситуация аналогична, и плохой сюжет испортит впечатление об игре, даже если геймплей очень хороший и можно забить на сюжет. Ну а если какого-то одного компонента в игре вообще нет, то он не может дать бонус, но и навредить тоже не сможет - на этом выезжают, например, песочницы, да и те же новеллы стараются не отягощать игрока лишними мини-играми (чаще наоборот, в "мини-игру" вставляют бонусный сюжет в виде слайдов визуальной новеллы).
>если история туфта, то это всё
Писатели графоманят тонны второсортной писанины и кто-то это покупает и читает. Ты можешь не создать шедевр, но какая-то аудитория читателей и даже фанатов у тебя может сформироваться. Нужно просто быть как Дарья Донцова и выдавать народу новые книжки с картинками как напитки из торгового автомата. А вот если ты пять лет пилишь новеллу в надежде на широкое признание твоего Гения, тогда да, ты, скорее всего, сильно разочаруешься.
Собственно, на мой взгляд, сложность визуальных новелл в основном в графике. Можно написать тонны текста за считанные дни и даже найти подходящую по духу бесплатную музыку, но вот картинки сделать на приемлемом уровне сможет далеко не каждый. Для академического рисунка нужны годы ежедневного обучения, даже если метишь в флет-шейд вектор; готовые 3D модельки сродни ассетфлипу, а свои делать не особо проще рисования; нейросети не могут в стабильность и находятся в очень напряжённых отношениях с копирастами (всё равно что торренты - технология замечательная, но использование может быть незаконно); даже бегать с фотоаппаратом и искать актёров - бОльшая проблема, чем настрочить десятки тысяч букв диалогов.
>Пусть я и сам порнушечник, но игру с одной лишь только порнухой делать мне скучно. Я так не смогу. За прошлый проект я понял, что сама половая тема довльно скучная. Из разряда очень скучная. А потому попробую что-то придумать в геймплейном плане.
ИМХО, такие игры вообще сложно делать. Порнуха максимально сужает твою аудиторию, сокращает число площадок и видимость в интернете. Видя, что игра с порно, к ней предвзято относятся, если только это не какой-то всем известный проект. Если у тебя там сложный геймплей, часть дрочеров резко отваливается, если пришли тупо подрочить. А тех, кто мог бы получить удовольствие от геймплея, может отпугнуть элемент порно. Ещё и сама порнография очень субъективна - кому-то большие сиськи нужны, а кого-то от них тошнит - аудитория ещё больше сокращается, если у тебя не гарем на любой вкус со всеми формами, цветами, крыльями и рогами, но и гарем тоже резко обрубает аудиторию из-за хейтеров гаремников.
Короче, это как при любом смешивании двух разных жанров: ты ожидаешь получить больше людей, захватив две ниши, но рискуешь получить даже меньше - тех, кого интересуют сразу две ниши.
Учитывая, что игру с геймплеем сделать сложнее, чем простую порнуху (интерактивные анимации), может оказаться, что порнуха только портит твою геймдизайнерскую работу, а не улучшает её.
Имхо, идеальный вариант - сделать обычную игру, интересную для всех (условно, с рейтингом 0+), а потом добавить в неё порнуху якобы "неофициальным модом от третьих лиц". С одной стороны, игра будет жизнеспособна даже без порно, с другой стороны, игра будет намного интереснее дрочерам, но при этом не будет бросать на тебя тень "порнодела", ведь это чей-то чужой мод. Таким образом можно реально захватить две ниши. Практика показывает, что секс можно органично вписать практически в любую игру, было б желание рисовать спрайты или делать дополнительные анимации моделькам. Зачем вообще делать порнушную игру с геймплеем, если можно добавить порнуху в обычную игру с геймплеем?
>рпгм
Делаешь с видом сверху-сбоку как в JRPG? Вроде видел какой-то фреймворк для Godot, но меня это особо не интересовало (захочу - с нуля сделаю).
>Четвёртый, из ноды А анхандлед - не выводится, потому что в ноде Б выставлен флаг и дальнейший коллбэк игнорирован.
О чём в документации и написано.
>Хандледы же обрабатываются
Почему ты называешь их "handled"?
Нигде не сказано, что _input - это "_handled_input".
"Input" = "ввод" (любой).
"Unhandled input" = "необработанный ввод".
Как только ввод обработан, он перестает поступать в обработчик необработанного ввода. Логично? Логично. А обработчик без уточнений типа ввода обрабатывает вообще всё. Логично? Логично.
>3д билды на годоте тормозят
1. Опиши конфигурацию ПК (CPU, GPU, RAM, OS).
2. Какие билды используешь, где ты их взял?
3. Что в игре есть и что ты делаешь в скриптах?
4. Логи проверял? Если в логи идёт большой поток записей, движок может тормозить. Логи можно найти на диске или запустить игру через консоль.
Алсо, тормозит ли пустой проект с настройками по умолчанию? Некоторые настройки графики сильно повышают нагрузку. Но по умолчанию настройки должны быть достаточно производительными.
>вообще всё - энтити
Выглядит сложно...
>Дерево сцены только для гуя
У тебя странное дерево, зачем тебе SubViewport? Эта нода рендерит в отдельную текстуру, которая через SubViewportContainer рендерится в окно.
GUI можно нарисовать поверх всего остального с помощью ноды CanvasLayer:
https://docs.godotengine.org/en/stable/classes/class_canvaslayer.html
Или у тебя совсем не будет анимаций и ты решил таким образом сэкономить на рендеринге сложной сцены? Но вряд ли у тебя там будет много деталей. Выглядит как преждевременная оптимизация.
Туман войны можно было бы рендерить шейдером. Каждый тайл - один пиксель текстуры. Можно даже применить фильтрацию текстуры для "мягкой тени".
> зачем тебе SubViewport?
Из-за тумана войны самого, в годоте я с ним боролся больше всего в свои прошлые попытки заделать рогалик (это четвёртая итерация). Я хотел бы как на гифрелетед, но она сделана челиком на второй ещё версии движка и я не разобраля и не смог адаптировать его для своего ещё на третьем годоте.
Сабвьюпорт нужен был для старой (недоделанной) системы освещения из генерации текстур в прямом эфире.
Я планирую опять сделать подход к освещению, но когда будет достаточно много наработок, чтобы быть рабочим прототипом и он своим существованием меня мотивировал. Ключ моей мотивации сейчас - постоянные успехи, без завязываний на чём либо надолго.
Пришлось поискать но вот тот проект с не приклеившейся гифки https://github.com/llasram/godot-visibility-demo
Нет, сначала вызывается input, а если же никто не обработал, тогда вызовается unhandled input. Это база блджад, иначе бы было так что сначала вызывался необработанный, и... зачем тогда вызывать другие?
Алсо любая функция может пометить ввод как обработанный вызвав set_input_as_handled.
Скорее всего, он подразумевает собранные по шаблону экспорта экспортированные проекты. Но ХЗ, подождём, пусть сам скажет.
Как же красиво ребята делают...
>Если захочешь писать какие-то данные вручную для загрузки через JSON, рекомендую взять вот это
Спасибо. Я посмотрю.
>Лично меня музыка в играх особо не волнует.
Ну ты ПИЗДЕЦ. В смысле, да, согласен. Не обязательно чтоб там прям отвал башки был. И как бы музыка может либо сильно решать и тогда огромный +, либо она просто может быть и тогда всем пофигу.
>Тем более в визуальных новеллах, которые суть короткие книги с простыми иллюстрациями а-ля диафильмы или слайд-шоу.
Ну я просто ориентируюсь опять же на фейт и принцессу. Там-то бгмки хорошо задавали настроение в сцены. Я лично считаю что музыка - это вообще топ для передачи эмоций. Не даром люди на всяких концертах сознание теряют и в трансе штаны обсирают. Ну а звуки да, тоже полезны. Хорошие звуковые эффекты - всегда приятно.
Со следующими двумя абзацами согласен. Тут как бы сложно довольно получается. Даже если например музыка будет топ, то плохой сюжет всё испортит и людям будет плевать, и на оборот если сюжет топ, то даже средненький саундрек люди, чисто на эмоциях, могут переслушивать.
>А вот если ты пять лет пилишь новеллу в надежде на широкое признание твоего Гения, тогда да, ты, скорее всего, сильно разочаруешься.
Да я как бы и не претендую ни на что, но за именно сюжеты боюсь. Писанина это ведь не только про хороший и логичный сюжет, это ведь ещё красота и литературность слога и т.д. И вот тут-то я как раз и не очень.
>Собственно, на мой взгляд, сложность визуальных новелл в основном в графике. Можно написать тонны текста за считанные дни
Ну пиздец ты. Завидую твоему ходу мысли. Видимо каждому своё. Для меня графен, конечно, тоже проблема, но я уже всё. Согласен, что он может быть большой преградой в создании внки, так-как она, как раз, ВИЗУАЛЬНАЯ НОВЕЛЛА, что как бы намекает.
>Порнуха максимально сужает твою аудиторию, сокращает число площадок и видимость в интернете.
Да я знаю. Но я не претендую на большую и серьёзную аудиторию. Хочу так просто людей повеселить, а в процессе и сам повеселится.
>Учитывая, что игру с геймплеем сделать сложнее, чем простую порнуху (интерактивные анимации), может оказаться, что порнуха только портит твою геймдизайнерскую работу, а не улучшает её.
Да, я согласен, но я знаю примеры когда наличие геймплея не хило бустило игру. Да я и сам люблю игры с геймплеем, так что буду стараться сделать не просто "писька в письку". Посмотрим короче.
>Имхо, идеальный вариант - сделать обычную игру, интересную для всех (условно, с рейтингом 0+), а потом добавить в неё порнуху
Согласен. Но для такого нужно быть реальным гейм девелопером. Я себя не чувствую таковым. Опыта мало.
>Зачем вообще делать порнушную игру с геймплеем, если можно добавить порнуху в обычную игру с геймплеем?
Так вот в том-то и дело. Если есть сильная игровая база, то порнухой вряд ли получится что-то испортить. А если у тебя в игре нет элемента игры (игра говно), то тут уже всем плевать. Только самые отъявленные порнушечники в такое мучится будут.
>Делаешь с видом сверху-сбоку как в JRPG?
Да. Статик пошаг jrpgшный.
>Вроде видел какой-то фреймворк для Godot, но меня это особо не интересовало (захочу - с нуля сделаю).
Спасибо что сказал. Буду знать. Но я тож лучше с нуля поковыряюсь. Хочу разбираться в том, что делаю.
На итч лей - больше народа заметит. В браузере там тоже можно.
>И как бы музыка может либо сильно решать и тогда огромный +, либо она просто может быть и тогда всем пофигу.
Не пофигу. Примеры из личного опыта:
1. Майнкрафт. Фоновая музыка есть и в целом она неплохая, но игра её воспроизводит как-то вообще невпопад. Можешь бегать полчаса в тишине и ВНЕЗАПНО начинается громкая музыка, вот просто так. Или музыка перекрывает реально важные звуки. Особенно бесит когда эта музыка ВНЕЗАПНО начинается в тёмной пещере, как в каком-то хорроре перед встречей с боссом. Вот только никакого босса нет, она просто так началась. В мобильной версии музыка вынесена в отдельный пакет на 300+ МБ. Поведение фоновой музыки точно такое же пугающе раздражающе рандомное. Но без этого пакета ты не сможешь услышать мелодии пластинок, которые можно в игре вставить в проигрыватель. А игра даже не предупреждает, что для работы блока нужен пакет с раздражающей фоновой музыкой, лол, ты просто смотришь на куб с вылетающими нотами и слышишь тишину.
2. В GTA Online геймплей растянут гриндом на тысячи часов и игра может затягивать на весь день. Но "радиостанция" - это плейлист длительностью меньше часа. Надоедает уже на втором-третьем повторе в день. Хуже всего то, что если выключить радио в машине, то на заданиях включается навязчивая фоновая мелодия, которая ещё короче и будет повторяться пока задание не закончишь. А оно может длиться полчаса или даже дольше. Раздражает ужасно. Если часто меняешь машины, приходится регулярно переключать радио на любимые станции, а на заданиях очень часто радио тупо ВЫКЛЮЧАЕТСЯ каждый раз, когда ты покидаешь транспорт, и ты вынужден каждый раз настраивать радио, чтобы не слышать бесячую фоновую музыку конкретного задания. А потом задание заставляет тебя слезать с транспорта каждые 100 метров. И они ничего из этого не могут пофиксить за десять лет, только недавно дали возможность выключить лишние радиостанции - но это сопровождается крашем игры, когда твой пассажир включает радиостанцию из твоего чёрного списка, лол. Вообще, любая игра с гриндом вынуждает выключать музыку, чтобы она не бесила постоянным повтором.
3. В Flatout хороший саундтрек, но воспроизведение начинается с самого начала рандомной песни при каждом запуске гонки. Гонки достаточно сложные даже на аркадном управлении и зафейлиться из-за физики очень легко, поэтому приходится рестартить. В результате песня-то нравится, но ты вынужден её обрывать и слушать с самого начала что-то другое... или её же, рандом ведь.
4. В некоторых играх музыка просто раздражающая, например, какой-нибудь давящий на моск тунц-тунц-тунц длительностью 50 секунд на бесконечном повторе, при том что геймплей норм и играть ты хочешь, но слушать вот это вот безобразие не хочется. Верх идиотизма - когда в игре нет отдельной кнопки для отключения музыки, можно только отключить вообще всю озвучку, а ведь звуки зачастую влияют на геймплей сильнее фоновой музыки, поскольку они связаны с игровым миром или GUI, а не просто бесцельно крутятся где-то на фоне.
Часть этих проблем можно решить, но их бы изначально не существовало, если бы игра не навязывала игроку необязательную музыку.
>музыка - это вообще топ для передачи эмоций
Не спорю, но это всё равно только украшение для игры, а не основной контент. Настроение ты можешь получить и без игры, слушая музыку, а в игру должен хотеть играть и без музыки (иначе зачем тебе эта игра, скачай саундтрек и всё).
>Не даром люди на всяких концертах
Это совершенно другое:
- близость к тысячам людей с тем же интересом;
- близость к любимым исполнителям на сцене;
- громкий звук аж сотрясает землю под ногами;
- световые эффекты, дым и т.д.
Суть концерта вообще не в музыке, исполнитель мог бы просто громко пердеть и любители его пердежа орали бы хором от удовольствия.
https://ru.wikipedia.org/wiki/Метеорист
А вот на записи чей-то пердёж слушать уже не то.
Даже классическая музыка использует трюки вроде специальной геометрии помещения и темноты, чтобы эффективнее действовать на моск слушателя, а зарождалось это как встречи сливок общества, музыка тут как бы бонусом.
>красота и литературность слога
1. Начитанность влияет больше всего. Чем больше читаешь литературы, тем лучше твой слог.
2. Можно найти "бету" - человек, который тщательно вычитывает твою писанину и указывает на ошибки и возможные правки. В сфере фанфиков они бесплатно этим занимаются, но за деньги нанять, я думаю, будет намного дешевле писателя.
3. На английском нейронки уже несколько месяцев как научились выполнять работу беты, вычищая стиль и даже переписывая литературно. Теперь любая обезьяна может писать как Шекспир.
4. Ты не прозу пишешь и в твою игру не литературные критики играют (в основном). Каждый раз удивляюсь критике игр за литературные ошибки, как будто эти отзывы училка по литературе по привычке пишет.
5. Имхо, логичность сюжета всё же влияет больше. Логические дыры в сюжете чаще заставляют закатывать глаза и прикладывать руку к лицу, чем какие-то мелкие косяки в речи персонажей. Но если заранее всё планировать и визуализировать, то заранее увидеть и исправить косяки можно как косяки в дизайне ещё не написанной программы.
>Видимо каждому своё.
Ну, скажем, у меня скорость печати около 300 знаков в минуту и придумать какой-то сюжет по шаблонам не проблема (можно шаблонный генератор смастерить для вдохновения, если у тебя беда с фантазией), вычитать и исправить косяки тоже несложно. В конце концов, можно просто описать историю из жизни, приукрасив элементами фэнтези, вот тебе и оригинальный сценарий. Будет ли это шедевром на века? Вряд ли. Но прочитать люди смогут без проблем, и части читателей обязательно что-нибудь понравится, не обязательно быть 10/10, тем более что восприятие сюжета очень субъективно. Хейтерам всегда можно сказать, что они ничего не понимают, и они не докопаются до "анатомии", "светотени" и других чисто технических элементов.
А вот с графикой всё сложнее - ты убиваешь несколько часов на одну иллюстрацию, а результат в лучшем случае так себе, в худшем - какая-то мазня дошкольника. Всё же почти все люди в современном обществе более или менее много читают, а в школах сочинения обязательны, тогда как для рисования недостаточно просто на чужие картинки смотреть, а художества в школах обычно не являются принудительными. Если смог сдать ЕГЭ, считай, сможешь написать несложный сценарий, а для рисования нужно конкретно запариться с художкой, курсами или мучительным самообучением. А в конечном итоге графика тоже субъективно воспринимается и тебя могут облить говном просто за то, что ты рисуешь "аниме", рисование которого ты оттачивал пять лет ежедневно, а ты потом ломаешь голову, в чём же ты ошибся... И фраза "я художник, я так вижу" как-то не очень оправдывает кривые руки и косой взгляд, которые на каждой иллюстрации по-разному кривые.
Сам я такое не делал, но 5 секунд в гугле
https://gamedev.stackexchange.com/questions/35253/tweaking-astar-to-find-closest-location-to-unreachable-destination
Спасибо, но я не понял о чём там речь... Не слышал о том, чтобы AStarGrid2D или даже AStar2D в годоте были "EstimatedDistanceToEnd (ie. the lowest h(x))"
Сам не смотрел, но глянь https://rakugoteam.github.io/
Справедливо, но увы по мне так в годоте изкоробки неправильный астар и для более-менее серьезной игры придется писать свой.
Если разбираешься в с++, вот кто-то пытался решить такую задачу в форке https://github.com/godotengine/godot-proposals/issues/277#issuecomment-1379431845
> в годоте изкоробки неправильный астар
Почему ты так думаешь? Какие подводные?
> разбираешься в с++
Это есть, но пересобирать годот не хочется. Я рассматриваю сейчас активнее всего хоть и костыльный, но вариант, где никакие клетки не блокируются, но непроходимые имеют огромный вес, а саму блокировку хранить отдельно и обрабатывать где нужно. То есть даже если в пути будут непроходимые клетки, когда непись захочет непосредственно сделать шаг на такую клетку, обработчик ходьбы осадит неразумного непися и пояснит как он неправ.
Хотя стоит отметить что это звучит дорого и возможно стоит иметь несколько карт для разных видов поиска пути в зависимости от интеллекта моба.
Писал с иллюстрациями в каком то старом треде, но пост потерли.
Суть в том, что они вообще реализовали не то. В каноническом астаре вес у ребер, соединяющих узлы, а не у самих узлов. То, что есть в годоте, подходит для простых игр на джемы (когда у тебя просто клетка земли, клетка леса, клетка воды), но не подходит для глубоких тактических и стратегических игр, когда отличается стоимость входа из поля в лес, из поля в воду, из леса в воду, из воды в лес и т.д. А как ты заметил, апи не гибкий, не дает "кубиков", "строительных блоков" из которых ты мог бы собрать нужное, а умеет только пару базовых вещей. Поэтому в своем рогалике на с++ я буду писать свой астар. Раньше пытался портировать из какого-то движка на c# (Nez кажется), сейчас думаю писать с нуля с чатгопотой.
> отличается стоимость входа из поля в лес, из поля в воду, из леса в воду, из воды в лес и т.д
Разве это важно? То есть разве почему обычных весов клетки будет недостаточно?
Недостаточно даже на более простом примере (если зайти в лес из поля дороже, чем выйти на поле из леса). Просто с 3 клетками еще нагляднее будет.
Нормальных а-старов полно на гитхабе, в том числе на плюсах. Не пиши сам, подумой.
Сидим, обдумываем с phind.com процедурную генерацию мира и поведение персонажей в моей игре, открыл для себя много интересных идей.
Делать саму игру я, конечно же, не буду.
Да, заебался возиться с попытками довести до ума поиск пути на AStarGrid2D, заменю на свой, написанный по уму, в нынешнем состоянии для прототипа и основы сойдёт. Судя по https://www.redblobgames.com/pathfinding/a-star/introduction.html это относительно просто.
>>893360
> phind.com
Как оно в сравнении с ГПТ3?
>Как оно в сравнении с ГПТ3?
Ну, там за основу "лучшей модели" берут GPT-4:
>Our most advanced searching mode, powered by a combination of GPT-4 and our own model. This mode hallucinates less and writes better code.
Но он умеет гуглить и ходить по ссылкам:
>Phind is smart enough to proactively ask you questions to clarify its assumptions and to browse the web (or your codebase) when it needs additional context.
>Phind will use any custom links you paste into the search box automatically.
Есть доступ анонимно без регистрации, но помни, что все обсуждения доступны по ссылке.
А оно может само сходить на гит, изучить либу, и ответить на вопрос по ней?
Я пробовал, нет, не может, выдумывает АПИ как оно могло бы быть хорошо в идеальном мире, но увы таких функций не было.
>изучить либу и ответить на вопрос
Наверное, зависит от сложности.
Галлюцинации неизбежны, т.к. GPT только генерирует текст. Такие нейронки не проверяют факты в написанном, и если она что-то написала не так - backspace жать не будет. Для избавления от галлюцинаций нужен бесконечный цикл самопроверки, а это уже никто бесплатно тебе не даст, придётся на своём железе крутить.
На пикриле цитаты из документации к Godex на гитхабе, вот только эти цитаты устарели после того, как разработчики добавили этап инициализации, так что теперь никакой физический пайплайн настраивать больше не нужно. Вывод: проще самому перейти по ссылке и прочитать. Но нюанс в том, что я не задавал никаких конкретных вопросов, только "опиши", вот она и описала как смогла.
>ходить по ссылкам
Ладно, похоже, не умеет.
МОЖЕШЬ ХОДИТЬ ПО ССЫЛКАМ?
@
МОГУ, ДАВАЙ ССЫЛКУ
@
ВОТ ССЫЛКА
@
ОЙ, НЕ МОГУ. Я ИИ АССИСТЕНТ И У МЕНЯ НЕТ ДОСТУПА В ИНТЕРНЕТ. ЗАДАВАЙ ОТВЕТЫ.
@
ХОРОШО, ПРОСТО ОПИШИ ЧТО ТАМ ЕСТЬ
@
ЩАС ПОГУГЛЮ...
@
ДА ТАМ КАКИЕ-ТО ДВАЧЕРЫ ТОКСИЧНЫЕ [^3^] ТИПА ИГРЫ ДЕЛАЮТ. ВЕДИ СЕБЯ ХОРОШО, СЭМПАЙ. [^3^]
@
ЕЩЁ ВОПРОСЫ? [^3^]
Даже такое общение лучше, чем с людьми. [^3^]
Что здесь не так?
var hp:int = 0
onready var hp_bar = $ProgressBar
func set_max_hp():
hp = randi() % 3 + 1
hp_bar.max_value = hp
Invalid call. Nonexistent function 'set_max' in base 'Nil'.
туплю не понимаю
По ошибке выглядит так, будто ты пытаешься вызывать метод у объекта, который ещё не инициализировался. У тебя точно ProgressBar существует как ребёнок ноды, к которой приклеен скрипт и получается её найти?
Зачем тебе такое решение? Рассмотрим ситуации.
1. Игрок промахнулся. Персонаж топает куда-то, куда не следует. Игрок злится.
2. Игрок тыкает на клетку за пределами зоны ходьбы, рассчитывая, что персонаж остановится. Персонаж топает к краю скалы без моста, падает и умирает, потому что по механике встать на край обрыва можно, но смертельно опасно. Игрок злится.
3. Игрок тыкает на клетку за стеной, рассчитывая пробить себе путь киркой. Персонаж топает к стенке, а стенка-то неразрушимая. Игрок злится.
4. Игрок тыкает на клетку за болотом, земля вокруг которого огорожена непроходимым забором. Персонаж топает в болото и тонет. Игрок злится.
Всего этого можно избежать, если просто никак не двигаться, когда тупой игрок приказывает идти туда, куда невозможно дойти. В случае NPC, они, в отличие игрока, наделены интеллектом, поэтому идти туда, куда нельзя дойти, не будут.
Чисто интуитивно я жду от игры интеллектуальной подсказки: мол, сюда вот дойти нельзя, поэтому персонаж не будет нарезать круги бестолку. Если на карте спиральный туннель длиной в километр, а в центре непроходимое препятствие, я буду дико взбешён от того, что игра вообще начала двигать персонажа в этот тупик. Это просто тупо...
А если ты хочешь разместить лучника, который мог бы стрелять через стены, реки и обрывы, тогда тебе нужен не AStar, а какой-то другой алгоритм, определяющий наличие подходящей для стрелка позиции. Потому что самая короткая дистанция не всегда самая эффективная.
>>893159
>вес у ребер, соединяющих узлы, а не у самих узлов
Вес у рёбер есть. Но он не произвольный, а зависит от расстояния между узлами. Если у тебя все узлы на равномерной сетке, то и веса всех рёбер равны.
>отличается стоимость входа из поля в лес, из поля в воду, из леса в воду, из воды в лес и т.д.
Вход должен быть одинаковым независимо от того, откуда ты начинаешь движение, если движение происходит по дискретным клеткам, потому что ты не можешь встать между клетками.
Для примера, если мы пытаемся просчитать оптимальный путь между комнатами лаборатории, то мы будем стараться избегать комнаты с радиацией, токсичным газом, зомби и другими препятствиями и опасностями, независимо от того, с какой стороны входим в комнату. И наоборот, мы выберем путь в безопасную комнату из опасной даже если путь из опасной комнаты в другую опасную комнату короче. В данном случае комнаты - это клетки (узлы графа), мы не можем встать в проходе и нас не сильно интересует, сколько времени мы будем идти внутри комнаты, если само вхождение в комнату грозит моментальной смертью. Само же движение между двумя комнатами оценивается геометрическим размером комнат (длина ребра графа), а не каким-то рандомным числом (этот твой вес ребра). Если у тебя путь между двумя комнатами ограничен необходимостью взломать панель доступа, ты должен поставить дополнительный узел возле двери, задав ему высокий вес, поскольку взлом займёт много времени. Движение в пространстве разбивается дополнительной точкой, путь до которой короче, но пройти которую сложнее, чем простую дверь.
Если же ты пытаешься симулировать ходьбу по очень большим пространствам, как здесь:
1. Шли 2 часа к центру леса.
2. Шли 2 часа к краю леса.
3. Перешли на край поля.
4. Шли 1 час к центру поля.
5. Шли 1 час к краю поля.
6. Перешли на край воды.
7. Плыли 4 часа к центру воды.
8. Плыли 4 часа к краю воды.
9. Перешли на край леса.
Тогда тебе просто нужно больше узлов:
- центр области, из которого идут к краю;
- край области с каждой проходимой стороны.
Края соседних областей будут совпадать чисто геометрически, т.е. расстояние между ними - ноль, но формально это разные узлы, ведь они меняют свойства движения: перейти от центра леса на край леса или обратно сложнее, чем перейти от центра поля на край поля или обратно.
А как иначе это решать?
Понятное дело что это не для игрока, а для всякого эффективного окружения мобами и прочего
>эффективного окружения мобами
1. Мобы за стеной не должны преследовать игрока, потому что они не знают о его существовании.
2. Мобы за рекой могут подходить к краю реки, если видят игрока в зоне прямой видимости (рейкаст).
3. Если моб способен слышать игрока, тогда он идёт не к источника шума, а в сторону усиления шума, то есть ему вообще не должен быть известен оптимальный путь к игроку, даже если они есть.
4. Если хочешь создать засаду из мобов в визуально скрытой от игрока зоне, проще заспавнить новых мобов сразу за разрушенной игроком стеной, чем звать уже имеющихся мобов к непроходимой стене. Игрок не заметит разницу, ведь он не видит этих перемещений за кадром.
Челидзе, поиграй хотя бы в одну РТС, прежде чем рассуждать о том, что там игрок хочет или нет.
>Вход должен быть одинаковым независимо от того, откуда ты начинаешь движение,
Это не так, поэтому дальшнейшую стену текста не читал.
В стратегии в одну и ту же клетку равнин вход может стоить разную стоимость, если с ты выходишь из леса, или идешь поперек дороги, или идешь вдоль дороги.
Ты опять не понял. Если в клетке может быть только одно существо, то оно по сути блокирует путь остальным. Как тогда толпой из двадцати орков окружить игрока в максимально плотное кольцо? Делать мобов не блочащими путь, а делать клетки на которых они находятся дорогими, но не позволять вставать на них в обработчике ходьбы
В смысле замедляется? Как это должно для пользователя выглядеть?
>Есть окошко диалога куда вбиваются символы по таймеру
Если ты хочешь чтобы текст появлялся плавно, символ за символом, то у лейбла есть охуенное свойство percent visible, которое делает именно это. Еще visible characters есть.
>В смысле замедляется? Как это должно для пользователя выглядеть?
У меня символ печатается по таймеру раз в 0.04 секунды. Я хочу чтоб я например оставил в строке "Я посрал ^^говном" вот эти вот ^^ и тогда "Я посрал" напечатается со скоростью 0.04 секунды, а "говном" со скоростью 0.5 например.
>>893449
>percent visible
Спасибо. Буду знать. Но мне нужно как раз по буквам. Что visible characters и делает собственно.
>поиграй хотя бы в одну РТС
Играл в несколько разных RTS. Бесит, когда юниты могут принять команду на движение в недоступную для них зону карты и застрять по дороге, а потом их придётся возвращать обратно, когда заметишь, что они напрасно ходили в какой-то тупик.
Вот представь, у тебя N отрядов, ты отправляешь один через всю карту, и пока занимаешься другими отрядами, ожидаешь, что отправленный отряд выполнит свою задачу. А они встали в какой-то дыре и стоят, ведь система навигации не смогла проложить путь до цели, заведя отряд в какой-то рандомный тупик. Зачем так обманывать игрока?
Игра должна чётко говорить игроку: сюда пути нет, сюда пройти нельзя. Она не должна отвечать, что сюда пройти можно, а потом бросать ходьбу на полпути, потому что пройти в реальности нельзя.
>>893420
>В стратегии в одну и ту же клетку равнин
Просто убери клетки. В RTS клетки - атавизм.
>>893437
>Как тогда толпой из двадцати орков окружить игрока в максимально плотное кольцо?
Это уже не относится к AStar. AStar только находит кратчайший путь. Чтобы мобы окружили игрока, тебе нужно найти подходящие позиции в окружности вокруг игрока, а затем отправить мобов на свободные позиции. Менеджер мобов выдаёт им свободные места как билеты в кинотеатре. А как они будут друг друга обходить - вообще отдельная задача.
Если нужно пройти большое расстояние, мобы могут выстраиваться в колонну, следуя друг за другом, и когда первый моб достигает цели, следующий за ним движется к ближайшей незанятой клетке, и т.д.
В большинстве игр мобы проходят друг друга или вообще не обходят препятствия. Если твоя игра не фановая из-за того, что мобы проходят друг сквозь друга или тупят возле препятствий, то ты делаешь что-то не то. Делай так, чтобы игра была интересной даже с максимально тупыми мобами.
Так я не про RTS говорил, а стратегии. RTS крайне редко бывают стратегиями, это тактики в основном.
Назови мне какую-нибудь актуальную клеточную стратегию с твоей механикой. Лучше на Android.
А то без примеров это просто хотелки какие-то.
>Ряяяяяя, в Godot неправильно реализованные StaticBody3D, они не могут набигать!!
>Где ты видел, чтобы StaticBody3D набигали?
>Я хочу чтобы домики набигали! Домики - это недвижимость, но в их API нет nabigat(mesto)!!!
>Как бы сделать, что если в строке есть определённая комбинация символов, например ^^, они не печатаются, но таймер замедляется пока не дойдёт до пробела " ".
Алгоритм прост, но для него требуется:
- проверять, какой символ мы будем печатать;
- проверять следующий символ после него.
Делать это через API RichTextLabel скорее всего будет затратно, поскольку там происходят операции с BB-кодами, добавляющие форматирование.
Я бы попробовал загонять текст по букве. Либо загонять сразу весь текст, но без твоих "^^" - с самого начала удали их из текста, сохранив информацию о том, на каких позициях нужно включать замедление.
В общем, это никак не касается API Godot. Это чисто алгоритмическая задача. Тебе её помочь решить?
>Алгоритм прост, но для него требуется:
>- проверять, какой символ мы будем печатать;
>- проверять следующий символ после него.
>Делать это через API RichTextLabel скорее всего будет >затратно, поскольку там происходят операции с BB-кодами, >добавляющие форматирование.
>Я бы попробовал загонять текст по букве. Либо загонять сразу >весь текст, но без твоих "^^" - с самого начала удали их из >текста, сохранив информацию о том, на каких позициях нужно >включать замедление.
Ну я вот тоже так думаю. Все строки в json у меня. По сути всё так, как ты и сказал, но я хз как такое сделать. У меня есть идея загнать всю строку по символам в массив. И там уже операции производить. Но может есть какое-то более элегантное решение?
>Это чисто алгоритмическая задача. Тебе её помочь решить?
Если тебе не сложно, то буду рад помощи.
>загнать всю строку по символам в массив
Работать будет, но есть один нюанс - Godot будет вынужден после каждого символа перестраивать элемент GUI и отображаемый текст. Хотя для коротких текстов разница должна быть незаметной.
Учитывай, что Timer.wait_time не может быть короче времени одного кадра или тика физики, и может странно себя вести на слишком коротких интервалах.
Кстати, меня раздражает этот эффект "печатной машинки" в играх. Он не помогает чтению, ведь взрослые люди не читают по буквам как маленькие дети, и эффект совсем не похож на речь. Люди читают текст по словам, вот наглядный пример, просто расслабься и смотри в центр экрана, не проговаривая слова:
https://youtu.be/XJd_RvAlMKU
ИМХО, в визуальных новеллах вывод текста должен быть аналогичным образом - по словам, а не по буквам. Так хотя бы можно будет читать текст сразу, не дожидаясь, пока игра выведет все буквы, и не пропуская эту анимацию кликом. Хотя для оптимального чтения слова должны сменять друг друга в одном месте (как на видео), чтобы читателю не приходилось двигать глазами.
Могу накидать алгоритм для быстрого вывода по словам с эффектом замедленной побуквенной печати на отдельных словах. Можно использовать String.split(" ") для получения списка слов, а потом просто проверять, не начинаются ли слова контрольным символом: String.begins_with("^^").
>Могу накидать алгоритм для быстрого вывода по словам с эффектом замедленной побуквенной печати на отдельных словах.
Как-то так можно.
Текущий код (рис.1):
if raycast.is_colliding():
var decal = preload("res://decal.tscn").instantiate()
raycast.get_collider().add_child(decal)
decal.global_position = raycast.get_collision_point()
Текущий код (рис.1):
if raycast.is_colliding():
var decal = preload("res://decal.tscn").instantiate()
raycast.get_collider().add_child(decal)
decal.global_position = raycast.get_collision_point()
двачую, а лучше бы по возможности весь текст был сразу виден, чтобы читал с удобной скоростью игрок
>куб
>decal
Куб - не декаль, декаль - это текстура:
https://docs.godotengine.org/en/stable/classes/class_decal.html
https://en.wikipedia.org/wiki/Decal_(disambiguation)
>Decal texture, a texture/image overlaid on top of other textures in computer graphics
>куб не располагался в стене
Сдвинь свой куб в сцене decal.tscn так, чтобы одна из его сторон пересекалась с точкой (0;0;0), а потом поворачивай куб, чтобы он был параллелен нормали:
https://docs.godotengine.org/en/stable/classes/class_raycast3d.html#class-raycast3d-method-get-collision-normal
...как конкретно вращать - выясняй сам, мне лень. Я каждый раз методом тыка разбираюсь, лол.
>чтобы он был параллелен
Хотел написать "чтобы ось, перпендикулярная грани, пересекающейся с точкой начала координат, была параллельна нормали точки коллизии". Ну ты понял.
>как конкретно вращать - выясняй сам
Там что-то с базисами и вот это вот всё. Чисто по ощущениям потыкай числа и что-то получится. Всегда так делаю и спустя несколько часов получается.
Спасибо за помощь. Ты навёл меня на определённую мысль. Постараюсь это всё перетащить себе в код. Я и не подумал на слова разбивать.
> меня раздражает этот эффект "печатной машинки" в играх
Скучный.
>>893593
>лучше бы по возможности весь текст был сразу виден, чтобы читал с удобной скоростью игрок
Тоже скучный.
Будет хорошим тоном сделать варианты и для таких скучных, чтобы в опциях можно было выбрать
>Скучный.
Если хочешь нескучный текст, сделай чтоб буквы подпрыгивали, делали переворот в полёте, динамично меняли рандомные цвета и масштаб, из букв вылетали искорки, звёздочки, сердечки и маленькие мордочки животных, и всё это сопровождалось множеством забавных звуков вроде "ня", "кря" и прочее. И чтобы эти эффекты нельзя было отключить или пропустить.
Игроки читатели будут блевать радугой и писать "рекомендую" в отзывах, чтобы другие тоже проблевались.
Яндекс, вк - там нормизы сидят. Белорусам на игровое шоу отправь, вдруг увидят.
>>893559
>Игра должна чётко говорить игроку: сюда пути нет, сюда пройти нельзя.
А если местность скрыта для игрока? Получается, он таким образом может получить информацию, которую знать не должен, пока не разведает местность. Просто отправляя юнитов в закрытые регионы (и тут же отменяя) можно узнать, проходимы они или нет. Или например, местность уже разведанная, но с тех пор враг успел там построить стену; игрок эту стену ещё не видел, но может догадаться о её появлении по тому, что юниты отказываются туда идти.
>>893607
Обычно делают для нетерпеливых - по нажатию кнопки анимация прерывается, весь текст отображается.
Тащемта "сок" нужен, анимированный текст придаёт ощущения, что это персонаж реально говорит. Но факт - большинство игроков в какой-то момент наедаются этим эффектом и начинают скипать анимации.
Олсо, хинт. У лейблов (в том числе ричтекст) есть свойства percent_visible и visible_characters, существующие именно для таких анимаций. Они позволяют не пересчитывать каждый раз границы элемента и избегать случаев, когда слово начало отрисовываться на одной строке, а в следующем кадре резко целиком перенеслось на следующую, потому что не влезло.
А ещё ричтекстлейбл умеет возвращать чистый текст, без ббкодов, чтобы, например, проще там было найти эти самые ^^ или что ещё надо.
>А если местность скрыта для игрока?
По чёрным клеткам вообще должен быть полный запрет ходьбы. Вдруг там ловушка? Яма? Болото с крокодилами? Минное поле? Радиация? Аномалии?
>местность уже разведанная, но с тех пор враг успел там построить стену
Я бы последовал принципу "better safe than sorry" и трактовал серые клетки как чёрные, см. выше. Если настолько сильно нужна быстрая ходьба - ставь вышки, которые будут мониторить дорогу, сообщая о проблемах заранее. Иначе ты посылаешь своих бойцов на убой, т.к. они тупые как дети.
ИРЛ разведка и все её устройства предназначены как раз для того, чтобы не посылать отряд "куда-то туда", чтобы он застрял в тупике/ловушке/засаде.
TL;DR: хреновый из тебя стратег, если ты хочешь посылать юниты в неизвестном направлении.
И тебе кажется интересным микрить каждого разведчика по трём направлениям пройти вперёд на десять шагов?
>ощущения, что это персонаж реально говорит
Для этого игра должна не буквы печатать, а слоги, соответствующие произносимым звукам, ещё и липсинк прикрутить можно. Всегда воспринимал эту печать текста как неуместный атавизм древних времён, когда компы были такими медленными, что натурально печатали на экране текст.
>percent_visible и visible_characters
Ты опять с запоздалыми советами?
Присмотрись к коду на скриншоте: >>893438
Мне никогда не было интересно играть против онлайн игроков, которые за 10 секунд развиваются и уже собирают против тебя войско. А в одиночном режиме в РТС всё обычно тихо и спокойно, боты не быкуют и есть достаточно времени для развития.
Я не спорю, что для какой-нибудь высшей лиги состязательных РТС нужно другое управление. Но Godot вряд ли потянет такое без специальных модулей, а раз ты всё равно движок модишь, так что толку жаловаться на встроенный астар, вполне подходящий обычным играм.
У нас тут 5 фпс от 150 кинематиков в кучке, а ты на стратегию уровня старкрафта замахиваешься...
Я другой анон, но изъяны в твоей логике очевидны. Вспомни тот же варик третий, где такая возможность есть. Или век империй второй. Да вообще во всех одиночных стратегиях можно посылать юниты в неизвестность.
>когда компы были такими медленными, что натурально печатали на экране текст.
Наоборот же. Когда компы были настолько медленными, что даже отображение текста было трудной задачей, отрисовка по буквам была вообще недостижима. Настолько, что даже ввод с клавиатуры не отображался в реальном времени, пока ентер не бахнешь.
А вот игры "в стиле ретро" очень любят отрисовывать по буковкам, потому что реальные старые игры именно так и делали. А делали они это именно из-за того, что так тексту придавалась динамика без чрезмерной вычислительной нагрузки. Но, конечно, следует понимать, где стоит использовать такой эффект, а где нет. В каком-нибудь cozy adventure он обязателен (ещё и с разноцветными буковками, искорками и прочими свистоперделками), а в рпг типа фоллаута уже категорически не нужен. Всё-таки в первую очередь это художественный приём.
>Ты опять с запоздалыми советами?
лол, походу да :3
>>893642
>хреновый из тебя стратег, если ты хочешь посылать юниты в неизвестном направлении.
Последний раз играл в стратежки лет 15 назад, так что да, определённо хреновый.
Есть опция экспорта откуда угодно куда угодно. С линукса на винду и наоборот, например. Если ты об этом.
не я про то, что движок под винду собирать говорят студией или как альтернативой mingw
а я спросил clang-ом собирается нормально ли и собирается ли
>clang-ом собирается нормально ли и собирается ли
Судя по гитхабу, да, есть возможность собрать и в пулл-реквестах встречаются фиксы багов с clang.
Честно говоря, я ни разу годот из исходников не собирал, так что ничем помочь не могу.
другой анон
clang под виндой вроде все равно сильно от студии зависит? Не уверен, давно не возился с этим.
Вот тут можешь поскроллить, там и какие то флаги упоминаются, и пулл реквесты правда закрытые с пометкой недостаточно проработаны.
https://github.com/godotengine/godot/issues/6560
Попробуй поискать grappling hook, должно быть куча туториалов.
https://godotengine.org/asset-library/asset/1712
> Всегда воспринимал эту печать текста как неуместный атавизм древних времён, когда компы были такими медленными, что натурально печатали на экране текст.
Они имитировали печатные машинки, которые в то время еще были понятны и знакомы игрокам.
https://youtu.be/HlqOLYSmKk0?t=41
Не переусложняй, в стратегиях обычно есть разные виды кликов (с шифтом, контролем), где меняется режим движения - так что можно делать и так и так, игрок сам решит, когда надо идти в неизвестность, а когда не надо, когда атаковать а когда просто бежать мимо.
Если, конечно, не прикручиваешь продвинутый ИИ. Но, судя по шебм тредам, стратеги то особо микро и не занимаются, а действительно посылают юниты как попало, прямо по минам.
У кое-кого на борде в играх на годоте так нескучно и сделано.
>Когда компы были настолько медленными, что даже отображение текста было трудной задачей, отрисовка по буквам была вообще недостижима.
Возможно, мы о разном говорим? В фильмах часто на зелёных экранах буквы появляются по одной - и это не выдумка сценаристов, что-то такое было ИРЛ. Вот, недавно видел видео про ASCII анимации в терминале, и там автор объясняет, что увидеть анимацию без специальных настроек невозможно, потому что терминал на современном ПК выводит текст слишком быстро. Дальше он показывает замедление до считанных тысяч бод и на экране видна анимация. Учитывая, что MUD состоит в основном из текста, который передаётся в терминал через сеть - можно предположить, что на ранних этапах медленный вывод в играх вплоть до отдельных символов был вынужденным, а не художественным приёмом. Ты просто не можешь выводить буквы быстрее, чем они прилетают к тебе по проводам.
Далее, в прошлом я имел много опыта в TurboPascal, и заметил, что для вывода на экран без мерцания ему не хватает скорости. Сейчас принято очищать экран после каждого кадра, а раньше такая роскошь была явно недоступна. Т.е. дешевле вывести дополнительные элементы поверх уже имеющихся в видеопамяти, чем полностью очищать экран и выводить заново. Это же касается прямого вывода в текстовый буффер экрана. Конечно, ты можешь выводить большими пачками, а не отдельными символами, но замедление всё равно ощущается.
Как вообще работает компьютер? Монитор условные 60 раз в секунду обновляет свои физические ячейки (субпиксели), но для их обновления ему нужна информация о том, в каком состоянии должны быть эти физические ячейки. Эта информация хранится где-то в памяти, по заранее известному адресу. Хранение этой информации бесплатно, чтение этой информации дёшево, но изменение - дорого. Центральный процессор может менять эту информацию в режиме одна ячейка за раз, а видеоускорители позволяют менять сразу несколько ячеек параллельно по одной команде процессора. Вот с распространением этих видеоускорителей стало возможным менять сразу всю информацию о кадре 60 раз в секунду, а раньше ты был вынужден последовательно переключать ячейки. Если ты пишешь в ячейки памяти медленнее, чем монитор обновляет видимые пользователю физические ячейки, пользоваль неизбежно будет видеть "анимацию" вывода информации на экран. Т.е. это не художественный приём, а особенность работы компьютера.
>cozy adventure
Как искать? Я понял, что это "уютное приключение", но поисковик выдаёт какую-то фигню.
>в рпг типа фоллаута уже категорически не нужен
Я бы предпочёл короткие сообщения, разбитые по отдельным предложениям, чем встречать в игре стену текста на 2-3 А4 листа, которую ты обязан прочитать за один раз, чтобы всё понять...
Попытался однажды сыграть в Morrowind, а там с самого начала доступны КНИГИ, в которых на десятках страниц расписывают приключения каких-то ноунейм царей или что-то вроде того. Охренеть, зашёл, называется, в видеоигру, и несколько часов буду сидеть книжки читать?! Можешь сказать, что у меня "твиттерное мышление", но чукча писатель, чукча не читатель. Я не хочу читать стены какой-то рандомной фэнтезятины, которые даже не имеют отношения к реальному геймплею (заклинивание мобов насмерть, прокачивая цифру урона от каждого клика, и получая какой-то лут на продажу или для коллекции). Вот если бы разбили эту информацию на короткие кусочки, доступные по ходу исследования мира - тогда ОК, интересно, а так я лучше пойду на Вики прочитаю всё это нормальным шрифтом с нормальным фоном на телефоне, чем сидеть и читать виртуальные книги в игре...
>Если, конечно, не прикручиваешь продвинутый ИИ. Но, судя по шебм тредам, стратеги то особо микро и не занимаются, а действительно посылают юниты как попало, прямо по минам.
Насколько я понял, нейронка победила в Дота 2 за счёт бешеного микроконтроля всех 5 персонажей, так что её даже специально замедляли, чтобы дать шанс мясным мешкам с их медленной реакцией. Т.е. продвинутый ИИ будет заниматься микроконтролем, а не посылать бесконтрольную толпу. Очевидно, игроки забивают на микроконтроль просто потому что у них нет физической возможности им заниматься.
Второе предложение было про стратегов ИРЛ, просто не стал акцентировать внимание.
А под продвинутым ИИ я имел в виду нечто такое.
Вот выше анон писал, что если враг не может подойти к игроку, то он должен остаться стоять или подойти к стенке/реке и остановиться. Это действительно ожидаемое поведение в играх в прошлом.
Только вот продвинутый интеллект, как раз, должен был бы подумать - ага, раз враг в той комнате за стеной, значит я могу добежать вон до того коридора и перехвачу его там, когда он будет выходить. В это время другой юнит мог бы подумать, ага, мой напарник перекроет тот коридор, значит я могу пойти налево и там прикрыть второй выход, если враг решит вылезти там.
>добежать вон до того коридора
По идее, AStar как раз может это решить, если путь "сквозь стену" значительно дороже, чем путь через "закрытую дверь в конце коридора". AStar проложит обходной путь до двери, а дальше моб просто ждёт, пока дверь не откроется игроком. Зависит, конечно, от геометрии карты, и может быть неэффективным решением в определённых случаях.
>другой юнит мог бы подумать, ага, мой напарник перекроет тот коридор, значит я могу
Для этого уже лучше создать общего менеджера, чем пытаться научить индивидуальных агентов. Агенты по одиночке будут вынуждены работать со слишком большим числом переменных, в отличии от общего менеджера, который может решить задачу "надо перекрыть все выходы" и отправить свободных юнитов на позиции. Менеджер решает задачу "навредить игроку" и использует юнитов как пешки, тогда как индивидуальные агенты будут слишком перегружены лишними деталями вроде "куда идут мои товарищи и что нам там делать". Индивидуально думающие агенты подходят симуляции живого мира, но не подходят для стратегических игр.
Написал стену текста и удалил, давайте без оффтопа.
надо поискать может был тред про игровой ИИ (ну, который не про нейронки)
>веревку ниндзя
Подобное делается созданием большого количества RigidBody2D, соединённых между собой PinJoint2D:
https://docs.godotengine.org/en/stable/classes/class_pinjoint2d.html
Игрок (червяк) болтается на последнем сегменте, для спуска добавляются новые сегменты, для подъёма ближайший к игроку сегмент удаляется. Для раскачки игрок прикладывает импульс к ближайшему сегменту.
>>893770
>grappling hook
В Worms другое. Там прям физическая нитка, которая наматывается на препятствия, и на которой можно физически реалистично раскачиваться.
А по твоей ссылке простой импульс:
>When it reaches a body, it will pull the player towards it. If the player moves during that, the grapple will cancel.
Подобное делается элементарно, тут даже туториал не нужен, если ты хоть немного в движке разбираешься.
>тред про игровой ИИ
Такого сейчас нет и вроде никогда не было.
Проблема такого треда в том, что "игровой ИИ" - это большая куча разношёрстных специализированных алгоритмов, которые делаются под одну конкретную задачу и чаще всего не подходят всему остальному.
Что там обсуждать?
Деревья решений?
Конечные автоматы?
GOAP планировщик?
Генетические алгоритмы?
Всё сведётся к кучке безыгорных фантазёров, которые не могут конкретизировать задачу.
Только я бы не стал использовать стандартные джойнты, а сделал свои.
Честно говоря, цепь в Dumer довольно нестабильно себя вела.
Вообще я заметил, что коллизии вращения - довольно непроработанная в разных движках тема. Видимо математика становится сложной на шейпкастах.
Представьте ситуацию, играете себе, получаете экспу, и по середине экрана появляется окно, где можно повысить характеристику например. Надо, чтобы весь мир паузился кроме этого окна. Как это сделать?
Прикол в том, что если у тебя окно появляется посередине, то ты НЕ хочешь чтобы весь мир паузился. Ты хочешь паузить только игровую логику, но не хочешь паузить, например, анимацию воды и травы, музыку. Поэтому тебе и ответ - паузи только тот process который отвечает за игровую логику.
Делай очень-очень простые. А еще лучше - разбивай их на очень-очень-очень простые компоненты.
Когда делаешь ОЧЕНЬ простую игру начинает казаться, что она никому не нужна (так и есть). В итоге на половине начинаешь думать, что надо бы прикрутить систему апгрейдов, ещё какие-нибудь приколы. А эти самые приколы оказываются адски тяжелыми в реализации для нубаса.
>она никому не нужна (так и есть)
Никакая игра никому не нужна. Мы мельче пыли в масштабах вселенной, и никто из нас не доживёт до времён, когда какая-либо цивилизация сможет существенно влиять хотя бы на одну галактику, что уж говорить о наших компьютерных развлечениях, которые устаревают быстрее, чем сменяются поколения людей. Но даже если рассматривать с точки зрения человечества, никакие игры не нужны - нужны только способы удовлетворения наших животных инстинктов. Даже если бы игр не было, люди нашли бы себе занятия для развлечения. Важность игр искусственно преувеличивается в целях прибыли их разработчиков и владельцев, как, впрочем, и важность очень многих других не обязательных для выживания товаров. Тебе буквально внушают необходимость купить что-то, и ты можешь настолько поверить этим внушениям, что начнёшь сам убеждать окружающих купить что-то, поиграть во что-то и т.д. Люди всего лишь животные, управляемые древним механизмом подкрепления, нас можно дрессировать как животных и нам это будет даже нравиться, у нас только иллюзия свободы. Вот игры, и вообще любая индустрия дрессирует нас покупать, чтобы мы генерировали им больше прибыли. А сами по себе игры не нужны независимо от их сложности, так что если твоя игра проще какой-то другой - не парься. Сделай клон гиперказуалки, они очень популярны несмотря на техническую, геймплейную и визуальную простоту.
https://www.roguebasin.com/index.php/Field_of_Vision
>У анона выше было сделано что-то похожее
У него просто второй тайлмап с единственным тайлом в виде чёрного квадрата. Скорее всего.
>Ты хочешь паузить только игровую логику, но не хочешь паузить, например, анимацию воды и травы, музыку.
Ну хз, а я (влез в ваш разговор) вот не люблю, когда игры так делают. Когда какие-то анимации на паузе продолжают двигаться, то
а) возникает ощущение, что пауза какая-то "ненадёжная", может подвести в какой-то момент, и какой-нибудь геймплейный элемент не замрёт.
б) теряется вера в игровой мир, сразу понимаешь, где декорации, а где настоящие интерактивные объекты.
И музыка - мне вот нравится, когда на паузе либо отдельная музыка, либо просто основная приглушается. Ну, если пауза инициирована не игроком, то второй вариант. Сразу как-то фокусирует внимание.
>>893774
>Как искать? Я понял, что это "уютное приключение", но поисковик выдаёт какую-то фигню.
Я бы сказал, Hyperbolica по самой сути попадает в жанр. Шатаешься по миру, общаешься с "няшными" персонажами, а с кисельных берегов единороги ссут радугой в молочные реки. Из геймплейных механик - ходьба.
Годаны, я трейлер белорусам отправил. Впервые показываю свою игру не каким-то друзьям-знакомым, а прям важным дядям, для которых игры это не баловство, а профессия.
Если хочешь чтобы тайлы оставались видимы, то тебе в общем-то ничего делать не надо после того как клетку открыл. Смотри пикрелетед
>>893857
Всё так, но два цвета: один чёрный, другой серый прозрачный для известных клеток, но вне поля видимости.
> Годаны, я трейлер белорусам отправил. Впервые показываю свою игру не каким-то друзьям-знакомым, а прям важным дядям, для которых игры это не баловство, а профессия.
поздравления мои прими
Конечно же поздравляю, но с этого
>для которых игры это не баловство, а профессия.
Кринжанул
> image.png
Ужас какой-то. Человек пытается в какие-то модные-молодёжные ЕЦСы, но при этом допускает в своём коде магические числа.
Ой всё. Переделка работы с графоном у меня в планах, если я сейчас вместо маленьких успехов ведущих к игре буду пытаться сделать всё идеально, то у меня игры никогда не будет.
>если я сейчас вместо маленьких успехов ведущих к игре буду пытаться сделать всё идеально, то у меня игры никогда не будет
Этот шарит.
> модные-молодёжные ЕЦСы
это уже как сто лет стандартный подход в играх
Не работает почему-то, уже часами над этим сижу. Может какие-то ноды неправильно работают с этим? Это просто элемент гуи, панель и на ней лейбл и контейнер, мир паузится, а панель не анпаузится, даже если процесс ставить.
>модные-молодёжные ЕЦС
Не вижу там ЕЦС, по ЕЦСу каждая клеточка карты - это сущность с компонентами, например:
- компонент "видна";
- компонент "исследована игроком";
- компонент "спрайт";
- компонент "позиция";
и т.д. Далее десятки систем параллельно работают с каждой клеточкой на 9000 ядрах процессора, избегая промахов кэша и повышая ЧСВ разраба до небес.
А у него ООП какое-то с циклами в циклах... Будет занимать одно ядро и промахиваться мимо кэша каждый раз, когда ОС переключает процессы.
>допускает в своём коде магические числа
Это фигня по сравнению с тем, что он допустил C#.
>>893877
>стандартный подход в играх
Это компоненты в играх стандарт, а ЕЦС возвели в культ совсем недавно, под давлением корпоратов.
Скоро ничего нельзя будет сделать без создания нескольких сотен систем для переключения bool.
Зависит от версии Godot. В 4.0 синтаксис поменяли.
Godot 4.x:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#properties-setters-and-getters
Godot 3.x:
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_basics.html#setters-getters
> каждая клеточка карты - это сущность с компонентами
Звучит не очень эффективно
> он допустил C#
Не на ГД скрипте же писать в годоте. Он ещё медленнее же
>возникает ощущение, что пауза какая-то "ненадёжная", может подвести в какой-то момент, и какой-нибудь геймплейный элемент не замрёт.
У тебя какая-то психотравма или профдеформация, если ожидаешь на каждом шагу game-breaking bug.
>теряется вера в игровой мир, сразу понимаешь, где декорации, а где настоящие интерактивные объекты.
Пауза сама по себе ломает веру в игровой мир, особенно когда злые мобы, люди вокруг и даже само солнце резко встают на месте и ждут, пока ты не закончишь диалог с каким-либо персонажем.
Ящитаю, если не хочешь анимировать фон, тогда делай окно паузы на весь экран, чтобы оно перекрывало всю игру - какой-то своей картинкой, сплошным чёрным фоном или хотя бы очень сильным размытием. Если ты делаешь маленькое окошко в центре/сбоку экрана, или хочешь ставить игру на паузу во время диалога - анимации необходимы, чтобы картинка не выглядела скучной. Анимация воды нужна не для того, чтобы игрок верил в мир, а чтобы картинка была нескучной - потому что в стоячей воде нет ничего нереалистичного, даже текущая река чисто визуально может выглядеть неподвижной - но наблюдать за стоячей рекой скучно, так что анимации здесь служат исключительно эстетическую роль. Аналогично с травой, светлячками, облаками и т.п. Останавливаться должны только объекты, движение которых способно влиять на геймплей. Скажем, если волны физически влияют на лодку игрока, тогда ты обязан ставить воду на паузу; если облака влияют на решение головоломки, они обязаны замирать вместе со всем миром; если светлячки указывают игроку путь, они не должны улетать за край экрана во время паузы.
>>893886
>ноды неправильно работают с этим
В 99% случаев это не баг, а твоё непонимание.
В 1% случаев иди на гитхаб и ищи issue с багом.
>панель не анпаузится
pause_mode == process заставляет ноду работать независимо от состояния паузы:
>PAUSE_MODE_PROCESS = 2 --- Continue to process regardless of the SceneTree pause state.
Т.е. твоё меню паузы будет существовать и работать даже если игра не стоит на паузе. Следовательно, у тебя там какая-то другая проблема в коде. Может быть, ты где-то в своём коде сделал set_process(false) у ноды меню и забыл об этом?
https://docs.godotengine.org/en/3.5/classes/class_node.html#class-node-method-set-process
>Звучит не очень эффективно
Это был сарказм через утрирование.
>GDScript
>Он ещё медленнее же
Ну, давай на ассемблере писать игры. Это как раз то, что называют преждевременной оптимизацией. Вместо разработки игры ты заботишься о скорости выполнения кода, который ты, скорее всего, вообще выбросишь из проекта на каком-то этапе.
GDScript адаптирован под скорость написания кода, который можно безболезненно выбросить или, при необходимости, переписать на C++ ради скорости выполнения. Сначала делаешь игру, потом ищешь наиболее тяжёлые по скорости вычислений места и переписываешь их другим инструментом.
Те же операторные скобки только мешают, когда тебе необходимо высрать 1500 строк кода за час и потом удалить больше половины.
Взять хотя бы for:
>for (int x = 0; x < parent.gameMap.width; x++) {
>_ for (int y = 0; y < parent.gameMap.height; y++) { ... }}
На GDScript проще и для записи, и для чтения:
>for x in parent.game_map.width:
>_ for y in parent.game_map.height:
Какой смысл в первой записи по сравнению со второй, если тебе нужно просто пробежаться по всем ячейкам карты? Ты не будешь начинать не с 0, не будешь перескакивать через несколько ячеек, не будешь делать какую-то сложную проверку вместо проверки на достижение конца строки или столбца. И отступы ты в любом случае добавишь для читабельности кода. Круглые скобки тут вообще не нужны, просто C-подобный синтаксис слишком перегружен.
Ну да, медленнее выполняется. Но ты скорее всего не на пентиуме начала 00-х сидишь, и тебя сейчас скорость выполнения кода не должна волновать. Сделай сначала игру, а код оптимизировать можно сто раз даже после релиза. Люди давно привыкли покупать новый компьютер для новых игр, и не ценят по достоинству высокую производительность кода в играх. А вот что они ценят - это интересный геймплей, обилие контента и частые обновления контента с фиксом багов. Поэтому так популярны скриптовые языки в игровых движках, и поэтому скриптовые языки адаптированы на читабельность и модифицируемость кода, а не на скорость выполнения. Если ты отказываешься от скриптового языка, ты сам себя замедляешь, оттягивая релиз игры и усложняя процесс доработки игры после релиза. Потому что переписать уже существующую систему на другой язык намного проще, чем изобретать несуществующую систему с нуля, особенно если язык не адаптирован под скоростную разработку.
Я не то чтобы испытываю невероятные сложности со скоростью написания на с#, учитывая что я на работе пишу на с++. Чаще возникают проблемы с тем что писать, а не с тем, что мясистые пальцы не поспевают за стрелой мысли.
операторные скобки не мешают, а наоборот только помогают видеть код быстрее более структурированным
Моё оправдание это то, что я психически больной. Но я делаю игру, я доведу 1 игру до коммерческого релиза, даже если этот релиз будет приносить 1 рубль в год.
>>893869
Аригато, пацаны
>>893869
>Кринжанул
Ну смотри. Условный Вася любит поиграть в игры, но так вообще работает на работе, и если игры из его жизни убрать, в целом ничего особо не изменится - "баловство". Не условный Виталик играет в игры, снимает видео про игры, зарабатывает этим всем на жизнь; невозможно убрать игры из его жизни, не порушив эту самую жизнь - "профессия".
Определение профессии - человек занимается чем-то на постоянной основе, и это является основной статьёй его заработка. А уж кто, чем и с каким качеством, в этом определении не учитывается.
И вообще, понимаю твой кринж, но я на анонимной борде, и мне насрать :3
>>893919
>Делать игры вам мешает не язык/движок/арт/шизы с харкача, а ваша прокрастинация. Все остальное - гнилые отмазки.
Вот я хоть и согласен, ты правильно говоришь, но заебал. Пару раз это выглядело как правда-матка, но в стопицотый - уже шиза. Сам иди игры делай, а не пости одно и то же.
>>893900
>ожидаешь на каждом шагу game-breaking bug
Я тут поиграл в Jagged Alliance 1. Великая классика из 90х, ещё под ДОС. Пошаговая тактика: ходишь ты, потом ходит комп, ну и так далее. И там совершенно эпичный финал, когда главзлодей самоубивается во взрывах, и всё начинает взрываться. Задача игрока - спасти сюжетный макгаффин из ящика злодея и эвакуироваться с минимальными потерями. Вот только взрывы реалтаймовые. То есть, мы ходим в пошаге; взрывы взрываются когда хотят.
Психотравма, говоришь? Ну да, сорт оф.
>ждут, пока ты не закончишь диалог с каким-либо персонажем.
С диалогами есть альтернативный вариант реализации - ничего не паузить, но дать возможность прервать диалог в любой момент. ИМХО это честнее; а важные сюжетные разговоры устраивать только в безопасных местах.
>анимации здесь служат исключительно эстетическую роль
Если очень нужно, чтобы обязательно что-то мельтешило (вообще да, согласен, нужно), то лучше пусть интерфейс мельтешит.
Но в общем-то это такая вкусовщина. Я предпочитаю, чтобы пауза всем своим видом однозначно говорила: "игра замерла, ты в безопасности, можешь спокойно читать окошко или пойти отлить", и какой-нибудь шейдер, продолжающий анимироваться, воспринимается мной как недоработка. Но у меня нет доводов в пользу этого, кроме "мне так больше нравится".
Я тебя еще не так заебу. Иди делай игры, блять. Делай-делай. Приду проверю потом, чтоб сделал все. Хватит яйца мять.
> Ой всё.
> если я сейчас вместо маленьких успехов ведущих к игре буду пытаться сделать всё идеально
Это вопрос внутренней дисциплины.
ИМХОИМХО
Нет ничего сложного, чтобы ебануть энум с подливой под себя и в дальнейшем брать оттуда константы:
> enum BallColor { None=-1, Black, Gray, White, LightSalmon}
И что характерно, попытки в самоорганизацию есть, далее по пикче есть следы использования энумов.
То есть, анон знает о них, но всё равно ленив и расхлябан, что позволяет себе магические числа в коде, оправдываясь тем, что когда-нибудь сядет и всё отрефакторит. Ага. Да-да.
>enum BallColor { None=-1, Black, Gray, White, LightSalmon}
Тогда уж ему нужно
>enum FogState { Visible = -1, Known, Unknown }
Visible - клетки в поле видимости;
Known - клетки, которые игрок видел ранее;
Unknown - клетки, которые игрок никогда не видел.
Чтоб абстрагироваться от визуализации.
>С диалогами есть альтернативный вариант реализации - ничего не паузить, но дать возможность прервать диалог в любой момент.
Идеальный вариант - это чат, такой же, как в мультиплеерных играх. Реализовать сложнее, но преимущества перевешивают недостатки.
Написал длинное сообщение с описанием всех преимуществ и недостатков каждого подхода, но случайно закрыл браузер и всё потерял. Лень повторять.
Вроде есть revenue share программа и выплаты от 100 баксов. С РФ сам понимаешь.
Мне в основном нужны структурированные отзывы, а то на итче их хуй дождешься, и трафик на мобильные аппсторы. Что NG мне и дал.
Как заработаю с игры, так и смогу оплатить психолога. А сейчас я нищук.
А то как-то на каждую кнопку по сигналу жирно выходит. Там не красивый копипаст получится.
Короче я решил просто из vbox'а с кнопками стрелять сигналом. Но может ещё как-то можно?
покажи конкретнее кусок, что и где у тебя не крутится или поясни более нагляднее желаемый результат
представь себе спрайт со свастоном
мне нужно заставить крутиться этот свастон по часовой стрелке
ну вот ставишь Sprite2D или 3D в зависимости от игры и крутишь ноду со свастоном
>А то как-то на каждую кнопку по сигналу жирно выходит. Там не красивый копипаст получится.
Можешь циклом по всем кнопкам пройтись и подключить. Я так делаю. Тогда всего 2 строки.
Все три кнопки сажаешь на один сигнал. Или я непонел, что именно ты хочешь.
Значит создай меш, в него установи плейн, отключи куллинг бэкфейса, и собсна крути как хочешь.
>собсна крути как хочешь
Я так и делаю, но думал чёт из коробки пропустил мб, заебно всё время плейн в камеру поворачивать.
> заебно всё время плейн в камеру поворачивать
Э, в смысле всё время? Один раз код поворота написал и не трогаешь.
>в смысле всё время?
ну дрочить в процессе векторы трансформа камеры, чтобы плейн к ней повернуть
Ты мой пост читал вообще? Продрочи векторы один раз и код будет just work, что с тобой не так?
Технически то ты никак не можешь избавиться от "одна кнопка - один сигнал", ведь источником сигналов являются разные кнопки. Ну а принимать можешь в одном месте, да. В коннекте можно указать в параметрах от кого сигнал.
>спрайт в 3д в биллборд режиме с возможностью этот спрайт крутить по своей оси?
Это?
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-billboard-mode
>>894122
>отключи куллинг бэкфейса
Зачем, если билборд всегда в камеру смотрит?
>>894150
>Ага, каждый тик
А встроенный билборд как часто крутится?
Выбери режим BILLBOARD_ENABLED, конвертируй стандартный материал в шейдер, изучи его код и доделай ему вращение по нужной оси (z?).
>просто так
>отправляет массив вместе с сигналом
>данные посланные с сигналом
>копипаст получится
RTFM, чтобы не задавать глупых вопросов.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
>Выбери режим BILLBOARD_ENABLED, конвертируй стандартный материал в шейдер, изучи его код и доделай ему вращение по нужной оси (z?).
Это кстати может и получше будет постоянного поворота трансформных базисов камеры в процессе. Спс, попробую.
Сколько у тебя таких билбордов? 100? 10000? Ты делал бенчмарки или просто занимаешься предварительной оптимизацией?
>занимаешься предварительной оптимизацией?
)))а чё для себя низя чёль?)))
Иногда сам руками, иногда готовое. В любом случае если ты берешь/делаешь что-то графически сложное, то ты, за крайне редким исключением, уже провалился.
>Я имею право поставить его на иконку?
Смотри лицензию ассетов.
Я рисую сам. Рисовать не умею правда, но другого пути нет. Повезло, что у меня не ретро пиксель арт. Я вообще хз как его рисовать. Когда делал на пикселях, там подрезал из интернетов всё и чуть менял под себя.
>opengameart
Просто без задней мысли скачиваешь ассеты/спрайты и всё? Ничего не прилетит?
>Ничего не прилетит?
ПРОСТО смотришь, чтобы в лицензии не было NC. Если BY, то записываешь ник автора в титры. А в целом так-то похуй.
Делай минималистичную в Блокбенче если 3д, или в аспрайте если 2д
> Повезло, что у меня не ретро пиксель арт. Я вообще хз как его рисовать
Так он же в разы проще всего остального рисуется.
В связи с юридическим аспектом нужно сделать так чтобы пользователь распаковал файлы оригинальной игры и сунул в папку с exe моего переноса, пока прикидывал просто выдирал файлы и совал в проект настраивая всё, сейчас понял что я лучше сейчас переделаю малый объём работы, чем буду всё переделывать на такую формулу в последний момент.
Встал вопрос - как использовать файлы из одной папки с исполняемым файлом не используя скрипты и никак не упаковывая эти файлы? Желательно, но не обязательно чтобы их было видно в редакторе.
Да вот видимо придётся. А то есть шанс пожалеть потом. Я рисковать не стану.
Кодом никогда в жизни не занимался, поэтому не понимаю даже как его начать, то что означает иф и елс понятно, но как из них получить что-то полноценное понятия не имею. Каким образом вы научились работать с буковками? Ибо просто тыря код, я далеко не уйду и врятли научусь
> просто тыря код, я далеко не уйду и врятли научусь
Это так, даже если берёшь с гайдов, лучше переписывай ручками, желательно стараясь понять что там написано. Конкретно тут сходу видно что код под третий годот, а ты скорее всего скачал четвёртый. Надо не onready, а @onready.
onready var ray = $RayCast2D TO onready var ray = get_node("/root/Area2D/RayCast2D")
А, да кстати, возможно банально код для третьего годота в четвёртом.
О. Здорова братан. Я тоже с рпгма. Но я делаю без клеток так что у меня таких проблем нет. Как и сказали аноны выше, у тебя годота версия новее. А вообще советую прям сходу посмотреть гайд "Make an Action RPG in Godot 3.2". Там базис и основа, хоть и под другую версию (мне это не помешало). Ну а дальше по запросам в гугле и итт.
Добавил собачку и ща ругается что инпуты и тайл сайзы не в зоне видимости, но эт думаю пока сам попробую решить, спасибо в любом случае!
>>894342
Оо, супер, щас тогда и погляжу. Может еще по каким-то урокам учишься?
>Может еще по каким-то урокам учишься?
Есть какие-то видео, но они специфические. Ты сам их запросто нагуглишь если придётся искать, например, как работать с кастомными ресурсами. Обучение, и программирование в частности - это 90% времени решение возникающих проблем. По этому я дальше стал просто под себя писать то, что мне нужно. Всё что не знаю гуглю или спрашиваю здесь. Сам понимаешь опыта в программировании у меня только с рпгма. Но тут практически тоже само и даже легче в некоторых аспектах. Например практически нет ограничений родного кода. Всё пиши как хочешь. Как напишешь, так и будет. Я в рпгме заебался во круг него прыгать с плагинами да остальными ограничениями и по этому, пока что, с годотом работь очень приятно после рпгма.
Ну... Мне придётся так всё подгружать, не цеплять-же мне ко всему скрипты только для подгрузки графики?
https://docs.godotengine.org/en/3.5/tutorials/export/exporting_pcks.html
https://github.com/GodotModding/godot-mod-loader
Это глянь. Не знаю отвечает ли они твоим требованиям, просто мимопроходил.
Рейкаст возвращает нормаль.
Вот ее плюсуй к координате спавнящегося куба домножив на половину стороны куба.
Должно проканать.
Не ебаться с у-сортами и слоями, халявные тени, отражения, окружения, свет, глубина сцен, ю нейм ит. Сам делаю.
> Хочу сделать передвижение по карте по клеточкам
> В гайде чел через РейКаст2Д
для ходьбы по клеточкам вообще не нужен рейкаст, ты просто проверяешь свой массив карты на тему проходима клетка или нет, всё
Я сижу на 3.5 и жду 3.6, потом буду ждать 4.х - где Х выше 5. Тройка под веб лучше работает и физика менее сломана. Но в 4 фичи вкусные пиздец.
Разве 3.6 будет? 3.5 же ЛТС. И почему 4.7+ будут на твой вкус? Минорные версии означают номер порядковый номер релиза в мажорной версии же, или у годота свой путь?
3.6 будет, уже третья бета есть: https://godotengine.org/article/dev-snapshot-godot-3-6-beta-3/
Предполагается что 3.6 будет последней версией в третьей ветке.
В четверке мне просто стабильности не хватает. Фичи хороши.
> В четверке мне просто стабильности не хватает
а что там? вроде сейчас пилим два проекта: один в 2d другой в 3d и каких-то проблем не было, еще с беток годота четвертого начинали
Честно говоря вопрос не так прост как кажется. Если зоны2д однотипные, скажем сферы или квадраты, то можно просто проверить в цикле distance_to_squared. А если нет, то что делать хз. Какой тогда критерий, зона у которой любая вершина, любой угол ближе? Или какой-то центр масс? Читал в одном месте, что можно использовать AStar для такого, видимо, наполнить массив координатами вершин и искать чем-то подобным волновому алгоритму.
Например 3д физика. В трешке был Буллет, в четвертом его выкинули и заменили на Godot Physics. На полпути чувака, который его пилил на зарплате от Годот Фаундейшн, спиздили Рокстары. Итог такой себе. Сейчас в рамках отдельного проекта пилится Jolt, который, например, использовался в Хорайзоне. Как я понимаю планируется мердж в основную ветку когда допилят.
>халявные
Не такие халявные, влегкую может оказаться что надо ебаться в 10х по сравнению с 2д. Тени для плавной смены времени дня я так и не осилил, например. А если статичные тени, то с запеканием были проблемы, не знаю сейчас уже поправили или нет. В общем у меня есть долгострой 3д и там много возни, а вот 2д пиксельное легко пилю одну за другой.
Сколько месяцев/лет прошло, пока до вас не дошло что за свою жизнь вы успеете всего десяток полноценных проектов сделать, и то если повезет, а потом все, гроб гроб кладбище? И пиздец как важно выбирать не хуйню в этот жалкий десяток.
Это ещё если гейдев это основная профессия и ты уже серьезно настроился до гроба игры делать. А если ты фанат пивандеполы который зашел почилить в годот после работы? Дай бог одна нормальная игра за 10 лет изучения движка.
Ну у нас там конечно не какая-то мега крутая физика, чтобы волосы развевались, но с обычной физикой проблем не наблюдали каких-то
а зачем туториалы, когда есть документация и мы тут еще сидим не просто так
Это не флажки, это массив. Зачем тебе room_index и четыре константы? Если отображаемые кнопки по сути есть двоичное представление номера комнаты, то почему бы не
buttonX.visible = room_number & (1 << X)
buttonY.visible = room_number & (1 << Y)
buttonZ.visible = room_number & (1 << Z)
>это массив
Ну допустим, а мне говорит, что int.
>Зачем тебе room_index и четыре константы?
Да это я так просто потупил немного. По сути там только @export в тему, остальное - полёт фантазии.
>Если отображаемые кнопки по сути есть двоичное представление номера комнаты
Там всё немного не так. Но по сути кнопка должна отображаться в комнатах A, B, C, но не D. Или только в A, C. Вот какую систему я хочу сделать. Сейчас уже думаю просто сделать массив имён комнат и там проверять всё это.
Ещё у тебя есть вариант сделать массив флагов тогда, где индекс - номер комнаты и использовать >>894603 с небольшой модификацией room_array[room_number] вместо room_number Тогда например с массивом [1, 3, 4] у тебя отобразятся в первой первая кнопка, во второй первая и вторая, в третьей только третья
Понятно. Спасибо. А вот вообще есть способ узнать какие именно флажки активированы? То есть я то понимаю, что например если enum {a:1, b:2, c:4, d:8} равен = 3, то значит a и b активны, но как бы это каким-то алгоритмом определить.
Анончик, ты опять перепутал. Енам - есть по сути перечисление разных значений, в твоём случае интов. Флажки - определённый бит в инте. Определяется есть ли флажок или нет вот так >>894603 смещением единицы на столько разрядов, какой у тебя флажок. Почитай про битовые операции, например вот эту статью https://metanit.com/cpp/tutorial/2.8.php там хоть и для плюсов, но принцип во всех языках один
А бляпиздец. Лол. Вот что значит нихуя не программист. Спасибо что объяснил. Пизда рулю я чуть не упустил это знание.
> Пизда рулю я чуть не упустил это знание.
Когда впервые узнаёшь о битовых флагах - это такой кайф, на пару месяцев становишься байтоёбом и пихаешь флаги всюду. Я так пару лет назад когда узнал о флагах, пытался на них сделать составную стейтмашину. Что-то получалось, но функционал мне не удалось сделать более удобным или быстрым, чем просто стейт-машины.
>как использовать файлы из одной папки с исполняемым файлом
https://stackoverflow.com/questions/75187804/how-to-get-acces-to-file-in-the-same-folder-of-the-game-godot-engine
>не используя скрипты
WTF? Тебе шашечки или ехать? Пиши код давай, пиши.
>просто выдирал файлы и совал в проект
>чтобы их было видно в редакторе
Ты не против выложить исходники своей игры в опенсурс, чтобы игрок мог их модифицировать? Тогда просто забудь про "экспорт" игры. Просто положи Godot в папку проекта и запакуй эту папку в zip. Выкладываешь zip, игрок качает и распаковывает, закидывает в папку файлы игры и кликает на твою игру.exe, которая на самом деле Godot Editor или export template (на выбор, есть существенные отличия). Если ничего не путаю, Godot в таком случае сразу запускает игру, не заходя в режим редактирования. Ещё можно сделать специальный ярлык, по нажатию на который проект будет сразу запускаться на выполнение редактором Godot.
Преимущества: игрок имеет доступ к файлам и может их использовать на своё усмотрение, а тебе не нужно делать обходные пути для загрузки файлов.
>когда надо подключать графику мотивации никакой, всё же уже работает
У меня наоборот. Я не могу себя заставить делать прототип игры, если у меня нет готовой приятной графики. Но сам я не художник и сделать приятную графику не могу, а в интернете приятной графики нет.
>>894260
>Делай минималистичную в Блокбенче
Она некрасивая получается. Дурацкий кубач...
> Я не могу себя заставить делать прототип игры, если у меня нет готовой приятной графики.
Тебе надо в моддинг скайрима вкатываться, там как раз то самое и будет.
>Тени для плавной смены времени дня я так и не осилил
Что конкретно не получается?
Просто размещаешь в сцене вот это:
https://docs.godotengine.org/en/stable/classes/class_directionallight3d.html
И вращаешь вокруг одной оси по таймеру.
Если у тебя время в игре долгое относительно реального времени (сутки за 24-48 минут и дольше), тогда ты можешь позволить себе долгие паузы между поворотами источника света, чтобы сэкономить на обновлении теней и неба. На самом деле, в играх типа GTA можно заметить движение теней рывками, но в нормальном геймплее на такие мелочи внимание не обращаешь - нужно стоять на месте и внимательно следить за тенью, чтобы заметить. Если у тебя проблемы с "протеканием" света через щели, тени отстают от предметов, или есть какие-то другие артефакты - нужно подгонять параметры источника света.
>Она некрасивая получается. Дурацкий кубач...
Прокачивай стиль.
>Что конкретно не получается?
Тени полосами на домики ложаться.
>Тени полосами на домики ложаться.
Знакомо. Связано с особенностью алгоритма теней, который используется в Godot. Уже обсуждали здесь в прошлые годы. Можно исправить через параметры в источниках света и настройках проекта. Значения по умолчанию не под любую сцену подходят.
https://docs.godotengine.org/en/stable/classes/class_light3d.html#class-light3d-property-shadow-bias
И дальше по списку.
У меня эти артефакты в SpotLight чаще всего были, DirectionalLight сравнительно беспроблемный.
я где-то читал, что одни настройки лучше подходят для теней падающих на вертикальные стены, а какие-то - на горизонтальные полы. А в опенворлде с динамическим временем получается засада, надо и те и те, и они сменяют друг друга. На статичной то сцене еще можно попытаться подобрать хорошие настройки, а там было буквально, починил тень на домике - полосит асфальт. В общем пока забил я.
Мне кажется, с домами тени лучше всего работают с shadow_reverse_cull_face = true.
Но я не помню точно, а видео с подобной демонстрацией таких моментов я не делал. Тем более что в 4.x рендеринг другой совсем.
Вообще, я бы забил, тени в играх не так важны, в какой-нибудь ГТА тени вообще отключаются в настройках для повышения производительности.
Можно ли такой ассет использовать в коммерческой игре? Если чел не указал лицензию конкретно, но написал своими словами, что бесплатно.
Скорее всего это что-то вроде WTFPL. Если ассет прям узнаваемый - можешь в кредитах указать его. Иначе хуй забей. У меня две коммерческих игры, внутри которых, среди моих собственных ассетов, валяется пара чужих с похожей на твою проблему. Всем похуй.
Не узнаваемый, у него буквально 10 просмотров и 0 комментариев на итче. Просто красивый спрайт чел нарисовал.
Спасибо за ответ.
Можно, но я б не стал.
Тем более если ты пишешь это просто спрайт. Перерисуй похоже и все.
Проблемы могут возникнуть, только если он сам (или его представитель) подаст на тебя в суд или напишет DMCA заявку в магазины/хостинги с твоей игрой. Посторонние люди в данной ситуации никак повлиять на тебя не могут, игры удаляют только по заявке правообладателя (в целом по интернету; у стима может быть своё мнение). Вот именно тогда ты должен гордо показать бумажку и ткнуть пальцем в строчку, которая утверждает, что ты всё используешь легально, а он может попытаться доказать, что ты подделал бумажку и он ничего такого не писал. В твоём случае роль бумажки выполняет страничка в интернете, над которой он имеет полный контроль, поэтому стоит сделать бэкап его странички в Wayback Machine и других веб-архивах (можно запросить удаление архивной копии сайта у владельцев архива). Но тут важен именно сторонний архив, т.к. на своём диске ты можешь и подделку сохранить, так что личная копия ничего не даёт.
Это серьёзная тема. Если игра внезапно выстрелит и принесёт миллионы, этот рандомный чувак может заявиться и отсудить круглую сумму просто за то, что у тебя там его файл в запакованном архиве лежит, нигде не используясь. Были случаи.
Вот Godot использовать безопасно, потому что это широко известный проект, доказательств его бесплатности и открытости полно.
Я в ахуе просто. Зачем он его тогда выкладывал бесплатно на сайт с бесплатными ассетами?
Хочу сымитировать импульс:
player.velocity += velocity_new
Проблема в контроллере у player, где velocity приравнивается:
if direction:
velocity.x = direction.x SPEED
velocity.z = direction.z SPEED
else:
velocity.x = move_toward(velocity.x, 0, SPEED)
velocity.z = move_toward(velocity.z, 0, SPEED)
Для того же, для чего и другие. Почесать свое ЧСВ, показать свой скилл, потренироваться, приобщиться, получить лойсы, привлечь внимание к своему аккаунту и к другим своим проектам. Я тоже выкладываю. Но у меня лицензия четко указана.
Ну вот представь, открываешь ты какой-нибудь гугл плей и видишь свой бесплатный ассет на иконке, рядом надпись - 10000 скачиваний. Твои действия?
>видишь свой бесплатный ассет
Я если что-то бесплатно выкладываю, то всегда явно указываю либо CC BY SA (если медиа), либо GPL/LGPL (если софт). Так что, если увижу 10000 скачиваний, то порадуюсь, ведь там где-то мои копирайты.
мимо
https://docs.godotengine.org/en/stable/classes/class_textserver.html#enum-textserver-autowrapmode
>>894853
То есть https://docs.godotengine.org/en/stable/classes/class_label.html#class-label-property-autowrap-mode
Тру стори. Точно так же закончился и мой вкат в геймдев. Сижу теперь ИТТ, по привычке. Кстати вот тебе тема для размышлений: на годоте можно не только игоры делать. Вон чуваки сделали графический редактор для пиксельарта, Pixelorama. Так что, думой.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#common-use-case-scenarios
Viewport
Спасибо!
Жаль в оф доке нет отдельных мини-инструкций, типа user stroy под самые распространенные проекты, с сылками на нужные разделы
Ты изменяешь не ребёнку, а родителю. Ну и ты уверен что ты получаешь и попадаешь в этот цикл?
>Ты изменяешь не ребёнку, а родителю.
Сорян, что не пояснил, что так и нужно. Блять, я там вообще не то написал. Совсем уже голова не соображает. Всмысле я смотрю если у ребёнка чек стоит, то вырубаю родителя. Мне вот так нужно.
>Ну и ты уверен что ты получаешь и попадаешь в этот цикл?
Ну как бы я просто ребёнку в редакторе чек включал, тогда он вырубает родителя как нужно.
А. У меня же ещё там переход между сценами. Я так понимаю при смене сцены параметры не сохраняются? Ну типа я чекнул кнопку, перешёл в другую сцену, потом вернулся обратно и оно не сохранилось чтоль? А как тогда сохранять?
Чёт всё ещё не очень понятно что у тебя происходит, но в любом случае ты можешь эту проверку на "parent.visible = not button.is_pressed()"
>>895113
Берёшь и пишешь в нужное место, например в глобальную переменную или ещё какое хранилище нужное состояние, и в реди каждый раз ставишь кнопкам нужное.
Вообще я не понимаю что ты делаешь, у тебя кноки или чекбоксы? У кнопки нет checked, а у чекбокса он отвечает за текстуру. Проверять включен чекбокс или нет надо через is_pressed()
Спасибо за помощь. Я понял, что обосрался с сохранением. При переходе из одной сцены в другую в прошлой сцене всё на дефолт прыгает. Буду думать как лучше сохранять всё.
>Вообще я не понимаю что ты делаешь, у тебя кноки или чекбоксы? У кнопки нет checked, а у чекбокса он отвечает за текстуру.
Да это свой кастомный параметр на кнопке. Обычная кнопка.
Если простая кнопка, то почему бы не добавить выключение видимости на нажатие этой кнопки?
Там в зависимости от комнаты свои кнопки в каждой. При переходе в комнату идёт проверка какие кнопки показывать. На реди идёт дрочь с визиблами жёсткий. Этот самый checked как раз и нужен чтоб не показывать кнопку если на неё хоть раз нажимали. Соррян, что криво объясняю я просто сижу сейчас как овощь ничего не соображаю. День не удачный.
Ну так храни для каждой комнаты переменную, массив или словарь, в котором ты будешь отмечать кого рисовать, а кого нет. Меняй его по нажатию в функции обработки нажатия, назначай его при переходе в комнату, выгружай в удобное тебе хранилище при переходе из неё. Кнопкам тогда не нужно хранить статус своей девственности.
При использовании вьюпорт + кип спрайт дергается придвижении по диагонали. При канвас итем + кип есть периодические поддергивания при горизонтальном/вертикальном движении
Делаю top down игру. Так понимаю в четвертой части velocity по дефолту учтен в move_and_slide, как и delta. Норм такой код, ничего не упустил в базовых аспектах?
Давно есть фукнкция которая сразу возвращает нормализованный вектор и учитывает дедзоны
Input.get_vector("left", "right", "up", "down")
- Вид сверху
- Движение по 8 направлениями (право, лево, верх, низ + диагонали)
- Анимация передвижения в 2 стороны
Проблема:
При передвижении вправо/влево и по диагоналям все ок.
Но если персонаж двигается только по оси y, то спрайт исчезает
Т.е. я хочу 8 направлений движения, 2 направления спрайта, как в nuclear throne https://youtu.be/_-P3DnjiuSw?si=DoFKbbmYEOowGe1v
Код:
#func Animated_player(input_vector):
#if input_vector != Vector2.ZERO:
#Player_sprite.scale.x = sign(input_vector.x)
#Player_animation.play("Walk")
#else:
#Player_animation.play("Idle")
Возможное решение:
Пока в голову приходит идея разве что использовать доп переменную, куда буду записывать последнее значение вектора по оси x, и использовать ее значение, перезаписывая, только при возобновлении движения по оси x.
Но может есть более лаконичное решение?
Естественно исчезает, ты же в таком случае присваиваешь scale = 0.
дык это ясно
Проблему таки решил лаконично по крайней мере лаконичнее, чем через доп переменную
>>895180
func Animated_player(input_vector):
if input_vector.x != 0:
Player_sprite.scale.x = sign(input_vector.x)
Player_animation.play("Walk")
elif input_vector.x == 0 and input_vector.y !=0:
Player_animation.play("Walk")
else:
Player_animation.play("Idle")
> чем через доп переменную
> if input_vector.x != 0
> elif input_vector.x == 0
> else:
Перестань мыслить переменными, начни мыслить стейтмашинами. В стейтмашине у тебя не потребуется вообще делать дополнительные проверки, или вводить дополнительные переменные.
Вот, читани базу. Если не можешь в инглиш - переводчики на любой вкус.
https://gameprogrammingpatterns.com/state.html
Установи годот через scoop и тогда у тебя будет одно единственное, обновляющеееся приложение по пути %username%/scoop/apps/godot/current
И тогда фаервол не будет срать себе в правила разными версиями godot_version.exe
Вот тебе один маленький скриншот с официального сайта скупа, со страницы с букетами. Знакомых ников не видишь?
Двачую, один хуй через полгода венда засрётся и придёт время переустанавливать.
да десятка годами стоит, проблем нет, если вот ее не засирать всякие типа как на скринах
Подъебал-подъебал.
TL;DR: Мокрописечка на скринах устанавливает портативные приложения, в том числе она принудительно делает портативными непортативные.
А теперь в подробностях:
Мокрописечка на скринах устанавливается локально для юзера, как скрипт помершелла. На других юзеров и на систему влияния не оказывает (в конфиге по умолчанию не оказывает, а если юзер достаточно умён чтобы залезть в конфиг scoop'а, то в любом случае уже он несет ответ за свои действия). Если вдруг тревожному юзеру показалось, что scoop засрал ему систему, он в общем случае просто заводит новую учётку, перекидывает туда конфиг браузера с паролями и просто без задней мысли сносит старую учётку. И всё. В системе не остаётся никаких следов scoop и приложух, установленных им.
У этого приложения есть недостатки, но в вопросе установки годота там недостатков нет. Установка максимально приближена к линуксу:
1. scoop install godot
2. godot
И всё! Редактор запускается.
Что "зачем"? Каждая новая версия (3.5, 3.5.2, и т.д) показывала свое окошко фаервола и добавляла правило.
Мотивации игры делать не хватает. Но я все равно через силу открываю годот просто чтобы рука сама потянулась что-то сделать.
> Игры делайте.
Я хочу делать аддоны годота. Посоветуйте, какой бы сделать? Чего вам не хватает для пущего удобства, годаны? Оставляйте заявки ИТТ.
Для шарпа есть мскоде, который в одиночку никто не догонит. И вот в мскоде уже есть интеграция годота. Так что нинужон. Еще предложения?
При комментировании одной линии через хоткей нужен переход на строку ниже. Так во многих редакторах. А в годотю не везут.
Год назад был такой прототип, но скорее всего автор не доделал.
За ночь уже 76 накапало. К сожалению, мне кажется на этом доходы резко пойдут вниз.
Все так. Первая неделя-полторы самые заметные, если тебя потом ВНЕЗАПНО не заревьюит какой-нибудь блоггер.
Но начало хорошее. На какую платформу выложил?
Я надеюсь ты понимаешь, что это не шутка и не игривое преуменьшение, это не 36к, это реально 36 копеек
На запретную платформу с последней буквой алфавита в названии.
> с последней буквой алфавита в названии
>это реально 36 копеек
Я надеюсь ты понимаешь что это уже круче чем большинство ноудевов из /gd когда-либо сможет достичь. Продолжай работать.
А почему кто-то должен считать это шуткой?
Ты выложил на не особо популярной платформе, наверняка даже в рекламу не вкладывался, да и игра скорее всего слеплена за пару недель и не какой-то шедевр.
Я за два года заработал 73$. А там вывод на площадке от 150. То есть через 2,5 года у меня будет первая зарплата. Такие дела лол.
> вопросе установки годота
чел, скачал exe нужный с сайта, запустил его
> чел
Амёб, следи за дискассом, тот пост является решением проблемы длинного списка одинаковых правил в брандмауэре. потому что каждый
> exe нужный с сайта
Будет регистрироваться там отдельно при первом запуске.
А при установке через scoop экзешник всегда будет один, но будет меняться, следовательно и правило брандмауэра будет одно. И это один из минусов искаробочного брандмауэра. Сторонние фаерволы контрольные суммы хотя бы сверяют, а этому всё похуй. Ебёшь-ебёшь, а хуй-то выпал!
Хочу зделоть свою вайфу в виде приложения на смартфон на данном движке, какие подводные? Четвёрка всё ещё умеет экономить батарейку или будет сжирать 100% за 6 часов на простейшей 2Д графике как печально известная юнити? Можно ли из коробки создать фоновый процесс (работает даже если закрыть игру) и выдавать системные оповещения (сверху, под шторкой) по таймеру? Или придётся ковырять компиляцию C++, чтобы реализовать подобные фичи?
Алсо, кто-нибудь уже разобрался, как сделать 2Д анимации в стиле Live2D? Как-то сложно всё.
>Пришло время почистить правила фаервола
Зачем? Они тебе чем-то мешают? Зачем ты вообще в фаервол лезешь?
>>895332
>через полгода венда засрётся и придёт время переустанавливать
Лично у меня за 16+ лет использования начиная с XP необходимость в переустановке возникала только когда я своими шаловливыми ручками вырывал из системы какой-нибудь жизненно важный модуль и не мог восстановить его штатными средствами или копированием файлов с живой системы/образа. Ну ты понял, люблю залезть туда, куда нельзя, и переключить/вырезать/удалить то, на что не стоит даже смотреть, а потом забываю, куда залез и что сделал и почему система еле дышит. В остальном система работает как часы даже с серьёзными повреждениями, в отличие от кернел паник симулятора, ЕВПОЧЯ.
>>895476
>является решением проблемы длинного списка одинаковых правил в брандмауэре
Не смотри в этот список и не будет проблемы.
>один из минусов искаробочного брандмауэра
А он тебе вообще нужен? Ты за корпоративным компьютером сидишь и вирусы скачиваешь? Просто не запускай в основной системе левые программы. И вообще, этим твой сисадмин должен заниматься.
>при установке через scoop экзешник всегда будет один
>контрольные суммы хотя бы сверяют
Так ведь у тебя scoop один и тот же, контрольная сумма у него поменяется только при обновлении...
Алсо, а если мне нужны разные версии Godot? У меня даже до выпуска 4.0 было несколько версий в одной папке, все подписаны разными именами и имеют индивидуальные ярлыки. Мне не нужен один "godot.exe". У серьёзных разрабов наверняка каждая стабильная версия хранится. По этой причине я даже не пробовал что-то делать с версией из Steam, ведь она будет автоматически обновляться с заменой старой версии. Единственно верный способ использования игрового движка и любого другого подобного ПО - это раскладывать всё строго по номерам версий. Blender сечёт фишку - устанавливается в отдельную папку с номером версии (blender/x.y/, где x.y - версия), а не поверх старой версии, и старую версию ты сам можешь удалить или оставить по желанию/необходимости. Godot отдельные папки не нужны, но разные названия у разных версий следует сохранять.
>У меня же ещё там переход между сценами. Я так понимаю при смене сцены параметры не сохраняются?
ИМХО, если делаешь что-то вроде "комнат" в JRPG или метроидвании, то лучше написать свой велосипед, чем пользоваться встроенным переключением сцен. Встроенное переключение сцен больше подходит для игр типа "набор головоломок", в которых запуск уровня всегда должен быть одинаковым. Для любых других игр, где состояние "комнаты" может меняться, лучше написать свой менеджер комнат, чем обвязывать встроенный инструмент костылями.
Встроенный инструмент при переключении удаляет из памяти старую сцену, считывает новую с диска (если ещё не считал) и инстанциирует её в дерево сцены в состоянии, в котором она сохранена на диск. Если это происходит только при выборе уровня на экране уровней как в любой головоломке, то всё норм. Но если это событие происходит, когда персонаж игрока переходит из зоны в зону в большом игровом мире, то может возникнуть масса нюансов, с частью из которых ты уже столкнулся (хранение состояния героя и локации). Тебе в любом случае потребуется писать много собственного кода, но если ты завязываешь свой код на встроенное API, ты зависишь от его поведения, которое не можешь поменять без перекомпиляции движка. Если тебе вдруг потребуется что-то оптимизировать или какой-то костыль покажется слишком кривым, тебе придётся зарываться в исходники движка или переписывать всю свою систему.
Так что для большого мира из множества комнат лучше заранее написать независимую систему, не трогая встроенную фичу переключения сцен.
>Player_sprite.scale.x = sign(input_vector.x)
>Player_animation.play("Walk")
А не лучше ли перенести разворот спрайта в систему анимации, чтобы не было лишнего кода?
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html#blendspace2d
Тогда всё происходящее со спрайтом будет описано декларативно в системе анимации, а в коде будешь только передавать вектор в систему анимации.
>>895230
>мыслить стейтмашинами
>>895235
>Стейт машины это база
>>895259
>читани базу
Ты сам-то свою статью хоть раз прочитай. Там же сказано, что конечные автоматы слишком жёсткие для сложного игрового ИИ, так что не панацея.
Проблема конечных автоматов в том, что ты должен самостоятельно вручную спланировать все состояния и переходы между ними. Это рационально делать только для очень простой системы, где количество состояний не просто конечно, а обозримо. А то число возможных миров майнкрафта тоже конечно...
>Игры давайте делайте.
Мне нравится геймдев и решать простые задачки, но полноценную игру я никогда не сделаю. Слишком много всего нужно сделать - арт, звук, левелдизайн (даже для песочницы без сюжета), потом маркетинг чтобы проект не пропал на дне интернетов... а всё зачем? Ради лайков? Чёт вообще не мотивирует.
>>895359
>Мотивации игры делать не хватает.
Всё так, даже комп включить лень...
>>895361
>Я хочу делать аддоны годота. Посоветуйте, какой бы сделать? Чего вам не хватает для пущего удобства, годаны? Оставляйте заявки ИТТ.
Я бы хотел инструмент, который графически рисует все связи между файлами проекта: tscn, tres, gd и т.д. Разумеется, не все связи можно статически узнать, если ссылка на файл образуется динамически во время выполнения игры. Но большинство ссылок в проекте статические - их можно заранее узнать. Хотелось бы видеть автоматическую диаграмму-граф с файлами и связями между ними. Тогда будет легче понять, что и куда ссылается и что от проекта отвалилось в процессе разработки (изолированные "острова" файлов, на которые нет ссылок из основной массы файлов). Я хотел сделать такой аддон сам, но мотивации не хватило. По идее, там нужно всего лишь пробежаться по всем файлам, распарсить ссылки и отобразить получившийся граф.
>>895366
>При комментировании одной линии через хоткей нужен переход на строку ниже.
Зачем? А если мне нужен переход на строчку выше? Или вообще в другой файл/вкладку? Или на N>1 строк ниже? Или вообще переход не нужен? На одну строчку вниз я и сам могу нажать стрелку на клавиатуре на автомате, даже не осознавая этого. Ненавижу, когда редактор решает за меня что-то, что потом приходится отменять/исправлять. Больше всего бесят парные скобки, которые вечно не туда вставляются или съедают уже имеющиеся скобки и всё заново вручную пересчитывать приходится - кто придумал, что автоматически ставить закрывающую скобку сразу после открывающей - это что-то хорошее? А кто придумал НЕ ставить закрывающую, если закрывающая уже есть? Вот из-за таких "интеллектуальных" фич простой Блокнот лучше любой навороченной IDE, потому что Блокнот не ставит тебе палки в колёса после каждого нажатия клавиши. Вот подсветка синтаксиса, блоков кода (линеечкой слева) и т.д. - это хорошо и полезно, а такие автоматические действия невпопад НИНУЖНЫ.
в 2д
в рпгмейкере вроде даже готовый ре инвентарь уже гуглится, но я так понял заебусь делать боевку и проще уж годот курить
и что выбирать?
> Не смотри в этот список и не будет проблемы.
Не смотрю.
> А он тебе вообще нужен?
Не нужен.
> Так ведь у тебя scoop
Да, scoop у меня.
> Я бы хотел инструмент, который графически рисует все связи между файлами проекта: tscn, tres, gd и т.д.
В шапке есть.
https://godotengine.org/asset-library/asset/879
Но я заперт в РФ.
Это правда. Но я делаю игру. Просто на итче я не выведу деньги никогда.
Тебе ничего не мешает так и сделать. Вот только вывести ты 10 баксов потом не сможешь.
ты же в курсе, что у Godot уже давно свой asset store есть с кучей всего уже готового?
Я бы задал вопрос, обязательно ли на семантическом уровне слово STORE подразумевает продажу, но это вопрос для лингвача. Такшта не будем.
Ну какбэ очевидно что нет.
>asset/879
1. Он не автоматический.
2. Можно только группировать файлы и всё.
3. Я знаю о нём и пробовал. Повторяю: это не то.
>готовый инвентарь
Не ленись и сделай свой. Или выбери один из:
https://godotengine.org/asset-library/asset?filter=inventory
Но я бы сделал свой, иначе зачем игра? Просто ассеты слепить и выложить в маркет? Тьфу...
Лепить свой надо хотя бы по той причине, что инвентарь должен взаимодействовать с другими твоими элементами, а вот посмотреть как сделаны разные моменты...
> а вот посмотреть как сделаны разные моменты
О да, там бесконечное количество вариантов. Я в прошлом году плотно интересовался темой, досконально изучил вдоль и поперёк, ознакомился с различными подходами и могу сказать, что инвентарь в общем случае это КРУД, если ты пришел в геймдев из ентерпрайза, то тебе будет вдвойне легко пилить менеджмент инвентаря.
>инвентарь в общем случае это
Массив предметов.
>inventory.append(item)
>inventory.erase(item)
>inventory.sort_custom(func(a, b): return a.name > b.name)
И т.д. Как это отображать - другой вопрос.
CRUD слишком абстрактный принцип, не?
А зря. Был бы платный - я бы возможно даже покодил для годотей что-нибудь.
> Inventory.create(item)
> Inventory.read(item)
> Inventory.update(item)
> Inventory.delete(item)
> Как это отображать - другой вопрос.
Карочи, ебош интерфейс в стиле SkyUI это такой мод для скайрима. Удобнее я в жизни не видел.
Я делаю. Но тяжело. Хочется депрессию вылечить, чтобы игры больше ценить.
>Зачем ты вообще в фаервол лезешь?
Надо было и зашел, что за вопрос вообще? Настраивал порт для сервиса нужного.
>Они тебе чем-то мешают?
Хз, не замерял, возможно большое количество правил тормозит, ведь системе надо их перебирать и матчить.
>>895499
>в отличие от кернел паник симулятора
Перешел на дебиан больше года, никаких проблем, кроме первых трех дней активной настройки.
>>895476
>при установке через scoop экзешник всегда будет один, но будет меняться,
Не подходит моему воркфлоу, например я люблю делать в 3.6 бете, но для джемов я беру стейбл 3.5.2, потому что на готм.ио только последний стейбл, еще естбюь в проде проект с модулями под 3.4 и никто не будет его переводить, но контент изредка еще добавляем. Еще редко бывает надо одновременно запустить старую и новую версию даижка, чтобы сравнить поведение ассета или демки, или победить в споре в интернете.
Годо 3.5.2
Кто-то сталкивался с таким?
Внизу редактора, там где output, есть вкладка аудио. Посмотри там. Может ты на мьют поставил глобально или аудиопоток перенаправил в задницу.
Да я уж понял. Спасибо. Решил пользоваться встроенным переключением поменьше. Храню все данные в ресурсах. Пока нормально, как дойду до масштабирования, там уже посмотри.
Создаёшь лейб на экране самым верхним слоем, в процесс() меняешь текст на текущее время.
>STORE
>@
>ПРОДАВАТЬ НЕЛЬЗЯ
назвал для понятности, в оригинале там даже на скрине видно Asset Library
Не, падажи. Я не это имел ввиду. Я имел ввиду игровое время. Оно там не двигается, пока код не скажет.
Тогда в реди запускаешь таймер, и его же выводишь в процесс
Как будто есть только нубы, которые зашли месяц назад (вроде меня) и титаны, которые тут сидят 5 лет. А те кто сидят год например не показываются...
Те кто сидят год заняты деланием игр. Вопросы спрашивают нубы, отвечают на них титаны. Остальные заняты. И ты давай игры делай.
Так может просто мидловые вопросы тебе кажутся очень сложными.
Во сейчас все вебмакаки удивились
https://reactdev.ru/libs/redux/basics/Store/
>>895659
Если бы да кабы. Ты просто хвастун. Если бы умел, уже накодил бы и лутал донаты или туториалы.
Итак. 2D-персонаж собран из кусков, т.н. cutout-анимация. Анимировать было бы очень неплохо с использованием IK-цепочек. Анимации рук отдельно (под разные виды оружия), ног отдельно (под разные виды перемещения), можно независимо комбинировать. Умирая, персонаж превращается в рэгдолл и двигается по физике.
Спрашивается. Опишите в общих чертах структуру нод такого персонажа, как на ваш взгляд лучше. Ну и как бы вы выстраивали анимацию.
И да. 3.5 или 4.х? Я в четвёрке попробовал потыкать в новые ноды, которые в моём представлении должны иметь к этому всему отношение, нихуя не понял.
Другие искусства не настолько составные из чужих искусств. А тут будь специалистом по всему. Гейм дизайнером, UX/IU дизайнером, кодером, тестером, рисовакой, 3д модельщиком, аниматором, музыкантом, звуканом, сценаристом, пиарщиком, вообще охуеть.
Но большую часть этого можно просто купить или использовать бесплатные ассеты
Или сгенерить сеткой, она даже фрагменты кода подскажет как писать
Ну давай разберём по пунктам тобою написанное.
>Inventory.create(item)
Инвентарь не создаёт предметы, он их получает из внешнего мира или от системы крафта.
>Inventory.read(item)
Зачем тебе функция чтения, если тебе обычно нужен список всех предметов или конкретный предмет? Предметы не на диске хранятся, их не нужно читать.
>Inventory.update(item)
Инвентарь не должен заниматься модификацией предметов, это не его забота. Инвентарь - это просто контейнер, как рюкзак или сумка. Рюкзак не делает хранящуюся еду испорченной, она сама портится.
>Inventory.delete(item)
Такое возможно в некоторых играх, где много принципиально мусорного лута, там часто есть иконка мусорки для этого. Но в остальных случаях инвентарь должен отдавать предметы в руки герою или во внешний мир, а не просто удалять их из себя.
Плюс у игрового инвентаря ожидается множество специфичных функций, имеющих смысл только для игрового инвентаря, вроде "узнать суммарный вес" или "вывалиться из персонажа как предмет" (весь инвентарь выпадает в виде сумки).
Короч, непонятно, зачем ты сюда CRUD тянешь...
>интерфейс в стиле SkyUI
>Удобнее я в жизни не видел
Какие-то таблички, лол. Зачем игровые движки, когда подобную игру можно сделать в экселе на формулах?
>средней сложности очень мало
Щас разберём психологичненько.
Простые задачи вызывают:
- у ньюфагов апатию,
- у середнячков скуку,
- у олдфагов релаксацию.
Сложные задачи вызывают:
- у ньюфагов сильную тревогу,
- у середнячков возбуждение,
- у олдфагов состояние потока.
Средние задачи НИНУЖНЫ.
>самая вариативная форма искусства
>>895827
>другие виды искусства
>>895832
>купить или использовать бесплатные ассеты
>>895836
>Или сгенерить сеткой
Ну и в чём тогда "искусство"? В расстановке по сцене готовых бесплатных ассетов и подключении к ним готовых бесплатных скриптов? 10 искусств из 10.
>>895814
>служите Аргентине
Никто никому не служит. Движок под лицензией MIT, которая позволяет использовать исходники движка в совершенно любых целях без разглашения своих модификаций. А если ты даже делишься чем-то, ты делишься в интересах всего человечества, а не какой-то отдельной страны или народа.
>отечественное Фалько Двигло
Ты сначала выложи исходники под лицензией MIT или аналогичной, а потом поговорим. Ты ведь тоже взял за основу какое-то открытое ПО, а не целиком с нуля делал, а теперь не хочешь отдавать.
>Анимации рук отдельно (под разные виды оружия), ног отдельно (под разные виды перемещения), можно независимо комбинировать.
>Опишите в общих чертах структуру нод такого персонажа, как на ваш взгляд лучше.
А что тут описывать? Делаешь персонажа, делаешь отдельные анимации в AnimationPlayer, соединяешь анимации в AnimationTree как тебе угодно.
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html
>И да. 3.5 или 4.х?
Если хочешь за неделю слепить ассет-флип, кинуть в магазин и забыть - тогда стабильную тройку юзай.
Если планируешь несколько лет копаться с проектом мечты, тогда сразу начинай на четвёрке, потому что тройка больше развиваться не будет, а четвёрка по мере твоего копания сильно улучшится.
Свали отсюда нахуй, блядь, в свой тред.
>смогу ли я
Гарантий нет, но попробуй.
Успех в геймдеве обратно пропорционален успеху в сексуальной жизни. Предложения ты начинаешь с большой буквы и запятые ставишь, но на двач тебя пустило, так что твои шансы сделать игру должны быть весьма высоки.
Главное - не сдаваться.
> Че делать если в мире нейронок страшно жить?
Перекатывать треды. А там уж разберешься.
Предлагайте арт для переката.
>>895906 (OP)
>>895906 (OP)
>>895906 (OP)
>Че делать в мире нейронок
Делать нейронку, которая делает игры вместо тебя.
>человеческая мысль
Достаточно сложная нейронка не человек? Расист!
>>895896
>А всё это собирать кто будет
Специальная нейронка-сборщик.
>придумывать что генерить
var result = ""
for i in randi() % a + b:
result += words[randi() % words.size()] + " "
return result
хуйня какая-то. У высокоскиллового сложные задачи так же вызывают фрустрацию, а не какой-то флоу. Какая то девочка психологиня просто от балды слова накидала.
Игры не искусство. В них, конечно, бывает искусство в качестве некоторых составных элементов. Например, футбол игра, но не искусство, хотя в нем есть искусство в виде логотипов на футболках, и иногда некоторые позы можно отнести к нему.
>девочка психологиня
https://ru.wikipedia.org/wiki/Чиксентмихайи_Михай
>У высокоскиллового сложные задачи так же вызывают фрустрацию
Согласен, не совсем корректный график. На практике состояние потока относительно - возникает, когда сложность задачи соответствует твоим навыкам. Новичок словит поток только от самых простых задач, профи словит поток только от задач, соответствующих высокому уровню его навыков, но даже профи будет испытывать стресс от сверхсложных задач, которые даже он не способен решить.
>>896004
>Игры не искусство
>футбол игра
Футбол не игра, а спорт. А вот видеоигра про футбол - это как раз искусство. Видеоигра по сути ближе к мячику, воротам, ровно подстриженному газону и т.д., тогда как в спорте "игрой" называют процесс взаимодействия, а не инструменты. Видеоигра - это не процесс, а результат деятельности творцов (программистов, художников, дизайнеров, музыкантов и т.д.), т.е. предмет искусства. Вот непосредственное использование видеоигры по прямому назначению обычно не является искусством, хотя и тут есть исключения - машиниму, летсплеи, спидраны и прочее подобное можно назвать искусством.
Игра - это программа с правилами геймплея, то есть именно игра как футбол. С вкраплениями элементов искусства (картинки, музыка) которых я и не отрицал.
>идеоигра по сути ближе к мячику, воротам, ровно подстриженному газону
Ну и вот мячик, ворота, газон искусством не называют же.
>Футбол не игра, а спорт.
Футбол это игра, но может быть и спортом. Ведь вопрос только в том с какой целью. Ведь каждую игру можно превратить в спорт просто поставив соревновательную цель.
Пацаны оцените щас ещё приседания прикручу и вообще сказка будет кто хочет го ко мне в команду делаю шутер иммёрсив сим! йоооу!