Катабасис - слово, которое можно буквально перевести с греческого как «спуск». В более широком смысле это мифологема, описывающая спуск героя в подземное царство.
Около года назад мой интерес к античности сподвиг меня начать разработку рогалика в неком греко-римско-персидском сеттинге, в котором будут катакомбы, митреумы, бронзовое оружие, можно будет приносить в жертву быков и общаться со всякими хтоническими и не очень богами.
Так же, я поставил себе две технических задачи:
Реализовать физику.
Реализовать расчлененку.
В некоторой степени мне удалось и то и другое: от ударов противники разлетаются на части, ноги и головы летят кувыркаясь и сталкиваясь по пути с другими объектами. Так же реализованы взрывы с осколками, стрельба из лука и арбалета (Да, греки таки изобрели арбалет, правда не совсем такой, какой был в средневековье), метание ножей и прочие простые физические манипуляции.
Так как до этого, опыта разработки я почти не имел, работа идет неспешно. Работаю я на Юнити.
Что реализовано на данный момент:
- Время измеряемое в тиках. Большинство существ ходят со скоростью 1 клетка/10 тиков. За это время может произойти много чего интересного.
- Около 20 различных существ. Некоторые из них нейтральны к игроку, а некоторые охотятся на других существ.
- Система морали. Когда существу больно ему при этом еще и страшно. Оно бежит.
- У каждого существа есть несколько частей тела, которые приняв достаточно урона могут покинуть свои естественные места.
- Части тела врагов можно кушать, восстанавливая себе хп.
- Возможность сломать любой предмет, например, прокопать стену киркой.
- Зелья. Их пока всего два – реген и инвиз. В моем рогалике принято не принимать зелья внутрь, а обливаться ими. Таким образом можно сделать чтобы рука тряслась стала невидимой.
- Прокачка. Пока скудная, есть только два стата STR и DEX их можно повышать и от них скейлится урон оружия примерно как в дарксоулсе.
- Подземелье, представляющее собой смесь пещер и комнат соединенных коридорами. При этом, есть две уникальные локации: Яма и Озеро. В яму попадаешь прыгнув с обрыва. Из нее потом можно влезти обратно по лестнице. Озеро находится на пятом этаже подземелья, там живет босс, или что-то подобное - Еа, Владыка Глубин. Здоровенная рыбина такая. Можете ее отпиздить.
Все это вроде даже особо не лагает, ради чего мне в какой-то момент пришлось начать разработку заново, перенеся все на Unity ECS (Уууу сука как же я ненавижу это кривое поделие, но без него видимо никак)
Что планируется:
- Взаимодействие с Богами.
- Нормальная прокачка.
- Всякие механизмы с рычагами, нажимными плитами и.т.д.
- Секретные комнаты.
- Озвучка.
- Подземные города, населенные нейтральными людьми.
- Торговля.
- Больше уникальных локаций
Можете подписаться на мою группу в ВК: https://vk.com/Katabasys
Там можно скачать и последний билд.
ИТТ предлагаем предложения, спрашиваем вопросы, даем советы, называем меня Керилом, (любой фидбек будет мне очень приятен) расчленяем котов, закидываем костями красных ползунов, славим Митру и Вакха!
Около года назад мой интерес к античности сподвиг меня начать разработку рогалика в неком греко-римско-персидском сеттинге, в котором будут катакомбы, митреумы, бронзовое оружие, можно будет приносить в жертву быков и общаться со всякими хтоническими и не очень богами.
Так же, я поставил себе две технических задачи:
Реализовать физику.
Реализовать расчлененку.
В некоторой степени мне удалось и то и другое: от ударов противники разлетаются на части, ноги и головы летят кувыркаясь и сталкиваясь по пути с другими объектами. Так же реализованы взрывы с осколками, стрельба из лука и арбалета (Да, греки таки изобрели арбалет, правда не совсем такой, какой был в средневековье), метание ножей и прочие простые физические манипуляции.
Так как до этого, опыта разработки я почти не имел, работа идет неспешно. Работаю я на Юнити.
Что реализовано на данный момент:
- Время измеряемое в тиках. Большинство существ ходят со скоростью 1 клетка/10 тиков. За это время может произойти много чего интересного.
- Около 20 различных существ. Некоторые из них нейтральны к игроку, а некоторые охотятся на других существ.
- Система морали. Когда существу больно ему при этом еще и страшно. Оно бежит.
- У каждого существа есть несколько частей тела, которые приняв достаточно урона могут покинуть свои естественные места.
- Части тела врагов можно кушать, восстанавливая себе хп.
- Возможность сломать любой предмет, например, прокопать стену киркой.
- Зелья. Их пока всего два – реген и инвиз. В моем рогалике принято не принимать зелья внутрь, а обливаться ими. Таким образом можно сделать чтобы рука тряслась стала невидимой.
- Прокачка. Пока скудная, есть только два стата STR и DEX их можно повышать и от них скейлится урон оружия примерно как в дарксоулсе.
- Подземелье, представляющее собой смесь пещер и комнат соединенных коридорами. При этом, есть две уникальные локации: Яма и Озеро. В яму попадаешь прыгнув с обрыва. Из нее потом можно влезти обратно по лестнице. Озеро находится на пятом этаже подземелья, там живет босс, или что-то подобное - Еа, Владыка Глубин. Здоровенная рыбина такая. Можете ее отпиздить.
Все это вроде даже особо не лагает, ради чего мне в какой-то момент пришлось начать разработку заново, перенеся все на Unity ECS (Уууу сука как же я ненавижу это кривое поделие, но без него видимо никак)
Что планируется:
- Взаимодействие с Богами.
- Нормальная прокачка.
- Всякие механизмы с рычагами, нажимными плитами и.т.д.
- Секретные комнаты.
- Озвучка.
- Подземные города, населенные нейтральными людьми.
- Торговля.
- Больше уникальных локаций
Можете подписаться на мою группу в ВК: https://vk.com/Katabasys
Там можно скачать и последний билд.
ИТТ предлагаем предложения, спрашиваем вопросы, даем советы, называем меня Керилом, (любой фидбек будет мне очень приятен) расчленяем котов, закидываем костями красных ползунов, славим Митру и Вакха!
1,9 Мб, 860x756Так на данный момент выглядят взрывы. Я взрываю стопку бомб, каждая из которых создает около десятка осколков. Не смотря на то, что я не пренебрег мерами безопасности и спрятался за сталагмитами, голову мне все-таки снесло.
Веселые гифки из старой версии полугодичной давности. Теперь бои стали менее эпичными, так как многие действия мобов, такие как поиск и подбор предметов с земли оказались довольно требовательными к производительности. Да и заканчиваются они теперь слишком быстро, несколько попаданий по голове и моб уже не жилец.
Стоит наверное попытаться вернуть элементы старой боевой системы в более оптимизированном виде...
Стоит наверное попытаться вернуть элементы старой боевой системы в более оптимизированном виде...
54 Кб, 1230x509Раньше я прописывал значения всех предметов внутри Юнити, но потом я догадался использовать для этого Эксель и это колоссально упростило мне жизнь. Теперь все данные о параметрах предметов и существ хранятся в эксель таблице, что позволяет мне видеть все статы сразу, а так же высчитывать всякие параметры, такие как урон существ за тик с разным оружием в зависимости от статов.
Сейчас тут 114 строк и 55 столбцов. Конечно не все ячейки используются для каждого предмета, но все равно если бы я баллансил все это внутри Юнити я бы сдох как собака
Сейчас тут 114 строк и 55 столбцов. Конечно не все ячейки используются для каждого предмета, но все равно если бы я баллансил все это внутри Юнити я бы сдох как собака
Еще есть такая же таблица для структур (комнаты всякие и.т.д) сейчас занимаюсь расширением этой системы, в частности, хочу чтобы можно было взять и заспавнить комнату прямо во время игры, введя консольную команду.
Для того чтобы проектировать комнаты я не придумал ничего лучше чем рисовать их в виде png, где цвету пикселей соответствуют объекты из которых комната состоит. Скрипт перебирает все пиксели, переводит цвет в хекс строку и сравнивает его со значением из таблицы предметов.
По началу это было удобно, но сейчас нужно держать в голове кучу инфы о том какой цвет за какой предмет отвечает.
Хотел бы написать инструмент чтобы рисовать эти комнаты прямо внутри
юнити, но увы, в инструментописании я ничего не смыслю.
Для того чтобы проектировать комнаты я не придумал ничего лучше чем рисовать их в виде png, где цвету пикселей соответствуют объекты из которых комната состоит. Скрипт перебирает все пиксели, переводит цвет в хекс строку и сравнивает его со значением из таблицы предметов.
По началу это было удобно, но сейчас нужно держать в голове кучу инфы о том какой цвет за какой предмет отвечает.
Хотел бы написать инструмент чтобы рисовать эти комнаты прямо внутри
юнити, но увы, в инструментописании я ничего не смыслю.
>>796296 Спасибо, я польщен
7,3 Мб, 789x681Сделал эффект окаменения. Любой предмет можно временно обратить в камень, из за чего тот получит +100 защиты, но потеряет способность двигаться, если это существо.
>>796365
Вообще, я бы хотел конечно.
Но сейчас не понятно, что вообще дальше будет со стимом. Сейчас там из России вообще только через тенге платить можно)
Да и на данный момент, игра еще не доделана настолько, чтобы об этом можно было серьезно говорить. Во всяком случае я плохо представляю, чтобы в обозримом будущем кто-то был готов купить ее за деньги.
Более реалистичный вариант - портировать ее на андроид и залить в плеймаркет. Я не особо шарю за особенности разработки и тестирования на андроиде, но тем не менее стараюсь большинство вещей делать так чтобы такой порт был возможен. Например, вместо миллиона кнопок, как это принято в рогаликах я хочу все управление свести к манипуляциям мышкой, а его уже можно будет превратить в управление с тачскрина.
Вообще, я бы хотел конечно.
Но сейчас не понятно, что вообще дальше будет со стимом. Сейчас там из России вообще только через тенге платить можно)
Да и на данный момент, игра еще не доделана настолько, чтобы об этом можно было серьезно говорить. Во всяком случае я плохо представляю, чтобы в обозримом будущем кто-то был готов купить ее за деньги.
Более реалистичный вариант - портировать ее на андроид и залить в плеймаркет. Я не особо шарю за особенности разработки и тестирования на андроиде, но тем не менее стараюсь большинство вещей делать так чтобы такой порт был возможен. Например, вместо миллиона кнопок, как это принято в рогаликах я хочу все управление свести к манипуляциям мышкой, а его уже можно будет превратить в управление с тачскрина.
336 Кб, 320x562>>796250
Готово. Теперь я могу спавнить любые структуры в процессе игры, и что более важно, проверять наличие определенной структуры на клетках.
Зачем мне это нужно?
На основе этой механики будут работать жертвоприношения. По моей задумке игрок должен выкладывать на полу фигуры из определенных предметов, после чего, предмет, лежащий в центре фигуры будет принесен в жертву.
На данный момент такая фигура только одна - квадрат круг 3*3 из костей.
Теперь нужно создать систему которая будет оценивать насколько та или иная жертва имеет смысл. Некоторые предметы будут вызывать расположение богов: любому приятно получить в подарок сочного пещерного быка, а если игрок принесет в жертву свою собственную конечность, это вообще способно растрогать кого угодно.
Так же будут и хреновые жертвы, которые будут восприняты как оскорбление. Так что, подходите к выбору своего подношения с умом.
Готово. Теперь я могу спавнить любые структуры в процессе игры, и что более важно, проверять наличие определенной структуры на клетках.
Зачем мне это нужно?
На основе этой механики будут работать жертвоприношения. По моей задумке игрок должен выкладывать на полу фигуры из определенных предметов, после чего, предмет, лежащий в центре фигуры будет принесен в жертву.
На данный момент такая фигура только одна - квадрат круг 3*3 из костей.
Теперь нужно создать систему которая будет оценивать насколько та или иная жертва имеет смысл. Некоторые предметы будут вызывать расположение богов: любому приятно получить в подарок сочного пещерного быка, а если игрок принесет в жертву свою собственную конечность, это вообще способно растрогать кого угодно.
Так же будут и хреновые жертвы, которые будут восприняты как оскорбление. Так что, подходите к выбору своего подношения с умом.
Последние несколько дней я занимался исправлением всяких багов. Доделал скрипт который позволяет отцентровывать предмет в руке так чтобы ты брал его не за центр, который может оказаться пустым, а за ближайший к центру непрозрачный пиксель.
Добавил несколько новых команд в консоль.
Добавил несколько новых команд в консоль.
306 Кб, 748x287Кстати про консоль.
Я понял одну вещь: чит-консоль это первое что ты должен сделать когда начинаешь разработку. Дабавляешь какой-то функционал в игру - сразу добавляй чит, чтобы вызывать его в рантайме. До меня это дошло только ближе к середине, но после этого жизнь стала значительно проще.
На данный момент, я могу спавнить через консоль любые вещи, накладывать эффекты, отсоединять части тела, присоединять, спавнить структуры и так далее. Так же запоминается история ввода и работают подсказки, между которыми можно переключаться жмякая таб.
Я понял одну вещь: чит-консоль это первое что ты должен сделать когда начинаешь разработку. Дабавляешь какой-то функционал в игру - сразу добавляй чит, чтобы вызывать его в рантайме. До меня это дошло только ближе к середине, но после этого жизнь стала значительно проще.
На данный момент, я могу спавнить через консоль любые вещи, накладывать эффекты, отсоединять части тела, присоединять, спавнить структуры и так далее. Так же запоминается история ввода и работают подсказки, между которыми можно переключаться жмякая таб.
Добавил глубокий и интересный геймплей освещение вокруг курсора и карты нормалей. Сейчас играюсь с разными их параметрами.
Качество нормалей оставляет желать лучшего, так как они генерируются автоматически в юнити-шейдерграфе, а он часто вообще не понимает какую форму я имел в виду когда рисовал.
Тем не менее, делать нормали вручную я не буду, это полнейшее безумие. А так, пусть будет, как маленькая приятная фича.
Качество нормалей оставляет желать лучшего, так как они генерируются автоматически в юнити-шейдерграфе, а он часто вообще не понимает какую форму я имел в виду когда рисовал.
Тем не менее, делать нормали вручную я не буду, это полнейшее безумие. А так, пусть будет, как маленькая приятная фича.
Пока разработка системы жертвоприношений немного застопилась.
Вместо этого я добавил спутников.
Это мобы, которые при определенных условиях готовы следовать за игроком и защищать его.
Вообще эту механику я спиздил из моего любимого и несравненного Dungeon Crawl Stone Soup. Там, если ты играешь за орка то можно основать свою секту и ходить по данжу с толпой орков адептов, которые постепенно прокачиваются, получают новые способности итд. Там это сделано просто великолепно, за жизнь каждого орка ты переживаешь как за свою собственную, а когда ваш отряд заходит в болото и там его накрывает ядовитое облако, то это вообще воспринимается как настоящая трагедия.
Вместо этого я добавил спутников.
Это мобы, которые при определенных условиях готовы следовать за игроком и защищать его.
Вообще эту механику я спиздил из моего любимого и несравненного Dungeon Crawl Stone Soup. Там, если ты играешь за орка то можно основать свою секту и ходить по данжу с толпой орков адептов, которые постепенно прокачиваются, получают новые способности итд. Там это сделано просто великолепно, за жизнь каждого орка ты переживаешь как за свою собственную, а когда ваш отряд заходит в болото и там его накрывает ядовитое облако, то это вообще воспринимается как настоящая трагедия.
4,5 Мб, 1041x779Me and the boys
На данный момент спутники умеют следовать за персонажем, атакуют тех кто пытается ему навредить, а так же при помощи кнопки броска на них можно экипировать разное оружие и броню. Каким образом игрок этих спутников будет встречать я пока не придумал(
Слушай, а как ты организовал работу с тайлами в юнити? стандартным тайл мэпом и спрайтами?
>>798217
А я что-то взглянул на встроенную тайлмапу, и решил что это какая-то фигня и надо свою писать. Хз, может слишком поспешное решение было, ну да ладно. Во всяком случае, на этапе знакомства этой тайлмапы с ECS сто проц были бы какие-нибудь проблемы.
Вот, например, я только что выяснил, что если ты используешь в юнити атласы текстур, то ты не можешь использовать карты нормалей. Либо одно либо другое.
Чувствую что там тоже мог возникнуть какой-нибудь подобный неожиданный Unity-прикол который бы все заруинил.
Если интересно, про то как устроены тайлы могу поподробнее расписать.
А я что-то взглянул на встроенную тайлмапу, и решил что это какая-то фигня и надо свою писать. Хз, может слишком поспешное решение было, ну да ладно. Во всяком случае, на этапе знакомства этой тайлмапы с ECS сто проц были бы какие-нибудь проблемы.
Вот, например, я только что выяснил, что если ты используешь в юнити атласы текстур, то ты не можешь использовать карты нормалей. Либо одно либо другое.
Чувствую что там тоже мог возникнуть какой-нибудь подобный неожиданный Unity-прикол который бы все заруинил.
Если интересно, про то как устроены тайлы могу поподробнее расписать.
>>798321
Давай всегда интересовал этот вопрос, как оптимизировать мир, где каждый тайл это геймобджект. У меня уже в мире из 1000 начинало подлагивать.
Мимо-экспериментировал с рандомной генерацией
Давай всегда интересовал этот вопрос, как оптимизировать мир, где каждый тайл это геймобджект. У меня уже в мире из 1000 начинало подлагивать.
Мимо-экспериментировал с рандомной генерацией
>>798321
да, спасибо, было б очень круто.
Я объясню, что меня смущает. Есть подход, когда на каждый тайл навешают MonoBehaviour скрипт, который отвечает за активность тайла. т.е. на карте 10х10 будет 100 тайлов со 100 экземплярами MB.
весь мой предыдущий опыт с другими движками вопит, что это не очень хорошая идея, но все юнити туториалы делают именно так. Что ты думаешь?
да, спасибо, было б очень круто.
Я объясню, что меня смущает. Есть подход, когда на каждый тайл навешают MonoBehaviour скрипт, который отвечает за активность тайла. т.е. на карте 10х10 будет 100 тайлов со 100 экземплярами MB.
весь мой предыдущий опыт с другими движками вопит, что это не очень хорошая идея, но все юнити туториалы делают именно так. Что ты думаешь?
>>798325
>>798334
Изначально я тоже далал кучу геймобджектов с монобихейвиорами в 2д массиве, но потом понял что это кукож и перешел на ECS. Скорее всего, это единственное нормальное решение для большого количества тайлов и предметов в них.
На данный момент это сделано так:
Тайл это структура. Там содержится его порядковый номер и ссылки на сущности которые в этом тайле находятся.
Все тайлы, коих для удобства всегда 4096 (64*64) лежат в специальном статическом NativeArray.
Каждый тик запускается джоба, которая выполняет нужные вычисления со всеми этими тайлами. (виден\не виден, можно ли ходить и так далее).
Можно было бы каждый тайл тоже сделать сущностью и чтобы их перебирала система, но я не вижу какой в этом плюс в плане производительности, ведь тайлов всегда одно и то же количество, и они не заменяются новыми.
Что же делать в таком случае с объектами в тайлах?
У меня есть такая штука как PrimitiveObject. Это единственный префаб во всей схеме. На нем так же лежит одноименный монобехейвиор и спрайтрендерер.
Эти примитивы лежат в пуле. Их там много-много около 10к.
Когда мне надо заспавнить какую-то вещь я создаю сущность, вешаю на нее специфические для этой вещи компоненты, достаю из пула примитив, прикрепляю его к сущности и ставлю в его спрайтрендерер нужный спрайт. Далее размещаю этот примитив на координатах и добавляю ссылку на его сущность в соответсвующий тайл. Все.
Таким образом в моей игре нет ни одного префаба не считая примитива. И слава богу, так как апи работы с префабами это по-моему одна из самых всратых вещей в вдижке.
Есть конечно способ сделать все еще круче, используя pure ECS. Там вообще ни одного гемобджекта не будет. Но увы, за рендеринг на чистом ецс я не шарю. А надо бы...
>>798334
Изначально я тоже далал кучу геймобджектов с монобихейвиорами в 2д массиве, но потом понял что это кукож и перешел на ECS. Скорее всего, это единственное нормальное решение для большого количества тайлов и предметов в них.
На данный момент это сделано так:
Тайл это структура. Там содержится его порядковый номер и ссылки на сущности которые в этом тайле находятся.
Все тайлы, коих для удобства всегда 4096 (64*64) лежат в специальном статическом NativeArray.
Каждый тик запускается джоба, которая выполняет нужные вычисления со всеми этими тайлами. (виден\не виден, можно ли ходить и так далее).
Можно было бы каждый тайл тоже сделать сущностью и чтобы их перебирала система, но я не вижу какой в этом плюс в плане производительности, ведь тайлов всегда одно и то же количество, и они не заменяются новыми.
Что же делать в таком случае с объектами в тайлах?
У меня есть такая штука как PrimitiveObject. Это единственный префаб во всей схеме. На нем так же лежит одноименный монобехейвиор и спрайтрендерер.
Эти примитивы лежат в пуле. Их там много-много около 10к.
Когда мне надо заспавнить какую-то вещь я создаю сущность, вешаю на нее специфические для этой вещи компоненты, достаю из пула примитив, прикрепляю его к сущности и ставлю в его спрайтрендерер нужный спрайт. Далее размещаю этот примитив на координатах и добавляю ссылку на его сущность в соответсвующий тайл. Все.
Таким образом в моей игре нет ни одного префаба не считая примитива. И слава богу, так как апи работы с префабами это по-моему одна из самых всратых вещей в вдижке.
Есть конечно способ сделать все еще круче, используя pure ECS. Там вообще ни одного гемобджекта не будет. Но увы, за рендеринг на чистом ецс я не шарю. А надо бы...
>>798321 >>798325 >>798334 >>798338
Какие ецс, какие геймобжект, какие монобехи? Что за поколение... Берёте массив БАЙТОВ (или слов, если нужно больше 256 тайлов), каждый байт - ID тайла (0..255), например, 0 - это голая земля, 1 - травка, 2 - камень, 3 - песок, 4 - вода... Потом каждый тик по смещению камеры от начала координат вычисляете диапазон видимых тайлов и отображаете на экране только их. Ещё лучше, если все тайлы статичные - делите карту на чанки и рендерите каждый чанк в текстуру, выводите на экран только эти пререндеренные чанки, которые попадают в обзор камеры, так будет ещё быстрее, особенно если тайлы очень мелкие (типа 8х8 пикселей). Всё. Один скрипт, минимум затрат памяти, никакого ецс и даже ООП не нужно. Даже Юнити не нужна, берите SDL и делайте так.
А туториалы зачастую пишут ньюфаги и дурачки.
мимо песочниц enjoyer
Какие ецс, какие геймобжект, какие монобехи? Что за поколение... Берёте массив БАЙТОВ (или слов, если нужно больше 256 тайлов), каждый байт - ID тайла (0..255), например, 0 - это голая земля, 1 - травка, 2 - камень, 3 - песок, 4 - вода... Потом каждый тик по смещению камеры от начала координат вычисляете диапазон видимых тайлов и отображаете на экране только их. Ещё лучше, если все тайлы статичные - делите карту на чанки и рендерите каждый чанк в текстуру, выводите на экран только эти пререндеренные чанки, которые попадают в обзор камеры, так будет ещё быстрее, особенно если тайлы очень мелкие (типа 8х8 пикселей). Всё. Один скрипт, минимум затрат памяти, никакого ецс и даже ООП не нужно. Даже Юнити не нужна, берите SDL и делайте так.
А туториалы зачастую пишут ньюфаги и дурачки.
мимо песочниц enjoyer
>>798351
А ты хорош
А ты хорош
>>798351
Если надо просто выводить картинку, то да, можно и массив байтов использовать. А для чего-то посложнее придется все-таки хранить в тайле больше инфы чем просто id.
Мобы же должны знать, какой тайл в поле зрения игрока, а какой нет? Должны.
Игрок должен знать, какой дроп на тайле лежит? А то.
Вот и получается, что вместо байта с id текстурки, нужно тащить туда какую-никакую структуру со всеми этими данными.
А мысль рендерить каждый чанк в текстуру крутая, но я боюсь мне просто столько фпс не нужно)
Если надо просто выводить картинку, то да, можно и массив байтов использовать. А для чего-то посложнее придется все-таки хранить в тайле больше инфы чем просто id.
Мобы же должны знать, какой тайл в поле зрения игрока, а какой нет? Должны.
Игрок должен знать, какой дроп на тайле лежит? А то.
Вот и получается, что вместо байта с id текстурки, нужно тащить туда какую-никакую структуру со всеми этими данными.
А мысль рендерить каждый чанк в текстуру крутая, но я боюсь мне просто столько фпс не нужно)
>>798375
Для чего-то сложнее нужно разделять всё на разные системы, слои. Тайлы - это статичные элементы карты, даже если они когда-либо меняются (как в Террарии), то делают это редко. Предметы, лут - это отдельные простые сущности, которые лежат поверх сетки тайлов. Какие-нибудь деревья, кусты, которые колышутся на ветру, растут, цветут и могут быть срублены, могут быть особенными сущностями типа мобов, со своей логикой и состояниями. Вряд ли в какой-то игре будут тысячи лутабельных деревьев на одном экране одновременно или тысячи отдельных единиц лута, а вот тысячи тайлов на одном экране при сегодняшних разрешениях экранов - это запросто. Следовательно, тайловую систему нужно оптимизировать отдельно от тех немногочисленных сущностей, которые лежат или живут поверх неё.
Алсо, если необходимо хранить много настроек в каждом тайле, может иметь смысл создать отдельную "палитру тайлов" и хранить в двумерном массиве тайлов только индексы этой палитры. При этом наполнять палитру (определять индексы) можно динамически по мере создания новых комбинаций настроек. Это избавляет от необходимости хранить кучу лишних данных для повторяющихся тайлов, но при этом позволяет иметь удобный доступ к индивидуальным свойствам каждого тайла. Снова имеем двумерный массив байтов/слов, только каждое число - индекс в палитре (одномерном массиве или списке), хранящей сложные структуры (записи/словари) с разными свойствами.
Пример кодом. Вместо этого:
Будет примерно такой код:
С одной стороны, почти ничего не изменилось в плане читабельности (если обернуть сеттерами и геттерами - внешне код будет совсем одинаковым), а с другой - мы можем иметь тысячи одинаковых тайлов травы с одинаковой влажностью и это будет просто тысяча индексов, указывающих на одну тяжёлую структуру с параметрами. Да, для изменения одного тайла понадобится новая структура (или найти подходящую в палитре), но мы же говорим о тайлах, которые по определению редко меняют своё состояние (в отличие от мобов, лута, снарядов и т.д., которые обрабатываются отдельно).
Фпс лишними не бывают. Особенно если захочешь портировать игру на смартфоны, там неоптимальная архитектура игры в буквальном смысле чувствуется руками, ЕВПОЧЯ.
Кстати, пошаговые тайловые рогалики неожиданно приятно играются на смартфоне, тыкаешь в тайлы и персонаж топает туда или кого-то атакует, кайф, не то что мышкой елозить.
Для чего-то сложнее нужно разделять всё на разные системы, слои. Тайлы - это статичные элементы карты, даже если они когда-либо меняются (как в Террарии), то делают это редко. Предметы, лут - это отдельные простые сущности, которые лежат поверх сетки тайлов. Какие-нибудь деревья, кусты, которые колышутся на ветру, растут, цветут и могут быть срублены, могут быть особенными сущностями типа мобов, со своей логикой и состояниями. Вряд ли в какой-то игре будут тысячи лутабельных деревьев на одном экране одновременно или тысячи отдельных единиц лута, а вот тысячи тайлов на одном экране при сегодняшних разрешениях экранов - это запросто. Следовательно, тайловую систему нужно оптимизировать отдельно от тех немногочисленных сущностей, которые лежат или живут поверх неё.
Алсо, если необходимо хранить много настроек в каждом тайле, может иметь смысл создать отдельную "палитру тайлов" и хранить в двумерном массиве тайлов только индексы этой палитры. При этом наполнять палитру (определять индексы) можно динамически по мере создания новых комбинаций настроек. Это избавляет от необходимости хранить кучу лишних данных для повторяющихся тайлов, но при этом позволяет иметь удобный доступ к индивидуальным свойствам каждого тайла. Снова имеем двумерный массив байтов/слов, только каждое число - индекс в палитре (одномерном массиве или списке), хранящей сложные структуры (записи/словари) с разными свойствами.
Пример кодом. Вместо этого:
>if tile[x][y].type == GRASS and tile[x][y].walkable and tile[x][y].wetness > 0: ...
Будет примерно такой код:
>if palette[tile[x][y]].type == GRASS and palette[tile[x][y]].walkable and palette[tile[x][y]].wetness > 0: ...
С одной стороны, почти ничего не изменилось в плане читабельности (если обернуть сеттерами и геттерами - внешне код будет совсем одинаковым), а с другой - мы можем иметь тысячи одинаковых тайлов травы с одинаковой влажностью и это будет просто тысяча индексов, указывающих на одну тяжёлую структуру с параметрами. Да, для изменения одного тайла понадобится новая структура (или найти подходящую в палитре), но мы же говорим о тайлах, которые по определению редко меняют своё состояние (в отличие от мобов, лута, снарядов и т.д., которые обрабатываются отдельно).
>мне просто столько фпс не нужно
Фпс лишними не бывают. Особенно если захочешь портировать игру на смартфоны, там неоптимальная архитектура игры в буквальном смысле чувствуется руками, ЕВПОЧЯ.
Кстати, пошаговые тайловые рогалики неожиданно приятно играются на смартфоне, тыкаешь в тайлы и персонаж топает туда или кого-то атакует, кайф, не то что мышкой елозить.
>>798375
Для чего-то сложнее нужно разделять всё на разные системы, слои. Тайлы - это статичные элементы карты, даже если они когда-либо меняются (как в Террарии), то делают это редко. Предметы, лут - это отдельные простые сущности, которые лежат поверх сетки тайлов. Какие-нибудь деревья, кусты, которые колышутся на ветру, растут, цветут и могут быть срублены, могут быть особенными сущностями типа мобов, со своей логикой и состояниями. Вряд ли в какой-то игре будут тысячи лутабельных деревьев на одном экране одновременно или тысячи отдельных единиц лута, а вот тысячи тайлов на одном экране при сегодняшних разрешениях экранов - это запросто. Следовательно, тайловую систему нужно оптимизировать отдельно от тех немногочисленных сущностей, которые лежат или живут поверх неё.
Алсо, если необходимо хранить много настроек в каждом тайле, может иметь смысл создать отдельную "палитру тайлов" и хранить в двумерном массиве тайлов только индексы этой палитры. При этом наполнять палитру (определять индексы) можно динамически по мере создания новых комбинаций настроек. Это избавляет от необходимости хранить кучу лишних данных для повторяющихся тайлов, но при этом позволяет иметь удобный доступ к индивидуальным свойствам каждого тайла. Снова имеем двумерный массив байтов/слов, только каждое число - индекс в палитре (одномерном массиве или списке), хранящей сложные структуры (записи/словари) с разными свойствами.
Пример кодом. Вместо этого:
Будет примерно такой код:
С одной стороны, почти ничего не изменилось в плане читабельности (если обернуть сеттерами и геттерами - внешне код будет совсем одинаковым), а с другой - мы можем иметь тысячи одинаковых тайлов травы с одинаковой влажностью и это будет просто тысяча индексов, указывающих на одну тяжёлую структуру с параметрами. Да, для изменения одного тайла понадобится новая структура (или найти подходящую в палитре), но мы же говорим о тайлах, которые по определению редко меняют своё состояние (в отличие от мобов, лута, снарядов и т.д., которые обрабатываются отдельно).
Фпс лишними не бывают. Особенно если захочешь портировать игру на смартфоны, там неоптимальная архитектура игры в буквальном смысле чувствуется руками, ЕВПОЧЯ.
Кстати, пошаговые тайловые рогалики неожиданно приятно играются на смартфоне, тыкаешь в тайлы и персонаж топает туда или кого-то атакует, кайф, не то что мышкой елозить.
Для чего-то сложнее нужно разделять всё на разные системы, слои. Тайлы - это статичные элементы карты, даже если они когда-либо меняются (как в Террарии), то делают это редко. Предметы, лут - это отдельные простые сущности, которые лежат поверх сетки тайлов. Какие-нибудь деревья, кусты, которые колышутся на ветру, растут, цветут и могут быть срублены, могут быть особенными сущностями типа мобов, со своей логикой и состояниями. Вряд ли в какой-то игре будут тысячи лутабельных деревьев на одном экране одновременно или тысячи отдельных единиц лута, а вот тысячи тайлов на одном экране при сегодняшних разрешениях экранов - это запросто. Следовательно, тайловую систему нужно оптимизировать отдельно от тех немногочисленных сущностей, которые лежат или живут поверх неё.
Алсо, если необходимо хранить много настроек в каждом тайле, может иметь смысл создать отдельную "палитру тайлов" и хранить в двумерном массиве тайлов только индексы этой палитры. При этом наполнять палитру (определять индексы) можно динамически по мере создания новых комбинаций настроек. Это избавляет от необходимости хранить кучу лишних данных для повторяющихся тайлов, но при этом позволяет иметь удобный доступ к индивидуальным свойствам каждого тайла. Снова имеем двумерный массив байтов/слов, только каждое число - индекс в палитре (одномерном массиве или списке), хранящей сложные структуры (записи/словари) с разными свойствами.
Пример кодом. Вместо этого:
>if tile[x][y].type == GRASS and tile[x][y].walkable and tile[x][y].wetness > 0: ...
Будет примерно такой код:
>if palette[tile[x][y]].type == GRASS and palette[tile[x][y]].walkable and palette[tile[x][y]].wetness > 0: ...
С одной стороны, почти ничего не изменилось в плане читабельности (если обернуть сеттерами и геттерами - внешне код будет совсем одинаковым), а с другой - мы можем иметь тысячи одинаковых тайлов травы с одинаковой влажностью и это будет просто тысяча индексов, указывающих на одну тяжёлую структуру с параметрами. Да, для изменения одного тайла понадобится новая структура (или найти подходящую в палитре), но мы же говорим о тайлах, которые по определению редко меняют своё состояние (в отличие от мобов, лута, снарядов и т.д., которые обрабатываются отдельно).
>мне просто столько фпс не нужно
Фпс лишними не бывают. Особенно если захочешь портировать игру на смартфоны, там неоптимальная архитектура игры в буквальном смысле чувствуется руками, ЕВПОЧЯ.
Кстати, пошаговые тайловые рогалики неожиданно приятно играются на смартфоне, тыкаешь в тайлы и персонаж топает туда или кого-то атакует, кайф, не то что мышкой елозить.
>>796015 (OP)
Стена - не предмет, а часть ландшафта... А ты планируешь делать какие-нибудь головоломки, лабиринты? Если любую стену можно прокопать, смысл головоломок теряется. Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
Играл в пару разных рогаликов с зельями, так вот там у всех зелий две функции: выпить и бросить. Если бросить на кого-то, включая себя, обольёшь цель этим зельем. Смысл в том, что при разном применении - разные эффекты, к тому же эффект зелья изначально неизвестен. К примеру, зелье нейтрализации при броске нейтрализует газы вокруг цели, а при приёме внутрь - позволяет этими газами безопасно дышать. Поджигающее зелье рациональнее бросить, чем пить, а зелье лечения рациональнее выпить, чем бросить, но в самом начале ты не знаешь, какое зелье нашёл. По-моему, так интереснее.
>>796120
В пошаговой-то игре? Странно.
>>796248
А как ты экспортируешь из редактора и импортируешь в игру? Сам парсер писал или нашёл готовое решение?
>>796250
Сначала хотел посоветовать сделать внутриигровой редактор, но есть решение намного проще - универсальный бесплатный редактор тайловых карт Tiled, в формате легко разберёшься:
https://github.com/mapeditor/tiled
Вроде бы есть готовые плагины для импорта в Unity.
С другой стороны, внутриигровой редактор был бы удобнее для игроков, желающих разнообразить себе игру самодельными модами. Как в старых стратегиях (Age of Empires), когда можно было сделать собственную карту прямо в игре. Понятия не имею, как такая фича отразится на сути рогалика, но по-моему это круто.
>>796896
Я надеюсь, этот скрипт не для рантайма? В смысле, звучит довольно глупо попиксельно центровать каждый спрайт в рантайме, когда это нужно делать всего один раз на этапе дизайна предметов в игре. Или у тебя можно будет рисовать новые предметы прямо в игре?
>>796905
Интересная мысль, тоже думаю сделать консоль.
>>797463
Почему безумие? Если текстуры ты сам вручную рисовал, то и карты нормалей к ним очень легко нарисуешь. На самом деле для вручную нарисованных карт нормалей достаточно всего 9 цветов. Есть специальные картинки-подсказки как с градиентами, так и с резкими границами цвета. Есть туториалы, как их рисовать... Также есть бесплатные утилиты, даже прямо в браузере, позволяющие интерактивно сгенерировать карту нормалей из любой картинки, настроив различные параметры перед экспортом. Попробуй это, я пробовал, вроде неплохо генерирует по пиксель-арт рисункам, правда, я так и не понял, как проверить корректность:
https://cpetry.github.io/NormalMap-Online/
А для совмещения карт нормалей с текстурным атласом, скорее всего, нужно писать свой собственный шейдер. Но лучше, имхо, отказаться от карт нормалей в 2D игре. Выглядят максимально тупо, создавая неестественный объём, да ещё поди и видеокарту грузят как какая-нибудь 3D графика.
>>798047
Мне больше всего нравится в играх, когда можно любого врага "приручить", "очаровать" или иным образом обратить в союзники, конечно, затратив какие-то ресурсы. Во всяком случае обычного врага, а не босса, хотя вроде бы есть игры, где можно даже боссов обращать в союзники. Но раз ты планируешь города и торговлю, логично было бы нанимать наёмников в этих городах (или покупать рабов у бродячих работорговцев, почему бы и нет).
>Возможность сломать любой предмет, например, прокопать стену киркой.
Стена - не предмет, а часть ландшафта... А ты планируешь делать какие-нибудь головоломки, лабиринты? Если любую стену можно прокопать, смысл головоломок теряется. Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
>Зелья. Их пока всего два – реген и инвиз. В моем рогалике принято не принимать зелья внутрь, а обливаться ими.
Играл в пару разных рогаликов с зельями, так вот там у всех зелий две функции: выпить и бросить. Если бросить на кого-то, включая себя, обольёшь цель этим зельем. Смысл в том, что при разном применении - разные эффекты, к тому же эффект зелья изначально неизвестен. К примеру, зелье нейтрализации при броске нейтрализует газы вокруг цели, а при приёме внутрь - позволяет этими газами безопасно дышать. Поджигающее зелье рациональнее бросить, чем пить, а зелье лечения рациональнее выпить, чем бросить, но в самом начале ты не знаешь, какое зелье нашёл. По-моему, так интереснее.
>>796120
>многие действия мобов, такие как поиск и подбор предметов с земли оказались довольно требовательными к производительности
В пошаговой-то игре? Странно.
>>796248
>эксель таблица
А как ты экспортируешь из редактора и импортируешь в игру? Сам парсер писал или нашёл готовое решение?
>>796250
>Для того чтобы проектировать комнаты я не придумал ничего лучше чем рисовать их в виде png
Сначала хотел посоветовать сделать внутриигровой редактор, но есть решение намного проще - универсальный бесплатный редактор тайловых карт Tiled, в формате легко разберёшься:
https://github.com/mapeditor/tiled
Вроде бы есть готовые плагины для импорта в Unity.
С другой стороны, внутриигровой редактор был бы удобнее для игроков, желающих разнообразить себе игру самодельными модами. Как в старых стратегиях (Age of Empires), когда можно было сделать собственную карту прямо в игре. Понятия не имею, как такая фича отразится на сути рогалика, но по-моему это круто.
>>796896
>Доделал скрипт который позволяет отцентровывать предмет в руке так чтобы ты брал его не за центр, который может оказаться пустым, а за ближайший к центру непрозрачный пиксель.
Я надеюсь, этот скрипт не для рантайма? В смысле, звучит довольно глупо попиксельно центровать каждый спрайт в рантайме, когда это нужно делать всего один раз на этапе дизайна предметов в игре. Или у тебя можно будет рисовать новые предметы прямо в игре?
>>796905
>добавляй чит, чтобы вызывать его в рантайме
Интересная мысль, тоже думаю сделать консоль.
>>797463
>делать нормали вручную я не буду, это полнейшее безумие
Почему безумие? Если текстуры ты сам вручную рисовал, то и карты нормалей к ним очень легко нарисуешь. На самом деле для вручную нарисованных карт нормалей достаточно всего 9 цветов. Есть специальные картинки-подсказки как с градиентами, так и с резкими границами цвета. Есть туториалы, как их рисовать... Также есть бесплатные утилиты, даже прямо в браузере, позволяющие интерактивно сгенерировать карту нормалей из любой картинки, настроив различные параметры перед экспортом. Попробуй это, я пробовал, вроде неплохо генерирует по пиксель-арт рисункам, правда, я так и не понял, как проверить корректность:
https://cpetry.github.io/NormalMap-Online/
А для совмещения карт нормалей с текстурным атласом, скорее всего, нужно писать свой собственный шейдер. Но лучше, имхо, отказаться от карт нормалей в 2D игре. Выглядят максимально тупо, создавая неестественный объём, да ещё поди и видеокарту грузят как какая-нибудь 3D графика.
>>798047
>Каким образом игрок этих спутников будет встречать я пока не придумал(
Мне больше всего нравится в играх, когда можно любого врага "приручить", "очаровать" или иным образом обратить в союзники, конечно, затратив какие-то ресурсы. Во всяком случае обычного врага, а не босса, хотя вроде бы есть игры, где можно даже боссов обращать в союзники. Но раз ты планируешь города и торговлю, логично было бы нанимать наёмников в этих городах (или покупать рабов у бродячих работорговцев, почему бы и нет).
>>796015 (OP)
Стена - не предмет, а часть ландшафта... А ты планируешь делать какие-нибудь головоломки, лабиринты? Если любую стену можно прокопать, смысл головоломок теряется. Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
Играл в пару разных рогаликов с зельями, так вот там у всех зелий две функции: выпить и бросить. Если бросить на кого-то, включая себя, обольёшь цель этим зельем. Смысл в том, что при разном применении - разные эффекты, к тому же эффект зелья изначально неизвестен. К примеру, зелье нейтрализации при броске нейтрализует газы вокруг цели, а при приёме внутрь - позволяет этими газами безопасно дышать. Поджигающее зелье рациональнее бросить, чем пить, а зелье лечения рациональнее выпить, чем бросить, но в самом начале ты не знаешь, какое зелье нашёл. По-моему, так интереснее.
>>796120
В пошаговой-то игре? Странно.
>>796248
А как ты экспортируешь из редактора и импортируешь в игру? Сам парсер писал или нашёл готовое решение?
>>796250
Сначала хотел посоветовать сделать внутриигровой редактор, но есть решение намного проще - универсальный бесплатный редактор тайловых карт Tiled, в формате легко разберёшься:
https://github.com/mapeditor/tiled
Вроде бы есть готовые плагины для импорта в Unity.
С другой стороны, внутриигровой редактор был бы удобнее для игроков, желающих разнообразить себе игру самодельными модами. Как в старых стратегиях (Age of Empires), когда можно было сделать собственную карту прямо в игре. Понятия не имею, как такая фича отразится на сути рогалика, но по-моему это круто.
>>796896
Я надеюсь, этот скрипт не для рантайма? В смысле, звучит довольно глупо попиксельно центровать каждый спрайт в рантайме, когда это нужно делать всего один раз на этапе дизайна предметов в игре. Или у тебя можно будет рисовать новые предметы прямо в игре?
>>796905
Интересная мысль, тоже думаю сделать консоль.
>>797463
Почему безумие? Если текстуры ты сам вручную рисовал, то и карты нормалей к ним очень легко нарисуешь. На самом деле для вручную нарисованных карт нормалей достаточно всего 9 цветов. Есть специальные картинки-подсказки как с градиентами, так и с резкими границами цвета. Есть туториалы, как их рисовать... Также есть бесплатные утилиты, даже прямо в браузере, позволяющие интерактивно сгенерировать карту нормалей из любой картинки, настроив различные параметры перед экспортом. Попробуй это, я пробовал, вроде неплохо генерирует по пиксель-арт рисункам, правда, я так и не понял, как проверить корректность:
https://cpetry.github.io/NormalMap-Online/
А для совмещения карт нормалей с текстурным атласом, скорее всего, нужно писать свой собственный шейдер. Но лучше, имхо, отказаться от карт нормалей в 2D игре. Выглядят максимально тупо, создавая неестественный объём, да ещё поди и видеокарту грузят как какая-нибудь 3D графика.
>>798047
Мне больше всего нравится в играх, когда можно любого врага "приручить", "очаровать" или иным образом обратить в союзники, конечно, затратив какие-то ресурсы. Во всяком случае обычного врага, а не босса, хотя вроде бы есть игры, где можно даже боссов обращать в союзники. Но раз ты планируешь города и торговлю, логично было бы нанимать наёмников в этих городах (или покупать рабов у бродячих работорговцев, почему бы и нет).
>Возможность сломать любой предмет, например, прокопать стену киркой.
Стена - не предмет, а часть ландшафта... А ты планируешь делать какие-нибудь головоломки, лабиринты? Если любую стену можно прокопать, смысл головоломок теряется. Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
>Зелья. Их пока всего два – реген и инвиз. В моем рогалике принято не принимать зелья внутрь, а обливаться ими.
Играл в пару разных рогаликов с зельями, так вот там у всех зелий две функции: выпить и бросить. Если бросить на кого-то, включая себя, обольёшь цель этим зельем. Смысл в том, что при разном применении - разные эффекты, к тому же эффект зелья изначально неизвестен. К примеру, зелье нейтрализации при броске нейтрализует газы вокруг цели, а при приёме внутрь - позволяет этими газами безопасно дышать. Поджигающее зелье рациональнее бросить, чем пить, а зелье лечения рациональнее выпить, чем бросить, но в самом начале ты не знаешь, какое зелье нашёл. По-моему, так интереснее.
>>796120
>многие действия мобов, такие как поиск и подбор предметов с земли оказались довольно требовательными к производительности
В пошаговой-то игре? Странно.
>>796248
>эксель таблица
А как ты экспортируешь из редактора и импортируешь в игру? Сам парсер писал или нашёл готовое решение?
>>796250
>Для того чтобы проектировать комнаты я не придумал ничего лучше чем рисовать их в виде png
Сначала хотел посоветовать сделать внутриигровой редактор, но есть решение намного проще - универсальный бесплатный редактор тайловых карт Tiled, в формате легко разберёшься:
https://github.com/mapeditor/tiled
Вроде бы есть готовые плагины для импорта в Unity.
С другой стороны, внутриигровой редактор был бы удобнее для игроков, желающих разнообразить себе игру самодельными модами. Как в старых стратегиях (Age of Empires), когда можно было сделать собственную карту прямо в игре. Понятия не имею, как такая фича отразится на сути рогалика, но по-моему это круто.
>>796896
>Доделал скрипт который позволяет отцентровывать предмет в руке так чтобы ты брал его не за центр, который может оказаться пустым, а за ближайший к центру непрозрачный пиксель.
Я надеюсь, этот скрипт не для рантайма? В смысле, звучит довольно глупо попиксельно центровать каждый спрайт в рантайме, когда это нужно делать всего один раз на этапе дизайна предметов в игре. Или у тебя можно будет рисовать новые предметы прямо в игре?
>>796905
>добавляй чит, чтобы вызывать его в рантайме
Интересная мысль, тоже думаю сделать консоль.
>>797463
>делать нормали вручную я не буду, это полнейшее безумие
Почему безумие? Если текстуры ты сам вручную рисовал, то и карты нормалей к ним очень легко нарисуешь. На самом деле для вручную нарисованных карт нормалей достаточно всего 9 цветов. Есть специальные картинки-подсказки как с градиентами, так и с резкими границами цвета. Есть туториалы, как их рисовать... Также есть бесплатные утилиты, даже прямо в браузере, позволяющие интерактивно сгенерировать карту нормалей из любой картинки, настроив различные параметры перед экспортом. Попробуй это, я пробовал, вроде неплохо генерирует по пиксель-арт рисункам, правда, я так и не понял, как проверить корректность:
https://cpetry.github.io/NormalMap-Online/
А для совмещения карт нормалей с текстурным атласом, скорее всего, нужно писать свой собственный шейдер. Но лучше, имхо, отказаться от карт нормалей в 2D игре. Выглядят максимально тупо, создавая неестественный объём, да ещё поди и видеокарту грузят как какая-нибудь 3D графика.
>>798047
>Каким образом игрок этих спутников будет встречать я пока не придумал(
Мне больше всего нравится в играх, когда можно любого врага "приручить", "очаровать" или иным образом обратить в союзники, конечно, затратив какие-то ресурсы. Во всяком случае обычного врага, а не босса, хотя вроде бы есть игры, где можно даже боссов обращать в союзники. Но раз ты планируешь города и торговлю, логично было бы нанимать наёмников в этих городах (или покупать рабов у бродячих работорговцев, почему бы и нет).
>>798414
Ух, как много всего)
Окей, может быть, я соврал. Если будут головоломки, придется добавлять неразрушаемые стены, это правда.
Да, механика при которой ты не знаешь какое зелье ты пьешь веселая, но это, в купе со свитками идентификации - такое клише. Я бы не хотел воспроизводить эту систему именно в таком виде, но если я не придумаю ничего оригинальнее, видимо, придется.
А тема с обиванием нужна для того чтобы можно было похилить, например, конкретную часть тела.
На самом деле, в той версии почти все было "довольно тебовательно к производительности" .
каждый тик моб обыскивал пол в некотором радиусе вокруг себя и напряженно думал, что бы ему поднять.
Я временно отключил эти функции и сейчас возвращаю их в более оптимизированном виде. В следующем билде будут.
Я использую вот эту штуку: https://github.com/tsubaki/Unity-Excel-Importer-Maker
О, спасибо, пойду заценю.
Я думаю, что во внутриигровом редакторе нет особой необходимости. Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты. Хотя, чем черт не шутит.
Нет) Это делается один раз в начале.
Да, это очень удобно.
Ну может и не безумие.. Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Видеокарту они грузят несравнимо меньше чем 3д, на то они и нормали, чтобы использовать их там где 3д слишком дорого обходится. А по поводу эстетической составляющей мне пока они тоже не на 100% нравятся.
Мыслительный процесс идет. Мб можно будет и приручать кого-то, но это довольно тяжело забалансить. Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий". С рабами норм тема.
Ух, как много всего)
>Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
Окей, может быть, я соврал. Если будут головоломки, придется добавлять неразрушаемые стены, это правда.
>Зелья
Да, механика при которой ты не знаешь какое зелье ты пьешь веселая, но это, в купе со свитками идентификации - такое клише. Я бы не хотел воспроизводить эту систему именно в таком виде, но если я не придумаю ничего оригинальнее, видимо, придется.
А тема с обиванием нужна для того чтобы можно было похилить, например, конкретную часть тела.
>Тяжелые действия мобов
На самом деле, в той версии почти все было "довольно тебовательно к производительности" .
каждый тик моб обыскивал пол в некотором радиусе вокруг себя и напряженно думал, что бы ему поднять.
Я временно отключил эти функции и сейчас возвращаю их в более оптимизированном виде. В следующем билде будут.
>Эксель
Я использую вот эту штуку: https://github.com/tsubaki/Unity-Excel-Importer-Maker
>Редактор карт
О, спасибо, пойду заценю.
Я думаю, что во внутриигровом редакторе нет особой необходимости. Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты. Хотя, чем черт не шутит.
>Центровка предметов
Нет) Это делается один раз в начале.
>Консоль
Да, это очень удобно.
>Нормали
Ну может и не безумие.. Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Видеокарту они грузят несравнимо меньше чем 3д, на то они и нормали, чтобы использовать их там где 3д слишком дорого обходится. А по поводу эстетической составляющей мне пока они тоже не на 100% нравятся.
>Спутники
Мыслительный процесс идет. Мб можно будет и приручать кого-то, но это довольно тяжело забалансить. Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий". С рабами норм тема.
>>798414
Ух, как много всего)
Окей, может быть, я соврал. Если будут головоломки, придется добавлять неразрушаемые стены, это правда.
Да, механика при которой ты не знаешь какое зелье ты пьешь веселая, но это, в купе со свитками идентификации - такое клише. Я бы не хотел воспроизводить эту систему именно в таком виде, но если я не придумаю ничего оригинальнее, видимо, придется.
А тема с обиванием нужна для того чтобы можно было похилить, например, конкретную часть тела.
На самом деле, в той версии почти все было "довольно тебовательно к производительности" .
каждый тик моб обыскивал пол в некотором радиусе вокруг себя и напряженно думал, что бы ему поднять.
Я временно отключил эти функции и сейчас возвращаю их в более оптимизированном виде. В следующем билде будут.
Я использую вот эту штуку: https://github.com/tsubaki/Unity-Excel-Importer-Maker
О, спасибо, пойду заценю.
Я думаю, что во внутриигровом редакторе нет особой необходимости. Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты. Хотя, чем черт не шутит.
Нет) Это делается один раз в начале.
Да, это очень удобно.
Ну может и не безумие.. Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Видеокарту они грузят несравнимо меньше чем 3д, на то они и нормали, чтобы использовать их там где 3д слишком дорого обходится. А по поводу эстетической составляющей мне пока они тоже не на 100% нравятся.
Мыслительный процесс идет. Мб можно будет и приручать кого-то, но это довольно тяжело забалансить. Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий". С рабами норм тема.
Ух, как много всего)
>Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)
Окей, может быть, я соврал. Если будут головоломки, придется добавлять неразрушаемые стены, это правда.
>Зелья
Да, механика при которой ты не знаешь какое зелье ты пьешь веселая, но это, в купе со свитками идентификации - такое клише. Я бы не хотел воспроизводить эту систему именно в таком виде, но если я не придумаю ничего оригинальнее, видимо, придется.
А тема с обиванием нужна для того чтобы можно было похилить, например, конкретную часть тела.
>Тяжелые действия мобов
На самом деле, в той версии почти все было "довольно тебовательно к производительности" .
каждый тик моб обыскивал пол в некотором радиусе вокруг себя и напряженно думал, что бы ему поднять.
Я временно отключил эти функции и сейчас возвращаю их в более оптимизированном виде. В следующем билде будут.
>Эксель
Я использую вот эту штуку: https://github.com/tsubaki/Unity-Excel-Importer-Maker
>Редактор карт
О, спасибо, пойду заценю.
Я думаю, что во внутриигровом редакторе нет особой необходимости. Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты. Хотя, чем черт не шутит.
>Центровка предметов
Нет) Это делается один раз в начале.
>Консоль
Да, это очень удобно.
>Нормали
Ну может и не безумие.. Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Видеокарту они грузят несравнимо меньше чем 3д, на то они и нормали, чтобы использовать их там где 3д слишком дорого обходится. А по поводу эстетической составляющей мне пока они тоже не на 100% нравятся.
>Спутники
Мыслительный процесс идет. Мб можно будет и приручать кого-то, но это довольно тяжело забалансить. Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий". С рабами норм тема.
>>798423
Есть ещё такой: https://github.com/deepnight/ldtk
Но я о нём буквально этой ночью узнал, пока искал ссылки на Tiled, о котором давно знаю и даже немного щупал.
В зависимости от типа головоломки, стены можно переключить в разрушаемые после решения головоломки игроком. Либо сделать их очень прочными, чтобы игроку было лень долбить их, но всё-таки оставалась возможность пробиться грубой силой, если мозгов не хватает решить головоломку умом. Либо эти супер прочные стены может пробить только супер оружие с ограниченным боезапасом, и игроку нужно думать, стоит ли тратить заряды. А самое весёлое, если сокровище за стеной хрупкое и испортится, если пробить стену силой или попасться в скрытую за стеной ловушку...
При запуске игры? Или у разработчика игры? Я просто не понимаю, зачем делать на компе пользователя то, что можно легко рассчитать заранее и хранить только пару чисел, как с хот-спотом курсора:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.cursor.hotspot
Правильно, геймплей важнее, особенно для рогалика.
Почему? По-моему, свобода интереснее.
Я правильно понимаю, что подземелья генерируются рандомно, а редактор карт тебе нужен для дизайна комнат, которые будут примерно одинаковыми, только в разных местах и в разном количестве? Тогда будет в тему одна моя идея, которую я уже несколько лет обдумываю. Идея в том, чтобы игрок имел возможность повлиять на результат генерации игрового мира какими-либо внутриигровыми средствами, т.е. как минимум без модификации игровых файлов сторонними инструментами.
Проще всего объяснить на примере. Вот в Minecraft есть деревни - это случайно генерируемые структуры, в которых форма улиц и число домов полностью случайно, а дома захардкожены разработчиками и имеют всего несколько форм, которые легко запомнить и узнать. То есть даже в одной деревне может быть два совершенно одинаковых дома, но сложно найти две полностью одинаковых деревни. Игрок, при желании, может создать модификацию для игры, которая добавит какие-то новые виды домов или структур в генерацию деревень, и игра будет строить эти новые дома в новых деревнях по мере путешествия игрока по миру. Но делать модификации - сложно, это отдельный от игры набор инструментов, которые нужно где-то достать и потом обучаться им. Что, если бы игрок мог прямо в игре построить домик и каким-то образом зарегистрировать его для генерации в новых деревнях того же мира? С какими-нибудь реками и горами такой трюк не пройдёт, потому что они описываются математически, а вот деревни составляются из готовых кусочков, и на их генерацию было бы легко повлиять игровыми же средствами.
Ну да, согласен, это создаёт проблемы баланса для игры, нацеленной на сложное прохождение, но во многих играх есть упрощённый режим "песочницы", где игрок может творить всё что захочет, и иметь такую фичу в песочнице было бы очень интересно.
Что касается кастомных карт - в таких играх, как Minecraft и Terraria, игроки любят создавать свои собственные карты, нацеленные на решение головоломок, повествование или что-то другое, и делиться этими картами с другими пользователями. И это несмотря на то, что миры в этих играх генерируются рандомно. В тот же Minecraft добавили режим Adventure специально для пользовательских карт, который ограничивает использование инструментов, чтобы игрок не мог случайно сломать карту-головоломку раньше времени. Думаю, в кастомные карты играют в том числе потому, что генератор карт ограничен шаблонами/правилами и не может сгенерировать абсолютно любую карту, т.е. ты не можешь встретить на стандартной карте то, что может сделать на кастомной карте другой игрок. И чем проще и доступнее инструменты редактирования карт, тем больше мотивации у игроков создавать что-то своё и делиться этим с другими игроками, а это расширяет и поддерживает коммьюнити игры даже если разработчик прекратил поддержку игры.
А с возможностью влиять на результат генерации, игрок может создавать новый интересный контент самому себе, потому что даже если бродить по собственному дому скучно, искать по миру деревни с комбинациями своих домов может быть интересно. Просто потому что результат генерации не всегда предсказуем и может создавать неожиданные вещи, о возможности существования которых ты даже не догадывался. Ну, зависит от того, как работает генератор...
>>798424
Треда пока нет. У меня много абстрактных идей (как пример выше) и мало конкретных деталей, чтобы сделать конкретную игру, да и идеи зачастую слишком сложны для меня, чтобы сесть и реализовать за пару дней, а долго работать я не умею - отсутствие результатов вгоняет в депрессию. Были попытки, есть какие-то наброски, но, например, последний месяц я всё забросил и почти ничего не сделал, только играю и сижу в интернете, каждый день думая "завтра точно что-нибудь сделаю". Завидую людям, которые месяцами каждый день работают над своим проектом и получают существенный результат...
>>Редактор карт
>О, спасибо, пойду заценю.
Есть ещё такой: https://github.com/deepnight/ldtk
Но я о нём буквально этой ночью узнал, пока искал ссылки на Tiled, о котором давно знаю и даже немного щупал.
>Если будут головоломки, придется добавлять неразрушаемые стены
В зависимости от типа головоломки, стены можно переключить в разрушаемые после решения головоломки игроком. Либо сделать их очень прочными, чтобы игроку было лень долбить их, но всё-таки оставалась возможность пробиться грубой силой, если мозгов не хватает решить головоломку умом. Либо эти супер прочные стены может пробить только супер оружие с ограниченным боезапасом, и игроку нужно думать, стоит ли тратить заряды. А самое весёлое, если сокровище за стеной хрупкое и испортится, если пробить стену силой или попасться в скрытую за стеной ловушку...
>Это делается один раз в начале.
При запуске игры? Или у разработчика игры? Я просто не понимаю, зачем делать на компе пользователя то, что можно легко рассчитать заранее и хранить только пару чисел, как с хот-спотом курсора:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.cursor.hotspot
>Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Правильно, геймплей важнее, особенно для рогалика.
>Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий".
Почему? По-моему, свобода интереснее.
>Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты.
Я правильно понимаю, что подземелья генерируются рандомно, а редактор карт тебе нужен для дизайна комнат, которые будут примерно одинаковыми, только в разных местах и в разном количестве? Тогда будет в тему одна моя идея, которую я уже несколько лет обдумываю. Идея в том, чтобы игрок имел возможность повлиять на результат генерации игрового мира какими-либо внутриигровыми средствами, т.е. как минимум без модификации игровых файлов сторонними инструментами.
Проще всего объяснить на примере. Вот в Minecraft есть деревни - это случайно генерируемые структуры, в которых форма улиц и число домов полностью случайно, а дома захардкожены разработчиками и имеют всего несколько форм, которые легко запомнить и узнать. То есть даже в одной деревне может быть два совершенно одинаковых дома, но сложно найти две полностью одинаковых деревни. Игрок, при желании, может создать модификацию для игры, которая добавит какие-то новые виды домов или структур в генерацию деревень, и игра будет строить эти новые дома в новых деревнях по мере путешествия игрока по миру. Но делать модификации - сложно, это отдельный от игры набор инструментов, которые нужно где-то достать и потом обучаться им. Что, если бы игрок мог прямо в игре построить домик и каким-то образом зарегистрировать его для генерации в новых деревнях того же мира? С какими-нибудь реками и горами такой трюк не пройдёт, потому что они описываются математически, а вот деревни составляются из готовых кусочков, и на их генерацию было бы легко повлиять игровыми же средствами.
Ну да, согласен, это создаёт проблемы баланса для игры, нацеленной на сложное прохождение, но во многих играх есть упрощённый режим "песочницы", где игрок может творить всё что захочет, и иметь такую фичу в песочнице было бы очень интересно.
Что касается кастомных карт - в таких играх, как Minecraft и Terraria, игроки любят создавать свои собственные карты, нацеленные на решение головоломок, повествование или что-то другое, и делиться этими картами с другими пользователями. И это несмотря на то, что миры в этих играх генерируются рандомно. В тот же Minecraft добавили режим Adventure специально для пользовательских карт, который ограничивает использование инструментов, чтобы игрок не мог случайно сломать карту-головоломку раньше времени. Думаю, в кастомные карты играют в том числе потому, что генератор карт ограничен шаблонами/правилами и не может сгенерировать абсолютно любую карту, т.е. ты не можешь встретить на стандартной карте то, что может сделать на кастомной карте другой игрок. И чем проще и доступнее инструменты редактирования карт, тем больше мотивации у игроков создавать что-то своё и делиться этим с другими игроками, а это расширяет и поддерживает коммьюнити игры даже если разработчик прекратил поддержку игры.
А с возможностью влиять на результат генерации, игрок может создавать новый интересный контент самому себе, потому что даже если бродить по собственному дому скучно, искать по миру деревни с комбинациями своих домов может быть интересно. Просто потому что результат генерации не всегда предсказуем и может создавать неожиданные вещи, о возможности существования которых ты даже не догадывался. Ну, зависит от того, как работает генератор...
>>798424
>А ты тоже что-то пилишь? Есть тред тут?
Треда пока нет. У меня много абстрактных идей (как пример выше) и мало конкретных деталей, чтобы сделать конкретную игру, да и идеи зачастую слишком сложны для меня, чтобы сесть и реализовать за пару дней, а долго работать я не умею - отсутствие результатов вгоняет в депрессию. Были попытки, есть какие-то наброски, но, например, последний месяц я всё забросил и почти ничего не сделал, только играю и сижу в интернете, каждый день думая "завтра точно что-нибудь сделаю". Завидую людям, которые месяцами каждый день работают над своим проектом и получают существенный результат...
>>798423
Есть ещё такой: https://github.com/deepnight/ldtk
Но я о нём буквально этой ночью узнал, пока искал ссылки на Tiled, о котором давно знаю и даже немного щупал.
В зависимости от типа головоломки, стены можно переключить в разрушаемые после решения головоломки игроком. Либо сделать их очень прочными, чтобы игроку было лень долбить их, но всё-таки оставалась возможность пробиться грубой силой, если мозгов не хватает решить головоломку умом. Либо эти супер прочные стены может пробить только супер оружие с ограниченным боезапасом, и игроку нужно думать, стоит ли тратить заряды. А самое весёлое, если сокровище за стеной хрупкое и испортится, если пробить стену силой или попасться в скрытую за стеной ловушку...
При запуске игры? Или у разработчика игры? Я просто не понимаю, зачем делать на компе пользователя то, что можно легко рассчитать заранее и хранить только пару чисел, как с хот-спотом курсора:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.cursor.hotspot
Правильно, геймплей важнее, особенно для рогалика.
Почему? По-моему, свобода интереснее.
Я правильно понимаю, что подземелья генерируются рандомно, а редактор карт тебе нужен для дизайна комнат, которые будут примерно одинаковыми, только в разных местах и в разном количестве? Тогда будет в тему одна моя идея, которую я уже несколько лет обдумываю. Идея в том, чтобы игрок имел возможность повлиять на результат генерации игрового мира какими-либо внутриигровыми средствами, т.е. как минимум без модификации игровых файлов сторонними инструментами.
Проще всего объяснить на примере. Вот в Minecraft есть деревни - это случайно генерируемые структуры, в которых форма улиц и число домов полностью случайно, а дома захардкожены разработчиками и имеют всего несколько форм, которые легко запомнить и узнать. То есть даже в одной деревне может быть два совершенно одинаковых дома, но сложно найти две полностью одинаковых деревни. Игрок, при желании, может создать модификацию для игры, которая добавит какие-то новые виды домов или структур в генерацию деревень, и игра будет строить эти новые дома в новых деревнях по мере путешествия игрока по миру. Но делать модификации - сложно, это отдельный от игры набор инструментов, которые нужно где-то достать и потом обучаться им. Что, если бы игрок мог прямо в игре построить домик и каким-то образом зарегистрировать его для генерации в новых деревнях того же мира? С какими-нибудь реками и горами такой трюк не пройдёт, потому что они описываются математически, а вот деревни составляются из готовых кусочков, и на их генерацию было бы легко повлиять игровыми же средствами.
Ну да, согласен, это создаёт проблемы баланса для игры, нацеленной на сложное прохождение, но во многих играх есть упрощённый режим "песочницы", где игрок может творить всё что захочет, и иметь такую фичу в песочнице было бы очень интересно.
Что касается кастомных карт - в таких играх, как Minecraft и Terraria, игроки любят создавать свои собственные карты, нацеленные на решение головоломок, повествование или что-то другое, и делиться этими картами с другими пользователями. И это несмотря на то, что миры в этих играх генерируются рандомно. В тот же Minecraft добавили режим Adventure специально для пользовательских карт, который ограничивает использование инструментов, чтобы игрок не мог случайно сломать карту-головоломку раньше времени. Думаю, в кастомные карты играют в том числе потому, что генератор карт ограничен шаблонами/правилами и не может сгенерировать абсолютно любую карту, т.е. ты не можешь встретить на стандартной карте то, что может сделать на кастомной карте другой игрок. И чем проще и доступнее инструменты редактирования карт, тем больше мотивации у игроков создавать что-то своё и делиться этим с другими игроками, а это расширяет и поддерживает коммьюнити игры даже если разработчик прекратил поддержку игры.
А с возможностью влиять на результат генерации, игрок может создавать новый интересный контент самому себе, потому что даже если бродить по собственному дому скучно, искать по миру деревни с комбинациями своих домов может быть интересно. Просто потому что результат генерации не всегда предсказуем и может создавать неожиданные вещи, о возможности существования которых ты даже не догадывался. Ну, зависит от того, как работает генератор...
>>798424
Треда пока нет. У меня много абстрактных идей (как пример выше) и мало конкретных деталей, чтобы сделать конкретную игру, да и идеи зачастую слишком сложны для меня, чтобы сесть и реализовать за пару дней, а долго работать я не умею - отсутствие результатов вгоняет в депрессию. Были попытки, есть какие-то наброски, но, например, последний месяц я всё забросил и почти ничего не сделал, только играю и сижу в интернете, каждый день думая "завтра точно что-нибудь сделаю". Завидую людям, которые месяцами каждый день работают над своим проектом и получают существенный результат...
>>Редактор карт
>О, спасибо, пойду заценю.
Есть ещё такой: https://github.com/deepnight/ldtk
Но я о нём буквально этой ночью узнал, пока искал ссылки на Tiled, о котором давно знаю и даже немного щупал.
>Если будут головоломки, придется добавлять неразрушаемые стены
В зависимости от типа головоломки, стены можно переключить в разрушаемые после решения головоломки игроком. Либо сделать их очень прочными, чтобы игроку было лень долбить их, но всё-таки оставалась возможность пробиться грубой силой, если мозгов не хватает решить головоломку умом. Либо эти супер прочные стены может пробить только супер оружие с ограниченным боезапасом, и игроку нужно думать, стоит ли тратить заряды. А самое весёлое, если сокровище за стеной хрупкое и испортится, если пробить стену силой или попасться в скрытую за стеной ловушку...
>Это делается один раз в начале.
При запуске игры? Или у разработчика игры? Я просто не понимаю, зачем делать на компе пользователя то, что можно легко рассчитать заранее и хранить только пару чисел, как с хот-спотом курсора:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.cursor.hotspot
>Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Правильно, геймплей важнее, особенно для рогалика.
>Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий".
Почему? По-моему, свобода интереснее.
>Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты.
Я правильно понимаю, что подземелья генерируются рандомно, а редактор карт тебе нужен для дизайна комнат, которые будут примерно одинаковыми, только в разных местах и в разном количестве? Тогда будет в тему одна моя идея, которую я уже несколько лет обдумываю. Идея в том, чтобы игрок имел возможность повлиять на результат генерации игрового мира какими-либо внутриигровыми средствами, т.е. как минимум без модификации игровых файлов сторонними инструментами.
Проще всего объяснить на примере. Вот в Minecraft есть деревни - это случайно генерируемые структуры, в которых форма улиц и число домов полностью случайно, а дома захардкожены разработчиками и имеют всего несколько форм, которые легко запомнить и узнать. То есть даже в одной деревне может быть два совершенно одинаковых дома, но сложно найти две полностью одинаковых деревни. Игрок, при желании, может создать модификацию для игры, которая добавит какие-то новые виды домов или структур в генерацию деревень, и игра будет строить эти новые дома в новых деревнях по мере путешествия игрока по миру. Но делать модификации - сложно, это отдельный от игры набор инструментов, которые нужно где-то достать и потом обучаться им. Что, если бы игрок мог прямо в игре построить домик и каким-то образом зарегистрировать его для генерации в новых деревнях того же мира? С какими-нибудь реками и горами такой трюк не пройдёт, потому что они описываются математически, а вот деревни составляются из готовых кусочков, и на их генерацию было бы легко повлиять игровыми же средствами.
Ну да, согласен, это создаёт проблемы баланса для игры, нацеленной на сложное прохождение, но во многих играх есть упрощённый режим "песочницы", где игрок может творить всё что захочет, и иметь такую фичу в песочнице было бы очень интересно.
Что касается кастомных карт - в таких играх, как Minecraft и Terraria, игроки любят создавать свои собственные карты, нацеленные на решение головоломок, повествование или что-то другое, и делиться этими картами с другими пользователями. И это несмотря на то, что миры в этих играх генерируются рандомно. В тот же Minecraft добавили режим Adventure специально для пользовательских карт, который ограничивает использование инструментов, чтобы игрок не мог случайно сломать карту-головоломку раньше времени. Думаю, в кастомные карты играют в том числе потому, что генератор карт ограничен шаблонами/правилами и не может сгенерировать абсолютно любую карту, т.е. ты не можешь встретить на стандартной карте то, что может сделать на кастомной карте другой игрок. И чем проще и доступнее инструменты редактирования карт, тем больше мотивации у игроков создавать что-то своё и делиться этим с другими игроками, а это расширяет и поддерживает коммьюнити игры даже если разработчик прекратил поддержку игры.
А с возможностью влиять на результат генерации, игрок может создавать новый интересный контент самому себе, потому что даже если бродить по собственному дому скучно, искать по миру деревни с комбинациями своих домов может быть интересно. Просто потому что результат генерации не всегда предсказуем и может создавать неожиданные вещи, о возможности существования которых ты даже не догадывался. Ну, зависит от того, как работает генератор...
>>798424
>А ты тоже что-то пилишь? Есть тред тут?
Треда пока нет. У меня много абстрактных идей (как пример выше) и мало конкретных деталей, чтобы сделать конкретную игру, да и идеи зачастую слишком сложны для меня, чтобы сесть и реализовать за пару дней, а долго работать я не умею - отсутствие результатов вгоняет в депрессию. Были попытки, есть какие-то наброски, но, например, последний месяц я всё забросил и почти ничего не сделал, только играю и сижу в интернете, каждый день думая "завтра точно что-нибудь сделаю". Завидую людям, которые месяцами каждый день работают над своим проектом и получают существенный результат...
>>798439
Tiled это просто великолепная прога, спасибо тебе огромное!
Аналогичную штуку внутри юнити я бы пилил десять тыщ лет, а с ней разобрался вчера за пол дня.
Я экспортирую карту и палитру как джесоны, потом читаю карту, ищу соответствующие тайлы в в палитре по id, а в них, в свойствах уже написано какой мне нужно заспавнить предмет.
Так же я хочу сделать чтобы палитра автоматически обновлялась когда я добавляю новые предметы в игру. Но есть одна проблема.
Нужно как-то связать предмет и тайл палитры.
Но при этом не по порядковому номеру предмета в моей эксель таблице, так как тогда, либо при добавлении нового предмета все будет смещаться, либо мне нужно будет добавлять его в конец, из за чего все предметы в таблице будут идти вперемешку (а не по типам, как это сейчас сделано).
Таким образом логичнее всего как-то привязать id тайла в палитре к названию предмета, это решит все проблемы.
id тайла это число. Я конвертирую строку с именем в массив байтов, а потом в число, но c# не способен поддерживать такие большие числа. Там 20+ знаков, это не то что в int, и в long не влезает.
Как быть? Есть какие-нибудь способы шифровать строку в число так чтобы оно не получалось таким огромным?
Tiled это просто великолепная прога, спасибо тебе огромное!
Аналогичную штуку внутри юнити я бы пилил десять тыщ лет, а с ней разобрался вчера за пол дня.
Я экспортирую карту и палитру как джесоны, потом читаю карту, ищу соответствующие тайлы в в палитре по id, а в них, в свойствах уже написано какой мне нужно заспавнить предмет.
Так же я хочу сделать чтобы палитра автоматически обновлялась когда я добавляю новые предметы в игру. Но есть одна проблема.
Нужно как-то связать предмет и тайл палитры.
Но при этом не по порядковому номеру предмета в моей эксель таблице, так как тогда, либо при добавлении нового предмета все будет смещаться, либо мне нужно будет добавлять его в конец, из за чего все предметы в таблице будут идти вперемешку (а не по типам, как это сейчас сделано).
Таким образом логичнее всего как-то привязать id тайла в палитре к названию предмета, это решит все проблемы.
id тайла это число. Я конвертирую строку с именем в массив байтов, а потом в число, но c# не способен поддерживать такие большие числа. Там 20+ знаков, это не то что в int, и в long не влезает.
Как быть? Есть какие-нибудь способы шифровать строку в число так чтобы оно не получалось таким огромным?
>>798394
Спасибо, довольно интересная система. Правда для того чтобы мне сейчас ее внедрить, боюсь придется слишком много всего перелопатить.
Спасибо, довольно интересная система. Правда для того чтобы мне сейчас ее внедрить, боюсь придется слишком много всего перелопатить.
>>798439
Тема с кастомными структурами прикольная.
Игроки смогут передавать друг другу самодельные паки ульрахардкорных комнат)
Но добавлять это надо в са-амый последний момент, когда будет уже собрана какая-то аудитория.
Тема с кастомными структурами прикольная.
Игроки смогут передавать друг другу самодельные паки ульрахардкорных комнат)
Но добавлять это надо в са-амый последний момент, когда будет уже собрана какая-то аудитория.
>>798478
В результате я пришел к тому, что я перевожу строку в массив байтов, после чего каждый байт возвожу в квадрат,
умножаю на его номер в массиве,
умножаю на длину массива,
умножаю на предыдущий байт,
умножаю на следующий байт.
Все это суммирую.
На выходе получается 8-значное число.
Это очень тупо, такая последовательность операций была подобрана перебором без какой-либо логики, но на большее я кажется не способен.
Я прогнал через этот метод массив рандомных строк от 3 до 15 символов, что показало результат 1 повторение на ~20 000.
Мне этого скорее всего хватит, но я недоволен. Я хочу метод который будет безошибочно работать.
Скорее всего, я сейчас заведу в таблице еще один столбец в который просто буду вбивать эти Id вручную.
В результате я пришел к тому, что я перевожу строку в массив байтов, после чего каждый байт возвожу в квадрат,
умножаю на его номер в массиве,
умножаю на длину массива,
умножаю на предыдущий байт,
умножаю на следующий байт.
Все это суммирую.
На выходе получается 8-значное число.
Это очень тупо, такая последовательность операций была подобрана перебором без какой-либо логики, но на большее я кажется не способен.
Я прогнал через этот метод массив рандомных строк от 3 до 15 символов, что показало результат 1 повторение на ~20 000.
Мне этого скорее всего хватит, но я недоволен. Я хочу метод который будет безошибочно работать.
Скорее всего, я сейчас заведу в таблице еще один столбец в который просто буду вбивать эти Id вручную.
464 Кб, 1071x921Довел до ума импорт карт из Tiled. Теперь перерисовываю там все структуры.
Переписал базы данных. До этого данные импортировались из экселей при каждом рестарте. Потому что мне было лень.
Теперь импорт происходит отдельно, при нажатии кнопки в эдиторе, а при старте игры данные просто распределяются по словарям. (Юнити не способен сериализовать словарь и хранить сохранять его между сессиями)
Это сэкономило всего пол секунды при запуске, но теперь все сделано намного более правильно и основательно.
Переписал базы данных. До этого данные импортировались из экселей при каждом рестарте. Потому что мне было лень.
Теперь импорт происходит отдельно, при нажатии кнопки в эдиторе, а при старте игры данные просто распределяются по словарям. (Юнити не способен сериализовать словарь и хранить сохранять его между сессиями)
Это сэкономило всего пол секунды при запуске, но теперь все сделано намного более правильно и основательно.
Времени сейчас ни на что не хватает. Мне еще надо параллельно писать статью по Истории Искусств для института и доделывать курс на скиллбоксе. Полное говно кстати. Купил курс мидл разраба на юинити и был весьма разочарован. В анотации значилось, что там ~100 видосов с уроками, плюс препод который дз проверяет. По поводу видосов, их реально столько, но в это число входят так же 10-секундные интро, и просто коротенькие видосики по 1-2 минуты, а большая часть рассматриваемого материала вызывает вопрос "Если это мидл, то чем тогда занимаются на джуниор курсе?"
На счет препода, он тоже действительно есть, но пользы от него не много. Все дз либо слишком простое, чтобы у него что-то спрашивать по этому поводу, либо, если попадается что-то реально запарное он отвечает что-то по типу "ну вот тебе документация на 8 листах, ты там почитай, разберись как-нибудь". Не сказать чтобы это было полное 0/10. Нет. Кое какая инфа реально полезная. Но не за 50 же косарей!
Короче не советую покупать такие курсы, смотрите видосы на ютубе, живите молодостью и энергией.
На счет препода, он тоже действительно есть, но пользы от него не много. Все дз либо слишком простое, чтобы у него что-то спрашивать по этому поводу, либо, если попадается что-то реально запарное он отвечает что-то по типу "ну вот тебе документация на 8 листах, ты там почитай, разберись как-нибудь". Не сказать чтобы это было полное 0/10. Нет. Кое какая инфа реально полезная. Но не за 50 же косарей!
Короче не советую покупать такие курсы, смотрите видосы на ютубе, живите молодостью и энергией.
Написал еще одну небольшую систему.
Система пачек. Мобы должны спавниться пачками. Например, когда спавнится торговец рядом с ним должны спавниться два охранника, а так же пещерный осел, груженый товаром.
Информация о составе пачек хранится в отдельной эксель таблице.
Система пачек. Мобы должны спавниться пачками. Например, когда спавнится торговец рядом с ним должны спавниться два охранника, а так же пещерный осел, груженый товаром.
Информация о составе пачек хранится в отдельной эксель таблице.
>>796015 (OP)
Слушай, а можешь накидать каких-нибудь гайдов по ецс? Сейчас учу его и после монобехов очень сложно идёт.
Слушай, а можешь накидать каких-нибудь гайдов по ецс? Сейчас учу его и после монобехов очень сложно идёт.
>>799320
Вообще я смотрел вот этого чела.
https://www.youtube.com/watch?v=Z9-WkwdDoNY&ab_channel=CodeMonkey
Но, так или иначе большую часть инфы я брал из документации а в некоторых вещах я до сих пор вообще не разбираюсь, так как их не использовал.
От себя могу дать несколько советов.
Сделай класс с кучей экстеншен методов для сущностей и для других элементов ецс. Нужно часто запрашивать какой-то параметр из компонента, например координаты из PositionComponent? Сразу делай экстеншен entity.GetPosition(). Иначе если каждый раз вызывать World.DefaultGameobjectInjectionWorld и так далее, можно себе клавиатуру разломать.
Сначала я хотел создавать на основе эксель таблицы List<IComponentData> в котором будут лежать все нужные компоненты, а потом через foreach добавлять их на сущность. Так вот, судя по всему это невозможно. Ты не можешь выполнить приведение типов IComponentData к конкретному типу компонента.
Дичайше сгорела жепа с этого в свое время. И такое будет на каждом шагу
Вообще я смотрел вот этого чела.
https://www.youtube.com/watch?v=Z9-WkwdDoNY&ab_channel=CodeMonkey
Но, так или иначе большую часть инфы я брал из документации а в некоторых вещах я до сих пор вообще не разбираюсь, так как их не использовал.
От себя могу дать несколько советов.
Сделай класс с кучей экстеншен методов для сущностей и для других элементов ецс. Нужно часто запрашивать какой-то параметр из компонента, например координаты из PositionComponent? Сразу делай экстеншен entity.GetPosition(). Иначе если каждый раз вызывать World.DefaultGameobjectInjectionWorld и так далее, можно себе клавиатуру разломать.
Сначала я хотел создавать на основе эксель таблицы List<IComponentData> в котором будут лежать все нужные компоненты, а потом через foreach добавлять их на сущность. Так вот, судя по всему это невозможно. Ты не можешь выполнить приведение типов IComponentData к конкретному типу компонента.
Дичайше сгорела жепа с этого в свое время. И такое будет на каждом шагу
>>799385
Ой, забыл сказать, что я совсем нубка и вкатываюсь в юнити сразу через ецс, причем через конкретный LeoECS, поэтому мало что понял из того, что ты написал. Но за видео спасибо, добра.
Игра, кстати, классная, надеюсь, выпустишь ее когда-нибудь в сторы и можно будет позалипать.
Ой, забыл сказать, что я совсем нубка и вкатываюсь в юнити сразу через ецс, причем через конкретный LeoECS, поэтому мало что понял из того, что ты написал. Но за видео спасибо, добра.
Игра, кстати, классная, надеюсь, выпустишь ее когда-нибудь в сторы и можно будет позалипать.
>>799442
О, ничего себе. Возможно это и правильное решение, LeoEcs как я слышал, позиционируется как мультидвижковая вещь, так что есть вероятность что она проще и не такая кривая как unityEcs.
О, ничего себе. Возможно это и правильное решение, LeoEcs как я слышал, позиционируется как мультидвижковая вещь, так что есть вероятность что она проще и не такая кривая как unityEcs.
>>799442
А за теплые пожелания - спасибо.
А за теплые пожелания - спасибо.
Я сделал странствующего торговца!
Торговец будет спавниться в пещерах в сопровождении охранника и навьюченного пещерного осла.
Для этого был написан скрипт, позволяющий создавать гибкие пачки мобов с кастомными параметрами, прописывая все в екселе. Например этот мини-караван описывается строкой на пике.
Торговец носит на голове кипу извините и обменивает товар в правой руке на куски золотой руды. При попытке атаковать его, торговец моментально телепортируется вон из подземелья, забирая с собой своего осла, а охранник бросается тебя месить.
Так же можно заметить, что члены каравана не разбредаются далеко друг от друга, а тусуются примерно в одном месте.
Это происходит благодаря системе отрядов. Мобы объединенные в отряды везде следуют за лидером отряда, стараясь не отдаляться от него больше чем на 3 клетки. Та будет работать и система спутников игрока.
Правда, в дальнейшем я уже вижу несколько проблем. Что делать если один из членов отряда отстал или вообще оказался отрезан от лидера. Лидер что, должен его ждать? Или телепортировать к себе? Или забить и двигаться дальше? Непонятно.
Торговец будет спавниться в пещерах в сопровождении охранника и навьюченного пещерного осла.
Для этого был написан скрипт, позволяющий создавать гибкие пачки мобов с кастомными параметрами, прописывая все в екселе. Например этот мини-караван описывается строкой на пике.
Торговец носит на голове кипу извините и обменивает товар в правой руке на куски золотой руды. При попытке атаковать его, торговец моментально телепортируется вон из подземелья, забирая с собой своего осла, а охранник бросается тебя месить.
Так же можно заметить, что члены каравана не разбредаются далеко друг от друга, а тусуются примерно в одном месте.
Это происходит благодаря системе отрядов. Мобы объединенные в отряды везде следуют за лидером отряда, стараясь не отдаляться от него больше чем на 3 клетки. Та будет работать и система спутников игрока.
Правда, в дальнейшем я уже вижу несколько проблем. Что делать если один из членов отряда отстал или вообще оказался отрезан от лидера. Лидер что, должен его ждать? Или телепортировать к себе? Или забить и двигаться дальше? Непонятно.
14,3 Мб, 1013x740Последнюю неделю я работал над оптимизацией и переписывал систему искусственного интеллекта так чтобы она могла работать с отрядами и была по возможности джобифицирована.
Сколько же я страдал. Этот чертов Unity DOTS постоянно выдает ошибки, текст которых вообще не имеет никакого отношения как тому что происходит на самом деле. Ецсные функции имеют кучу неочевидных ограничений, про которые надо каждый раз индивидуально гуглить. Я просто чуть головой не поехал.
Так или иначе, вот замес 25 на 25 человек, который не так уж и сильно лагает, а большинство нагрузки создает создание сообщений в логе и рендеринг луж крови (похоже я их реально потом буду в одну текстуру запекать и отдельно рендерить). Правда я отключил пока систему морали, так что все юниты дерутся до конца.
Сколько же я страдал. Этот чертов Unity DOTS постоянно выдает ошибки, текст которых вообще не имеет никакого отношения как тому что происходит на самом деле. Ецсные функции имеют кучу неочевидных ограничений, про которые надо каждый раз индивидуально гуглить. Я просто чуть головой не поехал.
Так или иначе, вот замес 25 на 25 человек, который не так уж и сильно лагает, а большинство нагрузки создает создание сообщений в логе и рендеринг луж крови (похоже я их реально потом буду в одну текстуру запекать и отдельно рендерить). Правда я отключил пока систему морали, так что все юниты дерутся до конца.
Изучил немножко функции эдитора в юнити и написал небольшой дебагер для отрядов. Все члены отряды связаны линиями с лидером, и обведены цветом зависящим от Id отряда, а рядом еще панель на которой можно через поиск найти любой отряд и инфу про него, сколько в нем существ, с какие отряды для него враждебны и т.д.
Через это я вывел Правило геймдева номер два (первое было про консольные команды) : если есть какой-то зарытый в коде функционал который ты не можешь напрямую контролировать - не ленись, пиши EditorWindow, который будет тебе его показывать.
Написал аналогичный скрипт для дебага тайлов, содержимое которых я напрямую тоже не мог увидеть.
Через это я вывел Правило геймдева номер два (первое было про консольные команды) : если есть какой-то зарытый в коде функционал который ты не можешь напрямую контролировать - не ленись, пиши EditorWindow, который будет тебе его показывать.
Написал аналогичный скрипт для дебага тайлов, содержимое которых я напрямую тоже не мог увидеть.
Интересно, конечно, но вот эти ломаные не трушные не пиксельперфект пиксели всегда выглядят очень неприятно и неопрятно.
Планируешь что-то с этим делать или так и останется?
Планируешь что-то с этим делать или так и останется?
Анон, это тот другой анон, что спрашивал тебя про организацию тайлов (спасибо за ответ кстати). Просто зашел сказать, что ты офигенно крут и у тебя отлично выходит!
А я решил пойти путем слабоумия и отваги и пилю на monogame и попутно осваиваю ecs в интерпретации monogame.extended
А я решил пойти путем слабоумия и отваги и пилю на monogame и попутно осваиваю ecs в интерпретации monogame.extended
>>796015 (OP)
Самый добрый и хороший тред на дваче.
Самый добрый и хороший тред на дваче.
>>803014
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
>>803014
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
>>803014
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
Согласен, надо бы это пофиксить. Есть два способа. Можно просто все объекты выровнять так как разрешение везде одинаковое. А еще в юнити есть такой аддон Pixel Perfect Camera, но я что-то пока не понял, как ее нормально настроить.
>>803063
Разобрался с пиксель перфект камерой.
Можно отцентровать пиксели по сетке используя sapping (пик 1)
А можно сделать настоящий пиксель перфект (пик 2)
Прикольный эффект конечно, но, мне кажется, для того чтобы его использовать нужно спрайты рисовать немного в другом стиле, без обводок. При этом этот эффект был бы уместнее в игре где что-то двигается в реальном времени. Когда пиксель перфектные объекты постоянно крутятся и перемещаются их очертания лучше различаются.
Например в Noita, где это как раз используется, движущиеся враги выглядят шикарно, а вот когда какой-нибудь пузырек с зельем и так состоящий из 8 пикселей падает на бок по углом 30* и просто лежит, он вообще теряет всяческие очертания.
Разобрался с пиксель перфект камерой.
Можно отцентровать пиксели по сетке используя sapping (пик 1)
А можно сделать настоящий пиксель перфект (пик 2)
Прикольный эффект конечно, но, мне кажется, для того чтобы его использовать нужно спрайты рисовать немного в другом стиле, без обводок. При этом этот эффект был бы уместнее в игре где что-то двигается в реальном времени. Когда пиксель перфектные объекты постоянно крутятся и перемещаются их очертания лучше различаются.
Например в Noita, где это как раз используется, движущиеся враги выглядят шикарно, а вот когда какой-нибудь пузырек с зельем и так состоящий из 8 пикселей падает на бок по углом 30* и просто лежит, он вообще теряет всяческие очертания.
>>803245
Только вот нафига крутить пиксели? Обычно же это делается анимацией. Нарисовал анимацию летящей бомбочки - герой кидает бомбочку, бомбочка летит к цели, проигрывается анимация полёта бомбочки. Ты крутишь спрайты трансформом чтоли?
Только вот нафига крутить пиксели? Обычно же это делается анимацией. Нарисовал анимацию летящей бомбочки - герой кидает бомбочку, бомбочка летит к цели, проигрывается анимация полёта бомбочки. Ты крутишь спрайты трансформом чтоли?
>>803258
Да, у меня процедурные анимации сделанные кручением и перемещением трансформа.
Безусловно, если бы условная бомбочка была уникальным объектом, и игрок жал на кнопку "B" чтобы выполнить действие "бросок бомбы" стоило бы нарисовать нормальную анимацию, где в каждом кадре определенный поворот этой бомбы и чтобы еще там фитиль тлел и искры летели.
Дело в том, что в моей игре игрок может кинуть не только бомбу, но и любой другой предмет. В теории его самого могут взять и кинуть. Очевидно, что нарисовать отдельную анимацию вращения, для каждого предмета в игре я не могу, так что единственное решение - крутить трансформы.
Это что касается анимаций.
Что больше бросается в глаза - то что предметы на полу повернуты по рандомным углом. В принципе это сделано с одной единственной целью: если на клетке будет лежать несколько предметов, их все будет видно. Предметы не будут скрывать друг друга.
В других играх, особенно старых, это делалось по-другому.
Когда на клетке лежит более одного предмета, в углу клетки рисовалась звездочка, или обводка вокруг нее. В дварф фортресс клетка начинает мигать, отображая по кругу разные предметы которые на ней находятся. В графическом Адоме вроде рисовалася специальный спрайт кучи предметов.
Все эти решения мне показались довольно стремными, поэтому я решил сделать так как сделал. У разных людей восприятие немного отличается, меня лично повернутые пиксели особо не триггерят, так что я об этом как-то и не задумывался...
Да, у меня процедурные анимации сделанные кручением и перемещением трансформа.
Безусловно, если бы условная бомбочка была уникальным объектом, и игрок жал на кнопку "B" чтобы выполнить действие "бросок бомбы" стоило бы нарисовать нормальную анимацию, где в каждом кадре определенный поворот этой бомбы и чтобы еще там фитиль тлел и искры летели.
Дело в том, что в моей игре игрок может кинуть не только бомбу, но и любой другой предмет. В теории его самого могут взять и кинуть. Очевидно, что нарисовать отдельную анимацию вращения, для каждого предмета в игре я не могу, так что единственное решение - крутить трансформы.
Это что касается анимаций.
Что больше бросается в глаза - то что предметы на полу повернуты по рандомным углом. В принципе это сделано с одной единственной целью: если на клетке будет лежать несколько предметов, их все будет видно. Предметы не будут скрывать друг друга.
В других играх, особенно старых, это делалось по-другому.
Когда на клетке лежит более одного предмета, в углу клетки рисовалась звездочка, или обводка вокруг нее. В дварф фортресс клетка начинает мигать, отображая по кругу разные предметы которые на ней находятся. В графическом Адоме вроде рисовалася специальный спрайт кучи предметов.
Все эти решения мне показались довольно стремными, поэтому я решил сделать так как сделал. У разных людей восприятие немного отличается, меня лично повернутые пиксели особо не триггерят, так что я об этом как-то и не задумывался...
>>803068
Я на самом деле начинал несколько раз на юнити и годоте, но каждый раз ловил себя на том, что по сути писал игру, которая к движку вообще никак не привязана. Как бы описать так... Я создавал набор классов, стейт машины, движок событий, движок игровой логики, а потом это все пытался впихнуть в юнити, или годот и получалось как-то криво. Как бы моя абстрактная игра отдельно, и движок отдельно.
Думаю, это привычка. Я много писал под флэш, когда он был популярен. И прилично на pixijs. Там и там, нужно очень четко разделять игровую логику и вывод графики имхо. Иначе получишь неуправляемое говно на выходе.
Ну и мне нравиться C#, а выбор движков на шарпе не очень большой.
]Говоря откровенно, я надеюсь, если я осилю доделать игру на моногейме, мне это поможет осознать, каких инструментов мне реально не хватает.
Как то так.
Я на самом деле начинал несколько раз на юнити и годоте, но каждый раз ловил себя на том, что по сути писал игру, которая к движку вообще никак не привязана. Как бы описать так... Я создавал набор классов, стейт машины, движок событий, движок игровой логики, а потом это все пытался впихнуть в юнити, или годот и получалось как-то криво. Как бы моя абстрактная игра отдельно, и движок отдельно.
Думаю, это привычка. Я много писал под флэш, когда он был популярен. И прилично на pixijs. Там и там, нужно очень четко разделять игровую логику и вывод графики имхо. Иначе получишь неуправляемое говно на выходе.
Ну и мне нравиться C#, а выбор движков на шарпе не очень большой.
]Говоря откровенно, я надеюсь, если я осилю доделать игру на моногейме, мне это поможет осознать, каких инструментов мне реально не хватает.
Как то так.
>>803314
Твой опыт работы с разными штуками несравним с моим, так что, в таком случае, monogame и правда может быть хорошим выбором.
Я никогда не работал ни на чем кроме юнити, и ни на чем кроме С#, так что даже не могу сказать, нравится мне этот язык или нет)
На счет юнити - очевидный плюс в том, что не так много приходится велосипедить. Вот я например сейчас делаю перевод игры на русский язык не особо актуальная задача, но мне захотелось. Зашел в гугл и вот, пожалуйста: unity localization package. И куча документации к нему. Посидел один вечер и можно сказать, локализация уже готова.
Другое дело, что все эти многочисленные паки и ассеты бывают довольно кривыми. Если в самом юнити полно багов, то там и подавно. Баг который я создал сам я могу пофиксить, а вот искать ошибку допущенную каким-то сумрачным гением писавшим ассет и зарытую в глубине абсолютно неизвестного мне кода это полная жесть. В некоторых случаях и правда проще написать все самому.
Твой опыт работы с разными штуками несравним с моим, так что, в таком случае, monogame и правда может быть хорошим выбором.
Я никогда не работал ни на чем кроме юнити, и ни на чем кроме С#, так что даже не могу сказать, нравится мне этот язык или нет)
На счет юнити - очевидный плюс в том, что не так много приходится велосипедить. Вот я например сейчас делаю перевод игры на русский язык не особо актуальная задача, но мне захотелось. Зашел в гугл и вот, пожалуйста: unity localization package. И куча документации к нему. Посидел один вечер и можно сказать, локализация уже готова.
Другое дело, что все эти многочисленные паки и ассеты бывают довольно кривыми. Если в самом юнити полно багов, то там и подавно. Баг который я создал сам я могу пофиксить, а вот искать ошибку допущенную каким-то сумрачным гением писавшим ассет и зарытую в глубине абсолютно неизвестного мне кода это полная жесть. В некоторых случаях и правда проще написать все самому.
32x32Зацените, написал небольшую заметку про процедурные тексты и
про то чем отличается создание такого текста на английском и на русском.
https://vk.com/@katabasys-lokalizaciya-procedurnyh-tekstov
про то чем отличается создание такого текста на английском и на русском.
https://vk.com/@katabasys-lokalizaciya-procedurnyh-tekstov
Вы могли подумать что меня съел пещерный бык, но нет, я просто решил дать себе некоторый отпуск.
Я принялся за работу снова несколько дней назад и теперь работаю над генерацией подземных городов.
Наличие городов открывает огромную перспективу для усложнения всего и вся, я бы не хотел в это сильно вдаваться потому что просто не вывезу. Пока я хочу реализовать просто несколько домиков, бегающих вокруг крестьян и рынок где можно купить себе шмот, или даже приобрести раба.
Что пока получилось - смотрите на пиках. Дома в городе построены из перевязанных веревками огромных грибных ножек. Мне на первый взгляд показалось что это офигенная идея, хотя может быть сейчас не особо понятно что это такое...
Я принялся за работу снова несколько дней назад и теперь работаю над генерацией подземных городов.
Наличие городов открывает огромную перспективу для усложнения всего и вся, я бы не хотел в это сильно вдаваться потому что просто не вывезу. Пока я хочу реализовать просто несколько домиков, бегающих вокруг крестьян и рынок где можно купить себе шмот, или даже приобрести раба.
Что пока получилось - смотрите на пиках. Дома в городе построены из перевязанных веревками огромных грибных ножек. Мне на первый взгляд показалось что это офигенная идея, хотя может быть сейчас не особо понятно что это такое...
Так же пришлось дополнительно усложнить мою базу данных, сейчас я использую следующие таблицы:
-базовая таблица предметов.
Содержит собственно предметы а так же "тела" существ.
-таблица модифицированных предметов.
В ней находятся ссылки на базовые предметы и набор модификаций, которые я могу вносить. Например там находится Торговец и прописано что это Человек у которого в руке весы, на голове кипа, на нем висит тег торговца и так далее..
-таблица пачек.
В ней информация об отрядах существ в виде ссылок на таблицу модифицированных объектов: Торговый Караван это 1 Торговец + 1 Осел + 2 Охранника.
-таблица структур.
В ней инфа о комнатах в виде ссылки на карту комнаты с деланную в Tiled map editor и в некоторых случаях ссылка на специальное существо котрое 100% должно быть заспавнено в этой комнате. Как например торговец в магазине.
-таблица гиперструктур
В ней описываются структуры включающие в себя другие структуры. Например города. скорее всего в ней будут только данные о частоте их спавна, а все остальное будет прописано кодом. Увы, гиперструктуры скорее всего будут слишком разные чтобы их параметры задавать обобщенно через эксель.
-таблица локализации. Это не эксель таблица, а штука прямо внутри юнити, в ней всякие переводы.
От этого конечно голова кругом идет, но других вариантов нет, все нужно тонко контролировать.
-базовая таблица предметов.
Содержит собственно предметы а так же "тела" существ.
-таблица модифицированных предметов.
В ней находятся ссылки на базовые предметы и набор модификаций, которые я могу вносить. Например там находится Торговец и прописано что это Человек у которого в руке весы, на голове кипа, на нем висит тег торговца и так далее..
-таблица пачек.
В ней информация об отрядах существ в виде ссылок на таблицу модифицированных объектов: Торговый Караван это 1 Торговец + 1 Осел + 2 Охранника.
-таблица структур.
В ней инфа о комнатах в виде ссылки на карту комнаты с деланную в Tiled map editor и в некоторых случаях ссылка на специальное существо котрое 100% должно быть заспавнено в этой комнате. Как например торговец в магазине.
-таблица гиперструктур
В ней описываются структуры включающие в себя другие структуры. Например города. скорее всего в ней будут только данные о частоте их спавна, а все остальное будет прописано кодом. Увы, гиперструктуры скорее всего будут слишком разные чтобы их параметры задавать обобщенно через эксель.
-таблица локализации. Это не эксель таблица, а штука прямо внутри юнити, в ней всякие переводы.
От этого конечно голова кругом идет, но других вариантов нет, все нужно тонко контролировать.
После полутора лет разработки, Finally, Doors.
На этот раз нормальные. Правда кнопку чтобы их закрывать я пока не придумал.
Вообще для взаимодействия с объектами я скорее всего запилю отдельное маленькое меню которое вылазит когда нажимаешь на клетку и там все функции что с ней можно сделать.
На этот раз нормальные. Правда кнопку чтобы их закрывать я пока не придумал.
Вообще для взаимодействия с объектами я скорее всего запилю отдельное маленькое меню которое вылазит когда нажимаешь на клетку и там все функции что с ней можно сделать.
19,4 Мб, 984x747Замки и ключи! Теперь все что угодно может быть защищено от взаимодействия замком.
Время реализовывать "Дверь и 12 ржавых ключей"
Время реализовывать "Дверь и 12 ржавых ключей"
>>820068
Да лааадно, слушай, я тоже гуманитарий. Программирование это скорее исключение, остальные мои интересы это живопись, философия и религиоведение.
Да лааадно, слушай, я тоже гуманитарий. Программирование это скорее исключение, остальные мои интересы это живопись, философия и религиоведение.
>>796015 (OP)
Обожаю процедурную генерацию в целом и рогалики в частности, игра выглядит отлично, я бы непременно такую купил если в финальной версии можно будет дрочить циферки.
Обожаю процедурную генерацию в целом и рогалики в частности, игра выглядит отлично, я бы непременно такую купил если в финальной версии можно будет дрочить циферки.
>>820572
Спасибо, бро. Надеюсь в будущем развить рпг составляющую, добавив больше всяких статов, а то пока есть только сила и ловкость, чего для полноценного цифрового дроча недостаточно.
Спасибо, бро. Надеюсь в будущем развить рпг составляющую, добавив больше всяких статов, а то пока есть только сила и ловкость, чего для полноценного цифрового дроча недостаточно.
>>820513
Ты ещё больше меня опустил , ведь я не могу ни в живопись ни в философию . Просто даун короче
Ты ещё больше меня опустил , ведь я не могу ни в живопись ни в философию . Просто даун короче
>>823981
Там можно выбрать других.
Я правда чуть погонял демку и такое чувство, что циклоп единственный хоть на что-то способный персонаж - остальные сразу отлетают от мышей или скелетов.
мимо
Там можно выбрать других.
Я правда чуть погонял демку и такое чувство, что циклоп единственный хоть на что-то способный персонаж - остальные сразу отлетают от мышей или скелетов.
мимо
>>823981
Это пережиток совсем старых версий. Изначально я хотел сделать рогалик про гоблинов воюющих против людей. В античную тему гоблин явно не вписывался, но мне нравился его спрайт, поэтому я решил нарисовать ему один глаз и сделать циклопом. Мб потом сделаю его рядовым противником а не гг.
Это пережиток совсем старых версий. Изначально я хотел сделать рогалик про гоблинов воюющих против людей. В античную тему гоблин явно не вписывался, но мне нравился его спрайт, поэтому я решил нарисовать ему один глаз и сделать циклопом. Мб потом сделаю его рядовым противником а не гг.
>>824015
Да, это правда. Просто те мобы за которых играет игрок имеют те же статы, что и враждебные их версии. Так как изначально гг был только циклоп я сделал его значительно сильнее остальных. Конечно, надо бы это поменять, чтобы игроку просто бонусные статы давались.
Да, это правда. Просто те мобы за которых играет игрок имеют те же статы, что и враждебные их версии. Так как изначально гг был только циклоп я сделал его значительно сильнее остальных. Конечно, надо бы это поменять, чтобы игроку просто бонусные статы давались.
ОП, смотри, я немного пишу музыку и, прочитав тред, набросал тебе тут пару треков, основываясь на ассоциациях, которые у меня вызвала игра. Я использовал сочетания аккордов, которые звучат примерно как греческая музыка. Также решил добавить электронные фишки, чтобы отразить фантастические моменты игры, как, например, чудовища.
Первый трек титульный, мог бы играть в меню. Второй для жёсткой подземки какой-нибудь. Ещё хочу написать пару лёгких и мечтательных треков для локаций под небом или встреч с людьми.
Как тебе? Какие-то вещи можно изменить, что-то добавить. Ты мог бы вставить эту музыку в демку?
Первый трек титульный, мог бы играть в меню. Второй для жёсткой подземки какой-нибудь. Ещё хочу написать пару лёгких и мечтательных треков для локаций под небом или встреч с людьми.
Как тебе? Какие-то вещи можно изменить, что-то добавить. Ты мог бы вставить эту музыку в демку?
>>824541
>>824542
Вау, это просто великолепно! Никогда бы не подумал что моя игра может вдохновить кого-то на написание музыки. Я обязательно включу твои треки в следующий билд, у меня как раз было в планах поработать над озвучкой.
Обычно, когда мне кто-то помогает, я добавляю в игру отсылку к нему в виде уникального персонажа. Таким образом появился, например, Александр, легендарный метатель ножей, в честь моего приятеля который консультировал меня на счет физики.
Так что твой персонаж будет сидеть где-нибудь в укромном уголке пещеры и играть на кифаре. Хотя судя по нику подошел бы какой-то более восточный инструмент)
>>824542
Вау, это просто великолепно! Никогда бы не подумал что моя игра может вдохновить кого-то на написание музыки. Я обязательно включу твои треки в следующий билд, у меня как раз было в планах поработать над озвучкой.
Обычно, когда мне кто-то помогает, я добавляю в игру отсылку к нему в виде уникального персонажа. Таким образом появился, например, Александр, легендарный метатель ножей, в честь моего приятеля который консультировал меня на счет физики.
Так что твой персонаж будет сидеть где-нибудь в укромном уголке пещеры и играть на кифаре. Хотя судя по нику подошел бы какой-то более восточный инструмент)
>>824541
>>824542
Вообще я и сам по себе слушаю что-то подобное, иногда под кодинг очень хорошо заходит. Мне первый и второй напомнили Lustmord использованием всяких шумов. Мне такое нравится.
Есть еще похожий по звучанию исполнитель - 721, сейчас попробую отыскать.
Будет очень круто если напишешь еще, буду рад послушать!
>>824542
Вообще я и сам по себе слушаю что-то подобное, иногда под кодинг очень хорошо заходит. Мне первый и второй напомнили Lustmord использованием всяких шумов. Мне такое нравится.
Есть еще похожий по звучанию исполнитель - 721, сейчас попробую отыскать.
Будет очень круто если напишешь еще, буду рад послушать!
>>825319
https://721albums.bandcamp.com/album/bellum-omnium-contra-omnes
Во. Не в том плане, что я хочу так же, это очень мрачно все-таки. Просто занятная вещь.
https://721albums.bandcamp.com/album/bellum-omnium-contra-omnes
Во. Не в том плане, что я хочу так же, это очень мрачно все-таки. Просто занятная вещь.
>>825314
Ахаха, спасибо тебе! Это круто. Я сам филолог по призванию и одно время увлекался античностью. Да и до сих пор часто думаю о ней.
>>825319
Да, я планирую писать дальше, пока будет писаться. Был бы рад, если бы тебе понравились какие-нибудь треки и ты использовал их.
А ты планируешь вводить квестовых персонажей? Как в Диабле первой, например.
Ахаха, спасибо тебе! Это круто. Я сам филолог по призванию и одно время увлекался античностью. Да и до сих пор часто думаю о ней.
>>825319
Да, я планирую писать дальше, пока будет писаться. Был бы рад, если бы тебе понравились какие-нибудь треки и ты использовал их.
А ты планируешь вводить квестовых персонажей? Как в Диабле первой, например.
>>825544
Не играл в Диаблу.
Боюсь, что пока на счет квестов рано говорить, может будут, но совсем примитивные, типа торговцы готовые обменять какой-то редкий но бесполезный предмет на кучу денег.
Но вот чтобы прямо с сюжетом вряд ли...
И если будут какие-то диалоги то максимум как в дарксоулс, просто с вариантами нет\да.
Не играл в Диаблу.
Боюсь, что пока на счет квестов рано говорить, может будут, но совсем примитивные, типа торговцы готовые обменять какой-то редкий но бесполезный предмет на кучу денег.
Но вот чтобы прямо с сюжетом вряд ли...
И если будут какие-то диалоги то максимум как в дарксоулс, просто с вариантами нет\да.
>>825741
Ну да, в Диабле примерно так. Квесты не сюжетные — просто стоит персонаж и говорит тебе при встрече: "Я когда-то был в той пещере и потерял там свою хуйню. Принеси, если найдёшь". Было бы очень круто сделать отсылки к античности, называя персонажей именами известных греков. Например, НПС Гесиод пашет поле и просит найти мотыгу, которую утащили те же гоблины. Или Алкей, который влюблён в Сапфо и просит найти для неё ожерелье, или что-нибудь в этом духе. Ну это просто мои маняфантазии и пожелания как фаната, ожидающего релиза :D
Ну да, в Диабле примерно так. Квесты не сюжетные — просто стоит персонаж и говорит тебе при встрече: "Я когда-то был в той пещере и потерял там свою хуйню. Принеси, если найдёшь". Было бы очень круто сделать отсылки к античности, называя персонажей именами известных греков. Например, НПС Гесиод пашет поле и просит найти мотыгу, которую утащили те же гоблины. Или Алкей, который влюблён в Сапфо и просит найти для неё ожерелье, или что-нибудь в этом духе. Ну это просто мои маняфантазии и пожелания как фаната, ожидающего релиза :D
>>818751
планируешь ли редактор уровней ? чтобы ноны могли собирать левелы и давать проходить друг другу
планируешь ли редактор уровней ? чтобы ноны могли собирать левелы и давать проходить друг другу
>>826758
Ух, только что вернулся из путешествия к друзьям в глухую деревню. Завтра примусь за работу!
Но сначала мне нужно доделать ебучиеплоты в соседнем треде.
Ух, только что вернулся из путешествия к друзьям в глухую деревню. Завтра примусь за работу!
Но сначала мне нужно доделать ебучиеплоты в соседнем треде.
>>825969
Сейчас все комнаты делаются в Tiled Map Editor.
В теории игрок вполне может их рисовать сам, прописывать в таблице название и шанс спавна, после чего встречать их в игре.
Помню уже задавали вопрос про редактор уровней. Если людям это действительно интересно, могу к следующему билду приложить тайлсет для эдитора и инструкцию. Я был бы счастлив если бы в дальнейшем игроки сами расширяли разнообразие комнат.
Так же могу сделать специальную кнопку в меню чтобы вместо арены генерить большую кастомную карту которую ты перед этим в эдиторе нарисовал. Вроде это несложно.
Правда есть одно узкое место... Если не вдаваться в подробности то сейчас каждый элемент тайлсета соотносится с игровым объектом при помощи 4-значного буквенного ID, который, желательно, должен быть читаемым. Этого может не хватить на все предметы, всякое оружие, мобов итд, чтобы там прямо крутые уровни пилить в этом редакторе.
Хотя блин, с другой стороны если забить на читаемость, это же получается 264 уникальных айдишников. Ну ладно тогда может и норм
Сейчас все комнаты делаются в Tiled Map Editor.
В теории игрок вполне может их рисовать сам, прописывать в таблице название и шанс спавна, после чего встречать их в игре.
Помню уже задавали вопрос про редактор уровней. Если людям это действительно интересно, могу к следующему билду приложить тайлсет для эдитора и инструкцию. Я был бы счастлив если бы в дальнейшем игроки сами расширяли разнообразие комнат.
Так же могу сделать специальную кнопку в меню чтобы вместо арены генерить большую кастомную карту которую ты перед этим в эдиторе нарисовал. Вроде это несложно.
Правда есть одно узкое место... Если не вдаваться в подробности то сейчас каждый элемент тайлсета соотносится с игровым объектом при помощи 4-значного буквенного ID, который, желательно, должен быть читаемым. Этого может не хватить на все предметы, всякое оружие, мобов итд, чтобы там прямо крутые уровни пилить в этом редакторе.
Хотя блин, с другой стороны если забить на читаемость, это же получается 264 уникальных айдишников. Ну ладно тогда может и норм
>>827072
А можно сделать так чтобы анонс мог прописывать свои квесты ? Прописывать диалоги разрбрасыват предметы квестовые чтобы сделать историю на движке игры. Прописывать кастомные анимации. Допустим моб подходит далее что то говорит далее дает вещь далее уходит. И так далее.
А можно сделать так чтобы анонс мог прописывать свои квесты ? Прописывать диалоги разрбрасыват предметы квестовые чтобы сделать историю на движке игры. Прописывать кастомные анимации. Допустим моб подходит далее что то говорит далее дает вещь далее уходит. И так далее.
>>827443
Ну об этом пока точно рано говорить)
Квесты я пока еще вообще не реализовал.
К тому же, рогалики это все-таки не про сделанные вручную истории... Погонять рукотворную карту с испытаниями это прикольно, но то что ты описываешь как-то уже чересчур сложно
Ну об этом пока точно рано говорить)
Квесты я пока еще вообще не реализовал.
К тому же, рогалики это все-таки не про сделанные вручную истории... Погонять рукотворную карту с испытаниями это прикольно, но то что ты описываешь как-то уже чересчур сложно
>>827444
Ну такой рогалик Скайрим сделать мне кажется интереснее чем просто рубку монстров.
Ну такой рогалик Скайрим сделать мне кажется интереснее чем просто рубку монстров.
>>827072
Если буквы, то String? Если String, то можно ведь строки любой длины использовать. Конечно, сравнивать строки - затратно, но у тебя и так строки используются. Или внутри какая-то оптимизация именно для 4 символов? Сомневаюсь, что ограничение на 4 символа имеет какой-то смысл, в том числе по производительности.
>при помощи 4-значного буквенного ID
Если буквы, то String? Если String, то можно ведь строки любой длины использовать. Конечно, сравнивать строки - затратно, но у тебя и так строки используются. Или внутри какая-то оптимизация именно для 4 символов? Сомневаюсь, что ограничение на 4 символа имеет какой-то смысл, в том числе по производительности.
>>827444
Почему же, вполне может быть. Пример: в Shattered Pixel Dungeon есть несколько квестов, которые генерируются на определённых уровнях. Диалоги фиксированные, награда тоже, но искать NPC и делать квест нужно на процедурной карте с рандомным шмотом и противниками. Есть другой форк Pixel Dungeon, в котором, вроде бы, пошли ещё дальше, но я не играл и не знаю точно.
В целом, не вижу проблемы сделать рандомные квесты от рандомно находимых в подземелье NPC. Может, это редко реализуют, но для разнообразия, я считаю, фича хорошая, не одних же монстров убивать. Кому будет скучно квесты делать, может их игнорировать, т.е. это как побочные квесты получается.
>рогалики это все-таки не про сделанные вручную истории...
Почему же, вполне может быть. Пример: в Shattered Pixel Dungeon есть несколько квестов, которые генерируются на определённых уровнях. Диалоги фиксированные, награда тоже, но искать NPC и делать квест нужно на процедурной карте с рандомным шмотом и противниками. Есть другой форк Pixel Dungeon, в котором, вроде бы, пошли ещё дальше, но я не играл и не знаю точно.
В целом, не вижу проблемы сделать рандомные квесты от рандомно находимых в подземелье NPC. Может, это редко реализуют, но для разнообразия, я считаю, фича хорошая, не одних же монстров убивать. Кому будет скучно квесты делать, может их игнорировать, т.е. это как побочные квесты получается.
>>827489
А там есть нюанс. Этот стринг нужно потом в инт переводить. Причем если я правильно помню, именно в инт а не в лонг, поэтому только 4 символа влезает. Tiled в качестве Id только инт принимает и ничего кроме него.
А там есть нюанс. Этот стринг нужно потом в инт переводить. Причем если я правильно помню, именно в инт а не в лонг, поэтому только 4 символа влезает. Tiled в качестве Id только инт принимает и ничего кроме него.
>>827490
Да не, с этим я не спорю, такие квесты вполне можно сделать. Вопрос был про возможность игроку создавать свои кастомные квесты.
Вот это уже вряд ли, выглядит как очень затратная задача.
Для самодельных карт есть Tiled, а самодельные квесты это уже что-то из области модов. Кто знает, может и такое запилю когда-нибудь, но для начала нужно чтобы игра сам по себе играбельная была
Да не, с этим я не спорю, такие квесты вполне можно сделать. Вопрос был про возможность игроку создавать свои кастомные квесты.
Вот это уже вряд ли, выглядит как очень затратная задача.
Для самодельных карт есть Tiled, а самодельные квесты это уже что-то из области модов. Кто знает, может и такое запилю когда-нибудь, но для начала нужно чтобы игра сам по себе играбельная была
>>825745
Знаешь, я сначала думал сделать именно так, чтобы все было основано на реальных исторических моментах. Чтобы там был культ Аполлона и Диониса, других греческих богов. Тогда я прочитал Рождение Трагедии Ницше и был под впечатлением. да я и сейчас
Но потом мое мнение поменялось.
Я все равно не смогу воссоздать ни одну из этих вещей с той мерой серьезности которую они требуют. А вещи то серьезные. И известные. Не хотелось бы превращать их в фарс.
К тому же четкое следование мифу лишит меня свободы творчества.
Ни Аполлон ни Дионис не были никак связаны с подземным миром. И с огромными красными грибами. И бафы они давали очень специфические). Единственный связанный с подземельем бог это Аид. Но про него игра уже есть Hades.
Короче да, от идеи добавления таких вещей, с которыми Древняя Греция напрямую ассоциируется я решил отказаться.
Сейчас у меня два варианта, либо я вообще выдумаю свою альтернативную подземную катаморфную античность, либо я буду эксплуатировать какие-то не особо известные мифы. Может быть не совсем элинские. Митра,(вполне подземный бог кста) Кибела, Армазд какой-нибудь. А персонажей-людей я просто выдумаю.
Или вот ещё, Гностицизм!
Такая крутая и малоизученная вещь.
Средний человек вообще не в курсе что это.
Сделать игру в гностическом сеттинге было бы просто великолепно. Вроде таких ещё не было.
Правда гностические боги очень специфические, непонятно какие вообще у них свойства и как с ними взаимодействовать. и бафов они не дают
Короче я сейчас больше думаю в этом направлении.
Хотя я больше болтаю чем делаю. Этот апдейт с богами я планирую ещё с весны и до сих пор ничего не готово
Знаешь, я сначала думал сделать именно так, чтобы все было основано на реальных исторических моментах. Чтобы там был культ Аполлона и Диониса, других греческих богов. Тогда я прочитал Рождение Трагедии Ницше и был под впечатлением. да я и сейчас
Но потом мое мнение поменялось.
Я все равно не смогу воссоздать ни одну из этих вещей с той мерой серьезности которую они требуют. А вещи то серьезные. И известные. Не хотелось бы превращать их в фарс.
К тому же четкое следование мифу лишит меня свободы творчества.
Ни Аполлон ни Дионис не были никак связаны с подземным миром. И с огромными красными грибами. И бафы они давали очень специфические). Единственный связанный с подземельем бог это Аид. Но про него игра уже есть Hades.
Короче да, от идеи добавления таких вещей, с которыми Древняя Греция напрямую ассоциируется я решил отказаться.
Сейчас у меня два варианта, либо я вообще выдумаю свою альтернативную подземную катаморфную античность, либо я буду эксплуатировать какие-то не особо известные мифы. Может быть не совсем элинские. Митра,(вполне подземный бог кста) Кибела, Армазд какой-нибудь. А персонажей-людей я просто выдумаю.
Или вот ещё, Гностицизм!
Такая крутая и малоизученная вещь.
Средний человек вообще не в курсе что это.
Сделать игру в гностическом сеттинге было бы просто великолепно. Вроде таких ещё не было.
Правда гностические боги очень специфические, непонятно какие вообще у них свойства и как с ними взаимодействовать. и бафов они не дают
Короче я сейчас больше думаю в этом направлении.
Хотя я больше болтаю чем делаю. Этот апдейт с богами я планирую ещё с весны и до сих пор ничего не готово
>>827649
Что тебе больше нравится в инди разработке? Рисовать, думать над лором описаниями или программировать ?
Что тебе больше нравится в инди разработке? Рисовать, думать над лором описаниями или программировать ?
>>827700
Да мне все нравится.
В программировании мне обычно заходят всякие низкоуровневые штуки.
Чтобы был какой-нибудь огромный массив чисел, чтобы между его квадратных скобок все "раз-раз-раз" быстро-быстро итерировалось и чтобы с каждым числом какая-нибудь хитрая операция совершалась. И чтобы потом все это ещё распараллелить.
Ох как же приятно.
Вообще математика это красиво.
А вот когда с какими-то классами внутри юнити работать, а ещё хуже сторонними апи где куча методов с мутными названиями, которые непонятно кто кодил, вот это не, мне такое не нравится.
А лор и рисование тоже интересно, но очень сложно. И обидно когда навыдумывал лора, а с геймплейной точки зрения это бессмыслица.
Или когда сидишь и вдруг такой: "так, эта стена плохо сочетается с полом , она должна быть совсем другого цвета, теперь я вижу". И так каждую неделю.
Да мне все нравится.
В программировании мне обычно заходят всякие низкоуровневые штуки.
Чтобы был какой-нибудь огромный массив чисел, чтобы между его квадратных скобок все "раз-раз-раз" быстро-быстро итерировалось и чтобы с каждым числом какая-нибудь хитрая операция совершалась. И чтобы потом все это ещё распараллелить.
Ох как же приятно.
Вообще математика это красиво.
А вот когда с какими-то классами внутри юнити работать, а ещё хуже сторонними апи где куча методов с мутными названиями, которые непонятно кто кодил, вот это не, мне такое не нравится.
А лор и рисование тоже интересно, но очень сложно. И обидно когда навыдумывал лора, а с геймплейной точки зрения это бессмыслица.
Или когда сидишь и вдруг такой: "так, эта стена плохо сочетается с полом , она должна быть совсем другого цвета, теперь я вижу". И так каждую неделю.
>>827644
Два варианта:
1. Хеш-сумма строки. Могут быть коллизии, а в Юнити вроде бы нет 32-битной хеш-суммы, только 128-битная. Разве что брать только часть суммы (первые 4 байта).
2. Позволить вводить длинную строку в качестве ID для удобства, но для Tiled будет использоваться число, с которого эта строка начинается, типа:
И так далее. Тут будет проблема коллизий модов, когда два мода используют один и тот же номер, несмотря на разные надписи. Это нужно как-то программно решать, например, сдвигая каждый мод на какое-то число и затем вычисляя ссылки между модами (если нужны).
>>827645
Не понял, а как ты планируешь свои квесты делать? Тупо хардкодом? Логичнее было бы описывать их чисто декларативно (для простоты - в JSON), чтобы потом была возможность дописывать квесты, не меняя код игры. Это упростит создание квестов и тебе, и моддерам. Вообще избегай хардкода в игре, как можно больше вещей должно описываться декларативно, так будет проще расширять контент и возможности игрока. В первую очередь - тебе самому, а моды тут идут бонусом.
>>827878
Пробовал Godot? Как по мне, у него достаточно чистое API. И если что-то непонятно, можно на гитхабе посмотреть в коде или начать обсуждение "это непонятно, нужно изменить на другое" - многие вещи изменили в результате таких обсуждений. Тем более что у тебя 2D игра, Godot в 2D без каких-либо проблем работает, у него только 3D недостаточно развитое по мнению графодрочеров, да и того достаточно для большинства 3D игр 00-х.
>Этот стринг нужно потом в инт переводить.
Два варианта:
1. Хеш-сумма строки. Могут быть коллизии, а в Юнити вроде бы нет 32-битной хеш-суммы, только 128-битная. Разве что брать только часть суммы (первые 4 байта).
2. Позволить вводить длинную строку в качестве ID для удобства, но для Tiled будет использоваться число, с которого эта строка начинается, типа:
>0-dirt
>1-grass
>2-stone
И так далее. Тут будет проблема коллизий модов, когда два мода используют один и тот же номер, несмотря на разные надписи. Это нужно как-то программно решать, например, сдвигая каждый мод на какое-то число и затем вычисляя ссылки между модами (если нужны).
>>827645
>такие квесты вполне можно сделать.
>самодельные квесты это уже что-то из области модов.
Не понял, а как ты планируешь свои квесты делать? Тупо хардкодом? Логичнее было бы описывать их чисто декларативно (для простоты - в JSON), чтобы потом была возможность дописывать квесты, не меняя код игры. Это упростит создание квестов и тебе, и моддерам. Вообще избегай хардкода в игре, как можно больше вещей должно описываться декларативно, так будет проще расширять контент и возможности игрока. В первую очередь - тебе самому, а моды тут идут бонусом.
>>827878
>А вот когда с какими-то классами внутри юнити работать, а ещё хуже сторонними апи где куча методов с мутными названиями, которые непонятно кто кодил, вот это не, мне такое не нравится.
Пробовал Godot? Как по мне, у него достаточно чистое API. И если что-то непонятно, можно на гитхабе посмотреть в коде или начать обсуждение "это непонятно, нужно изменить на другое" - многие вещи изменили в результате таких обсуждений. Тем более что у тебя 2D игра, Godot в 2D без каких-либо проблем работает, у него только 3D недостаточно развитое по мнению графодрочеров, да и того достаточно для большинства 3D игр 00-х.
>>827917
Опчик вложился в Unity ECS на нативном эррее и джобсах параллельных . Годот никогда такой скорости не получит как этот метод.
>Пробовал Godot?
Опчик вложился в Unity ECS на нативном эррее и джобсах параллельных . Годот никогда такой скорости не получит как этот метод.
>>827917
Почитал про разные хеши, прикольная штука. Но там же все равно на выходе получается что-то вида 2d6e582c3fcfb4b8f3c16650a75dc37b
А как из этого инт извлечь?
Видимо я чего-то недопонял...
Выше по треду были мои попытки сделать свою хеш функцию, я по всякому перемножал друг на друга номера символов и их положение в строке, но у меня ничего не получилось, коллизий было много.
Сейчас все в принципе и так сделано по второму твоему варианту. Только там ID и название в соседних столбцах таблицы.
Например
Stone Wall | STWL
По большому счету, я пока вообще не думал как их технически реализовать.
Представим как может выглядеть средний квест.
Есть НПС.
Он в такой-то локе.
Он хочет предмет.
Предмет в другой локе. Ну, и скажем, не просто на полу, а в брюхе у Владыки Глубин.
НПС получает предмет, отдает награду.
Да, такое вполне можно сделать. Через джсон, да много как... Но будет ли кому-то интересно вручную добавлять такие квесты, располагая таким набором параметров?
Да такие квесты можно генерировать процедурно тысячами. Что, конечно же будет сделано сразу как только я создам класс quest и впишу в него параметры.
А вот представим другой квест.
Есть культ подземных гностиков грибопоклонников.
Они готовы отдать тебе легендарный предмет, Древний Грибной Нож, но если ты выполнить все их испытания.
Далее три испытания
-убить пещерного быка живущего в башне
-собрать 10 жёлтых грибов сгенеренных в рандомных локах
- победить Грибного Патриарха в состязании кто выпьет больше грибного кваса.
И потом ещё оказывается что все это был сон.
Вот такой квест проходить будет куда интереснее.
И придумывать тоже.
А представь теперь апи который все это будет обеспечивать?
Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
И без багов))
Вот я лично не представляю.
Понятно что и это в теории возможно, всякие скайримы же как-то делают, у них там наверно разные люди кодят и квесты создают, но блин, все все понимают
Короче либо квесты простые, а тогда значит процедурные, либо нет этого не будет, пример выше это просто прекол, мысленный эксперимент офигенно сложные и проработанные, но если хочешь добавить новый - пиши мод.
А откуда вообще пошла идея с этими квестами?
В каких-то ещё играх игроки могут добавлять свои квесты?
Я такого вроде нигде не видел.
>Хеш сумма
Почитал про разные хеши, прикольная штука. Но там же все равно на выходе получается что-то вида 2d6e582c3fcfb4b8f3c16650a75dc37b
А как из этого инт извлечь?
Видимо я чего-то недопонял...
Выше по треду были мои попытки сделать свою хеш функцию, я по всякому перемножал друг на друга номера символов и их положение в строке, но у меня ничего не получилось, коллизий было много.
Сейчас все в принципе и так сделано по второму твоему варианту. Только там ID и название в соседних столбцах таблицы.
Например
Stone Wall | STWL
>Как планируешь квесты делать?
По большому счету, я пока вообще не думал как их технически реализовать.
Представим как может выглядеть средний квест.
Есть НПС.
Он в такой-то локе.
Он хочет предмет.
Предмет в другой локе. Ну, и скажем, не просто на полу, а в брюхе у Владыки Глубин.
НПС получает предмет, отдает награду.
Да, такое вполне можно сделать. Через джсон, да много как... Но будет ли кому-то интересно вручную добавлять такие квесты, располагая таким набором параметров?
Да такие квесты можно генерировать процедурно тысячами. Что, конечно же будет сделано сразу как только я создам класс quest и впишу в него параметры.
А вот представим другой квест.
Есть культ подземных гностиков грибопоклонников.
Они готовы отдать тебе легендарный предмет, Древний Грибной Нож, но если ты выполнить все их испытания.
Далее три испытания
-убить пещерного быка живущего в башне
-собрать 10 жёлтых грибов сгенеренных в рандомных локах
- победить Грибного Патриарха в состязании кто выпьет больше грибного кваса.
И потом ещё оказывается что все это был сон.
Вот такой квест проходить будет куда интереснее.
И придумывать тоже.
А представь теперь апи который все это будет обеспечивать?
Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
И без багов))
Вот я лично не представляю.
Понятно что и это в теории возможно, всякие скайримы же как-то делают, у них там наверно разные люди кодят и квесты создают, но блин, все все понимают
Короче либо квесты простые, а тогда значит процедурные, либо нет этого не будет, пример выше это просто прекол, мысленный эксперимент офигенно сложные и проработанные, но если хочешь добавить новый - пиши мод.
А откуда вообще пошла идея с этими квестами?
В каких-то ещё играх игроки могут добавлять свои квесты?
Я такого вроде нигде не видел.
>>827917
Почитал про разные хеши, прикольная штука. Но там же все равно на выходе получается что-то вида 2d6e582c3fcfb4b8f3c16650a75dc37b
А как из этого инт извлечь?
Видимо я чего-то недопонял...
Выше по треду были мои попытки сделать свою хеш функцию, я по всякому перемножал друг на друга номера символов и их положение в строке, но у меня ничего не получилось, коллизий было много.
Сейчас все в принципе и так сделано по второму твоему варианту. Только там ID и название в соседних столбцах таблицы.
Например
Stone Wall | STWL
По большому счету, я пока вообще не думал как их технически реализовать.
Представим как может выглядеть средний квест.
Есть НПС.
Он в такой-то локе.
Он хочет предмет.
Предмет в другой локе. Ну, и скажем, не просто на полу, а в брюхе у Владыки Глубин.
НПС получает предмет, отдает награду.
Да, такое вполне можно сделать. Через джсон, да много как... Но будет ли кому-то интересно вручную добавлять такие квесты, располагая таким набором параметров?
Да такие квесты можно генерировать процедурно тысячами. Что, конечно же будет сделано сразу как только я создам класс quest и впишу в него параметры.
А вот представим другой квест.
Есть культ подземных гностиков грибопоклонников.
Они готовы отдать тебе легендарный предмет, Древний Грибной Нож, но если ты выполнить все их испытания.
Далее три испытания
-убить пещерного быка живущего в башне
-собрать 10 жёлтых грибов сгенеренных в рандомных локах
- победить Грибного Патриарха в состязании кто выпьет больше грибного кваса.
И потом ещё оказывается что все это был сон.
Вот такой квест проходить будет куда интереснее.
И придумывать тоже.
А представь теперь апи который все это будет обеспечивать?
Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
И без багов))
Вот я лично не представляю.
Понятно что и это в теории возможно, всякие скайримы же как-то делают, у них там наверно разные люди кодят и квесты создают, но блин, все все понимают
Короче либо квесты простые, а тогда значит процедурные, либо нет этого не будет, пример выше это просто прекол, мысленный эксперимент офигенно сложные и проработанные, но если хочешь добавить новый - пиши мод.
А откуда вообще пошла идея с этими квестами?
В каких-то ещё играх игроки могут добавлять свои квесты?
Я такого вроде нигде не видел.
>Хеш сумма
Почитал про разные хеши, прикольная штука. Но там же все равно на выходе получается что-то вида 2d6e582c3fcfb4b8f3c16650a75dc37b
А как из этого инт извлечь?
Видимо я чего-то недопонял...
Выше по треду были мои попытки сделать свою хеш функцию, я по всякому перемножал друг на друга номера символов и их положение в строке, но у меня ничего не получилось, коллизий было много.
Сейчас все в принципе и так сделано по второму твоему варианту. Только там ID и название в соседних столбцах таблицы.
Например
Stone Wall | STWL
>Как планируешь квесты делать?
По большому счету, я пока вообще не думал как их технически реализовать.
Представим как может выглядеть средний квест.
Есть НПС.
Он в такой-то локе.
Он хочет предмет.
Предмет в другой локе. Ну, и скажем, не просто на полу, а в брюхе у Владыки Глубин.
НПС получает предмет, отдает награду.
Да, такое вполне можно сделать. Через джсон, да много как... Но будет ли кому-то интересно вручную добавлять такие квесты, располагая таким набором параметров?
Да такие квесты можно генерировать процедурно тысячами. Что, конечно же будет сделано сразу как только я создам класс quest и впишу в него параметры.
А вот представим другой квест.
Есть культ подземных гностиков грибопоклонников.
Они готовы отдать тебе легендарный предмет, Древний Грибной Нож, но если ты выполнить все их испытания.
Далее три испытания
-убить пещерного быка живущего в башне
-собрать 10 жёлтых грибов сгенеренных в рандомных локах
- победить Грибного Патриарха в состязании кто выпьет больше грибного кваса.
И потом ещё оказывается что все это был сон.
Вот такой квест проходить будет куда интереснее.
И придумывать тоже.
А представь теперь апи который все это будет обеспечивать?
Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
И без багов))
Вот я лично не представляю.
Понятно что и это в теории возможно, всякие скайримы же как-то делают, у них там наверно разные люди кодят и квесты создают, но блин, все все понимают
Короче либо квесты простые, а тогда значит процедурные, либо нет этого не будет, пример выше это просто прекол, мысленный эксперимент офигенно сложные и проработанные, но если хочешь добавить новый - пиши мод.
А откуда вообще пошла идея с этими квестами?
В каких-то ещё играх игроки могут добавлять свои квесты?
Я такого вроде нигде не видел.
>>828054
Это и есть целое число в шестнадцатеричной системе счисления, в десятичной оно будет выглядеть так:
Это у тебя 128-битный хеш, т.е. 16 байт (максимум 32 цифры в 16-ричной системе счисления). Тип int в языках программирования обычно означает 32- или 64-битное число, следовательно, тебе нужно искать соответствующую хеш-функцию (чтобы давала маленькие числа) или брать только 1/4 или 1/2 от 128-битной хеш-суммы. В любом случае число коллизий увеличится, но насколько это будет критично в конкретном случае можно узнать только на практике.
Процедурно ты скорее всего будешь подставлять случайные предметы случайным НПЦ под шаблонный текст "мне нужен %предмет%", а вручную можно запилить какую-нибудь осмысленную историю, вроде Красной Шапочки, потерявшей свою шапочку, которую игрок найдёт в брюхе минибосса Волк. Здесь от процедурного генератора требуется только разместить НПЦ (Красную Шапочку) и соответствующую цель (Волка с шапочкой) в сгенерированных комнатах подземелья.
https://ru.wikipedia.org/wiki/Декомпозиция
Вкратце, раздели задачу на минимальные части и реализуй эти части по отдельности. Сначала будут простые квесты типа "поиск предмета", потом всё сложнее и сложнее. Если тебя это вообще интересует, конечно.
А вот в Godot не пришлось бы API делать, там можно загружать моды, сделанные на самом Godot.
Да в любой РПГ/рогалике с модами игроки могут создавать свои квесты, обычно в том же формате, в котором их делали разработчики игры. Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.
>>827936
Зато на Godot ты можешь быстро разрабатывать игру, а не ковыряться в каком-то ECS, создавая 100500 "систем" только для одного игрового персонажа, состоящего из 100500 независимых "компонентов". ECS нинужна для большинства игр, потому что ускоряет работу только на огромных массивах (сотни тысяч независимых юнитов в какой-нибудь стратегии), которые выгодно хранить в кэше процессора, чтобы он не ждал ответ от RAM. Алсо реализация ECS для Godot есть, но никто в ней разбираться не будет, потому что она нинужна.
>2d6e582c3fcfb4b8f3c16650a75dc37b
>А как из этого инт извлечь?
Это и есть целое число в шестнадцатеричной системе счисления, в десятичной оно будет выглядеть так:
>60388200822592973995575059968711050107
Это у тебя 128-битный хеш, т.е. 16 байт (максимум 32 цифры в 16-ричной системе счисления). Тип int в языках программирования обычно означает 32- или 64-битное число, следовательно, тебе нужно искать соответствующую хеш-функцию (чтобы давала маленькие числа) или брать только 1/4 или 1/2 от 128-битной хеш-суммы. В любом случае число коллизий увеличится, но насколько это будет критично в конкретном случае можно узнать только на практике.
>Да такие квесты можно генерировать процедурно тысячами.
Процедурно ты скорее всего будешь подставлять случайные предметы случайным НПЦ под шаблонный текст "мне нужен %предмет%", а вручную можно запилить какую-нибудь осмысленную историю, вроде Красной Шапочки, потерявшей свою шапочку, которую игрок найдёт в брюхе минибосса Волк. Здесь от процедурного генератора требуется только разместить НПЦ (Красную Шапочку) и соответствующую цель (Волка с шапочкой) в сгенерированных комнатах подземелья.
>А представь теперь апи который все это будет обеспечивать?
>Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
>Вот я лично не представляю.
https://ru.wikipedia.org/wiki/Декомпозиция
Вкратце, раздели задачу на минимальные части и реализуй эти части по отдельности. Сначала будут простые квесты типа "поиск предмета", потом всё сложнее и сложнее. Если тебя это вообще интересует, конечно.
А вот в Godot не пришлось бы API делать, там можно загружать моды, сделанные на самом Godot.
>В каких-то ещё играх игроки могут добавлять свои квесты?
Да в любой РПГ/рогалике с модами игроки могут создавать свои квесты, обычно в том же формате, в котором их делали разработчики игры. Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.
>>827936
>ECS
>Годот никогда такой скорости не получит
Зато на Godot ты можешь быстро разрабатывать игру, а не ковыряться в каком-то ECS, создавая 100500 "систем" только для одного игрового персонажа, состоящего из 100500 независимых "компонентов". ECS нинужна для большинства игр, потому что ускоряет работу только на огромных массивах (сотни тысяч независимых юнитов в какой-нибудь стратегии), которые выгодно хранить в кэше процессора, чтобы он не ждал ответ от RAM. Алсо реализация ECS для Godot есть, но никто в ней разбираться не будет, потому что она нинужна.
>>828054
Это и есть целое число в шестнадцатеричной системе счисления, в десятичной оно будет выглядеть так:
Это у тебя 128-битный хеш, т.е. 16 байт (максимум 32 цифры в 16-ричной системе счисления). Тип int в языках программирования обычно означает 32- или 64-битное число, следовательно, тебе нужно искать соответствующую хеш-функцию (чтобы давала маленькие числа) или брать только 1/4 или 1/2 от 128-битной хеш-суммы. В любом случае число коллизий увеличится, но насколько это будет критично в конкретном случае можно узнать только на практике.
Процедурно ты скорее всего будешь подставлять случайные предметы случайным НПЦ под шаблонный текст "мне нужен %предмет%", а вручную можно запилить какую-нибудь осмысленную историю, вроде Красной Шапочки, потерявшей свою шапочку, которую игрок найдёт в брюхе минибосса Волк. Здесь от процедурного генератора требуется только разместить НПЦ (Красную Шапочку) и соответствующую цель (Волка с шапочкой) в сгенерированных комнатах подземелья.
https://ru.wikipedia.org/wiki/Декомпозиция
Вкратце, раздели задачу на минимальные части и реализуй эти части по отдельности. Сначала будут простые квесты типа "поиск предмета", потом всё сложнее и сложнее. Если тебя это вообще интересует, конечно.
А вот в Godot не пришлось бы API делать, там можно загружать моды, сделанные на самом Godot.
Да в любой РПГ/рогалике с модами игроки могут создавать свои квесты, обычно в том же формате, в котором их делали разработчики игры. Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.
>>827936
Зато на Godot ты можешь быстро разрабатывать игру, а не ковыряться в каком-то ECS, создавая 100500 "систем" только для одного игрового персонажа, состоящего из 100500 независимых "компонентов". ECS нинужна для большинства игр, потому что ускоряет работу только на огромных массивах (сотни тысяч независимых юнитов в какой-нибудь стратегии), которые выгодно хранить в кэше процессора, чтобы он не ждал ответ от RAM. Алсо реализация ECS для Godot есть, но никто в ней разбираться не будет, потому что она нинужна.
>2d6e582c3fcfb4b8f3c16650a75dc37b
>А как из этого инт извлечь?
Это и есть целое число в шестнадцатеричной системе счисления, в десятичной оно будет выглядеть так:
>60388200822592973995575059968711050107
Это у тебя 128-битный хеш, т.е. 16 байт (максимум 32 цифры в 16-ричной системе счисления). Тип int в языках программирования обычно означает 32- или 64-битное число, следовательно, тебе нужно искать соответствующую хеш-функцию (чтобы давала маленькие числа) или брать только 1/4 или 1/2 от 128-битной хеш-суммы. В любом случае число коллизий увеличится, но насколько это будет критично в конкретном случае можно узнать только на практике.
>Да такие квесты можно генерировать процедурно тысячами.
Процедурно ты скорее всего будешь подставлять случайные предметы случайным НПЦ под шаблонный текст "мне нужен %предмет%", а вручную можно запилить какую-нибудь осмысленную историю, вроде Красной Шапочки, потерявшей свою шапочку, которую игрок найдёт в брюхе минибосса Волк. Здесь от процедурного генератора требуется только разместить НПЦ (Красную Шапочку) и соответствующую цель (Волка с шапочкой) в сгенерированных комнатах подземелья.
>А представь теперь апи который все это будет обеспечивать?
>Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.
>Вот я лично не представляю.
https://ru.wikipedia.org/wiki/Декомпозиция
Вкратце, раздели задачу на минимальные части и реализуй эти части по отдельности. Сначала будут простые квесты типа "поиск предмета", потом всё сложнее и сложнее. Если тебя это вообще интересует, конечно.
А вот в Godot не пришлось бы API делать, там можно загружать моды, сделанные на самом Godot.
>В каких-то ещё играх игроки могут добавлять свои квесты?
Да в любой РПГ/рогалике с модами игроки могут создавать свои квесты, обычно в том же формате, в котором их делали разработчики игры. Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.
>>827936
>ECS
>Годот никогда такой скорости не получит
Зато на Godot ты можешь быстро разрабатывать игру, а не ковыряться в каком-то ECS, создавая 100500 "систем" только для одного игрового персонажа, состоящего из 100500 независимых "компонентов". ECS нинужна для большинства игр, потому что ускоряет работу только на огромных массивах (сотни тысяч независимых юнитов в какой-нибудь стратегии), которые выгодно хранить в кэше процессора, чтобы он не ждал ответ от RAM. Алсо реализация ECS для Godot есть, но никто в ней разбираться не будет, потому что она нинужна.
>>828733
Я предложил потому что фанат модинга в играх. В каждой игре первым делом смотрю есть ли поддержка модов и какие топ моды для этой игры
>Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.
Я предложил потому что фанат модинга в играх. В каждой игре первым делом смотрю есть ли поддержка модов и какие топ моды для этой игры
>>828733
Окей, в целом идея с квестами интересная, но, повторюсь, пока мне нужно доделать все остальное)
Первые подвижки к квестам будут либо в после-следующем, либо в после-после-следующем билде.
Печально осознавать, что многие в этом треде умрут от старости и квестов не застанут.
А ецс нужен. У меня там не сотни тысяч, но все равно довольно много всяких вещей считается. Я пробовал без ецс, но получалось как-то не очень. К тому-же, то что работает на моем наса-пека далеко не факт что будет работать на андроиде каком-нибудь, а вполне возможно я все-таки буду порт делать.
Окей, в целом идея с квестами интересная, но, повторюсь, пока мне нужно доделать все остальное)
Первые подвижки к квестам будут либо в после-следующем, либо в после-после-следующем билде.
Печально осознавать, что многие в этом треде умрут от старости и квестов не застанут.
А ецс нужен. У меня там не сотни тысяч, но все равно довольно много всяких вещей считается. Я пробовал без ецс, но получалось как-то не очень. К тому-же, то что работает на моем наса-пека далеко не факт что будет работать на андроиде каком-нибудь, а вполне возможно я все-таки буду порт делать.
>>828899
ВПЕРВЫЕ ВИДИШЬ ИГРУ
@
УЖЕ ИЩЕШЬ ТОП МОДЫ
>>828989
Это правильно, нужно следовать планам.
ARM - другая архитектура. Сильно сомневаюсь, что преимущества и недостатки будут одинаковыми для десктопа (x86-64) и мобилок (ARM).
Хм, а разве это критично для пошаговой игры? Тебе же не нужно 120 фпс реалтайм экшон...
>В каждой игре первым делом смотрю есть ли поддержка модов и какие топ моды для этой игры
ВПЕРВЫЕ ВИДИШЬ ИГРУ
@
УЖЕ ИЩЕШЬ ТОП МОДЫ
>>828989
>пока мне нужно доделать все остальное
Это правильно, нужно следовать планам.
>ецс
>будет работать на андроиде каком-нибудь
ARM - другая архитектура. Сильно сомневаюсь, что преимущества и недостатки будут одинаковыми для десктопа (x86-64) и мобилок (ARM).
>довольно много всяких вещей считается
Хм, а разве это критично для пошаговой игры? Тебе же не нужно 120 фпс реалтайм экшон...
>>829158
Про архитектуры я вообще ничего не знаю. Может там и правда все сильно по-другому. Но практика показывает что ецс и на андроиде хорошо заходит, если в игре какое-то серьезное количество сущностей.
Если у нас реально стратегия типо Songs Of Syx, великолепная игра кстати, то там конечно эффект будет сильнее ощущаться, но и с меньшим количеством сущностей он есть.
На счет пошаговости и производительности.
Действительно на первый взгляд кажется, что тут она не так важна. Игрок же все время просто стоит и думает, а время не идет.
Но на самом деле все как раз наоборот.
В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
В пошаговой игре время идет неравномерно. Да 70% времени игрок разглядывает циферки в 120фпс двигая время на 10 тиков раз в 5 секунд. Тут вообще можно ничего не оптимизировать.
Но вот в оставшихся 30% вычисления должны происходить просто молниеносно.
Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку. А игрок в этом не участвует, а просто проходит мимо. Он должен пройти так же плавно как если бы вокруг ничего не происходило. И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков. И каждый тик это точка синхронизации, к которой должны быть выполнены все-все рассчеты, должны пройти все потоки и так далее.
Вот в чем узкое место.
Есть конечно обходные пути.
Можно заставить игрока после каждого хода смотреть анимацию того как персонаж перепрыгивает с одной клетки на другую. Так сделано у меня, что дает немного дополнительного времени на расчеты. Сейчас это совсем чуть-чуть, если сделать этот промежуток больше, выглядеть будет отвратительно, я вас уверяю.
Можно сделать так, чтобы когда игрок идет быстро мобы переставали драться. Или делали это медленнее.
Но это же полная херня! Это просто нечестно.
Хотя, если фпсов будет не хватать я прибегну и к этому.
Есть вариант для шахматистов. Просчитывать все заранее. пока игрок стоит. Гениально!
Если такое реально где-то реализовано (не в шахматах не в го и не в крестиках-ноликах, а в настоящем рогалике) то я бы поклонился до земли. Хз может где и есть, не берусь утверждать
Количество комбинаций с увеличением глубины просчета растет в такой лютой прогрессии, что я не представляю как это возможно.
Ну хорошо, за секунду стояния на месте просчитал ты все варианты на 5 ходов вперед и что дальше? А игрок не остановился на пятом ходу, пошел дальше и все, 10 фпс.
Чуть более адекватным кажется вариант когда есть какой-то максимальный отрезок времени выделенный на тик. Вот вычисляют все мобы свой ИИ, кто успел за 100 мс, тот ходит в этот тик, а кто не успел тот пропускает ход и дальше считает на отдельном потоке, пока не будет готов. А потом ходит и уходит в меньший кулдаун чем те, кто успел посчитать раньше.
Вот в сторону этого мб есть смысл подумать, но выглядит очень замороченно и без многоядерности, получается, оно вообще не будет работать.
Про архитектуры я вообще ничего не знаю. Может там и правда все сильно по-другому. Но практика показывает что ецс и на андроиде хорошо заходит, если в игре какое-то серьезное количество сущностей.
Если у нас реально стратегия типо Songs Of Syx, великолепная игра кстати, то там конечно эффект будет сильнее ощущаться, но и с меньшим количеством сущностей он есть.
На счет пошаговости и производительности.
Действительно на первый взгляд кажется, что тут она не так важна. Игрок же все время просто стоит и думает, а время не идет.
Но на самом деле все как раз наоборот.
В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
В пошаговой игре время идет неравномерно. Да 70% времени игрок разглядывает циферки в 120фпс двигая время на 10 тиков раз в 5 секунд. Тут вообще можно ничего не оптимизировать.
Но вот в оставшихся 30% вычисления должны происходить просто молниеносно.
Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку. А игрок в этом не участвует, а просто проходит мимо. Он должен пройти так же плавно как если бы вокруг ничего не происходило. И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков. И каждый тик это точка синхронизации, к которой должны быть выполнены все-все рассчеты, должны пройти все потоки и так далее.
Вот в чем узкое место.
Есть конечно обходные пути.
Можно заставить игрока после каждого хода смотреть анимацию того как персонаж перепрыгивает с одной клетки на другую. Так сделано у меня, что дает немного дополнительного времени на расчеты. Сейчас это совсем чуть-чуть, если сделать этот промежуток больше, выглядеть будет отвратительно, я вас уверяю.
Можно сделать так, чтобы когда игрок идет быстро мобы переставали драться. Или делали это медленнее.
Но это же полная херня! Это просто нечестно.
Хотя, если фпсов будет не хватать я прибегну и к этому.
Есть вариант для шахматистов. Просчитывать все заранее. пока игрок стоит. Гениально!
Если такое реально где-то реализовано (не в шахматах не в го и не в крестиках-ноликах, а в настоящем рогалике) то я бы поклонился до земли. Хз может где и есть, не берусь утверждать
Количество комбинаций с увеличением глубины просчета растет в такой лютой прогрессии, что я не представляю как это возможно.
Ну хорошо, за секунду стояния на месте просчитал ты все варианты на 5 ходов вперед и что дальше? А игрок не остановился на пятом ходу, пошел дальше и все, 10 фпс.
Чуть более адекватным кажется вариант когда есть какой-то максимальный отрезок времени выделенный на тик. Вот вычисляют все мобы свой ИИ, кто успел за 100 мс, тот ходит в этот тик, а кто не успел тот пропускает ход и дальше считает на отдельном потоке, пока не будет готов. А потом ходит и уходит в меньший кулдаун чем те, кто успел посчитать раньше.
Вот в сторону этого мб есть смысл подумать, но выглядит очень замороченно и без многоядерности, получается, оно вообще не будет работать.
>>829158
Про архитектуры я вообще ничего не знаю. Может там и правда все сильно по-другому. Но практика показывает что ецс и на андроиде хорошо заходит, если в игре какое-то серьезное количество сущностей.
Если у нас реально стратегия типо Songs Of Syx, великолепная игра кстати, то там конечно эффект будет сильнее ощущаться, но и с меньшим количеством сущностей он есть.
На счет пошаговости и производительности.
Действительно на первый взгляд кажется, что тут она не так важна. Игрок же все время просто стоит и думает, а время не идет.
Но на самом деле все как раз наоборот.
В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
В пошаговой игре время идет неравномерно. Да 70% времени игрок разглядывает циферки в 120фпс двигая время на 10 тиков раз в 5 секунд. Тут вообще можно ничего не оптимизировать.
Но вот в оставшихся 30% вычисления должны происходить просто молниеносно.
Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку. А игрок в этом не участвует, а просто проходит мимо. Он должен пройти так же плавно как если бы вокруг ничего не происходило. И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков. И каждый тик это точка синхронизации, к которой должны быть выполнены все-все рассчеты, должны пройти все потоки и так далее.
Вот в чем узкое место.
Есть конечно обходные пути.
Можно заставить игрока после каждого хода смотреть анимацию того как персонаж перепрыгивает с одной клетки на другую. Так сделано у меня, что дает немного дополнительного времени на расчеты. Сейчас это совсем чуть-чуть, если сделать этот промежуток больше, выглядеть будет отвратительно, я вас уверяю.
Можно сделать так, чтобы когда игрок идет быстро мобы переставали драться. Или делали это медленнее.
Но это же полная херня! Это просто нечестно.
Хотя, если фпсов будет не хватать я прибегну и к этому.
Есть вариант для шахматистов. Просчитывать все заранее. пока игрок стоит. Гениально!
Если такое реально где-то реализовано (не в шахматах не в го и не в крестиках-ноликах, а в настоящем рогалике) то я бы поклонился до земли. Хз может где и есть, не берусь утверждать
Количество комбинаций с увеличением глубины просчета растет в такой лютой прогрессии, что я не представляю как это возможно.
Ну хорошо, за секунду стояния на месте просчитал ты все варианты на 5 ходов вперед и что дальше? А игрок не остановился на пятом ходу, пошел дальше и все, 10 фпс.
Чуть более адекватным кажется вариант когда есть какой-то максимальный отрезок времени выделенный на тик. Вот вычисляют все мобы свой ИИ, кто успел за 100 мс, тот ходит в этот тик, а кто не успел тот пропускает ход и дальше считает на отдельном потоке, пока не будет готов. А потом ходит и уходит в меньший кулдаун чем те, кто успел посчитать раньше.
Вот в сторону этого мб есть смысл подумать, но выглядит очень замороченно и без многоядерности, получается, оно вообще не будет работать.
Про архитектуры я вообще ничего не знаю. Может там и правда все сильно по-другому. Но практика показывает что ецс и на андроиде хорошо заходит, если в игре какое-то серьезное количество сущностей.
Если у нас реально стратегия типо Songs Of Syx, великолепная игра кстати, то там конечно эффект будет сильнее ощущаться, но и с меньшим количеством сущностей он есть.
На счет пошаговости и производительности.
Действительно на первый взгляд кажется, что тут она не так важна. Игрок же все время просто стоит и думает, а время не идет.
Но на самом деле все как раз наоборот.
В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
В пошаговой игре время идет неравномерно. Да 70% времени игрок разглядывает циферки в 120фпс двигая время на 10 тиков раз в 5 секунд. Тут вообще можно ничего не оптимизировать.
Но вот в оставшихся 30% вычисления должны происходить просто молниеносно.
Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку. А игрок в этом не участвует, а просто проходит мимо. Он должен пройти так же плавно как если бы вокруг ничего не происходило. И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков. И каждый тик это точка синхронизации, к которой должны быть выполнены все-все рассчеты, должны пройти все потоки и так далее.
Вот в чем узкое место.
Есть конечно обходные пути.
Можно заставить игрока после каждого хода смотреть анимацию того как персонаж перепрыгивает с одной клетки на другую. Так сделано у меня, что дает немного дополнительного времени на расчеты. Сейчас это совсем чуть-чуть, если сделать этот промежуток больше, выглядеть будет отвратительно, я вас уверяю.
Можно сделать так, чтобы когда игрок идет быстро мобы переставали драться. Или делали это медленнее.
Но это же полная херня! Это просто нечестно.
Хотя, если фпсов будет не хватать я прибегну и к этому.
Есть вариант для шахматистов. Просчитывать все заранее. пока игрок стоит. Гениально!
Если такое реально где-то реализовано (не в шахматах не в го и не в крестиках-ноликах, а в настоящем рогалике) то я бы поклонился до земли. Хз может где и есть, не берусь утверждать
Количество комбинаций с увеличением глубины просчета растет в такой лютой прогрессии, что я не представляю как это возможно.
Ну хорошо, за секунду стояния на месте просчитал ты все варианты на 5 ходов вперед и что дальше? А игрок не остановился на пятом ходу, пошел дальше и все, 10 фпс.
Чуть более адекватным кажется вариант когда есть какой-то максимальный отрезок времени выделенный на тик. Вот вычисляют все мобы свой ИИ, кто успел за 100 мс, тот ходит в этот тик, а кто не успел тот пропускает ход и дальше считает на отдельном потоке, пока не будет готов. А потом ходит и уходит в меньший кулдаун чем те, кто успел посчитать раньше.
Вот в сторону этого мб есть смысл подумать, но выглядит очень замороченно и без многоядерности, получается, оно вообще не будет работать.
>>829158
Игра с топ модом всегда лучше чем без него. Раз мод топ то он очень нужен оказался всем игрокам. Значит он добавляет что то реально крутое
> ВПЕРВЫЕ ВИДИШЬ ИГРУ
> @
> УЖЕ ИЩЕШЬ ТОП МОДЫ
Игра с топ модом всегда лучше чем без него. Раз мод топ то он очень нужен оказался всем игрокам. Значит он добавляет что то реально крутое
>>828899
А я вот наоборот моды считаю отрицательным элементом
потому что моды нарушают целостность игры, задумку автора. Их делают васяны. Это как фанфики по наруто.. мало того что наруто сам по себе говно, так еще и кто-то читает фанфики по нему - пиздец.
Хотя конечно есть исключения - тиа модов на варкрафт создавших новые жанры игр... но в том и дело что это по сути переработка всей механики, а не очередные перерисованные текстуры и "хардкор-режим"
>Я предложил потому что фанат модинга в играх
А я вот наоборот моды считаю отрицательным элементом
потому что моды нарушают целостность игры, задумку автора. Их делают васяны. Это как фанфики по наруто.. мало того что наруто сам по себе говно, так еще и кто-то читает фанфики по нему - пиздец.
Хотя конечно есть исключения - тиа модов на варкрафт создавших новые жанры игр... но в том и дело что это по сути переработка всей механики, а не очередные перерисованные текстуры и "хардкор-режим"
>>829327
Игра с модом = игра, которую некий Васян из шестого /б/ изменил по сравнению с замыслом автора игры. Даже если мод вписывается в лор игры, есть весомая причина, почему он не вошёл в оригинал, и это не отсутствие финансов, т.к. моддеры часто вообще бесплатно всё делают. Меняя игру модом с самого начала (не пройдя её несколько раз в оригинальном виде), ты тем самым лишаешь себя восприятия авторского замысла. Ну, это если мы говорим о контенте, а не о фиксе объективных багов, когда древнюю игру неудачно портируют на современную платформу, или когда оригинальный разработчик официально мёртв и игра больше не сможет получить багфиксов. Но мы вроде как обсуждаем моды с контентом (карты, квесты)?
Если в игру для детей топовый мод добавляет секс, то это не значит, что он нужен конкретной игре - просто большинство игроков проходят половое созревание и готовы дрочить даже на кубоголовых созданий Майнкрафта или Роблокс, если приделать им нечто напоминающее сиськи и письки. Будешь ли ты ставить секс-мод только из-за его высокой популярности, даже если тебя он не интересует и откровенно портит изначальный замысел игры, смещая фокус её геймплея на секс или сексуальных персонажей? Может, лучше купить/скачать профессиональную игру про секс или с сексуальными персонажами, чем ставить васянский секс-мод на изначально не предназначенную для этого игру? Аналогично с любым другим контент-модом.
Ну да, с точки зрения молодого кумера секс-мод - это круто, даже если он в пикселявой игре и размер сисек измеряется буквально считанными пикселями, а геймплей оригинала заточен на бои с боссами и исследования мира, а не сношение всего, что движется.
>>829347
Двачую. Фанфики иногда бывают хорошими и на основе одной игры можно создать другую игру, но оригинал ценен сам по себе, без изменений третьих лиц, а все изменения по сути создают новый продукт. Если же оригинал настолько говно, что без модов неиграбелен, то стоит ли вообще за него платить и потом искать моды, если в мире так много других, более качественных в оригинале игр?
Я понимаю желание поставить мод, который добавляет что-то, что тебе очень нравится и хочется увидеть в твоей любимой игре. То есть ты сначала много играешь в игру, а потом случайно находишь мод, который добавляет то, что тебя в целом очень интересует. Ну, можно понять фурфага, который ставит мод на фурри в любимую игру из-за того, что ему по жизни нравятся фурри. Но такие моды как правило нишевые, имеют низкую популярность, либо популярность обеспечена большим посторонним коммьюнити (те же фурри, их много). Но ставить популярные моды на игру, в которую ты даже не играл - имхо, глупо. Другое дело если ты в первую очередь узнал и заинтересовался модом, а игру скачал только как платформу для этого мода, но это уже совсем другая история.
>Игра с топ модом всегда лучше чем без него.
Игра с модом = игра, которую некий Васян из шестого /б/ изменил по сравнению с замыслом автора игры. Даже если мод вписывается в лор игры, есть весомая причина, почему он не вошёл в оригинал, и это не отсутствие финансов, т.к. моддеры часто вообще бесплатно всё делают. Меняя игру модом с самого начала (не пройдя её несколько раз в оригинальном виде), ты тем самым лишаешь себя восприятия авторского замысла. Ну, это если мы говорим о контенте, а не о фиксе объективных багов, когда древнюю игру неудачно портируют на современную платформу, или когда оригинальный разработчик официально мёртв и игра больше не сможет получить багфиксов. Но мы вроде как обсуждаем моды с контентом (карты, квесты)?
>Раз мод топ то он очень нужен оказался всем игрокам.
Если в игру для детей топовый мод добавляет секс, то это не значит, что он нужен конкретной игре - просто большинство игроков проходят половое созревание и готовы дрочить даже на кубоголовых созданий Майнкрафта или Роблокс, если приделать им нечто напоминающее сиськи и письки. Будешь ли ты ставить секс-мод только из-за его высокой популярности, даже если тебя он не интересует и откровенно портит изначальный замысел игры, смещая фокус её геймплея на секс или сексуальных персонажей? Может, лучше купить/скачать профессиональную игру про секс или с сексуальными персонажами, чем ставить васянский секс-мод на изначально не предназначенную для этого игру? Аналогично с любым другим контент-модом.
>Значит он добавляет что то реально крутое
Ну да, с точки зрения молодого кумера секс-мод - это круто, даже если он в пикселявой игре и размер сисек измеряется буквально считанными пикселями, а геймплей оригинала заточен на бои с боссами и исследования мира, а не сношение всего, что движется.
>>829347
>наоборот моды считаю отрицательным элементом
>потому что моды нарушают целостность игры, задумку автора. Их делают васяны. Это как фанфики
>это по сути переработка всей механики, а не очередные перерисованные текстуры и "хардкор-режим"
Двачую. Фанфики иногда бывают хорошими и на основе одной игры можно создать другую игру, но оригинал ценен сам по себе, без изменений третьих лиц, а все изменения по сути создают новый продукт. Если же оригинал настолько говно, что без модов неиграбелен, то стоит ли вообще за него платить и потом искать моды, если в мире так много других, более качественных в оригинале игр?
Я понимаю желание поставить мод, который добавляет что-то, что тебе очень нравится и хочется увидеть в твоей любимой игре. То есть ты сначала много играешь в игру, а потом случайно находишь мод, который добавляет то, что тебя в целом очень интересует. Ну, можно понять фурфага, который ставит мод на фурри в любимую игру из-за того, что ему по жизни нравятся фурри. Но такие моды как правило нишевые, имеют низкую популярность, либо популярность обеспечена большим посторонним коммьюнити (те же фурри, их много). Но ставить популярные моды на игру, в которую ты даже не играл - имхо, глупо. Другое дело если ты в первую очередь узнал и заинтересовался модом, а игру скачал только как платформу для этого мода, но это уже совсем другая история.
>>829327
Игра с модом = игра, которую некий Васян из шестого /б/ изменил по сравнению с замыслом автора игры. Даже если мод вписывается в лор игры, есть весомая причина, почему он не вошёл в оригинал, и это не отсутствие финансов, т.к. моддеры часто вообще бесплатно всё делают. Меняя игру модом с самого начала (не пройдя её несколько раз в оригинальном виде), ты тем самым лишаешь себя восприятия авторского замысла. Ну, это если мы говорим о контенте, а не о фиксе объективных багов, когда древнюю игру неудачно портируют на современную платформу, или когда оригинальный разработчик официально мёртв и игра больше не сможет получить багфиксов. Но мы вроде как обсуждаем моды с контентом (карты, квесты)?
Если в игру для детей топовый мод добавляет секс, то это не значит, что он нужен конкретной игре - просто большинство игроков проходят половое созревание и готовы дрочить даже на кубоголовых созданий Майнкрафта или Роблокс, если приделать им нечто напоминающее сиськи и письки. Будешь ли ты ставить секс-мод только из-за его высокой популярности, даже если тебя он не интересует и откровенно портит изначальный замысел игры, смещая фокус её геймплея на секс или сексуальных персонажей? Может, лучше купить/скачать профессиональную игру про секс или с сексуальными персонажами, чем ставить васянский секс-мод на изначально не предназначенную для этого игру? Аналогично с любым другим контент-модом.
Ну да, с точки зрения молодого кумера секс-мод - это круто, даже если он в пикселявой игре и размер сисек измеряется буквально считанными пикселями, а геймплей оригинала заточен на бои с боссами и исследования мира, а не сношение всего, что движется.
>>829347
Двачую. Фанфики иногда бывают хорошими и на основе одной игры можно создать другую игру, но оригинал ценен сам по себе, без изменений третьих лиц, а все изменения по сути создают новый продукт. Если же оригинал настолько говно, что без модов неиграбелен, то стоит ли вообще за него платить и потом искать моды, если в мире так много других, более качественных в оригинале игр?
Я понимаю желание поставить мод, который добавляет что-то, что тебе очень нравится и хочется увидеть в твоей любимой игре. То есть ты сначала много играешь в игру, а потом случайно находишь мод, который добавляет то, что тебя в целом очень интересует. Ну, можно понять фурфага, который ставит мод на фурри в любимую игру из-за того, что ему по жизни нравятся фурри. Но такие моды как правило нишевые, имеют низкую популярность, либо популярность обеспечена большим посторонним коммьюнити (те же фурри, их много). Но ставить популярные моды на игру, в которую ты даже не играл - имхо, глупо. Другое дело если ты в первую очередь узнал и заинтересовался модом, а игру скачал только как платформу для этого мода, но это уже совсем другая история.
>Игра с топ модом всегда лучше чем без него.
Игра с модом = игра, которую некий Васян из шестого /б/ изменил по сравнению с замыслом автора игры. Даже если мод вписывается в лор игры, есть весомая причина, почему он не вошёл в оригинал, и это не отсутствие финансов, т.к. моддеры часто вообще бесплатно всё делают. Меняя игру модом с самого начала (не пройдя её несколько раз в оригинальном виде), ты тем самым лишаешь себя восприятия авторского замысла. Ну, это если мы говорим о контенте, а не о фиксе объективных багов, когда древнюю игру неудачно портируют на современную платформу, или когда оригинальный разработчик официально мёртв и игра больше не сможет получить багфиксов. Но мы вроде как обсуждаем моды с контентом (карты, квесты)?
>Раз мод топ то он очень нужен оказался всем игрокам.
Если в игру для детей топовый мод добавляет секс, то это не значит, что он нужен конкретной игре - просто большинство игроков проходят половое созревание и готовы дрочить даже на кубоголовых созданий Майнкрафта или Роблокс, если приделать им нечто напоминающее сиськи и письки. Будешь ли ты ставить секс-мод только из-за его высокой популярности, даже если тебя он не интересует и откровенно портит изначальный замысел игры, смещая фокус её геймплея на секс или сексуальных персонажей? Может, лучше купить/скачать профессиональную игру про секс или с сексуальными персонажами, чем ставить васянский секс-мод на изначально не предназначенную для этого игру? Аналогично с любым другим контент-модом.
>Значит он добавляет что то реально крутое
Ну да, с точки зрения молодого кумера секс-мод - это круто, даже если он в пикселявой игре и размер сисек измеряется буквально считанными пикселями, а геймплей оригинала заточен на бои с боссами и исследования мира, а не сношение всего, что движется.
>>829347
>наоборот моды считаю отрицательным элементом
>потому что моды нарушают целостность игры, задумку автора. Их делают васяны. Это как фанфики
>это по сути переработка всей механики, а не очередные перерисованные текстуры и "хардкор-режим"
Двачую. Фанфики иногда бывают хорошими и на основе одной игры можно создать другую игру, но оригинал ценен сам по себе, без изменений третьих лиц, а все изменения по сути создают новый продукт. Если же оригинал настолько говно, что без модов неиграбелен, то стоит ли вообще за него платить и потом искать моды, если в мире так много других, более качественных в оригинале игр?
Я понимаю желание поставить мод, который добавляет что-то, что тебе очень нравится и хочется увидеть в твоей любимой игре. То есть ты сначала много играешь в игру, а потом случайно находишь мод, который добавляет то, что тебя в целом очень интересует. Ну, можно понять фурфага, который ставит мод на фурри в любимую игру из-за того, что ему по жизни нравятся фурри. Но такие моды как правило нишевые, имеют низкую популярность, либо популярность обеспечена большим посторонним коммьюнити (те же фурри, их много). Но ставить популярные моды на игру, в которую ты даже не играл - имхо, глупо. Другое дело если ты в первую очередь узнал и заинтересовался модом, а игру скачал только как платформу для этого мода, но это уже совсем другая история.
>>829193
Суммарно нагрузка будет значительно выше, что вызовет более скорый перегрев и разряд аккумулятора мобильного устройства (как смартфона, так и ноутбука). В шахматах брутфорсят ходы, чтобы обыграть слишком умного человека, потому что не хотят учить машину оптимальным шахматным стратегиям, которым обучен человек, которого нужно обыграть. У тебя же вопрос оптимизации хода, а это совсем другое.
А в чём разница-то? В реалтайм игре моб принимает решения каждые несколько секунд, а в пошаговой тот же моб будет принимать решения каждые несколько шагов. Рогалик - не шахматы, тут твой противник не обязан изменять свои решения каждый ход, не так ли? Тем более если игрок делает несколько "ходов" за один клик мыши - с какой стати мобы должны думать каждый ход, если игрок думает каждые два десятка ходов?
Вопрос в том, по какой причине "толпа мобов" создаёт нагрузку, если операции, которые она выполняет, должны быть очень примитивны? Логика моба в толпе: "вижу врага на клетке справа от меня -> могу его ударить -> бью его". Даже если у тебя 100 врагов действуют по этому шаблону, это ничтожно малая нагрузка на процессор. Тем более если моб фиксируется на враге и бьёт его, пока тот не умрёт или пока ему не потребуется отступить. Т.е. перед первым ударом моб сканирует 8 соседних клеток, а все следующие ходы он только проверяет собственное здоровье и состояние врага - не пытается ли он сбежать, что будет быстрее сканирования клеток. Вообще, сканирование должно быть редким, тем более мобы не должны сканировать большую зону вокруг себя. Алсо, не обязательно сканировать пустые клетки, если моба волнуют только враги - он может посмотреть список имеющихся мобов в данной локации, и узнать расстояние до них, не проверяя тысячи пустых клеток.
Другими словами, делай мозги мобов глупее - игроку вовсе не нужна крыса с 5 хп и единицей урона, которая каждый ход сканирует область радиусом 100 клеток и выбирает следующего врага с помощью какой-то сложной формулы. Это пушечное мясо и оно не должно много думать. Вообще, вместо таких мобов может думать общий интеллект, особенно если мобы группируются в стайки - он просто ищет цель для них всех раз в N ходов, а дальше простой а-стар находит им пути до цели, раз в M ходов.
А что ты там каждый тик считаешь? 250 тиков за 5 секунд - всего лишь 50 тиков в секунду. Физические движки обычно работают на скорости 60 тиков - для примера, движок Bullet начинает тормозить на процессоре 2007 года при попытке симулировать физику примерно при 500+ независимых физических тел на скорости 60 тиков. Неужели ты хочешь сказать, что твоя симуляция пары десятков тупых мобов на клеточной 2D карте значительно сложнее симуляции достаточно правдоподобной физики 500+ независимых тел? Ещё можно было бы понять, если у тебя на одном экране сотни независимых и по определению умных ИИ, а мы вроде как говорим о простых мобах в узких пещерах, где столько народу просто не поместится.
Теперь хочется набросать прототип пошагового 2D рогалика и убедиться самостоятельно, будет ли он лагать на сравнительно большом количестве мобов...
>Просчитывать все заранее, пока игрок стоит.
Суммарно нагрузка будет значительно выше, что вызовет более скорый перегрев и разряд аккумулятора мобильного устройства (как смартфона, так и ноутбука). В шахматах брутфорсят ходы, чтобы обыграть слишком умного человека, потому что не хотят учить машину оптимальным шахматным стратегиям, которым обучен человек, которого нужно обыграть. У тебя же вопрос оптимизации хода, а это совсем другое.
>В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
А в чём разница-то? В реалтайм игре моб принимает решения каждые несколько секунд, а в пошаговой тот же моб будет принимать решения каждые несколько шагов. Рогалик - не шахматы, тут твой противник не обязан изменять свои решения каждый ход, не так ли? Тем более если игрок делает несколько "ходов" за один клик мыши - с какой стати мобы должны думать каждый ход, если игрок думает каждые два десятка ходов?
>Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку.
Вопрос в том, по какой причине "толпа мобов" создаёт нагрузку, если операции, которые она выполняет, должны быть очень примитивны? Логика моба в толпе: "вижу врага на клетке справа от меня -> могу его ударить -> бью его". Даже если у тебя 100 врагов действуют по этому шаблону, это ничтожно малая нагрузка на процессор. Тем более если моб фиксируется на враге и бьёт его, пока тот не умрёт или пока ему не потребуется отступить. Т.е. перед первым ударом моб сканирует 8 соседних клеток, а все следующие ходы он только проверяет собственное здоровье и состояние врага - не пытается ли он сбежать, что будет быстрее сканирования клеток. Вообще, сканирование должно быть редким, тем более мобы не должны сканировать большую зону вокруг себя. Алсо, не обязательно сканировать пустые клетки, если моба волнуют только враги - он может посмотреть список имеющихся мобов в данной локации, и узнать расстояние до них, не проверяя тысячи пустых клеток.
Другими словами, делай мозги мобов глупее - игроку вовсе не нужна крыса с 5 хп и единицей урона, которая каждый ход сканирует область радиусом 100 клеток и выбирает следующего врага с помощью какой-то сложной формулы. Это пушечное мясо и оно не должно много думать. Вообще, вместо таких мобов может думать общий интеллект, особенно если мобы группируются в стайки - он просто ищет цель для них всех раз в N ходов, а дальше простой а-стар находит им пути до цели, раз в M ходов.
>И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков.
А что ты там каждый тик считаешь? 250 тиков за 5 секунд - всего лишь 50 тиков в секунду. Физические движки обычно работают на скорости 60 тиков - для примера, движок Bullet начинает тормозить на процессоре 2007 года при попытке симулировать физику примерно при 500+ независимых физических тел на скорости 60 тиков. Неужели ты хочешь сказать, что твоя симуляция пары десятков тупых мобов на клеточной 2D карте значительно сложнее симуляции достаточно правдоподобной физики 500+ независимых тел? Ещё можно было бы понять, если у тебя на одном экране сотни независимых и по определению умных ИИ, а мы вроде как говорим о простых мобах в узких пещерах, где столько народу просто не поместится.
Теперь хочется набросать прототип пошагового 2D рогалика и убедиться самостоятельно, будет ли он лагать на сравнительно большом количестве мобов...
>>829193
Суммарно нагрузка будет значительно выше, что вызовет более скорый перегрев и разряд аккумулятора мобильного устройства (как смартфона, так и ноутбука). В шахматах брутфорсят ходы, чтобы обыграть слишком умного человека, потому что не хотят учить машину оптимальным шахматным стратегиям, которым обучен человек, которого нужно обыграть. У тебя же вопрос оптимизации хода, а это совсем другое.
А в чём разница-то? В реалтайм игре моб принимает решения каждые несколько секунд, а в пошаговой тот же моб будет принимать решения каждые несколько шагов. Рогалик - не шахматы, тут твой противник не обязан изменять свои решения каждый ход, не так ли? Тем более если игрок делает несколько "ходов" за один клик мыши - с какой стати мобы должны думать каждый ход, если игрок думает каждые два десятка ходов?
Вопрос в том, по какой причине "толпа мобов" создаёт нагрузку, если операции, которые она выполняет, должны быть очень примитивны? Логика моба в толпе: "вижу врага на клетке справа от меня -> могу его ударить -> бью его". Даже если у тебя 100 врагов действуют по этому шаблону, это ничтожно малая нагрузка на процессор. Тем более если моб фиксируется на враге и бьёт его, пока тот не умрёт или пока ему не потребуется отступить. Т.е. перед первым ударом моб сканирует 8 соседних клеток, а все следующие ходы он только проверяет собственное здоровье и состояние врага - не пытается ли он сбежать, что будет быстрее сканирования клеток. Вообще, сканирование должно быть редким, тем более мобы не должны сканировать большую зону вокруг себя. Алсо, не обязательно сканировать пустые клетки, если моба волнуют только враги - он может посмотреть список имеющихся мобов в данной локации, и узнать расстояние до них, не проверяя тысячи пустых клеток.
Другими словами, делай мозги мобов глупее - игроку вовсе не нужна крыса с 5 хп и единицей урона, которая каждый ход сканирует область радиусом 100 клеток и выбирает следующего врага с помощью какой-то сложной формулы. Это пушечное мясо и оно не должно много думать. Вообще, вместо таких мобов может думать общий интеллект, особенно если мобы группируются в стайки - он просто ищет цель для них всех раз в N ходов, а дальше простой а-стар находит им пути до цели, раз в M ходов.
А что ты там каждый тик считаешь? 250 тиков за 5 секунд - всего лишь 50 тиков в секунду. Физические движки обычно работают на скорости 60 тиков - для примера, движок Bullet начинает тормозить на процессоре 2007 года при попытке симулировать физику примерно при 500+ независимых физических тел на скорости 60 тиков. Неужели ты хочешь сказать, что твоя симуляция пары десятков тупых мобов на клеточной 2D карте значительно сложнее симуляции достаточно правдоподобной физики 500+ независимых тел? Ещё можно было бы понять, если у тебя на одном экране сотни независимых и по определению умных ИИ, а мы вроде как говорим о простых мобах в узких пещерах, где столько народу просто не поместится.
Теперь хочется набросать прототип пошагового 2D рогалика и убедиться самостоятельно, будет ли он лагать на сравнительно большом количестве мобов...
>Просчитывать все заранее, пока игрок стоит.
Суммарно нагрузка будет значительно выше, что вызовет более скорый перегрев и разряд аккумулятора мобильного устройства (как смартфона, так и ноутбука). В шахматах брутфорсят ходы, чтобы обыграть слишком умного человека, потому что не хотят учить машину оптимальным шахматным стратегиям, которым обучен человек, которого нужно обыграть. У тебя же вопрос оптимизации хода, а это совсем другое.
>В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.
А в чём разница-то? В реалтайм игре моб принимает решения каждые несколько секунд, а в пошаговой тот же моб будет принимать решения каждые несколько шагов. Рогалик - не шахматы, тут твой противник не обязан изменять свои решения каждый ход, не так ли? Тем более если игрок делает несколько "ходов" за один клик мыши - с какой стати мобы должны думать каждый ход, если игрок думает каждые два десятка ходов?
>Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку.
Вопрос в том, по какой причине "толпа мобов" создаёт нагрузку, если операции, которые она выполняет, должны быть очень примитивны? Логика моба в толпе: "вижу врага на клетке справа от меня -> могу его ударить -> бью его". Даже если у тебя 100 врагов действуют по этому шаблону, это ничтожно малая нагрузка на процессор. Тем более если моб фиксируется на враге и бьёт его, пока тот не умрёт или пока ему не потребуется отступить. Т.е. перед первым ударом моб сканирует 8 соседних клеток, а все следующие ходы он только проверяет собственное здоровье и состояние врага - не пытается ли он сбежать, что будет быстрее сканирования клеток. Вообще, сканирование должно быть редким, тем более мобы не должны сканировать большую зону вокруг себя. Алсо, не обязательно сканировать пустые клетки, если моба волнуют только враги - он может посмотреть список имеющихся мобов в данной локации, и узнать расстояние до них, не проверяя тысячи пустых клеток.
Другими словами, делай мозги мобов глупее - игроку вовсе не нужна крыса с 5 хп и единицей урона, которая каждый ход сканирует область радиусом 100 клеток и выбирает следующего врага с помощью какой-то сложной формулы. Это пушечное мясо и оно не должно много думать. Вообще, вместо таких мобов может думать общий интеллект, особенно если мобы группируются в стайки - он просто ищет цель для них всех раз в N ходов, а дальше простой а-стар находит им пути до цели, раз в M ходов.
>И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков.
А что ты там каждый тик считаешь? 250 тиков за 5 секунд - всего лишь 50 тиков в секунду. Физические движки обычно работают на скорости 60 тиков - для примера, движок Bullet начинает тормозить на процессоре 2007 года при попытке симулировать физику примерно при 500+ независимых физических тел на скорости 60 тиков. Неужели ты хочешь сказать, что твоя симуляция пары десятков тупых мобов на клеточной 2D карте значительно сложнее симуляции достаточно правдоподобной физики 500+ независимых тел? Ещё можно было бы понять, если у тебя на одном экране сотни независимых и по определению умных ИИ, а мы вроде как говорим о простых мобах в узких пещерах, где столько народу просто не поместится.
Теперь хочется набросать прототип пошагового 2D рогалика и убедиться самостоятельно, будет ли он лагать на сравнительно большом количестве мобов...
>>829362
Разница в том что все должно синхронизироваться каждый тик.
Моб не обязан каждый тик считать ИИ. Естественно, я так не делаю. Они считают раз в 10 тиков в среднем.
Но если моб начал считать, то ровно в этот же тик он должен закончить, иначе либо все рассинхронизируется и начнется бардак, либо придется реализовывать схему которую я описал в самом конце сообщения, сказав что она замороченная.
А есть, кстати, вещи которые буквально каждый тик считаются, физика там, эффекты. Они немного нагрузки создают, но тем не менее.
Я не сомневаюсь. Наверно это связано с тем что они все-таки сделаны не на Юнити с монобехейвиорами, а как-то по-другому)
Ецс удобно, например с могопоточностью комбинировать, еще и поэтому я его использую.
А это уже вопрос дизайна. Может мне нужны умные мобы?
Я задумывал, что они всякие интересные штуки должны делать, предметы подбирать, в инвентаре копаться и так далее. Сейчас они с этим более менее справляются, сильно урезать их функционал из за производительности пока не планирую.
Хотя оптимизировать то что есть не помешало бы.
попробуй, почему нет.
>В чем разница?
Разница в том что все должно синхронизироваться каждый тик.
Моб не обязан каждый тик считать ИИ. Естественно, я так не делаю. Они считают раз в 10 тиков в среднем.
Но если моб начал считать, то ровно в этот же тик он должен закончить, иначе либо все рассинхронизируется и начнется бардак, либо придется реализовывать схему которую я описал в самом конце сообщения, сказав что она замороченная.
А есть, кстати, вещи которые буквально каждый тик считаются, физика там, эффекты. Они немного нагрузки создают, но тем не менее.
>Физические движки работают на скорости 60 тиков
Я не сомневаюсь. Наверно это связано с тем что они все-таки сделаны не на Юнити с монобехейвиорами, а как-то по-другому)
Ецс удобно, например с могопоточностью комбинировать, еще и поэтому я его использую.
>Делай мобов глупее
А это уже вопрос дизайна. Может мне нужны умные мобы?
Я задумывал, что они всякие интересные штуки должны делать, предметы подбирать, в инвентаре копаться и так далее. Сейчас они с этим более менее справляются, сильно урезать их функционал из за производительности пока не планирую.
Хотя оптимизировать то что есть не помешало бы.
>Теперь хочется набросать прототип пошагового 2D рогалика
попробуй, почему нет.
>>829401
Ну так отсортируй мобов по разным тикам, чтобы распределить нагрузку. Или тебе обязательно нужно, чтобы все мобы думали в один конкретный тик?
Так ведь C# не такой уж медленный вроде как...
Тебе шашечки или ехать? Умные мобы ради умных мобов или игра про весёлую конверсию толпы монстров в груду мяса? Можно понять стремление к умному ИИ в симуляторе жизни, где важно, чтобы человечки были похожи на людей, но игрока в рогалик про пещеры и монстров как-то не особо волнуют личные переживания конкретного моба, особенно если эти переживания заставляют перегреваться его игровое устройство. На игровой ИИ обычно жалуются, когда от него ожидают чего-то большего, чем, например, бежать с жутким криком прямо на игрока и взрываться.
Ну, да, ты геймдизайнер, тебе решать. Просто предупреждаю, что большинство игроков скорее всего не заметят и не оценят по достоинству ум большинства мобов, зато заметят низкую производительность визуально сравнительно простой игры (не крайзис уж точно).
Хех, пытаясь разрабатывать игры самостоятельно, быстро понимаешь, почему в других играх такой тупой ИИ, и перестаёшь на него жаловаться...
>Они считают раз в 10 тиков в среднем.
>Но если моб начал считать, то ровно в этот же тик он должен закончить
Ну так отсортируй мобов по разным тикам, чтобы распределить нагрузку. Или тебе обязательно нужно, чтобы все мобы думали в один конкретный тик?
>Наверно это связано с тем что они все-таки сделаны не на Юнити с монобехейвиорами, а как-то по-другому)
Так ведь C# не такой уж медленный вроде как...
>А это уже вопрос дизайна. Может мне нужны умные мобы?
Тебе шашечки или ехать? Умные мобы ради умных мобов или игра про весёлую конверсию толпы монстров в груду мяса? Можно понять стремление к умному ИИ в симуляторе жизни, где важно, чтобы человечки были похожи на людей, но игрока в рогалик про пещеры и монстров как-то не особо волнуют личные переживания конкретного моба, особенно если эти переживания заставляют перегреваться его игровое устройство. На игровой ИИ обычно жалуются, когда от него ожидают чего-то большего, чем, например, бежать с жутким криком прямо на игрока и взрываться.
Ну, да, ты геймдизайнер, тебе решать. Просто предупреждаю, что большинство игроков скорее всего не заметят и не оценят по достоинству ум большинства мобов, зато заметят низкую производительность визуально сравнительно простой игры (не крайзис уж точно).
Хех, пытаясь разрабатывать игры самостоятельно, быстро понимаешь, почему в других играх такой тупой ИИ, и перестаёшь на него жаловаться...
1 Мб, 1140x865>>829458
Наша беседа сподвигла меня на великие свершения.
Я в очередной раз перелопатил искусственный интеллект, обновив unity ecs до последней версии. Он этим летом обновился с 0.17 до аж 0.51. Теперь это почти нормальный инструмент, хотя баги все равно еще есть.
Теперь в более-менее нормальных фпс можно лицезреть замесы такого размера как на скрине. Это 476 агентов.
При этом большую часть нагрузки составляет не сам ИИ а другие неэффективные системы, до которых я еще не добрался с оптимизацией.
Например есть система морали, она сидит на главном потоке и каждый тик пробегается по всем частям тела каждого моба, смотря сколько они получили дамага. Таким образом высчитывает общее количество боли и дальше вычисляет мораль на его основе.
Сейчас сяду переписывать и ее.
И еще когда камеру отдаляешь там огромная нагрузка за счет рендера кучи спрайтов. Надо и этим заняться.
Тут был мудрый анон, посоветовавший вообще все предметы которые не двигаются сшить в одну процедурную большую текстуру. Звучит круто, мне нравится.
Наша беседа сподвигла меня на великие свершения.
Я в очередной раз перелопатил искусственный интеллект, обновив unity ecs до последней версии. Он этим летом обновился с 0.17 до аж 0.51. Теперь это почти нормальный инструмент, хотя баги все равно еще есть.
Теперь в более-менее нормальных фпс можно лицезреть замесы такого размера как на скрине. Это 476 агентов.
При этом большую часть нагрузки составляет не сам ИИ а другие неэффективные системы, до которых я еще не добрался с оптимизацией.
Например есть система морали, она сидит на главном потоке и каждый тик пробегается по всем частям тела каждого моба, смотря сколько они получили дамага. Таким образом высчитывает общее количество боли и дальше вычисляет мораль на его основе.
Сейчас сяду переписывать и ее.
И еще когда камеру отдаляешь там огромная нагрузка за счет рендера кучи спрайтов. Надо и этим заняться.
Тут был мудрый анон, посоветовавший вообще все предметы которые не двигаются сшить в одну процедурную большую текстуру. Звучит круто, мне нравится.
>>829785
Чего? Почему не добавлять боль в той же процедуре где ты наносишь дамаг.
>каждый тик пробегается по всем частям тела каждого моба, смотря сколько они получили дамага
Чего? Почему не добавлять боль в той же процедуре где ты наносишь дамаг.
221 Кб, 1279x978>>829798
ну вообще не совсем так
У меня на каждом мобе висит буфер "модификаторов морали", которые добавляются туда из разных источников, в течении тика.
Одним из источников является дамаг по частям тела.
Система проходит только по задамаженым частям тела и добавляет эти модификаторы.
Потом вторая система суммирует их все и это дает конечное изменение морали за тик.
А боль и дамаг лучше держать в разных местах, так как дамажить можно что угодно, не обязательно чью-то часть тела.
На самом деле нагрузка была даже не из за самого принципа работы системы, я в другом месте там ошибку нашел. Так или иначе я ее уже починил, теперь эта система занимает что-то вроде 3 мс.
Вот так у меня сейчас профайлинг выглядит. Зеленое это
Всего в пике 220 мс нагрузки.
Из них 195 это скрипты а 15 рендерингчто для рендеринга очень много.
Путеискатель 65 мс жрет, а он вроде уже по максимуму оптимизирован.
Но это при 470 агентах. Нормально.
Следующими идут коллизии 17мс и смерть существ 16 мс. Не знаю что там так нагружает, я туда пока не лез.
ну вообще не совсем так
У меня на каждом мобе висит буфер "модификаторов морали", которые добавляются туда из разных источников, в течении тика.
Одним из источников является дамаг по частям тела.
Система проходит только по задамаженым частям тела и добавляет эти модификаторы.
Потом вторая система суммирует их все и это дает конечное изменение морали за тик.
А боль и дамаг лучше держать в разных местах, так как дамажить можно что угодно, не обязательно чью-то часть тела.
На самом деле нагрузка была даже не из за самого принципа работы системы, я в другом месте там ошибку нашел. Так или иначе я ее уже починил, теперь эта система занимает что-то вроде 3 мс.
Вот так у меня сейчас профайлинг выглядит. Зеленое это
Всего в пике 220 мс нагрузки.
Из них 195 это скрипты а 15 рендерингчто для рендеринга очень много.
Путеискатель 65 мс жрет, а он вроде уже по максимуму оптимизирован.
Но это при 470 агентах. Нормально.
Следующими идут коллизии 17мс и смерть существ 16 мс. Не знаю что там так нагружает, я туда пока не лез.
>>829820
Самая распространенная оптимизация пасфайндинга - не искать пути каждый кадр для всех юнитов, вероятность того что всем срочно надо поменять путь крайне мала, поэтому их можно разделить на батчи.
Самая распространенная оптимизация пасфайндинга - не искать пути каждый кадр для всех юнитов, вероятность того что всем срочно надо поменять путь крайне мала, поэтому их можно разделить на батчи.
>>829833
Да тут вообще надо всё делать без обходов, а в отдельном планировщике, который будет формировать бакеты вычислений и постепенно обновлять весь стейт. Когда агентов сотни, обычные методы не годятся.
Да тут вообще надо всё делать без обходов, а в отдельном планировщике, который будет формировать бакеты вычислений и постепенно обновлять весь стейт. Когда агентов сотни, обычные методы не годятся.
>>829833
>>829837
На самом деле есть какой-то момент когда надо остановиться. Я все-таки эту толпу заспавнил ради стресс-теста, в реальности там больше 15 тел одновременно собираться не будет.
Но как же это затягивает.
Сделал так что теперь мобы используют не только первую точку построенного пути а первые три. Больше точек не вижу смысла пока ставить.
Конечно перед тем как сделать ход моб проверяет, не появилось ли у него на пути чего-нибудь. Если появилось то перестраивает путь.
Теперь нагрузка от путеискателя 25 мс. Я думаю, этого пока достаточно.
>>829837
На самом деле есть какой-то момент когда надо остановиться. Я все-таки эту толпу заспавнил ради стресс-теста, в реальности там больше 15 тел одновременно собираться не будет.
Но как же это затягивает.
Сделал так что теперь мобы используют не только первую точку построенного пути а первые три. Больше точек не вижу смысла пока ставить.
Конечно перед тем как сделать ход моб проверяет, не появилось ли у него на пути чего-нибудь. Если появилось то перестраивает путь.
Теперь нагрузка от путеискателя 25 мс. Я думаю, этого пока достаточно.
>>829820
Хотел прилепить картинку-мем, но не хочу обидеть, т.к. ты всё же адекватный анон. Возможно даже я не прав и твой метод действительно имеет смысл... Но по описанию это всё выглядит так, будто ты абузишь ECS и в хвост и в гриву, рассчитывая, что она магически всё оптимизирует за тебя. Это не так. Если ты делаешь несколько циклов обхода массива подряд, ты в любом случае тратишь дополнительное время, которое можно было бы сэкономить, сделав все дела за один проход. Да, ECS даёт некоторое ускорение в случае работы с большими однородными массивами данных, но это не панацея, архитектура всё равно должна быть продумана. Если лепить системы абы как, можно сделать такую игру на ECS, которая будет медленнее обычного ООП на скриптовом языке. Собственно поэтому я и другие сторонимся ECS, для эффективной реализации этой парадигмы необходимо иметь в голове совсем другой подход к разработке ПО, иначе получится хрень.
3 мс из 16 мс на кадр, если ты хочешь стабильные 60 квс.
А у тебя включена вертикальная синхронизация? По идее, с включённой вертикальной синхронизацией рендеринг кадра всегда должен занимать 16.6 мс на графике. Если же у тебя реально 15 мс на кадр, то я даже не знаю, сколько же у тебя там спрайтов, десять тысяч?
Что такое "коллизии" в клеточном мире? У тебя там вообще никаких физических объектов быть не должно, откуда взяться коллизиям? Или что ты так называешь?
Добавляй мёртвых существ в очередь и освобождай их ресурсы по мере возможности... или в ECS всё не так просто? Если я правильно понимаю, удаление моба в ECS вызывает удаление всех его компонентов, которые могут быть в середине огромных массивов, которым придётся сместить половину данных на одну позицию в сторону удалённой. Понятия не имею, как можно оптимизировать удаление компонентов в ECS, есть ли какая-то официальная рекомендация Unity по этому вопросу? Для сравнения, в ООП обычно рекомендуют не уничтожать объекты лишний раз и использовать их повторно, чтобы не было лишних операций с кучей (освобождение и поиск нового места), и это, если я правильно помню, в туториалах Unity советовали (т.к. сборщик мусора C# - одна из печально известных проблем всех игр на Unity).
>>829861
А почему только три? Представь себе реальный мир. Тебе нужно пройти 10 км через город. Ты знаешь карту города и строишь маршрут по известным тебе дорогам прямо до пункта назначения. Ты не меняешь этот маршрут до тех пор, пока тебе не встретятся непреодолимые препятствия вроде перекопанной поперёк дороги. Но даже так, ты узнаешь об этой проблеме только когда дойдёшь до неё и убедишься в её непреодолимости, только тогда ты запросишь в своих мозгах построение нового маршрута и, возможно, даже пойдёшь сперва назад, т.е. финальный путь будет совсем не таким оптимальным, как хотелось бы.
Т.е. если моб знает наизусть пещеру, в которой он живёт, он проложит маршрут до цели, даже если она скрыта стенами пещеры, и будет идти до неё, пока не дойдёт, прямо перед ним (1-2 клетки маршрута) не появится препятствия или его не отвлекут от движения (урон). И это, я считаю, будет выглядеть достаточно реалистично. Не вижу смысла вычислять новый путь каждые три клетки, особенно если путь достаточно длинный (десятки клеток).
Хотя для 100% реализма каждый моб должен иметь индивидуальные воспоминания о форме карты. То есть если моб находится в комнате А и помнит комнату Б, а в это время в комнате Б произошли радикальные изменения, моб должен построить маршрут до предмета в комнате Б по своим воспоминаниям - устаревшей копии карты в его мозгах, и лишь после того, как он войдёт в комнату Б, он узнает о том, что его маршрут неправильный или предмета там нет, и будет решать, как двигаться дальше или что дальше делать, если пройти теперь нельзя. Но это, как ты понимаешь, совсем другой уровень ИИ и простому рогалику про убийство мобов в подземельях такое просто не нужно.
>Система проходит только по задамаженым частям тела и добавляет эти модификаторы.
>Потом вторая система суммирует их все и это дает конечное изменение морали за тик.
Хотел прилепить картинку-мем, но не хочу обидеть, т.к. ты всё же адекватный анон. Возможно даже я не прав и твой метод действительно имеет смысл... Но по описанию это всё выглядит так, будто ты абузишь ECS и в хвост и в гриву, рассчитывая, что она магически всё оптимизирует за тебя. Это не так. Если ты делаешь несколько циклов обхода массива подряд, ты в любом случае тратишь дополнительное время, которое можно было бы сэкономить, сделав все дела за один проход. Да, ECS даёт некоторое ускорение в случае работы с большими однородными массивами данных, но это не панацея, архитектура всё равно должна быть продумана. Если лепить системы абы как, можно сделать такую игру на ECS, которая будет медленнее обычного ООП на скриптовом языке. Собственно поэтому я и другие сторонимся ECS, для эффективной реализации этой парадигмы необходимо иметь в голове совсем другой подход к разработке ПО, иначе получится хрень.
>Так или иначе я ее уже починил, теперь эта система занимает что-то вроде 3 мс.
3 мс из 16 мс на кадр, если ты хочешь стабильные 60 квс.
>15 мс рендеринг, что для рендеринга очень много.
А у тебя включена вертикальная синхронизация? По идее, с включённой вертикальной синхронизацией рендеринг кадра всегда должен занимать 16.6 мс на графике. Если же у тебя реально 15 мс на кадр, то я даже не знаю, сколько же у тебя там спрайтов, десять тысяч?
>коллизии 17мс
Что такое "коллизии" в клеточном мире? У тебя там вообще никаких физических объектов быть не должно, откуда взяться коллизиям? Или что ты так называешь?
>смерть существ 16 мс
Добавляй мёртвых существ в очередь и освобождай их ресурсы по мере возможности... или в ECS всё не так просто? Если я правильно понимаю, удаление моба в ECS вызывает удаление всех его компонентов, которые могут быть в середине огромных массивов, которым придётся сместить половину данных на одну позицию в сторону удалённой. Понятия не имею, как можно оптимизировать удаление компонентов в ECS, есть ли какая-то официальная рекомендация Unity по этому вопросу? Для сравнения, в ООП обычно рекомендуют не уничтожать объекты лишний раз и использовать их повторно, чтобы не было лишних операций с кучей (освобождение и поиск нового места), и это, если я правильно помню, в туториалах Unity советовали (т.к. сборщик мусора C# - одна из печально известных проблем всех игр на Unity).
>>829861
>Сделал так что теперь мобы используют не только первую точку построенного пути а первые три. Больше точек не вижу смысла пока ставить.
>Конечно перед тем как сделать ход моб проверяет, не появилось ли у него на пути чего-нибудь.
А почему только три? Представь себе реальный мир. Тебе нужно пройти 10 км через город. Ты знаешь карту города и строишь маршрут по известным тебе дорогам прямо до пункта назначения. Ты не меняешь этот маршрут до тех пор, пока тебе не встретятся непреодолимые препятствия вроде перекопанной поперёк дороги. Но даже так, ты узнаешь об этой проблеме только когда дойдёшь до неё и убедишься в её непреодолимости, только тогда ты запросишь в своих мозгах построение нового маршрута и, возможно, даже пойдёшь сперва назад, т.е. финальный путь будет совсем не таким оптимальным, как хотелось бы.
Т.е. если моб знает наизусть пещеру, в которой он живёт, он проложит маршрут до цели, даже если она скрыта стенами пещеры, и будет идти до неё, пока не дойдёт, прямо перед ним (1-2 клетки маршрута) не появится препятствия или его не отвлекут от движения (урон). И это, я считаю, будет выглядеть достаточно реалистично. Не вижу смысла вычислять новый путь каждые три клетки, особенно если путь достаточно длинный (десятки клеток).
Хотя для 100% реализма каждый моб должен иметь индивидуальные воспоминания о форме карты. То есть если моб находится в комнате А и помнит комнату Б, а в это время в комнате Б произошли радикальные изменения, моб должен построить маршрут до предмета в комнате Б по своим воспоминаниям - устаревшей копии карты в его мозгах, и лишь после того, как он войдёт в комнату Б, он узнает о том, что его маршрут неправильный или предмета там нет, и будет решать, как двигаться дальше или что дальше делать, если пройти теперь нельзя. Но это, как ты понимаешь, совсем другой уровень ИИ и простому рогалику про убийство мобов в подземельях такое просто не нужно.
>>829820
Хотел прилепить картинку-мем, но не хочу обидеть, т.к. ты всё же адекватный анон. Возможно даже я не прав и твой метод действительно имеет смысл... Но по описанию это всё выглядит так, будто ты абузишь ECS и в хвост и в гриву, рассчитывая, что она магически всё оптимизирует за тебя. Это не так. Если ты делаешь несколько циклов обхода массива подряд, ты в любом случае тратишь дополнительное время, которое можно было бы сэкономить, сделав все дела за один проход. Да, ECS даёт некоторое ускорение в случае работы с большими однородными массивами данных, но это не панацея, архитектура всё равно должна быть продумана. Если лепить системы абы как, можно сделать такую игру на ECS, которая будет медленнее обычного ООП на скриптовом языке. Собственно поэтому я и другие сторонимся ECS, для эффективной реализации этой парадигмы необходимо иметь в голове совсем другой подход к разработке ПО, иначе получится хрень.
3 мс из 16 мс на кадр, если ты хочешь стабильные 60 квс.
А у тебя включена вертикальная синхронизация? По идее, с включённой вертикальной синхронизацией рендеринг кадра всегда должен занимать 16.6 мс на графике. Если же у тебя реально 15 мс на кадр, то я даже не знаю, сколько же у тебя там спрайтов, десять тысяч?
Что такое "коллизии" в клеточном мире? У тебя там вообще никаких физических объектов быть не должно, откуда взяться коллизиям? Или что ты так называешь?
Добавляй мёртвых существ в очередь и освобождай их ресурсы по мере возможности... или в ECS всё не так просто? Если я правильно понимаю, удаление моба в ECS вызывает удаление всех его компонентов, которые могут быть в середине огромных массивов, которым придётся сместить половину данных на одну позицию в сторону удалённой. Понятия не имею, как можно оптимизировать удаление компонентов в ECS, есть ли какая-то официальная рекомендация Unity по этому вопросу? Для сравнения, в ООП обычно рекомендуют не уничтожать объекты лишний раз и использовать их повторно, чтобы не было лишних операций с кучей (освобождение и поиск нового места), и это, если я правильно помню, в туториалах Unity советовали (т.к. сборщик мусора C# - одна из печально известных проблем всех игр на Unity).
>>829861
А почему только три? Представь себе реальный мир. Тебе нужно пройти 10 км через город. Ты знаешь карту города и строишь маршрут по известным тебе дорогам прямо до пункта назначения. Ты не меняешь этот маршрут до тех пор, пока тебе не встретятся непреодолимые препятствия вроде перекопанной поперёк дороги. Но даже так, ты узнаешь об этой проблеме только когда дойдёшь до неё и убедишься в её непреодолимости, только тогда ты запросишь в своих мозгах построение нового маршрута и, возможно, даже пойдёшь сперва назад, т.е. финальный путь будет совсем не таким оптимальным, как хотелось бы.
Т.е. если моб знает наизусть пещеру, в которой он живёт, он проложит маршрут до цели, даже если она скрыта стенами пещеры, и будет идти до неё, пока не дойдёт, прямо перед ним (1-2 клетки маршрута) не появится препятствия или его не отвлекут от движения (урон). И это, я считаю, будет выглядеть достаточно реалистично. Не вижу смысла вычислять новый путь каждые три клетки, особенно если путь достаточно длинный (десятки клеток).
Хотя для 100% реализма каждый моб должен иметь индивидуальные воспоминания о форме карты. То есть если моб находится в комнате А и помнит комнату Б, а в это время в комнате Б произошли радикальные изменения, моб должен построить маршрут до предмета в комнате Б по своим воспоминаниям - устаревшей копии карты в его мозгах, и лишь после того, как он войдёт в комнату Б, он узнает о том, что его маршрут неправильный или предмета там нет, и будет решать, как двигаться дальше или что дальше делать, если пройти теперь нельзя. Но это, как ты понимаешь, совсем другой уровень ИИ и простому рогалику про убийство мобов в подземельях такое просто не нужно.
>Система проходит только по задамаженым частям тела и добавляет эти модификаторы.
>Потом вторая система суммирует их все и это дает конечное изменение морали за тик.
Хотел прилепить картинку-мем, но не хочу обидеть, т.к. ты всё же адекватный анон. Возможно даже я не прав и твой метод действительно имеет смысл... Но по описанию это всё выглядит так, будто ты абузишь ECS и в хвост и в гриву, рассчитывая, что она магически всё оптимизирует за тебя. Это не так. Если ты делаешь несколько циклов обхода массива подряд, ты в любом случае тратишь дополнительное время, которое можно было бы сэкономить, сделав все дела за один проход. Да, ECS даёт некоторое ускорение в случае работы с большими однородными массивами данных, но это не панацея, архитектура всё равно должна быть продумана. Если лепить системы абы как, можно сделать такую игру на ECS, которая будет медленнее обычного ООП на скриптовом языке. Собственно поэтому я и другие сторонимся ECS, для эффективной реализации этой парадигмы необходимо иметь в голове совсем другой подход к разработке ПО, иначе получится хрень.
>Так или иначе я ее уже починил, теперь эта система занимает что-то вроде 3 мс.
3 мс из 16 мс на кадр, если ты хочешь стабильные 60 квс.
>15 мс рендеринг, что для рендеринга очень много.
А у тебя включена вертикальная синхронизация? По идее, с включённой вертикальной синхронизацией рендеринг кадра всегда должен занимать 16.6 мс на графике. Если же у тебя реально 15 мс на кадр, то я даже не знаю, сколько же у тебя там спрайтов, десять тысяч?
>коллизии 17мс
Что такое "коллизии" в клеточном мире? У тебя там вообще никаких физических объектов быть не должно, откуда взяться коллизиям? Или что ты так называешь?
>смерть существ 16 мс
Добавляй мёртвых существ в очередь и освобождай их ресурсы по мере возможности... или в ECS всё не так просто? Если я правильно понимаю, удаление моба в ECS вызывает удаление всех его компонентов, которые могут быть в середине огромных массивов, которым придётся сместить половину данных на одну позицию в сторону удалённой. Понятия не имею, как можно оптимизировать удаление компонентов в ECS, есть ли какая-то официальная рекомендация Unity по этому вопросу? Для сравнения, в ООП обычно рекомендуют не уничтожать объекты лишний раз и использовать их повторно, чтобы не было лишних операций с кучей (освобождение и поиск нового места), и это, если я правильно помню, в туториалах Unity советовали (т.к. сборщик мусора C# - одна из печально известных проблем всех игр на Unity).
>>829861
>Сделал так что теперь мобы используют не только первую точку построенного пути а первые три. Больше точек не вижу смысла пока ставить.
>Конечно перед тем как сделать ход моб проверяет, не появилось ли у него на пути чего-нибудь.
А почему только три? Представь себе реальный мир. Тебе нужно пройти 10 км через город. Ты знаешь карту города и строишь маршрут по известным тебе дорогам прямо до пункта назначения. Ты не меняешь этот маршрут до тех пор, пока тебе не встретятся непреодолимые препятствия вроде перекопанной поперёк дороги. Но даже так, ты узнаешь об этой проблеме только когда дойдёшь до неё и убедишься в её непреодолимости, только тогда ты запросишь в своих мозгах построение нового маршрута и, возможно, даже пойдёшь сперва назад, т.е. финальный путь будет совсем не таким оптимальным, как хотелось бы.
Т.е. если моб знает наизусть пещеру, в которой он живёт, он проложит маршрут до цели, даже если она скрыта стенами пещеры, и будет идти до неё, пока не дойдёт, прямо перед ним (1-2 клетки маршрута) не появится препятствия или его не отвлекут от движения (урон). И это, я считаю, будет выглядеть достаточно реалистично. Не вижу смысла вычислять новый путь каждые три клетки, особенно если путь достаточно длинный (десятки клеток).
Хотя для 100% реализма каждый моб должен иметь индивидуальные воспоминания о форме карты. То есть если моб находится в комнате А и помнит комнату Б, а в это время в комнате Б произошли радикальные изменения, моб должен построить маршрут до предмета в комнате Б по своим воспоминаниям - устаревшей копии карты в его мозгах, и лишь после того, как он войдёт в комнату Б, он узнает о том, что его маршрут неправильный или предмета там нет, и будет решать, как двигаться дальше или что дальше делать, если пройти теперь нельзя. Но это, как ты понимаешь, совсем другой уровень ИИ и простому рогалику про убийство мобов в подземельях такое просто не нужно.
>>829911
На самом деле там не так эпично как кажется. Дерутся только первые ряды мобов, а остальные тупят сзади пытаясь протиснуться вперёд или обойти с боков. А потом у одной из сторон сдают нервы, они пытаются сбежать и стоят в огромной пробке пока их не добьют.
Когда закончу переделывать системы запилю отдельную арену для теста этого побоища и сниму видос.
На самом деле там не так эпично как кажется. Дерутся только первые ряды мобов, а остальные тупят сзади пытаясь протиснуться вперёд или обойти с боков. А потом у одной из сторон сдают нервы, они пытаются сбежать и стоят в огромной пробке пока их не добьют.
Когда закончу переделывать системы запилю отдельную арену для теста этого побоища и сниму видос.
>>829992
Если это бой двух организованных групп, разве у них не должен быть какой-то руководитель, который будет разруливать неоптимальное построение, например, меняя раненных бойцов на свежих, прикрывая лучников и магов бойцами с щитами и так далее? В смысле, если ты хочешь в игре не только тупых крыс и зомби, дерущихся каждый сам за себя, но и организованных бандитов, у них должен быть кто-то в роли предводителя. Хотя даже у глупых, но социальных животных обычно есть "альфы", за которыми сравнительно организованно идёт более слабая толпа (видел мем с волчицей?). Так что оптимизация рода "один строит маршрут и все идут друг за другом по нему" - это даже более реалистично, чем оптимально, лол. Собственно мозг тоже заботится об оптимизациях разного рода, так что ничего удивительного тут нет...
А у них разве нет возможности поменяться местами? Тем более если это союзники. В рогаликах, в которые я играх, союзники могут меняться местами, примерно как король с ладьёй в шахматах, но неограниченно. Визуально у тебя довольно крупные клетки, было бы странно, если бы мобы не могли меняться местами друг с другом. Тогда раненные мобы имели бы возможность легко сбежать в тыл большой толпы союзников и бой был бы намного живее.
>Дерутся только первые ряды мобов
Если это бой двух организованных групп, разве у них не должен быть какой-то руководитель, который будет разруливать неоптимальное построение, например, меняя раненных бойцов на свежих, прикрывая лучников и магов бойцами с щитами и так далее? В смысле, если ты хочешь в игре не только тупых крыс и зомби, дерущихся каждый сам за себя, но и организованных бандитов, у них должен быть кто-то в роли предводителя. Хотя даже у глупых, но социальных животных обычно есть "альфы", за которыми сравнительно организованно идёт более слабая толпа (видел мем с волчицей?). Так что оптимизация рода "один строит маршрут и все идут друг за другом по нему" - это даже более реалистично, чем оптимально, лол. Собственно мозг тоже заботится об оптимизациях разного рода, так что ничего удивительного тут нет...
>стоят в огромной пробке пока их не добьют
А у них разве нет возможности поменяться местами? Тем более если это союзники. В рогаликах, в которые я играх, союзники могут меняться местами, примерно как король с ладьёй в шахматах, но неограниченно. Визуально у тебя довольно крупные клетки, было бы странно, если бы мобы не могли меняться местами друг с другом. Тогда раненные мобы имели бы возможность легко сбежать в тыл большой толпы союзников и бой был бы намного живее.
>>829991
Все значения см которые я привожу замеряются с этой 470-мобной толпой. Точнее две дерущихся толпы по 235 тел
Я использую ее для того чтобы лучше контролировать какой результат моя оптимизация оказывает на системы.
В реальности такой нагрузки даже близко не планируется.
3мс намерено тоже там. В нормальной ситуации это не 3 мс а ноль-точка-че-то-там мс.
Кстати, на счёт фпс, вообще не особо понятно как их мерять, все эти цифры это же пиковая нагрузка.
Что там системе киллов, я не помню, писал ее давно. Во всяком случае это точно не уничтожение сущностей, умерший моб не уничтожается, а просто теряет свой ИИ вместе с парой других компонентов и падает на пол.
Там как минимум в одном месте Debug.log который сообщает кто кого убил и как. Сообщения дебага очень дорогие.
Сто процентов есть способ сделать это в разы дешевле, я просто туда пока не добрался, всему свое время.
Пути по 10 клеток в длину это слишком много. Моб идёт бить игрока в 10 клетках, а игрок взял и телепортировался и теперь он у него за спиной вообще. Если моб пройдет по инерции три клетки то это нормально а 10 уже не очень. Соотношение оптимизация/функционал плохое.
Можно конечно проверять, как далеко ушла цель от конечной точки маршрута, и тогда перестраивать, но мне что-то лень это прописывать, мб потом сделаю.
Вижу, ты тут не так уж давно.
Физика играет в моем рогалик не последнюю роль, а раньше ее было значительно больше. Объекты могут двигаться и сталкиваться если их бросают или если ими атакуют из рук. При каждом столкновении вычисляется коллизия.
Каждый предмет в игре делится на части, их потенциально может быть сколько угодно, но минимум одна.
Предположим моб атакует топором другого моба.
Вычисляется в какую часть моба попал топор. Это рука.
Вычисляется в какую часть этой руки попал топор. Это щит.
Вычисляется какой частью топор попал по щиту.
К счастью топор имеет только одну часть, это он сам. Как собственно и щит, хотя ничто не мешает ещё углубить эту иерархию.
И так, мы имеем две финальных части, это топор и щит. Щит, как и любая часть прикреплен к своей родительской части соединением.
Вычисляется достаточно ли урона топора + скорости топора, чтобы порвать соединение между рукой и щитом. (Прочность соединения зависит от прочности предмета и характеристик моба)
Если да то после коллизии щит улетает и сталкивается дальше. Если нет то остаётся.
Дальше считается дамаг. Дамаг топора по щиту и щита по топору. Часть дамага топора по щиту проходит через щит в руку которая его держит.
Потом взаимно накладываются эффекты-при-стоклновении, если они были.
Если удар был такой силы что раздербанило и саму руку, то отрывается и рука. Если бы это был не рука а тело или голова то наступает смэрть.
Ещё через всю эту цепочку проходит инфа о том кто ее запустил, так что если мобу снесло голову щитом который выбило из рук другого моба взрывной волной от бомбы, брошенной игроком то все об этом узнают.
Да, я понимаю, местами это переусложненная система. Ты можешь сказать что тут многое из этого нафиг не нужно, и будешь прав. Но мне так прикольно. Я экспериментирую, ищу новые механики. На данный момент эта система норм, хотя и не получила того развития которое я планировал. По факту сейчас частями тела обладают только мобы.
Вообще система уже прошла несколько циклов упрощения, изначально там ещё рикошеты были, масса и ещё всякое разное...
Плюс с оптимизацией я туда пока не зашел.
Все значения см которые я привожу замеряются с этой 470-мобной толпой. Точнее две дерущихся толпы по 235 тел
Я использую ее для того чтобы лучше контролировать какой результат моя оптимизация оказывает на системы.
В реальности такой нагрузки даже близко не планируется.
3мс намерено тоже там. В нормальной ситуации это не 3 мс а ноль-точка-че-то-там мс.
Кстати, на счёт фпс, вообще не особо понятно как их мерять, все эти цифры это же пиковая нагрузка.
Что там системе киллов, я не помню, писал ее давно. Во всяком случае это точно не уничтожение сущностей, умерший моб не уничтожается, а просто теряет свой ИИ вместе с парой других компонентов и падает на пол.
Там как минимум в одном месте Debug.log который сообщает кто кого убил и как. Сообщения дебага очень дорогие.
Сто процентов есть способ сделать это в разы дешевле, я просто туда пока не добрался, всему свое время.
Пути по 10 клеток в длину это слишком много. Моб идёт бить игрока в 10 клетках, а игрок взял и телепортировался и теперь он у него за спиной вообще. Если моб пройдет по инерции три клетки то это нормально а 10 уже не очень. Соотношение оптимизация/функционал плохое.
Можно конечно проверять, как далеко ушла цель от конечной точки маршрута, и тогда перестраивать, но мне что-то лень это прописывать, мб потом сделаю.
>Что такое коллизии
Вижу, ты тут не так уж давно.
Физика играет в моем рогалик не последнюю роль, а раньше ее было значительно больше. Объекты могут двигаться и сталкиваться если их бросают или если ими атакуют из рук. При каждом столкновении вычисляется коллизия.
Каждый предмет в игре делится на части, их потенциально может быть сколько угодно, но минимум одна.
Предположим моб атакует топором другого моба.
Вычисляется в какую часть моба попал топор. Это рука.
Вычисляется в какую часть этой руки попал топор. Это щит.
Вычисляется какой частью топор попал по щиту.
К счастью топор имеет только одну часть, это он сам. Как собственно и щит, хотя ничто не мешает ещё углубить эту иерархию.
И так, мы имеем две финальных части, это топор и щит. Щит, как и любая часть прикреплен к своей родительской части соединением.
Вычисляется достаточно ли урона топора + скорости топора, чтобы порвать соединение между рукой и щитом. (Прочность соединения зависит от прочности предмета и характеристик моба)
Если да то после коллизии щит улетает и сталкивается дальше. Если нет то остаётся.
Дальше считается дамаг. Дамаг топора по щиту и щита по топору. Часть дамага топора по щиту проходит через щит в руку которая его держит.
Потом взаимно накладываются эффекты-при-стоклновении, если они были.
Если удар был такой силы что раздербанило и саму руку, то отрывается и рука. Если бы это был не рука а тело или голова то наступает смэрть.
Ещё через всю эту цепочку проходит инфа о том кто ее запустил, так что если мобу снесло голову щитом который выбило из рук другого моба взрывной волной от бомбы, брошенной игроком то все об этом узнают.
Да, я понимаю, местами это переусложненная система. Ты можешь сказать что тут многое из этого нафиг не нужно, и будешь прав. Но мне так прикольно. Я экспериментирую, ищу новые механики. На данный момент эта система норм, хотя и не получила того развития которое я планировал. По факту сейчас частями тела обладают только мобы.
Вообще система уже прошла несколько циклов упрощения, изначально там ещё рикошеты были, масса и ещё всякое разное...
Плюс с оптимизацией я туда пока не зашел.
>>829991
Все значения см которые я привожу замеряются с этой 470-мобной толпой. Точнее две дерущихся толпы по 235 тел
Я использую ее для того чтобы лучше контролировать какой результат моя оптимизация оказывает на системы.
В реальности такой нагрузки даже близко не планируется.
3мс намерено тоже там. В нормальной ситуации это не 3 мс а ноль-точка-че-то-там мс.
Кстати, на счёт фпс, вообще не особо понятно как их мерять, все эти цифры это же пиковая нагрузка.
Что там системе киллов, я не помню, писал ее давно. Во всяком случае это точно не уничтожение сущностей, умерший моб не уничтожается, а просто теряет свой ИИ вместе с парой других компонентов и падает на пол.
Там как минимум в одном месте Debug.log который сообщает кто кого убил и как. Сообщения дебага очень дорогие.
Сто процентов есть способ сделать это в разы дешевле, я просто туда пока не добрался, всему свое время.
Пути по 10 клеток в длину это слишком много. Моб идёт бить игрока в 10 клетках, а игрок взял и телепортировался и теперь он у него за спиной вообще. Если моб пройдет по инерции три клетки то это нормально а 10 уже не очень. Соотношение оптимизация/функционал плохое.
Можно конечно проверять, как далеко ушла цель от конечной точки маршрута, и тогда перестраивать, но мне что-то лень это прописывать, мб потом сделаю.
Вижу, ты тут не так уж давно.
Физика играет в моем рогалик не последнюю роль, а раньше ее было значительно больше. Объекты могут двигаться и сталкиваться если их бросают или если ими атакуют из рук. При каждом столкновении вычисляется коллизия.
Каждый предмет в игре делится на части, их потенциально может быть сколько угодно, но минимум одна.
Предположим моб атакует топором другого моба.
Вычисляется в какую часть моба попал топор. Это рука.
Вычисляется в какую часть этой руки попал топор. Это щит.
Вычисляется какой частью топор попал по щиту.
К счастью топор имеет только одну часть, это он сам. Как собственно и щит, хотя ничто не мешает ещё углубить эту иерархию.
И так, мы имеем две финальных части, это топор и щит. Щит, как и любая часть прикреплен к своей родительской части соединением.
Вычисляется достаточно ли урона топора + скорости топора, чтобы порвать соединение между рукой и щитом. (Прочность соединения зависит от прочности предмета и характеристик моба)
Если да то после коллизии щит улетает и сталкивается дальше. Если нет то остаётся.
Дальше считается дамаг. Дамаг топора по щиту и щита по топору. Часть дамага топора по щиту проходит через щит в руку которая его держит.
Потом взаимно накладываются эффекты-при-стоклновении, если они были.
Если удар был такой силы что раздербанило и саму руку, то отрывается и рука. Если бы это был не рука а тело или голова то наступает смэрть.
Ещё через всю эту цепочку проходит инфа о том кто ее запустил, так что если мобу снесло голову щитом который выбило из рук другого моба взрывной волной от бомбы, брошенной игроком то все об этом узнают.
Да, я понимаю, местами это переусложненная система. Ты можешь сказать что тут многое из этого нафиг не нужно, и будешь прав. Но мне так прикольно. Я экспериментирую, ищу новые механики. На данный момент эта система норм, хотя и не получила того развития которое я планировал. По факту сейчас частями тела обладают только мобы.
Вообще система уже прошла несколько циклов упрощения, изначально там ещё рикошеты были, масса и ещё всякое разное...
Плюс с оптимизацией я туда пока не зашел.
Все значения см которые я привожу замеряются с этой 470-мобной толпой. Точнее две дерущихся толпы по 235 тел
Я использую ее для того чтобы лучше контролировать какой результат моя оптимизация оказывает на системы.
В реальности такой нагрузки даже близко не планируется.
3мс намерено тоже там. В нормальной ситуации это не 3 мс а ноль-точка-че-то-там мс.
Кстати, на счёт фпс, вообще не особо понятно как их мерять, все эти цифры это же пиковая нагрузка.
Что там системе киллов, я не помню, писал ее давно. Во всяком случае это точно не уничтожение сущностей, умерший моб не уничтожается, а просто теряет свой ИИ вместе с парой других компонентов и падает на пол.
Там как минимум в одном месте Debug.log который сообщает кто кого убил и как. Сообщения дебага очень дорогие.
Сто процентов есть способ сделать это в разы дешевле, я просто туда пока не добрался, всему свое время.
Пути по 10 клеток в длину это слишком много. Моб идёт бить игрока в 10 клетках, а игрок взял и телепортировался и теперь он у него за спиной вообще. Если моб пройдет по инерции три клетки то это нормально а 10 уже не очень. Соотношение оптимизация/функционал плохое.
Можно конечно проверять, как далеко ушла цель от конечной точки маршрута, и тогда перестраивать, но мне что-то лень это прописывать, мб потом сделаю.
>Что такое коллизии
Вижу, ты тут не так уж давно.
Физика играет в моем рогалик не последнюю роль, а раньше ее было значительно больше. Объекты могут двигаться и сталкиваться если их бросают или если ими атакуют из рук. При каждом столкновении вычисляется коллизия.
Каждый предмет в игре делится на части, их потенциально может быть сколько угодно, но минимум одна.
Предположим моб атакует топором другого моба.
Вычисляется в какую часть моба попал топор. Это рука.
Вычисляется в какую часть этой руки попал топор. Это щит.
Вычисляется какой частью топор попал по щиту.
К счастью топор имеет только одну часть, это он сам. Как собственно и щит, хотя ничто не мешает ещё углубить эту иерархию.
И так, мы имеем две финальных части, это топор и щит. Щит, как и любая часть прикреплен к своей родительской части соединением.
Вычисляется достаточно ли урона топора + скорости топора, чтобы порвать соединение между рукой и щитом. (Прочность соединения зависит от прочности предмета и характеристик моба)
Если да то после коллизии щит улетает и сталкивается дальше. Если нет то остаётся.
Дальше считается дамаг. Дамаг топора по щиту и щита по топору. Часть дамага топора по щиту проходит через щит в руку которая его держит.
Потом взаимно накладываются эффекты-при-стоклновении, если они были.
Если удар был такой силы что раздербанило и саму руку, то отрывается и рука. Если бы это был не рука а тело или голова то наступает смэрть.
Ещё через всю эту цепочку проходит инфа о том кто ее запустил, так что если мобу снесло голову щитом который выбило из рук другого моба взрывной волной от бомбы, брошенной игроком то все об этом узнают.
Да, я понимаю, местами это переусложненная система. Ты можешь сказать что тут многое из этого нафиг не нужно, и будешь прав. Но мне так прикольно. Я экспериментирую, ищу новые механики. На данный момент эта система норм, хотя и не получила того развития которое я планировал. По факту сейчас частями тела обладают только мобы.
Вообще система уже прошла несколько циклов упрощения, изначально там ещё рикошеты были, масса и ещё всякое разное...
Плюс с оптимизацией я туда пока не зашел.
>>830021
Лучше уж проверять наличие цели в заданной точке каждый шаг, чем каждый шаг теребонькать а-стар, чтобы он выдал в ответ тот же путь, что и на прошлом шаге (ведь заданная цель не сдвинулась с места). Каким бы методом ты не вычислял новый путь, делать это каждый шаг дороже одного if "цель на том же месте, где и была" then "продолжить путь" else "посчитать новый путь". А твоя оптимизация "всегда идти ровно 3 шага и только потом посчитать новый путь" может оказаться менее верной, особенно если игрок часто телепортируется.
Кстати, что будет делать твой моб, если игрок скроется за углом пещеры? Продолжит преследовать? Или дойдёт до угла и потеряет интерес, если игрока в поле зрения не окажется (успел сбежать)? У мобов вообще есть поле зрения или они сканируют все клетки в радиусе?
Нет, я тут давно, просто до сих пор не играл в демку и забыл то, что читал несколько месяцев назад. Да, я вспомнил, у тебя там было что-то про броски предметов. Но так ли уж нужно включать в это дело физику, если предметы всё равно должны лечь на клетки? В крайнем случае коллизии здесь уровня Майнкрафта - if "клетка занята" then "произошло столкновение" else "продолжить движение". Тут нет необходимости в полноценных коллизиях.
По-моему, это не механики, а просто анимации. Имеет ли смысл, куда попал топор и куда полетел щит с рукой, если все персонажи стоят на клетках как фигурки в шахматах? Игрок не может встать левее или правее и, соответственно, не может повлиять на траекторию полёта разных частей тела врага. Всё равно как если бы все эти полёты были бы просто анимированны, а не точно симулировались физическим движком. То есть да, отлетевший в сторону топор может нанести урон тому, кто находится в какой-то клетке, но определить траекторию полёта и клетку, на которую упадёт топор, можно и без коллизий, это элементарные операции с векторами.
Реальной механикой было бы двигаться не по клеткам, а как в обычных топдаун шутерах, где можно двигаться как пожелаешь, физически сталкиваясь со стенами, врагами и другими объектами. Но тогда ты бы не смог сделать игру пошаговой и не удалось бы упростить ИИ до клеток мира, ведь игрок большую часть времени был бы не в центре клетки. Но это не новая механика, конечно, таких игр достаточно много.
>игрок взял и телепортировался
Лучше уж проверять наличие цели в заданной точке каждый шаг, чем каждый шаг теребонькать а-стар, чтобы он выдал в ответ тот же путь, что и на прошлом шаге (ведь заданная цель не сдвинулась с места). Каким бы методом ты не вычислял новый путь, делать это каждый шаг дороже одного if "цель на том же месте, где и была" then "продолжить путь" else "посчитать новый путь". А твоя оптимизация "всегда идти ровно 3 шага и только потом посчитать новый путь" может оказаться менее верной, особенно если игрок часто телепортируется.
Кстати, что будет делать твой моб, если игрок скроется за углом пещеры? Продолжит преследовать? Или дойдёт до угла и потеряет интерес, если игрока в поле зрения не окажется (успел сбежать)? У мобов вообще есть поле зрения или они сканируют все клетки в радиусе?
>Вижу, ты тут не так уж давно.
>Объекты могут двигаться и сталкиваться
Нет, я тут давно, просто до сих пор не играл в демку и забыл то, что читал несколько месяцев назад. Да, я вспомнил, у тебя там было что-то про броски предметов. Но так ли уж нужно включать в это дело физику, если предметы всё равно должны лечь на клетки? В крайнем случае коллизии здесь уровня Майнкрафта - if "клетка занята" then "произошло столкновение" else "продолжить движение". Тут нет необходимости в полноценных коллизиях.
>Я экспериментирую, ищу новые механики
По-моему, это не механики, а просто анимации. Имеет ли смысл, куда попал топор и куда полетел щит с рукой, если все персонажи стоят на клетках как фигурки в шахматах? Игрок не может встать левее или правее и, соответственно, не может повлиять на траекторию полёта разных частей тела врага. Всё равно как если бы все эти полёты были бы просто анимированны, а не точно симулировались физическим движком. То есть да, отлетевший в сторону топор может нанести урон тому, кто находится в какой-то клетке, но определить траекторию полёта и клетку, на которую упадёт топор, можно и без коллизий, это элементарные операции с векторами.
Реальной механикой было бы двигаться не по клеткам, а как в обычных топдаун шутерах, где можно двигаться как пожелаешь, физически сталкиваясь со стенами, врагами и другими объектами. Но тогда ты бы не смог сделать игру пошаговой и не удалось бы упростить ИИ до клеток мира, ведь игрок большую часть времени был бы не в центре клетки. Но это не новая механика, конечно, таких игр достаточно много.
>>830021
Лучше уж проверять наличие цели в заданной точке каждый шаг, чем каждый шаг теребонькать а-стар, чтобы он выдал в ответ тот же путь, что и на прошлом шаге (ведь заданная цель не сдвинулась с места). Каким бы методом ты не вычислял новый путь, делать это каждый шаг дороже одного if "цель на том же месте, где и была" then "продолжить путь" else "посчитать новый путь". А твоя оптимизация "всегда идти ровно 3 шага и только потом посчитать новый путь" может оказаться менее верной, особенно если игрок часто телепортируется.
Кстати, что будет делать твой моб, если игрок скроется за углом пещеры? Продолжит преследовать? Или дойдёт до угла и потеряет интерес, если игрока в поле зрения не окажется (успел сбежать)? У мобов вообще есть поле зрения или они сканируют все клетки в радиусе?
Нет, я тут давно, просто до сих пор не играл в демку и забыл то, что читал несколько месяцев назад. Да, я вспомнил, у тебя там было что-то про броски предметов. Но так ли уж нужно включать в это дело физику, если предметы всё равно должны лечь на клетки? В крайнем случае коллизии здесь уровня Майнкрафта - if "клетка занята" then "произошло столкновение" else "продолжить движение". Тут нет необходимости в полноценных коллизиях.
По-моему, это не механики, а просто анимации. Имеет ли смысл, куда попал топор и куда полетел щит с рукой, если все персонажи стоят на клетках как фигурки в шахматах? Игрок не может встать левее или правее и, соответственно, не может повлиять на траекторию полёта разных частей тела врага. Всё равно как если бы все эти полёты были бы просто анимированны, а не точно симулировались физическим движком. То есть да, отлетевший в сторону топор может нанести урон тому, кто находится в какой-то клетке, но определить траекторию полёта и клетку, на которую упадёт топор, можно и без коллизий, это элементарные операции с векторами.
Реальной механикой было бы двигаться не по клеткам, а как в обычных топдаун шутерах, где можно двигаться как пожелаешь, физически сталкиваясь со стенами, врагами и другими объектами. Но тогда ты бы не смог сделать игру пошаговой и не удалось бы упростить ИИ до клеток мира, ведь игрок большую часть времени был бы не в центре клетки. Но это не новая механика, конечно, таких игр достаточно много.
>игрок взял и телепортировался
Лучше уж проверять наличие цели в заданной точке каждый шаг, чем каждый шаг теребонькать а-стар, чтобы он выдал в ответ тот же путь, что и на прошлом шаге (ведь заданная цель не сдвинулась с места). Каким бы методом ты не вычислял новый путь, делать это каждый шаг дороже одного if "цель на том же месте, где и была" then "продолжить путь" else "посчитать новый путь". А твоя оптимизация "всегда идти ровно 3 шага и только потом посчитать новый путь" может оказаться менее верной, особенно если игрок часто телепортируется.
Кстати, что будет делать твой моб, если игрок скроется за углом пещеры? Продолжит преследовать? Или дойдёт до угла и потеряет интерес, если игрока в поле зрения не окажется (успел сбежать)? У мобов вообще есть поле зрения или они сканируют все клетки в радиусе?
>Вижу, ты тут не так уж давно.
>Объекты могут двигаться и сталкиваться
Нет, я тут давно, просто до сих пор не играл в демку и забыл то, что читал несколько месяцев назад. Да, я вспомнил, у тебя там было что-то про броски предметов. Но так ли уж нужно включать в это дело физику, если предметы всё равно должны лечь на клетки? В крайнем случае коллизии здесь уровня Майнкрафта - if "клетка занята" then "произошло столкновение" else "продолжить движение". Тут нет необходимости в полноценных коллизиях.
>Я экспериментирую, ищу новые механики
По-моему, это не механики, а просто анимации. Имеет ли смысл, куда попал топор и куда полетел щит с рукой, если все персонажи стоят на клетках как фигурки в шахматах? Игрок не может встать левее или правее и, соответственно, не может повлиять на траекторию полёта разных частей тела врага. Всё равно как если бы все эти полёты были бы просто анимированны, а не точно симулировались физическим движком. То есть да, отлетевший в сторону топор может нанести урон тому, кто находится в какой-то клетке, но определить траекторию полёта и клетку, на которую упадёт топор, можно и без коллизий, это элементарные операции с векторами.
Реальной механикой было бы двигаться не по клеткам, а как в обычных топдаун шутерах, где можно двигаться как пожелаешь, физически сталкиваясь со стенами, врагами и другими объектами. Но тогда ты бы не смог сделать игру пошаговой и не удалось бы упростить ИИ до клеток мира, ведь игрок большую часть времени был бы не в центре клетки. Но это не новая механика, конечно, таких игр достаточно много.
>>830047
Стоит ещё учитывать что цель вообще двигается довольно часто.
Вот тут я пока не придумал. Сейчас он просто сканирует зону вокруг себя, но есть и способ быстро проверять есть ли прямая видимость цели.
Надо это как-то совместить. Типо когда моб перестает видеть цель он знает о ее местоположении ещё несколько ходов а потом теряет.
Я описал что там конкретно происходит, физика это или нет, можешь для себя сам решить.
На счёт того механика это или нет тоже вопрос определения. Это точно не анимация так как улетевшая часть тела воздействует на окружающий мир.
Вот локализованный урон это точно механика потому что ты можешь хилить отдельные части тела. То что они отваливаются это скорее ее следствие.
В демку можешь пока не играть, дождись лучше следующего билда.
>Проверять стоит ли цель на том же месте. Да, ты прав. но мне все равно лень это сейчас кодить
Стоит ещё учитывать что цель вообще двигается довольно часто.
>Что будет когда моб дойдет до угла?
Вот тут я пока не придумал. Сейчас он просто сканирует зону вокруг себя, но есть и способ быстро проверять есть ли прямая видимость цели.
Надо это как-то совместить. Типо когда моб перестает видеть цель он знает о ее местоположении ещё несколько ходов а потом теряет.
>Физика
Я описал что там конкретно происходит, физика это или нет, можешь для себя сам решить.
На счёт того механика это или нет тоже вопрос определения. Это точно не анимация так как улетевшая часть тела воздействует на окружающий мир.
Вот локализованный урон это точно механика потому что ты можешь хилить отдельные части тела. То что они отваливаются это скорее ее следствие.
В демку можешь пока не играть, дождись лучше следующего билда.
>>829996
У них есть предводители, но от них не особо много зависит. Пока только перемещение отряда Ане боя. Я бы расширил их возможности, мб сделал бы каких-нибудь знаменосцев, которые не дают морали упасть.
Меняться местами мобы могут, пробка получается из за того что они просто в край карты упираются
У них есть предводители, но от них не особо много зависит. Пока только перемещение отряда Ане боя. Я бы расширил их возможности, мб сделал бы каких-нибудь знаменосцев, которые не дают морали упасть.
Меняться местами мобы могут, пробка получается из за того что они просто в край карты упираются
Так, я съездил, поизучал процедурную генерацию грибов в ирл лесу и решил что нужно переделывать анатомию. На самом деле она совсем-совсем не норм.
Сейчас анатомия это компонент со статами + коллекция с неограниченным числом частей тела.
А должно быть так:
Компонент, в котором по мимо статов фиксированные части тела: конкретно голова, рука1, рука2, рука3 и так далее.
И висеть он будет только на существах.
Никакие топоры у которых отдельной частью обух и отдельно рукоятка мне не нужны.
Как и стены у которых 10 отдельных частей-кирпичей, которые из нее можно выбить.
Существа с н-ным плавающим числом голов мне тоже не нужны.
Ну ладно, я оставлю слот под вторую голову на случай пикрелейтед1, но не более.
Как и существа, которые держат в руках других существ, которые держат в руках других существ. как на пикрелейтед 2, таких конструкций тоже не будет.
С геймплейной точки зрения это полная бессмыслица и плодит баги. Надо переставать фигней страдат
ь.
Сейчас анатомия это компонент со статами + коллекция с неограниченным числом частей тела.
А должно быть так:
Компонент, в котором по мимо статов фиксированные части тела: конкретно голова, рука1, рука2, рука3 и так далее.
И висеть он будет только на существах.
Никакие топоры у которых отдельной частью обух и отдельно рукоятка мне не нужны.
Как и стены у которых 10 отдельных частей-кирпичей, которые из нее можно выбить.
Существа с н-ным плавающим числом голов мне тоже не нужны.
Ну ладно, я оставлю слот под вторую голову на случай пикрелейтед1, но не более.
Как и существа, которые держат в руках других существ, которые держат в руках других существ. как на пикрелейтед 2, таких конструкций тоже не будет.
С геймплейной точки зрения это полная бессмыслица и плодит баги. Надо переставать фигней страдат
ь.
36 Мб, 1230x859И так, кажется процесс переработки и оптимизации подходит к концу.
Все системы были переписаны с учетом entities 0.51.
Все методы, находившиеся в компонентах, что абсолютно неправильно с точки зрения ecs были перенесены оттуда в системы. В компонентах должны лежать только данные.
Все что можно распараллелить было распараллелено.
В каждую систему добавлен дебаг лог, который можно по желанию включать и выключать.
Упрощена анатомия. Теперь она есть только у существ. каждое существо имеет фиксированное количество частей тела.
Была изменена структура обновления тика. Все системы были поделены на следующие три группы.
- Синхронные системы
Все системы, которые как-то зависят от внутриигрового времени. Это ИИ, который считается раз в н тиков, эффекты которые считаются каждый тик и так далее.
Они обновляются каждый тик в его начале.
- Цикличные системы
Это системы по большей части связанные с физикой, отсоединением частей тела, экипировкой предметов, изменение инвентаря, перемещением.
После обновления синхронных систем начинается цикл в котором эти системы обновляются по кругу, пока для них есть работа.
Для чего это нужно?
Некоторые системы создают цепные реакции. Вот, например, просчитывается физика, в моба прилетает стрела. Она отрывает ему конечность и уже она улетает в сторону, требуя в свою очередь еще один просчет физики, движения и анатомии.
Если это последний тик и дальше идет ход игрока, то это приводит к очень странным последствиям, когда конечность уже формально оторвана, а физика считает что она еще на месте и тому подобное.
Теперь вся цепная реакция просчитывается в течении одного тика.
Если ты бросаешь предмет, он пролетает не 10 клеток по 1 клетке за тик, как раньше, а в первый же тик все расстояние пока не врежется куда-нибудь.
Это лишило игрока возможности уклоняться от стрел, аки Нео, но мне эту механику не жалко, она хоть и добавляла рогалику индивидуальности, но была кривая и несвязанная с остальными.
Наверно, тем кто не успел поиграть в последний билд не особо понятно о чем я вообще говорю...
После того как прошло несколько таких циклов и работы для цикличных систем больше нет, начинается новый тик, а когда проходят все тики, происходит обновление систем конца хода. В эту группу входят тяжелые системы связанные в основном с игроком, например просчет того какие клетки игрок видит а какие нет.
Периодически еще возникают баги по типу того, что одна сущность сталкивается с уже уничтоженной сущностью, но я стараюсь все это отслеживать и фиксить.
Сейчас нагрузка в бою с 400+ мобов получается очень рандомной, скачет в пределах от 60 до 150 мс в пике.
Ну хоть уже не 220 и на том спасибо.
Все системы были переписаны с учетом entities 0.51.
Все методы, находившиеся в компонентах, что абсолютно неправильно с точки зрения ecs были перенесены оттуда в системы. В компонентах должны лежать только данные.
Все что можно распараллелить было распараллелено.
В каждую систему добавлен дебаг лог, который можно по желанию включать и выключать.
Упрощена анатомия. Теперь она есть только у существ. каждое существо имеет фиксированное количество частей тела.
Была изменена структура обновления тика. Все системы были поделены на следующие три группы.
- Синхронные системы
Все системы, которые как-то зависят от внутриигрового времени. Это ИИ, который считается раз в н тиков, эффекты которые считаются каждый тик и так далее.
Они обновляются каждый тик в его начале.
- Цикличные системы
Это системы по большей части связанные с физикой, отсоединением частей тела, экипировкой предметов, изменение инвентаря, перемещением.
После обновления синхронных систем начинается цикл в котором эти системы обновляются по кругу, пока для них есть работа.
Для чего это нужно?
Некоторые системы создают цепные реакции. Вот, например, просчитывается физика, в моба прилетает стрела. Она отрывает ему конечность и уже она улетает в сторону, требуя в свою очередь еще один просчет физики, движения и анатомии.
Если это последний тик и дальше идет ход игрока, то это приводит к очень странным последствиям, когда конечность уже формально оторвана, а физика считает что она еще на месте и тому подобное.
Теперь вся цепная реакция просчитывается в течении одного тика.
Если ты бросаешь предмет, он пролетает не 10 клеток по 1 клетке за тик, как раньше, а в первый же тик все расстояние пока не врежется куда-нибудь.
Это лишило игрока возможности уклоняться от стрел, аки Нео, но мне эту механику не жалко, она хоть и добавляла рогалику индивидуальности, но была кривая и несвязанная с остальными.
Наверно, тем кто не успел поиграть в последний билд не особо понятно о чем я вообще говорю...
После того как прошло несколько таких циклов и работы для цикличных систем больше нет, начинается новый тик, а когда проходят все тики, происходит обновление систем конца хода. В эту группу входят тяжелые системы связанные в основном с игроком, например просчет того какие клетки игрок видит а какие нет.
Периодически еще возникают баги по типу того, что одна сущность сталкивается с уже уничтоженной сущностью, но я стараюсь все это отслеживать и фиксить.
Сейчас нагрузка в бою с 400+ мобов получается очень рандомной, скачет в пределах от 60 до 150 мс в пике.
Ну хоть уже не 220 и на том спасибо.
36 Мб, 1230x859И так, кажется процесс переработки и оптимизации подходит к концу.
Все системы были переписаны с учетом entities 0.51.
Все методы, находившиеся в компонентах, что абсолютно неправильно с точки зрения ecs были перенесены оттуда в системы. В компонентах должны лежать только данные.
Все что можно распараллелить было распараллелено.
В каждую систему добавлен дебаг лог, который можно по желанию включать и выключать.
Упрощена анатомия. Теперь она есть только у существ. каждое существо имеет фиксированное количество частей тела.
Была изменена структура обновления тика. Все системы были поделены на следующие три группы.
- Синхронные системы
Все системы, которые как-то зависят от внутриигрового времени. Это ИИ, который считается раз в н тиков, эффекты которые считаются каждый тик и так далее.
Они обновляются каждый тик в его начале.
- Цикличные системы
Это системы по большей части связанные с физикой, отсоединением частей тела, экипировкой предметов, изменение инвентаря, перемещением.
После обновления синхронных систем начинается цикл в котором эти системы обновляются по кругу, пока для них есть работа.
Для чего это нужно?
Некоторые системы создают цепные реакции. Вот, например, просчитывается физика, в моба прилетает стрела. Она отрывает ему конечность и уже она улетает в сторону, требуя в свою очередь еще один просчет физики, движения и анатомии.
Если это последний тик и дальше идет ход игрока, то это приводит к очень странным последствиям, когда конечность уже формально оторвана, а физика считает что она еще на месте и тому подобное.
Теперь вся цепная реакция просчитывается в течении одного тика.
Если ты бросаешь предмет, он пролетает не 10 клеток по 1 клетке за тик, как раньше, а в первый же тик все расстояние пока не врежется куда-нибудь.
Это лишило игрока возможности уклоняться от стрел, аки Нео, но мне эту механику не жалко, она хоть и добавляла рогалику индивидуальности, но была кривая и несвязанная с остальными.
Наверно, тем кто не успел поиграть в последний билд не особо понятно о чем я вообще говорю...
После того как прошло несколько таких циклов и работы для цикличных систем больше нет, начинается новый тик, а когда проходят все тики, происходит обновление систем конца хода. В эту группу входят тяжелые системы связанные в основном с игроком, например просчет того какие клетки игрок видит а какие нет.
Периодически еще возникают баги по типу того, что одна сущность сталкивается с уже уничтоженной сущностью, но я стараюсь все это отслеживать и фиксить.
Сейчас нагрузка в бою с 400+ мобов получается очень рандомной, скачет в пределах от 60 до 150 мс в пике.
Ну хоть уже не 220 и на том спасибо.
Все системы были переписаны с учетом entities 0.51.
Все методы, находившиеся в компонентах, что абсолютно неправильно с точки зрения ecs были перенесены оттуда в системы. В компонентах должны лежать только данные.
Все что можно распараллелить было распараллелено.
В каждую систему добавлен дебаг лог, который можно по желанию включать и выключать.
Упрощена анатомия. Теперь она есть только у существ. каждое существо имеет фиксированное количество частей тела.
Была изменена структура обновления тика. Все системы были поделены на следующие три группы.
- Синхронные системы
Все системы, которые как-то зависят от внутриигрового времени. Это ИИ, который считается раз в н тиков, эффекты которые считаются каждый тик и так далее.
Они обновляются каждый тик в его начале.
- Цикличные системы
Это системы по большей части связанные с физикой, отсоединением частей тела, экипировкой предметов, изменение инвентаря, перемещением.
После обновления синхронных систем начинается цикл в котором эти системы обновляются по кругу, пока для них есть работа.
Для чего это нужно?
Некоторые системы создают цепные реакции. Вот, например, просчитывается физика, в моба прилетает стрела. Она отрывает ему конечность и уже она улетает в сторону, требуя в свою очередь еще один просчет физики, движения и анатомии.
Если это последний тик и дальше идет ход игрока, то это приводит к очень странным последствиям, когда конечность уже формально оторвана, а физика считает что она еще на месте и тому подобное.
Теперь вся цепная реакция просчитывается в течении одного тика.
Если ты бросаешь предмет, он пролетает не 10 клеток по 1 клетке за тик, как раньше, а в первый же тик все расстояние пока не врежется куда-нибудь.
Это лишило игрока возможности уклоняться от стрел, аки Нео, но мне эту механику не жалко, она хоть и добавляла рогалику индивидуальности, но была кривая и несвязанная с остальными.
Наверно, тем кто не успел поиграть в последний билд не особо понятно о чем я вообще говорю...
После того как прошло несколько таких циклов и работы для цикличных систем больше нет, начинается новый тик, а когда проходят все тики, происходит обновление систем конца хода. В эту группу входят тяжелые системы связанные в основном с игроком, например просчет того какие клетки игрок видит а какие нет.
Периодически еще возникают баги по типу того, что одна сущность сталкивается с уже уничтоженной сущностью, но я стараюсь все это отслеживать и фиксить.
Сейчас нагрузка в бою с 400+ мобов получается очень рандомной, скачет в пределах от 60 до 150 мс в пике.
Ну хоть уже не 220 и на том спасибо.
17 Кб, 150x295Я столкнулся с неожиданной проблемой.
Так как теперь брошенные предметы перемещаются мгновенно в течении одного тика единственный способ визуализировать их полет это вот этот белый шлейф который за ними остается. Если его убрать, игрок будет видеть только как предмет исчез из руки бросающего и появился в конечной точке.
Так вот, шлейф реализован через Trail Renderer а он, ведет себя очень странно. Судя по всему, для того чтобы строить этот меш ему нужно чтобы в каждой точке маршрута камера рендерила кадр. Иначе он не регистрирует перемещение вообще.
Рендерить камеру каждый раз когда что-то перемещается на одну клетку это очень дорого, почти столько же сколько стоят все остальные скрипты.
Нужно искать какие-то обходные пути. Может использовать свой собственный меш, который будет делать то-же самое, но нормально? Или спавнить на каждой клетке которую преодолел предмет частицы?
Не думал что это будет такой большой проблемой.
Так как теперь брошенные предметы перемещаются мгновенно в течении одного тика единственный способ визуализировать их полет это вот этот белый шлейф который за ними остается. Если его убрать, игрок будет видеть только как предмет исчез из руки бросающего и появился в конечной точке.
Так вот, шлейф реализован через Trail Renderer а он, ведет себя очень странно. Судя по всему, для того чтобы строить этот меш ему нужно чтобы в каждой точке маршрута камера рендерила кадр. Иначе он не регистрирует перемещение вообще.
Рендерить камеру каждый раз когда что-то перемещается на одну клетку это очень дорого, почти столько же сколько стоят все остальные скрипты.
Нужно искать какие-то обходные пути. Может использовать свой собственный меш, который будет делать то-же самое, но нормально? Или спавнить на каждой клетке которую преодолел предмет частицы?
Не думал что это будет такой большой проблемой.
>>798351
>>829785
>>829991
Я наконец сделал механизм спекания всех редко изменяющихся спрайтов в одну большую текстуру. Оказалось что это просто элементарно, я потратил всего пол часа.
Пока спекаются только полы.
До этого каждая клетка пола имела свой спрайт 32х32. Теперь весь пол 64х64 клетки это одна текстура 2048х2048.
Когда вся карта была в зоне видимости камеры рендер занимал 30 мс.
Теперь 2.8 .
Анону, который посоветовал так сделать - низкий поклон.
Еще до этого при спавне каждого предмета, из пула брался специальный геймобджект с рендерером, которых там лежало 10к. Теперь, получается их требуется на 4096 штук меньше.
Сейчас думаю, можно ли поступить так же еще и со стенами. Боюсь что пока нет.
Пол в моей игре это просто спрайт 32х32. А вот стены это другое. Начнем с того что она 32х48 и если ты стоишь перед стеной то твоя голова перекрывает ее нижнюю часть. А если за стеной то уже она тебя перекрывает.
С одной текстурой так не сделать...
>>829785
>>829991
Я наконец сделал механизм спекания всех редко изменяющихся спрайтов в одну большую текстуру. Оказалось что это просто элементарно, я потратил всего пол часа.
Пока спекаются только полы.
До этого каждая клетка пола имела свой спрайт 32х32. Теперь весь пол 64х64 клетки это одна текстура 2048х2048.
Когда вся карта была в зоне видимости камеры рендер занимал 30 мс.
Теперь 2.8 .
Анону, который посоветовал так сделать - низкий поклон.
Еще до этого при спавне каждого предмета, из пула брался специальный геймобджект с рендерером, которых там лежало 10к. Теперь, получается их требуется на 4096 штук меньше.
Сейчас думаю, можно ли поступить так же еще и со стенами. Боюсь что пока нет.
Пол в моей игре это просто спрайт 32х32. А вот стены это другое. Начнем с того что она 32х48 и если ты стоишь перед стеной то твоя голова перекрывает ее нижнюю часть. А если за стеной то уже она тебя перекрывает.
С одной текстурой так не сделать...
>>831160
У тебя 2D игра или 3D?
1. Рисуешь в пейнте шлейф.
2. Отображаешь спрайт шлейфа в игре.
3. ???
4. ПРОФИТ.
Зачем клетки, зачем частицы?
Спавни спрайты по вектору движения.
Затем скрывай их до следующего раза.
>меш
У тебя 2D игра или 3D?
1. Рисуешь в пейнте шлейф.
2. Отображаешь спрайт шлейфа в игре.
3. ???
4. ПРОФИТ.
>спавнить на каждой клетке которую преодолел предмет частицы
Зачем клетки, зачем частицы?
Спавни спрайты по вектору движения.
Затем скрывай их до следующего раза.
>>831179
Так и знал, что поможет. Везде работает. Впервые узнал об этом приёме, когда bitblt()-ом рисовал.
Ммм... Если я правильно понял, ты хранишь все игровые объекты в одном массиве, с которым работает и чанковая система, и спавнер предметов, и всё остальное? Разве не было бы лучше разделить их на несколько массивов в соответствии с целью их использования (тайлы; предметы; персонажи; летящие предметы - пули, стрелы и т.п.), чтобы не приходилось далеко бегать по массиву? Заодно можно было бы разложить по разным скриптам: тайлами управляет тайловая карта, персонажами - менеджер персонажей, предметами - менеджер лута, летящими снарядами - менеджер летящих снарядов и т.д. Я бы сделал так хотя бы чтобы самому не запутаться, где что.
Если я правильно понял, то перекрывает персонажа не вся стена целиком, а кусочек 32x16 пикселей сверху спрайта стены. Под нижними 32x32 пикселями персонаж встать никак не может. Ну вот и нарисуй их прямо поверх пола, или даже вместо пола, если стена целиком перекрывает клетку пола. Кусочки 32x16 можешь либо отдельно рисовать, либо тоже запечь в текстуру, но уже отдельную, которая будет отображаться после всех персонажей. Только учитывай, что эта текстура должна иметь прозрачность, что может повлечь за собой снижение производительности. Замеряй сам, что будет выгоднее.
Разрушаемые стены тоже легко сделать. Принцип тот же, что в майнкрафте. При частичном разрушении рисуешь анимацию разрушения поверх блока, а при полном разрушении один раз отрисовываешь текстуру пола заново, заменяя в ней тайл стены на тайл пола. Или, если такое технически возможно в юнити, можно нарисовать всего один тайл - тайл пола - поверх уже готовой текстуры, в то место, где нарисован тайл стены. В майнкрафте чанки не состоят из независимых кубов и собираются заново при каждом добавлении/удалении куба, а 2D игре можно тупо поверх готовой текстуры новый блок нарисовать (или закрасить прозрачными пикселями удаляемый блок).
>рендер занимал 30 мс.
>Теперь 2.8 мс.
Так и знал, что поможет. Везде работает. Впервые узнал об этом приёме, когда bitblt()-ом рисовал.
>Еще до этого при спавне каждого предмета, из пула брался специальный геймобджект с рендерером, которых там лежало 10к. Теперь, получается их требуется на 4096 штук меньше.
Ммм... Если я правильно понял, ты хранишь все игровые объекты в одном массиве, с которым работает и чанковая система, и спавнер предметов, и всё остальное? Разве не было бы лучше разделить их на несколько массивов в соответствии с целью их использования (тайлы; предметы; персонажи; летящие предметы - пули, стрелы и т.п.), чтобы не приходилось далеко бегать по массиву? Заодно можно было бы разложить по разным скриптам: тайлами управляет тайловая карта, персонажами - менеджер персонажей, предметами - менеджер лута, летящими снарядами - менеджер летящих снарядов и т.д. Я бы сделал так хотя бы чтобы самому не запутаться, где что.
>Пол в моей игре это просто спрайт 32х32. А вот стены это другое. Начнем с того что она 32х48 и если ты стоишь перед стеной то твоя голова перекрывает ее нижнюю часть. А если за стеной то уже она тебя перекрывает.
Если я правильно понял, то перекрывает персонажа не вся стена целиком, а кусочек 32x16 пикселей сверху спрайта стены. Под нижними 32x32 пикселями персонаж встать никак не может. Ну вот и нарисуй их прямо поверх пола, или даже вместо пола, если стена целиком перекрывает клетку пола. Кусочки 32x16 можешь либо отдельно рисовать, либо тоже запечь в текстуру, но уже отдельную, которая будет отображаться после всех персонажей. Только учитывай, что эта текстура должна иметь прозрачность, что может повлечь за собой снижение производительности. Замеряй сам, что будет выгоднее.
Разрушаемые стены тоже легко сделать. Принцип тот же, что в майнкрафте. При частичном разрушении рисуешь анимацию разрушения поверх блока, а при полном разрушении один раз отрисовываешь текстуру пола заново, заменяя в ней тайл стены на тайл пола. Или, если такое технически возможно в юнити, можно нарисовать всего один тайл - тайл пола - поверх уже готовой текстуры, в то место, где нарисован тайл стены. В майнкрафте чанки не состоят из независимых кубов и собираются заново при каждом добавлении/удалении куба, а 2D игре можно тупо поверх готовой текстуры новый блок нарисовать (или закрасить прозрачными пикселями удаляемый блок).
>>831179
Так и знал, что поможет. Везде работает. Впервые узнал об этом приёме, когда bitblt()-ом рисовал.
Ммм... Если я правильно понял, ты хранишь все игровые объекты в одном массиве, с которым работает и чанковая система, и спавнер предметов, и всё остальное? Разве не было бы лучше разделить их на несколько массивов в соответствии с целью их использования (тайлы; предметы; персонажи; летящие предметы - пули, стрелы и т.п.), чтобы не приходилось далеко бегать по массиву? Заодно можно было бы разложить по разным скриптам: тайлами управляет тайловая карта, персонажами - менеджер персонажей, предметами - менеджер лута, летящими снарядами - менеджер летящих снарядов и т.д. Я бы сделал так хотя бы чтобы самому не запутаться, где что.
Если я правильно понял, то перекрывает персонажа не вся стена целиком, а кусочек 32x16 пикселей сверху спрайта стены. Под нижними 32x32 пикселями персонаж встать никак не может. Ну вот и нарисуй их прямо поверх пола, или даже вместо пола, если стена целиком перекрывает клетку пола. Кусочки 32x16 можешь либо отдельно рисовать, либо тоже запечь в текстуру, но уже отдельную, которая будет отображаться после всех персонажей. Только учитывай, что эта текстура должна иметь прозрачность, что может повлечь за собой снижение производительности. Замеряй сам, что будет выгоднее.
Разрушаемые стены тоже легко сделать. Принцип тот же, что в майнкрафте. При частичном разрушении рисуешь анимацию разрушения поверх блока, а при полном разрушении один раз отрисовываешь текстуру пола заново, заменяя в ней тайл стены на тайл пола. Или, если такое технически возможно в юнити, можно нарисовать всего один тайл - тайл пола - поверх уже готовой текстуры, в то место, где нарисован тайл стены. В майнкрафте чанки не состоят из независимых кубов и собираются заново при каждом добавлении/удалении куба, а 2D игре можно тупо поверх готовой текстуры новый блок нарисовать (или закрасить прозрачными пикселями удаляемый блок).
>рендер занимал 30 мс.
>Теперь 2.8 мс.
Так и знал, что поможет. Везде работает. Впервые узнал об этом приёме, когда bitblt()-ом рисовал.
>Еще до этого при спавне каждого предмета, из пула брался специальный геймобджект с рендерером, которых там лежало 10к. Теперь, получается их требуется на 4096 штук меньше.
Ммм... Если я правильно понял, ты хранишь все игровые объекты в одном массиве, с которым работает и чанковая система, и спавнер предметов, и всё остальное? Разве не было бы лучше разделить их на несколько массивов в соответствии с целью их использования (тайлы; предметы; персонажи; летящие предметы - пули, стрелы и т.п.), чтобы не приходилось далеко бегать по массиву? Заодно можно было бы разложить по разным скриптам: тайлами управляет тайловая карта, персонажами - менеджер персонажей, предметами - менеджер лута, летящими снарядами - менеджер летящих снарядов и т.д. Я бы сделал так хотя бы чтобы самому не запутаться, где что.
>Пол в моей игре это просто спрайт 32х32. А вот стены это другое. Начнем с того что она 32х48 и если ты стоишь перед стеной то твоя голова перекрывает ее нижнюю часть. А если за стеной то уже она тебя перекрывает.
Если я правильно понял, то перекрывает персонажа не вся стена целиком, а кусочек 32x16 пикселей сверху спрайта стены. Под нижними 32x32 пикселями персонаж встать никак не может. Ну вот и нарисуй их прямо поверх пола, или даже вместо пола, если стена целиком перекрывает клетку пола. Кусочки 32x16 можешь либо отдельно рисовать, либо тоже запечь в текстуру, но уже отдельную, которая будет отображаться после всех персонажей. Только учитывай, что эта текстура должна иметь прозрачность, что может повлечь за собой снижение производительности. Замеряй сам, что будет выгоднее.
Разрушаемые стены тоже легко сделать. Принцип тот же, что в майнкрафте. При частичном разрушении рисуешь анимацию разрушения поверх блока, а при полном разрушении один раз отрисовываешь текстуру пола заново, заменяя в ней тайл стены на тайл пола. Или, если такое технически возможно в юнити, можно нарисовать всего один тайл - тайл пола - поверх уже готовой текстуры, в то место, где нарисован тайл стены. В майнкрафте чанки не состоят из независимых кубов и собираются заново при каждом добавлении/удалении куба, а 2D игре можно тупо поверх готовой текстуры новый блок нарисовать (или закрасить прозрачными пикселями удаляемый блок).
86 Кб, 340x340>>832837
Ну чел...
Ты видел как выглядит этот юнитёвский шлейф?
У него процедурно меняется толщина, прозрачность и так далее.
Там именно что меш строится.
Просто рисовать спрайты по ходу движения, я и так понимаю, что можно. Я же хочу чтобы красиво было.
Пока остановился на варианте с частицами, типо предмет летит и за собой пыль поднимает. Потом наверно сделаю этот механизм более внятным, но
пока есть другие дела.
Ну чел...
Ты видел как выглядит этот юнитёвский шлейф?
У него процедурно меняется толщина, прозрачность и так далее.
Там именно что меш строится.
Просто рисовать спрайты по ходу движения, я и так понимаю, что можно. Я же хочу чтобы красиво было.
Пока остановился на варианте с частицами, типо предмет летит и за собой пыль поднимает. Потом наверно сделаю этот механизм более внятным, но
пока есть другие дела.
>>832784
На сколько я знаю, юнити может делать билды под линукс.
Но я, если честно, ни разу с ним не сталкивался и не представляю какие там могут быть подводные камни.
Может быть, когда дойду до какой-нибудь стабильной версии и линуксовый тоже запилю.
На сколько я знаю, юнити может делать билды под линукс.
Но я, если честно, ни разу с ним не сталкивался и не представляю какие там могут быть подводные камни.
Может быть, когда дойду до какой-нибудь стабильной версии и линуксовый тоже запилю.
>>832842
Не совсем так. У меня же ECS, так что все рантайм-данные висят на сущностях, массивы используются только в базе данных со статами. А пул это просто хранилище из кучи одинаковых примитивных объектов, использующихся для рендеринга, которые берутся оттуда по мере надобности, а потом туда-же возвращаются.
А чанков у меня нет.
Каждый этаж подземелья это целиковый квадрат 64х64. Один чанк, если угодно. Делить его на меньшие области я пока не вижу смысла, узкое место производительности сейчас явно не в этом. Хотя в теории возможность за счет чанков делать этажи произвольного размера звучит очень заманчиво
По поводу стен и полов. Да, персонажа перекрывают только верхние 16 пикселей. Мне бы не хотелось отдельно дорисовывать эти куски, уж очень это много вносит дополнительной работы.
Получается теперь что стена это уникальный предмет с двумя рендерерами. А у всех остальных по одному.
А еще нужна специальная коллекция этих 16 пиксельных кусков.
А есть еще прозрачные стены и всякое такое...
Короче да, это все можно сделать, но сложно. Пока я наверно не буду.
Не совсем так. У меня же ECS, так что все рантайм-данные висят на сущностях, массивы используются только в базе данных со статами. А пул это просто хранилище из кучи одинаковых примитивных объектов, использующихся для рендеринга, которые берутся оттуда по мере надобности, а потом туда-же возвращаются.
А чанков у меня нет.
Каждый этаж подземелья это целиковый квадрат 64х64. Один чанк, если угодно. Делить его на меньшие области я пока не вижу смысла, узкое место производительности сейчас явно не в этом. Хотя в теории возможность за счет чанков делать этажи произвольного размера звучит очень заманчиво
По поводу стен и полов. Да, персонажа перекрывают только верхние 16 пикселей. Мне бы не хотелось отдельно дорисовывать эти куски, уж очень это много вносит дополнительной работы.
Получается теперь что стена это уникальный предмет с двумя рендерерами. А у всех остальных по одному.
А еще нужна специальная коллекция этих 16 пиксельных кусков.
А есть еще прозрачные стены и всякое такое...
Короче да, это все можно сделать, но сложно. Пока я наверно не буду.
19,5 Мб, 1137x786>>832842
>>832908
Кстати, раз уж мы заговорили от этом, пришло время открыть величайший секрет катабасиса)
Смотри гифрелейтед.
Такой ход был предпринят именно из за этой темы со стенами, перекрывающими лежащую за ними клетку.
Этого эффекта нельзя было бы достигнуть используя обычный sorting order спрайтов, сдвигать объект по Z координате если его нужно рендерить поверх другого оказалось вполне разумным решением.
Так что в качестве метода спекания стен в текстуру я скорее рассматриваю создание стопки из 64 горизонтальных полосок разрешения 2048*32 расположенных как на гифке. Это не так сложно сделать, а эффект все равно будет значительный.
>>832908
Кстати, раз уж мы заговорили от этом, пришло время открыть величайший секрет катабасиса)
Смотри гифрелейтед.
Такой ход был предпринят именно из за этой темы со стенами, перекрывающими лежащую за ними клетку.
Этого эффекта нельзя было бы достигнуть используя обычный sorting order спрайтов, сдвигать объект по Z координате если его нужно рендерить поверх другого оказалось вполне разумным решением.
Так что в качестве метода спекания стен в текстуру я скорее рассматриваю создание стопки из 64 горизонтальных полосок разрешения 2048*32 расположенных как на гифке. Это не так сложно сделать, а эффект все равно будет значительный.
642 Кб, 802x650Вообще по поводу разработки я могу сказать что пока ничего интересного не происходит, последние две недели я чиню баги, которых огромное количество.
Из новых механик, в будущем скорее всего будут добавлены фракции, пока просто типо как еще один уровень абстракции над отрядами. А то на данный момент можно прийти в деревню и начать драться с жителем, а остальные на это не будут реагировать. А если просто объединить их всех в отряд то и вести они себя будут соответственно (сбившись в кучу вокруг лидера).
Ударил одного крестьянина - дипломатические отношения со всеми жителями деревни портятся на долгие годы. Вот это справедливость.
Из новых механик, в будущем скорее всего будут добавлены фракции, пока просто типо как еще один уровень абстракции над отрядами. А то на данный момент можно прийти в деревню и начать драться с жителем, а остальные на это не будут реагировать. А если просто объединить их всех в отряд то и вести они себя будут соответственно (сбившись в кучу вокруг лидера).
Ударил одного крестьянина - дипломатические отношения со всеми жителями деревни портятся на долгие годы. Вот это справедливость.
>>832908
>>832910
>>832913
Че-то я заметил, что мои сообщения иногда приобретают какой-то официально-высокопарный тон.
"Это решение было продиктовано тем-то и тем-то"
Я не специально, это видимо такая проф-деформация из за написания статей по учебе.
На самом деле я осознаю насколько я кривой кодер, вон, уже сколько времени сижу и не могу нормальную систему сейвов сделать)
Так что большинство решений продиктованы тем, что первое в голову придет.
>>832910
>>832913
Че-то я заметил, что мои сообщения иногда приобретают какой-то официально-высокопарный тон.
"Это решение было продиктовано тем-то и тем-то"
Я не специально, это видимо такая проф-деформация из за написания статей по учебе.
На самом деле я осознаю насколько я кривой кодер, вон, уже сколько времени сижу и не могу нормальную систему сейвов сделать)
Так что большинство решений продиктованы тем, что первое в голову придет.
>>832902
Разве процедурная толщина, прозрачность и т.д. образуют красоту?
Насколько я знаю, в обычных 2D играх все эти шлейфы стараются рисовать одним спрайтом. Во-первых, так дешевле, во-вторых, этот шлейф всё равно видно будет 1-2 кадра, игрок ничего не разглядит.
Процедурный шлейф из юнити полезен игре типа Fruit Ninja, где траектория удара непредсказуема и находится в плоскости экрана, поэтому шлейф приходится строить процедурно. В большинстве игр это не так, предмет летит по предсказуемой траектории, чаще всего по прямой, а шлейфы от холодного оружия являются простой дугой.
Вот на твоей гифке лично я вижу статичный спрайт, который крутится вокруг оси, перпендикулярной плоскости спрайта. И если тебе нужен именно такой эффект кручения, например, для анимации загрузки уровня, ты должен сделать его спрайтом. Потому что процедурно генерировать такую предсказуемую вещь - впустую тратить ресурсы.
>>832908
Звучит странно, ты имеешь в виду Component в ECS? Так это же не ты сам делаешь, а ECS должна автоматически это делать, абстрагируя тебя от работы с пулами данных.
Именно так. Ограничение в 64x64 клетки как-то не очень звучит.
Помимо рендеринга, чанки могут использоваться для уменьшения других вычислений. У тебя сейчас боты ходят по всей карте или только в поле зрения игрока? Логично было бы сделать их немного "глупее" вне поля зрения игрока.
Согласен. Тем более что выгода не гарантированна. Нужно сначала провести тесты и сравнить производительность, прежде чем вводить в игру такую оптимизацию.
>>832910
В чём секрет-то, это же Unity, в ней нет труъ 2D.
>>832913
А что на счёт куриц? Курица будет телепатически сообщать всем жителям об ухудшении отношений в результате пинка ей под зад?
>>832941
JSON или бинарный формат? Сохраняешь все тайлы или только параметры генерации?
>Я же хочу чтобы красиво было.
>У него процедурно меняется толщина, прозрачность и так далее.
Разве процедурная толщина, прозрачность и т.д. образуют красоту?
Насколько я знаю, в обычных 2D играх все эти шлейфы стараются рисовать одним спрайтом. Во-первых, так дешевле, во-вторых, этот шлейф всё равно видно будет 1-2 кадра, игрок ничего не разглядит.
Процедурный шлейф из юнити полезен игре типа Fruit Ninja, где траектория удара непредсказуема и находится в плоскости экрана, поэтому шлейф приходится строить процедурно. В большинстве игр это не так, предмет летит по предсказуемой траектории, чаще всего по прямой, а шлейфы от холодного оружия являются простой дугой.
Вот на твоей гифке лично я вижу статичный спрайт, который крутится вокруг оси, перпендикулярной плоскости спрайта. И если тебе нужен именно такой эффект кручения, например, для анимации загрузки уровня, ты должен сделать его спрайтом. Потому что процедурно генерировать такую предсказуемую вещь - впустую тратить ресурсы.
>>832908
>А пул это просто хранилище из кучи одинаковых примитивных объектов, использующихся для рендеринга, которые берутся оттуда по мере надобности, а потом туда-же возвращаются.
Звучит странно, ты имеешь в виду Component в ECS? Так это же не ты сам делаешь, а ECS должна автоматически это делать, абстрагируя тебя от работы с пулами данных.
>делать этажи произвольного размера звучит очень заманчиво
Именно так. Ограничение в 64x64 клетки как-то не очень звучит.
>Делить его на меньшие области я пока не вижу смысла, узкое место производительности сейчас явно не в этом.
Помимо рендеринга, чанки могут использоваться для уменьшения других вычислений. У тебя сейчас боты ходят по всей карте или только в поле зрения игрока? Логично было бы сделать их немного "глупее" вне поля зрения игрока.
>сложно
Согласен. Тем более что выгода не гарантированна. Нужно сначала провести тесты и сравнить производительность, прежде чем вводить в игру такую оптимизацию.
>>832910
>величайший секрет
В чём секрет-то, это же Unity, в ней нет труъ 2D.
>>832913
>Ударил одного крестьянина - дипломатические отношения со всеми жителями деревни портятся на долгие годы.
А что на счёт куриц? Курица будет телепатически сообщать всем жителям об ухудшении отношений в результате пинка ей под зад?
>>832941
>нормальную систему сейвов
JSON или бинарный формат? Сохраняешь все тайлы или только параметры генерации?
>>832902
Разве процедурная толщина, прозрачность и т.д. образуют красоту?
Насколько я знаю, в обычных 2D играх все эти шлейфы стараются рисовать одним спрайтом. Во-первых, так дешевле, во-вторых, этот шлейф всё равно видно будет 1-2 кадра, игрок ничего не разглядит.
Процедурный шлейф из юнити полезен игре типа Fruit Ninja, где траектория удара непредсказуема и находится в плоскости экрана, поэтому шлейф приходится строить процедурно. В большинстве игр это не так, предмет летит по предсказуемой траектории, чаще всего по прямой, а шлейфы от холодного оружия являются простой дугой.
Вот на твоей гифке лично я вижу статичный спрайт, который крутится вокруг оси, перпендикулярной плоскости спрайта. И если тебе нужен именно такой эффект кручения, например, для анимации загрузки уровня, ты должен сделать его спрайтом. Потому что процедурно генерировать такую предсказуемую вещь - впустую тратить ресурсы.
>>832908
Звучит странно, ты имеешь в виду Component в ECS? Так это же не ты сам делаешь, а ECS должна автоматически это делать, абстрагируя тебя от работы с пулами данных.
Именно так. Ограничение в 64x64 клетки как-то не очень звучит.
Помимо рендеринга, чанки могут использоваться для уменьшения других вычислений. У тебя сейчас боты ходят по всей карте или только в поле зрения игрока? Логично было бы сделать их немного "глупее" вне поля зрения игрока.
Согласен. Тем более что выгода не гарантированна. Нужно сначала провести тесты и сравнить производительность, прежде чем вводить в игру такую оптимизацию.
>>832910
В чём секрет-то, это же Unity, в ней нет труъ 2D.
>>832913
А что на счёт куриц? Курица будет телепатически сообщать всем жителям об ухудшении отношений в результате пинка ей под зад?
>>832941
JSON или бинарный формат? Сохраняешь все тайлы или только параметры генерации?
>Я же хочу чтобы красиво было.
>У него процедурно меняется толщина, прозрачность и так далее.
Разве процедурная толщина, прозрачность и т.д. образуют красоту?
Насколько я знаю, в обычных 2D играх все эти шлейфы стараются рисовать одним спрайтом. Во-первых, так дешевле, во-вторых, этот шлейф всё равно видно будет 1-2 кадра, игрок ничего не разглядит.
Процедурный шлейф из юнити полезен игре типа Fruit Ninja, где траектория удара непредсказуема и находится в плоскости экрана, поэтому шлейф приходится строить процедурно. В большинстве игр это не так, предмет летит по предсказуемой траектории, чаще всего по прямой, а шлейфы от холодного оружия являются простой дугой.
Вот на твоей гифке лично я вижу статичный спрайт, который крутится вокруг оси, перпендикулярной плоскости спрайта. И если тебе нужен именно такой эффект кручения, например, для анимации загрузки уровня, ты должен сделать его спрайтом. Потому что процедурно генерировать такую предсказуемую вещь - впустую тратить ресурсы.
>>832908
>А пул это просто хранилище из кучи одинаковых примитивных объектов, использующихся для рендеринга, которые берутся оттуда по мере надобности, а потом туда-же возвращаются.
Звучит странно, ты имеешь в виду Component в ECS? Так это же не ты сам делаешь, а ECS должна автоматически это делать, абстрагируя тебя от работы с пулами данных.
>делать этажи произвольного размера звучит очень заманчиво
Именно так. Ограничение в 64x64 клетки как-то не очень звучит.
>Делить его на меньшие области я пока не вижу смысла, узкое место производительности сейчас явно не в этом.
Помимо рендеринга, чанки могут использоваться для уменьшения других вычислений. У тебя сейчас боты ходят по всей карте или только в поле зрения игрока? Логично было бы сделать их немного "глупее" вне поля зрения игрока.
>сложно
Согласен. Тем более что выгода не гарантированна. Нужно сначала провести тесты и сравнить производительность, прежде чем вводить в игру такую оптимизацию.
>>832910
>величайший секрет
В чём секрет-то, это же Unity, в ней нет труъ 2D.
>>832913
>Ударил одного крестьянина - дипломатические отношения со всеми жителями деревни портятся на долгие годы.
А что на счёт куриц? Курица будет телепатически сообщать всем жителям об ухудшении отношений в результате пинка ей под зад?
>>832941
>нормальную систему сейвов
JSON или бинарный формат? Сохраняешь все тайлы или только параметры генерации?
>>832945
Не пул данных, пул гемобджектов с рендерерами. Рендеринг в Unity DOTS еще слишком сырой, так что я использую обычные SpriteRenderer.
Я беру их из пула для того чтобы не делать каждый раз instanciate.
Мобы ходят по всей карте. В идеальных условиях игрок, собственно, половину этой карты может держать в поле зрения, у него сейчас радиус обзора 20.
Так что, пока карта такого размера, не вижу смысла как-то менять искуссвенный интеллект в эту сторону, все равно там эффект будет не в 10 раз, а на сколько-то процентов. На общем фоне это не окупится.
Ну мне просто нравится, как выглядит эта безумная лестница, Пока в 2д смотришь особо этого не ожидаешь)
домашних животных в игре пока нет, но я могу разными способами это рализовать.
По геймплейным соображениям скорее всего будет примерно так как ты описал. а ты представь, курица же орет на всю деревню когда ее бьют. Вполне логично что это не останется незамеченным.
Ну, с нюансами конечно. Мб если от нее в каком-то радиусе есть человек то все сагрятся.
Да не, все норм, сейвы есть. Бинарные. Я просто посетовал на тему того, что там часто что-то отваливается во время рефакторинга, а замечаешь это не сразу.
По поводу шлейфов какие-то очень странные рассуждения...
Кажется мы не понимаем друг друга.
Мне нужен шлейф ведущий из точки А в точку Б находящуюся на произвольном расстоянии. Как он может быть одним спрайтом? Типо мне его растянуть до нужной длины?
Нарисуй, что-ли, что ты имеешь в виду..
>пул
Не пул данных, пул гемобджектов с рендерерами. Рендеринг в Unity DOTS еще слишком сырой, так что я использую обычные SpriteRenderer.
Я беру их из пула для того чтобы не делать каждый раз instanciate.
>чанки
Мобы ходят по всей карте. В идеальных условиях игрок, собственно, половину этой карты может держать в поле зрения, у него сейчас радиус обзора 20.
Так что, пока карта такого размера, не вижу смысла как-то менять искуссвенный интеллект в эту сторону, все равно там эффект будет не в 10 раз, а на сколько-то процентов. На общем фоне это не окупится.
>секрет
Ну мне просто нравится, как выглядит эта безумная лестница, Пока в 2д смотришь особо этого не ожидаешь)
>курицы
домашних животных в игре пока нет, но я могу разными способами это рализовать.
По геймплейным соображениям скорее всего будет примерно так как ты описал. а ты представь, курица же орет на всю деревню когда ее бьют. Вполне логично что это не останется незамеченным.
Ну, с нюансами конечно. Мб если от нее в каком-то радиусе есть человек то все сагрятся.
>сейвы
Да не, все норм, сейвы есть. Бинарные. Я просто посетовал на тему того, что там часто что-то отваливается во время рефакторинга, а замечаешь это не сразу.
По поводу шлейфов какие-то очень странные рассуждения...
Кажется мы не понимаем друг друга.
Мне нужен шлейф ведущий из точки А в точку Б находящуюся на произвольном расстоянии. Как он может быть одним спрайтом? Типо мне его растянуть до нужной длины?
Нарисуй, что-ли, что ты имеешь в виду..
>>832963
Признаю, тупанул. У тебя же мгновенная телепортация предмета в другую клетку, а не анимация полёта между закончившимся ходом и началом следующего. Если бы была анимация полёта по прямой, можно было бы рисовать фиксированный шлейф как поток огня от реактивного двигателя, только белый (наверняка видел подобное во множестве игр). Почему ты отказался от анимаций, неужели они так сильно мешают?
Если тебе нужно процедурно нарисовать прямую линию, разве в юнити нет функции типа draw_line?
>Мне нужен шлейф ведущий из точки А в точку Б находящуюся на произвольном расстоянии. Как он может быть одним спрайтом?
Признаю, тупанул. У тебя же мгновенная телепортация предмета в другую клетку, а не анимация полёта между закончившимся ходом и началом следующего. Если бы была анимация полёта по прямой, можно было бы рисовать фиксированный шлейф как поток огня от реактивного двигателя, только белый (наверняка видел подобное во множестве игр). Почему ты отказался от анимаций, неужели они так сильно мешают?
Если тебе нужно процедурно нарисовать прямую линию, разве в юнити нет функции типа draw_line?
30,9 Мб, 1137x810>>833009
>>831160
Ух....
Сегодня вечером я просто сел, подумал и все сделал. Больше никаких шлейфов не нужно, все работает идеально, ровно как я и хотел.
Это была очень простое решение, долго расписывать в чем оно заключалось, главное что теперь все работает.
Давайте сделаем вид что все так и было с самого начала)
>>831160
Ух....
Сегодня вечером я просто сел, подумал и все сделал. Больше никаких шлейфов не нужно, все работает идеально, ровно как я и хотел.
Это была очень простое решение, долго расписывать в чем оно заключалось, главное что теперь все работает.
Давайте сделаем вид что все так и было с самого начала)
Как дела?
Очень нравится проект, буду следить.
Можешь ещё рассказать о гностицизме, который ты уже упоминал? >>827649 Решил, что лучше просто спросить, чем пытаться разобраться в источниках из гугла непонятной достоверности. Может быть меня это вдохновит.
fellow roguelike fan
Очень нравится проект, буду следить.
Можешь ещё рассказать о гностицизме, который ты уже упоминал? >>827649 Решил, что лучше просто спросить, чем пытаться разобраться в источниках из гугла непонятной достоверности. Может быть меня это вдохновит.
fellow roguelike fan
>>833025
Как-то по ебаному траектория выглядит местами, всрато.
Не лучше прямую линию до курсора рисовать от персонажа а потом все тайлы через которые она проходит и считать траекторией?
Как-то по ебаному траектория выглядит местами, всрато.
Не лучше прямую линию до курсора рисовать от персонажа а потом все тайлы через которые она проходит и считать траекторией?
>>834046
А точки это не траектория, это пасфайндинг самого персонажа.
Хотя было бы уместно в режиме кидания (если он здесь отдельно включается как в большинстве рогаликов) выключать точки и подсвечивать именно траекторию.
Надеюсь ОПа не забрали.
А точки это не траектория, это пасфайндинг самого персонажа.
Хотя было бы уместно в режиме кидания (если он здесь отдельно включается как в большинстве рогаликов) выключать точки и подсвечивать именно траекторию.
Надеюсь ОПа не забрали.
>>834294
В таком случае пасфайндинг тоже всратый и должен быть пофикшен. Там пустое поле, нечего обходить, и хоть по тайлам то на то и выходит, но выглядит всрато, потому-что видно что это не кратчайший путь.
В таком случае пасфайндинг тоже всратый и должен быть пофикшен. Там пустое поле, нечего обходить, и хоть по тайлам то на то и выходит, но выглядит всрато, потому-что видно что это не кратчайший путь.
>>834296
upd. Я пригляделся и вроде как по этому же пасфайнду у него траектория броска и идёт.
upd. Я пригляделся и вроде как по этому же пасфайнду у него траектория броска и идёт.
>>834045
>>834046
>>834294
>>834296
>>834297
Траектория и пасфайндинг это разные алгоритмы. Траектория вроде сейчас нормально работает.
А пасфайндинг действительно какой-то кривой, не смотря на то, что расстояние в клетках там получается такое-же, как если бы он был нормальный. Мб я даже знаю как это исправить.
>>834046
>>834294
>>834296
>>834297
Траектория и пасфайндинг это разные алгоритмы. Траектория вроде сейчас нормально работает.
А пасфайндинг действительно какой-то кривой, не смотря на то, что расстояние в клетках там получается такое-же, как если бы он был нормальный. Мб я даже знаю как это исправить.
149 Кб, 500x769>>834003
По большому счету гностицизм это еще одна авраамическая религия наравне с иудаизмом, христианством и исламом, которая существовала примерно первые 5 веков нашей эры, а потом вымерла во многом из за собственного пессимизма и нигилизма.
Гностическое учение это свойственное авраамизму призрение к материальному миру доведенное до крайности. Гностики признавали ветхий завет, но при этом для них бог ветхого завета это основной отрицательный персонаж, которого они называли Демиургом. По их мнению мир, созданный Демиургом абсолютно ужасен и создан им либо по ошибке, либо со злым умыслом, в зависимости от конкретной версии гностического учения. Других представителей авраамических религий они считают рабами Демиурга, а для себя целью ставят освобождение из материального мира, которое можно достичь путем обретения неких тайных знаний. При этом сделать это может не каждый, а только тот у кого, грубо говоря, есть душа. А у большинства людей ее нет и поэтому в их отношении все дозволено.
Еще у гностиков присутствует безумно сложная мифологическая система. По мимо демиурга у них еще огромное количество различных богов, по большей части непознаваемых, и напоминающих по своим свойствам тех про которых писал Лавкрафт. Кстати, Иисуса они тоже считают богом, и при этом не являющимся сыном Демиурга, а отдельным богом примерно одного с ним ранга.
В реальности Гностики собирались в различные закрытые секты, часто жили под землей в катакомбах, полностью отвергали общественную мораль, устраивали оргии, похищали и убивали людей и так далее.
В общем ничего себе.
Я удивлен что у нас до сих пор нет никаких игр в таком сеттинге.
По большому счету гностицизм это еще одна авраамическая религия наравне с иудаизмом, христианством и исламом, которая существовала примерно первые 5 веков нашей эры, а потом вымерла во многом из за собственного пессимизма и нигилизма.
Гностическое учение это свойственное авраамизму призрение к материальному миру доведенное до крайности. Гностики признавали ветхий завет, но при этом для них бог ветхого завета это основной отрицательный персонаж, которого они называли Демиургом. По их мнению мир, созданный Демиургом абсолютно ужасен и создан им либо по ошибке, либо со злым умыслом, в зависимости от конкретной версии гностического учения. Других представителей авраамических религий они считают рабами Демиурга, а для себя целью ставят освобождение из материального мира, которое можно достичь путем обретения неких тайных знаний. При этом сделать это может не каждый, а только тот у кого, грубо говоря, есть душа. А у большинства людей ее нет и поэтому в их отношении все дозволено.
Еще у гностиков присутствует безумно сложная мифологическая система. По мимо демиурга у них еще огромное количество различных богов, по большей части непознаваемых, и напоминающих по своим свойствам тех про которых писал Лавкрафт. Кстати, Иисуса они тоже считают богом, и при этом не являющимся сыном Демиурга, а отдельным богом примерно одного с ним ранга.
В реальности Гностики собирались в различные закрытые секты, часто жили под землей в катакомбах, полностью отвергали общественную мораль, устраивали оргии, похищали и убивали людей и так далее.
В общем ничего себе.
Я удивлен что у нас до сих пор нет никаких игр в таком сеттинге.
>>834383
Для пасфайнда хуяришь рейкаст до курсора или объекта в который он воткнётся, если втыкается в объект выбираешь ближайший по x,y пустой тайл к точке назначения из которого есть прямой рейкаст к персонажу, кастишь из этого тайла к точке назначения, повторяешь пока столкновений не будет. Тайлы ессно все запоминаешь, из этого строишь путь.
Вроде как-то так, я конечно прибуханый сейчас и может упустил чего.
Для пасфайнда хуяришь рейкаст до курсора или объекта в который он воткнётся, если втыкается в объект выбираешь ближайший по x,y пустой тайл к точке назначения из которого есть прямой рейкаст к персонажу, кастишь из этого тайла к точке назначения, повторяешь пока столкновений не будет. Тайлы ессно все запоминаешь, из этого строишь путь.
Вроде как-то так, я конечно прибуханый сейчас и может упустил чего.
>>834388
Бывает, хули, мне лень сейчас над этим думать, со своим прокгеном ебусь. Главное - идея ясна.
Бывает, хули, мне лень сейчас над этим думать, со своим прокгеном ебусь. Главное - идея ясна.
219 Кб, 600x493>>834383
>>834387
Сделал.
Вся тема была в том, что клетчатое поле это, в каком-то роде, неевклидова система и там может быть несколько прямых маршрутов. Несмотря на то что для нас они выглядят угловатыми, в рамках клетчатого поля они именно, что прямые и абсолютно равнозначные. Алгоритм выбирал первый попавшийся из них.
Пришлось немного повозиться, но теперь он выбирает маршрут, наиболее близкий к прямой евклидовой линии.
>>834387
Сделал.
Вся тема была в том, что клетчатое поле это, в каком-то роде, неевклидова система и там может быть несколько прямых маршрутов. Несмотря на то что для нас они выглядят угловатыми, в рамках клетчатого поля они именно, что прямые и абсолютно равнозначные. Алгоритм выбирал первый попавшийся из них.
Пришлось немного повозиться, но теперь он выбирает маршрут, наиболее близкий к прямой евклидовой линии.
>>834393
Ну, я думал, что у меня FPS сталкеро/тарково/хант:шоудаун сессионка будет с процедурными уровнями, где чувачки заходят в сессию и лутают артефакты, избегая аномалий и попутно стараясь убить/не быть убитыми чтобы съебать с лутом.
Но тут выяснилось, что:
1) Уже существует Lost Light.
2) Это какой-то унылый дроч.
Так что теперь это будет сингл экспириенс с душой, эмбиентом, хоррор-элементами и сужетом наподобие Papers, please, где ты лутаешь чтобы семья с голоду не сдохла, попутно привнося во внешний мир хаос, боль и разруху. И без стрельбы вообще нахуй.
На данном этапе у меня есть прокгенкарта, и почти закончил с генерацией зданий.
Ну, я думал, что у меня FPS сталкеро/тарково/хант:шоудаун сессионка будет с процедурными уровнями, где чувачки заходят в сессию и лутают артефакты, избегая аномалий и попутно стараясь убить/не быть убитыми чтобы съебать с лутом.
Но тут выяснилось, что:
1) Уже существует Lost Light.
2) Это какой-то унылый дроч.
Так что теперь это будет сингл экспириенс с душой, эмбиентом, хоррор-элементами и сужетом наподобие Papers, please, где ты лутаешь чтобы семья с голоду не сдохла, попутно привнося во внешний мир хаос, боль и разруху. И без стрельбы вообще нахуй.
На данном этапе у меня есть прокгенкарта, и почти закончил с генерацией зданий.
>>834391
Молодец. Люблю умных и продуктивных. И рогалики.
Молодец. Люблю умных и продуктивных. И рогалики.
>>834384
Как мог бы выглядеть такой сеттинг?
А из существующего самое близкое, что приходит в голову - Noita. Там сеттинг на основе герметизма, а он, как понимаю, вместе с гностицизмом рука об руку шёл.
Как мог бы выглядеть такой сеттинг?
А из существующего самое близкое, что приходит в голову - Noita. Там сеттинг на основе герметизма, а он, как понимаю, вместе с гностицизмом рука об руку шёл.
5 Мб, webm,640x360, 2:08
>>834531
О, кстати да, обожаю Нойту.
Вообще, если подумать, адаптировать такой сеттинг под какой-то геймплей и правда непросто.
Вот например, возьмем гностический пантеон. Богов там много, но в то-же время про большинство этих богов известно, грубо говоря, только то, что они есть.
Что конкретно они из себя представляют не совсем ясно, как с ними можно повзаимодействовать тоже не понятно.
Они не принимают жертв.
Они не связаны ни с какими сферами человеческой жизни, типо торговли или войны, так же как и с природными силами, как в нормальном язычестве.
Всякие традиционные языческие боги, кстати тоже признаются гностиками как нечто имеющее место, но низведены в ранг архонтов, слуг Демиурга. Ну что-то типо демонов, если упростить.
А настоящие боги в гностицизме в основном соотносятся со всякими абстрактными понятиями, как например "Смысл" или "Неподвижность".
Можно ли вообще считать их богами в привычном смысле?
Для какой-то геймплейной адаптации всего этого явно придется очень много выдумывать.
О, кстати да, обожаю Нойту.
Вообще, если подумать, адаптировать такой сеттинг под какой-то геймплей и правда непросто.
Вот например, возьмем гностический пантеон. Богов там много, но в то-же время про большинство этих богов известно, грубо говоря, только то, что они есть.
Что конкретно они из себя представляют не совсем ясно, как с ними можно повзаимодействовать тоже не понятно.
Они не принимают жертв.
Они не связаны ни с какими сферами человеческой жизни, типо торговли или войны, так же как и с природными силами, как в нормальном язычестве.
Всякие традиционные языческие боги, кстати тоже признаются гностиками как нечто имеющее место, но низведены в ранг архонтов, слуг Демиурга. Ну что-то типо демонов, если упростить.
А настоящие боги в гностицизме в основном соотносятся со всякими абстрактными понятиями, как например "Смысл" или "Неподвижность".
Можно ли вообще считать их богами в привычном смысле?
Для какой-то геймплейной адаптации всего этого явно придется очень много выдумывать.
>>834546
Я после твоего первого упоминания гностицизма заинтересовался и решил посмотреть, что есть по теме, а там оказалось, что у Дика (которого я очень люблю) есть ряд книг, вдохновлённых теми или иными гностическими мотивами. Насколько я понял, из его книг в сторону гностицизма больше всего ушли ВАЛИС и продолжения, но меня сначала больше заинтересовала Deus Irae (Господь Гнева), и я её прочёл.
Там очень прикольный постапокалиптический сеттинг, много хорошо обыгранных заимствований из мифологии. Что касается гностических мотивов - в этом сеттинге одновременно сосуществуют увядающая христианская церковь и церковь Господа Гнева, члены который поклоняются человеку, который изобрёл и актировал бомбу, которая уничтожила старый мир. Вот тебе и демиург. А есть ли у этого человека божественное сверхъестественное начало однозначно не выясняется. И сам персонаж Господа Гнева обыгран очень интересно и неожиданно. И основная сюжетная линия, связанная с ним - это майндфак.
Я после твоего первого упоминания гностицизма заинтересовался и решил посмотреть, что есть по теме, а там оказалось, что у Дика (которого я очень люблю) есть ряд книг, вдохновлённых теми или иными гностическими мотивами. Насколько я понял, из его книг в сторону гностицизма больше всего ушли ВАЛИС и продолжения, но меня сначала больше заинтересовала Deus Irae (Господь Гнева), и я её прочёл.
Там очень прикольный постапокалиптический сеттинг, много хорошо обыгранных заимствований из мифологии. Что касается гностических мотивов - в этом сеттинге одновременно сосуществуют увядающая христианская церковь и церковь Господа Гнева, члены который поклоняются человеку, который изобрёл и актировал бомбу, которая уничтожила старый мир. Вот тебе и демиург. А есть ли у этого человека божественное сверхъестественное начало однозначно не выясняется. И сам персонаж Господа Гнева обыгран очень интересно и неожиданно. И основная сюжетная линия, связанная с ним - это майндфак.
>>834494
Как я смотрю на это, не очень-то и амбициозно.
Для начала сделаю MVP - прокгенкарта, прокгенздания, фпс управление, инвентарь, один артефакт чтобы класть в инвентарь, одну аномалию, вин/луз стейт, главное меню с сэйв/лоадом, лобби с выбором карты.
Потом буду итерировать и добавлять, надстраивать на готовом костяке просто.
Как я смотрю на это, не очень-то и амбициозно.
Для начала сделаю MVP - прокгенкарта, прокгенздания, фпс управление, инвентарь, один артефакт чтобы класть в инвентарь, одну аномалию, вин/луз стейт, главное меню с сэйв/лоадом, лобби с выбором карты.
Потом буду итерировать и добавлять, надстраивать на готовом костяке просто.
22 Кб, 1015x871АААаа все, кажется я пофиксил большую часть багов, во всяком случае мне удалось пройти игру дойти до Владыки Глубин на 7 этаже чтобы он разорвал меня и весь мой отряд на части ни разу не вылетев не повиснув и не словив баг с дубликацией предметов.
Вот вам новый билд.
https://vk.com/katabasys?w=wall-201941833_94%2Fall
Вот вам новый билд.
https://vk.com/katabasys?w=wall-201941833_94%2Fall
>>834663
Печально.
Почему-то на некоторых компах игра действительно начинает ужасно тормозить и я абсолютно не понимаю в чем дело. У меня есть выборка из 4 человек у которых все норм, включая меня самого и есть один чел который лагает. Видимо теперь вас двое.
Прошу тебя сделать следующее:
Описать характер тормозов.
Рассказать что у тебя примерно за комп. Ведро это с болтами из 90х или нет. предполагаю, что нет.
Начать новую игру.
Нажать несколько раз ctrl + f10 пока в правом верхнем углу не появится полная инфа о производительности.
Сделать скрин с этой штукой пока ты просто стоишь.
Сделать скрин пока персонаж куда-то идет.
вдруг, если у тебя нет, вот очень удобная прога для скриншотов https://app.prntscr.com/ru/index.html
а кнопка B бывает полезна для дебага. Решил ее оставить.
Печально.
Почему-то на некоторых компах игра действительно начинает ужасно тормозить и я абсолютно не понимаю в чем дело. У меня есть выборка из 4 человек у которых все норм, включая меня самого и есть один чел который лагает. Видимо теперь вас двое.
Прошу тебя сделать следующее:
Описать характер тормозов.
Рассказать что у тебя примерно за комп. Ведро это с болтами из 90х или нет. предполагаю, что нет.
Начать новую игру.
Нажать несколько раз ctrl + f10 пока в правом верхнем углу не появится полная инфа о производительности.
Сделать скрин с этой штукой пока ты просто стоишь.
Сделать скрин пока персонаж куда-то идет.
вдруг, если у тебя нет, вот очень удобная прога для скриншотов https://app.prntscr.com/ru/index.html
а кнопка B бывает полезна для дебага. Решил ее оставить.
63 Кб, 750x679>>834664
Ну смотри, я использую клетчатый рейкаст, а не стандартный физический из юнити. Если я буду использовать физический это будет огромная нагрузка, при том что там еще и коллайдеры должны на каждой стене висеть. Пробовал, мне не понравилось.
Основное отличие моего рейкастера даже не в том что он по такой угловатой траектории идет, а в том что он может идти только через середины клеток и проверяет наличие\отсутствие преграды только там. Прочерти линии на своем скрине не до краев клеток а до центров и будет понятно.
Так чтобы он понимал где края объектов, судя по всему никак не сделать, без существенных потерь производительности. В клетчатой геометрии придется довольствоваться клетчатыми рейкастерами.
Ну смотри, я использую клетчатый рейкаст, а не стандартный физический из юнити. Если я буду использовать физический это будет огромная нагрузка, при том что там еще и коллайдеры должны на каждой стене висеть. Пробовал, мне не понравилось.
Основное отличие моего рейкастера даже не в том что он по такой угловатой траектории идет, а в том что он может идти только через середины клеток и проверяет наличие\отсутствие преграды только там. Прочерти линии на своем скрине не до краев клеток а до центров и будет понятно.
Так чтобы он понимал где края объектов, судя по всему никак не сделать, без существенных потерь производительности. В клетчатой геометрии придется довольствоваться клетчатыми рейкастерами.
>>834549
Хм, интересно. Мб мне стоит ознакомиться, хотя фантастику последний раз давным давно читал.
Мне это напомнило рогалик Caves of Qud. Тоже про постапокалипсис и тема культов, если я не ошибаюсь, немного раскрыта.
Вообще интересно было бы найти еще произведений с гностическими мотивами. Смотрел этим летом фильм "Суд над богом". Необычное, полностью диалоговое кино, посвященное теологическому спору между приговоренными к смерти евреями в концлагере. Вот там супер внезапно всплывает гностическая тема и все переворачивает.
Рекомендую.
Хм, интересно. Мб мне стоит ознакомиться, хотя фантастику последний раз давным давно читал.
Мне это напомнило рогалик Caves of Qud. Тоже про постапокалипсис и тема культов, если я не ошибаюсь, немного раскрыта.
Вообще интересно было бы найти еще произведений с гностическими мотивами. Смотрел этим летом фильм "Суд над богом". Необычное, полностью диалоговое кино, посвященное теологическому спору между приговоренными к смерти евреями в концлагере. Вот там супер внезапно всплывает гностическая тема и все переворачивает.
Рекомендую.
30 Кб, 1039x299>>834691
Да, это именно в эту сторону. Я очень мало знаю о Caves of Qud, но когда читал было понятно, что они близки по духу. К пикрелейтеду я бы ещё добавил всратых человекомутантов.
>>834688
Посмотри существующие алгоритмы ФОВа. Они изначально сделаны так, чтобы минимизировать артефакты, в т.ч. невидимые под углом стены.
В libtcod стандартный алгоритм это вот.
http://roguebasin.com/index.php/Restrictive_Precise_Angle_Shadowcasting
В DCSS используется (и мне в DCSS нравилось, как их фов работает) вот этот.
http://roguebasin.com/index.php/Permissive_Field_of_View
Да, это именно в эту сторону. Я очень мало знаю о Caves of Qud, но когда читал было понятно, что они близки по духу. К пикрелейтеду я бы ещё добавил всратых человекомутантов.
>>834688
Посмотри существующие алгоритмы ФОВа. Они изначально сделаны так, чтобы минимизировать артефакты, в т.ч. невидимые под углом стены.
В libtcod стандартный алгоритм это вот.
http://roguebasin.com/index.php/Restrictive_Precise_Angle_Shadowcasting
В DCSS используется (и мне в DCSS нравилось, как их фов работает) вот этот.
http://roguebasin.com/index.php/Permissive_Field_of_View
>>834384
Есть мнение что большая часть современного кино засолено на гностической повестке https://youtu.be/AefmFwVVrfc
Есть мнение что большая часть современного кино засолено на гностической повестке https://youtu.be/AefmFwVVrfc
>>834708
>>834664
Ок, вы почти забайтили меня на переписывание всего FOV'a, но что-то я смотрю на эти письмена на roguebasin и абсолютно не понимаю что они означают.
Мб мне сейчас лучше заняться чем-то более простым. Давно в голове есть идея насчет того как полностью исключить клавиатуру из управления. Сделать такое меню чтобы там были иконки всех все доступных действий и не нужно было запоминать кнопки.
Пожалуй пока этим займусь.
>>834664
Ок, вы почти забайтили меня на переписывание всего FOV'a, но что-то я смотрю на эти письмена на roguebasin и абсолютно не понимаю что они означают.
Мб мне сейчас лучше заняться чем-то более простым. Давно в голове есть идея насчет того как полностью исключить клавиатуру из управления. Сделать такое меню чтобы там были иконки всех все доступных действий и не нужно было запоминать кнопки.
Пожалуй пока этим займусь.
>>834687
i3-2130, 8Gb DDR3, SSD, HD6450 1Gb, это рабочее некроговно, но всё равно 10 фпс в простое это что-то с чем-то.
i3-2130, 8Gb DDR3, SSD, HD6450 1Gb, это рабочее некроговно, но всё равно 10 фпс в простое это что-то с чем-то.
>>834830
Какая жесть.
Кажется я понимаю в чем проблема.
Когда персонаж стоит, не происходит практически ничего кроме рендеринга спрайтов. Видимо дело в нем.
Я вспомнил что у меня есть еще один комп, запустил на нем, там то-же самое. Причем почему-то когда я отдаляю камеру на максимальное расстояние фпс выравнивается до 60, а когда приближаю опускается до 20. Вот это я вообще хз почему, логичнее было бы наоборот. Но в любом случае, очевидно, дело в рендеринге и слабой видеокарте.
Скорее всего мне нужно вернуть систему с атласами спрайтов, которая по идее и сделана для решения таких проблем. Я уже ее внедрял, но тогда эта оптимизация показалась мне избыточной и так как она накладывала некоторые ограничения, я от нее отказался.
Какая жесть.
Кажется я понимаю в чем проблема.
Когда персонаж стоит, не происходит практически ничего кроме рендеринга спрайтов. Видимо дело в нем.
Я вспомнил что у меня есть еще один комп, запустил на нем, там то-же самое. Причем почему-то когда я отдаляю камеру на максимальное расстояние фпс выравнивается до 60, а когда приближаю опускается до 20. Вот это я вообще хз почему, логичнее было бы наоборот. Но в любом случае, очевидно, дело в рендеринге и слабой видеокарте.
Скорее всего мне нужно вернуть систему с атласами спрайтов, которая по идее и сделана для решения таких проблем. Я уже ее внедрял, но тогда эта оптимизация показалась мне избыточной и так как она накладывала некоторые ограничения, я от нее отказался.
>>834762
Расскажи в псевдокоде как работает твой FOV и LOS (буддой клянусь, если у тебя каждый scenery объект оправшивается в Update я в тебе разочаруюсь нахуй).
Расскажи в псевдокоде как работает твой FOV и LOS (буддой клянусь, если у тебя каждый scenery объект оправшивается в Update я в тебе разочаруюсь нахуй).
121 Кб, 1146x800>>834837
Не, не все не так плохо)
Двач не очень хорош для написания кода, так что я просто скрин кину.
Если в двух словах то там происходит следующее.
Это джоба.
В нее подается:
-нейтив массив всех клеток.
-позиции членов отряда игрока
-дальность поля зрения.
Далее в рапаралеленном виде мы итерируемся через весь массив клеток.
Для каждой клетки смотрим попадает ли он в дистанцию видимости хотя-бы одного тиммейта.
Если да, то начинаем while.
в нем последовательно прибавляем к позиции текущей клетки нормализованный вектор в сторону клетки ближайшего наблюдателя. Ну типо прямую линию чертим.
Каждый раз у нас получается дробная координата, округляем ее до целочисленной.
Смотрим что находится на клетке по этим целочисленным координатам.
Если там стена то break;
Если нет то continue;
И так пока не дойдем до клетки где наблюдатель стоит. Тогда говорим что изначальная клетка является видимой.
Ну и потом еще кусочек кода не влезший на скрин, который определяет прозрачность тумана войны.
Да, не самая продуманная система, конечно это все намного умнее можно сделать.
Можно сходу решить проблему о которой мы говорим, например этот while проводить 4 раза для каждой клетки и чертить линию не из центра клетки а из каждого из углов, но это, собственно в 4 раза стоимость и повысит. Ну блин, или не 4. Там 3, или 2, хз, сколько там углов на самом деле имеет смысл проверять.
Лучше наверно вообще все это переписать и сделать нормально по существующим алгоритмам. Пока просто что-то сил нет на это)
Не, не все не так плохо)
Двач не очень хорош для написания кода, так что я просто скрин кину.
Если в двух словах то там происходит следующее.
Это джоба.
В нее подается:
-нейтив массив всех клеток.
-позиции членов отряда игрока
-дальность поля зрения.
Далее в рапаралеленном виде мы итерируемся через весь массив клеток.
Для каждой клетки смотрим попадает ли он в дистанцию видимости хотя-бы одного тиммейта.
Если да, то начинаем while.
в нем последовательно прибавляем к позиции текущей клетки нормализованный вектор в сторону клетки ближайшего наблюдателя. Ну типо прямую линию чертим.
Каждый раз у нас получается дробная координата, округляем ее до целочисленной.
Смотрим что находится на клетке по этим целочисленным координатам.
Если там стена то break;
Если нет то continue;
И так пока не дойдем до клетки где наблюдатель стоит. Тогда говорим что изначальная клетка является видимой.
Ну и потом еще кусочек кода не влезший на скрин, который определяет прозрачность тумана войны.
Да, не самая продуманная система, конечно это все намного умнее можно сделать.
Можно сходу решить проблему о которой мы говорим, например этот while проводить 4 раза для каждой клетки и чертить линию не из центра клетки а из каждого из углов, но это, собственно в 4 раза стоимость и повысит. Ну блин, или не 4. Там 3, или 2, хз, сколько там углов на самом деле имеет смысл проверять.
Лучше наверно вообще все это переписать и сделать нормально по существующим алгоритмам. Пока просто что-то сил нет на это)
121 Кб, 1146x800>>834837
Не, не все не так плохо)
Двач не очень хорош для написания кода, так что я просто скрин кину.
Если в двух словах то там происходит следующее.
Это джоба.
В нее подается:
-нейтив массив всех клеток.
-позиции членов отряда игрока
-дальность поля зрения.
Далее в рапаралеленном виде мы итерируемся через весь массив клеток.
Для каждой клетки смотрим попадает ли он в дистанцию видимости хотя-бы одного тиммейта.
Если да, то начинаем while.
в нем последовательно прибавляем к позиции текущей клетки нормализованный вектор в сторону клетки ближайшего наблюдателя. Ну типо прямую линию чертим.
Каждый раз у нас получается дробная координата, округляем ее до целочисленной.
Смотрим что находится на клетке по этим целочисленным координатам.
Если там стена то break;
Если нет то continue;
И так пока не дойдем до клетки где наблюдатель стоит. Тогда говорим что изначальная клетка является видимой.
Ну и потом еще кусочек кода не влезший на скрин, который определяет прозрачность тумана войны.
Да, не самая продуманная система, конечно это все намного умнее можно сделать.
Можно сходу решить проблему о которой мы говорим, например этот while проводить 4 раза для каждой клетки и чертить линию не из центра клетки а из каждого из углов, но это, собственно в 4 раза стоимость и повысит. Ну блин, или не 4. Там 3, или 2, хз, сколько там углов на самом деле имеет смысл проверять.
Лучше наверно вообще все это переписать и сделать нормально по существующим алгоритмам. Пока просто что-то сил нет на это)
Не, не все не так плохо)
Двач не очень хорош для написания кода, так что я просто скрин кину.
Если в двух словах то там происходит следующее.
Это джоба.
В нее подается:
-нейтив массив всех клеток.
-позиции членов отряда игрока
-дальность поля зрения.
Далее в рапаралеленном виде мы итерируемся через весь массив клеток.
Для каждой клетки смотрим попадает ли он в дистанцию видимости хотя-бы одного тиммейта.
Если да, то начинаем while.
в нем последовательно прибавляем к позиции текущей клетки нормализованный вектор в сторону клетки ближайшего наблюдателя. Ну типо прямую линию чертим.
Каждый раз у нас получается дробная координата, округляем ее до целочисленной.
Смотрим что находится на клетке по этим целочисленным координатам.
Если там стена то break;
Если нет то continue;
И так пока не дойдем до клетки где наблюдатель стоит. Тогда говорим что изначальная клетка является видимой.
Ну и потом еще кусочек кода не влезший на скрин, который определяет прозрачность тумана войны.
Да, не самая продуманная система, конечно это все намного умнее можно сделать.
Можно сходу решить проблему о которой мы говорим, например этот while проводить 4 раза для каждой клетки и чертить линию не из центра клетки а из каждого из углов, но это, собственно в 4 раза стоимость и повысит. Ну блин, или не 4. Там 3, или 2, хз, сколько там углов на самом деле имеет смысл проверять.
Лучше наверно вообще все это переписать и сделать нормально по существующим алгоритмам. Пока просто что-то сил нет на это)
64 Кб, 667x627>>834866
То есть все тайлы которые попадают в дистанцию поля зрения каждый "ход", проверяют могут ли они увидеть игрока?
То есть все тайлы которые попадают в дистанцию поля зрения каждый "ход", проверяют могут ли они увидеть игрока?
80 Кб, 1127x821Я освоил вершины некромантии, голова, ноги, руки? Пффф.. я левитирую свою полутушу силой воли.
Вот ещё про FOV, кстати.
Вот ещё про FOV, кстати.
86 Кб, 1463x557>>834964
>>834966
Ну да.
Но если мы посмотрим на таймлайн, то весь фов это вот этот маленький зеленый кусочек, так что такой размен производительно
сти на простоту меня устраивал.
Хорошо, пожелание понятно, в следующем апдейте постараюсь переписать фов и убрать все эти артефакты. Просто мне как-то раньше это не бросалось в глаза и не казалось таким важным
>>834969
Это ты как сделал?
>>834966
Ну да.
Но если мы посмотрим на таймлайн, то весь фов это вот этот маленький зеленый кусочек, так что такой размен производительно
сти на простоту меня устраивал.
Хорошо, пожелание понятно, в следующем апдейте постараюсь переписать фов и убрать все эти артефакты. Просто мне как-то раньше это не бросалось в глаза и не казалось таким важным
>>834969
Это ты как сделал?
>>834989
Хз, взорвал пару бомбуэ, пропал инпут, кроме кликов по менюшкам. Альт+Ф4, потом запустил и продолжил левитирующим торсом, который однако мог подбирать предметыи перемещаться. При этом в обрубки так же превратились все неписи.
Потом начался вообще ад вплоть до того что в новой игре и арене спавнился торсом игрок и все неписи, однако инпута не было.
Видимо я как-то хитро скорраптил сейв-файл и он у тебя как-то странно работает, раз влияет даже на новую игру новым персонажем после перезапуска.
Где сейвы лежат я не нашёл, а так бы сохранил тебе.
Хз, взорвал пару бомбуэ, пропал инпут, кроме кликов по менюшкам. Альт+Ф4, потом запустил и продолжил левитирующим торсом, который однако мог подбирать предметыи перемещаться. При этом в обрубки так же превратились все неписи.
Потом начался вообще ад вплоть до того что в новой игре и арене спавнился торсом игрок и все неписи, однако инпута не было.
Видимо я как-то хитро скорраптил сейв-файл и он у тебя как-то странно работает, раз влияет даже на новую игру новым персонажем после перезапуска.
Где сейвы лежат я не нашёл, а так бы сохранил тебе.
>>835002
Кажется я встречал такое. Иногда при отрыве конечностей взрывом происходит нулл референс из за чего все системы останавливаются.
Непонятно только почему это на сейв влияет.
Буду чинить.
Кажется я встречал такое. Иногда при отрыве конечностей взрывом происходит нулл референс из за чего все системы останавливаются.
Непонятно только почему это на сейв влияет.
Буду чинить.
>>835009
Если что, сейвы и лог лежат в AppData\LocalLow\DefaultCompany\Katabasis
Но мне они пока вряд ли помогут в решении этой проблемы.
Если что, сейвы и лог лежат в AppData\LocalLow\DefaultCompany\Katabasis
Но мне они пока вряд ли помогут в решении этой проблемы.
17 Кб, 528x507>>835002
>>834762
До конца не разобрался в чем было дело, но баг со взрывами и потерей инпута починил.
Сделал меню доступных действий.
https://vk.com/katabasys?w=wall-201941833_98%2Fall
>>834762
До конца не разобрался в чем было дело, но баг со взрывами и потерей инпута починил.
Сделал меню доступных действий.
https://vk.com/katabasys?w=wall-201941833_98%2Fall
Я разобрался почему люди на слабых пекарнях лагают.
Дело тут в рендеринге спрайтов, а в этой теме я не силен, так что только приблизительно понимаю как все устроено.
Во-первых, я объединил все спрайты в одну текстуру, атлас. Загружать одну текстуру и рендерить ее кусочек дешевле чем рендерить много-много маленьких.
Во-вторых, рендеринг проходит эффективно когда объекты с одинаковыми свойствами объединены в батчи. Рендерится как-бы целый батч за раз, вне зависимости от того сколько там объектов.
Я немного поменял код, так что на всех объектах теперь один и тот-же материал и шейдер, а не копия. На самом деле, получилось довольно глупо, я думал, это все уже и так сделано.
По идее, таким образом все объекты должны объединиться в один большой батч и разом отрендериться, но оказалось что все не совсем так.
Количество батчей снизилось с >3500 до <100, что уже очень хороший результат. Но почему это все не группируется в один батч я понять затрудняюсь.
На первой гифке последовательно показаны все запросы на отрисовку один кадр - один батч.
Как видно, батчи группируются в какой-то зависимости от положения объекта по вертикали, а следовательно от расстояния до камеры.(если вы помните в 3д пространстве у меня вся карта лесенкой выстроена)
Если попробовать отключить "лесенку" и спавнить все предметы на одном расстоянии от камеры, то количество батчей снизится еще раза в два с половиной, и получится гифка 2.
Но вот тут уже точно мои полномочия все. Почему и на этом этапе объекты собираются в разные батчи я не понимаю.
Юнитевский дебагер подписывает под каждым батчем почему тот не сгруппирован с предыдущим, но там значится какая-то ересь про batch index, который какого-то хрена отличается, про то что это связано с системами частиц а я не использую никаких частиц епту бля про то, что какой-то там Node не поддерживается. Чего несет...
Наверно это останется одной из многочисленных нерешенных загадок юнити.
Меня в принципе все и так устраивает, и лагать по идее больше не должно.
Дело тут в рендеринге спрайтов, а в этой теме я не силен, так что только приблизительно понимаю как все устроено.
Во-первых, я объединил все спрайты в одну текстуру, атлас. Загружать одну текстуру и рендерить ее кусочек дешевле чем рендерить много-много маленьких.
Во-вторых, рендеринг проходит эффективно когда объекты с одинаковыми свойствами объединены в батчи. Рендерится как-бы целый батч за раз, вне зависимости от того сколько там объектов.
Я немного поменял код, так что на всех объектах теперь один и тот-же материал и шейдер, а не копия. На самом деле, получилось довольно глупо, я думал, это все уже и так сделано.
По идее, таким образом все объекты должны объединиться в один большой батч и разом отрендериться, но оказалось что все не совсем так.
Количество батчей снизилось с >3500 до <100, что уже очень хороший результат. Но почему это все не группируется в один батч я понять затрудняюсь.
На первой гифке последовательно показаны все запросы на отрисовку один кадр - один батч.
Как видно, батчи группируются в какой-то зависимости от положения объекта по вертикали, а следовательно от расстояния до камеры.(если вы помните в 3д пространстве у меня вся карта лесенкой выстроена)
Если попробовать отключить "лесенку" и спавнить все предметы на одном расстоянии от камеры, то количество батчей снизится еще раза в два с половиной, и получится гифка 2.
Но вот тут уже точно мои полномочия все. Почему и на этом этапе объекты собираются в разные батчи я не понимаю.
Юнитевский дебагер подписывает под каждым батчем почему тот не сгруппирован с предыдущим, но там значится какая-то ересь про batch index, который какого-то хрена отличается, про то что это связано с системами частиц а я не использую никаких частиц епту бля про то, что какой-то там Node не поддерживается. Чего несет...
Наверно это останется одной из многочисленных нерешенных загадок юнити.
Меня в принципе все и так устраивает, и лагать по идее больше не должно.
1,3 Мб, 906x881>>835590
Вот твой Гоша ёбаный!
Который день уже тут срешь а у тебя все на завтра операция.
Иди работу найди, чмо.
Вот твой Гоша ёбаный!
Который день уже тут срешь а у тебя все на завтра операция.
Иди работу найди, чмо.
9,8 Мб, 906x881>>834969
>>835615
Так же был переписан фов. Разобрался таки как это работает.
Можете качать.
https://vk.com/katabasys?w=wall-201941833_99%2Fall
>>835615
Так же был переписан фов. Разобрался таки как это работает.
Можете качать.
https://vk.com/katabasys?w=wall-201941833_99%2Fall
>>835617
это солевой наркоман, уже несколько лет по двачу срет
это солевой наркоман, уже несколько лет по двачу срет
>>835643
Это пиздец..........
Короче, оказывается дело не в рендеринге.
Дело в вертикальной синхронизации.
Это штука которая ограничивает фремрейт, чтобы он не поднимался выше количества фпс, которое может выдать монитор (60 фпс обычно) и не тратил лишние ресурсы.
Почему-то на слабых компах иногда этот алгоритм урезает фпс до 10-20, хотя комп способен выдавать намного больше.
Эта хуета возникает рандомно. В некоторых билдах она есть, а в некоторых ее нет. Когда я проделал всю эту операцию с рендерингом, описанную выше, все почему-то было норм, и я решил что все починил. Но стоило мне собрать билд еще раз, но с переписанным фовом все вернулось обратно к 20 фпс. Чтобы это проверить нужно бежать в соседнюю комнату и запускать некро-комп, чего я тогда конечно же не сделал.
Причем я, не менял там абсолютно ничего что бы могло на это повлиять. Теперь у меня на руках есть два билда которые по факту ничем не отличаются, но при этом один выдает 60 фпс, если очень хотите можете скачать его тут: https://drive.google.com/file/d/1v5ljPFRo1mt4EmZiEhglvzgS_7Cwc3aB/view?usp=sharing а другой 20 фпс.
При этом в юнити есть целых два способа вообще эту синхронизацию полностью отключить. Так вот, они оба не работают. Просто не работают. VSync никуда не девается, как сжирал 40 фпс, так и сжирает.
На юнити-форуме есть тред где сидит десяток человек с такой-же проблемой и разраб который отвечает "ой, ну я хз что вам делать, попробуйте юнити обновить"
Я уже 4 часа сижу в попытках что-то с этим сделать.
Как же я задолбался...
Это пиздец..........
Короче, оказывается дело не в рендеринге.
Дело в вертикальной синхронизации.
Это штука которая ограничивает фремрейт, чтобы он не поднимался выше количества фпс, которое может выдать монитор (60 фпс обычно) и не тратил лишние ресурсы.
Почему-то на слабых компах иногда этот алгоритм урезает фпс до 10-20, хотя комп способен выдавать намного больше.
Эта хуета возникает рандомно. В некоторых билдах она есть, а в некоторых ее нет. Когда я проделал всю эту операцию с рендерингом, описанную выше, все почему-то было норм, и я решил что все починил. Но стоило мне собрать билд еще раз, но с переписанным фовом все вернулось обратно к 20 фпс. Чтобы это проверить нужно бежать в соседнюю комнату и запускать некро-комп, чего я тогда конечно же не сделал.
Причем я, не менял там абсолютно ничего что бы могло на это повлиять. Теперь у меня на руках есть два билда которые по факту ничем не отличаются, но при этом один выдает 60 фпс, если очень хотите можете скачать его тут: https://drive.google.com/file/d/1v5ljPFRo1mt4EmZiEhglvzgS_7Cwc3aB/view?usp=sharing а другой 20 фпс.
При этом в юнити есть целых два способа вообще эту синхронизацию полностью отключить. Так вот, они оба не работают. Просто не работают. VSync никуда не девается, как сжирал 40 фпс, так и сжирает.
На юнити-форуме есть тред где сидит десяток человек с такой-же проблемой и разраб который отвечает "ой, ну я хз что вам делать, попробуйте юнити обновить"
Я уже 4 часа сижу в попытках что-то с этим сделать.
Как же я задолбался...
>>835716
Как же я ору с рандомных юнитибагов. Скромный инди-стартап, где совсем не хватило денег на QA и толковых кодеров.
Как же я ору с рандомных юнитибагов. Скромный инди-стартап, где совсем не хватило денег на QA и толковых кодеров.
123 Кб, 1024x576>>835786
Ой, ну да, что-то я опять хуйни наделал.
Ну ничего через десять лет наберусь опыта и пойму как надо правильно кодить...
>Кнопка "отключить VSync"
>Нажал
>VSync не отключился
Ой, ну да, что-то я опять хуйни наделал.
Ну ничего через десять лет наберусь опыта и пойму как надо правильно кодить...
>>835793
Нет, на передней панели системного блока.
Ну ты мне сейчас будешь доказывать что в юнити багов нет?То что ты 10 лет работаешь на юнити это очень круто, я ни сколько не хочу покуситься на твою славу. Но если ты и правда провел там столько времени, то сам все должен понимать...
Нет, на передней панели системного блока.
Ну ты мне сейчас будешь доказывать что в юнити багов нет?То что ты 10 лет работаешь на юнити это очень круто, я ни сколько не хочу покуситься на твою славу. Но если ты и правда провел там столько времени, то сам все должен понимать...
>>835798
Не пытаюсь тебя убедить что в юнити нет багов. Только спросил что там за кнопка, так как позабавило описание проблемы "нажал кнопку и всинк не отключился". В ответ ты проткнулся. Что тогда тебе посоветовать, перекатись на движок без багов где кнопки отключения всинков работают.
Не пытаюсь тебя убедить что в юнити нет багов. Только спросил что там за кнопка, так как позабавило описание проблемы "нажал кнопку и всинк не отключился". В ответ ты проткнулся. Что тогда тебе посоветовать, перекатись на движок без багов где кнопки отключения всинков работают.
4,8 Мб, webm,1280x720, 0:19
>>834688
Gone to plaid?
>>835068
Планируешь контент для взрослых?
>>835716
Ещё раз рассмотри моё предложение освоить Godot и перекатиться на него. У него таких проблем нет (но есть другие, так что слишком скучно не будет).
>>835799
Вот-вот, и я о том же, в Godot эта кнопка работает, неоднократно нажимал и так, и эдак - работает.
>я использую клетчатый рейкаст
>В клетчатой геометрии придется довольствоваться клетчатыми рейкастерами.
Gone to plaid?
>>835068
>Это позволяет играть используя только мышку, а второй рукой делать что-нибудь более полезное.
Планируешь контент для взрослых?
>>835716
>в юнити
Ещё раз рассмотри моё предложение освоить Godot и перекатиться на него. У него таких проблем нет (но есть другие, так что слишком скучно не будет).
>>835799
>перекатись на движок без багов где кнопки отключения всинков работают
Вот-вот, и я о том же, в Godot эта кнопка работает, неоднократно нажимал и так, и эдак - работает.
Протестировал версии 0.50, 0.51, 0.52, 0.52-E.
Ну шо я могу сказать? С FPS всё в порядке.
Интерфейс говно (ожидаемо, игра ведь на юнити).
Управление говно, чего только зум камеры стоит.
Геймплей скучный, непродуманный. Можно ходить, бить рандомных существ, жрать их трупы, собирать палки, спускаться дальше. Но прогресса вообще не ощущается (дошёл до третьего этажа в 0.52 версии), уровни пустые и однообразные, мобы все одинаковые и постоянно пытаются толпой игрока забить. Непонятно вообще, зачем я сюда пришёл, что мне делать?
Короче, ты зря заботишься об оптимизации, потому что игры-то нет, есть только бесполезная расчленёнка. Можно набить инвентарь частями тел, костями, и т.п., но применения этому, видимо, нет. Инвентарь глючит и порой полностью блокируется всё управление из-за него. Если это лучшее состояние, в котором была эта игра (я читал, ты почти с нуля всё переделывал), то ты явно свернул куда-то не туда.
Игра должна развлекать, давать интересные, решаемые и посильные задачи, или хотя бы интересные игрушки и возможности их применения. Также юзабилити порой важнее геймплея, т.е. простенький геймплей с хорошим юзабилити намного лучше сложного с плохим. Ты явно это всё не продумал, начиная делать игру, заботясь о каких-то малозначимых деталях.
Но ничего страшного, это распространённая проблема в инди геймдеве. К тому же это моё субъективное мнение. С рогаликами я слабо знаком, но те, что я проходил, были достаточно увлекательными и продуманными.
Ну шо я могу сказать? С FPS всё в порядке.
Интерфейс говно (ожидаемо, игра ведь на юнити).
Управление говно, чего только зум камеры стоит.
Геймплей скучный, непродуманный. Можно ходить, бить рандомных существ, жрать их трупы, собирать палки, спускаться дальше. Но прогресса вообще не ощущается (дошёл до третьего этажа в 0.52 версии), уровни пустые и однообразные, мобы все одинаковые и постоянно пытаются толпой игрока забить. Непонятно вообще, зачем я сюда пришёл, что мне делать?
Короче, ты зря заботишься об оптимизации, потому что игры-то нет, есть только бесполезная расчленёнка. Можно набить инвентарь частями тел, костями, и т.п., но применения этому, видимо, нет. Инвентарь глючит и порой полностью блокируется всё управление из-за него. Если это лучшее состояние, в котором была эта игра (я читал, ты почти с нуля всё переделывал), то ты явно свернул куда-то не туда.
Игра должна развлекать, давать интересные, решаемые и посильные задачи, или хотя бы интересные игрушки и возможности их применения. Также юзабилити порой важнее геймплея, т.е. простенький геймплей с хорошим юзабилити намного лучше сложного с плохим. Ты явно это всё не продумал, начиная делать игру, заботясь о каких-то малозначимых деталях.
Но ничего страшного, это распространённая проблема в инди геймдеве. К тому же это моё субъективное мнение. С рогаликами я слабо знаком, но те, что я проходил, были достаточно увлекательными и продуманными.
>>835801
Ещё боёвка максимально унылая. Да, я вижу, что есть повреждение индивидуальных частей тела, но какой в этом смысл, если нельзя прицельно бить? Сейчас боёвка - тупое закликивание насмерть, и кликов нужно много. Отступать бесполезно, манёвров никаких нет. Может, на более глубоких уровнях с зельями и продвинутым оружием становится повеселее, но до тех уровней нужно ещё дожить, а меня с самого начала скелеты и крысы толпой гасят, в чём фан начинать с нуля каждую минуту?
Мне вот интересно, играешь ли ты в свою игру с точки зрения обычного игрока? Т.е. не с топовым шмотом, не с читами для дебага. А просто, запустил игру, нажал "новая игра" и играешь. Весело, нет? Вот должно быть весело ещё на стадии прототипа, прежде чем наполнять игру контентом и оптимизировать системы.
Прости, если слишком резко. У тебя есть потенциал, но ты фокусируешься не на том, что нужно.
Ещё боёвка максимально унылая. Да, я вижу, что есть повреждение индивидуальных частей тела, но какой в этом смысл, если нельзя прицельно бить? Сейчас боёвка - тупое закликивание насмерть, и кликов нужно много. Отступать бесполезно, манёвров никаких нет. Может, на более глубоких уровнях с зельями и продвинутым оружием становится повеселее, но до тех уровней нужно ещё дожить, а меня с самого начала скелеты и крысы толпой гасят, в чём фан начинать с нуля каждую минуту?
Мне вот интересно, играешь ли ты в свою игру с точки зрения обычного игрока? Т.е. не с топовым шмотом, не с читами для дебага. А просто, запустил игру, нажал "новая игра" и играешь. Весело, нет? Вот должно быть весело ещё на стадии прототипа, прежде чем наполнять игру контентом и оптимизировать системы.
Прости, если слишком резко. У тебя есть потенциал, но ты фокусируешься не на том, что нужно.
>>835801
>>835802
О, ну вот, конструктивная критика.
У большинства то да, просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин. Собственно в чем трагедия последних 10 постов.
Печально. Я вообще не особо представляю чем хороший интерфейс отличается от плохого, но это решаемо. Зум такой из за пиксель-перфект камеры, которая настоящего пиксель перфекта не дает а только обеспечивает выравнивание пикселей по сетке. По хорошему ее вообще можно убрать, просто я не замечал что зум это такая проблема.
Можешь указать какой элемент интерфейса наиболее всратый?
Ну да, есть такое. У меня есть статы, которые можно поднимать за очки опыта, но это пока не особо много чего дает. Вообще мне хотелось бы сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование и навыки самого играющего. Но это сложно.
Ну есть такие игры, например Exanima какая-нибудь. Где ты в начале, собственно, не особо сильнее чем в конце. Но Exanima это не рогалик, за счет чего там интерес именно в исследовании сделанных вручную лабиринтов. Увы, чтобы тот-же принцип был применим к процедурным мирам они должны быть не менее проработанные чем таковые в Dwarf Fortress, иначе, да, чувствуется однообразие...
Справедливости ради, лично я нахожу довольно веселым кидаться во врагов разными предметами, но возможность это делать действительно не так часто предоставляется.
В целом, по моей задумке тактика должна быть такая. Встречаешь толпу мобов, кидаешь в них всякие вещи пока они подходят. Потом пытаешься вынести одного, пока не отрубишь ему руку или не убьешь. В случае убийства, вероятно что у всех остальных упадет мораль и они разбегутся. Скелетов это не касается, у них нет морали. Мб мне не стоило ставить их на ранние уровни
Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты. Хотя блин, чтобы это узнать нужно открывать описание моба. Не удивительно что многие кто начинает играть сходу бегут всех месить Ну и еще они ходят группами, если ты напал на нейтрального члена группы то на тебя сагрятся, только другие ее члены, остальным группам будет все равно, даже если они того-же вида.
Да, когда новые билды тестирую каждый раз прохожу ее. Не могу сказать что мне самому это доставляет какое-то неописуемое удовольствие. Местами меня ваншотали на глубоких уровнях и жопа трескалась, но в целом это не было невозможно... Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Но игрокам конечно виднее весело это или нет. Очевидно что надо что-то менять.
Увы, это так.
Вот насчет локализованного урона. Предположим, я сделаю возможность прицельно бить по частям тела.
Тогда это будет подталкивать игрока к тому чтобы каждый удар делать прицельным в голову и для этого нажимать дополнительные кнопки. Примерно такая-же проблема в Dwarf fortress. Там можно прицельно бить по частям тела но никто этого не делает, так как это дополнительные взаимодействия с интерфейсом.
Может сделать эти прицельные удары очень эффективными, но платными, за стамину или типа того...
Да не, не резко. Когда меня критикуют это намного полезнее чем когда просто говорят что я молодец, но в игру не играют.
>>835802
О, ну вот, конструктивная критика.
>С фпс все в порядке
У большинства то да, просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин. Собственно в чем трагедия последних 10 постов.
>Интерфейс и управление говно
Печально. Я вообще не особо представляю чем хороший интерфейс отличается от плохого, но это решаемо. Зум такой из за пиксель-перфект камеры, которая настоящего пиксель перфекта не дает а только обеспечивает выравнивание пикселей по сетке. По хорошему ее вообще можно убрать, просто я не замечал что зум это такая проблема.
Можешь указать какой элемент интерфейса наиболее всратый?
>Прогресса не ощущается.
Ну да, есть такое. У меня есть статы, которые можно поднимать за очки опыта, но это пока не особо много чего дает. Вообще мне хотелось бы сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование и навыки самого играющего. Но это сложно.
Ну есть такие игры, например Exanima какая-нибудь. Где ты в начале, собственно, не особо сильнее чем в конце. Но Exanima это не рогалик, за счет чего там интерес именно в исследовании сделанных вручную лабиринтов. Увы, чтобы тот-же принцип был применим к процедурным мирам они должны быть не менее проработанные чем таковые в Dwarf Fortress, иначе, да, чувствуется однообразие...
>унылая боевка
Справедливости ради, лично я нахожу довольно веселым кидаться во врагов разными предметами, но возможность это делать действительно не так часто предоставляется.
В целом, по моей задумке тактика должна быть такая. Встречаешь толпу мобов, кидаешь в них всякие вещи пока они подходят. Потом пытаешься вынести одного, пока не отрубишь ему руку или не убьешь. В случае убийства, вероятно что у всех остальных упадет мораль и они разбегутся. Скелетов это не касается, у них нет морали. Мб мне не стоило ставить их на ранние уровни
Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты. Хотя блин, чтобы это узнать нужно открывать описание моба. Не удивительно что многие кто начинает играть сходу бегут всех месить Ну и еще они ходят группами, если ты напал на нейтрального члена группы то на тебя сагрятся, только другие ее члены, остальным группам будет все равно, даже если они того-же вида.
>играешь ли ты в свою игру с точки зрения обычного игрока?
Да, когда новые билды тестирую каждый раз прохожу ее. Не могу сказать что мне самому это доставляет какое-то неописуемое удовольствие. Местами меня ваншотали на глубоких уровнях и жопа трескалась, но в целом это не было невозможно... Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Но игрокам конечно виднее весело это или нет. Очевидно что надо что-то менять.
>Вот должно быть весело ещё на стадии прототипа, прежде чем наполнять игру контентом и оптимизировать системы.
Увы, это так.
Вот насчет локализованного урона. Предположим, я сделаю возможность прицельно бить по частям тела.
Тогда это будет подталкивать игрока к тому чтобы каждый удар делать прицельным в голову и для этого нажимать дополнительные кнопки. Примерно такая-же проблема в Dwarf fortress. Там можно прицельно бить по частям тела но никто этого не делает, так как это дополнительные взаимодействия с интерфейсом.
Может сделать эти прицельные удары очень эффективными, но платными, за стамину или типа того...
>Слишком резко
Да не, не резко. Когда меня критикуют это намного полезнее чем когда просто говорят что я молодец, но в игру не играют.
>>835801
>>835802
О, ну вот, конструктивная критика.
У большинства то да, просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин. Собственно в чем трагедия последних 10 постов.
Печально. Я вообще не особо представляю чем хороший интерфейс отличается от плохого, но это решаемо. Зум такой из за пиксель-перфект камеры, которая настоящего пиксель перфекта не дает а только обеспечивает выравнивание пикселей по сетке. По хорошему ее вообще можно убрать, просто я не замечал что зум это такая проблема.
Можешь указать какой элемент интерфейса наиболее всратый?
Ну да, есть такое. У меня есть статы, которые можно поднимать за очки опыта, но это пока не особо много чего дает. Вообще мне хотелось бы сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование и навыки самого играющего. Но это сложно.
Ну есть такие игры, например Exanima какая-нибудь. Где ты в начале, собственно, не особо сильнее чем в конце. Но Exanima это не рогалик, за счет чего там интерес именно в исследовании сделанных вручную лабиринтов. Увы, чтобы тот-же принцип был применим к процедурным мирам они должны быть не менее проработанные чем таковые в Dwarf Fortress, иначе, да, чувствуется однообразие...
Справедливости ради, лично я нахожу довольно веселым кидаться во врагов разными предметами, но возможность это делать действительно не так часто предоставляется.
В целом, по моей задумке тактика должна быть такая. Встречаешь толпу мобов, кидаешь в них всякие вещи пока они подходят. Потом пытаешься вынести одного, пока не отрубишь ему руку или не убьешь. В случае убийства, вероятно что у всех остальных упадет мораль и они разбегутся. Скелетов это не касается, у них нет морали. Мб мне не стоило ставить их на ранние уровни
Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты. Хотя блин, чтобы это узнать нужно открывать описание моба. Не удивительно что многие кто начинает играть сходу бегут всех месить Ну и еще они ходят группами, если ты напал на нейтрального члена группы то на тебя сагрятся, только другие ее члены, остальным группам будет все равно, даже если они того-же вида.
Да, когда новые билды тестирую каждый раз прохожу ее. Не могу сказать что мне самому это доставляет какое-то неописуемое удовольствие. Местами меня ваншотали на глубоких уровнях и жопа трескалась, но в целом это не было невозможно... Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Но игрокам конечно виднее весело это или нет. Очевидно что надо что-то менять.
Увы, это так.
Вот насчет локализованного урона. Предположим, я сделаю возможность прицельно бить по частям тела.
Тогда это будет подталкивать игрока к тому чтобы каждый удар делать прицельным в голову и для этого нажимать дополнительные кнопки. Примерно такая-же проблема в Dwarf fortress. Там можно прицельно бить по частям тела но никто этого не делает, так как это дополнительные взаимодействия с интерфейсом.
Может сделать эти прицельные удары очень эффективными, но платными, за стамину или типа того...
Да не, не резко. Когда меня критикуют это намного полезнее чем когда просто говорят что я молодец, но в игру не играют.
>>835802
О, ну вот, конструктивная критика.
>С фпс все в порядке
У большинства то да, просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин. Собственно в чем трагедия последних 10 постов.
>Интерфейс и управление говно
Печально. Я вообще не особо представляю чем хороший интерфейс отличается от плохого, но это решаемо. Зум такой из за пиксель-перфект камеры, которая настоящего пиксель перфекта не дает а только обеспечивает выравнивание пикселей по сетке. По хорошему ее вообще можно убрать, просто я не замечал что зум это такая проблема.
Можешь указать какой элемент интерфейса наиболее всратый?
>Прогресса не ощущается.
Ну да, есть такое. У меня есть статы, которые можно поднимать за очки опыта, но это пока не особо много чего дает. Вообще мне хотелось бы сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование и навыки самого играющего. Но это сложно.
Ну есть такие игры, например Exanima какая-нибудь. Где ты в начале, собственно, не особо сильнее чем в конце. Но Exanima это не рогалик, за счет чего там интерес именно в исследовании сделанных вручную лабиринтов. Увы, чтобы тот-же принцип был применим к процедурным мирам они должны быть не менее проработанные чем таковые в Dwarf Fortress, иначе, да, чувствуется однообразие...
>унылая боевка
Справедливости ради, лично я нахожу довольно веселым кидаться во врагов разными предметами, но возможность это делать действительно не так часто предоставляется.
В целом, по моей задумке тактика должна быть такая. Встречаешь толпу мобов, кидаешь в них всякие вещи пока они подходят. Потом пытаешься вынести одного, пока не отрубишь ему руку или не убьешь. В случае убийства, вероятно что у всех остальных упадет мораль и они разбегутся. Скелетов это не касается, у них нет морали. Мб мне не стоило ставить их на ранние уровни
Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты. Хотя блин, чтобы это узнать нужно открывать описание моба. Не удивительно что многие кто начинает играть сходу бегут всех месить Ну и еще они ходят группами, если ты напал на нейтрального члена группы то на тебя сагрятся, только другие ее члены, остальным группам будет все равно, даже если они того-же вида.
>играешь ли ты в свою игру с точки зрения обычного игрока?
Да, когда новые билды тестирую каждый раз прохожу ее. Не могу сказать что мне самому это доставляет какое-то неописуемое удовольствие. Местами меня ваншотали на глубоких уровнях и жопа трескалась, но в целом это не было невозможно... Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Но игрокам конечно виднее весело это или нет. Очевидно что надо что-то менять.
>Вот должно быть весело ещё на стадии прототипа, прежде чем наполнять игру контентом и оптимизировать системы.
Увы, это так.
Вот насчет локализованного урона. Предположим, я сделаю возможность прицельно бить по частям тела.
Тогда это будет подталкивать игрока к тому чтобы каждый удар делать прицельным в голову и для этого нажимать дополнительные кнопки. Примерно такая-же проблема в Dwarf fortress. Там можно прицельно бить по частям тела но никто этого не делает, так как это дополнительные взаимодействия с интерфейсом.
Может сделать эти прицельные удары очень эффективными, но платными, за стамину или типа того...
>Слишком резко
Да не, не резко. Когда меня критикуют это намного полезнее чем когда просто говорят что я молодец, но в игру не играют.
251 Кб, 864x432>>835821
Вряд ли это связано с вертикальной синхронизацией.
Проверь, что у тебя с аудио. Я видел, как некоторые игры на юнити очень страшно тормозят на определённых компьютерах. Может быть, проблема с декодированием звуков? Играл без звука, но видел в ctrl+F10 график аудио, в каком формате ты сохраняешь аудиофайлы? Алсо, проблемы кодировки могут объяснить нестабильность билдов, если юнити каждый раз заново кодирует все ресурсы. Т.е. вполне возможно, что аудиочип давится неправильным форматом и это замедляет игру, т.к. ЦПУ ждёт ответа от чипа.
Хорошо бы получить графики и другую информацию из Диспетчера Задач от анона со слабым компьютером, и посмотреть, как именно игра влияет на нагрузку его компьютера. Сама игра может даже не знать, чем именно она нагружает компьютер, если проблема в ОС, драйверах или железе.
Тому анону с тормозами следовало бы попробовать обновить все драйвера на железо, либо поставить более старые версии драйверов (если ноутбук - восстановить родные версии). Иногда проблема в драйвере сильно влияет на работу игры, даже если железо нормально справилось бы с нагрузкой.
Скажу банальность, но хорошим интерфейсом удобно и приятно пользоваться, так что тебе прям хочется нажимать все эти кнопочки просто так, а плохой интерфейс отталкивает неудобством или неприятностями, и ты пользуешься им только потому что у тебя нет других альтернатив (альтернатива - установить другую программу или игру, или посетить другой сайт).
Проблема разработки хорошего интерфейса в том, что ты, как разработчик, уже привык к своему интерфейсу, каким бы он ни был. Т.е. может быть сложно представить первый опыт постороннего человека. Для этого и существуют тестировщики, альфа/бета доступ и т.д. Подобное встречается даже в больших проектах вроде Блендера, который долго ругали за UI, созданный программистами для программистов, а не для 3D дизайнеров.
В главном меню и меню паузы мелкие кнопки, сидящие в центре ПУСТОТЫ, что мешало сделать их крупнее? Ещё и чёрными (?) буквами по коричневому, контраста нет = читабельность низкая. Аналогично нет контраста у кнопок в правом верхнем углу, они сливаются друг с другом в коричневую кашу, несмотря на размер.
Интерфейс инвентаря - аналогичная коричневая масса. В инвентаре хотелось бы иметь хоткеи (быстро надеть/снять/выкинуть/съесть и т.п.), чтобы не таскать предметы через весь экран по одному. Помни, инвентарь - чисто утилитарная система, и от неё нужен быстрый и чёткий отклик как в каком-нибудь Экселе. Иконки предметов, кстати, желательно подсветить рамочкой по их главному типу/назначению: еда, оружие, мусор и т.п. Раз уж у тебя 100500 иконок костей, сделай так, чтобы была чётко видна разница между костью и чем-то полезным. Алсо сортировка инвентаря по типу/ценности/весу/количеству, в таких играх очень полезна (но только по нажатию кнопки).
Для мобилок, если ты всё-таки метишь на них (судя по огромным кнопкам и ячейкам), во-первых, лучше будет не перетаскивать предметы, а кликать на предмет и затем на место назначения, как сделано в майнкрафте; во-вторых, лучше разделить инвентарь и меню с параметрами персонажа.
Также параметры предмета я бы выводил во всплывающем меню... Это вроде как чаще встречается в играх, чем фиксированный элемент окна. Плюс такой плавающей подсказки в том, что она может быть разных размеров. Ещё в подсказке можно отображать разницу между текущим оружием/бронёй и той, на которую ты навёл курсор/нажал. Да, это так-то дополнительная фича, но очень полезная...
Баги с интерфейсом, которые я встретил:
- кнопка с номером версии перекрывает кнопку арены (покажи хоть, как это меню должно выглядеть);
- меню паузы не сбрасывает своё состояние после закрытия эскейпом, т.е. если открыл справку и нажал на эскейп, в следующий раз справка уже открыта;
- инвентарь позволяет перетащить кость на голову, после чего игра глючит и управление полностью теряется, приходится нажимать alt+F4;
- предмет "череп" (иногда?) рендерится на ячейку выше той, в которой реально находится, это сбивает с толку.
Не знаю, может, это только я так криво управляюсь с непривычки... Ну, я бы сделал такую фичу: если пользователь нажал на стену (или невидимую клетку), то персонаж подходит максимально близко к этой стене (на крайнюю видимую клетку); если пользователь нажал на врага на расстоянии, а у персонажа только оружие ближнего боя, он пытается сначала подойти к врагу. Если ничего не путаю, видел такое управление в одном мобильном рогалике. Также я бы объединил движение и удар на одной кнопке, чтобы удар осуществлялся по занятой агрессивным врагом клетке, а движение - по незанятой или занятой нейтральным/дружественным мобом. В чём смысл пытаться месить руками воздух? Для метательных предметов должен быть отдельный способ, имхо (в тех рогаликах, что я играл, нужно было ткнуть по оружию/зелью/предмету, а затем ткнуть по клетке; в остальных случаях атака автоматически по клетке, на которую пытаешься пойти, если она занята). Можно добавить ctrl+клик для особых случаев (ударить друга и т.п.).
Ещё в рогаликах полезна кнопка "ничего не делать", у тебя я её не нашёл. Типа подождать, пока враг пройдёт мимо (если у него малое поле зрения или ты невидим).
Хреновая камера в таком случае. У меня получается либо несколько клеток на весь экран, либо всё слишком мелкое. При этом отдалять можно очень далеко (что противоречит концепции "пиксель-перфект"), но комфортно настроить не получается. Скорее всего ты зря на камеру вину перекладываешь, просто нужно сделать меньше шаг приближения (вроде 0.1). Или дублировать управление на клаву, для тех, у кого колёсико мыши сбоит (у меня оно неточно крутится, но сглаживание в большинстве приложений позволяет не париться). А ты точно считаешь КЛИКИ колёсика, а не прокрутку строк? У меня в настройках вроде бы 5 строк за один "клик".
Вот я именно об этом и говорил. Сейчас на первых уровнях куча крыс, котов и скелетов, да кучки мусора... Как через это проходить-то, если они толпой окружают. Обычно сложность увеличивается постепенно, давая освоиться и найти нормальный шмот, прежде чем на тебя накинется толпа бандитов. Алсо, крысы неожиданно сильны в сравнении со скелетами, обычно крысы в таких играх самый слабый моб. Серьёзно, несколько тычков в одну крысу, пока две другие грызут насмерть?
Параметрическая генерация. На первом уровне отдельные слабые крысы, на следующем к крысам добавляются хомячки-берсерки, и т.д. Если генерация состоит из комнат, комнаты имеют типы, типы можно фильтровать и т.д. Всё это можно настроить, чтобы не вываливать кучу рандома с порога, а плавно погружать игрока в мир игры. Посмотри Shattered Pixel Dungeon, потом сравни со своей игрой. Да, там нет расчленёнки, но зато игра увлекает и затягивает, а ещё там даже сюжет есть.
Котов я не трогал и они меня не трогали. Но толпа крыс была в узком проходе... Нет, не так. В чём смысл играть, если ни с кем не драться? Что ты ожидал от игрока, высыпав перед ним кучу крыс?
Делай плавное погружение, чтоб сложность росла равномерно с возможностями. Алсо, первый уровень может быть "туториальным", т.е. даже не процедурным, но с кучей подсказок и пояснений. Плюс галочка "пропустить обучение" при начале игры, как это обычно бывает.
В классический Fallout играл? Там вроде хорошо сделано, хотя не помню точно, как. Попадание в голову - высокий урон, но низкий шанс. В тело - урон низкий, но шанс высокий. В ноги - может сбить с ног. В руки - может выбить оружие. Быстрый удар - чистый рандом. Учитывая износ разных частей тела в твоей игре, локальные удары должны добавить больше тактики и интереса, а тупое закликивание делает бессмысленным износ частей тела.
В 3D экшен-шутере можно ПРИЦЕЛЬНО отрубить руку топором, а в пошаговом 2D рогалике нельзя?
>просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин
Вряд ли это связано с вертикальной синхронизацией.
Проверь, что у тебя с аудио. Я видел, как некоторые игры на юнити очень страшно тормозят на определённых компьютерах. Может быть, проблема с декодированием звуков? Играл без звука, но видел в ctrl+F10 график аудио, в каком формате ты сохраняешь аудиофайлы? Алсо, проблемы кодировки могут объяснить нестабильность билдов, если юнити каждый раз заново кодирует все ресурсы. Т.е. вполне возможно, что аудиочип давится неправильным форматом и это замедляет игру, т.к. ЦПУ ждёт ответа от чипа.
Хорошо бы получить графики и другую информацию из Диспетчера Задач от анона со слабым компьютером, и посмотреть, как именно игра влияет на нагрузку его компьютера. Сама игра может даже не знать, чем именно она нагружает компьютер, если проблема в ОС, драйверах или железе.
Тому анону с тормозами следовало бы попробовать обновить все драйвера на железо, либо поставить более старые версии драйверов (если ноутбук - восстановить родные версии). Иногда проблема в драйвере сильно влияет на работу игры, даже если железо нормально справилось бы с нагрузкой.
>чем хороший интерфейс отличается от плохого
Скажу банальность, но хорошим интерфейсом удобно и приятно пользоваться, так что тебе прям хочется нажимать все эти кнопочки просто так, а плохой интерфейс отталкивает неудобством или неприятностями, и ты пользуешься им только потому что у тебя нет других альтернатив (альтернатива - установить другую программу или игру, или посетить другой сайт).
Проблема разработки хорошего интерфейса в том, что ты, как разработчик, уже привык к своему интерфейсу, каким бы он ни был. Т.е. может быть сложно представить первый опыт постороннего человека. Для этого и существуют тестировщики, альфа/бета доступ и т.д. Подобное встречается даже в больших проектах вроде Блендера, который долго ругали за UI, созданный программистами для программистов, а не для 3D дизайнеров.
>какой элемент интерфейса наиболее всратый?
В главном меню и меню паузы мелкие кнопки, сидящие в центре ПУСТОТЫ, что мешало сделать их крупнее? Ещё и чёрными (?) буквами по коричневому, контраста нет = читабельность низкая. Аналогично нет контраста у кнопок в правом верхнем углу, они сливаются друг с другом в коричневую кашу, несмотря на размер.
Интерфейс инвентаря - аналогичная коричневая масса. В инвентаре хотелось бы иметь хоткеи (быстро надеть/снять/выкинуть/съесть и т.п.), чтобы не таскать предметы через весь экран по одному. Помни, инвентарь - чисто утилитарная система, и от неё нужен быстрый и чёткий отклик как в каком-нибудь Экселе. Иконки предметов, кстати, желательно подсветить рамочкой по их главному типу/назначению: еда, оружие, мусор и т.п. Раз уж у тебя 100500 иконок костей, сделай так, чтобы была чётко видна разница между костью и чем-то полезным. Алсо сортировка инвентаря по типу/ценности/весу/количеству, в таких играх очень полезна (но только по нажатию кнопки).
Для мобилок, если ты всё-таки метишь на них (судя по огромным кнопкам и ячейкам), во-первых, лучше будет не перетаскивать предметы, а кликать на предмет и затем на место назначения, как сделано в майнкрафте; во-вторых, лучше разделить инвентарь и меню с параметрами персонажа.
Также параметры предмета я бы выводил во всплывающем меню... Это вроде как чаще встречается в играх, чем фиксированный элемент окна. Плюс такой плавающей подсказки в том, что она может быть разных размеров. Ещё в подсказке можно отображать разницу между текущим оружием/бронёй и той, на которую ты навёл курсор/нажал. Да, это так-то дополнительная фича, но очень полезная...
Баги с интерфейсом, которые я встретил:
- кнопка с номером версии перекрывает кнопку арены (покажи хоть, как это меню должно выглядеть);
- меню паузы не сбрасывает своё состояние после закрытия эскейпом, т.е. если открыл справку и нажал на эскейп, в следующий раз справка уже открыта;
- инвентарь позволяет перетащить кость на голову, после чего игра глючит и управление полностью теряется, приходится нажимать alt+F4;
- предмет "череп" (иногда?) рендерится на ячейку выше той, в которой реально находится, это сбивает с толку.
Не знаю, может, это только я так криво управляюсь с непривычки... Ну, я бы сделал такую фичу: если пользователь нажал на стену (или невидимую клетку), то персонаж подходит максимально близко к этой стене (на крайнюю видимую клетку); если пользователь нажал на врага на расстоянии, а у персонажа только оружие ближнего боя, он пытается сначала подойти к врагу. Если ничего не путаю, видел такое управление в одном мобильном рогалике. Также я бы объединил движение и удар на одной кнопке, чтобы удар осуществлялся по занятой агрессивным врагом клетке, а движение - по незанятой или занятой нейтральным/дружественным мобом. В чём смысл пытаться месить руками воздух? Для метательных предметов должен быть отдельный способ, имхо (в тех рогаликах, что я играл, нужно было ткнуть по оружию/зелью/предмету, а затем ткнуть по клетке; в остальных случаях атака автоматически по клетке, на которую пытаешься пойти, если она занята). Можно добавить ctrl+клик для особых случаев (ударить друга и т.п.).
Ещё в рогаликах полезна кнопка "ничего не делать", у тебя я её не нашёл. Типа подождать, пока враг пройдёт мимо (если у него малое поле зрения или ты невидим).
>Зум такой из за пиксель-перфект камеры
Хреновая камера в таком случае. У меня получается либо несколько клеток на весь экран, либо всё слишком мелкое. При этом отдалять можно очень далеко (что противоречит концепции "пиксель-перфект"), но комфортно настроить не получается. Скорее всего ты зря на камеру вину перекладываешь, просто нужно сделать меньше шаг приближения (вроде 0.1). Или дублировать управление на клаву, для тех, у кого колёсико мыши сбоит (у меня оно неточно крутится, но сглаживание в большинстве приложений позволяет не париться). А ты точно считаешь КЛИКИ колёсика, а не прокрутку строк? У меня в настройках вроде бы 5 строк за один "клик".
>сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование
Вот я именно об этом и говорил. Сейчас на первых уровнях куча крыс, котов и скелетов, да кучки мусора... Как через это проходить-то, если они толпой окружают. Обычно сложность увеличивается постепенно, давая освоиться и найти нормальный шмот, прежде чем на тебя накинется толпа бандитов. Алсо, крысы неожиданно сильны в сравнении со скелетами, обычно крысы в таких играх самый слабый моб. Серьёзно, несколько тычков в одну крысу, пока две другие грызут насмерть?
>применим к процедурным мирам
Параметрическая генерация. На первом уровне отдельные слабые крысы, на следующем к крысам добавляются хомячки-берсерки, и т.д. Если генерация состоит из комнат, комнаты имеют типы, типы можно фильтровать и т.д. Всё это можно настроить, чтобы не вываливать кучу рандома с порога, а плавно погружать игрока в мир игры. Посмотри Shattered Pixel Dungeon, потом сравни со своей игрой. Да, там нет расчленёнки, но зато игра увлекает и затягивает, а ещё там даже сюжет есть.
>Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты.
Котов я не трогал и они меня не трогали. Но толпа крыс была в узком проходе... Нет, не так. В чём смысл играть, если ни с кем не драться? Что ты ожидал от игрока, высыпав перед ним кучу крыс?
>Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Делай плавное погружение, чтоб сложность росла равномерно с возможностями. Алсо, первый уровень может быть "туториальным", т.е. даже не процедурным, но с кучей подсказок и пояснений. Плюс галочка "пропустить обучение" при начале игры, как это обычно бывает.
>Вот насчет локализованного урона...
В классический Fallout играл? Там вроде хорошо сделано, хотя не помню точно, как. Попадание в голову - высокий урон, но низкий шанс. В тело - урон низкий, но шанс высокий. В ноги - может сбить с ног. В руки - может выбить оружие. Быстрый удар - чистый рандом. Учитывая износ разных частей тела в твоей игре, локальные удары должны добавить больше тактики и интереса, а тупое закликивание делает бессмысленным износ частей тела.
В 3D экшен-шутере можно ПРИЦЕЛЬНО отрубить руку топором, а в пошаговом 2D рогалике нельзя?
251 Кб, 864x432>>835821
Вряд ли это связано с вертикальной синхронизацией.
Проверь, что у тебя с аудио. Я видел, как некоторые игры на юнити очень страшно тормозят на определённых компьютерах. Может быть, проблема с декодированием звуков? Играл без звука, но видел в ctrl+F10 график аудио, в каком формате ты сохраняешь аудиофайлы? Алсо, проблемы кодировки могут объяснить нестабильность билдов, если юнити каждый раз заново кодирует все ресурсы. Т.е. вполне возможно, что аудиочип давится неправильным форматом и это замедляет игру, т.к. ЦПУ ждёт ответа от чипа.
Хорошо бы получить графики и другую информацию из Диспетчера Задач от анона со слабым компьютером, и посмотреть, как именно игра влияет на нагрузку его компьютера. Сама игра может даже не знать, чем именно она нагружает компьютер, если проблема в ОС, драйверах или железе.
Тому анону с тормозами следовало бы попробовать обновить все драйвера на железо, либо поставить более старые версии драйверов (если ноутбук - восстановить родные версии). Иногда проблема в драйвере сильно влияет на работу игры, даже если железо нормально справилось бы с нагрузкой.
Скажу банальность, но хорошим интерфейсом удобно и приятно пользоваться, так что тебе прям хочется нажимать все эти кнопочки просто так, а плохой интерфейс отталкивает неудобством или неприятностями, и ты пользуешься им только потому что у тебя нет других альтернатив (альтернатива - установить другую программу или игру, или посетить другой сайт).
Проблема разработки хорошего интерфейса в том, что ты, как разработчик, уже привык к своему интерфейсу, каким бы он ни был. Т.е. может быть сложно представить первый опыт постороннего человека. Для этого и существуют тестировщики, альфа/бета доступ и т.д. Подобное встречается даже в больших проектах вроде Блендера, который долго ругали за UI, созданный программистами для программистов, а не для 3D дизайнеров.
В главном меню и меню паузы мелкие кнопки, сидящие в центре ПУСТОТЫ, что мешало сделать их крупнее? Ещё и чёрными (?) буквами по коричневому, контраста нет = читабельность низкая. Аналогично нет контраста у кнопок в правом верхнем углу, они сливаются друг с другом в коричневую кашу, несмотря на размер.
Интерфейс инвентаря - аналогичная коричневая масса. В инвентаре хотелось бы иметь хоткеи (быстро надеть/снять/выкинуть/съесть и т.п.), чтобы не таскать предметы через весь экран по одному. Помни, инвентарь - чисто утилитарная система, и от неё нужен быстрый и чёткий отклик как в каком-нибудь Экселе. Иконки предметов, кстати, желательно подсветить рамочкой по их главному типу/назначению: еда, оружие, мусор и т.п. Раз уж у тебя 100500 иконок костей, сделай так, чтобы была чётко видна разница между костью и чем-то полезным. Алсо сортировка инвентаря по типу/ценности/весу/количеству, в таких играх очень полезна (но только по нажатию кнопки).
Для мобилок, если ты всё-таки метишь на них (судя по огромным кнопкам и ячейкам), во-первых, лучше будет не перетаскивать предметы, а кликать на предмет и затем на место назначения, как сделано в майнкрафте; во-вторых, лучше разделить инвентарь и меню с параметрами персонажа.
Также параметры предмета я бы выводил во всплывающем меню... Это вроде как чаще встречается в играх, чем фиксированный элемент окна. Плюс такой плавающей подсказки в том, что она может быть разных размеров. Ещё в подсказке можно отображать разницу между текущим оружием/бронёй и той, на которую ты навёл курсор/нажал. Да, это так-то дополнительная фича, но очень полезная...
Баги с интерфейсом, которые я встретил:
- кнопка с номером версии перекрывает кнопку арены (покажи хоть, как это меню должно выглядеть);
- меню паузы не сбрасывает своё состояние после закрытия эскейпом, т.е. если открыл справку и нажал на эскейп, в следующий раз справка уже открыта;
- инвентарь позволяет перетащить кость на голову, после чего игра глючит и управление полностью теряется, приходится нажимать alt+F4;
- предмет "череп" (иногда?) рендерится на ячейку выше той, в которой реально находится, это сбивает с толку.
Не знаю, может, это только я так криво управляюсь с непривычки... Ну, я бы сделал такую фичу: если пользователь нажал на стену (или невидимую клетку), то персонаж подходит максимально близко к этой стене (на крайнюю видимую клетку); если пользователь нажал на врага на расстоянии, а у персонажа только оружие ближнего боя, он пытается сначала подойти к врагу. Если ничего не путаю, видел такое управление в одном мобильном рогалике. Также я бы объединил движение и удар на одной кнопке, чтобы удар осуществлялся по занятой агрессивным врагом клетке, а движение - по незанятой или занятой нейтральным/дружественным мобом. В чём смысл пытаться месить руками воздух? Для метательных предметов должен быть отдельный способ, имхо (в тех рогаликах, что я играл, нужно было ткнуть по оружию/зелью/предмету, а затем ткнуть по клетке; в остальных случаях атака автоматически по клетке, на которую пытаешься пойти, если она занята). Можно добавить ctrl+клик для особых случаев (ударить друга и т.п.).
Ещё в рогаликах полезна кнопка "ничего не делать", у тебя я её не нашёл. Типа подождать, пока враг пройдёт мимо (если у него малое поле зрения или ты невидим).
Хреновая камера в таком случае. У меня получается либо несколько клеток на весь экран, либо всё слишком мелкое. При этом отдалять можно очень далеко (что противоречит концепции "пиксель-перфект"), но комфортно настроить не получается. Скорее всего ты зря на камеру вину перекладываешь, просто нужно сделать меньше шаг приближения (вроде 0.1). Или дублировать управление на клаву, для тех, у кого колёсико мыши сбоит (у меня оно неточно крутится, но сглаживание в большинстве приложений позволяет не париться). А ты точно считаешь КЛИКИ колёсика, а не прокрутку строк? У меня в настройках вроде бы 5 строк за один "клик".
Вот я именно об этом и говорил. Сейчас на первых уровнях куча крыс, котов и скелетов, да кучки мусора... Как через это проходить-то, если они толпой окружают. Обычно сложность увеличивается постепенно, давая освоиться и найти нормальный шмот, прежде чем на тебя накинется толпа бандитов. Алсо, крысы неожиданно сильны в сравнении со скелетами, обычно крысы в таких играх самый слабый моб. Серьёзно, несколько тычков в одну крысу, пока две другие грызут насмерть?
Параметрическая генерация. На первом уровне отдельные слабые крысы, на следующем к крысам добавляются хомячки-берсерки, и т.д. Если генерация состоит из комнат, комнаты имеют типы, типы можно фильтровать и т.д. Всё это можно настроить, чтобы не вываливать кучу рандома с порога, а плавно погружать игрока в мир игры. Посмотри Shattered Pixel Dungeon, потом сравни со своей игрой. Да, там нет расчленёнки, но зато игра увлекает и затягивает, а ещё там даже сюжет есть.
Котов я не трогал и они меня не трогали. Но толпа крыс была в узком проходе... Нет, не так. В чём смысл играть, если ни с кем не драться? Что ты ожидал от игрока, высыпав перед ним кучу крыс?
Делай плавное погружение, чтоб сложность росла равномерно с возможностями. Алсо, первый уровень может быть "туториальным", т.е. даже не процедурным, но с кучей подсказок и пояснений. Плюс галочка "пропустить обучение" при начале игры, как это обычно бывает.
В классический Fallout играл? Там вроде хорошо сделано, хотя не помню точно, как. Попадание в голову - высокий урон, но низкий шанс. В тело - урон низкий, но шанс высокий. В ноги - может сбить с ног. В руки - может выбить оружие. Быстрый удар - чистый рандом. Учитывая износ разных частей тела в твоей игре, локальные удары должны добавить больше тактики и интереса, а тупое закликивание делает бессмысленным износ частей тела.
В 3D экшен-шутере можно ПРИЦЕЛЬНО отрубить руку топором, а в пошаговом 2D рогалике нельзя?
>просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин
Вряд ли это связано с вертикальной синхронизацией.
Проверь, что у тебя с аудио. Я видел, как некоторые игры на юнити очень страшно тормозят на определённых компьютерах. Может быть, проблема с декодированием звуков? Играл без звука, но видел в ctrl+F10 график аудио, в каком формате ты сохраняешь аудиофайлы? Алсо, проблемы кодировки могут объяснить нестабильность билдов, если юнити каждый раз заново кодирует все ресурсы. Т.е. вполне возможно, что аудиочип давится неправильным форматом и это замедляет игру, т.к. ЦПУ ждёт ответа от чипа.
Хорошо бы получить графики и другую информацию из Диспетчера Задач от анона со слабым компьютером, и посмотреть, как именно игра влияет на нагрузку его компьютера. Сама игра может даже не знать, чем именно она нагружает компьютер, если проблема в ОС, драйверах или железе.
Тому анону с тормозами следовало бы попробовать обновить все драйвера на железо, либо поставить более старые версии драйверов (если ноутбук - восстановить родные версии). Иногда проблема в драйвере сильно влияет на работу игры, даже если железо нормально справилось бы с нагрузкой.
>чем хороший интерфейс отличается от плохого
Скажу банальность, но хорошим интерфейсом удобно и приятно пользоваться, так что тебе прям хочется нажимать все эти кнопочки просто так, а плохой интерфейс отталкивает неудобством или неприятностями, и ты пользуешься им только потому что у тебя нет других альтернатив (альтернатива - установить другую программу или игру, или посетить другой сайт).
Проблема разработки хорошего интерфейса в том, что ты, как разработчик, уже привык к своему интерфейсу, каким бы он ни был. Т.е. может быть сложно представить первый опыт постороннего человека. Для этого и существуют тестировщики, альфа/бета доступ и т.д. Подобное встречается даже в больших проектах вроде Блендера, который долго ругали за UI, созданный программистами для программистов, а не для 3D дизайнеров.
>какой элемент интерфейса наиболее всратый?
В главном меню и меню паузы мелкие кнопки, сидящие в центре ПУСТОТЫ, что мешало сделать их крупнее? Ещё и чёрными (?) буквами по коричневому, контраста нет = читабельность низкая. Аналогично нет контраста у кнопок в правом верхнем углу, они сливаются друг с другом в коричневую кашу, несмотря на размер.
Интерфейс инвентаря - аналогичная коричневая масса. В инвентаре хотелось бы иметь хоткеи (быстро надеть/снять/выкинуть/съесть и т.п.), чтобы не таскать предметы через весь экран по одному. Помни, инвентарь - чисто утилитарная система, и от неё нужен быстрый и чёткий отклик как в каком-нибудь Экселе. Иконки предметов, кстати, желательно подсветить рамочкой по их главному типу/назначению: еда, оружие, мусор и т.п. Раз уж у тебя 100500 иконок костей, сделай так, чтобы была чётко видна разница между костью и чем-то полезным. Алсо сортировка инвентаря по типу/ценности/весу/количеству, в таких играх очень полезна (но только по нажатию кнопки).
Для мобилок, если ты всё-таки метишь на них (судя по огромным кнопкам и ячейкам), во-первых, лучше будет не перетаскивать предметы, а кликать на предмет и затем на место назначения, как сделано в майнкрафте; во-вторых, лучше разделить инвентарь и меню с параметрами персонажа.
Также параметры предмета я бы выводил во всплывающем меню... Это вроде как чаще встречается в играх, чем фиксированный элемент окна. Плюс такой плавающей подсказки в том, что она может быть разных размеров. Ещё в подсказке можно отображать разницу между текущим оружием/бронёй и той, на которую ты навёл курсор/нажал. Да, это так-то дополнительная фича, но очень полезная...
Баги с интерфейсом, которые я встретил:
- кнопка с номером версии перекрывает кнопку арены (покажи хоть, как это меню должно выглядеть);
- меню паузы не сбрасывает своё состояние после закрытия эскейпом, т.е. если открыл справку и нажал на эскейп, в следующий раз справка уже открыта;
- инвентарь позволяет перетащить кость на голову, после чего игра глючит и управление полностью теряется, приходится нажимать alt+F4;
- предмет "череп" (иногда?) рендерится на ячейку выше той, в которой реально находится, это сбивает с толку.
Не знаю, может, это только я так криво управляюсь с непривычки... Ну, я бы сделал такую фичу: если пользователь нажал на стену (или невидимую клетку), то персонаж подходит максимально близко к этой стене (на крайнюю видимую клетку); если пользователь нажал на врага на расстоянии, а у персонажа только оружие ближнего боя, он пытается сначала подойти к врагу. Если ничего не путаю, видел такое управление в одном мобильном рогалике. Также я бы объединил движение и удар на одной кнопке, чтобы удар осуществлялся по занятой агрессивным врагом клетке, а движение - по незанятой или занятой нейтральным/дружественным мобом. В чём смысл пытаться месить руками воздух? Для метательных предметов должен быть отдельный способ, имхо (в тех рогаликах, что я играл, нужно было ткнуть по оружию/зелью/предмету, а затем ткнуть по клетке; в остальных случаях атака автоматически по клетке, на которую пытаешься пойти, если она занята). Можно добавить ctrl+клик для особых случаев (ударить друга и т.п.).
Ещё в рогаликах полезна кнопка "ничего не делать", у тебя я её не нашёл. Типа подождать, пока враг пройдёт мимо (если у него малое поле зрения или ты невидим).
>Зум такой из за пиксель-перфект камеры
Хреновая камера в таком случае. У меня получается либо несколько клеток на весь экран, либо всё слишком мелкое. При этом отдалять можно очень далеко (что противоречит концепции "пиксель-перфект"), но комфортно настроить не получается. Скорее всего ты зря на камеру вину перекладываешь, просто нужно сделать меньше шаг приближения (вроде 0.1). Или дублировать управление на клаву, для тех, у кого колёсико мыши сбоит (у меня оно неточно крутится, но сглаживание в большинстве приложений позволяет не париться). А ты точно считаешь КЛИКИ колёсика, а не прокрутку строк? У меня в настройках вроде бы 5 строк за один "клик".
>сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование
Вот я именно об этом и говорил. Сейчас на первых уровнях куча крыс, котов и скелетов, да кучки мусора... Как через это проходить-то, если они толпой окружают. Обычно сложность увеличивается постепенно, давая освоиться и найти нормальный шмот, прежде чем на тебя накинется толпа бандитов. Алсо, крысы неожиданно сильны в сравнении со скелетами, обычно крысы в таких играх самый слабый моб. Серьёзно, несколько тычков в одну крысу, пока две другие грызут насмерть?
>применим к процедурным мирам
Параметрическая генерация. На первом уровне отдельные слабые крысы, на следующем к крысам добавляются хомячки-берсерки, и т.д. Если генерация состоит из комнат, комнаты имеют типы, типы можно фильтровать и т.д. Всё это можно настроить, чтобы не вываливать кучу рандома с порога, а плавно погружать игрока в мир игры. Посмотри Shattered Pixel Dungeon, потом сравни со своей игрой. Да, там нет расчленёнки, но зато игра увлекает и затягивает, а ещё там даже сюжет есть.
>Кстати, многие мобы вообще нейтральные, как те же самые крысы и пещерные коты.
Котов я не трогал и они меня не трогали. Но толпа крыс была в узком проходе... Нет, не так. В чём смысл играть, если ни с кем не драться? Что ты ожидал от игрока, высыпав перед ним кучу крыс?
>Просто там много моментов, которые мне ясны, как разрабу, но могут быть абсолютно неочевидны игроку а чтобы сделать их более понятными мне не хватает опыта.
Делай плавное погружение, чтоб сложность росла равномерно с возможностями. Алсо, первый уровень может быть "туториальным", т.е. даже не процедурным, но с кучей подсказок и пояснений. Плюс галочка "пропустить обучение" при начале игры, как это обычно бывает.
>Вот насчет локализованного урона...
В классический Fallout играл? Там вроде хорошо сделано, хотя не помню точно, как. Попадание в голову - высокий урон, но низкий шанс. В тело - урон низкий, но шанс высокий. В ноги - может сбить с ног. В руки - может выбить оружие. Быстрый удар - чистый рандом. Учитывая износ разных частей тела в твоей игре, локальные удары должны добавить больше тактики и интереса, а тупое закликивание делает бессмысленным износ частей тела.
В 3D экшен-шутере можно ПРИЦЕЛЬНО отрубить руку топором, а в пошаговом 2D рогалике нельзя?
>>835821
Ещё момент по юзабилити и инвентарю. Сделай так, чтобы можно было просмотреть точный список предметов под ногами и выбрать для поднятия один конкретный. Пускай это занимает как и сейчас по одному ходу на предмет (для баланса), но, по крайней мере, не нужно будет собирать целую груду костей в инвентарь, чтобы убедиться, что под ними ничего полезного нет.
Также очень хорошо было бы иметь всплывающую подсказку о содержимом клетки поля игры при наведении на него мышью. Тайлы, спрайты - это всё замечательно, но хотелось бы иметь точную информацию, чтобы не делать лишних движений, копаясь в мусоре. Это добавило бы в геймплей больше пошаговой тактики, избавив от необходимости бегать и копаться в мусоре как в каком-нибудь экшене. Хотя, предполагаю, твоя задумка может быть в другом и подсказка может мешать...
Можно ли есть мясо из инвентаря я не понял, но если нет, такую фичу нужно сделать. Я поддерживаю быстрое поедание врагов прямо с земли хоткеем, но не бросать же куски мяса на землю, когда нужно поесть?
С камерой хотелось бы не только приближение и отдаление, но и сдвиг камеры в сторону мыши, если мышь близко к краю экрана; когда мышь возвращается к персонажу, камера центруется на персонаже. Это позволило бы иметь широкий обзор при комфортном разрешении тайлов. Все движения камеры должны быть сглаженными.
Мелкие одинаковые предметы типа костей в инвентаре я бы складывал в стопки... Не знаю, что ты планируешь в плане ограничений, но выглядит абсурдно, когда у тебя в рюкзаке маленькая кучка тонких ребёр и из-за этого не помещается кусочек мяса. Да, признаюсь, мне хочется собирать вообще всё, что может быть сколько-нибудь ценным, и я даже надеялся, что у тебя там есть какой-нибудь крафт из костей... Привычка из игр, в которых почти нет бесполезных предметов - всё или почти всё является ингредиентом крафта или может быть продано торговцу (кости хоть сколько-то да должны стоить, это же удобрение, ингредиент для клея или основа оружия; хотя в играх цена обычно обусловлена балансом - доступностью предмета для игрока).
Ещё момент по юзабилити и инвентарю. Сделай так, чтобы можно было просмотреть точный список предметов под ногами и выбрать для поднятия один конкретный. Пускай это занимает как и сейчас по одному ходу на предмет (для баланса), но, по крайней мере, не нужно будет собирать целую груду костей в инвентарь, чтобы убедиться, что под ними ничего полезного нет.
Также очень хорошо было бы иметь всплывающую подсказку о содержимом клетки поля игры при наведении на него мышью. Тайлы, спрайты - это всё замечательно, но хотелось бы иметь точную информацию, чтобы не делать лишних движений, копаясь в мусоре. Это добавило бы в геймплей больше пошаговой тактики, избавив от необходимости бегать и копаться в мусоре как в каком-нибудь экшене. Хотя, предполагаю, твоя задумка может быть в другом и подсказка может мешать...
Можно ли есть мясо из инвентаря я не понял, но если нет, такую фичу нужно сделать. Я поддерживаю быстрое поедание врагов прямо с земли хоткеем, но не бросать же куски мяса на землю, когда нужно поесть?
С камерой хотелось бы не только приближение и отдаление, но и сдвиг камеры в сторону мыши, если мышь близко к краю экрана; когда мышь возвращается к персонажу, камера центруется на персонаже. Это позволило бы иметь широкий обзор при комфортном разрешении тайлов. Все движения камеры должны быть сглаженными.
Мелкие одинаковые предметы типа костей в инвентаре я бы складывал в стопки... Не знаю, что ты планируешь в плане ограничений, но выглядит абсурдно, когда у тебя в рюкзаке маленькая кучка тонких ребёр и из-за этого не помещается кусочек мяса. Да, признаюсь, мне хочется собирать вообще всё, что может быть сколько-нибудь ценным, и я даже надеялся, что у тебя там есть какой-нибудь крафт из костей... Привычка из игр, в которых почти нет бесполезных предметов - всё или почти всё является ингредиентом крафта или может быть продано торговцу (кости хоть сколько-то да должны стоить, это же удобрение, ингредиент для клея или основа оружия; хотя в играх цена обычно обусловлена балансом - доступностью предмета для игрока).
>>835821
Ещё момент по юзабилити и инвентарю. Сделай так, чтобы можно было просмотреть точный список предметов под ногами и выбрать для поднятия один конкретный. Пускай это занимает как и сейчас по одному ходу на предмет (для баланса), но, по крайней мере, не нужно будет собирать целую груду костей в инвентарь, чтобы убедиться, что под ними ничего полезного нет.
Также очень хорошо было бы иметь всплывающую подсказку о содержимом клетки поля игры при наведении на него мышью. Тайлы, спрайты - это всё замечательно, но хотелось бы иметь точную информацию, чтобы не делать лишних движений, копаясь в мусоре. Это добавило бы в геймплей больше пошаговой тактики, избавив от необходимости бегать и копаться в мусоре как в каком-нибудь экшене. Хотя, предполагаю, твоя задумка может быть в другом и подсказка может мешать...
Можно ли есть мясо из инвентаря я не понял, но если нет, такую фичу нужно сделать. Я поддерживаю быстрое поедание врагов прямо с земли хоткеем, но не бросать же куски мяса на землю, когда нужно поесть?
С камерой хотелось бы не только приближение и отдаление, но и сдвиг камеры в сторону мыши, если мышь близко к краю экрана; когда мышь возвращается к персонажу, камера центруется на персонаже. Это позволило бы иметь широкий обзор при комфортном разрешении тайлов. Все движения камеры должны быть сглаженными.
Мелкие одинаковые предметы типа костей в инвентаре я бы складывал в стопки... Не знаю, что ты планируешь в плане ограничений, но выглядит абсурдно, когда у тебя в рюкзаке маленькая кучка тонких ребёр и из-за этого не помещается кусочек мяса. Да, признаюсь, мне хочется собирать вообще всё, что может быть сколько-нибудь ценным, и я даже надеялся, что у тебя там есть какой-нибудь крафт из костей... Привычка из игр, в которых почти нет бесполезных предметов - всё или почти всё является ингредиентом крафта или может быть продано торговцу (кости хоть сколько-то да должны стоить, это же удобрение, ингредиент для клея или основа оружия; хотя в играх цена обычно обусловлена балансом - доступностью предмета для игрока).
Ещё момент по юзабилити и инвентарю. Сделай так, чтобы можно было просмотреть точный список предметов под ногами и выбрать для поднятия один конкретный. Пускай это занимает как и сейчас по одному ходу на предмет (для баланса), но, по крайней мере, не нужно будет собирать целую груду костей в инвентарь, чтобы убедиться, что под ними ничего полезного нет.
Также очень хорошо было бы иметь всплывающую подсказку о содержимом клетки поля игры при наведении на него мышью. Тайлы, спрайты - это всё замечательно, но хотелось бы иметь точную информацию, чтобы не делать лишних движений, копаясь в мусоре. Это добавило бы в геймплей больше пошаговой тактики, избавив от необходимости бегать и копаться в мусоре как в каком-нибудь экшене. Хотя, предполагаю, твоя задумка может быть в другом и подсказка может мешать...
Можно ли есть мясо из инвентаря я не понял, но если нет, такую фичу нужно сделать. Я поддерживаю быстрое поедание врагов прямо с земли хоткеем, но не бросать же куски мяса на землю, когда нужно поесть?
С камерой хотелось бы не только приближение и отдаление, но и сдвиг камеры в сторону мыши, если мышь близко к краю экрана; когда мышь возвращается к персонажу, камера центруется на персонаже. Это позволило бы иметь широкий обзор при комфортном разрешении тайлов. Все движения камеры должны быть сглаженными.
Мелкие одинаковые предметы типа костей в инвентаре я бы складывал в стопки... Не знаю, что ты планируешь в плане ограничений, но выглядит абсурдно, когда у тебя в рюкзаке маленькая кучка тонких ребёр и из-за этого не помещается кусочек мяса. Да, признаюсь, мне хочется собирать вообще всё, что может быть сколько-нибудь ценным, и я даже надеялся, что у тебя там есть какой-нибудь крафт из костей... Привычка из игр, в которых почти нет бесполезных предметов - всё или почти всё является ингредиентом крафта или может быть продано торговцу (кости хоть сколько-то да должны стоить, это же удобрение, ингредиент для клея или основа оружия; хотя в играх цена обычно обусловлена балансом - доступностью предмета для игрока).
Вот ещё хороший пример рогалика (скорее рогулайт) от русскоговорящего разработчика:
https://play.google.com/store/apps/details?id=thirty.six.dev.underworld
Я даже задонатил ему через эту игру.
Потом, правда, надоело, но начало затягивает.
https://play.google.com/store/apps/details?id=thirty.six.dev.underworld
Я даже задонатил ему через эту игру.
Потом, правда, надоело, но начало затягивает.
>>835877
Какой развернутый фидбек, шикарно.
Возможно это на самом деле не висюнк а что-то другое, просто профайлер отображает его так. Во всяком случае передо мной то что на первом скрине. А в диспетчере задач то что на втором.
Как видно, гпу загружен под завязку.
Так же 700мб оперативки, это, как мне кажется, тоже абсолютли нот окей. Но тут скорее всего виновата моя база данных с предметами, я примерно понимаю как это починить.
А аудиофайлов в игре нет.
Некоторое время назад я сам добрался до компа на котором игра лагает так же как у анонов, так что могу сам проводить тесты. Попробую новые драйвера накатить.
Мне кажется, он у тебя как-то некорректно отображается. Во всяком случае кнопка версии точно не должна перекрывать арену. Смотри третий скрин.
По поводу подсказок в инвентаре - годная идея, попробую запилить.
Подождать 10 тиков можно если вызвать радиальное меню долгим нажатием правой кнопки на клетке где стоишь.
На счет пиксель-перфект камеры, мне кажется тут тоже что-то с разрешением не то. У меня где-то 4 или 5 разных режимов увеличения, большинством из них вроде вполне можно пользоваться...
Вот на счет крыс не согласен)
По-моему прикольно что они тебя избить могут. Просто не нужно самому на них нападать, если их большая пачка, а у тебя оружия нет. Периодически на них коты охотятся, вот тогда можно выждать момент и напасть.
Настоящие проблемы баланса начинаются в районе 5 уровня, когда и из угла выходит негр с молотом и просто двумя точными ударами в незащищенную голову тебя сносит.
Давно хотел его сделать. Типа как отдельную локацию в начле, куда можно зайти а можно мимо пройти.
В фоллауты, увы, ни в один не играл, но этот зеленый экран прицеливания видел. Нужно изучить эту тему.
>>835880
Содержимое клетки можно посмотреть нажав О и листая предметы, но да, это не самый удобный способ.
К сожалению, мясо из инвентаря есть нельзя.
Я бы вообще хотел как-нибудь ограничить механику переноса еды в инвентаре, так как это подталкивает игрока к гринду всего мяса и всех грибов на уровне. Хз как это сделать. Может переносимый вес ввести?
Но для другой еды безусловно хоткей нужен.
На счет того, почему ничего не стакается. По моей первоначальной задумке, я хотел чтобы каждый предмет был уникальный, чтобы у него были свои статы и так далее.
Сейчас например у всех предметов своя прочность и на любом предмете может какой-то эффект висеть.
По-моему классно, не хотелось бы от этого отказываться. Лучше наверно решить эту проблему как-то по-другому. Вот в пиксель данжене была куча всяких предметов, по типу семян, и для них был специальный предмет-мешок. где могли только они лежать и не занимать инвентарь. Вот что-то подобное нужно.
Какой развернутый фидбек, шикарно.
>про оптимизацию
Возможно это на самом деле не висюнк а что-то другое, просто профайлер отображает его так. Во всяком случае передо мной то что на первом скрине. А в диспетчере задач то что на втором.
Как видно, гпу загружен под завязку.
Так же 700мб оперативки, это, как мне кажется, тоже абсолютли нот окей. Но тут скорее всего виновата моя база данных с предметами, я примерно понимаю как это починить.
А аудиофайлов в игре нет.
Некоторое время назад я сам добрался до компа на котором игра лагает так же как у анонов, так что могу сам проводить тесты. Попробую новые драйвера накатить.
>про интерфейс
Мне кажется, он у тебя как-то некорректно отображается. Во всяком случае кнопка версии точно не должна перекрывать арену. Смотри третий скрин.
По поводу подсказок в инвентаре - годная идея, попробую запилить.
Подождать 10 тиков можно если вызвать радиальное меню долгим нажатием правой кнопки на клетке где стоишь.
На счет пиксель-перфект камеры, мне кажется тут тоже что-то с разрешением не то. У меня где-то 4 или 5 разных режимов увеличения, большинством из них вроде вполне можно пользоваться...
>про прогрессию
Вот на счет крыс не согласен)
По-моему прикольно что они тебя избить могут. Просто не нужно самому на них нападать, если их большая пачка, а у тебя оружия нет. Периодически на них коты охотятся, вот тогда можно выждать момент и напасть.
Настоящие проблемы баланса начинаются в районе 5 уровня, когда и из угла выходит негр с молотом и просто двумя точными ударами в незащищенную голову тебя сносит.
>туториальный уровень
Давно хотел его сделать. Типа как отдельную локацию в начле, куда можно зайти а можно мимо пройти.
В фоллауты, увы, ни в один не играл, но этот зеленый экран прицеливания видел. Нужно изучить эту тему.
>>835880
Содержимое клетки можно посмотреть нажав О и листая предметы, но да, это не самый удобный способ.
К сожалению, мясо из инвентаря есть нельзя.
Я бы вообще хотел как-нибудь ограничить механику переноса еды в инвентаре, так как это подталкивает игрока к гринду всего мяса и всех грибов на уровне. Хз как это сделать. Может переносимый вес ввести?
Но для другой еды безусловно хоткей нужен.
На счет того, почему ничего не стакается. По моей первоначальной задумке, я хотел чтобы каждый предмет был уникальный, чтобы у него были свои статы и так далее.
Сейчас например у всех предметов своя прочность и на любом предмете может какой-то эффект висеть.
По-моему классно, не хотелось бы от этого отказываться. Лучше наверно решить эту проблему как-то по-другому. Вот в пиксель данжене была куча всяких предметов, по типу семян, и для них был специальный предмет-мешок. где могли только они лежать и не занимать инвентарь. Вот что-то подобное нужно.
>>835877
Какой развернутый фидбек, шикарно.
Возможно это на самом деле не висюнк а что-то другое, просто профайлер отображает его так. Во всяком случае передо мной то что на первом скрине. А в диспетчере задач то что на втором.
Как видно, гпу загружен под завязку.
Так же 700мб оперативки, это, как мне кажется, тоже абсолютли нот окей. Но тут скорее всего виновата моя база данных с предметами, я примерно понимаю как это починить.
А аудиофайлов в игре нет.
Некоторое время назад я сам добрался до компа на котором игра лагает так же как у анонов, так что могу сам проводить тесты. Попробую новые драйвера накатить.
Мне кажется, он у тебя как-то некорректно отображается. Во всяком случае кнопка версии точно не должна перекрывать арену. Смотри третий скрин.
По поводу подсказок в инвентаре - годная идея, попробую запилить.
Подождать 10 тиков можно если вызвать радиальное меню долгим нажатием правой кнопки на клетке где стоишь.
На счет пиксель-перфект камеры, мне кажется тут тоже что-то с разрешением не то. У меня где-то 4 или 5 разных режимов увеличения, большинством из них вроде вполне можно пользоваться...
Вот на счет крыс не согласен)
По-моему прикольно что они тебя избить могут. Просто не нужно самому на них нападать, если их большая пачка, а у тебя оружия нет. Периодически на них коты охотятся, вот тогда можно выждать момент и напасть.
Настоящие проблемы баланса начинаются в районе 5 уровня, когда и из угла выходит негр с молотом и просто двумя точными ударами в незащищенную голову тебя сносит.
Давно хотел его сделать. Типа как отдельную локацию в начле, куда можно зайти а можно мимо пройти.
В фоллауты, увы, ни в один не играл, но этот зеленый экран прицеливания видел. Нужно изучить эту тему.
>>835880
Содержимое клетки можно посмотреть нажав О и листая предметы, но да, это не самый удобный способ.
К сожалению, мясо из инвентаря есть нельзя.
Я бы вообще хотел как-нибудь ограничить механику переноса еды в инвентаре, так как это подталкивает игрока к гринду всего мяса и всех грибов на уровне. Хз как это сделать. Может переносимый вес ввести?
Но для другой еды безусловно хоткей нужен.
На счет того, почему ничего не стакается. По моей первоначальной задумке, я хотел чтобы каждый предмет был уникальный, чтобы у него были свои статы и так далее.
Сейчас например у всех предметов своя прочность и на любом предмете может какой-то эффект висеть.
По-моему классно, не хотелось бы от этого отказываться. Лучше наверно решить эту проблему как-то по-другому. Вот в пиксель данжене была куча всяких предметов, по типу семян, и для них был специальный предмет-мешок. где могли только они лежать и не занимать инвентарь. Вот что-то подобное нужно.
Какой развернутый фидбек, шикарно.
>про оптимизацию
Возможно это на самом деле не висюнк а что-то другое, просто профайлер отображает его так. Во всяком случае передо мной то что на первом скрине. А в диспетчере задач то что на втором.
Как видно, гпу загружен под завязку.
Так же 700мб оперативки, это, как мне кажется, тоже абсолютли нот окей. Но тут скорее всего виновата моя база данных с предметами, я примерно понимаю как это починить.
А аудиофайлов в игре нет.
Некоторое время назад я сам добрался до компа на котором игра лагает так же как у анонов, так что могу сам проводить тесты. Попробую новые драйвера накатить.
>про интерфейс
Мне кажется, он у тебя как-то некорректно отображается. Во всяком случае кнопка версии точно не должна перекрывать арену. Смотри третий скрин.
По поводу подсказок в инвентаре - годная идея, попробую запилить.
Подождать 10 тиков можно если вызвать радиальное меню долгим нажатием правой кнопки на клетке где стоишь.
На счет пиксель-перфект камеры, мне кажется тут тоже что-то с разрешением не то. У меня где-то 4 или 5 разных режимов увеличения, большинством из них вроде вполне можно пользоваться...
>про прогрессию
Вот на счет крыс не согласен)
По-моему прикольно что они тебя избить могут. Просто не нужно самому на них нападать, если их большая пачка, а у тебя оружия нет. Периодически на них коты охотятся, вот тогда можно выждать момент и напасть.
Настоящие проблемы баланса начинаются в районе 5 уровня, когда и из угла выходит негр с молотом и просто двумя точными ударами в незащищенную голову тебя сносит.
>туториальный уровень
Давно хотел его сделать. Типа как отдельную локацию в начле, куда можно зайти а можно мимо пройти.
В фоллауты, увы, ни в один не играл, но этот зеленый экран прицеливания видел. Нужно изучить эту тему.
>>835880
Содержимое клетки можно посмотреть нажав О и листая предметы, но да, это не самый удобный способ.
К сожалению, мясо из инвентаря есть нельзя.
Я бы вообще хотел как-нибудь ограничить механику переноса еды в инвентаре, так как это подталкивает игрока к гринду всего мяса и всех грибов на уровне. Хз как это сделать. Может переносимый вес ввести?
Но для другой еды безусловно хоткей нужен.
На счет того, почему ничего не стакается. По моей первоначальной задумке, я хотел чтобы каждый предмет был уникальный, чтобы у него были свои статы и так далее.
Сейчас например у всех предметов своя прочность и на любом предмете может какой-то эффект висеть.
По-моему классно, не хотелось бы от этого отказываться. Лучше наверно решить эту проблему как-то по-другому. Вот в пиксель данжене была куча всяких предметов, по типу семян, и для них был специальный предмет-мешок. где могли только они лежать и не занимать инвентарь. Вот что-то подобное нужно.
>>835877
Совершенно нет. Сейчас играю в мобильный рогалик, и там перетсакивание из инвентаря на слоты снаряжения, и это охуенно удобно. Промахнуться нажатием легче, чем скорректировать движение пальца - но, конечно, двигаемый предмет должен двигаться за пальцем не лагая.
>Для мобилок, если ты всё-таки метишь на них (судя по огромным кнопкам и ячейкам), во-первых, лучше будет не перетаскивать предметы, а кликать на предмет и затем на место назначени
Совершенно нет. Сейчас играю в мобильный рогалик, и там перетсакивание из инвентаря на слоты снаряжения, и это охуенно удобно. Промахнуться нажатием легче, чем скорректировать движение пальца - но, конечно, двигаемый предмет должен двигаться за пальцем не лагая.
Поиграл немного в игру и встретил некоторые проблемы: кнопка версии перекрывает кнопку "продолжить", меню выбора персонажа просто огромное, я сначала подумал, что у меня разрешение экрана сломалось, настройки не открываются это кнопка-заглушка или баг?, в половине случаем при старте комнаты камера спавнится в темном месте и приходится рестартить игру, так же спавн живности непонятный - то спавнится куча врагов и окружают тебя, то пустота, интерфейсы абсоютно непонятные. Где моё здоровье? Что значит кнопки в инвентаре?
>>835887
Я играл в него кстати.
Очень качественно все сделано, но лично для меня чего-то в нем недостает. Много раз в него начинал играть, но так дальше 3 локации не доходил.
Вроде и графика классная и куча всяких замысловатых апгрейдов, а вот...
На андроид есть DCSS, вот в него я задротствую уже лет 7 к ряду.
По началу был только порт с ASCII.
Интерфейса по факту не было вообще.
Тем не менее, практически моя любимая игра.
>>835906
А это, если что, уже другой анон отвечает.
Я играл в него кстати.
Очень качественно все сделано, но лично для меня чего-то в нем недостает. Много раз в него начинал играть, но так дальше 3 локации не доходил.
Вроде и графика классная и куча всяких замысловатых апгрейдов, а вот...
На андроид есть DCSS, вот в него я задротствую уже лет 7 к ряду.
По началу был только порт с ASCII.
Интерфейса по факту не было вообще.
Тем не менее, практически моя любимая игра.
>>835906
А это, если что, уже другой анон отвечает.
1 Кб, 219x160>>835911
Да, тут явно с разрешением что-то. Буду чинить.
Настройки это заглушка, да.
Здоровья персонажа в игре нет. Есть только здоровье отдельных чатей тела, оно показано цветом на портрете справа снизу или на портрете в инвентаре если мышкой навести.
Если ты про те что на скрине то они переключают режимы отображения портрета: с прочностью\без, с экипировкой\без.
А что, действительно непонятно что это? В смысле, я без негатива спрашиваю, правда непонятно, даже после того как понажимаешь на них? Просто чужими глазами не посмотришь, я то этот интерфейс делал, мне то естественно все в нем интуитивно понятно.
Хотя может быть из за бага с разрешением ты вообще половины функций не видишь.
То что ты описываешь при старте, это и правда какой-то загадочный баг, я такого не встречал. Буду признателен если словишь его еще раз, закроешь игру, после чего скинешь сюда текстовый документ "Player" лежащий в AppData\LocalLow\DefaultCompany\Katabasis.
Да, тут явно с разрешением что-то. Буду чинить.
Настройки это заглушка, да.
Здоровья персонажа в игре нет. Есть только здоровье отдельных чатей тела, оно показано цветом на портрете справа снизу или на портрете в инвентаре если мышкой навести.
>Что значат кнопки в инвентаре
Если ты про те что на скрине то они переключают режимы отображения портрета: с прочностью\без, с экипировкой\без.
А что, действительно непонятно что это? В смысле, я без негатива спрашиваю, правда непонятно, даже после того как понажимаешь на них? Просто чужими глазами не посмотришь, я то этот интерфейс делал, мне то естественно все в нем интуитивно понятно.
Хотя может быть из за бага с разрешением ты вообще половины функций не видишь.
То что ты описываешь при старте, это и правда какой-то загадочный баг, я такого не встречал. Буду признателен если словишь его еще раз, закроешь игру, после чего скинешь сюда текстовый документ "Player" лежащий в AppData\LocalLow\DefaultCompany\Katabasis.
>>835914
Абсолютно не понятно, потому что:
1) Я не понял, что такое прочность. Я думал, что вот эта цветная хрень на портрете - баг но забыл об этом написал.. Просто пиксели шевелятся, когда я получаю демедж и цвет меняется очень странно. Лучше б это числовая шкала была, или что-то вроде портрета в doom, а то сейчас это непонятно.
2) На вторую кнопку я нажимал без эквипа
Вот скрин Бага и лог https://pastebin.com/d6QdpDaK . Он при первом же запуске вылез.
Еще добавил скрин создания персонажа и меню. Вот так они у меня выглядят
>А что, действительно непонятно что это?
Абсолютно не понятно, потому что:
1) Я не понял, что такое прочность. Я думал, что вот эта цветная хрень на портрете - баг но забыл об этом написал.. Просто пиксели шевелятся, когда я получаю демедж и цвет меняется очень странно. Лучше б это числовая шкала была, или что-то вроде портрета в doom, а то сейчас это непонятно.
2) На вторую кнопку я нажимал без эквипа
Вот скрин Бага и лог https://pastebin.com/d6QdpDaK . Он при первом же запуске вылез.
Еще добавил скрин создания персонажа и меню. Вот так они у меня выглядят
>>835914
Ну и так, в догонку, сделай что-нибудь с масштабированием. Какие-нибудь отдельные режимы, вроде x2, x3, а то колесиком мышки им просто невозможно управлять.
Ну и так, в догонку, сделай что-нибудь с масштабированием. Какие-нибудь отдельные режимы, вроде x2, x3, а то колесиком мышки им просто невозможно управлять.
>>835934
Ну да, интерфейс расплющило немного.
Лог выглядит очень странно, говорит что ты запустил, зашел в выбор персонажа а потом вышел из игры (или вылетел). Загадочно.
Кривое масштабирование видимо тоже связано с разрешением.
Ну да, интерфейс расплющило немного.
Лог выглядит очень странно, говорит что ты запустил, зашел в выбор персонажа а потом вышел из игры (или вылетел). Загадочно.
Кривое масштабирование видимо тоже связано с разрешением.
>>835935
Подвачну, сделай дискретно, один раз колесом крутанул х2, два раза х3, и обратно. И убери дефолтный зум в ебало, он не нужен, бесполезен. Так же можно убрать уровни зума где уже нихуя не видно что происходит.
Подвачну, сделай дискретно, один раз колесом крутанул х2, два раза х3, и обратно. И убери дефолтный зум в ебало, он не нужен, бесполезен. Так же можно убрать уровни зума где уже нихуя не видно что происходит.
>>835904
Вот мои скриншоты. Разрешение оригинальное.
Ещё по управлению, не помню уже, писал ли: сделай WASD управление, оно намного привычнее на компьютере, чем тыки мышкой. Тыки с поиском пути - это скорее к мобилкам, чем к ПК. Я знаю, что есть крупные ПК игры с управлением только мышкой, но это не меняет того, что тыки мышкой банально не так удобны, как движение клавишами. Я думаю, что управление тыками мыши характерно для игр с очень сложным GUI, типа MMORPG, MOBA, всевозможные симуляторы и т.д. Для рогаликов всё же характерно управление "только с клавиатуры", потому что во времена первых игр мышей вообще не существовало или они очень редко встречались у пользователей. Понимаю, что у тебя геймплей заточен в том числе на движение по диагонали, но это теоретически возможно осуществить четырьмя кнопками (потребуется минимальная задержка для того чтобы компенсировать разницу во времени нажатия двух клавиш), а в крайнем случае можно перенести управление на нумпад - там как раз вокруг клавиши "5" клавиши сеткой выстроены. Впрочем, в идеале у тебя должны быть настройки раскладки, чтобы игрок мог забиндить всё на свой вкус/под свои возможности. От управления чисто мышью отказываться не нужно, нужна просто альтернатива для расширения аудитории.
Пока делал скриншоты, немного побегал по первому уровню, никого не трогая - лестницу вниз не нашёл, зато встретил группу из 3+ скелетов и они меня... окружили (я попытался взорвать бомбу и меня разбросало, а скелетам вообще пофиг). Это не хардкор, это издевательство... впрочем, кто я такой, чтобы судить, я не разбираюсь в особенностях рогаликов - может, в этом и есть фан?
Таки мобы могут прицельно бить, а игрок - нет? Или ты имеешь в виду, что случайные удары так совпали?
https://fallout.fandom.com/wiki/Aimed_Shot
Нужно понимать важную разницу между первыми фоллаутами и рогаликами вроде твоей игры: в фоллауте тебе дают очки действия на каждый ход, что позволяет тебе осуществить несколько действий за один ход, прежде чем очередь дойдёт до противника; далее каждый враг ходит по очереди, тоже используя свои очки действий. Поэтому в фоллауте можно, например, сделать несколько быстрых ударов и заюзать хилку, а можно сделать только один мощный прицельный удар. Также максимальное количество очков действий зависит от параметров персонажа - прокачки, здоровья и т.п., например, если ничего не путаю, какой-то наркотик позволяет временно повысить число очков действий, но вызывает зависимость и в последствии число очков действий будет меньше обычного, вынуждая принимать наркотик дальше, пока не сдохнешь от передоза/побочек... таки реализм же.
Впрочем, я тут подумал, вроде бы в рогаликах отдалённо похожая система: разные действия занимают разное число тиков, и если игрок делает действие за 5 тиков, а монстру для атаки нужно 10 тиков, то игрок может успеть сделать ещё одно действие, прежде чем монстр атакует... Правильно ведь? Ты что-то такое вроде писал, но я в игре это как-то не разглядел. Так что советую отобразить ней таймер тиков в углу экрана... не знаю, как лучше описать... Вроде бы в CDDA такой таймер видел - в виде круглого прогресс бара, который обозначает какое-то круглое число тиков, наглядно демонстрируя, сколько времени затратило предыдущее действие игрока.
Банально добавь порчу еды со временем. Будет нерационально бегать собирать мясо, потому что пока соберёшь всё, половина по дороге испортится. Также я во многих рогаликах вижу параметр голода, который не позволяет игроку бесцельно блуждать - даже если еда не портится, бегать по уровню нерационально, т.к. пока всё соберёшь, половину придётся съесть. В остальном, балансируй по формулам: нужно составить такую формулу, которая позволяет игроку в среднем вынести с уровня только минимальное количество еды; такие параметры, как размер уровня, количество мобов и растений, дроп еды с каждого растения и моба, скорость порчи/голода, средний расход еды на лечение и т.д. будут неизвестными в этой формуле. Решаешь формулу и получаешь набор параметров для генерации уровня. Эту формулу можно даже использовать во время генерации уровня: если результат формулы говорит о том, что игрок будет голодать, нужно накинуть в уровень бонусной еды и снова проверить формулу; если формула говорит, что еды слишком много, нужно убрать часть мобов/растений или, например, изменить их тип на "токсичный", чтобы игрок их не ел.
Тут нужно понимать, как это выглядит с точки зрения игрока. Если у тебя 10 кусков мяса, которые весят около 1 кг, но отличаются буквально на считанные граммы друг от друга, то технически все эти куски мяса уникальны, но с точки зрения пользователя разницы между ними нет - это всего лишь расходный материал для лечения, а какие-то мелкие колебания веса значения не имеют. С точки зрения игрока было бы удобнее иметь стопку мяса, чтобы не искать кусок мяса по всему инвентарю. Пускай инвентарь ограничен, но зато нужно меньше движений для использования нужного предмета.
В твоём случае рекомендую сделать так. Пусть любой предмет может быть уникальным, но предметы с одинаковыми параметрами должны образовывать стопки. Незначительные параметры должны быть полностью устранены, т.е. если мясо - то стандартный 1 кг мяса. Предметы с прочностью тоже можно стакать, просто после изменения износа у одного предмета он вылетает из стопки и больше не может быть с ней объединён. Это упростит интерфейс и поиск нужного предмета.
Что касается ограничений, я считаю, что фиксированное число ячеек интерфейса намного сложнее балансировать, чем, например, ограничение по суммарному весу предметов или по числу предметов одного типа. Не знаю, может, это Майнкрафт на геймдев так повлиял, что у многих сейчас инвентарь из фиксированного числа ячеек... Но я не считаю это таким уж хорошим решением, просто к нему привыкли.
Для примера годного инвентаря рекомендую это:
https://play.google.com/store/apps/details?id=com.gm_shaber.dayr
Это тоже пошаговая игра, только игрок большую часть времени один и от его действий зависит течение времени, а не действия противников (противники есть в отдельной боевой системе, которая выглядит как мини-игра). Но не в этом суть. Там инвентарь выглядит как неограниченная сетка с постраничной прокруткой, расширяющаяся по мере необходимости. Можно посмотреть все предметы, а можно выбрать категорию кнопкой-вкладкой сбоку. Есть сортировка по весу, по количеству, по названию, по типу предмета. Есть даже такая крутая фича: каждый расходник имеет уровень износа, но при этом он собирается в стопку с другими расходниками; стопка точно помнит износ всех предметов в ней, но сортирует их степени износа, т.о. при использовании всегда тратится предмет с наибольшим износом. Это избавляет от кучи функционально одинаковых предметов с высоким износом. Есть и уникальные предметы, занимающие одну ячейку - обычно это что-то важное, вроде пистолета. Инвентарь, как ты уже понял, ограничен максимальным переносимым весом, но при этом персонаж способен напихать себе в "карманы" любое количество предметов - просто при превышении лимита он не сможет двигаться по карте. Это тоже очень удобная фича, позволяющая удобнее сортировать предметы в локациях, хотя крафтинг доступен даже если необходимые предметы с точки зрения интерфейса "лежат на земле". Короче, система очень продуманная и удобная для этой игры, хотя я не уверен, насколько хорошо она подойдёт рогалику.
Для сравнения, в Фоллаут тоже ограничение только по весу, а не по числу предметов, только инвентарь там в виде списка, а не сеткой. Сетка по идее лучше работает для большого количества предметов, а список позволяет разместить название и некоторые параметры предмета прямо на строке списка. В общем, нужно смотреть по тому, сколько позиций в инвентаре может быть - если у тебя там только стопки мяса, костей да палок, то сетка из квадратиков вообще ни к чему...
Мне эта фича не понравилась, ибо костыль. Почему в "обычном" рюкзаке одно семечко занимает объём боевого молота? Просто сделай массу и дай бесконечные ячейки, делов-то. Сбалансировать можно что угодно, главное - юзабилити гуя.
Вот мои скриншоты. Разрешение оригинальное.
Ещё по управлению, не помню уже, писал ли: сделай WASD управление, оно намного привычнее на компьютере, чем тыки мышкой. Тыки с поиском пути - это скорее к мобилкам, чем к ПК. Я знаю, что есть крупные ПК игры с управлением только мышкой, но это не меняет того, что тыки мышкой банально не так удобны, как движение клавишами. Я думаю, что управление тыками мыши характерно для игр с очень сложным GUI, типа MMORPG, MOBA, всевозможные симуляторы и т.д. Для рогаликов всё же характерно управление "только с клавиатуры", потому что во времена первых игр мышей вообще не существовало или они очень редко встречались у пользователей. Понимаю, что у тебя геймплей заточен в том числе на движение по диагонали, но это теоретически возможно осуществить четырьмя кнопками (потребуется минимальная задержка для того чтобы компенсировать разницу во времени нажатия двух клавиш), а в крайнем случае можно перенести управление на нумпад - там как раз вокруг клавиши "5" клавиши сеткой выстроены. Впрочем, в идеале у тебя должны быть настройки раскладки, чтобы игрок мог забиндить всё на свой вкус/под свои возможности. От управления чисто мышью отказываться не нужно, нужна просто альтернатива для расширения аудитории.
>Настоящие проблемы баланса
Пока делал скриншоты, немного побегал по первому уровню, никого не трогая - лестницу вниз не нашёл, зато встретил группу из 3+ скелетов и они меня... окружили (я попытался взорвать бомбу и меня разбросало, а скелетам вообще пофиг). Это не хардкор, это издевательство... впрочем, кто я такой, чтобы судить, я не разбираюсь в особенностях рогаликов - может, в этом и есть фан?
>двумя точными ударами в незащищенную голову тебя сносит
Таки мобы могут прицельно бить, а игрок - нет? Или ты имеешь в виду, что случайные удары так совпали?
>В фоллауты, увы, ни в один не играл
https://fallout.fandom.com/wiki/Aimed_Shot
Нужно понимать важную разницу между первыми фоллаутами и рогаликами вроде твоей игры: в фоллауте тебе дают очки действия на каждый ход, что позволяет тебе осуществить несколько действий за один ход, прежде чем очередь дойдёт до противника; далее каждый враг ходит по очереди, тоже используя свои очки действий. Поэтому в фоллауте можно, например, сделать несколько быстрых ударов и заюзать хилку, а можно сделать только один мощный прицельный удар. Также максимальное количество очков действий зависит от параметров персонажа - прокачки, здоровья и т.п., например, если ничего не путаю, какой-то наркотик позволяет временно повысить число очков действий, но вызывает зависимость и в последствии число очков действий будет меньше обычного, вынуждая принимать наркотик дальше, пока не сдохнешь от передоза/побочек... таки реализм же.
Впрочем, я тут подумал, вроде бы в рогаликах отдалённо похожая система: разные действия занимают разное число тиков, и если игрок делает действие за 5 тиков, а монстру для атаки нужно 10 тиков, то игрок может успеть сделать ещё одно действие, прежде чем монстр атакует... Правильно ведь? Ты что-то такое вроде писал, но я в игре это как-то не разглядел. Так что советую отобразить ней таймер тиков в углу экрана... не знаю, как лучше описать... Вроде бы в CDDA такой таймер видел - в виде круглого прогресс бара, который обозначает какое-то круглое число тиков, наглядно демонстрируя, сколько времени затратило предыдущее действие игрока.
>ограничить механику переноса еды
>гринду всего мяса и всех грибов на уровне
Банально добавь порчу еды со временем. Будет нерационально бегать собирать мясо, потому что пока соберёшь всё, половина по дороге испортится. Также я во многих рогаликах вижу параметр голода, который не позволяет игроку бесцельно блуждать - даже если еда не портится, бегать по уровню нерационально, т.к. пока всё соберёшь, половину придётся съесть. В остальном, балансируй по формулам: нужно составить такую формулу, которая позволяет игроку в среднем вынести с уровня только минимальное количество еды; такие параметры, как размер уровня, количество мобов и растений, дроп еды с каждого растения и моба, скорость порчи/голода, средний расход еды на лечение и т.д. будут неизвестными в этой формуле. Решаешь формулу и получаешь набор параметров для генерации уровня. Эту формулу можно даже использовать во время генерации уровня: если результат формулы говорит о том, что игрок будет голодать, нужно накинуть в уровень бонусной еды и снова проверить формулу; если формула говорит, что еды слишком много, нужно убрать часть мобов/растений или, например, изменить их тип на "токсичный", чтобы игрок их не ел.
>каждый предмет был уникальный
Тут нужно понимать, как это выглядит с точки зрения игрока. Если у тебя 10 кусков мяса, которые весят около 1 кг, но отличаются буквально на считанные граммы друг от друга, то технически все эти куски мяса уникальны, но с точки зрения пользователя разницы между ними нет - это всего лишь расходный материал для лечения, а какие-то мелкие колебания веса значения не имеют. С точки зрения игрока было бы удобнее иметь стопку мяса, чтобы не искать кусок мяса по всему инвентарю. Пускай инвентарь ограничен, но зато нужно меньше движений для использования нужного предмета.
В твоём случае рекомендую сделать так. Пусть любой предмет может быть уникальным, но предметы с одинаковыми параметрами должны образовывать стопки. Незначительные параметры должны быть полностью устранены, т.е. если мясо - то стандартный 1 кг мяса. Предметы с прочностью тоже можно стакать, просто после изменения износа у одного предмета он вылетает из стопки и больше не может быть с ней объединён. Это упростит интерфейс и поиск нужного предмета.
Что касается ограничений, я считаю, что фиксированное число ячеек интерфейса намного сложнее балансировать, чем, например, ограничение по суммарному весу предметов или по числу предметов одного типа. Не знаю, может, это Майнкрафт на геймдев так повлиял, что у многих сейчас инвентарь из фиксированного числа ячеек... Но я не считаю это таким уж хорошим решением, просто к нему привыкли.
Для примера годного инвентаря рекомендую это:
https://play.google.com/store/apps/details?id=com.gm_shaber.dayr
Это тоже пошаговая игра, только игрок большую часть времени один и от его действий зависит течение времени, а не действия противников (противники есть в отдельной боевой системе, которая выглядит как мини-игра). Но не в этом суть. Там инвентарь выглядит как неограниченная сетка с постраничной прокруткой, расширяющаяся по мере необходимости. Можно посмотреть все предметы, а можно выбрать категорию кнопкой-вкладкой сбоку. Есть сортировка по весу, по количеству, по названию, по типу предмета. Есть даже такая крутая фича: каждый расходник имеет уровень износа, но при этом он собирается в стопку с другими расходниками; стопка точно помнит износ всех предметов в ней, но сортирует их степени износа, т.о. при использовании всегда тратится предмет с наибольшим износом. Это избавляет от кучи функционально одинаковых предметов с высоким износом. Есть и уникальные предметы, занимающие одну ячейку - обычно это что-то важное, вроде пистолета. Инвентарь, как ты уже понял, ограничен максимальным переносимым весом, но при этом персонаж способен напихать себе в "карманы" любое количество предметов - просто при превышении лимита он не сможет двигаться по карте. Это тоже очень удобная фича, позволяющая удобнее сортировать предметы в локациях, хотя крафтинг доступен даже если необходимые предметы с точки зрения интерфейса "лежат на земле". Короче, система очень продуманная и удобная для этой игры, хотя я не уверен, насколько хорошо она подойдёт рогалику.
Для сравнения, в Фоллаут тоже ограничение только по весу, а не по числу предметов, только инвентарь там в виде списка, а не сеткой. Сетка по идее лучше работает для большого количества предметов, а список позволяет разместить название и некоторые параметры предмета прямо на строке списка. В общем, нужно смотреть по тому, сколько позиций в инвентаре может быть - если у тебя там только стопки мяса, костей да палок, то сетка из квадратиков вообще ни к чему...
>специальный предмет-мешок
Мне эта фича не понравилась, ибо костыль. Почему в "обычном" рюкзаке одно семечко занимает объём боевого молота? Просто сделай массу и дай бесконечные ячейки, делов-то. Сбалансировать можно что угодно, главное - юзабилити гуя.
>>835904
Вот мои скриншоты. Разрешение оригинальное.
Ещё по управлению, не помню уже, писал ли: сделай WASD управление, оно намного привычнее на компьютере, чем тыки мышкой. Тыки с поиском пути - это скорее к мобилкам, чем к ПК. Я знаю, что есть крупные ПК игры с управлением только мышкой, но это не меняет того, что тыки мышкой банально не так удобны, как движение клавишами. Я думаю, что управление тыками мыши характерно для игр с очень сложным GUI, типа MMORPG, MOBA, всевозможные симуляторы и т.д. Для рогаликов всё же характерно управление "только с клавиатуры", потому что во времена первых игр мышей вообще не существовало или они очень редко встречались у пользователей. Понимаю, что у тебя геймплей заточен в том числе на движение по диагонали, но это теоретически возможно осуществить четырьмя кнопками (потребуется минимальная задержка для того чтобы компенсировать разницу во времени нажатия двух клавиш), а в крайнем случае можно перенести управление на нумпад - там как раз вокруг клавиши "5" клавиши сеткой выстроены. Впрочем, в идеале у тебя должны быть настройки раскладки, чтобы игрок мог забиндить всё на свой вкус/под свои возможности. От управления чисто мышью отказываться не нужно, нужна просто альтернатива для расширения аудитории.
Пока делал скриншоты, немного побегал по первому уровню, никого не трогая - лестницу вниз не нашёл, зато встретил группу из 3+ скелетов и они меня... окружили (я попытался взорвать бомбу и меня разбросало, а скелетам вообще пофиг). Это не хардкор, это издевательство... впрочем, кто я такой, чтобы судить, я не разбираюсь в особенностях рогаликов - может, в этом и есть фан?
Таки мобы могут прицельно бить, а игрок - нет? Или ты имеешь в виду, что случайные удары так совпали?
https://fallout.fandom.com/wiki/Aimed_Shot
Нужно понимать важную разницу между первыми фоллаутами и рогаликами вроде твоей игры: в фоллауте тебе дают очки действия на каждый ход, что позволяет тебе осуществить несколько действий за один ход, прежде чем очередь дойдёт до противника; далее каждый враг ходит по очереди, тоже используя свои очки действий. Поэтому в фоллауте можно, например, сделать несколько быстрых ударов и заюзать хилку, а можно сделать только один мощный прицельный удар. Также максимальное количество очков действий зависит от параметров персонажа - прокачки, здоровья и т.п., например, если ничего не путаю, какой-то наркотик позволяет временно повысить число очков действий, но вызывает зависимость и в последствии число очков действий будет меньше обычного, вынуждая принимать наркотик дальше, пока не сдохнешь от передоза/побочек... таки реализм же.
Впрочем, я тут подумал, вроде бы в рогаликах отдалённо похожая система: разные действия занимают разное число тиков, и если игрок делает действие за 5 тиков, а монстру для атаки нужно 10 тиков, то игрок может успеть сделать ещё одно действие, прежде чем монстр атакует... Правильно ведь? Ты что-то такое вроде писал, но я в игре это как-то не разглядел. Так что советую отобразить ней таймер тиков в углу экрана... не знаю, как лучше описать... Вроде бы в CDDA такой таймер видел - в виде круглого прогресс бара, который обозначает какое-то круглое число тиков, наглядно демонстрируя, сколько времени затратило предыдущее действие игрока.
Банально добавь порчу еды со временем. Будет нерационально бегать собирать мясо, потому что пока соберёшь всё, половина по дороге испортится. Также я во многих рогаликах вижу параметр голода, который не позволяет игроку бесцельно блуждать - даже если еда не портится, бегать по уровню нерационально, т.к. пока всё соберёшь, половину придётся съесть. В остальном, балансируй по формулам: нужно составить такую формулу, которая позволяет игроку в среднем вынести с уровня только минимальное количество еды; такие параметры, как размер уровня, количество мобов и растений, дроп еды с каждого растения и моба, скорость порчи/голода, средний расход еды на лечение и т.д. будут неизвестными в этой формуле. Решаешь формулу и получаешь набор параметров для генерации уровня. Эту формулу можно даже использовать во время генерации уровня: если результат формулы говорит о том, что игрок будет голодать, нужно накинуть в уровень бонусной еды и снова проверить формулу; если формула говорит, что еды слишком много, нужно убрать часть мобов/растений или, например, изменить их тип на "токсичный", чтобы игрок их не ел.
Тут нужно понимать, как это выглядит с точки зрения игрока. Если у тебя 10 кусков мяса, которые весят около 1 кг, но отличаются буквально на считанные граммы друг от друга, то технически все эти куски мяса уникальны, но с точки зрения пользователя разницы между ними нет - это всего лишь расходный материал для лечения, а какие-то мелкие колебания веса значения не имеют. С точки зрения игрока было бы удобнее иметь стопку мяса, чтобы не искать кусок мяса по всему инвентарю. Пускай инвентарь ограничен, но зато нужно меньше движений для использования нужного предмета.
В твоём случае рекомендую сделать так. Пусть любой предмет может быть уникальным, но предметы с одинаковыми параметрами должны образовывать стопки. Незначительные параметры должны быть полностью устранены, т.е. если мясо - то стандартный 1 кг мяса. Предметы с прочностью тоже можно стакать, просто после изменения износа у одного предмета он вылетает из стопки и больше не может быть с ней объединён. Это упростит интерфейс и поиск нужного предмета.
Что касается ограничений, я считаю, что фиксированное число ячеек интерфейса намного сложнее балансировать, чем, например, ограничение по суммарному весу предметов или по числу предметов одного типа. Не знаю, может, это Майнкрафт на геймдев так повлиял, что у многих сейчас инвентарь из фиксированного числа ячеек... Но я не считаю это таким уж хорошим решением, просто к нему привыкли.
Для примера годного инвентаря рекомендую это:
https://play.google.com/store/apps/details?id=com.gm_shaber.dayr
Это тоже пошаговая игра, только игрок большую часть времени один и от его действий зависит течение времени, а не действия противников (противники есть в отдельной боевой системе, которая выглядит как мини-игра). Но не в этом суть. Там инвентарь выглядит как неограниченная сетка с постраничной прокруткой, расширяющаяся по мере необходимости. Можно посмотреть все предметы, а можно выбрать категорию кнопкой-вкладкой сбоку. Есть сортировка по весу, по количеству, по названию, по типу предмета. Есть даже такая крутая фича: каждый расходник имеет уровень износа, но при этом он собирается в стопку с другими расходниками; стопка точно помнит износ всех предметов в ней, но сортирует их степени износа, т.о. при использовании всегда тратится предмет с наибольшим износом. Это избавляет от кучи функционально одинаковых предметов с высоким износом. Есть и уникальные предметы, занимающие одну ячейку - обычно это что-то важное, вроде пистолета. Инвентарь, как ты уже понял, ограничен максимальным переносимым весом, но при этом персонаж способен напихать себе в "карманы" любое количество предметов - просто при превышении лимита он не сможет двигаться по карте. Это тоже очень удобная фича, позволяющая удобнее сортировать предметы в локациях, хотя крафтинг доступен даже если необходимые предметы с точки зрения интерфейса "лежат на земле". Короче, система очень продуманная и удобная для этой игры, хотя я не уверен, насколько хорошо она подойдёт рогалику.
Для сравнения, в Фоллаут тоже ограничение только по весу, а не по числу предметов, только инвентарь там в виде списка, а не сеткой. Сетка по идее лучше работает для большого количества предметов, а список позволяет разместить название и некоторые параметры предмета прямо на строке списка. В общем, нужно смотреть по тому, сколько позиций в инвентаре может быть - если у тебя там только стопки мяса, костей да палок, то сетка из квадратиков вообще ни к чему...
Мне эта фича не понравилась, ибо костыль. Почему в "обычном" рюкзаке одно семечко занимает объём боевого молота? Просто сделай массу и дай бесконечные ячейки, делов-то. Сбалансировать можно что угодно, главное - юзабилити гуя.
Вот мои скриншоты. Разрешение оригинальное.
Ещё по управлению, не помню уже, писал ли: сделай WASD управление, оно намного привычнее на компьютере, чем тыки мышкой. Тыки с поиском пути - это скорее к мобилкам, чем к ПК. Я знаю, что есть крупные ПК игры с управлением только мышкой, но это не меняет того, что тыки мышкой банально не так удобны, как движение клавишами. Я думаю, что управление тыками мыши характерно для игр с очень сложным GUI, типа MMORPG, MOBA, всевозможные симуляторы и т.д. Для рогаликов всё же характерно управление "только с клавиатуры", потому что во времена первых игр мышей вообще не существовало или они очень редко встречались у пользователей. Понимаю, что у тебя геймплей заточен в том числе на движение по диагонали, но это теоретически возможно осуществить четырьмя кнопками (потребуется минимальная задержка для того чтобы компенсировать разницу во времени нажатия двух клавиш), а в крайнем случае можно перенести управление на нумпад - там как раз вокруг клавиши "5" клавиши сеткой выстроены. Впрочем, в идеале у тебя должны быть настройки раскладки, чтобы игрок мог забиндить всё на свой вкус/под свои возможности. От управления чисто мышью отказываться не нужно, нужна просто альтернатива для расширения аудитории.
>Настоящие проблемы баланса
Пока делал скриншоты, немного побегал по первому уровню, никого не трогая - лестницу вниз не нашёл, зато встретил группу из 3+ скелетов и они меня... окружили (я попытался взорвать бомбу и меня разбросало, а скелетам вообще пофиг). Это не хардкор, это издевательство... впрочем, кто я такой, чтобы судить, я не разбираюсь в особенностях рогаликов - может, в этом и есть фан?
>двумя точными ударами в незащищенную голову тебя сносит
Таки мобы могут прицельно бить, а игрок - нет? Или ты имеешь в виду, что случайные удары так совпали?
>В фоллауты, увы, ни в один не играл
https://fallout.fandom.com/wiki/Aimed_Shot
Нужно понимать важную разницу между первыми фоллаутами и рогаликами вроде твоей игры: в фоллауте тебе дают очки действия на каждый ход, что позволяет тебе осуществить несколько действий за один ход, прежде чем очередь дойдёт до противника; далее каждый враг ходит по очереди, тоже используя свои очки действий. Поэтому в фоллауте можно, например, сделать несколько быстрых ударов и заюзать хилку, а можно сделать только один мощный прицельный удар. Также максимальное количество очков действий зависит от параметров персонажа - прокачки, здоровья и т.п., например, если ничего не путаю, какой-то наркотик позволяет временно повысить число очков действий, но вызывает зависимость и в последствии число очков действий будет меньше обычного, вынуждая принимать наркотик дальше, пока не сдохнешь от передоза/побочек... таки реализм же.
Впрочем, я тут подумал, вроде бы в рогаликах отдалённо похожая система: разные действия занимают разное число тиков, и если игрок делает действие за 5 тиков, а монстру для атаки нужно 10 тиков, то игрок может успеть сделать ещё одно действие, прежде чем монстр атакует... Правильно ведь? Ты что-то такое вроде писал, но я в игре это как-то не разглядел. Так что советую отобразить ней таймер тиков в углу экрана... не знаю, как лучше описать... Вроде бы в CDDA такой таймер видел - в виде круглого прогресс бара, который обозначает какое-то круглое число тиков, наглядно демонстрируя, сколько времени затратило предыдущее действие игрока.
>ограничить механику переноса еды
>гринду всего мяса и всех грибов на уровне
Банально добавь порчу еды со временем. Будет нерационально бегать собирать мясо, потому что пока соберёшь всё, половина по дороге испортится. Также я во многих рогаликах вижу параметр голода, который не позволяет игроку бесцельно блуждать - даже если еда не портится, бегать по уровню нерационально, т.к. пока всё соберёшь, половину придётся съесть. В остальном, балансируй по формулам: нужно составить такую формулу, которая позволяет игроку в среднем вынести с уровня только минимальное количество еды; такие параметры, как размер уровня, количество мобов и растений, дроп еды с каждого растения и моба, скорость порчи/голода, средний расход еды на лечение и т.д. будут неизвестными в этой формуле. Решаешь формулу и получаешь набор параметров для генерации уровня. Эту формулу можно даже использовать во время генерации уровня: если результат формулы говорит о том, что игрок будет голодать, нужно накинуть в уровень бонусной еды и снова проверить формулу; если формула говорит, что еды слишком много, нужно убрать часть мобов/растений или, например, изменить их тип на "токсичный", чтобы игрок их не ел.
>каждый предмет был уникальный
Тут нужно понимать, как это выглядит с точки зрения игрока. Если у тебя 10 кусков мяса, которые весят около 1 кг, но отличаются буквально на считанные граммы друг от друга, то технически все эти куски мяса уникальны, но с точки зрения пользователя разницы между ними нет - это всего лишь расходный материал для лечения, а какие-то мелкие колебания веса значения не имеют. С точки зрения игрока было бы удобнее иметь стопку мяса, чтобы не искать кусок мяса по всему инвентарю. Пускай инвентарь ограничен, но зато нужно меньше движений для использования нужного предмета.
В твоём случае рекомендую сделать так. Пусть любой предмет может быть уникальным, но предметы с одинаковыми параметрами должны образовывать стопки. Незначительные параметры должны быть полностью устранены, т.е. если мясо - то стандартный 1 кг мяса. Предметы с прочностью тоже можно стакать, просто после изменения износа у одного предмета он вылетает из стопки и больше не может быть с ней объединён. Это упростит интерфейс и поиск нужного предмета.
Что касается ограничений, я считаю, что фиксированное число ячеек интерфейса намного сложнее балансировать, чем, например, ограничение по суммарному весу предметов или по числу предметов одного типа. Не знаю, может, это Майнкрафт на геймдев так повлиял, что у многих сейчас инвентарь из фиксированного числа ячеек... Но я не считаю это таким уж хорошим решением, просто к нему привыкли.
Для примера годного инвентаря рекомендую это:
https://play.google.com/store/apps/details?id=com.gm_shaber.dayr
Это тоже пошаговая игра, только игрок большую часть времени один и от его действий зависит течение времени, а не действия противников (противники есть в отдельной боевой системе, которая выглядит как мини-игра). Но не в этом суть. Там инвентарь выглядит как неограниченная сетка с постраничной прокруткой, расширяющаяся по мере необходимости. Можно посмотреть все предметы, а можно выбрать категорию кнопкой-вкладкой сбоку. Есть сортировка по весу, по количеству, по названию, по типу предмета. Есть даже такая крутая фича: каждый расходник имеет уровень износа, но при этом он собирается в стопку с другими расходниками; стопка точно помнит износ всех предметов в ней, но сортирует их степени износа, т.о. при использовании всегда тратится предмет с наибольшим износом. Это избавляет от кучи функционально одинаковых предметов с высоким износом. Есть и уникальные предметы, занимающие одну ячейку - обычно это что-то важное, вроде пистолета. Инвентарь, как ты уже понял, ограничен максимальным переносимым весом, но при этом персонаж способен напихать себе в "карманы" любое количество предметов - просто при превышении лимита он не сможет двигаться по карте. Это тоже очень удобная фича, позволяющая удобнее сортировать предметы в локациях, хотя крафтинг доступен даже если необходимые предметы с точки зрения интерфейса "лежат на земле". Короче, система очень продуманная и удобная для этой игры, хотя я не уверен, насколько хорошо она подойдёт рогалику.
Для сравнения, в Фоллаут тоже ограничение только по весу, а не по числу предметов, только инвентарь там в виде списка, а не сеткой. Сетка по идее лучше работает для большого количества предметов, а список позволяет разместить название и некоторые параметры предмета прямо на строке списка. В общем, нужно смотреть по тому, сколько позиций в инвентаре может быть - если у тебя там только стопки мяса, костей да палок, то сетка из квадратиков вообще ни к чему...
>специальный предмет-мешок
Мне эта фича не понравилась, ибо костыль. Почему в "обычном" рюкзаке одно семечко занимает объём боевого молота? Просто сделай массу и дай бесконечные ячейки, делов-то. Сбалансировать можно что угодно, главное - юзабилити гуя.
>>835906
Нажатием промахнуться можно только если кнопки чрезвычайно мелкие по сравнению с физическим размером экрана. Если гуй прибит гвоздями как у ОПа - это проблема, но хороший гуй должен подстраиваться и делать кнопки оптимального размера. Плюс в настройках обычно можно изменить масштабирование.
У перетаскивания два косяка.
Во-первых, если предмет ТОЧНО ПОД ПАЛЬЦЕМ, ты со своими сосисками не видишь, куда именно роняешь предмет, т.к. предмет не видишь. На первый взгляд, это возможно пофиксить смещением точки захвата от пальца, но тут возникает вопрос - каким пальцем пользователь ведёт по экрану? Может, правым, может, левым, а может вообще сверху экрана рука висит (если горизонтальная ориентация, такое вполне возможно и иногда удобно). Т.е. эта проблема куда сложнее, чем кажется.
Во-вторых, даже самые лучшие сенсорные дисплеи могут ошибаться, особенно если телефон нагрелся во время игры и руки вспотели. У меня неоднократно бывало в самых разных играх и на разных смартфонах, что я не могу с первой попытки перенести предмет, т.к. он роняется раньше времени или не цепляется вообще. А современные "безрамочные" смартфоны ухудшают проблему - теперь ты можешь неосознанно нажимать на край экрана, вызывая непредсказуемые глюки в игре. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает, потому что у дисплея сейчас 5-10+ точек контакта и каждая из них регистрируется как независимый "клик", позволяя наплевать на многие ошибки. Т.е. у тебя выше шанс правильно переместить предмет кликом, чем если тебя заставляют вести палец через всю твою лопату, ни в коем случае не отрывая от экрана и не прикасаясь вторым пальцем. Видимо, у тебя другой опыт...
>>835911
А ты пробовал подождать? У меня не сразу начинается: сначала чернота и циклоп несколько секунд, только потом появляется локация и правильный персонаж (в смысле, если выбрал не циклопа). Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.
Ты за тредом не следил вообще? ОП же писал с самого начала, что у него фокус на расчленёнке. С таким подходом общий пул здоровья не имеет смысла, нужно следить за здоровьем каждой части тела.
>>835912
Глянул порт, на андроид предлагают виртуальную клавиатуру и набирать на ней сочетания клавиш. Ну уж нет, какой бы там геймплей ни был, такие извращения я не люблю ни на компьютере, ни тем более на телефоне. Я считаю, что богатый геймплей можно совместить с простым управлением, не создавая сотни шорткатов на клавиатуру для примитивных действий. Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.
>>835914
Совершенно непонятно даже то, что это на самом деле кнопки, а не какие-то декоративные спрайты или плейсхолдеры для будущих функций (типа статусные эффекты). У тебя во всей игре кнопки выглядят как коричневые прямоугольники, а тут внезапно цветные иконки даже без рамки. Как я должен понять, что это кнопка? Алсо, раз уж ты занял весь экран инвентарём, мог бы сделать обычные чекбоксы с текстом, а не какие-то огромные иконки.
Либо у тебя компьютер очень быстрый, либо кэш на диске помогает игре быстрее стартовать. Попробуй удалить кэш или запустить игру на виртуальной машине, особенно на искусственно замедленной, чтобы оценить процесс загрузки на слабом компьютере. Oracle VM VirtualBox бесплатная и её легко настроить.
>>835934
У меня это каждый раз. Нужно просто подождать, пока игра что-то там сделает, потом она автоматически закинет тебя в локацию и исправит интерфейс.
>>835935 >>836027
Зачем вы ему эту гадость советуете, "x2/x3" - это как те два стула, на одном двойки точёные, на другом тройки дрочёные. У него не пиксель-перфект графика, так что он может спокойно забить болт на пиксели и приближать камеру с минимальным шагом. Чем меньше шаг, тем плавнее и удобнее будет настройка.
>Промахнуться нажатием легче, чем скорректировать движение пальца
Нажатием промахнуться можно только если кнопки чрезвычайно мелкие по сравнению с физическим размером экрана. Если гуй прибит гвоздями как у ОПа - это проблема, но хороший гуй должен подстраиваться и делать кнопки оптимального размера. Плюс в настройках обычно можно изменить масштабирование.
У перетаскивания два косяка.
Во-первых, если предмет ТОЧНО ПОД ПАЛЬЦЕМ, ты со своими сосисками не видишь, куда именно роняешь предмет, т.к. предмет не видишь. На первый взгляд, это возможно пофиксить смещением точки захвата от пальца, но тут возникает вопрос - каким пальцем пользователь ведёт по экрану? Может, правым, может, левым, а может вообще сверху экрана рука висит (если горизонтальная ориентация, такое вполне возможно и иногда удобно). Т.е. эта проблема куда сложнее, чем кажется.
Во-вторых, даже самые лучшие сенсорные дисплеи могут ошибаться, особенно если телефон нагрелся во время игры и руки вспотели. У меня неоднократно бывало в самых разных играх и на разных смартфонах, что я не могу с первой попытки перенести предмет, т.к. он роняется раньше времени или не цепляется вообще. А современные "безрамочные" смартфоны ухудшают проблему - теперь ты можешь неосознанно нажимать на край экрана, вызывая непредсказуемые глюки в игре. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает, потому что у дисплея сейчас 5-10+ точек контакта и каждая из них регистрируется как независимый "клик", позволяя наплевать на многие ошибки. Т.е. у тебя выше шанс правильно переместить предмет кликом, чем если тебя заставляют вести палец через всю твою лопату, ни в коем случае не отрывая от экрана и не прикасаясь вторым пальцем. Видимо, у тебя другой опыт...
>>835911
>при старте комнаты камера спавнится в темном месте и приходится рестартить игру
А ты пробовал подождать? У меня не сразу начинается: сначала чернота и циклоп несколько секунд, только потом появляется локация и правильный персонаж (в смысле, если выбрал не циклопа). Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.
>Где моё здоровье?
Ты за тредом не следил вообще? ОП же писал с самого начала, что у него фокус на расчленёнке. С таким подходом общий пул здоровья не имеет смысла, нужно следить за здоровьем каждой части тела.
>>835912
>DCSS
Глянул порт, на андроид предлагают виртуальную клавиатуру и набирать на ней сочетания клавиш. Ну уж нет, какой бы там геймплей ни был, такие извращения я не люблю ни на компьютере, ни тем более на телефоне. Я считаю, что богатый геймплей можно совместить с простым управлением, не создавая сотни шорткатов на клавиатуру для примитивных действий. Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.
>>835914
>А что, действительно непонятно что это?
Совершенно непонятно даже то, что это на самом деле кнопки, а не какие-то декоративные спрайты или плейсхолдеры для будущих функций (типа статусные эффекты). У тебя во всей игре кнопки выглядят как коричневые прямоугольники, а тут внезапно цветные иконки даже без рамки. Как я должен понять, что это кнопка? Алсо, раз уж ты занял весь экран инвентарём, мог бы сделать обычные чекбоксы с текстом, а не какие-то огромные иконки.
>То что ты описываешь при старте, это и правда какой-то загадочный баг, я такого не встречал.
Либо у тебя компьютер очень быстрый, либо кэш на диске помогает игре быстрее стартовать. Попробуй удалить кэш или запустить игру на виртуальной машине, особенно на искусственно замедленной, чтобы оценить процесс загрузки на слабом компьютере. Oracle VM VirtualBox бесплатная и её легко настроить.
>>835934
>Вот скрин Бага
>Он при первом же запуске вылез.
У меня это каждый раз. Нужно просто подождать, пока игра что-то там сделает, потом она автоматически закинет тебя в локацию и исправит интерфейс.
>>835935 >>836027
Зачем вы ему эту гадость советуете, "x2/x3" - это как те два стула, на одном двойки точёные, на другом тройки дрочёные. У него не пиксель-перфект графика, так что он может спокойно забить болт на пиксели и приближать камеру с минимальным шагом. Чем меньше шаг, тем плавнее и удобнее будет настройка.
>>835906
Нажатием промахнуться можно только если кнопки чрезвычайно мелкие по сравнению с физическим размером экрана. Если гуй прибит гвоздями как у ОПа - это проблема, но хороший гуй должен подстраиваться и делать кнопки оптимального размера. Плюс в настройках обычно можно изменить масштабирование.
У перетаскивания два косяка.
Во-первых, если предмет ТОЧНО ПОД ПАЛЬЦЕМ, ты со своими сосисками не видишь, куда именно роняешь предмет, т.к. предмет не видишь. На первый взгляд, это возможно пофиксить смещением точки захвата от пальца, но тут возникает вопрос - каким пальцем пользователь ведёт по экрану? Может, правым, может, левым, а может вообще сверху экрана рука висит (если горизонтальная ориентация, такое вполне возможно и иногда удобно). Т.е. эта проблема куда сложнее, чем кажется.
Во-вторых, даже самые лучшие сенсорные дисплеи могут ошибаться, особенно если телефон нагрелся во время игры и руки вспотели. У меня неоднократно бывало в самых разных играх и на разных смартфонах, что я не могу с первой попытки перенести предмет, т.к. он роняется раньше времени или не цепляется вообще. А современные "безрамочные" смартфоны ухудшают проблему - теперь ты можешь неосознанно нажимать на край экрана, вызывая непредсказуемые глюки в игре. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает, потому что у дисплея сейчас 5-10+ точек контакта и каждая из них регистрируется как независимый "клик", позволяя наплевать на многие ошибки. Т.е. у тебя выше шанс правильно переместить предмет кликом, чем если тебя заставляют вести палец через всю твою лопату, ни в коем случае не отрывая от экрана и не прикасаясь вторым пальцем. Видимо, у тебя другой опыт...
>>835911
А ты пробовал подождать? У меня не сразу начинается: сначала чернота и циклоп несколько секунд, только потом появляется локация и правильный персонаж (в смысле, если выбрал не циклопа). Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.
Ты за тредом не следил вообще? ОП же писал с самого начала, что у него фокус на расчленёнке. С таким подходом общий пул здоровья не имеет смысла, нужно следить за здоровьем каждой части тела.
>>835912
Глянул порт, на андроид предлагают виртуальную клавиатуру и набирать на ней сочетания клавиш. Ну уж нет, какой бы там геймплей ни был, такие извращения я не люблю ни на компьютере, ни тем более на телефоне. Я считаю, что богатый геймплей можно совместить с простым управлением, не создавая сотни шорткатов на клавиатуру для примитивных действий. Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.
>>835914
Совершенно непонятно даже то, что это на самом деле кнопки, а не какие-то декоративные спрайты или плейсхолдеры для будущих функций (типа статусные эффекты). У тебя во всей игре кнопки выглядят как коричневые прямоугольники, а тут внезапно цветные иконки даже без рамки. Как я должен понять, что это кнопка? Алсо, раз уж ты занял весь экран инвентарём, мог бы сделать обычные чекбоксы с текстом, а не какие-то огромные иконки.
Либо у тебя компьютер очень быстрый, либо кэш на диске помогает игре быстрее стартовать. Попробуй удалить кэш или запустить игру на виртуальной машине, особенно на искусственно замедленной, чтобы оценить процесс загрузки на слабом компьютере. Oracle VM VirtualBox бесплатная и её легко настроить.
>>835934
У меня это каждый раз. Нужно просто подождать, пока игра что-то там сделает, потом она автоматически закинет тебя в локацию и исправит интерфейс.
>>835935 >>836027
Зачем вы ему эту гадость советуете, "x2/x3" - это как те два стула, на одном двойки точёные, на другом тройки дрочёные. У него не пиксель-перфект графика, так что он может спокойно забить болт на пиксели и приближать камеру с минимальным шагом. Чем меньше шаг, тем плавнее и удобнее будет настройка.
>Промахнуться нажатием легче, чем скорректировать движение пальца
Нажатием промахнуться можно только если кнопки чрезвычайно мелкие по сравнению с физическим размером экрана. Если гуй прибит гвоздями как у ОПа - это проблема, но хороший гуй должен подстраиваться и делать кнопки оптимального размера. Плюс в настройках обычно можно изменить масштабирование.
У перетаскивания два косяка.
Во-первых, если предмет ТОЧНО ПОД ПАЛЬЦЕМ, ты со своими сосисками не видишь, куда именно роняешь предмет, т.к. предмет не видишь. На первый взгляд, это возможно пофиксить смещением точки захвата от пальца, но тут возникает вопрос - каким пальцем пользователь ведёт по экрану? Может, правым, может, левым, а может вообще сверху экрана рука висит (если горизонтальная ориентация, такое вполне возможно и иногда удобно). Т.е. эта проблема куда сложнее, чем кажется.
Во-вторых, даже самые лучшие сенсорные дисплеи могут ошибаться, особенно если телефон нагрелся во время игры и руки вспотели. У меня неоднократно бывало в самых разных играх и на разных смартфонах, что я не могу с первой попытки перенести предмет, т.к. он роняется раньше времени или не цепляется вообще. А современные "безрамочные" смартфоны ухудшают проблему - теперь ты можешь неосознанно нажимать на край экрана, вызывая непредсказуемые глюки в игре. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает, потому что у дисплея сейчас 5-10+ точек контакта и каждая из них регистрируется как независимый "клик", позволяя наплевать на многие ошибки. Т.е. у тебя выше шанс правильно переместить предмет кликом, чем если тебя заставляют вести палец через всю твою лопату, ни в коем случае не отрывая от экрана и не прикасаясь вторым пальцем. Видимо, у тебя другой опыт...
>>835911
>при старте комнаты камера спавнится в темном месте и приходится рестартить игру
А ты пробовал подождать? У меня не сразу начинается: сначала чернота и циклоп несколько секунд, только потом появляется локация и правильный персонаж (в смысле, если выбрал не циклопа). Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.
>Где моё здоровье?
Ты за тредом не следил вообще? ОП же писал с самого начала, что у него фокус на расчленёнке. С таким подходом общий пул здоровья не имеет смысла, нужно следить за здоровьем каждой части тела.
>>835912
>DCSS
Глянул порт, на андроид предлагают виртуальную клавиатуру и набирать на ней сочетания клавиш. Ну уж нет, какой бы там геймплей ни был, такие извращения я не люблю ни на компьютере, ни тем более на телефоне. Я считаю, что богатый геймплей можно совместить с простым управлением, не создавая сотни шорткатов на клавиатуру для примитивных действий. Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.
>>835914
>А что, действительно непонятно что это?
Совершенно непонятно даже то, что это на самом деле кнопки, а не какие-то декоративные спрайты или плейсхолдеры для будущих функций (типа статусные эффекты). У тебя во всей игре кнопки выглядят как коричневые прямоугольники, а тут внезапно цветные иконки даже без рамки. Как я должен понять, что это кнопка? Алсо, раз уж ты занял весь экран инвентарём, мог бы сделать обычные чекбоксы с текстом, а не какие-то огромные иконки.
>То что ты описываешь при старте, это и правда какой-то загадочный баг, я такого не встречал.
Либо у тебя компьютер очень быстрый, либо кэш на диске помогает игре быстрее стартовать. Попробуй удалить кэш или запустить игру на виртуальной машине, особенно на искусственно замедленной, чтобы оценить процесс загрузки на слабом компьютере. Oracle VM VirtualBox бесплатная и её легко настроить.
>>835934
>Вот скрин Бага
>Он при первом же запуске вылез.
У меня это каждый раз. Нужно просто подождать, пока игра что-то там сделает, потом она автоматически закинет тебя в локацию и исправит интерфейс.
>>835935 >>836027
Зачем вы ему эту гадость советуете, "x2/x3" - это как те два стула, на одном двойки точёные, на другом тройки дрочёные. У него не пиксель-перфект графика, так что он может спокойно забить болт на пиксели и приближать камеру с минимальным шагом. Чем меньше шаг, тем плавнее и удобнее будет настройка.
>>836069
Вообще ничем не поможет в твоем случае с перегревом. Ну кликнул ты и ничего не произошло, потому что клик сработал не там. Только у тебя еще и визуального фидбека не будет, потому что при таскании ты хотя бы выдишь насколько мимо тащится.
>. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает,
Вообще ничем не поможет в твоем случае с перегревом. Ну кликнул ты и ничего не произошло, потому что клик сработал не там. Только у тебя еще и визуального фидбека не будет, потому что при таскании ты хотя бы выдишь насколько мимо тащится.
>>835914 >>835934
ОП, рекомендую нарисовать один универсальный схематичный индикатор для всех персонажей, по крайней мере для всех гуманоидов, в примитивном стиле квадратиков и прямоугольников, чтобы очертания были чётко узнаваемы, части тела чётко различимы и цвета не смешивались в грязь из-за спрайта персонажа. Видел такое в каких-то играх, хотя намного чаще такие индикаторы используют для машин (автомобиль, танк и т.п.). Во-первых, такой индикатор будет читабельнее, во-вторых, он будет сразу ассоциироваться с уровнем здрровья за счёт визуального подобия зелёной шкале. Тебе в любом случае нет смысла рендерить персонажа повторно, когда он уже есть на экране. В инвентаре можешь оставить как есть или разделить схему-индикатор и спрайты персонажа. Хотя я понимаю, что текущий индикатор универсален, но его читабельность сомнительна.
Впрочем, лично я сразу понял, что это индикатор здоровья каждой части тела, скорее всего благодаря опыту игры в игры с похожим индикатором. Но большинство людей не сталкивались с такими индикаторами, привыкнув к абстрактным очкам здоровья персонажа.
Также можно предоставить выбор типа индикатора в настройках игры, как сделали в Terraria, хотя там ситуация намного проще была (изначально были сердечки вместо классической ровной шкалы, но потом добавили опцию для выбора ровной шкалы). Типа выбор между красивой, но плохо читаемой, и примитивной, но намного лучше читаемой версией индикатора.
>Лучше б это числовая шкала была, или что-то вроде портрета в doom, а то сейчас это непонятно.
ОП, рекомендую нарисовать один универсальный схематичный индикатор для всех персонажей, по крайней мере для всех гуманоидов, в примитивном стиле квадратиков и прямоугольников, чтобы очертания были чётко узнаваемы, части тела чётко различимы и цвета не смешивались в грязь из-за спрайта персонажа. Видел такое в каких-то играх, хотя намного чаще такие индикаторы используют для машин (автомобиль, танк и т.п.). Во-первых, такой индикатор будет читабельнее, во-вторых, он будет сразу ассоциироваться с уровнем здрровья за счёт визуального подобия зелёной шкале. Тебе в любом случае нет смысла рендерить персонажа повторно, когда он уже есть на экране. В инвентаре можешь оставить как есть или разделить схему-индикатор и спрайты персонажа. Хотя я понимаю, что текущий индикатор универсален, но его читабельность сомнительна.
Впрочем, лично я сразу понял, что это индикатор здоровья каждой части тела, скорее всего благодаря опыту игры в игры с похожим индикатором. Но большинство людей не сталкивались с такими индикаторами, привыкнув к абстрактным очкам здоровья персонажа.
Также можно предоставить выбор типа индикатора в настройках игры, как сделали в Terraria, хотя там ситуация намного проще была (изначально были сердечки вместо классической ровной шкалы, но потом добавили опцию для выбора ровной шкалы). Типа выбор между красивой, но плохо читаемой, и примитивной, но намного лучше читаемой версией индикатора.
>>836071
Как один раз кликнул, так и второй раз кликну.
Видел в нескольких мобильных играх искорки, падающие из места касания. На первый взгляд выглядит бесполезной фигнёй для маленьких девочек, но на практике это очень хорошо показывает, куда ты нажал. Легко адаптировать этот эффект для любой по сеттингу игры, сделав вместо цветных искорок, например, какие-нибудь брызги крови или клубы дыма, чтоб брутально выглядело.
"Насколько мимо"? На 100% мимо! Приходится возвращаться и тащить заново.
Вот у меня сейчас смартфон 6.5'', это 15x7см, если округлять. Игра заставляет меня перетаскивать предметы с одной стороны экрана на другую, это будет до 15 см в реальном мире. Я веду палец 10 см и предмет РОНЯЕТСЯ, нужно возвращаться и вести его снова, с того же места, в том же направлении. Единичные клики к таким косякам не приводят и не заставляют водить пальцем - более того, во многих случаях можно задействовать два пальца разных рук и вообще руками не двигать. А на планшете 10'' ещё хуже ситуация была, когда я пробовал играть, т.к. там вообще рукой махать нужно, чтобы "таскать" предметы. Я играть пытаюсь или гимнастикой занимаюсь?
Допускаю, что у тебя мелкий 3''-4'' дисплей, холодный процессор, всегда совершенно сухие руки и максимально холодный рассудок в совершенно любой игре, поэтому ты не испытываешь никаких проблем. Но для таких как я было бы желательно иметь альтернативный способ, как сделали в мобильном Minecraft: выбираешь предмет, потом выбираешь назначение. Я не говорю, что Майнкрафт идеален, меня этот менеджмент предметов раздражает в любой форме, но у него оптимальное для мобилок решение, в отличие от других игр (не буду называть).
>Ну кликнул ты и ничего не произошло, потому что клик сработал не там.
Как один раз кликнул, так и второй раз кликну.
>визуального фидбека не будет
Видел в нескольких мобильных играх искорки, падающие из места касания. На первый взгляд выглядит бесполезной фигнёй для маленьких девочек, но на практике это очень хорошо показывает, куда ты нажал. Легко адаптировать этот эффект для любой по сеттингу игры, сделав вместо цветных искорок, например, какие-нибудь брызги крови или клубы дыма, чтоб брутально выглядело.
>при таскании ты хотя бы выдишь насколько мимо тащится
"Насколько мимо"? На 100% мимо! Приходится возвращаться и тащить заново.
Вот у меня сейчас смартфон 6.5'', это 15x7см, если округлять. Игра заставляет меня перетаскивать предметы с одной стороны экрана на другую, это будет до 15 см в реальном мире. Я веду палец 10 см и предмет РОНЯЕТСЯ, нужно возвращаться и вести его снова, с того же места, в том же направлении. Единичные клики к таким косякам не приводят и не заставляют водить пальцем - более того, во многих случаях можно задействовать два пальца разных рук и вообще руками не двигать. А на планшете 10'' ещё хуже ситуация была, когда я пробовал играть, т.к. там вообще рукой махать нужно, чтобы "таскать" предметы. Я играть пытаюсь или гимнастикой занимаюсь?
Допускаю, что у тебя мелкий 3''-4'' дисплей, холодный процессор, всегда совершенно сухие руки и максимально холодный рассудок в совершенно любой игре, поэтому ты не испытываешь никаких проблем. Но для таких как я было бы желательно иметь альтернативный способ, как сделали в мобильном Minecraft: выбираешь предмет, потом выбираешь назначение. Я не говорю, что Майнкрафт идеален, меня этот менеджмент предметов раздражает в любой форме, но у него оптимальное для мобилок решение, в отличие от других игр (не буду называть).
>>836083
И третий, и четвертый...
По твоей же логике выше, искорка закрыта сосисочным пальцем.
Зачем? Пока ты не отпустил, предмет все еще под пальцем, не отпускай пока не убедишься что он над слотом.
Согласен, что мешает оба способа иметь.
>Как один раз кликнул, так и второй раз кликну.
И третий, и четвертый...
>Видел в нескольких мобильных играх искорки, падающие из места касания. На первый взгляд выглядит бесполезной фигнёй для маленьких девочек
По твоей же логике выше, искорка закрыта сосисочным пальцем.
> Приходится возвращаться и тащить заново.
Зачем? Пока ты не отпустил, предмет все еще под пальцем, не отпускай пока не убедишься что он над слотом.
> Но для таких как я было бы желательно иметь альтернативный способ
Согласен, что мешает оба способа иметь.
>>836069
Знаешь, если в игре нужно ждать прогрузки, то нужно добавить экран прогрузки, чтоб игрок не пялил в это штуку и не охреневал от происходящего.
Нет, не следил. Или играть в игру можно только тем, кто следил за тредом? Охуенный порог вхождения
Потому что это удобно. Управление колесиком не дает поставить нормальное разрешение, потому что им управлять невозможно. Не хочет? Это его дело, но вон скольким людям это не понравилось. И ещё большему количеству не понравится при выходе. Из-за этого дебилизма человек просто аудиторию потенциальную потеряет.
>Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.
Знаешь, если в игре нужно ждать прогрузки, то нужно добавить экран прогрузки, чтоб игрок не пялил в это штуку и не охреневал от происходящего.
>Ты за тредом не следил вообще?
Нет, не следил. Или играть в игру можно только тем, кто следил за тредом? Охуенный порог вхождения
>Зачем вы ему эту гадость советуете, "x2/x3"
Потому что это удобно. Управление колесиком не дает поставить нормальное разрешение, потому что им управлять невозможно. Не хочет? Это его дело, но вон скольким людям это не понравилось. И ещё большему количеству не понравится при выходе. Из-за этого дебилизма человек просто аудиторию потенциальную потеряет.
>>836069
Блин, только сейчас заметил. Только зря время на чтение твоих постов тратил.
>Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.
Блин, только сейчас заметил. Только зря время на чтение твоих постов тратил.
>>836095
Так в любом случае это быстрее, чем двигать пальцем через весь экран несколько раз подряд без результата.
Предмет ты удерживать должен и он мгновенно исчезает после отпускания, а эффект от касания сохраняется на какие-то доли секунды так, что можно разглядеть при необходимости.
Так я ж говорю, если произошёл сбой сенсора или ты сам случайно палец от экрана оторвал, предмет вернётся на место и придётся повторять операцию. Хуже всего, когда нужно таким образом много предметов переместить. Вот поэтому перемещение нажатием лучше.
А для ПК нужны шорткаты. Только ньюфаг будет мышкой таскать, продвинутые игроки прокликивают нужные предметы с shift/ctrl/alt. Таскание предметов мышкой только в первые часы игры кажется интересным, потом это тупо лишняя рутина.
>>836101
Там есть экран загрузки. Но после экрана загрузки игра по какой-то причине тупит несколько секунд, прежде чем наконец-то отобразит карту и правильную аватарку на индикаторе здоровья. Согласен, что экран загрузки должен висеть до тех пор, пока игра окончательно не прогрузит все ресурсы, и только потом исчезать.
Приведу пример: в Terraria можно настроить приближение камеры в сотых долях от x0.6 до x2.0. Графика выглядит нормально на любом значении, нет смысла округлять. А вот в Starbound дали три стула: x2, x3 и x4. Все три стула лично мне не подходят, и это невероятно бесит. Про x4 вообще молчу, x3 слишком близко, а x2 слишком далеко - мне бы хотелось что-то около x2.5, но его нет. Что толку от "пиксель-перфект", если приходится либо всматриваться в мелкие детали, либо терять область обзора?
Людям не понравилось то, что у него слишком мало подходящих уровней приближения, поэтому так сложно установить комфортное значение. А ты предлагаешь ещё больше ограничить, до двух значений.
>>836113
Рогалики рогаликам рознь, если рогалик выглядит и управляется как таблица в экселе, то это может быть замечательный рогалик, но плохая игра. Если я хочу поиграть в компьютерную игру, я хочу управлять персонажем, а не заниматься рассчётами в таблицах.
Даже управление самолётом можно сделать аркадным, а в некоторых играх управление человечком сложнее, чем настоящая приборная панель самолёта. Зачем? Что это даёт? Свободу действий? Так вся свобода заключается в том, чтобы зайти в подземелье и сдохнуть.
>И третий, и четвертый
Так в любом случае это быстрее, чем двигать пальцем через весь экран несколько раз подряд без результата.
>искорка закрыта сосисочным пальцем
Предмет ты удерживать должен и он мгновенно исчезает после отпускания, а эффект от касания сохраняется на какие-то доли секунды так, что можно разглядеть при необходимости.
>Пока ты не отпустил
Так я ж говорю, если произошёл сбой сенсора или ты сам случайно палец от экрана оторвал, предмет вернётся на место и придётся повторять операцию. Хуже всего, когда нужно таким образом много предметов переместить. Вот поэтому перемещение нажатием лучше.
А для ПК нужны шорткаты. Только ньюфаг будет мышкой таскать, продвинутые игроки прокликивают нужные предметы с shift/ctrl/alt. Таскание предметов мышкой только в первые часы игры кажется интересным, потом это тупо лишняя рутина.
>>836101
>добавить экран прогрузки
Там есть экран загрузки. Но после экрана загрузки игра по какой-то причине тупит несколько секунд, прежде чем наконец-то отобразит карту и правильную аватарку на индикаторе здоровья. Согласен, что экран загрузки должен висеть до тех пор, пока игра окончательно не прогрузит все ресурсы, и только потом исчезать.
>Потому что это удобно. Управление колесиком не дает поставить нормальное разрешение
Приведу пример: в Terraria можно настроить приближение камеры в сотых долях от x0.6 до x2.0. Графика выглядит нормально на любом значении, нет смысла округлять. А вот в Starbound дали три стула: x2, x3 и x4. Все три стула лично мне не подходят, и это невероятно бесит. Про x4 вообще молчу, x3 слишком близко, а x2 слишком далеко - мне бы хотелось что-то около x2.5, но его нет. Что толку от "пиксель-перфект", если приходится либо всматриваться в мелкие детали, либо терять область обзора?
>скольким людям это не понравилось
Людям не понравилось то, что у него слишком мало подходящих уровней приближения, поэтому так сложно установить комфортное значение. А ты предлагаешь ещё больше ограничить, до двух значений.
>>836113
Рогалики рогаликам рознь, если рогалик выглядит и управляется как таблица в экселе, то это может быть замечательный рогалик, но плохая игра. Если я хочу поиграть в компьютерную игру, я хочу управлять персонажем, а не заниматься рассчётами в таблицах.
Даже управление самолётом можно сделать аркадным, а в некоторых играх управление человечком сложнее, чем настоящая приборная панель самолёта. Зачем? Что это даёт? Свободу действий? Так вся свобода заключается в том, чтобы зайти в подземелье и сдохнуть.
>>836095
Так в любом случае это быстрее, чем двигать пальцем через весь экран несколько раз подряд без результата.
Предмет ты удерживать должен и он мгновенно исчезает после отпускания, а эффект от касания сохраняется на какие-то доли секунды так, что можно разглядеть при необходимости.
Так я ж говорю, если произошёл сбой сенсора или ты сам случайно палец от экрана оторвал, предмет вернётся на место и придётся повторять операцию. Хуже всего, когда нужно таким образом много предметов переместить. Вот поэтому перемещение нажатием лучше.
А для ПК нужны шорткаты. Только ньюфаг будет мышкой таскать, продвинутые игроки прокликивают нужные предметы с shift/ctrl/alt. Таскание предметов мышкой только в первые часы игры кажется интересным, потом это тупо лишняя рутина.
>>836101
Там есть экран загрузки. Но после экрана загрузки игра по какой-то причине тупит несколько секунд, прежде чем наконец-то отобразит карту и правильную аватарку на индикаторе здоровья. Согласен, что экран загрузки должен висеть до тех пор, пока игра окончательно не прогрузит все ресурсы, и только потом исчезать.
Приведу пример: в Terraria можно настроить приближение камеры в сотых долях от x0.6 до x2.0. Графика выглядит нормально на любом значении, нет смысла округлять. А вот в Starbound дали три стула: x2, x3 и x4. Все три стула лично мне не подходят, и это невероятно бесит. Про x4 вообще молчу, x3 слишком близко, а x2 слишком далеко - мне бы хотелось что-то около x2.5, но его нет. Что толку от "пиксель-перфект", если приходится либо всматриваться в мелкие детали, либо терять область обзора?
Людям не понравилось то, что у него слишком мало подходящих уровней приближения, поэтому так сложно установить комфортное значение. А ты предлагаешь ещё больше ограничить, до двух значений.
>>836113
Рогалики рогаликам рознь, если рогалик выглядит и управляется как таблица в экселе, то это может быть замечательный рогалик, но плохая игра. Если я хочу поиграть в компьютерную игру, я хочу управлять персонажем, а не заниматься рассчётами в таблицах.
Даже управление самолётом можно сделать аркадным, а в некоторых играх управление человечком сложнее, чем настоящая приборная панель самолёта. Зачем? Что это даёт? Свободу действий? Так вся свобода заключается в том, чтобы зайти в подземелье и сдохнуть.
>И третий, и четвертый
Так в любом случае это быстрее, чем двигать пальцем через весь экран несколько раз подряд без результата.
>искорка закрыта сосисочным пальцем
Предмет ты удерживать должен и он мгновенно исчезает после отпускания, а эффект от касания сохраняется на какие-то доли секунды так, что можно разглядеть при необходимости.
>Пока ты не отпустил
Так я ж говорю, если произошёл сбой сенсора или ты сам случайно палец от экрана оторвал, предмет вернётся на место и придётся повторять операцию. Хуже всего, когда нужно таким образом много предметов переместить. Вот поэтому перемещение нажатием лучше.
А для ПК нужны шорткаты. Только ньюфаг будет мышкой таскать, продвинутые игроки прокликивают нужные предметы с shift/ctrl/alt. Таскание предметов мышкой только в первые часы игры кажется интересным, потом это тупо лишняя рутина.
>>836101
>добавить экран прогрузки
Там есть экран загрузки. Но после экрана загрузки игра по какой-то причине тупит несколько секунд, прежде чем наконец-то отобразит карту и правильную аватарку на индикаторе здоровья. Согласен, что экран загрузки должен висеть до тех пор, пока игра окончательно не прогрузит все ресурсы, и только потом исчезать.
>Потому что это удобно. Управление колесиком не дает поставить нормальное разрешение
Приведу пример: в Terraria можно настроить приближение камеры в сотых долях от x0.6 до x2.0. Графика выглядит нормально на любом значении, нет смысла округлять. А вот в Starbound дали три стула: x2, x3 и x4. Все три стула лично мне не подходят, и это невероятно бесит. Про x4 вообще молчу, x3 слишком близко, а x2 слишком далеко - мне бы хотелось что-то около x2.5, но его нет. Что толку от "пиксель-перфект", если приходится либо всматриваться в мелкие детали, либо терять область обзора?
>скольким людям это не понравилось
Людям не понравилось то, что у него слишком мало подходящих уровней приближения, поэтому так сложно установить комфортное значение. А ты предлагаешь ещё больше ограничить, до двух значений.
>>836113
Рогалики рогаликам рознь, если рогалик выглядит и управляется как таблица в экселе, то это может быть замечательный рогалик, но плохая игра. Если я хочу поиграть в компьютерную игру, я хочу управлять персонажем, а не заниматься рассчётами в таблицах.
Даже управление самолётом можно сделать аркадным, а в некоторых играх управление человечком сложнее, чем настоящая приборная панель самолёта. Зачем? Что это даёт? Свободу действий? Так вся свобода заключается в том, чтобы зайти в подземелье и сдохнуть.
>>836151
Да пусть у него хоть миллион уровней приближения сделает. Колесиком тупо неудобно этим управлять. Нужна наглядная шкала, где пользователь будет видить и настраиваиь уровень приближения как в той же террарии или кнопки, которые будут за нажатие прибавлять и отнимать фиксированное значение.
Колесиком же настроить камеру можно только примерно, да и то, это заставляет поебаться, чтобы даже примерно комфортную величину выставить.
Да пусть у него хоть миллион уровней приближения сделает. Колесиком тупо неудобно этим управлять. Нужна наглядная шкала, где пользователь будет видить и настраиваиь уровень приближения как в той же террарии или кнопки, которые будут за нажатие прибавлять и отнимать фиксированное значение.
Колесиком же настроить камеру можно только примерно, да и то, это заставляет поебаться, чтобы даже примерно комфортную величину выставить.
>>836064
интересно что у многих из вас беда с разрешением, но при этом у всех немного по разному. Ничего, это решаемо.
Такое управление было в более старых версиях, правда не WASD а QWEASDZX. Не знаю... мне было не очень удобно. Мне и в классических рогаликах это никогда не нравилось.
Да, нужно сделать несколько режимов управления, и такой и такой. Это решит проблему.
Тему с задержкой wasd'a я бы не стал пробовать. Я просто представляю как у кого-нибудь после 5 минут обдумывания следующего хода соскальзывает палец и он идет не направо вверх, а просто вверх. А в нашем жанре слишком велика цена любой ошибки. Если бы в DCSS такое было, игроки бы горели знатно.
Ну вообще, одно из моих любимых развлечений - накатывать какой-нибудь хардкор-модпак на игру, ставить максимальную сложность и пытаться пройти ее без смертей. Всякие скайрим-реквиемы, мизери-сталкеры, дарк соулсыобычные, майнкрафт с отключенной регенерацией, вот это все.
Видимо, далеко не всем такое заходит)
Ну да, я имею в виду случайно.
Да, полезная штука. Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Раньше у меня была система с зависимостью скорости действий от здоровья. Это было на удивление брутально. На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
...но, к сожалению, абсолютно неиграбельно.
Вот это, кстати, классно ты придумал. Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
Наверно мне стоит пока просто сделать его бесконечным, ввести вес и посмотреть как это будет выглядеть.
Потом мб сделать вместо сетки список. Я так понимаю, во всех играх от Бесезды инвентари со списком.
Надо еще подумать над этим.
Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь. Типо как в Dayz или рогалике Stone Shard. Я уверен что есть куча народу кому это категорически не нравится, но мне обычно заходило когда такое встречал.
- Оп
>разрешение
интересно что у многих из вас беда с разрешением, но при этом у всех немного по разному. Ничего, это решаемо.
>Wasd
Такое управление было в более старых версиях, правда не WASD а QWEASDZX. Не знаю... мне было не очень удобно. Мне и в классических рогаликах это никогда не нравилось.
Да, нужно сделать несколько режимов управления, и такой и такой. Это решит проблему.
Тему с задержкой wasd'a я бы не стал пробовать. Я просто представляю как у кого-нибудь после 5 минут обдумывания следующего хода соскальзывает палец и он идет не направо вверх, а просто вверх. А в нашем жанре слишком велика цена любой ошибки. Если бы в DCSS такое было, игроки бы горели знатно.
>Фан
Ну вообще, одно из моих любимых развлечений - накатывать какой-нибудь хардкор-модпак на игру, ставить максимальную сложность и пытаться пройти ее без смертей. Всякие скайрим-реквиемы, мизери-сталкеры, дарк соулсыобычные, майнкрафт с отключенной регенерацией, вот это все.
Видимо, далеко не всем такое заходит)
>двумя точными ударами
Ну да, я имею в виду случайно.
>таймер
Да, полезная штука. Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Раньше у меня была система с зависимостью скорости действий от здоровья. Это было на удивление брутально. На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
...но, к сожалению, абсолютно неиграбельно.
>Проча еды
Вот это, кстати, классно ты придумал. Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
>инвентарь
Наверно мне стоит пока просто сделать его бесконечным, ввести вес и посмотреть как это будет выглядеть.
Потом мб сделать вместо сетки список. Я так понимаю, во всех играх от Бесезды инвентари со списком.
Надо еще подумать над этим.
Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь. Типо как в Dayz или рогалике Stone Shard. Я уверен что есть куча народу кому это категорически не нравится, но мне обычно заходило когда такое встречал.
- Оп
>>836064
интересно что у многих из вас беда с разрешением, но при этом у всех немного по разному. Ничего, это решаемо.
Такое управление было в более старых версиях, правда не WASD а QWEASDZX. Не знаю... мне было не очень удобно. Мне и в классических рогаликах это никогда не нравилось.
Да, нужно сделать несколько режимов управления, и такой и такой. Это решит проблему.
Тему с задержкой wasd'a я бы не стал пробовать. Я просто представляю как у кого-нибудь после 5 минут обдумывания следующего хода соскальзывает палец и он идет не направо вверх, а просто вверх. А в нашем жанре слишком велика цена любой ошибки. Если бы в DCSS такое было, игроки бы горели знатно.
Ну вообще, одно из моих любимых развлечений - накатывать какой-нибудь хардкор-модпак на игру, ставить максимальную сложность и пытаться пройти ее без смертей. Всякие скайрим-реквиемы, мизери-сталкеры, дарк соулсыобычные, майнкрафт с отключенной регенерацией, вот это все.
Видимо, далеко не всем такое заходит)
Ну да, я имею в виду случайно.
Да, полезная штука. Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Раньше у меня была система с зависимостью скорости действий от здоровья. Это было на удивление брутально. На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
...но, к сожалению, абсолютно неиграбельно.
Вот это, кстати, классно ты придумал. Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
Наверно мне стоит пока просто сделать его бесконечным, ввести вес и посмотреть как это будет выглядеть.
Потом мб сделать вместо сетки список. Я так понимаю, во всех играх от Бесезды инвентари со списком.
Надо еще подумать над этим.
Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь. Типо как в Dayz или рогалике Stone Shard. Я уверен что есть куча народу кому это категорически не нравится, но мне обычно заходило когда такое встречал.
- Оп
>разрешение
интересно что у многих из вас беда с разрешением, но при этом у всех немного по разному. Ничего, это решаемо.
>Wasd
Такое управление было в более старых версиях, правда не WASD а QWEASDZX. Не знаю... мне было не очень удобно. Мне и в классических рогаликах это никогда не нравилось.
Да, нужно сделать несколько режимов управления, и такой и такой. Это решит проблему.
Тему с задержкой wasd'a я бы не стал пробовать. Я просто представляю как у кого-нибудь после 5 минут обдумывания следующего хода соскальзывает палец и он идет не направо вверх, а просто вверх. А в нашем жанре слишком велика цена любой ошибки. Если бы в DCSS такое было, игроки бы горели знатно.
>Фан
Ну вообще, одно из моих любимых развлечений - накатывать какой-нибудь хардкор-модпак на игру, ставить максимальную сложность и пытаться пройти ее без смертей. Всякие скайрим-реквиемы, мизери-сталкеры, дарк соулсыобычные, майнкрафт с отключенной регенерацией, вот это все.
Видимо, далеко не всем такое заходит)
>двумя точными ударами
Ну да, я имею в виду случайно.
>таймер
Да, полезная штука. Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Раньше у меня была система с зависимостью скорости действий от здоровья. Это было на удивление брутально. На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
...но, к сожалению, абсолютно неиграбельно.
>Проча еды
Вот это, кстати, классно ты придумал. Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
>инвентарь
Наверно мне стоит пока просто сделать его бесконечным, ввести вес и посмотреть как это будет выглядеть.
Потом мб сделать вместо сетки список. Я так понимаю, во всех играх от Бесезды инвентари со списком.
Надо еще подумать над этим.
Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь. Типо как в Dayz или рогалике Stone Shard. Я уверен что есть куча народу кому это категорически не нравится, но мне обычно заходило когда такое встречал.
- Оп
>>836069
Как интересно. У меня все почти моментально грузится. Ну за секунду-полторы. Причем без разницы, на основном компе или на соседнем некро-компе. И там и там они лежат на HDD.
А что там за кэш я хз. По идее я же каждый раз новый билд делаю, не должно такого быть.
Реально надо виртуальную машину накатить.
- Оп
>Баг при старте.
Как интересно. У меня все почти моментально грузится. Ну за секунду-полторы. Причем без разницы, на основном компе или на соседнем некро-компе. И там и там они лежат на HDD.
А что там за кэш я хз. По идее я же каждый раз новый билд делаю, не должно такого быть.
Реально надо виртуальную машину накатить.
- Оп
>>836161
Это раздел разработчиков игр. Здесь не только игроки сидят. Если ты никогда не видел нормального зума в играх, это не значит, что его в принципе невозможно сделать. Вот, сегодня просто сел и накидал сравнительно удобный зум колёсиком, позволяющий установить точные значения с достаточно маленьким шагом (отдельный шаг для >x1 и <x1).
>>836226
Потому что у всех разные мониторы, а ты захардкодил игру под свой монитор, не задумываясь о зоопарке возможных на сегодняшний день устройств. Кстати, это касается не только разрешений, но и контраста графики - если у тебя IPS/VA/OLED да ещё и яркость подсветки установлена высоко, то у тебя более контрастная картинка, чем на обычных дешёвых LCD (а я ещё яркость снижаю, потому что глаза от яркого света болят). Поэтому у тебя такие грязно-коричневые нечитаемые кнопки, которые тебе, видимо, кажутся нормальными благодаря монитору. Погугли про веб-палитру и почему она появилась - вот с играми, к сожалению, похожая тема.
Разное соотношение сторон. У меня 16:10, у того анона что-то близкое к 16:9, но не совсем. Какое у тебя соотношение сторон, на каком разрешении тестируешь игру? По-моему, ты давно не выкладывал полных скриншотов своей игры со своего монтооа, всё время какие-то обрезки. В юнити так сложно реализовать функцию создания скриншотов? В Godot это в пару строк делается.
Тогда нумпад. Владельцы обрезков клавиатуры пусть кусают локти и покупают отдельный нумпад))))
Не люблю непрерывное высокое напряжение. Когда встречаешь босса - ок, иногда адреналин приятно получать. Но испытывать напряжение на каждом шагу, перед каждым тривиальным действием - не ок. Должны быть моменты адреналина и моменты расслабления, а "хардкорные" игры - это, как правило, адреналин 100% времени, не дают расслабиться. У меня низкая выносливость и я не могу долго на адреналине играть, а после чувствую себя выжатым лимоном. При этом в условно спокойные игры могу играть много часов подряд, иногда более 12 часов почти без перерывов. Так что внезапная смерть на первом уровне - бред, лучше побродить несколько часов и собрать снаряжение, а затем тактически разобрать босса, чем играть в усложнённую версию русской рулетки. Впрочем, я могу понять людей, которые тратят в день на игру не больше часа и поэтому предпочитают максимально сложные игры, чтобы сразу получить дозу адреналина, без многочасовой подготовки...
Понятно, я не заметил/не разглядел. Теперь вижу. Важные индикаторы должны быть контрастными, как, собственно, и любые другие важные GUI элементы. А то получается будто бы ты специально прячешь эти элементы.
Ну дык, не доводи героя до минимального здоровья и будет играбельно, лол. Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира. https://youtu.be/6darJMyrAE8
Я думаю, если увеличить ХП в два раза, но при этом ниже 50% будет постепенно увеличиваться штраф на важные параметры - будет нормально. Игрок после нескольких смертей от штрафов смекнёт, что ниже 50% опускать здоровье нельзя, и будет играть аккуратнее. Главное чтобы мобы реже ганкали (gank = gang killing), ну серьёзно, хотя бы новичка (0-1-2 этажи) пожалей.
А разве в рогаликах редко встречается механика голода и/или порчи еды? Я думал, это норма для жанра. Типа прародитель выживалок (Survival) как жанра, только в выживалках обычно бесконечное число жизней.
Можно добавить спавн мобов со временем. Типа чем дольше игрок задерживается на уровне, тем больше монстров там появляется. Если успел по-быстрому найти выход - тебе повезло, иначе придётся пробиваться с боем. Главное хорошо сбалансировать, чтобы уровень не превращался в непроходимую толпу. И ещё чтобы монстры теряли интерес, если преследуют слишком долго (как если бы у них была энергия/усталость и чувство лени). А ещё можно сделать рост растений и/или "порчи" (Terraria).
Да, знаю. Система сложная для реализации, сложная для управления. Да, я уверен, что многим не нравится, т.к. вынуждает ещё больше времени проводить за сортировкой предметов в инвентаре, а не за игрой. Типа, ты зашёл в "3D экшон сурвайвол суть такова", но вместо экшена 90% времени стоишь на месте и сортируешь лут, чтобы впихнуть в рюкзак побольше ценных предметов. Как будто мало игроку разбираться с бардаком в реальности (если бы я хотел сортировать вещи, я бы убрался в комнате или разобрался бы с файлами на диске)...
>>836229
У меня SSD. Дело явно не в скорости диска, поскольку игра очень маленькая по весу файлов. Скорее всего дело в выделении памяти под спрайты или что-то в этом роде. Говорю же, запусти игру на медленной виртуальной машине и замерь через логи время каждого шага - имхо, это полезнее графиков в юнити на быстрой машине.
Ну типа кэш шейдеров. Если у тебя много разных шейдеров, их компиляция может занять существенное время. Это объясняет задержку при первом запуске. Но у меня тормозит каждый раз.
>>836230
Ты правильно заметил, она БРОСАЕТСЯ в глаза. В буквальном смысле, лол.
Хорошая мысль, но это не отменяет необходимости в адекватном зуме. Зум + сдвиг мышкой (ПКМ). Всё равно у тебя поле обзора персонажа ограничено туманом войны, следовательно, нет причины запрещать игроку максимально свободный обзор одной только мышкой. Тогда и миникарта в принципе не нужна будет.
>>836231
Ясно, расходимся ещё на несколько месяцев?)
Шучу, это должно быть несложно реализовать в техническом плане. Сложно сбалансировать, чтобы не было меты "всегда бить только в голову" или чего-то в этом роде. Этим геймдизайнеры и занимаются, если я правильно понимаю, в своих табличках с формулами баланса.
Специально для ОПа записал летсплей, чтобы продемонстрировать количество багов на квадратный тайл земли в его игре. Первое видео с неправильной частотой кадров, т.к. OBS не хватало чего-то (во втором видео всё нормально), но я решил сохранить его, т.к. там удалось воспроизвести баг с жизнью после смерти - в самом конце уложил 3 скелетов своим трупом и потом скончался при попытке поесть (на undead лечение действует как отрава, всё по канону, спасибо за такое внимание к деталям даже в багах). Во втором видео несколько багов:
1. Игра крашнулась, когда я попытался открыть инвентарь в меню паузы.
2. При попытке БЕЗРУКNМ взять что-либо в "руки" всё управление теряется.
3. Удалось воспроизвести баг того анона со "спавном в тёмном месте". Это оказался независимый от загрузки баг, так что совет "подождать" тут не поможет.
4. Последующий старт котом - непобедимый спидран death% в 0.000 сек, ибо головы нет с самого начала.
Не понимаю, почему у тебя столько возмутительных багов? Понимаю мелкие косяки вроде наезжающей надписи в главном меню, но вот эти краши, ошибки во время загрузки и т.п. просто выводят из себя своей тупостью, будто ты не запускаешь свою игру. Такое ощущение, что ты игру не на самом популярном универсальном игровом движке делаешь, а пишешь с нуля на ассемблере. Не срача ради, но если Юнити настолько непослушная и непредсказуемая конкретно в твоих руках, лучше бы ты делал на Годо. Щас ты доиграешься со своими багами - я не выдержу и сделаю клон твоей игры на Годо быстрее тебя, и все люди будут играть в мою "Скотобазу", а не в твой "Катабазис". Фикси баги. Вот дебаггер, садись фикси. Дебаггером фикси.
>Да пусть у него хоть миллион уровней приближения сделает. Колесиком тупо неудобно этим управлять.
>Колесиком же настроить камеру можно только примерно, да и то, это заставляет поебаться, чтобы даже примерно комфортную величину выставить.
Это раздел разработчиков игр. Здесь не только игроки сидят. Если ты никогда не видел нормального зума в играх, это не значит, что его в принципе невозможно сделать. Вот, сегодня просто сел и накидал сравнительно удобный зум колёсиком, позволяющий установить точные значения с достаточно маленьким шагом (отдельный шаг для >x1 и <x1).
>>836226
>интересно что у многих из вас беда с разрешением
Потому что у всех разные мониторы, а ты захардкодил игру под свой монитор, не задумываясь о зоопарке возможных на сегодняшний день устройств. Кстати, это касается не только разрешений, но и контраста графики - если у тебя IPS/VA/OLED да ещё и яркость подсветки установлена высоко, то у тебя более контрастная картинка, чем на обычных дешёвых LCD (а я ещё яркость снижаю, потому что глаза от яркого света болят). Поэтому у тебя такие грязно-коричневые нечитаемые кнопки, которые тебе, видимо, кажутся нормальными благодаря монитору. Погугли про веб-палитру и почему она появилась - вот с играми, к сожалению, похожая тема.
>но при этом у всех немного по разному.
Разное соотношение сторон. У меня 16:10, у того анона что-то близкое к 16:9, но не совсем. Какое у тебя соотношение сторон, на каком разрешении тестируешь игру? По-моему, ты давно не выкладывал полных скриншотов своей игры со своего монтооа, всё время какие-то обрезки. В юнити так сложно реализовать функцию создания скриншотов? В Godot это в пару строк делается.
>Тему с задержкой wasd'a я бы не стал пробовать
Тогда нумпад. Владельцы обрезков клавиатуры пусть кусают локти и покупают отдельный нумпад))))
>ставить максимальную сложность и пытаться пройти ее без смертей.
Не люблю непрерывное высокое напряжение. Когда встречаешь босса - ок, иногда адреналин приятно получать. Но испытывать напряжение на каждом шагу, перед каждым тривиальным действием - не ок. Должны быть моменты адреналина и моменты расслабления, а "хардкорные" игры - это, как правило, адреналин 100% времени, не дают расслабиться. У меня низкая выносливость и я не могу долго на адреналине играть, а после чувствую себя выжатым лимоном. При этом в условно спокойные игры могу играть много часов подряд, иногда более 12 часов почти без перерывов. Так что внезапная смерть на первом уровне - бред, лучше побродить несколько часов и собрать снаряжение, а затем тактически разобрать босса, чем играть в усложнённую версию русской рулетки. Впрочем, я могу понять людей, которые тратят в день на игру не больше часа и поэтому предпочитают максимально сложные игры, чтобы сразу получить дозу адреналина, без многочасовой подготовки...
>Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Понятно, я не заметил/не разглядел. Теперь вижу. Важные индикаторы должны быть контрастными, как, собственно, и любые другие важные GUI элементы. А то получается будто бы ты специально прячешь эти элементы.
>На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
>неиграбельно
Ну дык, не доводи героя до минимального здоровья и будет играбельно, лол. Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира. https://youtu.be/6darJMyrAE8
Я думаю, если увеличить ХП в два раза, но при этом ниже 50% будет постепенно увеличиваться штраф на важные параметры - будет нормально. Игрок после нескольких смертей от штрафов смекнёт, что ниже 50% опускать здоровье нельзя, и будет играть аккуратнее. Главное чтобы мобы реже ганкали (gank = gang killing), ну серьёзно, хотя бы новичка (0-1-2 этажи) пожалей.
>>Порча еды
>Вот это, кстати, классно ты придумал.
А разве в рогаликах редко встречается механика голода и/или порчи еды? Я думал, это норма для жанра. Типа прародитель выживалок (Survival) как жанра, только в выживалках обычно бесконечное число жизней.
>Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
Можно добавить спавн мобов со временем. Типа чем дольше игрок задерживается на уровне, тем больше монстров там появляется. Если успел по-быстрому найти выход - тебе повезло, иначе придётся пробиваться с боем. Главное хорошо сбалансировать, чтобы уровень не превращался в непроходимую толпу. И ещё чтобы монстры теряли интерес, если преследуют слишком долго (как если бы у них была энергия/усталость и чувство лени). А ещё можно сделать рост растений и/или "порчи" (Terraria).
>Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь.
Да, знаю. Система сложная для реализации, сложная для управления. Да, я уверен, что многим не нравится, т.к. вынуждает ещё больше времени проводить за сортировкой предметов в инвентаре, а не за игрой. Типа, ты зашёл в "3D экшон сурвайвол суть такова", но вместо экшена 90% времени стоишь на месте и сортируешь лут, чтобы впихнуть в рюкзак побольше ценных предметов. Как будто мало игроку разбираться с бардаком в реальности (если бы я хотел сортировать вещи, я бы убрался в комнате или разобрался бы с файлами на диске)...
>>836229
>И там и там они лежат на HDD.
У меня SSD. Дело явно не в скорости диска, поскольку игра очень маленькая по весу файлов. Скорее всего дело в выделении памяти под спрайты или что-то в этом роде. Говорю же, запусти игру на медленной виртуальной машине и замерь через логи время каждого шага - имхо, это полезнее графиков в юнити на быстрой машине.
>А что там за кэш
Ну типа кэш шейдеров. Если у тебя много разных шейдеров, их компиляция может занять существенное время. Это объясняет задержку при первом запуске. Но у меня тормозит каждый раз.
>>836230
>Никогда бы не подумал что механика приближения будет так бросаться в глаза.
Ты правильно заметил, она БРОСАЕТСЯ в глаза. В буквальном смысле, лол.
>Мб неплохой идеей будет вообще привязать камеру не к игроку а к курсору.
Хорошая мысль, но это не отменяет необходимости в адекватном зуме. Зум + сдвиг мышкой (ПКМ). Всё равно у тебя поле обзора персонажа ограничено туманом войны, следовательно, нет причины запрещать игроку максимально свободный обзор одной только мышкой. Тогда и миникарта в принципе не нужна будет.
>>836231
>решил заняться системой прицельного битья
Ясно, расходимся ещё на несколько месяцев?)
Шучу, это должно быть несложно реализовать в техническом плане. Сложно сбалансировать, чтобы не было меты "всегда бить только в голову" или чего-то в этом роде. Этим геймдизайнеры и занимаются, если я правильно понимаю, в своих табличках с формулами баланса.
Специально для ОПа записал летсплей, чтобы продемонстрировать количество багов на квадратный тайл земли в его игре. Первое видео с неправильной частотой кадров, т.к. OBS не хватало чего-то (во втором видео всё нормально), но я решил сохранить его, т.к. там удалось воспроизвести баг с жизнью после смерти - в самом конце уложил 3 скелетов своим трупом и потом скончался при попытке поесть (на undead лечение действует как отрава, всё по канону, спасибо за такое внимание к деталям даже в багах). Во втором видео несколько багов:
1. Игра крашнулась, когда я попытался открыть инвентарь в меню паузы.
2. При попытке БЕЗРУКNМ взять что-либо в "руки" всё управление теряется.
3. Удалось воспроизвести баг того анона со "спавном в тёмном месте". Это оказался независимый от загрузки баг, так что совет "подождать" тут не поможет.
4. Последующий старт котом - непобедимый спидран death% в 0.000 сек, ибо головы нет с самого начала.
Не понимаю, почему у тебя столько возмутительных багов? Понимаю мелкие косяки вроде наезжающей надписи в главном меню, но вот эти краши, ошибки во время загрузки и т.п. просто выводят из себя своей тупостью, будто ты не запускаешь свою игру. Такое ощущение, что ты игру не на самом популярном универсальном игровом движке делаешь, а пишешь с нуля на ассемблере. Не срача ради, но если Юнити настолько непослушная и непредсказуемая конкретно в твоих руках, лучше бы ты делал на Годо. Щас ты доиграешься со своими багами - я не выдержу и сделаю клон твоей игры на Годо быстрее тебя, и все люди будут играть в мою "Скотобазу", а не в твой "Катабазис". Фикси баги. Вот дебаггер, садись фикси. Дебаггером фикси.
>>836161
Это раздел разработчиков игр. Здесь не только игроки сидят. Если ты никогда не видел нормального зума в играх, это не значит, что его в принципе невозможно сделать. Вот, сегодня просто сел и накидал сравнительно удобный зум колёсиком, позволяющий установить точные значения с достаточно маленьким шагом (отдельный шаг для >x1 и <x1).
>>836226
Потому что у всех разные мониторы, а ты захардкодил игру под свой монитор, не задумываясь о зоопарке возможных на сегодняшний день устройств. Кстати, это касается не только разрешений, но и контраста графики - если у тебя IPS/VA/OLED да ещё и яркость подсветки установлена высоко, то у тебя более контрастная картинка, чем на обычных дешёвых LCD (а я ещё яркость снижаю, потому что глаза от яркого света болят). Поэтому у тебя такие грязно-коричневые нечитаемые кнопки, которые тебе, видимо, кажутся нормальными благодаря монитору. Погугли про веб-палитру и почему она появилась - вот с играми, к сожалению, похожая тема.
Разное соотношение сторон. У меня 16:10, у того анона что-то близкое к 16:9, но не совсем. Какое у тебя соотношение сторон, на каком разрешении тестируешь игру? По-моему, ты давно не выкладывал полных скриншотов своей игры со своего монтооа, всё время какие-то обрезки. В юнити так сложно реализовать функцию создания скриншотов? В Godot это в пару строк делается.
Тогда нумпад. Владельцы обрезков клавиатуры пусть кусают локти и покупают отдельный нумпад))))
Не люблю непрерывное высокое напряжение. Когда встречаешь босса - ок, иногда адреналин приятно получать. Но испытывать напряжение на каждом шагу, перед каждым тривиальным действием - не ок. Должны быть моменты адреналина и моменты расслабления, а "хардкорные" игры - это, как правило, адреналин 100% времени, не дают расслабиться. У меня низкая выносливость и я не могу долго на адреналине играть, а после чувствую себя выжатым лимоном. При этом в условно спокойные игры могу играть много часов подряд, иногда более 12 часов почти без перерывов. Так что внезапная смерть на первом уровне - бред, лучше побродить несколько часов и собрать снаряжение, а затем тактически разобрать босса, чем играть в усложнённую версию русской рулетки. Впрочем, я могу понять людей, которые тратят в день на игру не больше часа и поэтому предпочитают максимально сложные игры, чтобы сразу получить дозу адреналина, без многочасовой подготовки...
Понятно, я не заметил/не разглядел. Теперь вижу. Важные индикаторы должны быть контрастными, как, собственно, и любые другие важные GUI элементы. А то получается будто бы ты специально прячешь эти элементы.
Ну дык, не доводи героя до минимального здоровья и будет играбельно, лол. Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира. https://youtu.be/6darJMyrAE8
Я думаю, если увеличить ХП в два раза, но при этом ниже 50% будет постепенно увеличиваться штраф на важные параметры - будет нормально. Игрок после нескольких смертей от штрафов смекнёт, что ниже 50% опускать здоровье нельзя, и будет играть аккуратнее. Главное чтобы мобы реже ганкали (gank = gang killing), ну серьёзно, хотя бы новичка (0-1-2 этажи) пожалей.
А разве в рогаликах редко встречается механика голода и/или порчи еды? Я думал, это норма для жанра. Типа прародитель выживалок (Survival) как жанра, только в выживалках обычно бесконечное число жизней.
Можно добавить спавн мобов со временем. Типа чем дольше игрок задерживается на уровне, тем больше монстров там появляется. Если успел по-быстрому найти выход - тебе повезло, иначе придётся пробиваться с боем. Главное хорошо сбалансировать, чтобы уровень не превращался в непроходимую толпу. И ещё чтобы монстры теряли интерес, если преследуют слишком долго (как если бы у них была энергия/усталость и чувство лени). А ещё можно сделать рост растений и/или "порчи" (Terraria).
Да, знаю. Система сложная для реализации, сложная для управления. Да, я уверен, что многим не нравится, т.к. вынуждает ещё больше времени проводить за сортировкой предметов в инвентаре, а не за игрой. Типа, ты зашёл в "3D экшон сурвайвол суть такова", но вместо экшена 90% времени стоишь на месте и сортируешь лут, чтобы впихнуть в рюкзак побольше ценных предметов. Как будто мало игроку разбираться с бардаком в реальности (если бы я хотел сортировать вещи, я бы убрался в комнате или разобрался бы с файлами на диске)...
>>836229
У меня SSD. Дело явно не в скорости диска, поскольку игра очень маленькая по весу файлов. Скорее всего дело в выделении памяти под спрайты или что-то в этом роде. Говорю же, запусти игру на медленной виртуальной машине и замерь через логи время каждого шага - имхо, это полезнее графиков в юнити на быстрой машине.
Ну типа кэш шейдеров. Если у тебя много разных шейдеров, их компиляция может занять существенное время. Это объясняет задержку при первом запуске. Но у меня тормозит каждый раз.
>>836230
Ты правильно заметил, она БРОСАЕТСЯ в глаза. В буквальном смысле, лол.
Хорошая мысль, но это не отменяет необходимости в адекватном зуме. Зум + сдвиг мышкой (ПКМ). Всё равно у тебя поле обзора персонажа ограничено туманом войны, следовательно, нет причины запрещать игроку максимально свободный обзор одной только мышкой. Тогда и миникарта в принципе не нужна будет.
>>836231
Ясно, расходимся ещё на несколько месяцев?)
Шучу, это должно быть несложно реализовать в техническом плане. Сложно сбалансировать, чтобы не было меты "всегда бить только в голову" или чего-то в этом роде. Этим геймдизайнеры и занимаются, если я правильно понимаю, в своих табличках с формулами баланса.
Специально для ОПа записал летсплей, чтобы продемонстрировать количество багов на квадратный тайл земли в его игре. Первое видео с неправильной частотой кадров, т.к. OBS не хватало чего-то (во втором видео всё нормально), но я решил сохранить его, т.к. там удалось воспроизвести баг с жизнью после смерти - в самом конце уложил 3 скелетов своим трупом и потом скончался при попытке поесть (на undead лечение действует как отрава, всё по канону, спасибо за такое внимание к деталям даже в багах). Во втором видео несколько багов:
1. Игра крашнулась, когда я попытался открыть инвентарь в меню паузы.
2. При попытке БЕЗРУКNМ взять что-либо в "руки" всё управление теряется.
3. Удалось воспроизвести баг того анона со "спавном в тёмном месте". Это оказался независимый от загрузки баг, так что совет "подождать" тут не поможет.
4. Последующий старт котом - непобедимый спидран death% в 0.000 сек, ибо головы нет с самого начала.
Не понимаю, почему у тебя столько возмутительных багов? Понимаю мелкие косяки вроде наезжающей надписи в главном меню, но вот эти краши, ошибки во время загрузки и т.п. просто выводят из себя своей тупостью, будто ты не запускаешь свою игру. Такое ощущение, что ты игру не на самом популярном универсальном игровом движке делаешь, а пишешь с нуля на ассемблере. Не срача ради, но если Юнити настолько непослушная и непредсказуемая конкретно в твоих руках, лучше бы ты делал на Годо. Щас ты доиграешься со своими багами - я не выдержу и сделаю клон твоей игры на Годо быстрее тебя, и все люди будут играть в мою "Скотобазу", а не в твой "Катабазис". Фикси баги. Вот дебаггер, садись фикси. Дебаггером фикси.
>Да пусть у него хоть миллион уровней приближения сделает. Колесиком тупо неудобно этим управлять.
>Колесиком же настроить камеру можно только примерно, да и то, это заставляет поебаться, чтобы даже примерно комфортную величину выставить.
Это раздел разработчиков игр. Здесь не только игроки сидят. Если ты никогда не видел нормального зума в играх, это не значит, что его в принципе невозможно сделать. Вот, сегодня просто сел и накидал сравнительно удобный зум колёсиком, позволяющий установить точные значения с достаточно маленьким шагом (отдельный шаг для >x1 и <x1).
>>836226
>интересно что у многих из вас беда с разрешением
Потому что у всех разные мониторы, а ты захардкодил игру под свой монитор, не задумываясь о зоопарке возможных на сегодняшний день устройств. Кстати, это касается не только разрешений, но и контраста графики - если у тебя IPS/VA/OLED да ещё и яркость подсветки установлена высоко, то у тебя более контрастная картинка, чем на обычных дешёвых LCD (а я ещё яркость снижаю, потому что глаза от яркого света болят). Поэтому у тебя такие грязно-коричневые нечитаемые кнопки, которые тебе, видимо, кажутся нормальными благодаря монитору. Погугли про веб-палитру и почему она появилась - вот с играми, к сожалению, похожая тема.
>но при этом у всех немного по разному.
Разное соотношение сторон. У меня 16:10, у того анона что-то близкое к 16:9, но не совсем. Какое у тебя соотношение сторон, на каком разрешении тестируешь игру? По-моему, ты давно не выкладывал полных скриншотов своей игры со своего монтооа, всё время какие-то обрезки. В юнити так сложно реализовать функцию создания скриншотов? В Godot это в пару строк делается.
>Тему с задержкой wasd'a я бы не стал пробовать
Тогда нумпад. Владельцы обрезков клавиатуры пусть кусают локти и покупают отдельный нумпад))))
>ставить максимальную сложность и пытаться пройти ее без смертей.
Не люблю непрерывное высокое напряжение. Когда встречаешь босса - ок, иногда адреналин приятно получать. Но испытывать напряжение на каждом шагу, перед каждым тривиальным действием - не ок. Должны быть моменты адреналина и моменты расслабления, а "хардкорные" игры - это, как правило, адреналин 100% времени, не дают расслабиться. У меня низкая выносливость и я не могу долго на адреналине играть, а после чувствую себя выжатым лимоном. При этом в условно спокойные игры могу играть много часов подряд, иногда более 12 часов почти без перерывов. Так что внезапная смерть на первом уровне - бред, лучше побродить несколько часов и собрать снаряжение, а затем тактически разобрать босса, чем играть в усложнённую версию русской рулетки. Впрочем, я могу понять людей, которые тратят в день на игру не больше часа и поэтому предпочитают максимально сложные игры, чтобы сразу получить дозу адреналина, без многочасовой подготовки...
>Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.
Понятно, я не заметил/не разглядел. Теперь вижу. Важные индикаторы должны быть контрастными, как, собственно, и любые другие важные GUI элементы. А то получается будто бы ты специально прячешь эти элементы.
>На низких хп было полное ощущение того что тебя избивают толпой катая по полу.
>неиграбельно
Ну дык, не доводи героя до минимального здоровья и будет играбельно, лол. Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира. https://youtu.be/6darJMyrAE8
Я думаю, если увеличить ХП в два раза, но при этом ниже 50% будет постепенно увеличиваться штраф на важные параметры - будет нормально. Игрок после нескольких смертей от штрафов смекнёт, что ниже 50% опускать здоровье нельзя, и будет играть аккуратнее. Главное чтобы мобы реже ганкали (gank = gang killing), ну серьёзно, хотя бы новичка (0-1-2 этажи) пожалей.
>>Порча еды
>Вот это, кстати, классно ты придумал.
А разве в рогаликах редко встречается механика голода и/или порчи еды? Я думал, это норма для жанра. Типа прародитель выживалок (Survival) как жанра, только в выживалках обычно бесконечное число жизней.
>Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.
Можно добавить спавн мобов со временем. Типа чем дольше игрок задерживается на уровне, тем больше монстров там появляется. Если успел по-быстрому найти выход - тебе повезло, иначе придётся пробиваться с боем. Главное хорошо сбалансировать, чтобы уровень не превращался в непроходимую толпу. И ещё чтобы монстры теряли интерес, если преследуют слишком долго (как если бы у них была энергия/усталость и чувство лени). А ещё можно сделать рост растений и/или "порчи" (Terraria).
>Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь.
Да, знаю. Система сложная для реализации, сложная для управления. Да, я уверен, что многим не нравится, т.к. вынуждает ещё больше времени проводить за сортировкой предметов в инвентаре, а не за игрой. Типа, ты зашёл в "3D экшон сурвайвол суть такова", но вместо экшена 90% времени стоишь на месте и сортируешь лут, чтобы впихнуть в рюкзак побольше ценных предметов. Как будто мало игроку разбираться с бардаком в реальности (если бы я хотел сортировать вещи, я бы убрался в комнате или разобрался бы с файлами на диске)...
>>836229
>И там и там они лежат на HDD.
У меня SSD. Дело явно не в скорости диска, поскольку игра очень маленькая по весу файлов. Скорее всего дело в выделении памяти под спрайты или что-то в этом роде. Говорю же, запусти игру на медленной виртуальной машине и замерь через логи время каждого шага - имхо, это полезнее графиков в юнити на быстрой машине.
>А что там за кэш
Ну типа кэш шейдеров. Если у тебя много разных шейдеров, их компиляция может занять существенное время. Это объясняет задержку при первом запуске. Но у меня тормозит каждый раз.
>>836230
>Никогда бы не подумал что механика приближения будет так бросаться в глаза.
Ты правильно заметил, она БРОСАЕТСЯ в глаза. В буквальном смысле, лол.
>Мб неплохой идеей будет вообще привязать камеру не к игроку а к курсору.
Хорошая мысль, но это не отменяет необходимости в адекватном зуме. Зум + сдвиг мышкой (ПКМ). Всё равно у тебя поле обзора персонажа ограничено туманом войны, следовательно, нет причины запрещать игроку максимально свободный обзор одной только мышкой. Тогда и миникарта в принципе не нужна будет.
>>836231
>решил заняться системой прицельного битья
Ясно, расходимся ещё на несколько месяцев?)
Шучу, это должно быть несложно реализовать в техническом плане. Сложно сбалансировать, чтобы не было меты "всегда бить только в голову" или чего-то в этом роде. Этим геймдизайнеры и занимаются, если я правильно понимаю, в своих табличках с формулами баланса.
Специально для ОПа записал летсплей, чтобы продемонстрировать количество багов на квадратный тайл земли в его игре. Первое видео с неправильной частотой кадров, т.к. OBS не хватало чего-то (во втором видео всё нормально), но я решил сохранить его, т.к. там удалось воспроизвести баг с жизнью после смерти - в самом конце уложил 3 скелетов своим трупом и потом скончался при попытке поесть (на undead лечение действует как отрава, всё по канону, спасибо за такое внимание к деталям даже в багах). Во втором видео несколько багов:
1. Игра крашнулась, когда я попытался открыть инвентарь в меню паузы.
2. При попытке БЕЗРУКNМ взять что-либо в "руки" всё управление теряется.
3. Удалось воспроизвести баг того анона со "спавном в тёмном месте". Это оказался независимый от загрузки баг, так что совет "подождать" тут не поможет.
4. Последующий старт котом - непобедимый спидран death% в 0.000 сек, ибо головы нет с самого начала.
Не понимаю, почему у тебя столько возмутительных багов? Понимаю мелкие косяки вроде наезжающей надписи в главном меню, но вот эти краши, ошибки во время загрузки и т.п. просто выводят из себя своей тупостью, будто ты не запускаешь свою игру. Такое ощущение, что ты игру не на самом популярном универсальном игровом движке делаешь, а пишешь с нуля на ассемблере. Не срача ради, но если Юнити настолько непослушная и непредсказуемая конкретно в твоих руках, лучше бы ты делал на Годо. Щас ты доиграешься со своими багами - я не выдержу и сделаю клон твоей игры на Годо быстрее тебя, и все люди будут играть в мою "Скотобазу", а не в твой "Катабазис". Фикси баги. Вот дебаггер, садись фикси. Дебаггером фикси.
>>836261
>>836261
Блин, я прямо чувствую страдание в этих скачках зума. Реально бросается. Я не знаю в чем дело, но у меня явно не так. Такое чувство что у меня какое-то менее чувствительно колесико на мышке, что-ли. Ну ладно, в любом случае переделаю это.
Да, кажется, в 0.51 я как-то разломал систему менюинга, что теперь можно открывать инвентарь во время паузы, ходить с открытым инвентарем и прочее. И ничего не протестил. Эх..
Можешь, кстати, пояснить мне немного за автоматическое тестирование? Стоит ли мне вкладываться в создание тестов для всего что есть в игре? Я как-то не оценил юнитевских тестов, там как я понял, нужно над каждым тестом вешать атрибут с номером, а потом если хочешь какой-то тест вставить в середину вся нумерация слетает, да и вообще довольно запарно их писать...
По поводу безголового кота, живого трупа-убийцы, а так же "темного места" я ничего не могу сказать. У меня почему-то такого не происходит, кот спавнится живым.Хотя и не на долго. Кот это все равно death%
Почему у меня такого почти нет, а у многих анонов при каждом запуске происходит я не понимаю.
Тут были бы полезны логи.
Вообщем да, пристыдили меня эти летсплеи. Дождись лучше следующего билда, где я починю хотя-бы часть, а то реально больно смотреть)
А на годот я не пойду, бесполезно это предлагать. Переход на новый движок еще год займет. Я уж лучше как-нибудь тут.
>>836261
Блин, я прямо чувствую страдание в этих скачках зума. Реально бросается. Я не знаю в чем дело, но у меня явно не так. Такое чувство что у меня какое-то менее чувствительно колесико на мышке, что-ли. Ну ладно, в любом случае переделаю это.
Да, кажется, в 0.51 я как-то разломал систему менюинга, что теперь можно открывать инвентарь во время паузы, ходить с открытым инвентарем и прочее. И ничего не протестил. Эх..
Можешь, кстати, пояснить мне немного за автоматическое тестирование? Стоит ли мне вкладываться в создание тестов для всего что есть в игре? Я как-то не оценил юнитевских тестов, там как я понял, нужно над каждым тестом вешать атрибут с номером, а потом если хочешь какой-то тест вставить в середину вся нумерация слетает, да и вообще довольно запарно их писать...
По поводу безголового кота, живого трупа-убийцы, а так же "темного места" я ничего не могу сказать. У меня почему-то такого не происходит, кот спавнится живым.Хотя и не на долго. Кот это все равно death%
Почему у меня такого почти нет, а у многих анонов при каждом запуске происходит я не понимаю.
Тут были бы полезны логи.
Вообщем да, пристыдили меня эти летсплеи. Дождись лучше следующего билда, где я починю хотя-бы часть, а то реально больно смотреть)
А на годот я не пойду, бесполезно это предлагать. Переход на новый движок еще год займет. Я уж лучше как-нибудь тут.
>>836261
Как настолко-вытиран могу порекомендовать броню для локаций тела и пониженный шанс попадания по небольшим частям с поправкой на подвижность. По голове должно быть сложнее попасть чем по торсу, а по ладони сложнее чем по голове.
>Сложно сбалансировать
Как настолко-вытиран могу порекомендовать броню для локаций тела и пониженный шанс попадания по небольшим частям с поправкой на подвижность. По голове должно быть сложнее попасть чем по торсу, а по ладони сложнее чем по голове.
>>836261
Видео не смотрел, из-за кликбейтного превью. Но нереалистичность вносят не драка с 1 хп, а сами хитпоинты, поскольку ИРЛ это не так работает. Можно умереть от случайного чиха, а есть задокументированные случаи, как перестрелка с ФБР в Майами, когда преступник был ранен 5 раз, включая пробитое легкое, и продолжал ходить, после чего застрелил еще двух ФБРовцев, угнал их машину и т.д, при это даже не будучи обдолбаным. https://en.wikipedia.org/wiki/1986_FBI_Miami_shootout
В самой же ДнД, хитпониты обозначают не просто раны, а комбинацию здоровья и моральной воли к сражению. Что подтверждается такими явлениями, как заклинание героизм, дающее временные хитпоинты, и ярость берсерка. Это же может объяснять, почему у высокоуровневых персонажей намного больше хитпоинтов - они просто игнорируют мелкие порезы и ожоги.
Сам же геймдизайн специально не вводит в ДнД травмы, чтобы избежать спирали смерти https://rpg.fandom.com/ru/wiki/Спираль_смерти
Эффект спирали смерти известен по другим играм, и приводит к скучному геймплею. Например, в обычной гонке, если кто-то оторвался, с этим уже ничего не сделать, а в популярной марио гонке, отстающему подкидывают оружие, чтобы он мог помешать и вырваться. При этом в каких-то выживачах или рогаликах это может быть нужно.
Видео не смотрел, из-за кликбейтного превью. Но нереалистичность вносят не драка с 1 хп, а сами хитпоинты, поскольку ИРЛ это не так работает. Можно умереть от случайного чиха, а есть задокументированные случаи, как перестрелка с ФБР в Майами, когда преступник был ранен 5 раз, включая пробитое легкое, и продолжал ходить, после чего застрелил еще двух ФБРовцев, угнал их машину и т.д, при это даже не будучи обдолбаным. https://en.wikipedia.org/wiki/1986_FBI_Miami_shootout
В самой же ДнД, хитпониты обозначают не просто раны, а комбинацию здоровья и моральной воли к сражению. Что подтверждается такими явлениями, как заклинание героизм, дающее временные хитпоинты, и ярость берсерка. Это же может объяснять, почему у высокоуровневых персонажей намного больше хитпоинтов - они просто игнорируют мелкие порезы и ожоги.
Сам же геймдизайн специально не вводит в ДнД травмы, чтобы избежать спирали смерти https://rpg.fandom.com/ru/wiki/Спираль_смерти
Эффект спирали смерти известен по другим играм, и приводит к скучному геймплею. Например, в обычной гонке, если кто-то оторвался, с этим уже ничего не сделать, а в популярной марио гонке, отстающему подкидывают оружие, чтобы он мог помешать и вырваться. При этом в каких-то выживачах или рогаликах это может быть нужно.
>>836339
Про спираль смерти соглы.
Нужно избегать моментов когда персонаж еще жив, но его дела так плохи что дальше они будут становиться только хуже, и проще ливнуть. У игрока всегда должна быть надежда камбекнуть.
По этому я эту механику и убрал. Получалось что если ты дошел до состояния когда тебя катают по полу шанс вернуться обратно просто мизерный.
Плюс если ты сильно побил моба то в нормальной ситуации он убегал бы с низкой моралью, а так он даже этого не сможет сделать.
Реалистично но неинтересно.
Геймплейно достаточно занятно выглядит вообще обратная зависимость - чем меньше хп, тем быстрее бегаешь. Но с точки зрения игрового мира это конечно полный абсурд.
-Оп
Про спираль смерти соглы.
Нужно избегать моментов когда персонаж еще жив, но его дела так плохи что дальше они будут становиться только хуже, и проще ливнуть. У игрока всегда должна быть надежда камбекнуть.
По этому я эту механику и убрал. Получалось что если ты дошел до состояния когда тебя катают по полу шанс вернуться обратно просто мизерный.
Плюс если ты сильно побил моба то в нормальной ситуации он убегал бы с низкой моралью, а так он даже этого не сможет сделать.
Реалистично но неинтересно.
Геймплейно достаточно занятно выглядит вообще обратная зависимость - чем меньше хп, тем быстрее бегаешь. Но с точки зрения игрового мира это конечно полный абсурд.
-Оп
>>836270
Мне кажется, я нашёл причины проблемы. Вернее, подтвердил свои догадки:
1. Ты проверяешь не щелчок колёсика мыши, а число строк прокрутки, который сообщает игре Windows. У тебя это число скорее всего равно 1, а у меня оно стояло на 3 (раньше и на 5 ставил), из-за чего отдаление камеры происходило в 3 раза быстрее, чем у тебя. Установив это значение на 1 в настройках мыши (см. скриншот), зум стал более послушным на отдаление. Переделай свой код, чтобы он проверял щелчки колёсика, а не прокрутку строк, потому что ты не должен заставлять игрока менять системные настройки. Лучше сделать настройку скорости прокрутки в игре, чем делать её зависимой от настроек ОС.
2. Приближение камеры вообще сломано, т.е. вместо плавного приближения ты просто присваиваешь какое-то конкретное значение, типа "1.0", и уже от него приближаешь, из-за чего возникает эффект, будто камера "бросается" на персонажа. Это должно быть легко пофиксить, скорее всего у тебя где-то "=" вместо "-=" или что-то вроде.
В видео ближе к концу видно, как теперь у меня работает зум, после изменения системной настройки мыши. Но в первую очередь записывал это видео чтобы показать поведение грудной клетки человечка, которого разорвало на части взрывом тестовой /b/омбы. Он продолжает бегать, хотя с точки зрения игрового персонажа это лежащий на земле предмет - его нельзя атаковать, на него можно встать, и его даже можно съесть. Всё просто замечательно, но есть один маленький баг: после обгладывания мяса грудная клетка перестала двигаться, превратившись в груду костей. Срочно пофикси так, чтобы игрок мог создать дружелюбного скелета путём обгладывания трупов врагов или сбора разбросанных костей в кучку. Короче, баг в механике некромантии, делает игру неиграбельной((((
Кстати, благодаря тестовой /b/омбуэ и неудачному расположению v и b рядом, я узнал, что игрок может регенерировать оторванные конечности, если сможет каким-то образом съесть достаточно мяса. Это так и задумано? Сначала удалось восстановить левую руку, а потом и правую. Вот что мясо пещерных крыс животворящее делает!
Почему я? Я безыгорный движкопися-годотер, который все баги ловит с помощью print()...
Я сомневаюсь, возможно ли покрыть тестами любые игровые ситуации. Игры характерны очень сложным поведением, поэтому автоматические тесты должны будут быть очень сложными... Тут важнее вопрос, достаточно ли независимы у тебя все системы. Если не контролировать архитектуру, любой проект рано или поздно превращается в лапшу, т.е. возникают нежелательные связи, которыми сложно управлять. Поэтому тщательно пересмотри свою архитектуру и сделай системы более независимыми, а после уже сможешь проверять баги в этих отдельных системах. Когда ты убедишься, что в отдельных системах багов нет, ты можешь подняться на абстракцию выше и искать баги в более общих системах. Изменяя какую-то систему, ты будешь искать баги только в ней, т.к. другие системы от неё не зависят и поэтому не могут сломаться, т.е. не придётся тестировать весь проект после изменения одной маленькой системы. Нужно ли писать автоматические тесты на уже протестированные и полностью независимые системы, которые ты больше не будешь изменять?
В частности, непонятно, как ты мог сломать систему меню, если у тебя управление менюшками должно быть в одной очень простой системе наивысшего уровня (Game), которая ставит почти всю игру на паузу, когда игрок открывает меню паузы. Т.е. чтобы сломать это поведение, ты должен был сломать эту простую высшую систему, и возникает вопрос, зачем ты в неё лез? Если же это не так, и поведение менюх разложено между ними, то это значит, что у тебя в коде лапша - неявные взаимосвязи между отдельными менюшками, которые не должны друг о друге знать. Вот распутаешь эту лапшу и никакие тесты будут не нужны (я утрирую, конечно, тесты могут пригодиться, например, при переходе на новую версию движка).
Вообще ничего о них не знаю.
У меня он тоже спавнился живым. Тот спавн без частей тела получился из-за какого-то бага, который ломает запуск новой игры. Т.е. после какого-то момента запуск новой игры спавнит персонажа без конечностей - только грудная клетка. Кстати, почему грудная клетка, а не голова? Было бы логичнее сделать голову корневым элементом, в частности если предполагается замена частей кибернетическими или магическими протезами.
После событий этого лета многие инди на юнити заинтересовались переходом на альтернативные движки, в частности Годо. Потом часто всплывали посты о том, как им понравился Годо и что они теперь будут делать игру на нём. На самом деле освоить Годо не так сложно после Юнити. Полностью портировать большую игру, наверное, всё-таки сложно, но начать осваивать несложно - концепции в основном те же самые. Тем более 2D, в Годо тебе не придётся мудрить с третьей осью, тут 2D полностью абстрагировано от 3D (как в SDL).
>зум. Реально бросается. Я не знаю в чем дело
Мне кажется, я нашёл причины проблемы. Вернее, подтвердил свои догадки:
1. Ты проверяешь не щелчок колёсика мыши, а число строк прокрутки, который сообщает игре Windows. У тебя это число скорее всего равно 1, а у меня оно стояло на 3 (раньше и на 5 ставил), из-за чего отдаление камеры происходило в 3 раза быстрее, чем у тебя. Установив это значение на 1 в настройках мыши (см. скриншот), зум стал более послушным на отдаление. Переделай свой код, чтобы он проверял щелчки колёсика, а не прокрутку строк, потому что ты не должен заставлять игрока менять системные настройки. Лучше сделать настройку скорости прокрутки в игре, чем делать её зависимой от настроек ОС.
2. Приближение камеры вообще сломано, т.е. вместо плавного приближения ты просто присваиваешь какое-то конкретное значение, типа "1.0", и уже от него приближаешь, из-за чего возникает эффект, будто камера "бросается" на персонажа. Это должно быть легко пофиксить, скорее всего у тебя где-то "=" вместо "-=" или что-то вроде.
В видео ближе к концу видно, как теперь у меня работает зум, после изменения системной настройки мыши. Но в первую очередь записывал это видео чтобы показать поведение грудной клетки человечка, которого разорвало на части взрывом тестовой /b/омбы. Он продолжает бегать, хотя с точки зрения игрового персонажа это лежащий на земле предмет - его нельзя атаковать, на него можно встать, и его даже можно съесть. Всё просто замечательно, но есть один маленький баг: после обгладывания мяса грудная клетка перестала двигаться, превратившись в груду костей. Срочно пофикси так, чтобы игрок мог создать дружелюбного скелета путём обгладывания трупов врагов или сбора разбросанных костей в кучку. Короче, баг в механике некромантии, делает игру неиграбельной((((
Кстати, благодаря тестовой /b/омбуэ и неудачному расположению v и b рядом, я узнал, что игрок может регенерировать оторванные конечности, если сможет каким-то образом съесть достаточно мяса. Это так и задумано? Сначала удалось восстановить левую руку, а потом и правую. Вот что мясо пещерных крыс животворящее делает!
>Можешь, кстати, пояснить мне немного за автоматическое тестирование?
Почему я? Я безыгорный движкопися-годотер, который все баги ловит с помощью print()...
>Стоит ли мне вкладываться в создание тестов для всего что есть в игре?
Я сомневаюсь, возможно ли покрыть тестами любые игровые ситуации. Игры характерны очень сложным поведением, поэтому автоматические тесты должны будут быть очень сложными... Тут важнее вопрос, достаточно ли независимы у тебя все системы. Если не контролировать архитектуру, любой проект рано или поздно превращается в лапшу, т.е. возникают нежелательные связи, которыми сложно управлять. Поэтому тщательно пересмотри свою архитектуру и сделай системы более независимыми, а после уже сможешь проверять баги в этих отдельных системах. Когда ты убедишься, что в отдельных системах багов нет, ты можешь подняться на абстракцию выше и искать баги в более общих системах. Изменяя какую-то систему, ты будешь искать баги только в ней, т.к. другие системы от неё не зависят и поэтому не могут сломаться, т.е. не придётся тестировать весь проект после изменения одной маленькой системы. Нужно ли писать автоматические тесты на уже протестированные и полностью независимые системы, которые ты больше не будешь изменять?
В частности, непонятно, как ты мог сломать систему меню, если у тебя управление менюшками должно быть в одной очень простой системе наивысшего уровня (Game), которая ставит почти всю игру на паузу, когда игрок открывает меню паузы. Т.е. чтобы сломать это поведение, ты должен был сломать эту простую высшую систему, и возникает вопрос, зачем ты в неё лез? Если же это не так, и поведение менюх разложено между ними, то это значит, что у тебя в коде лапша - неявные взаимосвязи между отдельными менюшками, которые не должны друг о друге знать. Вот распутаешь эту лапшу и никакие тесты будут не нужны (я утрирую, конечно, тесты могут пригодиться, например, при переходе на новую версию движка).
>юнитевских тестов
Вообще ничего о них не знаю.
>кот спавнится живым
У меня он тоже спавнился живым. Тот спавн без частей тела получился из-за какого-то бага, который ломает запуск новой игры. Т.е. после какого-то момента запуск новой игры спавнит персонажа без конечностей - только грудная клетка. Кстати, почему грудная клетка, а не голова? Было бы логичнее сделать голову корневым элементом, в частности если предполагается замена частей кибернетическими или магическими протезами.
>А на годот я не пойду
>Переход на новый движок еще год займет
После событий этого лета многие инди на юнити заинтересовались переходом на альтернативные движки, в частности Годо. Потом часто всплывали посты о том, как им понравился Годо и что они теперь будут делать игру на нём. На самом деле освоить Годо не так сложно после Юнити. Полностью портировать большую игру, наверное, всё-таки сложно, но начать осваивать несложно - концепции в основном те же самые. Тем более 2D, в Годо тебе не придётся мудрить с третьей осью, тут 2D полностью абстрагировано от 3D (как в SDL).
>>836270
Мне кажется, я нашёл причины проблемы. Вернее, подтвердил свои догадки:
1. Ты проверяешь не щелчок колёсика мыши, а число строк прокрутки, который сообщает игре Windows. У тебя это число скорее всего равно 1, а у меня оно стояло на 3 (раньше и на 5 ставил), из-за чего отдаление камеры происходило в 3 раза быстрее, чем у тебя. Установив это значение на 1 в настройках мыши (см. скриншот), зум стал более послушным на отдаление. Переделай свой код, чтобы он проверял щелчки колёсика, а не прокрутку строк, потому что ты не должен заставлять игрока менять системные настройки. Лучше сделать настройку скорости прокрутки в игре, чем делать её зависимой от настроек ОС.
2. Приближение камеры вообще сломано, т.е. вместо плавного приближения ты просто присваиваешь какое-то конкретное значение, типа "1.0", и уже от него приближаешь, из-за чего возникает эффект, будто камера "бросается" на персонажа. Это должно быть легко пофиксить, скорее всего у тебя где-то "=" вместо "-=" или что-то вроде.
В видео ближе к концу видно, как теперь у меня работает зум, после изменения системной настройки мыши. Но в первую очередь записывал это видео чтобы показать поведение грудной клетки человечка, которого разорвало на части взрывом тестовой /b/омбы. Он продолжает бегать, хотя с точки зрения игрового персонажа это лежащий на земле предмет - его нельзя атаковать, на него можно встать, и его даже можно съесть. Всё просто замечательно, но есть один маленький баг: после обгладывания мяса грудная клетка перестала двигаться, превратившись в груду костей. Срочно пофикси так, чтобы игрок мог создать дружелюбного скелета путём обгладывания трупов врагов или сбора разбросанных костей в кучку. Короче, баг в механике некромантии, делает игру неиграбельной((((
Кстати, благодаря тестовой /b/омбуэ и неудачному расположению v и b рядом, я узнал, что игрок может регенерировать оторванные конечности, если сможет каким-то образом съесть достаточно мяса. Это так и задумано? Сначала удалось восстановить левую руку, а потом и правую. Вот что мясо пещерных крыс животворящее делает!
Почему я? Я безыгорный движкопися-годотер, который все баги ловит с помощью print()...
Я сомневаюсь, возможно ли покрыть тестами любые игровые ситуации. Игры характерны очень сложным поведением, поэтому автоматические тесты должны будут быть очень сложными... Тут важнее вопрос, достаточно ли независимы у тебя все системы. Если не контролировать архитектуру, любой проект рано или поздно превращается в лапшу, т.е. возникают нежелательные связи, которыми сложно управлять. Поэтому тщательно пересмотри свою архитектуру и сделай системы более независимыми, а после уже сможешь проверять баги в этих отдельных системах. Когда ты убедишься, что в отдельных системах багов нет, ты можешь подняться на абстракцию выше и искать баги в более общих системах. Изменяя какую-то систему, ты будешь искать баги только в ней, т.к. другие системы от неё не зависят и поэтому не могут сломаться, т.е. не придётся тестировать весь проект после изменения одной маленькой системы. Нужно ли писать автоматические тесты на уже протестированные и полностью независимые системы, которые ты больше не будешь изменять?
В частности, непонятно, как ты мог сломать систему меню, если у тебя управление менюшками должно быть в одной очень простой системе наивысшего уровня (Game), которая ставит почти всю игру на паузу, когда игрок открывает меню паузы. Т.е. чтобы сломать это поведение, ты должен был сломать эту простую высшую систему, и возникает вопрос, зачем ты в неё лез? Если же это не так, и поведение менюх разложено между ними, то это значит, что у тебя в коде лапша - неявные взаимосвязи между отдельными менюшками, которые не должны друг о друге знать. Вот распутаешь эту лапшу и никакие тесты будут не нужны (я утрирую, конечно, тесты могут пригодиться, например, при переходе на новую версию движка).
Вообще ничего о них не знаю.
У меня он тоже спавнился живым. Тот спавн без частей тела получился из-за какого-то бага, который ломает запуск новой игры. Т.е. после какого-то момента запуск новой игры спавнит персонажа без конечностей - только грудная клетка. Кстати, почему грудная клетка, а не голова? Было бы логичнее сделать голову корневым элементом, в частности если предполагается замена частей кибернетическими или магическими протезами.
После событий этого лета многие инди на юнити заинтересовались переходом на альтернативные движки, в частности Годо. Потом часто всплывали посты о том, как им понравился Годо и что они теперь будут делать игру на нём. На самом деле освоить Годо не так сложно после Юнити. Полностью портировать большую игру, наверное, всё-таки сложно, но начать осваивать несложно - концепции в основном те же самые. Тем более 2D, в Годо тебе не придётся мудрить с третьей осью, тут 2D полностью абстрагировано от 3D (как в SDL).
>зум. Реально бросается. Я не знаю в чем дело
Мне кажется, я нашёл причины проблемы. Вернее, подтвердил свои догадки:
1. Ты проверяешь не щелчок колёсика мыши, а число строк прокрутки, который сообщает игре Windows. У тебя это число скорее всего равно 1, а у меня оно стояло на 3 (раньше и на 5 ставил), из-за чего отдаление камеры происходило в 3 раза быстрее, чем у тебя. Установив это значение на 1 в настройках мыши (см. скриншот), зум стал более послушным на отдаление. Переделай свой код, чтобы он проверял щелчки колёсика, а не прокрутку строк, потому что ты не должен заставлять игрока менять системные настройки. Лучше сделать настройку скорости прокрутки в игре, чем делать её зависимой от настроек ОС.
2. Приближение камеры вообще сломано, т.е. вместо плавного приближения ты просто присваиваешь какое-то конкретное значение, типа "1.0", и уже от него приближаешь, из-за чего возникает эффект, будто камера "бросается" на персонажа. Это должно быть легко пофиксить, скорее всего у тебя где-то "=" вместо "-=" или что-то вроде.
В видео ближе к концу видно, как теперь у меня работает зум, после изменения системной настройки мыши. Но в первую очередь записывал это видео чтобы показать поведение грудной клетки человечка, которого разорвало на части взрывом тестовой /b/омбы. Он продолжает бегать, хотя с точки зрения игрового персонажа это лежащий на земле предмет - его нельзя атаковать, на него можно встать, и его даже можно съесть. Всё просто замечательно, но есть один маленький баг: после обгладывания мяса грудная клетка перестала двигаться, превратившись в груду костей. Срочно пофикси так, чтобы игрок мог создать дружелюбного скелета путём обгладывания трупов врагов или сбора разбросанных костей в кучку. Короче, баг в механике некромантии, делает игру неиграбельной((((
Кстати, благодаря тестовой /b/омбуэ и неудачному расположению v и b рядом, я узнал, что игрок может регенерировать оторванные конечности, если сможет каким-то образом съесть достаточно мяса. Это так и задумано? Сначала удалось восстановить левую руку, а потом и правую. Вот что мясо пещерных крыс животворящее делает!
>Можешь, кстати, пояснить мне немного за автоматическое тестирование?
Почему я? Я безыгорный движкопися-годотер, который все баги ловит с помощью print()...
>Стоит ли мне вкладываться в создание тестов для всего что есть в игре?
Я сомневаюсь, возможно ли покрыть тестами любые игровые ситуации. Игры характерны очень сложным поведением, поэтому автоматические тесты должны будут быть очень сложными... Тут важнее вопрос, достаточно ли независимы у тебя все системы. Если не контролировать архитектуру, любой проект рано или поздно превращается в лапшу, т.е. возникают нежелательные связи, которыми сложно управлять. Поэтому тщательно пересмотри свою архитектуру и сделай системы более независимыми, а после уже сможешь проверять баги в этих отдельных системах. Когда ты убедишься, что в отдельных системах багов нет, ты можешь подняться на абстракцию выше и искать баги в более общих системах. Изменяя какую-то систему, ты будешь искать баги только в ней, т.к. другие системы от неё не зависят и поэтому не могут сломаться, т.е. не придётся тестировать весь проект после изменения одной маленькой системы. Нужно ли писать автоматические тесты на уже протестированные и полностью независимые системы, которые ты больше не будешь изменять?
В частности, непонятно, как ты мог сломать систему меню, если у тебя управление менюшками должно быть в одной очень простой системе наивысшего уровня (Game), которая ставит почти всю игру на паузу, когда игрок открывает меню паузы. Т.е. чтобы сломать это поведение, ты должен был сломать эту простую высшую систему, и возникает вопрос, зачем ты в неё лез? Если же это не так, и поведение менюх разложено между ними, то это значит, что у тебя в коде лапша - неявные взаимосвязи между отдельными менюшками, которые не должны друг о друге знать. Вот распутаешь эту лапшу и никакие тесты будут не нужны (я утрирую, конечно, тесты могут пригодиться, например, при переходе на новую версию движка).
>юнитевских тестов
Вообще ничего о них не знаю.
>кот спавнится живым
У меня он тоже спавнился живым. Тот спавн без частей тела получился из-за какого-то бага, который ломает запуск новой игры. Т.е. после какого-то момента запуск новой игры спавнит персонажа без конечностей - только грудная клетка. Кстати, почему грудная клетка, а не голова? Было бы логичнее сделать голову корневым элементом, в частности если предполагается замена частей кибернетическими или магическими протезами.
>А на годот я не пойду
>Переход на новый движок еще год займет
После событий этого лета многие инди на юнити заинтересовались переходом на альтернативные движки, в частности Годо. Потом часто всплывали посты о том, как им понравился Годо и что они теперь будут делать игру на нём. На самом деле освоить Годо не так сложно после Юнити. Полностью портировать большую игру, наверное, всё-таки сложно, но начать осваивать несложно - концепции в основном те же самые. Тем более 2D, в Годо тебе не придётся мудрить с третьей осью, тут 2D полностью абстрагировано от 3D (как в SDL).
>>836325
Это всё очевидно даже тому, кто в игры никогда не играл и о настолках даже не слышал, лол. Проблема игрового баланса не в очевидных вещах вроде "по маленькой части тела сложнее попасть", а в конкретных числах - т.е. в коэффициентах формул. От этих чисел зависит то, победит игрок или проиграет и понравится ему играть или нет; будет ли победа интересной и будет ли проигрыш обидным. В частности, твоё "ладони сложнее попасть чем по голове" не так-то просто сбалансировать, потому что в ладони может лежать большое оружие и это оружие по логике игрока проще выбить из рук, чем попасть по голове. Но если игрок будет легко выбивать любое оружие, то битвы могут стать слишком простыми. А если попадание по рукам и голове будет слишком сложным, то мотивации целиться в них будет значительно меньше, ведь проткнуть мобу грудную клетку будет означать более быструю победу. Должен быть баланс, но его сложно рассчитать.
>>836339
Зря, у Viva La Dirt League всегда очень качественные и очень смешные видео. Если тебя обижает надпись "D&D Logic", тогда рассматривай это видео как описание практически любой видеоигры - это именно в видеоиграх игрок может бегать с 1 хп и совершать очень сложные действия без каких-либо трудностей. В том видео просто описана уязвимость правил, в которых не написано, как нужно отыгрывать низкое здоровье персонажа, но по сути это справедливо для любой игры со шкалой здоровья.
Конечно, ИРЛ это не так работает, но хитпоинты можно приблизить к реализму, если подразумевать, что низкое число хитпоинтов означает высокий износ организма или жизненно важных органов. В твоих примерах случайный чих, вызывающий закупорку главных сосудов и поступления крови в мозг снимает 100 ХП мозгу, из-за чего ведёт к смерти, а в примере перестрелки слишком мелкие пули несмотря на их экспансивность попадали по малозначимым органам и поэтому условно снимали мало ХП, хотя и накладывали дебафф "кровотечение", поэтому позволяли действовать дальше несмотря на ранения. Алсо те люди были под баффом "адреналин", снимающий боль и увеличивающий производительность мышц и мозга несмотря на повреждения органов, логично? Это всё легко вписать в игровой мир, если постараться, просто большинство разработчиков не хотят усложнять баланс и без того сложного дизайна игры.
Однако ОП сам взял на себя ношу балансировать сложную игру, добавив индивидуальный износ разных частей тела. Ему однозначно нужно добавить изменение поведения персонажа при повреждении отдельных частей тела, иначе вся эта возня с индивидуальным износом будет абсолютно бесполезна. Какой смысл отрывать мобу ноги, если он и без них спокойно бегает? Хотя, какие ноги, тут у него одна грудная клетка без головы и конечностей спокойно бегает по карте, ведь ей нечем осознать, что она мертва (мысленно отыгрываю это как то, что строчка кода "func is_dead(): return not head" находится в голове моба, поэтому после отделения головы моб не понимает, что он мёртв, и продолжает вести себя как обычно)...
Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья. Может быть здоровый бугай, который трусливо бежит от любого сражения и визжит как девчонка от любого пореза, и может быть смертельно больной герой, закрывающий собой амбразуру, гранату или ещё что-то опасное. В фэнтези огромный голем по логике будет иметь много очков здоровья, но это не значит, что он очень сильно хочет тебя убить - он просто бродит по миру, в основном игнорируя любую живность, потому что создан из камней и собственного мышления не имеет. А у какого-нибудь хомячка-берсерка огромная воля к сражению несмотря на один хитпойнт (давится лапой любого животного крупнее крысы).
Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией, так что нанести урон становится сложнее. Если 1/100 = мелкий порез, то для раскаченного до 1000 ХП персонажа мелкий порез = 10 хп, а не 1 хп. Что он почувствует, зависит не от числа хп, а его болевого порога, а будет ли он игнорировать то, что он почувствует, зависит не от хп и не от болевого порога, а от болевой терпимости. ИРЛ у людей тоже очень разные уровни этих двух параметров - можно иметь низкий болевой порог и высокую терпимость, а можно иметь высокий болевой порог и низкую терпимость, но это всё не имеет отношения ни к здоровью, ни к воле к сражению.
Это 100% ложь, ты в гонки вообще не играл? Во-первых, противники могут делать ошибки - если ты делаешь меньше ошибок, чем делают противники, ты постепенно их догоняешь. Во-вторых, если игра не против "призраков", есть возможность развернуть противника на 180 градусов, фактически выведя его из гонки на несколько секунд. Видел даже летсплеи, где игроку удавалось выйти на первое место после неудачного старта, то есть подняться с 16-го места на первое почти к концу гонки - и это без каких-либо бонусов и оружия, против реальных людей. Но если твой уровень игровых навыков значительно ниже противников, то ты, естественно, будешь допускать больше ошибок и постоянно отставать, а не догонять. ИИ противников в гонках настраивают на какой-то уровень игры игрока, и тебе просто не повезло, если этот уровень значительно выше твоего лучшего результата...
>>836403
Лол, а как же отрывание рук? Игрок без рук не сможет отбиться от противников. Мне уже несколько раз в твоей игре отрывали руки, после этого мобам остаётся только добить остаток игрока. Аналогично с мобами, что они против меня сделают без рук? Покусают?
Почему же, без рук вес тела ниже, а значит бежать легче, поэтому скорость бега повышается. Без головы ещё легче бежать, а без ног так вообще пулей бегать будешь, что в твоей игре в данный момент и происходит.
>пониженный шанс попадания по небольшим частям с поправкой на подвижность. По голове должно быть сложнее попасть чем по торсу, а по ладони сложнее чем по голове.
Это всё очевидно даже тому, кто в игры никогда не играл и о настолках даже не слышал, лол. Проблема игрового баланса не в очевидных вещах вроде "по маленькой части тела сложнее попасть", а в конкретных числах - т.е. в коэффициентах формул. От этих чисел зависит то, победит игрок или проиграет и понравится ему играть или нет; будет ли победа интересной и будет ли проигрыш обидным. В частности, твоё "ладони сложнее попасть чем по голове" не так-то просто сбалансировать, потому что в ладони может лежать большое оружие и это оружие по логике игрока проще выбить из рук, чем попасть по голове. Но если игрок будет легко выбивать любое оружие, то битвы могут стать слишком простыми. А если попадание по рукам и голове будет слишком сложным, то мотивации целиться в них будет значительно меньше, ведь проткнуть мобу грудную клетку будет означать более быструю победу. Должен быть баланс, но его сложно рассчитать.
>>836339
>Видео не смотрел, из-за кликбейтного превью.
Зря, у Viva La Dirt League всегда очень качественные и очень смешные видео. Если тебя обижает надпись "D&D Logic", тогда рассматривай это видео как описание практически любой видеоигры - это именно в видеоиграх игрок может бегать с 1 хп и совершать очень сложные действия без каких-либо трудностей. В том видео просто описана уязвимость правил, в которых не написано, как нужно отыгрывать низкое здоровье персонажа, но по сути это справедливо для любой игры со шкалой здоровья.
>хитпоинты, поскольку ИРЛ это не так работает
Конечно, ИРЛ это не так работает, но хитпоинты можно приблизить к реализму, если подразумевать, что низкое число хитпоинтов означает высокий износ организма или жизненно важных органов. В твоих примерах случайный чих, вызывающий закупорку главных сосудов и поступления крови в мозг снимает 100 ХП мозгу, из-за чего ведёт к смерти, а в примере перестрелки слишком мелкие пули несмотря на их экспансивность попадали по малозначимым органам и поэтому условно снимали мало ХП, хотя и накладывали дебафф "кровотечение", поэтому позволяли действовать дальше несмотря на ранения. Алсо те люди были под баффом "адреналин", снимающий боль и увеличивающий производительность мышц и мозга несмотря на повреждения органов, логично? Это всё легко вписать в игровой мир, если постараться, просто большинство разработчиков не хотят усложнять баланс и без того сложного дизайна игры.
Однако ОП сам взял на себя ношу балансировать сложную игру, добавив индивидуальный износ разных частей тела. Ему однозначно нужно добавить изменение поведения персонажа при повреждении отдельных частей тела, иначе вся эта возня с индивидуальным износом будет абсолютно бесполезна. Какой смысл отрывать мобу ноги, если он и без них спокойно бегает? Хотя, какие ноги, тут у него одна грудная клетка без головы и конечностей спокойно бегает по карте, ведь ей нечем осознать, что она мертва (мысленно отыгрываю это как то, что строчка кода "func is_dead(): return not head" находится в голове моба, поэтому после отделения головы моб не понимает, что он мёртв, и продолжает вести себя как обычно)...
>хитпониты обозначают не просто раны, а комбинацию здоровья и моральной воли к сражению
Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья. Может быть здоровый бугай, который трусливо бежит от любого сражения и визжит как девчонка от любого пореза, и может быть смертельно больной герой, закрывающий собой амбразуру, гранату или ещё что-то опасное. В фэнтези огромный голем по логике будет иметь много очков здоровья, но это не значит, что он очень сильно хочет тебя убить - он просто бродит по миру, в основном игнорируя любую живность, потому что создан из камней и собственного мышления не имеет. А у какого-нибудь хомячка-берсерка огромная воля к сражению несмотря на один хитпойнт (давится лапой любого животного крупнее крысы).
>почему у высокоуровневых персонажей намного больше хитпоинтов - они просто игнорируют мелкие порезы и ожоги.
Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией, так что нанести урон становится сложнее. Если 1/100 = мелкий порез, то для раскаченного до 1000 ХП персонажа мелкий порез = 10 хп, а не 1 хп. Что он почувствует, зависит не от числа хп, а его болевого порога, а будет ли он игнорировать то, что он почувствует, зависит не от хп и не от болевого порога, а от болевой терпимости. ИРЛ у людей тоже очень разные уровни этих двух параметров - можно иметь низкий болевой порог и высокую терпимость, а можно иметь высокий болевой порог и низкую терпимость, но это всё не имеет отношения ни к здоровью, ни к воле к сражению.
>Например, в обычной гонке, если кто-то оторвался, с этим уже ничего не сделать
Это 100% ложь, ты в гонки вообще не играл? Во-первых, противники могут делать ошибки - если ты делаешь меньше ошибок, чем делают противники, ты постепенно их догоняешь. Во-вторых, если игра не против "призраков", есть возможность развернуть противника на 180 градусов, фактически выведя его из гонки на несколько секунд. Видел даже летсплеи, где игроку удавалось выйти на первое место после неудачного старта, то есть подняться с 16-го места на первое почти к концу гонки - и это без каких-либо бонусов и оружия, против реальных людей. Но если твой уровень игровых навыков значительно ниже противников, то ты, естественно, будешь допускать больше ошибок и постоянно отставать, а не догонять. ИИ противников в гонках настраивают на какой-то уровень игры игрока, и тебе просто не повезло, если этот уровень значительно выше твоего лучшего результата...
>>836403
>Поэтому я эту механику и убрал
Лол, а как же отрывание рук? Игрок без рук не сможет отбиться от противников. Мне уже несколько раз в твоей игре отрывали руки, после этого мобам остаётся только добить остаток игрока. Аналогично с мобами, что они против меня сделают без рук? Покусают?
>чем меньше хп, тем быстрее бегаешь. Но с точки зрения игрового мира это конечно полный абсурд.
Почему же, без рук вес тела ниже, а значит бежать легче, поэтому скорость бега повышается. Без головы ещё легче бежать, а без ног так вообще пулей бегать будешь, что в твоей игре в данный момент и происходит.
>>836325
Это всё очевидно даже тому, кто в игры никогда не играл и о настолках даже не слышал, лол. Проблема игрового баланса не в очевидных вещах вроде "по маленькой части тела сложнее попасть", а в конкретных числах - т.е. в коэффициентах формул. От этих чисел зависит то, победит игрок или проиграет и понравится ему играть или нет; будет ли победа интересной и будет ли проигрыш обидным. В частности, твоё "ладони сложнее попасть чем по голове" не так-то просто сбалансировать, потому что в ладони может лежать большое оружие и это оружие по логике игрока проще выбить из рук, чем попасть по голове. Но если игрок будет легко выбивать любое оружие, то битвы могут стать слишком простыми. А если попадание по рукам и голове будет слишком сложным, то мотивации целиться в них будет значительно меньше, ведь проткнуть мобу грудную клетку будет означать более быструю победу. Должен быть баланс, но его сложно рассчитать.
>>836339
Зря, у Viva La Dirt League всегда очень качественные и очень смешные видео. Если тебя обижает надпись "D&D Logic", тогда рассматривай это видео как описание практически любой видеоигры - это именно в видеоиграх игрок может бегать с 1 хп и совершать очень сложные действия без каких-либо трудностей. В том видео просто описана уязвимость правил, в которых не написано, как нужно отыгрывать низкое здоровье персонажа, но по сути это справедливо для любой игры со шкалой здоровья.
Конечно, ИРЛ это не так работает, но хитпоинты можно приблизить к реализму, если подразумевать, что низкое число хитпоинтов означает высокий износ организма или жизненно важных органов. В твоих примерах случайный чих, вызывающий закупорку главных сосудов и поступления крови в мозг снимает 100 ХП мозгу, из-за чего ведёт к смерти, а в примере перестрелки слишком мелкие пули несмотря на их экспансивность попадали по малозначимым органам и поэтому условно снимали мало ХП, хотя и накладывали дебафф "кровотечение", поэтому позволяли действовать дальше несмотря на ранения. Алсо те люди были под баффом "адреналин", снимающий боль и увеличивающий производительность мышц и мозга несмотря на повреждения органов, логично? Это всё легко вписать в игровой мир, если постараться, просто большинство разработчиков не хотят усложнять баланс и без того сложного дизайна игры.
Однако ОП сам взял на себя ношу балансировать сложную игру, добавив индивидуальный износ разных частей тела. Ему однозначно нужно добавить изменение поведения персонажа при повреждении отдельных частей тела, иначе вся эта возня с индивидуальным износом будет абсолютно бесполезна. Какой смысл отрывать мобу ноги, если он и без них спокойно бегает? Хотя, какие ноги, тут у него одна грудная клетка без головы и конечностей спокойно бегает по карте, ведь ей нечем осознать, что она мертва (мысленно отыгрываю это как то, что строчка кода "func is_dead(): return not head" находится в голове моба, поэтому после отделения головы моб не понимает, что он мёртв, и продолжает вести себя как обычно)...
Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья. Может быть здоровый бугай, который трусливо бежит от любого сражения и визжит как девчонка от любого пореза, и может быть смертельно больной герой, закрывающий собой амбразуру, гранату или ещё что-то опасное. В фэнтези огромный голем по логике будет иметь много очков здоровья, но это не значит, что он очень сильно хочет тебя убить - он просто бродит по миру, в основном игнорируя любую живность, потому что создан из камней и собственного мышления не имеет. А у какого-нибудь хомячка-берсерка огромная воля к сражению несмотря на один хитпойнт (давится лапой любого животного крупнее крысы).
Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией, так что нанести урон становится сложнее. Если 1/100 = мелкий порез, то для раскаченного до 1000 ХП персонажа мелкий порез = 10 хп, а не 1 хп. Что он почувствует, зависит не от числа хп, а его болевого порога, а будет ли он игнорировать то, что он почувствует, зависит не от хп и не от болевого порога, а от болевой терпимости. ИРЛ у людей тоже очень разные уровни этих двух параметров - можно иметь низкий болевой порог и высокую терпимость, а можно иметь высокий болевой порог и низкую терпимость, но это всё не имеет отношения ни к здоровью, ни к воле к сражению.
Это 100% ложь, ты в гонки вообще не играл? Во-первых, противники могут делать ошибки - если ты делаешь меньше ошибок, чем делают противники, ты постепенно их догоняешь. Во-вторых, если игра не против "призраков", есть возможность развернуть противника на 180 градусов, фактически выведя его из гонки на несколько секунд. Видел даже летсплеи, где игроку удавалось выйти на первое место после неудачного старта, то есть подняться с 16-го места на первое почти к концу гонки - и это без каких-либо бонусов и оружия, против реальных людей. Но если твой уровень игровых навыков значительно ниже противников, то ты, естественно, будешь допускать больше ошибок и постоянно отставать, а не догонять. ИИ противников в гонках настраивают на какой-то уровень игры игрока, и тебе просто не повезло, если этот уровень значительно выше твоего лучшего результата...
>>836403
Лол, а как же отрывание рук? Игрок без рук не сможет отбиться от противников. Мне уже несколько раз в твоей игре отрывали руки, после этого мобам остаётся только добить остаток игрока. Аналогично с мобами, что они против меня сделают без рук? Покусают?
Почему же, без рук вес тела ниже, а значит бежать легче, поэтому скорость бега повышается. Без головы ещё легче бежать, а без ног так вообще пулей бегать будешь, что в твоей игре в данный момент и происходит.
>пониженный шанс попадания по небольшим частям с поправкой на подвижность. По голове должно быть сложнее попасть чем по торсу, а по ладони сложнее чем по голове.
Это всё очевидно даже тому, кто в игры никогда не играл и о настолках даже не слышал, лол. Проблема игрового баланса не в очевидных вещах вроде "по маленькой части тела сложнее попасть", а в конкретных числах - т.е. в коэффициентах формул. От этих чисел зависит то, победит игрок или проиграет и понравится ему играть или нет; будет ли победа интересной и будет ли проигрыш обидным. В частности, твоё "ладони сложнее попасть чем по голове" не так-то просто сбалансировать, потому что в ладони может лежать большое оружие и это оружие по логике игрока проще выбить из рук, чем попасть по голове. Но если игрок будет легко выбивать любое оружие, то битвы могут стать слишком простыми. А если попадание по рукам и голове будет слишком сложным, то мотивации целиться в них будет значительно меньше, ведь проткнуть мобу грудную клетку будет означать более быструю победу. Должен быть баланс, но его сложно рассчитать.
>>836339
>Видео не смотрел, из-за кликбейтного превью.
Зря, у Viva La Dirt League всегда очень качественные и очень смешные видео. Если тебя обижает надпись "D&D Logic", тогда рассматривай это видео как описание практически любой видеоигры - это именно в видеоиграх игрок может бегать с 1 хп и совершать очень сложные действия без каких-либо трудностей. В том видео просто описана уязвимость правил, в которых не написано, как нужно отыгрывать низкое здоровье персонажа, но по сути это справедливо для любой игры со шкалой здоровья.
>хитпоинты, поскольку ИРЛ это не так работает
Конечно, ИРЛ это не так работает, но хитпоинты можно приблизить к реализму, если подразумевать, что низкое число хитпоинтов означает высокий износ организма или жизненно важных органов. В твоих примерах случайный чих, вызывающий закупорку главных сосудов и поступления крови в мозг снимает 100 ХП мозгу, из-за чего ведёт к смерти, а в примере перестрелки слишком мелкие пули несмотря на их экспансивность попадали по малозначимым органам и поэтому условно снимали мало ХП, хотя и накладывали дебафф "кровотечение", поэтому позволяли действовать дальше несмотря на ранения. Алсо те люди были под баффом "адреналин", снимающий боль и увеличивающий производительность мышц и мозга несмотря на повреждения органов, логично? Это всё легко вписать в игровой мир, если постараться, просто большинство разработчиков не хотят усложнять баланс и без того сложного дизайна игры.
Однако ОП сам взял на себя ношу балансировать сложную игру, добавив индивидуальный износ разных частей тела. Ему однозначно нужно добавить изменение поведения персонажа при повреждении отдельных частей тела, иначе вся эта возня с индивидуальным износом будет абсолютно бесполезна. Какой смысл отрывать мобу ноги, если он и без них спокойно бегает? Хотя, какие ноги, тут у него одна грудная клетка без головы и конечностей спокойно бегает по карте, ведь ей нечем осознать, что она мертва (мысленно отыгрываю это как то, что строчка кода "func is_dead(): return not head" находится в голове моба, поэтому после отделения головы моб не понимает, что он мёртв, и продолжает вести себя как обычно)...
>хитпониты обозначают не просто раны, а комбинацию здоровья и моральной воли к сражению
Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья. Может быть здоровый бугай, который трусливо бежит от любого сражения и визжит как девчонка от любого пореза, и может быть смертельно больной герой, закрывающий собой амбразуру, гранату или ещё что-то опасное. В фэнтези огромный голем по логике будет иметь много очков здоровья, но это не значит, что он очень сильно хочет тебя убить - он просто бродит по миру, в основном игнорируя любую живность, потому что создан из камней и собственного мышления не имеет. А у какого-нибудь хомячка-берсерка огромная воля к сражению несмотря на один хитпойнт (давится лапой любого животного крупнее крысы).
>почему у высокоуровневых персонажей намного больше хитпоинтов - они просто игнорируют мелкие порезы и ожоги.
Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией, так что нанести урон становится сложнее. Если 1/100 = мелкий порез, то для раскаченного до 1000 ХП персонажа мелкий порез = 10 хп, а не 1 хп. Что он почувствует, зависит не от числа хп, а его болевого порога, а будет ли он игнорировать то, что он почувствует, зависит не от хп и не от болевого порога, а от болевой терпимости. ИРЛ у людей тоже очень разные уровни этих двух параметров - можно иметь низкий болевой порог и высокую терпимость, а можно иметь высокий болевой порог и низкую терпимость, но это всё не имеет отношения ни к здоровью, ни к воле к сражению.
>Например, в обычной гонке, если кто-то оторвался, с этим уже ничего не сделать
Это 100% ложь, ты в гонки вообще не играл? Во-первых, противники могут делать ошибки - если ты делаешь меньше ошибок, чем делают противники, ты постепенно их догоняешь. Во-вторых, если игра не против "призраков", есть возможность развернуть противника на 180 градусов, фактически выведя его из гонки на несколько секунд. Видел даже летсплеи, где игроку удавалось выйти на первое место после неудачного старта, то есть подняться с 16-го места на первое почти к концу гонки - и это без каких-либо бонусов и оружия, против реальных людей. Но если твой уровень игровых навыков значительно ниже противников, то ты, естественно, будешь допускать больше ошибок и постоянно отставать, а не догонять. ИИ противников в гонках настраивают на какой-то уровень игры игрока, и тебе просто не повезло, если этот уровень значительно выше твоего лучшего результата...
>>836403
>Поэтому я эту механику и убрал
Лол, а как же отрывание рук? Игрок без рук не сможет отбиться от противников. Мне уже несколько раз в твоей игре отрывали руки, после этого мобам остаётся только добить остаток игрока. Аналогично с мобами, что они против меня сделают без рук? Покусают?
>чем меньше хп, тем быстрее бегаешь. Но с точки зрения игрового мира это конечно полный абсурд.
Почему же, без рук вес тела ниже, а значит бежать легче, поэтому скорость бега повышается. Без головы ещё легче бежать, а без ног так вообще пулей бегать будешь, что в твоей игре в данный момент и происходит.
>>836599
Потому что ты жопой прочитал. Не "воля к сражению" зависит "от уровня здоровья", а хп в днд не являются уровнем здоровья, а являются комбинацией морали и здоровья.
>Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья
Потому что ты жопой прочитал. Не "воля к сражению" зависит "от уровня здоровья", а хп в днд не являются уровнем здоровья, а являются комбинацией морали и здоровья.
>>836599
Не означает. У тебя просто растет уровень и вместе с ним здоровье. Ты становишься более героичным.
> Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией
Не означает. У тебя просто растет уровень и вместе с ним здоровье. Ты становишься более героичным.
>>836607 >>836608
Мы не днд твоё обсуждаем, а систему здоровья в играх. Если в днд что-то как-то сделано, это не значит, что в других играх нужно делать так же, в первую очередь потому, что днд плохо переносится на компьютерные игры. Правила днд применяет игровой мастер, который может изменять правила по ситуации, адаптируя под конкретных игроков, чтобы им было веселее. А компьютерная игра накладывает фиксированные правила, и обычно игрок может только бросить игру и пойти играть в другую.
Мы не днд твоё обсуждаем, а систему здоровья в играх. Если в днд что-то как-то сделано, это не значит, что в других играх нужно делать так же, в первую очередь потому, что днд плохо переносится на компьютерные игры. Правила днд применяет игровой мастер, который может изменять правила по ситуации, адаптируя под конкретных игроков, чтобы им было веселее. А компьютерная игра накладывает фиксированные правила, и обычно игрок может только бросить игру и пойти играть в другую.
>>836619
Ну это ты принес ролик D&D Logic, и обсуждаешь тезисы про днд, поэтому получается что мы обсуждаем твое днд
Аналогично, если где-то с 1 хп нельзя бегать, это не значит, что в других играх нужно делать так же.
Это тут вообще не при чем, когда обсуждают правила, обсуждают правила - можешь считать, что если у мастера с уменьшением хп персонажи начнут медленнее ходить, то игроки тоже бросят игру и пойдут играть к другому мастеру, потому что у этого мастера не днд, а другая игра.
>Мы не днд твоё обсуждаем
Ну это ты принес ролик D&D Logic, и обсуждаешь тезисы про днд, поэтому получается что мы обсуждаем твое днд
> Если в днд что-то как-то сделано, это не значит, что в других играх нужно делать так же
Аналогично, если где-то с 1 хп нельзя бегать, это не значит, что в других играх нужно делать так же.
>Правила днд применяет игровой мастер, который может изменять правила по ситуации, адаптируя под конкретных игроков, чтобы им было веселее.
Это тут вообще не при чем, когда обсуждают правила, обсуждают правила - можешь считать, что если у мастера с уменьшением хп персонажи начнут медленнее ходить, то игроки тоже бросят игру и пойдут играть к другому мастеру, потому что у этого мастера не днд, а другая игра.
ОП, сделай тайл спуска на следующий уровень более заметным и чтобы на него не падали предметы и кровь. Сейчас потратил 10 минут на поиск спуска и уже хотел писать отчёт о баге "нет спуска на следующий уровень", но обнаружил, что тайл спрятался за половинкой стены, на нём лежал арбалет и сверху ещё была кровь. Выглядело это как обычная каменная плита с мусором на ней, так что я даже не пытался на неё встать, не говоря уж о нажатии V. Алсо, зачем нажимать клавишу? Сделай спуск автоматическим, как в Pixel Dungeon. А мобам запрети вставать на эту клетку вообще, чтобы ничего на неё не дропали. Главное пофикси длительность загрузки, невыносимо ждать загрузки, в твоей игре не так уж много тайлов чтобы столько грузить.
>>836620
Я принёс логик нелогичности дизайна игр, когда персонаж, едва цепляющийся за жизнь, действует точно так же, как полностью здоровый. "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения. А герои видеоигр спокойно бегают и выполняют любые задачи, только умирают с любого тычка.
Ты потерял оригинальный контекст:
Я не говорил, что нужно обязательно сделать механику штрафа при низком здоровье, я говорил только что мы привыкли к тому, что персонаж на низком здоровье действует так же как на полном. Привыкли - значит, нам кажется неудобным или даже неиграбельным другое поведение персонажа. Но это не означает, что оно действительно неиграбельно. Ты просто должен действовать аккуратнее и не рисковать лишний раз. ИРЛ ты не будешь скакать как горный баран по скалам, если у тебя серьёзное кротечение, а попытаешься немедленно оказать себе первую помощь и обратиться к тем, кто может тебе помочь. А когда ты играешь, ты вместо оказания первой помощи персонажу продолжаешь сражаться или бегать по уровню, и возмущаешься, если игра своими механиками мешает тебе это делать. Просто нужно изменить отношение к игре и всё встанет на свои места.
В конце концов, есть уровни сложности. Но в большинстве игр при увеличении сложности мобы просто-напросто увеличивают свои урон и здоровье - в результате ты дольше их бьёшь и быстрее умираешь от их ударов, что очень тупо и не приносит по сути ничего нового кроме необходимости чаще уворачиваться от ударов. Если бы игра накладывала на игрока и мобов штрафы по здоровью, она была бы справедливо сложнее, но интереснее за счёт необходимости тактически рассчитывать свои силы и заботиться о состоянии персонажа, а не только о том, чтобы ХП было хотя бы на единицу выше нуля.
Лол. Если не ошибаюсь, это называется "домашние правила" и выбираются они под вкусы конкретных участников игры. Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.
В любом случае, правила компьютерной игры сложно изменить под себя, поэтому в случае компьютерной игры игрок действительно просто уйдёт.
>>836620
>принес ролик
Я принёс логик нелогичности дизайна игр, когда персонаж, едва цепляющийся за жизнь, действует точно так же, как полностью здоровый. "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения. А герои видеоигр спокойно бегают и выполняют любые задачи, только умирают с любого тычка.
>в других играх нужно делать так же
Ты потерял оригинальный контекст:
>Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира.
Я не говорил, что нужно обязательно сделать механику штрафа при низком здоровье, я говорил только что мы привыкли к тому, что персонаж на низком здоровье действует так же как на полном. Привыкли - значит, нам кажется неудобным или даже неиграбельным другое поведение персонажа. Но это не означает, что оно действительно неиграбельно. Ты просто должен действовать аккуратнее и не рисковать лишний раз. ИРЛ ты не будешь скакать как горный баран по скалам, если у тебя серьёзное кротечение, а попытаешься немедленно оказать себе первую помощь и обратиться к тем, кто может тебе помочь. А когда ты играешь, ты вместо оказания первой помощи персонажу продолжаешь сражаться или бегать по уровню, и возмущаешься, если игра своими механиками мешает тебе это делать. Просто нужно изменить отношение к игре и всё встанет на свои места.
В конце концов, есть уровни сложности. Но в большинстве игр при увеличении сложности мобы просто-напросто увеличивают свои урон и здоровье - в результате ты дольше их бьёшь и быстрее умираешь от их ударов, что очень тупо и не приносит по сути ничего нового кроме необходимости чаще уворачиваться от ударов. Если бы игра накладывала на игрока и мобов штрафы по здоровью, она была бы справедливо сложнее, но интереснее за счёт необходимости тактически рассчитывать свои силы и заботиться о состоянии персонажа, а не только о том, чтобы ХП было хотя бы на единицу выше нуля.
>игроки тоже бросят игру и пойдут играть к другому мастеру, потому что у этого мастера не днд, а другая игра.
Лол. Если не ошибаюсь, это называется "домашние правила" и выбираются они под вкусы конкретных участников игры. Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.
В любом случае, правила компьютерной игры сложно изменить под себя, поэтому в случае компьютерной игры игрок действительно просто уйдёт.
ОП, сделай тайл спуска на следующий уровень более заметным и чтобы на него не падали предметы и кровь. Сейчас потратил 10 минут на поиск спуска и уже хотел писать отчёт о баге "нет спуска на следующий уровень", но обнаружил, что тайл спрятался за половинкой стены, на нём лежал арбалет и сверху ещё была кровь. Выглядело это как обычная каменная плита с мусором на ней, так что я даже не пытался на неё встать, не говоря уж о нажатии V. Алсо, зачем нажимать клавишу? Сделай спуск автоматическим, как в Pixel Dungeon. А мобам запрети вставать на эту клетку вообще, чтобы ничего на неё не дропали. Главное пофикси длительность загрузки, невыносимо ждать загрузки, в твоей игре не так уж много тайлов чтобы столько грузить.
>>836620
Я принёс логик нелогичности дизайна игр, когда персонаж, едва цепляющийся за жизнь, действует точно так же, как полностью здоровый. "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения. А герои видеоигр спокойно бегают и выполняют любые задачи, только умирают с любого тычка.
Ты потерял оригинальный контекст:
Я не говорил, что нужно обязательно сделать механику штрафа при низком здоровье, я говорил только что мы привыкли к тому, что персонаж на низком здоровье действует так же как на полном. Привыкли - значит, нам кажется неудобным или даже неиграбельным другое поведение персонажа. Но это не означает, что оно действительно неиграбельно. Ты просто должен действовать аккуратнее и не рисковать лишний раз. ИРЛ ты не будешь скакать как горный баран по скалам, если у тебя серьёзное кротечение, а попытаешься немедленно оказать себе первую помощь и обратиться к тем, кто может тебе помочь. А когда ты играешь, ты вместо оказания первой помощи персонажу продолжаешь сражаться или бегать по уровню, и возмущаешься, если игра своими механиками мешает тебе это делать. Просто нужно изменить отношение к игре и всё встанет на свои места.
В конце концов, есть уровни сложности. Но в большинстве игр при увеличении сложности мобы просто-напросто увеличивают свои урон и здоровье - в результате ты дольше их бьёшь и быстрее умираешь от их ударов, что очень тупо и не приносит по сути ничего нового кроме необходимости чаще уворачиваться от ударов. Если бы игра накладывала на игрока и мобов штрафы по здоровью, она была бы справедливо сложнее, но интереснее за счёт необходимости тактически рассчитывать свои силы и заботиться о состоянии персонажа, а не только о том, чтобы ХП было хотя бы на единицу выше нуля.
Лол. Если не ошибаюсь, это называется "домашние правила" и выбираются они под вкусы конкретных участников игры. Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.
В любом случае, правила компьютерной игры сложно изменить под себя, поэтому в случае компьютерной игры игрок действительно просто уйдёт.
>>836620
>принес ролик
Я принёс логик нелогичности дизайна игр, когда персонаж, едва цепляющийся за жизнь, действует точно так же, как полностью здоровый. "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения. А герои видеоигр спокойно бегают и выполняют любые задачи, только умирают с любого тычка.
>в других играх нужно делать так же
Ты потерял оригинальный контекст:
>Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира.
Я не говорил, что нужно обязательно сделать механику штрафа при низком здоровье, я говорил только что мы привыкли к тому, что персонаж на низком здоровье действует так же как на полном. Привыкли - значит, нам кажется неудобным или даже неиграбельным другое поведение персонажа. Но это не означает, что оно действительно неиграбельно. Ты просто должен действовать аккуратнее и не рисковать лишний раз. ИРЛ ты не будешь скакать как горный баран по скалам, если у тебя серьёзное кротечение, а попытаешься немедленно оказать себе первую помощь и обратиться к тем, кто может тебе помочь. А когда ты играешь, ты вместо оказания первой помощи персонажу продолжаешь сражаться или бегать по уровню, и возмущаешься, если игра своими механиками мешает тебе это делать. Просто нужно изменить отношение к игре и всё встанет на свои места.
В конце концов, есть уровни сложности. Но в большинстве игр при увеличении сложности мобы просто-напросто увеличивают свои урон и здоровье - в результате ты дольше их бьёшь и быстрее умираешь от их ударов, что очень тупо и не приносит по сути ничего нового кроме необходимости чаще уворачиваться от ударов. Если бы игра накладывала на игрока и мобов штрафы по здоровью, она была бы справедливо сложнее, но интереснее за счёт необходимости тактически рассчитывать свои силы и заботиться о состоянии персонажа, а не только о том, чтобы ХП было хотя бы на единицу выше нуля.
>игроки тоже бросят игру и пойдут играть к другому мастеру, потому что у этого мастера не днд, а другая игра.
Лол. Если не ошибаюсь, это называется "домашние правила" и выбираются они под вкусы конкретных участников игры. Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.
В любом случае, правила компьютерной игры сложно изменить под себя, поэтому в случае компьютерной игры игрок действительно просто уйдёт.
>>836673
Ты прочитал про перестрелку с ФБР, которую я тебе скидывал, где преступник с 5-12 пулевыми ранениями, простреленными ступнями, и продырявленным легким, подошел к их машине, застрелил двоих, и потом попытался ее угнать?
Тут большой спектр, начиная с позвали в группу мастера по объявлению, до сходили в платный клуб, до водит просто приятель или знакомый, не друг. В общем, чаще проще поменять мастера, или группу, чем пытаться отменить левое домашнее правило (а мастер не всегда хороший геймдизайнер и не всегда понимает почему в игре так или иначе).
Ну и вообще гибкость настольной игры часто переоценена, там мастер во-первых часто пытается самоутвердиться как главный, поэтому может толкать всякую дичь, во-вторых, он зачастую ограничен тем, что подготовил, и на какие-то попытки уйти с мейнквеста просто скажет нет, да и вообще, часто транслирует свои представления о мире и политике, так что попросту не может обработать все возможные заявки и укладывает все в довольно однообразные трактовки.
> "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения
Ты прочитал про перестрелку с ФБР, которую я тебе скидывал, где преступник с 5-12 пулевыми ранениями, простреленными ступнями, и продырявленным легким, подошел к их машине, застрелил двоих, и потом попытался ее угнать?
> Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.
Тут большой спектр, начиная с позвали в группу мастера по объявлению, до сходили в платный клуб, до водит просто приятель или знакомый, не друг. В общем, чаще проще поменять мастера, или группу, чем пытаться отменить левое домашнее правило (а мастер не всегда хороший геймдизайнер и не всегда понимает почему в игре так или иначе).
Ну и вообще гибкость настольной игры часто переоценена, там мастер во-первых часто пытается самоутвердиться как главный, поэтому может толкать всякую дичь, во-вторых, он зачастую ограничен тем, что подготовил, и на какие-то попытки уйти с мейнквеста просто скажет нет, да и вообще, часто транслирует свои представления о мире и политике, так что попросту не может обработать все возможные заявки и укладывает все в довольно однообразные трактовки.
>>836538
Так вот оно что...
А приближение скачками было из за пиксель-перфект камеры. В ней зум может только определенные значения принимать. Ну да не важно, я ее убрал уже.
Ну и жесть. То есть моб не сдох, но при этом все равно упал на пол как дроп. Это ж, блин, в двух соседних строчках происходит, как так...
О да! Да!
Наверно не самая очевидная механика, я понимаю.
Ну да, я примерно так и понял. Нормальный тест должен быть почти таким же сложным как и то что он тестит. Достаточно узкоспециализированная штука, получается.
когда радиальную менюху кодил. Сегодня все исправил как раз.
В основном это рудимент с тех времен когда анатомия была вообще у всех предметов. Тело то у всего есть, а голова - не обязательно.
Ну и еще, таким образом получается, что все другие части крепятся к корню через одно соединение. Ну типа глубина иерархии всего 1. Это удобно.
А чем годот выигрывает у юнити в плане... сложившейся политической ситуации? Я просто не особо в курсе.
Так или иначе, я потратил уйму времени даже не на изучение самого юнити а на изучение unity DOTS, на котором все и сделано. Теперь чтобы эту игру перенести на что-то другое я даже не знаю сколько времени нужно потратить. Проще уж другой проект начать.
Но так, да, мне нравится в 2д работать. Может когда-нибудь и годо тоже изучу, но уже явно что-то другое буду на нем делать.
>мышка
Так вот оно что...
А приближение скачками было из за пиксель-перфект камеры. В ней зум может только определенные значения принимать. Ну да не важно, я ее убрал уже.
>грудная клетка
Ну и жесть. То есть моб не сдох, но при этом все равно упал на пол как дроп. Это ж, блин, в двух соседних строчках происходит, как так...
>регенерировать оторванные конечности
О да! Да!
Наверно не самая очевидная механика, я понимаю.
>Тесты
Ну да, я примерно так и понял. Нормальный тест должен быть почти таким же сложным как и то что он тестит. Достаточно узкоспециализированная штука, получается.
>Как сломал менюинг?
когда радиальную менюху кодил. Сегодня все исправил как раз.
>Почему тело а не голова?
В основном это рудимент с тех времен когда анатомия была вообще у всех предметов. Тело то у всего есть, а голова - не обязательно.
Ну и еще, таким образом получается, что все другие части крепятся к корню через одно соединение. Ну типа глубина иерархии всего 1. Это удобно.
>Годот
А чем годот выигрывает у юнити в плане... сложившейся политической ситуации? Я просто не особо в курсе.
Так или иначе, я потратил уйму времени даже не на изучение самого юнити а на изучение unity DOTS, на котором все и сделано. Теперь чтобы эту игру перенести на что-то другое я даже не знаю сколько времени нужно потратить. Проще уж другой проект начать.
Но так, да, мне нравится в 2д работать. Может когда-нибудь и годо тоже изучу, но уже явно что-то другое буду на нем делать.
>>836538
Так вот оно что...
А приближение скачками было из за пиксель-перфект камеры. В ней зум может только определенные значения принимать. Ну да не важно, я ее убрал уже.
Ну и жесть. То есть моб не сдох, но при этом все равно упал на пол как дроп. Это ж, блин, в двух соседних строчках происходит, как так...
О да! Да!
Наверно не самая очевидная механика, я понимаю.
Ну да, я примерно так и понял. Нормальный тест должен быть почти таким же сложным как и то что он тестит. Достаточно узкоспециализированная штука, получается.
когда радиальную менюху кодил. Сегодня все исправил как раз.
В основном это рудимент с тех времен когда анатомия была вообще у всех предметов. Тело то у всего есть, а голова - не обязательно.
Ну и еще, таким образом получается, что все другие части крепятся к корню через одно соединение. Ну типа глубина иерархии всего 1. Это удобно.
А чем годот выигрывает у юнити в плане... сложившейся политической ситуации? Я просто не особо в курсе.
Так или иначе, я потратил уйму времени даже не на изучение самого юнити а на изучение unity DOTS, на котором все и сделано. Теперь чтобы эту игру перенести на что-то другое я даже не знаю сколько времени нужно потратить. Проще уж другой проект начать.
Но так, да, мне нравится в 2д работать. Может когда-нибудь и годо тоже изучу, но уже явно что-то другое буду на нем делать.
>мышка
Так вот оно что...
А приближение скачками было из за пиксель-перфект камеры. В ней зум может только определенные значения принимать. Ну да не важно, я ее убрал уже.
>грудная клетка
Ну и жесть. То есть моб не сдох, но при этом все равно упал на пол как дроп. Это ж, блин, в двух соседних строчках происходит, как так...
>регенерировать оторванные конечности
О да! Да!
Наверно не самая очевидная механика, я понимаю.
>Тесты
Ну да, я примерно так и понял. Нормальный тест должен быть почти таким же сложным как и то что он тестит. Достаточно узкоспециализированная штука, получается.
>Как сломал менюинг?
когда радиальную менюху кодил. Сегодня все исправил как раз.
>Почему тело а не голова?
В основном это рудимент с тех времен когда анатомия была вообще у всех предметов. Тело то у всего есть, а голова - не обязательно.
Ну и еще, таким образом получается, что все другие части крепятся к корню через одно соединение. Ну типа глубина иерархии всего 1. Это удобно.
>Годот
А чем годот выигрывает у юнити в плане... сложившейся политической ситуации? Я просто не особо в курсе.
Так или иначе, я потратил уйму времени даже не на изучение самого юнити а на изучение unity DOTS, на котором все и сделано. Теперь чтобы эту игру перенести на что-то другое я даже не знаю сколько времени нужно потратить. Проще уж другой проект начать.
Но так, да, мне нравится в 2д работать. Может когда-нибудь и годо тоже изучу, но уже явно что-то другое буду на нем делать.
35,4 Мб, mp4,1440x900, 24:14
>>836679
Мы об играх говорим или о чём? В игре твой персонаж может и сотню пулевых ранений перенести без использования аптечек, но у него останется одно очко здоровья - после потери которого он сдохнет. Вот чтобы игрок аккуратнее играл и не ловил пули безрассудно, нужны штрафы за потерю здоровья, чтобы он каждый раз думал головой, прежде чем лезть прямо под пули. А что там какие-то люди получали ранения - это игр не касается. Т.е. ты снова не уловил изначальный контекст.
Лол, ну и зачем они нужны)
>>836704
Позже я прочитал о ней в инвентаре. Да, неочевидная, потому что конечность буквально отрывает, т.е. начисто, а она вырастает снова как у ящерицы. Играл котом, ему оторвало хвост, я подобрал хвост и потом отрастил хвост заново - теперь у него два хвоста... Впрочем, я не представляю себе, как можно отыграться с оторванными конечностями без использования /b/омбы, если даже крысы жутко буйные и прочные, а основные враги укладываются с 2-3 бомб минимум.
Понимаю. Но я бы распределил логику по частям тела, чтобы мобу хотя бы отрывало весь интеллект вместе с головой, даже если голова не является корнем.
Мне кажется, что такое обилие багов у тебя из-за этого DOTS. Не в том смысле, что баги не в твоём коде, а в том смысле, что писать код под DOTS значительно сложнее, чем на простом ООП. Также у меня ощущение, что часть кода у тебя работает в параллельных потоках, из-за чего могут возникать такие ошибки с ожившими трупами и т.п. Сомневаюсь, что прирост производительности стоит таких жертв, если этот прирост вообще есть...
Ты не понял, этим летом менеджеры Юнити как корпорации вложились в маркетинг, произведя слияние с одной мутной конторой, а их главная шишка безо всякого стеснения обосрал индюков, высказавшись по поводу того, что игры необходимо монетизировать. Перед этим Юнити знатно обсрались, отменив разработку демо-проекта и уволив 300 разработчиков, с ним связанных. Алсо у людей накопилось негодование тем, что важные баги не фиксят годами, а тут такие неоднозначные ходы один за другим. А ещё акции U$ в этом году серьёзно просели. Короче, разработчики побежали как крысы с тонущего корабля - искать новые движки под свои проекты.
Ну а Годо последнее время набирает популярность и отличается опенсурсностью - т.е. что бы там ни делали основные разработчики, всегда можно сделать форк и продолжить разработку независимо от них, они не имеют права этому помешать. Если Юнити завтра решит, что её движок должны использовать только ААА студии - все индюки пукнут и обмякнут, а с Годо этого не может произойти по определению опенсурса. Конечно, есть очень много других опенсурс движков, но они намного меньше похожи на Юнити, имеют значительно меньшую популярность и поддержку, и зачастую стрёмную GPL лицензию, которая не позволяет захапать исходники и делать с ними всякое...
Я тут попытался пройти всю игру котом с бомбами, и это было максимально уныло и утомительно. Сначала мне приходилось перезапускать игру, потому что при подборе предметов котом иногда возникает баг с потерей управления. В конце концов решил вообще ничего с пола не подбирать, только есть еду.
Самый главный враг игрока на данный момент - процедурная генерация подземелья. На уровне совершенно нечем заняться кроме убийства мобов, сбора еды и бесполезного мусора. Но при этом уровень - сраный лабиринт с кучей длинных коридоров, поворотов и тупиков, в котором нужно найти сраный выход на следующий этаж. А иногда этот выход может быть прямо рядом со входом, и тогда мотивации бегать по этим унылым коридорам вообще нет. Я специально использовал дебаг-бомбу, ожидая пройти игру очень быстро, но без подрыва стен поиск выхода оказался уж слишком долгим. 99% времени ты просто идёшь по пустым коридорам. Может быть, сократить площадь уровней? Сделать их компактнее. Не знаю, в Shattered Pixel Dungeon мне поиск выхода не казался настолько унылым занятием, а там аж 25 этажей.
Кроме того, боёвка совершенно дисбалансная, если раньше я сомневался в этом, то теперь убеждён. Да, я играл безоружным котом, но всё же могу оценить силу врагов и эффективность находимого оружия (пробовал до булавы, которая на 100 дамага, лучше неё не видел). Так вот, ты 99% времени бегаешь по пустым коридорам с редкими крысами, а потом на тебя внезапно нападает 5+ мощных монстров, от которых никак не отстать и даже бомб нужно по 4+ штук на одного. Это издательство, как будто ты специально пытаешься убить игрока после долгих минут унылой ходьбы. Это не "хардкор", тут тебя просто выносят без вариантов, и это после унылой ходьбы по пустым коридорам. А могут вынести с самого входа на уровень, при том первый удар наносят ещё до того, как у тебя вся графика прогрузится. Снова упоминаю Shattered Pixel Dungeon - там, конечно, тебя тоже могут легко убить, но если делать всё аккуратно, ты можешь постепенно продвигаться вглубь и получать оружие всё лучше и лучше, прокачиваться и открывать способности и т.д., при этом враги на уровнях распределены достаточно равномерно.
Что делать на уровне Pit 5 я вообще не понял, полная тьма и какие-то змеи с огромным здоровьем. Да, я проскочил Dungeon 5, наверное, там был какой-то босс или что-то вроде, ты вроде упоминал об этом. Но какой смысл тогда давать спуск вниз, если нужно зачистить уровень? Учитывая унылую ходьбу по уровню, лежащий рядом со входом выход выглядит приоритетной целью.
Я, конечно, не фанат рогаликов и тем более хардкорных игр, так что можешь ко мне не прислушиваться, но всё-таки мне кажется, что тебе ещё далеко до хорошо сбалансированного рогалика. Особенно если хочешь придерживаться отсутствия прокачки с открытием и улучшением классовых способностей (как в SPD - "невидимость" и т.п.). Прокачка у тебя есть, но даже если удастся поднять уровень, максимум это даст мизерную прибавку к урону, если я правильно понял надписи в инвентаре.
Бесконечную дебаг-/б/омбу оставь, лол, только добавь какую-нибудь чит-комбинацию для её разблокировки ("добропожаловатьснова"?). Взрывать всё и всех подряд хотя бы веселее, чем бесцельно бродить по пустым слишком длинным коридорам и дохнуть от группы перекаченных гопников.
>с 5-12 пулевыми ранениями
Мы об играх говорим или о чём? В игре твой персонаж может и сотню пулевых ранений перенести без использования аптечек, но у него останется одно очко здоровья - после потери которого он сдохнет. Вот чтобы игрок аккуратнее играл и не ловил пули безрассудно, нужны штрафы за потерю здоровья, чтобы он каждый раз думал головой, прежде чем лезть прямо под пули. А что там какие-то люди получали ранения - это игр не касается. Т.е. ты снова не уловил изначальный контекст.
>гибкость настольной игры часто переоценена
Лол, ну и зачем они нужны)
>>836704
>Наверно не самая очевидная механика
Позже я прочитал о ней в инвентаре. Да, неочевидная, потому что конечность буквально отрывает, т.е. начисто, а она вырастает снова как у ящерицы. Играл котом, ему оторвало хвост, я подобрал хвост и потом отрастил хвост заново - теперь у него два хвоста... Впрочем, я не представляю себе, как можно отыграться с оторванными конечностями без использования /b/омбы, если даже крысы жутко буйные и прочные, а основные враги укладываются с 2-3 бомб минимум.
>типа глубина иерархии всего 1
Понимаю. Но я бы распределил логику по частям тела, чтобы мобу хотя бы отрывало весь интеллект вместе с головой, даже если голова не является корнем.
>unity DOTS, на котором все и сделано
Мне кажется, что такое обилие багов у тебя из-за этого DOTS. Не в том смысле, что баги не в твоём коде, а в том смысле, что писать код под DOTS значительно сложнее, чем на простом ООП. Также у меня ощущение, что часть кода у тебя работает в параллельных потоках, из-за чего могут возникать такие ошибки с ожившими трупами и т.п. Сомневаюсь, что прирост производительности стоит таких жертв, если этот прирост вообще есть...
>чем годот выигрывает
>политической ситуации
Ты не понял, этим летом менеджеры Юнити как корпорации вложились в маркетинг, произведя слияние с одной мутной конторой, а их главная шишка безо всякого стеснения обосрал индюков, высказавшись по поводу того, что игры необходимо монетизировать. Перед этим Юнити знатно обсрались, отменив разработку демо-проекта и уволив 300 разработчиков, с ним связанных. Алсо у людей накопилось негодование тем, что важные баги не фиксят годами, а тут такие неоднозначные ходы один за другим. А ещё акции U$ в этом году серьёзно просели. Короче, разработчики побежали как крысы с тонущего корабля - искать новые движки под свои проекты.
Ну а Годо последнее время набирает популярность и отличается опенсурсностью - т.е. что бы там ни делали основные разработчики, всегда можно сделать форк и продолжить разработку независимо от них, они не имеют права этому помешать. Если Юнити завтра решит, что её движок должны использовать только ААА студии - все индюки пукнут и обмякнут, а с Годо этого не может произойти по определению опенсурса. Конечно, есть очень много других опенсурс движков, но они намного меньше похожи на Юнити, имеют значительно меньшую популярность и поддержку, и зачастую стрёмную GPL лицензию, которая не позволяет захапать исходники и делать с ними всякое...
Я тут попытался пройти всю игру котом с бомбами, и это было максимально уныло и утомительно. Сначала мне приходилось перезапускать игру, потому что при подборе предметов котом иногда возникает баг с потерей управления. В конце концов решил вообще ничего с пола не подбирать, только есть еду.
Самый главный враг игрока на данный момент - процедурная генерация подземелья. На уровне совершенно нечем заняться кроме убийства мобов, сбора еды и бесполезного мусора. Но при этом уровень - сраный лабиринт с кучей длинных коридоров, поворотов и тупиков, в котором нужно найти сраный выход на следующий этаж. А иногда этот выход может быть прямо рядом со входом, и тогда мотивации бегать по этим унылым коридорам вообще нет. Я специально использовал дебаг-бомбу, ожидая пройти игру очень быстро, но без подрыва стен поиск выхода оказался уж слишком долгим. 99% времени ты просто идёшь по пустым коридорам. Может быть, сократить площадь уровней? Сделать их компактнее. Не знаю, в Shattered Pixel Dungeon мне поиск выхода не казался настолько унылым занятием, а там аж 25 этажей.
Кроме того, боёвка совершенно дисбалансная, если раньше я сомневался в этом, то теперь убеждён. Да, я играл безоружным котом, но всё же могу оценить силу врагов и эффективность находимого оружия (пробовал до булавы, которая на 100 дамага, лучше неё не видел). Так вот, ты 99% времени бегаешь по пустым коридорам с редкими крысами, а потом на тебя внезапно нападает 5+ мощных монстров, от которых никак не отстать и даже бомб нужно по 4+ штук на одного. Это издательство, как будто ты специально пытаешься убить игрока после долгих минут унылой ходьбы. Это не "хардкор", тут тебя просто выносят без вариантов, и это после унылой ходьбы по пустым коридорам. А могут вынести с самого входа на уровень, при том первый удар наносят ещё до того, как у тебя вся графика прогрузится. Снова упоминаю Shattered Pixel Dungeon - там, конечно, тебя тоже могут легко убить, но если делать всё аккуратно, ты можешь постепенно продвигаться вглубь и получать оружие всё лучше и лучше, прокачиваться и открывать способности и т.д., при этом враги на уровнях распределены достаточно равномерно.
Что делать на уровне Pit 5 я вообще не понял, полная тьма и какие-то змеи с огромным здоровьем. Да, я проскочил Dungeon 5, наверное, там был какой-то босс или что-то вроде, ты вроде упоминал об этом. Но какой смысл тогда давать спуск вниз, если нужно зачистить уровень? Учитывая унылую ходьбу по уровню, лежащий рядом со входом выход выглядит приоритетной целью.
Я, конечно, не фанат рогаликов и тем более хардкорных игр, так что можешь ко мне не прислушиваться, но всё-таки мне кажется, что тебе ещё далеко до хорошо сбалансированного рогалика. Особенно если хочешь придерживаться отсутствия прокачки с открытием и улучшением классовых способностей (как в SPD - "невидимость" и т.п.). Прокачка у тебя есть, но даже если удастся поднять уровень, максимум это даст мизерную прибавку к урону, если я правильно понял надписи в инвентаре.
Бесконечную дебаг-/б/омбу оставь, лол, только добавь какую-нибудь чит-комбинацию для её разблокировки ("добропожаловатьснова"?). Взрывать всё и всех подряд хотя бы веселее, чем бесцельно бродить по пустым слишком длинным коридорам и дохнуть от группы перекаченных гопников.
35,4 Мб, mp4,1440x900, 24:14
>>836679
Мы об играх говорим или о чём? В игре твой персонаж может и сотню пулевых ранений перенести без использования аптечек, но у него останется одно очко здоровья - после потери которого он сдохнет. Вот чтобы игрок аккуратнее играл и не ловил пули безрассудно, нужны штрафы за потерю здоровья, чтобы он каждый раз думал головой, прежде чем лезть прямо под пули. А что там какие-то люди получали ранения - это игр не касается. Т.е. ты снова не уловил изначальный контекст.
Лол, ну и зачем они нужны)
>>836704
Позже я прочитал о ней в инвентаре. Да, неочевидная, потому что конечность буквально отрывает, т.е. начисто, а она вырастает снова как у ящерицы. Играл котом, ему оторвало хвост, я подобрал хвост и потом отрастил хвост заново - теперь у него два хвоста... Впрочем, я не представляю себе, как можно отыграться с оторванными конечностями без использования /b/омбы, если даже крысы жутко буйные и прочные, а основные враги укладываются с 2-3 бомб минимум.
Понимаю. Но я бы распределил логику по частям тела, чтобы мобу хотя бы отрывало весь интеллект вместе с головой, даже если голова не является корнем.
Мне кажется, что такое обилие багов у тебя из-за этого DOTS. Не в том смысле, что баги не в твоём коде, а в том смысле, что писать код под DOTS значительно сложнее, чем на простом ООП. Также у меня ощущение, что часть кода у тебя работает в параллельных потоках, из-за чего могут возникать такие ошибки с ожившими трупами и т.п. Сомневаюсь, что прирост производительности стоит таких жертв, если этот прирост вообще есть...
Ты не понял, этим летом менеджеры Юнити как корпорации вложились в маркетинг, произведя слияние с одной мутной конторой, а их главная шишка безо всякого стеснения обосрал индюков, высказавшись по поводу того, что игры необходимо монетизировать. Перед этим Юнити знатно обсрались, отменив разработку демо-проекта и уволив 300 разработчиков, с ним связанных. Алсо у людей накопилось негодование тем, что важные баги не фиксят годами, а тут такие неоднозначные ходы один за другим. А ещё акции U$ в этом году серьёзно просели. Короче, разработчики побежали как крысы с тонущего корабля - искать новые движки под свои проекты.
Ну а Годо последнее время набирает популярность и отличается опенсурсностью - т.е. что бы там ни делали основные разработчики, всегда можно сделать форк и продолжить разработку независимо от них, они не имеют права этому помешать. Если Юнити завтра решит, что её движок должны использовать только ААА студии - все индюки пукнут и обмякнут, а с Годо этого не может произойти по определению опенсурса. Конечно, есть очень много других опенсурс движков, но они намного меньше похожи на Юнити, имеют значительно меньшую популярность и поддержку, и зачастую стрёмную GPL лицензию, которая не позволяет захапать исходники и делать с ними всякое...
Я тут попытался пройти всю игру котом с бомбами, и это было максимально уныло и утомительно. Сначала мне приходилось перезапускать игру, потому что при подборе предметов котом иногда возникает баг с потерей управления. В конце концов решил вообще ничего с пола не подбирать, только есть еду.
Самый главный враг игрока на данный момент - процедурная генерация подземелья. На уровне совершенно нечем заняться кроме убийства мобов, сбора еды и бесполезного мусора. Но при этом уровень - сраный лабиринт с кучей длинных коридоров, поворотов и тупиков, в котором нужно найти сраный выход на следующий этаж. А иногда этот выход может быть прямо рядом со входом, и тогда мотивации бегать по этим унылым коридорам вообще нет. Я специально использовал дебаг-бомбу, ожидая пройти игру очень быстро, но без подрыва стен поиск выхода оказался уж слишком долгим. 99% времени ты просто идёшь по пустым коридорам. Может быть, сократить площадь уровней? Сделать их компактнее. Не знаю, в Shattered Pixel Dungeon мне поиск выхода не казался настолько унылым занятием, а там аж 25 этажей.
Кроме того, боёвка совершенно дисбалансная, если раньше я сомневался в этом, то теперь убеждён. Да, я играл безоружным котом, но всё же могу оценить силу врагов и эффективность находимого оружия (пробовал до булавы, которая на 100 дамага, лучше неё не видел). Так вот, ты 99% времени бегаешь по пустым коридорам с редкими крысами, а потом на тебя внезапно нападает 5+ мощных монстров, от которых никак не отстать и даже бомб нужно по 4+ штук на одного. Это издательство, как будто ты специально пытаешься убить игрока после долгих минут унылой ходьбы. Это не "хардкор", тут тебя просто выносят без вариантов, и это после унылой ходьбы по пустым коридорам. А могут вынести с самого входа на уровень, при том первый удар наносят ещё до того, как у тебя вся графика прогрузится. Снова упоминаю Shattered Pixel Dungeon - там, конечно, тебя тоже могут легко убить, но если делать всё аккуратно, ты можешь постепенно продвигаться вглубь и получать оружие всё лучше и лучше, прокачиваться и открывать способности и т.д., при этом враги на уровнях распределены достаточно равномерно.
Что делать на уровне Pit 5 я вообще не понял, полная тьма и какие-то змеи с огромным здоровьем. Да, я проскочил Dungeon 5, наверное, там был какой-то босс или что-то вроде, ты вроде упоминал об этом. Но какой смысл тогда давать спуск вниз, если нужно зачистить уровень? Учитывая унылую ходьбу по уровню, лежащий рядом со входом выход выглядит приоритетной целью.
Я, конечно, не фанат рогаликов и тем более хардкорных игр, так что можешь ко мне не прислушиваться, но всё-таки мне кажется, что тебе ещё далеко до хорошо сбалансированного рогалика. Особенно если хочешь придерживаться отсутствия прокачки с открытием и улучшением классовых способностей (как в SPD - "невидимость" и т.п.). Прокачка у тебя есть, но даже если удастся поднять уровень, максимум это даст мизерную прибавку к урону, если я правильно понял надписи в инвентаре.
Бесконечную дебаг-/б/омбу оставь, лол, только добавь какую-нибудь чит-комбинацию для её разблокировки ("добропожаловатьснова"?). Взрывать всё и всех подряд хотя бы веселее, чем бесцельно бродить по пустым слишком длинным коридорам и дохнуть от группы перекаченных гопников.
>с 5-12 пулевыми ранениями
Мы об играх говорим или о чём? В игре твой персонаж может и сотню пулевых ранений перенести без использования аптечек, но у него останется одно очко здоровья - после потери которого он сдохнет. Вот чтобы игрок аккуратнее играл и не ловил пули безрассудно, нужны штрафы за потерю здоровья, чтобы он каждый раз думал головой, прежде чем лезть прямо под пули. А что там какие-то люди получали ранения - это игр не касается. Т.е. ты снова не уловил изначальный контекст.
>гибкость настольной игры часто переоценена
Лол, ну и зачем они нужны)
>>836704
>Наверно не самая очевидная механика
Позже я прочитал о ней в инвентаре. Да, неочевидная, потому что конечность буквально отрывает, т.е. начисто, а она вырастает снова как у ящерицы. Играл котом, ему оторвало хвост, я подобрал хвост и потом отрастил хвост заново - теперь у него два хвоста... Впрочем, я не представляю себе, как можно отыграться с оторванными конечностями без использования /b/омбы, если даже крысы жутко буйные и прочные, а основные враги укладываются с 2-3 бомб минимум.
>типа глубина иерархии всего 1
Понимаю. Но я бы распределил логику по частям тела, чтобы мобу хотя бы отрывало весь интеллект вместе с головой, даже если голова не является корнем.
>unity DOTS, на котором все и сделано
Мне кажется, что такое обилие багов у тебя из-за этого DOTS. Не в том смысле, что баги не в твоём коде, а в том смысле, что писать код под DOTS значительно сложнее, чем на простом ООП. Также у меня ощущение, что часть кода у тебя работает в параллельных потоках, из-за чего могут возникать такие ошибки с ожившими трупами и т.п. Сомневаюсь, что прирост производительности стоит таких жертв, если этот прирост вообще есть...
>чем годот выигрывает
>политической ситуации
Ты не понял, этим летом менеджеры Юнити как корпорации вложились в маркетинг, произведя слияние с одной мутной конторой, а их главная шишка безо всякого стеснения обосрал индюков, высказавшись по поводу того, что игры необходимо монетизировать. Перед этим Юнити знатно обсрались, отменив разработку демо-проекта и уволив 300 разработчиков, с ним связанных. Алсо у людей накопилось негодование тем, что важные баги не фиксят годами, а тут такие неоднозначные ходы один за другим. А ещё акции U$ в этом году серьёзно просели. Короче, разработчики побежали как крысы с тонущего корабля - искать новые движки под свои проекты.
Ну а Годо последнее время набирает популярность и отличается опенсурсностью - т.е. что бы там ни делали основные разработчики, всегда можно сделать форк и продолжить разработку независимо от них, они не имеют права этому помешать. Если Юнити завтра решит, что её движок должны использовать только ААА студии - все индюки пукнут и обмякнут, а с Годо этого не может произойти по определению опенсурса. Конечно, есть очень много других опенсурс движков, но они намного меньше похожи на Юнити, имеют значительно меньшую популярность и поддержку, и зачастую стрёмную GPL лицензию, которая не позволяет захапать исходники и делать с ними всякое...
Я тут попытался пройти всю игру котом с бомбами, и это было максимально уныло и утомительно. Сначала мне приходилось перезапускать игру, потому что при подборе предметов котом иногда возникает баг с потерей управления. В конце концов решил вообще ничего с пола не подбирать, только есть еду.
Самый главный враг игрока на данный момент - процедурная генерация подземелья. На уровне совершенно нечем заняться кроме убийства мобов, сбора еды и бесполезного мусора. Но при этом уровень - сраный лабиринт с кучей длинных коридоров, поворотов и тупиков, в котором нужно найти сраный выход на следующий этаж. А иногда этот выход может быть прямо рядом со входом, и тогда мотивации бегать по этим унылым коридорам вообще нет. Я специально использовал дебаг-бомбу, ожидая пройти игру очень быстро, но без подрыва стен поиск выхода оказался уж слишком долгим. 99% времени ты просто идёшь по пустым коридорам. Может быть, сократить площадь уровней? Сделать их компактнее. Не знаю, в Shattered Pixel Dungeon мне поиск выхода не казался настолько унылым занятием, а там аж 25 этажей.
Кроме того, боёвка совершенно дисбалансная, если раньше я сомневался в этом, то теперь убеждён. Да, я играл безоружным котом, но всё же могу оценить силу врагов и эффективность находимого оружия (пробовал до булавы, которая на 100 дамага, лучше неё не видел). Так вот, ты 99% времени бегаешь по пустым коридорам с редкими крысами, а потом на тебя внезапно нападает 5+ мощных монстров, от которых никак не отстать и даже бомб нужно по 4+ штук на одного. Это издательство, как будто ты специально пытаешься убить игрока после долгих минут унылой ходьбы. Это не "хардкор", тут тебя просто выносят без вариантов, и это после унылой ходьбы по пустым коридорам. А могут вынести с самого входа на уровень, при том первый удар наносят ещё до того, как у тебя вся графика прогрузится. Снова упоминаю Shattered Pixel Dungeon - там, конечно, тебя тоже могут легко убить, но если делать всё аккуратно, ты можешь постепенно продвигаться вглубь и получать оружие всё лучше и лучше, прокачиваться и открывать способности и т.д., при этом враги на уровнях распределены достаточно равномерно.
Что делать на уровне Pit 5 я вообще не понял, полная тьма и какие-то змеи с огромным здоровьем. Да, я проскочил Dungeon 5, наверное, там был какой-то босс или что-то вроде, ты вроде упоминал об этом. Но какой смысл тогда давать спуск вниз, если нужно зачистить уровень? Учитывая унылую ходьбу по уровню, лежащий рядом со входом выход выглядит приоритетной целью.
Я, конечно, не фанат рогаликов и тем более хардкорных игр, так что можешь ко мне не прислушиваться, но всё-таки мне кажется, что тебе ещё далеко до хорошо сбалансированного рогалика. Особенно если хочешь придерживаться отсутствия прокачки с открытием и улучшением классовых способностей (как в SPD - "невидимость" и т.п.). Прокачка у тебя есть, но даже если удастся поднять уровень, максимум это даст мизерную прибавку к урону, если я правильно понял надписи в инвентаре.
Бесконечную дебаг-/б/омбу оставь, лол, только добавь какую-нибудь чит-комбинацию для её разблокировки ("добропожаловатьснова"?). Взрывать всё и всех подряд хотя бы веселее, чем бесцельно бродить по пустым слишком длинным коридорам и дохнуть от группы перекаченных гопников.
>>836709
Братишка, это так не работает. Игра всегда моделирует что-то, а то, что она моделирует, даже фантастическое, опирается на ИРЛ. Поэтому ты и аргументируешь понятиями "пулевые ранения", "аппарат ИВЛ". То есть изначально твой тезис был, что с 1 хп надо не бегать, а лежать в реанимации, и это основано на том, что ты в голове представляешь себе, как бы это происходило IRL.
Теперь ты, правда, сменил тезис на то, что игрок обязан играть осторожнее с 1 хп - так это уже его дело, это выбор его стратегии, как он будет поступать, обычно в играх и так есть наказание в виде смерти, и если он будет играть неаккуратно, то проиграет и сделает выводы и в следующий раз научится или не терять хп, или беречь последний, отстреливать монстров по одному из за угла.
>Мы об играх говорим или о чём? А что там какие-то люди получали ранения - это игр не касается.
Братишка, это так не работает. Игра всегда моделирует что-то, а то, что она моделирует, даже фантастическое, опирается на ИРЛ. Поэтому ты и аргументируешь понятиями "пулевые ранения", "аппарат ИВЛ". То есть изначально твой тезис был, что с 1 хп надо не бегать, а лежать в реанимации, и это основано на том, что ты в голове представляешь себе, как бы это происходило IRL.
Теперь ты, правда, сменил тезис на то, что игрок обязан играть осторожнее с 1 хп - так это уже его дело, это выбор его стратегии, как он будет поступать, обычно в играх и так есть наказание в виде смерти, и если он будет играть неаккуратно, то проиграет и сделает выводы и в следующий раз научится или не терять хп, или беречь последний, отстреливать монстров по одному из за угла.
>>836599
Раньше в побитом состоянии у тебя все действия замедлялись. Это намного жестче, чем то что сейчас.
Когда тебе оторвало руку - подбираешь оружие, берешь в другую разницы между левой и правой нет в этом плане, убиваешь моба, съедаешь его, отращиваешь руку обратно.
Если тебе оторвало обе руки то скорее всего - горе побежденным.
Но даже без рук ты можешь убежать, наесться грибов, отрастить руки и вернуться.
Бить без рук бодать ты, кстати, все равно можешь, это будет наносить столько же урона как и атака без оружия.
-Оп
>Лол, а как же отрывание рук?
Раньше в побитом состоянии у тебя все действия замедлялись. Это намного жестче, чем то что сейчас.
Когда тебе оторвало руку - подбираешь оружие, берешь в другую разницы между левой и правой нет в этом плане, убиваешь моба, съедаешь его, отращиваешь руку обратно.
Если тебе оторвало обе руки то скорее всего - горе побежденным.
Но даже без рук ты можешь убежать, наесться грибов, отрастить руки и вернуться.
Бить без рук бодать ты, кстати, все равно можешь, это будет наносить столько же урона как и атака без оружия.
-Оп
>>836745
Могу выступить тестером билда для линукса! алсо, запиливал проект на юнити и билдил для линукса, проблем, вроде не было..
Могу выступить тестером билда для линукса! алсо, запиливал проект на юнити и билдил для линукса, проблем, вроде не было..
>>836709
На кота забей, серьезно. Им невозможно пройти игру. Мне стоило одного клика добавить возможность за него играть, и я решил по приколу это сделать.
Pit 5 это знаменитая Яма.
Ты падаешь в яму если прыгнешь в пропасть нажав пробел. Яма так же соединена с основным данжем, кажется с пятым уровнем, обычной лестницей. Ты именно так туда попал?
Сейчас это сделано не особо правильно, таким образом получается что с пятого уровня два выхода, что конечно очень запутывает. Какое-то понимание может дать карта, но она тоже недоделанная.
По идее проход из ямы должен работать в одну сторону (из нее) или хотя-бы должен выглядеть по-другому. Раньше так было, но потом я этот момент сломал и забыл вернуть обратно.
По моей задумке яма это что-то типо секретной локации. Так что, кончено, прыжок с обрыва должен быть единственным способом. Если ты туда упал - просто как можно быстрее ищи выход. Змей огромные толпы, отбиться от них почти нереально и они быстрее в воде. Победить их может только чел в очень топовом шмоте, а лучше с отрядом. Так же в яме спавнятся все мобы и предметы, которые когда-либо были туда сброшены.
А ты побывал в городе? Он вроде на третьем этаже или на четвертом. По поводу разнообразия лабиринтов, да, есть такое. Ну вот, город вносит живинку.
Раньше у меня еще были секретные комнаты, но их я тоже сломал и не починил. Надо вернуть.
Еще в игре есть консоль, на / с разными читами, но кажется, из за бага с менюхами в этом билде ей будет очень тяжело пользоваться. Там подсказки которые можно листать табом, а следующие морфемы команды добавляются через точку.
Во всяком случае, команда Spawn.<Id предмета> спавнит его на выделенной клетке.
В целом по поводу хардкора, постараюсь пожелания учесть, но все-же, на мой взгляд, во многих случаях, проблема больше не в цифрах, а скорее в том, что игрок не знает как правильно играть, а ему никто не объясняет.
-Оп
На кота забей, серьезно. Им невозможно пройти игру. Мне стоило одного клика добавить возможность за него играть, и я решил по приколу это сделать.
Pit 5 это знаменитая Яма.
Ты падаешь в яму если прыгнешь в пропасть нажав пробел. Яма так же соединена с основным данжем, кажется с пятым уровнем, обычной лестницей. Ты именно так туда попал?
Сейчас это сделано не особо правильно, таким образом получается что с пятого уровня два выхода, что конечно очень запутывает. Какое-то понимание может дать карта, но она тоже недоделанная.
По идее проход из ямы должен работать в одну сторону (из нее) или хотя-бы должен выглядеть по-другому. Раньше так было, но потом я этот момент сломал и забыл вернуть обратно.
По моей задумке яма это что-то типо секретной локации. Так что, кончено, прыжок с обрыва должен быть единственным способом. Если ты туда упал - просто как можно быстрее ищи выход. Змей огромные толпы, отбиться от них почти нереально и они быстрее в воде. Победить их может только чел в очень топовом шмоте, а лучше с отрядом. Так же в яме спавнятся все мобы и предметы, которые когда-либо были туда сброшены.
А ты побывал в городе? Он вроде на третьем этаже или на четвертом. По поводу разнообразия лабиринтов, да, есть такое. Ну вот, город вносит живинку.
Раньше у меня еще были секретные комнаты, но их я тоже сломал и не починил. Надо вернуть.
Еще в игре есть консоль, на / с разными читами, но кажется, из за бага с менюхами в этом билде ей будет очень тяжело пользоваться. Там подсказки которые можно листать табом, а следующие морфемы команды добавляются через точку.
Во всяком случае, команда Spawn.<Id предмета> спавнит его на выделенной клетке.
В целом по поводу хардкора, постараюсь пожелания учесть, но все-же, на мой взгляд, во многих случаях, проблема больше не в цифрах, а скорее в том, что игрок не знает как правильно играть, а ему никто не объясняет.
-Оп
>>836757
Ок, я попробую сделать и билд под линукс, но, получается я его даже протестить не смогу.
Ок, я попробую сделать и билд под линукс, но, получается я его даже протестить не смогу.
130 Кб, 960x960>>836734
Да. Игровой мир. Похожий на наш, но не наш.
Я привёл пример с реанимацией для контраста по сравнению с тем, чем игрок реально занимается с 1 хп. В игре не обязательно моделировать реанимацию, но стоит показать игроку, что персонажу пикрил.jpg и вот-вот настанет конец, если ничего не предпринять. А ты начал приплетать что-то про то, как люди иногда могут совершать героические подвиги на адреналине, прежде чем сдохнуть от потери крови из десятка дырок. К чему это? По-твоему, человеку с десятком кровоточащих дырок так хорошо, что он может часами бегать по большой локации, занимаясь абсолютно неважными делами?
Нет, игрок не "обязан", но должен прийти к этому из поставленных игрой условий. Если игроку недостаточно кровавой рамки по краю экрана, мигающей красной надписи и тяжёлого дыхания персонажа, значит, нужно накладывать другие штрафы, чтобы до тупого игрока наконец-то дошло, что пора бы отступить и подлечиться.
Повторяю, этот спор начался с того, что ОП назвал "неиграбельной" механику штрафов за снижение здоровья, мол, ты не можешь быть супергероем, который мочит всех направо и налево несмотря на повреждения. Я же возразил, что это не механика неиграбельная, а просто он и многие другие игроки привыкли не обращать внимание на уровень здоровья, и поэтому не умеют действовать соответственно уровню здоровья. По факту, механика штрафов за низкий уровень здоровья просто заставляет игрока вовремя отступать, выходить из боя пока это ещё возможно и искать средства для поправки здоровья. В обычной игре ты делаешь это перед добивающим ударом монстра, когда у тебя 1 хп, а в игре со штрафами ты делаешь это до получения штрафов, например, на 50% здоровья. Это не значит, что бои станут короче и скучнее, потому что здоровье можно поднять в два раза и практически ничего не изменится. Но зато "лишние" 50% послужат подушкой безопасности на случай, если ты умудрился каким-то образом серьёзно ранить себя в относительно безопасной ситуации - к примеру, упав со скалы или подорвавшись на мине - даже получив все возможные штрафы у тебя ещё есть шанс выжить, подлатав себя лечилками из инвентаря, тогда как игровой персонаж без штрафов на здоровье просто-напросто сдохнет, потеряв все очки здоровья.
В этом суть, персонаж со штрафом на здоровье фактически живучее обычного персонажа, но для игры за него нужно иметь другое восприятие игры и персонажа. А ОП просто этого не понял и поэтому решил полностью выпилить такую интересную механику.
>Игра всегда моделирует что-то
Да. Игровой мир. Похожий на наш, но не наш.
>изначально твой тезис был, что с 1 хп надо не бегать, а лежать в реанимации, и это основано на том, что ты в голове представляешь себе, как бы это происходило IRL
Я привёл пример с реанимацией для контраста по сравнению с тем, чем игрок реально занимается с 1 хп. В игре не обязательно моделировать реанимацию, но стоит показать игроку, что персонажу пикрил.jpg и вот-вот настанет конец, если ничего не предпринять. А ты начал приплетать что-то про то, как люди иногда могут совершать героические подвиги на адреналине, прежде чем сдохнуть от потери крови из десятка дырок. К чему это? По-твоему, человеку с десятком кровоточащих дырок так хорошо, что он может часами бегать по большой локации, занимаясь абсолютно неважными делами?
>сменил тезис на то, что игрок обязан играть осторожнее с 1 хп - так это уже его дело
Нет, игрок не "обязан", но должен прийти к этому из поставленных игрой условий. Если игроку недостаточно кровавой рамки по краю экрана, мигающей красной надписи и тяжёлого дыхания персонажа, значит, нужно накладывать другие штрафы, чтобы до тупого игрока наконец-то дошло, что пора бы отступить и подлечиться.
Повторяю, этот спор начался с того, что ОП назвал "неиграбельной" механику штрафов за снижение здоровья, мол, ты не можешь быть супергероем, который мочит всех направо и налево несмотря на повреждения. Я же возразил, что это не механика неиграбельная, а просто он и многие другие игроки привыкли не обращать внимание на уровень здоровья, и поэтому не умеют действовать соответственно уровню здоровья. По факту, механика штрафов за низкий уровень здоровья просто заставляет игрока вовремя отступать, выходить из боя пока это ещё возможно и искать средства для поправки здоровья. В обычной игре ты делаешь это перед добивающим ударом монстра, когда у тебя 1 хп, а в игре со штрафами ты делаешь это до получения штрафов, например, на 50% здоровья. Это не значит, что бои станут короче и скучнее, потому что здоровье можно поднять в два раза и практически ничего не изменится. Но зато "лишние" 50% послужат подушкой безопасности на случай, если ты умудрился каким-то образом серьёзно ранить себя в относительно безопасной ситуации - к примеру, упав со скалы или подорвавшись на мине - даже получив все возможные штрафы у тебя ещё есть шанс выжить, подлатав себя лечилками из инвентаря, тогда как игровой персонаж без штрафов на здоровье просто-напросто сдохнет, потеряв все очки здоровья.
В этом суть, персонаж со штрафом на здоровье фактически живучее обычного персонажа, но для игры за него нужно иметь другое восприятие игры и персонажа. А ОП просто этого не понял и поэтому решил полностью выпилить такую интересную механику.
130 Кб, 960x960>>836734
Да. Игровой мир. Похожий на наш, но не наш.
Я привёл пример с реанимацией для контраста по сравнению с тем, чем игрок реально занимается с 1 хп. В игре не обязательно моделировать реанимацию, но стоит показать игроку, что персонажу пикрил.jpg и вот-вот настанет конец, если ничего не предпринять. А ты начал приплетать что-то про то, как люди иногда могут совершать героические подвиги на адреналине, прежде чем сдохнуть от потери крови из десятка дырок. К чему это? По-твоему, человеку с десятком кровоточащих дырок так хорошо, что он может часами бегать по большой локации, занимаясь абсолютно неважными делами?
Нет, игрок не "обязан", но должен прийти к этому из поставленных игрой условий. Если игроку недостаточно кровавой рамки по краю экрана, мигающей красной надписи и тяжёлого дыхания персонажа, значит, нужно накладывать другие штрафы, чтобы до тупого игрока наконец-то дошло, что пора бы отступить и подлечиться.
Повторяю, этот спор начался с того, что ОП назвал "неиграбельной" механику штрафов за снижение здоровья, мол, ты не можешь быть супергероем, который мочит всех направо и налево несмотря на повреждения. Я же возразил, что это не механика неиграбельная, а просто он и многие другие игроки привыкли не обращать внимание на уровень здоровья, и поэтому не умеют действовать соответственно уровню здоровья. По факту, механика штрафов за низкий уровень здоровья просто заставляет игрока вовремя отступать, выходить из боя пока это ещё возможно и искать средства для поправки здоровья. В обычной игре ты делаешь это перед добивающим ударом монстра, когда у тебя 1 хп, а в игре со штрафами ты делаешь это до получения штрафов, например, на 50% здоровья. Это не значит, что бои станут короче и скучнее, потому что здоровье можно поднять в два раза и практически ничего не изменится. Но зато "лишние" 50% послужат подушкой безопасности на случай, если ты умудрился каким-то образом серьёзно ранить себя в относительно безопасной ситуации - к примеру, упав со скалы или подорвавшись на мине - даже получив все возможные штрафы у тебя ещё есть шанс выжить, подлатав себя лечилками из инвентаря, тогда как игровой персонаж без штрафов на здоровье просто-напросто сдохнет, потеряв все очки здоровья.
В этом суть, персонаж со штрафом на здоровье фактически живучее обычного персонажа, но для игры за него нужно иметь другое восприятие игры и персонажа. А ОП просто этого не понял и поэтому решил полностью выпилить такую интересную механику.
>Игра всегда моделирует что-то
Да. Игровой мир. Похожий на наш, но не наш.
>изначально твой тезис был, что с 1 хп надо не бегать, а лежать в реанимации, и это основано на том, что ты в голове представляешь себе, как бы это происходило IRL
Я привёл пример с реанимацией для контраста по сравнению с тем, чем игрок реально занимается с 1 хп. В игре не обязательно моделировать реанимацию, но стоит показать игроку, что персонажу пикрил.jpg и вот-вот настанет конец, если ничего не предпринять. А ты начал приплетать что-то про то, как люди иногда могут совершать героические подвиги на адреналине, прежде чем сдохнуть от потери крови из десятка дырок. К чему это? По-твоему, человеку с десятком кровоточащих дырок так хорошо, что он может часами бегать по большой локации, занимаясь абсолютно неважными делами?
>сменил тезис на то, что игрок обязан играть осторожнее с 1 хп - так это уже его дело
Нет, игрок не "обязан", но должен прийти к этому из поставленных игрой условий. Если игроку недостаточно кровавой рамки по краю экрана, мигающей красной надписи и тяжёлого дыхания персонажа, значит, нужно накладывать другие штрафы, чтобы до тупого игрока наконец-то дошло, что пора бы отступить и подлечиться.
Повторяю, этот спор начался с того, что ОП назвал "неиграбельной" механику штрафов за снижение здоровья, мол, ты не можешь быть супергероем, который мочит всех направо и налево несмотря на повреждения. Я же возразил, что это не механика неиграбельная, а просто он и многие другие игроки привыкли не обращать внимание на уровень здоровья, и поэтому не умеют действовать соответственно уровню здоровья. По факту, механика штрафов за низкий уровень здоровья просто заставляет игрока вовремя отступать, выходить из боя пока это ещё возможно и искать средства для поправки здоровья. В обычной игре ты делаешь это перед добивающим ударом монстра, когда у тебя 1 хп, а в игре со штрафами ты делаешь это до получения штрафов, например, на 50% здоровья. Это не значит, что бои станут короче и скучнее, потому что здоровье можно поднять в два раза и практически ничего не изменится. Но зато "лишние" 50% послужат подушкой безопасности на случай, если ты умудрился каким-то образом серьёзно ранить себя в относительно безопасной ситуации - к примеру, упав со скалы или подорвавшись на мине - даже получив все возможные штрафы у тебя ещё есть шанс выжить, подлатав себя лечилками из инвентаря, тогда как игровой персонаж без штрафов на здоровье просто-напросто сдохнет, потеряв все очки здоровья.
В этом суть, персонаж со штрафом на здоровье фактически живучее обычного персонажа, но для игры за него нужно иметь другое восприятие игры и персонажа. А ОП просто этого не понял и поэтому решил полностью выпилить такую интересную механику.
>>836738 >>836757
Ты разве не понимаешь, что у него игра в неиграбельном состоянии? Баги такие, что приходится порой несколько раз перезапустить игру, чтобы поиграть больше 10 минут. Бессмысленно тестить билд на линукс, если основа игры такая багнутая. Вот когда пофиксит все эти ошибки, приводящие к зависанию игры или спавну без конечностей, тогда может делать билд на другие ОС.
А ты пока можешь и через вайн запустить.
>>836777
Ну чего ты оправдываешься, поставь виртуалку, вторую ОС на тот же диск, или даже просто запусти портативную версию с флешки. Это же не макинтош и не айос, способов протестировать масса. Тем более что ты говорил что у тебя два полноценных ПК.
Просто сейчас тебе бессмысленно делать билд на линукс, даже если сделаешь, ошибки будут плюс-минус те же, только аноны будут их по второму кругу репортить.
Ты разве не понимаешь, что у него игра в неиграбельном состоянии? Баги такие, что приходится порой несколько раз перезапустить игру, чтобы поиграть больше 10 минут. Бессмысленно тестить билд на линукс, если основа игры такая багнутая. Вот когда пофиксит все эти ошибки, приводящие к зависанию игры или спавну без конечностей, тогда может делать билд на другие ОС.
А ты пока можешь и через вайн запустить.
>>836777
>даже протестить не смогу
Ну чего ты оправдываешься, поставь виртуалку, вторую ОС на тот же диск, или даже просто запусти портативную версию с флешки. Это же не макинтош и не айос, способов протестировать масса. Тем более что ты говорил что у тебя два полноценных ПК.
Просто сейчас тебе бессмысленно делать билд на линукс, даже если сделаешь, ошибки будут плюс-минус те же, только аноны будут их по второму кругу репортить.
266 Кб, 1600x900>>836770
Поздно, я теперь хочу играть котом-нек(р)омантом, взрывая крыс бесконечными нек(р)о-бомбами и поднимая их трупы в свою нек(р)о-армию, а потом целой толпой вынося любых боссов. Делай некромантию, выделишься на фоне унылых рогаликов без некромантии и станешь популярным.
Но сначала пофикси баги.
>На кота забей, серьезно. Им невозможно пройти игру. Мне стоило одного клика добавить возможность за него играть, и я решил по приколу это сделать.
Поздно, я теперь хочу играть котом-нек(р)омантом, взрывая крыс бесконечными нек(р)о-бомбами и поднимая их трупы в свою нек(р)о-армию, а потом целой толпой вынося любых боссов. Делай некромантию, выделишься на фоне унылых рогаликов без некромантии и станешь популярным.
Но сначала пофикси баги.
Запилил патч с фиксами багов.
Надеюсь теперь играть будет поприятнее.
Подкрутил балланс.
Приделал репортилку.
https://vk.com/katabasys?w=wall-201941833_100%2Fall
Почему-то ссылку на скачивание не получилось прикрепить. Так или иначе она всегда есть в закрепленном посте.
Надеюсь теперь играть будет поприятнее.
Подкрутил балланс.
Приделал репортилку.
https://vk.com/katabasys?w=wall-201941833_100%2Fall
Почему-то ссылку на скачивание не получилось прикрепить. Так или иначе она всегда есть в закрепленном посте.
6,6 Мб, 906x881>>836793
Почему бы и нет. Это вполне укладывается в мою концепцию. Если в игре и так можно зазывать в отряд неписей, то почему бы не делать этого и с мертвыми.
Я, кстати, сам стал свидетелем этого леденящего душу явления. Безголовый протей катается по полу заливая все вокруг кровью.
Его можно сожрать)
На самом деле это забавно выглядит, я бы даже это оставил, когда разберусь в чем дело. Но пока не смог разобраться, почему так бывает.
Почему бы и нет. Это вполне укладывается в мою концепцию. Если в игре и так можно зазывать в отряд неписей, то почему бы не делать этого и с мертвыми.
Я, кстати, сам стал свидетелем этого леденящего душу явления. Безголовый протей катается по полу заливая все вокруг кровью.
Его можно сожрать)
На самом деле это забавно выглядит, я бы даже это оставил, когда разберусь в чем дело. Но пока не смог разобраться, почему так бывает.
>>837509
Завтра займусь этим.
Просто я накатил новую билдовую систему, там пока не нашел как это делать.
Завтра займусь этим.
Просто я накатил новую билдовую систему, там пока не нашел как это делать.
>>837517
Ну что там, анончик?
Ну что там, анончик?
>>837509
Вот, держи.
https://drive.google.com/file/d/1-YjgqGI1JNTgu7byaBsPiCgJCGyl6WE6/view?usp=share_link
Я хз что там внутри)
Виртуальную машину я пока не поставил.
Вот, держи.
https://drive.google.com/file/d/1-YjgqGI1JNTgu7byaBsPiCgJCGyl6WE6/view?usp=share_link
Я хз что там внутри)
Виртуальную машину я пока не поставил.
Пофиксил еще кое что. В последней версии как выяснилось, все удары игрока приходились по голое, а я этого даже не заметил когда тестил.
https://vk.com/katabasys?w=wall-201941833_101%2Fall
https://vk.com/katabasys?w=wall-201941833_101%2Fall
80 Кб, 1920x1080>>837628
Зашел в арену, не понял что это, захотел выйти.. Краш, видимо.
Миша, переделывай, все хуйня.
Зашел в арену, не понял что это, захотел выйти.. Краш, видимо.
Миша, переделывай, все хуйня.
Противостою хейтерам лучами добра.
Игра ОПчика на настолько ранней стадии, что любая критика кроме указания конкретных багов - null and void.
Те, кто этого не понимают - не кириллили ни разу в жизни, а следовательно права голоса не имеют.
ОПчик - молодец, особенно для своих лет. Пили дальше, ОПчик, игнорь претензии по вкусовщине и не по делу, старательно фикси баги и YGMI.
Игра ОПчика на настолько ранней стадии, что любая критика кроме указания конкретных багов - null and void.
Те, кто этого не понимают - не кириллили ни разу в жизни, а следовательно права голоса не имеют.
ОПчик - молодец, особенно для своих лет. Пили дальше, ОПчик, игнорь претензии по вкусовщине и не по делу, старательно фикси баги и YGMI.
>>837736
Такой отзыв, хотя и способен меня расстроить, несет в себе не много информации. Укажи конкретно, что для тебя ужасно.
-Оп
Такой отзыв, хотя и способен меня расстроить, несет в себе не много информации. Укажи конкретно, что для тебя ужасно.
-Оп
>>838483
Я бы с радостью разделил твой оптимизм, но то, что он описывает о устройстве игры, больше похоже на разработку методом тыка - тут вопрос времени, как быстро наступит девелопмент хелл из-за технических проблем.
Я бы с радостью разделил твой оптимизм, но то, что он описывает о устройстве игры, больше похоже на разработку методом тыка - тут вопрос времени, как быстро наступит девелопмент хелл из-за технических проблем.
>>838603
Я согласен что это девелопмент хеллтартар, но я тут не для того чтобы показывать как нужно разрабатывать игры.
Кроме разработки методом тыка, ничего другого пока не могу предложить. Если есть какой-то другой способ проверять, зайдут те или иные фичи или нет, то он мне не доступен.
Оптимизм или пессимизм тут ни при чем, это рабочий процесс.
-Оп
Я согласен что это девелопмент хеллтартар, но я тут не для того чтобы показывать как нужно разрабатывать игры.
Кроме разработки методом тыка, ничего другого пока не могу предложить. Если есть какой-то другой способ проверять, зайдут те или иные фичи или нет, то он мне не доступен.
Оптимизм или пессимизм тут ни при чем, это рабочий процесс.
-Оп
>>838609
Я сугубо про технические вопросы. Игра мне, возможно, даже нравится, есть в ней что-то ретро в духе первых графических рогаликов.
Я сугубо про технические вопросы. Игра мне, возможно, даже нравится, есть в ней что-то ретро в духе первых графических рогаликов.
Например вот это >>832910, ну, серьезно, можно же до разработки игры было разобраться с тем как рисовать 2д.
>>838612
Ну в смысле?
Я и разобрался. Когда только начал разработку.
Видимо, только таким замысловатым способом и можно.
И решил рассказать об этом, скинув гифку.
Ну прикинь, смотришь на экран, там все плоское, меняешь вид на 3д и, хоба, оказывается что оно все в форме лестницы. Ну прикольно же)
Или ты имеешь в виду что какой-то другой способ есть это делать? Этот самый простой.
Ну в смысле?
Я и разобрался. Когда только начал разработку.
Видимо, только таким замысловатым способом и можно.
И решил рассказать об этом, скинув гифку.
Ну прикинь, смотришь на экран, там все плоское, меняешь вид на 3д и, хоба, оказывается что оно все в форме лестницы. Ну прикольно же)
Или ты имеешь в виду что какой-то другой способ есть это делать? Этот самый простой.
>>838603
По-твоему, он ещё не наступил?
>>838609
А ты не пробовал заранее спроектировать необходимые тебе системы?
Я пробовал. Не получилось(
>>838617
Такой эффект можно изобразить в любой 2D игре с тайлами, требующими Z-сортировки. Просто обычно игровые движки не имеют функции преобразования 2D+Z -> 3D, но в Unity решили изначально закостылить 2D через 3D, поэтому там такая сомнительная фича имеется.
>как быстро наступит девелопмент хелл из-за технических проблем
По-твоему, он ещё не наступил?
>>838609
>Кроме разработки методом тыка, ничего другого пока не могу предложить
А ты не пробовал заранее спроектировать необходимые тебе системы?
Я пробовал. Не получилось(
>>838617
>оказывается что оно все в форме лестницы
Такой эффект можно изобразить в любой 2D игре с тайлами, требующими Z-сортировки. Просто обычно игровые движки не имеют функции преобразования 2D+Z -> 3D, но в Unity решили изначально закостылить 2D через 3D, поэтому там такая сомнительная фича имеется.
>>838603
Чувак кириллит свою первую игру, более того - рогалик, что автоматом добавляет сложности, учится по курсам, конечно же он будет делать методом тыка. Он же не коммерческий продукт разрабатывает.
Единственно что я бы порекомендовал ОПчику, это поиграть в рогалики побольше, DCSS - божественный UI, CDDA - куча охуенных механик, модабилити, Incursion - прекрасно воплощенная ролевая система d20 SRD, Elona - лоли-жёны, ну и т.д.
Чувак кириллит свою первую игру, более того - рогалик, что автоматом добавляет сложности, учится по курсам, конечно же он будет делать методом тыка. Он же не коммерческий продукт разрабатывает.
Единственно что я бы порекомендовал ОПчику, это поиграть в рогалики побольше, DCSS - божественный UI, CDDA - куча охуенных механик, модабилити, Incursion - прекрасно воплощенная ролевая система d20 SRD, Elona - лоли-жёны, ну и т.д.
36 Кб, 1920x1080>>838600
Сейчас уже и не вспомнить, что мне не понравилось.. Но. Почему при запуске в углу отображается русский язык, а на деле английский? Непорядок. И поменять могу, только если я нажму на английский, а потом на русский.
Арена. Иногда, с некоторым шансом арена представляет из себя белое пространство, без чего-либо >>837734; немного походив, все таки понял, что это этакий devroom. Ладненько.
Долгие загрузки. Такое чувство, будто ты грузишь сцену не асинхронно, а стандартным образом если, конечно, в юнити это реализовано не также, как в годот.
Отсутствие звуков также. Может быть, сказалось то, что это очень ранняя и сырая версия игры. Но, хотя бы, стандартные бесплатные звуки или звуки из 8bit генератора можно накинуть, пожалуйста?
Неинтуитивные кейбинды. Пока я не зашел во вкладку "управление", я не мог понять, как в это играть
Вроде бы все. Хотя, может быть, по мере геймплея могут возникнуть баги.
Сейчас уже и не вспомнить, что мне не понравилось.. Но. Почему при запуске в углу отображается русский язык, а на деле английский? Непорядок. И поменять могу, только если я нажму на английский, а потом на русский.
Арена. Иногда, с некоторым шансом арена представляет из себя белое пространство, без чего-либо >>837734; немного походив, все таки понял, что это этакий devroom. Ладненько.
Долгие загрузки. Такое чувство, будто ты грузишь сцену не асинхронно, а стандартным образом если, конечно, в юнити это реализовано не также, как в годот.
Отсутствие звуков также. Может быть, сказалось то, что это очень ранняя и сырая версия игры. Но, хотя бы, стандартные бесплатные звуки или звуки из 8bit генератора можно накинуть, пожалуйста?
Неинтуитивные кейбинды. Пока я не зашел во вкладку "управление", я не мог понять, как в это играть
Вроде бы все. Хотя, может быть, по мере геймплея могут возникнуть баги.
>>838734
Почему по дефолту ставится английский - вообще ни малейшего понятия не имею. На винде никогда не встречал такого.
Да, арена нужна только для того чтобы тестить всякие вещи. Переименую ее лучше Тестовую Арену.
По поводу белых полов, видел такое, но мне этот баг пока не удавалось реплицировать. Почему-то вместо спекания всех клеток пола в одну текстуру получается этот белый лист...
По поводу длинных загрузок - многие аноны жаловались.
Там видимо вся тема не в том что сама сцена загружается, а в том что долго генерируется карта. А в генераторе присутствуют всякие main-thread-only штуки.
Буду пытаться это оптимизировать.
Звуки действительно важная часть, планировал добавлять их в одном из следующих обновлений.
Спасибо за репорт.
-Оп
Почему по дефолту ставится английский - вообще ни малейшего понятия не имею. На винде никогда не встречал такого.
Да, арена нужна только для того чтобы тестить всякие вещи. Переименую ее лучше Тестовую Арену.
По поводу белых полов, видел такое, но мне этот баг пока не удавалось реплицировать. Почему-то вместо спекания всех клеток пола в одну текстуру получается этот белый лист...
По поводу длинных загрузок - многие аноны жаловались.
Там видимо вся тема не в том что сама сцена загружается, а в том что долго генерируется карта. А в генераторе присутствуют всякие main-thread-only штуки.
Буду пытаться это оптимизировать.
Звуки действительно важная часть, планировал добавлять их в одном из следующих обновлений.
Спасибо за репорт.
-Оп
>>838783
Смею предположить — локаль у меня в линуксе английская. Однако.. Почему бы не сделать скрипт if else, который проверяет локаль?
Если локаль английская — значок в углу английский.
Если нет — значок русский.
>Почему по дефолту ставится английский - вообще ни малейшего понятия не имею.
Смею предположить — локаль у меня в линуксе английская. Однако.. Почему бы не сделать скрипт if else, который проверяет локаль?
Если локаль английская — значок в углу английский.
Если нет — значок русский.
>>838678
Почему это рогалик добавляет сложности? Разве что достойная процедурная генерация уровня - это сложно, остальные компоненты рогалика просты. Даже спрайты можно было заменить ASCII графикой.
Вот что реально добавляет проблем ОПу - неуместное использование ECS Unity. ИМХО.
>>838734
Мне кажется, он пытался забиндить по первой букве английского слова, обозначающего действие: [g]rab, [k]ick, [t]hrow, [m]ap, omb... Это классика, между прочим, в старых играх так чаще всего делали, и во многих современных играх до сих пор прослеживаются следы тех времён: nventory, [c]raft и т.д. Тем более что у него рогалик.
>>838783
Что мешает скинуть генератор целиком в отдельный поток? Он ведь результатом должен выдать массив чисел, обозначающих клетки пола, и массив мобов, предметов и прочих сущностей. Но мне кажется, твоя главная проблема не в генерации карты, а в рендеринге. Поэтому после того, как пропадает надпись "загрузка", ещё какое-то ощутимое время игра тормозит и показывает совершенно неправильную картинку - циклопа вместо человека, грудную клетку без частей тела, какую-то неправильную часть карты без тумана войны и т.п. Т.е. нужно задержать "экран загрузки" на экране до тех пор, пока игра не отобразит всё правильно, и только после этого давать игроку управление.
>>838819 >>838875
Предполагаю, что локаль проверяет и ставит соответствующий язык Unity, а ОП просто не обновляет состояние кнопки в углу. В любом случае, я считаю, язык игры не должен зависеть от локали ОС - игра должна хотя бы один раз на старте предложить выбор языка, на случай, если игрок хочет играть на другом языке. Некоторые могут ставить себе японскую локаль ради запуска старых японских игр, но это не значит, что они хотят вообще все игры на японском языке проходить, верно?
>рогалик, что автоматом добавляет сложности
Почему это рогалик добавляет сложности? Разве что достойная процедурная генерация уровня - это сложно, остальные компоненты рогалика просты. Даже спрайты можно было заменить ASCII графикой.
Вот что реально добавляет проблем ОПу - неуместное использование ECS Unity. ИМХО.
>>838734
>Неинтуитивные кейбинды
Мне кажется, он пытался забиндить по первой букве английского слова, обозначающего действие: [g]rab, [k]ick, [t]hrow, [m]ap, omb... Это классика, между прочим, в старых играх так чаще всего делали, и во многих современных играх до сих пор прослеживаются следы тех времён: nventory, [c]raft и т.д. Тем более что у него рогалик.
>>838783
>долго генерируется карта. А в генераторе присутствуют всякие main-thread-only штуки.
Что мешает скинуть генератор целиком в отдельный поток? Он ведь результатом должен выдать массив чисел, обозначающих клетки пола, и массив мобов, предметов и прочих сущностей. Но мне кажется, твоя главная проблема не в генерации карты, а в рендеринге. Поэтому после того, как пропадает надпись "загрузка", ещё какое-то ощутимое время игра тормозит и показывает совершенно неправильную картинку - циклопа вместо человека, грудную клетку без частей тела, какую-то неправильную часть карты без тумана войны и т.п. Т.е. нужно задержать "экран загрузки" на экране до тех пор, пока игра не отобразит всё правильно, и только после этого давать игроку управление.
>>838819 >>838875
Предполагаю, что локаль проверяет и ставит соответствующий язык Unity, а ОП просто не обновляет состояние кнопки в углу. В любом случае, я считаю, язык игры не должен зависеть от локали ОС - игра должна хотя бы один раз на старте предложить выбор языка, на случай, если игрок хочет играть на другом языке. Некоторые могут ставить себе японскую локаль ради запуска старых японских игр, но это не значит, что они хотят вообще все игры на японском языке проходить, верно?
Сделал начальную озвучку большинства самых распространенных действий. Прикольно, мне понравилось всякие рычаги в миксере крутить. хотя в аудио-дизайне я, увы, ничего не понимаю.
https://vk.com/katabasys?w=wall-201941833_102%2Fall
Обновил закрепленный пост, теперь там и ссылка на линуксовый билд есть.
>>824541
>>824542
Анон-музыкант, отзовись, если ты еще тут! По твоей старой ссылке у меня не получается перейти. Видимо, саундклауд у нас того...
Если бы я мог скачать твои треки где-то еще, я бы их поставил. Они классные, пускай, по крайней мере, в главном меню играют.
https://vk.com/katabasys?w=wall-201941833_102%2Fall
Обновил закрепленный пост, теперь там и ссылка на линуксовый билд есть.
>>824541
>>824542
Анон-музыкант, отзовись, если ты еще тут! По твоей старой ссылке у меня не получается перейти. Видимо, саундклауд у нас того...
Если бы я мог скачать твои треки где-то еще, я бы их поставил. Они классные, пускай, по крайней мере, в главном меню играют.
>>839842
Всё нормально с саундклаудом, доступ есть. Это тот анон свой аккаунт полностью удалил. Проверил через прокси, прокси говорит "404". В крайнем случае это не анон удалил, а анона удалили, но это вряд ли, мало кто захотел терять клиентов из-за политики, а законы США не обязывают ничего удалять - они коснулись только платёжных систем.
Что ж ты раньше не скачал, раз классные?
>По твоей старой ссылке у меня не получается перейти. Видимо, саундклауд у нас того...
Всё нормально с саундклаудом, доступ есть. Это тот анон свой аккаунт полностью удалил. Проверил через прокси, прокси говорит "404". В крайнем случае это не анон удалил, а анона удалили, но это вряд ли, мало кто захотел терять клиентов из-за политики, а законы США не обязывают ничего удалять - они коснулись только платёжных систем.
>Если бы я мог скачать твои треки где-то еще, я бы их поставил. Они классные
Что ж ты раньше не скачал, раз классные?
Я занимался всяческими тестами и сравнением с нормальными играми и пришел к следующему выводу:
1) управление через радиальное меню которое я сделал в одном из последних апдейтов казалось мне чем-то замечательным, на самом деле, использовать его удобно только для некоторых функций, таких, как например, взаимодействие с нпс.
2) Сделать боевку увлекательной можно добавив в игру способности. Этих способностей нужно сделать огромное количество, аки скиллов в доте и сделать так чтобы они отображались примерно таким-же образом (Внизу экрана в виде кнопок с иконками)
3) Использование скиллов не должно быть бесплатным. Пока в игре стоимость всех действий измеряется только во времени которое тратится на их выполнение. Этого недостаточно, нужна какая-то энергия, стамина, или иными словами, мана.
Возможно, мобы тоже должны уметь пользоваться скилами, предется опять перелопатить ИИ.
Пока я запилил базу данных способностей. Теперь каждая способность это структура, где чать функционала захардкожена, а параметры грузятся из эксель таблицы. Еще неделю назад сделал систему чтобы прицельно бить по разным частям тела врага, но она пока мне не особо нравится. Сейчас это один из скилов, на ряду с пинком, и прыжком.
1) управление через радиальное меню которое я сделал в одном из последних апдейтов казалось мне чем-то замечательным, на самом деле, использовать его удобно только для некоторых функций, таких, как например, взаимодействие с нпс.
2) Сделать боевку увлекательной можно добавив в игру способности. Этих способностей нужно сделать огромное количество, аки скиллов в доте и сделать так чтобы они отображались примерно таким-же образом (Внизу экрана в виде кнопок с иконками)
3) Использование скиллов не должно быть бесплатным. Пока в игре стоимость всех действий измеряется только во времени которое тратится на их выполнение. Этого недостаточно, нужна какая-то энергия, стамина, или иными словами, мана.
Возможно, мобы тоже должны уметь пользоваться скилами, предется опять перелопатить ИИ.
Пока я запилил базу данных способностей. Теперь каждая способность это структура, где чать функционала захардкожена, а параметры грузятся из эксель таблицы. Еще неделю назад сделал систему чтобы прицельно бить по разным частям тела врага, но она пока мне не особо нравится. Сейчас это один из скилов, на ряду с пинком, и прыжком.
>>841304
Ну а хули хотели? Разработка игр дело неблагодарное! Поиграли, пора и денюшку платить!
>Использование скиллов не должно быть бесплатным.
Ну а хули хотели? Разработка игр дело неблагодарное! Поиграли, пора и денюшку платить!
Добавил гниение съедобных предметов. Теперь вся еда будет становиться непригодной через 10 000 тиков. А все потому что нефиг набирать себе полный инвентарь всяких грибов и мертвых котов в надежде потом в критический момент все это сожрать. Игрок должен продвигаться вперед а не гриндить каждый этаж по 10 минут.
Еще будет добавлена еда которая не портится, но она будет встречаться реже.
Еще будет добавлена еда которая не портится, но она будет встречаться реже.
>>841304
Сделай открытие на КЛИК, а не на удержание. Реально, вся проблема твоего меню в УДЕРЖАНИИ, которое очень сильно замедляет использование. Либо ориентируйся на радиальные меню в Blender: меню появляется сразу после нажатия и открыто пока клавишу удерживают, а чтобы выбрать пункт - нужно сместить мышь в направлении пункта меню и отпустить клавишу меню. Это очень удобно и достаточно легко сделать в игре.
Не нужно. Посмотри на Shattered Pixel Dungeon, там у каждого класса всего 1-2 способности плюс по одной способности на артефакт, остальное - свитки, зелья, камни да зачарования, и всё равно боёвка очень интересная, прохожу не первый раз.
Ты сначала рассчитай баланс игры в таблицах, потом будешь делать выводы, что нужно и что нет.
>>841673
Вот с самого начала твоего треда этот момент меня задевает и раздражает. Почему у тебя такая ненависть к кошкам? Я бы ещё понял, если бы ты убивал в игре собак - собаки реально дают много поводов для ненависти. А кошки совершенно безвредны и даже полезны для человека, тихие и милые, не нападают пока сыты и по-настоящему дружат с человеком (в смысле не считают себя рабами человека и не подчиняются ему, а признают человека равным им членом их семьи и заботятся о нём в силу своих сил и понимания). Было бы лучше сделать кошек в игре удобным питомцем как в Minecraft, а не потенциальным врагом.
Но дело твоё, конечно, некоторые и совершенно безобидных маленьких и даже миленьких паучков боятся и убивают из-за своих страхов...
>управление через радиальное меню
Сделай открытие на КЛИК, а не на удержание. Реально, вся проблема твоего меню в УДЕРЖАНИИ, которое очень сильно замедляет использование. Либо ориентируйся на радиальные меню в Blender: меню появляется сразу после нажатия и открыто пока клавишу удерживают, а чтобы выбрать пункт - нужно сместить мышь в направлении пункта меню и отпустить клавишу меню. Это очень удобно и достаточно легко сделать в игре.
>Этих способностей нужно сделать огромное количество
Не нужно. Посмотри на Shattered Pixel Dungeon, там у каждого класса всего 1-2 способности плюс по одной способности на артефакт, остальное - свитки, зелья, камни да зачарования, и всё равно боёвка очень интересная, прохожу не первый раз.
>Этого недостаточно, нужна какая-то энергия, стамина, или иными словами, мана.
Ты сначала рассчитай баланс игры в таблицах, потом будешь делать выводы, что нужно и что нет.
>>841673
>мертвых котов
Вот с самого начала твоего треда этот момент меня задевает и раздражает. Почему у тебя такая ненависть к кошкам? Я бы ещё понял, если бы ты убивал в игре собак - собаки реально дают много поводов для ненависти. А кошки совершенно безвредны и даже полезны для человека, тихие и милые, не нападают пока сыты и по-настоящему дружат с человеком (в смысле не считают себя рабами человека и не подчиняются ему, а признают человека равным им членом их семьи и заботятся о нём в силу своих сил и понимания). Было бы лучше сделать кошек в игре удобным питомцем как в Minecraft, а не потенциальным врагом.
Но дело твоё, конечно, некоторые и совершенно безобидных маленьких и даже миленьких паучков боятся и убивают из-за своих страхов...
132 Кб, 640x640>>841680
Да, пожалуй. Мб стоит его на среднюю кнопку мыши поставить.
Что это за таблицы такие, которые позволят мне определить нужна ли в игре какая-то конкретная механика?
На счет котов.. Блин, я абсолютно не понимаю как это можно воспринимать в таком ключе. Лично для меня все эти вещи выглядят как какое-то изначально постановочное, гротескное насилие. Ты раскраиваешь кота кувалдой, смотришь на то, что от него осталось и такой "ааа какая же нелепая херня, как же это плохо" и начинаешь угарать. У меня, по крайней мере, такая реакция.
Вот был мультик Happy tree friends. Офигенная же вещь. Я бы вообще сделал игру ровно с таким уровнем насилия, но, увы, 32 битные текстуры это вряд-ли позволят.
Ирл я никакой неприязни к животным и в частности к котам не испытываю. Паучки вообще офигенные ребята.
Ну и в конце концов, кот гибнет в бою. Это достойная смерть.
Этот кот по силе эквивалентен большой собаке ИРЛ. С моей точки зрения, выйти 1 на 1 против подобного животного, запиздить его и съесть это намного более моральный поступок чем выращивать и есть тех-же коров.
Да, пожалуй. Мб стоит его на среднюю кнопку мыши поставить.
Что это за таблицы такие, которые позволят мне определить нужна ли в игре какая-то конкретная механика?
На счет котов.. Блин, я абсолютно не понимаю как это можно воспринимать в таком ключе. Лично для меня все эти вещи выглядят как какое-то изначально постановочное, гротескное насилие. Ты раскраиваешь кота кувалдой, смотришь на то, что от него осталось и такой "ааа какая же нелепая херня, как же это плохо" и начинаешь угарать. У меня, по крайней мере, такая реакция.
Вот был мультик Happy tree friends. Офигенная же вещь. Я бы вообще сделал игру ровно с таким уровнем насилия, но, увы, 32 битные текстуры это вряд-ли позволят.
Ирл я никакой неприязни к животным и в частности к котам не испытываю. Паучки вообще офигенные ребята.
Ну и в конце концов, кот гибнет в бою. Это достойная смерть.
Этот кот по силе эквивалентен большой собаке ИРЛ. С моей точки зрения, выйти 1 на 1 против подобного животного, запиздить его и съесть это намного более моральный поступок чем выращивать и есть тех-же коров.
Делаю симулятор города и нахожу некоторые механики схожими с теми, которые реализуешь ты в своем рогалике. Поэтому надеюсь, что ты развернуто ответишь и дашь ответы-советы на вопросы ниже, с помощью которых я доработаю свои идеи.
Как именно у тебя работают тики? Я вначале просто работал с юнитевским тайм.дельта таймом, но по итогу оно слишком неточное, и при если я реализую ускорение времени, то это выглядит вообще очень странно. Видел ролик Код Манки на эту тему, про то что он тайм оборачивает в тики и ставит ограничение не более одного тика на 0.2 секунды и уже с этими тиками работает. Но при этом возникают проблемы, что при подписке на такие тики объект может подписаться прям вначале тика или в конце и тик мгновенно пройдет. Второй момент тики все равно синхронизируются с обновлением кадра. Короче все равно довольно неточно выходит. Как ты это реализовал, особенно в реалиях юнити дотс, который я тоже думаю частично внедрить в проект.
Второй вопрос, каким инструментом ты пользуешься для реализации навимеша? Я вот использую дефолтный юнити navmesh пакет, только совмещая его с кастомным 2d измерением. Но он какой-то очень странный, на ровной плоскости путь иногда может не просчитаться. Боюсь представить если я буду это еще в многопоточность совать. Нужны какие-то советы и наставления как это лучше сделать.
Как именно у тебя работают тики? Я вначале просто работал с юнитевским тайм.дельта таймом, но по итогу оно слишком неточное, и при если я реализую ускорение времени, то это выглядит вообще очень странно. Видел ролик Код Манки на эту тему, про то что он тайм оборачивает в тики и ставит ограничение не более одного тика на 0.2 секунды и уже с этими тиками работает. Но при этом возникают проблемы, что при подписке на такие тики объект может подписаться прям вначале тика или в конце и тик мгновенно пройдет. Второй момент тики все равно синхронизируются с обновлением кадра. Короче все равно довольно неточно выходит. Как ты это реализовал, особенно в реалиях юнити дотс, который я тоже думаю частично внедрить в проект.
Второй вопрос, каким инструментом ты пользуешься для реализации навимеша? Я вот использую дефолтный юнити navmesh пакет, только совмещая его с кастомным 2d измерением. Но он какой-то очень странный, на ровной плоскости путь иногда может не просчитаться. Боюсь представить если я буду это еще в многопоточность совать. Нужны какие-то советы и наставления как это лучше сделать.
>>841694
Энергия/мана/стамина - это не просто механика, это ограничитель каких-то действий с целью направления игрока в нужное русло. Игроку совершенно не в радость бегать и собирать какие-нибудь бутылки с водой только потому, что его персонаж умирает от жажды. Но если без этих бутылок ему нет мотивации лазить по всей карте и он может просто проследовать от одной лестницы до другой, то введение бутылок потребует от игрока тщательнее исследовать карту. В то же время игрок не может целый час лупить стену, прокачивая силу, потому что тогда он умрёт от жажды. Если ты рассчитал геймплей по формулам и видишь, что ограничивать тебе нечего - игрок и без того пойдёт куда следует и не сможет прокачаться выше положенного, зачем тогда вводить лишнюю механику?
А я не понимаю, как можно не ассоциировать картинки на экране с реальными объектами и категориями. Если на экране нарисован кот, то ты должен испытывать к нему приблизительно те же эмоции, что и к реальному коту, разве не так? Иначе зачем вообще рисовать именно кота, если ты относишься к рисунку кота точно так же, как к рисунку квадрата или треугольника? В чём смысл изображать реальный объект, если ты не относишься к нему так же, как к реальному объекту?
Я отношусь к играм как к продолжению реальности или как к модели реальности. Даже если объект на экране - всего лишь картинка с очень примитивной логикой поведения и без каких-либо чувств кроме минимальных триггеров нескольких возможных событий, заслужила ли эта "картинка" жестокого (с точки зрения человека) обращения с ней? Она всего лишь актёр, и не заслуживает негативных эмоций по отношению к ней. Если ты не испытываешь буквальной ненависти к тому объекту, которого этот по своей сути невинный виртуальный актёр изображает, то какой вообще смысл над ним издеваться, убивать или делать прочие жестокие вещи? Зачем?
В смысле, зачем игроку играть в такое, зачем разработчику игр разрабатывать такое? Мне кажется очевидным, что игра про убийство котов нужна ненавистникам котов в реальной жизни, тогда как любой другой игрок может выбрать любую другую игру - без котов или без убийств. Это как гонки создаются любителям автомобилей в реальной жизни, а шутеры - любителям реального оружия. В противном случае все эти игры просто теряют смысл. Какой ты видишь свою ЦА?
Так если это плохо - зачем тогда это делать?
Как можно смеяться/веселиться с изображения убийства того, кому ты смерти вовсе не желаешь? Должен ли я смеяться, если увижу фотографию твоего обезображенного убийцами трупа, при том что личной вражды с тобой не имею и смерти тебе не желаю? Ведь это просто картинка, такая же, как спрайт мёртвого кота или другого моба в любой игре, к тому же сегодня такое фото легко подделать.
Совершенно отвратительная вещь, меня в детстве это травмировало. Да меня и более детские мультики напрягали: Тома в "Том и Джерри" жалко было, Волка в "Ну, погоди" и так далее. Кто вообще придумал, что изображать насилие - это весело и должно нравиться детям? Даже если никаких физических травм не остаётся, психические травмы могут быть куда хуже физических.
Рад это слышать.
Коров мы выращиваем на мясо, потому что пока что не нашли/не создали другого столь же удобного и дешёвого источника конкретного вида мяса, которое нам нужно для выживания (веганы истощаются и болеют, к сожалению). Когда создадим (или иным способом преодолеем биологические ограничения своих тел) - быстро забросим разведение скота, которым продолжат заниматься только страны третьего мира. В мире игры же ты, как разработчик - самый настоящий бог мира, можешь придумать и создать что угодно - всё в твоих силах и возможностях. Но вместо этого ты делаешь расчленёнку котов и вполне осознанно мотивируешь игрока их убивать, чтобы восстановить здоровье в тяжёлой ситуации, т.к. тех же грибов мало и они мало восстанавливают. Тут напрашивается единственный вывод, что тебе лично чем-то реальные коты не угодили (потому что крысы, скелеты и т.п. - это всё клише и почти в каждой игре являются врагами, многие добавят их не раздумывая чисто по шаблону "фэнтези игра").
Я ничего не предлагаю, только изложил свои мысли по этому поводу.
>определить нужна ли в игре какая-то конкретная механика
Энергия/мана/стамина - это не просто механика, это ограничитель каких-то действий с целью направления игрока в нужное русло. Игроку совершенно не в радость бегать и собирать какие-нибудь бутылки с водой только потому, что его персонаж умирает от жажды. Но если без этих бутылок ему нет мотивации лазить по всей карте и он может просто проследовать от одной лестницы до другой, то введение бутылок потребует от игрока тщательнее исследовать карту. В то же время игрок не может целый час лупить стену, прокачивая силу, потому что тогда он умрёт от жажды. Если ты рассчитал геймплей по формулам и видишь, что ограничивать тебе нечего - игрок и без того пойдёт куда следует и не сможет прокачаться выше положенного, зачем тогда вводить лишнюю механику?
>не понимаю как это можно воспринимать в таком ключе
А я не понимаю, как можно не ассоциировать картинки на экране с реальными объектами и категориями. Если на экране нарисован кот, то ты должен испытывать к нему приблизительно те же эмоции, что и к реальному коту, разве не так? Иначе зачем вообще рисовать именно кота, если ты относишься к рисунку кота точно так же, как к рисунку квадрата или треугольника? В чём смысл изображать реальный объект, если ты не относишься к нему так же, как к реальному объекту?
>изначально постановочное, гротескное насилие
Я отношусь к играм как к продолжению реальности или как к модели реальности. Даже если объект на экране - всего лишь картинка с очень примитивной логикой поведения и без каких-либо чувств кроме минимальных триггеров нескольких возможных событий, заслужила ли эта "картинка" жестокого (с точки зрения человека) обращения с ней? Она всего лишь актёр, и не заслуживает негативных эмоций по отношению к ней. Если ты не испытываешь буквальной ненависти к тому объекту, которого этот по своей сути невинный виртуальный актёр изображает, то какой вообще смысл над ним издеваться, убивать или делать прочие жестокие вещи? Зачем?
В смысле, зачем игроку играть в такое, зачем разработчику игр разрабатывать такое? Мне кажется очевидным, что игра про убийство котов нужна ненавистникам котов в реальной жизни, тогда как любой другой игрок может выбрать любую другую игру - без котов или без убийств. Это как гонки создаются любителям автомобилей в реальной жизни, а шутеры - любителям реального оружия. В противном случае все эти игры просто теряют смысл. Какой ты видишь свою ЦА?
>как же это плохо
Так если это плохо - зачем тогда это делать?
>и начинаешь угарать
Как можно смеяться/веселиться с изображения убийства того, кому ты смерти вовсе не желаешь? Должен ли я смеяться, если увижу фотографию твоего обезображенного убийцами трупа, при том что личной вражды с тобой не имею и смерти тебе не желаю? Ведь это просто картинка, такая же, как спрайт мёртвого кота или другого моба в любой игре, к тому же сегодня такое фото легко подделать.
>Happy tree friends. Офигенная же вещь.
Совершенно отвратительная вещь, меня в детстве это травмировало. Да меня и более детские мультики напрягали: Тома в "Том и Джерри" жалко было, Волка в "Ну, погоди" и так далее. Кто вообще придумал, что изображать насилие - это весело и должно нравиться детям? Даже если никаких физических травм не остаётся, психические травмы могут быть куда хуже физических.
>Ирл я никакой неприязни к животным и в частности к котам не испытываю. Паучки вообще офигенные ребята.
Рад это слышать.
>намного более моральный поступок чем выращивать и есть тех-же коров
Коров мы выращиваем на мясо, потому что пока что не нашли/не создали другого столь же удобного и дешёвого источника конкретного вида мяса, которое нам нужно для выживания (веганы истощаются и болеют, к сожалению). Когда создадим (или иным способом преодолеем биологические ограничения своих тел) - быстро забросим разведение скота, которым продолжат заниматься только страны третьего мира. В мире игры же ты, как разработчик - самый настоящий бог мира, можешь придумать и создать что угодно - всё в твоих силах и возможностях. Но вместо этого ты делаешь расчленёнку котов и вполне осознанно мотивируешь игрока их убивать, чтобы восстановить здоровье в тяжёлой ситуации, т.к. тех же грибов мало и они мало восстанавливают. Тут напрашивается единственный вывод, что тебе лично чем-то реальные коты не угодили (потому что крысы, скелеты и т.п. - это всё клише и почти в каждой игре являются врагами, многие добавят их не раздумывая чисто по шаблону "фэнтези игра").
Я ничего не предлагаю, только изложил свои мысли по этому поводу.
>>841694
Энергия/мана/стамина - это не просто механика, это ограничитель каких-то действий с целью направления игрока в нужное русло. Игроку совершенно не в радость бегать и собирать какие-нибудь бутылки с водой только потому, что его персонаж умирает от жажды. Но если без этих бутылок ему нет мотивации лазить по всей карте и он может просто проследовать от одной лестницы до другой, то введение бутылок потребует от игрока тщательнее исследовать карту. В то же время игрок не может целый час лупить стену, прокачивая силу, потому что тогда он умрёт от жажды. Если ты рассчитал геймплей по формулам и видишь, что ограничивать тебе нечего - игрок и без того пойдёт куда следует и не сможет прокачаться выше положенного, зачем тогда вводить лишнюю механику?
А я не понимаю, как можно не ассоциировать картинки на экране с реальными объектами и категориями. Если на экране нарисован кот, то ты должен испытывать к нему приблизительно те же эмоции, что и к реальному коту, разве не так? Иначе зачем вообще рисовать именно кота, если ты относишься к рисунку кота точно так же, как к рисунку квадрата или треугольника? В чём смысл изображать реальный объект, если ты не относишься к нему так же, как к реальному объекту?
Я отношусь к играм как к продолжению реальности или как к модели реальности. Даже если объект на экране - всего лишь картинка с очень примитивной логикой поведения и без каких-либо чувств кроме минимальных триггеров нескольких возможных событий, заслужила ли эта "картинка" жестокого (с точки зрения человека) обращения с ней? Она всего лишь актёр, и не заслуживает негативных эмоций по отношению к ней. Если ты не испытываешь буквальной ненависти к тому объекту, которого этот по своей сути невинный виртуальный актёр изображает, то какой вообще смысл над ним издеваться, убивать или делать прочие жестокие вещи? Зачем?
В смысле, зачем игроку играть в такое, зачем разработчику игр разрабатывать такое? Мне кажется очевидным, что игра про убийство котов нужна ненавистникам котов в реальной жизни, тогда как любой другой игрок может выбрать любую другую игру - без котов или без убийств. Это как гонки создаются любителям автомобилей в реальной жизни, а шутеры - любителям реального оружия. В противном случае все эти игры просто теряют смысл. Какой ты видишь свою ЦА?
Так если это плохо - зачем тогда это делать?
Как можно смеяться/веселиться с изображения убийства того, кому ты смерти вовсе не желаешь? Должен ли я смеяться, если увижу фотографию твоего обезображенного убийцами трупа, при том что личной вражды с тобой не имею и смерти тебе не желаю? Ведь это просто картинка, такая же, как спрайт мёртвого кота или другого моба в любой игре, к тому же сегодня такое фото легко подделать.
Совершенно отвратительная вещь, меня в детстве это травмировало. Да меня и более детские мультики напрягали: Тома в "Том и Джерри" жалко было, Волка в "Ну, погоди" и так далее. Кто вообще придумал, что изображать насилие - это весело и должно нравиться детям? Даже если никаких физических травм не остаётся, психические травмы могут быть куда хуже физических.
Рад это слышать.
Коров мы выращиваем на мясо, потому что пока что не нашли/не создали другого столь же удобного и дешёвого источника конкретного вида мяса, которое нам нужно для выживания (веганы истощаются и болеют, к сожалению). Когда создадим (или иным способом преодолеем биологические ограничения своих тел) - быстро забросим разведение скота, которым продолжат заниматься только страны третьего мира. В мире игры же ты, как разработчик - самый настоящий бог мира, можешь придумать и создать что угодно - всё в твоих силах и возможностях. Но вместо этого ты делаешь расчленёнку котов и вполне осознанно мотивируешь игрока их убивать, чтобы восстановить здоровье в тяжёлой ситуации, т.к. тех же грибов мало и они мало восстанавливают. Тут напрашивается единственный вывод, что тебе лично чем-то реальные коты не угодили (потому что крысы, скелеты и т.п. - это всё клише и почти в каждой игре являются врагами, многие добавят их не раздумывая чисто по шаблону "фэнтези игра").
Я ничего не предлагаю, только изложил свои мысли по этому поводу.
>определить нужна ли в игре какая-то конкретная механика
Энергия/мана/стамина - это не просто механика, это ограничитель каких-то действий с целью направления игрока в нужное русло. Игроку совершенно не в радость бегать и собирать какие-нибудь бутылки с водой только потому, что его персонаж умирает от жажды. Но если без этих бутылок ему нет мотивации лазить по всей карте и он может просто проследовать от одной лестницы до другой, то введение бутылок потребует от игрока тщательнее исследовать карту. В то же время игрок не может целый час лупить стену, прокачивая силу, потому что тогда он умрёт от жажды. Если ты рассчитал геймплей по формулам и видишь, что ограничивать тебе нечего - игрок и без того пойдёт куда следует и не сможет прокачаться выше положенного, зачем тогда вводить лишнюю механику?
>не понимаю как это можно воспринимать в таком ключе
А я не понимаю, как можно не ассоциировать картинки на экране с реальными объектами и категориями. Если на экране нарисован кот, то ты должен испытывать к нему приблизительно те же эмоции, что и к реальному коту, разве не так? Иначе зачем вообще рисовать именно кота, если ты относишься к рисунку кота точно так же, как к рисунку квадрата или треугольника? В чём смысл изображать реальный объект, если ты не относишься к нему так же, как к реальному объекту?
>изначально постановочное, гротескное насилие
Я отношусь к играм как к продолжению реальности или как к модели реальности. Даже если объект на экране - всего лишь картинка с очень примитивной логикой поведения и без каких-либо чувств кроме минимальных триггеров нескольких возможных событий, заслужила ли эта "картинка" жестокого (с точки зрения человека) обращения с ней? Она всего лишь актёр, и не заслуживает негативных эмоций по отношению к ней. Если ты не испытываешь буквальной ненависти к тому объекту, которого этот по своей сути невинный виртуальный актёр изображает, то какой вообще смысл над ним издеваться, убивать или делать прочие жестокие вещи? Зачем?
В смысле, зачем игроку играть в такое, зачем разработчику игр разрабатывать такое? Мне кажется очевидным, что игра про убийство котов нужна ненавистникам котов в реальной жизни, тогда как любой другой игрок может выбрать любую другую игру - без котов или без убийств. Это как гонки создаются любителям автомобилей в реальной жизни, а шутеры - любителям реального оружия. В противном случае все эти игры просто теряют смысл. Какой ты видишь свою ЦА?
>как же это плохо
Так если это плохо - зачем тогда это делать?
>и начинаешь угарать
Как можно смеяться/веселиться с изображения убийства того, кому ты смерти вовсе не желаешь? Должен ли я смеяться, если увижу фотографию твоего обезображенного убийцами трупа, при том что личной вражды с тобой не имею и смерти тебе не желаю? Ведь это просто картинка, такая же, как спрайт мёртвого кота или другого моба в любой игре, к тому же сегодня такое фото легко подделать.
>Happy tree friends. Офигенная же вещь.
Совершенно отвратительная вещь, меня в детстве это травмировало. Да меня и более детские мультики напрягали: Тома в "Том и Джерри" жалко было, Волка в "Ну, погоди" и так далее. Кто вообще придумал, что изображать насилие - это весело и должно нравиться детям? Даже если никаких физических травм не остаётся, психические травмы могут быть куда хуже физических.
>Ирл я никакой неприязни к животным и в частности к котам не испытываю. Паучки вообще офигенные ребята.
Рад это слышать.
>намного более моральный поступок чем выращивать и есть тех-же коров
Коров мы выращиваем на мясо, потому что пока что не нашли/не создали другого столь же удобного и дешёвого источника конкретного вида мяса, которое нам нужно для выживания (веганы истощаются и болеют, к сожалению). Когда создадим (или иным способом преодолеем биологические ограничения своих тел) - быстро забросим разведение скота, которым продолжат заниматься только страны третьего мира. В мире игры же ты, как разработчик - самый настоящий бог мира, можешь придумать и создать что угодно - всё в твоих силах и возможностях. Но вместо этого ты делаешь расчленёнку котов и вполне осознанно мотивируешь игрока их убивать, чтобы восстановить здоровье в тяжёлой ситуации, т.к. тех же грибов мало и они мало восстанавливают. Тут напрашивается единственный вывод, что тебе лично чем-то реальные коты не угодили (потому что крысы, скелеты и т.п. - это всё клише и почти в каждой игре являются врагами, многие добавят их не раздумывая чисто по шаблону "фэнтези игра").
Я ничего не предлагаю, только изложил свои мысли по этому поводу.
>>841829
Тоже хотелось сделать симулятор города, но не пошаговый, а в реальном времени.
Я не знаю, как реализовано у ОПа, но разве пошаговая игра должна связывать себя с временем кадра? Тики в пошаговых играх - это просто абстрактные шаги развития событий (итерации цикла) и никак с реальным временем (отрисовкой кадров) не связаны. Ты можешь симулировать много тиков за один кадр (цикл for) или растянуть тики на множество кадров (пропускать кадры, симулируя один тик каждые 2+ кадра) в целях оптимизации - выбор за тобой. На практике тебе нужно замерить, какую нагрузку даёт один твой тик игры и соответственно их группировать или распределять. И, конечно, поскольку игра пошаговая, тики не симулируются, пока игрок не сделает какое-то действие своим персонажем, то есть весь мир буквально останавливается, пока игрок думает.
Если же у тебя игра в реальном времени, то зачем тебе вообще концепция тика из игры ОПа? Работай в реальном времени, опираясь на обновления (тики) физического движка (в Unity это FixedUpdate()), а не на отрисовку кадров.
>Делаю симулятор города
Тоже хотелось сделать симулятор города, но не пошаговый, а в реальном времени.
>Как работают тики
>тайм.дельта
Я не знаю, как реализовано у ОПа, но разве пошаговая игра должна связывать себя с временем кадра? Тики в пошаговых играх - это просто абстрактные шаги развития событий (итерации цикла) и никак с реальным временем (отрисовкой кадров) не связаны. Ты можешь симулировать много тиков за один кадр (цикл for) или растянуть тики на множество кадров (пропускать кадры, симулируя один тик каждые 2+ кадра) в целях оптимизации - выбор за тобой. На практике тебе нужно замерить, какую нагрузку даёт один твой тик игры и соответственно их группировать или распределять. И, конечно, поскольку игра пошаговая, тики не симулируются, пока игрок не сделает какое-то действие своим персонажем, то есть весь мир буквально останавливается, пока игрок думает.
Если же у тебя игра в реальном времени, то зачем тебе вообще концепция тика из игры ОПа? Работай в реальном времени, опираясь на обновления (тики) физического движка (в Unity это FixedUpdate()), а не на отрисовку кадров.
>>841887
Вообще ты мне дал неплохую идею насчет FixedUpdate я не задумывался об этом. Но у меня игра да в реальном времени и в идеале должна иметь возможность ускорения до х3 без особой потери в производительности.
Вообще ты мне дал неплохую идею насчет FixedUpdate я не задумывался об этом. Но у меня игра да в реальном времени и в идеале должна иметь возможность ускорения до х3 без особой потери в производительности.
>>841887
У меня тики в отденьном потоке считаются, вместе со всей логикой. В рендер цикле просто считываются значения из объектов. Тут главное или держать ровно один фоновый поток на все или разделять объекты по типам, но следить, чтобы разные потоки никогда один оъект не одновляли, иначе по пизде пойдет все.
У меня тики в отденьном потоке считаются, вместе со всей логикой. В рендер цикле просто считываются значения из объектов. Тут главное или держать ровно один фоновый поток на все или разделять объекты по типам, но следить, чтобы разные потоки никогда один оъект не одновляли, иначе по пизде пойдет все.
452 Кб, 1204x677>>841829
>>841829
На счет тиков, как писал анон выше, я тебе действительно не особо смогу помочь. Скажу только что так как я использую ЕЦС у меня тик это просто последовательное обновление всех систем, которые в свою очередь уже работают с компонентами, которые им нужны. Вообще, как многие замечают, в моем проекте ЕЦС не реализуется в полной мере, наверно можно было бы и без него, но мой мозг уже перестроился под дата-ориентированную модель, так что на данный момент мне с ним наверно проще чем без него.
Вот во всяких симуляторах городов где куча юнитов ецс и дотс должны себя очень хорошо показать, так что советую.
На счет пасфайндера - напиши лучше свой. Тогда не возникнет ситуации когда тебе будет нужен какой-то функционал, которого разрабы этого юнити пакета не предусмотрели. Navmesh, очень хорош для всяких прыжков по платформам в 3д, там где ты свой такой алгоритм замучаешься писать. Но в то-же время меш, блин, нельзя нормально повернуть набок чтобы Y ось была "верхом". Приходится какой-то костыль мутить. Сгорел с этого однажды.
Это на самом деле не так сложно, есть куча готовых алгоритмов А* пасфайндера. Могу тебе даже свою реализацию скинуть. Но для этого нужно поделить пространство на клетки.
Симуляторы городов - крутая тема, хотя Songs of Syx сложно будет переплюнуть
-ОП
>>841829
На счет тиков, как писал анон выше, я тебе действительно не особо смогу помочь. Скажу только что так как я использую ЕЦС у меня тик это просто последовательное обновление всех систем, которые в свою очередь уже работают с компонентами, которые им нужны. Вообще, как многие замечают, в моем проекте ЕЦС не реализуется в полной мере, наверно можно было бы и без него, но мой мозг уже перестроился под дата-ориентированную модель, так что на данный момент мне с ним наверно проще чем без него.
Вот во всяких симуляторах городов где куча юнитов ецс и дотс должны себя очень хорошо показать, так что советую.
На счет пасфайндера - напиши лучше свой. Тогда не возникнет ситуации когда тебе будет нужен какой-то функционал, которого разрабы этого юнити пакета не предусмотрели. Navmesh, очень хорош для всяких прыжков по платформам в 3д, там где ты свой такой алгоритм замучаешься писать. Но в то-же время меш, блин, нельзя нормально повернуть набок чтобы Y ось была "верхом". Приходится какой-то костыль мутить. Сгорел с этого однажды.
Это на самом деле не так сложно, есть куча готовых алгоритмов А* пасфайндера. Могу тебе даже свою реализацию скинуть. Но для этого нужно поделить пространство на клетки.
Симуляторы городов - крутая тема, хотя Songs of Syx сложно будет переплюнуть
-ОП
30 Кб, 822x503>>841884
Похоже, мы просто очень разные люди.
На самом деле, наверно я действительно обладаю несколько специфическими вкусами и чувством юмора, что довольно часто замечаю в общении.
Я не знаю как на самом деле работает этот механизм притягательности жестокости, но вот некоторые предположения.
Во-первых чувство, которое я испытываю от вида какой-то жестокости в искусстве родственно с катарсисом, чувством сопровождающим восприятие трагедии. Трагедии тоже "понарошку" изображают не самые приятные ИРЛ вещи.
Механизм примерно такой:
Было бы мне приятно убить кота молотком ИРЛ?
Скорее всего нет, особенно с точки зрения того, что у него есть хозяин который расстроится.
В игре персонаж обязан убивать котов.
Я проецирую свое восприятие на персонажа игры.
Если бы я был на его месте я бы кайнд-оф страдал.
Таким образом я на самом деле сопереживаю страданиям персонажа и испытываю катарсис.
Это первая часть механизма, а дальше добавляется еще то, как конкретно это происходит. Кота нахуй рапидорашивает, у него отрывается бошка, а все в радиусе 3 метров заливает кровью. Это, мягко говоря, не очень реалистичная смерть для такого животного. Абсурдность и нереалистичность того как это произошло вместе с серьезностью того что произошло и создает комический эффект.
А вот если бы я убивал в игре каких-то действительно неприятных персонажей, злых собак, плохих людей и прочего всей этой цепочки не было бы, на все это насилие было бы просто по-е-бать. Ну а че, просто неприятные существа, просто получают то что и должны получать. На что тут смотреть, сразу же и так понятно что с ними будет.
Похоже, мы просто очень разные люди.
На самом деле, наверно я действительно обладаю несколько специфическими вкусами и чувством юмора, что довольно часто замечаю в общении.
Я не знаю как на самом деле работает этот механизм притягательности жестокости, но вот некоторые предположения.
Во-первых чувство, которое я испытываю от вида какой-то жестокости в искусстве родственно с катарсисом, чувством сопровождающим восприятие трагедии. Трагедии тоже "понарошку" изображают не самые приятные ИРЛ вещи.
Механизм примерно такой:
Было бы мне приятно убить кота молотком ИРЛ?
Скорее всего нет, особенно с точки зрения того, что у него есть хозяин который расстроится.
В игре персонаж обязан убивать котов.
Я проецирую свое восприятие на персонажа игры.
Если бы я был на его месте я бы кайнд-оф страдал.
Таким образом я на самом деле сопереживаю страданиям персонажа и испытываю катарсис.
Это первая часть механизма, а дальше добавляется еще то, как конкретно это происходит. Кота нахуй рапидорашивает, у него отрывается бошка, а все в радиусе 3 метров заливает кровью. Это, мягко говоря, не очень реалистичная смерть для такого животного. Абсурдность и нереалистичность того как это произошло вместе с серьезностью того что произошло и создает комический эффект.
А вот если бы я убивал в игре каких-то действительно неприятных персонажей, злых собак, плохих людей и прочего всей этой цепочки не было бы, на все это насилие было бы просто по-е-бать. Ну а че, просто неприятные существа, просто получают то что и должны получать. На что тут смотреть, сразу же и так понятно что с ними будет.
26 Кб, 500x562>>842122 >>842123
Кто-кто, а шизы здесь вы, а не я.
Хрен знает, у меня даже отрицательные персонажи вызывают сочувствие. Я могу испытывать ненависть к сценаристу, который заставляет персонажа быть плохим и не оставляет герою бескровного выхода из ситуации, а также ненависть к тем, кто считает "геройским" кровавую расправу над кем-либо или чем-либо. В реальности даже у самого последнего маньяка есть какая-то причина его жестокости (чаще всего это насилие со стороны других людей, когда он сам был ребёнком), а у людей, пытающихся с ним совладать, есть или могут быть (в технологически развитом будущем) бескровные методы, превращающие маньяка в нормального законопослушного гражданина или даже ценного союзника. В произведениях искусства же злодеи злые просто потому что они злодеи, и у героев нет ничего кроме инструментов для убийств. Это выглядит крайне негуманно и избыточно жестоко, как будто автору произведения просто нравится жестокость и ему нужны куклы, на которых можно эту жестокость проявить. Куда интереснее читать/смотреть/играть в то, где условная "магия дружбы" решает проблемы в пользу всех, а не только одной заинтересованной в чём-то стороны. Реальность и без человека крайне жестока, так почему мы создаём в основном истории о жестокости, имея возможность создавать что угодно другое? Почитай СМИ, если так нетерпится окунуться в жестокость.
>Ебать ты шиз
Кто-кто, а шизы здесь вы, а не я.
>просто неприятные существа, просто получают то что и должны получать
Хрен знает, у меня даже отрицательные персонажи вызывают сочувствие. Я могу испытывать ненависть к сценаристу, который заставляет персонажа быть плохим и не оставляет герою бескровного выхода из ситуации, а также ненависть к тем, кто считает "геройским" кровавую расправу над кем-либо или чем-либо. В реальности даже у самого последнего маньяка есть какая-то причина его жестокости (чаще всего это насилие со стороны других людей, когда он сам был ребёнком), а у людей, пытающихся с ним совладать, есть или могут быть (в технологически развитом будущем) бескровные методы, превращающие маньяка в нормального законопослушного гражданина или даже ценного союзника. В произведениях искусства же злодеи злые просто потому что они злодеи, и у героев нет ничего кроме инструментов для убийств. Это выглядит крайне негуманно и избыточно жестоко, как будто автору произведения просто нравится жестокость и ему нужны куклы, на которых можно эту жестокость проявить. Куда интереснее читать/смотреть/играть в то, где условная "магия дружбы" решает проблемы в пользу всех, а не только одной заинтересованной в чём-то стороны. Реальность и без человека крайне жестока, так почему мы создаём в основном истории о жестокости, имея возможность создавать что угодно другое? Почитай СМИ, если так нетерпится окунуться в жестокость.
439 Кб, 570x746>>842188
При этом ты надрачиваешь на аниме, где нет тайтла, где хотя бы раз ГГ не побила по голове тянка за то что сказал или посмотрел не так. Не говоря уж о всяких Атаках Титанов и Сделанных в Бездне.
При этом ты надрачиваешь на аниме, где нет тайтла, где хотя бы раз ГГ не побила по голове тянка за то что сказал или посмотрел не так. Не говоря уж о всяких Атаках Титанов и Сделанных в Бездне.
205 Кб, 1617x785Продолжаю пилить механику скиллов. На данный момент я поменял худ вот таким образом. По мое задумке персонаж будет иметь некоторое количество изначальных скиллов, но в процессе игры будет получать дополнительные.
Раз уж у меня в игре можно собирать отряд, скиллы должны как-то взаимодействовать с этой отрядной механикой. Давно было понятно что необходимо сделать возможность отдавать соотрядникам команды по типу "атакуем конкретную цель" \ "отступаем" \ "группируемся в одной точке". Есть вариант сделать для этого какое-то отдельное меню, или же сделать эти команды скиллами и отображать прямо тут.
Если учитывать еще и это, то скиллов в распоряжении игрока может скопиться достаточно большое количество. Для того чтобы не запутаться в них, мне кажется неплохим решением добавить кнопки фильтров (слева от списка скиллов) типа "отобразить только боевые скиллы" "отобразить только команды" "отобразить избранное". Хотя, мб это черезмерно нагрузит интерфейс.
Сверху над скиллами идет полоска маны. Так как я буду делать первую в мире игру в гностическом сеттинге, я хочу повыпендриваться. Мана будет называться Гнозис и восполняться будет за получение знаний из окружающего мира, а именно, по чуть-чуть каждый раз когда игрок открывает неизведанную ранее клетку. Будут так-же и другие способы более быстрого пополнения гнозиса чтение Свитков Метровго моря?, а возможно и какие-то другие способы его тратить Мб, разблокировать за его счет новые скиллы? но пока так.
Похожая механика была в DCSS где у некоторых богов piety начислялся за исследование, а потом тратился на абилки.
Еще где-то нужно прописать характеристики скиллов. Пока желтым и зеленым подписана стоимость скилла в гнозисе и в затраченном времени. Но этого недостаточно, где-то еще должно быть название, описание скилла и условия его применения. Видимо нужно городить еще какое-то всплывающее окно над гносис-полоской.
Как мне кажется, еще с этим всем плохо вяжется механика опыта. Сейчас враги дропают опыт за который ты повышаешь уровень, а за уровень повышаешь статы, которые повышают урон. По большому счету это мизерная прибавка к урону, которая ничего не дает. Может мобы должны дропать гнозис а не опыт? Или опыт должен открывать скиллы?
Раз уж у меня в игре можно собирать отряд, скиллы должны как-то взаимодействовать с этой отрядной механикой. Давно было понятно что необходимо сделать возможность отдавать соотрядникам команды по типу "атакуем конкретную цель" \ "отступаем" \ "группируемся в одной точке". Есть вариант сделать для этого какое-то отдельное меню, или же сделать эти команды скиллами и отображать прямо тут.
Если учитывать еще и это, то скиллов в распоряжении игрока может скопиться достаточно большое количество. Для того чтобы не запутаться в них, мне кажется неплохим решением добавить кнопки фильтров (слева от списка скиллов) типа "отобразить только боевые скиллы" "отобразить только команды" "отобразить избранное". Хотя, мб это черезмерно нагрузит интерфейс.
Сверху над скиллами идет полоска маны. Так как я буду делать первую в мире игру в гностическом сеттинге, я хочу повыпендриваться. Мана будет называться Гнозис и восполняться будет за получение знаний из окружающего мира, а именно, по чуть-чуть каждый раз когда игрок открывает неизведанную ранее клетку. Будут так-же и другие способы более быстрого пополнения гнозиса чтение Свитков Метровго моря?, а возможно и какие-то другие способы его тратить Мб, разблокировать за его счет новые скиллы? но пока так.
Похожая механика была в DCSS где у некоторых богов piety начислялся за исследование, а потом тратился на абилки.
Еще где-то нужно прописать характеристики скиллов. Пока желтым и зеленым подписана стоимость скилла в гнозисе и в затраченном времени. Но этого недостаточно, где-то еще должно быть название, описание скилла и условия его применения. Видимо нужно городить еще какое-то всплывающее окно над гносис-полоской.
Как мне кажется, еще с этим всем плохо вяжется механика опыта. Сейчас враги дропают опыт за который ты повышаешь уровень, а за уровень повышаешь статы, которые повышают урон. По большому счету это мизерная прибавка к урону, которая ничего не дает. Может мобы должны дропать гнозис а не опыт? Или опыт должен открывать скиллы?
205 Кб, 1617x785Продолжаю пилить механику скиллов. На данный момент я поменял худ вот таким образом. По мое задумке персонаж будет иметь некоторое количество изначальных скиллов, но в процессе игры будет получать дополнительные.
Раз уж у меня в игре можно собирать отряд, скиллы должны как-то взаимодействовать с этой отрядной механикой. Давно было понятно что необходимо сделать возможность отдавать соотрядникам команды по типу "атакуем конкретную цель" \ "отступаем" \ "группируемся в одной точке". Есть вариант сделать для этого какое-то отдельное меню, или же сделать эти команды скиллами и отображать прямо тут.
Если учитывать еще и это, то скиллов в распоряжении игрока может скопиться достаточно большое количество. Для того чтобы не запутаться в них, мне кажется неплохим решением добавить кнопки фильтров (слева от списка скиллов) типа "отобразить только боевые скиллы" "отобразить только команды" "отобразить избранное". Хотя, мб это черезмерно нагрузит интерфейс.
Сверху над скиллами идет полоска маны. Так как я буду делать первую в мире игру в гностическом сеттинге, я хочу повыпендриваться. Мана будет называться Гнозис и восполняться будет за получение знаний из окружающего мира, а именно, по чуть-чуть каждый раз когда игрок открывает неизведанную ранее клетку. Будут так-же и другие способы более быстрого пополнения гнозиса чтение Свитков Метровго моря?, а возможно и какие-то другие способы его тратить Мб, разблокировать за его счет новые скиллы? но пока так.
Похожая механика была в DCSS где у некоторых богов piety начислялся за исследование, а потом тратился на абилки.
Еще где-то нужно прописать характеристики скиллов. Пока желтым и зеленым подписана стоимость скилла в гнозисе и в затраченном времени. Но этого недостаточно, где-то еще должно быть название, описание скилла и условия его применения. Видимо нужно городить еще какое-то всплывающее окно над гносис-полоской.
Как мне кажется, еще с этим всем плохо вяжется механика опыта. Сейчас враги дропают опыт за который ты повышаешь уровень, а за уровень повышаешь статы, которые повышают урон. По большому счету это мизерная прибавка к урону, которая ничего не дает. Может мобы должны дропать гнозис а не опыт? Или опыт должен открывать скиллы?
Раз уж у меня в игре можно собирать отряд, скиллы должны как-то взаимодействовать с этой отрядной механикой. Давно было понятно что необходимо сделать возможность отдавать соотрядникам команды по типу "атакуем конкретную цель" \ "отступаем" \ "группируемся в одной точке". Есть вариант сделать для этого какое-то отдельное меню, или же сделать эти команды скиллами и отображать прямо тут.
Если учитывать еще и это, то скиллов в распоряжении игрока может скопиться достаточно большое количество. Для того чтобы не запутаться в них, мне кажется неплохим решением добавить кнопки фильтров (слева от списка скиллов) типа "отобразить только боевые скиллы" "отобразить только команды" "отобразить избранное". Хотя, мб это черезмерно нагрузит интерфейс.
Сверху над скиллами идет полоска маны. Так как я буду делать первую в мире игру в гностическом сеттинге, я хочу повыпендриваться. Мана будет называться Гнозис и восполняться будет за получение знаний из окружающего мира, а именно, по чуть-чуть каждый раз когда игрок открывает неизведанную ранее клетку. Будут так-же и другие способы более быстрого пополнения гнозиса чтение Свитков Метровго моря?, а возможно и какие-то другие способы его тратить Мб, разблокировать за его счет новые скиллы? но пока так.
Похожая механика была в DCSS где у некоторых богов piety начислялся за исследование, а потом тратился на абилки.
Еще где-то нужно прописать характеристики скиллов. Пока желтым и зеленым подписана стоимость скилла в гнозисе и в затраченном времени. Но этого недостаточно, где-то еще должно быть название, описание скилла и условия его применения. Видимо нужно городить еще какое-то всплывающее окно над гносис-полоской.
Как мне кажется, еще с этим всем плохо вяжется механика опыта. Сейчас враги дропают опыт за который ты повышаешь уровень, а за уровень повышаешь статы, которые повышают урон. По большому счету это мизерная прибавка к урону, которая ничего не дает. Может мобы должны дропать гнозис а не опыт? Или опыт должен открывать скиллы?
>>842590
ТЫ НЕМНОГО ТУПОВАТ
@
ЗАШЁЛ В СТАРОЕ ПОДЗЕМЕЛЬЕ
@
ПОЧУВСТВОВАЛ РЕЗКИЙ ПРИЛИВ ЗНАНИЙ
@
БУКВАЛЬНО КАЖДАЯ ПЛИТКА ПОЛА ДАЁТ ЗНАНИЯ
@
ПЬЯНЕЯ ОТ СИЛЫ ЗНАНИЙ ПОБЕЖАЛ КУДА ГЛАЗА ГЛЯДЯТ
@
ТЫ НАКАЧАЛСЯ ЗНАНИЯМИ, СТАВ УМНЕЕ ВАССЕРМАНА
@
ТЫ МОЖЕШЬ ПРОСЧИТАТЬ ВСЮ ЖИЗНЬ ВСЕЛЕННОЙ
@
ИЗ-ЗА УГЛА НА ТЕБЯ НАПАДАЮТ СРАЗУ ТРИ КРЫСЫ
@
НО ТЫ ПРЕДСКАЗАЛ ИХ ПОЯВЛЕНИЕ И ЗНАЕШЬ ЧТО ДЕЛАТЬ
@
ПРИМЕНЯЕШЬ СКИЛЛЫ, ИСПЕПЕЛЯЯ КРЫС НА МЕСТЕ
@
ВДРУГ ДО ТЕБЯ ДОХОДИТ, ЧТО ТЫ ИЗРЯДНО ОТУПЕЛ
@
ТЫ НЕ ПОМНИШЬ ГДЕ ТЫ И КАК ТЫ ЗДЕСЬ ОКАЗАЛСЯ
@
НАПАДАЮТ СКЕЛЕТЫ, ТЫ НЕ ЗНАЕШЬ, СКОЛЬКО ИХ
@
ЕЛЕ-ЕЛЕ ОТБИЛ КОСТИСТЫХ, ПОТРАТИВ ПОСЛЕДНИЙ IQ
@
ТЕПЕРЬ ТЫ БОЛЬШЕ НЕ ЧЕЛОВЕК, ТЫ ГРИБ
@
СИДИШЬ НА ПОЛУ И ПУСКАЕШЬ СЛЮНИ
@
ПЛИТКИ ПОЛА БОЛЬШЕ НЕ ДАЮТ ЗНАНИЯ
@
ЧИТАТЬ СВИТКИ ТЫ БОЛЬШЕ НЕ УМЕЕШЬ
@
НИЧТО В МИРЕ НЕ ВЕРНЁТ ТЕБЕ ЗНАНИЯ
@
И ЛИШЬ КРЫСЫ НЕУВЕРЕННО ОКРУЖАЮТ
ТЫ НЕМНОГО ТУПОВАТ
@
ЗАШЁЛ В СТАРОЕ ПОДЗЕМЕЛЬЕ
@
ПОЧУВСТВОВАЛ РЕЗКИЙ ПРИЛИВ ЗНАНИЙ
@
БУКВАЛЬНО КАЖДАЯ ПЛИТКА ПОЛА ДАЁТ ЗНАНИЯ
@
ПЬЯНЕЯ ОТ СИЛЫ ЗНАНИЙ ПОБЕЖАЛ КУДА ГЛАЗА ГЛЯДЯТ
@
ТЫ НАКАЧАЛСЯ ЗНАНИЯМИ, СТАВ УМНЕЕ ВАССЕРМАНА
@
ТЫ МОЖЕШЬ ПРОСЧИТАТЬ ВСЮ ЖИЗНЬ ВСЕЛЕННОЙ
@
ИЗ-ЗА УГЛА НА ТЕБЯ НАПАДАЮТ СРАЗУ ТРИ КРЫСЫ
@
НО ТЫ ПРЕДСКАЗАЛ ИХ ПОЯВЛЕНИЕ И ЗНАЕШЬ ЧТО ДЕЛАТЬ
@
ПРИМЕНЯЕШЬ СКИЛЛЫ, ИСПЕПЕЛЯЯ КРЫС НА МЕСТЕ
@
ВДРУГ ДО ТЕБЯ ДОХОДИТ, ЧТО ТЫ ИЗРЯДНО ОТУПЕЛ
@
ТЫ НЕ ПОМНИШЬ ГДЕ ТЫ И КАК ТЫ ЗДЕСЬ ОКАЗАЛСЯ
@
НАПАДАЮТ СКЕЛЕТЫ, ТЫ НЕ ЗНАЕШЬ, СКОЛЬКО ИХ
@
ЕЛЕ-ЕЛЕ ОТБИЛ КОСТИСТЫХ, ПОТРАТИВ ПОСЛЕДНИЙ IQ
@
ТЕПЕРЬ ТЫ БОЛЬШЕ НЕ ЧЕЛОВЕК, ТЫ ГРИБ
@
СИДИШЬ НА ПОЛУ И ПУСКАЕШЬ СЛЮНИ
@
ПЛИТКИ ПОЛА БОЛЬШЕ НЕ ДАЮТ ЗНАНИЯ
@
ЧИТАТЬ СВИТКИ ТЫ БОЛЬШЕ НЕ УМЕЕШЬ
@
НИЧТО В МИРЕ НЕ ВЕРНЁТ ТЕБЕ ЗНАНИЯ
@
И ЛИШЬ КРЫСЫ НЕУВЕРЕННО ОКРУЖАЮТ
>>842590
ТЫ НЕМНОГО ТУПОВАТ
@
ЗАШЁЛ В СТАРОЕ ПОДЗЕМЕЛЬЕ
@
ПОЧУВСТВОВАЛ РЕЗКИЙ ПРИЛИВ ЗНАНИЙ
@
БУКВАЛЬНО КАЖДАЯ ПЛИТКА ПОЛА ДАЁТ ЗНАНИЯ
@
ПЬЯНЕЯ ОТ СИЛЫ ЗНАНИЙ ПОБЕЖАЛ КУДА ГЛАЗА ГЛЯДЯТ
@
ТЫ НАКАЧАЛСЯ ЗНАНИЯМИ, СТАВ УМНЕЕ ВАССЕРМАНА
@
ТЫ МОЖЕШЬ ПРОСЧИТАТЬ ВСЮ ЖИЗНЬ ВСЕЛЕННОЙ
@
ИЗ-ЗА УГЛА НА ТЕБЯ НАПАДАЮТ СРАЗУ ТРИ КРЫСЫ
@
НО ТЫ ПРЕДСКАЗАЛ ИХ ПОЯВЛЕНИЕ И ЗНАЕШЬ ЧТО ДЕЛАТЬ
@
ПРИМЕНЯЕШЬ СКИЛЛЫ, ИСПЕПЕЛЯЯ КРЫС НА МЕСТЕ
@
ВДРУГ ДО ТЕБЯ ДОХОДИТ, ЧТО ТЫ ИЗРЯДНО ОТУПЕЛ
@
ТЫ НЕ ПОМНИШЬ ГДЕ ТЫ И КАК ТЫ ЗДЕСЬ ОКАЗАЛСЯ
@
НАПАДАЮТ СКЕЛЕТЫ, ТЫ НЕ ЗНАЕШЬ, СКОЛЬКО ИХ
@
ЕЛЕ-ЕЛЕ ОТБИЛ КОСТИСТЫХ, ПОТРАТИВ ПОСЛЕДНИЙ IQ
@
ТЕПЕРЬ ТЫ БОЛЬШЕ НЕ ЧЕЛОВЕК, ТЫ ГРИБ
@
СИДИШЬ НА ПОЛУ И ПУСКАЕШЬ СЛЮНИ
@
ПЛИТКИ ПОЛА БОЛЬШЕ НЕ ДАЮТ ЗНАНИЯ
@
ЧИТАТЬ СВИТКИ ТЫ БОЛЬШЕ НЕ УМЕЕШЬ
@
НИЧТО В МИРЕ НЕ ВЕРНЁТ ТЕБЕ ЗНАНИЯ
@
И ЛИШЬ КРЫСЫ НЕУВЕРЕННО ОКРУЖАЮТ
ТЫ НЕМНОГО ТУПОВАТ
@
ЗАШЁЛ В СТАРОЕ ПОДЗЕМЕЛЬЕ
@
ПОЧУВСТВОВАЛ РЕЗКИЙ ПРИЛИВ ЗНАНИЙ
@
БУКВАЛЬНО КАЖДАЯ ПЛИТКА ПОЛА ДАЁТ ЗНАНИЯ
@
ПЬЯНЕЯ ОТ СИЛЫ ЗНАНИЙ ПОБЕЖАЛ КУДА ГЛАЗА ГЛЯДЯТ
@
ТЫ НАКАЧАЛСЯ ЗНАНИЯМИ, СТАВ УМНЕЕ ВАССЕРМАНА
@
ТЫ МОЖЕШЬ ПРОСЧИТАТЬ ВСЮ ЖИЗНЬ ВСЕЛЕННОЙ
@
ИЗ-ЗА УГЛА НА ТЕБЯ НАПАДАЮТ СРАЗУ ТРИ КРЫСЫ
@
НО ТЫ ПРЕДСКАЗАЛ ИХ ПОЯВЛЕНИЕ И ЗНАЕШЬ ЧТО ДЕЛАТЬ
@
ПРИМЕНЯЕШЬ СКИЛЛЫ, ИСПЕПЕЛЯЯ КРЫС НА МЕСТЕ
@
ВДРУГ ДО ТЕБЯ ДОХОДИТ, ЧТО ТЫ ИЗРЯДНО ОТУПЕЛ
@
ТЫ НЕ ПОМНИШЬ ГДЕ ТЫ И КАК ТЫ ЗДЕСЬ ОКАЗАЛСЯ
@
НАПАДАЮТ СКЕЛЕТЫ, ТЫ НЕ ЗНАЕШЬ, СКОЛЬКО ИХ
@
ЕЛЕ-ЕЛЕ ОТБИЛ КОСТИСТЫХ, ПОТРАТИВ ПОСЛЕДНИЙ IQ
@
ТЕПЕРЬ ТЫ БОЛЬШЕ НЕ ЧЕЛОВЕК, ТЫ ГРИБ
@
СИДИШЬ НА ПОЛУ И ПУСКАЕШЬ СЛЮНИ
@
ПЛИТКИ ПОЛА БОЛЬШЕ НЕ ДАЮТ ЗНАНИЯ
@
ЧИТАТЬ СВИТКИ ТЫ БОЛЬШЕ НЕ УМЕЕШЬ
@
НИЧТО В МИРЕ НЕ ВЕРНЁТ ТЕБЕ ЗНАНИЯ
@
И ЛИШЬ КРЫСЫ НЕУВЕРЕННО ОКРУЖАЮТ
>>842835
Ха-Ха, я вижу скептический прищур неофита, не воспринявшего гностическое учение во всей его полноте и продвинувшегося в изучении священных текстов не далее Евангелия от Фомы. Любой бывалый пневматик стразу пояснит тебе, что если ты и правда человек духовной природы, то окружающая реальность открывает тебе знания принципиально другого рода, чем те, которыми так кичится этот толстый бородатый архонт в жилетке с кучей карманов. Человек, наделенный истинным духовным знанием обладает полной властью над материей, в то время, как над обычными людьми материя, во главе с Ялдабаофом, сама властвует.
Тем не менее, очевидно, что мирская суета по типу бездумного каста абилок способна несколько зашкватрить тебя от материю и отдалить о Бога, каким бы мощным пневматиком ты изначально ни был. Лишившись гнозиса ты не потеряешь способность делать те все те-же вещи что делают люди материальной природы, но Плерома от тебя, увы, отвернется.
Проблема с тем, что игрок построит весь свой геймплей на абилках, после чего окажется в ситуации, когда маны у него больше нет, и двигаться дальше восполняя ее он не может, действительно присутствует. Надо что-то придумать на этот счет, мб действительно добавить каких-то поглощаемых штук, которые ману восстанавливают. Делать реген, что хп, что маны я принципиально не хочу, так как это побуждает персонажа ждать, что во многих играх мне не нравилось.
Во всяком случае, абилки точно не должны быть настолько жизненно необходимыми чтобы без маны игрок просто осел на пол и пускал слюни. Основной дамаг, так или иначе, будет все-таки с руки наноситься.
Ха-Ха, я вижу скептический прищур неофита, не воспринявшего гностическое учение во всей его полноте и продвинувшегося в изучении священных текстов не далее Евангелия от Фомы. Любой бывалый пневматик стразу пояснит тебе, что если ты и правда человек духовной природы, то окружающая реальность открывает тебе знания принципиально другого рода, чем те, которыми так кичится этот толстый бородатый архонт в жилетке с кучей карманов. Человек, наделенный истинным духовным знанием обладает полной властью над материей, в то время, как над обычными людьми материя, во главе с Ялдабаофом, сама властвует.
Тем не менее, очевидно, что мирская суета по типу бездумного каста абилок способна несколько зашкватрить тебя от материю и отдалить о Бога, каким бы мощным пневматиком ты изначально ни был. Лишившись гнозиса ты не потеряешь способность делать те все те-же вещи что делают люди материальной природы, но Плерома от тебя, увы, отвернется.
Проблема с тем, что игрок построит весь свой геймплей на абилках, после чего окажется в ситуации, когда маны у него больше нет, и двигаться дальше восполняя ее он не может, действительно присутствует. Надо что-то придумать на этот счет, мб действительно добавить каких-то поглощаемых штук, которые ману восстанавливают. Делать реген, что хп, что маны я принципиально не хочу, так как это побуждает персонажа ждать, что во многих играх мне не нравилось.
Во всяком случае, абилки точно не должны быть настолько жизненно необходимыми чтобы без маны игрок просто осел на пол и пускал слюни. Основной дамаг, так или иначе, будет все-таки с руки наноситься.
>>842835
Я считаю, это нужно в лор игры добавить. Грибы уже есть.
>>842903
Т.е. банальная "мана" для особых способностей...
Так-то идея с утратой базовых физических способностей крута.
Если делаешь хардкорную игру, то не нужно.
Игрок сделал что-то неправильное - проиграл. Всё.
>ТЕПЕРЬ ТЫ БОЛЬШЕ НЕ ЧЕЛОВЕК, ТЫ ГРИБ
>СИДИШЬ НА ПОЛУ И ПУСКАЕШЬ СЛЮНИ
Я считаю, это нужно в лор игры добавить. Грибы уже есть.
>>842903
>ты не потеряешь способность делать
Т.е. банальная "мана" для особых способностей...
Так-то идея с утратой базовых физических способностей крута.
>Проблема с тем, что игрок построит
>Надо что-то придумать на этот счет
Если делаешь хардкорную игру, то не нужно.
Игрок сделал что-то неправильное - проиграл. Всё.
78 Кб, 838x805>>842959
блин, это отлично
ПРЕДВКУШАЕШЬ КАК КАК СЕЙЧАС КАЙФОВО ПОСТОИШЬ И ПОРЕГЕНИШЬСЯ
@
ВЫБИРАЕШЬ В УКРОМНОЕ МЕСТО
@
ОСТАНАВЛИВАЕШЬСЯ
@
МГНОВЕННАЯ СМЕРТЬ
@
А ВОТ НЕЧГО ПОТОМУ ЧТО
блин, это отлично
ПРЕДВКУШАЕШЬ КАК КАК СЕЙЧАС КАЙФОВО ПОСТОИШЬ И ПОРЕГЕНИШЬСЯ
@
ВЫБИРАЕШЬ В УКРОМНОЕ МЕСТО
@
ОСТАНАВЛИВАЕШЬСЯ
@
МГНОВЕННАЯ СМЕРТЬ
@
А ВОТ НЕЧГО ПОТОМУ ЧТО
>>843056
Не смерть, а превращение в гриб. Такой же, как остальные.
А во время следующего забега игрок может найти этот гриб.
И съесть, конечно.
>МГНОВЕННАЯ СМЕРТЬ
Не смерть, а превращение в гриб. Такой же, как остальные.
А во время следующего забега игрок может найти этот гриб.
И съесть, конечно.
>>796015 (OP)
Получается ты сделал этакий аналог fear & hunger в древнегреческом стиле? Одобряю.
Получается ты сделал этакий аналог fear & hunger в древнегреческом стиле? Одобряю.
>>843503
Твоей игре необходимы багфиксы и нормальный UI/UX.
Кстати, вдохновился анимациями менюшек отсюда:
https://ru.wikipedia.org/wiki/Ex_Machina_(игра)
Хотя там анимации ужасно медленные и бесят.
>Блин, в моей игре тоже необходима корова.
Твоей игре необходимы багфиксы и нормальный UI/UX.
Кстати, вдохновился анимациями менюшек отсюда:
https://ru.wikipedia.org/wiki/Ex_Machina_(игра)
Хотя там анимации ужасно медленные и бесят.
>>843503
Я имею ввиду концепцию взаимодействия с богами. Там в игре тоже есть несколько богов и ты выбираешь кому служить и служить ли вообще . Если бог темный то и действия чтобы получить его милость довольно темные, да и сама "милость" будет специфической.
Понимаю, но, главное не бросай, я бы хотел поиграть в релиз.
> Не играл в F&H, но судя по видосам это не особо похоже.
Я имею ввиду концепцию взаимодействия с богами. Там в игре тоже есть несколько богов и ты выбираешь кому служить и служить ли вообще . Если бог темный то и действия чтобы получить его милость довольно темные, да и сама "милость" будет специфической.
> Да и я бы не сказал что я в принципе что-то сделал на данный момент)
Понимаю, но, главное не бросай, я бы хотел поиграть в релиз.
13 Кб, 360x360>>843616
>Если бог темный то и действия чтобы получить его милость довольно темные, да и сама "милость" будет специфической.
>>843601
Привожу UI к какому-то нормальному виду.
Разобрался как масштабировать окно по размеру содержимого и сделал вот такие всплывающее описания для скилов и для предметов.
Со скилами вроде все и так норм, а в инвентаре по мимо описания предмета на нем должны быть кнопки быстрой экипировки, быстрого использования, и мб еще каких-то действий.
И вот тут опять развилка с кучей вариантов.
- Можно впихнуть эти кнопки в описание снизу или сбоку. Тогда оно не должно исчезать когда ты двигаешь мышку.
- Можно сделать так же, только чтобы это описание всплывало не при наведении мышкой на слот а при нажатии. Тогда можно сделать вообще два таких одинаковых окна, висящих одновременно для двух разных предметов, так чтобы их сравнить можно было. а где эти окна тогда должны висеть? Ну, очевидно не на слотах, иначе будут их перекрывать. Но и не на экипировке, так как тогда нельзя будет сравнивать с экипированными слотами
- Можно забить на сравнение, оставить описание как есть, а для действий сделать еще одну аналогичную маленькую менюшку, с пол слота размером, появляющуюся при нажатии.
- Можно забить и на то и на другое, оставить описание как есть, а эти быстрые действия вообще сделать на хоткеи. (На двойной клик или шифт клик). Того что можно сделать с предметом прямо в инвентаре на самом деле очень ограниченное количество вариантов. Съесть, экипировать... да вроде и все.
Блин, как же это запарно. Я на генератор наверно примерно столько же времени потратил, как суммарно на все эти инвентари, описания и менюшки.
Квадратные слоты, я, кстати вполне возможно переделаю в список, но пока решил их не трогать.
-ОП
Привожу UI к какому-то нормальному виду.
Разобрался как масштабировать окно по размеру содержимого и сделал вот такие всплывающее описания для скилов и для предметов.
Со скилами вроде все и так норм, а в инвентаре по мимо описания предмета на нем должны быть кнопки быстрой экипировки, быстрого использования, и мб еще каких-то действий.
И вот тут опять развилка с кучей вариантов.
- Можно впихнуть эти кнопки в описание снизу или сбоку. Тогда оно не должно исчезать когда ты двигаешь мышку.
- Можно сделать так же, только чтобы это описание всплывало не при наведении мышкой на слот а при нажатии. Тогда можно сделать вообще два таких одинаковых окна, висящих одновременно для двух разных предметов, так чтобы их сравнить можно было. а где эти окна тогда должны висеть? Ну, очевидно не на слотах, иначе будут их перекрывать. Но и не на экипировке, так как тогда нельзя будет сравнивать с экипированными слотами
- Можно забить на сравнение, оставить описание как есть, а для действий сделать еще одну аналогичную маленькую менюшку, с пол слота размером, появляющуюся при нажатии.
- Можно забить и на то и на другое, оставить описание как есть, а эти быстрые действия вообще сделать на хоткеи. (На двойной клик или шифт клик). Того что можно сделать с предметом прямо в инвентаре на самом деле очень ограниченное количество вариантов. Съесть, экипировать... да вроде и все.
Блин, как же это запарно. Я на генератор наверно примерно столько же времени потратил, как суммарно на все эти инвентари, описания и менюшки.
Квадратные слоты, я, кстати вполне возможно переделаю в список, но пока решил их не трогать.
-ОП
>>843616
В этом смысле, да, вполне может быть. Но на счет лора я пока не предпринимаю каких-либо шагов, сначала надо разобраться с технической частью.
Вот, некоторое время назад, у меня появилась идея привязать лор к гностической мифологии. Плюс в том что это не заезженная тема, и вообще мне это интересно.
Тем не менее это не совсем вяжется с изначальной концепцией которая написана в оп-посте, с жертвами и прочим. В гностицизме боги несколько по-другому устроены.
Мне нравится и то и то, я хз что выбрать.
В этом смысле, да, вполне может быть. Но на счет лора я пока не предпринимаю каких-либо шагов, сначала надо разобраться с технической частью.
Вот, некоторое время назад, у меня появилась идея привязать лор к гностической мифологии. Плюс в том что это не заезженная тема, и вообще мне это интересно.
Тем не менее это не совсем вяжется с изначальной концепцией которая написана в оп-посте, с жертвами и прочим. В гностицизме боги несколько по-другому устроены.
Мне нравится и то и то, я хз что выбрать.
>>843724
Вижу ньюфага, не игравшего в рогалики.
Вот, поиграй, очень просто вкатиться:
https://shatteredpixel.com/
Опенсурс + графонисто + хороший UI/UX.
Интуитивно поймёшь, как время считается.
Подсказка: "ход" занимает много "тиков".
Вижу ньюфага, не игравшего в рогалики.
Вот, поиграй, очень просто вкатиться:
https://shatteredpixel.com/
Опенсурс + графонисто + хороший UI/UX.
Интуитивно поймёшь, как время считается.
Подсказка: "ход" занимает много "тиков".
>>843707
Хрень, будет мешать.
Вот это норм, на видео выше именно так сделано.
В идеале, они должны быть плавающими. Это наиболее очевидный вариант. Пусть игрок сам передвинет окно туда, куда ему удобно, и растянет до удобного размера. Так делают многие ММО/РПГ, потому что у них по природе много окошек, которые каждый настраивает под себя. Раз уж твой рогалик всё равно не классический для ASCII-задротов, а ближе к обычной РПГ, то и UI смотри в ММО/РПГ. Не нужно изобретать велосипед, учись у удачных проектов и не повторяй ошибок неудачных.
Бред, сколько кнопок ты там уместишь? Одну? Две? Даже если без надписей, всё равно мелко. Если уж хочешь отдельные кнопки, то лучше круговое меню вокруг слота, чем внутри/размером со слот. Либо я тебя не понял, о каком слоте идёт речь. Но вариант с кнопками под/внутри описания предмета мне нравится больше.
Недостаточно дружелюбно для тех, кто не знает хоткеи или не может их использовать. Те хоткеи, которые удобны тебе, могут быть неудобны другим. Нет, хоткеи, конечно, нужны, но это как бы продвинутый уровень. Даже профессиональный софт вроде Blender часто ругают за то, что у него всё на хоткеях и мало визуальных элементов управления. А игра - тем более... К Dwarf Fortress много критики из-за необходимости учить комбинации клавиш вместо навигации по меню - хотя комбинации клавиш, конечно, ускоряют игровой процесс, но новичку сложно с нуля в этом всём разобраться.
А ты не планируешь расширять и дополнять игру в будущем? Нужно закладывать гибкость с самого начала, иначе потом придётся переделывать. Вот в том же Shattered Pixel Dungeon у некоторых предметов в инвентаре аж 5-6 кнопок действий. Допустим, сейчас ты не планируешь добавлять такие сложные предметы, а что, если потом захочется? Будешь делать новую игру с нуля? Куда лучше допилить в старую, если не хочешь сильно менять - в виде DLC или мода, но основа в любом случае должна быть достаточно гибкой для таких нововведений.
>Можно впихнуть эти кнопки в описание снизу или сбоку. Тогда оно не должно исчезать когда ты двигаешь мышку.
Хрень, будет мешать.
>Можно сделать так же, только чтобы это описание всплывало не при наведении мышкой на слот а при нажатии.
Вот это норм, на видео выше именно так сделано.
>где эти окна тогда должны висеть?
В идеале, они должны быть плавающими. Это наиболее очевидный вариант. Пусть игрок сам передвинет окно туда, куда ему удобно, и растянет до удобного размера. Так делают многие ММО/РПГ, потому что у них по природе много окошек, которые каждый настраивает под себя. Раз уж твой рогалик всё равно не классический для ASCII-задротов, а ближе к обычной РПГ, то и UI смотри в ММО/РПГ. Не нужно изобретать велосипед, учись у удачных проектов и не повторяй ошибок неудачных.
>для действий сделать еще одну аналогичную маленькую менюшку, с пол слота размером, появляющуюся при нажатии.
Бред, сколько кнопок ты там уместишь? Одну? Две? Даже если без надписей, всё равно мелко. Если уж хочешь отдельные кнопки, то лучше круговое меню вокруг слота, чем внутри/размером со слот. Либо я тебя не понял, о каком слоте идёт речь. Но вариант с кнопками под/внутри описания предмета мне нравится больше.
>быстрые действия вообще сделать на хоткеи
Недостаточно дружелюбно для тех, кто не знает хоткеи или не может их использовать. Те хоткеи, которые удобны тебе, могут быть неудобны другим. Нет, хоткеи, конечно, нужны, но это как бы продвинутый уровень. Даже профессиональный софт вроде Blender часто ругают за то, что у него всё на хоткеях и мало визуальных элементов управления. А игра - тем более... К Dwarf Fortress много критики из-за необходимости учить комбинации клавиш вместо навигации по меню - хотя комбинации клавиш, конечно, ускоряют игровой процесс, но новичку сложно с нуля в этом всём разобраться.
>Того что можно сделать с предметом прямо в инвентаре на самом деле очень ограниченное количество вариантов. Съесть, экипировать... да вроде и все.
А ты не планируешь расширять и дополнять игру в будущем? Нужно закладывать гибкость с самого начала, иначе потом придётся переделывать. Вот в том же Shattered Pixel Dungeon у некоторых предметов в инвентаре аж 5-6 кнопок действий. Допустим, сейчас ты не планируешь добавлять такие сложные предметы, а что, если потом захочется? Будешь делать новую игру с нуля? Куда лучше допилить в старую, если не хочешь сильно менять - в виде DLC или мода, но основа в любом случае должна быть достаточно гибкой для таких нововведений.
>>843707
Хрень, будет мешать.
Вот это норм, на видео выше именно так сделано.
В идеале, они должны быть плавающими. Это наиболее очевидный вариант. Пусть игрок сам передвинет окно туда, куда ему удобно, и растянет до удобного размера. Так делают многие ММО/РПГ, потому что у них по природе много окошек, которые каждый настраивает под себя. Раз уж твой рогалик всё равно не классический для ASCII-задротов, а ближе к обычной РПГ, то и UI смотри в ММО/РПГ. Не нужно изобретать велосипед, учись у удачных проектов и не повторяй ошибок неудачных.
Бред, сколько кнопок ты там уместишь? Одну? Две? Даже если без надписей, всё равно мелко. Если уж хочешь отдельные кнопки, то лучше круговое меню вокруг слота, чем внутри/размером со слот. Либо я тебя не понял, о каком слоте идёт речь. Но вариант с кнопками под/внутри описания предмета мне нравится больше.
Недостаточно дружелюбно для тех, кто не знает хоткеи или не может их использовать. Те хоткеи, которые удобны тебе, могут быть неудобны другим. Нет, хоткеи, конечно, нужны, но это как бы продвинутый уровень. Даже профессиональный софт вроде Blender часто ругают за то, что у него всё на хоткеях и мало визуальных элементов управления. А игра - тем более... К Dwarf Fortress много критики из-за необходимости учить комбинации клавиш вместо навигации по меню - хотя комбинации клавиш, конечно, ускоряют игровой процесс, но новичку сложно с нуля в этом всём разобраться.
А ты не планируешь расширять и дополнять игру в будущем? Нужно закладывать гибкость с самого начала, иначе потом придётся переделывать. Вот в том же Shattered Pixel Dungeon у некоторых предметов в инвентаре аж 5-6 кнопок действий. Допустим, сейчас ты не планируешь добавлять такие сложные предметы, а что, если потом захочется? Будешь делать новую игру с нуля? Куда лучше допилить в старую, если не хочешь сильно менять - в виде DLC или мода, но основа в любом случае должна быть достаточно гибкой для таких нововведений.
>Можно впихнуть эти кнопки в описание снизу или сбоку. Тогда оно не должно исчезать когда ты двигаешь мышку.
Хрень, будет мешать.
>Можно сделать так же, только чтобы это описание всплывало не при наведении мышкой на слот а при нажатии.
Вот это норм, на видео выше именно так сделано.
>где эти окна тогда должны висеть?
В идеале, они должны быть плавающими. Это наиболее очевидный вариант. Пусть игрок сам передвинет окно туда, куда ему удобно, и растянет до удобного размера. Так делают многие ММО/РПГ, потому что у них по природе много окошек, которые каждый настраивает под себя. Раз уж твой рогалик всё равно не классический для ASCII-задротов, а ближе к обычной РПГ, то и UI смотри в ММО/РПГ. Не нужно изобретать велосипед, учись у удачных проектов и не повторяй ошибок неудачных.
>для действий сделать еще одну аналогичную маленькую менюшку, с пол слота размером, появляющуюся при нажатии.
Бред, сколько кнопок ты там уместишь? Одну? Две? Даже если без надписей, всё равно мелко. Если уж хочешь отдельные кнопки, то лучше круговое меню вокруг слота, чем внутри/размером со слот. Либо я тебя не понял, о каком слоте идёт речь. Но вариант с кнопками под/внутри описания предмета мне нравится больше.
>быстрые действия вообще сделать на хоткеи
Недостаточно дружелюбно для тех, кто не знает хоткеи или не может их использовать. Те хоткеи, которые удобны тебе, могут быть неудобны другим. Нет, хоткеи, конечно, нужны, но это как бы продвинутый уровень. Даже профессиональный софт вроде Blender часто ругают за то, что у него всё на хоткеях и мало визуальных элементов управления. А игра - тем более... К Dwarf Fortress много критики из-за необходимости учить комбинации клавиш вместо навигации по меню - хотя комбинации клавиш, конечно, ускоряют игровой процесс, но новичку сложно с нуля в этом всём разобраться.
>Того что можно сделать с предметом прямо в инвентаре на самом деле очень ограниченное количество вариантов. Съесть, экипировать... да вроде и все.
А ты не планируешь расширять и дополнять игру в будущем? Нужно закладывать гибкость с самого начала, иначе потом придётся переделывать. Вот в том же Shattered Pixel Dungeon у некоторых предметов в инвентаре аж 5-6 кнопок действий. Допустим, сейчас ты не планируешь добавлять такие сложные предметы, а что, если потом захочется? Будешь делать новую игру с нуля? Куда лучше допилить в старую, если не хочешь сильно менять - в виде DLC или мода, но основа в любом случае должна быть достаточно гибкой для таких нововведений.
>>843732
А можно просто объяснить? Я из рогаликов играл в Tales of Maj'Eyal, но все равно не понимаю
А можно просто объяснить? Я из рогаликов играл в Tales of Maj'Eyal, но все равно не понимаю
>>843735
Короче я сделаю так: наводишь на слот - появляется описание. Жмешь на него, описание исчезает появляется менюшка с действиями.
Сравнение предметов и плавающие окна это какой-то оверкил мне лень. Все таки темп игры медленный, сравнить 4 стата можно и без этих окон, а ощутимо больше статов вряд ли будет.
Я мел в виду просто маленькую менюшку. Решил просто сделать в ней кнопки с текстом, рисовать эти иконки, еще и маленькие я задолбаюсь. Еще одну радиальную анимированную фиговину я тоже не хочу делать.
По поводу расширяемости, не вижу никакой проблемы чтобы добавлять новые функции, но их все равно не будет какое-то запредельное количество, особенно таких, которые можно одновременно с одним предметом провернуть.
>>843738
В игре идут тики, каждый перс когда что-то делает ждет после этого несколько тиков, это и называется затраченным временем. Один шаг делаешь, 10 тиков ждешь.
Короче я сделаю так: наводишь на слот - появляется описание. Жмешь на него, описание исчезает появляется менюшка с действиями.
Сравнение предметов и плавающие окна это какой-то оверкил мне лень. Все таки темп игры медленный, сравнить 4 стата можно и без этих окон, а ощутимо больше статов вряд ли будет.
>с пол слота размером
Я мел в виду просто маленькую менюшку. Решил просто сделать в ней кнопки с текстом, рисовать эти иконки, еще и маленькие я задолбаюсь. Еще одну радиальную анимированную фиговину я тоже не хочу делать.
По поводу расширяемости, не вижу никакой проблемы чтобы добавлять новые функции, но их все равно не будет какое-то запредельное количество, особенно таких, которые можно одновременно с одним предметом провернуть.
>>843738
В игре идут тики, каждый перс когда что-то делает ждет после этого несколько тиков, это и называется затраченным временем. Один шаг делаешь, 10 тиков ждешь.
>>843784
А как коррелируют шаги и тики? Я реально не понимаю концепцию. Или лучше статейку какую-нибудь об этом?
А как коррелируют шаги и тики? Я реально не понимаю концепцию. Или лучше статейку какую-нибудь об этом?
>>843830
Если по простому то
Быстрый персонаж
a...a...a...
Медленный персонаж
a.....a.....
Монстр в это время
m...m...m
Соответственно, игрок делает шаг во время "a"
То есть между шагами медленного персонажа, монстр успел 2 раза походить, возможно на 2 клетки или 2 атаки сделать.
Алсо, в рогаликах часто делают рандом +-1 к цене в тиках. Это чтобы медленные иногда таки догоняли быстрых.
Если по простому то
Быстрый персонаж
a...a...a...
Медленный персонаж
a.....a.....
Монстр в это время
m...m...m
Соответственно, игрок делает шаг во время "a"
То есть между шагами медленного персонажа, монстр успел 2 раза походить, возможно на 2 клетки или 2 атаки сделать.
Алсо, в рогаликах часто делают рандом +-1 к цене в тиках. Это чтобы медленные иногда таки догоняли быстрых.
>>843842
То есть, как бы за один ход делается несколько действий, я правильно понял? Но ведь игрок за один ход может сделать только одно. Я не понимаю
И в интернете материала на тему я не нашел.
То есть, как бы за один ход делается несколько действий, я правильно понял? Но ведь игрок за один ход может сделать только одно. Я не понимаю
И в интернете материала на тему я не нашел.
>>843859
Игрок делает действие "a", на этом его ход заканчивается и он спит несколько тиков до своего следующего "а". Поэтому для игрока, это выглядит как будто он сделал только одно действие, а какой-то монстр успел походить дважды.
Игра работает по тикам, но останавливается и ждет ввода "а" от игрока.
Не знаю, как еще проще объяснить
https://www.reddit.com/r/roguelikedev/comments/4pk2k6/faq_friday_41_time_systems/
Попробую еще раз словами
Игрок может делать одно действие раз в 5 секунд.
Он делает свои действия на 0, 5, 10, 15 секундах.
Монстр ходит раз в 3 секунды. Он делает их на 1, 4, 7, 10 секундах.
Игрок ходит на 0 секунде
Дальше игрок спит, игра быстро считает
(На 1 секунде: ходит монстр
На 2, 3 секунде: ничего
На 4 секунде: ходит монстр) - эти "секунды" схлопнуты в мгновение
На 5 секунде: второй ход игрока.
Игрок делает действие "a", на этом его ход заканчивается и он спит несколько тиков до своего следующего "а". Поэтому для игрока, это выглядит как будто он сделал только одно действие, а какой-то монстр успел походить дважды.
Игра работает по тикам, но останавливается и ждет ввода "а" от игрока.
Не знаю, как еще проще объяснить
https://www.reddit.com/r/roguelikedev/comments/4pk2k6/faq_friday_41_time_systems/
Попробую еще раз словами
Игрок может делать одно действие раз в 5 секунд.
Он делает свои действия на 0, 5, 10, 15 секундах.
Монстр ходит раз в 3 секунды. Он делает их на 1, 4, 7, 10 секундах.
Игрок ходит на 0 секунде
Дальше игрок спит, игра быстро считает
(На 1 секунде: ходит монстр
На 2, 3 секунде: ничего
На 4 секунде: ходит монстр) - эти "секунды" схлопнуты в мгновение
На 5 секунде: второй ход игрока.
Написал этот пост ещё вчера днём, но отвлёкся и забыл отправить...
>>843724 >>843738
Игра имеет состояние. Есть правила перехода из одного состояния в другое. Переход из одного состояние в другое происходит в определённый момент - "тик":
Но некоторые правила требуют, чтобы прошло несколько тиков, прежде чем что-то изменится. Скажем, переход с клетки на клетку может занимать 10 тиков: после того, как игрок нажал на соседнюю клетку, игра переходит через 9 состояний, останавливаясь на 10-м. Если моб должен двигаться в два раза быстрее игрока, то он окажется на соседней клетке через 5 тиков, а ещё через 5 - на следующей. Аналогично с действиями: если мобу для удара нужно 20 тиков, а игроку только 5, то игрок может сделать по этому мобу 4 удара подряд, прежде чем моб сможет нанести ответный удар. Если что-то прерывает действие до того, как оно сможет совершиться, то оно не совершится. Т.е. если быстрый моб встанет на клетку, на которую игрок должен пройти через один тик, игрок остановится на предыдущей клетке. Если игрок оттолкнул на соседнюю клетку моба, которому осталось ждать один тик до своего удара, то он не сможет ударить игрока (ударит по пустой клетке). Долго заряжаемые атаки, прыжки и т.п. могут дополнительно подсвечиваться игрой, отображая соответствующие подсказки или спецэффекты в том месте, куда персонаж собирается ударить или прыгнуть, чтобы игрок мог, например, увернуться, если его движения требуют сравнительно мало тиков.
Концепция "шага"/"хода" может подразумевать одно действие игрока, но при этом действие может тратить несколько тиков. Если игрок выпил зелье ускорения движения, то его шаги тратят меньше тиков, и в результате мобам сложнее его догнать. Если игрок попал в капкан, который парализует его на 50 тиков, он получит возможность сделать ход только когда все окружающие мобы сделают все свои действия, занимающие 50 тиков (если мобов рядом нет, симуляция пройдёт мгновенно, т.к. игре нечего анимировать на экране). Т.е. несмотря на пошаговость, в рогалике есть время и разная длительность разных действий/событий/состояний.
Для сравнения, в шахматах каждое движение фигуры выполняется за один тик. Т.е. в шахматах не возникает ситуации, когда одна фигура планирует переместиться или атаковать и ждёт, а другая фигура подрезает её или успевает убежать от неё. Но в рогалике такая система была бы скучной и не позволила бы реализовать многие механики, связанные со скоростью действий. Нельзя было бы изобразить, что вот этот персонаж быстрый, хотя и хрупкий, а вот этот медленный и неповоротливый, но сильный и выносливый. Поэтому разделили шаг/ход на множество частей - тиков. Продолжая сравнение с шахматами: представь себе, что противник говорит "я собираюсь пойти ладьёй", после чего ты имеешь право сделать либо 4 действия разными пешками, либо 2 действия разными слонами или конями, либо так же как он заявить, что собираешься пойти ладьёй. Только после твоих действий он сможет переместить ладью. Такие правила кажутся странными, но это как раз то, что происходит в рогаликах. Пешка, можно сказать, имеет самую быструю скорость и потому самую низкую стоимость в тиках, а остальные фигуры медленнее, и поэтому дороже по тикам.
>>843724 >>843738
Игра имеет состояние. Есть правила перехода из одного состояния в другое. Переход из одного состояние в другое происходит в определённый момент - "тик":
>прогр., жарг. условный интервал времени, за который выполняется одна простая команда
Но некоторые правила требуют, чтобы прошло несколько тиков, прежде чем что-то изменится. Скажем, переход с клетки на клетку может занимать 10 тиков: после того, как игрок нажал на соседнюю клетку, игра переходит через 9 состояний, останавливаясь на 10-м. Если моб должен двигаться в два раза быстрее игрока, то он окажется на соседней клетке через 5 тиков, а ещё через 5 - на следующей. Аналогично с действиями: если мобу для удара нужно 20 тиков, а игроку только 5, то игрок может сделать по этому мобу 4 удара подряд, прежде чем моб сможет нанести ответный удар. Если что-то прерывает действие до того, как оно сможет совершиться, то оно не совершится. Т.е. если быстрый моб встанет на клетку, на которую игрок должен пройти через один тик, игрок остановится на предыдущей клетке. Если игрок оттолкнул на соседнюю клетку моба, которому осталось ждать один тик до своего удара, то он не сможет ударить игрока (ударит по пустой клетке). Долго заряжаемые атаки, прыжки и т.п. могут дополнительно подсвечиваться игрой, отображая соответствующие подсказки или спецэффекты в том месте, куда персонаж собирается ударить или прыгнуть, чтобы игрок мог, например, увернуться, если его движения требуют сравнительно мало тиков.
Концепция "шага"/"хода" может подразумевать одно действие игрока, но при этом действие может тратить несколько тиков. Если игрок выпил зелье ускорения движения, то его шаги тратят меньше тиков, и в результате мобам сложнее его догнать. Если игрок попал в капкан, который парализует его на 50 тиков, он получит возможность сделать ход только когда все окружающие мобы сделают все свои действия, занимающие 50 тиков (если мобов рядом нет, симуляция пройдёт мгновенно, т.к. игре нечего анимировать на экране). Т.е. несмотря на пошаговость, в рогалике есть время и разная длительность разных действий/событий/состояний.
Для сравнения, в шахматах каждое движение фигуры выполняется за один тик. Т.е. в шахматах не возникает ситуации, когда одна фигура планирует переместиться или атаковать и ждёт, а другая фигура подрезает её или успевает убежать от неё. Но в рогалике такая система была бы скучной и не позволила бы реализовать многие механики, связанные со скоростью действий. Нельзя было бы изобразить, что вот этот персонаж быстрый, хотя и хрупкий, а вот этот медленный и неповоротливый, но сильный и выносливый. Поэтому разделили шаг/ход на множество частей - тиков. Продолжая сравнение с шахматами: представь себе, что противник говорит "я собираюсь пойти ладьёй", после чего ты имеешь право сделать либо 4 действия разными пешками, либо 2 действия разными слонами или конями, либо так же как он заявить, что собираешься пойти ладьёй. Только после твоих действий он сможет переместить ладью. Такие правила кажутся странными, но это как раз то, что происходит в рогаликах. Пешка, можно сказать, имеет самую быструю скорость и потому самую низкую стоимость в тиках, а остальные фигуры медленнее, и поэтому дороже по тикам.
Написал этот пост ещё вчера днём, но отвлёкся и забыл отправить...
>>843724 >>843738
Игра имеет состояние. Есть правила перехода из одного состояния в другое. Переход из одного состояние в другое происходит в определённый момент - "тик":
Но некоторые правила требуют, чтобы прошло несколько тиков, прежде чем что-то изменится. Скажем, переход с клетки на клетку может занимать 10 тиков: после того, как игрок нажал на соседнюю клетку, игра переходит через 9 состояний, останавливаясь на 10-м. Если моб должен двигаться в два раза быстрее игрока, то он окажется на соседней клетке через 5 тиков, а ещё через 5 - на следующей. Аналогично с действиями: если мобу для удара нужно 20 тиков, а игроку только 5, то игрок может сделать по этому мобу 4 удара подряд, прежде чем моб сможет нанести ответный удар. Если что-то прерывает действие до того, как оно сможет совершиться, то оно не совершится. Т.е. если быстрый моб встанет на клетку, на которую игрок должен пройти через один тик, игрок остановится на предыдущей клетке. Если игрок оттолкнул на соседнюю клетку моба, которому осталось ждать один тик до своего удара, то он не сможет ударить игрока (ударит по пустой клетке). Долго заряжаемые атаки, прыжки и т.п. могут дополнительно подсвечиваться игрой, отображая соответствующие подсказки или спецэффекты в том месте, куда персонаж собирается ударить или прыгнуть, чтобы игрок мог, например, увернуться, если его движения требуют сравнительно мало тиков.
Концепция "шага"/"хода" может подразумевать одно действие игрока, но при этом действие может тратить несколько тиков. Если игрок выпил зелье ускорения движения, то его шаги тратят меньше тиков, и в результате мобам сложнее его догнать. Если игрок попал в капкан, который парализует его на 50 тиков, он получит возможность сделать ход только когда все окружающие мобы сделают все свои действия, занимающие 50 тиков (если мобов рядом нет, симуляция пройдёт мгновенно, т.к. игре нечего анимировать на экране). Т.е. несмотря на пошаговость, в рогалике есть время и разная длительность разных действий/событий/состояний.
Для сравнения, в шахматах каждое движение фигуры выполняется за один тик. Т.е. в шахматах не возникает ситуации, когда одна фигура планирует переместиться или атаковать и ждёт, а другая фигура подрезает её или успевает убежать от неё. Но в рогалике такая система была бы скучной и не позволила бы реализовать многие механики, связанные со скоростью действий. Нельзя было бы изобразить, что вот этот персонаж быстрый, хотя и хрупкий, а вот этот медленный и неповоротливый, но сильный и выносливый. Поэтому разделили шаг/ход на множество частей - тиков. Продолжая сравнение с шахматами: представь себе, что противник говорит "я собираюсь пойти ладьёй", после чего ты имеешь право сделать либо 4 действия разными пешками, либо 2 действия разными слонами или конями, либо так же как он заявить, что собираешься пойти ладьёй. Только после твоих действий он сможет переместить ладью. Такие правила кажутся странными, но это как раз то, что происходит в рогаликах. Пешка, можно сказать, имеет самую быструю скорость и потому самую низкую стоимость в тиках, а остальные фигуры медленнее, и поэтому дороже по тикам.
>>843724 >>843738
Игра имеет состояние. Есть правила перехода из одного состояния в другое. Переход из одного состояние в другое происходит в определённый момент - "тик":
>прогр., жарг. условный интервал времени, за который выполняется одна простая команда
Но некоторые правила требуют, чтобы прошло несколько тиков, прежде чем что-то изменится. Скажем, переход с клетки на клетку может занимать 10 тиков: после того, как игрок нажал на соседнюю клетку, игра переходит через 9 состояний, останавливаясь на 10-м. Если моб должен двигаться в два раза быстрее игрока, то он окажется на соседней клетке через 5 тиков, а ещё через 5 - на следующей. Аналогично с действиями: если мобу для удара нужно 20 тиков, а игроку только 5, то игрок может сделать по этому мобу 4 удара подряд, прежде чем моб сможет нанести ответный удар. Если что-то прерывает действие до того, как оно сможет совершиться, то оно не совершится. Т.е. если быстрый моб встанет на клетку, на которую игрок должен пройти через один тик, игрок остановится на предыдущей клетке. Если игрок оттолкнул на соседнюю клетку моба, которому осталось ждать один тик до своего удара, то он не сможет ударить игрока (ударит по пустой клетке). Долго заряжаемые атаки, прыжки и т.п. могут дополнительно подсвечиваться игрой, отображая соответствующие подсказки или спецэффекты в том месте, куда персонаж собирается ударить или прыгнуть, чтобы игрок мог, например, увернуться, если его движения требуют сравнительно мало тиков.
Концепция "шага"/"хода" может подразумевать одно действие игрока, но при этом действие может тратить несколько тиков. Если игрок выпил зелье ускорения движения, то его шаги тратят меньше тиков, и в результате мобам сложнее его догнать. Если игрок попал в капкан, который парализует его на 50 тиков, он получит возможность сделать ход только когда все окружающие мобы сделают все свои действия, занимающие 50 тиков (если мобов рядом нет, симуляция пройдёт мгновенно, т.к. игре нечего анимировать на экране). Т.е. несмотря на пошаговость, в рогалике есть время и разная длительность разных действий/событий/состояний.
Для сравнения, в шахматах каждое движение фигуры выполняется за один тик. Т.е. в шахматах не возникает ситуации, когда одна фигура планирует переместиться или атаковать и ждёт, а другая фигура подрезает её или успевает убежать от неё. Но в рогалике такая система была бы скучной и не позволила бы реализовать многие механики, связанные со скоростью действий. Нельзя было бы изобразить, что вот этот персонаж быстрый, хотя и хрупкий, а вот этот медленный и неповоротливый, но сильный и выносливый. Поэтому разделили шаг/ход на множество частей - тиков. Продолжая сравнение с шахматами: представь себе, что противник говорит "я собираюсь пойти ладьёй", после чего ты имеешь право сделать либо 4 действия разными пешками, либо 2 действия разными слонами или конями, либо так же как он заявить, что собираешься пойти ладьёй. Только после твоих действий он сможет переместить ладью. Такие правила кажутся странными, но это как раз то, что происходит в рогаликах. Пешка, можно сказать, имеет самую быструю скорость и потому самую низкую стоимость в тиках, а остальные фигуры медленнее, и поэтому дороже по тикам.
>>843972
Это да, просто до меня это не дошло сразу, потому что в рогаликах все ходят одновременно. Так что как-то не очень очевидны эти экшен-поинты Да и их зависимость от игрока тоже вещь странная
Это да, просто до меня это не дошло сразу, потому что в рогаликах все ходят одновременно. Так что как-то не очень очевидны эти экшен-поинты Да и их зависимость от игрока тоже вещь странная
>>839842
Если бы я мог скачать твои треки где-то еще, я бы их поставил. Они классные, пускай, по крайней мере, в главном меню играют.
Привет! Я в сентябре экстренно мобилизовал руки в ноги и призвался в дальние страны, подальше от происходящего. Саундклауд в России всё, да. Но, к сожалению, там, где я сейчас, он тоже недоступен. А файлы с компа для меня сейчас недоступны. В который раз, как дебил, жалею, что не заливал всё на облако. Я на днях попрошу кое-кого достать их с моей пекарни, оставшейся в РФ, и тогда, может быть, смогу перезалить их для тебя.
>Анон-музыкант, отзовись, если ты еще тут! По твоей старой ссылке у меня не получается перейти. Видимо, саундклауд у нас того...
Если бы я мог скачать твои треки где-то еще, я бы их поставил. Они классные, пускай, по крайней мере, в главном меню играют.
Привет! Я в сентябре экстренно мобилизовал руки в ноги и призвался в дальние страны, подальше от происходящего. Саундклауд в России всё, да. Но, к сожалению, там, где я сейчас, он тоже недоступен. А файлы с компа для меня сейчас недоступны. В который раз, как дебил, жалею, что не заливал всё на облако. Я на днях попрошу кое-кого достать их с моей пекарни, оставшейся в РФ, и тогда, может быть, смогу перезалить их для тебя.
>>843984
Так опкакался, что хддшку дернуть из компа не смог?
Так опкакался, что хддшку дернуть из компа не смог?
>>843984
Эх, жаль что так случилось, но в то же время я рад что ты не исчез на совсем. В любом случае, если перезальешь эти треки или напишешь что-то еще, я с радостью их использую, благо я разобрался с механизмом озвучки.
Я уж думал, ты стал музыкантом несколько другого рода)
-Оп
Эх, жаль что так случилось, но в то же время я рад что ты не исчез на совсем. В любом случае, если перезальешь эти треки или напишешь что-то еще, я с радостью их использую, благо я разобрался с механизмом озвучки.
Я уж думал, ты стал музыкантом несколько другого рода)
-Оп
С быстрыми действиями я вроде разобрался.
Наводишь курсор - видишь описание.
Жмешь пкм - видишь доступные действия.
Жмешь два раза - предмет идет в руку.
После этого я занялся переработкой самих слотов. Вообще система инвентаря была самой архаичной частью игры я написал ее полтора года назад по гайду с ютуба. Тогда я естественно вообще не думал о том подходит она мне или нет, так как сделать даже это мне было сложно.
Теперь я хочу чтобы инвентарь выполнял следующие задачи:
- Решал проблему стаков, когда у тебя все завалено кучей костей.
- Был бесконечным.
- Чтобы все еще можно было таскать предметы мышкой. Я считаю что это должно остаться для того чтобы экипировать разные предметы в разные слоты. По крайней мере остальные варианты как это делать сейчас выглядят не очень.
Я придумал следующее:
У тебя есть вертикальный спиок всех стаков предметов. (рис.1)
По идее там еще должен быть ползунок сбоку который все это будет прокручивать. А над списком кнопки для сортировки.
У стака есть "заглавный слот" отображающийся рядом с названием. Взаимодействуя с ним можно совершать действия с верхним предметом из стопки.
Если ты просто хочешь съесть кусок гриба то тебе не важно какой конкретно это кусок. Жмешь на стопку сьесть и ешь верхний. Или перетаскиваешь в руку, тогда тоже перетаскивается верхний кусок.
При этом ты можешь нажать на стопку и тогда под ней отобразятся все конкретные лежащие в ней предметы.(Рис.2)
Их тоже можно перетаскивать и.т.д.
Но и тут есть несколько неясных моментов.
Теперь стопки это строки списка. Сделать стопки сеткой как до этого были слоты нельзя, так как тогда непонятно, куда они будут раскрываться.
Таким образом там где название стопки куча неиспользуемого места. Что с ним делать? Статы там размещать я не хочу, это перегружает и для них отдельное окно есть.
Чтобы этого избежать можно пойти радикальным путем и вообще сделать инвентарь частью HUDа я хз как это правильно называть (Рис.3) С возможностью, ее скрыть, конечно. И мб даже с возможностью ходить с открытым инвентарем.
То же самое сделать и с экраном анатомии. Сделать его появление по нажатию на портрет в правом углу худа, и отцепить от него слоты экипировки, повестив их слева от инвентаря.По факту этот анатомический экран нужен только для того чтобы смотреть насколько конкретно ты задамажен, хилить конкретные части тела и смотреть на каких из них висят эффекты. С инвентарем и экипировкой это все никак не связано.
Так же такое расположение позволит сделать отдельный экран подбора предметов с земли\ из контейнера, висящий например там где сейчас скилы. Или вертикальным списком как и инвентарь, но справа.
Наводишь курсор - видишь описание.
Жмешь пкм - видишь доступные действия.
Жмешь два раза - предмет идет в руку.
После этого я занялся переработкой самих слотов. Вообще система инвентаря была самой архаичной частью игры я написал ее полтора года назад по гайду с ютуба. Тогда я естественно вообще не думал о том подходит она мне или нет, так как сделать даже это мне было сложно.
Теперь я хочу чтобы инвентарь выполнял следующие задачи:
- Решал проблему стаков, когда у тебя все завалено кучей костей.
- Был бесконечным.
- Чтобы все еще можно было таскать предметы мышкой. Я считаю что это должно остаться для того чтобы экипировать разные предметы в разные слоты. По крайней мере остальные варианты как это делать сейчас выглядят не очень.
Я придумал следующее:
У тебя есть вертикальный спиок всех стаков предметов. (рис.1)
По идее там еще должен быть ползунок сбоку который все это будет прокручивать. А над списком кнопки для сортировки.
У стака есть "заглавный слот" отображающийся рядом с названием. Взаимодействуя с ним можно совершать действия с верхним предметом из стопки.
Если ты просто хочешь съесть кусок гриба то тебе не важно какой конкретно это кусок. Жмешь на стопку сьесть и ешь верхний. Или перетаскиваешь в руку, тогда тоже перетаскивается верхний кусок.
При этом ты можешь нажать на стопку и тогда под ней отобразятся все конкретные лежащие в ней предметы.(Рис.2)
Их тоже можно перетаскивать и.т.д.
Но и тут есть несколько неясных моментов.
Теперь стопки это строки списка. Сделать стопки сеткой как до этого были слоты нельзя, так как тогда непонятно, куда они будут раскрываться.
Таким образом там где название стопки куча неиспользуемого места. Что с ним делать? Статы там размещать я не хочу, это перегружает и для них отдельное окно есть.
Чтобы этого избежать можно пойти радикальным путем и вообще сделать инвентарь частью HUDа я хз как это правильно называть (Рис.3) С возможностью, ее скрыть, конечно. И мб даже с возможностью ходить с открытым инвентарем.
То же самое сделать и с экраном анатомии. Сделать его появление по нажатию на портрет в правом углу худа, и отцепить от него слоты экипировки, повестив их слева от инвентаря.По факту этот анатомический экран нужен только для того чтобы смотреть насколько конкретно ты задамажен, хилить конкретные части тела и смотреть на каких из них висят эффекты. С инвентарем и экипировкой это все никак не связано.
Так же такое расположение позволит сделать отдельный экран подбора предметов с земли\ из контейнера, висящий например там где сейчас скилы. Или вертикальным списком как и инвентарь, но справа.
С быстрыми действиями я вроде разобрался.
Наводишь курсор - видишь описание.
Жмешь пкм - видишь доступные действия.
Жмешь два раза - предмет идет в руку.
После этого я занялся переработкой самих слотов. Вообще система инвентаря была самой архаичной частью игры я написал ее полтора года назад по гайду с ютуба. Тогда я естественно вообще не думал о том подходит она мне или нет, так как сделать даже это мне было сложно.
Теперь я хочу чтобы инвентарь выполнял следующие задачи:
- Решал проблему стаков, когда у тебя все завалено кучей костей.
- Был бесконечным.
- Чтобы все еще можно было таскать предметы мышкой. Я считаю что это должно остаться для того чтобы экипировать разные предметы в разные слоты. По крайней мере остальные варианты как это делать сейчас выглядят не очень.
Я придумал следующее:
У тебя есть вертикальный спиок всех стаков предметов. (рис.1)
По идее там еще должен быть ползунок сбоку который все это будет прокручивать. А над списком кнопки для сортировки.
У стака есть "заглавный слот" отображающийся рядом с названием. Взаимодействуя с ним можно совершать действия с верхним предметом из стопки.
Если ты просто хочешь съесть кусок гриба то тебе не важно какой конкретно это кусок. Жмешь на стопку сьесть и ешь верхний. Или перетаскиваешь в руку, тогда тоже перетаскивается верхний кусок.
При этом ты можешь нажать на стопку и тогда под ней отобразятся все конкретные лежащие в ней предметы.(Рис.2)
Их тоже можно перетаскивать и.т.д.
Но и тут есть несколько неясных моментов.
Теперь стопки это строки списка. Сделать стопки сеткой как до этого были слоты нельзя, так как тогда непонятно, куда они будут раскрываться.
Таким образом там где название стопки куча неиспользуемого места. Что с ним делать? Статы там размещать я не хочу, это перегружает и для них отдельное окно есть.
Чтобы этого избежать можно пойти радикальным путем и вообще сделать инвентарь частью HUDа я хз как это правильно называть (Рис.3) С возможностью, ее скрыть, конечно. И мб даже с возможностью ходить с открытым инвентарем.
То же самое сделать и с экраном анатомии. Сделать его появление по нажатию на портрет в правом углу худа, и отцепить от него слоты экипировки, повестив их слева от инвентаря.По факту этот анатомический экран нужен только для того чтобы смотреть насколько конкретно ты задамажен, хилить конкретные части тела и смотреть на каких из них висят эффекты. С инвентарем и экипировкой это все никак не связано.
Так же такое расположение позволит сделать отдельный экран подбора предметов с земли\ из контейнера, висящий например там где сейчас скилы. Или вертикальным списком как и инвентарь, но справа.
Наводишь курсор - видишь описание.
Жмешь пкм - видишь доступные действия.
Жмешь два раза - предмет идет в руку.
После этого я занялся переработкой самих слотов. Вообще система инвентаря была самой архаичной частью игры я написал ее полтора года назад по гайду с ютуба. Тогда я естественно вообще не думал о том подходит она мне или нет, так как сделать даже это мне было сложно.
Теперь я хочу чтобы инвентарь выполнял следующие задачи:
- Решал проблему стаков, когда у тебя все завалено кучей костей.
- Был бесконечным.
- Чтобы все еще можно было таскать предметы мышкой. Я считаю что это должно остаться для того чтобы экипировать разные предметы в разные слоты. По крайней мере остальные варианты как это делать сейчас выглядят не очень.
Я придумал следующее:
У тебя есть вертикальный спиок всех стаков предметов. (рис.1)
По идее там еще должен быть ползунок сбоку который все это будет прокручивать. А над списком кнопки для сортировки.
У стака есть "заглавный слот" отображающийся рядом с названием. Взаимодействуя с ним можно совершать действия с верхним предметом из стопки.
Если ты просто хочешь съесть кусок гриба то тебе не важно какой конкретно это кусок. Жмешь на стопку сьесть и ешь верхний. Или перетаскиваешь в руку, тогда тоже перетаскивается верхний кусок.
При этом ты можешь нажать на стопку и тогда под ней отобразятся все конкретные лежащие в ней предметы.(Рис.2)
Их тоже можно перетаскивать и.т.д.
Но и тут есть несколько неясных моментов.
Теперь стопки это строки списка. Сделать стопки сеткой как до этого были слоты нельзя, так как тогда непонятно, куда они будут раскрываться.
Таким образом там где название стопки куча неиспользуемого места. Что с ним делать? Статы там размещать я не хочу, это перегружает и для них отдельное окно есть.
Чтобы этого избежать можно пойти радикальным путем и вообще сделать инвентарь частью HUDа я хз как это правильно называть (Рис.3) С возможностью, ее скрыть, конечно. И мб даже с возможностью ходить с открытым инвентарем.
То же самое сделать и с экраном анатомии. Сделать его появление по нажатию на портрет в правом углу худа, и отцепить от него слоты экипировки, повестив их слева от инвентаря.По факту этот анатомический экран нужен только для того чтобы смотреть насколько конкретно ты задамажен, хилить конкретные части тела и смотреть на каких из них висят эффекты. С инвентарем и экипировкой это все никак не связано.
Так же такое расположение позволит сделать отдельный экран подбора предметов с земли\ из контейнера, висящий например там где сейчас скилы. Или вертикальным списком как и инвентарь, но справа.
456 Кб, 1619x911Третий день UI кранча.
Я переделал инвентарь, так что теперь он занимает только часть экрана. Как я уже говорил, все предметы сгруппированы в стопки по типам. Жмешь на стоку, она разворачивается и показывает конкретное содержимое. Ну и его можно прокручивать.
Предметы можно экипировать двойным кликом, или перетаскиванием, а если перетащить на пустое место то предмет дропается.
При этом, инвентарь не блокирует управление, игрок может ходить с открытым инвентарем.
И наконец, теперь можно нажать хоткей и просмотреть все предметы, лежащие под ногами или заглянуть в контейнер.
Тогда открывается еще один список, только справа, отображающий содержимое контейнера или предметы на полу. В такой ситуации по двойному клику предметы перемещаются из контейнера в инвентарь и обратно.
Что делать дальше?
Все элементы с которыми можно повзаимодействовать нужно снабдить тултипами. Ну, в тех местах где это не совсем интуитивно. Наводишь курсор - появляется подсказка о том что это такое. И пусть тогда хоть один игрок не догадается что зеленый портрет справа отображает хп. Уууу только попробуй!
Хотя, если разобраться, большинство таких элементов связано именно с экраном анатомии или со статами, где нужно понимать что за что отвечает. Остальное не должно вызывать вопросов.
В этом обновлении я хочу довести UI до действительно хорошего уровня, чтобы потом долгое время можно было не возвращаться к нему. Вроде все пожелания игроков по этому поводу я учел, если есть еще какие-то идеи - пишите.
Я переделал инвентарь, так что теперь он занимает только часть экрана. Как я уже говорил, все предметы сгруппированы в стопки по типам. Жмешь на стоку, она разворачивается и показывает конкретное содержимое. Ну и его можно прокручивать.
Предметы можно экипировать двойным кликом, или перетаскиванием, а если перетащить на пустое место то предмет дропается.
При этом, инвентарь не блокирует управление, игрок может ходить с открытым инвентарем.
И наконец, теперь можно нажать хоткей и просмотреть все предметы, лежащие под ногами или заглянуть в контейнер.
Тогда открывается еще один список, только справа, отображающий содержимое контейнера или предметы на полу. В такой ситуации по двойному клику предметы перемещаются из контейнера в инвентарь и обратно.
Что делать дальше?
Все элементы с которыми можно повзаимодействовать нужно снабдить тултипами. Ну, в тех местах где это не совсем интуитивно. Наводишь курсор - появляется подсказка о том что это такое. И пусть тогда хоть один игрок не догадается что зеленый портрет справа отображает хп. Уууу только попробуй!
Хотя, если разобраться, большинство таких элементов связано именно с экраном анатомии или со статами, где нужно понимать что за что отвечает. Остальное не должно вызывать вопросов.
В этом обновлении я хочу довести UI до действительно хорошего уровня, чтобы потом долгое время можно было не возвращаться к нему. Вроде все пожелания игроков по этому поводу я учел, если есть еще какие-то идеи - пишите.
>>844243
Даже если догадается, то удобнее и понятнее от этого эта фигня не станет
>И пусть тогда хоть один игрок не догадается что зеленый портрет справа отображает хп
Даже если догадается, то удобнее и понятнее от этого эта фигня не станет
>>844253
Ну а как это еще отобразить?
У персонажа н-ное количество частей тела и у каждой из них свое хп.
Игроку для выживания необходимо знать насколько в относительных значениях какая часть тела задамажена. Следовательно это должно отображаться в худе.
Игрок видит в углу изображение своего персонажа и при получении урона части тела из зеленого становятся красными. Как вообще можно не понять что это?
Мне, типо, вместо этого таблицу из 4 хп-полосок сделать?
Ну а как это еще отобразить?
У персонажа н-ное количество частей тела и у каждой из них свое хп.
Игроку для выживания необходимо знать насколько в относительных значениях какая часть тела задамажена. Следовательно это должно отображаться в худе.
Игрок видит в углу изображение своего персонажа и при получении урона части тела из зеленого становятся красными. Как вообще можно не понять что это?
Мне, типо, вместо этого таблицу из 4 хп-полосок сделать?
>>844259
1) Это выглядит уродливо. Очень уродливо. Персонаж на индикаторе выглядит грязно и стремно. Буквально каша из пикселей внутри контура и не вписывается в интерфейс, будто это тут для отладки.
2) По этому индикатору понятно только лишь получил ты урон или нет и то, если игрок все ж допер, что это. Как сильно ты ранен - хрен оценишь.
Да. Ещё и с цифрами. Буквально самое лучшее решение.Если так хочется визуально отобразить, то делай часть тела, по которой попали, прозрачнее. Все равно лучше будет
1) Это выглядит уродливо. Очень уродливо. Персонаж на индикаторе выглядит грязно и стремно. Буквально каша из пикселей внутри контура и не вписывается в интерфейс, будто это тут для отладки.
2) По этому индикатору понятно только лишь получил ты урон или нет и то, если игрок все ж допер, что это. Как сильно ты ранен - хрен оценишь.
>Мне, типо, вместо этого таблицу из 4 хп-полосок сделать?
Да. Ещё и с цифрами. Буквально самое лучшее решение.Если так хочется визуально отобразить, то делай часть тела, по которой попали, прозрачнее. Все равно лучше будет
>>844304
Поддерживаю этого. Опу респект и зависть за интересный проект.
Поддерживаю этого. Опу респект и зависть за интересный проект.
>>844275
По поводу графического исполнения, месиво пикселей действительно имеет место, мне этот эффект показался забавным, но да, многих может раздражать. Мб имеет смысл сделать отображение более чистым.
Ты понимаешь, что когда говорят "интерфейс похож на панель управления космолета" это, как бы, не комплимент а наоборот?
Единственное, что игроку нужно знать от худа в течении каждого хода это, грубо говоря, в каком он находится положении из трех возможных: здоровый/ можно полечиться/ща сдохну.
Если он хочет узнать какую-то дополнительную инфу он может открыть полноценный экран со статами и там все это прочитать уже в виде цифр, полосок, таблиц, и т. д. Видеть все это каждый ход ему абсолютно не за чем.
да ты троллишь меня что-ли?
>>844427
Ну вот, да, я примерно так и хочу сделать. Правда, я все-таки хотел бы оставить возможность играть за персонажей с разным строением тела, так что единый красивый скелет для всех нарисовать не получится. Картинка в любом случае должна как-то процедурно создаваться на основе спрайтов выбранного перса.
-Оп
По поводу графического исполнения, месиво пикселей действительно имеет место, мне этот эффект показался забавным, но да, многих может раздражать. Мб имеет смысл сделать отображение более чистым.
>Да. Ещё и с цифрами.
Ты понимаешь, что когда говорят "интерфейс похож на панель управления космолета" это, как бы, не комплимент а наоборот?
Единственное, что игроку нужно знать от худа в течении каждого хода это, грубо говоря, в каком он находится положении из трех возможных: здоровый/ можно полечиться/ща сдохну.
Если он хочет узнать какую-то дополнительную инфу он может открыть полноценный экран со статами и там все это прочитать уже в виде цифр, полосок, таблиц, и т. д. Видеть все это каждый ход ему абсолютно не за чем.
>делай часть тела, по которой попали, прозрачнее
да ты троллишь меня что-ли?
>>844427
Ну вот, да, я примерно так и хочу сделать. Правда, я все-таки хотел бы оставить возможность играть за персонажей с разным строением тела, так что единый красивый скелет для всех нарисовать не получится. Картинка в любом случае должна как-то процедурно создаваться на основе спрайтов выбранного перса.
-Оп
>>796015 (OP)
А как вы сделали частицы с цифрами? Просто я только частицы крови, пыли, и стандартный текст могу.
А как вы сделали частицы с цифрами? Просто я только частицы крови, пыли, и стандартный текст могу.
>>845093
Это ты про вылетающие цифры урона?
Так это не частицы, это спавнится берется из пулла объект с текстом, а на нем висит аниматор, который его двигает.
-Оп
Это ты про вылетающие цифры урона?
Так это не частицы, это спавнится берется из пулла объект с текстом, а на нем висит аниматор, который его двигает.
-Оп
Запостил вчера новый билд.
https://vk.com/katabasys?w=wall-201941833_106
Там новый инвентарь, тултипы, скиллы и всякое другое.
Не удалось только ввести механику порчи еды, так как эффект гниения был сделан через шейдер, а выяснилось что юнити не может нормально отображать шейдеры в UI элементах. С 2021 года разработчики движка бьются над этой сложнейшей задачей, но пока, увы, современное развитие технологий не позволяет этого добиться. да не пойду я на Годот
https://vk.com/katabasys?w=wall-201941833_106
Там новый инвентарь, тултипы, скиллы и всякое другое.
Не удалось только ввести механику порчи еды, так как эффект гниения был сделан через шейдер, а выяснилось что юнити не может нормально отображать шейдеры в UI элементах. С 2021 года разработчики движка бьются над этой сложнейшей задачей, но пока, увы, современное развитие технологий не позволяет этого добиться. да не пойду я на Годот
3 Кб, 154x154Я хочу резюмировать очевидную проблему, более серьезную, чем плохой UI.
Дело в том, что в добавлении различных механик я, за недостатком опыта, руководствовался исключительно тем, как они будут выглядеть в отдельности без какой-либо связи с остальными. Как заметили участники треда это "разработка методом тыка", что не есть хорошо.
На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
По крайней мере, на них я потратил довольно много времени.
Проблема в том, что они существуют отдельно друг от друга и никак не связаны. При этом первая механика, с частями тела, не особо обыгрывается, в том плане, что это не сильно отличается от обычной полоски хп. То что части тела это реальные объекты с физикой и статами не имеет никакого геймплейного смысла. Вот, в последнем апдейте я добавил прицельные удары, чтобы можно было отрубить конкретную часть. Вроде это несколько исправляет положение.
По поводу отрядов, тут основная беда в том, что ничто в игре не подталкивает игрока этот отряд собирать. Игру можно пройти и не имея спутников. Большинство игроков скорее всего так и делают.
При этом, на данном этапе не достаточно просто сделать гг слабее, чтобы заставить его заняться сбором отряда. Если сделать так, то в какой-то момент, когда все спутники благополучно сольются, игрок останется один. И что ему тогда делать? Идти дальше он не может, так как слабый. Бесконечно найти себе новых спутников он тоже скорее всего не сможет, на данный момент их <10 штук во всем данже.
По мимо этого, есть еще куча других механик, слабо скомбинированных друг с другом.
Например, возможность подниматься по лестницам. Что игроку делать на верхних этажах? Мобы там не респавнятся. Единственное когда это нужно, это когда ты спустился на этаж, а там тебя прямо у входа встретили и побили, и ты позорно сваливаешь обратно по лестнице есть грибы.
Изначально я планировал что структура всего подземелья будет иметь элементы метроидвании, то есть на верхних этажах будут открываться развилки в какие-то локации в которые сначала игрок не может попасть. Дизайн мира в первом дарк соулсе мне кажется идеальным в этом плане.
Это решает проблему, но сколько же контента еще, получается, нужно пилить!
Можно еще много всего перечислять. Возьмем например прокачку. Это просто стандартная прокачка с повышением статов, как во всех играх. Связана ли она как-то с механикой анатомии? Нет. Связана ли она с отрядами? Тоже нет. Члены отряда никак не качаются.
Есть еще механика ключей и дверей. На каждом предмете может висеть замок с уникальным ключем. Это сейчас используется в магазине работорговца для открывания клеток с рабами, и больше нигде. А есть, при этом, механика полной разрушаемости, которая вообще ей противоречит. Да, получается, вместо того чтобы использовать ключ, любую запертую дверь ты можешь разломать кувалдой, а при желании вообще весь этаж сровнять.
А при этом из стен еще будут дропаться камни, как будто я в Dont Starve зашел. Тоже абсолютно бессмысленная фича.
Короче, все это печально, очень много всего нужно кардинально менять или выпиливать....
Дело в том, что в добавлении различных механик я, за недостатком опыта, руководствовался исключительно тем, как они будут выглядеть в отдельности без какой-либо связи с остальными. Как заметили участники треда это "разработка методом тыка", что не есть хорошо.
На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
По крайней мере, на них я потратил довольно много времени.
Проблема в том, что они существуют отдельно друг от друга и никак не связаны. При этом первая механика, с частями тела, не особо обыгрывается, в том плане, что это не сильно отличается от обычной полоски хп. То что части тела это реальные объекты с физикой и статами не имеет никакого геймплейного смысла. Вот, в последнем апдейте я добавил прицельные удары, чтобы можно было отрубить конкретную часть. Вроде это несколько исправляет положение.
По поводу отрядов, тут основная беда в том, что ничто в игре не подталкивает игрока этот отряд собирать. Игру можно пройти и не имея спутников. Большинство игроков скорее всего так и делают.
При этом, на данном этапе не достаточно просто сделать гг слабее, чтобы заставить его заняться сбором отряда. Если сделать так, то в какой-то момент, когда все спутники благополучно сольются, игрок останется один. И что ему тогда делать? Идти дальше он не может, так как слабый. Бесконечно найти себе новых спутников он тоже скорее всего не сможет, на данный момент их <10 штук во всем данже.
По мимо этого, есть еще куча других механик, слабо скомбинированных друг с другом.
Например, возможность подниматься по лестницам. Что игроку делать на верхних этажах? Мобы там не респавнятся. Единственное когда это нужно, это когда ты спустился на этаж, а там тебя прямо у входа встретили и побили, и ты позорно сваливаешь обратно по лестнице есть грибы.
Изначально я планировал что структура всего подземелья будет иметь элементы метроидвании, то есть на верхних этажах будут открываться развилки в какие-то локации в которые сначала игрок не может попасть. Дизайн мира в первом дарк соулсе мне кажется идеальным в этом плане.
Это решает проблему, но сколько же контента еще, получается, нужно пилить!
Можно еще много всего перечислять. Возьмем например прокачку. Это просто стандартная прокачка с повышением статов, как во всех играх. Связана ли она как-то с механикой анатомии? Нет. Связана ли она с отрядами? Тоже нет. Члены отряда никак не качаются.
Есть еще механика ключей и дверей. На каждом предмете может висеть замок с уникальным ключем. Это сейчас используется в магазине работорговца для открывания клеток с рабами, и больше нигде. А есть, при этом, механика полной разрушаемости, которая вообще ей противоречит. Да, получается, вместо того чтобы использовать ключ, любую запертую дверь ты можешь разломать кувалдой, а при желании вообще весь этаж сровнять.
А при этом из стен еще будут дропаться камни, как будто я в Dont Starve зашел. Тоже абсолютно бессмысленная фича.
Короче, все это печально, очень много всего нужно кардинально менять или выпиливать....
3 Кб, 154x154Я хочу резюмировать очевидную проблему, более серьезную, чем плохой UI.
Дело в том, что в добавлении различных механик я, за недостатком опыта, руководствовался исключительно тем, как они будут выглядеть в отдельности без какой-либо связи с остальными. Как заметили участники треда это "разработка методом тыка", что не есть хорошо.
На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
По крайней мере, на них я потратил довольно много времени.
Проблема в том, что они существуют отдельно друг от друга и никак не связаны. При этом первая механика, с частями тела, не особо обыгрывается, в том плане, что это не сильно отличается от обычной полоски хп. То что части тела это реальные объекты с физикой и статами не имеет никакого геймплейного смысла. Вот, в последнем апдейте я добавил прицельные удары, чтобы можно было отрубить конкретную часть. Вроде это несколько исправляет положение.
По поводу отрядов, тут основная беда в том, что ничто в игре не подталкивает игрока этот отряд собирать. Игру можно пройти и не имея спутников. Большинство игроков скорее всего так и делают.
При этом, на данном этапе не достаточно просто сделать гг слабее, чтобы заставить его заняться сбором отряда. Если сделать так, то в какой-то момент, когда все спутники благополучно сольются, игрок останется один. И что ему тогда делать? Идти дальше он не может, так как слабый. Бесконечно найти себе новых спутников он тоже скорее всего не сможет, на данный момент их <10 штук во всем данже.
По мимо этого, есть еще куча других механик, слабо скомбинированных друг с другом.
Например, возможность подниматься по лестницам. Что игроку делать на верхних этажах? Мобы там не респавнятся. Единственное когда это нужно, это когда ты спустился на этаж, а там тебя прямо у входа встретили и побили, и ты позорно сваливаешь обратно по лестнице есть грибы.
Изначально я планировал что структура всего подземелья будет иметь элементы метроидвании, то есть на верхних этажах будут открываться развилки в какие-то локации в которые сначала игрок не может попасть. Дизайн мира в первом дарк соулсе мне кажется идеальным в этом плане.
Это решает проблему, но сколько же контента еще, получается, нужно пилить!
Можно еще много всего перечислять. Возьмем например прокачку. Это просто стандартная прокачка с повышением статов, как во всех играх. Связана ли она как-то с механикой анатомии? Нет. Связана ли она с отрядами? Тоже нет. Члены отряда никак не качаются.
Есть еще механика ключей и дверей. На каждом предмете может висеть замок с уникальным ключем. Это сейчас используется в магазине работорговца для открывания клеток с рабами, и больше нигде. А есть, при этом, механика полной разрушаемости, которая вообще ей противоречит. Да, получается, вместо того чтобы использовать ключ, любую запертую дверь ты можешь разломать кувалдой, а при желании вообще весь этаж сровнять.
А при этом из стен еще будут дропаться камни, как будто я в Dont Starve зашел. Тоже абсолютно бессмысленная фича.
Короче, все это печально, очень много всего нужно кардинально менять или выпиливать....
Дело в том, что в добавлении различных механик я, за недостатком опыта, руководствовался исключительно тем, как они будут выглядеть в отдельности без какой-либо связи с остальными. Как заметили участники треда это "разработка методом тыка", что не есть хорошо.
На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
По крайней мере, на них я потратил довольно много времени.
Проблема в том, что они существуют отдельно друг от друга и никак не связаны. При этом первая механика, с частями тела, не особо обыгрывается, в том плане, что это не сильно отличается от обычной полоски хп. То что части тела это реальные объекты с физикой и статами не имеет никакого геймплейного смысла. Вот, в последнем апдейте я добавил прицельные удары, чтобы можно было отрубить конкретную часть. Вроде это несколько исправляет положение.
По поводу отрядов, тут основная беда в том, что ничто в игре не подталкивает игрока этот отряд собирать. Игру можно пройти и не имея спутников. Большинство игроков скорее всего так и делают.
При этом, на данном этапе не достаточно просто сделать гг слабее, чтобы заставить его заняться сбором отряда. Если сделать так, то в какой-то момент, когда все спутники благополучно сольются, игрок останется один. И что ему тогда делать? Идти дальше он не может, так как слабый. Бесконечно найти себе новых спутников он тоже скорее всего не сможет, на данный момент их <10 штук во всем данже.
По мимо этого, есть еще куча других механик, слабо скомбинированных друг с другом.
Например, возможность подниматься по лестницам. Что игроку делать на верхних этажах? Мобы там не респавнятся. Единственное когда это нужно, это когда ты спустился на этаж, а там тебя прямо у входа встретили и побили, и ты позорно сваливаешь обратно по лестнице есть грибы.
Изначально я планировал что структура всего подземелья будет иметь элементы метроидвании, то есть на верхних этажах будут открываться развилки в какие-то локации в которые сначала игрок не может попасть. Дизайн мира в первом дарк соулсе мне кажется идеальным в этом плане.
Это решает проблему, но сколько же контента еще, получается, нужно пилить!
Можно еще много всего перечислять. Возьмем например прокачку. Это просто стандартная прокачка с повышением статов, как во всех играх. Связана ли она как-то с механикой анатомии? Нет. Связана ли она с отрядами? Тоже нет. Члены отряда никак не качаются.
Есть еще механика ключей и дверей. На каждом предмете может висеть замок с уникальным ключем. Это сейчас используется в магазине работорговца для открывания клеток с рабами, и больше нигде. А есть, при этом, механика полной разрушаемости, которая вообще ей противоречит. Да, получается, вместо того чтобы использовать ключ, любую запертую дверь ты можешь разломать кувалдой, а при желании вообще весь этаж сровнять.
А при этом из стен еще будут дропаться камни, как будто я в Dont Starve зашел. Тоже абсолютно бессмысленная фича.
Короче, все это печально, очень много всего нужно кардинально менять или выпиливать....
>>845898
Справедливости ради, в годоте с шейдерами гуя тоже какая-то проблема, не помню точно что, то ли накладывать друг на друга сложно, то не у всех элементов есть
Справедливости ради, в годоте с шейдерами гуя тоже какая-то проблема, не помню точно что, то ли накладывать друг на друга сложно, то не у всех элементов есть
>>845906
Нормальные механики, не стоит выпиливать, стоит их просто верно подать.
Нормальные механики, не стоит выпиливать, стоит их просто верно подать.
336 Кб, 320x562Для исправление сложившейся ситуации я придумал следующее.
1. Сейчас чтобы восстановить утраченную часть тела нужно есть. Это какой-то костыль.
Вместо этого нужно заставить игрока подбирать ее с пола и пришивать обратно. Это придаст какой-то смысл тому что все эти части валяются по полу.
На данный момент, вероятность того что тебе не просто оторвет руку а именно полностью ее уничтожит довольно мала. "Смертельный" урон проходящий по прикрепленной части тела всегда отрывает ее вместо того чтобы уничтожить, так что для полного уничтожения нужны специфические условия.
Тем не менее, это все равно возможно, так что способ восстановить конечность "из ничего" все-таки нужно оставить, но сделать его более дорогим.
2. Если у игрока есть спутник и он умирает, то он умирает.
Я считаю, что нужна возможность воскрешать спутников. Для этого нужно вынести с поля боя его отрубленную голову и произвести с ней некоторые манипуляции. Отнести в специальное место? Провести ритуал с костями как на старой гифке? (гифрелейтед) Опять же, я запилил эту тему с кругом из костей хрен знает когда, а нормального применения ему так и не нашел
3. Есть еще довольно радикальная мысль, взять то что в пункте 1 и сделать так, что сам себе пришить конечность ты не можешь, для этого нужен союзник. Ох, это то точно превратит отряды в кор-механику. Но, конечно, пока выглядит как жесть какая-то.
1. Сейчас чтобы восстановить утраченную часть тела нужно есть. Это какой-то костыль.
Вместо этого нужно заставить игрока подбирать ее с пола и пришивать обратно. Это придаст какой-то смысл тому что все эти части валяются по полу.
На данный момент, вероятность того что тебе не просто оторвет руку а именно полностью ее уничтожит довольно мала. "Смертельный" урон проходящий по прикрепленной части тела всегда отрывает ее вместо того чтобы уничтожить, так что для полного уничтожения нужны специфические условия.
Тем не менее, это все равно возможно, так что способ восстановить конечность "из ничего" все-таки нужно оставить, но сделать его более дорогим.
2. Если у игрока есть спутник и он умирает, то он умирает.
Я считаю, что нужна возможность воскрешать спутников. Для этого нужно вынести с поля боя его отрубленную голову и произвести с ней некоторые манипуляции. Отнести в специальное место? Провести ритуал с костями как на старой гифке? (гифрелейтед) Опять же, я запилил эту тему с кругом из костей хрен знает когда, а нормального применения ему так и не нашел
3. Есть еще довольно радикальная мысль, взять то что в пункте 1 и сделать так, что сам себе пришить конечность ты не можешь, для этого нужен союзник. Ох, это то точно превратит отряды в кор-механику. Но, конечно, пока выглядит как жесть какая-то.
>>845906
Ночью приснися геймплей, что вся группа безногих и безруких и они компенсируют недостатки друг друга.
Ночью приснися геймплей, что вся группа безногих и безруких и они компенсируют недостатки друг друга.
>>845989
Сделай создание спутников из отрубленных конечностей своих и врагов. Типо положил 4 ноги 2 головы, и 3 руки - получи нахуй здарова ебать. Идем на прааааавооо - нееет, на лееееевоо. Или спутник с 4мя руками в которых сразу лук меч щит или типо того
Сделай создание спутников из отрубленных конечностей своих и врагов. Типо положил 4 ноги 2 головы, и 3 руки - получи нахуй здарова ебать. Идем на прааааавооо - нееет, на лееееевоо. Или спутник с 4мя руками в которых сразу лук меч щит или типо того
>>845989
Можно перки на конечности раскидать. типа стратуешь с одним рандомным перком на каждой конечности. Положительный или отрицательный, как повезет. Съел вражескую конечность, повесил с нее перк себе, причем тоже не известно, что это будет.
Можно перки на конечности раскидать. типа стратуешь с одним рандомным перком на каждой конечности. Положительный или отрицательный, как повезет. Съел вражескую конечность, повесил с нее перк себе, причем тоже не известно, что это будет.
>>846030
Можно сделать алтари, который из чужих конечностей будут восстанавливать свою, не 1 к 1 конечно. Или торговца какого-то мифологического сделать, который за обрубки будет что-то продавать.
Можно сделать алтари, который из чужих конечностей будут восстанавливать свою, не 1 к 1 конечно. Или торговца какого-то мифологического сделать, который за обрубки будет что-то продавать.
>>845989
Вообще, когда речь заходит в рогаликах или в песочницах об отрядах очень часто разрабы допускают как мне кажется ключевую ошибку в их дизайне, из-за чего начинается душка со сейв скамом. Примеры: смерть незаменимой пешки в римке или смерть спутника в маунте блейде 2. Проблема тут в том, что ошибки игрока всегда должны наказываться, но такие ошибки наказываются слишком сильно. Ты десятки часов качаешь своего спутника/пешку и потом рандом шот или еще что-то и ты уже никак не можешь в течение ближайшего времени вернуть потерю.
Поэтому согласен с твоими мыслями выше, что можно сделать допустим душу героя, которая остается на месте смерти твоего спутника и если собрать для него новое тело и потом вдохнуть душу через тотем то ты его вернешь к жизни. С потерей 10% прокачки, чтобы было небольшое доп наказание.
Так же окончательно советую определиться, что ты хочешь сделать рогалик в котором отряд просто является условным бустером 20% к твоему дамагу или реально боевые единицы. Если второе то, как мне кажется тебе нужно доделать|переделать так чтобы твой герой мог вытянуть бой 1в3, но дальше он просто не имеет возможности в одиночку воевать. Короче приземлить по силе героя к местной фауне.
Вообще, когда речь заходит в рогаликах или в песочницах об отрядах очень часто разрабы допускают как мне кажется ключевую ошибку в их дизайне, из-за чего начинается душка со сейв скамом. Примеры: смерть незаменимой пешки в римке или смерть спутника в маунте блейде 2. Проблема тут в том, что ошибки игрока всегда должны наказываться, но такие ошибки наказываются слишком сильно. Ты десятки часов качаешь своего спутника/пешку и потом рандом шот или еще что-то и ты уже никак не можешь в течение ближайшего времени вернуть потерю.
Поэтому согласен с твоими мыслями выше, что можно сделать допустим душу героя, которая остается на месте смерти твоего спутника и если собрать для него новое тело и потом вдохнуть душу через тотем то ты его вернешь к жизни. С потерей 10% прокачки, чтобы было небольшое доп наказание.
Так же окончательно советую определиться, что ты хочешь сделать рогалик в котором отряд просто является условным бустером 20% к твоему дамагу или реально боевые единицы. Если второе то, как мне кажется тебе нужно доделать|переделать так чтобы твой герой мог вытянуть бой 1в3, но дальше он просто не имеет возможности в одиночку воевать. Короче приземлить по силе героя к местной фауне.
>>845997
>>846023
>>846029
>>846030
>>846032
>>846033
Ну и сны у тебя)
Раньше у меня была техническая возможность делать в игре существ с произвольным числом произвольных конечностей, но от нее мне пришлось отказаться в виду некоторых технических ограничений и того что это все очень тяжело отобразить графически.
Но просто добавить кому-нибудь вторую пару рук - почему бы и нет.
- Оп
>>846023
>>846029
>>846030
>>846032
>>846033
Ну и сны у тебя)
Раньше у меня была техническая возможность делать в игре существ с произвольным числом произвольных конечностей, но от нее мне пришлось отказаться в виду некоторых технических ограничений и того что это все очень тяжело отобразить графически.
Но просто добавить кому-нибудь вторую пару рук - почему бы и нет.
- Оп
>>846125
А всего-то и нужно что ПРОСТО не давать спутнику погибать от рандомного попадания или "ещё чего-то". В некоторых многопользовательских играх товарищей можно поднимать на ноги неограниченное количество раз. Да, ты тратишь время и рискуешь жизнью, но вы можете продолжать игру. В одиночных играх враги могут просто фокусироваться на игроке и в основном игнорировать его союзников, либо у союзников может быть подкручена живучесть/удача значительно выше, чем у игрока. Т.е. ты просто компенсируешь тупость ИИ параметрами его персонажа и этого оказывается достаточно. Ну а если хочешь честную симуляцию, где игрок и NPC полностью равны, тогда придётся делать союзникам нормальный ИИ, который не позволит им слишком рисковать и лезть туда, где их гарантированно убьёт. Впрочем, игра с внезапной смертью кого угодно - полная фигня, так что если у тебя союзники внезапно дохнут - нужно не союзников чинить, а игру в целом.
>Ты десятки часов качаешь своего спутника/пешку и потом рандом шот или еще что-то и ты уже никак не можешь
А всего-то и нужно что ПРОСТО не давать спутнику погибать от рандомного попадания или "ещё чего-то". В некоторых многопользовательских играх товарищей можно поднимать на ноги неограниченное количество раз. Да, ты тратишь время и рискуешь жизнью, но вы можете продолжать игру. В одиночных играх враги могут просто фокусироваться на игроке и в основном игнорировать его союзников, либо у союзников может быть подкручена живучесть/удача значительно выше, чем у игрока. Т.е. ты просто компенсируешь тупость ИИ параметрами его персонажа и этого оказывается достаточно. Ну а если хочешь честную симуляцию, где игрок и NPC полностью равны, тогда придётся делать союзникам нормальный ИИ, который не позволит им слишком рисковать и лезть туда, где их гарантированно убьёт. Впрочем, игра с внезапной смертью кого угодно - полная фигня, так что если у тебя союзники внезапно дохнут - нужно не союзников чинить, а игру в целом.
>>845906
Не рассматривал идею переделать свой "рогалик" в нечто более близкое RimWorld? Т.е. вместо задачи "пройти до самого дна подземелья, не умерев" перед игроком ставится задача "развивать колонию в подземелье, чтобы она выжила как можно дольше".
Смотри:
1. Продвинутая система частей тела у тебя уже есть, осталось накрутить болезни, более реалистичное лечение, протезирование и т.п.
2. Система отрядов у тебя уже есть (хотя я и не смог её испытать), значит, можно сформировать нечто вроде колонии, раздавая приказы своим союзникам.
3. Ландшафт у тебя полностью редактируемый, то есть ничто не мешает добавить механику строительства, чтобы игрок мог строить и развивать базу, или хотя бы домики для своих персонажей с минимально необходимыми удобствами.
4. Кусочки мяса и костей обретут новый смысл. Мясо можно будет жарить на кострах и засаливать на будущее, а из костей крайфтить оружие, инструменты и прочее необходимое для выживания.
5. Свободное передвижение по этажам тут как нельзя кстати, только нижние этажи должны быть куда опаснее и агрессивнее. Думаю, легко позволить игроку прокапывать свои ходы вниз/вверх, чтобы подходить к освоению следующих этажей эффективнее.
6. Т.к. мы уже в пещерах, легко добавить какие-то руды, чтобы добывать металл для продвинутых построек.
7. Т.к. мы в фэнтези сеттинге, не вижу проблемы спамить каких-то жутких существ, от которых база игрока должна обороняться. При продвижении вниз волны усиливаются, но обустройство базы позволяет "очистить" этаж, сделав его более цивилизованным и безопасным.
8. Конечной цели нет, ты просто развиваешь базу и стараешься сохранить её как можно дольше. Это очень большая жанровая ниша с кучей игроков, мне кажется, куда большей, чем у классических рогаликов.
Единственный нюанс - тебе придётся пересмотреть пошаговость игры. Сейчас время идёт только когда игрок делает действие, но для симулятора колонии будет лучше иметь возможность играть в реальном времени, ставя игру на паузу по желанию. Т.е. игрок следит за развитием событий в реальном времени, ставит игру на паузу в случае необходимости и раздаёт новую пачку приказов своим юнитам, затем снимает игру с паузы и смотрит за тем, как его приказы повлияли на ход событий. Это типичная схема управления для подобных игр, она не навязывает ни жёсткую пошаговость, ни принуждает делать всё исключительно в реальном времени - идеальный баланс.
Конечно, тебе придётся серьёзно озаботиться оптимизацией, чтобы симуляция всего подземелья могла плавно идти в реальном времени. Но это возможно, так что ты наверняка справишься.
разработчик Скотобазы, слишком быстро потерявший интерес к созданию очередного банального рогалика
>На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
>По крайней мере, на них я потратил довольно много времени.
Не рассматривал идею переделать свой "рогалик" в нечто более близкое RimWorld? Т.е. вместо задачи "пройти до самого дна подземелья, не умерев" перед игроком ставится задача "развивать колонию в подземелье, чтобы она выжила как можно дольше".
Смотри:
1. Продвинутая система частей тела у тебя уже есть, осталось накрутить болезни, более реалистичное лечение, протезирование и т.п.
2. Система отрядов у тебя уже есть (хотя я и не смог её испытать), значит, можно сформировать нечто вроде колонии, раздавая приказы своим союзникам.
3. Ландшафт у тебя полностью редактируемый, то есть ничто не мешает добавить механику строительства, чтобы игрок мог строить и развивать базу, или хотя бы домики для своих персонажей с минимально необходимыми удобствами.
4. Кусочки мяса и костей обретут новый смысл. Мясо можно будет жарить на кострах и засаливать на будущее, а из костей крайфтить оружие, инструменты и прочее необходимое для выживания.
5. Свободное передвижение по этажам тут как нельзя кстати, только нижние этажи должны быть куда опаснее и агрессивнее. Думаю, легко позволить игроку прокапывать свои ходы вниз/вверх, чтобы подходить к освоению следующих этажей эффективнее.
6. Т.к. мы уже в пещерах, легко добавить какие-то руды, чтобы добывать металл для продвинутых построек.
7. Т.к. мы в фэнтези сеттинге, не вижу проблемы спамить каких-то жутких существ, от которых база игрока должна обороняться. При продвижении вниз волны усиливаются, но обустройство базы позволяет "очистить" этаж, сделав его более цивилизованным и безопасным.
8. Конечной цели нет, ты просто развиваешь базу и стараешься сохранить её как можно дольше. Это очень большая жанровая ниша с кучей игроков, мне кажется, куда большей, чем у классических рогаликов.
Единственный нюанс - тебе придётся пересмотреть пошаговость игры. Сейчас время идёт только когда игрок делает действие, но для симулятора колонии будет лучше иметь возможность играть в реальном времени, ставя игру на паузу по желанию. Т.е. игрок следит за развитием событий в реальном времени, ставит игру на паузу в случае необходимости и раздаёт новую пачку приказов своим юнитам, затем снимает игру с паузы и смотрит за тем, как его приказы повлияли на ход событий. Это типичная схема управления для подобных игр, она не навязывает ни жёсткую пошаговость, ни принуждает делать всё исключительно в реальном времени - идеальный баланс.
Конечно, тебе придётся серьёзно озаботиться оптимизацией, чтобы симуляция всего подземелья могла плавно идти в реальном времени. Но это возможно, так что ты наверняка справишься.
разработчик Скотобазы, слишком быстро потерявший интерес к созданию очередного банального рогалика
>>845906
Не рассматривал идею переделать свой "рогалик" в нечто более близкое RimWorld? Т.е. вместо задачи "пройти до самого дна подземелья, не умерев" перед игроком ставится задача "развивать колонию в подземелье, чтобы она выжила как можно дольше".
Смотри:
1. Продвинутая система частей тела у тебя уже есть, осталось накрутить болезни, более реалистичное лечение, протезирование и т.п.
2. Система отрядов у тебя уже есть (хотя я и не смог её испытать), значит, можно сформировать нечто вроде колонии, раздавая приказы своим союзникам.
3. Ландшафт у тебя полностью редактируемый, то есть ничто не мешает добавить механику строительства, чтобы игрок мог строить и развивать базу, или хотя бы домики для своих персонажей с минимально необходимыми удобствами.
4. Кусочки мяса и костей обретут новый смысл. Мясо можно будет жарить на кострах и засаливать на будущее, а из костей крайфтить оружие, инструменты и прочее необходимое для выживания.
5. Свободное передвижение по этажам тут как нельзя кстати, только нижние этажи должны быть куда опаснее и агрессивнее. Думаю, легко позволить игроку прокапывать свои ходы вниз/вверх, чтобы подходить к освоению следующих этажей эффективнее.
6. Т.к. мы уже в пещерах, легко добавить какие-то руды, чтобы добывать металл для продвинутых построек.
7. Т.к. мы в фэнтези сеттинге, не вижу проблемы спамить каких-то жутких существ, от которых база игрока должна обороняться. При продвижении вниз волны усиливаются, но обустройство базы позволяет "очистить" этаж, сделав его более цивилизованным и безопасным.
8. Конечной цели нет, ты просто развиваешь базу и стараешься сохранить её как можно дольше. Это очень большая жанровая ниша с кучей игроков, мне кажется, куда большей, чем у классических рогаликов.
Единственный нюанс - тебе придётся пересмотреть пошаговость игры. Сейчас время идёт только когда игрок делает действие, но для симулятора колонии будет лучше иметь возможность играть в реальном времени, ставя игру на паузу по желанию. Т.е. игрок следит за развитием событий в реальном времени, ставит игру на паузу в случае необходимости и раздаёт новую пачку приказов своим юнитам, затем снимает игру с паузы и смотрит за тем, как его приказы повлияли на ход событий. Это типичная схема управления для подобных игр, она не навязывает ни жёсткую пошаговость, ни принуждает делать всё исключительно в реальном времени - идеальный баланс.
Конечно, тебе придётся серьёзно озаботиться оптимизацией, чтобы симуляция всего подземелья могла плавно идти в реальном времени. Но это возможно, так что ты наверняка справишься.
разработчик Скотобазы, слишком быстро потерявший интерес к созданию очередного банального рогалика
>На данный момент в игре две механики, выходящие за рамки стандартного рогалик-набора, которые я бы назвал основными. Это локализованный урон и отряды.
>По крайней мере, на них я потратил довольно много времени.
Не рассматривал идею переделать свой "рогалик" в нечто более близкое RimWorld? Т.е. вместо задачи "пройти до самого дна подземелья, не умерев" перед игроком ставится задача "развивать колонию в подземелье, чтобы она выжила как можно дольше".
Смотри:
1. Продвинутая система частей тела у тебя уже есть, осталось накрутить болезни, более реалистичное лечение, протезирование и т.п.
2. Система отрядов у тебя уже есть (хотя я и не смог её испытать), значит, можно сформировать нечто вроде колонии, раздавая приказы своим союзникам.
3. Ландшафт у тебя полностью редактируемый, то есть ничто не мешает добавить механику строительства, чтобы игрок мог строить и развивать базу, или хотя бы домики для своих персонажей с минимально необходимыми удобствами.
4. Кусочки мяса и костей обретут новый смысл. Мясо можно будет жарить на кострах и засаливать на будущее, а из костей крайфтить оружие, инструменты и прочее необходимое для выживания.
5. Свободное передвижение по этажам тут как нельзя кстати, только нижние этажи должны быть куда опаснее и агрессивнее. Думаю, легко позволить игроку прокапывать свои ходы вниз/вверх, чтобы подходить к освоению следующих этажей эффективнее.
6. Т.к. мы уже в пещерах, легко добавить какие-то руды, чтобы добывать металл для продвинутых построек.
7. Т.к. мы в фэнтези сеттинге, не вижу проблемы спамить каких-то жутких существ, от которых база игрока должна обороняться. При продвижении вниз волны усиливаются, но обустройство базы позволяет "очистить" этаж, сделав его более цивилизованным и безопасным.
8. Конечной цели нет, ты просто развиваешь базу и стараешься сохранить её как можно дольше. Это очень большая жанровая ниша с кучей игроков, мне кажется, куда большей, чем у классических рогаликов.
Единственный нюанс - тебе придётся пересмотреть пошаговость игры. Сейчас время идёт только когда игрок делает действие, но для симулятора колонии будет лучше иметь возможность играть в реальном времени, ставя игру на паузу по желанию. Т.е. игрок следит за развитием событий в реальном времени, ставит игру на паузу в случае необходимости и раздаёт новую пачку приказов своим юнитам, затем снимает игру с паузы и смотрит за тем, как его приказы повлияли на ход событий. Это типичная схема управления для подобных игр, она не навязывает ни жёсткую пошаговость, ни принуждает делать всё исключительно в реальном времени - идеальный баланс.
Конечно, тебе придётся серьёзно озаботиться оптимизацией, чтобы симуляция всего подземелья могла плавно идти в реальном времени. Но это возможно, так что ты наверняка справишься.
разработчик Скотобазы, слишком быстро потерявший интерес к созданию очередного банального рогалика
>>849690
Эх, это пожалуй уж слишком радикально. Система отрядов это процентов 10 от того что нужно для превращения игры в подземный римворлд. На это еще несколько лет уйдет, я буду сидеть как разрабы дварф фортресса, но при этом в два раза дольше, так как их было двое, а я один.
Ну и к тому же, мне все-таки хочется сделать игру с хардкорной смертью. Геймплей состоит из забегов. Зашел, поиграл несколько часов, умер - все сначала. Мне принципиально нравится именно такой гемплей.
Поэтому, я, например, не хочу делать никакой метапрогрессии (ну всякие там бонусы сохраняющиеся между забегами или анлоки оружия)
А если там надо будет строить базу как в римворлде это будут катки уже по 30 часов. При этом, скорее всего, в таком случае смерть будет вызывать лютый рейдж и желание загрузиться.
Такой геймплей это конечно тоже круто, но все-таки совсем другая специфика. А если добавить немножко того, немножко того и сделать полу-стратегию полу-рогалик который тоже играется короткими забегами, но при этом с базой... пока я плохо представляю как сделать это гармонично и не зафейлить и чтобы это не был Cult of the Lamb с клеточками .
Я думаю, для этого нужно в разы больше опыта и желательно несколько человек команды.
Тем не менее, некоторые идеи кажутся мне неплохими.
Например про болезни.
Я бы не стал формулировать это именно таким образом, но механика при которой ты можешь как-то "зашкварить" какую-то свою часть, так что она будет приносить неудобства, ставящие перед выбором, сложно и дорого откатывать ее в прежнее состояние или вообще отрезать - звучит интересно.
Ну или про руды. Я раньше думал сделать таким образом фарм золота, но мб есть какие-то более разумные применения...
-Оп
Эх, это пожалуй уж слишком радикально. Система отрядов это процентов 10 от того что нужно для превращения игры в подземный римворлд. На это еще несколько лет уйдет, я буду сидеть как разрабы дварф фортресса, но при этом в два раза дольше, так как их было двое, а я один.
Ну и к тому же, мне все-таки хочется сделать игру с хардкорной смертью. Геймплей состоит из забегов. Зашел, поиграл несколько часов, умер - все сначала. Мне принципиально нравится именно такой гемплей.
Поэтому, я, например, не хочу делать никакой метапрогрессии (ну всякие там бонусы сохраняющиеся между забегами или анлоки оружия)
А если там надо будет строить базу как в римворлде это будут катки уже по 30 часов. При этом, скорее всего, в таком случае смерть будет вызывать лютый рейдж и желание загрузиться.
Такой геймплей это конечно тоже круто, но все-таки совсем другая специфика. А если добавить немножко того, немножко того и сделать полу-стратегию полу-рогалик который тоже играется короткими забегами, но при этом с базой... пока я плохо представляю как сделать это гармонично и не зафейлить и чтобы это не был Cult of the Lamb с клеточками .
Я думаю, для этого нужно в разы больше опыта и желательно несколько человек команды.
Тем не менее, некоторые идеи кажутся мне неплохими.
Например про болезни.
Я бы не стал формулировать это именно таким образом, но механика при которой ты можешь как-то "зашкварить" какую-то свою часть, так что она будет приносить неудобства, ставящие перед выбором, сложно и дорого откатывать ее в прежнее состояние или вообще отрезать - звучит интересно.
Ну или про руды. Я раньше думал сделать таким образом фарм золота, но мб есть какие-то более разумные применения...
-Оп
4 Кб, 309x163>>849690
- лучшее место для базы это грибной лес! Бесконечный фарм грибных ножек, только подумай!
- неееет! Базу нужно строить в центре подземного озера и разводить там донных ползунов! Имбо страта!
Хотелось бы мне, конечно, такое услышать. Но увы.
- Оп
- лучшее место для базы это грибной лес! Бесконечный фарм грибных ножек, только подумай!
- неееет! Базу нужно строить в центре подземного озера и разводить там донных ползунов! Имбо страта!
Хотелось бы мне, конечно, такое услышать. Но увы.
- Оп
Давно я, кстати, не постил ничего.
Вот, небольшое обновление запилил: https://vk.com/katabasys?w=wall-201941833_108%2Fall
"Теперь система морали оказывает больше влияния на игровой процесс. На низкой морали существа получают х2 бонус к скорости, и убегая начинают регенерировать, восстанавливая до 50% прочности своего тела.
Это определенно делает бои разнообразнее. Игрок не может догнать большинство убегающих существ, в результате чего, броски предметов теперь действительно имеют смысл. Так как убежавший моб вполне может отрегениться и вернуться, имеет смысл либо стараться добить противника за несколько сильных тычек, используя медленное оружие типо молота, чтобы он не успел испугаться, или, собственно, кидать что-то им вслед. По мимо этого, копья по идее тоже теперь имеют некоторый дополнительный смысл, за счет возможности тыкать на 2 клетки.
По крайней мере, так задумывалось. Как конкретно это балансить, у меня пока недостаточная выборка.
"
Вот, небольшое обновление запилил: https://vk.com/katabasys?w=wall-201941833_108%2Fall
"Теперь система морали оказывает больше влияния на игровой процесс. На низкой морали существа получают х2 бонус к скорости, и убегая начинают регенерировать, восстанавливая до 50% прочности своего тела.
Это определенно делает бои разнообразнее. Игрок не может догнать большинство убегающих существ, в результате чего, броски предметов теперь действительно имеют смысл. Так как убежавший моб вполне может отрегениться и вернуться, имеет смысл либо стараться добить противника за несколько сильных тычек, используя медленное оружие типо молота, чтобы он не успел испугаться, или, собственно, кидать что-то им вслед. По мимо этого, копья по идее тоже теперь имеют некоторый дополнительный смысл, за счет возможности тыкать на 2 клетки.
По крайней мере, так задумывалось. Как конкретно это балансить, у меня пока недостаточная выборка.
"
Анон, как дела? Я не верю, что ты забросишь проект. Один из немногих на доске, кто реально имеет успехи в деланье своего проекта.
>>858585
>>862208
>>863055
Ой, извините простите, нет тред не умер и я тоже не умер.
Просто мы тут с одним знакомым решили посмотреть, что там и как на рынке гиперказуального треша и решили запилить какой-нибудь небольшой проект под соответствующую платформу. Таким образом сейчас я доделываю нечто на замечательном портале убийце плеймаркетаYandex Games.
Проделанной работой я не особо горжусь, так что сюда, пожалуй кидать ее не буду. Тем не менее это был полезный опыт, я научился работать со всякими базами данных, аккаунтами и делать билды под WebGL. Могу сделать в катабазисе онлайновую таблицу рекордов, например. Надеюсь, что в перспективе запилы подобных проектов но нормальных способны принести мне даже какое-то количество денег.
К разработке рогалика я планирую вернуться в течении ближайших недель, но новый билд будет явно не скоро, так как работы много и судя по всему, нужно добавлять что-то типо древа навыков, чтобы наконец в игре появились билды и она нормально функционировала в роли рогалика. Пока у меня на этот счет только некоторые теоретические соображения, которые надо долго доводить до ума чтобы, собственно, начать что-то кодить.
-Оп
>>862208
>>863055
Ой, извините простите, нет тред не умер и я тоже не умер.
Просто мы тут с одним знакомым решили посмотреть, что там и как на рынке гиперказуального треша и решили запилить какой-нибудь небольшой проект под соответствующую платформу. Таким образом сейчас я доделываю нечто на замечательном портале убийце плеймаркетаYandex Games.
Проделанной работой я не особо горжусь, так что сюда, пожалуй кидать ее не буду. Тем не менее это был полезный опыт, я научился работать со всякими базами данных, аккаунтами и делать билды под WebGL. Могу сделать в катабазисе онлайновую таблицу рекордов, например. Надеюсь, что в перспективе запилы подобных проектов но нормальных способны принести мне даже какое-то количество денег.
К разработке рогалика я планирую вернуться в течении ближайших недель, но новый билд будет явно не скоро, так как работы много и судя по всему, нужно добавлять что-то типо древа навыков, чтобы наконец в игре появились билды и она нормально функционировала в роли рогалика. Пока у меня на этот счет только некоторые теоретические соображения, которые надо долго доводить до ума чтобы, собственно, начать что-то кодить.
-Оп
>>863254
Давай, добавляй древо навыков, мне тоже надо нечто похожже, сам страдаю выдумываю скиллы.
Давай, добавляй древо навыков, мне тоже надо нечто похожже, сам страдаю выдумываю скиллы.
>>863254
Самая бесполезная фича, имхо.
ДЕЛАЕШЬ ОНЛАЙН ТАБЛИЦУ РЕКОРДОВ
@
ИГРА СТАНОВИТСЯ ЧУТЬ-ЧУТЬ ПОПУЛЯРНОЙ
@
В ТОПЕ ТАБЛИЦЫ У ВСЕХ <INT32_MAX> ОЧКОВ
@
ЛЕГАЛЬНО МОЖНО ПОЛУЧИТЬ НЕ БОЛЕЕ 99
Самое смешное, когда входишь в топ не из-за использования читов, а из-за багов самой игры. В одной игре я провалился под асфальт и летел в пустоту, пока в таблице рекордов накручивался счётчик пройденного расстояния, хотя топ-1 я так и не стал - надоело ждать, слишком долго лететь.
Делай максимально универсальную систему, которая позволяет добавлять любые бонусы ко всем статам и разблокировать любые навыки. И только потом, когда отладишь эту систему, только потом рисуй своё дерево и балансируй раздачу бонусов и навыков на разных возможных ветках этого дерева. То есть у тебя должен быть некий json файлик с деревом, чтобы быстро его менять, не трогая основной код.
А то сейчас опять наговнокодишь и будешь ещё несколько месяцев исправлять. Я дурак и учусь на своих ошибках, а ты будь умнее и учись на чужих.
Вот пример, как я вижу настройку дерева через json с помощью универсальной системы:
{
"перки": {
"живучий 1": [
"здоровье": 5,
"скорость": 3,
"сила": 1,
],
"ловкач 1": [
"скорость": 10,
"сила": -2,
"здоровье": -5,
],
"ловкач 2": [
"использование лука": true,
"меткость": 5,
],
"неуловимый": [
"скорость": 10,
]
},
"дерево": [
["root", "живучий 1"],
["root", "ловкач 1"],
["ловкач 1", "ловкач 2"],
["ловкач 1", "неуловимый"],
["живучий 1", "неуловимый"],
]
}
Если не понял пример:
1. Сначала перечисляются все перки/навыки. На экране они будут отображаться как уникальные кнопки. В их свойствах указаны число очков, суммирующихся с базовыми параметрами героя, и опционально разблокировка навыков (true). Можно также блокировать навыки (false), скажем, если игрок пошёл по пути танка - у него блокируется базовая возможность прыгать, чтобы снизить мобильность и продемонстрировать увеличенную массу.
2. Потом перечисляются связи, начиная от root, т.е. корня, и дальше в произвольном направлении. Каждая пара - это ветка в одном направлении. На экране отображаются линиями от одной кнопки к другой, при этом разблокированы только кнопки, которые напрямую связаны с уже нажатыми кнопками. Пути могут пересекаться (видел такое в разных играх), так что формально это уже не дерево, а граф, ну ты понял. Ещё можно разрешить связи в двух направлениях, тоже видел в одной игре, но это сложнее балансировать.
>онлайновую таблицу рекордов
Самая бесполезная фича, имхо.
ДЕЛАЕШЬ ОНЛАЙН ТАБЛИЦУ РЕКОРДОВ
@
ИГРА СТАНОВИТСЯ ЧУТЬ-ЧУТЬ ПОПУЛЯРНОЙ
@
В ТОПЕ ТАБЛИЦЫ У ВСЕХ <INT32_MAX> ОЧКОВ
@
ЛЕГАЛЬНО МОЖНО ПОЛУЧИТЬ НЕ БОЛЕЕ 99
Самое смешное, когда входишь в топ не из-за использования читов, а из-за багов самой игры. В одной игре я провалился под асфальт и летел в пустоту, пока в таблице рекордов накручивался счётчик пройденного расстояния, хотя топ-1 я так и не стал - надоело ждать, слишком долго лететь.
>древа навыков
>доводить до ума
Делай максимально универсальную систему, которая позволяет добавлять любые бонусы ко всем статам и разблокировать любые навыки. И только потом, когда отладишь эту систему, только потом рисуй своё дерево и балансируй раздачу бонусов и навыков на разных возможных ветках этого дерева. То есть у тебя должен быть некий json файлик с деревом, чтобы быстро его менять, не трогая основной код.
А то сейчас опять наговнокодишь и будешь ещё несколько месяцев исправлять. Я дурак и учусь на своих ошибках, а ты будь умнее и учись на чужих.
Вот пример, как я вижу настройку дерева через json с помощью универсальной системы:
{
"перки": {
"живучий 1": [
"здоровье": 5,
"скорость": 3,
"сила": 1,
],
"ловкач 1": [
"скорость": 10,
"сила": -2,
"здоровье": -5,
],
"ловкач 2": [
"использование лука": true,
"меткость": 5,
],
"неуловимый": [
"скорость": 10,
]
},
"дерево": [
["root", "живучий 1"],
["root", "ловкач 1"],
["ловкач 1", "ловкач 2"],
["ловкач 1", "неуловимый"],
["живучий 1", "неуловимый"],
]
}
Если не понял пример:
1. Сначала перечисляются все перки/навыки. На экране они будут отображаться как уникальные кнопки. В их свойствах указаны число очков, суммирующихся с базовыми параметрами героя, и опционально разблокировка навыков (true). Можно также блокировать навыки (false), скажем, если игрок пошёл по пути танка - у него блокируется базовая возможность прыгать, чтобы снизить мобильность и продемонстрировать увеличенную массу.
2. Потом перечисляются связи, начиная от root, т.е. корня, и дальше в произвольном направлении. Каждая пара - это ветка в одном направлении. На экране отображаются линиями от одной кнопки к другой, при этом разблокированы только кнопки, которые напрямую связаны с уже нажатыми кнопками. Пути могут пересекаться (видел такое в разных играх), так что формально это уже не дерево, а граф, ну ты понял. Ещё можно разрешить связи в двух направлениях, тоже видел в одной игре, но это сложнее балансировать.
>>863254
Самая бесполезная фича, имхо.
ДЕЛАЕШЬ ОНЛАЙН ТАБЛИЦУ РЕКОРДОВ
@
ИГРА СТАНОВИТСЯ ЧУТЬ-ЧУТЬ ПОПУЛЯРНОЙ
@
В ТОПЕ ТАБЛИЦЫ У ВСЕХ <INT32_MAX> ОЧКОВ
@
ЛЕГАЛЬНО МОЖНО ПОЛУЧИТЬ НЕ БОЛЕЕ 99
Самое смешное, когда входишь в топ не из-за использования читов, а из-за багов самой игры. В одной игре я провалился под асфальт и летел в пустоту, пока в таблице рекордов накручивался счётчик пройденного расстояния, хотя топ-1 я так и не стал - надоело ждать, слишком долго лететь.
Делай максимально универсальную систему, которая позволяет добавлять любые бонусы ко всем статам и разблокировать любые навыки. И только потом, когда отладишь эту систему, только потом рисуй своё дерево и балансируй раздачу бонусов и навыков на разных возможных ветках этого дерева. То есть у тебя должен быть некий json файлик с деревом, чтобы быстро его менять, не трогая основной код.
А то сейчас опять наговнокодишь и будешь ещё несколько месяцев исправлять. Я дурак и учусь на своих ошибках, а ты будь умнее и учись на чужих.
Вот пример, как я вижу настройку дерева через json с помощью универсальной системы:
{
"перки": {
"живучий 1": [
"здоровье": 5,
"скорость": 3,
"сила": 1,
],
"ловкач 1": [
"скорость": 10,
"сила": -2,
"здоровье": -5,
],
"ловкач 2": [
"использование лука": true,
"меткость": 5,
],
"неуловимый": [
"скорость": 10,
]
},
"дерево": [
["root", "живучий 1"],
["root", "ловкач 1"],
["ловкач 1", "ловкач 2"],
["ловкач 1", "неуловимый"],
["живучий 1", "неуловимый"],
]
}
Если не понял пример:
1. Сначала перечисляются все перки/навыки. На экране они будут отображаться как уникальные кнопки. В их свойствах указаны число очков, суммирующихся с базовыми параметрами героя, и опционально разблокировка навыков (true). Можно также блокировать навыки (false), скажем, если игрок пошёл по пути танка - у него блокируется базовая возможность прыгать, чтобы снизить мобильность и продемонстрировать увеличенную массу.
2. Потом перечисляются связи, начиная от root, т.е. корня, и дальше в произвольном направлении. Каждая пара - это ветка в одном направлении. На экране отображаются линиями от одной кнопки к другой, при этом разблокированы только кнопки, которые напрямую связаны с уже нажатыми кнопками. Пути могут пересекаться (видел такое в разных играх), так что формально это уже не дерево, а граф, ну ты понял. Ещё можно разрешить связи в двух направлениях, тоже видел в одной игре, но это сложнее балансировать.
>онлайновую таблицу рекордов
Самая бесполезная фича, имхо.
ДЕЛАЕШЬ ОНЛАЙН ТАБЛИЦУ РЕКОРДОВ
@
ИГРА СТАНОВИТСЯ ЧУТЬ-ЧУТЬ ПОПУЛЯРНОЙ
@
В ТОПЕ ТАБЛИЦЫ У ВСЕХ <INT32_MAX> ОЧКОВ
@
ЛЕГАЛЬНО МОЖНО ПОЛУЧИТЬ НЕ БОЛЕЕ 99
Самое смешное, когда входишь в топ не из-за использования читов, а из-за багов самой игры. В одной игре я провалился под асфальт и летел в пустоту, пока в таблице рекордов накручивался счётчик пройденного расстояния, хотя топ-1 я так и не стал - надоело ждать, слишком долго лететь.
>древа навыков
>доводить до ума
Делай максимально универсальную систему, которая позволяет добавлять любые бонусы ко всем статам и разблокировать любые навыки. И только потом, когда отладишь эту систему, только потом рисуй своё дерево и балансируй раздачу бонусов и навыков на разных возможных ветках этого дерева. То есть у тебя должен быть некий json файлик с деревом, чтобы быстро его менять, не трогая основной код.
А то сейчас опять наговнокодишь и будешь ещё несколько месяцев исправлять. Я дурак и учусь на своих ошибках, а ты будь умнее и учись на чужих.
Вот пример, как я вижу настройку дерева через json с помощью универсальной системы:
{
"перки": {
"живучий 1": [
"здоровье": 5,
"скорость": 3,
"сила": 1,
],
"ловкач 1": [
"скорость": 10,
"сила": -2,
"здоровье": -5,
],
"ловкач 2": [
"использование лука": true,
"меткость": 5,
],
"неуловимый": [
"скорость": 10,
]
},
"дерево": [
["root", "живучий 1"],
["root", "ловкач 1"],
["ловкач 1", "ловкач 2"],
["ловкач 1", "неуловимый"],
["живучий 1", "неуловимый"],
]
}
Если не понял пример:
1. Сначала перечисляются все перки/навыки. На экране они будут отображаться как уникальные кнопки. В их свойствах указаны число очков, суммирующихся с базовыми параметрами героя, и опционально разблокировка навыков (true). Можно также блокировать навыки (false), скажем, если игрок пошёл по пути танка - у него блокируется базовая возможность прыгать, чтобы снизить мобильность и продемонстрировать увеличенную массу.
2. Потом перечисляются связи, начиная от root, т.е. корня, и дальше в произвольном направлении. Каждая пара - это ветка в одном направлении. На экране отображаются линиями от одной кнопки к другой, при этом разблокированы только кнопки, которые напрямую связаны с уже нажатыми кнопками. Пути могут пересекаться (видел такое в разных играх), так что формально это уже не дерево, а граф, ну ты понял. Ещё можно разрешить связи в двух направлениях, тоже видел в одной игре, но это сложнее балансировать.
>>863330
Ты советуешь говно. Сложность не в том, чтобы с лучших традициях поеботы сделать 500 одинаковых навыков +10 к силе, а в том, чтобы каждый из них добавлял геймплейные фичи, например, атака со станом, атака с дешем, непробиваемый блок на 1 атаку. Каждую такую штуку надо отдельно закодить, а уж потом раскидать все в жсон вопрос пары часов
Ты советуешь говно. Сложность не в том, чтобы с лучших традициях поеботы сделать 500 одинаковых навыков +10 к силе, а в том, чтобы каждый из них добавлял геймплейные фичи, например, атака со станом, атака с дешем, непробиваемый блок на 1 атаку. Каждую такую штуку надо отдельно закодить, а уж потом раскидать все в жсон вопрос пары часов
>>863330
>>863639
На счет jsona для создания графа звучит интересно, а то я сейчас его почти не использую. Но для описания различных вещей имеющих количественные параметры я всегда юзал эксель таблицы.
С другой стороны, я пока не уверен, будет ли это вообще деревом или этот экран будет выглядеть как-то по-другому.
Так или иначе, сейчас я пришел к выводу что скилы, по мимо того что могут быть пассивными или активными могут делиться на три категории по способу их получения.
- скилы которые ты можешь каким-то образом "найти" в данже и изучить без дополнительных требований.
- прокачиваемые скилы.
- скилы от экипировки
Первая категория наиболее простая, туда пойдут всякие опциональные, веселые скилы, может быть даже секретные, которые не оказывают какого-то супер важного влияния на прохождение и просто разнообразят геймплей. У меня есть несколько мыслей на этот счет.
Вот другими двумя категориями сложнее.
Ну, предположим, во вторую должны входить всякие пассивки, типо, условно шанс отпрыгнуть назад когда тебя бьют. Или наоборот шанс вернуть часть урона.
А экипировка тогда будет давать активки, например булавой можно застанить.
А щитом можно закрыться, блоча весь урон.
А как должны вести себя мобы? Они тоже должны использовать все эти способности? А любой моб, у которого есть руки, получается, может взять любое оружие и полчить доступ к его скилам. Это мне, получается под каждый скилл нужно будет писать поведение для ИИ чтобы он знал в какой момент его нужно юзать.
Или может нафиг эти экипировочные скилы, пускай все скилы прокачиваются, а у мобов будет набор врожденных способностей типо прыжка, если это прыгучий моб.
Я понятия не имею как мне дальше действовать, и что из этих вариантов выбирать, а играть сейчас в кучу разных рпг и заимствовать что-то оттуда у меня нет времени...
>>863639
На счет jsona для создания графа звучит интересно, а то я сейчас его почти не использую. Но для описания различных вещей имеющих количественные параметры я всегда юзал эксель таблицы.
С другой стороны, я пока не уверен, будет ли это вообще деревом или этот экран будет выглядеть как-то по-другому.
Так или иначе, сейчас я пришел к выводу что скилы, по мимо того что могут быть пассивными или активными могут делиться на три категории по способу их получения.
- скилы которые ты можешь каким-то образом "найти" в данже и изучить без дополнительных требований.
- прокачиваемые скилы.
- скилы от экипировки
Первая категория наиболее простая, туда пойдут всякие опциональные, веселые скилы, может быть даже секретные, которые не оказывают какого-то супер важного влияния на прохождение и просто разнообразят геймплей. У меня есть несколько мыслей на этот счет.
Вот другими двумя категориями сложнее.
Ну, предположим, во вторую должны входить всякие пассивки, типо, условно шанс отпрыгнуть назад когда тебя бьют. Или наоборот шанс вернуть часть урона.
А экипировка тогда будет давать активки, например булавой можно застанить.
А щитом можно закрыться, блоча весь урон.
А как должны вести себя мобы? Они тоже должны использовать все эти способности? А любой моб, у которого есть руки, получается, может взять любое оружие и полчить доступ к его скилам. Это мне, получается под каждый скилл нужно будет писать поведение для ИИ чтобы он знал в какой момент его нужно юзать.
Или может нафиг эти экипировочные скилы, пускай все скилы прокачиваются, а у мобов будет набор врожденных способностей типо прыжка, если это прыгучий моб.
Я понятия не имею как мне дальше действовать, и что из этих вариантов выбирать, а играть сейчас в кучу разных рпг и заимствовать что-то оттуда у меня нет времени...
>>863639
Это ты советуешь говно. Игра должна быть достаточно простой, но при этом регулярно кормить игрока дозами дофамина. Дерево навыков предназначено именно для этого. Если у тебя на каждом узле дерева будет какой-то новый геймплейный навык, то ты либо завалишь игрока ненужными фичами с порога, либо заставишь его очень долго гриндить опыт ради следующего навыка.
Правильное дерево развития регулярно кормит игрока маленькими апгрейдами, лишь иногда открывая ему дополнительные фичи, которых немного.
Условно, вот есть у тебя в игре три основных ветки развития: ближний бой, дальний бой, призыватель. Ты даёшь каждой ветке 2-3 активных способности, которые игрок может по кнопке запускать, а всё остальное - это исключительно пассивные бонусы вроде "+5 здоровья", влияющие на то, как ты играешь. Игрок сможет попробовать сделать шустрого призывателя или Толстого призывателя, или сбалансировать скорость и толщину, но основной навык (призыв нежити) будет одинаковым.
>>863723
Ты прав, я как-то не подумал, что можно просто назначить столбцам различные параметры и потом в строчках перечислять перки, а потом экспортировать в csv. По идее, так может быть проще, но если параметров много, таблица слишком растянется по ширине, и будет что-то вроде:
Читать такую запись сложно, а каких-то инструментов для упрощения я не нашёл (LibreOffice).
Связь данных в виде графа не зависит от визуализации, то есть тебе всё равно нужно как-то описать, что с чем связано и когда разблокируется.
Игроки привыкли, что ИИ в играх тупой и ни на что не способен, пытаясь взять количеством, а не тактикой. Так что вряд ли тебе стоит этим заморачиваться. У тебя же просто мясной рогалик, а не симулятор чего-то.
По идее, стан оружием - это навык героя. Обычно именно герой усваивает навык "стан тяжёлым оружием", который он может использовать, если держит в руках тяжёлое оружие. Это самое логичное.
Другое дело, если у тебя будет автоматическое оружие, вроде турелей. Они, по идее, переключаются кнопкой, и нажать на кнопку может любой идиот. Но с другой стороны, можно сделать ветку развития "механик" и заставить изучать владение техникой, аргументируя тем, что герой не совсем тупой и не будет жать кнопки, не зная о том, что эти кнопки делают.
Не нужно копировать, у тебя оригинальная игра. Делай так, чтобы тебе было весело играть, а если в какой-то игре есть какая-то механика, это не значит, что она будет весёлой в конкретно твоей игре.
Тебе же весело в свою игру играть?
"Весело" в смысле "fun", сложно перевести без потери смысла. Скорее, "интересно" или "увлекательно"...
>каждый из них добавлял геймплейные фичи
Это ты советуешь говно. Игра должна быть достаточно простой, но при этом регулярно кормить игрока дозами дофамина. Дерево навыков предназначено именно для этого. Если у тебя на каждом узле дерева будет какой-то новый геймплейный навык, то ты либо завалишь игрока ненужными фичами с порога, либо заставишь его очень долго гриндить опыт ради следующего навыка.
Правильное дерево развития регулярно кормит игрока маленькими апгрейдами, лишь иногда открывая ему дополнительные фичи, которых немного.
Условно, вот есть у тебя в игре три основных ветки развития: ближний бой, дальний бой, призыватель. Ты даёшь каждой ветке 2-3 активных способности, которые игрок может по кнопке запускать, а всё остальное - это исключительно пассивные бонусы вроде "+5 здоровья", влияющие на то, как ты играешь. Игрок сможет попробовать сделать шустрого призывателя или Толстого призывателя, или сбалансировать скорость и толщину, но основной навык (призыв нежити) будет одинаковым.
>>863723
>эксель таблицы
Ты прав, я как-то не подумал, что можно просто назначить столбцам различные параметры и потом в строчках перечислять перки, а потом экспортировать в csv. По идее, так может быть проще, но если параметров много, таблица слишком растянется по ширине, и будет что-то вроде:
>название 5 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 -2
Читать такую запись сложно, а каких-то инструментов для упрощения я не нашёл (LibreOffice).
>будет ли это вообще деревом или этот экран будет выглядеть как-то по-другому.
Связь данных в виде графа не зависит от визуализации, то есть тебе всё равно нужно как-то описать, что с чем связано и когда разблокируется.
>поведение для ИИ
Игроки привыкли, что ИИ в играх тупой и ни на что не способен, пытаясь взять количеством, а не тактикой. Так что вряд ли тебе стоит этим заморачиваться. У тебя же просто мясной рогалик, а не симулятор чего-то.
>А экипировка тогда будет давать активки, например булавой можно застанить.
По идее, стан оружием - это навык героя. Обычно именно герой усваивает навык "стан тяжёлым оружием", который он может использовать, если держит в руках тяжёлое оружие. Это самое логичное.
Другое дело, если у тебя будет автоматическое оружие, вроде турелей. Они, по идее, переключаются кнопкой, и нажать на кнопку может любой идиот. Но с другой стороны, можно сделать ветку развития "механик" и заставить изучать владение техникой, аргументируя тем, что герой не совсем тупой и не будет жать кнопки, не зная о том, что эти кнопки делают.
>играть сейчас в кучу разных рпг и заимствовать
Не нужно копировать, у тебя оригинальная игра. Делай так, чтобы тебе было весело играть, а если в какой-то игре есть какая-то механика, это не значит, что она будет весёлой в конкретно твоей игре.
Тебе же весело в свою игру играть?
"Весело" в смысле "fun", сложно перевести без потери смысла. Скорее, "интересно" или "увлекательно"...
>>863639
Это ты советуешь говно. Игра должна быть достаточно простой, но при этом регулярно кормить игрока дозами дофамина. Дерево навыков предназначено именно для этого. Если у тебя на каждом узле дерева будет какой-то новый геймплейный навык, то ты либо завалишь игрока ненужными фичами с порога, либо заставишь его очень долго гриндить опыт ради следующего навыка.
Правильное дерево развития регулярно кормит игрока маленькими апгрейдами, лишь иногда открывая ему дополнительные фичи, которых немного.
Условно, вот есть у тебя в игре три основных ветки развития: ближний бой, дальний бой, призыватель. Ты даёшь каждой ветке 2-3 активных способности, которые игрок может по кнопке запускать, а всё остальное - это исключительно пассивные бонусы вроде "+5 здоровья", влияющие на то, как ты играешь. Игрок сможет попробовать сделать шустрого призывателя или Толстого призывателя, или сбалансировать скорость и толщину, но основной навык (призыв нежити) будет одинаковым.
>>863723
Ты прав, я как-то не подумал, что можно просто назначить столбцам различные параметры и потом в строчках перечислять перки, а потом экспортировать в csv. По идее, так может быть проще, но если параметров много, таблица слишком растянется по ширине, и будет что-то вроде:
Читать такую запись сложно, а каких-то инструментов для упрощения я не нашёл (LibreOffice).
Связь данных в виде графа не зависит от визуализации, то есть тебе всё равно нужно как-то описать, что с чем связано и когда разблокируется.
Игроки привыкли, что ИИ в играх тупой и ни на что не способен, пытаясь взять количеством, а не тактикой. Так что вряд ли тебе стоит этим заморачиваться. У тебя же просто мясной рогалик, а не симулятор чего-то.
По идее, стан оружием - это навык героя. Обычно именно герой усваивает навык "стан тяжёлым оружием", который он может использовать, если держит в руках тяжёлое оружие. Это самое логичное.
Другое дело, если у тебя будет автоматическое оружие, вроде турелей. Они, по идее, переключаются кнопкой, и нажать на кнопку может любой идиот. Но с другой стороны, можно сделать ветку развития "механик" и заставить изучать владение техникой, аргументируя тем, что герой не совсем тупой и не будет жать кнопки, не зная о том, что эти кнопки делают.
Не нужно копировать, у тебя оригинальная игра. Делай так, чтобы тебе было весело играть, а если в какой-то игре есть какая-то механика, это не значит, что она будет весёлой в конкретно твоей игре.
Тебе же весело в свою игру играть?
"Весело" в смысле "fun", сложно перевести без потери смысла. Скорее, "интересно" или "увлекательно"...
>каждый из них добавлял геймплейные фичи
Это ты советуешь говно. Игра должна быть достаточно простой, но при этом регулярно кормить игрока дозами дофамина. Дерево навыков предназначено именно для этого. Если у тебя на каждом узле дерева будет какой-то новый геймплейный навык, то ты либо завалишь игрока ненужными фичами с порога, либо заставишь его очень долго гриндить опыт ради следующего навыка.
Правильное дерево развития регулярно кормит игрока маленькими апгрейдами, лишь иногда открывая ему дополнительные фичи, которых немного.
Условно, вот есть у тебя в игре три основных ветки развития: ближний бой, дальний бой, призыватель. Ты даёшь каждой ветке 2-3 активных способности, которые игрок может по кнопке запускать, а всё остальное - это исключительно пассивные бонусы вроде "+5 здоровья", влияющие на то, как ты играешь. Игрок сможет попробовать сделать шустрого призывателя или Толстого призывателя, или сбалансировать скорость и толщину, но основной навык (призыв нежити) будет одинаковым.
>>863723
>эксель таблицы
Ты прав, я как-то не подумал, что можно просто назначить столбцам различные параметры и потом в строчках перечислять перки, а потом экспортировать в csv. По идее, так может быть проще, но если параметров много, таблица слишком растянется по ширине, и будет что-то вроде:
>название 5 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 -2
Читать такую запись сложно, а каких-то инструментов для упрощения я не нашёл (LibreOffice).
>будет ли это вообще деревом или этот экран будет выглядеть как-то по-другому.
Связь данных в виде графа не зависит от визуализации, то есть тебе всё равно нужно как-то описать, что с чем связано и когда разблокируется.
>поведение для ИИ
Игроки привыкли, что ИИ в играх тупой и ни на что не способен, пытаясь взять количеством, а не тактикой. Так что вряд ли тебе стоит этим заморачиваться. У тебя же просто мясной рогалик, а не симулятор чего-то.
>А экипировка тогда будет давать активки, например булавой можно застанить.
По идее, стан оружием - это навык героя. Обычно именно герой усваивает навык "стан тяжёлым оружием", который он может использовать, если держит в руках тяжёлое оружие. Это самое логичное.
Другое дело, если у тебя будет автоматическое оружие, вроде турелей. Они, по идее, переключаются кнопкой, и нажать на кнопку может любой идиот. Но с другой стороны, можно сделать ветку развития "механик" и заставить изучать владение техникой, аргументируя тем, что герой не совсем тупой и не будет жать кнопки, не зная о том, что эти кнопки делают.
>играть сейчас в кучу разных рпг и заимствовать
Не нужно копировать, у тебя оригинальная игра. Делай так, чтобы тебе было весело играть, а если в какой-то игре есть какая-то механика, это не значит, что она будет весёлой в конкретно твоей игре.
Тебе же весело в свою игру играть?
"Весело" в смысле "fun", сложно перевести без потери смысла. Скорее, "интересно" или "увлекательно"...
9,5 Мб, 847x803...Но для того чтобы снова начинать писать что-то серьезное мне нужно провести глобальный рефакторинг. Периодически я и так переписываю те части игры, которые я кодил будучи совсем юным и зеленым, но сейчас необходимо прямо серьезно за это взяться.
Вот, например, переписал недавно ту часть генератора, которая отвечала за шаблоны генерации (такие как озеро, пещера, яма и прочее). До этого все методы связанные с созданием конкретных фич лежали в огромном 1000 строчном классе (запечатлен на гифке перед удалением), на который ссылались классы шаблонов, в которых применение этих методов было захардкожено в определенном порядке.
Это было очень плохо...
Я расчленил этот мега класс на 20 маленьких классов, которые я в теперь вешаю в качестве компонентов на геймобджект и таким образом могу создавать шаблоны генерации чисто внутри эдитора, не прибегая к коду.
И такой херни в проекте все еще довольно много. Вот, взялся сейчас за переписывание базы данных предметов. Она 700 строк в длину, обрабатывает результат импорта эксель таблицы предметов, а еще существ, отрядов существ и уникальных предметов. А еще заполняет таблицы локализации, создает коллекции спрайтов для импортированных предметов, играет на баяне и хуй сосет
Это тоже максимально плохо, single responsibility principle не просто так придумали.
Вот, например, переписал недавно ту часть генератора, которая отвечала за шаблоны генерации (такие как озеро, пещера, яма и прочее). До этого все методы связанные с созданием конкретных фич лежали в огромном 1000 строчном классе (запечатлен на гифке перед удалением), на который ссылались классы шаблонов, в которых применение этих методов было захардкожено в определенном порядке.
Это было очень плохо...
Я расчленил этот мега класс на 20 маленьких классов, которые я в теперь вешаю в качестве компонентов на геймобджект и таким образом могу создавать шаблоны генерации чисто внутри эдитора, не прибегая к коду.
И такой херни в проекте все еще довольно много. Вот, взялся сейчас за переписывание базы данных предметов. Она 700 строк в длину, обрабатывает результат импорта эксель таблицы предметов, а еще существ, отрядов существ и уникальных предметов. А еще заполняет таблицы локализации, создает коллекции спрайтов для импортированных предметов, играет на баяне и хуй сосет
Это тоже максимально плохо, single responsibility principle не просто так придумали.
>>865028
Да уж, это самое скучное в разработке.
У тебя хотя бы херня есть. А я переписываю всё с нуля по несколько раз, и в общем и целом игры как не было, так и нет, только несколько разных переписанных несколько раз систем, которые не работают и нужно переписывать снова.
>>865058
Соло инди не может сделать очень дорогую графику, длинный сюжет с озвучкой, огромное количество вручную сделанных сцен и т.д. Поэтому инди выкручиваются оригинальными комбинациями того, что раньше даже не думали комбинировать. Это даёт тот эффект новизны и уникальности, который может продать твою игру. А очередная банальная реализация стандартных для какого-то относительно популярного жанра фич никому не нужна.
Так что идея ОПа имеет смысл, нужно только как-то интересно вписать её в геймплей, чтобы она не выглядела лишней или мешающей.
>нужно провести глобальный рефакторинг
Да уж, это самое скучное в разработке.
>И такой херни в проекте все еще довольно много.
У тебя хотя бы херня есть. А я переписываю всё с нуля по несколько раз, и в общем и целом игры как не было, так и нет, только несколько разных переписанных несколько раз систем, которые не работают и нужно переписывать снова.
>>865058
Соло инди не может сделать очень дорогую графику, длинный сюжет с озвучкой, огромное количество вручную сделанных сцен и т.д. Поэтому инди выкручиваются оригинальными комбинациями того, что раньше даже не думали комбинировать. Это даёт тот эффект новизны и уникальности, который может продать твою игру. А очередная банальная реализация стандартных для какого-то относительно популярного жанра фич никому не нужна.
Так что идея ОПа имеет смысл, нужно только как-то интересно вписать её в геймплей, чтобы она не выглядела лишней или мешающей.
>>865114
ок, пойду сделаю пошаговую гонку с элементами стелса, думаю что получится заебок
ок, пойду сделаю пошаговую гонку с элементами стелса, думаю что получится заебок
>>865140
Нормально.
Тоже неплохо.
Я как раз сегодня думал о том, что можно сделать пошаговую текстовую гонку, в которой ты управляешь автомобилем и читаешь описание дорожных ситуаций, вроде "тебя подрезали" или "ты врезался в столб".
По стелсу не знаю, например, от копов уходить? Или выигрывать гонки секретными путями - противник теряет тебя из виду и расслабляется, а ты вылетаешь у него перед носом с секретного пути.
В общем, удачи, надеюсь, у тебя получится.
>>865178
А ты не завидуй, на наших глазах рождается легенда.
>пошаговую гонку
Нормально.
>с элементами стелса
Тоже неплохо.
Я как раз сегодня думал о том, что можно сделать пошаговую текстовую гонку, в которой ты управляешь автомобилем и читаешь описание дорожных ситуаций, вроде "тебя подрезали" или "ты врезался в столб".
По стелсу не знаю, например, от копов уходить? Или выигрывать гонки секретными путями - противник теряет тебя из виду и расслабляется, а ты вылетаешь у него перед носом с секретного пути.
В общем, удачи, надеюсь, у тебя получится.
>>865178
А ты не завидуй, на наших глазах рождается легенда.
>>865211
я не завидую, скорее, грущу от неизбежности подобного расклада
если готов быть геймдизайнером, я могу тебе накодить твою текстовую гонку для бота в телеграме
я не завидую, скорее, грущу от неизбежности подобного расклада
если готов быть геймдизайнером, я могу тебе накодить твою текстовую гонку для бота в телеграме
>>865245
Не, это была просто мысль на тему того, что можно оформить в виде текстовой игры, сохранив хотя бы общие черты жанра. Делать такое я не буду.
>накодить твою текстовую гонку
Не, это была просто мысль на тему того, что можно оформить в виде текстовой игры, сохранив хотя бы общие черты жанра. Делать такое я не буду.
>>865211
Прикольно. Напоминает всякие настолки, где ты по маршруту фишки двигаешь, кидая кубик и там разные эвенты на пути которые тебя ускоряют или назад отбрасывают.
-Оп
Прикольно. Напоминает всякие настолки, где ты по маршруту фишки двигаешь, кидая кубик и там разные эвенты на пути которые тебя ускоряют или назад отбрасывают.
-Оп
1,9 Мб, 860x756>>865058
>>865114
Справедливости ради, на данный момент этот эксперимент с физикой бы признан мной неудачным и оная была порезана до возможности кидать и пинать предметы и взрывать бомбы с осколками.
Всякие вещи по типу рикошетов предметов от стен, столкновений предметов в воздухе и отбрасывания врагов в зависимости от силы удара были отняли у меня несколько месяцев времени, после чего были выпилены.
А все почему?
Потому что эксперименты это хорошо, но введение новых механик должно быть продиктовано геймплейной целесообразностью. Продвинутая физика была очень сложной, и плохо предсказуемой, а никакого глубокого геймплея, оправдывающего эту сложность за ней не стояло.
- Оп
>>865114
Справедливости ради, на данный момент этот эксперимент с физикой бы признан мной неудачным и оная была порезана до возможности кидать и пинать предметы и взрывать бомбы с осколками.
Всякие вещи по типу рикошетов предметов от стен, столкновений предметов в воздухе и отбрасывания врагов в зависимости от силы удара были отняли у меня несколько месяцев времени, после чего были выпилены.
А все почему?
Потому что эксперименты это хорошо, но введение новых механик должно быть продиктовано геймплейной целесообразностью. Продвинутая физика была очень сложной, и плохо предсказуемой, а никакого глубокого геймплея, оправдывающего эту сложность за ней не стояло.
- Оп
>>865058
Это было тем, что цепляло глаз и вызывало интерес к проекту. Нихуя себе, рогалик с честной физической симуляцией, киданием отрубленных рук.
Это было тем, что цепляло глаз и вызывало интерес к проекту. Нихуя себе, рогалик с честной физической симуляцией, киданием отрубленных рук.
>>865516
Кстати, как их кидать правильно? Обычно в играх достаточно кинуть бомбу и отойти на безопасное расстояние, а у тебя осколками убивает только так.
Пнул врага - враг упал в дырку в полу и разбился насмерть, а лут ты с него подобрал с пола на следующем этапе. Подобное есть в (Shattered) Pixel Dungeon, помогает избежать гибели/серьёзных повреждений из-за слишком сильного противника, если он не умеет летать (иначе будет парить над дырой в полу). Но там это способность одного из героев и ещё функция одной из волшебных палочек, а не какая-то базовая физика. Я давно рекомендовал тебе поиграть в SPD, ты играл?
Рикошеты: кинуть нож в стену, чтобы он отскочил за угол и попал в ничего не подозревающего противника, нанеся ему критический урон. Нереалистично, но кто сказал, что игра должна быть реалистичной? Главное, иметь способ узнать о противнике заранее и точно предсказать траекторию полёта предмета, и будет весело.
Столкновения: если стрела, нож, топор, бомба или ракета летят достаточно долго, чтобы игрок успел отреагировать, то он может спастись, кинув предмет в их сторону, или даже контратаковать, если сработает рикошет в обратную сторону (того, кто атаковал первым). Опять же, это нереалистично, но будет весело, если можно будет производить с достаточной точностью.
Тут вопрос не в какой-то особой глубине механик, а в игровом балансе. У тебя большинство стычек почти фатальны, всех постоянно на куски рвёт. Если бы можно было танковать больше урона телом, было бы куда больше свободы для экспериментов, а у тебя сейчас "кинул бомбу - умер от рикошета - начинай с нуля", это совсем не весело и заставляет избегать экспериментов. Вышеупомянутый SPD прощает намного больше локальных ошибок (вроде неудачного боя с одним-двумя мобами, падения в яму, срабатывания ловушки и т.д.), при этом оставаясь достаточно сложным. Отчасти это потому, что сытость легче восполнить и сытый регенируется до 100%, есть целебные травы и предметы из них, а зелье здоровья вообще почти моментально добивает до 100% и ещё немного. Все эти предметы ограничены в данже и не позволят выживать бесконечно долго, но на прохождение всего данжа (25 этажей) сверху вниз и обратно их более, чем достаточно, и если не тупить слишком сильно, то выйдешь наружу с несколькими лишними лечилками. А для хардкорных задротов - отдельные режимы испытаний.
>взрывать бомбы с осколками
>плохо предсказуемой
Кстати, как их кидать правильно? Обычно в играх достаточно кинуть бомбу и отойти на безопасное расстояние, а у тебя осколками убивает только так.
>отбрасывания врагов в зависимости от силы удара
>продиктовано геймплейной целесообразностью
>глубокого геймплея, оправдывающего
Пнул врага - враг упал в дырку в полу и разбился насмерть, а лут ты с него подобрал с пола на следующем этапе. Подобное есть в (Shattered) Pixel Dungeon, помогает избежать гибели/серьёзных повреждений из-за слишком сильного противника, если он не умеет летать (иначе будет парить над дырой в полу). Но там это способность одного из героев и ещё функция одной из волшебных палочек, а не какая-то базовая физика. Я давно рекомендовал тебе поиграть в SPD, ты играл?
>рикошетов предметов от стен
>столкновений предметов в воздухе
>глубокого геймплея, оправдывающего
Рикошеты: кинуть нож в стену, чтобы он отскочил за угол и попал в ничего не подозревающего противника, нанеся ему критический урон. Нереалистично, но кто сказал, что игра должна быть реалистичной? Главное, иметь способ узнать о противнике заранее и точно предсказать траекторию полёта предмета, и будет весело.
Столкновения: если стрела, нож, топор, бомба или ракета летят достаточно долго, чтобы игрок успел отреагировать, то он может спастись, кинув предмет в их сторону, или даже контратаковать, если сработает рикошет в обратную сторону (того, кто атаковал первым). Опять же, это нереалистично, но будет весело, если можно будет производить с достаточной точностью.
Тут вопрос не в какой-то особой глубине механик, а в игровом балансе. У тебя большинство стычек почти фатальны, всех постоянно на куски рвёт. Если бы можно было танковать больше урона телом, было бы куда больше свободы для экспериментов, а у тебя сейчас "кинул бомбу - умер от рикошета - начинай с нуля", это совсем не весело и заставляет избегать экспериментов. Вышеупомянутый SPD прощает намного больше локальных ошибок (вроде неудачного боя с одним-двумя мобами, падения в яму, срабатывания ловушки и т.д.), при этом оставаясь достаточно сложным. Отчасти это потому, что сытость легче восполнить и сытый регенируется до 100%, есть целебные травы и предметы из них, а зелье здоровья вообще почти моментально добивает до 100% и ещё немного. Все эти предметы ограничены в данже и не позволят выживать бесконечно долго, но на прохождение всего данжа (25 этажей) сверху вниз и обратно их более, чем достаточно, и если не тупить слишком сильно, то выйдешь наружу с несколькими лишними лечилками. А для хардкорных задротов - отдельные режимы испытаний.
>>865516
Кстати, как их кидать правильно? Обычно в играх достаточно кинуть бомбу и отойти на безопасное расстояние, а у тебя осколками убивает только так.
Пнул врага - враг упал в дырку в полу и разбился насмерть, а лут ты с него подобрал с пола на следующем этапе. Подобное есть в (Shattered) Pixel Dungeon, помогает избежать гибели/серьёзных повреждений из-за слишком сильного противника, если он не умеет летать (иначе будет парить над дырой в полу). Но там это способность одного из героев и ещё функция одной из волшебных палочек, а не какая-то базовая физика. Я давно рекомендовал тебе поиграть в SPD, ты играл?
Рикошеты: кинуть нож в стену, чтобы он отскочил за угол и попал в ничего не подозревающего противника, нанеся ему критический урон. Нереалистично, но кто сказал, что игра должна быть реалистичной? Главное, иметь способ узнать о противнике заранее и точно предсказать траекторию полёта предмета, и будет весело.
Столкновения: если стрела, нож, топор, бомба или ракета летят достаточно долго, чтобы игрок успел отреагировать, то он может спастись, кинув предмет в их сторону, или даже контратаковать, если сработает рикошет в обратную сторону (того, кто атаковал первым). Опять же, это нереалистично, но будет весело, если можно будет производить с достаточной точностью.
Тут вопрос не в какой-то особой глубине механик, а в игровом балансе. У тебя большинство стычек почти фатальны, всех постоянно на куски рвёт. Если бы можно было танковать больше урона телом, было бы куда больше свободы для экспериментов, а у тебя сейчас "кинул бомбу - умер от рикошета - начинай с нуля", это совсем не весело и заставляет избегать экспериментов. Вышеупомянутый SPD прощает намного больше локальных ошибок (вроде неудачного боя с одним-двумя мобами, падения в яму, срабатывания ловушки и т.д.), при этом оставаясь достаточно сложным. Отчасти это потому, что сытость легче восполнить и сытый регенируется до 100%, есть целебные травы и предметы из них, а зелье здоровья вообще почти моментально добивает до 100% и ещё немного. Все эти предметы ограничены в данже и не позволят выживать бесконечно долго, но на прохождение всего данжа (25 этажей) сверху вниз и обратно их более, чем достаточно, и если не тупить слишком сильно, то выйдешь наружу с несколькими лишними лечилками. А для хардкорных задротов - отдельные режимы испытаний.
>взрывать бомбы с осколками
>плохо предсказуемой
Кстати, как их кидать правильно? Обычно в играх достаточно кинуть бомбу и отойти на безопасное расстояние, а у тебя осколками убивает только так.
>отбрасывания врагов в зависимости от силы удара
>продиктовано геймплейной целесообразностью
>глубокого геймплея, оправдывающего
Пнул врага - враг упал в дырку в полу и разбился насмерть, а лут ты с него подобрал с пола на следующем этапе. Подобное есть в (Shattered) Pixel Dungeon, помогает избежать гибели/серьёзных повреждений из-за слишком сильного противника, если он не умеет летать (иначе будет парить над дырой в полу). Но там это способность одного из героев и ещё функция одной из волшебных палочек, а не какая-то базовая физика. Я давно рекомендовал тебе поиграть в SPD, ты играл?
>рикошетов предметов от стен
>столкновений предметов в воздухе
>глубокого геймплея, оправдывающего
Рикошеты: кинуть нож в стену, чтобы он отскочил за угол и попал в ничего не подозревающего противника, нанеся ему критический урон. Нереалистично, но кто сказал, что игра должна быть реалистичной? Главное, иметь способ узнать о противнике заранее и точно предсказать траекторию полёта предмета, и будет весело.
Столкновения: если стрела, нож, топор, бомба или ракета летят достаточно долго, чтобы игрок успел отреагировать, то он может спастись, кинув предмет в их сторону, или даже контратаковать, если сработает рикошет в обратную сторону (того, кто атаковал первым). Опять же, это нереалистично, но будет весело, если можно будет производить с достаточной точностью.
Тут вопрос не в какой-то особой глубине механик, а в игровом балансе. У тебя большинство стычек почти фатальны, всех постоянно на куски рвёт. Если бы можно было танковать больше урона телом, было бы куда больше свободы для экспериментов, а у тебя сейчас "кинул бомбу - умер от рикошета - начинай с нуля", это совсем не весело и заставляет избегать экспериментов. Вышеупомянутый SPD прощает намного больше локальных ошибок (вроде неудачного боя с одним-двумя мобами, падения в яму, срабатывания ловушки и т.д.), при этом оставаясь достаточно сложным. Отчасти это потому, что сытость легче восполнить и сытый регенируется до 100%, есть целебные травы и предметы из них, а зелье здоровья вообще почти моментально добивает до 100% и ещё немного. Все эти предметы ограничены в данже и не позволят выживать бесконечно долго, но на прохождение всего данжа (25 этажей) сверху вниз и обратно их более, чем достаточно, и если не тупить слишком сильно, то выйдешь наружу с несколькими лишними лечилками. А для хардкорных задротов - отдельные режимы испытаний.
>>865573
Там есть лимит дальности разлета осколков. Сейчас глянул, он 10 клеток. Это явно многовато, надо раза в 2 как минимум сократить, а то так себя убить реально проще чем противника.
В пиксель данжен играл, он действительно хорош, несколько раз проходил его. Собственно, эти вещи про которые ты описал сейчас присутствуют, пинать врагов можно и в яму скидывать можно.
На счет физики, я просто пришел к выводу что если ты делаешь какую-то часть геймплея действительно физичной, с массой там, с ускорением, с сопротивлением воздуха и прочим, то по хорошему, физичным нужно делать и все остальное, иначе получается какая-то кринжатура. Нужно моделировать физичные удары, физичную броню, физичные части тела, никаих ХП, никаких больше силы и ловкости.
Именно за этим не стоит глубокого геймплея, а не за механикой пинков или бросков. А сделать его невероятно трудно. К тому же я на самом деле физику знаю очень плохо, даже на уровне школы.
Броски предметов, пинки и все вот это можно сделать и без физики. А рикошеты я убрал потому что это просто одна из многих механик, для которой нужно пилить какое-то запарное UI чтобы она нормально работала, а результат все равно сомнительный.
Отбивание летящих в тебя предметов другими предметами это вообще какой-то абсурд. Дело не в реализме, а в том что у игрока должна сохраняться хоть какая-то вера в осмысленность происходящего. У меня же не ироничный ломатель жанра типо Cat Mario.
Плюс, до того что так вообще можно делать игрок скорее всего никогда в жизни не догадается.к тому же, кажется, с тем как сейчас строено время в игре, застать летящий в тебя нож пока он еще летит в принципе нельзя...
>как кидать гранаты
Там есть лимит дальности разлета осколков. Сейчас глянул, он 10 клеток. Это явно многовато, надо раза в 2 как минимум сократить, а то так себя убить реально проще чем противника.
В пиксель данжен играл, он действительно хорош, несколько раз проходил его. Собственно, эти вещи про которые ты описал сейчас присутствуют, пинать врагов можно и в яму скидывать можно.
На счет физики, я просто пришел к выводу что если ты делаешь какую-то часть геймплея действительно физичной, с массой там, с ускорением, с сопротивлением воздуха и прочим, то по хорошему, физичным нужно делать и все остальное, иначе получается какая-то кринжатура. Нужно моделировать физичные удары, физичную броню, физичные части тела, никаих ХП, никаких больше силы и ловкости.
Именно за этим не стоит глубокого геймплея, а не за механикой пинков или бросков. А сделать его невероятно трудно. К тому же я на самом деле физику знаю очень плохо, даже на уровне школы.
Броски предметов, пинки и все вот это можно сделать и без физики. А рикошеты я убрал потому что это просто одна из многих механик, для которой нужно пилить какое-то запарное UI чтобы она нормально работала, а результат все равно сомнительный.
Отбивание летящих в тебя предметов другими предметами это вообще какой-то абсурд. Дело не в реализме, а в том что у игрока должна сохраняться хоть какая-то вера в осмысленность происходящего. У меня же не ироничный ломатель жанра типо Cat Mario.
Плюс, до того что так вообще можно делать игрок скорее всего никогда в жизни не догадается.к тому же, кажется, с тем как сейчас строено время в игре, застать летящий в тебя нож пока он еще летит в принципе нельзя...
>>866198
Эм... Либо я не понял твою мысль, либо ты никогда не видел все эти, наверное, уже сотни игр построенных на сравнительно реалистичной физике, но без детальной проработки повреждений и т.п.
Другое дело, что все эти игры с физикой - в реальном времени, и редко ставят серьёзные задачи, их цель - забавное времяпрепровождение, а не хардкорный выживач. Поэтому недостатки физического движка компенсируются несерьёзностью происходящего на экране, даже наоборот, добавляя комичности.
Твоя же игра пошаговая, поэтому основная сложность - увязать физику с пошаговостью. Мне кажется, ты просто слишком зафиксировался на жанре рогаликов с его квадратно-гнездовым полем боя, и поэтому не смог на полную раскрыть физику. Если бы ты пошёл дальше, логично было бы отказаться от каноничного движения по клеточкам, сохранив только пошаговость (время идёт после действия игрока, затем мир снова замораживается, ожидая решения игрока)... Добавить ещё скольжение как по льду и вообще кайф будет, успевай только шинковать врагов на куски и уворачиваться от их острых клинков, всё с учётом физического скольжения с отскоками, но пошагово. Отбрось реализм и будет весело, ты же не реалистичный боевой симулятор для тренировки солдат делаешь, а игру для получения удовольствия от геймплея.
Это же игра. Если механика создаёт интересные игровые ситуации, то она имеет смысл для игрока. Вот сейчас у тебя есть возможность разобрать любого противника на отдельные косточки и набить этими костями инвентарь или разбросать их по уровню - в этом нет смысла, потому что это ни на что не влияет и ни для чего не нужно, в этом нет фана (если ты не какой-то... костефил). А отбивание снарядов было бы полезным, даже если этому тяжело научиться, чтобы использовать регулярно. Кости тоже можно было бы сделать осмысленными, если бы был крафт костяных инструментов или хотя бы использование их как одноразовые отмычки для дверей.
>если ты делаешь какую-то часть геймплея действительно физичной, с массой там, с ускорением, с сопротивлением воздуха и прочим, то по хорошему, физичным нужно делать и все остальное, иначе получается какая-то кринжатура. Нужно моделировать физичные удары, физичную броню, физичные части тела, никаих ХП, никаких больше силы и ловкости.
Эм... Либо я не понял твою мысль, либо ты никогда не видел все эти, наверное, уже сотни игр построенных на сравнительно реалистичной физике, но без детальной проработки повреждений и т.п.
Другое дело, что все эти игры с физикой - в реальном времени, и редко ставят серьёзные задачи, их цель - забавное времяпрепровождение, а не хардкорный выживач. Поэтому недостатки физического движка компенсируются несерьёзностью происходящего на экране, даже наоборот, добавляя комичности.
Твоя же игра пошаговая, поэтому основная сложность - увязать физику с пошаговостью. Мне кажется, ты просто слишком зафиксировался на жанре рогаликов с его квадратно-гнездовым полем боя, и поэтому не смог на полную раскрыть физику. Если бы ты пошёл дальше, логично было бы отказаться от каноничного движения по клеточкам, сохранив только пошаговость (время идёт после действия игрока, затем мир снова замораживается, ожидая решения игрока)... Добавить ещё скольжение как по льду и вообще кайф будет, успевай только шинковать врагов на куски и уворачиваться от их острых клинков, всё с учётом физического скольжения с отскоками, но пошагово. Отбрось реализм и будет весело, ты же не реалистичный боевой симулятор для тренировки солдат делаешь, а игру для получения удовольствия от геймплея.
>Отбивание летящих в тебя предметов
>вера в осмысленность происходящего
Это же игра. Если механика создаёт интересные игровые ситуации, то она имеет смысл для игрока. Вот сейчас у тебя есть возможность разобрать любого противника на отдельные косточки и набить этими костями инвентарь или разбросать их по уровню - в этом нет смысла, потому что это ни на что не влияет и ни для чего не нужно, в этом нет фана (если ты не какой-то... костефил). А отбивание снарядов было бы полезным, даже если этому тяжело научиться, чтобы использовать регулярно. Кости тоже можно было бы сделать осмысленными, если бы был крафт костяных инструментов или хотя бы использование их как одноразовые отмычки для дверей.
>>866198
Эм... Либо я не понял твою мысль, либо ты никогда не видел все эти, наверное, уже сотни игр построенных на сравнительно реалистичной физике, но без детальной проработки повреждений и т.п.
Другое дело, что все эти игры с физикой - в реальном времени, и редко ставят серьёзные задачи, их цель - забавное времяпрепровождение, а не хардкорный выживач. Поэтому недостатки физического движка компенсируются несерьёзностью происходящего на экране, даже наоборот, добавляя комичности.
Твоя же игра пошаговая, поэтому основная сложность - увязать физику с пошаговостью. Мне кажется, ты просто слишком зафиксировался на жанре рогаликов с его квадратно-гнездовым полем боя, и поэтому не смог на полную раскрыть физику. Если бы ты пошёл дальше, логично было бы отказаться от каноничного движения по клеточкам, сохранив только пошаговость (время идёт после действия игрока, затем мир снова замораживается, ожидая решения игрока)... Добавить ещё скольжение как по льду и вообще кайф будет, успевай только шинковать врагов на куски и уворачиваться от их острых клинков, всё с учётом физического скольжения с отскоками, но пошагово. Отбрось реализм и будет весело, ты же не реалистичный боевой симулятор для тренировки солдат делаешь, а игру для получения удовольствия от геймплея.
Это же игра. Если механика создаёт интересные игровые ситуации, то она имеет смысл для игрока. Вот сейчас у тебя есть возможность разобрать любого противника на отдельные косточки и набить этими костями инвентарь или разбросать их по уровню - в этом нет смысла, потому что это ни на что не влияет и ни для чего не нужно, в этом нет фана (если ты не какой-то... костефил). А отбивание снарядов было бы полезным, даже если этому тяжело научиться, чтобы использовать регулярно. Кости тоже можно было бы сделать осмысленными, если бы был крафт костяных инструментов или хотя бы использование их как одноразовые отмычки для дверей.
>если ты делаешь какую-то часть геймплея действительно физичной, с массой там, с ускорением, с сопротивлением воздуха и прочим, то по хорошему, физичным нужно делать и все остальное, иначе получается какая-то кринжатура. Нужно моделировать физичные удары, физичную броню, физичные части тела, никаих ХП, никаких больше силы и ловкости.
Эм... Либо я не понял твою мысль, либо ты никогда не видел все эти, наверное, уже сотни игр построенных на сравнительно реалистичной физике, но без детальной проработки повреждений и т.п.
Другое дело, что все эти игры с физикой - в реальном времени, и редко ставят серьёзные задачи, их цель - забавное времяпрепровождение, а не хардкорный выживач. Поэтому недостатки физического движка компенсируются несерьёзностью происходящего на экране, даже наоборот, добавляя комичности.
Твоя же игра пошаговая, поэтому основная сложность - увязать физику с пошаговостью. Мне кажется, ты просто слишком зафиксировался на жанре рогаликов с его квадратно-гнездовым полем боя, и поэтому не смог на полную раскрыть физику. Если бы ты пошёл дальше, логично было бы отказаться от каноничного движения по клеточкам, сохранив только пошаговость (время идёт после действия игрока, затем мир снова замораживается, ожидая решения игрока)... Добавить ещё скольжение как по льду и вообще кайф будет, успевай только шинковать врагов на куски и уворачиваться от их острых клинков, всё с учётом физического скольжения с отскоками, но пошагово. Отбрось реализм и будет весело, ты же не реалистичный боевой симулятор для тренировки солдат делаешь, а игру для получения удовольствия от геймплея.
>Отбивание летящих в тебя предметов
>вера в осмысленность происходящего
Это же игра. Если механика создаёт интересные игровые ситуации, то она имеет смысл для игрока. Вот сейчас у тебя есть возможность разобрать любого противника на отдельные косточки и набить этими костями инвентарь или разбросать их по уровню - в этом нет смысла, потому что это ни на что не влияет и ни для чего не нужно, в этом нет фана (если ты не какой-то... костефил). А отбивание снарядов было бы полезным, даже если этому тяжело научиться, чтобы использовать регулярно. Кости тоже можно было бы сделать осмысленными, если бы был крафт костяных инструментов или хотя бы использование их как одноразовые отмычки для дверей.
>>866392
Вот кстати, до сих пор не могу понять, зачем ты их вообще реализовал. Потратил время на код, набил в игру кучу лишних спрайтов, а всё зачем? Чтобы игра зависла или крашнулась, когда игрок попробовал надеть кость на персонажа, лол? В большинстве игр костей вообще нет, даже враждебные скелеты не во всех играх оставляют после себя предмет "кость". Мясо после съедания не оставляет костей и т.д. В тех же играх, где такой предмет есть, его получение ограничено и у него есть конкретное применение - костная мука, костяной клей, инструменты из костей и т.д. Или хотя бы строительный блок "груда костей", если уж игра генерирует слишком много костей и тратить их особо некуда. Ну, декоративная мебель из костей... А у тебя кости просто есть, просто захламляют пространство. Применения им нет, кроме как намусорить в данже или захламить инвентарь. Они просто есть и раздражают своей бесполезностью, учитывая их огромное количество. В других играх тоже бывают "мусорные" предметы, но их там не так много или хотя бы как-то можно переработать, они не мешают, не перекрывают собой полезные вещи.
И после таких странных решений ты ещё говоришь, что отбить снаряд в пошаговой игре - это что-то, что может вызвать у игрока потерю веры в осмысленность происходящего. Да у тебя там каждый уровень бессмысленным мусором забит, а отбивание снарядов имело бы вполне конкретный и важный для игрока смысл - спасти свою жопу от пробивания летящим снарядом.
Но я не говорю, что ты должен что-то с костями делать. Может, у тебя такое видение: мол, игрок должен искать что-то ценное в груде бесполезного хлама. Чтобы игрок ценил полезные вещи на фоне кучи мусора. Только беда в том, что куча бесполезного мусора в игре выглядит как куча бесполезного мусора, а не как глубокая философская мысль мудрого разработчика. До широкой аудитории глубокие мысли редко доходят...
>>осмысленность происходящего
>Кости
Вот кстати, до сих пор не могу понять, зачем ты их вообще реализовал. Потратил время на код, набил в игру кучу лишних спрайтов, а всё зачем? Чтобы игра зависла или крашнулась, когда игрок попробовал надеть кость на персонажа, лол? В большинстве игр костей вообще нет, даже враждебные скелеты не во всех играх оставляют после себя предмет "кость". Мясо после съедания не оставляет костей и т.д. В тех же играх, где такой предмет есть, его получение ограничено и у него есть конкретное применение - костная мука, костяной клей, инструменты из костей и т.д. Или хотя бы строительный блок "груда костей", если уж игра генерирует слишком много костей и тратить их особо некуда. Ну, декоративная мебель из костей... А у тебя кости просто есть, просто захламляют пространство. Применения им нет, кроме как намусорить в данже или захламить инвентарь. Они просто есть и раздражают своей бесполезностью, учитывая их огромное количество. В других играх тоже бывают "мусорные" предметы, но их там не так много или хотя бы как-то можно переработать, они не мешают, не перекрывают собой полезные вещи.
И после таких странных решений ты ещё говоришь, что отбить снаряд в пошаговой игре - это что-то, что может вызвать у игрока потерю веры в осмысленность происходящего. Да у тебя там каждый уровень бессмысленным мусором забит, а отбивание снарядов имело бы вполне конкретный и важный для игрока смысл - спасти свою жопу от пробивания летящим снарядом.
Но я не говорю, что ты должен что-то с костями делать. Может, у тебя такое видение: мол, игрок должен искать что-то ценное в груде бесполезного хлама. Чтобы игрок ценил полезные вещи на фоне кучи мусора. Только беда в том, что куча бесполезного мусора в игре выглядит как куча бесполезного мусора, а не как глубокая философская мысль мудрого разработчика. До широкой аудитории глубокие мысли редко доходят...
>>866392
>>866397
Ну да, все так. Я не смог реализовать физику и по этому отказался от нее.
В таком случае нужно заново начинать, так как это уже абсолютно другая игра будет. Это примерно как если сказать "Ну вроде норм рогалик, но что-то ты зациклился на 2Д, переведи его в 3Д, пожалуйста. Ну чел..."
Ни об одной пошаговой игре без клеточек лично я не слышал. Super Hot не подходит, он не пошаговый. Может быть это и правда будет гениально, но пока у меня нет ресурсов на то чтобы это проверить.
Ну хорошо, сейчас они реально довольно бессмысленные. Надо уменьшить их количество и поднять урон, чтобы возложенная на них функция работала. Или вообще выпилить, раз они так всех раздражают.
Изначально кости существуют для того чтобы их кидать во врагов, когда другого оружия под рукой нет.
Ты абсолютно не понимаешь при помощи каких инструментов вообще реализуются фичи в играх.
Между добавлением костей и созданием механики столкновения объектов существует фундаментальное различие.
Для того чтобы добавить кости я буквально не написал НИ ОДНОЙ строчки кода. Я просто открыл таблицу с существами, нашел там колонку "дроп" и вписал туда "кости". И еще нарисовал несколько спрайтов. Все.
Захочу, могу так же убрать их или заменить на что либо угодно другое.
>>866397
>Мне кажется, ты просто слишком зафиксировался на жанре рогаликов с его квадратно-гнездовым полем боя, и поэтому не смог на полную раскрыть физику.
Ну да, все так. Я не смог реализовать физику и по этому отказался от нее.
>Если бы ты пошёл дальше, логично было бы отказаться от каноничного движения по клеточкам, сохранив только пошаговость
В таком случае нужно заново начинать, так как это уже абсолютно другая игра будет. Это примерно как если сказать "Ну вроде норм рогалик, но что-то ты зациклился на 2Д, переведи его в 3Д, пожалуйста. Ну чел..."
Ни об одной пошаговой игре без клеточек лично я не слышал. Super Hot не подходит, он не пошаговый. Может быть это и правда будет гениально, но пока у меня нет ресурсов на то чтобы это проверить.
>Кости
Ну хорошо, сейчас они реально довольно бессмысленные. Надо уменьшить их количество и поднять урон, чтобы возложенная на них функция работала. Или вообще выпилить, раз они так всех раздражают.
Изначально кости существуют для того чтобы их кидать во врагов, когда другого оружия под рукой нет.
>Зачем добавил кости, это лишний код
Ты абсолютно не понимаешь при помощи каких инструментов вообще реализуются фичи в играх.
Между добавлением костей и созданием механики столкновения объектов существует фундаментальное различие.
Для того чтобы добавить кости я буквально не написал НИ ОДНОЙ строчки кода. Я просто открыл таблицу с существами, нашел там колонку "дроп" и вписал туда "кости". И еще нарисовал несколько спрайтов. Все.
Захочу, могу так же убрать их или заменить на что либо угодно другое.
>>866491
Ну, чуть динамичнее и не по клеточкам...
Тащемто это простая задача, если тебя просят накинуть 3D ассеты (особенно уже готовые, бесплатные и т.п.) на тот же самый геймплей. Вместо тайлов стен будут кубики, вместо спрайтов персонажей - 3D модели, а в остальном игра останется без изменений. Так многие классические 2D игры перевели в 3D, просто заменив объекты на трёхмерные. И примерно так же делают различные 2D/3D визуализации ASCII-рогаликов.
Вот если тебя просят сделать 3D кубач с копанием вверх и вниз без экрана загрузки, тогда да, другая игра, но даже так можно что-то придумать, например, чтобы данж был по-прежнему по слоям и геймплей остался без изменений, но слои данжа видны одновременно друг над другом, без экрана загрузки, создавая ощущение ходьбы по многоуровневому зданию, а не по 2D плоскостям.
У меня ощущение, что где-то я такое видел, чтобы пошагово и без клеточек, но не могу вспомнить, где. Проще будет прототип накидать, чем вспомнить)
Тогда сделай чтобы они хотя бы стакались в инвентаре, если ещё не сделал. У меня было штук 20 костей и я не догадался, что их можно зачем-то бросать...
Предмет летит по клеточкам > проверяет, нет ли кого-то летящего в клеточке, на которую он сдвигается > если там кто-то есть, предметы сообщают друг другу "о, привет" и падают на землю в виде дропа или меняют векторы направления (ничего сложного в данном случае). Если сделать умнее, то нужно проверять размер объекта и бросать кубик, чтобы нельзя было монеткой в 100% случаев останавливать дротики; нужно также проверять прочность и скорость движения, чтобы нельзя было вяло падающей бумажкой останавливать стрелы и камни. Что-то не вижу какой-то сверхсложной математики, тут только if-else и пара сравнений параметров на больше/меньше, ну ещё можно векторы посчитать, но это уже следующий уровень. Или ты хотел прям реализм-реализм? Так ведь в квадратно-гнездовом мире игрок этот твой реализм разглядеть не сможет (или не захочет, ибо пришёл фишечки по сетке двигать, а не в симулятор космонавта играть).
Но это ведь тоже работа, и нарисовать достаточно красивые кости в большом количестве, имхо, не проще вышеописанной механики столкновений, особенно если ты не художник. Я это и имел в виду, ты нарисовал и вписал в файлы конфигурации игры кучу независимых костей, не придумав им ничего кроме метания от безысходности - я бы поленился и сделал только одну абстрактную кость, как в майнкрафте. Вот если бы у разных костей было разное применение (черепа на штыки для устрашения, бедренные кости - это натуральные дубинки, какие-то мелкие и тонкие кости для чего-то ещё вроде одноразовых отмычек, остальную рассыпуху на клей или тупо кидать), тогда я бы нарисовал побольше спрайтов (по 1 штуке на тип, лол).
>>866492
Не нужно совсем убирать, просто оставь все эти разнообразные спрайты как декорации на полу (стильно, подземно), а при подборе они будут стакаться в одну ячейку предмета "груда костей", из которой кости можно швырять или использовать для чего-то ещё (кости > костный клей > починка брони/оружия?), а можно дропнуть все кости сразу. Так они будут куда больше похожи на снаряды и меньше раздражать количеством, если игрок решил собрать кучку костей (ища какой-то предмет под ними) и потом вынужден бороться с заваленным костями инвертарём.
>абсолютно другая игра будет
Ну, чуть динамичнее и не по клеточкам...
>рогалик
>зациклился на 2Д, переведи его в 3Д
Тащемто это простая задача, если тебя просят накинуть 3D ассеты (особенно уже готовые, бесплатные и т.п.) на тот же самый геймплей. Вместо тайлов стен будут кубики, вместо спрайтов персонажей - 3D модели, а в остальном игра останется без изменений. Так многие классические 2D игры перевели в 3D, просто заменив объекты на трёхмерные. И примерно так же делают различные 2D/3D визуализации ASCII-рогаликов.
Вот если тебя просят сделать 3D кубач с копанием вверх и вниз без экрана загрузки, тогда да, другая игра, но даже так можно что-то придумать, например, чтобы данж был по-прежнему по слоям и геймплей остался без изменений, но слои данжа видны одновременно друг над другом, без экрана загрузки, создавая ощущение ходьбы по многоуровневому зданию, а не по 2D плоскостям.
>Ни об одной пошаговой игре без клеточек лично я не слышал. Super Hot не подходит, он не пошаговый.
У меня ощущение, что где-то я такое видел, чтобы пошагово и без клеточек, но не могу вспомнить, где. Проще будет прототип накидать, чем вспомнить)
>Изначально кости существуют для того чтобы их кидать во врагов
Тогда сделай чтобы они хотя бы стакались в инвентаре, если ещё не сделал. У меня было штук 20 костей и я не догадался, что их можно зачем-то бросать...
>созданием механики столкновения объектов
Предмет летит по клеточкам > проверяет, нет ли кого-то летящего в клеточке, на которую он сдвигается > если там кто-то есть, предметы сообщают друг другу "о, привет" и падают на землю в виде дропа или меняют векторы направления (ничего сложного в данном случае). Если сделать умнее, то нужно проверять размер объекта и бросать кубик, чтобы нельзя было монеткой в 100% случаев останавливать дротики; нужно также проверять прочность и скорость движения, чтобы нельзя было вяло падающей бумажкой останавливать стрелы и камни. Что-то не вижу какой-то сверхсложной математики, тут только if-else и пара сравнений параметров на больше/меньше, ну ещё можно векторы посчитать, но это уже следующий уровень. Или ты хотел прям реализм-реализм? Так ведь в квадратно-гнездовом мире игрок этот твой реализм разглядеть не сможет (или не захочет, ибо пришёл фишечки по сетке двигать, а не в симулятор космонавта играть).
>еще нарисовал несколько спрайтов
Но это ведь тоже работа, и нарисовать достаточно красивые кости в большом количестве, имхо, не проще вышеописанной механики столкновений, особенно если ты не художник. Я это и имел в виду, ты нарисовал и вписал в файлы конфигурации игры кучу независимых костей, не придумав им ничего кроме метания от безысходности - я бы поленился и сделал только одну абстрактную кость, как в майнкрафте. Вот если бы у разных костей было разное применение (черепа на штыки для устрашения, бедренные кости - это натуральные дубинки, какие-то мелкие и тонкие кости для чего-то ещё вроде одноразовых отмычек, остальную рассыпуху на клей или тупо кидать), тогда я бы нарисовал побольше спрайтов (по 1 штуке на тип, лол).
>>866492
>убрать кости
Не нужно совсем убирать, просто оставь все эти разнообразные спрайты как декорации на полу (стильно, подземно), а при подборе они будут стакаться в одну ячейку предмета "груда костей", из которой кости можно швырять или использовать для чего-то ещё (кости > костный клей > починка брони/оружия?), а можно дропнуть все кости сразу. Так они будут куда больше похожи на снаряды и меньше раздражать количеством, если игрок решил собрать кучку костей (ища какой-то предмет под ними) и потом вынужден бороться с заваленным костями инвертарём.
>>866491
Ну, чуть динамичнее и не по клеточкам...
Тащемто это простая задача, если тебя просят накинуть 3D ассеты (особенно уже готовые, бесплатные и т.п.) на тот же самый геймплей. Вместо тайлов стен будут кубики, вместо спрайтов персонажей - 3D модели, а в остальном игра останется без изменений. Так многие классические 2D игры перевели в 3D, просто заменив объекты на трёхмерные. И примерно так же делают различные 2D/3D визуализации ASCII-рогаликов.
Вот если тебя просят сделать 3D кубач с копанием вверх и вниз без экрана загрузки, тогда да, другая игра, но даже так можно что-то придумать, например, чтобы данж был по-прежнему по слоям и геймплей остался без изменений, но слои данжа видны одновременно друг над другом, без экрана загрузки, создавая ощущение ходьбы по многоуровневому зданию, а не по 2D плоскостям.
У меня ощущение, что где-то я такое видел, чтобы пошагово и без клеточек, но не могу вспомнить, где. Проще будет прототип накидать, чем вспомнить)
Тогда сделай чтобы они хотя бы стакались в инвентаре, если ещё не сделал. У меня было штук 20 костей и я не догадался, что их можно зачем-то бросать...
Предмет летит по клеточкам > проверяет, нет ли кого-то летящего в клеточке, на которую он сдвигается > если там кто-то есть, предметы сообщают друг другу "о, привет" и падают на землю в виде дропа или меняют векторы направления (ничего сложного в данном случае). Если сделать умнее, то нужно проверять размер объекта и бросать кубик, чтобы нельзя было монеткой в 100% случаев останавливать дротики; нужно также проверять прочность и скорость движения, чтобы нельзя было вяло падающей бумажкой останавливать стрелы и камни. Что-то не вижу какой-то сверхсложной математики, тут только if-else и пара сравнений параметров на больше/меньше, ну ещё можно векторы посчитать, но это уже следующий уровень. Или ты хотел прям реализм-реализм? Так ведь в квадратно-гнездовом мире игрок этот твой реализм разглядеть не сможет (или не захочет, ибо пришёл фишечки по сетке двигать, а не в симулятор космонавта играть).
Но это ведь тоже работа, и нарисовать достаточно красивые кости в большом количестве, имхо, не проще вышеописанной механики столкновений, особенно если ты не художник. Я это и имел в виду, ты нарисовал и вписал в файлы конфигурации игры кучу независимых костей, не придумав им ничего кроме метания от безысходности - я бы поленился и сделал только одну абстрактную кость, как в майнкрафте. Вот если бы у разных костей было разное применение (черепа на штыки для устрашения, бедренные кости - это натуральные дубинки, какие-то мелкие и тонкие кости для чего-то ещё вроде одноразовых отмычек, остальную рассыпуху на клей или тупо кидать), тогда я бы нарисовал побольше спрайтов (по 1 штуке на тип, лол).
>>866492
Не нужно совсем убирать, просто оставь все эти разнообразные спрайты как декорации на полу (стильно, подземно), а при подборе они будут стакаться в одну ячейку предмета "груда костей", из которой кости можно швырять или использовать для чего-то ещё (кости > костный клей > починка брони/оружия?), а можно дропнуть все кости сразу. Так они будут куда больше похожи на снаряды и меньше раздражать количеством, если игрок решил собрать кучку костей (ища какой-то предмет под ними) и потом вынужден бороться с заваленным костями инвертарём.
>абсолютно другая игра будет
Ну, чуть динамичнее и не по клеточкам...
>рогалик
>зациклился на 2Д, переведи его в 3Д
Тащемто это простая задача, если тебя просят накинуть 3D ассеты (особенно уже готовые, бесплатные и т.п.) на тот же самый геймплей. Вместо тайлов стен будут кубики, вместо спрайтов персонажей - 3D модели, а в остальном игра останется без изменений. Так многие классические 2D игры перевели в 3D, просто заменив объекты на трёхмерные. И примерно так же делают различные 2D/3D визуализации ASCII-рогаликов.
Вот если тебя просят сделать 3D кубач с копанием вверх и вниз без экрана загрузки, тогда да, другая игра, но даже так можно что-то придумать, например, чтобы данж был по-прежнему по слоям и геймплей остался без изменений, но слои данжа видны одновременно друг над другом, без экрана загрузки, создавая ощущение ходьбы по многоуровневому зданию, а не по 2D плоскостям.
>Ни об одной пошаговой игре без клеточек лично я не слышал. Super Hot не подходит, он не пошаговый.
У меня ощущение, что где-то я такое видел, чтобы пошагово и без клеточек, но не могу вспомнить, где. Проще будет прототип накидать, чем вспомнить)
>Изначально кости существуют для того чтобы их кидать во врагов
Тогда сделай чтобы они хотя бы стакались в инвентаре, если ещё не сделал. У меня было штук 20 костей и я не догадался, что их можно зачем-то бросать...
>созданием механики столкновения объектов
Предмет летит по клеточкам > проверяет, нет ли кого-то летящего в клеточке, на которую он сдвигается > если там кто-то есть, предметы сообщают друг другу "о, привет" и падают на землю в виде дропа или меняют векторы направления (ничего сложного в данном случае). Если сделать умнее, то нужно проверять размер объекта и бросать кубик, чтобы нельзя было монеткой в 100% случаев останавливать дротики; нужно также проверять прочность и скорость движения, чтобы нельзя было вяло падающей бумажкой останавливать стрелы и камни. Что-то не вижу какой-то сверхсложной математики, тут только if-else и пара сравнений параметров на больше/меньше, ну ещё можно векторы посчитать, но это уже следующий уровень. Или ты хотел прям реализм-реализм? Так ведь в квадратно-гнездовом мире игрок этот твой реализм разглядеть не сможет (или не захочет, ибо пришёл фишечки по сетке двигать, а не в симулятор космонавта играть).
>еще нарисовал несколько спрайтов
Но это ведь тоже работа, и нарисовать достаточно красивые кости в большом количестве, имхо, не проще вышеописанной механики столкновений, особенно если ты не художник. Я это и имел в виду, ты нарисовал и вписал в файлы конфигурации игры кучу независимых костей, не придумав им ничего кроме метания от безысходности - я бы поленился и сделал только одну абстрактную кость, как в майнкрафте. Вот если бы у разных костей было разное применение (черепа на штыки для устрашения, бедренные кости - это натуральные дубинки, какие-то мелкие и тонкие кости для чего-то ещё вроде одноразовых отмычек, остальную рассыпуху на клей или тупо кидать), тогда я бы нарисовал побольше спрайтов (по 1 штуке на тип, лол).
>>866492
>убрать кости
Не нужно совсем убирать, просто оставь все эти разнообразные спрайты как декорации на полу (стильно, подземно), а при подборе они будут стакаться в одну ячейку предмета "груда костей", из которой кости можно швырять или использовать для чего-то ещё (кости > костный клей > починка брони/оружия?), а можно дропнуть все кости сразу. Так они будут куда больше похожи на снаряды и меньше раздражать количеством, если игрок решил собрать кучку костей (ища какой-то предмет под ними) и потом вынужден бороться с заваленным костями инвертарём.
9,5 Мб, mp4,800x600, 2:50
>>866583
- Пошаговость "пусть весь мир подождёт" с регулировкой затрат времени хода тиками: есть.
- Физическая симуляция движения импульсами, отскоков от стен, падений в ямы и пинков мобов: есть.
- Многоуровневый данж с переходом между уровнями в обоих направлениях: есть (процедурную генерацию потом можно прикрутить, это сейчас не важно).
- Упавшие в яму мобы падают на этаж ниже: есть.
Хотел ещё набросать метательное оружие, чтобы показать столкновение предметов в полёте, но сегодня мне уже лень этим заниматься. Ограничился пинком.
Скажу так, идея оправдала себя только частично:
1. Управление "оттяни и отпусти" какое-то неудобное получилось, хотя должно было быть интуитивно простым. Скорее всего я перемудрил с виртуальным джойстиком, из-за этого сам путаюсь в управлении. Потом другие варианты попробую, как-то по-другому я это себе представлял.
2. Проходить в проходы шириной в одну клетку очень неудобно даже несмотря на отскоки и заниженный физический размер персонажа (он примерно в два раза тоньше прохода). Научиться можно, но я ожидал чего-то другого... не знаю, как описать. Типа, я ожидал, что герой за счёт своей сферической геометрии будет проскальзывать в узкие проходы, а он как будто застревает, задевая углы. Трение в физических материалах выкрутил в 0. Может, дело в слишком сильных отскоках? Типа, от любого угла отлетает как мячик, вместо скольжения. Но совсем без отскоков получается как-то вяло.
3. Сначала я сохранял вектор скорости между ходами, но потом начал обнулять скорость после истечения таймера хода, которому потом прикрутил зависимость от силы рывка - чем сильнее, тем дольше ход и дальше движение (на видео только последний вариант). Но после тестирования мне кажется, что должен быть какой-то промежуточный вариант, чтобы выбирать - продолжать движение по намеченной траектории или резко свернуть в другом направлении. Потому что в первом варианте персонажа сложнее контролировать, а во втором он слишком заторможенный какой-то. Или нет? Наверное, нужно с первыми двумя проблемами разобраться.
4. В остальном, если решить эти проблемы, концепция на мой взгляд шикарна, имеет смысл развивать в направлении физики и способностей, основанных на физике. Можно много чего прикрутить из обычных рогаликов, но сделать это интереснее - вместо тупого заклинивания на одном месте можно было бы комбинировать движения, оружие и даже подвижные предметы окружения, всё под управлением физической симуляции. При этом на 100% сохраняется тактика за счёт достаточно предсказуемых траекторий (можно векторы точнее рисовать) и полной остановки симуляции до решения игрока. Т.е. всегда можно пойти заварить чай и подумать о смысле жизни, задумчиво смотря в окно, а потом сделать следующий ход. Скорость реакции игрока не играет совершенно никакой роли благодаря тому, что всё управление персонажем заблокировано, пока симуляция физики не остановится - хотя я оставил возможность оттягивать джойстик для следующего хода, чтобы геймплей был более быстрым.
Подводя итог, хочу сказать, что в этом всём нет ничего сложного. Я использую готовый физический движок (2D), приостанавливаю его работу - получаю пошаговость, внешне идентичную пошаговости игр с движением по клеткам - можно даже замерять число тиков движка и таким образом отмерять ходы, ограничивать действия ИИ и что там ещё. Даже странно, что не слышно об играх с такой механикой, потому что это вот буквально на поверхности лежит и не требует чего-то сложного. Может, это всё уже где-то было, но не взлетело? У меня стойкое чувство, что я где-то это видел... Возможно, в мобильной игре с очень примитивным геймплеем, но всё же.
>Проще будет прототип накидать
- Пошаговость "пусть весь мир подождёт" с регулировкой затрат времени хода тиками: есть.
- Физическая симуляция движения импульсами, отскоков от стен, падений в ямы и пинков мобов: есть.
- Многоуровневый данж с переходом между уровнями в обоих направлениях: есть (процедурную генерацию потом можно прикрутить, это сейчас не важно).
- Упавшие в яму мобы падают на этаж ниже: есть.
Хотел ещё набросать метательное оружие, чтобы показать столкновение предметов в полёте, но сегодня мне уже лень этим заниматься. Ограничился пинком.
Скажу так, идея оправдала себя только частично:
1. Управление "оттяни и отпусти" какое-то неудобное получилось, хотя должно было быть интуитивно простым. Скорее всего я перемудрил с виртуальным джойстиком, из-за этого сам путаюсь в управлении. Потом другие варианты попробую, как-то по-другому я это себе представлял.
2. Проходить в проходы шириной в одну клетку очень неудобно даже несмотря на отскоки и заниженный физический размер персонажа (он примерно в два раза тоньше прохода). Научиться можно, но я ожидал чего-то другого... не знаю, как описать. Типа, я ожидал, что герой за счёт своей сферической геометрии будет проскальзывать в узкие проходы, а он как будто застревает, задевая углы. Трение в физических материалах выкрутил в 0. Может, дело в слишком сильных отскоках? Типа, от любого угла отлетает как мячик, вместо скольжения. Но совсем без отскоков получается как-то вяло.
3. Сначала я сохранял вектор скорости между ходами, но потом начал обнулять скорость после истечения таймера хода, которому потом прикрутил зависимость от силы рывка - чем сильнее, тем дольше ход и дальше движение (на видео только последний вариант). Но после тестирования мне кажется, что должен быть какой-то промежуточный вариант, чтобы выбирать - продолжать движение по намеченной траектории или резко свернуть в другом направлении. Потому что в первом варианте персонажа сложнее контролировать, а во втором он слишком заторможенный какой-то. Или нет? Наверное, нужно с первыми двумя проблемами разобраться.
4. В остальном, если решить эти проблемы, концепция на мой взгляд шикарна, имеет смысл развивать в направлении физики и способностей, основанных на физике. Можно много чего прикрутить из обычных рогаликов, но сделать это интереснее - вместо тупого заклинивания на одном месте можно было бы комбинировать движения, оружие и даже подвижные предметы окружения, всё под управлением физической симуляции. При этом на 100% сохраняется тактика за счёт достаточно предсказуемых траекторий (можно векторы точнее рисовать) и полной остановки симуляции до решения игрока. Т.е. всегда можно пойти заварить чай и подумать о смысле жизни, задумчиво смотря в окно, а потом сделать следующий ход. Скорость реакции игрока не играет совершенно никакой роли благодаря тому, что всё управление персонажем заблокировано, пока симуляция физики не остановится - хотя я оставил возможность оттягивать джойстик для следующего хода, чтобы геймплей был более быстрым.
Подводя итог, хочу сказать, что в этом всём нет ничего сложного. Я использую готовый физический движок (2D), приостанавливаю его работу - получаю пошаговость, внешне идентичную пошаговости игр с движением по клеткам - можно даже замерять число тиков движка и таким образом отмерять ходы, ограничивать действия ИИ и что там ещё. Даже странно, что не слышно об играх с такой механикой, потому что это вот буквально на поверхности лежит и не требует чего-то сложного. Может, это всё уже где-то было, но не взлетело? У меня стойкое чувство, что я где-то это видел... Возможно, в мобильной игре с очень примитивным геймплеем, но всё же.
9,5 Мб, mp4,800x600, 2:50
>>866583
- Пошаговость "пусть весь мир подождёт" с регулировкой затрат времени хода тиками: есть.
- Физическая симуляция движения импульсами, отскоков от стен, падений в ямы и пинков мобов: есть.
- Многоуровневый данж с переходом между уровнями в обоих направлениях: есть (процедурную генерацию потом можно прикрутить, это сейчас не важно).
- Упавшие в яму мобы падают на этаж ниже: есть.
Хотел ещё набросать метательное оружие, чтобы показать столкновение предметов в полёте, но сегодня мне уже лень этим заниматься. Ограничился пинком.
Скажу так, идея оправдала себя только частично:
1. Управление "оттяни и отпусти" какое-то неудобное получилось, хотя должно было быть интуитивно простым. Скорее всего я перемудрил с виртуальным джойстиком, из-за этого сам путаюсь в управлении. Потом другие варианты попробую, как-то по-другому я это себе представлял.
2. Проходить в проходы шириной в одну клетку очень неудобно даже несмотря на отскоки и заниженный физический размер персонажа (он примерно в два раза тоньше прохода). Научиться можно, но я ожидал чего-то другого... не знаю, как описать. Типа, я ожидал, что герой за счёт своей сферической геометрии будет проскальзывать в узкие проходы, а он как будто застревает, задевая углы. Трение в физических материалах выкрутил в 0. Может, дело в слишком сильных отскоках? Типа, от любого угла отлетает как мячик, вместо скольжения. Но совсем без отскоков получается как-то вяло.
3. Сначала я сохранял вектор скорости между ходами, но потом начал обнулять скорость после истечения таймера хода, которому потом прикрутил зависимость от силы рывка - чем сильнее, тем дольше ход и дальше движение (на видео только последний вариант). Но после тестирования мне кажется, что должен быть какой-то промежуточный вариант, чтобы выбирать - продолжать движение по намеченной траектории или резко свернуть в другом направлении. Потому что в первом варианте персонажа сложнее контролировать, а во втором он слишком заторможенный какой-то. Или нет? Наверное, нужно с первыми двумя проблемами разобраться.
4. В остальном, если решить эти проблемы, концепция на мой взгляд шикарна, имеет смысл развивать в направлении физики и способностей, основанных на физике. Можно много чего прикрутить из обычных рогаликов, но сделать это интереснее - вместо тупого заклинивания на одном месте можно было бы комбинировать движения, оружие и даже подвижные предметы окружения, всё под управлением физической симуляции. При этом на 100% сохраняется тактика за счёт достаточно предсказуемых траекторий (можно векторы точнее рисовать) и полной остановки симуляции до решения игрока. Т.е. всегда можно пойти заварить чай и подумать о смысле жизни, задумчиво смотря в окно, а потом сделать следующий ход. Скорость реакции игрока не играет совершенно никакой роли благодаря тому, что всё управление персонажем заблокировано, пока симуляция физики не остановится - хотя я оставил возможность оттягивать джойстик для следующего хода, чтобы геймплей был более быстрым.
Подводя итог, хочу сказать, что в этом всём нет ничего сложного. Я использую готовый физический движок (2D), приостанавливаю его работу - получаю пошаговость, внешне идентичную пошаговости игр с движением по клеткам - можно даже замерять число тиков движка и таким образом отмерять ходы, ограничивать действия ИИ и что там ещё. Даже странно, что не слышно об играх с такой механикой, потому что это вот буквально на поверхности лежит и не требует чего-то сложного. Может, это всё уже где-то было, но не взлетело? У меня стойкое чувство, что я где-то это видел... Возможно, в мобильной игре с очень примитивным геймплеем, но всё же.
>Проще будет прототип накидать
- Пошаговость "пусть весь мир подождёт" с регулировкой затрат времени хода тиками: есть.
- Физическая симуляция движения импульсами, отскоков от стен, падений в ямы и пинков мобов: есть.
- Многоуровневый данж с переходом между уровнями в обоих направлениях: есть (процедурную генерацию потом можно прикрутить, это сейчас не важно).
- Упавшие в яму мобы падают на этаж ниже: есть.
Хотел ещё набросать метательное оружие, чтобы показать столкновение предметов в полёте, но сегодня мне уже лень этим заниматься. Ограничился пинком.
Скажу так, идея оправдала себя только частично:
1. Управление "оттяни и отпусти" какое-то неудобное получилось, хотя должно было быть интуитивно простым. Скорее всего я перемудрил с виртуальным джойстиком, из-за этого сам путаюсь в управлении. Потом другие варианты попробую, как-то по-другому я это себе представлял.
2. Проходить в проходы шириной в одну клетку очень неудобно даже несмотря на отскоки и заниженный физический размер персонажа (он примерно в два раза тоньше прохода). Научиться можно, но я ожидал чего-то другого... не знаю, как описать. Типа, я ожидал, что герой за счёт своей сферической геометрии будет проскальзывать в узкие проходы, а он как будто застревает, задевая углы. Трение в физических материалах выкрутил в 0. Может, дело в слишком сильных отскоках? Типа, от любого угла отлетает как мячик, вместо скольжения. Но совсем без отскоков получается как-то вяло.
3. Сначала я сохранял вектор скорости между ходами, но потом начал обнулять скорость после истечения таймера хода, которому потом прикрутил зависимость от силы рывка - чем сильнее, тем дольше ход и дальше движение (на видео только последний вариант). Но после тестирования мне кажется, что должен быть какой-то промежуточный вариант, чтобы выбирать - продолжать движение по намеченной траектории или резко свернуть в другом направлении. Потому что в первом варианте персонажа сложнее контролировать, а во втором он слишком заторможенный какой-то. Или нет? Наверное, нужно с первыми двумя проблемами разобраться.
4. В остальном, если решить эти проблемы, концепция на мой взгляд шикарна, имеет смысл развивать в направлении физики и способностей, основанных на физике. Можно много чего прикрутить из обычных рогаликов, но сделать это интереснее - вместо тупого заклинивания на одном месте можно было бы комбинировать движения, оружие и даже подвижные предметы окружения, всё под управлением физической симуляции. При этом на 100% сохраняется тактика за счёт достаточно предсказуемых траекторий (можно векторы точнее рисовать) и полной остановки симуляции до решения игрока. Т.е. всегда можно пойти заварить чай и подумать о смысле жизни, задумчиво смотря в окно, а потом сделать следующий ход. Скорость реакции игрока не играет совершенно никакой роли благодаря тому, что всё управление персонажем заблокировано, пока симуляция физики не остановится - хотя я оставил возможность оттягивать джойстик для следующего хода, чтобы геймплей был более быстрым.
Подводя итог, хочу сказать, что в этом всём нет ничего сложного. Я использую готовый физический движок (2D), приостанавливаю его работу - получаю пошаговость, внешне идентичную пошаговости игр с движением по клеткам - можно даже замерять число тиков движка и таким образом отмерять ходы, ограничивать действия ИИ и что там ещё. Даже странно, что не слышно об играх с такой механикой, потому что это вот буквально на поверхности лежит и не требует чего-то сложного. Может, это всё уже где-то было, но не взлетело? У меня стойкое чувство, что я где-то это видел... Возможно, в мобильной игре с очень примитивным геймплеем, но всё же.
>>866799
можно движение как в тотал варе сделать
можно движение как в тотал варе сделать
Держу в курсе: я зарефакторил и частично переписал все что касалось сохранений, эксель таблиц и баз данных.
Я думаю нет смысла в подробностях описывать что там было не так, скажу только что теперь все это написано значительно более правильно: один класс - одна ответственность, все нормально расширяется, нет кучи публичных полей и так далее.
Я молодец.
Теперь надо бы переделать еще некоторые части которые совсем плохие.
Например, у меня есть класс UIManager к которому ты обращаешься каждый раз когда хочешь открыть какой-то UI экран. При открытии некоторых UI бывает так, что нужно сделать еще какое-то действие, например обновить статы которые на этом экране отображаются. Для этого UIManager прогоняет тип открываемого экрана через switch, узнает таким образом какое действие нужно произвести после открытия и залезая в публичные поля экрана делает то что нужно сделать. Это называется ВАРВАРСТВО
- Оп
Я думаю нет смысла в подробностях описывать что там было не так, скажу только что теперь все это написано значительно более правильно: один класс - одна ответственность, все нормально расширяется, нет кучи публичных полей и так далее.
Я молодец.
Теперь надо бы переделать еще некоторые части которые совсем плохие.
Например, у меня есть класс UIManager к которому ты обращаешься каждый раз когда хочешь открыть какой-то UI экран. При открытии некоторых UI бывает так, что нужно сделать еще какое-то действие, например обновить статы которые на этом экране отображаются. Для этого UIManager прогоняет тип открываемого экрана через switch, узнает таким образом какое действие нужно произвести после открытия и залезая в публичные поля экрана делает то что нужно сделать. Это называется ВАРВАРСТВО
- Оп
>>868553
Эьто нетак делается, у тебя экраны юи должны быть подписаны на события изменения состояний отображаемых сущностей
Эьто нетак делается, у тебя экраны юи должны быть подписаны на события изменения состояний отображаемых сущностей
>>866799
О, скотобаза-дев, здравствуйте. Какое прекрасное исследование.
Мне лично кажется, что одна из причин отсутствия пошаговых игр без клеточек в том что игрок не может точно сопоставлять недискретные пространственные величины с дискретными временными величинами. Иными словами - игрок видит определенное расстояние и не понимает за сколько ходов он его преодолеет.
Таким образом, он не может точно установить, успеет ли он сделать то или иное действие за определенное количество ходов, и вообще все становится значительно менее предсказуемым, а значит, сколько не думай между ходами, это мало что даст. Само по себе недискретное пространство ведет к возникновению большого количества рандома, который сложно контроллировать.
- Оп
О, скотобаза-дев, здравствуйте. Какое прекрасное исследование.
Мне лично кажется, что одна из причин отсутствия пошаговых игр без клеточек в том что игрок не может точно сопоставлять недискретные пространственные величины с дискретными временными величинами. Иными словами - игрок видит определенное расстояние и не понимает за сколько ходов он его преодолеет.
Таким образом, он не может точно установить, успеет ли он сделать то или иное действие за определенное количество ходов, и вообще все становится значительно менее предсказуемым, а значит, сколько не думай между ходами, это мало что даст. Само по себе недискретное пространство ведет к возникновению большого количества рандома, который сложно контроллировать.
- Оп
>>868556
А бывает так, что процесс отображения является довольно дорогим. Тогда его следует приводить в действие только тогда необходимо, а именно при открытии соответствующего экрана.
Да и из за того что я работаю с ECS, события обеспечивающие связь именно данных и UI я не очень хорошо могу использовать
Мне кажется, лучше сделать абстрактный синглтон Экран с двумя методами Открыть и Закрыть. И еще с двумя событиями "открылся" и "закрылся"
А UIManager пускай подпишется на эти события чтобы хранить инфу о том какие экраны сейчас открыты.
-ОП
А бывает так, что процесс отображения является довольно дорогим. Тогда его следует приводить в действие только тогда необходимо, а именно при открытии соответствующего экрана.
Да и из за того что я работаю с ECS, события обеспечивающие связь именно данных и UI я не очень хорошо могу использовать
Мне кажется, лучше сделать абстрактный синглтон Экран с двумя методами Открыть и Закрыть. И еще с двумя событиями "открылся" и "закрылся"
А UIManager пускай подпишется на эти события чтобы хранить инфу о том какие экраны сейчас открыты.
-ОП
8 Кб, 436x480>>868553
Следуй паттерну MVC:
- Model: это твоя игра - мир, лут, мобы, окошки.
- View: это графика игры, включая спрайты и GUI, которая отображает состояние Model. Этот >>868556 правильно говорит, нужно использовать события (event) для обновления View по мере необходимости.
- Controller: это кнопки, физические и виртуальные, и другие интерактивные элементы GUI, через которые игрок оказывает воздействие на Model.
Т.е. получается как-то так:
1. Игрок нажимает tab, желая открыть инвентарь.
2. Контроллер передаёт модели запрос на открытие инвентаря (игровая сущность).
3. Модель проверяет, можно ли в данный момент открыть инвентарь, и если можно, то открывает.
4. Представление регистрирует событие "у модели открылся инвентарь" и отображает меню инвентаря.
В результате твоя модель - это вещь в себе, которая никак не зависит ни от способа воздействия на неё, ни от способа отображения модели на экране. Модель только выставляет наружу свои интерфейсы для контроллера и события для представления, чтобы они могли влиять на модель и считывать её состояние, узнавать об изменениях. В остальном модель должна быть чёрной коробкой, которая ни с чем снаружи себя не взаимодействует и только делает что-то сама с собой внутри, реагируя на воздействия контроллера или течение времени.
Ну, могу ошибаться, но Википедия говорит, что конкретные реализации MVC могут отступать от базовой формулировки, так что, наверное, тут невозможно ошибиться. Всё-таки игровые движки типа Unity плохо ложатся на MVC, точнее, из-за обилия возможных решений сложно понять, как применить MVC для игры на таком движке. Типа, ты же можешь чему угодно скрипт с любым поведением навесить, такая свобода как бы развращает, и в итоге получаешь лапшу, где всё от всего зависит.
>>868565
Подписывайся на события типа "инвентарь открыт (актуальные данные инвентаря)", "справка о мобе открыта (данные моба)" и т.д. Тогда ты не будешь обновлять экраны, которые игрок не видит, получая информацию для GUI только в момент непосредственного открытия меню.
MVC. Твой UIManager по большому счёту View, только сделан наизнанку, т.е. вызывается из Model, а не считывает актуальное состояние Model по необходимости. Твоя Model не должна знать о существовании каких-либо GUI, она знает только о существовании инвентаря, лупы для изучения мобов и т.п. А уже твой "менеджер гуя" рисует всё что ты считаешь нужным, когда модель сообщает об открытии инвентаря или использовании лупы на мобе.
Превращает проект в тарелку лапши, пропускающей свои ниточки через несколько глобальных дырок, и если ты случайно что-то в этих глобальных дырках изменишь, то проект не запустится или сломается. Нужно избегать использования синглтонов как и любых других глобальных сущностей. Да, обычно у тебя всего один View, но он не синглтон, а просто подписчик на события Model, и при желании ты можешь сделать несколько View для одной Model. Пример: делаешь веб-морду для игры, чтобы можно было играть через браузер слабого телефона на сервере запущенной на мощном ПК игре без какого-либо стороннего ПО - у игры всё та же Model, но View используется другой, транслируя состояние Model в веб-морду, и он даже может работать одновременно с обычным View, отображающим менюшки на ПК, где крутится Model.
Следуй паттерну MVC:
- Model: это твоя игра - мир, лут, мобы, окошки.
- View: это графика игры, включая спрайты и GUI, которая отображает состояние Model. Этот >>868556 правильно говорит, нужно использовать события (event) для обновления View по мере необходимости.
- Controller: это кнопки, физические и виртуальные, и другие интерактивные элементы GUI, через которые игрок оказывает воздействие на Model.
Т.е. получается как-то так:
1. Игрок нажимает tab, желая открыть инвентарь.
2. Контроллер передаёт модели запрос на открытие инвентаря (игровая сущность).
3. Модель проверяет, можно ли в данный момент открыть инвентарь, и если можно, то открывает.
4. Представление регистрирует событие "у модели открылся инвентарь" и отображает меню инвентаря.
В результате твоя модель - это вещь в себе, которая никак не зависит ни от способа воздействия на неё, ни от способа отображения модели на экране. Модель только выставляет наружу свои интерфейсы для контроллера и события для представления, чтобы они могли влиять на модель и считывать её состояние, узнавать об изменениях. В остальном модель должна быть чёрной коробкой, которая ни с чем снаружи себя не взаимодействует и только делает что-то сама с собой внутри, реагируя на воздействия контроллера или течение времени.
Ну, могу ошибаться, но Википедия говорит, что конкретные реализации MVC могут отступать от базовой формулировки, так что, наверное, тут невозможно ошибиться. Всё-таки игровые движки типа Unity плохо ложатся на MVC, точнее, из-за обилия возможных решений сложно понять, как применить MVC для игры на таком движке. Типа, ты же можешь чему угодно скрипт с любым поведением навесить, такая свобода как бы развращает, и в итоге получаешь лапшу, где всё от всего зависит.
>>868565
>Тогда его следует приводить в действие только тогда необходимо, а именно при открытии соответствующего экрана.
Подписывайся на события типа "инвентарь открыт (актуальные данные инвентаря)", "справка о мобе открыта (данные моба)" и т.д. Тогда ты не будешь обновлять экраны, которые игрок не видит, получая информацию для GUI только в момент непосредственного открытия меню.
>Мне кажется, лучше сделать...
MVC. Твой UIManager по большому счёту View, только сделан наизнанку, т.е. вызывается из Model, а не считывает актуальное состояние Model по необходимости. Твоя Model не должна знать о существовании каких-либо GUI, она знает только о существовании инвентаря, лупы для изучения мобов и т.п. А уже твой "менеджер гуя" рисует всё что ты считаешь нужным, когда модель сообщает об открытии инвентаря или использовании лупы на мобе.
>синглтон
Превращает проект в тарелку лапши, пропускающей свои ниточки через несколько глобальных дырок, и если ты случайно что-то в этих глобальных дырках изменишь, то проект не запустится или сломается. Нужно избегать использования синглтонов как и любых других глобальных сущностей. Да, обычно у тебя всего один View, но он не синглтон, а просто подписчик на события Model, и при желании ты можешь сделать несколько View для одной Model. Пример: делаешь веб-морду для игры, чтобы можно было играть через браузер слабого телефона на сервере запущенной на мощном ПК игре без какого-либо стороннего ПО - у игры всё та же Model, но View используется другой, транслируя состояние Model в веб-морду, и он даже может работать одновременно с обычным View, отображающим менюшки на ПК, где крутится Model.
8 Кб, 436x480>>868553
Следуй паттерну MVC:
- Model: это твоя игра - мир, лут, мобы, окошки.
- View: это графика игры, включая спрайты и GUI, которая отображает состояние Model. Этот >>868556 правильно говорит, нужно использовать события (event) для обновления View по мере необходимости.
- Controller: это кнопки, физические и виртуальные, и другие интерактивные элементы GUI, через которые игрок оказывает воздействие на Model.
Т.е. получается как-то так:
1. Игрок нажимает tab, желая открыть инвентарь.
2. Контроллер передаёт модели запрос на открытие инвентаря (игровая сущность).
3. Модель проверяет, можно ли в данный момент открыть инвентарь, и если можно, то открывает.
4. Представление регистрирует событие "у модели открылся инвентарь" и отображает меню инвентаря.
В результате твоя модель - это вещь в себе, которая никак не зависит ни от способа воздействия на неё, ни от способа отображения модели на экране. Модель только выставляет наружу свои интерфейсы для контроллера и события для представления, чтобы они могли влиять на модель и считывать её состояние, узнавать об изменениях. В остальном модель должна быть чёрной коробкой, которая ни с чем снаружи себя не взаимодействует и только делает что-то сама с собой внутри, реагируя на воздействия контроллера или течение времени.
Ну, могу ошибаться, но Википедия говорит, что конкретные реализации MVC могут отступать от базовой формулировки, так что, наверное, тут невозможно ошибиться. Всё-таки игровые движки типа Unity плохо ложатся на MVC, точнее, из-за обилия возможных решений сложно понять, как применить MVC для игры на таком движке. Типа, ты же можешь чему угодно скрипт с любым поведением навесить, такая свобода как бы развращает, и в итоге получаешь лапшу, где всё от всего зависит.
>>868565
Подписывайся на события типа "инвентарь открыт (актуальные данные инвентаря)", "справка о мобе открыта (данные моба)" и т.д. Тогда ты не будешь обновлять экраны, которые игрок не видит, получая информацию для GUI только в момент непосредственного открытия меню.
MVC. Твой UIManager по большому счёту View, только сделан наизнанку, т.е. вызывается из Model, а не считывает актуальное состояние Model по необходимости. Твоя Model не должна знать о существовании каких-либо GUI, она знает только о существовании инвентаря, лупы для изучения мобов и т.п. А уже твой "менеджер гуя" рисует всё что ты считаешь нужным, когда модель сообщает об открытии инвентаря или использовании лупы на мобе.
Превращает проект в тарелку лапши, пропускающей свои ниточки через несколько глобальных дырок, и если ты случайно что-то в этих глобальных дырках изменишь, то проект не запустится или сломается. Нужно избегать использования синглтонов как и любых других глобальных сущностей. Да, обычно у тебя всего один View, но он не синглтон, а просто подписчик на события Model, и при желании ты можешь сделать несколько View для одной Model. Пример: делаешь веб-морду для игры, чтобы можно было играть через браузер слабого телефона на сервере запущенной на мощном ПК игре без какого-либо стороннего ПО - у игры всё та же Model, но View используется другой, транслируя состояние Model в веб-морду, и он даже может работать одновременно с обычным View, отображающим менюшки на ПК, где крутится Model.
Следуй паттерну MVC:
- Model: это твоя игра - мир, лут, мобы, окошки.
- View: это графика игры, включая спрайты и GUI, которая отображает состояние Model. Этот >>868556 правильно говорит, нужно использовать события (event) для обновления View по мере необходимости.
- Controller: это кнопки, физические и виртуальные, и другие интерактивные элементы GUI, через которые игрок оказывает воздействие на Model.
Т.е. получается как-то так:
1. Игрок нажимает tab, желая открыть инвентарь.
2. Контроллер передаёт модели запрос на открытие инвентаря (игровая сущность).
3. Модель проверяет, можно ли в данный момент открыть инвентарь, и если можно, то открывает.
4. Представление регистрирует событие "у модели открылся инвентарь" и отображает меню инвентаря.
В результате твоя модель - это вещь в себе, которая никак не зависит ни от способа воздействия на неё, ни от способа отображения модели на экране. Модель только выставляет наружу свои интерфейсы для контроллера и события для представления, чтобы они могли влиять на модель и считывать её состояние, узнавать об изменениях. В остальном модель должна быть чёрной коробкой, которая ни с чем снаружи себя не взаимодействует и только делает что-то сама с собой внутри, реагируя на воздействия контроллера или течение времени.
Ну, могу ошибаться, но Википедия говорит, что конкретные реализации MVC могут отступать от базовой формулировки, так что, наверное, тут невозможно ошибиться. Всё-таки игровые движки типа Unity плохо ложатся на MVC, точнее, из-за обилия возможных решений сложно понять, как применить MVC для игры на таком движке. Типа, ты же можешь чему угодно скрипт с любым поведением навесить, такая свобода как бы развращает, и в итоге получаешь лапшу, где всё от всего зависит.
>>868565
>Тогда его следует приводить в действие только тогда необходимо, а именно при открытии соответствующего экрана.
Подписывайся на события типа "инвентарь открыт (актуальные данные инвентаря)", "справка о мобе открыта (данные моба)" и т.д. Тогда ты не будешь обновлять экраны, которые игрок не видит, получая информацию для GUI только в момент непосредственного открытия меню.
>Мне кажется, лучше сделать...
MVC. Твой UIManager по большому счёту View, только сделан наизнанку, т.е. вызывается из Model, а не считывает актуальное состояние Model по необходимости. Твоя Model не должна знать о существовании каких-либо GUI, она знает только о существовании инвентаря, лупы для изучения мобов и т.п. А уже твой "менеджер гуя" рисует всё что ты считаешь нужным, когда модель сообщает об открытии инвентаря или использовании лупы на мобе.
>синглтон
Превращает проект в тарелку лапши, пропускающей свои ниточки через несколько глобальных дырок, и если ты случайно что-то в этих глобальных дырках изменишь, то проект не запустится или сломается. Нужно избегать использования синглтонов как и любых других глобальных сущностей. Да, обычно у тебя всего один View, но он не синглтон, а просто подписчик на события Model, и при желании ты можешь сделать несколько View для одной Model. Пример: делаешь веб-морду для игры, чтобы можно было играть через браузер слабого телефона на сервере запущенной на мощном ПК игре без какого-либо стороннего ПО - у игры всё та же Model, но View используется другой, транслируя состояние Model в веб-морду, и он даже может работать одновременно с обычным View, отображающим менюшки на ПК, где крутится Model.
60 Кб, 1179x872>>868563
Для близкого расстояния (один экран) достаточно указать стрелочкой и/или точками, куда побежит герой и с чем он гарантированно столкнётся (стены). Для дальнего расстояния точно знать количество ходов нет никакой необходимости, потому что даже в клеточном мире на большом расстоянии будут десятки, а то и сотни ходов, и считать их все перед принятием решения нерационально.
Так ведь рогалики построены вокруг рандома. Данж генерируется рандомно - в некоторых рогаликах ты даже не знаешь, повезло тебе с данжем или игра сгенерировала принципиально непроходимый данж. Свойства оружия, зелий, свитков, аксессуаров - всё рандомное и заранее неизвестно, ты можешь надеть колечко и сдохнуть от проклятия, о котором игра тебе вообще ничего не сообщила, когда ты изучал кольцо. Выпил зелье и сдох, потому что это оказался яд. Использовал свиток и сдох, потому что это был свиток жертвоприношения аццкому сотоне и рядом не оказалось подходящей жертвы, кроме тебя. Взял в руки меч и сдох от того, что меч оказался говорящим и насмешил тебя петросянскими анекдотами насмерть. Боёвка в рогаликах вообще торжество рандома: на каждый удар кидается виртуальный кубик, и ты можешь как ваншотнуть какого-то суперсолдата голой рукой, так и нанести 0 урона легендарным эскалибуром почти дохлой крысе с 1/10 хп и буквально 0 защиты. Рогалики высыпают на игрока тонну непредсказуемого рандома и в этом заключается фан рогаликов. В отличие от обычных игр, где ты после первого прохождения точно знаешь, что лечилка имеет красный цвет, а яд - зелёный, в рогаликах сколько ни играй, ты на каждом прохождении можешь травануться насмерть, не угадав с цветом жижи, поэтому опытный игрок предпочтёт вылить незнакомое зелье кому-нибудь на голову, а не себе в желудок.
И вот после всего этого ты говоришь, что движение без клеточек "слишком рандомное", "недостаточно предсказуемое" и поэтому, мол, не будет весело?
Кстати, вот есть Angry Birds. Да, это совсем не рогалик и игра не останавливает симуляцию физики до принятия игроком решения, но применение физики там похожее (оттянул и полетел). Мешает ли игре то, что физику сложно предсказать? Там головоломки, в которых ты должен предсказать полёт своей птицы, чтобы пройти игру с наименьшим числом попыток. Если бы игра была непредсказуемой из-за физики, головомки ощущались бы как непроходимые - их можно было бы пройти только случайным образом. Но нет, игра имела бешенный успех, особых жалоб на "непредсказуемость" что-то не слышал (ладно, я не изучал отзывы, последний раз играл когда-то очень давно, и вообще мне больше всего понравился спин-офф про свиней и их очумелые копытца, которыми они строят всякие машины, а основная игра про птиц меня лично вообще не привлекала).
Есть и другие головоломки, построенные вокруг 2D, а то и 3D физики. Да, физический движок может иногда глючить и ломать уровень, но в большинстве случаев ты можешь пройти уровень одним предсказуемым способом хотя бы в 9 из 10 запусков. Так что не вижу проблемы применить аналогичный подход к рогаликам, которые, в отличие от головоломок, построены вокруг непредсказуемого хаоса (рандомные уровни, рандомный лут, рандомный бой, рандомное всё), а не чётко спланированных задачек с единственным верным решением (головоломку хотя и можно решить тупым брутфорсом, обычно предполагается применение мозгов для поиска верного решения; рогалики же чаще строятся вокруг брутфорса - закликивания мобов случайно найденным мечом на +5 к остроте).
...Мне кажется, у нас тут какое-то недопонимание. Либо я не понимаю, что ты имеешь в виду, либо ты не понимаешь, в чём вообще фан рогалика. А фан рогаликов в том, что ты заранее не знаешь, что будет дальше, и можешь сдохнуть по любой рандомной, неизвестной заранее причине, а потом начать с нуля, утратив почти все знания, полученные на предыдущем забеге. Ты знаешь, что тебе нужно кушать вовремя и избегать злых мобов, но всё остальное - воля богини Рандома, на которую можно повлиять разве что кольцом на удачу.
На мой взгляд, для соответствия духу рогаликов физику нужно не просто прикрутить, а сделать более непредсказуемой - базовая физика почти полностью детерминирована (при одинаковых начальных условиях будет одинаковый результат, хаоса добавляет только погрешность операций с плавающей точкой, но и её можно избежать), её слишком легко предсказать, поэтому персонаж игрока должен рандомно отклоняться от курса, как бы случайно спотыкаясь. Путём прокачки параметров или нахождения особых аксессуаров игрок может снизить влияние этих спецдефектов, но даже персонаж 80 уровня должен иметь маленький шанс ошибиться и пролететь мимо заданной цели. Иначе игра будет слишком предсказуемой и, соответственно, скучной. Смысл играть в то, что ты заранее знаешь? Это как проходить одну и ту же головоломку больше одного раза - все решения тебе уже известны и игра больше неспособна тебя удивить, а поэтому проходить её повторно смысла нет.
Рогалики реиграбельны как раз благодаря их непредсказуемости - они способны удивить тебя чем-то даже спустя сотни часов копания на одном и том же уровне, даже если ты видел все тайлы и спрайты и знаешь все возможные зелья. Поэтому они и сформировались как жанр, и даже породили жанр рогулайтов для тех, кому полная утрата всего нажитого добра как-то не очень, но вот рандомные уровни с рандомным лутом и рандомным боем доставляют своей рандомностью. Это тебе не шахматы, в которых все ходы можно наперёд предсказать.
>Иными словами - игрок видит определенное расстояние и не понимает за сколько ходов он его преодолеет.
Для близкого расстояния (один экран) достаточно указать стрелочкой и/или точками, куда побежит герой и с чем он гарантированно столкнётся (стены). Для дальнего расстояния точно знать количество ходов нет никакой необходимости, потому что даже в клеточном мире на большом расстоянии будут десятки, а то и сотни ходов, и считать их все перед принятием решения нерационально.
>Таким образом, он не может точно установить, успеет ли он сделать то или иное действие за определенное количество ходов, и вообще все становится значительно менее предсказуемым, а значит, сколько не думай между ходами, это мало что даст. Само по себе недискретное пространство ведет к возникновению большого количества рандома, который сложно контроллировать.
Так ведь рогалики построены вокруг рандома. Данж генерируется рандомно - в некоторых рогаликах ты даже не знаешь, повезло тебе с данжем или игра сгенерировала принципиально непроходимый данж. Свойства оружия, зелий, свитков, аксессуаров - всё рандомное и заранее неизвестно, ты можешь надеть колечко и сдохнуть от проклятия, о котором игра тебе вообще ничего не сообщила, когда ты изучал кольцо. Выпил зелье и сдох, потому что это оказался яд. Использовал свиток и сдох, потому что это был свиток жертвоприношения аццкому сотоне и рядом не оказалось подходящей жертвы, кроме тебя. Взял в руки меч и сдох от того, что меч оказался говорящим и насмешил тебя петросянскими анекдотами насмерть. Боёвка в рогаликах вообще торжество рандома: на каждый удар кидается виртуальный кубик, и ты можешь как ваншотнуть какого-то суперсолдата голой рукой, так и нанести 0 урона легендарным эскалибуром почти дохлой крысе с 1/10 хп и буквально 0 защиты. Рогалики высыпают на игрока тонну непредсказуемого рандома и в этом заключается фан рогаликов. В отличие от обычных игр, где ты после первого прохождения точно знаешь, что лечилка имеет красный цвет, а яд - зелёный, в рогаликах сколько ни играй, ты на каждом прохождении можешь травануться насмерть, не угадав с цветом жижи, поэтому опытный игрок предпочтёт вылить незнакомое зелье кому-нибудь на голову, а не себе в желудок.
И вот после всего этого ты говоришь, что движение без клеточек "слишком рандомное", "недостаточно предсказуемое" и поэтому, мол, не будет весело?
Кстати, вот есть Angry Birds. Да, это совсем не рогалик и игра не останавливает симуляцию физики до принятия игроком решения, но применение физики там похожее (оттянул и полетел). Мешает ли игре то, что физику сложно предсказать? Там головоломки, в которых ты должен предсказать полёт своей птицы, чтобы пройти игру с наименьшим числом попыток. Если бы игра была непредсказуемой из-за физики, головомки ощущались бы как непроходимые - их можно было бы пройти только случайным образом. Но нет, игра имела бешенный успех, особых жалоб на "непредсказуемость" что-то не слышал (ладно, я не изучал отзывы, последний раз играл когда-то очень давно, и вообще мне больше всего понравился спин-офф про свиней и их очумелые копытца, которыми они строят всякие машины, а основная игра про птиц меня лично вообще не привлекала).
Есть и другие головоломки, построенные вокруг 2D, а то и 3D физики. Да, физический движок может иногда глючить и ломать уровень, но в большинстве случаев ты можешь пройти уровень одним предсказуемым способом хотя бы в 9 из 10 запусков. Так что не вижу проблемы применить аналогичный подход к рогаликам, которые, в отличие от головоломок, построены вокруг непредсказуемого хаоса (рандомные уровни, рандомный лут, рандомный бой, рандомное всё), а не чётко спланированных задачек с единственным верным решением (головоломку хотя и можно решить тупым брутфорсом, обычно предполагается применение мозгов для поиска верного решения; рогалики же чаще строятся вокруг брутфорса - закликивания мобов случайно найденным мечом на +5 к остроте).
...Мне кажется, у нас тут какое-то недопонимание. Либо я не понимаю, что ты имеешь в виду, либо ты не понимаешь, в чём вообще фан рогалика. А фан рогаликов в том, что ты заранее не знаешь, что будет дальше, и можешь сдохнуть по любой рандомной, неизвестной заранее причине, а потом начать с нуля, утратив почти все знания, полученные на предыдущем забеге. Ты знаешь, что тебе нужно кушать вовремя и избегать злых мобов, но всё остальное - воля богини Рандома, на которую можно повлиять разве что кольцом на удачу.
На мой взгляд, для соответствия духу рогаликов физику нужно не просто прикрутить, а сделать более непредсказуемой - базовая физика почти полностью детерминирована (при одинаковых начальных условиях будет одинаковый результат, хаоса добавляет только погрешность операций с плавающей точкой, но и её можно избежать), её слишком легко предсказать, поэтому персонаж игрока должен рандомно отклоняться от курса, как бы случайно спотыкаясь. Путём прокачки параметров или нахождения особых аксессуаров игрок может снизить влияние этих спецдефектов, но даже персонаж 80 уровня должен иметь маленький шанс ошибиться и пролететь мимо заданной цели. Иначе игра будет слишком предсказуемой и, соответственно, скучной. Смысл играть в то, что ты заранее знаешь? Это как проходить одну и ту же головоломку больше одного раза - все решения тебе уже известны и игра больше неспособна тебя удивить, а поэтому проходить её повторно смысла нет.
Рогалики реиграбельны как раз благодаря их непредсказуемости - они способны удивить тебя чем-то даже спустя сотни часов копания на одном и том же уровне, даже если ты видел все тайлы и спрайты и знаешь все возможные зелья. Поэтому они и сформировались как жанр, и даже породили жанр рогулайтов для тех, кому полная утрата всего нажитого добра как-то не очень, но вот рандомные уровни с рандомным лутом и рандомным боем доставляют своей рандомностью. Это тебе не шахматы, в которых все ходы можно наперёд предсказать.
60 Кб, 1179x872>>868563
Для близкого расстояния (один экран) достаточно указать стрелочкой и/или точками, куда побежит герой и с чем он гарантированно столкнётся (стены). Для дальнего расстояния точно знать количество ходов нет никакой необходимости, потому что даже в клеточном мире на большом расстоянии будут десятки, а то и сотни ходов, и считать их все перед принятием решения нерационально.
Так ведь рогалики построены вокруг рандома. Данж генерируется рандомно - в некоторых рогаликах ты даже не знаешь, повезло тебе с данжем или игра сгенерировала принципиально непроходимый данж. Свойства оружия, зелий, свитков, аксессуаров - всё рандомное и заранее неизвестно, ты можешь надеть колечко и сдохнуть от проклятия, о котором игра тебе вообще ничего не сообщила, когда ты изучал кольцо. Выпил зелье и сдох, потому что это оказался яд. Использовал свиток и сдох, потому что это был свиток жертвоприношения аццкому сотоне и рядом не оказалось подходящей жертвы, кроме тебя. Взял в руки меч и сдох от того, что меч оказался говорящим и насмешил тебя петросянскими анекдотами насмерть. Боёвка в рогаликах вообще торжество рандома: на каждый удар кидается виртуальный кубик, и ты можешь как ваншотнуть какого-то суперсолдата голой рукой, так и нанести 0 урона легендарным эскалибуром почти дохлой крысе с 1/10 хп и буквально 0 защиты. Рогалики высыпают на игрока тонну непредсказуемого рандома и в этом заключается фан рогаликов. В отличие от обычных игр, где ты после первого прохождения точно знаешь, что лечилка имеет красный цвет, а яд - зелёный, в рогаликах сколько ни играй, ты на каждом прохождении можешь травануться насмерть, не угадав с цветом жижи, поэтому опытный игрок предпочтёт вылить незнакомое зелье кому-нибудь на голову, а не себе в желудок.
И вот после всего этого ты говоришь, что движение без клеточек "слишком рандомное", "недостаточно предсказуемое" и поэтому, мол, не будет весело?
Кстати, вот есть Angry Birds. Да, это совсем не рогалик и игра не останавливает симуляцию физики до принятия игроком решения, но применение физики там похожее (оттянул и полетел). Мешает ли игре то, что физику сложно предсказать? Там головоломки, в которых ты должен предсказать полёт своей птицы, чтобы пройти игру с наименьшим числом попыток. Если бы игра была непредсказуемой из-за физики, головомки ощущались бы как непроходимые - их можно было бы пройти только случайным образом. Но нет, игра имела бешенный успех, особых жалоб на "непредсказуемость" что-то не слышал (ладно, я не изучал отзывы, последний раз играл когда-то очень давно, и вообще мне больше всего понравился спин-офф про свиней и их очумелые копытца, которыми они строят всякие машины, а основная игра про птиц меня лично вообще не привлекала).
Есть и другие головоломки, построенные вокруг 2D, а то и 3D физики. Да, физический движок может иногда глючить и ломать уровень, но в большинстве случаев ты можешь пройти уровень одним предсказуемым способом хотя бы в 9 из 10 запусков. Так что не вижу проблемы применить аналогичный подход к рогаликам, которые, в отличие от головоломок, построены вокруг непредсказуемого хаоса (рандомные уровни, рандомный лут, рандомный бой, рандомное всё), а не чётко спланированных задачек с единственным верным решением (головоломку хотя и можно решить тупым брутфорсом, обычно предполагается применение мозгов для поиска верного решения; рогалики же чаще строятся вокруг брутфорса - закликивания мобов случайно найденным мечом на +5 к остроте).
...Мне кажется, у нас тут какое-то недопонимание. Либо я не понимаю, что ты имеешь в виду, либо ты не понимаешь, в чём вообще фан рогалика. А фан рогаликов в том, что ты заранее не знаешь, что будет дальше, и можешь сдохнуть по любой рандомной, неизвестной заранее причине, а потом начать с нуля, утратив почти все знания, полученные на предыдущем забеге. Ты знаешь, что тебе нужно кушать вовремя и избегать злых мобов, но всё остальное - воля богини Рандома, на которую можно повлиять разве что кольцом на удачу.
На мой взгляд, для соответствия духу рогаликов физику нужно не просто прикрутить, а сделать более непредсказуемой - базовая физика почти полностью детерминирована (при одинаковых начальных условиях будет одинаковый результат, хаоса добавляет только погрешность операций с плавающей точкой, но и её можно избежать), её слишком легко предсказать, поэтому персонаж игрока должен рандомно отклоняться от курса, как бы случайно спотыкаясь. Путём прокачки параметров или нахождения особых аксессуаров игрок может снизить влияние этих спецдефектов, но даже персонаж 80 уровня должен иметь маленький шанс ошибиться и пролететь мимо заданной цели. Иначе игра будет слишком предсказуемой и, соответственно, скучной. Смысл играть в то, что ты заранее знаешь? Это как проходить одну и ту же головоломку больше одного раза - все решения тебе уже известны и игра больше неспособна тебя удивить, а поэтому проходить её повторно смысла нет.
Рогалики реиграбельны как раз благодаря их непредсказуемости - они способны удивить тебя чем-то даже спустя сотни часов копания на одном и том же уровне, даже если ты видел все тайлы и спрайты и знаешь все возможные зелья. Поэтому они и сформировались как жанр, и даже породили жанр рогулайтов для тех, кому полная утрата всего нажитого добра как-то не очень, но вот рандомные уровни с рандомным лутом и рандомным боем доставляют своей рандомностью. Это тебе не шахматы, в которых все ходы можно наперёд предсказать.
>Иными словами - игрок видит определенное расстояние и не понимает за сколько ходов он его преодолеет.
Для близкого расстояния (один экран) достаточно указать стрелочкой и/или точками, куда побежит герой и с чем он гарантированно столкнётся (стены). Для дальнего расстояния точно знать количество ходов нет никакой необходимости, потому что даже в клеточном мире на большом расстоянии будут десятки, а то и сотни ходов, и считать их все перед принятием решения нерационально.
>Таким образом, он не может точно установить, успеет ли он сделать то или иное действие за определенное количество ходов, и вообще все становится значительно менее предсказуемым, а значит, сколько не думай между ходами, это мало что даст. Само по себе недискретное пространство ведет к возникновению большого количества рандома, который сложно контроллировать.
Так ведь рогалики построены вокруг рандома. Данж генерируется рандомно - в некоторых рогаликах ты даже не знаешь, повезло тебе с данжем или игра сгенерировала принципиально непроходимый данж. Свойства оружия, зелий, свитков, аксессуаров - всё рандомное и заранее неизвестно, ты можешь надеть колечко и сдохнуть от проклятия, о котором игра тебе вообще ничего не сообщила, когда ты изучал кольцо. Выпил зелье и сдох, потому что это оказался яд. Использовал свиток и сдох, потому что это был свиток жертвоприношения аццкому сотоне и рядом не оказалось подходящей жертвы, кроме тебя. Взял в руки меч и сдох от того, что меч оказался говорящим и насмешил тебя петросянскими анекдотами насмерть. Боёвка в рогаликах вообще торжество рандома: на каждый удар кидается виртуальный кубик, и ты можешь как ваншотнуть какого-то суперсолдата голой рукой, так и нанести 0 урона легендарным эскалибуром почти дохлой крысе с 1/10 хп и буквально 0 защиты. Рогалики высыпают на игрока тонну непредсказуемого рандома и в этом заключается фан рогаликов. В отличие от обычных игр, где ты после первого прохождения точно знаешь, что лечилка имеет красный цвет, а яд - зелёный, в рогаликах сколько ни играй, ты на каждом прохождении можешь травануться насмерть, не угадав с цветом жижи, поэтому опытный игрок предпочтёт вылить незнакомое зелье кому-нибудь на голову, а не себе в желудок.
И вот после всего этого ты говоришь, что движение без клеточек "слишком рандомное", "недостаточно предсказуемое" и поэтому, мол, не будет весело?
Кстати, вот есть Angry Birds. Да, это совсем не рогалик и игра не останавливает симуляцию физики до принятия игроком решения, но применение физики там похожее (оттянул и полетел). Мешает ли игре то, что физику сложно предсказать? Там головоломки, в которых ты должен предсказать полёт своей птицы, чтобы пройти игру с наименьшим числом попыток. Если бы игра была непредсказуемой из-за физики, головомки ощущались бы как непроходимые - их можно было бы пройти только случайным образом. Но нет, игра имела бешенный успех, особых жалоб на "непредсказуемость" что-то не слышал (ладно, я не изучал отзывы, последний раз играл когда-то очень давно, и вообще мне больше всего понравился спин-офф про свиней и их очумелые копытца, которыми они строят всякие машины, а основная игра про птиц меня лично вообще не привлекала).
Есть и другие головоломки, построенные вокруг 2D, а то и 3D физики. Да, физический движок может иногда глючить и ломать уровень, но в большинстве случаев ты можешь пройти уровень одним предсказуемым способом хотя бы в 9 из 10 запусков. Так что не вижу проблемы применить аналогичный подход к рогаликам, которые, в отличие от головоломок, построены вокруг непредсказуемого хаоса (рандомные уровни, рандомный лут, рандомный бой, рандомное всё), а не чётко спланированных задачек с единственным верным решением (головоломку хотя и можно решить тупым брутфорсом, обычно предполагается применение мозгов для поиска верного решения; рогалики же чаще строятся вокруг брутфорса - закликивания мобов случайно найденным мечом на +5 к остроте).
...Мне кажется, у нас тут какое-то недопонимание. Либо я не понимаю, что ты имеешь в виду, либо ты не понимаешь, в чём вообще фан рогалика. А фан рогаликов в том, что ты заранее не знаешь, что будет дальше, и можешь сдохнуть по любой рандомной, неизвестной заранее причине, а потом начать с нуля, утратив почти все знания, полученные на предыдущем забеге. Ты знаешь, что тебе нужно кушать вовремя и избегать злых мобов, но всё остальное - воля богини Рандома, на которую можно повлиять разве что кольцом на удачу.
На мой взгляд, для соответствия духу рогаликов физику нужно не просто прикрутить, а сделать более непредсказуемой - базовая физика почти полностью детерминирована (при одинаковых начальных условиях будет одинаковый результат, хаоса добавляет только погрешность операций с плавающей точкой, но и её можно избежать), её слишком легко предсказать, поэтому персонаж игрока должен рандомно отклоняться от курса, как бы случайно спотыкаясь. Путём прокачки параметров или нахождения особых аксессуаров игрок может снизить влияние этих спецдефектов, но даже персонаж 80 уровня должен иметь маленький шанс ошибиться и пролететь мимо заданной цели. Иначе игра будет слишком предсказуемой и, соответственно, скучной. Смысл играть в то, что ты заранее знаешь? Это как проходить одну и ту же головоломку больше одного раза - все решения тебе уже известны и игра больше неспособна тебя удивить, а поэтому проходить её повторно смысла нет.
Рогалики реиграбельны как раз благодаря их непредсказуемости - они способны удивить тебя чем-то даже спустя сотни часов копания на одном и том же уровне, даже если ты видел все тайлы и спрайты и знаешь все возможные зелья. Поэтому они и сформировались как жанр, и даже породили жанр рогулайтов для тех, кому полная утрата всего нажитого добра как-то не очень, но вот рандомные уровни с рандомным лутом и рандомным боем доставляют своей рандомностью. Это тебе не шахматы, в которых все ходы можно наперёд предсказать.
>>868568
>>868563
Да, все верно я стараюсь следовать этой схеме, в последнее время по крайней мере.
Когда я написал что не могу использовать события я имел в виду случай когда, предположим есть класс Player в нем есть событие OnHealthChanged и на него подписываются всякие UI типо полосок здоровья. Я так не могу сделать, так как нет никакого класса Player. Есть только HealthSystem которая обрабатывает все сущности имеющие здоровье. Если я в ней заведу событие OnPlayersHealthChanged и буду каждый раз при переборе сущностей проверять, работаю я с игроком или нет, то это тоже как-то нехорошо будет.
А так, да, наверно в случае с этими экранами лучше без синглтона обойтись...
-Оп
>>868563
Да, все верно я стараюсь следовать этой схеме, в последнее время по крайней мере.
Когда я написал что не могу использовать события я имел в виду случай когда, предположим есть класс Player в нем есть событие OnHealthChanged и на него подписываются всякие UI типо полосок здоровья. Я так не могу сделать, так как нет никакого класса Player. Есть только HealthSystem которая обрабатывает все сущности имеющие здоровье. Если я в ней заведу событие OnPlayersHealthChanged и буду каждый раз при переборе сущностей проверять, работаю я с игроком или нет, то это тоже как-то нехорошо будет.
А так, да, наверно в случае с этими экранами лучше без синглтона обойтись...
-Оп
>>868576
Я в ECS не разбираюсь, но разве нельзя создать специальную систему "StatsMonitorSystem", которая будет работать только с игроком и проверять, изменились ли его параметры, и при изменении параметров генерировать событие?
Вообще, разве ECS требует обязательное следование определённой схеме во всём проекте? У ECS две стороны: дизайнерская (комбинация компонентов) и техническая (DOD, data oriented design). Применение ECS к единственной сущности - игроку - оправдано только с дизайнерской стороны, т.к. позволяет произвольно менять свойства игрока, добавляя и удаляя компоненты. С технической стороны применение ECS к игроку смысла не имеет, поскольку данных у игрока немного, а DOD даёт сколь-либо ощутимый эффект только на огромных массивах данных, к которым требуется применить одну и ту же операцию. То есть когда у тебя тысячи мобов с самыми разнообразными свойствами - ECS оправдан, а для единственного игрока смысла как бы и нет, если только ты не планируешь давать игроку возможность трансформироваться в любое существо и приобретать разные мутации.
Так вот, что мешает комбинировать ООП с ECS? В Unity есть какие-то рекомендации не смешивать подходы? Или какие-то другие причины?
>HealthSystem
>OnPlayersHealthChanged
Я в ECS не разбираюсь, но разве нельзя создать специальную систему "StatsMonitorSystem", которая будет работать только с игроком и проверять, изменились ли его параметры, и при изменении параметров генерировать событие?
Вообще, разве ECS требует обязательное следование определённой схеме во всём проекте? У ECS две стороны: дизайнерская (комбинация компонентов) и техническая (DOD, data oriented design). Применение ECS к единственной сущности - игроку - оправдано только с дизайнерской стороны, т.к. позволяет произвольно менять свойства игрока, добавляя и удаляя компоненты. С технической стороны применение ECS к игроку смысла не имеет, поскольку данных у игрока немного, а DOD даёт сколь-либо ощутимый эффект только на огромных массивах данных, к которым требуется применить одну и ту же операцию. То есть когда у тебя тысячи мобов с самыми разнообразными свойствами - ECS оправдан, а для единственного игрока смысла как бы и нет, если только ты не планируешь давать игроку возможность трансформироваться в любое существо и приобретать разные мутации.
Так вот, что мешает комбинировать ООП с ECS? В Unity есть какие-то рекомендации не смешивать подходы? Или какие-то другие причины?
>>868580
Комбинировать то конечно можно, что я по возможности и делаю.
Да, такой StatsMonitor возможен и даже не обязательно чтобы это была System, можно получать доступ к сущностям поштучно. Он может периодически каждый тик..? дергать игрока и сравнивать его статы с тем, какими они были в прошлый раз. Если надо, то можно так сделать, но, не знаю, на первый взгляд, для меня это выглядит как-то очень некрасиво. Нужно смотреть какой вариант хуже.
В любом случае, такой элегантности как в ооп, когда из того-же места где изменился параметр, срабатывает событие и сразу все подписчики оповещаются, добиться вряд ли получится...
Комбинировать то конечно можно, что я по возможности и делаю.
Да, такой StatsMonitor возможен и даже не обязательно чтобы это была System, можно получать доступ к сущностям поштучно. Он может периодически каждый тик..? дергать игрока и сравнивать его статы с тем, какими они были в прошлый раз. Если надо, то можно так сделать, но, не знаю, на первый взгляд, для меня это выглядит как-то очень некрасиво. Нужно смотреть какой вариант хуже.
В любом случае, такой элегантности как в ооп, когда из того-же места где изменился параметр, срабатывает событие и сразу все подписчики оповещаются, добиться вряд ли получится...
ОП, напомни, а почему для симуляции размером с этаж данжа нужен ECS? Классические рогалики же как-то жили без этого. Вот есть, например, Brogue c кучей взаимодействующих систем, и он прекрасно работает без ECS я понимаю, что там то ещё C-спагетти, но всё же.
Не может же yniti быть настолько плохой?
Будет смешно, если действительно так. Я сам сейчас начал с ней работать и лепить прототип механик. Но если прототип соберётся, планирую на свой двиг перенести.
Мне хочется надеяться, что юнити не так плоха. Ты уверен, что подошёл к проблеме с нужной стороны?
Не может же yniti быть настолько плохой?
Будет смешно, если действительно так. Я сам сейчас начал с ней работать и лепить прототип механик. Но если прототип соберётся, планирую на свой двиг перенести.
Мне хочется надеяться, что юнити не так плоха. Ты уверен, что подошёл к проблеме с нужной стороны?
>>869692
Можно с ЕЦС, а можно и без ЕЦС.
Только в первом случае очевидно, что предел сложности симуляции которую ты потянешь значительно выше.
Я выбрал первый вариант, потому что на тот момент я ни малейшего представления не имел насколько высоко этот предел находится и какая сложность мне нужна.
Сейчас да, я согласен что наверно все что есть в игре можно сделать и без использования ЕЦС, если руки не кривые.
Но у меня кривые я привык работать с ним, мне так удобно и лишние фпс никогда не помешают. Если я буду делать еще какие-то рогалики и им подобные, то я буду юзать его и там.
Кстати, способ использовать эвенты в системах я таки нашел, хоть он и неудобный
-ОП
Можно с ЕЦС, а можно и без ЕЦС.
Только в первом случае очевидно, что предел сложности симуляции которую ты потянешь значительно выше.
Я выбрал первый вариант, потому что на тот момент я ни малейшего представления не имел насколько высоко этот предел находится и какая сложность мне нужна.
Сейчас да, я согласен что наверно все что есть в игре можно сделать и без использования ЕЦС, если руки не кривые.
Но у меня кривые я привык работать с ним, мне так удобно и лишние фпс никогда не помешают. Если я буду делать еще какие-то рогалики и им подобные, то я буду юзать его и там.
Кстати, способ использовать эвенты в системах я таки нашел, хоть он и неудобный
-ОП
>>871619
пососав хуй сказало быдло
пососав хуй сказало быдло
Анон-музыкант в треде.
>>839915
Я аккаунт переименовало просто.
https://soundcloud.com/minebee
>>839842
Добрался-таки до своего компа, держи треки.
https://dropmefiles.com/U9JTR
Если хочешь ещё музыки — пиши пожелания, как ты её видишь. Сейчас могу писать, но стимула нет. Мне нужна задача какая-нибудь.
>>839915
Я аккаунт переименовало просто.
https://soundcloud.com/minebee
>>839842
Добрался-таки до своего компа, держи треки.
https://dropmefiles.com/U9JTR
Если хочешь ещё музыки — пиши пожелания, как ты её видишь. Сейчас могу писать, но стимула нет. Мне нужна задача какая-нибудь.
>>869964
Чего? Кому это "очевидно"? Мне вот это не очевидно. Я пришёл в ООП из процедурного кода и мне комфортно в ООП: с объектами легко и приятно работать. Сложность симуляции зависит от того, сколько всего ты можешь представить в своей голове и разложить по полочкам, в моём случае - объектам ООП. Если потребуется какая-то оптимизация производительности, я могу придумать решение, группирующее однородные данные в одном месте, чтобы они поступали к кэш процессора одной пачкой - ООП ничем не мешает применять ДОД. Я могу точечно применить оптимизации по ДОДу и всё остальное время иметь комфортные отношения со своими объектами.
ЕЦС же заставляет мыслить и кодить иначе. У тебя больше нет объектов, свойства сущностей размазаны по многим независимым системам, ты работаешь с наборами неких безликих компонентов, а не с конкретными объектами. Ты вынужден держать в голове или на каких-то отдельных чертежах то, что в ООП описано почти естественным языком, то есть в коде программы. Да, ЕЦС позволяет иметь оптимизацию по ДОДу во всех частях твоего приложения на фундаментальном уровне, но возникает закономерный вопрос, а нужно ли так глубоко оптимизировать все эти части приложения? Конечно, от игр ожидают высокой производительности, но большинство игр сегодня кладут болт на производительность и на любые негативные отзывы разраб отвечает "не моя проблема, купите более мощный компьютер". Какая-нибудь менюшка в шутере может открываться несколько секунд и всех это полностью устраивает. Так что жертва удобства ЕЦС в пользу избыточных оптимизаций просто смешна.
ИМХО, ФПС в твоей игре только пострадал от ЕЦС.
Конкретнее долго объяснять, тем более не зная код.
>>869692
Потому что он повёлся на маркетинг. Без обид, ОП.
Рекомендую попробовать Godot, он значительно удобнее для создания быстрых прототипов простых механик, особенно в 2D: у него куда лучше юзабилити, ему не хватает только некоторых небольших фич, большинство из которых относятся к 3D. К тому же можно исследовать все исходники и почерпнуть что-то для собственного движка, или сделать форк и никому не отдавать свои модификации движка. Короче, намного больше перспектив, чем у закрытых конкурентов, даже несмотря на непопулярность и текущие проблемы.
>ЕЦС
>очевидно, что предел сложности симуляции которую ты потянешь значительно выше.
Чего? Кому это "очевидно"? Мне вот это не очевидно. Я пришёл в ООП из процедурного кода и мне комфортно в ООП: с объектами легко и приятно работать. Сложность симуляции зависит от того, сколько всего ты можешь представить в своей голове и разложить по полочкам, в моём случае - объектам ООП. Если потребуется какая-то оптимизация производительности, я могу придумать решение, группирующее однородные данные в одном месте, чтобы они поступали к кэш процессора одной пачкой - ООП ничем не мешает применять ДОД. Я могу точечно применить оптимизации по ДОДу и всё остальное время иметь комфортные отношения со своими объектами.
ЕЦС же заставляет мыслить и кодить иначе. У тебя больше нет объектов, свойства сущностей размазаны по многим независимым системам, ты работаешь с наборами неких безликих компонентов, а не с конкретными объектами. Ты вынужден держать в голове или на каких-то отдельных чертежах то, что в ООП описано почти естественным языком, то есть в коде программы. Да, ЕЦС позволяет иметь оптимизацию по ДОДу во всех частях твоего приложения на фундаментальном уровне, но возникает закономерный вопрос, а нужно ли так глубоко оптимизировать все эти части приложения? Конечно, от игр ожидают высокой производительности, но большинство игр сегодня кладут болт на производительность и на любые негативные отзывы разраб отвечает "не моя проблема, купите более мощный компьютер". Какая-нибудь менюшка в шутере может открываться несколько секунд и всех это полностью устраивает. Так что жертва удобства ЕЦС в пользу избыточных оптимизаций просто смешна.
>лишние фпс никогда не помешают
ИМХО, ФПС в твоей игре только пострадал от ЕЦС.
Конкретнее долго объяснять, тем более не зная код.
>>869692
>почему ECS?
Потому что он повёлся на маркетинг. Без обид, ОП.
>сам сейчас начал с ней работать и лепить прототип механик.
>если прототип соберётся, планирую на свой двиг перенести.
Рекомендую попробовать Godot, он значительно удобнее для создания быстрых прототипов простых механик, особенно в 2D: у него куда лучше юзабилити, ему не хватает только некоторых небольших фич, большинство из которых относятся к 3D. К тому же можно исследовать все исходники и почерпнуть что-то для собственного движка, или сделать форк и никому не отдавать свои модификации движка. Короче, намного больше перспектив, чем у закрытых конкурентов, даже несмотря на непопулярность и текущие проблемы.
>>869964
Чего? Кому это "очевидно"? Мне вот это не очевидно. Я пришёл в ООП из процедурного кода и мне комфортно в ООП: с объектами легко и приятно работать. Сложность симуляции зависит от того, сколько всего ты можешь представить в своей голове и разложить по полочкам, в моём случае - объектам ООП. Если потребуется какая-то оптимизация производительности, я могу придумать решение, группирующее однородные данные в одном месте, чтобы они поступали к кэш процессора одной пачкой - ООП ничем не мешает применять ДОД. Я могу точечно применить оптимизации по ДОДу и всё остальное время иметь комфортные отношения со своими объектами.
ЕЦС же заставляет мыслить и кодить иначе. У тебя больше нет объектов, свойства сущностей размазаны по многим независимым системам, ты работаешь с наборами неких безликих компонентов, а не с конкретными объектами. Ты вынужден держать в голове или на каких-то отдельных чертежах то, что в ООП описано почти естественным языком, то есть в коде программы. Да, ЕЦС позволяет иметь оптимизацию по ДОДу во всех частях твоего приложения на фундаментальном уровне, но возникает закономерный вопрос, а нужно ли так глубоко оптимизировать все эти части приложения? Конечно, от игр ожидают высокой производительности, но большинство игр сегодня кладут болт на производительность и на любые негативные отзывы разраб отвечает "не моя проблема, купите более мощный компьютер". Какая-нибудь менюшка в шутере может открываться несколько секунд и всех это полностью устраивает. Так что жертва удобства ЕЦС в пользу избыточных оптимизаций просто смешна.
ИМХО, ФПС в твоей игре только пострадал от ЕЦС.
Конкретнее долго объяснять, тем более не зная код.
>>869692
Потому что он повёлся на маркетинг. Без обид, ОП.
Рекомендую попробовать Godot, он значительно удобнее для создания быстрых прототипов простых механик, особенно в 2D: у него куда лучше юзабилити, ему не хватает только некоторых небольших фич, большинство из которых относятся к 3D. К тому же можно исследовать все исходники и почерпнуть что-то для собственного движка, или сделать форк и никому не отдавать свои модификации движка. Короче, намного больше перспектив, чем у закрытых конкурентов, даже несмотря на непопулярность и текущие проблемы.
>ЕЦС
>очевидно, что предел сложности симуляции которую ты потянешь значительно выше.
Чего? Кому это "очевидно"? Мне вот это не очевидно. Я пришёл в ООП из процедурного кода и мне комфортно в ООП: с объектами легко и приятно работать. Сложность симуляции зависит от того, сколько всего ты можешь представить в своей голове и разложить по полочкам, в моём случае - объектам ООП. Если потребуется какая-то оптимизация производительности, я могу придумать решение, группирующее однородные данные в одном месте, чтобы они поступали к кэш процессора одной пачкой - ООП ничем не мешает применять ДОД. Я могу точечно применить оптимизации по ДОДу и всё остальное время иметь комфортные отношения со своими объектами.
ЕЦС же заставляет мыслить и кодить иначе. У тебя больше нет объектов, свойства сущностей размазаны по многим независимым системам, ты работаешь с наборами неких безликих компонентов, а не с конкретными объектами. Ты вынужден держать в голове или на каких-то отдельных чертежах то, что в ООП описано почти естественным языком, то есть в коде программы. Да, ЕЦС позволяет иметь оптимизацию по ДОДу во всех частях твоего приложения на фундаментальном уровне, но возникает закономерный вопрос, а нужно ли так глубоко оптимизировать все эти части приложения? Конечно, от игр ожидают высокой производительности, но большинство игр сегодня кладут болт на производительность и на любые негативные отзывы разраб отвечает "не моя проблема, купите более мощный компьютер". Какая-нибудь менюшка в шутере может открываться несколько секунд и всех это полностью устраивает. Так что жертва удобства ЕЦС в пользу избыточных оптимизаций просто смешна.
>лишние фпс никогда не помешают
ИМХО, ФПС в твоей игре только пострадал от ЕЦС.
Конкретнее долго объяснять, тем более не зная код.
>>869692
>почему ECS?
Потому что он повёлся на маркетинг. Без обид, ОП.
>сам сейчас начал с ней работать и лепить прототип механик.
>если прототип соберётся, планирую на свой двиг перенести.
Рекомендую попробовать Godot, он значительно удобнее для создания быстрых прототипов простых механик, особенно в 2D: у него куда лучше юзабилити, ему не хватает только некоторых небольших фич, большинство из которых относятся к 3D. К тому же можно исследовать все исходники и почерпнуть что-то для собственного движка, или сделать форк и никому не отдавать свои модификации движка. Короче, намного больше перспектив, чем у закрытых конкурентов, даже несмотря на непопулярность и текущие проблемы.
>>796067
Владыка весь в татуировках ?
Владыка весь в татуировках ?
>>872432
очевидно любому, кто серьезно пробовал ЕЦС. оптимизация - побочный продукт, основная польза ЕЦС именно в управлении сложностью и быстрой модификации логики без необходимости отлаживать непонятные баги по несколько часов
>Чего? Кому это "очевидно"?
очевидно любому, кто серьезно пробовал ЕЦС. оптимизация - побочный продукт, основная польза ЕЦС именно в управлении сложностью и быстрой модификации логики без необходимости отлаживать непонятные баги по несколько часов
Я снова целый месяц ничего не писал, опять было много всяких других дел и катабасить я не успевал. Но, тем не менее некоторые новости у меня есть.
1. Гностического лора не будет.
Адаптация какой-либо существующей мифологии под геймплей, или наоборот адаптация геймплея под уже существующий лор - дело очень сложное и неблагодарное. Во всяком случае, у меня не получилось придумать это так, чтобы оно было одновременно играбельно и с уважением к первоисточнику.
Лор нужно выдумывать самому, так и проще и интереснее.
2. Система прокачки должна быть выпилена и переделана.
Она кривая, она плохая, она была бездумно скопипащена с других игр, заимствуя не самые удачные механики, имхо.
3. Дерево перков я так и не сделал.
В таком виде, что ты просто открываешь за уровни новые ячейки на графе, ее скорее всего не будет. Я поэкспериментировал и решил, что это скукотища какая-то.
1. Гностического лора не будет.
Адаптация какой-либо существующей мифологии под геймплей, или наоборот адаптация геймплея под уже существующий лор - дело очень сложное и неблагодарное. Во всяком случае, у меня не получилось придумать это так, чтобы оно было одновременно играбельно и с уважением к первоисточнику.
Лор нужно выдумывать самому, так и проще и интереснее.
2. Система прокачки должна быть выпилена и переделана.
Она кривая, она плохая, она была бездумно скопипащена с других игр, заимствуя не самые удачные механики, имхо.
3. Дерево перков я так и не сделал.
В таком виде, что ты просто открываешь за уровни новые ячейки на графе, ее скорее всего не будет. Я поэкспериментировал и решил, что это скукотища какая-то.
7 Мб, 900x9014. Система богов
То, что в игре будут боги и продвинутое взаимодействие с ними задумывалось с самого начала, но только сейчас у меня дошли руки до того, чтобы что-то сделать в этом направлении.
В игре существует н-ное количество богов. К счастью, теперь я могу выдумывать их как угодно, не следуя никакому лору.
Каждый бог имеет два параметра: уровень отношения и уровень интереса.
В зависимости от интереса и отношения, боги могут влиять на игрока различными способами. Периодически это будет происходить в виде рандомных событий, или же как результат молитв, которые игрок может возносить, выпрашивая всякие полезные вещи, такие, как например восстановление отрубленной конечности и так далее.
Кроме этого, отношения с богами должны взять на себя роль, которую до этого играли опыт и прокачка. В зависимости от уровня отношения они будут давать бонусы к статам персонажа.
...и скорее всего, новые перки тоже они будут давать, но как конкретно это будет происходить пока не ясно.
Для отображения всего этого я сделал вот такую штуку. Иконки богов движутся по орбитам и расстояние до центра отображает уровень заинтересованности бога в происходящем. Боги ближе к центру заинтересованы больше всего, а те которым до игрока вообще дела нет находятся так далеко что не отображаются на диаграмме.
Такой UI может вызвать у неподготовленного зрителя некоторую фрустрацию, но извините, я так вижу. При этом, конечно все элементы будут снабжены подписями и туллтипами.
Как на этот уровень заинтересованности влиять - сейчас расскажу.
То, что в игре будут боги и продвинутое взаимодействие с ними задумывалось с самого начала, но только сейчас у меня дошли руки до того, чтобы что-то сделать в этом направлении.
В игре существует н-ное количество богов. К счастью, теперь я могу выдумывать их как угодно, не следуя никакому лору.
Каждый бог имеет два параметра: уровень отношения и уровень интереса.
В зависимости от интереса и отношения, боги могут влиять на игрока различными способами. Периодически это будет происходить в виде рандомных событий, или же как результат молитв, которые игрок может возносить, выпрашивая всякие полезные вещи, такие, как например восстановление отрубленной конечности и так далее.
Кроме этого, отношения с богами должны взять на себя роль, которую до этого играли опыт и прокачка. В зависимости от уровня отношения они будут давать бонусы к статам персонажа.
...и скорее всего, новые перки тоже они будут давать, но как конкретно это будет происходить пока не ясно.
Для отображения всего этого я сделал вот такую штуку. Иконки богов движутся по орбитам и расстояние до центра отображает уровень заинтересованности бога в происходящем. Боги ближе к центру заинтересованы больше всего, а те которым до игрока вообще дела нет находятся так далеко что не отображаются на диаграмме.
Такой UI может вызвать у неподготовленного зрителя некоторую фрустрацию, но извините, я так вижу. При этом, конечно все элементы будут снабжены подписями и туллтипами.
Как на этот уровень заинтересованности влиять - сейчас расскажу.
7,5 Мб, 900x7935. Система жертв
Основное взаимоотношение с богами происходит через жертвы.
Жертвы можно производить различными способами, но основной принцип такой: определенная клетка является алтарем, и когда предмет уничтожается находясь на ней он считается принесенным в жертву.
Не существует способа направить жертву лично одному конкретному богу. Когда жертва принесена, все боги узнают об этом, и реагируют по разному, в зависимости от того какой предмет был принесен в жертву, где и каким способом это было сделано.
Например, есть бог А, ремесленный бог, который любит, когда ему приносят в жертву инструменты и оружее, при этом разбивая их молотом.
Есть бог Б который является богом подземного земледелия и любит грибы, и при этом обязательно сожженные в огне. питается их дымом как Яхве
Если жертва удовлетворяет всем критериям, то бог приходит в восторг и отношение апается, как и его интерес к вам. В противном же случае, он все равно чувствует, что какие-то жертвы приносятся, хотя и не те, что надо, из за чего на небольшое значение повышается только интерес.
Перевесить качество жертв количеством не получится - количество возможных жертвоприношений должно быть ограничено, но пока не придумал как.
Существует 5 уровней интереса богов.
На первом уровне бог никак себя не проявляет, и ты даже не узнаешь о его существовании, пока каким-то образом не привлечешь его.
На третьем уровне бог начинает отвечать на молитвы.
На пятом же уровне, его присутствие ощущается прямо ТУТ.
На этом уровне интереса боги способны инкарнироваться, принимая материальное обличие. Эа Владыка Глубин, ровно таким образом и существует, кста.
Основное взаимоотношение с богами происходит через жертвы.
Жертвы можно производить различными способами, но основной принцип такой: определенная клетка является алтарем, и когда предмет уничтожается находясь на ней он считается принесенным в жертву.
Не существует способа направить жертву лично одному конкретному богу. Когда жертва принесена, все боги узнают об этом, и реагируют по разному, в зависимости от того какой предмет был принесен в жертву, где и каким способом это было сделано.
Например, есть бог А, ремесленный бог, который любит, когда ему приносят в жертву инструменты и оружее, при этом разбивая их молотом.
Есть бог Б который является богом подземного земледелия и любит грибы, и при этом обязательно сожженные в огне. питается их дымом как Яхве
Если жертва удовлетворяет всем критериям, то бог приходит в восторг и отношение апается, как и его интерес к вам. В противном же случае, он все равно чувствует, что какие-то жертвы приносятся, хотя и не те, что надо, из за чего на небольшое значение повышается только интерес.
Перевесить качество жертв количеством не получится - количество возможных жертвоприношений должно быть ограничено, но пока не придумал как.
Существует 5 уровней интереса богов.
На первом уровне бог никак себя не проявляет, и ты даже не узнаешь о его существовании, пока каким-то образом не привлечешь его.
На третьем уровне бог начинает отвечать на молитвы.
На пятом же уровне, его присутствие ощущается прямо ТУТ.
На этом уровне интереса боги способны инкарнироваться, принимая материальное обличие. Эа Владыка Глубин, ровно таким образом и существует, кста.
>>874286
Я большой любитель супа, и многое заимствую оттуда, но не хочу чтобы игра была его копией
-ОП
Я большой любитель супа, и многое заимствую оттуда, но не хочу чтобы игра была его копией
-ОП
>>874196
>>874204
Запили процедурную генерацию богов, лол.
- имя/пол/возраст/символ/аватарка (декорации);
- черты характера, влияющие на нижеследующее:
- на что/какие параметры влияет и с какой силой;
- какие жертвы, где и как нравятся/не нравятся;
- во что инкарнируется на поле боя (моб).
В каждый забег игра генерирует рандомное число рандомных богов, о которых игрок может узнать либо методом тыка, либо из артефактов на карте.
Топ фича - создание персонального бога с помощью суперультрамегагига одноразовой палки-создавалки. Балансирует рандомность игры в сторону стратегии.
>В игре существует н-ное количество богов. К счастью, теперь я могу выдумывать их как угодно, не следуя никакому лору.
>те которым до игрока вообще дела нет находятся так далеко что не отображаются на диаграмме.
>>874204
>На первом уровне бог никак себя не проявляет, и ты даже не узнаешь о его существовании, пока каким-то образом не привлечешь его.
Запили процедурную генерацию богов, лол.
- имя/пол/возраст/символ/аватарка (декорации);
- черты характера, влияющие на нижеследующее:
- на что/какие параметры влияет и с какой силой;
- какие жертвы, где и как нравятся/не нравятся;
- во что инкарнируется на поле боя (моб).
В каждый забег игра генерирует рандомное число рандомных богов, о которых игрок может узнать либо методом тыка, либо из артефактов на карте.
Топ фича - создание персонального бога с помощью суперультрамегагига одноразовой палки-создавалки. Балансирует рандомность игры в сторону стратегии.
>>881129
БРОДИШЬ ПО ЕБЕНЯМ
@
НАТЫКАЕШЬСЯ НА СКОПЛЕНИЕ ГИГАНТСКИХ ЯЩЕРИЦ
@
К СЧАСТЬЮ У ТЕБЯ БЫЛА СУПЕРУЛЬТРАМЕГАГИГА ОДНОРАЗОВАЯ ПАЛКА-СОЗДАВАЛКА
@
ПРИ ПОМОЩИ ЭТОЙ ШТУКИ, А ТАКЖЕ КУРИНОГО ЯЙЦА И СВОЕЙ СМЕРМЫ, ЗАКАЧЕННОЙ В НЕГО, ДЕЛАЕШЬ СЕБЕ ПЕРСОНАЛЬНОГО ПЕРУНА
@
ГРОМОНОСНЫЙ ДЕД ХУЯРИТ ПРЯМОЙ НАВОДКОЙ ПО РЕПТИЛИЯМ
@
ДОВОЛЬНО УРЧА, ИДЕШЬ СОБИРАТЬ ЛУТ
@
ЧТО-ТО НЕ ТО
@
УМЕРАЕШЬ ОТ ОТРАВЛЕНИЯ СЪЕДЕННЫМ НЕСКОЛЬКО ХОДОВ РАНЕЕ ГРИБОМ, КОИХ ТАК ДОХУЯ В ЗДЕШНИХ БЭКРУМСАХ
@
СЛАВЯНСКИЙ ЗЕВС УМИРАЕТ ВМЕСТЕ С ТОБОЙ
@
ОТ СМЕХА
БРОДИШЬ ПО ЕБЕНЯМ
@
НАТЫКАЕШЬСЯ НА СКОПЛЕНИЕ ГИГАНТСКИХ ЯЩЕРИЦ
@
К СЧАСТЬЮ У ТЕБЯ БЫЛА СУПЕРУЛЬТРАМЕГАГИГА ОДНОРАЗОВАЯ ПАЛКА-СОЗДАВАЛКА
@
ПРИ ПОМОЩИ ЭТОЙ ШТУКИ, А ТАКЖЕ КУРИНОГО ЯЙЦА И СВОЕЙ СМЕРМЫ, ЗАКАЧЕННОЙ В НЕГО, ДЕЛАЕШЬ СЕБЕ ПЕРСОНАЛЬНОГО ПЕРУНА
@
ГРОМОНОСНЫЙ ДЕД ХУЯРИТ ПРЯМОЙ НАВОДКОЙ ПО РЕПТИЛИЯМ
@
ДОВОЛЬНО УРЧА, ИДЕШЬ СОБИРАТЬ ЛУТ
@
ЧТО-ТО НЕ ТО
@
УМЕРАЕШЬ ОТ ОТРАВЛЕНИЯ СЪЕДЕННЫМ НЕСКОЛЬКО ХОДОВ РАНЕЕ ГРИБОМ, КОИХ ТАК ДОХУЯ В ЗДЕШНИХ БЭКРУМСАХ
@
СЛАВЯНСКИЙ ЗЕВС УМИРАЕТ ВМЕСТЕ С ТОБОЙ
@
ОТ СМЕХА
>>881159
БРОДИШЬ ПО ГРИБНОМУ УРОВНЮ
@
@
ПОМНЯ ОБ ИЗОБИЛИИ ГРИБОВ, СОЗДАЁШЬ СЕБЕ ГРИБНОГО БОГА И ЖЕРТВУЕШЬ ЕМУ ВСЕ ГРИБЫ
@
БОГ-ГРИБ СОЗДАЁТ "ГРИБНОЙ" ДОЖДЬ
@
ЯЩЕРИКИ ЛОВЯТ БЭД-ТРИП И УБИВАЮТ ДРУГ ДРУГА В ПРИСТУПЕ ПАРАНОЙИ И ПЕРВОБЫТНОЙ ЯРОСТИ
@
ПОКА ТЫ КАЙФУЕШЬ ОТ ШЕЙДЕРОВ, ИСКАЖАЮЩИХ РЕНДЕРИНГ УРОВНЯ ДО НЕУЗНАВАЕМОСТИ И СНИЖАЮЩИХ ФПС ДО УРОВНЯ ИНДИ ААА ИГРЫ
@
РАНДОМНЫЙ БОГ-Н∀РКОТ ТАЙНО НАБЛЮДАЕТ, ЗАИНТЕРЕСОВАВШИСЬ ЭФФЕКТАМИ ДОЖДЯ
@
ГНЕВАЕТСЯ ЗА СЛУЧАЙНО ЗАДАВЛЕННОГО В ЯЩЕРИКОВОМ БОЮ ПЕЩЕРНОГО КОТА И СПАВНИТ КОТОБУС С КОШКОДЕВОЧКАМИ В ТЕНЕВОЙ БРОНЕ
@
КОШКОДЕВОЧКИ [ВЫРЕЗАНО], ПОЛУЧАЯ [ВЫРЕЗАНО] ЗА УСПЕШНОЕ [ВЫРЕЗАНО] И [ВЫРЕЗАНО], МЕСТНЫЕ СМИ В ЗАМЕШАТЕЛЬСТВЕ И [ВЫРЕЗАНО]
@
УМИРАЕШЬ В ТЕМНИЦЕ ОТ КРИТИЧЕСКОГО УРОНА ОГНЁМ В РЕЗУЛЬТАТЕ САМОРАЗРЫВА ПЕРДАКА
@
ТВОЙ БОГ-ГРИБ ПОЛУЧАЕТ СВОБОДУ
@
БЕРЁТ БРЕВНО И СТРОИТ КОММУНИЗМ
@
ТЕПЕРЬ ВООБЩЕ НЕ НАДО НИКОГО УБИВАТЬ
@
ТЫ ПЛАЧЕШЬ И ПИШЕШЬ "РЕКОМЕНДУЮ" В СТИМЕ
БРОДИШЬ ПО ГРИБНОМУ УРОВНЮ
@
>НАТЫКАЕШЬСЯ НА СКОПЛЕНИЕ ГИГАНТСКИХ ЯЩЕРИЦ
>@
>К СЧАСТЬЮ У ТЕБЯ БЫЛА СУПЕРУЛЬТРАМЕГАГИГА ОДНОРАЗОВАЯ ПАЛКА-СОЗДАВАЛКА
@
ПОМНЯ ОБ ИЗОБИЛИИ ГРИБОВ, СОЗДАЁШЬ СЕБЕ ГРИБНОГО БОГА И ЖЕРТВУЕШЬ ЕМУ ВСЕ ГРИБЫ
@
БОГ-ГРИБ СОЗДАЁТ "ГРИБНОЙ" ДОЖДЬ
@
ЯЩЕРИКИ ЛОВЯТ БЭД-ТРИП И УБИВАЮТ ДРУГ ДРУГА В ПРИСТУПЕ ПАРАНОЙИ И ПЕРВОБЫТНОЙ ЯРОСТИ
@
ПОКА ТЫ КАЙФУЕШЬ ОТ ШЕЙДЕРОВ, ИСКАЖАЮЩИХ РЕНДЕРИНГ УРОВНЯ ДО НЕУЗНАВАЕМОСТИ И СНИЖАЮЩИХ ФПС ДО УРОВНЯ ИНДИ ААА ИГРЫ
@
РАНДОМНЫЙ БОГ-Н∀РКОТ ТАЙНО НАБЛЮДАЕТ, ЗАИНТЕРЕСОВАВШИСЬ ЭФФЕКТАМИ ДОЖДЯ
@
ГНЕВАЕТСЯ ЗА СЛУЧАЙНО ЗАДАВЛЕННОГО В ЯЩЕРИКОВОМ БОЮ ПЕЩЕРНОГО КОТА И СПАВНИТ КОТОБУС С КОШКОДЕВОЧКАМИ В ТЕНЕВОЙ БРОНЕ
@
КОШКОДЕВОЧКИ [ВЫРЕЗАНО], ПОЛУЧАЯ [ВЫРЕЗАНО] ЗА УСПЕШНОЕ [ВЫРЕЗАНО] И [ВЫРЕЗАНО], МЕСТНЫЕ СМИ В ЗАМЕШАТЕЛЬСТВЕ И [ВЫРЕЗАНО]
@
УМИРАЕШЬ В ТЕМНИЦЕ ОТ КРИТИЧЕСКОГО УРОНА ОГНЁМ В РЕЗУЛЬТАТЕ САМОРАЗРЫВА ПЕРДАКА
@
ТВОЙ БОГ-ГРИБ ПОЛУЧАЕТ СВОБОДУ
@
БЕРЁТ БРЕВНО И СТРОИТ КОММУНИЗМ
@
ТЕПЕРЬ ВООБЩЕ НЕ НАДО НИКОГО УБИВАТЬ
@
ТЫ ПЛАЧЕШЬ И ПИШЕШЬ "РЕКОМЕНДУЮ" В СТИМЕ
>>881159
БРОДИШЬ ПО ГРИБНОМУ УРОВНЮ
@
@
ПОМНЯ ОБ ИЗОБИЛИИ ГРИБОВ, СОЗДАЁШЬ СЕБЕ ГРИБНОГО БОГА И ЖЕРТВУЕШЬ ЕМУ ВСЕ ГРИБЫ
@
БОГ-ГРИБ СОЗДАЁТ "ГРИБНОЙ" ДОЖДЬ
@
ЯЩЕРИКИ ЛОВЯТ БЭД-ТРИП И УБИВАЮТ ДРУГ ДРУГА В ПРИСТУПЕ ПАРАНОЙИ И ПЕРВОБЫТНОЙ ЯРОСТИ
@
ПОКА ТЫ КАЙФУЕШЬ ОТ ШЕЙДЕРОВ, ИСКАЖАЮЩИХ РЕНДЕРИНГ УРОВНЯ ДО НЕУЗНАВАЕМОСТИ И СНИЖАЮЩИХ ФПС ДО УРОВНЯ ИНДИ ААА ИГРЫ
@
РАНДОМНЫЙ БОГ-Н∀РКОТ ТАЙНО НАБЛЮДАЕТ, ЗАИНТЕРЕСОВАВШИСЬ ЭФФЕКТАМИ ДОЖДЯ
@
ГНЕВАЕТСЯ ЗА СЛУЧАЙНО ЗАДАВЛЕННОГО В ЯЩЕРИКОВОМ БОЮ ПЕЩЕРНОГО КОТА И СПАВНИТ КОТОБУС С КОШКОДЕВОЧКАМИ В ТЕНЕВОЙ БРОНЕ
@
КОШКОДЕВОЧКИ [ВЫРЕЗАНО], ПОЛУЧАЯ [ВЫРЕЗАНО] ЗА УСПЕШНОЕ [ВЫРЕЗАНО] И [ВЫРЕЗАНО], МЕСТНЫЕ СМИ В ЗАМЕШАТЕЛЬСТВЕ И [ВЫРЕЗАНО]
@
УМИРАЕШЬ В ТЕМНИЦЕ ОТ КРИТИЧЕСКОГО УРОНА ОГНЁМ В РЕЗУЛЬТАТЕ САМОРАЗРЫВА ПЕРДАКА
@
ТВОЙ БОГ-ГРИБ ПОЛУЧАЕТ СВОБОДУ
@
БЕРЁТ БРЕВНО И СТРОИТ КОММУНИЗМ
@
ТЕПЕРЬ ВООБЩЕ НЕ НАДО НИКОГО УБИВАТЬ
@
ТЫ ПЛАЧЕШЬ И ПИШЕШЬ "РЕКОМЕНДУЮ" В СТИМЕ
БРОДИШЬ ПО ГРИБНОМУ УРОВНЮ
@
>НАТЫКАЕШЬСЯ НА СКОПЛЕНИЕ ГИГАНТСКИХ ЯЩЕРИЦ
>@
>К СЧАСТЬЮ У ТЕБЯ БЫЛА СУПЕРУЛЬТРАМЕГАГИГА ОДНОРАЗОВАЯ ПАЛКА-СОЗДАВАЛКА
@
ПОМНЯ ОБ ИЗОБИЛИИ ГРИБОВ, СОЗДАЁШЬ СЕБЕ ГРИБНОГО БОГА И ЖЕРТВУЕШЬ ЕМУ ВСЕ ГРИБЫ
@
БОГ-ГРИБ СОЗДАЁТ "ГРИБНОЙ" ДОЖДЬ
@
ЯЩЕРИКИ ЛОВЯТ БЭД-ТРИП И УБИВАЮТ ДРУГ ДРУГА В ПРИСТУПЕ ПАРАНОЙИ И ПЕРВОБЫТНОЙ ЯРОСТИ
@
ПОКА ТЫ КАЙФУЕШЬ ОТ ШЕЙДЕРОВ, ИСКАЖАЮЩИХ РЕНДЕРИНГ УРОВНЯ ДО НЕУЗНАВАЕМОСТИ И СНИЖАЮЩИХ ФПС ДО УРОВНЯ ИНДИ ААА ИГРЫ
@
РАНДОМНЫЙ БОГ-Н∀РКОТ ТАЙНО НАБЛЮДАЕТ, ЗАИНТЕРЕСОВАВШИСЬ ЭФФЕКТАМИ ДОЖДЯ
@
ГНЕВАЕТСЯ ЗА СЛУЧАЙНО ЗАДАВЛЕННОГО В ЯЩЕРИКОВОМ БОЮ ПЕЩЕРНОГО КОТА И СПАВНИТ КОТОБУС С КОШКОДЕВОЧКАМИ В ТЕНЕВОЙ БРОНЕ
@
КОШКОДЕВОЧКИ [ВЫРЕЗАНО], ПОЛУЧАЯ [ВЫРЕЗАНО] ЗА УСПЕШНОЕ [ВЫРЕЗАНО] И [ВЫРЕЗАНО], МЕСТНЫЕ СМИ В ЗАМЕШАТЕЛЬСТВЕ И [ВЫРЕЗАНО]
@
УМИРАЕШЬ В ТЕМНИЦЕ ОТ КРИТИЧЕСКОГО УРОНА ОГНЁМ В РЕЗУЛЬТАТЕ САМОРАЗРЫВА ПЕРДАКА
@
ТВОЙ БОГ-ГРИБ ПОЛУЧАЕТ СВОБОДУ
@
БЕРЁТ БРЕВНО И СТРОИТ КОММУНИЗМ
@
ТЕПЕРЬ ВООБЩЕ НЕ НАДО НИКОГО УБИВАТЬ
@
ТЫ ПЛАЧЕШЬ И ПИШЕШЬ "РЕКОМЕНДУЮ" В СТИМЕ
>>881191
ор
ор
>>881424
А в игру с названием СКОТОБАЗА / SKOTOBAZA?
>не буду играть в игру, которая называется котакбас
А в игру с названием СКОТОБАЗА / SKOTOBAZA?
343 Кб, 882x1080>>878322
Катабазис-дев на связи.
С того момента как я последний раз притрагивался к моему рогалику прошло невероятно много времени, чего я конечно стыжусь, но поделать ничего не могу.
Дело в том, что по мимо кувалдования котов в подземельях, у меня на этот год было запланировано три важных дела:
- сдать диплом.
- подготовиться к экзамену в аспирантуру
- довести до ума и релизнуть еще один проект
В середине весны я вдруг вспомнил о том, что все это мне нужно срочно делать, и разработка приостановилась. (В аккурат после того как я создал блог посвященный Катабазису на ДТФ и запостил первый пост)
Хорошая новость в том, первый пункт был успешно выполнен. Диплом специалиста художника-реставратора. Какой восторг!
А он при этом еще и красный как кусок пещерного гриба!
Остальные два пункта в процессе выполнения.
Что до второй игры которую я делаю - я скорее всего её потом тоже продемонстрирую. Скажу только, что это некий симулятор приготовления пищи и делается под плей маркет, с рекламой и всем прочим.
Теперь времени у меня стало чуть больше и я сегодня даже снова открыл проект и попытался вспомнить на чем остановился. Вроде моя мотивация пока никуда не делась.
Ждать от меня чего-то путного в ближайшее время не стоит, скорее всего я снова пропаду на неопределенный срок, но как знать)
Катабазис-дев на связи.
С того момента как я последний раз притрагивался к моему рогалику прошло невероятно много времени, чего я конечно стыжусь, но поделать ничего не могу.
Дело в том, что по мимо кувалдования котов в подземельях, у меня на этот год было запланировано три важных дела:
- сдать диплом.
- подготовиться к экзамену в аспирантуру
- довести до ума и релизнуть еще один проект
В середине весны я вдруг вспомнил о том, что все это мне нужно срочно делать, и разработка приостановилась. (В аккурат после того как я создал блог посвященный Катабазису на ДТФ и запостил первый пост)
Хорошая новость в том, первый пункт был успешно выполнен. Диплом специалиста художника-реставратора. Какой восторг!
А он при этом еще и красный как кусок пещерного гриба!
Остальные два пункта в процессе выполнения.
Что до второй игры которую я делаю - я скорее всего её потом тоже продемонстрирую. Скажу только, что это некий симулятор приготовления пищи и делается под плей маркет, с рекламой и всем прочим.
Теперь времени у меня стало чуть больше и я сегодня даже снова открыл проект и попытался вспомнить на чем остановился. Вроде моя мотивация пока никуда не делась.
Ждать от меня чего-то путного в ближайшее время не стоит, скорее всего я снова пропаду на неопределенный срок, но как знать)
>>883188
понял. хотя бы не умер)
понял. хотя бы не умер)
>>881129
Я думал и о таком варианте. Как концепция, выглядит круто, так как предполагает куда более широкую реиграбельность, и при этом игрок о богах буквально ничего не знает, даже если проходит игру не в первый раз.
Но сделать так, чтобы это нормально работало и боги генерились интересные и разнообразные и при этом не слишком абсурдные - ух как непросто, на мой взгляд.
Долго разрывался между этими двумя вариантами, с генерацией и без. Мб стоит сделать что-то среднее, чтобы боги были рандомизированные, но при этом следовали некоторым предустановленным архетипам.
Я думал и о таком варианте. Как концепция, выглядит круто, так как предполагает куда более широкую реиграбельность, и при этом игрок о богах буквально ничего не знает, даже если проходит игру не в первый раз.
Но сделать так, чтобы это нормально работало и боги генерились интересные и разнообразные и при этом не слишком абсурдные - ух как непросто, на мой взгляд.
Долго разрывался между этими двумя вариантами, с генерацией и без. Мб стоит сделать что-то среднее, чтобы боги были рандомизированные, но при этом следовали некоторым предустановленным архетипам.
>>881129
>>883213
Ну хорошо, челенж асептед.
Посидел сегодня несколько часов и написал небольшой скрипт генерирующий рандомных богов, с процедурными аватарками и именами.
Есть некоторое число архетипов, например "бог-кузнец", "бог-трикстер" и прочие. Каждый раз при генерации мира спавнится некоторое количестов богов, частично или полностью соответствующих этим архетипам с различными нюансами.
Как по мне, звучит прикольно.
>>883213
Ну хорошо, челенж асептед.
Посидел сегодня несколько часов и написал небольшой скрипт генерирующий рандомных богов, с процедурными аватарками и именами.
Есть некоторое число архетипов, например "бог-кузнец", "бог-трикстер" и прочие. Каждый раз при генерации мира спавнится некоторое количестов богов, частично или полностью соответствующих этим архетипам с различными нюансами.
Как по мне, звучит прикольно.
>>883213
>>883345
Всё правильно понял, молодец.
Только не зацикливайся на богах, лол. А то щас несколько месяцев будешь делать идеальную систему богов, которые по сути дают только бонусы к основной игре, а основная так и останется... ну... я не специалист в рогаликах, есть какие-то методы объективной оценки рогаликов?
>Как концепция, выглядит круто, так как предполагает куда более широкую реиграбельность, и при этом игрок о богах буквально ничего не знает, даже если проходит игру не в первый раз.
>>883345
>Как по мне, звучит прикольно.
Всё правильно понял, молодец.
Только не зацикливайся на богах, лол. А то щас несколько месяцев будешь делать идеальную систему богов, которые по сути дают только бонусы к основной игре, а основная так и останется... ну... я не специалист в рогаликах, есть какие-то методы объективной оценки рогаликов?
>>883368
Как часто хочется в неё играть и возвращаться после перерывов
мимо анон, который хочет сделать свой рогалик
> есть какие-то методы объективной оценки рогаликов?
Как часто хочется в неё играть и возвращаться после перерывов
мимо анон, который хочет сделать свой рогалик
>>888132
Тогда объективно в игру нужно добавить следующее (но вряд ли это будет рогалик, скорее рогулайт):
- хаб, сохраняющий часть находок из данжа;
- лутбоксы, которые можно открыть в хабе;
- открытие лутбокса занимает реальное время;
- онлайн доска почёта с достижениями игроков;
- ежедневные испытания, одинаковые для всех;
- регулярный новый контент, новые персонажи;
- и т.п. из популярных мобильных игр.
Такие трюки объективно работают на большинстве людей (потому что абузят особенности нервной системы человека), всё остальное субъективно (т.к. зависит от личных предпочтений, характера и т.п.).
>Как часто хочется в неё играть и возвращаться после перерывов
Тогда объективно в игру нужно добавить следующее (но вряд ли это будет рогалик, скорее рогулайт):
- хаб, сохраняющий часть находок из данжа;
- лутбоксы, которые можно открыть в хабе;
- открытие лутбокса занимает реальное время;
- онлайн доска почёта с достижениями игроков;
- ежедневные испытания, одинаковые для всех;
- регулярный новый контент, новые персонажи;
- и т.п. из популярных мобильных игр.
Такие трюки объективно работают на большинстве людей (потому что абузят особенности нервной системы человека), всё остальное субъективно (т.к. зависит от личных предпочтений, характера и т.п.).
>>888215
В данжн кравле всего этого нет, если не считать онлайн версии с турнирами, досками и испытаниями, тем не менее в него хочется возвращаться.
В данжн кравле всего этого нет, если не считать онлайн версии с турнирами, досками и испытаниями, тем не менее в него хочется возвращаться.
>>888217
Лутбоксы есть. Да и сам данж, если он процедурный - один большой лутбокс.
Проблема рогалика с перманентной смертью в том, что весь лут утрачивается после смерти или успешного прохождения данжа. Если добавить хаб, сохраняющий хотя бы небольшую часть лута, это увеличит мотивацию игрока возвращаться в игру - чтобы накопить в хабе как можно больше всякого добра, даже если это бесполезные декорации. Особенные лутбоксы, которые открываются только спустя время, заставляют игрока возвращаться в игру спустя некоторое время, даже если ему лень сейчас спускаться в данж - но зайдя в игру ради лутбокса, он с некоторой вероятностью всё же спустится в данж за новыми лутбоксами.
>В данжн кравле всего этого нет
Лутбоксы есть. Да и сам данж, если он процедурный - один большой лутбокс.
>A dungeon crawl is a type of scenario in fantasy role-playing games in which heroes navigate a labyrinth environment (a "dungeon"), battling various monsters, avoiding traps, solving puzzles, and looting any treasure they may find.
Проблема рогалика с перманентной смертью в том, что весь лут утрачивается после смерти или успешного прохождения данжа. Если добавить хаб, сохраняющий хотя бы небольшую часть лута, это увеличит мотивацию игрока возвращаться в игру - чтобы накопить в хабе как можно больше всякого добра, даже если это бесполезные декорации. Особенные лутбоксы, которые открываются только спустя время, заставляют игрока возвращаться в игру спустя некоторое время, даже если ему лень сейчас спускаться в данж - но зайдя в игру ради лутбокса, он с некоторой вероятностью всё же спустится в данж за новыми лутбоксами.
>>888221
Игра от красноглазиков для красноглазиков.
На её фоне катабазис ОПа выглядит ААА шедевром.
>DCSS
Игра от красноглазиков для красноглазиков.
На её фоне катабазис ОПа выглядит ААА шедевром.
>>888554
Как что то плохое.
Другие рогалик и не смогут создать.
>Игра от красноглазиков для красноглазиков.
Как что то плохое.
Другие рогалик и не смогут создать.
>>888740
ОП сделал рогалик на Юнити с ецс, хоть какой-то гуй приделал и в целом оригинально подошёл к разным механикам. А не ковыряет какой-то код из 1980-х, когда люди за зелёными мониторами играли в игры вводом текстовых команд в юникс-терминал.
>Другие рогалик и не смогут создать.
ОП сделал рогалик на Юнити с ецс, хоть какой-то гуй приделал и в целом оригинально подошёл к разным механикам. А не ковыряет какой-то код из 1980-х, когда люди за зелёными мониторами играли в игры вводом текстовых команд в юникс-терминал.
>>796015 (OP)
Следует придумать более оригинальное название.
https://www.indiedb.com/games/katabasis - 2012, 3D
https://shadowmonk.itch.io/katabasis - 2017, тоже 3D
https://youtu.be/MQj7w2YIRxI - 2021, 2D платформер
https://rathayibacter.itch.io/katabasis - настолка, лол
Следует придумать более оригинальное название.
https://www.indiedb.com/games/katabasis - 2012, 3D
https://shadowmonk.itch.io/katabasis - 2017, тоже 3D
https://youtu.be/MQj7w2YIRxI - 2021, 2D платформер
https://rathayibacter.itch.io/katabasis - настолка, лол
>>904877
Кота в базу, сис!
Кота в базу, сис!
>>904877
скотобазис
скотобазис
>>883345
Год в тред не заходил, радует несказанно, что ОПчик не бросил и пилит свой рогалик. Ну оно и понятно, у него задатки с самого начала были видны.
Люблю тебя ОП, держи так и далее
Год в тред не заходил, радует несказанно, что ОПчик не бросил и пилит свой рогалик. Ну оно и понятно, у него задатки с самого начала были видны.
Люблю тебя ОП, держи так и далее
Bump
>>963645
ОП забросил катабазис и делает какой-то кликер:
https://vk.com/wall-201941833_118
Последняя запись от 30 января, но ОП живой.
ОП забросил катабазис и делает какой-то кликер:
https://vk.com/wall-201941833_118
>Я посмеялся и забил. Когда-нибудь легендарный Катабасис все-таки будет доделан, но... ну вы поняли.
>Жанровая принадлежность моего нового детища - что-то между кликером, айдл игрой и тамагочи.
Последняя запись от 30 января, но ОП живой.
>>963653
Ахаха, ну вот и причина, почему не надо использовать ецс.
>Я действительно запустил это чудо на Андроиде, но производительность была такая, что один уровень генерировался около трех минут. Я посмеялся и забил.
Ахаха, ну вот и причина, почему не надо использовать ецс.
>>963671
Подозреваю, он слишком полагался на магическую оптимизацию ЕЦСа, используя наивные алгоритмы. Катабазис в целом был ненормально тормозной для классического рогалика, даже с учётом всех мелких разлетающихся в стороны спрайтов.
Подозреваю, он слишком полагался на магическую оптимизацию ЕЦСа, используя наивные алгоритмы. Катабазис в целом был ненормально тормозной для классического рогалика, даже с учётом всех мелких разлетающихся в стороны спрайтов.
>>965037
Это прям то что я хотел! Спасибо, все что я сам нашел это Caves of QUD , а эту не видел
Это прям то что я хотел! Спасибо, все что я сам нашел это Caves of QUD , а эту не видел
>>965014 >>965357 >>965362
Тебе туда:
Хватит топтать труп Катабазиса.
>Посоветуити игру(((
Тебе туда:
>>> https://2ch.hk/v/ (
М) <<<
Хватит топтать труп Катабазиса.