Bump
Лол, я букву проебал, но это не важно потому что это временное название, т.к. названия проекта сейчас не имеет значения и мне лень его придумывать, с мгс знаком, но тут ничего общего.
Топ кек, но вообще-то поддерживает, просто выше 1366или сколько там скейлиться.
Сейчас пишу тулзы для редактора эффектов, это то что будет давать возможность изменять переменные или запускать шаблонные скрипты, тем самым можно будет реализовать всякие прикладные эффекты типа изменения кол-ва здоровья, для реализации аптечек, или всякие потребляемые вещества которые будут влиять на базовые параметры актераNPC. Всякие бонусы оружия или предметов будь то броня которая дает +4 к силе или вкусный хлеб который дает -10 к голоду и +10 к здоровью,все это делается с помощью системы эффектов и по мимо изменения переменных, она так же использует систему условий, с помощью которой можно задавать условия ограничивающие или дополняющие влияние эффектов.
Например сумрачная аптечка которая дает +30 здоровья - обычно, и +60 здоровья, если выполняется условия времяСуток = ночь, или портвейн777 который дает эффект +50 к зависимости от алкоголя и +15 к здоровью - обычно ,и +1 к зависимости, и +15 здоровью если условия Удача >=50; выполняется.
Самые внимательные и матерые олдфаги могли заметить схожесть с различными Creation Kit'ами которые клепает "беседка" из года в год, это сходство не случайно, т.к. мне условно нужна схожая механика, я в лучших традиция, не нарушая EULA произвожу инженерный анализ тулзов доступных мне редакторов. Это относиться не только к тулзам беседки, так-же я гляжу в тулзы движка FIFE и прочего, жадно изучая доступные туториалы, что дает мне туманное представление о строении того или иного обьекта математическая абстракция. Ну ты понял я, просто смотрю редактор предметов в том-же G.E.C.K'е вижу что предметы имеют - имя, вес, звук при падении и прочие тривиальные параметры, которые я анализирую на актуальность и востребованность в своем проекте, перегоняю-адаптируя в c# В пошаговых изометрических играх, да и вообще в играх, очень много таких вещей которые как-бы являются определяющими жанр или каким-то принятыми тенденциями- у почти всех NPC, во всех играх есть очки здоровья, почти во всех пошаговых играх есть очки действия, в рпг есть диалоги и т.д Таким образом я экономлю много времени и получаю представления о архитектуре проекта, так и живем.
На текущий момент у меня есть доступные тулзы для редактора классов актеровтупо шаблон базовых параметров класса позволяющий экономить время не вбивая параметры которые должны наследоваться классом,например есть класс "тоннельные торговцы", у них всех есть одинаковые навыки[харизма, бартер] и они все могут торговать с игроком и допустим торгуют только 3 категориями товаров, благодаря этому можно просто казать что актер тоннельный торговец и не ставить галочки, писать циферки., тулзы для редактирования фракций В этом определяем как взаимодействуют актеры между собой и всякие определяющие параметры типа рангов - запах ,дух,слон,черпак, имена этих рангов для разных видов полов (есть только два) и типы взаимодействия и модификатор этого взаимодействия, например есть фракции "тоннельные крысы" и фракции "тоннельные торговцы", между ними взаимоотношение = враг, а модификатор этого отношения равен 15, далее при встрече одних с другими они определять друг друга и путем простых вычислений( рангмодификатор) выстроят алгоритм действия, например если есть крыса низкого ранг условно 2 из 8, в таком случае актер получит значение ( рангмодификатор)=(2*15)=30, и в зависимости от того что указано в AI пакете, произведет атаку или если там указано что атаковать можно только врагов с фактором >100 ничего не сделает.Тем самым можно не только сделать взаимоотношения между NPC человечными/реалистичными, но и сделать более умный AI который будет использовать фракцию и ранг для оценки цели, в случае когда их несколько например, и нам хочется что-бы AI нападал не на пешок, а на королей, что в некоторых случаях более рационально..Так-же есть редактор предметов, но пока только для одного типа -патронов, все это есть в видео в одном из бампов, если интересно как это выглядит визуально. В следующем посте распишу подробней за архитектуру и что собираюсь делать дальше и о GOAP и в целом AI, а так-же может проясню за так скажем roadmap.
Пилить инди изо рпг в одно лицо и так хард челлендж, так еще и такой визуальный стиль выбираешь.
Та не, все проще чем кажется, запощу позже об этом. А насчет графона все легко, я изначально environment artist 3D, уже после программист, art и leveldesign моя специализация, могу создавать контент сам и писать тз для аутсорса.Арт для меня самое простое. А что касается сложности, то это не так сложно как кажется если есть опыт, я использую модульную архитектуру и по сути, создал модуль для редактирования тех же сцен, считай создал их всех, арт тоже модульный тайлы/спрайты это модули, по сути мне нужно создать по одному экземпляру каждого игрового класса , которых примерно <~50 из которых для ~25 нужны тулзы.
Lead developer, могу вообщем почти во все, или как минимум имею представление о всех процессах в разработке, вообщем "because i can" Ну ты же понял что анимация на гифке это для тестирования тулзов которые рендерят спрайты и нарезают фреймы, не имеет отношение к делу и сделана за 1 минуту,как и риг со скином и сама болванка персонажа и весь контент из арта который будет использоваться в тестировании, тут же даже текстур нет, не стоит всерьез оценивать этот контент.
-ValueModifier, когда нужно изменить базовый параметр актера, например жизни,карму или уровень скилла заХардкодено.
-ValueAndParts,тоже самое что и ValueModifier только можно применять эффект локально, на конкретную часть актера, руку,ногу голову, например такой предмет аптечка, ее можно применить на голову или ногу,а так как например за поврежденную ногу,есть штрафы в кол-ве ОД для перемещения на клетку, то тем самым применив ее на ногу мы можем грамотно избежать так не нужных тебе штрафов. Ну и много всего.
-Script, запускает скрипт,класс которого имеет определенную структуру, которую наследуют все наши созданные для эффектов скрипты, структура типа точек входа-выхода, в скрипте может делать что хочешь, хоть файлы на жестком диске удалять, хоть сцены в игре менять.
Ну и в зависимости от архетипа выбирается ассоциируемый с ним предметто на что он будет влиять, если архетип ValueModifier или ValueAndParts то этим предметом служат параметры актера, Скиллы, ОЗ, ОД, карма,XP и т.д.
Если Script то один из написанных нами скрипт.
А сами BaseEffect служат фундаментом для ObjectEffectдля эффектов накладываемых на предметы, оружие, броню и т.д,ActorEffect для актеров, IngestibleEffectдля так скажем съедобных\потребляемых предметов, как аптечки, еда,напитки, мед.препараты, в которых непосредственно выбирается BaseEffect, модификатор для этого эффекта и условия для его запускаС помощью системы условий о которой я писал и расскажу в следующий раз..
/
Ну и приведу пример работы этой кабалы.
/
Создаем BaseEffect, называем его "RestoreHealth" выбираем архетип ValueAndParts, выбираем ассоциируемый предмет для этого архетипа параметр актера, в нашем случае пусть это будет "Health"- очки здоровья, но может быть любой параметр актера, ну ты понял. Ну и выбираем звук для разных стадий эффекта,отображаемый визуальный эффект и разные флаги\параметры, информацию о которых я сейчас опускаю, так как хочу донести лишь концепцию работы этой интересной системы, дабы ты смог пустить свежую струю в рот загнивающего геймдева, или смог пояснить потсонам в gd тусовке.
Вообщем после того как выбираем все необходимые параметры и сохраняем наш BaseEffect под именем "RestoreHealth". Далее решаем где будем использовать наш эффект и соответственно этому, выбираем тип эффекта ObjectEffect,ActorEffect,IngestibleEffect, для примера пусть будет IngestibleEffect - сьедобный предмет, так как созданный нами BaseEffect влияет на очки здоровья актера то предположим что это будет аптечка хотя может быть что угодно что влияет на очки здоровья аптечка это всего лишь абстракция , ну и следовательно создаем новый IngestibleEffect, в нем мы помимо ряда всяких параметров типа звука при использовании эффекта, имени и всякого что сейчас опускаем, мы выбираем базовый эффект, для этого эффекта, это и будет наш BaseEffect "RestoreHealth", и уже в этом классе как и в любом типе эффектов ObjectEffect,ActorEffect,IngestibleEffect мы выбираем модификатор, продолжительность действия и условия для запуска с помощью системы условий выбранного базового эффекта, например мы выбираем модификатор +47, и продолжительность 5 секунд, и делаем условие для запуска, например кол-во Текущее здоровья < макс Кол-во здоровья. Что-бы не использовать аптечку зря и можно было применять только когда у игрока не полные очки здоровья. Вот и все, дает имя этому IngestibleEffect например "lowHealthPack". И применив его на актера игрока у него к параметру Health прибавиться +47 в течении 5 секунд .
И допустим мы можем создать еще любое кол-во аптечек или других эффектов в которых будет использоваться один и тот-же базовый эффект "RestoreHealth", и в которых лишь будут меняться значение модификатора, время действия и условия запуска и то говно которое сейчас опускаем например можно сделать более крутую аптечку что-бы она прибавляла больше здоровья изменив значение модификатора и делала это быстрее чем 5 секунд изменив продолжительность эффекта, пусть даже мгновенно, так-же можно экспериментировать с условиями запуска и создать почти что угодно от штанов на +3, до волшебного эликсира применив которого в 00-00 ночи, имея 1 очко Здоровья и будучи одетым в штаны на +3, можно получить навык, изменить кол-во здоровья и кармы и переместиться на секретную сцену. Это очень гибкая система и она позволяет создать кучу геймплейных элементов сэкономив много времени, которое можно потратить на донаты и потронство интересным инди проектам типа этого шутка, пока нет., или на свою еот.
Ну и немного разавью пример, те штрафы за которые я упоминул , когда у игрока повреждена нога то требуется больше ОД для перемещения, тоже делаются с помощью этой системы, это ActorEffect, вообщем модульная система , которую можно легко внедрить и не заморачиваться с кучей геймплейных элементов которые пришлось бы выносить на кучу классов и придумывать сложную архитектуру...
Начну с архитектуры, как самые внимательные из вас могли заметить редакторнаписанные мной тулзы написан не для Editor'a в uinty, а для билда все кто писал тулзы Editor'a знают что это не благодарное занятие в Unity на текущий момент, следовательно юнитевский плеер скомпилированный билд, не может будучи скомпилированным добавлять или изменять что-то внутри себя, это очень важный момент, основополагающий при написании архитектуры.
Основываясь на этом и на предполагаемой игровой механики, приходим к ряду решений из которых сейчас затрону лишь часть требующуюся для понимания когда начнется "ебля" и сведения все в единое целое.
Вообщем если говорить о архитектуре, то это все похоже на моддинг, в том смысле что из-за того что мы не можем изменять скомпилированный билд, нам нужно писать код классов так, что-бы мы могли модифицировать и сериализовать их в файл, независимый от билда, с возможностью чтения\записи, и дальнейшей компиляциисборки/десериализации этих файлов внутри скомпилированного билда. С игровыми ресурсами немного иначе, например нам нет необходимости писать парсер для игровых звуков, музыки, тайлов и спрайтов с анимациями, с этими файлами лучше работать внутри unity и добавлять в билд перед компиляцией, заранее сделав анимации, повесив коллайдеры, выставив слои, тэги,добавить все в нужные атласы и т.д. Выходит что мы по большому счету редактируем классы, создавая их копии с различными параметрами, оперируя ресурсами имеющимися в билде моддинг.
В такой архитектуре есть как минусы так и плюсы, но так же есть и необходимость которая продиктована не только возможностями движка Unity, но и предполагаемой механикой RPG..
Так как RPG игры обычно оперируют большим обьемом данных,а эти данные требуется хранить в памяти компьютера, то самое верное решение хранить их на жестком диске а не в оперативной памяти,ну ты и сам знаешь, причем в компонентном виде, имея к ним компонентный доступ, что-бы не заполнять оперативную память и в определенный момент времени аллоцировать в нее только нужные данные. Например есть сцена, сцена состоит из карты проходимости, карты простреливаемости, актеров, предметов,контейнеров и т.д, каждый из этих классов сериальзуется в отдельный бинарный файл на жестком диске, к которому мы можем получить доступ из любого места. Тем самым мы например можем считать карту проходимости и произвести с ней нужный расчет не загружая всю сцену, это простой пример, или мы можем повстречать в игре актера торговца, который путешествует по миру и торгует с игроком и NPC, те товары которыми он располагает хранятся в контейнере класс в котором хранятся предметы(ammo,food,weapons etc...), как инвентарь, но контейнер, этот класс может быть у актеров или обьектов, например шкафчик, холодильник,сейф файл контейнера лежит на жестком диске и мы загружаем его только когда игрок пробует с ним торговать,но допустим что на этот файл ссылается в игре еще и сундук расположенный на какой либо сцене, скажем в доме торговца, тем самым мы может внести реализма, сделав эффект будто торговец хранит свои вещи в сундуке, так как сундук и торговец ссылаются на один и тот же файл контейнера, все изменения в контейнере отразятся на всех кто его использует, это более сложный пример.
По сути это тривиальное решение и отличается оно только реализацией и представляет из себя папку Data с россыпью бинарных файлов внутри.поскольку unity cкомпрометирован и нет смысла делать мастерФайл или шифровать эти данные.Те тулзы которые я сейчас пишу, и компилируют эти самые бинарные файлы которые нам нужно будет обрабатывать в игровом цикле. То есть написать тулзы это лишь половина работы, и основная "ебля" заключается в правильной десериализации производимых ими данных в игровом цикле, в правильности которой можно убедится только написав этот самый игровой цикл игровой цикл -имеется ввиду все то что будет обрабатывать компутер непосредственно в игре и сопряженные для каждого типа данных классы.
Тут и начинается "ебля" где обосраться можно на каждом повороте.
Но происходить все это будет постепенно, и для того что-бы начать этот живительный процесс, нужно написать редактор сцены, с редактором карты проходимости для поиска путей и редактором актеров с не полным инструментарием т.к. для начала нужно просто десириализовать файлы сцен и спавнить на них актера игрока, без AI, звуков, анимаций и всего, только игрок, и сцена с тайлами\спрайтами и возможностью передвижения игрока по ней. На этом этапе обрабатываются и внедряются в игровой цикл тулзы для сцен,актеров,предметов,поиска путей,некоторых эффектов. По мере добавления тулзов в игровой цикл, перечень тулзов будет расширятся, а сама структура цикла меняться, т.к. на данный момент не имею представления о том как точно они будут в этот цикл интегрироваться и взаимодействовать. Хоть я и написал уже 4 тулзы, толку от них пока нет, а не начал я писать с так нужных для начала формирования игрового цикла тулзов сцен и актеров, что-бы проверить всякое, и не кидаться сразу в этот гнетущий пиздец. Но сейчас уже преступаю к этому и надеюсь не обосрусь по дороге.Об этом пока и будет тред.
Такой графон уже 10 лет как устарел. Максимум, модельки можно использовать для обрисовки. А вообще, пиксельарт ведь так и остался в моде, что мешает нарисовать все от руки?
>3д-модельки рендерят в спрайты и делают из этого изометрические игры?
Это можно очень неплохо разукрасить и сделать конфетку. Стиль всё, старина ничего.
>пиксельарт ведь так и остался в моде
>что мешает
Возможно, ему мешает то, что он не листает томик Бегбедера лежа с баттплагом в жопе, натерев бороду специальным маслом и попивая крафтовое пиво.
Анон, ты не прав. Спрайты, пиксель арт, модельки - это все лишь средство выражения. Арт нельзя так оценивать, мы же не можем сказать что картины карандашом изначально хуже чем картины маслом или углем, те критерии по которым ты оцениваешь субъективны и вырваны из контекста.
>Спрайты, пиксель арт, модельки - это все лишь средство выражения.
Да, это все верно и мудро сказано, но вот как-то не вяжется с контентом вроде >>455075 >>455085
Короче, художественное выражение обычно бывает во всяких визуальных новеллах и симуляторах ходьбы. Во многих других случаях в геймдеве контент нужен только для того чтобы тупо заполнить игровой мир, сделать его убедительным в должной степени.
И тут на передний план встает не качество, а количество контента.
Ну а теперь посчитай, сколько нужно времени, чтобы сделать фотореалистичный дом полностью в 3д и сколько - чтобы нарисовать пиксельарт домишко из прямоугольников и повторяющихся тайлов.
Не совсем понял к каким выводам я должен придти, хоть контент и делают художники, но это не значит что все 2д художники могут делать 3D или 3D могут в пиксель арт. В моем случае я профессиональный 3d художник и пиксель арт у меня займет гораздо больше времени, и будет гораздо более плохого качества. В конкретно моем случае, я могу только 3D и оптимизация пайплайна, с целью увеличить кол-во контента и заключается в запекании моделей в 2d, т.к. это требует меньшей детализации и в целом на производство модели для последующего запекания уходит меньше времени т.к. снимается необходимость делать топологию, запекания, и заботиться о разверстке. и модульной архитектуре контентатайлы.
Думаю над архитектурой сцен. Внезапно всплыл вопрос генерации карты который нужно решить перед тем как писать код дальшету что открывает игрок для ориентации в мире.. Нужно решить ее архитектуру и визуальное представление. Всего будут карты двух видов, для открытого и закрытого пространства WorldSpace, Interiors. Для карт с открытым пространством есть, интересный момент связанный с размером локаций и их пропорциями ширина, длинна. Во многих играх все сцены открытого пространства имеют квадратную форму и и единый размер, например 256х256 клеток, что как-бы упрощает навигацию, позволяет рассчитать к какой сцене относиться та или иная точка в пространстве, а так-же это визуально красиво при генерации, на карте сразу видно квадраты, которые разделяют сцены, можно сориентироваться относительно переходов между ними как на 4 пик. Вообщем сижу думаю как их сделать, точнее как сделать понятно, просто напишу перемычку которая будет перебирать статические обьекты на сцене и относительно их буду рисовать текстуру карты, основной вопрос в визуальном представлении, в изометрической перспективе сложно ориентироваться по карте как на 2 пике, хоть карта на пике из изометрической игры, но ориентироваться по такой сложно, т.к. технически что-бы сдвинуться по карте вверх, в игре нужно идти вправо.у карты и сцены разные проекции. Исходя из этого склонюсь к карте в изометрической перспективе как на 3 пике, но например сделать визуально будто она нарисована от руки как в sh возможно или в виде таблички плана эвакуации. Вообщем думаю дальше, если что кидайте в тред интересные карты.
Что касается разделения всего открытого пространства на равные квадраты, то это тоже вероятно придется делать, хоть и практической пользы от этого мало т.к. все сцены рисуются с нулевого вектора и динамически не подгружаются, но зато можно сделать карту с маркерами, которая будет иметь человеческий вид и представлять из себя единый кусок площади. Вообщем вероятно весь внешний мир будет занимать фиксированный размер, каждая клетка которого сцена будет примерно 512х512 юнитов, или если все нормально сложится с HPA(звездочка), то можно будет и замахнуться на 1024х1024, что как-бы 500 метров ин ворлд 1 юнит в игре = 0.5м .
Далее решаю вопрос с сериализацией, затрону saveData и буду думать как все это добро сохранять, а добра сохранять придется много, каждый файл сохранения по сути содержит информацию о всей игре, о каждой сцене, расположенных на ней обьектах, о актерах на этих сценах и их характеристиках, получается что-то страшное размером под 10 мегабайт, по началу думал что я обасрался, потом глянул на структуру файла сохранения в скурим http://en.uesp точка нет/wiki/Tes5Mod:Save_File_Format, там тоже самое.
у них файл сохранения достигает 20 мб. Тут я понял что на правильном пути, лол.
Я опять проебался с контентом для этого бампа, поэтому расскажу о текущем положении на словах. Сейчас думаю над архитектурой редактора сцены, это совокупность тулзов начиная с размещения на сцене тайлов/спрайтов и навигации по ассетам, заканчивая редактором навигационных сеток и сетки простреливаемости да есть и такая, плюс куча мелких плюшек упрощающих работу,как например возможность сортировки ассетов по их типу (floors,walls,object,roofs) для удобства навигации по ним, или автоматического обновления навигационных и прочих сеток при размещении на сцене обьектов. Все необходимые вещи должны закладываться в архитектуру на этом этапе прототипирование и исходя из них и их взаимодействий можно получить представление о оптимальном пути их реализации и посчитать на бумаге какие-то вещи, после всего этого прототипируется интерфейс кнопочки, списочки, асечку, писечку, а дальше уже переносится с бумаги в код, чем я сейчас и занимаюсь.
А контент который я все хочу принести, но так предательски не успеваю к намеченным датам представляет из себя фундамент всего вышеописанного, который я сейчас переношу на код, я планировал написать большую часть кода редактора сцены что-бы сразу очертить Анону силует того чем по сути я буду заниматься ближайшее время пилить редактор сцены, постепенно добавляя тулзы по сути нужно было заводить тред на этом этапе, когда есть прототип основной архитектуры,но я поспешил молодой горячий из-за этого тред пока представляет из себя простыню из текста не сильно подкрепленного контентом, но надеюсь как я допишу проект до того этапа на котором планировал показывать прогресс здесь станет веселей и интересней нет, а так-же я буду приносить сюда контент мелких проектов которыми я занимаюсь отдыхая от этого проекта.
Буду бампать информацией по традиции каждое воскресенье и по необходимости в остальные дни.
Я опять пришел без товара.
Все еще пишу базовый функционал редактора сцен - это очень много разного говна, разной степени сложности. На первый взгляд до желаемой кондиции не хватает немного, но каждый раз вылазит что-то на решение чего уходит время, ну ты и сам знаешь как это работает, так-что пока сухой бамп, с пиком редактора над которым я сейчас сижу.А еще я приобрел рекордер для записи звуков, так что теперь буду писать звук, но основная работа со звуков будет летом(пойду в местную шарагу или школу, или где много разных дверей, чтобы писать звуки дверей. А так же
взаимодействия разных предметов с разными поверхностями, взаимодействия с предметами в инвентаре и т.д(это дома)).
https://впаше/doc159149115_455864975?hash=0bfdfb0129fdf01cf2&dl=9d696e5d829aef9cf5
>>461313
И на фреймрейт не обращай внимания Анон, я на гавно-ноуте работаю, у меня бандикам сжирает с косарь кадров когда сцена не загружена, а когда сцена загружена сжирает еще больше т.к. геймобжекты с навигационной сеткой это как ни как 256² что есть 14.336 геймобжектов хоть и не в одном кадре но все равно много и мне нужен каждый из них, но это пока даже не альфа, в действительности всю сетку не имеет смысла держать , нужны только закрытые клетки., без бандикама 200-300 кадров на моем гавноноуте, на твое пеке будет все 500. Это все можно будет посмотреть в полноценном бампе когда он будет, я прикреплю тестовый билд уровня, ничего не нажимай, а то сломаешь.
Тип того в рендере и проекции, это все для теста, тут даже швы не затерались и нормалей нет, я к тому что этот контент не стоит оценивать , он для теста pixel density, сделанный за 5 минут и не в прадакшн.
Я хотел сделать Beat 'em up где нужно постоянно идти направо и по пути ломать картонные коробки и гипсовые стены, а в конце пиздиться с Камой-пулей которого нельзя победить без чит кода, это гениально я знаю проект на 48 часов работы, но не срослось.
Маска отвечает за визуализацию занимаемых узлов навигационной сетки текущим объектом, то есть в зависимости от того сколько клеток игрового мира занимает выбранный объект рисуются спрайты клеток, чтобы при размещении его мы могли иметь представление о том сколько клеток он делает не проходимыми и какие именно клетки, ну и само собой при размещении объекта эти клетки автоматически меняют состояние в нав. секте, это экономит время на разметке карты в ручную, хотя в некоторых случаях, и при желании всегда можно вручную изменить состояние сетки, и сделать проход хоть сквозь стену или вообще не использовать автоМаску, это опциональная вещь, и да, маска указывается вручную при добавлении ассета просто лист с vector2 в котором хранятся индексы клеток которые занимает объект, а сама анкерная точка объекта относительно которой рассчитываются индексы маски (отмечена зеленым пикселем на каждом объекте) это нулевые координаты, всегда индекс(0,0), это все есть в пайплайне рендеринга спрайтов, как и куча других хитростей о которых когда-нибудь у меня дойдут руки написать. .
На видео выше описанная вича, только в нерабочем состоянии, т.к. я только начал ее писать и решил что тред слишком пуст и можно позаливать в него всякий около контент.
Как же меня бесит слово decarotaions! Сразу же выключаю твои вебмки, когда его вижу.
Так по сути и есть, это казуал для телефона, с казуальным интерфейсов свистелки-перделки, он такой из-за того что игра логическая и по сути своей не динамичная, из-за этого делается такой активный интерфейс, что-бы нивелировать вяло текущий геймплей и игрок не засыпал, ничего личного просто казуал и патерны. Ну вы же поняли что это не для этого изометрического проекта с пандемией и трупами.
Работа идет, работаю над пайплайна арта от 3ds max до спрайта в атласе и обкатываю сам арт, примеряю как организовать модули и какие есть подводные перед тем как начать делать арт в продакшн, потихоньку пишу код для тулзов...
Пайплайн кстати интересный, особенно доставляет то как нужно будет исхитрятся с тенями тени здесь довольно условное понятие с ними приходиться много возиться т.к. их приходиться подгонять практически в ручную условно, если обьект например водопроводная труба просто весит в воздухе над полов, то нужно просто запечь обьект с тенью на полу для двух сторон (передней, боковой), если труба идет вдоль стены, то нужно запекать тень с полом, и с полом и стеной, а еще труба может соединяться другой трубой и тень соответственно будет другая для простой трубы и той которая должная соединяться (см. картинку в верхнем-левом углу), итого некоторые обьекты нужно прогнать через рендер ~16 раз только ради тени. . Не менее веселое, это организация имен тайлов/спрайтов, среднее имя пока что выглядит примерно так - ShelterFrPipeStrOutNo01a, ShelterSdPipeCrnAl01a расшифровка на 3 пике, все это рутина без которой нельзя.
Потсоны не смотрите на 2 пик плис, это мусор который забыл удалить и случайно залил.
Начну с того что слои хранятся в чем-то вроде enum листа см.картинку 1, а метод камеры для работы с этими слоями Camera.cullingMask принимает интовое значение, при этом в самой камере слои хранятся в чем-то типа листа с bool, в котором можно поставить галку на нужном слое для его отображения см.картинку 2. Вообщем посував в метод Camera.cullingMask разные интовые числа и посмотрев на результат полез документацию, в референсе кода указан ужасный, путающий пример где в метод суют произведение побитового сдвига, и рекомендация с ссылкой где можно получить более подробную информацию, перейдя по ссылке за дополнительной информацией, получил еще такой же пример с сдвигом и описание концепции layers в unity бесполезное, однако в относительно смежном со слоями примере с рейкастом говориться что один из его аргументов отвечающий за работу с этими самыми layers принимает битовую маску, тут наконец-то у меня все сложилось и я понял почему получал такой странный результат перебирая интовое число по порядку и суя его в Camera.cullingMask.
Как ты знаешь все данные на пеке хранятся в двоичной системе счисления и интигер не исключение, его можно представить в двоичном коде получив последовательность единиц и нулей, это нам и нужно сделать что-бы работать с этим методом Camera.cullingMask, представим что каждый бит в нашем int числе которое мы будем совать в Camera.cullingMask это флаг bool, а его позиция в числе равна индексу слоя в слоях камеры см.картинку 3, на картинке указана стрелочка ведущая к числу состоящему из одних нулей длинной равной длине нашего списка Layers из картинки 1 8 из которых зарезервированы системой, такое двоичное число нам и нужно представить что-бы после перевести его в int и сунуть в Camera.cullingMask , собственно вот и все что нам нужно для работы, соотносим где в этом числе из одних нулей должна быть единица 1 = true, 0 = false и переводим из двоичной последовательности в интигер который суем в Camera.cullingMask, см.картинку 4 с примерами какое целое число нужно совать в Camera.cullingMask , как оно выглядит в двоичном коде, и какие флаги ставятся в слоях на камере в результате... добавлю 3 пик, если вдруг позабыл как конвертировать из двоичной системы в десятичную, вдруг кому понадобиться...
И это я не свой велосипед описываю, а нативный код unity. Кстати подход с битовой маской удобный , много где можно применить...
Мимо начал писать кусок кода тулзов для работы с сортировкой для решения проблем как на шебм, когда нужно что-бы объекты с разных слоев рисовались относительно какого-либо объекта. и слоями - скрытием\раскрытием слоев декораций (стены, полы, обьекты, etc), эта фича уже была, делалась путем скрытия родительского трансформа нужной группы декораций, но исходя из выбранного решения для "сортировки относительно обьекта" пришлось переписывать, так как иерархия изменилась и нужно соединять трансформы обьектов с разных слоев друг к другу и сортировать относительно этого относительно родителя трансформа для всех его детей, а детей относительно SiblingIndex, новый способ для работы со слоями нашел быстро - использовать встроенные в юнити слои Layers и скрывать ими с помощью Camera.cullingMask https://docs.unity3d.com/ScriptReference/Camera-cullingMask.html, но на удивление в сети не нашел нормальной информации или референсов. В сети советовали либо использовать что-то другое, либо была вредная информация уровня - создать несколько камер для разных слоев и переключать их кек,лол, ну и еще что-то построенное относительно референса в офф.документации, но тоже без внятного объяснения для тупых вроде меня, поэтому решил что анон наверняка столкнется с этой проблемой когда ему понадобиться работать с этим, поэтому расскажу как это работает и как используется у меня.
Начну с того что слои хранятся в чем-то вроде enum листа см.картинку 1, а метод камеры для работы с этими слоями Camera.cullingMask принимает интовое значение, при этом в самой камере слои хранятся в чем-то типа листа с bool, в котором можно поставить галку на нужном слое для его отображения см.картинку 2. Вообщем посував в метод Camera.cullingMask разные интовые числа и посмотрев на результат полез документацию, в референсе кода указан ужасный, путающий пример где в метод суют произведение побитового сдвига, и рекомендация с ссылкой где можно получить более подробную информацию, перейдя по ссылке за дополнительной информацией, получил еще такой же пример с сдвигом и описание концепции layers в unity бесполезное, однако в относительно смежном со слоями примере с рейкастом говориться что один из его аргументов отвечающий за работу с этими самыми layers принимает битовую маску, тут наконец-то у меня все сложилось и я понял почему получал такой странный результат перебирая интовое число по порядку и суя его в Camera.cullingMask.
Как ты знаешь все данные на пеке хранятся в двоичной системе счисления и интигер не исключение, его можно представить в двоичном коде получив последовательность единиц и нулей, это нам и нужно сделать что-бы работать с этим методом Camera.cullingMask, представим что каждый бит в нашем int числе которое мы будем совать в Camera.cullingMask это флаг bool, а его позиция в числе равна индексу слоя в слоях камеры см.картинку 3, на картинке указана стрелочка ведущая к числу состоящему из одних нулей длинной равной длине нашего списка Layers из картинки 1 8 из которых зарезервированы системой, такое двоичное число нам и нужно представить что-бы после перевести его в int и сунуть в Camera.cullingMask , собственно вот и все что нам нужно для работы, соотносим где в этом числе из одних нулей должна быть единица 1 = true, 0 = false и переводим из двоичной последовательности в интигер который суем в Camera.cullingMask, см.картинку 4 с примерами какое целое число нужно совать в Camera.cullingMask , как оно выглядит в двоичном коде, и какие флаги ставятся в слоях на камере в результате... добавлю 3 пик, если вдруг позабыл как конвертировать из двоичной системы в десятичную, вдруг кому понадобиться...
Кстати попробуй скрыть/раскрыть слои через скрипт в Unity, уверен обосрешься, так что не шути мне тут, а если критикуешь то предлагай..
Про что несет, вообще охуеть. Слой скроем - обосремся. Про какую-то хуйню, скрипты. Ты можешь просто заткнуться?
Речь идет про слои рендеринга в Unity https://docs.unity3d.com/ru/current/Manual/Layers.html
Автор реагируя на комментарий мимо проходящего анона призывает его попробовать произвести манипуляции с указанными выше слоями, а точнее скрыть/раскрыть эти слои, дабы убедить его в не компетентности, что он выражает как >попробуй скрыть/раскрыть слои через скрипт в Unity, уверен обосрешься. Вот и все.
https://vk.com/peacewalkergame
АаааааААааааААа , это опечатка, сам класс назван правильно, каким образом я умудряются так лежать в одном и том же месте хз, спасибо тебе что замечаешь без сарказма если бы не ты, толку от этого треда вообще бы не было.
>https://2ch.hk/gd/res/258859.html#258859
Добрый вечер, ОП. Если ты один- еще никто не говорил тебе, что к июню этот тред будет пуст как упомянутый выше?
Не совсем понял с чего ему опустеть, Абу разрешил вести тред.
А, ясно, а то я уже испугался, ну ты заходи сюда периодически и поглядывай, я просто параллельно над несколькими проектами работаю, может создаться впечатление что я забросил или сбавил темп, но на самом деле в одном из них релиз уже мае и я часто переключаюсь между ними, работаю несколько недель над одним, несколько над другим. Но будь моя воля я бы работал над одним этим проектом все время, он мне нравиться и работать над ним приятно, а так я как раз последние пару недель работаю над этим проектом и затих чтобы сделать хороший бамп. Я понимаю почему ты так предположил, но не стоит равнять всех под одну гребенку, тем более что в этом году точно не будет никаких забрасываний, у меня оборудование оплачено и я договорился о всяких работах полевых по звукозаписи на лето, моя жадность не позволит его забросить по своей воле. Ну а в целом не переживай, все идет отлично, скоро бамп.
"Изометрическая RPG с пошаговой боевкой, сейчас в стадии написания тулзов. В будущем будет много всего крутого, в частности открытые инструменты для модификаций и хороший 2D изометрический арт в сеттинге СНГ, а так-же открытый мир , квесты, диалоги, хардкор и апокалипсис."
Ну и небольшой бамп тулзами для самого рендера, они конечно были с самого начала, с них все и начиналось вообщем, но их реализация на начальном этапе была очень примитивной, вообщем старый инструмент для рендера умел только делать скриншот, обрезать на нем альфу и сохранять в .png файл, с новым все намного лучше, однако он все еще довольно примитивный, но он работает я его не трогаю.
Вообщем новый инструмент делает все тоже самое, только теперь он отвечает новым требованиям которые собственно утвердились с написанием тех.дока для арта где описаны технические характеристики, размеры, пропорции, сам пайплайн и все то, без чего этот самый арт нельзя делать , не буду сильно распинаться и писать большую простыню из текста, все равно это никто не читает кроме тебя опишу отличительные особенности в сухой форме.
-Теперь можно создавать файлы скриптуемых обьектов ScriptableObject, в которые сериализуются задачи для рендеринга, в этих файлах можно задать свойства для рендера и параметры для выходного файла, такие как имя, путь, направления, свет, тень и т.д Все задачи для рендера находятся в одном пространстве за ними удобно следить, им удобно давать имена, и в случае если если какая-то ошибка всегда можно найти необходимый файл с задачами рендера и исправить проблему без нарушения структуры.
- Теперь есть умная система рендера в которой можно задать направления спрайта и больше не вращать их руками, можно просто задать рендер для 8 направлений и ждать пока все запечется.
-Теперь есть умная система для именования файлов, тулза сама понимает тип скармливаемого обьекта и в зависимости от типа дает ему читаемое имя, например если обьект составной и состоит из нескольких частей, то она отрендерит обьект целиком, каждую его часть по отдельности, и даст удобное для навигации имя, из которого ясно какая это часть обьекта, и их общее кол-во, тот же принцип например для рендеринга обьектов с анимацией, в таком случае в имени каждого файла указывается номер фрейма из общего кол-ва.
-Есть и что-то еще но мне лень вспоминать...
У меня уже было, но слетели куки, теперь переподписываюсь, мимо ОП.
один вопрос — зачем так пердолиться? а вообще добра тебе, подписан на тренд
Делать игру страшно - вдруг обосрешься? Делать то, что умеешь - хороший выход. И, вроде, делом занят, и не фейлишь. Сам за собой часто замечаю, что ухожу в yak shaving, стараюсь бороться с этим. Психология, хуле.
а может он просто хочет эту тулзовину потом продать, чому нет
Ну я не сразу к этому пришел, постепенно.
Олдфаг в треде, все в фидо! А вообще да, это она, использую в качестве референса для арта, но пропорции у нас разные, у меня плотность пикселей на единицу мира больше, сейчас же не 90-е, средний компутер очень мощный, могу себе позволить, а вообще 2к18, 2д изометрия в упадке, делать сегодня такой арт, как впрочем и хороший пиксель арт - "Метать бисер перед свиньями.", ценители/целевая аудитория уже потихоньку начинают умирает от старости и спиваться.
Напоминаю что я пока там >>497446 до релиза, а после сюда. Всем все платится.
Она охуительна кстати.
Пытался тут найти себе браузерку дляпоиграть. Нормальных игорей нет. Ну щас думаю я хапну приключений каких-нибудь ламповых, неторопливых. Хуй там плавал. Это пиздец. Я даже представить себе не мог, что рынок в таком упадке. Да что там упадке. В говне прямо. У нас ничего такого по качеству нет даже близко. 2018 год идет казалось бы..
Скоро вернусь и продолжу, Stand by.
Хорошо, вот вот приду сюда, правда за время работы над другим проектом пересмотрел концепцию этого, и буду фичикатить чтобы уменьшить срок разработки, в новой концепции ,скорей всего, проект станет линейней, а технически будет похож на java игру с пиков, на стероидах, все наработанные тулзы останутся, будет инвентарь тетрисом, боевка пошаговая, свобода перемещения, тулзы для рендеринга тоже останутся, но от живого открытого мира нужно отказаться оставить на будущее. Жду когда выпущу второй проект, а пока ищу интересные сюжеты, присматриваюсь к "нишевому маркетингу". Самосборы, динозавры, зомби, апокалипсисы... nobody know
Пикчи найсовые.
ОП, поделись секретом, как такую графику делать. Смысл понятен, конечно, берешь 3д модель и рендеришь ее в изометрической проекции, и я так делал. Но есть же какие, то нюансы, особые технические приемы. Например, как лучше сделать бесшовный скальный ландшафт таким образом. Дай ссылки полезные почитать.
http://www.gdcvault.com/play/1023202/-Fallout-4-s-Modular - модульный дизайн в Fallout-4 (примерно такой используется в ИТТ проекте.)
http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html - модули в Fallout 3 / Skyrim (советую купить и скачать редактор G.E.C.K./Creation kit, в нем можешь рассмотреть все модули, поиграться с ними, посмотреть как они соединяются и всякие хитрые трюки, почти все справедливо и для 2д изометрии, нужно только делать поправку на сортировку для отрисовки, (там есть и скальные модули))
http://archivewiki.fifengine.net/Game_creation_guide -
http://falloutmods.wikia.com/wiki/Fallout_2_tutorials - туториалы как делают арт моддеры в fallout 2 и симметричных проектах для изометрического движка.
https://www.redblobgames.com/grids/hexagons/ - мат часть (лучшее что есть)
http://www-cs-students.stanford.edu/~amitp/game-programming/grids/ - мат часть
http://theory.stanford.edu/~amitp/GameProgramming/ - мат часть (с примерами и картинками, для изометрии разных сортов)
2д изометрия что-то среднее между 3д и пиксель артом, так что тут справедлив и пиксель артовый подход (с палитрами, диззерингом, традициями). Самая важная часть это хорошо построенный Pipeline/Workflow и документация, важно понимать всякие размеры/пропорции/константы для рендеринга, чтобы получать красивые рендеры и контролировать/представлять спрайт на этапе создания модели, в основном это значения плотности пикселей (PPU-PixelPerUnit), всякие минимальные значения для конвертирования из геометрии в пиксель, чтобы не тратить время на всякие мелкие детали которые не считаются при рендеринге в спрайт. А в целом в изометрия бывает разная если делать что-то не столько гранулированное-модульное, как Commandos,Chicago 1932, Stasis, Total influence, то пайплайн будет сильно отличаться от того подхода который используется в модульных проектах типа Diablo, Fallout,This project, etc.
>от живого открытого мира нужно отказатьс
Так хоть и проще будет, но какое-то подобие опенворлда всегда лучше. С линейным миром можно облажаться, но при наличии какой-то свободы игрок сам найдет, как себя развлечь.
С фильмами такая же хуйня, все позорно линейно развивается, вот если бы убрать дауна режиссера и дать зрителю самому творить!
Где-то через недельку-другую, щяс пока учусь делать UI в фотошопах то что на пике это просто хаотично расположенные не связанные элементы, суть была научиться рисовать в подобной технике. , леплю унитазы в 3d символично в 3ds max и запекаю в спрайты, пытаясь понять как это делать правильно, попутно собираю из всего что запекаю пару уровней для прототипа.
Сейчас планирую написать основу для пошаговой боевки, для этого нужно переписать мой старый G.O.A.P. так чтобы можно было симулировать в нем время для имитации жизни при выходе и возвращении в локацию.(если простым увеличением таймСкейла на дельту прошедшего времени не обойдется) и поставить его на пошаговые рельсы, сделав два состояния для боевого (пошагового) и не боевого режима (реал-таймового).
Как напишу, пару недель потыкаю прототип на телефоне, посмотрю как чувствуется игра, сделаю выводы и начну перегонять тулзы с проекта ИТТ, в то что решил делать после переосмысления и фичеката. Насчет сеттинга пока не определился, думаю отложить идею с "снг" на лучшие времена и сделать что то более приземленное. А сюжет все еще ищу..
Можешь попробовать, но я все еще не определился с сеттингом, возможно это будет что-то вроде утопии с индустриальным ретро-футуризмом, а может и что-то простое с НЁХ, уровня Кинговского тумана. Если желание есть, то прошу к нашему шалашу.
https://т.ме /Emitter9
кстати нужны и художники (пиксельные тоже) и просто энтузиасты, тестеры
Нет, пока без билда, сейчас все еще думаю над архитектурой и жду свободного времени чтобы начать переписывать тулзы с вверху треда под этот проект.
>>518548
Ага, тоже сделал такой вывод, в следующий раз буду рендерить с сглаживанием, чтобы выглядело гармонично.
А зачем тебе love2d, когда у тебя есть юнити? У него какие-то плюсы свои?
На самом деле плюс только в размере билда, ну и в том что love2d не прихотлив, можно писать код в блокноте и компилировать прямо на телефоне. Ну и для меня еще плюс поддержка Raspberry pi из которого я планирую сделать аркадный автомат. Все это конечно только для 2D игр, использовать и изучать один только Love2D наверно не рационально, но если знаком с Unity или чем то схожем, то перекатится займет не больше часа, а в некоторых случаях написать что-то простое можно даже быстрее.
Часто на форумах задаются вопросом - где популярные игры на love2d, почему их практически нет? Ну и это наводит на мысли, что что-то с этим движком не так, может сырой, нестабильный или заброшенный, или каких-то важных фич не хватает.
Ну это справедливо для всех фреймворков и я бы даже сказал для конструкторов, есть исключения, но для коммерческого релиза важна обфускация, чего эти инструменты в большинстве не обеспечивают, и не только. Касательно сырости, не уверен на 100%, но если сравнивать с мейнстримными defold, corona, то Love2D старше и выглядит стабильней для меня. Фичи, а фичи не нужны мне , на самом деле все эти фреймворки как воробьи похожи, уверен написать что-то хорошее можно на каждом из них, а вопрос о том что есть из коробки лично для меня не критичный, но многих отпугивает например отсутствие встроенного редактора или аниматора, что скорей всего станет решающим фактором для таких пользователей при выборе фреймворка, особенно если это первый движок, а у меня наоборот, думаю выбор на Love2D падает как раз у подобных мне велосипедистов или у тех кто предпочитает свой движок. А Love2D как раз обеспечивает фундамент рисование картинки на экране, проигрывание звука, , а все остальное пишешь под себя.
Уже ясно что игоря от тебя можно не ждать, расскажи хоть что там было в диздоках.
Да не, ждать то можно, но не то что планировал в начале, ибо уж очень дорого вышло скилл нужен по серьезней, скорей всего я бы обосрался бы под самый конец, так что решил сделать фичекат и спасти свою жопу и репутацию, в двух словах о том что планировал до, и что планирую теперь.
До этого Диз.дока не было, был только Тех.док, в котором я чуть меньше чем полностью срисовал архитектуру с редактора G.E.C.K. под Fallout 3, это хорошо проследуется в классах и тех тулзах что были написаны. План был перерисовать архитектуру полностью, с поправкой на пошаговость, 2D, и изометрию, а потом додумать то что не удастся спиздить понять с помощью инженерного анализа редактора от беседки.
Так что в техническом плане был бы симметричный редактор и даже многие туториалы для моддеров под G.E.C.K. работали бы на моих тулзах. Это конечно не мое изобретение, на Unity уже были ребята которые работали по такой схеме и за успехами которых я следил перед тем как начать этот проЭкт, в частности https://openmw.org/ru/ - который под конец переехал на свой движок с Unity, и еще были ребята https://www.dfworkshop.net/ В общем план был написать редактор, наклепать арт, и собрать что-то отталкиваясь от возможностей редактора. Как ты понимаешь дизайн был второстепенный, так как для редактора не имеет большой разницы что нарисовано на .dds картинке, шутка про то что фаллоут это обливион с пушками.
В общем Диз. дока не было, но был вижн примерно для трех разных сеттингов с синопсисом для двух из них. Чтобы не писать длинную простыню из букв которые не кто не прочтет, разделю эти вижны на пару кратких постов ниже.
Ну и сценарным ремеслом я не занимался, хоть и страдал графоманией, писав всякие пасты, и короткие рассказы для графоманских тредов на дваче уровня НИИ тредов.
Но я знаю о структуре сценариев, точнее о стандартной структуре которую наверно знают все кто хоть немного интересовался сабжем, в двух словах все сценарии имеют практически одинаковую структуру, которую можно выразить на графике в виде кривой которая стремиться от начала, к кульминации, это скелет любого сценария, и есть так называемая трех-акт'ная структура.
Такая структура состоит из трех актов, вау! , обычно это около 100 страниц, 1 акт занимает 25 страниц, второй 50, и третий оставшиеся 25. Чтобы не уходить в оффтоп не буду описывать её здесь, но добавлю хороший пиксаровский ролик о сабже, https://youtu.be/2vR2TWqnP_8 все кому интересно может легко нагуглить об этом, к чему это я - можешь смело сформировать представление о том что это были не "Унесенные ветром" или типа того, мои сценарий имеют как сейчас модно говорить первобытный-инди вид, иными словами распиздяйские и посредственные.
Теперь к самим синопсисам этих сценариев ниже.
Как я говорил раньше бюджета у меня нет, поэтому для создания вступительного ролика который поясняет в сюжет было две идеи.
Первая отснять ролик с натуры с использованием старой VHS-камеры, и студентов театрального, которые готовы работать за еду и доступ к которым у меня есть. Кстати говоря это хорошая практика, о которой многие не подозревают, но студенты легко соглашаются на подобную работу, если вы сможете четко донести до них свои цели и будете достаточно профессиональны, профессионализм обычно выражается в аренде студии которую может снять любой школьник за скромные 1к деревянных, и простом договоре который составляется в произвольной форме,( на использование контента в коммерческих целях), ну и заказ пиццы в конце дня, это основной мотивационный фактор который заставит студента работать с вами, грубо говоря за 5к можно записать голоса школьников студентов, или отснять мокапы и т.д. для ваших проектов. Но эта идея быстро уступила другой, которая была проще в реализации, и требовала меньше усилий.
Вторая идея была сделать простой CG-ролик в котором нужны были только монотонные и безразличные голоса разных людей с простой графикой для их красивой транскрипции на экран, ролик представлял из себя запись голосов разных диспетчеров аварийных служб, которые в хронологическом порядке должны были погружать игрока в постапокалиптический мир нагоняя саспенс, в синопсисе это должно было выглядеть примерно так.
В начале в радио эфир поступают простые рутиные сообщения о всяких авариях которым не кто не предает значения, потом ситуация набирает накал и переходит в панику, после чего эфир замолкает, символизируя собой наступивший "пиздец", но после нескольких десятков секунд прослушивания радио шумов, в эфир выходит та самая номерная станция Излучатель-9, Которую кстати можно слушать в любой момент игры и на этом тоже замешан ЛОР о о которой я упоминал в начале, в которой звучат всякие инструкции и которая призывает всех выживших явиться в точку сбора. В хронологическом порядке это занимает несколько лет, имею ввиду от начала тишины в радио эфире и до появления сигнала номерной станции.У меня даже есть ролик, который я планировал использовать в качестве референса при создании своего, прикреплю его, для наглядности.
Эта идея меня устраивала, такой ролик был прост в производстве и отвечал требованием, к тому же тема номерных радио станций ИРЛ очень глубокая, не раскрытая, и интересная, ну и как ты понимаешь снаряжение и поход игорька к точке сбора и есть та цель которая отправляет его из первого акта, в второй.
В втором акте должна была раскрываться тема городского андеграунда свойственного пост-советским городам, по которым игарёк и должен добираться до точки сбора, андеграунд, эта еще одна тема которая мне очень близка, о культуре которой я знаю и к которой имею отношение имею ввиду диггер-кавес культуру , ну и главное я бы смог достоверно, с любовью перенести подземную геометрию с ее шармом, я конечно имею ввиду не столько метро сколько всякие коллекторы, обьекты ГО и прочее. С этим и должен был знакомиться игрок в втором акте, постигая ЛОР и постапокалиптический пиздец, через прослушивание номерной станции, всего что врывается в эфир, попутно общаясь с другими выжившими и отстреливаясь от всякой НЁХ и т.д. В совокупности это должно к концу второго акта привести игорька к противоположным от первоначальных выводам, и под конец второго акта предоставить выбор который будет заведомо неверный и последствия которого он будет исправлять на протяжении третьего Акта. Главным инструментом в этом видении игры, должен был стать арт, который должен был подкупать ламповостью, имею ввиду квартиры в панельках, с интерьерами той ламповой эпохи с плакатами COOL и наклейками терминатора на мебели, заброшенные магазины, кинотеатры, школы, дворы с паутинкой из труб и качельками которые так любим мы ну и механика геймплея как мне казалась была интересной.
Это примерный синопсис.
Теперь о втором синопсисе , индустриально - утопическом.
.
Он замешан на "Большом брате", в многом им и вдохновленный имею ввиду "1984" .
Синопсис такой.
Игарёк цепной пес режима, работает чем-то типа этик-офицера, того строя шутка про Ангсоц, для этого сюжета CG-роликов не планировал, в первый акт игрока должен был вводить сюжет первых 30 минут игры, по ходу которых на сколько я помню он должен был выполнить несколько квестов, которые должны поведать ему о жестоком мире игры, показать его не справедливость, выработав негативное отношение к режиму лол, дабы потом гг стал участником тайного собрания заговорщиков с целью убийства "большого брата", по ходу которого игорька вводят в план по осуществление оного и знакомят с главными ключевыми лицами, после чего игорек в опале отправляется на виртуальную сгуху, с целью дальнейшей утилизации, откуда он должен сбежать в второй акт.
В втором акте, игорек сбежав с сгухи и избежав утилизации, выполняет, различные действия и побочные квесты, на пути осуществления основной цели. Действия эти выражаются в встречах с различными NPC в разных городах, перемещения по которым осуществляется разными путями например на ретро-футуристичном, дизель-панковском поезде, FUCK-YEAH., или другими путями которые можно разделить по уровням сложности их осуществления, для игорьков разной степени вовлечености - тех кто не хочет заморачиваться, и для тех кто отыгрывает роль, и действует по условному стелсу. Ну и поскольку игорёк находится в опале, это выражается и геймплейно, в виде стелс механики, в которой ему нужно не попадаться на глаза, не находиться там где нельзя, выбирать правильные ответы, и делать всякие действия помню что планировал всякие фичи типа, если не купить билет на поезд в кассе или не украсть его, то после можно погореть на этом попавшись и т.д, кек.
В общем на протяжении второго акта гг должен выбираться из ретро-футуристичных ебеней окутаных снегом, останавливаясь в попутных городах, на пути к главному метрополису, попадание в который и заканчивает второй акт.
В третьем акте игорёк может пойти различными путями, как придти к успеху, так и гробанутся сюжетно.
Геймплейно почему-то я видел это чем-то похожем на Final Fantasy 9, но с пошаговой боевкой на изометрической сетке, ну и возможность переключать режимы игры из мирного в боевой режим боевой режим от мирного отличается тем что в боевом все NPC действуют по очереди с ожиданием хода, эта механика должна была сыграть в реализации стелса, должно было выглядеть как в Hitman GO, с запоминанием точек патрулирования и выбором момента для перемещения, довольна интересно как мне казалось, хоть GO игры и не взлетают, а жаль. В общем как-то так, ну я предупреждал это синопсис уровня, родился-потерпел-умер.
Далее о том что планирую теперь, но видимо уже к вечеру.
>Unity
И сразу нахуй.
>к которой имею отношение имею ввиду диггер-кавес культуру
Гном, плавающий в канализации?
В общем, я уже в скольз писал что буду продолжать работу в том же направлении, отказываться от тех инструментов которые уже написаны было бы глупо, тем более что успел реализовать не малую часть функционала редактора и написал его архитектуру, которую правда в боевых условиях не проверил, но поскольку я в большей части пИздел ориентировался на тулзы других аналогичных по задачам проектов, условно можно считать что они бы работали примерно так-же.
Но как я и говорил, фичи нужно порезать, по моим представлениям на текущий момент, нужно отрезать всю, так скажем sandbox'ную часть, которая наследовалась от G.E.C.K.'а, и сделать те же тулзы, но более проектно-ориентированными. Сам проект по сути останется таким же, на синопсис это не сильно повлияет.
Ну, а на текущий момент я пинаю хуи отдыхаю, пробую разные идеи которые приходят в голову, и набираюсь сил перед тем как начать всё заново. Конечно еще остались всякие темные места которые мне нужно проверить и решить перед тем как начинать все заново, в большинстве это вопросы о том могу ли реализовать ту, или иную фичу, и каким путем то, или иное реализовывать. Могу даже на скидку накинуть таких вопросов.
Основной конечно вопрос о платформе, на компуктере конечно очень приятно играть в подобные игры, наводя курсор и подсвечивая разные предметы, но бессердечный рынок говорит что лучше делать на телефоны или поддерживать сразу несколько платформ, что в моем случае мало вероятно, так как исходя из того, что я успел оценить и примерить, различия между мышкой и тач'ем будут большие, если конечно не делать виртуальный курсор и управлять им с тач'а подобно трекболу, так что нужно определиться, а скорей всего делать для телефонов, но если честно, то я бы с большим интузиазмом сделал подобную игру под геймпад или на какую-нибудь консоль с кнопками, и возможно под конец лета когда я планирую начинать осуществлять задуманное если вдруг анальные требования для получения сертификата под какую-нибудь консоль ослабнут, то я серьезно задумаюсь о том чтобы не писать под так не любимый мной тач будь он проклят Да, я знаю что можно подключать периферийные устройства к телефону, тот же геймпад, или клавиатуру с мышкой.
Ну и еще есть много разных прикладных вопросов, но чтобы не создавать простыню из текста опишу два, над которыми думаю в данный момент.
Один из них эта фича с динамическим световым днем, которая не дает покоя с самого начала, вещь довольна тривиальная, но из-за того что я плохо могу в шейдеры, мне нужно либо найти готовое решение, либо человека который напишет нужный мне шейдер, ну или попробовать написать самому. Я точно знаю как он реализуется, он очень простой, не знаю почему юнити не реализует подобное из коробки. Вот пример на двух пиках того что требуется, эта реально примитивный шейдер, в котором смешиваются и сабстрактятся два слоя, но это до сих пор не решенный вопрос. Да, я скачал из интернетов ассет с второй картинке, но он не совсем подходит
Ну и еще один прикладной вопрос, это вопрос архитектуры рендеринга спрайтов, если конкретней то рендеринга анимаций, а если еще конкретней то ты хуй, шутка рендеринг анимаций с взаимодействиями, например анимация NPC который садиться на стул, есть два пути, либо запечь анимацию как он садиться на пустоту, сделать её константной, и под эту позу нарисовать стульев,а после нарезать их на части слои, чтобы реалистично сортировать в глубину например когда игрок садиться на стул с подлокотниками, ближний к камере подлокотник должен рисоваться перед спрайтом NPC, а дальний позади, для этого их нужно нарезать и сортировать, либо запекать для каждого NPC спрайты прямо со стулом, а на момент проигрывания такой анимации, просто убирать лишний стул. И аналогичный вопрос с внешним видом NPC, их можно либо запекать сразу в нужном шмоте и т.д., либо запекать их голыми и рендерить отдельно шмотки, волосы, и т.д. Делается это так-же как со стульями, запекается каждый предмет по отдельности, для каждой анимации и пропорции тела, а после совмещается, и в конкретном случае позволяет их комбинировать. В общем вот эти вопросы и еще разные похожие нужно будет решить до того как начинать, а решаю я их пока в пассивном режиме, так как ЛЕТО, но подобно вопросу об отлетающих конечностях, рано или поздно я протестирую возможные варианты и выберу нужное решение.
Это если об основном проекте, но я еще и планирую написать маленький проект, с коротким сроком разработки, чтобы заработать на печеньки в период разработки сабжа, и планирую написать не один проект, а работать параллельно как это делал, до этого, но это уже совсем другая история.
Думаю такой проект в одно рыло придётся делать лет пять-семь.
Я сам на подобное настроен собственно, есть отличные игры, которые очень долго уже в ерлиаксессе, но они реально хороши.
Чувак, у тебя готов сюжет, диалоги и прочее?
Если что, могу накатать.
Оставь контакты в треде.
Спасибо, буду делать с геймплеем. В скором времени соберусь с силами, выкачу патч для другого проекта, до прототипирую UI для этого проекта, и начну писать инструменты и переписывать доки.
Ты бы сначала что-то похожее на геймплей запилил, потом делал UI. А то думается мне до рабочего геймплея пройдёт ещё пара лет.
Алсо, изометрию всё же собираешься херачить? Или что-то другое? Заготовки есть уже, концепты?
Да вообщем то геймплей и делаю, точнее собираю прототип, я выше писал.
Да, буду делать изометрию, заготовки есть см. тред, но нужно сделать фичекат того что уже есть, чтобы не сидеть над этим проектом слишком долго. Делать Буду по этому концепту >>522161, но без Sandbox'вых механик.
Сам ты тупой пидоран, что и подтвердил своим постом.
Причём тут вообще шэбм, дебил? Мне понравилась идея и описание, которые наложились на картинки просмотренные выше в треде и мне кажется получилась бы хорошая новелла. В купе с идущим в тот момент дождём это вообще зашло и создало очень ностальгическое ламповое настроение. Я даже переслушал всякую депрессивную музыку из говнарской юности, покурил на балконе и всё таки переборол желание пойти полазить по какой-нибудь заброшено стройке, которых в округе не осталось уже.
Так что соси бибу, тупой пидоран.
Да, как я выше писал, знаю что тут есть талантливые ребята в самых разных направлениях, любой кто хочет принять участие, милости прошу к нашему шалашу в телеграмм конфу https:// т.ме /Emitter9 , можно и просто добавиться, и молчать, это тоже помогает и мотивирует. можно добавиться и в соц сети. https://vk.com/unnamedtitle3
Даже не знаю что ответить, Frozen state, ты?
Да, отмороженный штат. А когда письволькер выйдет поиграть?
Да не, я имел ввиду что ты разраб отмороженного штата, я когда-то давно вписывался туда артистом, но быстро слился на другой проект не удобно вышло, но это норма, я подумал что ты узнал меня и поприветствовал как коллегу, лол.
Когда выйдет письволькер сложно сказать, но думаю что прототип с геймплеем запилю за 3-4 месяца , но я еще не начинал, сейчас только включаюсь в работу с лета, допиливаю обновление на старый проект, как с ним закончу начну рефакторить и переписывать.
Штош, буду ждать выброса калосбора выхода фолача в панельках, всем добра.
Лютый кибер-панк. Не хватает выпирающих баклонов, дополнительных внешних труб и восстановленой (после взрыва самопальных труб) отделки. Можно даже без неона - так нуар == 100500.
На текущий момент видение такое.
Во первых сериализация, то бишь сохранение, это краеугольный камень, я смотрел на файл сохранений в скайрим, чтобы понять как они решали подобную проблему.
https://en.uesp.net/wiki/Tes5Mod:Save_File_Format
Суть примерно такова - никак, они там хранят все, включая выпущенные в момент сохранения заклинания, заканчивая всей игровой датой кроме статической, это в некоторой степени дает понимания как у них устроена архитектура между редактором и игрой, если не вдаваться в подробности, то они клепают игру в редакторе, который генерит по файлу для каждого игрового обьекта, будь то - npc, квест, предмет или что-то еще, условно по завершению работы в редакторе все эти файлы пакуются в один "СуперФайл", который дублируется при начале игры и изменяется по мере прохождения, каждое сохранение это слепок измененного "СуперФайл".
Я пойду концептуально по такому же пути, но с сильными различиями.
Так как, мы таки инди разработчики, сделать возможность сохранять игру в любой момент конечно можно, но для нас это будет очень дорого, но это не единственная причина, еще я хочу чтобы игроки не злоупотребляли тактикой сохранений и загрузок, "позволяя игре создавать увлекательные истории из своих ошибок и неудач" об этом можно почитать https://dtf.ru/gamedev/27574-kak-otuchit-igroka-zagruzhat-sohranenie-v-sluchae-neudachi . Так что скорей всего я буду сдувать пыль с старой механики с SaveRoom'ами и сохранение будет осуществляться в специальных комнатах без летящих пуль и сложных состояний мира, вероятно путем взаимодействия с каким-то предметом, нужно придумать с каким печатную машинку нельзя . Ну и вероятно ограничу кол-во слотов для сохранений, либо ограничу сами сохранения.
Пока пришел к тому что NPC вероятно будут жить только в рамках одной сцены, а сами сцены как я и говорил раньше, будут камерные, примерно по размеру среднего экрана например типичная локация в панельном доме будет разбита на кусочки, отдельно подъезд, отдельно каждая квартира, иногда отдельно каждая комната . Хоть NPC и не смогут бежать за игроком перемещаясь между этими маленькими локациями, я постараюсь сбалансировать это например не выпуская игорька из локации во время боя в ряде условий, ну и конечно добавлю симуляцию жизни сцены, чтобы избежать случаев когда игрок покинет сцену, вернется через 5 минут, а там все замерло на том же месте на котором он ее покидал, сцена будет привязываться к времени, при загрузке сцена сравнит привязанное время с текущим, и грубо говоря перемотает сцену вперед на полученное значение.
Теперь о квестах, с ними я еще до конца не разобрался, но на текущий момент вижу примерно так. Квесты в игре вероятно будут не очевидными, в том смысле что не будет окна где можно будет почитать о текущих активных квестах, о прогрессе по ним и т.д. Квесты скорее играют роль "дата пакетов", по идеи сердце редактора и в частности квестов будет система "Condition / Event", в двух словах эта система которая позволяет выбрать условия или несколько условий с логическими операторами "И / ИЛИ", и так-же выбрать действие которое последует после того как все выбранные условия будут "True", так как редактор работает не в среде Unity, а в Билде, список условий и действий за хардКодены прописаны в коде, нужно будет просто выбрать из выпадающего списка нужное "Условие / Действие", список действий конечно содержит только простые операции, в других случаях можно будет дополнительно выбрать скрипт для исполнения, но к сожалению эти скрипты компилировать в Билде Плеере нельзя, так что каждый такой скрипт должен быть заранее скомпилирован в проекте, перед тем как им можно будет пользоваться в редакторе, но так как редактор будет для внутреннего пользования, это нормально. Не буду сильно грузить технической инфой и углубляться в структуру квестов, тем более что большую часть идей я спиздил, так что проще дам ссылку на то откуда воровал концепцию https://tesck.ru/index.php/Учебник_Bethesda_Планирование_Квеста .
Добавлю лишь что квесты по концепции служат не столько для всяких заданий типа "убей 10 лягушек", сколько для создания тем для диалогов NPC и управления их AI пакетами, ну а концептуально это работает примерно так, когда вы заканчиваете работу в редакторе и хотите посмотреть игру, редактор перед тем как создать "СуперФайл", перебирает все созданные вами квесты, читает список "Conditions / Events" для каждой стадии квеста, и в зависимости от "Conditions" развешивает слушателей https://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования) на каждый нужный обьект, после чего как я уже вскользь упомянул этот "СуперФайл" дублируется и игре уже скармливается вместе со слушателями, которые как часовой механизм приводят в работу игровую логику.
Пример: ЛевелДизайнер в редакторе создает квест суть которого "найти взрывчатку и убить лягушку" это плохой пример, т.к. здесь много тонкостей, но будем условно считать что взрывчатку по квесту мы можем подобрать любую, а лягушку убить конкретную, заранее созданную как квестовый NPC, причем она должна просто умереть не обязательно от рук игрока, у квеста есть две стадии , [стадия 1] найти взрывчатку, [стадия 2] - убить лягушку , "Conditions / Events" для каждой из этих стадий примерно такой
[стадия 1] [Conditions]= playerHasItem( ID_врывчатки ) / [Event]= ThisQuestSetStage(2) переключаем стадию этого квеста на вторую.
[стадия 2] [Conditions]= NPCIsDead( ID_лягушки ) / [Event]= GetAchievement(ID_achievement) получаем достижение
Итого при переходе из редактора в игру эти "Conditions / Events" преобразуются в слушателей, для
[стадия 1] слушатель подпишется на метод который запускается при подборе игроком предметов, для
[стадия 2] слушатель подпишется на метод который запускается при смерти NPC.
А после все это соберется в "СуперФайл", который скармливается игре.
Чувствую что мало кто осилит этот текст, ну и хуй с ним, это ведь в каком-то роде дневник, а подобные разборы помогают скорее не объяснить кому-то как что-то работает, а сформулировать идею самому себе, хоть я и старался описать концепцию доступно. Позже напишу про AI и всякое другое, а как переварю все запроектированное начну перекатывать в код. В общем по техническим спецификациям уже смутно формируется проект...
Нихуя не понял, то есть ты хочешь создать свой рпгмейкер/редактор уровней, вшитый в билд игры, чтобы любой мог сам пилить свою игру?
Иначе непонятно зачем так извращаться, цена всего этого функционала 100$ в ассетсторе, если ты на юнити пилишь.
>ты хочешь создать свой рпгмейкер/редактор уровней, вшитый в билд игры, чтобы любой мог сам пилить свою игру?
Да, не рпгмейкер конечно, но редактор с инструментами..
Я думал написать расширения для редактора Unity, чтобы работать в инспекторе, но получается что мне проще написать редактор для билда, ну а готовые решения просто не подходят под мою архитектуру. Так что я собираю уровни в своем редакторе когда-то он выглядел примерно так >>471541 , но до того как собирать уровни нужно запечь 3д модельки в изометрические спрайты, тут тоже свои инструменты, наверняка их тоже можно купить, но переделывать чужие требования под свои было бы дольше. вот как выглядел мой инструмент, он работает в инспекторе на scriptableobject'ах. >>489335 , ну и после того как эта тулза нарендерила спрайтов, нужно их собрать в атласы, расставить правильно пивоты, нарезать, для этого уже купил сторонние инструменты >>489412.
Ну и не надо забывать о том что я буду работать не в одиночку, и редкий левелДизайнер осилит unity с git и научится оформлять коммиты, в случае с моими тулзами нужно просто отправить пару сгенерированных файлов. Ну и повторюсь что сторонние решения я уважаю, и не пренебрегаю, но для этого проекта они не подходят, а переписывать их под мою архитектуру будет дороже. Не буду углубляться в свою архитектуру, у меня есть уж совсем специфические классы обьектов, и инструменты для работы с ними, но взять даже простую локализацию, у меня есть много независимых инструментов которые генерируют текстовые данные, которые нужно локализовать, мои инструменты сами генерируют все данные для локализации в единый XML файл по мере работы, я закладывал это в архитектуру всех своих инструментов, ну, а если начать переписывать сторонние решения под одну только локализацию, можно потерять кучу времени, да и в любом случае всех нужных инструментов не найдешь.... я конечно присматривался к чему-то вроде https://habr.com/post/335512/ , но не вариант.
Вот нашел старую шебм с всякими тулзами, сейчас конечно они выглядят по другому, но смысл думаю понятен.
>https://dtf.ru/gamedev/27574-kak-otuchit-igroka-zagruzhat-sohranenie-v-sluchae-neudachi
Забавно, что буквально вчера смотрел то видео, которое они пересказывают.
А сегодня в одном из его же более старых видео вскользь упоминалась система сейвов из ори энд зе блайнд форест как одна из хороших вещей 2016 года.
Хули на связь не выходишь?
Да, проебался что-то.
Я живой, пилю проект. Сейчас делаю главное меню, арт и звук для него, определился с андроидом, буду делать под него, как запилю менюшку, скину апк'ашку.
сейчас используется референс заставки, потом конечно найду актеров и запишу с ними свою версию, по своему сценарию. Так как CG роликов не планируется, нужно будет постараться сделать так, чтобы единственная заставка не сильно бросалось в глаза и смотрелась гармонично. АПК'кашку решил не заливать, но в конфе есть. Далее буду переносить редактор....
Идею я честно спиздил у старой флеш игры, но к сожалению не смог ее найти, если кто узнает механику, напишите соус.
Ниже описание в паре предложений.
Игра про "Автонома" с первого пика, немного в стимпанковском стиле, основная геймплейная механика это управление этим самым "Автономом", которое осуществляется с помощью двух кнопок, ехать, прыгать, так как "АвтономЪ" не совершенный и вообще он Legacy, ехать он может только вперед, игрок не может выбрать направление движения - влево или вправо, "АвтономЪ" сам меняет направления когда его сенсоры улавливают перед ним стену или препятствие. Ну и не смотря на заводной ключ на спине, свойственный механическим устройствам, у него паровой механизм, и он расходует пар на все движения, объем бака с паром ограничен, так что ему нужно следить за расходом пара и планировать свои движения с учетом всех специфик его управления. Но это не мешает ему придти к успеху. Сможешь ли ты совладать с ним?. к е к
По факту platformer, puzzle.
Запилил прототип, с платформами и шипа, присмотрелся, думаю делать по концепции выше или сделать что-то большее, например разрешить игорьку двигать во всех направлениях и запилить npc с диалогами и грибами, как-то душит жаба тратить арт на что-то простое уровня джема. свой редактор в этот раз не пилил, использовал Tiled и написал под него свой парсер.
Спиздил идею и выпустил в стим.
https://store.steampowered.com/app/606500/HellSign/
>>539268
Врёти, это не мое, я то как червь медленный, только начинаю перекатывать редактор. Да и графоний у меня запеченный 2D.
будут в стеке в момент активных передвижений (боя), и все ходы можно будет считать по очереди хоть до утра, Сид Мейер подтвердит. Из интересностей в поисках путей разве что инфа о простреливаемой геометрии, так как это инфа статическая, запекаю ее в узлы поиска путей, для тактических расчетов ИИ
(по сути просто байт, где 0 - полностью простреливаемая, 255 - не простреливаемая, я просто вычитаю из потенциального урона этот байт и взвешиваю то что остается, + штраф за расстояния ) , после прикручиваю их в проЭкт к редактору, и сериализатору, чтобы можно было начать отлаживать редактор локаций. по сути редактор будет такой же как планировался в прототипе, например здесь >>471541 , добавлю только пару-тройку вещей типа мульти-выделения сцены как я говорил маленькие, практически камерные (не вылезают за экран), я раньше считал, что я проще переставлю нужные обьекты вручную, чем буду писать еще больше кода, но раз уж делаю рефакторинг, то добавлю. . Еще добавлю систему Undo/Redu раньше считал что это для слабаков и трусов, но написал подобную систему для редактора в "OpenBobbyCarrot" , понравилось, решил и сюда тоже сунуть. Ну и всякое говно которое не успел написать в прототипе, например тулзы для работы с светом когда пилил прототип у меня и шейдеров то нужных не было. В основном большая часть редактора это не инструменты для создания сцены, а всякие обработчики-интерпретаторы логики - маркеры, ентити, триггеры, маски...
В общем "всем все платится", но перед новым годом я как червь-пидор, отвлекаюсь,работаю вяло, пишу сумбурно...
Да, но не совсем так, в основном я пишу инструменты для плеера, эти инструменты работают в билде, и они заточены под конкретный проект, расширения конечно тоже пишу, например >>489184 конкретно этот инструмент для автоматизации запекания спрайтов, ибо в ручную каждую модельку - запекать, вращать для разных углов, переименовывать .png'шки, и рассовывать в атласы, занятие сомнительное. А общем-целом я делаю игру, и написание инструментов является следствием этого. Ну и добавлю что это норма для почти всех сложных* проектов, ибо unity использует компонентную drug & drop архитектуру-среду для разработки, что подходит только для простых задач, и расширения среды это нормально.
Для большинства проектов хватает стандартного тайлового редактора, и даже он не всегда нужен, и вполне успешно можно перетаскивать спрайты, и вешать компоненты вручную, просто на стадии формирования тех.дока нужно взвешивать время которое уйдет на ту или иную задачу, и сопоставляя находить пути-решения, просто в моем случае таких мест много, даже простое размещения спрайта на карту сопряжено с всякими операциями, произведения которых вручную, в конечном счете будет стоить дороже чем написания инструментов для автоматизации, но я не маньяк-велосипедист, честно, я стараюсь не изобретать велосипед, там где и так сойдет.
- Сколько-сколько у тебя детей?
- Пятнадцать: семь девочек и восемь мальчиков!
- Вот я, например, люблю курить "Беломор канал". Но иногда, все-таки, вынимаю папиросу изо рта.
Я очень люблю мат, но в таком количестве он не понравится ни одному человеку, который дорос до получения паспорта. Информативности в диалоге критически мало, но куче народа нравится читать.
♥
>>543007
Спасибо за фидбек. Я тоже люблю чтоб "Мясо, матюки, убийства и голые сиськи!", полностью согласен с тобой в подходе к их использованию. Диалог на шебм был сделан для теста системы диалогов, этот диалог не плод моих фантазий, я взял его из фонда классических диалогов о казино, и сделал это скорее ради потехи, в саму игру в подобном виде он не попадет, но вероятно я буду использовать цитаты для реакций NPC.
Неслабо ткнул обосравшегося тупого пидорана рылом в собственное говно
Вот оно чего. Не знал об этом меме. У видоса ритмика другая (в честь "живой озвучки"), хотя видос мне тоже наскучил.
>Вот оно чего. Не знал об этом меме. У видоса ритмика другая (в честь "живой озвучки"), хотя видос мне тоже наскучил.
Дизеринг как делал? Видел пару ассетов, у тебя наверное тот самый который бесплатный
Вот тут Атлас >>542956
, паллет дизеринга в правом-нижнем углу, шейдеры не использую, дизеринг на ковре и стенах это спрайты, дизеринг во время смены экрана, это анимация спрайтов.
Простой скрипт который получает FOV и скейлит под референс разрешения, пробовал нативный пиксель перфект от юнити, мне не подошло.
Кстати если что планирую наращивать активность свою в соц. сетях , так что буду рад если подпишитесь, там же есть отделная группа для ИТТ проекта изометрического . https://vk.com/emitter9studio
Такс, если не вдаваться в подробности, то использую что-то типа Системы Хатчинсона + свои костыли использую систему очков, но к Хатчинсону она уже почти не относится, веса очков на инжинерены нейронкой, не моей, и не мной, а вероятность планирую методом Монте-Карло не использую всякие кешированные матрицы для расчета вероятностей как пишут в интернетах, делаю по казуальному, ну и еще использую тейлзы подсказки которые можно считать наблюдая за игрой .
Тейлзы, со стороны ИИ к игроку это только тайм-тейлз / тайм-банк, со стороны игрока к ИИ , это тоже тайм-тейлз ,чат-телзы, и всякие тейлзы которые можно прочитать по анимациям персонажей, например ИИ отыгрывающий глупого игрока долго сверяет свои карты, относительно комбинации, чаще проверяет карманные карты и т.д.
Это должно работать так, чем глупее ИИ тем объективней считываемые с него тейлзы, например умный ИИ принимает решения о рейзе, блефе и т.д примерно за одно и тоже время, а в качестве блефа может копировать поведение глупого ИИ, ну а глупый ИИ все решения принимает за разное время и вообще рыба.
Вообще ИИ в покере та еще ебола, почти все что о нем говорят правда.
https://ru.wikipedia.org/wiki/Система_Хатчинсона
https://ru.wikipedia.org/wiki/Метод_Монте-Карло
http://www.pokermoscow.ru/blogs/littleinsanity/13147.htm
забыл, еще тут основа, всякие ауты-хуяты, эквити-хуеквити, это фундаментальные вещи.
www.poker-wiki.ru/poker/Категория:Математика_покера
https://youtu.be/COL3f0mMwNI
да, в целом я делал что-то похожее на то что было у PODBOT в ламповой cs1.5, 1.6
Кстати довольно полезный код для тех кто хочет вкатиться в ИИ , там в основе стейт-машина, все очень просто. Но для тех кто уже вкатился, я бы рекомендовал GOAP
https://github.com/evandrocoan/MultiModServer/tree/master/dependencies/server_files/gamemod_common/addons/podbot/source
https://youtu.be/CH0pTCCul_s
Судя по результат, работает он над котлетками с пюрешкой..
Я тоже думал изометрическую игру сделать, только не знаю, что там делать. Закликивать всех к в диабло не интересно, тактические пошаговые бои не интересно. Не знаю, что еще можно.
Занятные велосипеды, вот только одно не пойму - нахуя юнити в этой схеме, если понаписали столько велосипедов. С тем же успехом можно было поверх голого SDL нахуячить свои редакторы, и вы бы получили в десятки раз более компактный и шустрый билд, плюс респект сообщества.
А так ни от нормальных посонов, которые мочились на юнити, респекта не будет, и от самих юнитеков тоже, они скажут, вы чё, ебнулись там, пользоваться юнити и не таскать ассеты?
Например, сейчас продолжаю осваивать сетевые технологии, это принимает серьезный оборот, я начал задумываться о смене технологии, с unity, на свой движок* построенный над фреймворком LÖVE , с LuaJIT, SDL,BlackJack,Whores и т.д. Этот бы оценил >>570086
Начал перекатывать часть инструментов и извращаться. Пока дошло до того что написал клиент-сервер, работающий под raspberry pi, я даже задумываюсь о том, чтобы сделать что-то серьезное под эту платформу, точнее писать будущие проЭкты и под это железо..
>начал задумываться о смене технологии, с unity, на свой движок*
Это значит, что игр от тебя мы так и не дождемся?
Это было очевидно, ему пердолинг интереснее создания игор.
Чем представил ОПа в образе пикрелейтед. говорящего МММММ ПЕРДОЛИНГ. и проиграл.
https://www.youtube.com/watch?v=8-4P1WPE-Qg
>Это было очевидно, ему пердолинг интереснее создания игор.
Та, не, я же давно девелуплю, очевидно что моя гд деятельность не состоит только из того что есть в треде, я аутсорсю всякое, причем часто как художник 3д, а не программист, лол, а самое смишное что я левел-дизайнер, кек.
>>580082
>Это значит, что игр от тебя мы так и не дождемся?
Та, не, это замена по сути ничего не меняет, можно описать аксиомой Эскобара.
Но, посмотри на это с другой стороны, если предположить что я продолжу двигаться в масс-мультиплеерном направлении, а именно туда я по последним ощущениям скатываюсь, подобная рокировка дает больше плюсов чем минусов.
Не буду касаться всякий петушиных аргументов связных с производительностью, большинство устройств имеют фиксированный фреймрейт, что юнити, что любое другое, работает достаточно быстро для моих запросов, и конечному пользователю глубоко похуй на нашу под коверную возню, из петушиных плюсов отмечу все таки один, это размер клиента/билда. Условно на юнити пустой проект весит под 50 мб установленный, а в выбранном мной фреймворке проект весит несколько килобайт, если уже установлен на пк, либо по весу всех .dll в совокупности ~ 6 mb.
Ну, а из плюсов это собственно JIT - компиляция, это решает большую головную боль которая была у меня на юнити, если бы я продолжил пилить редактор с учетом моих хотелок, то мне бы пришлось либо интегрировать скриптовый язык для моего редактора, либо делать что-то типа конструктора логики, так как, на юнити новый код в скомпилированный проект не сунешь, нужно перекомпилировать билд. А при компиляции на лету, я могу просто дать возможность писать скрипты, и попутно это решит проблему с модами, так как я не планирую делать обфускацию Lua легко декомпилировать даже если делать, любой сможет поковырять код, написать любой аддон и заменить что-угодно на паровозика-Томаса, или что там моддеры обычно делают. Компиляция на лету так же облегчает загружаемый контент, я могу передавать по сети весь контент, включая код, что будет плюсом если писать ММО. ну, а еще это быстро работает, как нативный код на си или си++, КО-КО-КО
Ну и плюсом будет то, что не нужно будет платить оброк за использования, и лицензию, сейчас конечно похуй, и это не аргумент, но если целиться на развитие и расширения, то это может оказаться весомым аргументом.
Наверно есть и еще плюсы но лень думать...
А какая часть проекта у тебя будет на Lua, много ли будет C/C++? Я как-то невзлюбил динамические языки. Удобно ли на них писать большой проект?
>много ли будет C/C++?
Нет, основной язык lua, на C/C++ по сути только .dll , работа с этими языками идет через FFI - Foreign Function Interface на вскидку api для внутриигровых покупок, рекламы и т.п.
>Удобно ли на них писать большой проект?
Хз, я могу пока только проецировать, подобного опыта у меня еще нет, ну, и опыт у меня только в разработке игр, но почти на всех конференциях по lua спикеры упоминают например Adobe Photoshop Lightroom, ZeroBrane Studio, который на нем написаны, я этими тулзами не пользуюсь, не могу оценить объем проектов, но думаю что большие. Ну а в игровом направлении используется очень широко, от Свалкера до ВоВа, на нем написаны большие, серьезные вещи, в сталкере насколько помню АИ на луа GOAP - кстати, в ВоВе все аддоны, которые бывают больше чем некоторые проЭкты, в ГТА скрипты и моды...
Так когда будет рабочий прототип, чтобы мы могли начинать делать моды?
Выкатывай хотя бы прототип своего конструктора, чтобы я мог запилить в нём свой фоллач.
>Зачем?
Это весело и нужно качать скиллы, подтягивать слабые места, рано или поздно все равно придется разбираться с этим. Но оказалась что это довольна просто тупо отправлять массив байтов "пакет" как "с.м.с" на телефонах и после первого отправленного халлоВорлд'а и написанного чата, я капнул в сторону того как организован пакетный обмен у клиента-сервера в больших ММО, нашел сниферы и документированные пакеты для линейки - http://fursoffers.narod.ru/Packets.htm
А после еще и хорошую статью про то как синхронизировать клиент-сервер и решать связные проблемы - http://www.ant-karlov.ru/PlayerIO-onlayn-igri-v-realnom-vremeni.html
Так что очевидно нужно закрепить полученные теоретические знания практически применив их. Может это во что-то выльется, а может я успокоюсь написав какую-то часть кода, в любом случае это не пердеть в плед, и открывает новые перки улучшая связанные характеристики.
Я их и делаю, а рисёч неотъемлемая часть этого, есть жи.
Каждый раз проигрываю как в первый.
КаВО? Falco software уже сделали свой движок, кек.
Все уже и забыли что там была за концепция.
Я только помню что ты там собирался пилить что-то с миром мёртвых, что звучало очень интересно, атмосферно и в общем многообещающе на письме, но потеряло сразу же мой интерес как только ты написал, что это будет какая-то говноподелка для андроида.
Спизжу как я твою идею про мир мёртвых и выход оттуда на время,раз тебе она не нужна.
Та это не моя идея, наверно какого-то еще анона.
Из тех что я мог написать были ...
Про пандемию-апокалипсис и мистическую номерную станцию.
Про ретро-футуризм и большого брата, в этой концепции в основном механика интересная.
А про мертвых была покерная игра, большего всего кстати жалею вечерами об этом проекте, нужно будет допилить. Там идея была что ты умираешь, попадаешь в ад, вместе с другими грешниками, но тебе дается шанс вернуться, если выиграешь турнир в покер среди грешников. Нужно было играть в покер в халупе, слушая бредовые диалоги и крутую патифоную музыку.
>ты умираешь, попадаешь в ад, вместе с другими грешниками, но тебе дается шанс вернуться, если выиграешь турнир в покер среди грешников.
Ты придумал Pyre на минималках.
Ёбаный в рот, аноны, это отличный тред, потому что он показывает, как НЕ НАДО делать игру. Лид геймдев два года обдумывает архитектуру каждого стула, а мог бы делать игры.
Двачую, уже по самосбору давно можно было игру выкатить. А он все хуйней мается.
но человеку нравится сам процесс, он получает удовольствие от разработки, а у тебя полигры склёпана из говна и палок.
>>608812
Сделать игру можно и за день так-то, сомнительный кпд. А вообще меня ММО съело, тут есть над чем сидеть, не считая что тред это не дневник разработки, а что-то типа dump треда. Но мэсседж я уловил, обещаю, вкачусь в следующий джэм, если ткнете носом за день до начала.
> самописная ммошка от кирилла
> // 9 На аккаунте не осталось времени
БОЛЬШИЕ ПЛАНЫ
Проекции, нет больших планов, просто архитектура клиент-сервера, и та на реверс-инженеренная...
нихуя ты жаришь
я когда браузерку пилил тоже заебался адово, но ты ж поехавший, байтоебить полез. респект таким пацанам. не останавливайся. добра
Лол, это моя идея была наверно, я тред создавал.
Игрок попадает в чистилище, представленное городком из совковых бараков с вечной ночью, где такие же несчастные основали что-то вроде поселения. Можно временно возвращаться в реальность, при этом обычные люди тебя не замечают, ты призрак. Увидеть могут только те, с кем при жизни был контакт (расследование причин своей смерти - основа сюжета). Из реала можно вынести некое ограниченное количество вещей. Но чтобы вернуться в реал, нужно найти портал, порталы рандомно разбросаны по пустошам вокруг городка, их местоположение всегда меняется. Пустоши населены НёХ и всяким неприятным дерьмом вроде обрывов и кислоты, если там сгинешь - возродишься в бараке с потерей всего лута (который можно будет вернуться и забрать с места "смерти").
На подобных "сталкерах", таскающих вещи из реала строится жизнь и экономика городка, т.к. хоть ты и не можешь уже умереть, все хотят привычных вещей и комфорта.
Я могу запилить механики для этого >>608912 в тжриде с изометрическим видом сверху, только ассеты мне запилите, моделек и аутентичного 2д-арта.
Да, да, я именно об этом.
Странно, что я тебя перепутал с этим аноном.
А где твой тред?
> Я могу запилить механики
> только ассеты мне запилите
Все так могут. Только вот моделеры с художниками знают себе цену и, в отличие от прогеров, бесплатно не работают. Бесплатно можно только говна поесть на всяких там опен-гей-мартах.
Поэтому сидим и ждем дурачка, который бесплатно нам ассеты запилит.
А могли бы абстрактные игры делать, вроде OpenHexagon - ты треугольник, четырёхугольники хотят убить тебя! Избегай стен!
>>569921
Занятные велосипеды, вот только одно не пойму - нахуя юнити в этой схеме, если понаписали столько велосипедов. С тем же успехом можно было поверх голого SDL нахуячить свои редакторы, и вы бы получили в десятки раз более компактный и шустрый билд, плюс респект сообщества.
А так ни от нормальных посонов, которые мочились на юнити, респекта не будет, и от самих юнитеков тоже, они скажут, вы чё, ебнулись там, пользоваться юнити и не таскать ассеты?
>>535598
Охуенно. Самобытно, клаустрофобно, глаза разбегаются, но суть намеренной обстановки передается сполна. Не слушай местных хуил, у них нет вкуса.
> Но я знаю о структуре сценариев, точнее о стандартной структуре которую наверно знают все кто хоть немного интересовался сабжем, в двух словах все сценарии имеют практически одинаковую структуру
ржовая позиция, но у воннегута ржовее
https://www.youtube.com/watch?v=GOGru_4z1Vc
>>522462
> Это если об основном проекте, но я еще и планирую написать маленький проект, с коротким сроком разработки, чтобы заработать на печеньки в период разработки сабжа,
Тоже вот только решил сделать небольшой сайд-гиг, так он, видно из-за моего перфекционизма, медленно но верно морфирофал в собственно в ДАВНО ЗАДУМЫВАЮЩИЙСЯ МАГНУМ ОПУС, слился с ним воедино, восполнив недостающие детали гейплея. Вот и пиздец. Уже и сайд прожекта не могу сделать.
Конечно странно что ты начал с UI лол. И с сетевого кода лол. И вообще с A*, это же неимоверный велосипед сам на этом же проебывалсялол. Насчет тулзовин еще могу тебя понять. Сам щас пилю одну (для прогеров, и то только тех кто оценит с нужным скиллом). Сроки прототипа это откладывает по-сути, но хочется работать как человек, а не обезьяна, поэтому да.
Лан, телегу я твою запомнил, есличо буду знать где искать енвайронмент артиста, если ты не против конечно. Но не будем загадывать.
Арт смотрел с удовольствием, подписался, удачи тебе : )
С отзывом на меню я тебя немного наебал кста, оно неплохо, но реально охуенно будет когда впечатаешь текст в телик (как будто он на нем и показывается). Сейчас текст меню хуйня. Только рандомный зум оставь обязательно, пусть юзер мучается, ибо нехуй. Зум - изюминка этого меню.
Этот был прав, в итоге ОП начал писать свой движок на SDL, и проект переехал под raspberry pi, и на нем нативно работает сервер и клиент. Движок пилится с февраля этого года, вероятно к концу года ОП приступит к написанию тулзов уже под свой движок,кек. Движок с архитектурой E.C.S. написан на luajit , с использованием фреймворка LÖVE.SDL2,OpenAL,Box2D, etc... В дальнейшем планируется переписать фреймворк на свой, но это ничего не поменяет, т.к. love это и есть голый SDL.
Знаю что в марте было примерно так.
https://youtu.be/vCGpX38dLf8
Сейчас знаю что делается именно тех. демка. Знаю что там будет демонстрация потокового стриминга локаций, будет рельса длинной в несколько километров, по которой будет катиться камера, бесшовно погружая уровни и демонстрируя всякие системы движка и все это должно работать на raspberry pi.