Здорово, что всё получилось, но почему именно QA, а не, например, UX Writer? Там вроде как и конкуренция ниже, и изначальное образование пригодится больше.
Ограниченный ресурс - это распространённая механика в играх в принципе, как мана в Диабло и очки действия в Fallout 2. Цель механики - побудить игрока к выбору, дать вызов. Даже если ресурс не восполняем (патроны в КС), то механика всё равно работает на те же цели. Тут всё понятно.
А вот случаев, когда игрока награждают за неиспользование ресурса не так много. Я разве что могу снаряды в "танках" вспомнить, в том плане что чем меньше отстрелял - тем больше серебпа сэкономил. Но у игроков эта механика особой популярностью не пользовалась.
Главный ресурс в распоряжении игрока — показатель степени вмешательства. Каждое активное действие игрока будет повышать этот показатель. Конечный результат партии будет зависеть от значения вмешательства, и чем оно меньше, тем выше результат.
То есть игра буквально наказывает игрока за то что он играет? Звучит очень сомнительно, особенно когда это основная механика. Это всё равно что в тетрисе отнимать очки за переворачивание фигур.
Стоит продумать "план Б" на случай если такой подход не взлетит.
Обычно цель - не чтобы он много играл в абсолютных цифрах, а чтобы он делал это постоянно. Если игрок залипал неделю, а потом пошёл играть во что-то другое - он не особо ценен, даже если сидел с утра до вечера. А вот если он играет по часу в день, но много месяцев или лет - игра становится его хобби. А на хобби люди готовы тратить очень много.
Фильм "Мир танков и людей" здорово рассказывает об этом.
Я занимаюсь разработкой игр 20 лет, а последние несколько недель посвятил поиску издетеля для своего очередного проекта ;) И мне таки есть чем дополнить ваши, тоже очень дельные, советы.
Не пытайтесь откусить больше, чем сможете проглотить.
Ещё на самом раннем этапе, ещё когда вы только придумываете игру, учитывайте какие средства (время, скиллы, деньги) у вас есть и что вы можете сделать этими средствами.
Если вы не можете нарисовать / анимировать весь контент - сначала идите в ассет стор и думайте что более-менее достойное можно сделать из его содержимого.
Если вы не программист - тоже идите в стор или ищите примеры уже сделанных механик и выберите те, в которых сможете разобраться и адаптировать под себя.
Даже если ваш бюджет $0 - всё равно идите в стор и смотрите бесплатные ассеты. На них тоже можно дотащить игру до MVP и дальше искать издателя или единомышленников.
Трезво оценивайте свои трудозатраты. Исходите из того, что из MVP, сделанного за выходные, полноценная игра получится никак не меньше чем за 3-4 месяца.
Планируйте и следуйте плану.
Определитесь хотя бы какие фичи вы делаете на этой неделе и какие - на следующей. Занимайтесь своим проектом постоянно. Хотя бы понемногу, но каждый день. Иначе очень легко забросить, особенно если совмещаете с основной работой.
Даже если вы освободили под проект выходные - занимайтесь им по вечерам и на буднях тоже, иначе ваши эстимейты на дни превратятся в эстимейты на недели.
Fail fast & fail cheap
Если работа над игрой не идёт, сроки постоянно съезжают или вам буквально в тягость заниматься игрой - не бойтесь её бросить. Оглянитесь назад, поймите что сделали не так, составьте план на новый проект и потратьте 1-2 недели на R&D. Там посмотрите ещё раз, стоит ли забрасывать. Если вы осознали, что выбрали не ту технологию, то чем раньше вы её смените - тем лучше.
Вот если вы за собой заметили, что уже 2-3 раза меняете проект или движок - это повод задуматься что в целом идёт не так.
Когда вам, чтобы поменять хп у сотни врагов в вашей игре, нужно выбрать каждого персонально и изменить поле в редакторе - это не удобная работа с данными. Достоинства ScriptableObject совершенно не в этом, а в том, что его полями могут быть не простые типы, а сущности движка: спрайты, префабы, прочие ассеты и другие SO.
Например, вам нужно создать описание персонажа, которое объединит его префаб, спрайт иконки и контроллер анимации. Вот тут без SO не обойтись. Можно, конечно, хранить эти ассеты в Resources с определёнными именами, но такой способ имеет много минусов и разработчиками движка не рекоментдуется.
Данные из простых типов (например, характеристики персонажа) гораздо удобнее хранить в обычной экселевской таблице (или в каком-то удобном вам текстовом формате) и уже оттуда генерить в движок. Тогда эти данные легко массово редактировать и их можно мержить.
Unity с публикацией под WebGL в принципе подойдёт. Там не так всё наглядно, но по части работы с ресурсами, доступных платформ и производительности он на голову выше флеша.
Категоричное заявление. Но неверное. Если вы собираетесь писать игровую логику или шейдеры - вам нужна математика хотя бы на уровне средней школы. Хотя бы векторы и хотя бы на плоскости.
Причём чем меньше проект и на чем более ранней стадии разработки он находится - тем выше шанс что она пригодится. Если вы пишете систему начисления игрового имущества за баттлпасс в какой-то ААА игре, то там логика не будет сильно отличаться от начисления бонусных баллов в интернет-магазине. Но и работа будет далека от того, что обычно ждут от геймдева. А вот если у вас стартап с гиперказуальными паззлами на основе физики и командой в 2 программиста - то там с математикой всё же придётся иметь дело.
Какой-то странный список, в котором свалены в кучу должности, роли и даже грейды, без оглядки на особенности проекта и оргструктуру компании:
Руководитель проекта не обязательно должен быть визионером. Это может быть так на небольшом/инди проекте, но часто визионер - это Creative Director или Lead Game Designer. Всё же роли управления командой и формирования видения проекта - слишком разные.
Нарративщик - не всегда именно ведущий ГД. Его иногда может и не быть (у вас MOBA без сюжета), равно как может и не быть и ГД баланса (у вас квест без боёвки).
Локализацией занимаются переводчики-локализаторы. Их может быть и несколько отделов, и сторонняя студия на аутсорсе, и одинокий Chat GPT. А вот изначальные тексты может писать и ГД, и дизайнер UI, и UX Writer. Документацию для разработчиков пишут либо они сами, либо технический писатель.
Level-designer - это ГД, задача которого собрать цровень так, чтобы игроку было на нём интересно и увлекательно играть. Человек, который рисует сам уровень - Level Artist. Зачастую это не просто не один и тот же человек, а люди, мало между собой взаимодействующие в принципе.
Под "ведущим разработчиком" обычно понимают Lead Programmer / Technical Director. И такие мелочи как администрирование гита и перенос контента в движок - явно не его уровня задачи. На крупных проектах технического директора вообще может не быть, так как нет человека достаточно компетентного во всех областях сразу. Вместо этого там несколько Discipline Leads.
Забыта такая важная роль как QA :) Если речь о мультиплеерном проекте - нужны ещё и, например, DevOps.
Может. А может и не быть. Вот только коммерческий пет-проект кроме "новых технологий, развития и т. п." может принести вам деньги, в отличие от опенсорса за спасибо.
Отсутствие прокрутки списков и излишнее использование drag&drop - это всё же проблемы дизайна UI, а не кода.
Разбирать код проекта 10-летней давности ещё и через декомпиляцию - ну такое себе. Движок поменялся за это время, а декомпилятор никогда не выдаст именно тот код, который был написан.
Самая сырая её версия появилась в 2018, а игра, код которой Вы разбираете, вышла на 2 года раньше.
в некоторых местах длительность DOTween анимации и длительность ожидания (WaitForSeconds) разные, уверен что это ошибка и они должны быть одинаковыми
Скорее всего как раз сделано намеренно, например, когда нужно отдать управление игроку до того как отыграется вся анимация. И именно поэтому используются coroutine, а не OnComplete.
Собственный Debug класс
...
Хорошая идея, но плохо реализованная, потому что логов в релизном билде не будет, но сами вызовы методов и формирование строк останутся.
Решение: для методов добавить атрибут Conditional...
Мог быть кейс, когда при формировании дебажной строки вызывался метод, который что-то менял и это компенсировало какой-то баг. Тогда у вас при тестировании всё будет работать идеально, а на релизном билде (без логов!) будут волшебные баги. Если такой дебаг не просаживает производительность, логов много, а экспертиза в команде хромает, то такое решение оправдано.
Было бы неплохо привести какие-то примеры кейсов, где такой способ будет полезен.
Вот делаем мы ААА-проект уровня RDR2 (у нас сразу и мультиплеер, и одиночная кампания). У нас команда в 1000 человек, а на встрече присутствуют Development Director, Art Director, Creative Director, Publishing Producer и CEO. Вместе они тратят весь день, чтобы обклеить все стены в переговорке всеми возможными событиями в игре и как-то договориться по каждому из них.
Выглядит так, что составление детальной документации по flow игрока - это задача геймдизайнеров, делается это не за одну встречу и занимает не одну схему, особенно если проект объемный.
Код всего класса RandomExtractor целиком приведён ниже.
Зачем так сложно? Кладём все сегменты в список, перемешиваем его и идём по списку возвращая сегменты по одному. Как дошли до конца - снова перемешиваем
IEnumerator getSegment<T>(T[] segments) {
List<T> segmentsList = new List<T>(segments);
while (true) {
shuffle(segmentsList);
foreach(T value in segmentsList)
yield return value;
}
}
...
// Получение случайного значения. Каждый вызов iterator.MoveNext()
// будет присваиваьит iterator.Current новое случайное значение
var iterator = getSegment<int>(new int[] { 1, 2, 3 });
iterator.MoveNext();
Debug.Log(iterator.Current);
В целом, если скорость движения игрока постоянна, то нам достаточно просто создавать новые сегменты каждые X секунд (например, через StartCoroutine), а не замерять расстояние в каждом апдейте. Если хотим ставить сегменты прям идеально - можно держать ссылку на последний созданный и спавнить новый в N метрах от него. Удаление - также: мы знаем скорость, а значит, знаем за какое время сегмент окажется за камерой и станет не нужен. Сразу после его создания вызываем Destroy() с этим временем.
Проблема фона легко решается скайбоксом. Тогда не нужен будет отдельный спрайт в конце. Скайбокс даже можно сгенерировать нейронкой, а не рисовать самому.
Примеры современного ИИ какие-то не сильно современные.
В "Gears Tactics" противники с ИИ действуют стратегически: каждый получает свою задачу от группового ИИ
Групповой ИИ - это просто бот, который командует другими ботами, как ИИ-оппонент в стратегиях. Такой был ещё в первом XCOM четверть века назад.
разработчики использовали систему навигационных полигонов, называемых navmesh. Они поделили эти полигоны на группы: синие зоны — легкий путь, жёлтые — немного сложнее, красные — самые сложные.
NavMesh - это стандартный инструмент ИИ-навигации, доступный в любом современном движке, от громадного UE, до крохотного Godot. Сама же навигация с весами - это, например, алгоритм А* 1968 года
Здорово, что всё получилось, но почему именно QA, а не, например, UX Writer? Там вроде как и конкуренция ниже, и изначальное образование пригодится больше.
Ограниченный ресурс - это распространённая механика в играх в принципе, как мана в Диабло и очки действия в Fallout 2. Цель механики - побудить игрока к выбору, дать вызов. Даже если ресурс не восполняем (патроны в КС), то механика всё равно работает на те же цели. Тут всё понятно.
А вот случаев, когда игрока награждают за неиспользование ресурса не так много. Я разве что могу снаряды в "танках" вспомнить, в том плане что чем меньше отстрелял - тем больше серебпа сэкономил. Но у игроков эта механика особой популярностью не пользовалась.
То есть игра буквально наказывает игрока за то что он играет? Звучит очень сомнительно, особенно когда это основная механика. Это всё равно что в тетрисе отнимать очки за переворачивание фигур.
Стоит продумать "план Б" на случай если такой подход не взлетит.
Обычно цель - не чтобы он много играл в абсолютных цифрах, а чтобы он делал это постоянно. Если игрок залипал неделю, а потом пошёл играть во что-то другое - он не особо ценен, даже если сидел с утра до вечера. А вот если он играет по часу в день, но много месяцев или лет - игра становится его хобби. А на хобби люди готовы тратить очень много.
Фильм "Мир танков и людей" здорово рассказывает об этом.
Да хотя бы квадратные уравнения на математике порешать, игру сделать - перед друзьями попонтоваться.
Я занимаюсь разработкой игр 20 лет, а последние несколько недель посвятил поиску издетеля для своего очередного проекта ;) И мне таки есть чем дополнить ваши, тоже очень дельные, советы.
Не пытайтесь откусить больше, чем сможете проглотить.
Ещё на самом раннем этапе, ещё когда вы только придумываете игру, учитывайте какие средства (время, скиллы, деньги) у вас есть и что вы можете сделать этими средствами.
Если вы не можете нарисовать / анимировать весь контент - сначала идите в ассет стор и думайте что более-менее достойное можно сделать из его содержимого.
Если вы не программист - тоже идите в стор или ищите примеры уже сделанных механик и выберите те, в которых сможете разобраться и адаптировать под себя.
Даже если ваш бюджет $0 - всё равно идите в стор и смотрите бесплатные ассеты. На них тоже можно дотащить игру до MVP и дальше искать издателя или единомышленников.
Трезво оценивайте свои трудозатраты. Исходите из того, что из MVP, сделанного за выходные, полноценная игра получится никак не меньше чем за 3-4 месяца.
Планируйте и следуйте плану.
Определитесь хотя бы какие фичи вы делаете на этой неделе и какие - на следующей. Занимайтесь своим проектом постоянно. Хотя бы понемногу, но каждый день. Иначе очень легко забросить, особенно если совмещаете с основной работой.
Даже если вы освободили под проект выходные - занимайтесь им по вечерам и на буднях тоже, иначе ваши эстимейты на дни превратятся в эстимейты на недели.
Fail fast & fail cheap
Если работа над игрой не идёт, сроки постоянно съезжают или вам буквально в тягость заниматься игрой - не бойтесь её бросить. Оглянитесь назад, поймите что сделали не так, составьте план на новый проект и потратьте 1-2 недели на R&D. Там посмотрите ещё раз, стоит ли забрасывать. Если вы осознали, что выбрали не ту технологию, то чем раньше вы её смените - тем лучше.
Вот если вы за собой заметили, что уже 2-3 раза меняете проект или движок - это повод задуматься что в целом идёт не так.
Когда вам, чтобы поменять хп у сотни врагов в вашей игре, нужно выбрать каждого персонально и изменить поле в редакторе - это не удобная работа с данными. Достоинства ScriptableObject совершенно не в этом, а в том, что его полями могут быть не простые типы, а сущности движка: спрайты, префабы, прочие ассеты и другие SO.
Например, вам нужно создать описание персонажа, которое объединит его префаб, спрайт иконки и контроллер анимации. Вот тут без SO не обойтись. Можно, конечно, хранить эти ассеты в Resources с определёнными именами, но такой способ имеет много минусов и разработчиками движка не рекоментдуется.
Данные из простых типов (например, характеристики персонажа) гораздо удобнее хранить в обычной экселевской таблице (или в каком-то удобном вам текстовом формате) и уже оттуда генерить в движок. Тогда эти данные легко массово редактировать и их можно мержить.
Да он и в первой поддерживал. На основе прототипов, без private / protected, но всё остальное работало.
О да, его книга буквально открыла для меня мир флеша! Признаться, ещё недавно я ей пользовался. Монитор у меня на ней стоял)
Unity с публикацией под WebGL в принципе подойдёт. Там не так всё наглядно, но по части работы с ресурсами, доступных платформ и производительности он на голову выше флеша.
Стальные монстры (Pacific Strom)? 9 Рота?
Забавно, что Вы вспомнили так много почивших студий, и забыли крупнейшего на данный момент российского разработчика))
Так почему в итоге забросили геймдев? У Вас ведь даже получалось - вон, и первую игру сделали.
Работу / стажировку найти сложно? Так её в любой области найти непросто, когда нет опыта и за плечами только курсы.
Просто у Вас довольно тернистый путь из 1C, Java, C#, Unity и теперь вот ещё ASP. Не боитесь что с ним будет то же самое?
Категоричное заявление. Но неверное. Если вы собираетесь писать игровую логику или шейдеры - вам нужна математика хотя бы на уровне средней школы. Хотя бы векторы и хотя бы на плоскости.
Причём чем меньше проект и на чем более ранней стадии разработки он находится - тем выше шанс что она пригодится. Если вы пишете систему начисления игрового имущества за баттлпасс в какой-то ААА игре, то там логика не будет сильно отличаться от начисления бонусных баллов в интернет-магазине. Но и работа будет далека от того, что обычно ждут от геймдева. А вот если у вас стартап с гиперказуальными паззлами на основе физики и командой в 2 программиста - то там с математикой всё же придётся иметь дело.
Какой-то странный список, в котором свалены в кучу должности, роли и даже грейды, без оглядки на особенности проекта и оргструктуру компании:
Руководитель проекта не обязательно должен быть визионером. Это может быть так на небольшом/инди проекте, но часто визионер - это Creative Director или Lead Game Designer. Всё же роли управления командой и формирования видения проекта - слишком разные.
Нарративщик - не всегда именно ведущий ГД. Его иногда может и не быть (у вас MOBA без сюжета), равно как может и не быть и ГД баланса (у вас квест без боёвки).
Локализацией занимаются переводчики-локализаторы. Их может быть и несколько отделов, и сторонняя студия на аутсорсе, и одинокий Chat GPT. А вот изначальные тексты может писать и ГД, и дизайнер UI, и UX Writer. Документацию для разработчиков пишут либо они сами, либо технический писатель.
Level-designer - это ГД, задача которого собрать цровень так, чтобы игроку было на нём интересно и увлекательно играть. Человек, который рисует сам уровень - Level Artist. Зачастую это не просто не один и тот же человек, а люди, мало между собой взаимодействующие в принципе.
Под "ведущим разработчиком" обычно понимают Lead Programmer / Technical Director. И такие мелочи как администрирование гита и перенос контента в движок - явно не его уровня задачи. На крупных проектах технического директора вообще может не быть, так как нет человека достаточно компетентного во всех областях сразу. Вместо этого там несколько Discipline Leads.
Забыта такая важная роль как QA :) Если речь о мультиплеерном проекте - нужны ещё и, например, DevOps.
Может. А может и не быть. Вот только коммерческий пет-проект кроме "новых технологий, развития и т. п." может принести вам деньги, в отличие от опенсорса за спасибо.
Отсутствие прокрутки списков и излишнее использование drag&drop - это всё же проблемы дизайна UI, а не кода.
Разбирать код проекта 10-летней давности ещё и через декомпиляцию - ну такое себе. Движок поменялся за это время, а декомпилятор никогда не выдаст именно тот код, который был написан.
Самая сырая её версия появилась в 2018, а игра, код которой Вы разбираете, вышла на 2 года раньше.
Скорее всего как раз сделано намеренно, например, когда нужно отдать управление игроку до того как отыграется вся анимация. И именно поэтому используются coroutine, а не OnComplete.
Мог быть кейс, когда при формировании дебажной строки вызывался метод, который что-то менял и это компенсировало какой-то баг. Тогда у вас при тестировании всё будет работать идеально, а на релизном билде (без логов!) будут волшебные баги. Если такой дебаг не просаживает производительность, логов много, а экспертиза в команде хромает, то такое решение оправдано.
Было бы неплохо привести какие-то примеры кейсов, где такой способ будет полезен.
Вот делаем мы ААА-проект уровня RDR2 (у нас сразу и мультиплеер, и одиночная кампания). У нас команда в 1000 человек, а на встрече присутствуют Development Director, Art Director, Creative Director, Publishing Producer и CEO. Вместе они тратят весь день, чтобы обклеить все стены в переговорке всеми возможными событиями в игре и как-то договориться по каждому из них.
Выглядит так, что составление детальной документации по flow игрока - это задача геймдизайнеров, делается это не за одну встречу и занимает не одну схему, особенно если проект объемный.
Зачем так сложно? Кладём все сегменты в список, перемешиваем его и идём по списку возвращая сегменты по одному. Как дошли до конца - снова перемешиваем
Код функции shuffle можно найти например тут, там строк 10 от силы.
В целом, если скорость движения игрока постоянна, то нам достаточно просто создавать новые сегменты каждые X секунд (например, через StartCoroutine), а не замерять расстояние в каждом апдейте. Если хотим ставить сегменты прям идеально - можно держать ссылку на последний созданный и спавнить новый в N метрах от него. Удаление - также: мы знаем скорость, а значит, знаем за какое время сегмент окажется за камерой и станет не нужен. Сразу после его создания вызываем Destroy() с этим временем.
Проблема фона легко решается скайбоксом. Тогда не нужен будет отдельный спрайт в конце. Скайбокс даже можно сгенерировать нейронкой, а не рисовать самому.
Примеры современного ИИ какие-то не сильно современные.
Групповой ИИ - это просто бот, который командует другими ботами, как ИИ-оппонент в стратегиях. Такой был ещё в первом XCOM четверть века назад.
NavMesh - это стандартный инструмент ИИ-навигации, доступный в любом современном движке, от громадного UE, до крохотного Godot. Сама же навигация с весами - это, например, алгоритм А* 1968 года
Так хорошие же советы и рассуждения правильные. Тоже подпишусь под каждым абзацем.
А десятки проектов могут идти параллельно если автор ими руководит или менторит.
Кажется, помню Вас по форуму flashgamedev.ru. Вообще странно что при таких оценках так мало просмотров.
Да, отличное было время :D