Как считаете, время разработчиков-одиночек прошло? Или наступает именно сейчас? Когда самоизоляция и карантин обеспечили избыток свободного времени и свободу от офисной мозгомойки, можно задуматься не только о «текучке», но и творчестве.
Быть может, именно сейчас рождаются проекты «одного человека», которые смогут встать в один ряд с «Elite», «VVVVVV», «Papers, Please», «Stardew Valley», «Undertale» и «Minecraft». Gamedev вполне можно считать одним из видов искусства, расширяющим горизонты познания окружающего мира и внутреннего мира человека.
Мы подготовили концентрированную выжимку информации, полученной на лекционном вечере сообщества ECS COMRADE, которое проходило еще до карантина в Высшей школе бизнес-информатики НИУ ВШЭ в рамках образовательных программ по игровой индустрии «Менеджмент игровых проектов» и «Основы создания игр».
Давным-давно, в далёкой-далёкой галактике…
Примерно с 70-х годов прошлого века, когда разработка игр была еще в зачаточном состоянии, основным подходом в создании цифровых продуктов был классический метод (объектно-ориентированный). Однако он использовался за неимением альтернатив — сейчас наступает эра, когда «классика» должна остаться в прошлом, а на смену ей придет более функциональный и универсальный метод.
Представьте, что вам нужно создать определенного юнита, к примеру, кошку. Как это делается в обычное время? Нам необходимо сделать класс, потом подкласс, в который включается эта самая кошка (класс хищник, подкласс семейство кошачьих).
Пусть это будет не кошка, а боевой юнит в нашей игре, который со временем еще и будет меняться, получая различные изменения характеристик (воин или маг, прокачивающийся по мере получения опыта). И таких героев может быть целая куча, а есть еще и другие персонажи, механики, элементы окружения.
Одним словом, наступает момент, когда код нашей игры, созданной при помощи объектно-ориентированного подхода, превращается в этакого «макаронного монстра». Да, система все-таки будет рабочей, но развивать такой код окажется весьма проблематично.
Так что на замену данной методики пришел подход под названием composition over inheritance. Он оказывается более гибким и настраиваемым, который позволяет решать проблему создания новых игровых элементов. Однако в таком коде еще проще запутаться, чем в классическом, что снова возвращает нас к необходимости совершенствовать методику разработки игровых приложений и самостоятельных проектов.
Потом все изменилось…
Мартин Адамс стал тем человеком, который предложил внедрить революционную систему Entity component system. Именно она позволила приступить к разработке крутых ММОРПГ — именно ECS в дальнейшем будет использоваться практически во всех студиях и практически всеми разработчиками.
Что такие ECS? Это, если говорить простыми словами, архитектурный паттерн, который используется при разработке современных видеоигр.
В чем же преимущества этой системы?
Во-первых, она создана напрямую для разработки игр (целевое направление, которое позволяет адаптировать методику под определенные задачи).
Во-вторых, ECS намного проще развивать.
В-третьих, методика работает по принципу схожести с реальным миром (основана на реальных физических законах).
Мы любим обсуждать все, что связано с ECS в нашем Телеграм-канале. Присоединяйтесь, если также увлекаетесь этой темой.
В конце концов, архитектура идеально подходит для коллаборации. Программисты, использующие ECS, пишут атомизированный код, что позволяет вносить правки разными людьми, преследующими, порой, самые разные цели.
На каких фреймворках лучше работать с ECS?
Оптимально использовать DOTS (высокопроизводительный многопоточный стек, делающий работу на игровом движке более оптимизированной и комфортной), если речь идет о разработке игр на Unity. Это не сторонний фреймворк, а уже являющийся частью Unity, он постоянно развивается и поддерживается. Другими словами, у DOTS есть будущее.
Конечно, и с ним имеются определенные проблемы (например, допускается использование только blittable types и много boilerplate), которые устроят не каждого разработчика. Однако данному способу отдают предпочтения разработчики на Unity, которые предпочитают использовать огромное количество уже готовых инструментов и делать игру, а не писать код.
Не одной ECS едины
Конечно, всю игру, сделанную на Unity, невозможно разработать на одной лишь ECS. Есть определенные элементы, которые выполняются на другой архитектуре и служат эдакой связью системы с «внешним миром».
Новый Input, который не так давно сделали для движка. Так вот, с его помощью и модернизируется ESC-архитектура, что позволяет, к примеру, назначать клавиши клавиатуры или кнопки мышки для определенного действия. Главное преимущество подобного подхода – универсальность. «Прибиндить» к действию вы можете практически любую клавишу, в том числе и «курки» геймпадов. После чего все выполненные мероприятия перекладываются в специальный буфер, через который и идет связь с ECS.
Почему прототипировать на ECS быстро?
На самом деле, разработка на этой архитектуре быстрее, потому что сотруднику требуется прилагать меньше умственных усилий и писать меньше кода. Тут нужно оба момента разобрать подробнее, чтобы четко определить все преимущества данного подхода к созданию видеоигр.
Итак, про мышление. Всего можно мыслить в трех направлениях: YOLO, ООП и, собственного, ECS. Первое – это Unity-way, который легко освоить, однако у него есть весомая проблема – слабо развивается. Второй вариант активно поддерживается и развивается, но порог вхождения в него намного выше. Третий же подход к мышлению включает в себя одни плюсы (меньше печатать, легче освоить и так далее).
Когда вы работаете на ECS, то вы мыслите в данных. И у вас есть 3 типа данных: статические, runtime-данные и config-данные. Первые никогда не меняются, вторые представляют собой игровую логику, а последние отвечают за пользовательские настройки, данные баланса и прочие условия, меняющиеся от сессии к сессии.
Далее следует определить, на каком фреймворке мы будем работать (спойлер, выбираем LeoECS). Выбор делаем мы, смотря на скорость написания кода (она у данного фреймворка максимальная), на простоту освоения и степень зависимости от Unity. Данный фреймворк мы применяем на этапе перехода от статистических данных к runtime-сегменту, связывая их, а потом переходим к конфигам.
Итоги
Можно прийти к выводу, что архитектура ECS для разработки современных игр не просто подходит, а рекомендуется. С ее помощью вы сможете существенно сократить затраты временных ресурсов на ручную работу, что позволит выпустить игру раньше и более проработанной. А что еще нужно для обычного игрового разработчика?
Посмотреть полные видео с лекций можно здесь:
И пока идет карантин, можно поучаствовать в новых мероприятиях от Вышки, проводимых в онлайн режиме: онлайн конференция Gamedev.House 12 апреля, дистанционная образовательная программа «Основы создания игр» 17 апреля, онлайн день открытых дверей по программе «Менеджмент игровых проектов» 29 апреля.
А если вы хотите сразу писать под Кубернетес, но не знакомы с ним, можно обменять «внезапна»(с) появившееся свободное время на ценные знания и перспективы — и пройти бесплатные теоретические курсы по Kubernetes в «Вечерней школе Слёрма». Надо только зарегистрироваться по ссылке: http://to.slurm.io/CG2mYQ
Suvitruf
SH42913
Сама по себе архитектура никак не влияет на количество лапши, которую нужно писать. А вот конкретный фреймворк — уже влияет.
Svetlo ECS — ИМХО, рекордсмен по количеству лапши
Unity ECS — требует уже немного меньше необходимой лапши(хотя это еще хз)
Entitas — еще меньше лапши, но в обмен на кодогенерацию
Однако есть и всякие опенсорсные альтернативы, которые стараются делать максимально простой и понятный API — LeoECS и Morpeh. Вот в них количество кода будет на несколько строк больше, чем в аналогичном коде на монобехах, зато взамен они дают лучшую модульность, тестируемость и расширяемость, по сравнению с любыми вариантами на монобехах.