Моё перерождение в командира слизи
Хей-хей, ребята, это снова я, Значки.
И я снова хочу попробовать сделать хентайную игру, с крутой рпг-составляющей, генерацией мира, добычей ресурсов, исследованиями, производственной цепочкой и строительством базы.
Если получится, конечно!
Разработку решил разделить на циклы по три недели, которые поочерёдно будут включать в себя рисование, написание программного кода и сочинение каких-нибудь композиций — чтобы поменьше уставать из-за работы над одним и тем же.
Отчёты по проделываемой работе будут находиться где-то в комментариях.
Посмотрим, сколько я продержусь и чего смогу сделать на этот раз ^__--
- 02 января 2020, 19:40
- 07
Цикл 1, день 10.
Немного провтыкал с началом периода программирования, но (вроде бы) нормально покрасил первые четыре спрайта из главной эволюционной линейки слизьки.
Особенно горжусь кистями рук старшей слизи (самая правая).
Процесс их рисования остался за кадром, но это было что-то из топ-10 эпичных аниме-битв, ребята.
Завтра начну трогать юнити и C#.
Не знаю уж, что там наковыряю, но постараюсь успеть за следующие несколько дней хотя бы спрайтик какой на экран научиться выводить, лол.
Прикольные спрайты. Растешь!
Спрайты да. C# - про игру можно забыть, будешь месяцами читать про итераторы и короутины. :yak: Ты вот Питон (или то был Луа? я забыл) пробовал, и то там чё-т решил не продолжать, а тут берёшь полновесный не-скриптовый язык общего назначения. Нуууу... такое.
Самые правые кисти и вправду хороши.
Это вопрос мне или Разери?
Я Луа пробовал, но не продолжаю не из-за Луа.
Разери тоже пробовал Луа. Но там как бы дело не в самом Луа, я полагаю, а в том, что Лёв, как фреймворк, предоставляет самый базовый минимум, и нужно писать велосипеды (ну или брать готовые решения, что тоже сопряжено с некоторыми сложностями, возможно)
В Юнити может быть всё иначе - я не пробовал, не знаю.
Я тоже пока что не знаю, но через какое-то время у меня хотя бы будет более точная информация и выбор.
ну хз чо там месяцами читать про итераторы и корутины, тем более что в гугле комментированный код для юньки есть практически на любой возможный случай.
один раз понять, всю жизнь пользоваться
Мне щас бы опять перейти на личности и спервадобейся (типа, если там нечего читать, где вот конкретно ТВОИ игры более чем конкурсного формата?), но от этого устал уже я сам, и обсуждать это просто не буду.
лол. в стиме
Это я и назвал конкурсным форматом - на коленке и по фану делается легко. Я даже не о продажах, а просто о интересе и объёме геймплея. Раз уж на Стиме, то там сразу видно и интерес в разрезе публики, а не только мнение одного анона с одного Гамина.
ваще хз как ты притянул сюда антирес(Greenlight;Price: $8.99;Owners: < 20,000;Followers:55) и объем геймплея - раз уж мы говорим о коде. У меня есть траблы с геймплеем, с рисунками с модельками, с левелдизайном, но вот проблем с кодом, тем более неразрешимых проблем - ваще не встречал.
Любая проблема с кодом на юньке в течение пары часов разрешается мануалами, гитхабом и плагинами. Полностью разрушаемое окружение без просадок - ня, шикарный UI - вот он, шейдеры, сетевой код, встроенная реклама - из коробки. раннер в котором мир заранее генерируется на основе битов музыкального трека и реагирует на частоту и амплитуду нот через полгода баловства в пограмирование - achievement unlocked. ну и докинем туда сабстенс, мекаминм, синемашин, пробилдер, навмеш - и может так случится что и несложные итераторы и корутины даже не понадобятся
предсказание интереса публики к игре по возможностям языка - это какой-то оч сильное колдунство
Вот уж компонент игры таки да.
Не показатель для рекомендаций всем подряд. Достигаторство не делает игр, а делает только достижения. Увы, у людей господствует именно такая логика, поэтому почти все годами "делают" "игры" и "советуют" "инструменты". Вообще в инди-геймдеве мира, я не про Гамин. Никому не интересно брать и херачить как чёрт, как это по-трушному в девяностые делали. Нет, не в пост-СССР (и даже частично не-пост), а там, где делали игры в это же время.
До этой мысли нужно 2-3 фазовых перехода пройти от моих высказываний.
ну это достигаторство которое полностью зависит от удобства кодинга
Это не всегда кодинг, а в идеале это должен быть вообще не кодинг, но мы всё ещё в 2020.
Я кстати сейчас тоже переучиваюсь на C# в юнити, свой код пишу так чтобы не было вообще корутин,
я просто их не люблю, так что можно и без корутин писать. Всё время обычными переменными мерю, а для диалогов и других задержек пишу специальный внутренний язык, точнее переписываю с JS на С#, чтобы оно работало без компилятора, а то компилятор в юнити сильно раздражает, чем больше скриптов, тем больше паузы между компиляцией, даже если просто в код добавил коммент или одну букву.
В целом соглашусь, что C# это слишком жёстко для начала.
PS выглядит скриптер как обычный текст) а я его разбиваю через space и return символы,
а потом с помощью switch ищу нужную функцию, только начал движок, он ещё такой чистый,
но потом опять будет грязь и куча мусорных скриптов и файлов, которые забыл зачем сделал,
не знаю как вести свой проект чистым, видимо нужно чтобы инструментарий был готов, а в юнити есть много вещей, которые нужно либо самому делать, либо ассеты искать, и потом получается свалка((
Сабж учится за три часа, и нужен раз в полмесяца.
А для ГМа учится за 0 часов и нужен раз в никогда.
???
Это только один пример, таких вещей много.
Вот кстати Game Maker, мне кажется отличный инструмент для Разери.
Он полегче в разы будет, чем юнити.
Меньше придётся писать дополнительных скриптов.
Я не имею ничего против Game Maker, как впрочем и других инструментов, но мне кажется нет легких или сложных движков если их рассматривать в таком ключе. Есть движки и инструменты с которыми ты хорошо знаком, а есть - нет. Поэтому даже если Game Maker и кажется простым, то если человек не имеет опыта по его использованию, он возьмет то, что ему ближе. Я не говорю конкретно о raseri. Я говорю вообще :)))) Когда мы рассуждаем на такие темы, то нам кажется, но реальность такова, что все это лишь домыслы не имеющие ничего общего с реальностью :))))) Сколько придется писать будет зависеть от конкретной задачи и тех идей, которые хочется воплотить. Иногда хочется сделать именно то, чего нет и еще не было. Поэтому времени на это на любом движке может уйти столько, что уже не имеет значения какой движок выбран.
Насколько я понял Разери ещё не имел опыта с C# и Юнити, но если ошибаюсь, то тогда да, может быть Юнити будет проще, если есть уже опыт с ним, но с нуля легче освоить будет конструкторо-подобный движок, типа: Game Maker или Construct 2 (3-я часть с подпиской, и не особо отличается по технологиям)
Ещё Multimedia Fusion, классический конструктор.
По моему глубокому убеждению и исходя, что тут писалось про юнити - это далеко не самый лучший инструмент. Компиляция проекта например не должна происходить долго. Если это происходит - это повод задуматься над альтернативами. Либо вы что-то не так делаете. Например в среде Delphi проект разбивается на модули и скомпилированные модули естественно не компилируются, что сильно сокращает общее время компиляции - компилируются только те модули, в которых было сделано изменение. Если в юнити таких простых вещей нет или они сделаны абы как, либо чтобы понять как это использовать надо во что-то там вникать - значит система на самом деле недоделаная и недружелюбная. Я удивляюсь как многие на нем мучаются пытаясь что-то сделать. Не мучайте себя, выберите другую систему. Есть много движков и систем программирования, где все это делается автоматически и не требует вообще никаких познаний.
То что юнити разрекламирован это понятно, но лучше он от этого не становится. Я понимаю тех кто уже с ним долго работает или вынужден это делать. Но остальные то - зачем вы с ним мучаетесь ?
Конструкторы я бы тоже не советовал если нужно сделать какой-то глубокий проект, а не простенький прототип или на уровне того. Конструкторы - на то они и конструкторы.
А вот что касается функционала визуальной новеллы, то я например для своего проекта ria pc game все делал сам и это заняло на самом деле не так уж много времени. Было бы желание.
Но я конечно вас понимаю, если уж ввязался в юнити, то деваться некуда. Но все-таки. Если вы изучали js и использовали его в юнити может тогда взять node.js ? Или вообще писать браузерную версию игры на html 5 а потом скомпилировать в исполнимый файл. Тогда ваши js скрипты потребуют не так много изменений или по крайней мере это будет проще реализовать чем пытаться переписать на c# параллельно делая рефакторинг - т. е. улучшая старый код (рефакторинг это по большей части улучшения кода - изменение названий переменных чтобы они лучше читались, улучшение читабельности кода и т. п.)
Я конечно изложил свою точку зрения и не навязываю никому и ничего. Просто больно видеть как вы мучаетесь с инструментами которые на самом деле не помогают делать игру, а мешают.
Нужно брать не то что первое попалось под руку, а немножко использовать научный поход. Иначе вместо создания игр вы будете заниматься мазохизмом.
Уж наверное разработчики таких сред как Visual Studio и Delphi имеют больше опыта, чем те кто делал unity 3d или Game Maker. Game maker сделан кстати на delphi. А unity 3d надо полагать на c#, хотя изначально он писался на c++ когда c# еще не было и в те времена он еще был более-менее подъемным движком. Во что это сейчас превратилось вы видите сами. И многие пользуются старыми его версиями. О чем это говорит ? Что движок не прогрессирует, а регрессирует. Не помогает разработке, а мешает. Так что надо делать выводы и искать альтернативы.
Ну а те кто не видит альтернатив конечно пользуйтесь наздоровье, я ничего против этого движка не имею. Каждому свое.
Опыта в разработке игр? Ну, это как-то вряд ли.
Только старый:
В 2005 C# уже 3 года как был доступен для пользования разработчиками, и уже 12 лет как был придуман.
За остальное даю меч.
Опыта в разработке приложений конечно же. Не игр. Программирование, а не геймдизайн конечно. Для игры неважно криво она сделана или нет. Игрокам на это наплевать. Главное чтобы игра была интересной и захватывающей. Игра может при этом бажить и вылетать. Одно с другим никак не связано с точки зрения игроков. Но вот разработчик который мучается с такой кривой средой разработки однозначно потратит больше усилий. Только в этом ключе я имел в виду. Геймдизайн и прочие фишки создания игр я здесь не подразумевал.
Просто любой инструмент рассчитан на комп определенной мощности. Юнити новых версий будет тормозить на старом компе, дельфи и студия новых версий тоже. UE4 вот вообще почти топового железа требует.
Поэтому да, со слабым компом приоритеты в выборе движка\среды другие. А те у кого не тормозит смотрят с непониманием - какое им дело все скрипты перекомпилируются или не все если это занимает полсекунды.
Это точно. Но важно чтобы и железо и софт работали хорошо. И опыт разработки тоже играет роль. Если опыта нет, железо старое, софт глючит и тормозит да его еще и применяют не по назначению, то создание игры в этом случае превратится в ад. Может быть когда игры только только начинали делать, например тот же Периметр, в далеком 2000 - 2001 годах, тогда проблема стояла остро. Софт нужно было писать свой (движок), железо нужно было как можно более новое и мощное. Но сейчас с тех пор появилось много всего - и софта и железа, так что и выбор есть и необязательно использовать прям самое новое и свежее, тем более в новом могут быть ошибки, да и тормозит оно всегда больше. Плюс надо его еще освоить. А вот не очень новое и уже проверенное временем, вышедшее хотя бы 1-2 или чуть больше лет назад - смысл осваивать есть. Сейчас уже нет смысла гнаться за новинками и пытаться быть в тренде разработки с использованием самых современных инструментов. Инди разработчику это просто не нужно, да и не успеть. Хотя наверное и крупные студии не будут гнаться за новизной. Это большие риски. Мы живем сейчас в период, когда появились новые приоритеты - направленные на лучшее использование того, что уже проверено временем. А то что было разрекламировано и широко внедрялось не всегда показывает качество и проверку временем. Так что надо ориентироваться не только на популярность.
В этом плане ГМ кстати сильно сдал - 8.1 компилировался намного быстрее, а Студия 1 - намного медленнее, хотя функции были примерно те же самые. В Студии 2 наконец сделали компиляцию только того что изменилось, а не всего подряд, но это всё ещё медленней чем 8.1 из 2011 года, а интерфейс при этом где-то улучшили, где-то ухудшили. Хотя так почти у всех сред разработки что я видел - делать что-то лучше, не делая при этом хоть что-то другое хуже, тупо трудно.
Согласен. Идеального не существует. Как нового, так и старого.
Я может немного не понял суть, но я как раз наоборот рекомендую Разери перейти на что-то попроще, чем юнька. Хотя в остальном согласен, сам я на юнити, только потому-что она бесплатная да и уже давно, привык, если бы Game Maker был бы с такой же моделью продаж, то я бы давно освоил GM, жаль что я не купил Game Maker раньше, пока в кредитах не погрязла наша семья.
Ещё смотрю в направлении годот, но там пока неизвестно когда документацию освою и уроки.
Мне самому как художнику хочется поменьше писать кода и побольше заниматься разработкой самой игры,
то есть скрипты уровней, скрипты ситуаций в игре, диалоги, и сами уровни/локации.
Все правильно. Но вот насчет простоты наверное совет (с моей точки зрения) не совсем правильный. Чем меньше возможностей у движка или среды разработки, то учитывая то, что возможности никогда не используются на 100%, будет очень сложно достичь желаемого на движке или в среде разработки имеющей ограниченные возможности. Чем среда разработки проще (или движок), тем возможностей там меньше. Значит и игру можно будет сделать только самую простейшую. А проста это хуже воровства. Тем более в геймдеве. Простые игры это по сути клоны других простых игр - этого барахла пруд пруди. Поэтому совет не совсем правильный. Чем сложнее игра, тем шансы сделать её качественной выше. Понятно что сделать сложную игру на порядок сложнее чем простую. Но простую сделать интересной и качественной шансы еще меньше. Вот к примеру простая игра: Flappy Bird. Ну и что с ней делать ? :)))) А вот взять Периметр: Геометрия войны, которую делали более 4 лет ? Да сравнение конечно несопоставимое и результат заранее неочевиден. Но 100% или где-то 99,9% что разработчик как минимум после создания Периметра почуствовал что он хоть какую-то часть своих лучших идей смог воплотить. А что имеем с разработчиком Flappy Bird ? Да ничего. Он не то что доволен собой и своей игрой, а наоборот - плюется от неё, потому что и игра уже опротивела и то что его хвалят явно незаслуженно - тоже. Популярность и простота не синонимы качества. Как и критика, которая бывает разной. Например Периметр многие считают не то чтобы посредственной игрой, но не такой, какой она должна была быть. Но Периметр это лучшая игра от Российских разработчиков за последние 15 лет. Я имею в виду в жанре RTS. Конечно были и еще ряд проектов, но Периметр явно выделяется среди них. И это главным образом потому что игра сложна в реализации. Ну а представьте что бы было если бы разработчики решили реализовать свои идеи в виде простой игры ...
А что имеется ввиду под простотой? Flappy Bird с Периметром сравнить - это конечно жесть)
Я сам не люблю слишком простые игры, только глубокие по гемплею.
На Game Maker и Construct 2 при особой усидчивости можно сделать хоть Скайрим, хоть Fallout в 2D пиксельарте. Правда придется совместить с некоторыми элементами Зельды:
1) убрав например сохранение всех вещей брошенных на землю
2) не делать куча объектов контейнерами
3) сделать один контейнер у себя дома, чтоб БД не перегружать (как в Rune Factory)
4) не делать проверку AI неписей, которых не видно на экране
5) не сохранять состояния локаций на момент выхода из неё как в той же Кастлевании.
Но глубокую игру всё ещё можно создать
Также при должной находчивости на тех же конструкторах можно собрать свой 2D пиксельный Mount n Blade, убрав большие Базы Данных. И тут тоже никакого "воровства", глубокий гемплей можно сохранить, просто придётся отказаться от огромного количества переменных в этих Б.Д., вместо 100 не уникальных городов можно иметь 5 уникальных городов на всей глобальной карте, и вместо 10000 генералов, по карте вполне могут ходить 10 глобальных генералов и остальные локальные, те кто быстро исчезнут и сгенерируются пока видно на экране, как в той же GTA, например бандиты или крестьяне.
PS я сам люблю глубокие игры, но простые в реализации, в том плане что простота тут является помощником в урезании ненужного, но оставить нужные глубокие элементы, как например я очень хочу в своих играх сделать прохождение игр различными путями, и это также возможно сделать и с конструкторами
Проблема не в том, что нельзя сделать, а в том, что смысла в этом мало. Больше мучений и переоценки сложности проекта: сделаю за неделю, а на самом деле и за год не сделать. :))) Проблема в том, что когда смотришь игры со стороны - ты не знаешь всех деталей и сложностей процесса. Вот когда начнешь делать - тогда увидишь, что это не так легко. Впрочем зачем я это вам говорю. Вы это и сами прекрасно понимаете. Другой вопрос, что да - всегда хочется верить что сможешь. Потому и пытаешься. Плохого в этом ничего нет, нужно пробовать себя во всем. Правда не всегда это время проходит с пользой для проекта. Например брошенные проекты уже не принесут наверное никакой пользы, разве что опыта прибавится.
На Construct2 скайрим ты точно не сделаешь, уж поверь. На GM точно не. И тут даже усидчивость не поможет...
Я думаю имеется в виду 2д-версия - "(хоть Скайрим, хоть Fallout) в 2D пиксельарте" а не "хоть Скайрим, хоть (Fallout в 2D пиксельарте)".
Это точно не будут полноценные игры, скорее пародии минут на 5-10 геймплея...
Почему?
чисто ради информации... 3-4 года ушло на создание игры скайрим, команда которой составляла 100 человек или около того, второе - это функциональное ограничение что первого, что второго движка. Если говорить о Конструкт 2, то это скорее поделка для детей, нежели продукт для создания чего-то серьезного...
Зачем Skyrim, если есть Dwarf Fortress?
Не играл пока ни в то, ни в другое.
Рассуждать о достоинствах игр в которые никогда не играл. Ну это знаете ли странное занятие ;) Это непостижимая логика. Чем для вас хороши или плохи такие игры, если вы в них никогда не играли и вряд ли будете ? Ну я конечно понимаю, я сам не любитель всяческих ММО РПГ и иже с ними :)))) Куда привычнее классические однопользовательские компании. Сидишь и спокойно без нервов играешь. Вот никогда не мог понять людей которые в такие игры не играют, а как будто на работу ходят. Впрочем каждому свое. Кто-то любит классику, а кто-то онлайн.
И так видно, что DF более сложная, чем S, игра, притом инди. Для AAA характерны повышенная детализация и реализм графики, которые сильно сковывают разработку геймплейной составляющей (имею в виду не столько в творческом плане, сколько в реализации, например, сколько можно персонажей одновременно показать на экране и т.п.).
Мой вопрос в контексте разработки, а не играния. Играть понятно, что лучше в обе, если есть на это время.
Кстати да, чем более стилизованный графоний, тем легче делать игру.
Можно эти усилия вложить на другие вещи, а не полировка графона.
Очень много сил вкладывается на 3D и реалистичные вещи (чтобы персонаж ставил ноги правильно, мимика, анимация и прочие мелочи сжирающие ресурсы разработчиков), если вырезать эти вещи, то и игру в разы станет легче делать.
Я тут сейчас экспериментирую в Tic80, хочу соединить JRPG с Kenshi и Bitsy гемплеем, чем проще графон и физика, тем меньше головняка)
Dwarf Fortress выглядит по описанию эпично, но в самой игре я мало что понял.
Как-то не зацепило, наверное мне нужен более казуальный интерфейс, ну хотя бы как в Mount n Blade, где всё достаточно легко сразу понимаешь, кроме некоторых нюансов)
Казуальная версия DF это Rimworld. DF по сути очень похож, но только мир трехмерный (можно строить катакомбы в 3д) и живой (приходящие чуваки и события не генерируются по мере обнаружения игроком а существуют и взаимодействуют без него). Правда и баланса в DF нет, да и само слово баланс к нему не очень применимо - DF это генератор офигительных историй, а не игра в обычном понимании.
---
а, ну и в DF нет прямого управления, поэтому если ты видишь как дворфы тупят, то не можешь просто приказать пойти туда и взять то, а должен проявлять "смекалочку".
Меня даже Rimworld напугал. Там показалось слишком много всего и сразу в интерфейсе.
Хотя я люблю залипательные игры типа Mount n Blade и Kenshi, но это походу на порядок сложнее, чтоб разобраться во всём.
Может когда-нибудь я попробую разобраться с этим.
Ванильный Rimworld это развлечение для маленьких котят.
Самая вкуснота начинается с глобальным HSK-модом.
https://vk.com/hardcore_sk
Копировать легче чем быть первопроходцем. А сколько из этих людей не нужно в двухмерных играх, в отличие от трёхмерных - это ещё надо разобраться. Моделей-то в двухмерной игре нет, геометрия на целое измерение проще. И так далее.
А главное непонятно при чём тут GM. Типа, на UE4 или Юнити, Алекс мог бы сделать свой Скайрим?
Ну я просто планирую (уже где-то 4 года проектирую движок) сделать 2D игру с открытым миром, взяв концепцию Скайрима и скрестив в Зельдой, то есть буду делать только то что смогу, то что не осилю буду упрощать. Это конечно не будет тем самым Скайримом, я просто возьму тот функционал, что смогу сделать и буду оперировать им, а что не смогу, то как бы даже и не буду пытаться) тот же ИИ неписей и врагов я не планирую делать, ИИ у меня будет из игр Зельды или ещё проще.
Постепенно я понял что мог бы всё сделать и проще. И теперь переписываю движок на C# с оптимизацией и упрощением, заодно прикинул, что почти всё это можно сделать и в конструкторе, надеюсь когда-нибудь доберусь до этого эксперимента)
Почему нельзя сделать пиксельную игру на 5-10 часов? Что мешает?
Пародии, ну в принципе тоже неплохо, грамотные пародии до сих пор имеют спрос)
Я не имею ввиду Скайрим как он есть, я имею ввиду стилизованный и упрощённый, ближе к Зельде, но со свободой мира, где не надо лезть в подземелья, если не хочешь, где можешь в любой город сразу приехать. Сложный AI врагов и неписей, базы данных, 3D графику и прочие ништяки мы конечно отметаем сразу)
Ворвусь.
А зачем? Мало места на экране будет? Возможно. Но технически это реализуется в ГМ нормально (два раза делал)
2-3 похоже про сундуки с предметами? Думаю тоже делается в ГМ (в Бумажном, правда там 1 предмет. А в игре Дрейка Кристальное - там вообще мноха предметов).
спорное решение для игр с открытым миром, как по мне.
А как сложно сохранение делать? Лично я не смогу такую сложную БД делать и решил для себя обнулять уровни как в Зельде или Кастлевании.
Ну в целом есть минусы. Но если к этой игре относиться как к Зельде, в которой можно не проходить подземелья (по желанию), или можно идти сразу в большинство мест (пока сильные враги не убьют), то не так плохо, в принципе.
Ну и ещё добавить логичный ландшафт, в большинстве 2D игр по Зельде нет логичного ландшафта,
который проходится логичными "инструментами":
1) вода - просто создать или купить лодку, или научиться плавать, а не подбирать особый предмет
(это уже элемент открытого мира, где ты можешь инструмент получить когда сам решишь, а не по сценарию)
2) пропасть - варианты прохождения: воздушный шар, летающие расы, магия полёта
3) болото - просто идти аккуратно, иначе можно увязнуть в трясине (быть внимательным, инструменты не нужны)
4) дорога - в Зельдах редко есть логичная дорога по которой курсируют торговцы, путники и стража,
это есть в открытых мирах, и это тоже можно добавить в игру, это тоже окрасит игру с открытыми миром, можно генерировать неписей по типу GTA (в зависимости от ландшафта и времени суток генерируются свои неписи, которые создают иллюзию жизни)
5) дикая местность, чем дальше от дороги, тем опаснее, это тоже логично для открытого мира, обычно же в RPG и Зельдах местность делиться на прямоугольные зоны по уровню, вместо этих прямоугольников можно отталкиваться от цивилизованной местности и дикой, ну и по логике мира Властелина Колец сделать зоны типа гробниц и некрополей самыми ужасными местами, а не обычными рядовыми локациями как в обычных RPG с почти бесплатным лутом и экспой в виде зомби.
На самом деле не так сложно, как кажется. Вообще этот метод я подсмотрел почти случайно в структуре файлов игры Систем Шок 2 (вернее файлов сохранений конечно).
Там был не один файл, а несколько - включая отдельные файлы на локацию, где (я предположил) и была информация о динамических объектах (условные ящики, предметы и т.д.)
А формат может быть простым текстовым, где пишется тип, положение и какой-то ещё параметр (если в лоб решать эту задачу).
Если конечно сам замысел сделать Зельду-Кастлу, то да - свои подходы есть.
Вот взять к примеру Взертоса - у меня там враги спавнятся и это на 50% геймдизайнерское решение, а на другие 50% - я просто не смог сохранять врагов нормально (таковы особенности реализации, думаю теперь бы я написал иначе). Но вот предметы сохраняются - положение и тип (+\- ещё параметр)
Иными словами - ДД это делал в Гамаке ещё 4 года назад. Объём его игры - примерно как половина первой Диаблы, только без генерации, а с конкретным левел-дизайном.
На GBRII у меня был перманентно разрушаемый мир. Там как раз и была логика 1 файл сохранения на 1 локацию. Только я не запоминал каждый объект в текстовый файл, т.к. есть функция game_save(name). Вот такие гейм сейвы были на каждый уровень.
Зачем вообще делают самописные сейв файлы, когда есть функция сохранения всего: дело в том, что когда персонаж возвращается на старую локацию и загружается состояние локи, вы увидите, что глобальный сейв запомнил в том числе и параметры персонажа. Т.е. персонаж будет стоять там, где вышел с локации когда-то давно, иметь прошлогодний хп и все пройденные квесты сбрасываются нахер.
Так вот, оказалось, что проще поступить наоборот. Уровни запоминаем с помощью глобального game_save(name), а вручную остается сохранить только самого персонажа, вместо того, чтобы писать сейв для множества объектов с кучей параметров.
Так что задача сделать сохранения уровня Skyrim на GameMaker'e решается внутри недельного джема. Но придется и с файлами поработать и с чисткой, и особенно если вы хотите держать сразу несколько состояний мира в нескольких сейвах, тогда есть над чем запариться.
И всё же это не тянет ни на 100 людей, ни на много месяцев работы, верно?
Не, я к тому, что это не прямо так легко делается, как я описываю, лично мне поразмыслить пришлось. Но это все так же уровень недельного джема.
Кажется я столкнулся с какой-то проблемой при использовании этого сейва. Возможно как раз "запомнил в том числе и параметры персонажа", а может какие-то ещё особенности были. Но так или иначе было полезно с файлами поработать.
А вот в Бумажном я пошёл чуть дальше и сохраняю один файл, а там всё на ds_map, внутри которой ещё ds_map, внутри которой ещё ds_map, внутри которой ...
На JSONах?
Там с game_save одна проблема только, что она не запоминает структуры данных.
JSON использовал для БД различных, а вот данные сохранений именно ds_map (ds_map_write - по сути ds_map в строку записывает, которая уже в файл записывается) - в ГМС есть возможность их сохранить в файл, но файл не читаемый т.е. это не json.
Хм, вероятно поэтому и отказался от game_save - что структуры не сейвит.
"Я не юзал эту фичу, значит она никому не нужна". Классика.
Давай так. Поставлена задача - спрайт врага после получения урона должен на протяжении 0.2 секунд мигать (исчезать/появляться) с периодичностью в 25 миллисекунд. Просто ради интереса, как ты предложишь это решить? Желательно с подходом fire-and-forget, чтобы запустить и не париться.
Я создаю скрипт с обычной переменной int в виде таймера, потому-что боюсь корутины в коде, ведь при удалении объекта, корутину тоже надо останавливать, а запаришься вспоминать сколько я таймеров запускал,
мне очень часто нужны всякие мини таймеры, а о переменных внутри скрипта не стоит париться, при удалении объекта ничего не произойдёт с ними
"Я юзал эту фичу, значит она всем нужна". Классика.
alarm[0]=2
alarm[1]=12
В событие alarm 0: visible=!visible; alarm[0]=2;
В событие alarm 1: visible=1; alarm[0]=-1;
Это для 60FPS, и конечно 33,33 миллисекунды это не 25 миллисекунд, но много ли разницы. Мне в случае такой претензии интересно, как оригинальный код предполагалось синхронизировать с 60-герцовыми экранами, или с 144-герцовыми.
Если все алармы уже использованы (ни разу такого не видел в реальных проектах), можно добавить свой.
Ну да, именно это я имел ввиду. Спасибо за нахождение в моих словах смысла, о котором даже я не догадывался.
Но ведь я тебе лично ничего и не писал. Я писал форевервосьмопусу.
По коду, я так понимаю, возражений нет, так что - в чём проблема, непонятно...
Попробовал в Tic-80 написать на Lua, вроде работает:
Oчень страшный код, правда? _invincibilityEnds можно инициализировать тут же (оно определяется как Time.time + InvincibilityTime в момент получения урона), но мне это значение нужно локально в скрипте, поэтому оно ставится в другом методе скрипта.
Ну как тебе сказать. Не страшный, но https://en.wikipedia.org/wiki/Boilerplate_code
У меня в коде конкретно - таймер, количество шагов, таймер, количество шагов. А тут? Я знаю C#, и я знаю что тут происходит - мы определяем метод (1), имплементирующий (2) интерфейс (3) IEnumerator (4), йилдящий (есть такое слово вообще?) (5) результат вызова очередного WaitForSeconds (6). Это как минимум 6 ненужных вещей нужно выучить. Теперь посмотри на мой код:
alarm[0]=2
alarm[1]=12
В событие alarm 0:
visible=!visible;
alarm[0]=2;
В событие alarm 1:
visible=1;
alarm[0]=-1;
Один таймер работает раз в 2 кадра, перезапуская себя, другой срабатывает ровно 1 раз через 12 кадров. Тут для понимания происходящего нужно знать только понятия таймера и кадра.
Или так - у тебя 7 строк кода (скобки и пропуски я не считал) с вызовами методов, проверкой условия, возвратом; у меня - 6 строк, все из которых - просто присваивания.
Естественно, можно написать то же самое в один аларм, тогда будет ещё короче, но сложнее читаться.
Давай вот Алекса спросим, ему, как "менее программисту", виднее, какой код понятней и легче пишется.
Мне кажется ты не очень правильно понял что такое boilerplate code и кидаешься терминами чтобы казаться значимее
Не знаю что тебе кажется, но я привожу в доказательство конкретный код против конкретного кода - в одном нужно сделать много вещей, в другом мало, чтобы достичь одного и того же результата. Как насчёт обсудить именно код? Если это не бойлерплейт, то как ты это назовёшь?
Бойлерплейт код повторяющиеся участки кода, которые вынуждены быть использованы во многих классах практически без изменения, например листенеры для объектов и систем в Entity Component System парадигме.
Это же просто корутина, которая вызывается где надо простым StartCoroutine(HandleFlickering()).
Не вижу ничего "много" в этом коде, а в твоем коде вообще ничего не понимаю. Что такое alarm? Что такое 0? Что за события? Можно ли как-то переназвать этот alarm, а 0 заменить на человекопонятный enum, чтобы через месяц не пришлось рыскать по всему проекту чтобы понять, что изменилось?
Почему должно понадобиться рыскать по тому, что написано один раз правильно и всегда работает?
И что же, помимо мигания спрайта, в проекте не будет куча таких скопипащенных короутин, все из которых имплементируют энумератор, все из которых йилдят?
Ну да, потому что ты знаешь только свой инструмент. Это же логично.
Получается, что
нельзя, и надо использовать захардкоденные названия для вызова ивентов и держать в голове, что каждый ивент делает?
Твои выводы не коррелируют с тем, что я отвечал - enum'ы в ГМе есть, просто у меня порядочно много других полезных вещей, которыми я могу заняться помимо консультирования Юнитиводов по движку, прекрасно доступному для изучения самостоятельно.
Стрелочка, естественно, не поворачивается, да?
Зачем я вообще это пишу, в случае с кситом она никогда не поворачивается, сколько не старайся.
Чиво, какая стрелочка? Не разбираюсь во всех мемах на свете если что.
Я вам конкретный код привёл, конкретно назвал Юнитевский код бойлерплейтом, и вы ничего из этого не оспорили. Конструктивно обсудите - и докажете.
Пока что я вижу задачу из мира розовых единорогов - мигать раз в 25 миллисекунд. Это какой фреймрейт, 40? На каких устройствах это нужно, где столько герц? А вот именно что ни на каких, и сразу понятно, что ставящему такую задачу всё равно, что именно он ставит, для него это просто цифры и просто буквы чтобы просто программировать.
Забей, я всего лишь бесполезный разработчик, пилящий никому нахер ненужные вещи на богомерзком сишарпе. Зачем ты вообще на меня свое драгоценное время тратишь. С удобством разработки на гамаке ты бы за это время три игры с нуля релизнуть бы успел. А тут какое-то хуюнити, в котором на одни корутины надо получать диплом четыре года.
Заметь, я ничего подобного не говорил. Я просто сказал про короутины, и заверте.
По итогам этого "заверте", видно что в ГМе удобнее и проще делать вполне конкретную вещь. Под этим понимается меньше кода как такового, и меньше уровней абстракции, для ровно такой же гибкости.
Пожалуйста, не используй термин неправильно, в твоей же скинутой википедии он объясняется
Ты мне два раза сказал что я его использую неправильно, но не ответил на мой вопрос:
Утвердительный ответ на него означает что прав один из нас, а отрицательный - что другой. Начал говорить - так договаривай?
Кажется, я самое интересное пропустил.
По чистому коду я вижу, что первому элементу массива alarm назначают значение 2, а второму элементу назначают значение 12. Каким образом значения массива имеют отношение к кадрам, для меня, как для стороннего читателя, является загадкой.
Хотя это конечно же я зажрался со своим семантическим программированием.
Про массив тебе кстати тоже знать не надо для решения этой задачи - объективно говоря, это просто квадратные скобочки с цифрами. Посмотри на этот код как человек который не знает всего что ты знаешь вообще из программирования общего назначения.
Справка, с которой положено работать чтобы делать какие-либо проекты, отвечает на этот вопрос за пару секунд:
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/instances/instance_variables/alarm.html
Теперь открываем справку по короутинам, добро пожаловать:
https://docs.unity3d.com/ru/current/Manual/Coroutines.html
Опять таки, для меня как для человека даже имеющего определенные познания в базовом коде, это выглядит как эдакий мистический код. Знание того, как работают массивы, никак не помогает мне осознать, что назначение массиву значения 2 на самом деле обозначает "вызови какой-то там ивент через два кадра".
Извини, я вынужден напомнить, что чуть выше писал:
А ты мне отвечаешь:
Так оно и не должно тебе помогать. Ты просто полагаешь, что выучил программирование и этими знаниями сейчас будешь все проблемы расшвыривать с дороги, но есть много способов решить одну и ту же задачу. Для некоторых шагов вперёд нужно делать шаги назад.
По поводу "осознать, что назначение массиву значения 2 на самом деле обозначает "вызови какой-то там ивент через два кадра"." - а где в твоём коде написано что Time.time это текущий момент, а не какое-то непонятное "время времени"? Для того чтобы работать в конкретной среде, надо осваивать конкретную среду, а не общие законы.
The bottom line - программирует программист (а кодит кодер, более узкий спец), игры делает разработчик игр, и с годами эта линия будет проявляться всё сильнее и сильнее.
Блин, мне как художнику больше нравится лаконичность кода, чем меньше символов, тем легче понять код, надо бы постепенно изучать ГМ) Хотя конечно юнити я не брошу, ещё нужно долгострой достраивать)
При том что Алекс знает, что это менее гибко, но "плохая" гибкость "простых" игровых движков типа ГМа, Multimedia Fusion или Констракта за 15 последних лет вышла на такой уровень, что это уже "достаточно гибко". Таковы реалии.
на практике наоборот
На чьей практике? Вот у Алекса есть практика, я не думаю что он с тобой согласится. В моей это тоже не так, и уточню, что речь не о том чтобы всё сжимать в a.b=c.d();.
Наверное это зависит от мышления или психологии, просто когда вижу красивые целые предложения из привычных английских слов в виде операторов и переменных, то мне становится сложно читать, потому-что они очень длинные, я для юнити сделал свой скриптер, где очень короткие операторы, стараюсь избегать длинных названий.
Мне Tic-80 понравился, потому-что там операторы очень короткие типа:
if btn(0) then print("ok") endи самое главное операторов очень мало, чем меньше операторов, и чем меньше символов в них,
тем лучше для моего понимания кода
О чём и речь.
нет, тут речь об ужасном костыле из за незнания языка(разговорно). при взгляде на переменную ты должен получать весь контекст, а не шариться по пыльным полочкам собственных абстракций
А мне даже нравятся механики, которые можно описать малым количеством кода. Это значит, что меньше багов в коде, меньше объяснять игроку в туториалах и проще потом скомбинировать с другими механиками.
малое количество символов и малое количество кода - разные вещи
Не спорю.
А чойта коммент подредактирован?
Без понятия, я в основном дополнял новыми ссылками, а не правил существующее. Если там было что-то важное, можешь цитировать как будто оно там есть.
А что по части, если этот объект внезапно удалиться, я слышал что надо корутины отменять перед удалением объекта. Хотя не помню, может имелось ввиду что-то другое, что там есть проблемы с корутинами, но с тех пор я что-то боюсь пользоваться ими.
Рубрика "страшилки с Кситилоном". :D
Спрайтик на юнити на экран можно и без C# выводить :3
загузил текстуру как спрайт, перетащил этот спрайт на уровень
Мне нравится пожёще.
Мне нравится как сделано во всяких Tic-80 и Pico-8 и тот же Love2D, где спрайт выводишь командой
в любой кадр, к сожалению в юнити этого нет, мне очень хочется такую опцию в юньке, но увы.(
Разери, вообще, в юнити будешь очень долго с инструментарием возиться.
Лучше выбери конструктор или движок с готовым инструментарием типа Game Maker или Conctruct2.
Я сам когда-нибудь на один из них переберусь, когда с кредитами разберусь.
Иначе провозишься с созданием инструментария, а не создания игры.
Я сейчас для юнити пишу куча всякого, чтобы просто помочь себе в разработке игры в будущем.
Тонна неблагодарной работы, просто чтобы делать то, что в некоторых движках уже готово сразу.
Та же плавная загрузка уровней (готово сразу в Stencyl), или скриптер чтоб создавать скрипты для уникальных уровней без компиляции (в том же Game Maker изменение скрипта не мучает тебя компиляцией по минуте или Godot), в юнити компиляция в большом проекте доходит до 1 минуты, просто чтобы один символ поменять.
Что имеется ввиду? Асинхронная подгрузка уровней? Есть же давно.
Нет, когда экран плавно одного уровня сменяется на другой или плавно затеняется чёрным экраном,
в юнити приходится создавать отдельную камеру для этих целей, чтоб она между уровнями существовала
и скрипт соответствующий писать для этого надо. Как раз вот думаю как делать подобную плавную перезагрузку уровня на C#, раньше я на JS сидел и хочется сделать как-то более грамотнее.
Звучит как специфическая логика. Странно обвинять движок в том, что он не имплементит за тебя какой-то специфический функционал, который далеко не во всех играх используется.
А в плане оптимизации, я бы вообще давал игроку ложную картинку подгружаемого уровня вместо того чтобы ждать пока он загрузится и уже тогда давать ему его изображение.
Оно специфично, но используется в 95-99% играх есть какой-то плавный приём смены уровней или локаций, никогда не видел в готовых играх, чтобы один уровень резко менялся на другой, всегда есть какой-то промежуточный эффект или переход или картинка загрузки как в том же Skyrim - Loading Screen.
Там много таких специфичных, но часто используемых вещей без которых игра будет выглядеть сырой:
1) свой скрипт смены кнопок управления, в юнити ужасная реализация, но я не смотрел в 2019-х версиях, может там уже норм
2) база данных всего текста для перевода на другой язык
3) внутренний скриптер для создания уникальных уровней и диалогов без компиляции
4) Свой скрипт глобальных переменных. В юнити всегда нужно, чтобы переменные были в скрипте на каком-то объекте. Это немножко выматывает, ибо приходится много пустых объектов размещать на уровнях, и ещё и следить, чтобы эти пустые объекты случайно не удалились.
5) свой менеджер уровней, ибо просто закинуть уровни в меню Scenes in Build, там получается каша, когда уровней становится больше 100
PS я пока это всё писал, то часто думал о том, где бы найти такой конструктор, где всё за меня уже готово, ибо надоело программировать вспомогательные инструменты для создания игры)
Мне кажется, ты что-то делаешь не так - вот в 2011 году пишут, как это делается:
https://answers.unity.com/questions/50716/how-to-make-a-global-variable-in-unity.html
Возможно что-то не так делаю, хотя static использую. Но я боюсь слишком часто использовать static, потому выношу скрипты в пустые объекты, когда базы данных делаю, например для вещей или системных звуков,
чтоб был лёгкий доступ к ним
static для хранения игровых геймплейных данных лучше не использовать, это низкоуровневая вещь, которая нужна для реализации нужного code flow игры. Конкретно в юнити статики лучше использовать для методов, которые нужно часто вызывать, и они не привязаны к MonoBehaviour
Ну вот тем более, оказывается я вообще зря использовал static, ибо обычно я для гемплейных данных и использую. Например у меня в старом коде есть
static public int HeroHealth;и много другого подобного
Используй ScriptableObject для хранения таких данных. Ты можешь перекинуть ScriptableObject здоровья игрока в любое нужное место прямо в редакторе, без создания сложнозапутанного кода с static переменными.
Я не понял что я не так сделал, но попробовал один раз пример с официального сайта юнити,
и у ScriptableObject данные есть, пока не пройдёт немного времени или не откроешь заново юнити, то все эти объекты становятся девственно чистые и все данные пропадают, короче я подумал что тут нужна особая магия и пока забил на них, используя обычные префабы)
SO это временные хранилища, ты в них данные помещаешь в одном месте, и читаешь в любых других нужных местах
А вот в чём было дело) с таким пониманием надо ещё раз попробовать тот пример, может и правда пригодиться для игровых данных
Достаточно написать один раз и использовать во всех играх. Или взять чужой бесплатный, полно их в интернете.
Грузи текст для всех языков из json файла, который правится отдельно, очень удобно.
Можно свой написать, если очень надо, то и в виду визуального node-based редактора.
Все можно хранить в scriptable object.
Не вижу проблемы, если иметь глобальную неудаляемую сцену с объектами, которые переходят из сцены в сцену (это игрок, менеджеры всякие, камеры и т.п.), то каждая сцена это всего-лишь набор препятсвий с врагами, предметами для собирания и прочего, каждая сцена существует отдельно и ее нужно лишь загрузить.
Почему бы не сделать одну камеру и делать ей фейд, а после фейда загружать нужный уровень, при этом сама камера является неуничтожимой при смене сцен?
Не понимаю проблем с "писать скрипт надо", игровые движки для этого и нужны, и это простейшая логика, которая одинаково пишется на каждом из популярных движков. С другой стороны, для игры порнографического характера с монстродевочками не проще ли взять RPG Maker, людям там все равно геймплей не очень важен, главное чтобы арт был посочнее.
Давно написал на JS, теперь заново переписываю на C#, потому-что юнити отказались от JS (давно отказались от JS, но я только недавно решил перейти, ибо слишком много скриптов переписывать, меня это пугало) Тут ещё один камень в огород юнити, они часто отказываются от тех инструментов, на которые я уже всё написал и теперь приходится переучиваться, как было с JS, так и старой системой частиц.
А ещё у меня тогда было мало опыту, поэтому в скриптах много "велосипедов", это ещё одна причина, почему приходится создавать скрипт с нуля, ибо это всё плохо работает и не оптимизированно.
Я имею ввиду, что последнее время я занимаюсь с созданием вспомогательной логики, а не игровых скриптов.
И немного подустал от этого.
За советы спасибо, подумаю как сделать специальный системный уровень, чтоб там было всё сразу включая героя, только не придумал как сделать так чтобы системный уровень создавался, если он ещё не был создан,
ведь для этого нужно чтобы на каждом уровне уже был какой-то системный скрипт, который бы загружал бы этот системный уровень.
Ну, на уровне обычно и так нужен системный скрипт, который, скажем, загружает данные об объектах с сохраненного состояния. В своей наработке я делал такой подход (я там еще отказался от переноса общего уровня между сценами, мне было проще перезагружать его для каждой сцены, так как это решало много проблем, например, с загрузкой сохранения). Еще вариант есть загружать системный уровень в главном меню, еще до того как начал загружать первый уровень.
Это плохой вариант, ибо я запускаю для теста всегда тот уровень, который редактирую, а там точно не уровень главного меню, а скорее обычная локация над которой в данный момент работаю)
Ну я же уже написал как это сделать
Можно использовать такое свойство перед методом:
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
С таким свойством перед методом, этот метод будет запускаться каждый раз, как ты запускаешь игру в редакторе. В методе ты можешь загружать основную сцену со всеми контроллерами и игроком. Так очень просто тестить отдельные уровни - вместо того чтобы сначала загружать сцену-менеджер, а потом уровень (для чего придется либо править каждый раз код, либо менять переменные в редакторе), ты можешь использовать это свойство и проверять, загружена ли сцена-менеджер. Если нет - загружать ее, а потом уже, как обычно, соединять менеджер с загруженной сценой. Для этого поможет объект, который должен существовать в каждом уровне, и ты этот объект ищешь после завершения загрузки сцены и привязываешь его к менеджеру.
Звучит сложновато, но в коде на самом деле просто все. Это позволяет отвязать друг от друга многие элементы и править их по отдельности.
Спасибо, звучит как то что мне нужно)
Чтобы отвязать все эти элементы друг от друга.
Погуглю примеры и инфу
Вот только каждый разработчик делает это по своему, и каждому свой метод удобнее. У меня есть метод, который я сам юзаю (подсмотрено на работе), очень простой и удобный в применении, с удобным для создания и структуризации перевода форматом, и я не знаю, смог бы я его использовать вне C#.
Статические классы/переменные/синглтоны/ScriptableObjects.
точно, спасибо за напоминание, хотел загуглить можно ли синглтон создать вне объекта вообще,
то есть даже если на уровне вообще нет ни одного скрипта, но синглтон сам инициализируется без никого,
всё время забываю это название и забыл что хотел нагуглить)
https://gamin.me/posts/20838?comment=268152#comment_268152
Я так понял, что Алекс не обвинял Юнити в отсутствии фейд-инов всяких, просто как художнику ему интереснее если в коробке уже есть всякие прикольные штуки.
В красивых! И да, в подавляющем большинстве в двухмерных. В этом-то и затык.
Точно) Я пока изучаю демку ГМ и процесс разработки игры, но по ощущениям, в нём уже легче и комфортнее делать игру с нуля, чем в юнити) Хотя инструментарий придётся писать, но поменьше, чем в юнити.
Вроде для диалогов в ГМ тоже ничего нет.
Ну да, это же не конструктор визуальных новелл. Впрочем, я тебе кидал свою систему, написанную 10 лет назад, она вполне работоспособна и до сих пор.
Чем мне нравятся конструкторы визуальных новелл и Битси, тем что диалоги уже из коробки)
Странно что многие другие конструкторы игр это не предоставляют, даже если позиционируются как дружелюбные для полных новичков или не для программистов.
Это какбэ правильно. Ты тогда можешь не просто затенять, а делать это с различными эффектами. Или между переключения и сцен вставил катсцену...
Вот тут согласен, возможность разбивать солюшн на проекты довольно упростила бы процесс компиляции, сейчас это можно делать только через костыли.
А там нельзя как-то галочкой отмечать, какие файлы включать в текущий билд, а какие нет?
GM можно вообще не перекомпилировать: https://yellowafterlife.itch.io/gamemaker-live
Но этим колдунством не пользуется практически никто, разве что повыпендриваться. Да и двухмерные проекты не весят так много, чтобы прям убивать время компиляцией.
А в ГМ есть пауза в одну минуту, когда в скрипте ты написал один символ?
Просто в Юнити компиляция скриптов проходит во время процесса, а не когда уже игру билдишь.
Я тут недавно комментарий в скрипте немного поправил и чуть не психанул) ибо забыл, что в юнити теперь всё будет минуту блокироваться и не потестить сразу, пришлось идти чай пока себе наливать)
В 2019 версии юнити Visual Studio 2019 компилирует скрипты сразу как ты сохраняешь изменения, без необходимости переходить в окно юнити.
Если скриптов становится очень много, что время компиляции становится очень долгим (никогда не встречал компиляцию в одну минуту, если честно), можно воспользоваться Assembly Definition - делишь скрипты на небольшие библиотеки, и перекомпилироваться будет только библиотека с измененным скриптом, а не все сразу.
Я на Notepad++, не помню почему я забил на Visual Studio, то ли VS долго открывался на моём старом ноуте, то ли по другим причинам, или потому-что эта программа много весит.
А Visual Code я не смог настроить, что прописывать в системной строке, там какая-то каша всегда открывается, вместо нужных скриптов из проекта. Сколько ни гуглил решений, всегда что-то не то было и потому остался на Notepad++.
зависит от PC, у меня слабый ноут, а скриптов где-то около 150) правда многие из них маленькие и ещё они на JS, но всё же.
Сейчас перешёл на C#, компиляция пока что очень быстрая, но скриптов пока-что всего 2 переписал с JS на C#) так что поживём увидим, будет ли лучше или также)
Visual Studio может долго загружаться, но после загрузки она довольно шустрая, это лучшая бесплатная IDE для Unity, которая уже и официально поставляется с движком. Не знаю насчет Notepad++, но в VS много удобных инструментов для рефакторинга и контроля над кодом, я рекомендую пересесть на нее, раз уж пересел на C#
Я просто даже не знаю что такое рефакторинг, наверное не пригодится)
В Notepad++ я по старинке открываю все скрипты по отдельности, а не целый проект, так и программирую где-то с 2012-го) уже давно привык
Пригодится, через пару лет работы над проектом. Но не в том случае если меняешь движки как перчатки, а я так помню, у тебя именно это и происходит, так что НУ НЕ ЗНАЮ. :yak:
У меня долгострой пишется годами, лет 5-7 наверное уже) потому у меня и 150 скриптов накопилось в юнити на JS, а теперь приходится это ещё всё переносить на C#
мусора там кучу накопилось, неужели рефакторинг мусор будет помогать выискивать) надо бы загуглить что это)
Никому не нужная вещь, забей
Рефакторинг - переписывание кода так, что с ним легче работать, но при этом сама роль кода остаётся такой же.
Подводные камни включают, например:
1) переписал, и теперь не работает;
2) пока переписывал, переключился на новую фичу и запутался;
3) переписывал так часто, что забыл сделать игру;
4) переписал, и стало ещё хуже.
Так что делай бэкапы и не переусердствуй понапрасну :D
Если нет желания повышать технический скилл программирования, то лучше и правда что-то менее программировательное использовать, в юнити по незнанию можно таких дров нарубить (и мне кажется что компиляция в одну минуту это одно из последствий)
скорее всего) я уже руки опустил добивать эти 150 скриптов на JS на старой юнити, и начал с нуля на C#, с новым опытом, пока что компиляция идёт быстро, даже радует, перед тем, как начать новое ядро скриптов, я даже написал план, что никогда при программировании раньше не делал, так что технический скилл растёт, но не так быстро, ибо ещё надо рисовать и прочее)
Я сначала прочитал вопрос как "есть ли в ГМе команда чтоб игру поставить на паузу на минуту", м-да.
Нет там такой паузы. Там есть долгая упаковка при компиляции вообще, особенно на Андроид, Иксбокс и подобные громоздкие платформы. Но я думаю у Юнити с этим не лучше.
У Юнити при выборе платформы для экспорта идёт какая-то перестройка проекта, относительно долгая. Ну и потом ещё компилируй\экспортируй_игру. Не помню как в ГМС, но кажется там никаких ожиданий при смене платформы вообще нет, а вот в Юнити есть и приходится ждать пока проект "перестроится" под новый выбор.
Ну есть первая сборка, которая длится долго. Но с файлами игры ничего не делается, просто кэш строится.
Вроде, это можно делать когда непосредственно билдишь билд игры, но в дебаге Юнити компилит сразу все скрипты. Вообще, эту фичу можно отключить, и перезагружать ассеты по требованию, а не автоматически, но это не решает проблемы с тем, что изменение одного символа приводит к полной перекомпиляции.
Но это проблема не шарпа, а самой юнити, которая тупо не позволяет разбивать логику на проекты (обычно студия не компилит проекты, которые не изменились).