В этот раз я не написал ни строчки кода; в этот раз у меня был некоторый набор размышлений (в общем, на вполне себе такие обычные темы), которыми я хочу поделиться.
Речь пойдёт о технологиях; технологиях разработки и поддержки программного обеспечения, в том числе и для игр.
Давайте изначально определимся с тем, как мы работаем: перед началом выпуска любого приложения, мы должны определиться с тем, что мы хотим получить на выходе и определиться не с такими очевидными вещами, как какая будет программа, а с тем, какое будет связанное окружение этой программы:
- сколько памяти будет занимать приложение на диске и при загрузке;
- как будут функционировать системы загрузки и выгрузки данных;
- как будет организован код;
- какой язык (библиотеки, фреймворки) будут использоваться для её решения;
- и кое-что ещё.
Объясню вопрос на примерах.
Пример первый
Мы решили написать простенькую 2d аркаду на 2 часа игрового процесса. Но, поскольку не владеем ничем, кроме Unreal Engine - взяли его за основу. Быстро, удобно, но размер выходного файла, мягко говоря, неприятно поражает, да и оперативной памяти столь простая игра занимает неприлично много. Зато вся игра была сделана примерно за неделю.
Мы получаем ограничение на пользователя, который не сможет поиграть в данную игру, если у него параметры компьютера недостаточно высокие, т.е. отсечения части аудитории.
Пример второй
Например, в целях оптимизации памяти (дисковой, оперативной) было принято решение писать приложение "с нуля". Это заняло несколько месяцев (построение и отладка архитектуры, исправление ошибок и прочее). В качестве части решения был принят некий фреймворк и некий язык.
Через полгода фреймворк перестал быть популярным и ещё через полгода количество разработчиков на рынке труда, владеющих им, сократилось примерно в 10 раз (на самом деле просто стало моветоном указывать, что владеешь им).
В какой-то момент было принято решение выпустить вторую часть. Но, так как специалистов с нужной квалификацией оказалось не найти - было принято решение опять всё писать с нуля, что сильно подняло расходы и, после ряда обсуждения и расчётов, от второй части пришлось отказаться.
Ситуация, понятное дело, несколько надуманная, да и люди, знакомые с архитектурой могут поправить меня, мол, ну что ты, это ведь просто фреймворк, хорошая, мол, архитектура должна иметь запас прочности на смену.
Но тут мне есть, что возразить:
Лично был свидетелем, как от развития весьма перспективной SCADA системы пришлось отказаться из-за того, потому что найти подходящих специалистов на рынке труда оказалось практически нереально.
Что же касается разговоров об архитектуре, мол, она должна быть такой, что ого-го: всё это махание кулаками после драки. Любая архитектура имеет некоторый запас прочности, однако закладывается на каком-то фундаменте. И, зачастую, библиотеки и фреймворки являются частью этого фундамента.
Пример третий
Поддержка. Скажем, вы выпустили приложение, оно хорошо работает, однако есть некоторые проблемы, связанные с плохой балансировкой игрового процесса и ошибками.
Обычно, всё это исправляется патчами. Но вот тут появляется следующий нюанс: тип языка, который используется.
Например, есть языки со строгой типизацией (Typescript) и без оной (Javascript).
Так вот, лагерь веб-разработчиков разделился: одни говорят, мол, JS - это пережиток прошлого, а TS - это способ защититься от ошибок; другие говорят, что TS - избыточен, а те, кто наговаривают на JS просто дилетанты, которые не разобрались в его гибкости и устройстве.
По существу, наверное, обе стороны правы. Но есть, как обычно, нюанс: всё зависит от того, какое приложение разрабатывается и насколько высока цена ошибки.
Когда речь идёт о большом количестве работы с абстракциями и повышенной требовательности к соответствию структур данных (такое, обычно, бывает, когда реализуется сложная или изощрённая логика), то статическая типизация - это способ гарантировать правильность поступающих данных.
Однако, зачастую, повышенная требовательность контроля данных - отсутствует! То есть появление ошибки несоответствия типов либо сразу приведёт к заметной ошибке, либо данная ошибка не окажется никакого критического влияния на работу приложения.
Плата за использование статической типизации, порой, бывает крайне высокой: приходится постоянно держать на готове большое количество интерфейсов и описаний структур данных, которые используются более чем в одном файле (то есть практически любую структуру). Это крайне затрудняет чтение и поддержку кода, особенно, если не использовать IDE, зато позволяет не пропустить ошибку.
Так вот, цена за использование любой технологии всегда присутствует: вполне возможно пойти на риск отказа от части проверок и, засчёт этого, сократить время на поддержку и развитие приложения; а в ряде случаев, стоит, наоборот, использовать некоторые технологические преимущества, чтобы повысить надёжность приложения или его части.
Вместо выводов
Наверное, нет универсального подхода в разработке приложения, однако, если ответить себе в самом начале на вопросы, связанные с его размерами, допустимыми сроками разработки, желаемой аудиторией и сложностью поддержки, то всё встанет на свои места и можно будет создать не "просто игру", а нечто такое, с чем потом ещё можно будет взаимодействовать в будущем.
