CGAleksey

Разработчики находятся в достаточно трудной ситуации. С одной стороны начальство требует дойную корову, которая стабильно работает как автомат калащникова и приносит денежку. C другой стороны таких дойных коров уже изобретено достаточно и в целом все они похожи друг на друга с точки зрения наличия новых уникальных механик и их развития.

На первый взгляд все кажется просто.  Вот, на самом деле, почему нельзя просто создать какую-то новую механику, даже много новых механик и улучшать их пока они не устроят? Если что, неудачные механики можно выкинуть :)

<<Для начала в игре существует только одна core-механика. И для ее реализации, поверьте, придется уйти в работу с головой. Создавать нексолько механик = создавать несколько разных игр. А это равносильно усложнению своей жизни. Вместо шлифовки одной механики вы должны распылиться на 10, а потом оставить из них только одну, а остальные выкинуть. Печально выкидывать результаты работы, правда?>>

Разработка игры с новой механикой - это примерно то же самое как работа над открытием или даже процесс поиска клада. Отлично, если вы опытный кладоискатель. Такие кладоискатели знают, что клад вряд ли спрятан в песочнице на детской площадке и не будут его там искать, тратить на это время. Потому что в свое время они уже наступали на эти грабли и ничего там не нашли. То есть существуют механики, которые заведомо неудачны / непригодны для игр. Конечно, все можно адаптировать, видоизменить, подогнать. Но все же существуют вещи которые не следует делать.

Вот рассмотрим очень простой пример такой механики на мобильной игре.

Допустим у нас есть персонаж в мобильной игре и наша задача управлять им. Мы видим персонажа сверху (2D). Как бы в сделали его управление?

Это очень щепетильный вопрос. Управление - это задача задач, которую решают в процессе разработки.

(1) Если вы будете приказывать персонажу идти за пальцем, когда он опущен на экран, то ваша рука будет перекрывать экран и вы будете смотреть на свою руку;

(2) А если персонаж будет идти в противоположную о пальца сторону, то будет ли удобно такое интвертирование управления?

(3) Если персонаж будет идти в точку, которую вы кликнули, то сможет ли он увернуться от летящей ракеты? Не перекроется ли экран рукой, когда вы смените направляение движения персонажа? Это управление точно удобно?

(4) А если просто... Джойстик и все тут! Не перекроет ли джойстик экран? Сколько экранного пространства он занимает (допустимо ли это)? Удобен ли он? Функционален? Позволяет ли он погрузиться в атмосферу игры?

Кто-то скажет: вот вы написали столько всего, так и управления не сделаешь, если все плохои все "неочень". Сделаешь, как раз это частично задача дизайнера интерфейсов, частично дизайнера, отвечающего за управление. Но больше, конечно, задача дизайна управления.

Да, вот такими задачами и занимаются дизайнеры: сделай то, не знаю что, пойди туда, не знаю куда и чтобы все было круто и никак иначе.

Оптыный дизайнер (опытный кладоискатель) способен быстро оценить все "за" и "против" каждого из пунктов [1-4]. Новичок же, очень вероятно, будет экспериментировать и постигать тайны управления с нуля :)

Надеюсь теперь стало очевидней, что разработка новой механики - это работа.
Это работа и она не всегда увенчивается успехом. Не всегда даже опытному дизайнеру удается создать новую механику. И это часто зависит не только от дизайнера, но и от команды, от возможностей платформы для которой все разрабатывается.
Дизайнер создает тех. задание, отдает ее на реализацию дизайнерам и программистам, через какое-то время получает результат. Если результат устраивает, то это успех. Если результат не устраивает, то процесс повторяется до того момента, пока инвестору все это не надоест или пока команда не замучается "пробовать". Да, людям не нравится работать, а потом выкидывать свою работу. Особенно, когда ты старательно работаешь и не один месяц. Да, ты получаешь зарплату, но где удовлетворение от проделанной работы? Так и свихнуться недолго, если каждый день все рабочее время выкапываешь, а потом закапываешь выкопанную яму.

Вот потому-то все и идут на ухищрения. Зачем пидумывать что-то новое, когда старое хорошо работает? Возможно нужно немного изменить старое и все будет хорошо?

То, что я написал, касается многих вещей. Не только core-механики. Другие вещи могут быть подвержены этому.

//===

В процессе работы над персонажем всплыло множество моментов, которые требовали такой хорошей  и основательной проработки как со стороны дизайнера-программиста, так и со стороны дизайнера по механикам.

В процессе разаработки, было принято решение показыват игроку тело персонажа, чтобы он мог видеть себя своими глазами. Почему нет? Это добавляет атмосферы, смотрится круто.

Мы все фанаты крутого графона и в 21-м веке неприемлимо, когда твоя голова, руки, ноги или пушка влазят в полы или стену или еще куда-то. Нужно было это учесть.

С другой стороны, если персонаж стоит одной ногой на выступе обрыва, то все его тело должно как-то отреагировать на то, что вторая нога в воздухе. А если центр тела персонажа смещен в сторону обрыва, то тут уж 100% нужно это как-то отобразить на персонаже.

Мы справились с этой задачей, сбоку это выглядит так (скрины специально не содержат текстур, дабы не наспойлерить):

По части влияния смещения тела на механику движения: удалось добиться стабильности и минимизировать влияние анимации ног на перемещение игрока.

Ноги опускаются процедурно. Пришлось водключить инверсную кинематику и совместить ее с процедурной анимацией движения всего персонажа. О том как мы анимировали персонажа можно ознакомиться здесь: Процедурная анимация движения персонажа

Получилось весьма недурно :)

Руки.

C руками, как и со всем остальным, отдельная история. И она длинная.

Что требуется от рук? Чтобы они не пересекали стены, чтобы держали пушку. И чтобы это все выглядело нормально. Бывшый мой босс всегда ставил задачу примерно так. Он перечислял все требования до мельчайших и в конце добавлял: "И да, сделайте все это так, чтобы выглядело круто. Просто сделайте так, чтобы все было круто и не заставляйте меня говорить что получился отстой."

Руки персонажа эволюционировали и прошли очень долгий путь развития. Сперва мы работали над встроенной в руку "спец.пушкой". Всячески безуспешно пытались совместить то, что совместить трудно, да и нужно ли совмещать: руку + пушку + возможность изменения рукой гравитационного поля. Вот пара каких-то ранних скетчей "спец.пушки":

Подключенные первые варианты рук/манипуляторов выглядел примерно так:

Здесь один из вариантов ранних анимаций. Главное не внешний вид, а принцип работы:

Пробовали такие варианты:

Один манипулятор наехал на другой. Да, такое часто встречалось и приходилось много работать над исключением самопересечения манипуляторов.

Тесты инверсной кинематики. Чисто математика:

А здесь искусственный интеллект нечеловеческими способами учился взаимодействию рукой. Короче, робот как ребенок учился двигать рукой, а на видео некоторые промежуточные результаты, причем неуспешные XD

Инверсная кинематика  в чистом виде (IK):

Еще немного инверсной кинематики для тех кому понравились видео:

Здесь эксперименты того как смотрится перемещение обьекта манипуляторами (как манипуляторы ведут себя при перемещении аюстрактного куба):

Навозившись порядочно с манипуляторами, убив тонну времени, сил и нервов, исписав кучу бумаги, мы все же сумели добиться желаемого результата. Финальный вариант на данный момент показать не могу, но могу рассказать к чему мы пришли и как.

Манипулятор мы разделили, условно, на руку (манипулятор) и пушку. Пушка выполняет свои функции, а рука дополняет пушку. Не в воздухе же ей висеть.

Пришлось прописат анимации обхвата пушки рукой и то как рука двигается за пушкой (законы движения, которые позволяют руке не пересекать пушку).

Так же рука может быть и без пушки. Для этого случая мы научили кисть немног взаимодействовать с окружением: если игрок вплотную подходит к стене, то рука как бы занимает промежуточную позицию между стеной и телом игрока. не дает игроку лицом воткнуться в стену. Классно, правда? Так же рука может огибать предметы, если игрок захочет как-то повести себя нестандартно и влезть рукой во что-то.

Когда рука держит пушку, то для этого случая прописаны процедурные анимации движения пушки, которые предостерегают ее от влазания в стены или еще куда-то там. Пришлось порядочно поработать чтобы хитрый игрок никак не смог засунуть пушку туда, куда нельзя.

Некоторые скетчи из процесса разработки игры выкладываю здесь:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey/

--

Надеюсь статья понравилась и вы почерпнули из нее что-то новое.

На сегодня у меня все.

Спасибо за внимание!

Собираем с товарищем игру на коленке (3D-головоломку от первого лица).

Есть возможность поделиться скетчами, не пылиться же им на полке...
На данный момент есть возможность опубликовать некоторые наработки по окружению.

Справа(рядом текст "Wall concr") фильтр - барьер. Понятно, что сейчас это никому ни о чем не говорит, но все же интереснее разглядывать скетчи, когда есть хоть какое-то обьяснение.
Здесь наброски опор и немного монтажа этого фильтра в раму на которой держится игровой мир.

Варианты стен. Вариант стены с отражающей поверхностью(зеркало) от которой отразился лазерный луч (ПВ). Монолитная стена (ЛП). "Забор" (ЛН). Ряд опор и уходящий вдаль провод (ПН).

Все как бы разбито на кубики. Сделано это для того, чтобы можно было работать с метриками на бумаге, прикидывать размеры. Зачем мне это нужно? Не спрашивайте, мне нужно.

Монтаж окна, провод, источник питания (куб с зеленой точкой). немного набросков рамы-крепления потолка. В основном здесь совмещение разных узлов, проверка того как некоторые элементы крепятся друг к другу и как они смотрятся в целом.

Пол, приемники лазерных лучей, снова опоры:

Монтаж фильтров (горизонтальная опция монтажа). Фильтры прозрачные, чтобы не перекрывали стену и было видно как они установлены (вряд ли здесь что-то будет понятно):

Монтаж "сайдинга на бетонной стене". Некоторые варианты бетонных стен:

Варианты приемников энергии. Они используются в игре, что это... Это будет ясно из игры :)

Некоорые варианты потолочных конструкций.

Больше скетчей по нашему проекту вы можете найти здесь:
https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey

На сегодня все, спасибо за внимание :)

Немного экспериментировал с формами персонажа для игры, которую делаю с товарищем на коленке в гараже :) Не судите строго, ненастоящий художник.

Финальный набросок:

Некоторые попытки/эксперименты:

Здесь ещё пробовал экспериментировать с формой головы-корпуса. Немного менял принцип работы дрона:

Больше работ и прогресса по игре можете увидеть здесь:

https://twitter.com/CGAleksey
https://www.instagram.com/cgaleksey/

На этом все, всем хороших выходных!

Привет всем!
Вот мои некоторые попытки представить интерьер внутри игры, которую мы с товарищем делаем в гараже и на коленке 😂

Здесь часть потолка:

А это часть стены:

Немного работал над полом, креплениями стекла и монтажом игровых объектов в пол:

Здесь наброски соединительных коробок и электропроводки 😉 Ну и немного спойлеров об игре

Модули, которые формируют логические задачи-головоломки. Ещё не закончили экспериментировать с ними.

Воздушная шахта, вернее решетка. И пара эскизов логических модулей.

Здесь больше эскизов / набросков / схем уровней и вообще всего по нашей игре:
http://twitter.com/cgaleksey
http://instagram.com/cgaleksey

Спасибо зза внимание, всем хороших выходных :)

Статья о том как художник/дизайнер бодался с системой рисования линий для игры и сделал ее :)

Кому будет интересна статья? Наверно всем, но не бывалым прогерам так как тут ничего нового для них нет. Читателя ждет МНОООГО видео, картинок и обьяснений "на пальцах".

Немного модного арта для затравки (который получился попутно и случайно в процессе тестов рисовалки):

В общем надоело смотреть на то как лазерный луч в нашей инди-игре не оставляет на стенах ничего. Абсолютно ничего. Пробовал trail добавлять, но он же исчезает. И смотрится trail так себе... Даже бомжам стыдно показывать.

Итак, поехали. Нужно было сделать систему рисования линий для игры. Линия должна рисоваться от лазерного луча на любой поверхности. Стал делать свою систему потому, что на AssetStore ничего такого нет. Есть одна система, но она:
1) рисование на каждом обьекте (static/dynamic) приводит к тому, что обьект вырывается из батчинга и создает +1 drawCall.
2) система рисует только точки. Ну типа как в Splatoon. Можно рисовать пятна, но не линии.
Очевидно, это мне не подходит, так что go делать что-то свое.

Это далеко неконечный вариант так как линии здесь не рисуются, рисуются "точки". За счет медленного движения мышки кисть рисуется часто и след выглядит как линия:

В сети можно найти кусочки кода и даже проекты, которые позволяют рисовать следы на какой-то одной модели.

Требования к системе такие:
- линии должны рисоваться на статических обьектах, но не всех. Динамические обьекты должны не давать рисовать линию на полигонах, которые ЗА ними.
- работает максимально быстро
- работает на любом железе на котором работает Unity
- число линий неограничего
- число цветов линий - неограничено
- рисовать можно не только линии

Задача эта для меня новая, никогда такого еще не делал, пришлось повозиться.
Как рисуются линии в комп-графике? Есть модель и игрок проводит по модели лучем. На модели должен остаться след. Нужно найти в каком месте рисовать этот след.
1) очевидно, полигоны, которые смотрят ОТ начала рисования линии не будут содержать на себе след. Потому, что это полигоны с противоположной стороны модели. Их можно отбраковать.
2) есть полигоны, которые смотрят на игрока и которые попали в область рисования линии. На них предположительно будет след от линии.

Ну вот, для наглядности:

Красная точка - начало луча. Синие линии - это сектор в котором луч повернулся. Стрелка показывает направление поворота (хотя это неневажно).
В итоге у нас есть треугольник, которым рассекли модель. Полигоны, которые повернуты от игрока (backfaced) сразу тупо отбросились и я их не сек плоскостью в кторой орудует луч.

Есть некоторые полигоны, которые повернуты к нам, но, которые не дожны рисовать на себе линию так как они перекрыты другими полигонами. Например, это полигоны в центре картинки. Для отбраковки таких линий, я запилил алгоритм отбраковки, который отсеивает их.

Вот фото работы этого алгоритма:

Красные линии - это то, что будет рисовать линию на модели. Желтые - это то, что отсечено.
Цифры и прочее - это для себя. Вообще пришлось сделать стенд и на нем все отлаживать. Стенд поддерживает подргузку линий из файла. если в игре что-то крякнется, приходится запускать отладчик, который подгружает в себя все логи и тестирует состояние игры на момент поломки. Удобно, всем советую искать баги невручную :) ну а потом, когда баг выявлен, ищешь что нагнулось в алгоритме.

Здесь просто тесты алгоритма, смотрел как работает:

В сцене может быть несколько "рисователей". Вот видео. где одновременно рисуется больше одного пятна за 1 раз. Кстати, тут видно, что нужно рисовать именно линии, а не пятна. Иначе между точками есть пробелы.

Здесь видно (подсвечиваю) полигоны на модели и какие полигоны секутся лучем (рисуют линию):

Здесь наглядно видно как работает рисование линий:

Удалось сечь обьект и рисовать на нем линию. Здорово!
Осталось сделат самую малость: найти обьекты, которые будут рисовать на себе линии.Вот водишь ты лучем в пространстве и нужно знать с чем луч пересечется. Для этого есть Оctree & BVH. Первый хорош для статики, второй для динамических обьектов. Спасибо GameDev.ru (а именно крутым парням foxes и kkolyan за подсказки).

Внедряем деревянные структуры, печем, запускаем. Работает!
Это не конечный вариант, но все же. Вот как смотрится след в действии:

Спасибо за внимание. На данный момент я занимаюсь больше артом и даже на такие беглые статьи не хватает времени.

Кому интересно, вот ссылки на меня. Здесь я выкладываю некоторые результаты по игре. Пока больше скетчами делюсь. Позже больше видео начну выкладывать ;) Подписывайтесь, это сильно стимулирует работать :)

https://twitter.com/CGAleksey
https://www.instagram.com/cgaleksey/